[Gdal-dev] RDBMSes with multiple geometry columns

[Mateusz Loskot]

Frank Warmerdam wrote:
> Folks,
> 
> Mateusz has been looking into bug 1476 related to postgis tables with
>  multiple geometry columns:
> 
> http://bugzilla.remotesensing.org/show_bug.cgi?id=1476
> 
> Mateusz raised the question of whether we should refactor the OGR API
>  to support multiple geometry columns.  As usual, I am very leery of 
> API breakage, and responded as follows.

Frank,

Generally, I see two "directions" of possible solutions:
1) Refactor or extend current OGR interface

2) Handle it with current interface but introducing some new logic and
semantic of some PostGIS operations.

The latter is what you've included in reply on my analysis.

> """ 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.

Right, that's what I consider as direction 2).

> 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.

I like this option very much.
I think it's pretty logical and doesn't cause any
earthquake in OGR user's world.
Hopefully, existing client applications may handle this extension
transparently - just a few new layers will be added to a listing
or legend.

> 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.

This one is harder to handle by users, I suppose.

> 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. """

I agree with your opinion.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net