[GeoJSON] Aligning implementations

[Tim Schaub]

Hey-

Allan, thanks for putting together the proposal.  A few questions below.

Allan Doyle wrote:
> 1. A feature is an object.

It seemed there was some interest in collecting features in an object like:

{'features': array}

This would allow individual members of the feature array to inherit the 
crs of the collection - like:

{'features': array, 'crs': string}

Was there consensus on this?

> 2. A feature may have a name/value pair whose name
>     is 'geometry' and whose value conforms to rule 3.
>     (A feature may have any other name/value pairs,
>     without restriction.)
> 
> 3. The value of a geometry must itself be an object with
>     the following name/value pairs:
> 
>     'type' - [Point | Line | Polygon | Box]
> 
>     'coordinates' - In the case of a Point, an array
>                     of two or three number values representing
>                     x, y, and optionally z. In all other cases,
>                     an array of arrays of number values as in Point,
>                     restricted as follows:
>                     A Line must have at least two values.
>                     A Polygon must have at least three values.

This describes a Polygon as an array of Point arrays.  I think it's 
unnecessary to say that all GeoJSON Polygons will have one and only one 
linear ring.  Could we say that a Polygon is an array of Line arrays and 
that a Line is an array of Point arrays?

(That would need to change if a Point became an array of an array of 
values.)

>                     A Box must have exactly two values.
> 
>     'srs' - an optional string specifying a spatial reference system of
>             the coordinates.
>             If not present, WGS84 is implied and coordinates represent
>             decimal degrees ordered as "longitude, latitude  
> [,elevation]" and
>             z is expressed as meters above mean sea level per WGS84.
>             If present, the value of srs is to be interpreted as in  
> PROJ4's
>             EPSG tables and the values of the coordinates are to be  
> interpreted
>             accordingly.
> 

As above, does it work for people if a feature can inherit its CRS from 
the collection?

Tim