[Geojson] Request for comments (Re: Fixing problems in section 4)

[Sean Gillies]

Sean Gillies wrote:
> 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

http://wiki.geojson.org/Rethinking_CRS

Sean