Xastir improperly renders multi-part shapefile polylines as a single polyline

[tvrusso]

During investigation of some interesting shapefiles for bug #152, we discovered that Xastir is rendering certain shapes in a shapefile improperly.

These shapes are of polyline (SHPT_ARC or SHPT_ARCZ) with more than one "part". According to the shapelib API at http://shapelib.maptools.org/shp_api.html, a shape of ARC, POLYGON, or MULTIPOINT type may have parts. Xastir does not support MULTIPOINT, but we do support the other two. Multiple parts in a shape is indicated by a non-zero value of nParts in the SHPObject data structure returned by SHPReadObject function.

The code in map_shp.c for rendering SHPT_POLYGON polygons is in fact already careful to handle the case when nParts is nonzero, but the SHPT_ARC section of the code blindly constructs a single polyline out of the nVertices points it has in the shape, with no regard to the parts.

This code should be restructured so it looks at nParts, and properly loops over the parts constructing separate, unconnected polylines from them rather than treating the entire list of vertices as a single part.

Work on this would be much easier if issue #128 were closed first, because that would greatly simplify the map_shp.c file, making it much easier to read and modify.

[halmueller]

As a workaround, in case you have multipart Shapefiles that you need to use now:
ogr2ogr -f "ESRI Shapefile" -nlt LINESTRING -explodecollections -lco ENCODING=UTF-8 output.shp input.shp
(from https://gis.stackexchange.com/a/226616/16406)

[tvrusso]

I should point out that the workaround suggested by @halmueller is probably a desirable thing to do even after this issue is corrected, because Xastir's shapefile renderer also tries to build an rtree spatial index out of shapes, and it is doing so based on the bounding box returned in the min/max coordinates of the object returned by SHPReadObject --- which doesn't tell anything about the multiple parts. It then uses that rtree to determine which shapes to read from the shape file based on whether the bounding box of the shape intersects the screen.

this means a truly enormous shape (such as one that has one part in one continent, another part half-way across the world) will never really be pruned from consideration.

The breaking up of the multipart shapes using ogr2ogr will work around THAT problem, too.

[godfreja]

I think I will take a look at this one. Not an area of the code I am familiar with, but I believe I have an idea on what needs to be done.

[godfreja]

Not sure when I will get to this so un-assigning from myself for now.