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

Adding and changing data in OSM that is accurate and correct is great. Incorrectly changing OSM data to work around the limitations of another program is absolutely not. Not even temporarily.

If you want to use OSM data with some other program and doing so would require making incorrect changes to OSM you have two options:

1) fix the program to work with the correct data
2) download the osm data and make your changes offline

Diskussion hier fortgeführt: changeset/132920258

Habe ursprünglich hier kommentiert aber werde das jetzt hier weiterführen

changeset/132919460

Die Einstufung im digitalen Atlas Steiermark ist für die Straßenkategorie in OSM hier irrelevant. Der `highway`=* tag wird durch die Relevanz der Straßen für den Verkehr bestimmt.

Hallo, du hast hier die Straßenkategorie von einigen wichtigen Straßen in Graz heruntergesetzt. War das mit der lokalen Community abgesprochen bzw. was ist der Grund für diese Änderungen?

lg, Woazboat

If you want these roads to show up as cart paths in your golf game, poke the maintainer of your import tool to take a look at https://github.com/chadrockey/TGC-Designer-Tools/issues/94 and merge the changes in https://github.com/chadrockey/TGC-Designer-Tools/pull/119 instead of incorrectly modifying OSM data

Finding, reporting and fixing vandalism IS the responsibility of all OSM contributors and that includes @emersonveenstra.

If your changes violate the established mapping practice, they shouldn't be in OSM. That includes 'temporary' changes(/vandalism) to the shared global map just so you can import the data for some game. If you want to do that, make your changes to a local file and import that.

I don't see the problem with changing the unconventional mast:type to the accepted tower:type, but tags definitely shouldn't simply be removed.