I'm +0. Neither for nor against. One request:
#define OGR_G_NOT_EMPTY_POINT 0x1 #define OGR_G_3D 0x2 #define OGR_G_MEASURED 0x4 #define OGR_G_IGNORE_MEASURED 0x8 Can you make these a static const int or static const unsigned int member of the OGRGeometry class? #defines make life more difficult. find . -name \*.h -o -name \*.cpp | xargs grep '#define' | egrep '[0-9"]' | egrep -v '[(]|\[' | wc -l 4517 A random example of doing this: https://trac.osgeo.org/gdal/browser/trunk/gdal/alg/gdal_simplesurf.h?rev=33127#L93 // Descriptor length static const int DESC_SIZE = 64; -kurt On Wed, Feb 10, 2016 at 4:53 AM, Peter Halls <p.ha...@york.ac.uk> wrote: > > 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 > > Best wishes, > > Peter > > > > > On 10 February 2016 at 12:31, Even Rouault <even.roua...@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 >> > > > > -- > > ---------------------------------------------------------------------------------------------------------------- > Peter J Halls, PhD Student, Post-war Reconstruction and Development Unit > (PRDU), > University of York > > Snail mail: PRDU, Derwent College, University of York, > Heslington, York YO10 5DD > This message has the status of a private and personal communication > > ---------------------------------------------------------------------------------------------------------------- > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- -- http://schwehr.org
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev