[Geojson] Fixing problems in section 4

[Christopher Schmidt]

On Thu, Mar 13, 2008 at 10:41:52AM -0600, Sean Gillies wrote:
> Hi all,
> 
> I'm pretty much a +1 to go to 1.0 after we address 2 things:
> 
> >                     4.1.2.2.4. Unless your data falls under one of the
> > exceptions above, you should prefer EPSG codes to OGC URNs.
> 
> I'm -1 on this (which I've been overlooking until now). OGC URNs should
> be preferred to the legacy EPSG:n identifiers. Let's make GeoJSON about
> best practices.

OGC URNs don't yet "exist", which is why they're not preferred.
Encouraging the use of a non-approved URN unless absolutely neccesary
seemed troublesome, which is why it was written that way. I also think
there is a lack of support for these URNs because they're not yet
complete.

> The default case is already done exactly right in the spec. We could
> make it more clear that almost every open source GIS user could use the
> default instead of specifying "EPSG:4326".

Sure.

> Category 2 includes both OGC URNs and legacy EPSG:n identifiers. I think
> we can radically simplify to
> 
> "crs": {"value": "urn:ogc:..."} or "crs": {"value": "EPSG:..."}

I like this in general, though I like it better with 'type' as below. 

> with a strong preference for the former. This simplifies the data and
> also (in my opinion) is less offensive to the Category 3, the case where
> clients dereference a URL to get CRS parameters, can be represented by
> 
> "crs": {"link": {"href": "http://spatialreference.org/..."}}

Sure, though I still like a 'type' hint: maybe this isn't important
because Content-Type headers tell you the type, but most encodings of
projection don't have any reasonable content type (Well-Known Text
content type anyone?), which is why I liked the hint.    

> So, my rewrite of section 4 would be something like
> 
> 4. Coordinate Reference Systems
> 4.1 The default
> 4.2 CRS identifiers
> 4.2.1 "OGC URNs should be used whenever possible in preference to legacy
> EPSG:n identifiers"

If OGC is happy with that OR the URN is actually approved, this sounds
fine to me. 

> 4.2.2 "value" member
> 4.3 CRS links
> 4.3.1 "link" member
> 4.3.1.1 mandatory "href" member
> 4.3.1.2 "optional type member"
> 
> As I recall, the "properties" member specified currently in 4.1.2 is
> nothing more than a leftover of early discussions about putting PROJ4
> parameters directly into a crs object. That use case seems to have
> evaporated, yes?
> 
> A less radical departure from the current text of section 4, but that is
>  still a simpler way to treat the 3 CRS categories above would be: for 2)
> 
> "crs": {"type": "id", "value": "urn:ogc:..."}
> 
> and for 3)
> 
> "crs": {"type": "link", "value": {"href":
> "http://spatialreference.org/..."}}

I like this better. And still like the idea of encouraging type hints.

Regards,
-- 
Christopher Schmidt
MetaCarta