27.01.2016, 18:26, Even Rouault kirjoitti:
Le mercredi 27 janvier 2016 16:48:45, Ari Jolma a écrit :
The draft RFC is here
https://trac.osgeo.org/gdal/wiki/rfc61
Changed to
https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries
My remarks:
1) #define OGR_G_xxxx
--> should that be rather (since the intent seems to be bitwise combination):
#define OGR_G_NOT_EMPTY 0x1
#define OGR_G_3D 0x2
#define OGR_G_MEASURED 0x4
and I'd say put it ogr_geometry.h only as it is an internal implementation
detail.
2) new OGRGeometry methods. I think Kurt would prefer using straight C++ bool
type, but it is true we have used OGRBoolean for all other methods. So no
strong opinion on this.
3) "New OGRwkbGeometryType values are needed". I assume you will use the SFSQL
1.2 and ISO SQL/MM Part 3 way, ie. 2D type + 2000 for M and 2D type + 3000
for ZM ? I'm also wondering if, as a provision, we shouldn't also add the Tin
and PolyhedralSurface types for completness, even if unimplemented at that
point. At least people would be warned that such beasts may appear at some
point.
4) In the compatibility issues, we'd have to wonder if we need to make
something special when a driver ICreateLayer() is called with a XYM/XYZM type
and it is not ready for it. And same for ICreateFeature()/ISetFeature(). For
curve geometries, I decided that curve aware drivers would expose a
OLCCurveGeometries / ODsCCurveGeometries capability and that
CreateLayer()/CreateFeature()/SetFeature() generic methods would convert types
if needed before passing to the Ixxxx implementation method. Such technique
could be reused here potentially.
These are now taken into account in the draft.
BTW, where can I find a comprehensive list of the wkb types? There is an
old ISO SQL/MM Part 3 pdf in the web but it is old and seems to be
incorrect too. libspatialite has a header file that has many but not all
that ogr_core.h has.
Ari
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
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
