Changes between Version 36 and Version 37 of rfc61_support_for_measured_geometries


Ignore:
Timestamp:
Feb 3, 2016, 6:31:37 AM (8 years ago)
Author:
Ari Jolma
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • rfc61_support_for_measured_geometries

    v36 v37  
    9090The property int nCoordinateDimension in class OGRGeometry will be replaced by int flags. It may have the following flags:
    9191{{{
    92 #define OGR_G_NOT_EMPTY 0x1
     92#define OGR_G_NOT_EMPTY_POINT 0x1
    9393#define OGR_G_3D 0x2
    9494#define OGR_G_MEASURED 0x4
    9595#define OGR_G_IGNORE_MEASURED 0x8
    9696}}}
    97 The "ignore" flag is needed internally for backwards compatibility.
     97The "ignore" flag is needed internally for backwards compatibility. The flag OGR_G_NOT_EMPTY_POINT is used only to denote the emptiness of an OGRPoint object.
    9898
    9999Currently a hack to set nCoordDimension negative is used to denote an empty point.
    … …  
    104104
    105105{{{
    106 IsEmpty = !(flags & OGR_G_NOT_EMPTY)
    107106Is3D = flags & OGR_G_3D
    108107IsMeasured = flags & OGR_G_MEASURED
    … …  
    111110The setters and getters are implemented with |= and &=.
    112111
    113 The !IsEmpty method is needed only in the base class but the emptiness needs to be managed in all classes. It needs to be decided but when any of these flags is set, the corresponding data becomes invalid and may be discarded.
    114 
    115 Keep the following methods with original semantics, i.e., coordinate dimension is 2 or 3, but deprecate. There is some discrepancy in documentation. Their documentation says that they may return zero for empty points while in ogrpoint.cpp it says that negative nCoordDimension values are used for empty points and the getCoordinateDimension method of point returns absolute value of nCoordDimension - thus not zero.
     112When any of these flags is set or unset, the corresponding data becomes invalid and may be discarded.
     113
     114Keep the following methods with original semantics, i.e., coordinate dimension is 2 or 3, but deprecate. There is some discrepancy in documentation. Their documentation says that they may return zero for empty points while in ogrpoint.cpp it says that negative nCoordDimension values are used for empty points and the getCoordinateDimension method of point returns absolute value of nCoordDimension - thus not zero. A fix to the doc is probably enough.
     115
    116116{{{
    117117int getCoordinateDimension();
    … …  
    136136virtual void set3D(OGRBoolean bIs3D);
    137137virtual void setMeasured(OGRBoolean bIsMeasured);
    138 int getFlags() const;
    139 int setFlags( int newFlags ) const;
     138virtual int getFlags() const;
     139virtual int setFlags( int newFlags );
    140140
    141141//Add now or later methods:
    … …  
    143143virtual OGRGeometry *LocateBetween(double mStart, double mEnd);
    144144
    145 //Change the semantics of importPreambuleFromWkb: b3D is not used, the flags are managed within the method
     145//Remove b3D from importPreambuleFromWkb: it is not used, the flags are managed within the method.
    146146}}}
    147147
    … …  
    236236Once the support for M coordinates is in place the driver will advertise the support.
    237237
    238 Within the work of this RFC the support is built into shape and pg. Support for other drivers are left for further work.
     238Within the work of this RFC the support is built into memory, shape and pg drivers. Support for other drivers are left for further work.
    239239
    240240== Utilities ==
    … …  
    273273ICreateLayer, which all drivers that have create layer capability implement, have geometry type as an argument. The method should call CPLError() with CPLE_NotSupported and return NULL if the driver does not support measures. Similarly for ICreateFeature and ISetFeature.
    274274
    275 There is a question whether the user-oriented API functions (!CreateLayer, !CreateFeature, and !SetFeature) should (silently) strip out the measures before continuing to the I* methods. This (side effect) may not be what is wanted in some usage scenarios but it would follow the pattern of what is already done with non linear geometries.
     275The user-oriented API functions (!CreateLayer, !CreateFeature, and !SetFeature) should (silently) strip out the measures before continuing to the I* methods in drivers that do not support measures. This (side effect) may not be what is wanted in some usage scenarios but it would follow the pattern of what is already done with nonlinear geometries. This should be documented.
    276276
    277277An alternative would be to store M value(s) (or WKT or WKB) as attribute (scalar or vector, depending on the geometry type).
    278278
    279279Needs a decision.
     280
     281Some incompatibilities will necessarily be introduced. For example when the current XYM-as-XYZ hack in shape will be replaced by proper XYM.
    280282
    281283== Related tickets ==