Jody Garnett ha scritto: > Andrea Aime wrote: >> To recap the situation with OGC (I'm currently speaking to Raj >> and other folks alongside Frank Stegging from Bentley software): >> * EPSG:XXXX was dubious from the beginning, OGC is going to deprecate >> it are remove it from all standard, and it's safe to treat it >> as lon/lat ordered since everybody is doing it. >> * urn:x-ogc:def:crs:EPSG:6.11.2:XXXX is clearly lat/lon since it has >> been published after the clarification on what the expected axis >> order is (the one specified in the authority, in case of EPSG, >> it's lat/lon) >> * http://www.opengis.net/gml/srs/epsg.xml#XXXX is problematic, there >> is no clear assumption. The only thing I could say is that all >> WFS 1.0 are bound to use it and they react by treating it as >> lon/lat, so I guess we should do the same. >> > Ack?" I thought this one was lat/lon as well? Grumble. >> Long story short, we need GeoTools to respect the >> "org.geotools.referencing.forceXY" hint for the >> "http://www.opengis.net/gml/srs/epsg.xml#XXXX" form as well >> (or give us another hint to influence the interpretation of it). >> >> A possible workaround on the GeoServer side would be to kill all >> CRS.decode(...) calls, create our utility class that does the same, >> but that works with the above specified issues, calling >> CRS.decode(id, forceXY) under covers and forcing the crs depending >> on how the id looks like (id.startsWith("http") -> force xy). >> The drawback is that there is no guarantee things will go smoothly, >> because the GeoTools datastores will happily keep on doing >> CRS.decode(srsSpec). >> > Yeah; just fix decode to follow the current whim of the OGC. That is why > we made the method to begin with; the story is "I don't know what this > is turn it into the correct CRS for me".
I wish this was that simple. Not even OGC guys know what's the right interpretation for http://www.opengis.net/gml/srs/epsg.xml#4326. They say it's lat/lon, but common practice say otherwise, and you cannot find a single document stating how this should be handled publised at the time when wfs 1.0 was released. Even if the recommendation they make in two months from now say it has to be lat/lon, what value does that have? The common practice for that expression is lon/lat. That's why I prefer a configurable setting, so that people can choose their poison and adapt it to their context (aka "the clients that are hitting the server and their expectations"). Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
