[Geojson] GeoJSON '1.0'?

[Christopher Schmidt]

On Thu, Mar 13, 2008 at 07:43:59AM -0400, Panagiotis (Peter) A. Vretanos wrote:
> I think what Raj may have meant is that that all coordinate system 
> definitions (especially the ones from the EPSG database) include 
> (whether implicitly or explicitly) a statement about the coordinate 
> order which should be used when encoding the coordinates.
> 
> In the case of EPSG:4326 that order is lat, long because it is declared 
> to be a geographic coordinate system (as opposed to a projected 
> coordinate system) in the EPSG database.
> 
> So if you use EPSG:4326 and are encoding the coordinates in x,y (or 
> long,lat) ... well, Raj said it best "You can't do that."!
> 
> The obvious thing to do is simply state: Do what the CRS says.

Right, GeoJSON will not do that. We're not goign to get into the
confusion of x,y, y,x ordering that has hit WMS. It hurts clients, it
hurts servers, it hurts anyone without an intimate knowledge and
understanding of CRSes. So, given that we're not going to do that, the
question is: what should we do?

> BUT ... there is legacy.
> 
> In the distant past, the WMS specification used EPSG:4326 in its 
> examples.  HOWEVER, it used it with the coordinate order of long,lat 
> which according to the EPSG database is not correct.  So, we ended up 
> having a lot a client's built expecting EPSG:4326 to be in long,lat 
> order (or x,y).

Right, and GeoJSON will be one of these.

> So now we are in a situation where you have some clients who incorrectly 
> think that EPSG:4326 is long,lat and other who correctly think that 
> EPSG:4326 is lat,long.  What to do?

Luckily, GeoJSON doesn't have this problem. The spec and examples are
all very clear: The data is in x,y.

> One proposal is to explicitly have servers state the encoded coordinate 
> order using some tag.  OGC, for example, is pondering using a tag called 
> geometricCoordinateOrder in the output so that servers can say:  My 
> coordinates are in the EPSG:4326 CRS but are being transmitted in 
> long,lat order.

This sounds very much like the coordinate_order key/value pair that we
were discussing adding to (or rather, removing from) GeoJSON. 

> Not sure if this information helps but there you have it.  I hope I got 
> the details right because I am not a CRS expert and have generally tried 
> to avoid getting involved in the whole CRS-coordinate order discussion 
> ... especially in OGC where is seems to always spark heated debate.

This is essentially all stuff we know. The question comes down to this
statement:

> So if you use EPSG:4326 and are encoding the coordinates in x,y (or 
> long,lat) ... well, Raj said it best "You can't do that."!

*Why?* The answer is obviously not the same for GeoJSON as it is for
WMS: In WMS, there was no explicit statement that said "Ignore the CRS:
It's always in x, y." If the reason that there is a problem is because
the spec is poorly written, then that problem is *solved* with GeoJSON. 

Assuming that you override the ordering of the CRS in your spec: why
can't you use EPSG:4326?

Regards,
-- 
Christopher Schmidt
MetaCarta