You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: