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