[gdal-dev] Issues with shapefiles with Z values?

[Rahkonen Jukka]

Hi,

Could you ask the author of the PHP library to be more specific and refer to the correspointing parts of the shapefile specification https://www.esri.com/content/dam/esrisites/sitecore-archive/Files/Pdfs/library/whitepapers/pdfs/shapefile.pdf? I think that PolyLineZ and PointZ applies to your data.
What they see and what they suppose to see in the binary content? Do they mean that the Z array is too short and does not contain a height value for the last shape? 
In the shapefile specification 3D is supported for XYM geometries, but having Y requires also M and shapefiles with heights are actually 4D (XYZM). However, the M array is marked as optional in the table 14 of the specification. I believe that what GDAL does with XYZ linestring data is to create a shapefile with shape type 13, that is by the definition XYZM, but it does not write the optional M array at all. The result is effectively XYZM without M, thus XYZ.

-Jukka Rahkonen-

________________________________________
Lähettäjä: gdal-dev <gdal-dev-bounces at lists.osgeo.org> käyttäjän David Strip via gdal-dev <gdal-dev at lists.osgeo.org> puolesta
Lähetetty: Tiistai 14. lokakuuta 2025 23.50
Vastaanottaja: gdal dev <gdal-dev at lists.osgeo.org>
Aihe: [gdal-dev] Issues with shapefiles with Z values?

I'm sending this to the gdal-dev  on the assumption that gdal underlies QGIS's creation and export of shapefiles. Let me know if this is a bad assumption and I'll redirect to qgis-devBackground - I created a vector layer in QGIS with layer type shapefile and geometry type linestring. I then used the drape processing algorithm to add elevation values from a DEM in the QGIS project. I then exported the draped layer as a shapefile. I then passed this shapefile to an online utility that converts the shapefile into a Litchi (drone app) compatible CSV file. The converter issues a number of warnings. I also used the Extract Vertices utility to create point geometry which I also exported as a shapefile. This, too, created warnings.The author of the utility told me he is using a PHP library located here to handle the shapefile. The library author has this to say about the errors:It is indeed what I was suspecting: QGIS is creating a malformed 3D (4D actually) file when there is no Z nor M dimension needed.Basically they're missing binary data for Z and/or M dimensions either for the very last record (pretty usual) or sometimes ALL OF THEM (more rare, but I've seen some of them)!He was not specific beyond that. If I load these shapefiles into QGIS and look at the geometry, the z-values are what I would expect.The LineStringM and Point shapefiles are here.