Weitere einzubeziehende Daten zur Verbesserung des Ergebnisses

[tordans]

Es gibt weiter Daten, die wir berücksichtigen sollten, um die Präzision der Auswertung zu erhöhen: Edit @SupaplexOSM: Priorisierung nach Häufigkeit/Einfluss auf das Gesamtergebnis (meiner bisherigen Erfahrung nach)

---

leicht umsetzbar, da nach Schema "Fahrradständer"

(siehe auch #40)

• [x] Parklets leisure=parklet oder leisure=outdoor_seating + outdoor_seating=parklet (Beispiel)

• [x] area:highway=prohibited (Beispiel)

• [x] amenity=bicycle_rental + bicycle_rental:position=lane/street_side (Beispiel)

• [x] Motorradstellplätze: amenity=motorcycle_parking + entweder motorcycle_parking:position=lane/street_side oder parking=lane/street_side (Beispiel)

• [x] Stellplätze für Elektrokleinstfahrzeuge: amenity=small_electric_vehicle_parking + small_electric_vehicle_parking:position=lane/street_side (Beispiel).

• [x] Transportüberwege der BSR: amenity=loading_ramp + operator=Berliner Stadtreinigung (Neues Tagging!)

• [x] Alle diese Objekte, insbesondere Fahrradständer, auch mit *:position=shoulder und *:position=kerb_extension ausstanzen (ergänzend zu lane und street_side), da sie indirekt eine bessere Repräsentation von Gehwegvorstreckungen ermöglichen (Beispiel kerb_extension, Beispiel shoulder)

---

sehr relevant

• [x] highway=crossing + crossing:kerb_extension sowie crossing:buffer_marking werden noch nicht ausgestanzt (Gehwegvorstreckungen und randseitige Markierungen an Kreuzungen) (Beispiel OSM | Beispiel VectorTiles)

---

eher relevant

• [x] Ausstanzen von Objekten/Straßenmöbeln im Parkstreifenbereich, insbesondere bei Gehwegparken (obstacle:parking=yes) - im street parking-Script gibt es dafür default-Puffergrößen für verschiedene Objektarten wie Straßenbäume oder Laternen

• [ ] An einer Straße mit einem highway=turning_circle könnte man 10-12 Meter um den Wendekreis wegschneiden, rund um highway=turning_loop noch ein bisschen mehr (15-20 Meter?)

• [ ] Einbezug separat gemappter einzelner Stellplätze wie einzeln markierte Stellplätze für mobilitätseingeschränkte Personen (Beispiel) oder Doppelstellplätze vor Ladesäulen (capacity von Ladesäulen bzw. deren Node als Indikator nehmen? Oder separate Stellplatznodes mappen?). Ist auch noch nicht im Python-Script, aber ich stelle mir das so vor, dass die Stellplatz-Nodes gepuffert werden (Behindertenparkplätze sind btw. etwas länger), die Segmente innerhalb des Puffers die Eigenschaften der Nodes übertragen bekommen und die Reststücke so bleiben wie sie waren.

Ähnlich wie Einfahrten sollten außerdem folgende Wege aller Art (auch path, footway etc.) pauschal aus den Daten ausgestanzt werden, da man davon ausgehen kann, dass sie baulich in eine Straße münden:

• [ ] Wege mit emergency=designated oder emergency=yes

• [ ] Wege mit motor_vehicle-access ("motor_vehicle" & "motor_vehicle" != 'no', z.B. Wege mit motor_vehicle=private, die nur unter bestimmten Umständen mit Fahrzeugen befahren werden dürfen und normalerweise Fußwege o.ä. sind - Beispiel: (OSM) (VectorTiles)

• [ ] Parkstreifen, die sich längerfristig in einem Baustellenbereich befinden - also im Allgemeinen vorhanden sind, aber aktuell nicht verfügbar sind (construction:parking:<side>=*)

---

zur Zeit eher nice to have

• [ ] Bahnübergänge freihalten (laut StVo innerorts 5 Meter vor und hinter einem Andreaskreuz)

• [ ] In einzelnen Fällen gibt es Parkstreifen, die nur für Busse oder Lkw freigegeben sind. Da wäre es praktisch, nicht die Autolänge, sondern eine Bus- oder Lkw-Länge für die capacity heranzuziehen. Im Python-Script gibt es bereits eine Variable für eine Bus- oder Lkw-Länge (12 bzw. 16 Meter) und in der Parkraumkarte gibt es auf diese Weise manuell bearbeitete Segmente (Busbeispiel), automatisch einbezogen wird es aber noch nirgends.

• [ ] highway=traffic_sign + traffic_sign=DE:224 wie eine Bushaltestelle mit Pufferkreis von 15 Metern behandeln (Beispiel)

• [ ] opening_hours an (Nachtbus-)Bushaltestellen berücksichtigen (siehe Diskussion)

---

Relevanz prüfen/diskutieren

• [ ] abgesenkte Bordsteine (barrier=kerb + kerb=lowered) - als Linie (an die Parkstreifen snappen und in ihrer Länge ausstanzen) oder Punkt (einen Puffer annehmen, entweder wie bei Einfahrten default 4 Meter oder entsprechend der Breite des schneidenden Weges?)

• [ ] Verkehrsberuhigende Maßnahmen, die baulich das Parken verhindern (z.B. Verengungen)

---

Done

• [x] gemappte parking lanes an Wegen, die nicht zum allgemeinen Straßennetz gehören (insbes. an highway=service, aber auch anderen highways). Beispiel (siehe Kontast zur Parkraumkarte)

• [x] Bus-/Tramhaltestellen – entweder über die Länge der Linie public_transport=platform (Beispiel) oder über Standard-Werte (15 m) ausgehend von der Node highway=bus_stop (Beispiel); dabei müssen wir links/rechts berücksichtigen

• [x] Flächen amenity=bicycle_parking + bicycle_parking:position=lane (Beispiel); dabei müssen wir links/rechts berücksichtigen

• [x] BSR-Laderampen @supaplexosm

  Ich berücksichtige in dem "handkuratierten" Parkstreifenlayer der Straßenraumkarte seit kurzem diese BSR-Laderampen (zur Zeit erkennbar an "ramp=yes" + "operator=BSR"). Dafür füge ich eine Lücke von 2,8 Metern in den Parkstreifen ein (2 Meter Breite der Rampe + 40cm auf jeder Seite Puffer). Siehe z.B. hier: https://supaplexosm.github.io/strassenraumkarte-neukoelln/?map=micromap#20/52.47228/13.45086 Achtung: Tagging hat sich geändert von ramp=yes + operator=BSR zu amenity=loading_ramp + operator=Berliner Stadtreinigung! (Stand 05.01.2023)

[gislars]

Flächen mit landuse=residential (im Screenshot blau) sind nicht nützlich hier. Ich war neugierig ob die Gehwegvorstreckungen zum Verschneiden der Parklanes (orange) benutzt werden können. Aber durch die Offsetberechnung kann die Parklane vollständig in der landuse-Fläche liegen.

[joshinils]

wenn denn die public_transport=platform linien korekt gemappt sind. alle die ich in frohnau und umgebung gesehen hab, waren falsch platziert und/oder zu lang. es wäre also besser nur die stop_position oder bus_stop zu nehmen und mit den 30m auszustanzen. wenn denn auch eine längere markierung durch Zeichen 299 existiert, kann und sollte man das doch separat mappen.

[gislars]

parklet gibt es weltweit ca. 3, deswegen berücksichtige ich den Fall gerade nicht. Im Fall der Bergmannstraße gäbe es auch nichts auszustanzen.

[SupaplexOSM]

parklet gibt es weltweit ca. 3, deswegen berücksichtige ich den Fall gerade nicht. Im Fall der Bergmannstraße gäbe es auch nichts auszustanzen.

Es sind 3 in Berlin (leisure=parklet oder leisure=outdoor_seating + outdoor_seating=parklet) - und es werden bestimmt bald mehr :) Sollten wir also mit aufnehmen.

[SupaplexOSM]

• [ ] abgesenkte Bordsteine (barrier=kerb + kerb=lowered) - als Linie (an die Parkstreifen snappen und in ihrer Länge ausstanzen) oder Punkt (einen Puffer annehmen, entweder wie bei Einfahrten default 4 Meter oder entsprechend der Breite des schneidenden Weges?)

[tordans]

@SupaplexOSM du müsstest die Rechte haben den initialen Kommentar zu editieren. Ich habe das gemacht und blende die beiden letzten Kommentare der Übersichtlichkeit halber gleich aus.

[tordans]

Parkets: FYI, ich habe gerade zwei Parklets in Xhain gemapped. Ich weiß von anderen, die vermutlich auch fehlen. Letztes Jahr gab es eine Förderung dafür: https://www.berlin.de/ba-friedrichshain-kreuzberg/aktuelles/pressemitteilungen/2021/pressemitteilung.1106584.php + https://www.berlin.de/parklets/ — Ich habe bei den Kontaktadressen OpenData zu den Standorten angefragt.

[SupaplexOSM]

FYI: Diskussion am oben genannten CS über die Unterscheidung zwischen leisure=parklet und leisure=outdoor_seating + outdoor_seating=parklet.

[SupaplexOSM]

FYI: Einbezug separat gemappter einzelner Stellplätze in der Liste ergänzt.

[SupaplexOSM]

Bushaltestellen sind zwar abgehakt, zur Zeit aber nicht in der Karte erkennbar (z.B. nördliche Seite der Saalestraße, Harzer Straße). Habe den Haken daher erstmal wieder entfernt.

[joshinils]

Bus-/Tramhaltestellen – entweder über die Länge der Linie public_transport=platform (Beispiel) oder über Standard-Werte (15 m) ausgehend von der Node highway=bus_stop (Beispiel); dabei müssen wir links/rechts berücksichtigen

was ist, wenn eine haltestelle mehrere schilder hat, was zu einer verlängerung des halteverbnots führt? sind diese schilder mappbar und/oder nur über die platform?

[gislars]

Im Moment werden nur highway=bus_stop und railway=tram_stop berücksichtigt. Für beide wird dann ein 15m Segment erzeugt. Wenn die sich überlappen, verlängert siech der Gesamtbereich. Beispiel Milastraße / OSM

Das funktioniert auch bei nur Bus/Tram wie z.B. am Hermannplatz:

[joshinils]

hm, also wäre es doch nciht schlecht, wenn man entweder

• weitere haltestellenschilder mappt oder aber
• die platform verlängert mappt und hier auch berücksichtigt

[gislars]

Ja Haltestellenschilder sind gut. Insgesamt habe ich in Berlin 859 railway=tram_stop und 6351 highway=bus_stop gefunden.

[gislars]

highway=service habe ich hinzugefügt.

  parking IN ('lane', 'street_side')
  AND service IS DISTINCT FROM 'parking_aisle'
  AND (parking_lane_left|right IN ('diagonal', 'marked', 'parallel', 'perpendicular', 'separate', 'yes')

[SupaplexOSM]

hm, also wäre es doch nciht schlecht, wenn man entweder

* weitere haltestellenschilder mappt oder aber

* die platform verlängert mappt und hier auch berücksichtigt

Bei mir in Neukölln waren Bushaltestellen mit mehreren Schildern stets so gemappt (nicht von mir), das jedes Schild seinen eigenen Knoten hat, auch wenn kein eigener Fahrplan dran hängt oder es um separate End-Haltestellen geht. Ich kenne aber die ÖPNV-Mapping-Diskurse dazu nicht, weiß also nicht, ob das gängige oder gute Praxis ist. (Habe gesehen, dass du es in der DE:Telegram-Gruppe angesprochen hast.)

Es kann eigentlich nicht schaden, die Platformen zusätzlich mit abzuziehen, oder? Also so dass sie zwar nicht den 15-Meter-Radius bestimmen, aber bei fehlenden Nodes für einzelne Bushaltestellenschilder wenigstens eine Lücke mit der Länge der Platform entsteht. Vor einer Platform dürfte ja ohnehin nicht gehalten werden.

Da fällt mir ein: Bei Nachtbus-Haltestellen müsste man nochmal schauen, wie man die identifizieren kann, da dort ja tagsüber geparkt werden kann...

[joshinils]

ich wüsste nicht, dass der fahrplan der buslinie einen einfluss auf die wirksamkeit von zeichen 224 hätte, wenn dann müsste darunter ein entsprechendes zusatzzeichen hängen, hab ich aber noch nie gesehen. zb. 224-51 : sieht sowas vor. wie man das taggt - keine ahnung

[SupaplexOSM]

Das ist bei den Nachtbushaltestellen, die ich meine, auch so: Da steht irgendwas wie "23-7 Uhr" oder so unter dem H-Kreis. Kann gerade kein Beispiel suchen - gibt es auch nur selten. Das ist nicht StVO-normiert, vermute ich, aber es ist quasi mindestens "permissive", da zu parken.

[joshinils]

ich würde das dann so wie hier besprochen; https://github.com/orgs/OSM-de/discussions/2

einfach mit opening_hours taggen, ist die haltestelle "zu" kann man da parken

[SupaplexOSM]

Ah, interessant. Ja, warum nicht mit opening_hours arbeiten... Hier ist ein Fall, an dem ich neulich vorbeikam - in diesem Fall zwar nicht parkplatzrelevant, da ohnehin kein Parkstreifen besteht, aber ich habe mal opening_hours getaggt.

Für die Parkraumanalyse bedeutet das mMn: Hat eine Bushaltestelle ein opening_hours getaggt, wird der ausgestanzte Haltestellenbereich nicht mit einem generellen Halteverbot versehen, sondern mit einem *:conditional=no_stopping @ ($opening_hours).

[SupaplexOSM]

Ich habe die verschiedenen Möglichkeiten der "Datenverbesserung" mal etwas nach Relevanz sortiert. Einige dürften leicht umsetzbar sein, da sie von der Stanzung der genau wie die Fahrradständer im Fahrbahnbereich funktionieren. Einzelne Punkte dürften erstmal nicht so wichtig sein, andere müssten wir bei Gelegenheit nochmal diskutieren bzw. prüfen.

[SupaplexOSM]

@tordans hast du bei area:highway=prohibited den Hinweis "dabei müssen wir links/rechts berücksichtigen" ergänzt? Was bedeutet das genau bzw. inwiefern unterscheidet sich das von anderen Stanzungen dieser Art, z.B. Fahrradständern?

[SupaplexOSM]

Gelegentlich werden nun reine Motorrad-Stellplätze auf der Fahrbahn errichtet - diese habe ich oben in der Liste ergänzt, es stellt sich für später aber auch die Frage, wie wir diese in der Darstellung und ggf. in Analysen einbeziehen (denn es sind ja Kfz).

[joshinils]

Gelegentlich werden nun reine Motorrad-Stellplätze auf der Fahrbahn errichtet - diese habe ich oben in der Liste ergänzt, es stellt sich für später aber auch die Frage, wie wir diese in der Darstellung und ggf. in Analysen einbeziehen (denn es sind ja Kfz).

aber sie nehmen deutlich weniger platz weg und es passen halt mehr auf denselben stellplatz eines einzigen pkw.

genauso wäre es bestimmt erlaubt in engen straßen, wo platztechnisch nur auf einer seite geparkt werden kann mit pkw, motorräder oder roller auf beiden seiten parallel zu parken.

ich würde fast behaupten eine auswertung für motorräder allein macht mehr sinn, und natürlich bekommt man viel mehr stellplätze dabei.

andersrum macht es natürlich sinn diese gesondert anzuzeigen, wenn nur motorräder igendwo parken können/dürfen. denn pkw können dort nicht parken.

ich glaube eine betrachtung von nur pkw macht mehr sinn, ich hab jedenfalls noch nicht von motorradfahrern gehört, dass sie keinen parkplatz finden. im notfall stellt man das teil einfach auch auf dem bürgersteig ab, wie fahrräder auch...

und LKW sind ein ganz anderes thema, die meisten buchten zb sind einfach zu kurz um da mit einem lkw zu parken, und vielleicht auch für das gewicht gar nicht ausgelegt.

fazit: alle parkmöglichkeiten anzeigen, nur die für pkw nutzbaren betrachten in berechnungen.

[SupaplexOSM]

Genau, in den Berechnungen sollten wir im Allgemeinen nur von Pkw ausgehen - aber auf Flächen mit besonderen Fahrzeugbeschränkungen (z.B. auch seltene Bus- oder Lkw-Parkstreifen) müssen wir irgendwann überlegen, wie wir damit umgehen. Fürs erste würde ich es bei einem spezifischen Rendering belassen. Selbst in Analysen, die Kfz-Statistiken einbeziehen, ist die Beschränkung auf Pkw ok, da sich die 20% nicht-Pkw in der Kfz-Statistik zumindest in Berlin zu etwa gleichen Teilen auf Lkw/Transporter (länger) und Motorräder (kürzer) aufteilen - also im Mittel könnte man argumentieren, kommt etwa das gleiche raus.

[gislars]

• parklets
• area:highway=prohibited (Beispiel)
• amenity=bicycle_rental + bicycle_rental:position=lane/street_side (Beispiel)
• amenity=motorcycle_parking + entweder motorcycle_parking:position=lane/street_side oder parking=lane/street_side (Beispiel)
• amenity=small_electric_vehicle_parking + small_electric_vehicle_parking:position=lane/street_side (Beispiel).
• amenity=loading_ramp + operator=Berliner Stadtreinigung (Neues Tagging!)
• bicycle_parking:position kerb_extension

[gislars]

die obstacle sind auch enthalten, da muss ich aber noch eine Anpassung machen. Die müssen auf die parking_lane gesnappt werden, sonst kann von dieser auch nicht ausgeschnitten werden.