search

osmberlin / osm-parking-processing

Processing pipeline to generate data on public parking from OpenStreetMap-Data.
https://parkraum.osm-verkehrswende.org/project-vector-tiles/
GNU Affero General Public License v3.0
17 stars 2 forks source link

Update Vector Tiles Style (and add Legend) #16

Closed joshinils closed 1 year ago

tordans commented 2 years ago

Yes, the style for the vector tiles map is still a big TODO. We want to make it a lot nicer (soonisch). Will add a legend after that…

SupaplexOSM commented 2 years ago

Im Idealfall sollte das Styling mMn am Ende Aussagen zu folgenden Parkraum-Eigenschaften erlauben:

tordans commented 2 years ago

Testdaten, um in Mapbox Studio (oder ähnlich) einen Style zu entwickeln https://github.com/gislars/strassenraum-berlin/tree/wip/testdata

tordans commented 2 years ago

Ich vermute, es wird einfacher, erstmal mehrere Stile zu haben:

a. "Hier muss noch gemapped werden"

Gibt es noch Szenarien mit fehlenden Teil-Daten?

b. Parkraum-Daten (Haupt Stil)

Aussage: Haupt Stil um die Daten zum Parken zu betrachten.

c. Bedingungen fürs Parken

Aussage: Hier darf man parken… aber nur bestimmte Nutzer oder nur zu bestimmten Zeiten.

Hier wird es sehr schnell sehr kompliziert, da hier auch zeitliche Faktoren rein kommen. Das Zlant-Tool https://tordans.github.io/parking-lanes/#17/52.47906/13.42876 hat daher oben rechts die Datums-Auswahl. Je nach Tages-Zeit (und Tag) ändern sich dann die Farben auf der Karte (falls dort zeitliche Regeln definiert sind).

Ich würde gerne erstmal auf so eine Auswahl verzichten. Aber dann müsste man Zeitliche Regeln irgendwie mit Label(?) oder Icon(?) oder … anzeigen in der Karte.

d. Debug-Karte "So hat das Script gearbeitet"

Aussage: Erklären/zeigen, welche Stanzungen (oder "Subtraktionen") das Modell vorgenommen hat.

SupaplexOSM commented 2 years ago

Die capacity (a.) sollte kein Kriterium sein, denn diese berechnen wir ja und sie sollte nicht explizit gemappt werden (außer z.B. bei markierten Parkständen oder Spezialfällen, in denen sie sich klar ergibt). "Fehlende Daten" sind also in erster Linie fehlende parking-lane-Attribute. Zum Glück ist das OSM-Tagging-Schema so aufgebaut, dass die Ausrichtung bereits das Primärattribut ist, es gibt also üblicherweise nicht den Fall, dass wir wissen, dass es einen Parkstreifen gibt, aber seine Ausrichtung nicht kennen.

b. Agreed.

c. Fürs erste könnten wir uns hier an den Kategorien orientieren, die die Kreuzberger in ihren Daten haben. Es sollte mMn [noch nicht tiefer durchdacht] 3 klar unterscheidbare Hauptfarben geben: Eine für "free", eine für "wenn du bereit bist zu zahlen" und eine für "nur für spezielle Nutzer:innengruppen".

Weitere Beschränkungen, insbesondere temporäre Parkverbote, könnten mit ähnlichen, nur im Kontrast abgestuften Farben dargestellt werden. z.B. dunkelblau = free, etwas helleres dunkelblau = free, außer von 9-15 Uhr.

Ich fände am Ende einen Tag-/Nacht-Schalter genial, also dass man sich die Situation am Tag (z.B. 10 Uhr) und bei Nacht (3 Uhr) anzeigen lassen kann. Denn wenn es temporäre Beschränkungen gibt, gelten die ja üblicherweise tagsüber und nachts stehen erheblich mehr Parkplätze zur Verfügung. Das wäre dann auch beim bilden von Summen relevant. Default sollte die Nacht-Situation sein (also das "größte für Anwohnende zur Verfügung stehende Angebot").

d. Agreed.

joshinils commented 2 years ago

da ich hier, und an anderen s-bhf nähe brandenburg-grenze, eine große parkzone habe könnte man das auch noch beachten, dazu könnte man auch die straßen einfärben welche die zone darstellen. problem ist nur, dass die zone nicht als zone gemappt ist, sondern nur mit den daraus resultierenden eigenschaften. bei mir in forhnau sind das:

parking:condition:both = free parking:condition:both:conditional = disc @ (Mo-Fr 08:00-20:00, Sa 08:00-14:00) parking:condition:both:maxstay:conditional = 3 hours @ (Mo-Fr 08:00-20:00, Sa 08:00-14:00)

SupaplexOSM commented 2 years ago

Parkzonen könnten mit einer unauffälligen Hintergrundfarbe markiert werden. Ich verstehe darunter vor allem das Tagging für Anwohnerparkzonen (parking:condition:side:residents=$zone), es gibt aber auch noch (selten) allgemeine Parkzonen, wofür sowohl parking:zone als auch zone:parking in Verwendung zu sein scheint...

joshinils commented 2 years ago

die zone separat zu taggen wäre mir viel lieber, auch gern als relation wo die straßen enthalten sind, dann kleben die ganzen attribute nicht mehr an allen straßen und es ist klar dass es eine park-zone ist, nicht nur irgendwelche einschränkungen.

solch eine zione müsste dann natürlich mehrere straßen umfassen, und nicht nur in einer straße gelten, oder nur für einen teil.

damit wären dann auch geschachtelte zonen abbildbar, auf der frohnauer brücke ist nämlich wiederum das parken mit scheibe für kfz beschildert für eine strecke, und die frohnauer brücke ist innerhalb der parkzone.

joshinils commented 2 years ago

@tordans magst du issues zu den verschiedenen layer auf-machen?

dann kann man separat diskutieren was in denen enthalten sein kann / muss / soll und auch nicht. genauso kann man festhalten wie man die information darstellen mag, zb welche farbe, form, schraffur etc. und natürlich die legende jeweils oder aber auch insgesamt gestalten, so das zusammen möglich ist.

vielleicht ist es ja möglich, dass sich die layer nicht "streiten" mit ihren informationen und man sie auch zusammen gleichzeitig ansehen kann, so man das möchte. so können zb stellplätze, art, einschränkungen, und kapazitäten je leicht versetzt dargestellt werden, sodass man diese gleichzeitig gut sehen kann. zumindest wenn die zoom-stufe das zulässt.

tordans commented 2 years ago

Kopie von Alex Kommentar zu Layern aus https://github.com/gislars/osm-parking-processing/issues/41#issuecomment-1186521929

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: grafik
  • 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)
tordans commented 1 year ago

Der https://radverkehrsatlas.de/regionen/parkraum hat jetzt alle möglichen Stile und Zusatzinformationen, inkl. einer Debug-Ansicht. Ich schließe dieses Ticket daher.