Make calculating parking spots numbers per street even more precise by using the street width to estimate the parking direction

[tifa365]

By using the width of each street, one could narrow down which typ of parking is most likely used in that street. By knowing the parking type, the calculated number of cars could be even closer to reality. For a smaller street, for example, angular or perpendicular parking is much less likely (or even impossible) than parallel parking.

I would propose to check for street width as such:

1. Check whether the parking direction on one or both sides is already in the OpenStreetMap-data. (Done.)
2. If either parking direction or both are missing, check whether the street width of either can be taken from OpenstreetMap attribute width=*directly.
3. By knowing the overall street width and perhaps on or both parking directions, one could estimate the type of parking based on the already known size estimates of parking cars, using the most likely parking direction.
4. If the street width isn't in the data, it can be calculated with mathematical or geographical methods. This can be done for all cities world wide as long as the polygon data of the street is already availabe. For Berlin, I've already calculated that kind of data already, by street id. https://we.tl/t-HRHaKFCIiC
5. Estimate the type of parking based on the already known size estimates of parking cars and the legal parking distance.

I'm sure I am missing out on many details but this could be a start.

This could be further improved by calculating overall percentages of parallel/perpendicular/angle parking in a neighborhood and estimating the most likely type. Also I can imagine using neighbored streets of the same type/width to estimate the parking type.

The method of calculating street width by (street) polygons is written in Python. I could clean the data and share the notebook here if there's interest in doing this for other cities as well or have a second look at the Berlin data.

[SupaplexOSM]

Ich habe auch schon darüber nachgedacht, ob so eine Form der Interpolation grundsätzlich fehlender Daten sinnvoll oder zielführend ist. Auf jeden Fall wären sie sehr ungenau und sollten klar als ungenaue Daten erkennbar sein (wir planen einen Qualitäts-Layer, der soetwas vermitteln könnte). Am besten werden sie nur optional angezeigt und fehlende parking-lane-Attribute ansonsten als fehlende Daten markiert und ignoriert.

Ich würde außerdem dafür plädieren, alle Interpolationen auf reiner OSM-Basis zu machen, also ohne Einbezug externer Daten. Das wäre dann ungenauer, aber wir reden hier sowieso über eine extreme Ungenauigkeit. Dafür könnte man default-Straßenbreiten auf Basis von highway- und lane-Tags annehmen. Das Ganze ist aber mMn nice to have und wir müssten nochmal ganz genau ansehen, welches Genauigkeitsniveau sich damit überhaupt erreichen lässt (was sind denn eure Erfahrungen aus dem Parkplatzdaten-Hackathon?) und ob uns das für dieses Projekt ausreicht.

[tifa365]

Da genaue Daten zu haben ist glaube ich nicht möglich. Momentan (ohne Fremddaten) ist die Parkposition ja auch schon eine Schätzung, bzw. ein Fallback. Ich hab noch nicht genau geschaut wie das bisher berechnet wird, wenn keine OSM-Daten vorliegen. Wird paralleles Parken angenommen oder ein Durchschnitt der Parkarten?

Ich habe bisher nur einige Stichproben genommen, die relativ nah an den OSM-Daten waren. Die Berlin-Daten mussten dazu zunächst mit den OSM-Daten verschnitten werden. Ich glaube selbst bei Abweichungen von einem Meter könnte man vermutlich noch gut schätzen, welche Parkposition vorliegen könnte. Gibt es sonst Ideen, wie wir das überprüfen könnten? Das einfach mal testweise für Neukölln zu machen und zu schauen wie sich die Daten ändern, fände ich schon einen Versuch wert.

Um es nochmal anders zu sagen: Die Breite zu schätzen sollte definitv im Qualitäts-Layer transparent gemacht werden. Ich frage mich nur selbst wenn die Abweichungen größer wären, fragt sich, ob das für die Parkposition eine größere Rolle spielen würde. Das müsste man mal durchspielen.

[SupaplexOSM]

Vielleicht reden wir aneinander vorbei ;) Aber wenn keine (OSM-)Daten zu Parkstreifen vorliegen, dann tauchen sie in der Karte auch nicht auf. Um das Tool zu nutzen, ist es also eine Vorraussetzung, Parkraumdaten in OSM zu erfassen (egal ob grob oder detailliert).

Bei dem Schätzen fehlender Daten gibt es so viele Ungenauigkeitsfaktoren, dass ich bei genauerem drüber nachdenken wirklich nicht weiß ob das realistisch ist. Also was man natürlich immer machen kann: Überall parallel-Parken annehmen und dann mal sehen, wie "genau" das ist. Vielleicht an Hauptstraßen von einer 50% reduzierten Parkplatzzahl ausgehen.

Aber darüber hinaus... Um meine Zweifel mal zu illustrieren: In Berlin sind viele Wohnstraßen 11 Meter breit - hat vermutlich Hobrecht vor 150 Jahren so beschlossen :) Auch im Neuköllner Schillerkiez und im Körnerkiez sind die meisten Straßen 11 Meter breit. Aber im Schillerkiez gibt es sehr oft auf diesen 11 Metern eine Schrägpark-Seite, im Körnerkiez nicht. Wohl abhängig vom Durchgangsverkehr... Das man ansonsten Anzahl und Art von Fahrstreifen, Radwegen etc. mit in die Interpolation einbeziehen müsste, noch gar nicht mitbedacht...

[tordans]

By using the width of each street, one could narrow down which typ of parking is most likely used in that street. … Ich habe auch schon darüber nachgedacht, ob so eine Form der Interpolation grundsätzlich fehlender Daten sinnvoll oder zielführend ist. … Vielleicht reden wir aneinander vorbei ;) Aber wenn keine (OSM-)Daten zu Parkstreifen vorliegen, dann tauchen sie in der Karte auch nicht auf. Um das Tool zu nutzen, ist es also eine Vorraussetzung, Parkraumdaten in OSM zu erfassen (egal ob grob oder detailliert).

Danke, dass du das nochmal sichtbar machst: Wir müssen klarstellen, was das Ziel unseren Projektes ist.

Unser aktuelles Ziel: Dort, wo das parking:lane Schema verwendet wird, auf Basis eines "Subtraktiven Modells" Parkraumdaten berechnen. Mit einer Ziel Genauigkeit von %.

Zusätzlich Dinge, die dafür nötig sind, damit das möglich wird. Dazu gehört bspw. "Debug"-Kartenstile die zeigen, wo das parking:lane Schema noch fehlt.

Eine Bedingung für unsere Berechnung ist, dass wir die Park-Ausrichtung in OSM vorliegen haben (und einige andere Daten…).

Ein Follow-Up-Ziel könnte dann sein: Dort, wo kein parking:lane Schema existiert oder dort, wo die Park-Ausrichtung in OSM fehlt, trotzdem Daten interpolieren.

Diese Daten sollten wir dann aber sehr deutlich getrennt halten von den übrigen Daten. Denn ihre Genauigkeit und Aussagekraft ist eine ganz andere. Auch die "Prozesse", bspw. "da ist ein Fehler, wie behebe ich ihn?", sind für diese Daten ganz anders.

---

TODO:

• [ ] Projektziel und Nicht-Projektziel formulieren

[tifa365]

Bei dem Schätzen fehlender Daten gibt es so viele Ungenauigkeitsfaktoren, dass ich bei genauerem drüber nachdenken wirklich nicht weiß ob das realistisch ist. Also was man natürlich immer machen kann: Überall parallel-Parken annehmen und dann mal sehen, wie "genau" das ist. Vielleicht an Hauptstraßen von einer 50% reduzierten Parkplatzzahl ausgehen.

Wahrscheinlich läuft es ein bißchen auf die Gretchenfrage hinaus, ob geschätzte Werte immer noch besser sind als nicht vorliegende, was auch auf die Zielgruppe ankommt. Ich denke paralles Parken anzunehmen das könnte auch gute Ergebnisse liefern, aber wenn die Möglichkeit bestünde diese Annahmen mal stichprobenartig durchzurechnen, könnte man es vielleicht auf eine andere Basis legen, bzw. besser begründen. Das wäre durch die vorliegenden Straßenbreiten zumindest möglich.

Aber im Schillerkiez gibt es sehr oft auf diesen 11 Metern eine Schrägpark-Seite, im Körnerkiez nicht. Wohl abhängig vom Durchgangsverkehr... Das man ansonsten Anzahl und Art von Fahrstreifen, Radwegen etc. mit in die Interpolation einbeziehen müsste, noch gar nicht mitbedacht...

Das ist ein guter Punkt, ich glaube das werden immer Näherungswerte sein. Aber um es mal positiv zu sehen, mit den 11 Metern kann man Schrägparken und Parallparken vielleicht nicht unterscheiden, aber solange OSM-Daten für eine Straßenseite vorliegen, könnte man schon genauere "educated guesses" vornehmen. Könnte man nicht im ganz konkreten Fall einbeziehen, dass bei Schrägparken oft eine Parkbucht vorliegt?

Ich nehme mal mit, dass die Einbeziehung externer Daten noch nicht Teil des Projektziels ist, aber vielleicht in Zukunft ein Thema sein könnte.

[SupaplexOSM]

Der Fall, dass OSM-Daten nur für eine Seite vorliegen ist glaub ich eher vernachlässigbar. Bzw. wenn das so ist, dann kann man wahrscheinlich eher davon ausgehen, dass auf der anderen Seite nicht geparkt werden kann...

In den beiden genannten Kiezen tritt der Schrägparken übrigens erstaunlich oft ohne Parkbucht auf :)

Noch eine Eingebung, die aber sehr sehr weit über die Ziele und Möglichkeiten unseres Projektes hier hinausgeht: Würde man eine passende KI mit Straßennetzen füttern, könnte sie bestimmt lernen, wann wo wie geparkt werden kann ;)