Open tordans opened 2 years ago
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_carriageway
wird berücksichtigt und für dieses Segment nur die Hälfte des Wertes benutztlength_wo_dual_carriageway
wird zum Vergleich berechnetadmin_level = 9
, kann aber auch für andere level erzeugt werdenZur 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):
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.
Ziel & Daten:
Ich würde gerne aus den unseren Daten Zahlen generieren, die wir auf einer Art Dashboard darstellen können:
(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…