Handle axis order issues
------------------------
Key: GEOS-1325
URL: http://jira.codehaus.org/browse/GEOS-1325
Project: GeoServer
Issue Type: Bug
Components: WFS
Affects Versions: 1.6.0-beta2
Reporter: Andrea Aime
Assignee: Andrea Aime
Fix For: 1.6.0-beta4
Axis order issue is thickening.
Out of the box GeoServer:
* forces a lon/lat ordering in the CRS provider. This matches the reality of data sources but not the WFS 1.1 expectations.
* WFS 1.1 capabilities report SRS as urn:x-ogc:def:crs:EPSG:6.11.2:<srs>, which is inconsistent with the actual data
when the srid is not projected
* WFS 1.1 GML3 responses use again urn:x-ogc:def:crs:EPSG:6.11.2:<srs> to specify the geometry SRS, with the same issue
* WFS 1.1 filters are takes as they are, without considering the possiblity of a CRS mismatch with the actual data (I already
have a patch for this).
With this situation the only way to pass the cite tests is to add "-Dorg.geotools.referencing.forceXY=false" to the jvm startup options
and use datastores filled with data in lat/lon order.
A possible solution would be to:
* allow users to specify the srid in both "EPSG:XXXX" and URN format, and to assume "EPSG:XXXX" means lon/lat order,
whilst URN format means lat/lon
* use what the user specified in both capabilities and geometry encoding.
Assuming "EPSG:XXXX" to work in lon/lat order has its issues, but I don't know if it can be avoided:
* there should be a way to tell a datastore is in lon/lat order, and URN gives us none
* old users of GeoServer need continuity
Yet, this is going to speak trouble anyways. There is no OGC document I can refer to that states
anything about URN and EPSG:XXXX format, it's all word of mouth. And the only standard mentioning
the axis order is WMS 1.3, which states clearly EPSG:4326 is to be considered a lat/lon one. So
some people will want to install a GeoServer that treats it like that. They can do that easily specifying
the forcexy parameter on the command line, but then datastores like postgis will stop working (the
datastore grabs the id from geometry_columns and then does a CRS.decode(xxxx), Oracle does
the same because the WKT in the database is plainly broken).
So we may have to think a way to selectively force axis inversion in each feature type (a flag?).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira