MichaelsJP / Unrelevant

0 stars 0 forks source link

Workflow #2

Closed MichaelsJP closed 3 years ago

MichaelsJP commented 3 years ago

Wie wollen wir Ergebnisse generieren bzw. den Workflow strukturieren:

  1. Query Ohsome mit speziellen OSM-Tags (Grünflächen, Bundesländer, Landesgrenzen etc.)
  2. Antwort selektieren nach Polygonen
  3. Mit Polygonen Isochronen berechnen als Einzugsgebiet zb. Landesgrenzen.
  4. Ergebnisse umlegen auf Bevölkerungs-Layer
  5. Ergebnisse analysieren. Zb Unter- Überversorgung der Bevölkerung mit xyz (Grünflächen, Nah- Fernerholung etc.)
  6. 3-5 mit unterschiedlichen Isochronen-Anbietern rechnen und vergleichen.
BoSott commented 3 years ago

zu 3. ich würde das Einzugsgebiet tatsächlich nicht mit Landesgrenzen o.ä. verschneiden, da das ja an sich die Erreichbarkeit nicht beeinflusst - allerdings könnte man die Erreichbarkeit der Flächen auf bspw. die Stadtbezirke aggregieren

klingt aber so erstmal nach einem Plan - wobei ggf. noch eine genauere Research Question gut wäre - aber ggf. reicht ja auch die Erreichbarkeit von Grünflächen.

auch der Punkt 6. insbesondere das "vergleichen" müssten wir noch konkretisieren

weitere Idee: Einbindung von Bahnhöfen / und oder Bushaltestellen als Proxy für die Erreichbarkeit mit öffentlichen Verkehrsmitteln und vergleich zu Isochronen mit dem Autoverkehr.. ? aber gute Frage wie man das genau umsetzt..,

MichaelsJP commented 3 years ago

Öffie-Erreichbarkeit sollten wir imo nicht zu sehr betrachten. Es gibt momentan keinen open source routing anbieter, der öpnv sinnvoll routen kann. Wir können theoretisch Bushaltestellen als poi einbinden. Kein Problem. Allerdings können wir die Erreichbarkeit der Bushaltestellen nicht mit einbeziehen. Deswegen imo nicht benutzbar. Denke wenn wir da andere Parameter anlegen, wie im Umkreis xyz von Wohngebieten etc. kommen wir weiter mit der Aussagekraft der Analyse. Wir können die Erreichbarkeiten ja trotzdem mit verschiedenen Profilen betrachten, Fahrrad, Auto, zu Fuß und dann auch die Profile vergleichen.

BoSott commented 3 years ago

korrekt, ggf. ist eine Einbindung von POIs aber auch ganz interessant, mal sehen :) Erstmal das Ding so wie du es beschrieben hast ans Laufen bringen, mehr Features sind immer noch möglich..

lgroe commented 3 years ago

Ja sehe ich auch so. Das mit der Research Question können wir ja vlt nochmal im Seminar abklären, also ob Erreichbarkeit von Grünflächen als Fragestellung reicht oder ob das irgendwie mehr sein muss. Allerdings wäre Punkt 6 ja eigentlich auch noch mal eine eigene Frage.

Denke auch dass Punkt 6 konkretisiert werden sollte. Wie hattet ihr das im anderen Seminar gemacht, hattet ihr den Vergleich irgendwie quantifiziert?

Weiß nicht ob das Sinn macht: Die Isochronen werden doch auch als Polygone zurückgegeben oder? Wäre es nicht sinnvoll, die auch in die db zu laden und Punkt 4/5/ggf.6 direkt in der Datenbank mit PostGIS zu berechnen? Wie hattet ihr euch das bisher überlegt?

MichaelsJP commented 3 years ago

Ja sehe ich auch so. Das mit der Research Question können wir ja vlt nochmal im Seminar abklären, also ob Erreichbarkeit von Grünflächen als Fragestellung reicht oder ob das irgendwie mehr sein muss. Allerdings wäre Punkt 6 ja eigentlich auch noch mal eine eigene Frage.

Es sind nicht nur Grünflächen. Im Endeffekt alles was wir als Erholungs-POI klassifizieren. Schwimmbad, Badeseen, etc.

Weiß nicht ob das Sinn macht: Die Isochronen werden doch auch als Polygone zurückgegeben oder? Wäre es nicht sinnvoll, die auch in die db zu laden und Punkt 4/5/ggf.6 direkt in der Datenbank mit PostGIS zu berechnen? Wie hattet ihr euch das bisher überlegt?

Isochrone wird implizit bei der SQL Query als Geometry mit in die DB gegeben. Das muss nicht explizit geladen werden. Das Ergebnis wird mit der SQL-Query dann in der DB berechnet.