If you need an explicit written sentence on the wiki to tell you that OSM is a community project then you probably need to work on your understanding how OSM works. You aren't mapping alone in a green field and need to work in collaboration with the (local) community.

Your definition of what a 'tunnel' is and isn't has no bearing on what the `tunnel`=* tag means and is used for in OSM. You need to work with established OSM definitions and not try to single-handedly make OSM fit your world view.

In OSM, the `tunnel`=* tag is used for a wide variety of things that are 'artificial'/'man made' passages for vehicles, people, cables/infrastructure, water, etc... to pass through something else like a mountain, soil or even buildings.

Whether it is underground or not is independent of the fact that it is a 'tunnel'.
The `layer`=* tag also only specifies the relative height of overlapping features and similarly has no influence on whether something is a tunnel or not. It also does not specify that something is located underground.

Of course most tunnels (that aren't `tunnel=building_passage/avalanche_protector`) are indeed underground and that should probably be assumed as the default so that we don't need to add `location=underground` to all of them. For the exceptions that aren't, `location=overground` should be added instead.
From that perspective, adding a `tunnel`=* tag _does_ strongly imply that it is underground, even if it does not explicitly specify it. Tagging `location=underground` in addition would also be correct (even if possibly slightly redundant).

These changes been reverted in changeset/138008674 because they incorrectly removed information, disrupted road networks, and broke boundary relations and coastlines

These changes been reverted in changeset/138008674 because they incorrectly removed information, disrupted road networks, and broke boundary relations and coastlines

These changes been reverted in changeset/138008674 because they incorrectly removed information, disrupted road networks, and broke boundary relations and coastlines

These changes been reverted in changeset/138008674 because they incorrectly removed information, disrupted road networks, and broke boundary relations and coastlines

Hi,
removing the layer=-1 tag here is okay (even though it's not really necessary since it's not 'wrong' but just redundant).
The `covered=yes` tag was correct however and should not be removed.

The same applies e.g. here way/934071491/history

Die genaue Gemeindezugehörigkeit ist für den Ortsnamen doch irrelevant und nur weil da ein paar Meter drüberstehen bezweifle ich dass sich der Teil anders nennt. Wenn dann wäre das sowieso nur ein _Teil_ des Ortes und kein separater eigenständiger Ort.

Die `addr:*`=* Tags bestimmen nur die postalische Adresse die abweichend vom geläufigen Ortsnamen sein kann.

This changeset contained incorrect modifications and has been reverted in changeset/137579992

This changeset contained incorrect modifications and has been reverted in changeset/137580273

Ob das ein Bach, ein Kanal oder ein, zwei oder mehrere Eingänge hat ist völlig egal. Wenn es unterirdisch geführt wird ist ein `tunnel`=* Tag richtig und notwendig.

> It's certainly not how the overwhelming majority of editors do things.

By 'editors' I mean users/humans in this instance

> I always understood it to be best practice to use these boundary ways to form the areas.

It's certainly not how the overwhelming majority of editors do things. Simply because it doesn't really offer any benefits and only complicates things. Multipolygons should only really be used when they are necessary (e.g. when there's a hole in the area).

> For folks using iD and JOSM, having a bunch of relations in the editing area can make things quite frustrating to edit.

Normal editing operations such as changing tags or moving the outline around a bit work more or less fine and you won't even necessarily notice that you're editing a multipolygon. Even iD has that rudimentary level of support. Anything that involves creating new areas or deleting (parts) of areas is going to be more of a hassle than it needs to be though.
More problems start to pile up when you want to do things that are a bit more advanced, such as joining or splitting areas, etc... Editor support for operations on multipolygons simply is not as good as it is for simple closed ways. E.g. splitting multipolygon areas wasn't supported in josm and had to be done manually until I implemented it recently while it has been available for normal closed way areas for ages. These problems might not be as noticeable for users of editors that don't have these features in the first place and where doing things manually is the only way anyway, but it's a big annoyance and slowdown for users of advanced editors.

> Having multiple ways sharing the same nodes certainly makes it very difficult to select the way you actually want to edit much of the time.

> JOSM has the rather cumbersome "middle click to cycle through coincident objects".

You can select areas as normal by double clicking in them (josm), so selecting different closed way areas even when the ways are partially overlapping is a non-issue and you won't even notice it. If there are multiple linear ways overlapping, you can select them by cycling through them by holding the alt modifier key while clicking or selecting them from the popup list that appears when middle clicking on them.

> JOSM pulling all relation selection/editing into it's own side interface. And don't get me started on relations of relations ha.

Editing multipolygons works just like for any other objects. You _can_ select and edit them using the relation editor if you want to, but that is rarely necessary. Using the dedicated relation editor interface for other relations is a good thing since the properties of relations are so different to other objects and the normal editing interface is not intended for that (e.g. you need to be able to edit the member objects somehow).
Relations of relations are not relevant for multipolygons or areas that are the topic here.

Anyway. The multitude of issues with overlapping or not quite joining ways here in this area seem to have been here since they were created by a user who apparently didn't care too much and were not created by subsequent edits. This is not something that is an inherent fault of simple closed way areas.

changeset/108889099

> The duplicated edges tend to fall out of sync when edited so that abutting areas end up overlapping or not quite meeting.

I assume by 'get out of sync' you mean that the two closed way areas that used to perfectly share an edge are no longer identical along that edge and there are either holes or overlaps where one of the ways has some extra nodes/is missing some nodes somewhere in between?

I'm not quite sure I follow that argument. Deleting or moving a node always affect all parent ways and cannot make them go out of sync. When adding a new node into a way, pretty much all editors simultaneously add them to all overlapping ways that share the same way segment so that they are still in sync and attached (and if they don't, they shouldn't be anywhere near users who don't know exactly what they are doing). Detaching the ways from each other is actually harder than keeping them overlapping and really has to be done intentionally.
The one way that overlapping or not quite seamless areas can happen is if they are created that way and were never attached in the first place. Often there is a reason why there's a gap in between and if there isn't, they can simply be attached by merging the nodes to make them overlap.

boundary=hazard might be more suitable

Please use highway=construction instead
highway=construction

Also, please use more descriptive comments for your changesets and list your sources

Hi, you changed sections of a major road into a "guard rail" in this changeset and also in a previous changesets. What are your reasons for these edits/do you know these locations? As they are mapped right now, these "guard rails" are almost certainly not correct.

way/1119298556

Tags aside, changes like this and a lot of your other recent changes absolutely need to be discussed with the local community beforehand. You cannot just unilaterally change things across the world while disregarding local tagging customs and preceding discussions.

Hi,

`access=no` + `foot=yes` ist auf einem `highway=footway` unnötig. Dass Fahrzeuge dort nicht fahren dürfen ist schon durch footway impliziert [1].
way/1110097049

Hier hast du anscheinend den Übergang zweimal eingetragen?
way/1110097047

lg, Woazboat

[1] osm.wiki/OSM_tags_for_routing/Access_restrictions#Austria

Danke für's rückgängig machen