Fehlende Höhenangaben bei manchen Caches

[js_plasma]

so, nachdem ich auch schon die suche hier leider erfolglos gequält habe, hoffe ich von euch einen kleinen tipp für mein problem zu bekommen:

ich benutze GSAK lediglich zur generierung meiner statistik (mit FindStatGen3). Beides sind die aktuellen versionen!
seit kurzem jedoch (4 oder 5 wochen) werden bei manchen caches die höhenmeter immer auf "0" gesetzt... von meinen 667 finds betrifft das momentan 46 stück. diese hatten aber früher schon mal die korrekten höhenmeter (ist mir aufgefallen, weil ich eigentlich noch nie auf null höhenmeter funde hatte, aber die stehen eben mit "0" in meiner statistik).
die 46 stück sind nicht meine letzten founds, sondern das geht quer durch letzte jahr und auch heuer.

hatte jemand von euch schon mal das gleiche problem und vielleicht weiss jemand, wie ich das beheben kann? ich möchte nicht unbedingt ein weiteres macro einsetzten, weil es ist ja vorher auch ohne gegangen.

danke schon mal für eine antwort!

gruß
js_plasma

 

[NoPogo]

Es gibt ein eigenens "Elevation" Makro fürs GSAK.
Damit dass aber korrekt läuft, muss vorher die RESOLUTION-Zelle auf Leer gesetzt werden.
Dazu am besten erst eine Filter setzen, der nur alle Cache beinhaltet, die als Elevation "0" haben.
Dann über Database -> Global Replace die RESOLUTION auf den leeren Wert setzen lassen.
Anschliessend das Elevation Makro laufen lassen.
Danach hat es bei mir immer gepasst.

Warum das passiert weiss ich aber auch nicht.

 

[Lutz!]

Also bei mir klappt das Makro einwandfrei. Was ich allerdings nicht verstehe ist, wozu die Abfrage mit den 30m ist. Ich hab da einfach einen haken gesetzt, ohne wirklich zu wissen was das bewirkt.
Was ich nicht hinbekommen habe, sind Werte unter 0. Wie ist es, wenn ein Cache in einem Tal unter 0 liegt? Das Makro scheint mir nur Werte oberhalb 0 anzuzeigen!?

 

[UF aus LD]

Bei mir klappt es auch mit den tiefliegenden ....

GSAK 7.7.4.1.8, Macro Elevation 1.7, FindStatGen 4.105B

 

[Lutz!]

GSAK 7.7.3.53 (laut Update Button die aktuelle Version) und Makro Elevation 1.7

Bei mir sieht es leider so aus...

PS: Was bewirkt der Haken bei "Use Aster 30m Data", bzw. sollte man den setzen oder nicht?

 

[ElliPirelli]

Komischerweise klappte es bis vor kurzem bei mir auch mit den tieferliegenden Caches. In Holland waren einige bei -6m und -7m.
Jetzt auf einmal will GSAK mir weißmachen, daß bei Amsterdam der Cache bei 248m üNN liegen soll.
Was ist gleich noch mal die höchste Erhebung der Niederlande?
Unter Null hab ich jetzt keine Mehr, dafür sind einige bei 0m, die in Kassel liegen und andere, die definitiv niedrig liegen, sind plötzlich über 200m hoch?
Ich hab schon mehrfach versucht, die neu zu laden... Immer das gleiche...

 

[UF aus LD]

GSAK 7.7.3.53 (laut Update Button die aktuelle Version) und Makro Elevation 1.7

Bei mir sieht es leider so aus...

PS: Was bewirkt der Haken bei "Use Aster 30m Data", bzw. sollte man den setzen oder nicht?

GSAK 7.7.3.53 ist nicht die aktuellste Version.
bei "Tools"-"Options"-"Advanced" solltest du den Haken bei "Turn off version check" raus nehmen und bei "Notify me of patches" setzen, dann bekommst du auch "Zwischenupdates" gemeldet.
(Siehe Bild)

Der Haken bei "30mData" bewirkt meines Wissens nichts, da dann auf Daten zugegriffen wird, die für Europa (noch?) nicht verfügbar sind sondern nur für die USA. Sicher bin ich mir nicht, habe aber bei mir noch keinen Unterschied festgestellt und setze ihn daher nie.
Ich suche mal, ich glaube mich zu erinnern im GSAK-Forum von dem Problem <0m gelesen zu haben und wenn ich es hab poste ich es hier. Muss suchen.....

 

[Lutz!]

Ich suche mal, ich glaube mich zu erinnern im GSAK-Forum von dem Problem <0m gelesen zu haben und wenn ich es hab poste ich es hier. Muss suchen.....

Danke für Deine Mühe!

EDIT: Habe auf GSAK 7.7.4.18 erneuert, aber die Zahlen bleiben leider Konstant (nichts unter 0).

 

[UF aus LD]

Der Fehler scheint mit dem Felde "Resolution" zusammen zu hängen.
Versucht mal nach Kais Vorschlag das Resolution-Feld zu leeren (siehe Bild Resolution.png)

Der Thread ist HIER

alternativ könntet ihr auch

a) "resolution"-Feld und "elevation"-Feld jeweils mittels "Global replace..." mit "" überschreiben, d.h. leeren.
b) Die Datei "elevationdataSQL.db3" im GSAK-Markoordner löschen.
c) Elevation-Makro neu laufen lassen (ohne Haken im "30m-Feld")

 

[Lutz!]

Vielen Dank. Problem gelöst!

 

[js_plasma]

Es gibt ein eigenens "Elevation" Makro fürs GSAK.
Damit dass aber korrekt läuft, muss vorher die RESOLUTION-Zelle auf Leer gesetzt werden.
Dazu am besten erst eine Filter setzen, der nur alle Cache beinhaltet, die als Elevation "0" haben.
Dann über Database -> Global Replace die RESOLUTION auf den leeren Wert setzen lassen.
Anschliessend das Elevation Makro laufen lassen.
Danach hat es bei mir immer gepasst.

Warum das passiert weiss ich aber auch nicht.

so, jetzt bin ich - als der threadersteller - auch endlich mal dazu gekommen, das nachzuvollziehen.... ES HAT GEKLAPPT! die höhenmeter stimmen jetzt wieder!

danke an NoPogo für den wertvollen tipp!

 

[Angrentil]

PS: Was bewirkt der Haken bei "Use Aster 30m Data", bzw. sollte man den setzen oder nicht?

Der Haken bei "30mData" bewirkt meines Wissens nichts, da dann auf Daten zugegriffen wird, die für Europa (noch?) nicht verfügbar sind sondern nur für die USA. Sicher bin ich mir nicht, habe aber bei mir noch keinen Unterschied festgestellt und setze ihn daher nie.

Oh, oh... nicht mit Unwissen glänzen, sondern nachfragen.

Die Höhenangaben müssen aus einem zuvor berechneten Höhenmodell gezogen werden. Per default werden die Höhendaten hier wohl aus einem Modell gezogen, das mit Hilfe von SRTM-Daten (Radardaten!) mit 90m Auflösung gerechnet wurde. Hier gilt: frei verfügbar gibt es die nur für die USA mit 30m Auflösung, der Rest der Welt muss sich mit 90m Auflösung begnügen.

Das SRTM-Höhenmodell ist aber nicht das einzige Modell, es gibt auch die Variante wo die Höhendaten aus ASTER-Daten gerechnet werden. ASTER-Daten sind optische Daten... (sprich das ist ein anderer Sensor als der, der Radardaten aufnimmt, wodurch sich die Art der Daten wieder grundlegend unterscheidet, was auch Folgen für das berechnete Höhenmodell hat, usw, usw... wen das wirklich interessiert der kann selbst mal nachlesen).

Das ASTER-Modell hat mit einer Auflösung von 30m also eine höhere Auflösung als das SRTM-Modell. Allerdings heißt das nicht pauschal das es immer besser ist... in flachen Gebieten sollten die Unterschiede minimal sein, eigentlich gar nicht vorhanden. In stark zerklüfteten Gebieten werden sich hingegen schon eher Unterschiede feststellen lassen... also zum Beispiel in den Alpen.

Wie gesagt: es gibt jetzt kein pauschel: dieses ist immer genauer... das ist stark gebietsabhängig. Aber ich hab das Häkchen gesetzt und lasse mir dir Höhendaten aus dem ASTER-Modell auslesen.