[Geojson] GeoJSON '1.0'?

[Christopher Schmidt]

On Wed, Mar 12, 2008 at 09:27:16PM -0600, Tim Schaub wrote:
> Hey-
> 
> Allan Doyle wrote:
> > Yes, I'm generally +1, but I'm sliding from -0 to -0.1 on  
> > coordinate_order.
> > 
> 
> After proposing coordinate_order (to satisfy imaginary people who I 
> thought would claim that EPSG literature dictated the meaning of our 
> coordinates array instead of the GeoJSON spec), I also am now sliding 
> toward -1 on the idea.
> 
> Here's why.  If someone tells me that they've got a location that is 10 
> degrees north and -10 degrees east, and they tell me that the CRS is 
> referred to by EPSG:4326, I don't want to have to look anywhere except 
> for the GeoJSON spec to know how to encode that in GeoJSON.  (I know the 
> EPSG:4326 example is there.)  

Draft5 before this change did not support EPSG:4326: it was explicitly
disallowed, no? There was no example of how to encode coordinates in
lon/lat with an included CRS, I don't think. (There was a partial CRS
definition inside the spec: perhaps this was enough.)

> My point is, if we really are trying to 
> limit the number of dependencies for dumb clients, we shouldn't force 
> everybody to know that EPSG:4326 requires something like 
> "coordinate_order": [1, 0].

In which case we force clients to know that EPSG:4326 is really spelled
urn:ogc:CRS84 or whatever.

> Apologies for reversing positions, but I now don't want coordinate_order 
> in there at all.
> 
> So, if others agree, I will happily edit the spec to remove 
> coordinate_order.  That is, as long as *nobody* thinks there is a 
> problem saying that this point is in the northern hemisphere (and is 
> perfectly valid GeoJSON):
> 
> {
>      "type": "Point",
>      "coordinates": [-10, 10],
>      "crs": {
>          "type": "EPSG",
>          "properties": {
>               "code": 4326,
>          }
>      }
> }

This is not valid GeoJSON under the previous version of the spec: it is
explicitly disallowed by the CRS section. 

The biggest reason to add coordinate_order was to make this allowable
(with some extra data). If we were fine with this to begin with, then
the spec was wrong. The spec was written the way it was based on the
opinion, expressed by several different reasonably competent people,
that doing what you have done above is not 'allowed'. (Why this is, I
don't know, but it seems like EPSG easily gets cranky about the use of
their letters. Don't ask me how realistic this problem is.)

If we really don't care about pissing off EPSG: that's fine, but simply
ignoring the reason that coordinate_order was useful is not the best way
to go about handling the situation, in my opinion.

Regards,
-- 
Christopher Schmidt
MetaCarta