Zum Inhalt springen

Elevation in GSAK V8


Männi

Empfohlene Beiträge

FIndStatGen hat doch eine eigene Höhenfunktion, die automatisch beim Erstellen der Statistik aufgerufen wird, falls bei einem Cache noch keine Höhe eingetragen ist. Allerdings stimmen die Höhen nicht immer, manchmal bleiben da auch 0m stehen, allerdings wird behauptet, diese aus der 90m-Auflösung heraus gelesen zu haben.

 

elevation.gsk greift wohl auf eine Datenbasis mit 30m-Auflösung zurück, was bei Gipfeln natürlich immer noch nicht stimmen muss.

 

Gruss aus Cham

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das Makro elevation.gsk verwende ich auch. Aber natürlich funzt das bei Mysteries nicht, da er den Ankerpunkt nimmt. So bin ich auch schon zu einem Unterwassercache gekommen, ohne jemals einen Taucheranzug getragen zu haben :D. Vermutlich müsste man das Makro modifizieren, damit es auch Final-Waypoints berücksichtigt. Oder eben brav die Koordinaten korrigieren...

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das Makro elevation.gsk verwende ich auch. Aber natürlich funzt das bei Mysteries nicht, da er den Ankerpunkt nimmt. So bin ich auch schon zu einem Unterwassercache gekommen, ohne jemals einen Taucheranzug getragen zu haben :D. Vermutlich müsste man das Makro modifizieren, damit es auch Final-Waypoints berücksichtigt. Oder eben brav die Koordinaten korrigieren...

Ich habe das nicht kontrolliert, aber ich hätte erwartet, dass er bei Caches, für die Du in GSAK "Corrected Coordinates" eingetragen hast auch diese verwendet, für den Lookup. Zumindest für die Zuordnung zu County/State wird das verwendet, gemäss Aussagen im GSAK Forum.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das Update der Elevation ist seit längerem im findstats Makro enthalten, es kommt ja sogar mit einem Dialog falls es Cache ohne Daten findet. Das separate Markro muss eigendlich nicht laufengelassen werden, ausser man will die Höhendaten generell auch für Caches die man nicht gefunden hat und die in der Statistik gar nicht benötigt werden.

Ausser in den USA muss man sich mit dem 90m Grid abfinden, ist natürlich in den Bergen völlig ungenau...

 

Siehe auch http://www.swissgeoc...h=1

Von wo kommen diese Daten ? http://de.wikipedia.org/wiki/SRTM-Daten

Bearbeitet von gzxto
Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich nur für die Statistik auf meinem Profil. Die ist eigentlich völlig unwichtig beim Cachen und eine Spielerei... Aber auch grosse Männer spielen gerne ;)

Genau, so wie auch Cachen eigentlich eine völlig unnötige Spielerei ist. Da spielen aber für mich lebensnotwendig ist, gehört Cachen oder so eine Statistik eben doch zu den wichtigen Seiten im Leben.... :D

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich habe das nicht kontrolliert, aber ich hätte erwartet, dass er bei Caches, für die Du in GSAK "Corrected Coordinates" eingetragen hast auch diese verwendet, für den Lookup. Zumindest für die Zuordnung zu County/State wird das verwendet, gemäss Aussagen im GSAK Forum.

Sagte ich ja :). Allerdings habe ich die Angewohnheit gelöste Rätsel im GSAK mittels Final-Waypoints zu erfassen. Grund 1: Gelegentlich heisst es ja der Ankerpunkt ist der Parkplatz - also behalte ich den gerne. Grund 2: Ich habe mehrere DBs (pro Land eine + eine für die Finds) und kopiere mehrfach zwischen denen hin und her. Und das "mergen" der Waypoints geht tadellos, bei anderen Dingen habe ich mir so schon Sachen überschrieben (Beispiel: Kommentar zu Cache X in DB A erfasst und in DB B nicht. Kopiere ich nun von DB B nach A, dann wird der Kommentar überschrieben mit einem leeren Kommentar - Waypoints hingegen werden brav angefügt.)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...