I have a question regarding to swaping the axis order of coordinates in a
WFS GetFeature request with a spatial filter. My understanding is that since
a general WFS 1.1.0 GetFeature response from Geoserver does switch the axis
so that the latitude is ahead of longitude, so when I assemble my spatial
filter in a GetFeature request I should too switch the axis of coordinates.
But it seems that Geoserver still expects longitude ahead of latitude.
GeoServer assumes that a data source stores its coordinates in lon/lat
(EPSG:4326) natively. In a wfs 1.1 request, the lat/lon
(urn:x-ogc:def:crs:EPSG:4326) srs is assumed to be the "default", so if
your request does not explicitly specify an srsName, lat/long is
assumed. So when that query gets mapped to the back end, an axis flip is
performed.
You do however have the option of explicitly specifying that a wfs 1.1
request is being made in lon/lat. In this case no axis flip is
performed. The easiest way to do this is to specify the
"srsName=EPSG:4326" attribute on the wfs:Query element.
I hope that helps, not sure i did a great job of explaining it.
-Justin
Yingqi wrote:
All,
I have a question regarding to swaping the axis order of coordinates in a
WFS GetFeature request with a spatial filter. My understanding is that since
a general WFS 1.1.0 GetFeature response from Geoserver does switch the axis
so that the latitude is ahead of longitude, so when I assemble my spatial
filter in a GetFeature request I should too switch the axis of coordinates.
But it seems that Geoserver still expects longitude ahead of latitude.
So is that a known issue or there is a way to control?
I have a question regarding to swaping the axis order of coordinates in a
WFS GetFeature request with a spatial filter. My understanding is that since
a general WFS 1.1.0 GetFeature response from Geoserver does switch the axis
so that the latitude is ahead of longitude, so when I assemble my spatial
filter in a GetFeature request I should too switch the axis of coordinates.
But it seems that Geoserver still expects longitude ahead of latitude.
So is that a known issue or there is a way to control?
Can you paste your request? It may be that you specified an srsName
in your geometry that is assumed to be lon/lat.
I tried to explain the issue here: http://docs.codehaus.org/display/GEOSDOC/2.+WFS
Thanks for the help, and you guys are right. It’s the srsName in my geometry which causes the problem. I use geotools to encode the geometry in spatial filter which by default encodes " http://www.opengis.net/gml/srs/epsg.xml#xxxx" as srsName. Everything works as expected when I set srsName to "urn:x-ogc:def:crs:EPSG:xxxx ". One follow up question on this though: is there a way have the geotools GML3 encoder to encode “urn:x-ogc:def:crs:EPSG:xxxx” in srsName attribute of geometry instead of the old way? Right now I have to intercept the xml request and manipulate the DOM to inject that into my request.
I have a question regarding to swaping the axis order of coordinates in a
WFS GetFeature request with a spatial filter. My understanding is that since
a general WFS 1.1.0 GetFeature response from Geoserver does switch the axis
so that the latitude is ahead of longitude, so when I assemble my spatial
filter in a GetFeature request I should too switch the axis of coordinates.
But it seems that Geoserver still expects longitude ahead of latitude.
So is that a known issue or there is a way to control?
Can you paste your request? It may be that you specified an srsName
in your geometry that is assumed to be lon/lat.
I tried to explain the issue here: http://docs.codehaus.org/display/GEOSDOC/2.+WFS
Which encoder exactly are you using for the request? There might be a
quick solution depending on which code you are using.
In GeoServer, we have some utility code that will determine which uri to
use based on the crs... i actually went to port it to geotools however
there is already some methods there that do some similar stuff, i need
to reconcile with the appropriate module maitnainers. I will try to
expedite this process by posting a patch to the geotools developer list
soon.
-Justin
Yingqi Tang wrote:
Andrea, Justin,
Thanks for the help, and you guys are right. It's the srsName in my
geometry which causes the problem. I use geotools to encode the geometry
in spatial filter which by default encodes " http://www.opengis.net/gml/srs/epsg.xml#xxxx" as srsName. Everything
works as expected when I set srsName to "urn:x-ogc:def:crs:EPSG:xxxx ".
One follow up question on this though: is there a way have the geotools
GML3 encoder to encode "urn:x-ogc:def:crs:EPSG:xxxx" in srsName
attribute of geometry instead of the old way? Right now I have to
intercept the xml request and manipulate the DOM to inject that into my
request.
Thanks,
Yingqi
On Dec 29, 2007 12:14 AM, Andrea Aime <aaime@anonymised.com
<mailto:aaime@anonymised.com>> wrote:
Yingqi ha scritto:
> All,
>
> I have a question regarding to swaping the axis order of
coordinates in a
> WFS GetFeature request with a spatial filter. My understanding is
that since
> a general WFS 1.1.0 GetFeature response from Geoserver does switch
the axis
> so that the latitude is ahead of longitude, so when I assemble my
spatial
> filter in a GetFeature request I should too switch the axis of
coordinates.
> But it seems that Geoserver still expects longitude ahead of latitude.
>
> So is that a known issue or there is a way to control?
Can you paste your request? It may be that you specified an srsName
in your geometry that is assumed to be lon/lat.
I tried to explain the issue here: http://docs.codehaus.org/display/GEOSDOC/2.+WFS
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/