[fdo-internals] Multiple geometries per table
brent.robinson at autodesk.com
Tue May 11 08:48:55 EDT 2010
The PostgreSQL provider and FDO API can expose multiple geometric properties per class but AutoCAD Map will only pick one of them for display purposes. The provider will try to set a "main" geometry based on the presence of spatial indexes but if all of them are either indexed or not then it leaves the feature class main geometry as null and Map defaults to picking the first geometry.
One workaround would be to create a view for each geometry column where each view has all of the table columns but only one of the geometry columns. I believe you also have to add a row to geometry_columns table for each view geometry column. This step will become unnecessary in the next (probably 3.6) version of the PostgreSQL provider; it will look at the geometry_columns row for the view column's underlying column in the table.
The above is the only way I can think of to give a choice of which geometry column to use when running Map. If there is a particular column that you always want to use, but it's not the first, then a spatial index naming trick can be used. If one of the spatial index names contains '_gsi' but none of the other spatial indexes in the table do, then the provider will set that geometry as the main geometry and Map will use it.
For the "feature and manual label placement geometries" example, I'm not familiar enough with stylization to know if it can be done. Choosing the feature geometry can be done by one of the above solutions but I don't know if labels can be placed based on the other geometries. Does anyone else on the list know?
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Mike Toews
Sent: Tuesday, May 11, 2010 3:22 AM
To: FDO Internals Mail List
Subject: [fdo-internals] Multiple geometries per table
I'd like to clarify the scope of FDO capabilities (if any) for tables
with more than 1 geometry. (http://trac.osgeo.org/fdo/ticket/648)
I've defined several tables with more than 1 geometry, as this best
suits the needs of storing certain kinds of data. For PostGIS and
Quantum GIS, this type of geodatabase schema works quite effectively,
and there have been no complications implementing it. However, I have
not had any success with either the FDO providers for PostGIS
(http://trac.osgeo.org/fdo/ticket/443) or the newer (and mostly
impressive) Generic RDBMS-derived PostgreSQL Provider. Only the first
geometry column is recognized, and any other column is ignored
(despite the appropriate metadata in geometry_columns). I wonder if
this is a limitation of these providers, the base Generic RDBMS
Provider, or is it a limitation of the FDO Core API? If it is a
limitation in the API, are there any plans to extend it?
 examples: excavation top-of-bank and bottom-of-bank polygons;
features with either geographic or unreferenced/relative coordinates;
feature and manual label placement geometries
fdo-internals mailing list
fdo-internals at lists.osgeo.org
More information about the fdo-internals