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

[Ari Jolma]

10.02.2016, 13:55, Even Rouault kirjoitti:
> Le mercredi 10 février 2016 12:26:59, Ari Jolma a écrit :
>> One more issue came up.
>>
>> Shapefiles, which have Z will also have M, at least a placeholder for it.
>>
>> Having shapefiles as XYZM always in that case may be problematic.
> Small precision for those not necessarily familiar with the internals of the
> shapefile format. The .shp and .shx header have a declared shape type (used to
> set the OGR layer geometry type), that can be (restricting to the case of
> polygon for the sake of clarity, but true for other geometry types) :
> SHPT_POLYGON : the shapefile contains only Polygon 2D shapes
> SHPT_POLYGONZ:  the shapefile may contain a mix of PolygonZ or PolygonZM shapes

Would you differentiate between *Z or *ZM and * and *M shapes using the 
ESRI "no data":

"Nevertheless, shapefiles support the concept of "no data" values, but 
they are currently used only for measures. Any floating point number 
smaller than –1038 is considered by a shapefile reader to
represent a "no data" value."



> SHPT_POLYGONM: the shapefile may contain a mix of Polygon or PolygonM shapes
>
> Declaring a SHPT_POLYGONM as a PolygonM layer is OK (if the shapefile doesn't
> contain PolygonM shapes, it should declare only SHPT_POLYGON)
>
> But declaring SHPT_POLYGONZ as a PolygonZM layer, when there are in fact no
> PolygonZM shapes in it but just PolygonZ, is more problematic for backward
> compatibility issues. Ideally when dealing with shapefiles without M values we
> shouldn't advertize M neither in the layer geometry type, nor in the feature
> geometry.
>
>> It is possible to use the open options SHPT=type to override the
>> default. We could have Z => XYZ as default for backwards compatibility
>> and require open option for Z  => XYZM.
> That's one possibility. As open options should be a last resort, if SHPT isn't
> specified perhaps we could do a probing of the first shape. If it has a M
> component then advertize xxxxZM geometry type, otherwise just xxxxxZ. That's
> of course not completely bullet proof as there can be in theory a mix of Z and
> ZM shapes, but my feeling is that this should work in > 90% of the cases.
>
> That's an improvement I could have a look at during the Code Sprint if you
> don't feel confident enough in the shape driver.

Feel free to have a look. I'm now stuck with the pg driver :)

Maybe, if what I wrote above is correct, read the whole shapefile in and 
then, if all M values are "no data" downgrade all geometries to XY or XYZ?

Ari


>
>
> ~~~~~
>
> Somehow related issue I've noticed but that should be more easily fixable. Now
> creating a Polygon25D shapefile creates PolygonZM and not PolygonZ shapes (and
> perhaps true for other shape types).
>
> trunk:
> $ ogr2ogr poly25d.shp poly.shp -nlt multipolygon25d -overwrite
> $ ll poly25d.*
> -rw-r--r-- 1 even even  529 2016-02-10 12:36 poly25d.dbf
> -rw-r--r-- 1 even even  557 2016-02-10 12:36 poly25d.prj
> -rw-r--r-- 1 even even 8820 2016-02-10 12:36 poly25d.shp
> -rw-r--r-- 1 even even  180 2016-02-10 12:36 poly25d.shx
>
> 2.0:
> $ ogr2ogr poly25d.shp poly.shp -nlt multipolygon25d -overwrite
> $ ll poly25d.*
> -rw-r--r-- 1 even even  529 2016-02-10 12:36 poly25d.dbf
> -rw-r--r-- 1 even even  557 2016-02-10 12:36 poly25d.prj
> -rw-r--r-- 1 even even 6700 2016-02-10 12:36 poly25d.shp
> -rw-r--r-- 1 even even  180 2016-02-10 12:36 poly25d.shx
>
> On the read size, I've commited https://trac.osgeo.org/gdal/changeset/33408
> "Shape: fix crash when reading a MultiPointZ without M values, and when reading
> a PointZ without M do not create a PointZM geometry (trunk only)"
>
> Quickly checking at the code, I think other geometry types are OK, but perhaps
> we should have more extensive cases :
> - adding Z shapefiles of other geometry types generated with GDAL 2.0 and
> checking that the ExportToIsoWKT() read with trunk is the one expected
> - and/or generating Z shapes with trunk and checking they are read as Z only
> with ExportToIsoWKT()
>
>> Ari
>>
>> 09.02.2016, 17:07, Ari Jolma kirjoitti:
>>> I declare this motion passed with +1 from Even, Tamas, Jukka and
>>> Daniel and no -1.
>>>
>>> I'll commit soon the changes to the core and then later the drivers:
>>> memory, shape and pg. The goal is to keep the travis test build passing.
>>>
>>> Ari
>>>
>>> 05.02.2016, 10:04, Ari Jolma kirjoitti:
>>>> I'd like to ask the PSC and others to vote on adopting RFC 61:
>>>> Support for measured geometries.
>>>>
>>>> The draft RFC is at
>>>>
>>>> https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries
>>>>
>>>> and a draft implementation is at
>>>>
>>>> https://github.com/ajolma/GDAL-XYZM
>>>>
>>>> which is tested at
>>>>
>>>> https://travis-ci.org/ajolma/GDAL-XYZM
>>>>
>>>> (the test #34, which passed, was the so far last one after core
>>>> changes with unchanged autotests and a rather comprehensive set of
>>>> WKT tests in the Perl tests directory)
>>>>
>>>> This is seemingly a small change but it is at the heart of OGR so it
>>>> has some important implications. The only backwards incompatibilities
>>>> that have appeared so far are with some drivers, for example
>>>> shapefile, which can be lessened with, e.g., open options.
>>>>
>>>> Best,
>>>>
>>>> Ari