Opened 19 years ago
Closed 17 years ago
#1129 closed defect (fixed)
Support for specific geometry type in OGR for data with mixed geomeatry types
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | OGR Support | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: | bartvde@… |
Description
When using data like MapInfo TAB files MapServer's current behavior is turning (multi)polygons and (multi)linestrings into multiple points in POINT layers and turning (multi)polygons into multiple linestrings in LINE layers. This is a "feature" that was there for shapefiles even before OGR connections were added to MapServer. But when using data with mixed geometry types like TAB or DGN this is no desired behaviour. Current workarounds are: - Editing the data outside MapServer and splitting up data by geometry type before using it in MapServer. This means editing the source data which is not desired and/or always possible. - Using query statements through the DATA key. Only possible when you have an attribute which discriminates the different geomtery types. So it would be a nice enhancement to have a mechanism to filter OGR connections by geometry type, maybe something like a GEOMETRYTYPE filter? In the present situation a TAB file with POLYGON, LINESTRING and POINT data displays the points from LINESTRINGS and POLYGONS too if using a TYPE POINT layer in MapServer (gives an error when MULTIPOLYGONS are present in the dataset. This will be solved in MapServer 4.5, see bug 1124): NAME bis_his TYPE POINT CONNECTIONTYPE OGR CONNECTION "bis_his.tab" Workaround with a query (bad workaround because it is not generic, not always possible when a discriminating attribute lacks and it uses an alphanumeric attribute instead of the real geometrytype) NAME bis_his TYPE POINT CONNECTIONTYPE OGR CONNECTION "bis_his.tab" DATA "SELECT * FROM bis_his WHERE Opmerking LIKE 'C%'" Possible future situation: NAME bis_his TYPE POINT CONNECTIONTYPE OGR CONNECTION "bis_his.tab" GEOMETRYTYPE POINT GEOMETRYTYPE should offer all possibilities available in OGR like MULTIPOLYGON, POLYGON, MULTILINESTRING, LINESTRING, POINT etc. and restrict the data shown to only that geometry type and not use lines from polygons in a TYPE LINE layer or points from polygons and linestrings in a TYPE POINT layer. I would like to know what efforts are needed to implement such a GEOMETRYTYPE feature for OGR data in MapServer.
Change History (15)
comment:2 by , 19 years ago
Would be nice if this can be implemented at OGR level and used in MapServer. The possibility to query the geometry type in OGR looks like a valuable enhancement to me.
comment:3 by , 19 years ago
Cc: | added |
---|
There is no mechanism currently for querying based on geometry type in MapServer or OGR. I briefly looked into adding some sort of capability to do this in OGR but it seems pretty involved. It could be hacked into the OGR connector for MapServer pretty easiliy though. Something along the lines of a PROCESSING directive that only works for connection type OGR. You might want to file an enhancement request to this effect. Keep in mind that it wouldn't be terrible efficient since it would need to scan the source layer once for each map layer, just discarding features with the wrong geometry type once they have been read.
comment:4 by , 19 years ago
Frank, how much effort approximately would be involved in realizing this? Bart
comment:5 by , 19 years ago
Status: | new → assigned |
---|
Bart, A PROCESSING directive based approach in MapServer would likely only be one hour of work, perhaps two with a test case and documentation. An OGR SQL based solution would be more like a day or two of work. I would be happy to go ahead and do the processing directive for free, but I am a bit worried that it is a hack solution.
comment:6 by , 19 years ago
Hi Frank, the processing directive would do the trick for us. I would be happy to test. I do agree with you that an OGR SQL option would be the nicest, but I don't consider the PROCESSING OPTION a hack. Since this could even apply to Oracle Spatial or PostGIS layers theoretically, which would make a PROCESSING directive more logical. Would this require changes to both Mapserver and OGR? Bart
comment:7 by , 19 years ago
Bart, The processing directive would only require changes in the mapogr.cpp portion of MapServer. If it were to be applied to other datasources, the appropriate other modules would also need similar changes.
comment:8 by , 19 years ago
Hi Frank, if you could make those changes to mapogr.cpp I would be so thankful. I just realized that with spatial databases one would probably create a view for the specific geometry type, but anyway, I am okay with the PROCESSING option and don't consider it a hack. Best regards, Bart
comment:11 by , 19 years ago
Bart, I think I would use the approach proposed in bug 1438 which is actually in OGR instead of MapServer. However, there were several things I wanted to generalize from the proposed patch and it has fallen to a back-burner. I have no planned time table for addressing it. Best regards,
comment:12 by , 19 years ago
Cc: | added |
---|
comment:15 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
This feature has been implemented in gdal 1.4.0 as described at http://www.gdal.org/ogr/ogr_sql.html#ogr_sql_special_fields Closing this bug
Note:
See TracTickets
for help on using tickets.