[Geojson] [OSGeo-Standards] EPSG + Coordinate Ordering (Was Re:GeoJSON '1.0'?)

[Christopher Schmidt]

On Fri, Mar 14, 2008 at 09:21:22AM -0600, Carl Reed wrote:
> Christopher -
> 
> I understand your concerns.  However, the axis order issues transcends the 
> requirements for rapid development or any one application. 

Hm, I'm not sure where "one application" comes in? I accept that axis
order is extremely important, and making clear how to map your axis ordering
into data is absolutely imperative: but I'm not sure that I'm convinced
that this ordering *must* be represented in the format of the data. 

If a binary format were to encode geometry such that coordinates were
not stored as tuples, but instead as several different linked lists,
this wouldnt' be a problem. The fact that GeoJSON is mostly human
readable is the only reason this is a concern at all. 

I don't believe that human readability changes the requirements which
are placed on a particular encoding.

> Standardized approaches to using geospatial content (including
> payloads) and services is of paramount importance in many industries
> and enterprises. 

Understood. All the more reason to make it clear what the payload means
so that any application can consume it.

> For example, 
> the location services industry as represented by the Open Mobile Alliance, 
> the e-business industry as represented by OASIS and the internet industry 
> as represented by the IETF all rely honesty and consistency of how a CRS is 
> expressed even if the default is WFS 84-2d. 

Sure. Though I'll note that GeoJSON is not really in the business of
representing a CRS. 

I'm assuming you meant "honesty and consistency of representing
coordinates in a particular CRS": I value that in order for things to
mean the same thing, we have to agree on their meaning. Of course, that
doesn't seem to be something that is widely agreed upon within EPSG:
They don't seem to provide, for example, a way to determine what 'x' and
'y' mean for EPSG:4326, which makes this problem harder to solve.

> The key words are honesty and consistency. In other words, if one
> chooses to ignore the axis order as expressed in the CRS definition
> and express the geometry coordinate order differently (the crux of the
> lat-lon/lon-lat issue), then the application/payload must say so. 

I'm assuming this is represented in the work that you're doing within
OGC: You mentioned that you would send the paper to the list. Do you
have a timeline in mind for that? This paragraph would seem to me to
indicate: "Without  coordinate_order, GeoJSON would be badly behaved.
With it, it is fine.", but I'm assuming it's more complex than that. 

> The problem we have had is that applications state the 4326 CRS and
> then code the coordinates as lon-lat but say that this is the case.

Hm, "say that this is not the case" or "don't say that this is the
case"? I'm interested in understanding the difference there specifically
(for obvious reasons): I'm also interested in whether a specification
can provide this, rather than requiring it with all payload (which seems
a bit silly, if it's explicit in the spec).

> The focus of the axis order manifesto is providing guidance so that
> this does not happen and that honesty and consistency are achieved.

Sure, a laudable goal.

> As to the drawing and the short pieces on datums, that was written by Roger 
> Lott, chairman of the OGP and formerly Head of Survey BP Exploration. I 
> should have provided the reference! I will update ogcnetwork today.

Oh, I agree with the general principle, and I think that the differences
in the dimensions that are totally accurate: I just think that the
underlying map of buildings is likely a handwave. It looks too pretty to
be based on some actual location :) 

> Finally, as Metacarta is an OGC member, feel free to participate in the 
> process and provide what I know to be valuable implementation experience.

MetaCarta is not an OGC member. (Or at least, no one at MetaCarta is
aware of it, if we are!) 

Regards,
-- 
Christopher Schmidt
MetaCarta