Lanes, parking in Anwohnerstraßen

Wir hatten hier vor einiger Zeit einige Diskussionen, z.B. hier:

https://forum.openstreetmap.org/viewtopic.php?id=67468
https://forum.openstreetmap.org/viewtopic.php?id=54099

Ich glaubte z. B., dass 'lanes='* die Anzahl der markierten Spuren darstellt, was eine klare Definition wäre. Ich nahm zudem an, dass bei fehlender Mittellinie aber Begrenzungslinien rechts und links immer ‘lanes=1’ zu nehmen wäre, auch wenn die Spur überbreit wäre und PKW sich gegenseitig überholen können.

Beides ist nicht so. Gerade in Ländern mit weniger Geld für Straßen gibt es oft landesweit kaum Fahrbahnmarkierungen aber überall wird 'lanes='* getaggt. Mit meiner Interpretation, dass auch Begrenzungslinien eine Spur markieren, war ich recht einsam :slight_smile: .

Somit gibt es keine saubere Abgrenzung bei Grenzbreiten, z. B. bei 4,5m breiten Straßen, wo sich PKW begegnen können, große LKW aber nicht. Hier lasse ich das 'lanes='* weg, tagge stattdessen ‘width=4.5’ und ‘lane_marking=no’.

‘lanes=2’ gibt es bei mir nur, wenn entweder Fahrstreifen markiert sind (z. B. Radweg mit Mittellinie) oder sich zwei LKWs ohne Bremsen begegnen / überholen können.

und wenn es 2 markierte Spuren gibt aber LKWen bremsen wenn sie sich begegnen?

Da das eine OR-Bedingung ist und keine XOR-Bedingung … genügt das true von markiert …
Man mappt schließlich nach ‘On-the-Ground’ - und nicht nach dem subjektiven LKW-Fahrer-Verhalten. :slight_smile:

Dann ist es eindeutig. Im Zweifel halt 'width=’ *dazutägigen, die kann man aus den Luftbildern ja gut abschätzen.

Die Frage, ob man bei der lanes-Angabe parkende Autos ohne markierte Parkstreifen mitzählt, stellt sich übrigens auch beim Verzicht auf 'lanes=* bei der Frage, wo man die Breite misst. Ich bin dort immer pragmatisch vorgegangen. Wenn parkende Autos eher die Ausnahme sind, wie z.b. bei unbebauten Straßen, dann habe ich sie nicht mitgezählt. Wenn parkende Autos die Regel sind und mehr nur als eines pro Straßenabschnitt, dann habe ich die nicht markierten Parkstreifen nicht mit bei der Messung berücksichtigt.

Hmmm - width ist eine physikalische Eigenschaft des Objektes ‘Straße’ (ggf. Fahrbahn) - und sollte absolutes und unumstößliches Fakt sein.
Das Parken auf der Fahrbahn ist eine ‘vorübergehende’ Nutzung - und damit variabel und eher subjektiv.
Ich finde, man sollte das schon klar auseinanderhalten und nicht nach Gusto entscheiden.
Wenn die Straße mal in voller Breite benötigt wird, werden halt temporäre Halteverbote erlassen.
Die Eigenschaft ‘Parken auf Fahrbahn erlaubt/verboten’ kann man über geeignetere tags abbilden - und dann eben auch auswerten.
Meinetwegen dann auch noch die erlebte ‘Auslastung’.

Das sehe ich auch so.

Soweit ich weiß ist width auf Straßen von-Kantstein-zu-Kantstein und wenn keiner vorhanden ist dann die befahrbare Breite (dh normalerweise die Breite des Asphalts). Steht das nicht so in der Wiki? Das Thema wurde eigentlich grad neulich auf der tagging mailingliste besprochen.

Die rechtliche Situation in Deutschland ist ja meines Wissens so, dass man überall dort am Straßenrand, aber auf der Fahrbahn parken darf, wo es nicht ausdrücklich verboten ist. Verboten ist es dort, wo es durch Schilder oder Fahrbahnmarkierungen als verboten gekennzeichnet ist, im Kreuzungsbereich, entgegen der Fahrtrichtung und so, dass ein fahrendes Fahrzeug nicht mehr vobeipasst. Letzteres kann z.B. bedeuten, dass - wenn rechts bereits ein Fahrzeug steht, sich links keines mehr hinstellen darf und umgekehrt. Diese allgemeine Parkerlaubnis ist demnach sozusagen default. Ich halte es für sehr problematisch, parking:lanes hierfür zu verwenden. Denn dies müsste entweder flächendeckten für praktisch alle innerörliche Straßen hinzugefügt werden oder es sugeriert, dass es einen ausdrücklich zum Parken gedachten Parkstreifen gibt. Daher halte ich den Wiki-Artikel https://wiki.openstreetmap.org/wiki/Key:parking:lane/Examples für höchst problematisch. Da gibt es keine dem Parken vorbehaltene Spur, es ist dort lediglich das Parken auf der Fahrbahn erlaubt.
Ich halte es auch für höchst problematisch, bei Straßen, auf der keine Fahrbahnen eindeutig eingeteilt sind (durch Markierungen) von Fahrspuren zu sprechen. Das sind zwar Straßen, bei denen Begegnungsverkehr möglich ist, ohne die Fahrbahn zu verlassen oder eine Ausweichstelle zu nutzen. Aber erstens ist diese Situation je nach Fahrzeugart unterschiedlich (Begegnung zweier LKW braucht eine größere Breite als Begegnung zweiter PKW) und zweitens ist die Situation je nach dem, wo Fahrzeuge parken, unterschiedlich. Aus einer Straße, auf der sich zwei LKW locker begegnen können wird durch parkende Autos rechts und links dann schnell eine Straße, wo zwei sich begegnende PKW nur aneinander vorbeikommen, wenn eines der Fahrzeuge eine Lücke zwischen parkenden Fahrzeugen sucht, um den Gegenverkehr vorbeizulassen.

Wenn lanes also so diffus genutzt wird, sehe ich große Schwierigkeiten, daraus verwertbare Informationen zu ziehen.
Diese sind aber gerade im Stadtverkehr durchaus wichtig, wenn es sich tatsächlich um markierte Fahrspurgen handelt. Dann ist es nämlich super, wenn einem die Navi-App frühzeitig darauf hinweisen kann, auf welche Spur man sich einordnen soll (Abbiegespuren) oder wo es tatsächlich zwei markierte Fahrspuren in der gleichen Fahrtrichtung gibt, die man gut nutzen kann, um an ein langsameres Fahrzeug zu überholen.

Daher wäre aus meiner Sicht die richtige Konsequenz, einen Konsens darüber herbeizuführen, dass sich lanes nur auf markierte Fahrspuren bezieht und nicht darauf, wieviele Fahrzeuge auf der Straße nebeneinander fahren können und dass sich parking:lanes auch nur auf allein dem Parken vorbehaltene Parkstreifen bezieht und nicht darauf, ob man auf der Fahrbahn parken darf.

Ich persönlich werde unabhängig davon, ob ein solcher Konsens gefunden wird, weiterhin darauf verzichten, bei Straßen nicht markierte Fahrspuren anhand der Straßenbreite einzutragen. Für mich ist eine 7m breite Straße ohne Mittellinie im Grund eine Straße mit **einer **variabel genutzen Fahrspur. Variabel im Sinne, dass sie teilweise auch als Parkfläche genutzt wird, teilweise aber auch Begegnungsverkehr ermöglicht.

Ich werde weiterhin mit parking:lanes nur dann verwenden, wenn ich damit einen separat neben der Fahrbahn vorhandenen Parkstreifen vorfinde.

Da fehlt aber noch ein ganzer Schwung:
Bundesstraßen (etc.) innerorts, Alle Straßen ausserorts, die Hauptstraßen sind (also so gut wie alle Hauptverkehrswege), verkehrsberuhigte Zone, aufgemalte Fahrrad"angebots"-streifen und sicherlich noh einen Schwung andere, die ich grad auch nich aufm Schirm hab :wink:

Ja, schwierig. Schon dieses Proposal gesehen? Formalisierung von “street side parking” (~Parkbuchten) Abstimmung endet in 4 Tagen:
https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side

Die Wiki für parking:lanes ist noch recht dürftig, ich interpretiere sie die Values aber so:

  • on_street: keine Markierungen, “Parken auf der Straße”

  • half_on_kerb: ebenso, nur Autos parken halb auf dem Kantstein

  • on_kerb: evtl Markierungen oder auch nicht, Autos parken jedenfalls komplett auf dem Kantstein

  • lay_by: Parkbuchten. Wird nach Annahme des o.g. Proposals durch street_side ersetzt und deprecated

  • painted_area_only: einzelne markierte Parkplätze auf der Straße

  • on_lane: echte “Parking Lane”, also eine eigentlich vollwertige Fahrspur wenn sie nicht dediziert fürs Parken wäre

Das heißt, im Sinne was ich unter einer “Parking lane” verstehe sind eigentlich höchstens die letzten drei Werte “echte” Parking Lanes. Wobei natürlich auch Schilder existieren für solche Situationen wo einfach Autos an der Straße parken:
https://wiki.openstreetmap.org/wiki/File:Parking_P_inline_residents_S7_DE.jpg

Wie dem auch sei, ich finde es gut und wichtig wenn überall parking:lane getaggt ist, da es der Weg ist wie man Halte und Parkverbote taggt, weil viele “Parken auf der Straße nicht verboten” auch entsprechend beschildert sind und weil diese Information auch wichtig ist für Router. Schmale Straßen die zusätzlich noch parkende Autos auf der Straße haben, dort möchte man eher nicht durchgeroutet werden.

Dem kann ich mich anschließen. Noch wichtiger finde ich, was ich auch schon hier im Forum angesprochen habe, dass diese Informationen genutzt werden (Kartendarstellung, Router).

Parken auf der Fahrbahn ist was anderes als Parken auf einem Parkstreifen neben der Straße. Dies wird aber offenbar bislang auf wenig verifizierbare Art in einen Topf geschmissen. Gerade der Hinweis

zeigt dies meines Erachtens noch einmal deutlich. Ohne ein eindeutiges Attribut, dass verdeutlicht, ob es sich um Parken auf der Fahrbahn oder Parken neben der Fahrbahn auf einem Parkstreifen handelt, ist der Informationsgehalt meines Erachtens zweifelhaft. Daher bräuchte es tatsächlich Ergänzungen, wie in dem #18 erwähnte Proposal vorgeschlagen. Ich tu mich trotzdem schwer, Parken auf der Fahrbahn als parking:lane zu bezeichnen. Und das Attribut =on_street erscheint mir noch nicht optimal von der Wortwahl. Dies kann das allgemeine Parken auf der Fahrbahn meinen, aber auch das Parken auf, auf der Straßenfläche aufgemalte Parkflächen. Diese würde ich vom deutschen Wortverständnis her auch als “auf der Straße” interpretieren, allerdings nicht als “auf der Fahrbahn”. Das könnte man natürlich durch einen entsprechenden Erklärtext im Wiki eindeutig festlegen.
Mir wäre für die Parkerlaubnis auf der Farbahn ein parking=on_street eher gefallen als parking:lane=
, aber wir müssen bei OSM mit so manchen Begriffen leben, die nicht durchgängig logisch oder stimmig sind. Wichtig ist dabei die klare Definition.
Insgesamt habe ich aber Sorge, dass der Wunsch, die nicht gesondert ausgeschilderte Parkerlaubnis auf der Fahrbahn in OSM zu einem Wildwuchs und diversen Falscheintragungen führt. Denn die allgemeine Erlaubnis, innerorts an allen Straßen auf der Fahrbahn zu Parken wird durch §12 der StVO relativiert:
Das Parken ist demnach u.A. verboten

  • vor und hinter Kreuzungen und Einmündungen bis zu je 5 m von den Schnittpunkten der Fahrbahnkanten, soweit in Fahrtrichtung rechts neben der Fahrbahn ein Radweg baulich angelegt ist, vor Kreuzungen und Einmündungen bis zu je 8 m von den Schnittpunkten der Fahrbahnkanten,
  • vor Grundstücksein- und -ausfahrten, auf schmalen Fahrbahnen auch ihnen gegenüber,
  • vor Bordsteinabsenkungen.
    Ignorieren wird diese Einschränkungen oder zerstückeln wir alle Straßen in kurze Abschnitte, um die Situation korrekt abzubilden?

Um das beim Routen zu beachten, braucht es aber die Kombination aus Fahrbahnbreite und der Information, dass Parken auf der Fahrbahn erlaubt ist (und in dem Fall auch, ob auf beiden Seiten oder nur auf einer Seite) - ist es realistisch, dass diese Informationen alle realisitisch und korrekt in OSM eingetragen werden? Wie oft gibt es z.B. Diskussionen darüber, was als Straßenbreite bezeichnet wird. Und wir wissen alle, dass gerade innerorts die Straßenbreite sehr stark variiert. Zerstückeln wir also zukünftig alle innerörtlichen Straßen noch weiter, um die Straßenbreite stets korrekt eintragen zu können? Was ist dann mit der Wartungsfreundlichkeit? Dazu kommen ja dann noch die Attribute für sidepath=left, sidepath=both, sidepath=right, die innerorts teilweise auch auf recht kurzen Streckenabschnitten wechseln. Dazu kommen Wanderwegrelationen, die mal für 30m eine Straße entlang führen um dann wieder in eine andere Straße abzubiegen. Wenn wir das alles konsequent umsetzen wollten, hätten wir am Ende Straßen, die aus 10m-Stückchen zusammengesetzt sind. Sehr fehleranfällig und sehr unübersichtlich.
Daher fände ich es weit realisitischer wenn wir uns darauf einigten, nur tatsächlich aufgemalte oder baulich von der Fahrbahn getrennte Parkstreifen einzutragen und daneben meinetwegen alle Streckenabschnitte, auf denen ausdrücklich (Beschilderung) das Parken verboten ist. Alles andere wird meines Erachtens nur fragwürdiges Stückwerk bleiben.

Ich hatte vergessen “innerorts” in meinen Satz einzufügen.
Auf Bundesstraßen innerorts gibt es allerdings meines Wissens kein allgemeines Parkverbot. Und meines Wissens ist außerorts das Parken auf der Fahrbahn grundsätzlich untersagt und das nicht nur auf Hauptstraßen.

Den Wunsch kann ich gut nachvollziehen.

Aber wird sich meines Erachtens nicht umsetzen lassen.

Beispiel: Ich fahre täglich auf dem Weg zur Arbeit auf der Hauptstraße durch zwei Dörfer. Die Fahrbahn ist so ungefähr 7 Meter breit. Das Parken ist entlang dieser Straße auf der Fahrbahn mit den in der StVO beschriebenen Ausnahmen/Einschränkungen erlaubt. An einigen Stellen parken Autos auf einer Straßenseite, an einigen Stellen sogar auf beiden Straßenseiten. Wo, ist sehr unterschiedlich. Es gibt Zeiten, da steht gar kein Auto entlang der ganzen Ortsdurchfahrt und es gibt zeiten, da stehen in einem Abschnitt die Autos beidseitig geparkt. Einseitiges Parken: Kaum Einschränkung, zwei PKW können sich locker gegenseitig begegnen. Ist eines der Fahrzeuge ein LKW, wird es eng, eines der beiden Fahrzeuge sollte besser warten. Zweiseitiges Parken: Zwei sich begegnende PKW können vorsichtig fahren. Ist ein LKW dabei, muss ein Fahrzeug auf jeden Fall warten. Und wenn wegen einer größeren Veranstaltung (Konfirmation) mal über 200m beidseitig Autos auf der Straße parken, gibt es unweigerlich Stau.

Daher: Wonach soll sich eine Routing-App in diesen Fällen richten? Die rechtliche und bauliche Situation ist immer gleich.

Auch bei Straßen in Wohngebieten gibt es welche, da parken nur sehr wenige Fahrzeuge auf der Fahrbahn, da es genügend Stellplätze auf den anliegenden Wohngrundstücken gibt. Bei anderen sind nicht genügend Stellplätze vorhanden und die Anwohner parken überwiegend auf der Straße, und weil es Mehrfamilienhäuser sind, ist die Straße praktisch auf der ganzen Länge “zugeparkt”. Bei gleicher rechtlicher Situation und gleicher Fahrbahnbreite also eine vollkommen unterschiedliche Situation. Im ersten Fall kann man zügig in Tempo 30 durch die Siedlung fahren, im zweiten Fall kommt man nicht viel schneller als im Schritttempo dort entlang.

Noch ein Einwand dagegen, alle Parkmöglichkeiten als Zusatzattribute der Straßenlinie unterzugbringen:

Parken nur mit Parkscheibe, Parken mit Parkschein, Parken nur an bestimmten Wochentagen, Parken nur zu bestimmten Zeiten, Parken nur für Anwohner mit Parkausweis… als das muss in dem Fall für jedes Straßenstückchen exakt angegeben werden und bei jeder Veränderung der Straße, aktualisiert und berücksichtigt werden.

Wie könnte man die beschriebene Situation dann lösen, wie taggen?

Welche Situation meinst Du jetzt - die rechtliche oder die Nutzung?
Die rechtliche kann man taggen - dann muss man eben in den sauren Apfel beißen und die Zerstückelung in Kauf nehmen.

Ob dort nun eine rege Nutzung oder keine Nutzung der Parkmöglichkeiten stattfindet - würde ich zumindest nicht taggen.
In residential und unclassified ist da stets mit zu rechnen, bei höherer Klassifizierung ist das in meinen Augen kein routingrelevantes Problem, da es dort meist keine wesentlichen Alternativen zum Routen gibt - fahrzeittechnisch fällt das in meinen Augen nicht ins Gewicht.

Klar, wenn man in einer Straße steht und es kleinräumig betrachtet, dann fällt der Unterschied auf - frei oder beengt.
Aber wie ist das, wenn man es in der Gesamtheit des umgebenden Straßennetzes betrachtet:
Würde ein spezielles Tagging das Routing wirklich beeinflussen (können)?

Finde ich gut.

Schön wäre es. Für Deutschland könnten wir vielleicht einen solchen Kompromiss erreichen, weltweit aber nicht. Im größten Teil der Welt werden Fahrspuren selten markiert, das Tag lanes=* hat sich dort trotzdem etabliert als einfacher zu ermittelnde Alternative zu 'width='*. Das bekommen wir nicht wieder weg.

Die Frage ist, wie wir dem Router mitgeben, dass diese Straßen (meistens) sehr schmal sind.

Viele Router werten wohl ‘lanes=1’ aus und “bestrafen” diese Straßen beim Routen. Besser wäre es, wenn sie vorrangig 'width='* auswerten, so vorhanden.

Würde beides von Bordstein zu Bordstein gemessen so würde bei nahezu allen Wohnstraßen davon ausgegangen, dass man sich nicht begegnen kann, wenn gleichzeitig die Standard-Annahme gilt, dass bei Wohnstraßen beideitig geparkt wird. Das wird in einem großen Teil der Straßen nicht stimmen.

Drum nehme ich bislang an Straßen, wo nahezu immer geparkt wird, für 'width='* den Abstand zwischen den Autos, z.B. hier im Gründerzeitviertel. Aber ja, das Auslegungssache und damit problematisch.

Der Tag lane_markings=no ist bei mir obligatorisch, wenn es bei >3,5m Breite keine Mittelllinie gibt.

Ich denke auch, dass bei einem Fahrstreifen endweder baulich (Pflaster, Einbuchtungen, o.ä.) oder mittels Markierung kenntlich gemacht sein sollte, dass der Bereich der Straße vorrangig zum Parken vorgesehen ist.

Ohne Markierung ist es eine nicht markierte Multifunktionsspur und kein dem Parken zugewiesener Bereich.

Zum Glück.

Ich fnde subjektive lanes besser als “objektive” width. Bei lanes (in OSM) hat sich schon mal jemand Gedanken gemacht, width hingegen ist für einen Auswerter viel fehleranfälliger.

Beispiel für width: https://stadt.weimar.de/fileadmin/redaktion/processed/2/c/csm_05-Visualisierung-DNT_332c25b413.jpg (in Planung/Bau). keine Ahnung, wie das mal gemappt werden wird/kann aber width sagt hier genau überhaupt nix.

Das verstehe ich nicht. Subjektiv heißt, jeder kann es anders machen und der es auawertet weiß nicht wie der Mapper es gedacht hat. Objektiv heißt, wir haben zahlen-daten-fakten und keine persönlichen Interpretationen. Wenn ich weiß, dass mein Auto 2m breit ist, dann kann ich anhand von width ausrechnen, ob ich mit meinen Auto Gegenverkehr abwarten muss oder nicht. Geht mit lanes nicht.