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

Complex multipolygons should not inherit tags from members #2685

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

Complex multipolygons should not inherit tags from members #2685

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

Comments

@openstreetmap-trac
Copy link

Reporter: Vid the Kid
[Submitted to the original trac issue database at 9.04pm, Wednesday, 3rd February 2010]

In the simplest case of multipolygons, where one way represents the outside and one or more ways each represent a hole, it's not uncommon to put the feature tags on the outer way. In that case, it makes sense for the multipolygon to inherit all tags from the outer way, otherwise the holes don't work. However, this technique doesn't scale up well.

The preferred way to do it is to put all of the tags for the feature on the multipolygon relation. The outer way(s) don't get any tags unless they are themselves distinct features. Some examples of this are: a city boundary follows a river or roadway; or, a fence forms the boundary between two adjacent landuse areas. In these cases, the tags on the member ways and the tags on the multipolygon represent distinct features and should be kept distinct.

Unfortunately, Osmarender exhibits behavior where all multipolygons, not just the simple ones, take on the tags of their members.

Examples: [http://www.openstreetmap.org/browse/relation/182706 Columbus boundary relation] and its [http://www.openstreetmap.org/?lat=39.8228&lon=-82.9516&zoom=14&layers=0B00FTF crazy highway-area]; [http://www.openstreetmap.org/browse/relation/306645 The Oval] and [http://www.openstreetmap.org/browse/relation/306672 Mirror Lake Hollow], and [http://www.openstreetmap.org/?lat=39.99899&lon=-83.01196&zoom=17&layers=0B00FTF their incorrect labels].

It appears to me that a multipolygon will take on all of the tags of all of its members, and in the case of conflicts, the last member with any given key "wins" and contributes its tag to the multipolygon. (If the multipolygon has many members over a large area, apparently only the member ways loaded by the T@H client for that particular tileset are considered. That's why the Columbus rendering problem exhibits in only limited areas.)

In order to support the simple version of the multipolygon, this behavior should continue in extremely limited situations. Perhaps, when the relation has exactly one member way with role "outer" and that way is closed. Otherwise, the multipolygon relation represents a distinct feature from its member ways, and should be rendered from its own tags only. In any case, tags set on the relation should override tags inherited from members, if such inheritance takes place.

I skimmed through the source code, but I couldn't find the bit that causes the inheritance behavior, so I don't know what parts of what files need to be patched. I truly wish I could help beyond pointing out the problem.

@openstreetmap-trac
Copy link
Author

Author: Vid the Kid
[Added to the original trac issue at 3.02am, Thursday, 4th February 2010]

Regarding the Columbus highway-area symptom, I found the way which was contributing "area=yes" to the Columbus boundary relation and removed the tag. (In that case, the tag was redundant anyway...) Still, I wouldn't be surprised to see a false road drawn along the city border in that area next time the tileset is rendered. The inheritance behavior still needs to be fixed, regardless.

@openstreetmap-trac
Copy link
Author

Author: osm[at]petschge.de
[Added to the original trac issue at 10.44am, Thursday, 13th May 2010]

This should be fixed as of r21256. As the offending object has been removed from the database I can check though.

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