Here is the information from the "horses mouth" (Carl Reed) as dug
out of my mailbox from just under a year ago:
Prior to the June meetings, there was considerable email dialogue
regarding axis order and coordinate reference systems. During the
closing TC Plenary, we continued the dialogue. After some
discussion, the members in attendance agreed that:
1. Going forward, for new specifications, coordinate values shall
be listed in the axis order specified by the referenced coordinate
reference system (CRS).
2. Going forward, when a RWG is working on edits to an existing
adopted specification related to CRS and axis order, coordinate
values shall be listed in the axis order specified by the
referenced coordinate reference system (CRS).
2. Going forward, for updated and new OGC specifications, CRSs
should be referenced using URNs in the "ogc" URN namespace, as now
specified in Clause 7 of OGC 05-010/OWS Common (unless a URL is
used to reference a CRS ).
3. Existing adopted specifications will remain as is unless change
requests are submitted and accepted, that seek consistency in CRS
usage - such as for WMS.
Hopefully, we can finally but the axis order discussion to rest!
For those of you in attendance at the June meetings - if I missed
anything related to the discussion and decisions, please let me know.
On May 23, 2006, at 6:35 PM, Martin Desruisseaux wrote:
1) "EPSG:whatever = (longitude,latitude) axis order no matter what
the EPSG database said"
is now a formal OGC decision, and every OGC-compliant data
sources in the world should
comply with it.
See above. It is not clear, and no clarification was ever gained, on
what the situation with *existing* specifications was. The reality-
on-the-ground is that every WFS 1.0 (note, W*F*S, not WMS)
implementation I tested that advertised EPSG:4326 as its CRS returned
data on lon/lat order.
2) About every OGC data sources in the world are already using the
above-cited convention,
because of the (broken) way the OGC's WMS specification was
wrote. Actually, the above-
cited OGC's decision was just a recognition of the current stade
of affair of most data
in the world.
Actually, starting in WMS 1.1, the specification actually explicitly
states that the EPSG axis order is to be used, while making a special
case *exception* for EPSG:4326, which was to be in lon/lat order.
Oddly, they did not make exceptions for all geographic coordinate
systems (like, say EPSG:4269) just for EPSG:4326. Finally in WMS
1.3, that exception was dropped as well, to consternation all around.
Anyway, for now I plan to keep "EPSG:whatever" as "real EPSG" for
now (despite OGC decision) and users would have to invoke
OrderedAxisAuthorityFactory.register("EPSG") explicitly if they
wants the (longitude,latitude) axis order.
I think that is wise, since any fully interoperable solution (like
uDig) will have to be a fairly implementation specific balance of
ignoring EPSG axis order in some cases and respecting it in others,
depending on what facts one finds on the ground. For example, the
WMS 1.3 new behavior is not obvious in the specification (though it
is there, if one looks for it), and I am sure there will end up being
a number of "WMS 1.3" implementations out there that continue to use
lon/lat order, which will then require special casing in order for
WMS clients to work properly.
Paul
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
