Am 12.08.2013, 21:55 Uhr, schrieb Yuri D'Elia
<[email protected]>:
On 08/08/2013 11:54 PM, Martin Koppenhoefer wrote:
I guess in this case I can simply re-use the geometry in a new relation
with the proper valley name with type=multipolygon, place=region,
region:type=valley?
I'd use type=multipolygon natural=valley
I'm still not satisfied with type=multipolygon:
http://wiki.openstreetmap.org/wiki/Multipolygon#Detailed_tagging
specifically:
* The relation has tags:
Use the relation tagging. Ignore anything on the ways.
However, this is not what should happen for a lake group where each lake
name is independent (ie, the group is just a topological feature). And,
as I said before, unnamed lakes should not inherit the name of the group.
After re-reading the whole thread, I tend to agree with fly more, as a
boundary type seem to be much more appropriate:
type=boundary
boundary=topologic
natural=water
name=lake group name
the boundary relation has the advantage of not requiring a fake polygon
(as opposed to place=locality).
I have two examples of type=multipolygon which I introduced:
http://www.openstreetmap.org/browse/relation/3126464
http://www.openstreetmap.org/browse/relation/3126459
whole type=multipolygon relation simply broke the rendering (but
renderers here seem to be compliant).
Hmm, I'm not sure that boundary is the right tag. Isn't it a border, and
not an area?
The problem is, that multipolygon don't work in 2 cases:
- The areas touch each other.
- The "areas" are multipolygons. A multipolygon as a member in a other
multipolygon is not allowed.
Either we allowed this, or we need any relation which collect these
things...
(What the renderer do, is not primary. If we find a good tagging, the
renderer should follow the tagging, not backwards.)
_______________________________________________
Tagging mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/tagging
