Umgang mit CarSharing

[mathiasellpunkt]

Hallo in die Runde,

Wiesbaden freut sich in der Innenstadt über ein umfangreiches und weiter wachsendes CarSharing-Netz (stationär). In der Regel sind dafür in den normalen Straßenrandparkplätzen eins, zwei oder drei für den jeweiligen Anbieter reserviert.

Und obgleich es Sinn macht, CarSharing separat zu mappen, bin ich unsicher, wie man am besten mit dessen Auswirkungen auf den Parkraum umgeht (der ja rechnerisch sinkt). Wie handhabt ihr das?

1. Zählt ihr stationäre CarSharing-Plätze einfach dennoch zum regulären Parkraum, obwohl sie quasi exklusiv reserviert sind?
2. Klappt bei Carsharing-Flächen (analog zu Bäumen) auch einfach der "obstacle-parking = yes"-Tag?
3. Muss der restliche Parkraum dann separat gemappt werden (was ziemlich fummelig wäre)?

[tordans]

@mathiasellpunkt

In der Proof-Of-Concept Version der Prozessierung die du unter https://parkraum.osm-verkehrswende.org/project-prototype-neukoelln/?map=parkingmap#19/52.47781/13.43740 visualisiert sieht, werden Parkbeschränkungen bereits ausgewertet. Die Legende ist unter https://github.com/osmberlin/parkraum.osm-verkehrswende.org/tree/main/public/project-prototype-neukoelln/data#street_parking_linesgeojson .
Du kannst dieses Script in QGIS für deinen Bereich manuell laufen lassen.

In der Version die in der Datenbank prozessiert ist das noch nicht enthalten. Das Ticket dazu ist #80.

Ziel ist, das man diese Stellplätze auf drei Wege erfassen kann

• die Centerline zerschneiden und taggen – Nachteil: Zu viele kleine Linien-Stücke
• Separate Flächen; die Centerline ist dann "durchgehend" und ignoriert die Stellplätze. Die Prozessierung ignoriert dann die Daten der Centerline und übernimmt die der Fläche. Das ist der übliche Weg, den wir aktuell verwenden, bspw. https://www.openstreetmap.org/way/1198952905
• Separate Punkte. Analog zu den Flächen, aber mit den Daten als Punkt angegeben. Das ist häufig einfacher zu mappen. Ich bin aber nicht sicher, ob das in der Python Version supported ist. Für die Datenbank-Version ist es zumindest diskutiert, weil es auch für einzelne Behindertenparkplätze eine gute Methode wäre.

Wie du die Daten dann später summierst ist dir überlassen. Es kommt sehr auf den Anwendungsfall an.
Bspw. interessiert die Verwaltung häufig die Zahl der Parkstände für die sie direkt zuständig sind, das ist bspw. exklusive solcher wo die Straße operator_type=private ist. Aber für andere Betrachtungen will mit die Zahlen mit erfassen.

Das Summierungstool unter radverkehrsatlas kann diese Unterschiede noch nicht machen, da müsste man die Polygone manuell so markieren, dass die richtigen Punkte gezählt werden.

Klappt bei Carsharing-Flächen (analog zu Bäumen) auch einfach der "obstacle-parking = yes"-Tag?

Nein, kein "obstacle", sondern einfach nur anders getaggter Parkraum

Muss der restliche Parkraum dann separat gemappt werden (was ziemlich fummelig wäre)?

Zum Glück nicht, das konkretere Element gewinnt dann bei der Stanzung. Das wäre übrigens auch so, wenn du die Centerline als "parallelparken auf der Straße" taggst und dann Parkbuchten mit besonderen Attributen. Dann würde die Berechnung die Parkbuchten bevorzugen und nur für die Lücken das parallel parken anwenden.