Lex Tiekink wrote:
Hello,
I've seen on the mailing list that this problem has been talked about
before, but from the previous mails I could not get a definitive solution
for my problem, which is as follows:
I'm using Geoserver 1.6.0 beta4
When I do a WFS GetFeature request (http get)
http://xxx.xxx.xxx.xxx:8080/geoserver/wfs?SERVICE=WFS
<http://xxx.xxx.xxx.xxx:8080/geoserver/wfs?SERVICE=WFS&VERSION=1.1.0&REQUEST
=GetFeature&FEATUREID=road.550224>
&VERSION=1.1.0&REQUEST=GetFeature&FEATUREID=road.550224
I get my resulting feature with geometry in Lon/Lat, as I expect it:
[.]
<gml:MultiLineString srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4326">
<gml:lineStringMember>
<gml:LineString>
<gml:posList>4.89463 52.37444 4.89393 52.37474</gml:posList>
</gml:LineString>
</gml:lineStringMember>
</gml:MultiLineString> [.]
When I do a WFS UPDATE of the feature, (leaving the Lon / Lat in the same
order)
[.]
<wfs:Value>
<gml:MultiLineString xmlns:gml="http://www.opengis.net/gml"
srsName="urn:x-ogc:def:crs:EPSG:6.11.2:4326">
<gml:lineStringMember>
<gml:LineString>
<gml:posList>4.89463 52.37444 4.89393 52.37474</gml:posList>
</gml:LineString>
</gml:lineStringMember>
</gml:MultiLineString>
</wfs:Value>
[.]
The geometry of the feature is written to the database in the wrong order:
Lat / Lon!
Note that the srsName that I get in response to the WFS GetFeature is the
same as I use in the WFS Update.
Hi,
the problem lies in axis order issues that beta4 did not address properly.
First and foremost, when you're using urn:x-ogc:def:crs:EPSG:6.11.2:4326 the
axis order is lat/lon, that's by OGC specification and we cannot do anything
about it.
Beta4 had some issues and mixed axis order depending on the operation you
used, rc1 should be consistent, so:
* every time you get back your data from a WFS 1.1 GetFeature you'll receive
them back in lat/lon by default.
* every time you do an update/insert and do not specify the srsName,
GeoServer will assume data is in lat/lon order
* every time you use urn:x-ogc:def:crs:EPSG:6.11.2:XXXX way of stating a CRS
it will be in lat/lon order (by OGC spec)
* for backwards compatibility with the pre WFS 1.1 world, if you use
EPSG:XXXX or http://…:XXXX ways of expressing a CRS GeoServer will
interpret them as lon/lat instead. Given that WFS 1.0 do use those two
forms, with WFS 1.0 you'll still be using lon/lat formatted data.
I know it's messy, but that's the direction OGC is taking. In WFS 1.2 the
only accepted form of expressing an SRS will be
urn:x-ogc:def:crs:EPSG:6.11.2:xxxx so everybody will be stuck with lat/lon
ordered data.
And btw, that's the specification INSPIRE is going to mandate (that matters
to you if you live in europe) along with WMS 1.3, which again works only
with lat/lon data (for example you'll have to express the bbox in lat/lon
order).
Hope this clarifies a little the issue. I will try to write a wiki page
explaning the issue more in deep before we release GeoServer 1.6.0 final.
Cheers
Andrea
--
View this message in context: http://www.nabble.com/Lon---Lat-in-difrerent-order-between-WFS-insert-and-GetFeature--tf4822466.html#a13839361
Sent from the GeoServer - Dev mailing list archive at Nabble.com.