Improper handling of Postgis tables with multiple geometry columns

Assigning to Mateusz.

Please discuss any planned solution with me.  If it is not very disruptive 
if would be nice to fix things in 1.4 branch, but not if the changes are
very substantial.

Frank,

Current data model used by OGR is based on assumption that cardinality of the 
relation between a feature and associated geometry is 1:1.

feature -|----------|- geometry

If we want, in OGR, to support PostGIS ability to handle multiple geometry
columns will likely change the cardinality to 1:N

feature -|----------|< geometry

This change of relation cardinality will require substantial changes to
interface of some of OGR classes (as well as corresponding OGR C API).

Currently, OGRFeature provides access to single instance of associated geometry.
This will need to be changed to provide access to collection of geometries.

Here is list of public interfaces that will require changes to support
multiple geometries per feature:

1.
OGRFeature::GetGeometryRef
OGRFeature::StealGeometry
OGRFeature::SetGeometryDirectly
OGRFeature::SetGeometry

- access to geometries by index
- access default geometry (ie. with index 0, first column)

2. 
OGRFeatureDefn::GetGeomType
OGRFeatureDefn::SetGeomType

- specify type of which geometry is requested/set

3. 
OGRLayer::GetGeometryColumn

- return geometry by index, with default index = 0

4.
OGRLayer::GetSpatialRef

- specify SRS of which geometry is requested


Here are operations of OGRLayer that might require some changes:

OGRLayer::GetSpatialFilter
OGRLayer::SetSpatialFilter
OGRLayer::SetSpatialFilterRect

- these 3 operations listed above might require changes of their semantic:
-- how to specify to which geometry a filter should be applied?
-- do we want to provide all-by-one filtering where a common filter is
   applied to all geometries?


Certainly, this is a very first analysis and it is only supposed to help
us to decide if we want to support multiple geometries sooner or later
(I assume we need to support it at some time).

Mateusz, 

In the short to medium term we can't practically reengineer OGR to support
multiple geometry columns properly.  What we might consider are special ways 
of selecting the geometry column to use.

I can quickly imagine 3 scenarios that might apply. 

1) We actually offer distinct appearing layers for each geometry column.  So 
if the table roads has two geometry columns, one called centerline, and one
called boundaries we might show the application a layer called
roads_centerline, and roads_boundaries.  

2) We could provide a mechanism in the datasource connection string where
a particular geometry column could be selected for a given table.  For
instance I think we already support listing the tables to be represented
as layers in the PG driver connection string.  We could allow adding a
geometry column in brackets after the table name as a way of selecting the
geometry column to use.  If unspecified, the first geometry column would
be used. 

3) We could extend the OGR API with a way of listing the geometry columns
available for a layer, and a method for selecting a particular one.  Note,
we already have the informative GetGeometryColumn() method which for some
RDBMS providers returns the name of the currently used geometry column. 

I'm inclined to pursue option (1) in the postgis driver for the time being
as it requires no changes to public apis and applications.  I think option 
(3) should be a longer term goal. 

Re-prioritizing. Target 1.5.0.