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

Even Rouault even.rouault at spatialys.com
Wed Feb 10 05:05:18 PST 2016


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

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list