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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
!DSPAM:4022,47175f307011336712104!
