Objekthistorie visualisieren (am Beispiel Vulkanausbruch La Palma)

Der seit Wochen anhaltende Vulkanausbruch auf La Palma wird in OSM laufend dokumentiert.

Der Lavastrom wird teilweise mehrmals am Tag aktualisiert: https://www.openstreetmap.org/relation/13249829

Gibt es eine einfache Möglichkeit, die Veränderung dieser Flächenrelation zu visualisieren?

Hätte man seit der Erstellung dieser Relation jeden Tag einen Screenshot gemacht, könnte man daran die allmähliche Ausbreitung der Lava gut nachvollziehen. Aber man müsste das doch auch nachträglich noch irgendwie sichtbar machen können.

Auf die Idee sind andere auch schon gekommen … :slight_smile:

https://mobile.twitter.com/geospacedman/status/1443672538572283905

Anleitung gibt’s hier: https://gitlab.com/b-rowlingson/get_lava

Danke. Hatte mir schon gedacht, dass das jemand bereits gemacht hat.

Ich habe aus eigenem Interesse eine spezielle Karte gebastelt, die den Lavafluss visualisiert.

Dazu werden alle Versionen der Relation 13249829, deren Member-Ways und des Ways 985095439 davor (jetzt Member) aus einer zwischengespeicherten Datei geladen (dauert etwas) und können mit einem Schieberegler durchlaufen werden. Mit den Pfeiltasten Links/Rechts kann man zum vorherigen/nächsten Edit-Stand springen. Updates muss ich momentan noch manuell ausführen und hochladen. Umgesetzt ist das mit Leaflet und dem timeline Plugin.

Momentan sind einfach alle Edits drin, auch Fehler, erste grobe Schätzungen aus verschiedenen Quellen und spätere Verfeinerungen anhand der täglichen Drohnen-Aufnahme. Für die Animation und eine nur grobe Beobachtung des Fortschritts ist das nicht so ideal, da müsste man noch Edits aussortieren oder nur tageweise springen.

Die Overpass API Abfrage aus GIS SE bekommt nur Änderungen an der Relation selbst mit. Also in diesem Fall hauptsächlich wenn Löcher dem Polygon hinzugefügt oder wieder gelöscht werden. Das passiert zwar oft, aber es gibt auch ein paar Lücken von ein, zwei Tagen ohne Änderungen. Was man aber eigentlich mitbekommen will, sind Änderungen am Umriss, also den Member-Ways (121 Versionen der Relation vs. 226 allein am ältesten Way 985095439). Ich habe deshalb die Anfrage entsprechend abgeändert:


[out:json];
(
  timeline(way, 985095439, 1);
  timeline(way, 985095439, 2);
  ...
  timeline(way, 985095439, 14);
);
for (t["created"])
{
  retro(_.val)
  {
    out;
    way(985095439);
    out geom;
  };
};

(
  timeline(rel, 13249829);
  timeline(way, 993070371);
  timeline(way, 994088037);
  timeline(way, 994084011);
  timeline(way, 994084013);
  timeline(way, 985095439);
  timeline(way, 994084012);
);
for (t["created"])
{
  retro(_.val)
  {
    out;
    rel(13249829);
    out geom;
  };
};

Die IDs sind momentan fest drin, die müsste man auch noch abfragen und dynamisch einbauen. Mit “for” statt “foreach” werden die Versionen aller Objekte nach Datum (“created”) sortiert und bei gleichem Datum gruppiert. Die “timeline” Elemente gebe ich wegen der Zeitstempel mit aus. Was damit immer noch nicht als eigener Stand berücksichtigt wird, sind Edits, die nur Nodes verschieben.

Wenn man hier noch die Nodes dazunimmt wird wahrscheinlich das Datenvolumen noch stärker anwachsen. Da sich die Relation insgesamt nur minimal ändert, sind da auch recht viel redundante Informationen drin. Vielleicht wäre es geschickter, für alle beteiligten Objekte die komplette Historie einzeln und unabhängig voneinander abzurufen und dann das finale Ergebnis erst im Browser zu berechnen.

Ja, da gibt es noch viel Optimierungspotential.

Das wäre mir auch am liebsten. Für so was ist die Overpass API halt nicht wirklich geeignet. Da habe ich immer noch die Wunschvorstellung einer speziellen DB für historische Abfragen, auch zur Changeset-Visualisierung. Zum Beispiel eine read-only Replikation der OSM DB mit entsprechend erweiterten Full History API Abfragen.

Ich kann mich noch dunkel daran erinnern, dass ich so etwas mal für Ways gebaut habe: https://github.com/openstreetmap/openstreetmap-website/issues/130#issuecomment-537616760 - d.h. alle Versionen eines Ways und zusätzlich für alle darin enthaltenen Nodes auch jeweils die komplette Historie.

Leider lahmt das ganze API Thema dieses Jahr etwas rum, und ich habe im Moment auch nicht so viel Motivation, mich damit zu beschäftigen.

  • off topic *