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

[Even Rouault]

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