[gdal-dev] Support for measures

[Even Rouault]

Le mercredi 27 janvier 2016 16:48:45, Ari Jolma a écrit :
> The draft RFC is here
> 
> https://trac.osgeo.org/gdal/wiki/rfc61

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.

> 
> 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

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com