Hi Marco, Thanks very much for the advice. The work around of including the srsName parameter, or using WFS 1.0.0, works well and gets us out of a hole.
Given that the inconsistent axis order in nested geometries appears to be a bug, I will open a ticket on JIRA. Kind regards, Aaron Sedgmen. From: Marco Volpini <marco.volp...@geo-solutions.it> Sent: Wednesday, 28 April 2021 5:44 PM To: Sedgmen Aaron <aaron.sedg...@ga.gov.au> Cc: Geoserver-users@lists.sourceforge.net Subject: Re: [Geoserver-users] Inconsistent axis order in app-schema WFS json output [SEC=OFFICIAL] Hi, unfortunately this looks like an AppSchema bug. A possibile workaround for this problem is to force the SRS to be EPSG:4326 with east north axis order: you should be able to obtain all the geometries with the same coordinates order adding the srsName=EPSG:4326 parameter eg. https://boreholes.gs.cloud.ga.gov.au/wfs?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlbh:Borehole&outputFormat=json&featureid=ga.borehole.10093&srsName=EPSG:4326; alternatively you can use wfs 1.0.0 that by default request features using the east north axis order. If you are interested in here some more details on the issue: the GeoJSON standard mandates a longitude latitude axis order, while the different wfs protocol version have different way to handle this (more details are available here<https://docs.geoserver.org/latest/en/user/services/wfs/axis_order.html#:~:text=The%20formal%20EPSG%20definition%20provides,representation%20has%20east%2Fnorth%20order.>). The GeoServer encoding mechanism will force, for all the wfs version and CRS definition, the order to longitude latitude on the basis of the CRS axis order definition of the Geometry. In this case seems that due a bug in AppSchema the nested Geometry end up having a wrong axis order definition and that the GeoJSON encoder which wrongly switch the coordinates order. Best regards, Marco Volpini Il giorno ven 23 apr 2021 alle ore 05:39 Sedgmen Aaron <aaron.sedg...@ga.gov.au<mailto:aaron.sedg...@ga.gov.au>> ha scritto: Hi GeoServer Users, I have an app-schema WFS with a feature type containing a 3D LineString geometry. I’m finding that the axis order of the x,y coordinates is inconsistent in the json output, i.e. some features are returned with latitude first and longitude second and others the reverse. Following are two example features from our test server to illustrate the issue. The “shape” property contains the LineString geometry: Correct axis order - https://boreholes.gs.cloud.ga.gov.au/wfs?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlbh:Borehole&outputFormat=json&featureid=ga.borehole.466607 Incorrect axis order - https://boreholes.gs.cloud.ga.gov.au/wfs?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlbh:Borehole&outputFormat=json&featureid=ga.borehole.10093 gml32 output is ok, i.e. x,y axis order is the same for all features. The examples are from a GeoServer 2.18.1 and postgres/postgis installation. I’ve also tested with GeoServer 2.19.0 and an Oracle database, with the same results. There are no differences in geometry type, srid and ordering of the coordinates in the database geometries (both postgis and Oracle) where axis order differs in the WFS json output. Any suggestions or advice on what may be causing the inconsistent axis order would be much appreciated. Regards, Aaron Sedgmen. Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is intended only for the person or entity to which it is addressed. If you are not the intended recipient, then you have received this e-mail by mistake and any use, dissemination, forwarding, printing or copying of this e-mail and its file attachments is prohibited. The security of emails transmitted cannot be guaranteed; by forwarding or replying to this email, you acknowledge and accept these risks. _______________________________________________ Geoserver-users mailing list Please make sure you read the following two resources before posting to this list: - Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/ - The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer Geoserver-users@lists.sourceforge.net<mailto:Geoserver-users@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/geoserver-users Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is intended only for the person or entity to which it is addressed. If you are not the intended recipient, then you have received this e-mail by mistake and any use, dissemination, forwarding, printing or copying of this e-mail and its file attachments is prohibited. The security of emails transmitted cannot be guaranteed; by forwarding or replying to this email, you acknowledge and accept these risks.
_______________________________________________ Geoserver-users mailing list Please make sure you read the following two resources before posting to this list: - Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/ - The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
