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

[Ari Jolma]

I've started a wiki page for the status of the drivers regarding 
measured geometries:

https://trac.osgeo.org/gdal/wiki/MeasuredGeometriesInDrivers

Ari

10.02.2016, 15:05, Even Rouault kirjoitti:
> Le mercredi 10 février 2016 13:53:28, Peter Halls a écrit :
>>> Types on page 2).
>>> PointZ
>>> A PointZ consists of a triplet of double-precision coordinates in the
>> order
>>
>>> X, Y, Z plus a measure"
>>>
>>> I had misinterpreted their meaning of "optional" here and submitted a
>>> documentation query to ESRI on being told I was wrong.  The response was
>>> that M being optional means that it can be valueless, but is always
>>> present.
>> Woo, really ???? That's a genuine scoop.
>>
>> I reported it to  Frank at the time ... but several email systems later, I
>> no longer have my copies of the correspondence with ESRI nor the OGR bug
>> report, in which these were copied.  Somewhere I may still have a backup of
>> my work area, to see what I did in my code.  However, as you say, this is
>> 20+ years ago ....  It was something which, at the time, was causing us
>> some problems ....
>>
>> I think you to be correct in your Shapelib summary below:
>>
>> 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
> 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 was wondering if we should change the behaviour of the shape driver to add
> that nodata M component for XYZ shapes. This wouldn't cause compat problems
> with previous versions of GDAL, but it would cause .shp sizes to grow by ~
> 1/3. So perhaps go on with current behaviour of stripping M component if most
> implementations seem to be OK with that ?
>
>> Best wishes,
>>
>> Peter
>>
>>
>>
>>
>> On 10 February 2016 at 12:31, Even Rouault <even.rouault at spatialys.com>
>>
>> wrote:
>>> Le mercredi 10 février 2016 13:05:20, Peter Halls a écrit :
>>>> Ari, et al,
>>>>
>>>>        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
>>>> M. Note that "no data" value can be specified as a value for M (see
>>> Numeric
>>>
>>>> Types on page 2).
>>>> PointZ
>>>> A PointZ consists of a triplet of double-precision coordinates in the
>>> order
>>>
>>>> X, Y, Z plus a measure"
>>>>
>>>> I had misinterpreted their meaning of "optional" here and submitted a
>>>> documentation query to ESRI on being told I was wrong.  The response
>>>> was that M being optional means that it can be valueless, but is
>>>> always present.
>>> 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
>>>
>>>> Best wishes,
>>>>
>>>> Peter
>>> --
>>> Spatialys - Geospatial professional services
>>> http://www.spatialys.com