The request is issued by GeoTools' WFS 1.1.0 data store, but I think it is a POST request. At least it generates an XML query. I am testing against a GeoServer WFS, but as far as I can see from the generated XML query I've managed to intercept, the axis order is lon/lat. According to the docs, GeoServer only wants lon/lat for legacy srsnames for EPSG:4326. As far as I can tell, GeoServer behaves correctly when I manually issue WFS request at it.
This is the GeoTools generated query that doesn't work. It is centered on Oslo, just so that you can relate the coordinates to something. I've removed the typename, as this WFS isn't public. <?xml version="1.0" encoding="UTF-8"?><wfs:GetFeature xmlns:ogc="http://www.opengis.net/ogc"; xmlns:wfs="http://www.opengis.net/wfs"; xmlns:ows="http://www.opengis.net/ows"; xmlns:xlink="http://www.w3.org/1999/xlink"; xmlns:gml="http://www.opengis.net/gml"; handle="GeoTools 11.1 WFS DataStore" outputFormat="text/xml; subtype=gml/3.1.1" resultType="results" service="WFS" version="1.1.0"> <wfs:Query srsName="urn:x-ogc:def:crs:EPSG:4326" typeName="..."> <wfs:PropertyName>FLATE</wfs:PropertyName> <ogc:Filter> <ogc:BBOX> <ogc:PropertyName>FLATE</ogc:PropertyName> <gml:Envelope> <gml:lowerCorner>9.868587259429011 59.695554557915294</gml:lowerCorner> <gml:upperCorner>11.450188116029054 60.275969999291824</gml:upperCorner> </gml:Envelope> </ogc:BBOX> </ogc:Filter> </wfs:Query> </wfs:GetFeature> I haven't been able to test WFS 1.0.0 due to authentication problems, but this has been reported by someone else earlier. As for choice of gt-epsg package, our client is distributed over the Internet to customers with potentially very slow connections, so the smallest self-contained solution wins. That appear to be gt-epsg-wkt. But this does not appear to be the issue here. The axis order problem affects gt-epsg-hsql as well. The difference between them appears to cancel itself out. Regards Tor Egil Riegels Strand > -----Original Message----- > From: Ben Caradoc-Davies [mailto:ben.caradoc-dav...@csiro.au] > Sent: Wednesday, June 25, 2014 10:07 AM > To: Tor Egil Strand; geotools-gt2-users@lists.sourceforge.net > Subject: Re: [Geotools-gt2-users] Axis order when rendering WFS > > Is this a GET or POST? In a WFS GET request, SRSNAME is only applied to > the response. To specify a BBOX with the correct[*] lat/lon axis order, > use the five parameter form: > > BBOX=lat1,lon1,lat2,lon2,urn:ogc:def:crs:EPSG::4326 > > The four parameter BBOX uses the layer default CRS of (in your case) > EPSG:4326 which for reasons of backwards compatibility is implemented > by GeoServer as having lon/lat axis order. Is the server GeoServer? Not > sure if other implementations do this. > > I avoid using gt-epsg-wkt. > > Kind regards, > Ben. > > [*] By correct I mean EPSG and OGC compliant. I am safe being > opinionated while Andrea is on holiday. :-) > > > On 25/06/14 15:32, Tor Egil Strand wrote: > > Hi > > > > I am trying to render a WFS 1.1.0 datasource using GeoTools 11.1, but > have run into some problems, which seems to be due to axis ordering. > The WFS is using EPSG:4326, but I'm projecting it to EPSG:32633. Things > behave differently along the way depending on whether I use gt-epsg-wkt > or gt-epsg-hsql, but in the end, the bbox passed in the WFS query has > longitude first and latitude last, even though srsName is urn:x- > ogc:def:crs:EPSG:4326. With gt-epsg-wkt, east is always first/x and no > axis swapping takes place as the envelope is transformed from > EPSG:32633 (as used in the MapContent) to EPSG:4326 and finally turned > into XML. When I use gt-epsg-hsql, the envelope has north as x and east > as y after it has been transformed to EPSG:4326, but is then swapped > back to the wrong order by invertAxisInFilterIfNeeded() in > WFS_1_1_0_DataStore. > > > > Am I doing something wrong, or is axis ordering in GeoTools WFS > plugin still broken? I know I can force specific axis order, but I will > likely have to deal with WFS-es that aren't EPSG:4326 as well, so I'd > like to hear if there are any other possible solutions first. It might > even be that this is an unknown issue. > > > > (Sorry if this becomes a duplicate. I think something wasn't right > the first time I tried to send this e-mail.) > > > > Regards > > > > Tor Egil Riegels Strand > > Developer > > Direct: +47 32 11 81 61 > > E-mail: tor.egil.str...@kartverket.no > > > > Switchboard: +47 32 11 83 00 > > www.kartverket.no > > > > > > > > --------------------------------------------------------------------- > --------- > > Open source business process management suite built on Java and > Eclipse > > Turn processes into business applications with Bonita BPM Community > Edition > > Quickly connect people, data, and systems into organized workflows > > Winner of BOSSIE, CODIE, OW2 and Gartner awards > > http://p.sf.net/sfu/Bonitasoft > > _______________________________________________ > > GeoTools-GT2-Users mailing list > > GeoTools-GT2-Users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > > > > > > -- > Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> > Software Engineer > CSIRO Earth Science and Resource Engineering > Australian Resources Research Centre ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ GeoTools-GT2-Users mailing list GeoTools-GT2-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
