opengeospatial / geoedge-plugfest

Repository for Geospatial to the Edge Interoperability Plugfest
http://www.github.com/opengeospatial/geoedge-plugfest
0 stars 2 forks source link

Incorrect axis order interpretation for urn:ogc:def:crs:epsg::4326 in WFS Janus #15

Open robinhoutmeyers opened 6 years ago

robinhoutmeyers commented 6 years ago

The following XML POST request should return INLAND_WATERBODY_S features from the WFS source Janus available at https://externaltest.dev.geocloud.com/server/services/PuertoRicoVector/MapServer/WFSServer : ` <?xml version='1.0' encoding='UTF-8'?>

ns0:SHAPE 17.578125 -67.5 18.28125 -66.09375 ` Following the axis order for urn:ogc:def:crs:EPSG::4326, lat lon is used. However, no features are returned. Switching the lat lon axis order to lon lat does work, but it is expected that this should be the other way around - e.g. according to https://portal.opengeospatial.org/files/?artifact_id=24045. The same behavior happens for returned features; example: ` 0.001 -999999 noInformation -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 5 -999999 -999999 5 -999999 -999999 5 -999999 -999999 5 -999999 -999999 5 -999999 -999999 5 -999999 -999999 -999999 noInformation -999999 -999999 -999999 -999999 BH082 -999999 -999999 -999999 -999999 noInformation noInformation 7 1 -999999 -999999 -999999 noInformation -999999 5 -999999 -999999 -999999 {F14F3A20-4269-44F4-9D0E-1C3EA1D23AC1} -999999 5 -999999 -999999 -999999 -999999 -999999 1/1/1994 160 A9593791-4AE9-4180-8E1E-9CB3D239DEE5 25 No Information No Information No Information -999999 -999999 -999999 No Information No Information No Information No Information ge:GENC:3:1-2:PRI -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 -999999 5 1 20000 {ED427ED2-D469-4E55-9DC4-A711DF2C1E75} {4BFC16ED-BD58-48F2-AF60-A5E4F6DDD664} U REL (AUTHORIZED FOR RELEASE TO) noInformation USA (Trigraph for United States) -999999 -66.57471640699998 18.36690177100007 0 -66.57475487399995 18.36692017100006 0 -66.57479807399994 18.36692930400005 0 -66.57483167399994 18.36693850400007 0 -66.57488447399999 18.36694770400004 0 -66.57494700699993 18.36696597100007 0 -66.57500467399996 18.36698450400007 0 -66.57503347399995 18.36701190400004 0 -66.57504787399995 18.36703030400002 0 -66.57505280699996 18.36703937100003 0 -66.57504787399995 18.36706697100004 0 -66.57501427399995 18.36713130400005 0 -66.57500467399996 18.36715877100005 0 -66.57499020699998 18.36716790400004 0 -66.57494700699993 18.36717710400006 0 -66.57488460699994 18.36714030400003 0 -66.57482687399994 18.36709910400003 0 -66.57474040699998 18.36708990400007 0 -66.57469707399997 18.36707157100005 0 -66.57465880699993 18.36703490400004 0 -66.57463947399998 18.36697977100005 0 -66.57463480699994 18.36695230400005 0 -66.57464427399998 18.36693850400007 0 -66.57465867399998 18.36692937100003 0 -66.57466827399998 18.36691097100004 0 -66.57471640699998 18.36690177100007 0 ` The geometry above uses a lon lat axis order, while lat lon is expected.
bermud commented 6 years ago

Issue also reported by Client J "we had to manually specify axis order 1,2,3 for the features to render correctly."

robinhoutmeyers commented 6 years ago

Still present in sprint 2.

bermud commented 6 years ago

Client E, Sprint 2, reported that he had to check Invert Axis Orientation in QGIS in order for the queries to work.

robinhoutmeyers commented 6 years ago

Yes, but that is a workaround - which I assumed we should not use in an interoperability test.