Question about MapServer/OGR and MapInfo tab with multiple geometry types

[taatuut@…]

Added file mi_tab.rar with two MapInfo tab files:

TAB file bis_rap containing POINT, POLYGON and MULTIPOLYGON objects. Here the 
MULTIPOLYGON error occurs when using the data as POINT layer.

As Frank already pointed out in his response the MULTIPOLYGON data should be 
ignored just like the POLYGON data.


TAB file bis_his containing POINT and LINESTRING objects. Here the points from 
the LINESTRING get displayed when using the data as a POINT layer.

I'd prefer the LINESTRING points not to be displayed at all when defining a 
POINT layer.

[taatuut@…]

Two MapInfo TAB files

[fwarmerdam]

Emil, 

Please provide a map file that demonstrates the problem when used with 
shp2img. 

[taatuut@…]

MapServer MAP file

[fwarmerdam]

Accepting this bug myself. 

[taatuut@…]

MapServer MAP file

[fwarmerdam]

On reviewing the code, a MapServer layer of TYPE POINT will actually render
each vertex in a linestring, or polygon boundary using the point feature 
information.  So, apparently the correct operation would be for a multipolygon
to have the symbol rendered at each border vertex. 

I am not aware, off hand, of a way to tell MapServer to filter on geometry
type, so in a mixed layer situation such as this it could be very hard to 
render only point geometries in a selected way. 

I'm going to ask Daniel to comment on whether there is a way to accomplish this.

In the meantime, I will change MapServer to handle all the geometry collection
types in the ogrGeomPonits() function in mapogr.cpp. 

[fwarmerdam]

OK, I have committed changes so that TYPE POINT layers will work for all
geometry types, even multipolygon, geometrycollection and multilinestring.

These changes are only in 4.5.  They required substantial restructuring of
the ogrGeomPoints() function which I haven't really tested very extensively
so I am nervous to move it into 4.4.1 unless someone is in a good position
to do more extensive testing.

Emil, as your mapfile is configured you likely do *not* want the multpolygons
treated as points (a point for every vertex!) as the label collision detections
ends up taking a *long* time (minutes).  Could you confirm that you need
a way of filtering so that you only get points?   I suspect within the 
context of MapServer 4.4 you are basically faced with pre-processing your
data to extract only point features for use in your labelling layer. 

Daniel - hopefully you can comment on appropriateness of moving the geometry
handling changes back into 4.4 and whether there is a test stream that does
a decent job at various geometry types from OGR. 

For now leaving this bug report open pending a decision on backporting the
change. 

[taatuut@…]

Frank,

You're right, I need a way of spatial filtering so that I only get the 'real'
points in a TYPE POINT layer, not the points from other geometry types like
(multi)linestrings, (multi)polygons etc.

This way it should be possible in MapServer to use a TAB file with mixed
geometry types as source for multiple layers with different geometry types
without 'wrong' data like points from linestrings or polygons showing up in a
TYPE POINT layer or data like linestrings from polygons showing up in a TYPE
LINE layer.

[dmorissette]

Frank, I don't think we should backport this to 4.4.1 if there is a risk of
breaking anything. What you've done actually fixes old bug 478 (thanks!), but
that apparently doesn't address Emil's real problem so there would be little
benefit to backporting the fix compared to the risk.

Emil: MapServer's current behavior of turning linestrings into multiple points
in POINT layers is a "feature" that was there for shapefiles even before we
added OGR connections to MapServer. I don't find that this feature is
necessarily useful, and it's actually turning into a pain in the context of TAB
files like yours, but we can't get rid of it easily. For the time being you will
have to filter your data by geometry types as Frank suggested. However I do like
this idea, so you could also file another enhancement bug about this and this
may make it in a future release if someone has time/funding to do it.

[dmorissette]

*** Bug 478 has been marked as a duplicate of this bug. ***

[dmorissette]

My previous comment to Emil wasn't very clear. I meant that I like the idea of
having a mechanism to filter OGR connections by geometry type and that a new
enhancement bug could be filed about that.

[fwarmerdam]

This bug is resolved, and we are clearly not backporting, so I am closing it. 

I don't think an enhancement request was filed on the geometry based filtering.

[taatuut@…]

Hello Frank,

I did file an enhancement request on geometry based filtering under number 1129

[bartvde@…]

I just tested this and it works perfectly now!