[Geojson] GeoJSON '1.0'?

[Tim Schaub]

For clarification:

I'm responding the the current draft (which uses EPSG:4326) and saying 
that I don't think coordinate_order is needed.

The simple question is whether this should be a valid representation of 
a point in the northern hemisphere:

{
      "type": "Point",
      "coordinates": [-10, 10],
      "crs": {
          "type": "EPSG",
          "properties": {
               "code": 4326,
          }
      }
}

I think it should.

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