Zukünftig weltweit 30m SRTM-Daten verfügbar

Eine tolle Neuigkeit zur Verfügbarkeit von freien DEMs:
Irgendwann im kommenden Jahr wird die bisher nur für die USA verfügbare Auflösung von 30 Metern weltweit freigegeben. Bisher besitzen die SRTM-Daten eine Auflösung von 90 Metern.
http://www.digital-geography.com/kuenftig-auch-hochaufgeloeste-30m-srtm-daten-weltweit/

Die Originalmeldung: http://www.jpl.nasa.gov/news/news.php?release=2014-321

Bleibt dann aber immer noch die Frage wie man sowas händelt:

http://i.imgur.com/LSTtZcc.jpg

Für einen Router der Höhenangaben benutzt sieht sowas eher schlecht für Fahrradfahrer aus, in der Realität ist das ein perfekt ebener Weg.

Bedeutet weltweit auch in sehr nördlichen Regionen (z. B. Lappland)? Oder gibt’s bei SRTM davon keine Daten (so hatte ich das urspünglich verstanden, da die entsprechende Shuttlemission aufgrund ihrer Umlaufbahn diese Bereiche nicht erfassen konnte).

Gruß
unixasket

Hi!

Hatte schon angefangen mich zu freuen, als mir eingefallen ist, daß ich ja die berichtigte Version von CGIAR nutze, weil in den Originaldaten von SRTM eklatante Löcher und Meßfehler enthalten sind. Das dürfte bei höherer Auflösung nicht besser werden.

Bei 60° Nord und 58° Süd ist Schluß.

bye, Nop

Weisst Du da genaueres? Dass sie bei CGIAR Löcher gefüllt haben weiss ich und glaubich auch irgendwie die Küstenlinien bereinigt. Aber haben sie auch substantiell in der Fläche was gemacht an der Kalibrierung? Weil das wabert irgendwie nur so durch die Köpfe, aber eine Quelle für diese Behauptung kenne ich nicht.

Ich (->BRouter) verwende zwar auch den CGIAR-Datensatz, aber die Löcher-Füllungen brauch ich nicht wirklich ( ich fülle sie auch entlang der Pfade ) und Hügel auf dem Meer sind mir eigentlich egal.

Unter http://earthexplorer.usgs.gov/ wurden übrigens gestern schon grosse Bereiche freigeschaltet, da steht zwar was von Afrika, aber mit Geografie haben’s die Amis ja nicht so und deshalb geht Afrika scheinbar bis 41 Grad Nord, also Mallorca kann man da schon laden.

Gibt da 3 Formate, kennte jemand das “BIL” Format, scheinbar 10 mal kleiner als Geotiff. Den Welt-Datensatz in 30m zu Laden dürfte wohl eine Herausforderung sein. Vielleicht sollten wir uns da zusammentun.

Band Interleaved by Line. Einfach zeilenweise die Werte in eine Datei schreiben. Wie lang eine Zeile ist und wie viele Bytes einen Wert ergeben, muss irgendwo anders festgehalten werden. Deshalb liegt in der Regel irgendwo in der Nähe eine .hdr-Datei, wo diese Werte und die Koordinaten der Eckpunkte drin stehen.

Sowas kann man mit einem Hysterese-Filter handhaben.

Ich habe aber gerade ein anderes Problem: Mein Hysterese-Filter benutzt ein 10m-Band und hat damit bisher (SRTM-90m) sowohl Wälder als auch ganze Hochhaussiedlungen korrekt verschluckt.

Wenn ich jetzt zu SRTM-30m wechsele, bekomme ich wahrscheinlich mit den Hochhäusern ein Problem, weil wenn diese Mittelung über fast einen ganzen Hektar (9090 m2) ersetzt wird durch eine viel kleinere Zelle von 3030 m2, dann sind die Ausschläge entsprechend grösser.

Ich brauche also wohl einen neuen Tiefpass-Filter um den impliziten Tiefpass-Filter aus SRTM-90 zu ersetzen. Ich kann das machen, indem ich z.B. jede Zelle durch den Mittelwert aus den 9 Zellen der Umgebung ersetze. Aber habe ich dann überhaupt noch was gewonnen. Klar, ich hab tatsaechlich mehr Daten und die Konturen von Täleren wohl etwas besser modelliert, aber die neu gewonnene Trennschärfe durch den Tiefpassfilter ja doch wieder kaputt gemacht.

Gibt’s hier einen Ausweg?

Und gibts vielleicht ein funtionierende Tool-Chain, die solche 2d-Tiefpassfilter kann? Im Prinzip ist da ja nicht viel Gheist dahinter, aber es an den Kanten der Kacheln richtig zu machen ist schon bisschen Arbeit für Dumme.

Ein Vorschlag wäre, das Tiefpassfilter an OSM-Landuses zu koppeln. Ein landuse=residential könnte das Filter weicher machen als in sonstigen Gebieten. Technisch und die Hardwareanforderungen betreffend wird das ganz schön anspruchsvoll! Wenn ich es richtig verstanden habe, machen die Jungs von OpenDEM etwas Ähnliches.

PS: “Der Filter” bezeichnet einen Kaffeefilter. In der Signalverarbeitung ist das Filter Neutrum. :stuck_out_tongue:

Da müssten eigentlich die aus der Bildverarbeitung bekannten Filter-Algorithmen (unscharf maskieren etc) verwendbar sein.
Wenn man einen Format-Konvertierer hätte, bräuchte man nicht mal was programmieren.

Hab’ mal die SRTM1-Daten zu Mallorca in ein PNG-Bild konvertiert, mit Skalierung irgendwie so pseudo-logarmithmisch (Meeresspiegel bei 30, bis 127 linear in Metern, darüber irgendwie verbogen):

http://brouter.de/brouter_bin/mallorca_srtm1.png

Umrechnung von Pixel-Koordinaten (bei 0 anfangend) in Geo-Koordinaten ist lon=2+x/3600, lat=40-x/3600

Man kann da den Effekt von Gebäuden so halbwegs vermessen, z.B. von diesem auffaelligen, 20 Meter hohen Ding in Alcudia, was nach meiner Umrechnung dieses hier sein müsste:

http://brouter.de/brouter-web/#zoom=20&lat=39.82833&lon=3.11528&layer=OpenStreetMap

Der Blogeintrag wurde mit Terminen aktualisiert. Demnach kommt das Release für Europa im April 2015, letztes Release im September 2015.

Gruß,
Norbert

Ich habe kürzlich mit den Landesdaten “spielen” dürfen: 1-4 Punkte pro m² mit einer Höhengenauigkeit von +/- 20 cm :smiley:
Leider sind das aber so viele Daten, dass man massiv filtern und klassifizierten muss - aber es macht echt Spaß.

Ich arbeite zur Zeit an einem Projekt mit Geheimhaltung, aber ich darf euch kurz mitteilen, wieso genaue Höhendaten interessant sind:

Ein moderner Hybrid benötigen Höhendaten, um zu kalkulieren, wann sie auf der Route wo aufladen können. Wenn man z.B. von einer Landstraße bergab fährt, und am Ende des Berges ein Dorf/eine Stadt ist, springt der Motor so früh an, dass er durch die Stadt mit dem Elektromotor fahren kann. So werden Emissionen (Lärme und Abgase) in der Stadt verhindert.

Das Projekt ist sehr interessant und noch vor wenigen Jahren wäre keiner auf die Idee gekommen, Höhendaten für sowas zu nutzen.

Das Beispiel habe ich mir in QGIS mal genauer angeschaut und einen DEM-Vergleich gebastelt:
DEM Vergleich

Das Höhenprofil in BRouter Web (CGIAR-CSI SRTM 90m) zeigt bis zu 9m Höhendifferenz bei eigentlich flacher Straße. Leider scheint sich auch beim neuen 30m SRTM das Gebäude auf die Umgebung auszuwirken, da hätte ich eine genauere Trennung erwartet.

Links: Gebäude in OpenStreetMap und StreetView. DEM: NASA SRTM 1 Arc-Second Global, CGIAR-CSI SRTM, EU-DEM

.

Sehr interssant…

zwei Dinge fallen mir natürlich auf:

Einmal das Alignment: wenn SRTM-90 so wie dokumentiert durch Mittelung von jeweils 9 Pixeln in SRTM-30 entstanden ist, dann müssten die Erhebungen in beiden Bildern den gleichen Schwerpunkt haben, es scheint aber eindeutig verschoben. Ich nehme an, dass Dir QGIS das Alignment aus den Meta-Daten der Dateien selbst gemacht hat und Du unschuldig bist? Also muss der Fehler entweder in QGIS sein oder in einem der beiden Datensätze.

Und EU-DEM scheint hier subtanziell anders zu sein. so, als hätten sie das Gebäude weg-gefiltert. Nach so einem Filter suche ich noch, der nicht einfach nur Gebäude in die Breite zerlaufen lässt, sondern solche spitzen Strukturen tatsächlich als “ungeografisch” erkennt und wegfiltert.

Die erwähnen nichts vom Filtern, nur vom gewichteten Mitteln: " based on SRTM and ASTER GDEM data fused by a weighted averaging approach" (steht da). Vielleicht hat an dieser Stelle einfach das flachere ASTER beim Gewichten gewonnen.

Die heruntergeladenen GeoTiffs hab ich einfach direkt als Rasterlayer in QGIS hinzugefügt. Zum Hinterlegen mit Bing per OpenLayers Plugin hab ich das Projekt-KBS auf Pseudo Mercator / EPSG:3857 mit Auto-Transformation gestellt, der Versatz ist aber auch ohne da.

Ich bin da schon etwas arglos rangegangen und hab mich darauf verlassen, dass QGIS das schon richtig macht, wobei ich mich nicht wirklich gut damit auskenne und eine Fehlbedienung nicht ausschließen will. Etwas wundern tu ich mich über das Ergebnis schon auch, kann ja mal schauen wie ich das verifizieren kann und evtl. auch mein Vorgehen nachvollziehbar dokumentieren.

Leicht süd-östlich zur Straße hin versetzt gibt es ja auch bei EU-DEM noch eine Erhebung, mit einem Maximalwert von 7.739999771118164 zwar deutlich abgeflacht, aber trotzdem noch erkennbar.

Ich hab’ das nochmal geprüft: Mit dem CGIAR-Datensatz der Version 4.1 (da wo die Kacheln 6001*6001 Pixel haben) passt das vom relativen Alignment gegenüber SRTM 30m.

Das “+1” in 6001 ist eine Erleichterung für die Interpolation, so dass man die Randzeilen immer doppelt hat. Das Pixel der Spalte 0 hat seinen Schwerpunkt (nicht seinen linken Rand) dann genau auf dem Längengrad, der die Kachel begrenzt. Bei dem CGIAR Daten der Vesion 4.0 gab es das glaubich nicht, da waren es 6000*6000 Pixel.

Jedenfalls liegt der gemeinsame Mittelpunkt der beiden hellsten Pixel in allen Datensätzen am identischen Punkt, und der trifft in das Gebäude auch in Google-Earth leicht (ca 30m) südlich, so wie im linken Bild von ikonor zu sehen.

Das gleiche gilt auch für den 90m Datensatz, den man bei http://earthexplorer.usgs.gov/ laden kann, aber hier sind seltsamerweise dann die Werte anders und auch das hab’ ich mir angeschaut, und es scheint so zu sein dass:

  • bei CGIAR 4.1 die 90m-Pixel tatsaechlich durch Mittelung der jeweils 9 Pixel entstanden sind

  • bei USGS aber der Wert des jeweils zentralen Pixels genommen wurde.

so dass

  • diese beiden 90m Datensaetze also eine unterschiedliche Charakteristik haben und für Routingzwecke nicht unbedingt austauschbar sind.
  • man mit dem 30m Datensatz aber je nach Wahl des eigenen Filters beides wieder nachbauen kann