Ausreißer in SRTM-Daten?!

[sh20]

Hallo zusammen,

ich habe meine GPS-Tracks aus Norwegen mit der Funktion "Vervollständigen... > Höhe" auf allen Positionspunkten mit recht alten lokal gespeicherten SRTM-3-Daten bearbeitet. Dabei gab es bei Fährfahrten mehrmals starke Abweichungen in der Höhe: Anstatt 1 m standen da plötzlich z.B. 60 m, dann wieder 1 m, dann wieder 40 m - so seltsame Spitzen für viele Punkte nacheinander eben. Nachdem ich hier (http://www.viewfinderpanoramas.org/Cover...s_org3.htm) aktuelle Daten aus dem letzten Jahr oder so geladen habe, brachte die Neuberechnung schön konstant 1m an den richtigen Stellen. So weit, so schön.

Aus derselben Quelle habe ich Dateien für Schleswig-Holstein für die Anschlusstour, da tritt das Problem leider recht häufig auf - zu häufig um es manuell korrigieren zu können. Ich nehme aufgrund der Verbesserung bei neueren hgt-Dateien an, dass es kein RouteConverter-Problem ist, sondern eher Ungenauigkeiten/Fehler in den SRTM-Daten (je neuer, desto besser)!?
Habt ihr auch solche Probleme und wenn ja, was macht man dann? Mir gehen gerade die Ideen aus...

Leider kann man in RouteConverter die Höhe manuell ja nur pro Position einzeln eingeben - eine Art manuelles Massenupdate wäre gut, mit dem man mal 100 Positionen hintereinander auf die gleiche Höhe 1m (oder ähnlich wie davor und danach) setzen kann. Wäre so was denkbar?

Beispieldatei habe ich mal angehängt - nahe der Küste müsste die Höhe am Strand nur ca. 1-2 m sein. Hat aber nichts mit Küstenlinie oder so zu tun, da ich solche Fehler auch im Landesinneren habe.

Viele Grüße und danke für so ein schönes Programm!
Steffen

PS: Windows 7, RouteConverter 2.9-SNAPSHOT-382

[nordlicht]

Moin Steffen,

Ich nehme aufgrund der Verbesserung bei neueren hgt-Dateien an, dass es kein RouteConverter-Problem ist, sondern eher Ungenauigkeiten/Fehler in den SRTM-Daten (je neuer, desto besser)!?

richtig.

Habt ihr auch solche Probleme und wenn ja, was macht man dann? Mir gehen gerade die Ideen aus...

eine andere Quelle mit einem neueren Bearbeitungsstand suchen und nachsehen, ob der besser geputzt ist. Nördlich von 60°N war viewfinderpanoramas.org lange Zeit die einzige und ist m.M.n. weiterhin die beste Quelle. Die SRTM-Datengrundlage an sich ist schon relativ alt, lies mal den SRTM-Artikel in Wikipedia,

[sh20]

Hallo Hans,

die wohl in Frage kommende unsaubere Datei N54E010.hgt hat das Datum 11.07.2012. Das ist ja nicht gerade alt und ich nehme an, dass es keine neuere gibt (laut Wikipedia ist die letzte Erscheinungsversion ja aus dem Jahr 2009). Den Artikel http://de.wikipedia.org/wiki/SRTM hatte ich vorher schon gelesen, aber auch beim zweiten Lesen weiß ich nicht wirklich, wie mir das nun bei meinem Problem weiterhelfen soll. Was besseres gibt's wohl nicht, zumindest interpretiere ich das so...

Grüße, Steffen

[sh20]

Jetzt sieht es allerdings doch nach einem Fehler bzw. einer Unschönheit von RouteConverter aus...
Ich habe etwas rumprobiert und bekomme unterschiedliche Verhalten für dieselben Punkte, abhängig davon, wieviele Positionen in der Wegpunktliste enthalten sind. Meine Vermutung, die sich daraus ergibt: RouteConverter hat irgendwie Probleme bei Werten < 1 m.

Test 1: Eine gpx-Datei mit 2 Punkten: Einer mit Höhe 2m und einer bleibt leer. Passend dazu:
Apr 27, 2013 11:35:47 PM slash.navigation.completer.CompletePositionService getElevationFor
INFO: Service: HGTFiles Longitude: 10.349639 Latitude: 54.43251 Elevation: 1.4931983999996186
Apr 27, 2013 11:35:47 PM slash.navigation.completer.CompletePositionService getElevationFor
INFO: Service: HGTFiles Longitude: 10.349715 Latitude: 54.432498 Elevation: null

Test 2: 63 Punkte, davon die ersten bei 1 m, dann viele ohne Wert und dann wieder welche mit 2 m. Soweit so korrekt, weil evtl. die Werte dazwischen in der hgt-Datei fehlen. Dass hier nicht interpoliert wird, ist natürlich schade...aber okay.

Test 3: In der Originaldatei mit 21.590 Punkten verhält es sich in den daraus entnommenen Punkten (Test 1 und Test 2) leider völlig anders: Hier wird bei einer Höhensuche über alle Punkte (oder nur einen einzelnen in den SRTM-Daten evtl. fehlenden Punkt) statt keinem Wert z.B. der Wert 45m eingetragen. Und wenn das öfter passiert, kommen diese Balkendiagramme zustande, die eigentlich bei 0 liegen sollten (siehe Screenshot).

Also nochmals zusammengefasst: Ein Punkt aus Test3 kopiert liefert hier den Wert 45, wenn derselbe Punkt mit weniger Daten in eine andere Datei kopiert wird, dann wird kein Wert (null) zugewiesen. Seltsam.

Angehängte Grafik: Das Programm GPS-Track-Analyse.NET macht diese Ausschläge nicht mit, es scheint fehlende Werte gut ausgleichen zu können. Oder womöglich sind die Werte doch in der SRTM-Datei vorhanden und es liest die Werte korrekt und RouteConverter hat nur ein spezielles Problem an der Stelle (Werte um Null herum)?

Viele Grüße,
Steffen

[routeconverter]

Test 2: 63 Punkte, davon die ersten bei 1 m, dann viele ohne Wert und dann wieder welche mit 2 m. Soweit so korrekt, weil evtl. die Werte dazwischen in der hgt-Datei fehlen. Dass hier nicht interpoliert wird, ist natürlich schade...aber okay.

Hallo Steffen,

da wird interpoliert. Siehe ElevationTile#getElevationFor()

Also nochmals zusammengefasst: Ein Punkt aus Test3 kopiert liefert hier den Wert 45, wenn derselbe Punkt mit weniger Daten in eine andere Datei kopiert wird, dann wird kein Wert (null) zugewiesen. Seltsam.

In der Tat. Es gab da schon einmal ein zunächst unerklärliches Problem zwischen dem -1. und 0. Längengrad, das ich mit den Originaldaten nachstellen und beheben konnte. Könntest Du mir die Beispieldateien schicken und kurz beschreiben, wie ich das Problem bei mir nachvollziehen kann?

Angehängte Grafik: Das Programm GPS-Track-Analyse.NET macht diese Ausschläge nicht mit, es scheint fehlende Werte gut ausgleichen zu können. Oder womöglich sind die Werte doch in der SRTM-Datei vorhanden und es liest die Werte korrekt und RouteConverter hat nur ein spezielles Problem an der Stelle (Werte um Null herum)?

Könnte sein (s.o.).

[sh20]

Okay, ich habe die drei Testdateien und die verwendete Höhendatei N54E010.hgt angehängt:
- Position 1 und 2 in test2.gpx entsprechen Position 17 und 18 in test1.gpx; Position 1 funktioniert in beiden Dateien, Position 2 liefert keinen Wert in Datei test2.gpx, dieselbe Position 18 in test1.gpx dagegen 45m (was falsch ist).
- In test3.gpx Position 41 liefert keinen Wert, die identische Position 177 in test1.gpx dagegen 44m (was falsch ist).
Hinweis: Ich habe in der Registry nur das Suchen in den SRTM-Daten erlaubt.
Danke und Grüße,
Steffen

[routeconverter]

Okay, ich habe die drei Testdateien und die verwendete Höhendatei N54E010.hgt angehängt: [..]

Danke, das hat mir die Analyse sehr vereinfacht:
- für die Position 18 in test1.gpx bzw. 2 in test2.gpx lassen sich keine Daten interpolieren
- mir ist nicht ganz klar, warum, da muß ich den Autoren @robekas nochmal fragen (Zeile 113 in https://github.com/cpesch/RouteConverter...nTile.java)
- also kommt ein 'null' (für nichts gefunden) zurück, das aber beim Aktualisieren der Position ignoriert wird
- dasselbe passiert, wenn man die Höhe einer Position löscht: diese Änderung wird auch ignoriert
- der Unterschied zwischen test1.gpx und test2.gpx ist, daß test2.gpx eine Höhe für Position 18 eingetragen hat, eben die 45m

Ich habe gerade eine neue Vorabversion hochgeladen, die 'null' sowohl fürs Hinzufügen der Höhe als auch fürs Löschen der Höhe akzeptiert. Bitte teste(t) und berichte(t), ob das so funktioniert und nicht noch andere Nebeneffekte hat, die ich nicht gefunden habe.

[sh20]

Hi.

- der Unterschied zwischen test1.gpx und test2.gpx ist, daß test2.gpx eine Höhe für Position 18 eingetragen hat, eben die 45m

Stimmt, wenn ich für eine "kaputte" Position (45m) den Wert manuell setze (1m), dann fasst RC diesen Wert nicht mehr an, updated ihn also auch nicht wieder zurück auf 45m. Das heißt dann wohl tatsächlich, dass mein Smartphone die 45m Höhe eingetragen hat und RC einfach kein Update über diese "kaputten" Werte macht. Ich dachte ursprünglich, die falsch gesetzten Werte kämen direkt von RC.

Grüße, Steffen

[sh20]

So, ich hab' für alle 27 Dateien meiner letzten Tour nochmals für alle Positionen die Höhe mit der neuesten Version von heute zuweisen lassen: Die vier Dateien mit Problemen sehen jetzt gut aus, keine Balken mehr. Die restlichen Dateien sehen nach Augenschein hinterher gleich aus wie vorher, haben auch dieselbe Gesamtsteigung wie vorher. Nur bei einer Datei ist die Gesamtsteigung um 10 m gesunken, aber das kann ja durchaus auch ein versteckter Fehlerwert nahe der Küste gewesen sein, der nun genullt wurde.
Ich bin zufrieden und kann wieder damit arbeiten...danke!
Steffen

[routeconverter]

Nur bei einer Datei ist die Gesamtsteigung um 10 m gesunken, aber das kann ja durchaus auch ein versteckter Fehlerwert nahe der Küste gewesen sein, der nun genullt wurde.

Wenn die Datei Höhenangabe unter NN hatte, dann probier doch nochmal die gerade hochgeladene Vorabversion aus, die sollte auch für negative Höhenangaben interpolieren und nicht 'null' daraus machen.

Ich bin zufrieden und kann wieder damit arbeiten...danke!