The EPSG Contract

[Paul Ramsey]

GeoTools recently ran into the EPSG ordinate buzz saw, and I was mulling
over the implications for uDig when I realized that Mapserver had the
same problem.

(For reference of those unfamiliar, the backend EPSG database includes a
large amount of information about coordinate reference systems (CRS)
tied to numbers. A CRS includes not only information about projections
and parameters, but also what the meaning of the ordinates are. Is the
first ordinate an easting? a northing? if you are in South Africa, your
first ordinate might be a westing. if you are in Finland, it might be a
northing. In North America, our convention has been very strong
easting/northing, but that is not a global convention, and the EPSG
database reflects this. The place we notice it most, is that they define
the ordinates for geographic systems (lat/lon) as northing/easting. Note
that this order is actually the order we usually use when talking about
this system (we call it lat/lon). Ironic, because when we save data
files or put things on the screen, we almost always have the order as
lon/lat.)

We talked about this issue earlier, when discussing WMS 1.3 and the
re-imposition of the EPSG contract ("if you use our authority numbers,
use them correctly"). I assumed at the time that since Mapserver had not
yet grasped the 1.3 nettle it was still "safe" from this new
interoperability mine field.

However: Mapserver is not just a WMS, it is also a WFS. As such, if it
returns GML with a crs in the EPSG authority space, it is probably
breaking the contract, since I assume all the ordinates are coming out
in easting/northing order, regardless.

This whole issue is going to reach a breaking point soon, as some of the
OGC vendors carefully implement according to the contract, and others do
not. So far our default community response has been a combination of
"we're not going there (WMS 1.3)" and "uh oh".

GeoTools already has a pretty robust CRS mechanism: we can support
proper EPSG ordinate handling with only a little extra code. But that
assumes that the world we are going to interoperate with also honors the
contract.

For mapserver to honor the contract, proj will have to be updated to
include ordering in the projection objects, and then read/write things
in the correct order relative to the definitions. And the epsg file
would have to be updated to include the ordinate information for each
number. Then mapserver would have to be updated to work in "inverted
epsg" mode for the old WMS versions and in "real epsg" mode for future
WMS versions and WFS. It is not a lot of work, but it *is* work. And it
would involve a direct version tie between mapserver/proj (this version
of mapserver requires proj X or higher)

This is a really obscure issue, but the longer we ignore it the worse it
will get. We can use our implementation weight to try and get the result
we want (maybe we want easting/northing to be an ironclad assumption,
and damn the EPSG) but if we are going to do that, we should be
*explicit* about it, not just sleepwalk into it.

And if we want to follow the direction of the standards bodies (ISO,
OGC) then we should do the work ASAP, because the longer implementations
with broken contracts are out there, the more bifurcated and
non-interoperable the whole "geoweb" is going to get.

Thoughts, concerns, etc?

Paul