[Geojson] State of the GeoJSON

[Christopher Schmidt]

Last night, I cornered Sean Gillies in a smokey backroom to discuss
GeoJSON. I outlined two possible resolutions to the 'type' debate: 
 
 * Remove requirement for type on Feature and Collections. Restrict all
   GeoJSON objects from having the following members:
    * 'features'
    * 'geometries'
    * 'geometry'

 * Leave type be. 

The former required making the spec more complex, and I think I
eventually convinced Sean that it wasn't really required. (We also
discussed that in the case where GeoJSON is provided as part of a
protocol, you can determine this information from other context -- but
that the format itself should not be tied to that.)

I also researched more on my crs/srs stuff, and realized that my earlier
change was silly, and I've reverted that (so the term is CRS again). 

The only outstanding discussion item last night was regarding changing
the geometrycollection and featurecollection to use the 'features' and
'geometries' members instead of just 'members' -- both for less
confusion in the spec (members used for a specific property, and as a
general term) and for creating more descriptive property names. 

I've gone ahead and made the change to the more descriptive names in
Draft4, as well as changing the CRS stuff back.

With this, we have addressed most of the outstanding issues in the
GeoJSON spec as it stands. However, mpd brought up an additional point
this morning on IRC:

We currently tell people to use "type":"EPSG", but explicitly declare
that in the case of EPSG 4326, we are not following the EPSG coordinate
order. After talking to a couple people, I grabbed Raj Singh, who let me
know that OGC has established a CRS URN for this particular type of
projection:

   urn:ogc:def:crs:OGC:1.3:CRS84

So, I think that we should change the CRS section (just a little bit)
more, to say something like:
  
  * Support OGC URNs,
    {"type":"OGC",{"urn":"urn:ogc:def:crs:OGC:1.3:CRS84"}} 
  * "Don't use EPSG:4326 or other CRSes in lat, lon order." If you have data 
     in a projection which is defined to be in lat, lon order, you
     should either find another EPSG or OGC code to use. If you can't,
     you should define a spatial reference URL. If you can't do that,
     you should not include an SRS at all.
  * If your EPSG code doesn't use lat, lon order, you should prefer 
    EPSG codes over OGC URNs.
  * EPSG:4326 in lon, lat order is called urn:ogc:def:crs:OGC:1.3:CRS84
 
This results in us no longer violating the EPSG system, and instead
using alternative representations where available.

Does this seem like a sane solution?

I understand I'm just making a long process even longer, but I'm happy
now that we've resolved the core public debate over the spec -- though
others are welcome to weigh in on a change in opinion.

So, summary:
 * Leaving type
 * Changing *Collection members -> features, geometries
 * Changing CRS section some (exact text not written yet) to encourage
   use of other openly defined codes as alternatives in the case of EPSG
   codes which define lat, lon order.

Regards,
-- 
Christopher Schmidt
MetaCarta