On 03/22/2012 07:05 AM, Tim Alder wrote:
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:
Osm2pgsql currently only supports the relations of type multipolygon,
route and boundary. So it won't build a geometry for the relation type
We have also a lot of articles like:
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 (
) is in the database.
But it currently doesn't have a wikipedia tag on it, so it won't show up
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
I would also like to know why Austria is working in WIWOSM but not for
Two reasons I can think of:
For one the Germany relation ( think it is
), 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 (
). 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.
Maps-l mailing list