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

[Even Rouault]

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
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.


~~~~~

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

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