osm-parking-processing
osm-parking-processing copied to clipboard
osmberlin
Dashboard/Layer: Datenvollständigkeit pro Bezirk
Ziel & Daten:
Ich würde gerne aus den unseren Daten Zahlen generieren, die wir auf einer Art Dashboard darstellen können:
- [x] Fortschritt: 80% von <Bezirk> (in km) sind gemapped
- [ ] Anzahl: <Bezirk> hat 10.000 Parkplätze
(Erstmal statisch, später dann dynamisch, vermutlich analog https://github.com/gislars/strassenraum-berlin/issues/12)
Ausblick:
Über den Jahreswechsel, können wir das dann erweitern … zB nach Zahlen pro LOR. Und die Zahlen in Subsegmenten nach Ausrichtung (Parallel, …) und Park-Ort (Gehweg, Straße, Parkbucht, …). Im Ausblick wären auch Listen pro Straße pro Bezirk interessant mit den Straßen mit den meisten/wenigsten Parkplätzen…
Ich habe den Layer boundaries_stats überarbeitet. Dort sind alle Bezirke enthalten und folgende Attribute:
| Attributname | Beschreibung |
|---|---|
| name | Name der administrativen Fläche |
| aera_sqkm | Flächeninhalt [km²] |
| street_side_km | Straßenkilometer mit street_side |
| lane_km | Straßenkilometer mit lane |
| d_other_km | Straßenkilometer ohne Parkinfos |
| sum_km | Summe Straßenkilometer |
| length_wo_dual_carriageway | Summe ohne Berücksichtigung dual_carriageway |
| geom | Geometry(Multipolygon, 4326) |
-
dual_carriagewaywird berücksichtigt und für dieses Segment nur die Hälfte des Wertes benutzt -
length_wo_dual_carriagewaywird zum Vergleich berechnet - im Moment nur
admin_level = 9, kann aber auch für andere level erzeugt werden - der Layer wird täglich aktualisiert
Zur besseren Übersicht hier einmal als Tabelle (Stand: 2022-07-15T20:21:51Z):
| id | name | aera_sqkm | street_side_km | lane_km | d_other_km | sum_km | length_ohne_dual |
|---|---|---|---|---|---|---|---|
| 1 | "Charlottenburg-Wilmersdorf" | 64.68 | 4.1 | 55.1 | 435.3 | 494.5 | 494.5 |
| 2 | "Friedrichshain-Kreuzberg" | 20.37 | 9.8 | 151.0 | 36.2 | 197.0 | 227.7 |
| 3 | "Lichtenberg" | 52.14 | 5.0 | 68.0 | 298.6 | 371.6 | 386.4 |
| 4 | "Marzahn-Hellersdorf" | 61.83 | 1.4 | 7.3 | 580.1 | 588.8 | 594.9 |
| 5 | "Mitte" | 39.39 | 2.9 | 37.8 | 352.2 | 392.9 | 403.8 |
| 6 | "Neukölln" | 44.95 | 4.4 | 116.8 | 263.9 | 385.1 | 403.3 |
| 7 | "Pankow" | 103.22 | 1.0 | 70.6 | 580.6 | 652.2 | 662.3 |
| 8 | "Reinickendorf" | 89.34 | 0.5 | 6.3 | 539.5 | 546.3 | 546.2 |
| 9 | "Spandau" | 91.87 | 0 | 5.9 | 470.5 | 476.4 | 476.4 |
| 10 | "Steglitz-Zehlendorf" | 102.57 | 0 | 7.4 | 663.1 | 670.5 | 670.5 |
| 11 | "Tempelhof-Schöneberg" | 53.06 | 0.4 | 17.8 | 442.5 | 460.7 | 480.4 |
| 12 | "Treptow-Köpenick" | 167.72 | 3.8 | 143.2 | 543.3 | 690.3 | 702.8 |
Cool! Kann man den Flächen im Styling ein Label geben? Dann könnten wir eine Spalte "parking_km_share" oder so ergänzen mit der Prozentangabe der gemappten Parkstreifen >> "street_side_km" + "lane_km") / "sum_km" * 100 und diese als Label benutzen.
Der Layer muss auf unserer Seite eingebunden werden und dort kann man dann einen Stil anwenden, gleiches Schema wie bei den parking_segments. Auf der Demo-Seite kann ich keinen Stil angeben bzw. ich weiß nicht wie :)
Eine Spalte done_percent habe ich noch hinzugefügt. Jetzt müssen wir das nur noch visualisiert bekommen.
ich schlage vor das als farbskala anzuzeigen wenn man raus-zoomt, anstelle der anderen daten. auch weil diese dann ja offenbar nicht mehr richtig angezeigt werden können.
da es aber verschiedene zahlen und skalen sind, vielleicht doch lieber mit einem anderen overlay und text? ich mag das bei der parkraumkarte neuköln von zoom 16 und 15, aber frage mich, ob man das nicht optional halten will.
Um mal devil's advocate zu spielen: Ich weiß nicht, ob eine Karte immer die beste Wahl ist, um Daten anzuzeigen. Man muss sich ja fragen, was man mit dem jeweiligen Layer erreichen/sagen will. Wenn ich mir einen schnellen Überblick über die Bezirke verschaffen möchte, sehe ich mir lieber schnell die obige Tabelle an als mit der Maus über alle Bezirke zu fahren. Und die eigentlichen Grenzen der Bezirke werden ja auch in den anderen Layern recht klar. Wenn man das grafisch aufbereiten und als Choropleth darstellen möchte, müßte man aber fast jede der Kategorien über ein Drowndown auswählbar machen (aber auch hier: Wozu, wenn man das fixer in der (sortierbaren?) Tabelle sieht). Ich finde da eine Tabelle besser geeignet.
Was ich wirklich sinnvoll wäre, wäre ein eigener Layer für Completeness + vielleicht die Legende im anderen Layer der Gesamtzahl an Parkplätzen, wie viele pro Bezirk bereits gemappt sind - also wie man die Parkplatzgesamtzahl in Bezug auf die Vollständigkeit interpretiern muss. Das Ändern der Darstellung durch Rauszoomen ist eine coole Funktion, aber ich fand es auch recht ungewöhnlich. Ich denke die Nutzer sind es gewohnt, dass die Daten-Darstellung innerhalb eines Layers kohärent bleibt.
Ich denke auch, so ein "Dashboard" bietet sich tabellarisch/als Rangliste an, so hat es @gislars auch schon erstellt. Gerade bei kleineren räumlichen Ebenen (Ortsteile, LOR) finde ich eine einfache kartographische Darstellung aber auch super, um zu "sehen", wo sich in Berlin schon etwas tut - auch als Gamification-Element ;) ("ich will meinen Bezirk 'grün' machen")
Ich teile hier mal beispielhaft zwei Grafiken von @gislars dazu:
Die zoomstufenabhängigen Änderung der Datenebenen in der Neuköllner Parkraumkarte sind ursprünglich aus der Not geboren, dass ich unterschiedliche Dinge in einer Raster-Tiles-Karte darstellen wollte, ohne technisches Hintergrundwissen z.B. zum Einsatz von Layern etc. - aber eigentlich funktioniert es erstaunlich gut. Für dieses Projekt hier wäre es aber perspektivisch wohl besser, wenn die Daten innerhalb eines Layers in verschiedenen Zoomstufen gleich oder zumindest ähnlich bleiben (z.B. nur aggregiert werden, aber die selben Daten dargestellt werden).
In der Vergangenheit haben wir, soweit ich mich erinnere, bereits über eine Auswahlmöglichkeit verschiedener Layer geredet, und zwar in etwa die Folgenden (etwas offtopic - wenn es soweit ist/bei Bedarf evtl. woanders strukturiert sammeln/diskutieren):
- der "Standard-Layer" mit Parkstreifenzahlen, in großen Zoomstufen evtl. kombiniert mit einer symbolischen Darstellung von Einzelfahrzeugen (ähnlich Z18 in der Neuköllner Parkraumkarte, vgl. #37, #38)
- ein "Debug-Layer", der die Parkstreifensegmente, aber auch durch das Script generierte Pufferbereiche etc. anzeigt, um besser nachvollziehen zu können, wie aus den OSM-Daten die finalen Daten entstehen
- ein "Datenvollständigkeits-Layer", wozu einerseits das hier diskutierte Dashboard/eine darauf aufbauende Kartendarstellung gehören könnte, oder auch eine Darstellung, die fehlende/fehlerhafte Straßensegmente darstellt (ich hab mir gestern sowas in QGIS gebaut, um in Friedrichshain-Kreuzberg gezielt zu vervollständigen:
- nice to have/experimentell: ein "Datenqualitätslayer", der durch Daten-Voodoo versucht zu interpolieren/visualisieren, wo die Daten bereits eine hohe, und wo eher eine niedrige Qualität aufweisen (z.B. könnten Kriterien wie "unterdurchschnittlich viele Einfahrten pro km²", "wenig gemappte crossings" oder "überdurchschnittlich lange Straßensegmente ohne Parkstreifenwechsel" auf eher schlechte Daten hinweisen)
Update: Eine super simple Version gibt es jetzt unter https://parkraum.osm-verkehrswende.org/project-vector-tiles/dashboard. Für alle weitere muss ich aber erstmal das Framework ändern; Aufwand-Nutzen wird zu schlecht im aktuellen Setup.