[gdal-dev] Support for measures

[Even Rouault]

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