[Geojson] Fixing problems in section 4

[Sean Gillies]

Christopher Schmidt wrote:
> 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,

"crs": {
  "type": "link",
  "value": {
    "href": "http://spatialreference.org/...",
    "type": "proj4"
    }
  }

That works for me.

According to the history at

https://datatracker.ietf.org/idtracker/draft-creed-ogc-urn/

OGC URNs are all but published. It's possible that there will be a 4th
draft, but it doesn't look like it will be rejected at this point. If
anyone has any evidence to the contrary, please speak up if you can.

I don't want to hold up GeoJSON 1.0, so I'll get cracking on new wording
for section 4 in the wiki and we can vote on merging it into the spec.

Sean