~/cases/open-earthLive
Open Earth
Wie lassen sich heterogene wissenschaftliche Datensätze und Live-Beobachtungen verbinden, ohne Herkunft, Unsicherheit oder wissenschaftliche Bedeutung zu verlieren?
→Kontext
Open Earth führt Erdbeben, Vulkane und tektonischen Kontext auf einer untersuchbaren Karte zusammen.
→Datenmodell
Referenzdaten, Live-Beobachtungen und abgeleitete räumliche Beziehungen haben getrennte Pfade und Aktualitätssemantiken.
→Architektur
Eine Python-Aufbereitung erzeugt statische Snapshots und Manifeste; Browser-Adapter zeichnen MapLibre-Layer, Suche und Inspektor.
- Wissenschaftliche Quellen werden in browsersichere Snapshots und ein Manifest normalisiert.
- Der Browser kombiniert die Snapshots mit Live-Beobachtungen des USGS.
- Die Oberfläche erhält Herkunft, Aktualität und die Trennung von Referenz-, Beobachtungs- und abgeleiteten Daten.
→Abwägungen
Statische Auslieferung vermeidet ein Runtime-Backend, aber geplante Updates und explizite Quellmetadaten werden Teil des Produkts.
→Entscheidungen & Trade-offs
| Entscheidung | Warum | Trade-off |
|---|---|---|
| Provenienz in den normalisierten Daten behalten | Nutzer müssen wissen, woher ein Merkmal stammt und wie aktuell es ist. | Daten- und UI-Modelle werden expliziter. |
| Kartenzustand URL-first machen | Ansichten und ausgewählte Merkmale bleiben teilbar und wiederherstellbar. | Die Zustandsserialisierung muss stabil bleiben. |
→Ergebnis
- Ein statischer, quellenbewusster Explorer für Geowissenschaften läuft auf open-earth.info.
- Das Repository enthält JavaScript- und Python-Tests für Zustand, Daten und regionale Adapter.
→Nachweise
- Live-/Referenzquellen
- USGS · GVP
- Kartendarstellung
- MapLibre
- Deployment-Modell
- Statisch
Erdbeben- und Vulkandaten
Native Browser-ES-Module
Kein Konto, Backend oder API-Key
→Was ich heute anders machen würde
Der nächste sinnvolle Schritt ist, die Aktualität der Quellen noch sichtbarer zu machen, ohne die Karte zu überladen.