The draft RFC is here
https://trac.osgeo.org/gdal/wiki/rfc61
Ari
27.01.2016, 15:52, Even Rouault kirjoitti:
Le mercredi 27 janvier 2016 14:38:05, Ari Jolma a écrit :
27.01.2016, 15:23, Even Rouault kirjoitti:
Le mercredi 27 janvier 2016 14:01:42, Ari Jolma a écrit :
27.01.2016, 14:34, Ari Jolma kirjoitti:
27.01.2016, 13:27, Even Rouault kirjoitti:
Le mercredi 27 janvier 2016 11:55:01, Ari Jolma a écrit :
Folks,
I'd like to try to implement the XYZM support since I have some free
time.
Before making a RFC, there are some thoughts/questions/ideas:
* I made a fork for this work at https://github.com/ajolma/GDAL-XYZM
so I can more easily use travis.
* I think this is mainly changes in the geometry API and generic
methods.
Are there other drivers than shape, which are affected?
On top of my head: PostGIS, FileGDB, OpenFileGDB, GeoPackage,
Spatialite.
Probably other RDMBs too (Oracle, MSSQL, ... ?)
I'm not so sure that it is so many. For example PostGIS driver is
mostly moving WKB back and forth.
Well, it seems that they are affected. There is for example the
setCoordinateDimension() method, which is called by many drivers and
once measures are supported it becomes ambiguous since coordinate
dimension is 3 for both XYM and XYZ.
I think we should perhaps keep setCoordinateDimension() with the current
semantics for legacy reasons but not accept using 3 for XYM or extending
it to 4 for XYZM
That's my thinking too. The semantics of the old API should be kept the
same.
We should probably remove all its internal uses, and just have it used by
OGR_G_SetCoordinateDimension(). And figure out what the behaviour should be
when called on a XYM or XYZM geometry.
I'm thinking that there should perhaps be a new method
CoordinateDimension(), which would return the same as ST_NDims of
PostGIS. Actually the name of the method is CoordinateDimension()
(without get prefix) in simple feature access documents.
Sounds reasonable.
The OGRGeometry class could have for example a
setCoordinateInterpretation() with an enum XY, XYZ, XYM and XYZM. And a
similar member variable to store it.
set3D(boolean is3D) and setMeasured(boolean isMeasured)? As each
geometry could have boolean Is3D and IsMeasured properties, and the docs
have Is3D and IsMeasured methods.
I think that if possible we should try to minimize the number of attributes in
the base OGRGeometry class so that sizeof(OGRPoint) remains small. Having the
geometry type stored would capture both the Is3D and IsMeasure. And int
nCoordDimension could then potentially be removed, except that we have hacks
currently in OGRPoint : -2 = point 2D empty and -3 = point 3D empty.
Actually, I'm thinking we don't need that hack and that checking if isnan(x)
&& isnan(y) could be sufficient to model a POINT EMPTY (this is what we do in
OGRPoint::importFromWkb() to support the GeoPackage / PostGIS 2.2 way of
representing a POINT EMPTY) and avoid storing an explicit (and hacked)
nCoordDimension.
... or, as currently getGeometryType() dynamically builds the geometry
type, perhaps have instead a wkbGeometryType member in OGRGeometry
itself.
And have a setGeometryType() to modify it, with restrictions on which
kind of geometry type changes are allowed. You can't do
point.SetGeometryType(wkbLineString) )
Actually instead of setGeometryType() , the way QGIS has done with its
QgsAbstractGeometryV2 class, ie with explicit addZValues( double
zInitValue ), addZValues( double zInitValue ), dropZValues(),
dropMValues() could be a good inspiration.
I'll go through the API and prepare and post a proposal to discuss more.
Ari
Ari
Anyway, I'll look into the geometry API first.
Ari
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
