Opened 17 years ago
Last modified 15 years ago
#1476 closed defect
Improper handling of Postgis tables with multiple geometry columns — at Version 6
Reported by: | Owned by: | Mateusz Łoskot | |
---|---|---|---|
Priority: | normal | Milestone: | 1.6.0 |
Component: | OGR_SF | Version: | 1.4.0 |
Severity: | minor | Keywords: | PostgreSQL PostGIS |
Cc: | warmerdam, Ari Jolma |
Description (last modified by )
OGR is not able to handle properly feature types with multiple geometries. In the specific case of a Postgis table with 4 geometry columns we do have the following output: ogrinfo -so PG:"host=localhost port=5432 user=myuser password=mystery dbname=tiger2005fe" major_roads INFO: Open of `PG:host=localhost port=5432 user=myuser password=mystery dbname=tiger2005fe' using driver `PostgreSQL' successful. Layer name: major_roads Geometry: Unknown (any) Feature Count: 105628 Extent: (-170.837387, -14.377902) - (144.914001, 66.922287) Layer SRS WKT: (unknown) Geometry Column = gen_full fid: Integer (0.0) interstate: Integer (0.0) othername: String (0.0) state: String (0.0) statehighway: Integer (0.0) ushighway: Integer (0.0) Layer name: major_roads Geometry: Unknown (any) Feature Count: 105628 Extent: (-170.837387, -14.377902) - (144.914001, 66.922287) Layer SRS WKT: (unknown) Geometry Column = gen_full fid: Integer (0.0) interstate: Integer (0.0) othername: String (0.0) state: String (0.0) statehighway: Integer (0.0) ushighway: Integer (0.0) Layer name: major_roads Geometry: Unknown (any) Feature Count: 105628 Extent: (-170.837387, -14.377902) - (144.914001, 66.922287) Layer SRS WKT: (unknown) Geometry Column = gen_full fid: Integer (0.0) interstate: Integer (0.0) othername: String (0.0) state: String (0.0) statehighway: Integer (0.0) ushighway: Integer (0.0) Layer name: major_roads Geometry: Unknown (any) Feature Count: 105628 Extent: (-170.837387, -14.377902) - (144.914001, 66.922287) Layer SRS WKT: (unknown) Geometry Column = gen_full fid: Integer (0.0) interstate: Integer (0.0) othername: String (0.0) state: String (0.0) statehighway: Integer (0.0) ushighway: Integer (0.0) whilst the table definition is: tiger2005fe=# \d major_roads Table "public.major_roads" Column | Type | Modifiers --------------+----------+----------------------------------------------------------- state | text | gen_full | geometry | gen_1 | geometry | gen_2 | geometry | gen_3 | geometry | interstate | integer | ushighway | integer | statehighway | integer | othername | text | fid | integer | not null default nextval('major_roads_fid_seq'::regclass) Indexes: "fid_pkey" PRIMARY KEY, btree (fid) "major_roads_spatial_ind" gist (gen_full) "major_roads_spatial_ind1" gist (gen_1) "major_roads_spatial_ind2" gist (gen_2) "major_roads_spatial_ind3" gist (gen_3)
Change History (4)
comment:2 by , 17 years ago
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).
comment:3 by , 17 years ago
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.
comment:6 by , 17 years ago
Description: | modified (diff) |
---|---|
Milestone: | → 1.5.0 |
Priority: | highest → normal |
Severity: | blocker → minor |
Re-prioritizing. Target 1.5.0.
Note:
See TracTickets
for help on using tickets.