Le mercredi 10 février 2016 13:22:49, Ari Jolma a écrit : > 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."
Given latest Peter's message, yes likely. And also completely missing M as produced by shapelib up to now. > > > 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 :) Hopefully it is less tricky than shapefiles. I see there are other test failures related to shapefiles as well > > 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? For performance reason, I'd perhaps not read all M values of all shapes, but only the ones of the first shape. An extra enhancement would be to have an option to do a full scan of the shapefile. We could also use that to avoid advertizing Polygon layer geometry type when there's a mix of Polygon/MultiPolygon. > > 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 -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
