The EPSG Contract

[Paul Ramsey]

I definitely *am* concerned, because uDig has to function as a generic
WFS client. If mapserver is a WFS 1.0 returning easting/northing and
CubeWerx is a WFS 1.0 returning northing/easting, we are up shit creek.
See-no-evil, hear-no-evil is not consistent with a commitment to
interoperability.

I hope to receive some clarity from the WFS people (it is the state on
the ground of implementations I care about) soon and will feed it back
to one and all.

If this disagreement moves too far out of the committee room into
implementation land (as it already has, since the mapserver WFS
implementation is easting/northing) interoperability begins to die.
We'll need a special mapserver-wfs case for uDig. And then if you fix
it, we'll add a version test. And that is in the perfect world where
only mapserver does this.

Is it so bad to suck it up and follow the standards consensus, no matter
how silly? Sometimes bad decisions are made, but walking away from the
process destroys all the good decisions too.

Frank Warmerdam wrote:

> On 5/18/05, Paul Ramsey <pramsey at refractions.net> wrote:
>
>>Daniel,
>>
>>I think whether Mapserver is broken is a matter of interpretation. In
>>GML 2.1, when a CRS is referred to using an EPSG number, is the full
>>EPSG contract implied? If yes, then mapserver is broken: it returns
>>EPSG:4326 coordinates in easting/northing order. If no, then mapserver
>>is fine.
>
> Certainly my _assumption_ was that GML 2 operated on the basis of
> easting,northing order regardless of what EPSG says.  If you are concerned
> I really think you need to get clarification from the WFS and GML folks
> on this issue.  If we really need to, we can then hack something into
> MapServer's WFS client and server code to do this properly.
>
> I would add that I do anticipate adding some sort of "axis" directives
> to PROJ.4, at least for use with the pj_transform() entry point.  It is
> needed for Krovak projection as well as all these lat/long vs. long/lat
> items.
>
>
>>A speak-no-evil, hear-no-evil approach will just lead to sorrow and
>>wailing in the future. What we need from OGC is a pretty public and
>>solid directive about "what we mean now when we say EPSG:XXXX" and "what
>>we meant two years ago when we said EPSG:XXXX". Because the two are not
>>necessarily the same.
>
>
> I would just like to put a vote in for the "speak-no-evil,
> hear-no-evil" approach.
> I have yet to get past my anger with those who lobbed this compatibility
> nightmare into our midst, and I am loath to spend unfunded time dealing with
> it.
>
> Best regards,