[gdal-dev] Call for discussion for "RFC 41 : Support for multiple geometry fields in OGR"

[Even Rouault]

Le mercredi 24 juillet 2013 18:42:59, Frank Warmerdam a écrit :
> Even,
> 
> An excellent proposal!
> 
> I'm a bit sad about GetSpatialRef() on the first geometry field not
> necessarily returning the right value for old drivers.  I'd suggest we make
> a quick pass through the checked in drivers once your core work is done to
> update them.

This would require inspecting all driver code and make sure that at each place 
where they affect their poSRS member variable, they also call GetLayerDefn()-
>GetGeometryFieldDefn(0)->SetSpatialRef(poSRS) (caution: we must check that 
GetGeometryFieldCount() != 0 ! it can be 0 if SetGeomType(wkbNone) is called 
). A more reliable way of catching all the affected places reliably would be to 
remove the poSRS member from the drivers' layer classes and call 
SetSpatialRef() at geometry field defn.

I was also thinking to another way of doing that. It would have consisted in 
blindly replacing all occurences of new OGRFeatureDefn(name) in OGR drivers by 
new OGRClassFeatureDefn(this, name) (or a better name for this class !).

And have :

class OGRClassFeatureDefn : public OGRFeatureDefn
{
    private:
        bool bHackDone;
        OGRLayer* poLayer;

    public:
        OGRClassFeatureDefn(OGRLayer* poLayer, const char* pszName) :
            OGRFeatureDefn(pszName), bHackDone(false), poLayer(poLayer)
        {
        }

        virtual OGRGeomFieldDefn *GetGeomFieldDefn( int i )
        {
            OGRGeomFielDefn* poGeomFieldDefn =
                  OGRFeatureDefn::GetGeomFieldDefn(i);
            if( !bHackDone && i == 0 && poGeomFieldDefn != NULL &&
                poGeomFieldDefn->GetSpatialRef() == NULL )
            {
                bHackDone = true; /* prevent recursion if GetSpatialRef() 
calls GetGeomFieldDefn() */
                OGRSpatialRef* poSRS = poLayer->GetSpatialRef();
                if( poSRS != NULL )
                    poGeomFieldDefn->SetSpatialRef(poSRS);
            }
            return poGeomFieldDefn;
        }
};

... but there's a small problem. It is currently valid to access to the 
feature definition (and thus to a field definition) after the OGRLayer has been 
destroyed since feature/feature definitions are not strongly tied to their 
layer container.

OGRFeature* poFeat = poLayer->GetNextFeature();
delete poDS;
poFeat->GetGeomFieldDefnRef(0)->GetSpatialRef() --> bang !
delete poFeat;


> 
> I'd be interested in implementing multiple geometry column for the fusion
> tables driver to get my feet wet with this new capability once the core
> work is done.
> 
> I'd also love to see it added for GML but that could be an involved
> process, so I'm not going to commit to taking it on.

Yes, there are changes at .gfs level that should be done, and the GML code 
itself is now "a bit" cluttered (my fault...) with various hacks related to 
SRS handling, mainly to deal with specific GML profiles (WFS, etc...)

> 
> It is also timely in that the question of multi-geometry support came up
> recently in reference to Google Maps Engine.
> 
> Best regards,
> Frank
> 
> 
> 
> On Wed, Jul 24, 2013 at 5:49 AM, Even Rouault
> 
> <even.rouault at mines-paris.org>wrote:
> > Hi,
> > 
> > This is a call for discussion for "RFC 41 : Support for multiple geometry
> > fields in OGR" :
> > 
> > http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields
> > 
> > As an introduction, you'll find below the first paragraphs of the RFC.
> > Much more
> > to read at the above link !
> > 
> > == Summary ==
> > 
> > Add read/write support in the OGR data model for features with multiple
> > geometry fields.
> > 
> > == Motivation ==
> > 
> > The OGR data model is currently tied to a single geometry field per
> > feature,
> > feature definition and layer. But a number of data formats support
> > multiple geometry fields. The OGC Simple Feature Specifications also do
> > not limit to one geometry field per layer (e.g. §7.1.4 of
> > [http://portal.opengeospatial.org/files/?artifact_id=25354 OGC 06-104r4
> > "OpenGIS® Implementation Standard for Geographic information - Simple
> > feature
> > access -Part 2: SQL option]).
> > 
> > There are workarounds : using geometries of type GEOMETRYCOLLECTION, or
> > advertizing as many layers as there are geometry columns in the layer
> > (like currently done in the PostGIS or SQLite drivers). All those
> > approach are at
> > 
> > best workarounds that suffer from limitations :
> >   * GEOMETRYCOLLECTION approach : no way to know the name/semantics of
> >   each
> >   
> >     sub-geometry. All sub-geometries must be expressed in the same SRS.
> >     No
> > 
> > way
> > 
> >     of guaranteeing that the GEOMETRYCOLLECTION has always the same
> >     number
> > 
> > of
> > 
> >     sub-geometries or that there are of a consistent geometry type.
> >   
> >   * one layer per geometry column approach : only appropriate for
> >   read-only
> >   
> >     scenarios. Cannot work in write scenarios.
> > 
> > The purpose of this RFC is to make support for multiple geometry fields
> > per feature to be properly taken into account in the OGR data model.
> > 
> > [...]
> > 
> > Best regards,
> > 
> > Even
> > 
> > --
> > Geospatial professional services
> > http://even.rouault.free.fr/services.html
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html