2

We could be querying a GeoServer or ArcGIS server for WFS features (v1.1.0). However I'm finding that GeoServer takes the envelope bounds in LONG/LAT and ArcGIS takes them in LAT/LONG. The use of srsName="EPSG:..." doesn't seem to have any affect on the input coordinates.

Is this a known situation and is there any reliable solution to cater for this? I see a GeoServer ows:keyword for GeoServer but ArcGIS doesn't have anything like this. I think this would be unreliable. They each have different endpoints (wfs verses WFSServer) though this too is unreliable.

This is a significant issue though I can't see anyone else has had this problem so I feel I must be missing something obvious. Or no one else is trying to hit more than one type of geospatial data servers.

Is this a known problem?

For example.

GeoServer server - http://geossdi.dmp.wa.gov.au:80/services/wfs

POST -

<?xml version="1.0" encoding="UTF-8"?>
<wfs:GetFeature service="WFS" version="1.1.0"
                xmlns:gsml="urn:cgi:xmlns:CGI:GeoSciML:2.0"
                xmlns:ogc="http://www.opengis.net/ogc"
                xmlns:wfs="http://www.opengis.net/wfs"
                xmlns:ows="http://www.opengis.net/ows"
                xmlns:gml="http://www.opengis.net/gml"
                xmlns:er="urn:cgi:xmlns:GGIC:EarthResource:1.1"
                maxFeatures="200"                resultType="results">
<wfs:Query typeName="gsml:Borehole">
    <ogc:Filter>
        <ogc:BBOX>
            <ogc:PropertyName>gsml:collarLocation/gsml:BoreholeCollar/gsml:location</ogc:PropertyName>
            <gml:Envelope srsName="EPSG:4326"><gml:lowerCorner>37.0 -55.0 </gml:lowerCorner><gml:upperCorner>229.0 12.0 </gml:upperCorner></gml:Envelope>
        </ogc:BBOX>
    </ogc:Filter>
</wfs:Query>
</wfs:GetFeature>

ArcGIS server - http://www.ga.gov.au/gis/services/topography/National_Onshore_Gas_Pipelines/MapServer/WFSServer?

Post -

<?xml version="1.0" encoding="UTF-8"?>
<wfs:GetFeature service="WFS" version="1.1.0"
                xmlns:gsml="urn:cgi:xmlns:CGI:GeoSciML:2.0"
                xmlns:ogc="http://www.opengis.net/ogc"
                xmlns:wfs="http://www.opengis.net/wfs"
                xmlns:ows="http://www.opengis.net/ows"
                xmlns:gml="http://www.opengis.net/gml"
                xmlns:er="urn:cgi:xmlns:GGIC:EarthResource:1.1"
                maxFeatures="200"                resultType="results">
    <wfs:Query typeName="topography_National_Onshore_Gas_Pipelines:Gas_Pipelines">
        <ogc:Filter>
            <ogc:BBOX>
                <ogc:PropertyName>SHAPE</ogc:PropertyName>
                <gml:Envelope><gml:lowerCorner>-55.0 37.0</gml:lowerCorner><gml:upperCorner>12.0 229.0</gml:upperCorner></gml:Envelope>
            </ogc:BBOX>
        </ogc:Filter>
    </wfs:Query>
</wfs:GetFeature>
  • In WFS 1.1.0 srsName should be given as "urn:x-ogc:def:crs:EPSG:4326". GeoServer is using the same axis order as in WFS 1.0.0 if srsName is given with just EPSG:4326 docs.geoserver.org/latest/en/user/services/wfs/basics.html. However, without srsName in the filter GeoServer should also use the lat-lon order so you may have found a bug or wrong configuration. – user30184 Oct 26 '15 at 7:02
1

According to https://osgeo-org.atlassian.net/browse/GEOS-6216, older versions of GeoServer had a bug where with an app-schema complex feature the axis ordering is always long/lat, even with WFS 2.0.0 requests or specifying the srs as urn:ogc:def:crs:EPSG::4326.

We unfortunately utilise older versions :-(.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.