Beide routen durch alle Wohnstraßen, weil beide den Bug haben, das auf osm.wiki/OSM_tags_for_routing/Access_restrictions#Austria definierte motorcar=destination nicht zu berücksichtigen. Beispiel: osm.org/directions?engine=fossgis_osrm_car&route=48.17603%2C16.37069%3B48.17690%2C16.37354

> Und wieso haben wir das Problem deiner Meinung nach nicht, wenn wir Begegnungszonen und ganz normale Straßen durch Wohngebiete gleich taggen?

Weil die Berechtigungen für Begegnungszonen gleich sind wie für normale Straßen.

> Zusatztags brauchst du für highway=residential aber genauso, z.B. maxspeed=20, das ist bei einer Begegnungszone automatisch der Default, bei residential aber nicht. D.h., dein Vorschlag löst das Problem nicht.

Die Geschwindigkeitsbeschränkung ist in Begegnungszonen immer explizit angeschrieben und muss entsprechend getaggt werden. Genauso muss ja auch bei highway=primary im Ortsgebiet immer ein maxspeed + source:maxspeed (oder maxspeed:type) gesetzt werden. Und in 30er- und 50er-Zonen. Genau genommen müsste in Wien fast überall, wo ein 50er gilt, ein source:maxspeed=zone gesetzt werden wegen der 50er-Zone IG Luft. Begegnungszonen sind das geringste Problem, weil sie nur in anderen Zonen vorkommen (und somit der 20er bzw. 30er alles andere übersteuert) und nicht umgekehrt.

> Wir haben offensichtlich nicht genug international standardisierte highway=-Typen, um jedem in Österreich rechtlich definierten Straßentyp einen eigenen zuzuordnen.

Für Begegnungszonen brauchen wir keinen eigenen highway-Typ, weil das Begegnungszonen-Schild ein relativ "schwaches" Verkehrszeichen ist, das nur etwas über die Geschwindigkeitsbeschränkung und die Raumaufteilung der Straße aussagt, so ähnlich wie eine Ortstafel nur etwas über die Geschwindigkeitsbeschränkung aussagt. Es wär handlich, ein highway=shared_space zur Verfügung zu haben um maxspeed=20 + source:maxspeed nicht explizit setzen zu müssen (und es nur bei einem 30er setzen zu müssen), so ähnlich wie wir auf highway=residential (vs. unclassified) den 50er nicht explizit taggen müssen. Aber wir sind ja schon mit primary...tertiary und service leidgeprüft, maxspeed zusätzlich setzen zu müssen, also schaffen wir das auch bei Begegnungszonen. Wenn wir Begegnungszonen hingegen als Wohnstraßen taggen, dann müssen wir zum einen trotzdem maxspeed setzen (weil abweichend vom Default für Wohnstraßen) und zusätzlich noch eine Latte anderer Tags, um die Defaults für Wohnstraßen rückgängig zu machen. Das schafft kein normaler Mapper. Man braucht Insiderwissen um das in den Defaults gesetzte Radfahren gegen die Einbahn auszuschalten, ebenso die *=destination. Ich bin mir nicht sicher, ob dein access=yes überhaupt die in den Defaults (Link s.o.) definierten motorcar/goods/hgv/psv/moped=destination übersteuert, denn einerseits übersteuert das explizite Tag das implizite, andererseits aber auch das speziellere das allgemeinere. Um sicher zu gehen, müsstest du zusätzlich zu access=yes auch noch motorcar/goods/hgv/psv/moped=yes explizit setzen. Dann kennt sich überhaupt kein normaler Mapper mehr aus, und auch für einen erfahrenen User sieht es auf den ersten Blick nach einem Anfängerfehler (Auswahlorgie in den Listboxes des iD-Editors) aus.

Zur Mariahilfer Straße: Das Ziel war, mehr Platz für Fußgänger zu machen, nicht den Verkehr zu beruhigen. Was soll "beruhigen" überhaupt heißen? Das ist nur ein Euphemismus für Ausbremsen. Dafür gab es in der Mariahilfer Straße nie einen Bedarf, weil man dort sowieso nie schnell fahren konnte. Die grüne Stadträtin wollte den motorisierten Verkehr nicht ausbremsen, sondern ganz loswerden, und darum ist der mittlere Abschnitt der Mariahilfer Straße keine Begegnungs-, sondern eine Fußgängerzone. Wenn es nur nach ihr gegangen wäre, wären gar keine Begegnungszonen gekommen, sondern alles Fußgängerzone.

> Aber gerade dann (wenn es eine Durchzugsstraße ist) ist highway=residential unpassend

Genau, in so einem Fall sollte die Begegnungszone dann als primary/secondary/tertiary getaggt werden, aber halt mit maxspeed und evtl. shared_space=yes. Die Fallbeispiele (wo das nach meiner Erinnerung so umgesetzt war) müssten sich noch finden lassen.

> Ich will auf der Planansicht hier in Wien sehen, daß das eine verkehrsberuhigte Straße (grau) ist und nicht eine ganz normale (weiße) Straße.

Wie oft fährst du in Wien mit dem Auto? Selbst wenn du mit dem Fahrrad fährst, führt dich die Darstellung als Wohnstraße in die Irre, weil du dann davon ausgehst, dass du gegen die Einbahn fahren darfst.

Danke. Ich habe das Problem jetzt behoben.

Ich hab jetzt nicht nachgezählt, aber einerseits sind 6 Leute nicht repräsentativ, andererseits waren 6 Leute im Jahr 2013 zumindest repräsentativer als 6 heute, denn damals gab es noch nicht so viele User. Die ersten Abstimmungen über die Tags weltweit hatten nur eine Handvoll Teilnehmer.

Auf das Mail 2019 hat niemand geantwortet, weil es wie gesagt ein technisches Problem gab. Sonst hätte ich geantwortet und andere wahrscheinlich auch.

Ich hab jetzt nicht überprüft, wer wann was ins Wiki reingeschrieben hat (meistens sind das die selben, die alles umtaggen), aber deinen Angaben entnehme ich, dass das Tag in manchen Ländern zweckentfremdet wurde. In der Schweiz gibt es keine Wohnstraßen, also haben die Schweizer das Tag für die Begegnungszonen zweckentfremdet, weil das Verkehrszeichen ähnlich aussieht. In Österreich gibt es aber sowohl Begegnungszonen als auch Wohnstraßen und es sind unterschiedliche Dinge. So ähnlich war das auch bei highway=trunk, das in GB für "green roads" geschaffen wurde. In anderen Ländern gibt es diese "green roads" nicht, und darum haben die meisten es für Autostraßen verwendet. In GB wiederum gibt es keine Autostraßen, also ist es in jedem Land für sich genommen eindeutig. Wenn es in GB sowohl green roads als auch Autostraßen gäbe, wäre es absurd, highway=trunk für beides zu verwenden, weil man sie dann nicht mehr auseinander halten kann. Genau das Problem haben wir, wenn wir Wohnstraßen und Begegnungszonen gleich taggen. Das zieht eine Latte an Problemen nach sich, angefangen mit den Default-Berechtigungen. Man kann als Default nicht gleichzeitig vehicle=destination und vehicle=yes setzen. Entweder - oder. Auf jeden Way eine Latte an Tags zu setzen ist keine Lösung, weil weder durchschau- noch wartbar. Die Zauberformel lautet: 1 Schild – 1 Tag.

Du hast mehrmals das Wort "Verkehrsberuhigung" benutzt. Das gilt sicherlich für Wohnstraßen. Begegnungszonen haben hingegen NICHT Verkehrsberuhigung zum Ziel, sondern ganz im Gegenteil: Tests haben gezeigt, dass der Verkehr im shared space insgesamt flüssiger geht, als wenn Fahrbahn und Gehsteige getrennt sind. Die Höchstgeschwindigkeit hat nur das Ziel, Gefährdungen zu verringern, nicht den Verkehr aufzuhalten. 20 km/h sind näher an den heute in Wohngebieten üblichen 30 km/h als an der in Wohnstraßen vorgeschriebenen Schrittgeschwindigkeit.
Als ich mal Begegnungszonen recherciert habe, fand ich wie gesagt welche auch auf Bundesstraßen (in Kärnten?). Das sind Durchzugsstraßen, und keiner will stattdessen über eine Umfahrung durch enge Gasserln geroutet werden. Auch bei der Planansicht will man sehen, dass man durchfahren kann, also eine fette Liniensignatur und keine dünne graue, die in einem kleineren Maßstab ganz verschwindet.

Es ist keine lokale, sondern die nationale Ebene, und 2 oder 3 Personen können nicht für tausende österreichische Mapper einen Konsens aussprechen.
Abstimmungen gibt es nicht nur im Wiki, aber man kann darüber streiten, ob die Abstimmung 2013 eine gute Idee war. Meiner Meinung nach nicht! Bei der Anwendung existierender Tags auf die StVO sollte keine Anzahl von Meinungen zählen (wer holt seine meisten Freunde in die Abstimmung), sondern die Argumente. Die sprechen klar gegen living_street, weil eine Begegnungszone keine Wohnstraße ist. Zum Glück war der Abstimmung 2013 eine ausführliche Diskussion vorausgegangen, so dass die Abstimmung dann zum selben Ergebnis kam wie die Argumente.
Nein, ich habe keinen Bedarf das Thema nochmal aufzurollen. Ich habe bereits 2013 genug Zeit hineingesteckt und mache nicht gern die selbe Arbeit dreimal. Wenn du dir einbildest, die Abstimmung wiederholen zu müssen, dann schreib eine Ankündigung in Mailingliste und Forum und definiere einen Start- und ein Ende-Datum der Abstimmung.
Und es stimmt nicht, dass sich keiner über die "Entscheidung" von dir und Evod beschwert hat. Ich habe mich sowohl bei ihm (voriges Jahr) als auch bei dir beschwert.

This changeset has been reverted fully or in part by changeset/129979015 where the changeset comment is: 99674215 revertiert wegen falscher Änderung an Steinbruch

Im 2019er Thread war mit keinem Wort von einer Abstimmung die Rede. Die existiert nur in deiner Fantasie. Wenn du damit anfängst, Aussagen anderer Personen umzuinterpretieren und mich frech zu nennen, ist eine Diskussion mit dir nicht möglich und es bleibt keine andere Möglichkeit, als die Sache an die DWG zu eskalieren.

Erst mal zum Fachlichen: Eine Begegnungszone zeichnet sich nur durch die Aufteilung der Straßenbereiche auf. Das gehört in den Themenkreis lane-Tagging. Eine Begegnungszone sagt nichts über die Verkehrsbedeutung oder Benutzungsberechtigungen der Straße an sich aus. Eine Begegnungszone kann alles sein von primary bis residential. Das ist was ganz anderes als eine Wohnstraße, die durch spezielle Berechtigungen und geringe Verkehrsbedeutung gekennzeichnet ist.
Bei https://lists.openstreetmap.org/pipermail/talk-at/2019-December/010423.html muss es ein technisches Problem gegeben haben. Ich habe dieses Mail nicht bekommen (auf Talk-AT kam zwischen 3. und 12. Dezember 2019 gar nichts) und andere offenbar auch nicht, sonst hätte ihn jemand (ich sicher) ihn an den seit 2013 bestehenden Konsens erinnert.
Zu https://forum.openstreetmap.org/viewtopic.php?pid=770375: Einstimmig, wie bitte? Das war eine Diskussion, keine Abstimmung, und von den 6 beteiligten Usern schrieb Gppes explizit, dass living_street NICHT passt, ebenso argumentierte Connecticut gegen living_street,
Luzandro und friedl äußerten keine eigene Meinung zu residential vs. living_street, und somit bleiben evod und du als die zwei, die eigenmächtig das Wiki und die Daten verpfuscht haben. Vielleicht warst du 2013 noch kein Abonnent der Mailingliste und kanntest den Konsens daher nicht. Ab jetzt kennst du ihn und es gibt keine Entschuldigung mehr! Evod (=Markus Straub) kannte den Konsens sehr wohl seit 2013, denn er hatte sich damals nicht nur an der Diskussion und Abstimmung beteiligt, sondern er war derjenige, der die Abstimmung gestartet hat! Was hältst du von jemandem, der eine Abstimmung startet und sie dann nicht anerkennt, wenn sie anders ausgeht als erhofft?

Durch note/3473632 wurde ich auf diesen Fehler aufmerksam. Deine Änderung ist falsch, denn der Konsens ist genau andersrum, siehe osm.wiki/OSM_tags_for_routing/Access_restrictions#Austria Anmerkung 10. Leider hat, wie so oft, jemand, der null Ahnung von der Sache hat, das Wiki an mehreren Stellen verhunzt. Ich ersuche dich, alle auf living_street umgetaggten Begegnungszonen wieder auf residential zurückzuändern und die Tags für Sachen, die nicht ausgeschildert sind (vehicle=yes, oneway:bicycle und was auch immer), zu entfernen.

Das ist nicht die Bezeichnung des Wegweisers, sondern offenbar der Ziele, die am Wegweiser angeschrieben sind.

Interessant, dass du vor 5 Monaten den Zaun weitergezeichnet hast. Ich dachte schon, er sei komplett abgebaut worden, siehe note/3434847. Vielleicht wurde nur ein Teil im Osten aus dem Jagdgebiet ausgegliedert und der Zaun dort bergauf versetzt?

Wenn du Vorschläge des iD-Editors, der dafür bekannt ist, vieles hinzumachen, ungeprüft umsetzt, dann ist in Changesets wie diesem und 122379965 sicherlich viel mehr kaputtgegangen als das, wodurch ich darauf aufmerksam wurde: Du hast Luftschutzstollen als Gebäude getaggt. Wie kann man überhaupt auf so eine Idee kommen? Ich wil mir gar nicht ausmalen, was da sonst noch alles passiert ist. Darum bin ich für einen kompletten und möglichst raschen Revert dieser Changesets.

Die Seite berücksichtigt nicht den Fall, das es keinen highway gibt. Somit ist die Spezifikation fehlerhaft. Ich sehe 2 Möglichkeiten um mit dieser Wikiseite konform zu gehen: A) Den Node aufs Ende vom highway=service setzen. Denn das ist der näheste highway. B) public_transport=stop_position auf highway=bus_stop ändern ("In that case it can be abandoned.").

PS: Mir ist gerade klar geworden, dass die Spezifikation eh schon erfüllt ist, da die Haltestelle hier in beiden Relationen weder die "initial stop position" noch die "terminal stop position" ist.

Maxxar kenne ich nicht, ich finde im Web nur Maxar, und die Bilder dort (discover.maxar.com) sind total unscharf (10m-Raster?), da kann ich kaum erkennen, dass da überhaupt eine Siedlung ist.

Was die Bushaltestelle betrifft, da war meiner Meinung nach die alte Metode (highway=bus_stop dort, wo das Bus stehen bleibt) die logischere. stop_position wird meistens nicht dort gesetzt, wo der Bus stehen bleibt, sondern irgendwo abstrahiert in der Fahrbahnmitte. Dann kann man hier auf diesem Parkplatz aber nicht wieder mit Micromapping anfangen und die stop_position an den SO-Rand des Parkplatzes setzen, wie wir es früher mit highway=bus_stop gemacht hätten.

Ich hab jetzt auf route=bus?uselang=en nachgeschaut, ob die stop-positions überhaupt auf Ways liegen müssen. Das steht nicht explizit dort, nur bei der Reihenfolge steht, dass die Ways bei der ersten stop_position anfangen und bei der letzten aufhören sollen. Wer sich das ausgedacht hat, kann noch nie eine Relation editiert haben, denn zig Members in so eine Reihenfolge zu bringen ist mega aufwendig und für eine automatisierte Auswertung ist das überhaupt nicht notwendig.

Wer "regelkonforme" Busrelationen will und unendlich viel Zeit hat (emergency99?), kann einen taglosen Way (dass er mit highway=* getaggt sein muss, steht in der Spezifikation nicht) zwischen node/1423929885 und 1064647647 anlegen und jeweils 2x zwischen den zwei 73298026 in die Relationen einhängen.

Du meinst die parking_aisle? Dort ist keine! Das weiß ich sicher, weil ich gestern dort geparkt habe. Das ist ein völlig strukturloser Parkplatz ohne gekennzeichnete Spuren oder Stellplätze. Es gibt auch das Loch in der Mitte nicht, das vorher mittels Multipolygon gemappt war. Das sehe ich auch auf älteren Luftbildern (ab 2003) nicht. Darum verstehe ich nicht, wie jemand überhaupt auf die Idee kommen konnte, dieses Loch zu mappen.

relation/14379245 stimmt auch nicht. Bei restriction=only... sollte die Rolle "to" jener Way haben, auf den man fahren muss, nicht auf den es verboten ist. (Das ist andersrum als bei restriction=no...turn.) Ich würde auch vorschlagen, nicht zu viele Änderungen bzw. an weit auseinander liegenden Stellen im selben Changeset zu machen, denn bei so einem Mega-Changeset kann man nicht mehr nachvollziehen, was dabei an einer bestimmten Stelle verändert wurde, geschweige das rückgängig machen.

westlich

Du bist doch vorhin selber schon draufgekommen, dass destination überhaupt nicht stimmt. Lieferverkehr muss nicht explizit draufstehen, denn der ist mit "Fahrten von und zu Anrainern" schon impliziert.

Bitte rückgängig machen. Obersulz ist der Name des Dorfes, nicht der Straßen.

@Luzandro 10:11 Wenn du sie besuchst, lieferst du ihnen dich selbst. Ja, Kunden sind ein Problem, weil sie in Fußgängerzonen nicht zufahren dürfen (auch wenn Lieferverkehr erlaubt ist), in einem Fall wie hier aber schon. D.h. genau genommen müsste man vehicle=delivery;customers setzen.
@wolfgang8 Nein, bei "Zufahrt gestattet" darf jeder zufahren. Sonst würde sowas wie hier stehen oder gleichbedeutend "ausg. Anrainerverkehr". Bei Verkehrszeichen gibt es kein Zwischen-den-Zeilen-Lesen, sondern es gilt das, was draufsteht.
Nein, bei Lieferverkehr ist kein Durchfahren erlaubt, siehe Fußgängerzonen.
Was auf der verlinkten ÖAMTC-Seite über Anrainer und -verkehr steht, stimmt. Nur die Deutschen kapieren das nicht, die haben die Wikiseite (zumindest die deutschsprachige) wiederholt verfälscht.
@Luzandro 14:28 Dieses OGH-Urteil (von dem offenbar weder die Rechtsexperten des ÖAMTC etwas wissen, s.o., noch in der Newsgroup at.verkehr.strasse, wo Anrainer/-verkehr schon diskutiert wurde, bevor es OSM gab) ist komisch, weil im ersten Satz von Anrainern die Rede ist, im zweiten von Anliegern. Vielleicht ist diese Konfusion der Grund, warum das Urteil gleich wieder in Vergessenheit geriet.
@wolfgang8 15:37 Bin eh (und war immer schon) für einheitlich private (Anrainer) bzw. delivery (Anrainerverkehr). Wenn nicht delivery (oder delivery;customers), dann von mir aus private, das ist weniger falsch als destination.
Ich wollte schon vor vielen Jahren ein Proposal schreiben für ein neues access-Tag für Anrainerverkehr, aber das Problem ist, dass es dafür keine englische Übersetzung gibt. vehicle=visitors war noch das Beste, was mir eingefallen ist.