Enge Einbahnstraßen (`parking:both:staggered=yes`) ((ehemals `parking:condition:either_side_only=yes`))

[joshinils]

https://kartaview.org/details/3580373/1131/ https://www.openstreetmap.org/way/911884371 https://parkraum.osm-verkehrswende.org/project-vector-tiles/#18.05/52.63423/13.295185

rechtlich darf ich doch auf beiden seiten parken, auch wenn die rechte seite physisch wie parkbuchten aussieht oder? links ist kein haltverbot, jedoch ist parken nicht möglich vor/neben den bäumen, nur dazwischen, wenn rechts niemand steht.

problem; diese plätze werden doppelt gezählt, bzw. pro seite einmal, auch wenn bäume daneben sind.

ist das ein tagging-fehler?

[SupaplexOSM]

Es ist mindestens irreführend/ungünstig getaggt. Es gab mal irgendwo eine Diskussion zu solchen "alternierenden" Fällen, also Straßen, die zu eng zum Parken auf beiden Seiten sind, aber an denen abschnittsweise mal auf der einen Seite und mal auf der anderen geparkt wird. Ich finde sie leider gerade nicht wieder, aber ich weiß, dass es auch noch keine Lösung gab. Ist also ein Fall für einen speziellen Tagging-Vorschlag.

So lange dort aber quasi auf der linken Seite nie ein Auto steht, würde ich im Zweifelsfall lieber gar nichts mappen, vielleicht "no" (siehe unten). Oft hat sich in solchen engen Straßen ja einfach "historisch" eine Seite entwickelt, auf der geparkt wird. Die würde ich dann auch mappen. Aber wenn die Anzahl der parkenden Autos nicht all zu groß ist, wird halt mal hier und mal dort geparkt.

In deinem konkreten Fall könnte ich mir allerdings vorstellen, dass links parken trotz Einbahnstraße unzulässig ist, weil der Verkehrsfluss eingeschränkt wird oder so. Aber im Zweifelsfall können das wohl nur Gerichte entscheiden :)

[tordans]

Ich frage mich das gleiche, wenn ich an mein Heimatdorf denke. Alle Wohnstraßen müsste ich theoretisch dort mit beidseitigem Parallelparken mappen. Faktisch wäre die Straße dann unnutzbar oder zumindest könnte man nirgendwo mehr ausweichen (wie in Rixdorf quasi ;)). Meine Lösung bisher: Mein Heimatdorf mit mit parking:lane mappen ;-).

Für den konkreten Fall: Ich würde eine Seite auf "no" setzen. In diesem Fall die ohne Park"buchten". Das ist IMO das, was in Realität angewendet wird und wird den Daten am ehesten gerecht.

TODO

• [ ] In unseren Tagging-Empfehlungen (Wiki) hierfür eine klare Position beziehen [Anm. Alex: bzw. einen Tagging-Vorschlag dafür proposen - steht schon im Ideen-Pad.]

[joshinils]

hm, ja - viele straßen in frohnau sind so "schmal", dass man nur auf einer seite gleichzeitig parken kann, aber es ist auf beiden seiten erlaubt.

ich hatte irgendwo im wiki mal parking:condition:either_side_only gesehen, das nutzt aber niemand, und nun find ich die seite dazu auch nicht mehr. im endeffekt ist das aber erschließbar aus den lane-daten und der width, müsste also klar sein, wenn beides getaggt ist.

und eine seite zu bevorzugen im tagging finde ich unvorteilhaft gelöst, da meist in diesen straßen nach gewohnheit eine seite - auch abschnittsweise - präferiert wird.

im endeffekt kann man das doch als halben parkplatz zählen in solchen straßen, also (summe aller in der schmalen straße) / 2

[joshinils]

und fälle wo es ein parkverbot gibt mit alternierend gemalten flächen wo es doch erlaubt ist gibt es auch. da müsste man die ganze straße sehr oft zerstückeln und je beidseitig als auch links/rechts verbote taggen, was auch unangenehm ist

beispiel nicht in berlin: https://kartaview.org/details/3614441/1470/ https://www.openstreetmap.org/way/24555929

[SupaplexOSM]

parking:condition:either_side_only taucht auf dieser Seite auf. Derzeit 138 mal in Verwendung. Aussagen aus width ableiten würde ich vermeiden (allein schon weil Parkbuchten nicht in die width reinzählen, andere Parkstreifen aber schon - was gelegentlich aber nicht korrekt gemappt wird) - das kann man höchstens als Plausibilitätsprüfung nutzen. Lieber eine eindeutige Tagging-Ergänzung nutzen.

[joshinils]

verstehe, also ist der tag nicht dokumentiert, nicht wirklich in benutzung und somit nicht verwertbar? für mich wäre die frage, was (eineindeutig?) als parkbucht gilt und was einfach nur eine zwischendurch verengte fahrbahn ist.

im edelhofdamm ist das nicht als parkbucht markiert oder beschildert, hat gleichen untergrund, keinen bordstein oder irgendwas, somit nicht eindeutig als parkbucht definiert, aber faktisch so benutzt.

wäre das dort dann parking:lane:right:parallel=on_street oder street_side? (wir müssten das mal dokumentieren wo was gilt, mit bildern und vielen beispielen bitte) dass links on_street gilt ist klar, weil nicht explizit verboten, außer aus platzgründen neben den bäumen auf der rechten seite.

die width=3.4 hab ich mit streetcomplete an einer der verengten stellen gemessen, beinhaltet dort also nicht die breiteren abschnitte, und passt somit zum street_side tagging.

frage für mich ist also, ob das tagging richtig ist, und/oder ob die analyse richtig ist. faktisch darf man auf beiden seiten parken, also sind dort auf beiden seiten parkplätze (so wie auch bei anderen schmalen straßen auch). wirklich nutzbarer platz existiert nur jedoch halb so viel.

ich will auch nicht vorschlagen sich kompliziert auszusuchen, wo man parken darf, nach abschnitten pro einfahrt das dann zu maximieren und diese zahl zu nehmen, das ist zu umständlich.

man könnte aber bei solchen straßen, so man diese erkennen kann nach welchen maßstäben auch immer, einfach die seite der straße nehmen wo mehr parken können und die andere seite zu verwerfen, damit sind die "echten" plätze nicht doppelt so hoch.

[SupaplexOSM]

Ich würde das hier klar als "street_side" definieren, weil der rechte Straßenrand durch die "baulichen Baumscheiben" gravierend strukturiert wird und in dieser Form nicht als Fahrbahn genutzt werden kann. Daher wäre die Breitenangabe in diesem Fall auch ohne die Parkbuchten korrekt.

Eine gut illustrierte Unterscheidungshilfe für "street_side" und "on_street" entsteht hoffentlich im Rahmen dieses Projekts - wir haben schon oft drüber diskutiert und das Thema kommt immer wieder auf. Die Straße ist eigentlich ein schönes Fallbeispiel - könnte da also gut reinpassen.

Was das Parken links in diesem Fall angeht, hatte ich ja schon geschrieben, dass ich mir gut vorstellen kann, dass es nicht gestattet ist. Aber nur Gefühl. Ich würde es nicht mappen.

An eindeutigeren Stellen, wo das beidseitige, aber nur einseitig mögliche Parken auch Praxis ist, würde ich dann erstmal den Tag oben (parking:condition:either_side_only=yes) verwenden. Sehe da jetzt erstmal keinen offentlichtlichen Logikfehler im Tagging. Hier noch ein Beispielbild, das mir neulich untergekommen ist - wenn mal Gelegenheit ist, werde ich das mal im Wiki als "in use" dokumentieren:

[joshinils]

gut, dann werd ich in frohnau je straßw abwägen, ob man dort beidseitig parken kann und oder darf und das mit dem neuen tag anmerken.

ob und wie das hier berücksichtigt wird ist eine andere frage, wofür das issue eigentlich gut da ist

[joshinils]

Ich hab in der wiltinger str mal parking:condition:either_side_only=yes getaggt, dort erscheint das jetzt natülich noch doppelt gezählt: https://parkraum.osm-verkehrswende.org/project-vector-tiles/#16.46/52.636125/13.289792

[gislars]

oh ja, either_side_only wird noch nicht ausgewertet.

[joshinils]

ist ja auch recht "neu" und nicht wirklich gut dokumentiert. und laut overpass turbo berlinweit auch nur in der wiltinger straße seit meinem tagging benutzt.

insofern wundert mich das nicht

[SupaplexOSM]

Im Rahmen dieses Projekts habe ich mir vorgenommen, die Dokumentation des parking-lane-Schemas zu verbessern und evtl. das ein oder andere "Sonder-Tagging" zu dokumentieren/proposen, daher hab ich das mal auf meine Liste geschrieben. Von daher können/sollten wir das früher oder später auch berücksichtigen.