[Geojson] State of the GeoJSON

[Allan Doyle]

I'm glad to hear about this progress. I'm sufficiently out of the  
loop to not feel qualified to vote, but I applaud Chris for his  
initiative and perseverance, Sean for his willingness to be cornered,  
Raj for his SRS/CRS knowledge, and the FOSS4G organizers for  
providing the opportunity for them all to meet face to face.

Anyone else I should thank?

	Allan

On Sep 27, 2007, at 05:35 , Christopher Schmidt wrote:

> 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
> _______________________________________________
> Geojson mailing list
> Geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org

-- 
Allan Doyle
Director of Technology
MIT Museum
+1.617.452.2111