[Geojson] Three more things...

Matt Priour mpriour at kestrelcomputer.com
Sun Mar 16 13:57:17 PDT 2008

As neither an author nor public implementer of GeoJSON, I probably don't 
have much of a vote. However, I really think the *requirement* that features 
must have the exact same CRS as parent or none at all, goes against much of 
the spirit of this spec. I think this should be a recommendation, not a 
requirement. I think that *requirement* should be that the top-level element 
must specify a CRS or all elements are assumed to be default CRS. However, 
if a top-level CRS is set then also make it possible for any child element 
to have its own possibly different CRS.

I would personally never produce mixed CRS and don't think it is a good 
idea. Also any producing mixed CRS would have little hope that clients in 
general will pick up on the mixed CRS properly.
However, I can think of some use cases in which one could produce mixed CRS 
on purpose. For example, MS SQL 2008 will let you have a table with both 
mixed geometry and mixed CRS.

There is so much openness and freedom in the rest of the spec, that this 
seems overly restrictive. It seems to me that GeoJSON is primarily about 
providing a standardized syntax for encoding geographic data and passing it 
over the wire. REQUIREing a prohibition on mixed CRS instead of merely a 
recommendation against it just doesn't seem to fit with this purpose.

Matt Priour
Kestrel Computer Consulting
(210) 699-0242 office/home
(210) 846-4196 mobile
mpriour at kestrelcomputer.com
Martin Daly wrote:
> 1) Add a *requirement* that features must have either exactly the same
> CRS as their parent featureCollection, or none at all. the latter
> implying using the featureCollection CRS (where present)

Agreed. Mixed CRS would be obnoxious.

> 2) Add a *recommendation* that date properties are encoded by
> producers as ISO8601 strings, and parsed back into dates by clients
> (where possible)

I won't be using anything other than ISO8601/RFC3339, but I feel
non-geometry/CRS formats are outside the scope of GeoJSON.

> 3) Add a *recommendation* that all features in a featureCollection
> share the same set of properties (different values of course), to fit
> into the near-universal relational model
> Comments?
> M

GIS folks will do that as a matter of course, but we may not be able to
convince people who want to do otherwise that it's important. Let's
leave schema up to the WFS or origin server if we can.



More information about the GeoJSON mailing list