[GeoJSON] Aligning implementations

[Allan Doyle]

On Apr 11, 2007, at 11:51, Tim Schaub wrote:

> 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?

Hmm. I admit, I bleeped over that when it went by. I guess the 'srs'  
definition could say something like

If not present, WGS84 is implied..blah blah.. UNLESS the object is a  
member of a collection with an alternate srs definition.

But if an application has a collection of features, and it serializes  
those to geojson, can't it just jam in an srs into each geometry  
anyway? What if one of the srsless geometries escapes the confines of  
its parent array? An extra 10 or so bytes per object is not a huge  
price.

>
>> 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?

Yeah, this came up on the wiki....

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

We can call the atomic unit a coordinate rather than a point.

Then a point can be an array of one coordinate. A line can be an  
array of two or more, a polygon can be an array of lines, etc.

It might be worth trying to align with Simple Features WKT, something  
I'm not really up on.

>
>>                     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?

I'm slightly worried about special-case switches. Maybe crschmidt can  
give us a visceral reaction.

	Allan

-- 
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org