Support for specific geometry type in OGR for data with mixed geomeatry types

[tbonfort]

Reporter: taatuut@planet.nl Date: 2004/12/14 - 15:27

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.

[tbonfort]

Author: dmorissette Date: 2004/12/14 - 18:35

Frank, could this be supported directly at the OGR level by adding a way to
filter by geometry types in OGR's SQL? This might be useful outside of MapServer
as well. By using this with the "WHERE ..." passthru that's being added in bug
1126 we could achieve what Emil needs without any custom change to MapServer.

[tbonfort]

Author: taatuut@planet.nl Date: 2004/12/20 - 18:59

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.

[tbonfort]

Author: bartvde@osgis.nl Date: 2005/05/09 - 16:11

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. 

[tbonfort]

Author: bartvde@osgis.nl Date: 2005/05/09 - 17:07

Frank,

how much effort approximately would be involved in realizing this?

Bart

[tbonfort]

Author: fwarmerdam Date: 2005/05/09 - 17:27

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.  

[tbonfort]

Author: bartvde@osgis.nl Date: 2005/05/09 - 19:35

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

[tbonfort]

Author: fwarmerdam Date: 2005/05/09 - 19:54

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. 

[tbonfort]

Author: bartvde@osgis.nl Date: 2005/05/09 - 20:13

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

[tbonfort]

Author: fwarmerdam Date: 2005/09/28 - 15:58

This issue is also addressed in bug 1438

[tbonfort]

Author: bartvde@osgis.nl Date: 2005/10/24 - 09:41

Frank, any chance of getting this one into the 4.8 release?

[tbonfort]

Author: fwarmerdam Date: 2005/10/24 - 20:09

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,

[tbonfort]

Author: szekerest Date: 2006/02/01 - 23:30

Frank,

Have you managed to step forward with this issue?

Tamas

[tbonfort]

Author: fwarmerdam Date: 2006/02/02 - 20:28

No, I have not made any progress on this issue. 

[tbonfort]

Author: szekerest Date: 2007/03/16 - 22:31

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