Hi,
Fehler in hgt-Daten dürfte auch auf die Stelle südlich Isny ( N47° 33.7xx E10°) zutreffen.
Ist hier sogar gravierender.
Das aus den hgt-Daten erzeugte DEM zeigt an der genannten Koordinate zwei parallel verlaufende Verwerfungen.
Was die gleiche Kachel (N47E010.hgt, view1) wäre.
Hallo Thorsten,
Ich schreibe äusserst selten und ungern solche Antworten aber der “”“Verantwortliche”“” heisst Jonathan und da er seit fast 10 Jahren unermüdlich daran arbeitet der OSM-Welt ein ordentliches hgt-Dataset zur Verfügung zu stellen hat er sich den Respekt Ihn ordentlich beim Namen zu nennen wohl redlich verdient !
Bei allen Respekt…
Grüsse, Christian
Hallo Christian,
Leute, die ich mit Namen kenne, nenne ich auch so. Von Leuten, wo ich nur eine E-Mail Adresse habe, aber keinen Namen, vermeide ich es anhand der Adresse auf den Namen zu schließen. Das kann nämlich so richtig peinlich werden. Vor allem, wenn ich nicht weiß ob das der Vor/Nachname oder ein Fantasie-Account-Name ist. Und Leute, die ich nicht kenne, noch nie etwas mit zu tun hatte und rein gar nichts von weiß rede ich auch sehr ungern einfach so mit Vornamen an. Das hat rein gar nichts mit fehlendem Respekt zu tun, sondern genau das Gegenteil.
Solltest Du auch mal drüber nachdenken.
Thorsten
Sorry, war krank. daher nicht zum antworten gekommen.
Wenn man in der .hgt Datei, im Texteditor einige Zeilen aus der einen Kachel, in die Nächste kopiert, dann verschwindet die Linie. Allerdings treten andere auf. Mir hat jemand mal einen “korrigierten” srtm1 viewfinders Satz mal zugeschickt, und die beiden Linien hier waren eindeutig weg, allerdings gabs dafür zig andere Probleme. Also war es unsauber. Ich finde leider nicht raus, was genau im falschen File gelandet ist.
Mit phyghtmap kann man da nichts retten, aber die .hgt Dateien sollten mit Texteditor für jemand der sich mit dem Format auskennt, recht einfach zu fixen sein. Man braucht bei den entsprechenden aneinander angrenzenden Kacheln, nur die rund ~ersten 10 Zeilen analysieren und verschieben/kopieren.
Hallo,
ich würde da nicht herummanipulieren. Nachgeschaut habe ich mit einem Hex-Editor zwar nur bei VIEW3, bei VIEW1 ist das Prinzip aber das Gleiche.
Die Kacheln haben da ein Raster von 1201 x 1201 Punkten, jeweils in Wordgröße (2 Bytes) mit Höhenwert in Meter. Will man die nördliche Seite kopieren, müsste man genau die ersten 1201 Words oder ein mehrfaches davon kopieren, bei der südlichen Seite entsprechend die letzten. Schwieriger wird es bei Ost und West. Die westliche Seite entspricht dann genau jedem 1201-ten Word ab Offset 0, die östliche Seite dann auch, aber beginnend mit Offset 1200. Das ginge nicht mit dem Kopieren von Zeilen.
Davon abgesehen würde ich keinen Texteditor verwenden, da viele Bytes als Steuerzeichen interpretiert werden, was sie nicht sind (etwa ist 0A hier kein Zeilenvorschub und 0D kein Wagenrücklauf, sondern ein Binärwert - z.B 0D0A = 3338 Meter Höhe, von Backspace (08) oder Tabulator (09, welches sogar durch z.B. acht Leerzeichen ersetzt werden könnte) ganz zu schweigen) und man kann nicht sicher sein, dass das Ziel dann noch mit dem Quellabschnitt übereinstimmt. Und ein Kopieren in die Nachbarkachel kann sowieso nicht korrekt sein, da das Raster dann nicht mehr stimmt, von welchem die Programme bei der Auswertung ausgehen.
Ein Byte zuviel oder zuwenig verschiebt schon die Bedeutung der Words: Aus 2 benachbarten Höhen 0B|FE und 0C|02 wird xx|0B, FE|0C, 02|xx Ein Word verschiebt alle nachfolgenden Punkte um 3 bzw. 1 Arc in östliche Richtung., alle Höhenpunkte rechts sind dann links (Wrap around). Die nach dem Einfügen hinten “überstehenden” korrekten Zeilen werden wohl auch nicht mehr ausgewertet usw…
Grüße
Mario
Nahmd,
Die Dateien lassen sich trivial in ein CSV wandeln und dieses dann z.B. mit oocalc öffnen.
DecodeHgt.pl:
#!/usr/bin/perl
use strict;
foreach my $row (1..1201) {
sysread (STDIN, $_, 2*1201) or die;
print join (';', unpack ("n1201", $_)), "\n";
}
Aufruf: perl DecodeHgt.pl < xyz.hgt >xyz.csv
DecodeHgt.java:
public class DecodeHgt {
public static void
main (String... args) throws java.io.IOException {
java.io.DataInputStream in = new java.io.DataInputStream (System.in);
for (int row=0; row<1201; row++) {
for (int col=0; col<1201; col++) {
if (col>0) System.out.print (";");
System.out.print(in.readUnsignedShort());
}
System.out.println();
}
}
}
Übersetzen mit: javac DecodeHgt.java
Aufrufen mit: java DecodeHgt <xyz.hgt >xyz.csv
Im OOCalc kann man dann bequem Zeilen und Spalten kopieren.
Falls jemand auf diesem Weg arbeiten möchte, liefere ich die entsprechenden Encoder (ebenso kochkomplex ;)) nach.
Gruß Wolf
$ soffice xyz.csv
Libre Office 3.5
The maximum number of rows has been exceeded. Excess rows were not imported!
Hi!
Das ist komisch. Ich kann mich nicht erinnern bei meiner Umsetzung der Höhenlinien auf solche fehlenden Reihen gestoßen zu sein. Aber wenn ich Euch richtig verstanden habe sind das schon die ganz normalen NASA SRTM .hgts, oder?
bye, Nop
Ok, wenn man die “;” mit “,” vertauscht, schaft es gnumeric.
Uff, dachte schon, ich bräuchte excel.
Für sowas nimmt man z.B MICRODEM
Hab damit die benötigten ASTER GDEM vom TIFF ins HGT konvertiert - weil es nirgends für mein Gebiet SRTM1 gibt.
Nachebearbeitungen sind natürlich auch als GUI möglich.
Nahmd,
Die Meldung hatte ich auch: es waren aber alle Zeilen da (die sind ja listigerweise durchnummeriert und daher gut zu abzuzählen).
Mglw. ein Fehler im OOcalc, hab da nicht weiter nachgeforscht.
Gruß Wolf
Die Fehlermeldung von LibreOffice bis incl. Version 3.5 ist verkehrt:
Korrekt waere:
The maximum number of columns has been exceeded. …
Wurde in Verision 3.6 korrigiert.
LO 3.5 (umd wohl auch 3.6) koennen aber nur 1024 Spalten, so dass 1201 - 1024 = 177 Spalten fehlen!
Gnumeric (wie auch excel 2007) kann 16384 Spalten und zeigt dann die Datei vollstaendig an.
Jo, stimmt auch für 3.6: https://bugs.freedesktop.org/show_bug.cgi?id=50916
Die falsche Fehlermeldung soll aber korrigiert worden sein: “fdo#43911 FILEOPEN problem: error message mentions rows instead of columns for csv files with more than 1024 columns [Markus Mohrhard]”
Gruss
walter
Hallo,
ich habe heute Version 1.47 von phyghtmap veröffentlicht. Wie gewohnt ist die auf http://katze.tfiu.de/projects/phyghtmap/ zu finden.
Die wichtigsten Änderungen zu 1.45 sind:
- Es gibt jetzt die --void-range-max Option, mit der man eine Höhe festlegen kann, bis zu der alle Werte als void-Werte betrachtet werden. Das ist nützlich, wenn es hgt-Dateien mit kaputten Werten (-16384 und andere) gibt, die sich mittels z. B. --void-range-max=-500 ignorieren lassen.
- Void-Werte werden jetzt explizit ausgespart, das heißt, Höhenlinien am Rand von void-Bereichen werden jetzt nicht mehr geschlossen. In Bereichen mit vielen Void-Bereichen z. B. in den Alpen kann das die Output-Dateigröße stark reduzieren.
- Als einzige Änderung zu Version 1.46 wurde eine in matplotlib 1.3.0 kaputt gegangene Abhängigkeit gefixt.
Viele Grüße,
Adrian
Gibt es ev ein Problem mit der aktuellen Version? Ich wollte gerade für Texas (poly von geofabrik) eine neue Karte bauen und bekomme bei den Höhenlinien mehr oder weniger nur ein riesiges Durcheinander. Die Linien gehen über die gesamte Karte kreuz&quer?
Als Quelle habe ich neben etwas älteren NED Daten auch mal srtm1 probiert - leider mit dem selben Fehler.
phyghtmap --hgtdir=/usdem --poly=texas.poly --max-nodes-per-tile=0 --max-nodes-per-way=0 --source=srtm1 -s 10 -c 100,50 --pbf --out coni.pbf
Hört sich nach Kollision mit OSM-Objekten an … stell doch mal einen Screenshot ein.
Gruß Klaus
Anhand des Screenshots würde ich sagen, daß die OSM-IDs mit denen der Höhenlinien kollidieren (genauer: es gibt doppelte IDs).
Versuche mal diese Optionen: --start-node-id=4800000000 --start-way-id=2000000000
Gruß Klaus