<!DOCTYPE html>

<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    Thanks for taking the time to examine this issue. I was skeptical

    that the fault lies with the library given it's place underlying the

    world of GIS software. I will pass your comments to the developer of

    the PHP library.<br>

    <br>

    On 10/15/2025 1:09 AM, Rahkonen Jukka wrote:

    <blockquote type="cite">

      <pre wrap="" class="moz-quote-pre">Hi,

Could you ask the author of the PHP library to be more specific and refer to the correspointing parts of the shapefile specification <a class="moz-txt-link-freetext" href="https://www.esri.com/content/dam/esrisites/sitecore-archive/Files/Pdfs/library/whitepapers/pdfs/shapefile.pdf">https://www.esri.com/content/dam/esrisites/sitecore-archive/Files/Pdfs/library/whitepapers/pdfs/shapefile.pdf</a>? 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.

</pre>

    </blockquote>

    <br>

  </body>

</html>