(10.04.2010, 13:45)womisa Wrote: ...die *.hgt haben einen relative eifachen Dateiaufbau. Da stehen 16 Bit signed Integer (zB.: Array 1201x1201 90m Auflösung) drin. Der Stream ist BIG Endian. Der FileName ist die linke untere Ecke. Leider bin ich in Java nicht drin. Ich werde das mal für mich in C# ausprobieren.
Ok, wenn Du etwas in der Form hinbekommst wie im GeonamesService, das in der Schnittstelle
public Integer getElevationFor(double longitude, double latitude) throws IOException {
mündet sollte sich das von C# wohl nach Java portieren lassen, oder?
Das wäre schon eine tolle Sache, wenn das mit den hgt Dateien gehen würde.
Der Geschwindigkeitsgewinn beim Höhenprofilberechnen für einen längeren Track, wäre doch sicherlich
beträchtlich (würde ich mal vermuten).
Das war übrigens ein Punkt den ich von meiner Seite auch angegangen wäre.
11.04.2010, 13:52 (This post was last modified: 11.04.2010, 19:13 by womisa.)
Hallo
ich habe mal versucht das zu "interpretieren". Das Lesen des Files ist kein Problem...
..aber was rauskommt entspricht nicht meinen Erwartungen. Der Reihe nach:
Ich habe folgende Kurzbeschreibung gefunden:
Quote:Ich hab mir damals diese Info aus dem Netz gezogen, und damit gings problemlos:
* Ein SRTM3-File beinhaltet 1201x1201 Bildpunkte
* Die letzte Spalte eines Bildausschnittes überlappt sich dabei immer mit der ersten Spalte des nächsten Bildausschnittes in östlicher Richtung und die letzte Zeile überlappt sich mit der ersten Zeile des nächsten Bildausschnittes in südlicher Richtung
* Diese Bildinformationen sind somit vollkommen identisch und dienen lediglich als Überprüfungszweck ob diese Daten auch wirklich zusammen gehören
* Die Namenskonvention der Dateien hängen von dem jeweiligen Bildausschnitt ab und sind nach den Längen-und Breitengraden benannt
* N40W188.hgt beschreibt somit die Messung im Gebiet Breitengrad 40-Nord und Längengrad 188-West
* Die verschiedenen Höhenwerte sind in einem 16-Bit-Integer-Format gespeichert und sind einfach hintereinander geschrieben ohne Header-und Trailerbytes
* Sie sind Zeilenweise von links nach rechts auszulesen. Ist die erste Zeile vollständig ausgelesen folgt die Zweite, Dritte usw.
* Die einzelnen Integer-Werte beschreiben die jeweilige Höhe in Metern und können somit Höhen von –32767 bis 32767 Metern ausdrücken
* Der Wert –32768 beschreibt einen Fehler, der meistens schon beim Messen entstanden ist, und sollte im Programm interpoliert werden
Ich habe das mal mit dem File "N48E008hgt versucht. In meinem Programm habe ich ein Array von 1201x1201 short Integer erzeugt. Die Werte sind die Gleichen wie im Hexeditor.
So weit so gut. Aber die Höhe im ersten Wert (siehe Snapshot) ist vom hgt File "158" (Hexeditor und Arraywert hgt[0.0]. Das müßte doch N48E008 sein?
Der RouteConverter zeigt da aber 560 an. Wo liegt da der Fehler?
Hat die Höhe da einen anderen Bezugswert (Offset)?
Hintergrund: Ich möchte mir einen "kleinen" Wander_Routeneditor in C# zusammenstricken, der schon bei der Routenerstellung die Höhe anzeigt und das Ergebnis soll "Glopus" kompatibel () sein.
Wer hat mir da einen Tipp?
MfG
Achim
Ps:: Die Höhenermittlung steht da in der Prio weiter hinten...... aber trotzdem möchte ich das jetzt klären.......
Ich glaube da stimmt "nur" die Koordinatenzuordnung nicht N48E008 ist wohl nicht der erste Wert......sondern bei 1200,xxx?
Anbei ein Höhendiagramm von ein paar Kanälen.
Es sind in einigen Kanälen auch ungültige Werte (-32768) drin...
hab's mir mal angeschaut. Ist tatsächlich etwas verwirrend, und
nicht wirklich auf Anhieb zu durchschauen (sonst hätt' ich's ja gleich kapiert ).
Also von links nach rechts ist klar.
Der erste Wert in der Datei ist der ganz links also bei 8.0 östliche Länge,
der nächste Wert dann 8.0 + 1/1200, der nächste bei 8.0 + 2/1200.
Der Wert bei 1201 ist dann der Wert für 9.0 östliche Länge.
Aber nun zum Breitenwert:
Der erste Wert, bzw. die ersten 1201 Werte in der Datei,
haben nicht 48.0 nördliche Breite,
sondern 49.0 nördliche Breite, die nächste Zeile mit den 1201 Werten dann
49.0 - 1/1200 nördliche Breite, usw.
Die letzten Werte (Zeile) in der Datei müsste demnach die Werte für
48.0 nördliche Breite haben.
11.04.2010, 22:09 (This post was last modified: 11.04.2010, 22:50 by womisa.)
Hallo
Quote:hab's mir mal angeschaut. Ist tatsächlich etwas verwirrend, und
nicht wirklich auf Anhieb zu durchschauen (sonst hätt' ich's ja gleich kapiert Rolleyes ).
... so gehts mir auch
Quote:Der Wert bei 1201 ist dann der Wert für 9.0 östliche Länge.
Ich glaube (sicher) das ist die erste Reihe/Spalte vom nächten Block. Länge und Breite (Reihe/Spalte) überlappen am Rand zum nächsten Block zur Plausibilitätsprüfung, deshalb 1201 (1 Grad +1/1200) den (1200/1200 =1 )
..aber ich bin schon weiter gekommen. Habe aber aus Zeitgründen noch nicht weiter gemacht.
Ich habe ein Tool gefunden "HGT2XYZ" welche die HGT-Files nach ASCII wandelt. Da stehen die Koordinaten und die Höhe drin. Das ist ja mal schon was.
...mmh der erste Offset ist mir noch nicht klar ist (1/1200) halbe? Dann sind es eben diese 1/1200.
An der Stelle ==> 8,00041631973355,48,001248959198,548 sind es 548m, nur noch 12m Unterschied zum RC....
dass da 1201 Werte drinnen stehen hat meiner Meinung nach nichts mit
Plausibilität zu tun, sondern hat ganz einfach praktische Gründe:
Einfaches Beispiel mit 4 + 1 Punkten (anstatt mit 1200 + 1):
Damit erhalten wir folgende Werte (in horizontaler Richtung):
8.0; 8.25; 8.5; 8.75; 9.0;
Wenn wir nur vier Werte abspeichern würden hätten wir den 9.0 Wert
nicht in diesem Block/Kachel/Datei sondern erst im nächsten.
Das heißt um die Werte für den Bereich 8.75 - 9.0 zu berechnen, müssten
wir den nächsten/anschließenden Block öffnen (und das Ganze nach Süden
ebenso), und das ist halt unpraktisch.
12.04.2010, 08:44 (This post was last modified: 12.04.2010, 09:16 by womisa.)
Hallo Robert,
volle Zustimmung! Kann aber auch zur Überbrüfung der "nebenliegenden Kacheln" verwendet werden, was man nicht tut
Hast du mal mit dem oben erwähnten Tool HGT2XYZ getestet, da ist der erste Offset halbiert, warum?
Ich hab da noch ein "read_hgt" gefunden. Das ist für Testzwecke sehr zweckmäßig und bestätigt deine Antworten und meine Vermutungen..
Weiteres Tool "ViewHGT" zeigt unter dem Cursor die Höhe an. Leider ohne Karte drunter oder Koordinaten. Sowas möchte ich in meinen Routeneditor integrieren. Falls jemand Sourcen-(Files) für .Net kennt, her damit.
MfG
Achim
Ps: In dem Header ist die "linke" Ecke (xllcorner, yllcorner 8,48) wie du (und?) ich das abgeleitet haben. Siehe da, da stimmt die Höhe mit RC im Punkt 8/48 = 560 m überein
die Bezeichnung der Kachel/Datei bezieht sich auf die linke untere Ecke der Kachel,
das bedeutet aber nicht, das der erste Wert in der Datei sich
ebenfalls auf diese Ecke bezieht (das ist der Denkfehler, den ich
auch begangen habe).
Sondern die Kachel ist von oben (also 49.0) nach unten (hin zu 48.0) aufgebaut.
Warum man die Werte von 'oben' (erste Werte in der Datei) nach 'unten' (letzte Werte in der Datei) laufen lässt...?
Eine Erklärung wäre vielleicht, dass im Computer beim Bildaufbau die
Zeilen auch von oben nach unten aufgebaut (bzw. durchnummeriert) werden.
Und xllcorner und yllcorner beziehen sich eben auf die untere linke Referenzecke.
Warum die allerdings so krumm sind...?
Wahrscheinlich ein Rundungsfehler.
Quote:Warum die allerdings so krumm sind...?
Wahrscheinlich ein Rundungsfehler.
Das Krumme kommt vermutlich von der Float Darstellung (single) oder so? Werde ich aber auch mal anschauen.
Das meine ich aber nicht. Das mit den Ecken ist jetzt auch klar(er).
Was ich aber nicht (ganz)verstehe ist beim HGT2XY der Abstand in den Koordinaten zB: 0,00083263946711 das ist 1/1201
müßte doch ein 1/1200 = 0,0008333333333 sein...
Ist zwar Minimal, aber kleinvieh macht auch Mist..oder?
Der GANZE Block ist doch 1 Grad und 1 Bogensekunde, oder liege ich da falsch?
?
).