[gdal-dev] RFC 61: Call for vote on adoption

[Mike Toews]

On 11 February 2016 at 01:31, Even Rouault <even.rouault at spatialys.com> wrote:
> Le mercredi 10 février 2016 13:05:20, Peter Halls a écrit :
>>       ESRI handle this in a non-intuitive way:  XYM is supported, but Z
>> always has a Measure, so is XYZM!   The formal definition is here:
>> https://www.*esri*.com/library/whitepapers/pdfs/*shapefile*.pdf   (1998)
>>
>>       Shape Types having Z are defined on pp19ff where it states:
>>
>> "Shape Types inX,Y,Z Space
>> Shapes of this type have an optional coordinate
>
> Woo, really ???? That's a genuine scoop.
>
> Unless I'm seriously mistaken, shapelib / OGR has produced XYZ shapefiles
> without M values for more than 20 years. I'm surprised we wouldn't have heard
> about that if such shapefiles couldn't be read. Or perhaps ESRI software is
> robust to missing M too

I've looked into this a few years ago, because I found differences in
XYZ files written by GDAL and Esri software. There are two styles of
(e.g.) PointZ files, where the coordinates are written with either
three or four doubles (the last with "no data" if M is not used). The
style of PointZ is determined by the content length provided in the
record header as 16-bit words (either 14 or 18). Therefore, the specs
are correct when they describe M as an "optional coordinate" (p.15).

For XYZ shapefiles, GDAL always write three doubles, whereas Esri
write four doubles with "no data" as the last coordinate. As a result,
Esri's XYZ shp files are slightly larger than GDAL's.

Occasionally I use software that requires PointZ shapefiles to have
four doubles, so my existing workaround is to use Esri's
CopyFeatures_management tool to rewrite the shapefile.

Could "ogr2ogr -dim 4" be added to this RFC to write XYZ[M] Shapefiles
that always use four floats for coordinates, as Esri software does?


On 11 February 2016 at 02:05, Even Rouault <even.rouault at spatialys.com> wrote:
> Would someone looking at this discussion and having access to ESRI software be
> willing to generate tiny (meaning just one single shape, with the smallest
> number of vertices) shapefiles of type PointZ, ArcZ, PolygonZ and MultiPointZ,
> and *without* M values ? So as to enhance the test suite and see in particular
> which value is set exactly as the nodata value in the M component

I can generate these today, and will attach a zip file to
https://trac.osgeo.org/gdal/wiki/MeasuredGeometriesInDrivers