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

[Kurt Schwehr]

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.halls at 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.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
>>
>
>
>
> --
>
> ----------------------------------------------------------------------------------------------------------------
> 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160210/74a2e4b8/attachment.html>