Hi, it seems the more we try to play ok with CRS, the more we trip into troubles. This time a fix to handle the versioning demo (have the bbox and geometries expressed in 900913 reprojected on the fly to the native CRS before querying) made one of our demo request don't work anymore. The request is the simple:
>wfs:GetFeature service="WFS" version="1.0.0" outputFormat="GML2" maxFeatures="2" xmlns:topp="http://www.openplans.org/topp"; xmlns:wfs="http://www.opengis.net/wfs"; xmlns:ogc="http://www.opengis.net/ogc"; xmlns:gml="http://www.opengis.net/gml"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd";> <wfs:Query typeName="topp:states"> <ogc:Filter> <ogc:BBOX> <ogc:PropertyName>the_geom</ogc:PropertyName> <gml:Box srsName="http://www.opengis.net/gml/srs/epsg.xml#4326";> <gml:coordinates>-130,24 -66,50</gml:coordinates> </gml:Box> </ogc:BBOX> </ogc:Filter> </wfs:Query> </wfs:GetFeature> and it does not work anymore (does not return anything) because for the first time in GeoServer history we're reading the srsName attribute and use it. Now the explaination: Calling CRS.decode("EPSG:4326") in GeoServer returns: (org.geotools.referencing.crs.DefaultGeographicCRS) GEOGCS["WGS 84", DATUM["World Geodetic System 1984", SPHEROID["WGS 84", 6378137.0, 298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943295], AXIS["Geodetic longitude", EAST], AXIS["Geodetic latitude", NORTH], AUTHORITY["EPSG","4326"]] but doing the following, again in GeoServer: CRS.decode("http://www.opengis.net/gml/srs/epsg.xml#4326";) (org.geotools.referencing.crs.DefaultGeographicCRS) GEOGCS["WGS 84", DATUM["World Geodetic System 1984", SPHEROID["WGS 84", 6378137.0, 298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943295], AXIS["Geodetic latitude", NORTH], AXIS["Geodetic longitude", EAST], AUTHORITY["EPSG","4326"]] (notice the axis order in the two). So, it seems GeoTools CRS subsystem tries to respect the authority axis ordering no matter what even for "http://...."; srs versions (it does it already for the "urn:x-ogc:..." version). This is a little problematic because there is current debate with OGC folks on how this one should be handled. In any case, we all know that no current wfs client uses lat/lon ordering so the above is wrong from a practical point of view (it may be ok from a theoretical point of view, but we have to work in the real world). 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. 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). Opinions? 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
