[OSM-dev] libosmium and missing multipolygons

Sylvain Melin s.melin at alsim.com
Thu Apr 21 15:10:43 UTC 2016

On 21/04/2016 16:48, Jochen Topf wrote:
> On Do, Apr 21, 2016 at 04:03:31 +0200, Sylvain Melin wrote:
>> I wrote a C++ program using libosmium to read an osm file, filter the data
>> and extract the result to different target shapefiles.
>> I have a problem with some features not being written in shapefiles.
>> For example, I want to extract all water bodies in the bounding box
>> latmin=44 latmax=45 lonmin=-1 lonmax=0.
>> In the resulting shapefile, the relation 2988 "Lit de la Dordogne" is
>> missing : https://www.openstreetmap.org/relation/2988
>> The osmium::Area built from this relation seems to be empty.
>> area.num_rings() gives 0
> If there are no rings, this means the multipolygon relation is broken in some
> way. There can be many different reasons why this is the case, usually
> self-intersections or gaps in the rings. Or it can be a bug in the multipolygon
> assembly code. You can use "problem reporters" to give you more insight into
> what libosmium thinks is wrong with the area. (Sorry, currently no sample code.
> If you want to know how they work, say so, and I'll whip up some examples.)
> There are a few known bugs in the libosmium MP code and I am working on an
> improved versions which will be ready soon. At the moment I would suggest, you
> wait a few days and then try the new code, before digging further into this.
> I don't want to debug the old code any more.
> Sometimes the OSM Inspector can show you where the problem is:
> http://tools.geofabrik.de/osmi/?view=multipolygon&lon=0.82538&lat=45.03236&zoom=9&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,ways,role_markers,way_end_nodes,way_nodes
> In this case it doesn't say anything.
>> Importing my osm file in QGis or converting it with ogr2ogr gives the
>> appropriate result and the relation 2988 is correctly exported into the
>> shapefile.
> Osmium will not export a geometry it thinks is invalid. Other programs are
> often more forgiving. The reason Osmium is picky there, is that invalid
> geometries can sometimes create problems when used later, creating rendering
> errors or otherwise invalid data. It is better to get them fixed in OSM.
> That being said, I have also though about an "just do it" mode that doesn't
> give you any guarantees.
> Jochen
Ok, I'll wait for the new version of libosmium.
In the meantime I can use ogr2ogr.

Having the possibility to force export of invalid geometry would be a 
useful option, as long as the log tells you there's something wrong.
In my case, since I was filtering the data to export using the tags, and 
this particular area had no tags, it wasn't processed and I had no error 
messages or exception.
I realized it was missing only because it is a big river.

Thank you once again for your help Jochen.

More information about the dev mailing list