SRTM3-Daten, Datenbankgrößen

Hallöchen,

mir schwirren da so'n paar Ideen bezüglich der SRTM-Daten im Kopf rum und so habe ich mal fleißig im Web nach Datensätzen gesucht und war leicht ernüchtert.

Wenn man nur eine Abdeckung für Deutschland, also 5-15° Ost und 47-55° Nord, nimmt, kommt man schon bei den SRTM3-Daten auf 115,2 Mio. Datensätze. Selbst wenn ich die für den Zugriff in eine reine Altitude-Matrix mit 2Byte-Werten speichere, also ohne Positionsangaben und Zugriff rein über die Matrix-Position, komme ich auf eine Datenbankgröße von 220 MB!:(

Hat sich schon mal jemand intensiver mit den SRTM3-Daten beschäftigt und hat vielleicht noch ne' pfiffige Idee?

Gruß
blackwilli

Zitat von blackwilli

mir schwirren da so'n paar Ideen bezüglich der SRTM-Daten im Kopf rum

Hört sich gut an.

Zitat

und so habe ich mal fleißig im Web nach Datensätzen gesucht und war leicht ernüchtert.

Ernüchtert? Warum das?

Zitat

Wenn man nur eine Abdeckung für Deutschland, also 5-15° Ost und 47-55° Nord, nimmt, kommt man schon bei den SRTM3-Daten auf 115,2 Mio. Datensätze. Selbst wenn ich die für den Zugriff in eine reine Altitude-Matrix mit 2Byte-Werten speichere, also ohne Positionsangaben und Zugriff rein über die Matrix-Position, komme ich auf eine Datenbankgröße von 220 MB!:(

Das originale Format der SRTM-Daten ist das *.hgt-Format. Es enthält keine Positionangaben. Die Kantenlänge ist jeweils 1°. Die Position wird am Dateinamen fest gemacht. Eine 3"-Kachel ist 2818 kb gross. Eine 1" Kachel ist 25327 kb groß. Die Größe einer 30" Globe Kachel habe ich gerade nicht zur Hand.

Zitat

Hat sich schon mal jemand intensiver mit den SRTM3-Daten beschäftigt und hat vielleicht noch ne' pfiffige Idee?

Wo ist Dein Problem? Warum belässt du die *.hgt - Daten nicht in dem Format, wie sie sind.

Jonathan de Ferranti beschreibt das *.hgt-Format so:

Zitat

An HGT file covers an area of 1°x1°. Its south western corner can be deduced from its file name: for example, n51e002.hgt covers the area between N 51° E 2° and N 52° E 3°, and s14w077.hgt covers S 14° W 77° to S 13° W 76°. The fils size depends on the resolution. If this is 1", there are 3601 rows of 3601 cells each; if it is 3", there are 1201 rows of 1201 cells each. The rows are laid out like text on a page, starting with the northernmost row, with each row reading from west to east. Each cell has two bytes, and the elevation at that cell is 256*(1st byte) + (2nd byte). It follows that a 3" HGT file has a file length of 2 x 1201 x 1201. SRTM 3" cells are calculated by calculating the mean of 1" cells and their eight neighbors. It follows that the highest local point is likely to higher than the highest SRTM 3" cell. The difference should vary with the steepness of the local relief.

Gruss Joern Weber

Das ist ja nun alles bekannt. Bei meiner Frage geht es natürlich nicht um den Istzustand, sondern darum, wie man diesen weiter optimieren könnte, um größere Gebiete besser händeln zu können. Da wäre auch der Gedanke der Ausdünnung der Datenmengen unter Berücksichtigung der erforderlichen Genauigkeit bezogen auf das Einsatzgebiet nicht abwegig. Auf eventuelle Erfahrungen auch in dieser Richtung ging meine Frage.

Es gibt nichts, was man nicht optimieren könnte.

blackwilli

Hallo,

Zitat von blackwilli

Da wäre auch der Gedanke der Ausdünnung der Datenmengen unter Berücksichtigung der erforderlichen Genauigkeit bezogen auf das Einsatzgebiet nicht abwegig.

Ausdünnen? Dann kannst Du ja gleich die GTopo 30" Daten nehmen. Die existieren für die ganze Welt im 1000 Meter Raster. ca. 8Mb werden für eine Kachel so groß wie Westeuropa benötigt.

http://edc.usgs.gov/products/elevation/gtopo30/gtopo30.html

Für das Stopfen von Löchern im Track sind die Daten aber zu ungenau. Ich bin bisher nur den umgekehrten Weg gegangen und habe die Löcher in den STRM 3" Daten mit den GTOPO/Globe 30" Daten gestopft.

Gruss Joern Weber