Hello,

On 03/22/2012 07:05 AM, Tim Alder wrote:

Hello, I got from WIWOSM a bug report, that the relation of river danube is missing. This relation has the type waterway. The reason is that we have the relation not in toolserver-db: http://www.openstreetmap.org/browse/relation/89652

Osm2pgsql currently only supports the relations of type multipolygon, route and boundary. So it won't build a geometry for the relation type waterway.

We have also a lot of articles like: http://en.wikipedia.org/wiki/U2_%28Berlin_U-Bahn%29 Would be nice to support also this.

This should work I think, as the the relations of type route do get included in the database.

For example the U1 line in Berlin ( http://www.openstreetmap.org/browse/relation/58767 ) is in the database. But it currently doesn't have a wikipedia tag on it, so it won't show up in WIWOSM.

My question is now if we can change the config of osm2pgsql for the next import (after license-change) to support this ? Will this effect the rendering? Do we need a second database?

I don't know how easy adding relation type=waterway would be to osm2pgsql. I think all of the relation types are hardcoded in osm2pgsql, as each relation type is basically a different class of objects. (e.g. type=route, type=multipolygon, type=turn_restriction, all behave completely different and have to be handled by separate code)

Furthermore, with things like type=waterway, I am not sure if it wouldn't effect rendering. As the features would then be in the database twice and get rendered twice.

This is already a problem with some of the boundaries that exist both as relations and as individual ways. The lines then partly appear thicker on the map, which looks a bit ugly.

On the other hand I just remembered, that although the river danube relation isn't in the planet_line or planet_polygone tables, it is in the planet_rels (planet_ways / planet_nodes) table, which has a complete list of all osm objects.

Those tables don't have geometry built for them yet, as they were originally only for the diff processing, but with some postgis magic and the preprocessing done for WIWOSM anyway, perhaps those can be used for that too?

I would also like to know why Austria is working in WIWOSM but not for Germany.

Two reasons I can think of:

For one the Germany relation ( think it is http://www.openstreetmap.org/browse/relation/51477 ), didn't have a wikipedia tag on it (which I have now added).

But more importantly, that relation doesn't seem to be in the osm2pgsql database, at least not in the planet_polygon table. Osm2pgsql only adds a relation to the planet_polygon table, if it can construct a valid polygon geometry. If someone now e.g. removes a way from the relation, the ways no longer form a closed loop and thus isn't a valid polygon. The polygon then gets dropped from the planet_polygon table. There are a number of other reasons for the geometry not to be valid. Unfortunately these large boundary relations are rather fragile and can often brake.

There is however, not much that can be done about this other than to put better quality assurance tools in place in osm, that spot this problems.

There is the "Broken Polygon Report" tool ( http://open.mapquestapi.com/brokenpoly/ ). It also runs off of a osm2pgsql database and flags all polygons it can't create valid geometries for. It also flags large polygons as problematic that suddenly change dramatically in size.

This tool should perhaps be enhanced a bit and then publicised more.

Kai

Greetings Tim

---

Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l