Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

Rendering Issues with type=multipolygon and boundary=administrative #1550

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 4 comments
Closed

Comments

@openstreetmap-trac
Copy link

Reporter: malte.roedl[at]gmx.de
[Submitted to the original trac issue database at 10.42am, Sunday, 1st February 2009]

Look at this part of the map:[[BR]]
http://www.openstreetmap.org/?lat=51.198765&lon=6.861448&zoom=18&layers=B000FTF [[BR]]
In the middle, where the bridge crosses the railyway, there are the boundaries of 3 different relations.

On the top: http://www.openstreetmap.org/browse/relation/58407 (district Vennhausen)[[BR]]
On the right: http://www.openstreetmap.org/browse/relation/58436 (district Unterbach)[[BR]]
On the left/bottom: http://www.openstreetmap.org/browse/relation/58416 (district Eller)[[BR]]

All are tagged identically instead of the name.

But in district Eller and Unterbach there are rendering issues:[[BR]]
Eller:[[BR]]
In zoom 14 and higher there ist a white area over all the streets, but not over the streetnames and footways.[[BR]]
Unterbach:[[BR]]
The boundary has a black background and the label "Kikweg" everywhere although just the way which is the border to Vennhausen has got this name.[[BR]]

Any ideas?

@openstreetmap-trac
Copy link
Author

Author: grand.edgemaster[at]gmail.com
[Added to the original trac issue at 8.40pm, Sunday, 1st February 2009]

This is not the common tagging method, type=boundary is advised until use of type=multipolygon for boundaries is supported.

@openstreetmap-trac
Copy link
Author

Author: jburgess777[at]googlemail.com
[Added to the original trac issue at 9.00pm, Sunday, 1st February 2009]

I think I can see what is happening here. One of the behaviours of osm2pgsql is for a multipolygon to inherit the tags from the ways it is constructed from. This is to cope with multipolygons where only the ways and not the relation are tagged. In this case, some of the roads have bridge=yes set and so this is being applied to the relation as well, causing the black casing. This is also overriding the name and admin_level fields of the relation:

gis=> select osm_id,name,bridge,boundary,admin_level,ref,foot,highway from planet_osm_roads where osm_id=-58436;
 osm_id |  name  | bridge |    boundary    | admin_level |  ref  | foot | highway
--------+--------+--------+----------------+-------------+-------+------+---------
 -58436 | Kikweg | yes    | administrative | 6           | L 404 | yes  | track

I should probably adjust osm2pgsql to avoid the inheritance of tags from the ways if the relation has its own set of tags.

@openstreetmap-trac
Copy link
Author

Author: malte.roedl[at]gmx.de
[Added to the original trac issue at 10.22pm, Sunday, 1st February 2009]

Replying to [comment:1 grand.edgemaster[at]gmail.com]:[[BR]]
I just followed this: [[BR]]
http://wiki.openstreetmap.org/wiki/Import/Catalogue/Kreisgrenzen_Deutschland_2005#Format_in_der_OSM-Datenbank [[BR]]
http://wiki.openstreetmap.org/wiki/Talk:Relation:boundary#Use_type.3Dmultipolygon_instead [[BR]]
And with every other boundary i tagged this way it was working fine.

@openstreetmap-trac
Copy link
Author

Author: jonb
[Added to the original trac issue at 10.22pm, Monday, 2nd February 2009]

(In [13511]) osm2pgsql: fixes #1550. Don't inherit tags from ways if the multipolygon has its own tags. Don't match inner way tags if there are no poly_tags to match against

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant