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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
