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

[Frank Warmerdam]

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.

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.

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
>



-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130724/df9afc44/attachment-0001.html>