[Geoserver-users] Update from Geoserver 2.14 to 2.22 : WFS 1.1.0 result missing Z coordinate

GeoServer GeoServer User
1

Hi all,

I am trying to update from Geoserver 2.14 to 2.22. My Geoserver 2.22 instance starts on a copy of the 2.14 instance’s data. Everything looks good from the administration console.

A major difference is present in the WFS responses : This one is from Geoserver 2.14

<gml:MultiLineString srsName=“http://www.opengis.net/gml/srs/epsg.xml#3857” srsDimension=“3”>
gml:lineStringMember
gml:LineString
gml:posList676197.14171868 6332811.49687361 0 676205.71421278 6332795.82409933 0 676220.6667465 6332779.85090715 0 676244.61888527 6332759.23118246 0 676283.79094172 6332732.20673133 0 676325.2299601 6332703.43080496 0 676356.11501381 6332741.40711378 0 676382.92919821 6332782.03057298 0 676396.72379804 6332804.57979136 0 676404.37781378 6332825.87365151 0</gml:posList>
</gml:LineString>
</gml:lineStringMember>
</gml:MultiLineString>

And this one is from Geoserver 2.22

<gml:MultiLineString srsName=“http://www.opengis.net/gml/srs/epsg.xml#3857” srsDimension=“3”>
gml:lineStringMember
gml:LineString
gml:posList676197.14171868 6332811.49687361 676205.71421278 6332795.82409933 676220.6667465 6332779.85090715 676244.61888527 6332759.23118246 676283.79094172 6332732.20673133 676325.2299601 6332703.43080496 676356.11501381 6332741.40711378 676382.92919821 6332782.03057298 676396.72379804 6332804.57979136 676404.37781378 6332825.87365151</gml:posList>
</gml:LineString>
</gml:lineStringMember>
</gml:MultiLineString>

As you can see, the Z coordinate is absent from the Geoserver 2.22 response despite the srsDimension value ‘3’. As a result, my code can’t deserialize the LineString anymore.

If I switch my WFS request to WFS=1.0.0 on Geoserver 2.22, the Z coordinate is present :

<gml:MultiLineString srsName=“http://www.opengis.net/gml/srs/epsg.xml#3857”>
gml:lineStringMember
gml:LineString
<gml:coordinates xmlns:gml=“http://www.opengis.net/gml” decimal=“.” cs=“,” ts=" ">676197.14171868,6332811.49687361,0 676205.71421278,6332795.82409933,0 676220.6667465,6332779.85090715,0 676244.61888527,6332759.23118246,0 676283.79094172,6332732.20673133,0 676325.2299601,6332703.43080496,0 676356.11501381,6332741.40711378,0 676382.92919821,6332782.03057298,0 676396.72379804,6332804.57979136,0 676404.37781378,6332825.87365151,0</gml:coordinates>
</gml:LineString>
</gml:lineStringMember>
</gml:MultiLineString>

I took some hours to search about this issue but didn’t find anything. Is it a configuration issue ? How could the srsDimension be correct (3) but the Z value ignored only for WFS 1.1.0 ?

Best regards.

2

We have had a number of issues in the past with M and Z coordinates

https://osgeo-org.atlassian.net/browse/GEOT-6096
https://osgeo-org.atlassian.net/browse/GEOT-1716
https://osgeo-org.atlassian.net/browse/GEOS-10667
https://osgeo-org.atlassian.net/browse/GEOT-6740
https://osgeo-org.atlassian.net/browse/GEOT-6599
https://osgeo-org.atlassian.net/browse/GEOT-6362
https://osgeo-org.atlassian.net/browse/GEOT-4337
https://osgeo-org.atlassian.net/browse/GEOS-9520

for example.

What is your datasource? We need a small sample that demonstrates the issue before anyone can consider looking at it.

Ian

···

Ian Turton

3

As Ian indicated we added support for XY, XYZ, XYM, XYZM coordinates - the EPSG:3857 srs you have selected is two dimensional for XY data.

You can process your data, choose an XYZ srs, or configure the geoserver to consider Z as a measure (which should change the GML output).

···

–
Jody Garnett

4

Thank you for all the leads !

Considering the target SRS being only 2 dimensions and based on the users feedbacks from the issues Ian shared, I tested my shapefile with ogrinfo : it contains 3D line string. I used ogr2ogr to create a new version of my shapefile with 2 dimensions only. Using this new shapefile file, my Geoserver 2.14 and 2.22 are now serving the same result, with geometry objets transfered with the srsDimensions=‘2’ attribute.
This is a much cleaner situation than trying to pad the Z in the coordinates.

It seems like I have taken advantage of a bug in Geoserver 2.14 and using a relevant Shapefile in the first place is the best solution going forward.

Another workaround could be to check the “Strict CITE Compliance” on my WFS targeted workspace. The resulting GML does not mention the srsDimensions attribute and Geotools unmarshal successfully my lineString objects.

Best Regards,
François.

···

François Roussel