Wo bleibt die (Delta-)-Höhe des nächsten Routenpunktes (GoToAltitude)?

    Liebe Glopus-Gemeinde!
    Glopus vereint eine Menge nützliche Dinge für eine anständige Outdoor-Navigation oder Geocaching.
    Klare Sache. Auch die benutzereigene Seiten sind genial.
    So kann jeder die Information anzeigen lassen, die er für Notwendig erachtet.


    Was mir als Wanderer oder Radfahrer fehlt ist die Höhe vom oder zum, als Delta, nächsten Routenpunkt oder Wegpunkt überhaupt.
    Ich halte diese Information für durchaus von Interesse. Eigentlich sollte diese Information bereits in der Software (Algorithmus) implementiert sein, da nur so die Luftlinie zum nächsten Routenpunkt annähernd korrekt sein kann. Stichwort: Raumdiagonale!


    Sicherlich ist nicht jede Route aus dem Internet mit einem Höhenprofil unterlegt. (Lässt sich sicherlich nachtragen).
    Aber ein POI kann mit einfachen Mitteln mit einer Höhe versehen werden. Stichwort: GoogleEarth!


    Ich finde es wünschenswert, wenn die Höhe und Deltahöhe angezeigt wird.
    Sowohl in einer POI-Liste, Routenliste als auch in der Karte als Ergänzung zum Namen des POI.
    Es gibt GoToDistance, GoToDirection, GoToName und zumindest auf der "Goto Seite" wahrscheinlich ein GoToTime (Ankunft).
    Warum gibt es nicht GoToAltitude?


    Theoretisch ist (sollte) der Wert bereits im Algorithmus stecken, er muss "nur" ausgespurt werden.
    Gruß Minni

    Einmal editiert, zuletzt von minni ()

    Glopus verarbeitet keine Höhendaten!


    Ausser beim schreiben des Log's und was direkt damit zusammenhängt (Höhenansicht...) gibts es keine Höhen!


    Auch ist in Glopus weder bei Routen noch bei POI's Datenfelder für Höhen vorgesehen - auch wenn sich Glopus an das Kompass-TK-Format anlehen (Dort ist in der 3.Spalte die Höhen drin, wird dieses Feld für Kommentare verwendet.


    Sicher läßt sich alles Programmieren - schauen mir mal was die Zukunft noch alles so bringt!


    Gruß
    Silver

    Regioausflug.de Wandertourenplaner für Odenwald, Rhön, Mittelrhein und Taunus!!!!


    Ein Stau ist nur hinten blöd - vorne gehts !!!!

    Ich denke hier muss man zwischen "Routen" und "Tracks" unterscheiden. Routenformate führen normalerweise keine Höhe, aufgezeichnete Tracks schon. Glopus selbst arbeitet generell mit Rasterkarten ohne Höheninformation (ob's die in IMG gibt?) und kann demzufolge auch nicht nachträglich Höhen ergänzen. Anders ist das bei den Topokarten der Vermessungsämter. Kompass TK (was Glopus als Routen-Input nimmt) kannte ich auch nur als Long/Lat Koordinaten mit 2 Zahlenfeldern. Allerdings habe ich einige Tourenvorschläge auf der Kompass-Seite gesehen, die eine 3. Spalte mit Höhe führen. Da es direkt von der Kompass-Seite kam vermute ich, dass sie das als neuen Standard führen, zumindest optional. Für Bergtouren ist das durchaus sinnvoll.


    Wer sich für die Höhen interessiert sollte sich die topografischen Kartenprodukte anschauen: Geogrid-Viewer mit den Karten des Landesamtes für Vermessung (mit Navigation-Plugin), MagicMaps, Kompass etc. Zumindest beim Geogrid gibt es die Option, höhenlose Routen einzulesen und mit Höhenangabe abzuspeichern. Dabei übernimmt man die qualitativ hochwertigen Vermessungsdaten der zuständigen Ämter. Auf Google-Höhendaten würde ich mich weniger verlassen. Mit den Stichproben die ich kenne war ich weniger zufrieden (kleine Berkkuppe ins Tal verlegt). Auch die GPS-Höhenmessungen sind relativ unzuverlässig, gerade im Gebirge (Multipath-Effekte). Die angesprochenen Kartenprogramme bieten auch schöne Höhendiagramme zum Ausdrucken, für die Tour. Für interessante Punkte (POI/Waypoint), Gipfel, Berghütten etc. könnte man leicht per Script die Höhe auch in Klammern ins Beschreibungsfeld setzen, was dann im Kartendisplay erscheint. Ist zwar kein Delta, aber zumindest weiss man dann wie hoch es noch geht.

    Silver34

    Zitat

    Glopus verarbeitet keine Höhendaten!

    Und wie wird dann die Entfernung zum nächsten Wegpunkt gemessen? Einfach in der Ebene? Das wäre dann ziemlich realitätsfremd - Oder? So eine Raumdiagonale ist kein echtes Hexenwerk. Da sich der nächste Wegpunkt normalerweise in der Nähe befindet, kann man locker das Delta zwischen dem aktuellen Standort und des nächsten Wegpunktes als realitätsnahem Wert annehmen. Die eventuellen Fehler könnten dann vernachlässigt werden. Eventuell könnte der Korrekturparameter für die Höhe als Faktor zur Normierung (Nullung) herhalten. Also eine offizielle Markierung vor Ort mit der GPS-Maus in Einklang bringen.


    frank334

    Zitat

    Für interessante Punkte (POI/Waypoint), Gipfel, Berghütten etc. könnte man leicht per Script die Höhe auch in Klammern ins Beschreibungsfeld setzen, was dann im Kartendisplay erscheint. Ist zwar kein Delta, aber zumindest weiss man dann wie hoch es noch geht.

    Mit dieser Methode arbeite ich bereits. Der name des Wegpunktes (Routenpunkts) wird mit der Höhe ergänzt.
    Zum Beispiel mit einer csv-Datei in Excel die Textspalten verketten und wieder als csv-Datei speichern.
    Geht recht schnell. Sicherlich ist es einfacher, die Möglichkeit den <ele>-Parameter anzuzeigen.
    Oder in einer Wegpunkte-Liste als Spalte auszugeben.


    Interessanterweise habe ich noch keine Software gefunden, die sich mit der Höhe, "rumärgert".


    Ich suche eine Wegpunkt-Tabelle (Routenpunkte), die sich nach der Entfernung selbstständig abarbeitet, die Entfernung, Bearing und Deltahöhe anzeigt. Beim Erreichen Töne abgibt, in Abhängigkeit zur Entfernung und dann zum nächten vorgebenen Routenunkt springt.


    Gruß Minni

    Zitat von minni

    Und wie wird dann die Entfernung zum nächsten Wegpunkt gemessen? Einfach in der Ebene? Das wäre dann ziemlich realitätsfremd - Oder? So eine Raumdiagonale ist kein echtes Hexenwerk. Da sich der nächste Wegpunkt normalerweise in der Nähe befindet, kann man locker das Delta zwischen dem aktuellen Standort und des nächsten Wegpunktes als realitätsnahem Wert annehmen.
    ..

    Und die Luftlinie ist weniger realitätsfern? Kannst du fliegen? In den Bergen wird dein Wanderweg locker doppelt so lang sein wie die Luftlinie. Ich bin jedenfalls zufrieden mit der aktuellen Höhe und der Zielhöhe. Das Delta geht noch gut mit Kopfrechnen. Gut, die Gesamtlänge eines Bergpfades könnte interessant sein, zur Abschätzung wie lange es noch dauert. Dabei kann man sich leichter verschätzen. Dazu müsste man über den 3D-Pfad die Länge bis zum Ziel addieren (der muss dazu dann aber auch detailliert genug sein). So ähnlich wie es die Autonavis mit der Restfahrzeit/-weg machen. Das wäre vielleicht interessant für Glopus. Ich weiss nicht, ob intern in der Zielliste die Höhenangabe gespeichert werden kann. Sinnvoll wäre das schon, obwohl in der Regel bzw. im Flachland das keine Rolle spielt - daher auch optional bleiben muss. Die Rasterkarte hat zumindest keine Höheninformation, wenn in den Routenpunkten auch keine gespeichert wird dann gibt es gar keine.

    frank334
    Die Luftlinie (GoToDistance) ist fast immer fehlerbehaftet. Ob 2D oder 3D.
    Somit kann auch die Flächendiagonale zur Raumdiagonalen werden. Mit der Deltahöhe.
    Sicherlich ist in den Bergen die Abweichung Flächendiagonale und Raumdiagonale zum gelaufenen Weg erheblich.
    Jedoch ist die Raumdiagonale näher dran, weil immer länger als die Flächendiagonale.

    Zitat

    Ich bin jedenfalls zufrieden mit der aktuellen Höhe und der Zielhöhe. Das Delta geht noch gut mit Kopfrechnen.

    Aha - Die Zielhöhe (GoToAltitude)! Meine Rede! Die Zielhöhe möchte ich auch sehen und ohne Umweg über Excel.
    Die Information steht in der Wegpunkte-Datei.
    Gruß Skater
    PS
    @womisa = Sherlock Holmes :whistling:

    Zitat von minni

    Die Information steht in der Wegpunkte-Datei.

    Naja, so einfach ist das ja nicht. Es gibt verschiedene Definitionen. Kompass TK hat als optionale 3. Spalte die Höhe (Trackformat). Andererseits möchte man bei Wegepunkten auch einen Namen vergeben. Dazu gibt es ein CSV-Format mit einem Bezeichner in der 3. Spalte (POI, mit lon/lat vertauscht), was aber nicht TK-kompatibel wäre. Beides zusammen habe ich noch nicht im CSV gesehen (ausser für meine spezielle Octave-Matrixform zum Speed-Plot). GPX und KML hat Platz für beides, aber ich weiss nicht, ob Glopus alle Felder auswerten kann. Insbesondere für die Höhe müsste wahrscheinlich Glopus intern die Datenstrukturen aufweiten. Das kann aufwendig sein, insbesondere weil ja fallweise gar keine Höhen vorliegen können.


    p.s. hat eigentlich Openstreetmap die Höhe in den internen Datenstrukturen? Ich kannte dort auch nur 2D. Da aber die Karte aus GPS-Messungen aufgebaut wird, wäre es nicht ungeschickt, die Höhe gleich mitzuverarbeiten. Ok, GPS-Messungen diesbezüglich sind nicht sonderlich genau, aber immerhin kostet das 3. Feld nicht viel Speicherplatz. Und für die Bergtourplanung wäre es praktisch, wenn der Pfad mit Höhendaten versehen wird.
    Aufpassen muss man mit den Bezugsgrößen: die GPS-Höhe ist nicht gleich der üblichen Höhe über N.N. im Koordinatensystem (Postsdam-Datum) der Vermessungsämter. Die Differenz ist etwa 48m. Wenn man von WGS84-GPS-Daten spricht darf man letztere eigentlich nicht benutzen. Manche machen es trotzdem und stiften dann Verwirrung (sogar Hersteller von GPS-Artikeln).

    Ich habe ein paar Punkte mit GoogleEarth gespeichert als kml. Mit Routeconverter werden die Orte als Punkte dargestellt. Ohne Höhe. Nachdem markieren der Orte kann mit "Füge Höhe hinzu" die Wegpunkte mit der Höhe ergänzt werden. Woher diese Höheninformationen stammt kann ich nicht sagen, aber ein kurzer Vergleich mit offiziellen Daten, ergibt, dass die Höhenangaben durchaus der Realiät entsprechen.
    Der Export in "Haicom Logger csv" ergibt folgenden Header:
    INDEX,RCR,DATE,TIME,LATITUDE,N/S,LONGITUDE,E/W,ALTITUDE,COURSE,SPEED,
    2,T,,,46.49712,N,9.83846,E,1834.0m,0.0,0.0km/h
    GPX-Standard
    <wpt lon="9.838456" lat="46.497116"> <ele>1834.0</ele>
    Kompas tk
    46.4971160,9.8384560,1834.0
    nmea
    $GPGGA,,4629.8270,N,00950.3074,E,1,,,1834.0,M,,M,,*44
    $GPWPL,4629.8270,N,00950.3074,E,Sankt Moritz; Schweiz*55
    und sicherlich weiter Formate mit der Höhenangabe.


    Zumindest gibt es Möglichkeiten aus Koordinaten die Höhe zu ermitteln und diese in diverse Formate zu exportieren.
    Also an der Existenz der Höhe sollte niemand scheitern.
    Gruß Minni

    2 Mal editiert, zuletzt von minni ()

    So das mit dem Koordinaten nee Höhe hinzufügen ist ja nun geklärt.


    Was genauso wie der Routeconverter geht ist GPS-Track-Analyse.net - ich nehme an das die alle die freien hgt-Dateien der >NASA< verwenden (90 Meter-Rater mit allen ungenauigkeiten der Radamessung).


    Nun müst ihr euch noch gute Argumente überlegen um Peter davon zu überzeugen das auch reinzuprogrammieren.
    Ich hab bis jetzt die Deltahöhe noch nicht vermisst - was auch kein Wunder bei Routenpunktabstände von meist 50 m - da ist selbst die 10m Anstieg (bei 20% Steigeung) noch unterhalb der Geauigkeit die grad an Bergen oft >20 m ist.


    Gruß
    Silver

    Regioausflug.de Wandertourenplaner für Odenwald, Rhön, Mittelrhein und Taunus!!!!


    Ein Stau ist nur hinten blöd - vorne gehts !!!!

    Ich muss mich korrigieren: in GoogleEarth habe ich gerade nochmal die Höhen geprüft. Früher vor 1-2 Jahren hatte es mal die Häuser am Fuße eines Schloßberges auf den Berg gesetzt, also ziemlich daneben. Jetzt scheint die Lage etwa zu stimmen. Die Höhe der Kuppe stimmt jetzt sogar mit der amtlichen Karte überein. Anscheinend hat man bei Google nachgebessert, entweder mit den Daten der Vermessungsämter, oder durch ein besseres einkalibrieren der STRM-Daten. Die Ergänzung der Höhe durch GPS-Track-Analyse.net mit den STRM-Daten ergibt jedoch Abweichungen von 10-50m, je nach Geoidkorrektur. Eigentlich gibt es sogar 3 Höhen: die WGS84 Ellipsoid-Höhe, die WGS84 Geoid-Höhe und die Höhe im amtlichen Koordinatensystem (Postdam-Datum oder ED). Was im einzelnen in den Datensätzen verwendet wird ist mir schleierhaft. Gottgegeben würde ich nur die Daten unserer Vermessungsingenieure nehmen (Topokarte). Alles andere driftet mit der Zeit weg oder ist prinzipbedingt ungenau.

    Silver34
    In erster Linie geht es mir nicht um den Route selbst, die vor mir liegt. Sicherlich ist eine Route eine Anhäufung von Wegpunkten, die zusammengefasst werden. Ein Track ist eine vollständige Aufzeichnung einer Strecke. So mein Verständnis zur Route und Track. Sicherlich hätte ein sichtbarer 3D-Höhenverlauf einer Route auch einen Charme, ähnlich GTA.NET. Mutmaße aber jetzt eine Menge Arbeit für Peter.


    Mir geht es um echte Wegpunkte (Ziele, POI):
    Kreuzungen, Richtungswechsel, Wegänderungen (befestigt / unbefestigt), Landschaftspunkte und -merkmale (See, Berggipfel), Aussichtspunkte (Foto), Parkplatz, Schutzhütten, bewirtschaftete Almhütten (Skihütte), Liftstation (unten, oben) und so weiter.


    In einem unbekannten Gebiet, ohne Track oder Route, sind die wichtigen Wegpunkte zur Orientierung hilfreich und eben manchmal ist auch eine Höhenangabe dorthin zweckmäßig.


    Denkbar ist es auch für Geocacher. Ich nähere mich zwar dem Cache und stehe plötzlich auf einer Klippe.
    Oder ein Bekannter hat mir erzählt, dass bei einer Lawinensuchübung, die Rettungsmanschaft zwar in die richtige Richtung marschiert ist, aber leider die Höhenangabe des "Opfers" nicht im Blick hatten. Sie standen sämtlichst vor dem Abgrund!


    Sofern der Wert eines echten Wegpunktes gegeben ist, sollte dieser Wert (abschaltbar) in der Karte angezeigt werden.
    Beziehungsweise auch in einer entfernungsabhängigen Wegpunktetabelle: Name - Entfernung - Höhe - Lat - Lon
    Wenn sich die Höhe in der Karte oder in der Wegpunkttabelle noch als Delta (wahlweise) anzeigen lässt, ist das Ergebnis perfekt.


    Gruß Skater

    Hallo Skater,


    als Notbehelf kann man die Höhe in die *.tk Routendatei eintragen. Das ist auch mit einem Programm, welches die SRTM Daten auswertet, relativ einfach machbar.
    Ist zwar nicht das was du anstrebst, aber als Übergangslösung zu deinem Problem ein Schritt in diese Richtung....


    MfG
    Achim

    @womisa
    Das Bild gefällt mir. Und auch die Idee neben die eigentlich namelosen Routenpunkte die Höhe zu schreiben.
    Jetzt noch eine Anleitung wie ich aus einer gpx (lat, lon, ele), csv oder kml diese tk-Route erstelle.
    Insbesondere soll diese Datei noch Glopus tauglich sein.
    Gruß minni
    PS
    Trotzdem sollte Peter die Delta-Höhe in die Entfernungsmessung einfließen lassen sollte und parallel dazu die Höhe von nächsten Punkt als GoToAltitude oder DeltaGoToAltitude auswirft.

    Zitat von minni

    Das Bild gefällt mir. Und auch die Idee neben die eigentlich namelosen Routenpunkte die Höhe zu schreiben.
    Jetzt noch eine Anleitung wie ich aus einer gpx (lat, lon, ele), csv oder kml diese tk-Route erstelle.
    Insbesondere soll diese Datei noch Glopus tauglich sein.

    Aber das ist doch genau das, was Glopus mit TK-Routen macht. Beim Import wird die 3. Spalte als ASCII-Bezeichner interpretiert. Das ist zwar nicht TK-Standardkonform, macht aber genau das was du willst. RouteConverter bspw. exportiert Kompass TK mit Höhenangabe in der 3. Spalte. Zum Gpsbabel habe ich ein Style definiert, der zum TK die Höhenangabe ergänzt.


    Im übrigen würde ich aber wenn es dir auf das Höhenprofil ankommt gute topografische Karten nehmen. Dort stehen die Höhen von markanten Punkten als Zahlenwert drin. Auch dein Beispiel mit der Suchmannschaft am Abgrund ist nicht so dramatisch mit der richtigen Karte. Gerade solche Details sind dort sehr schön mit Felszeichnungen bebildert. OSM-Derivate können da nicht mithalten. Obwohl OSM gelegentlich vorteilhaft ist, da wo Waldwege der Topokarte nicht mehr existieren bzw. unbefahrbar sind. Es fehlen bei OSM zwar viele Wege, dagegen hat die Topokarte auch viele Waldwege verzeichnet, die längst verschwunden sind. Offenbar hat das Vermessungsamt viele Updates verschlafen. Mir ist das unverständlich, da sie direkt an der Quelle der Katasterämter hängen. Es muss doch sonst jede bauliche Veränderung gemeldet werden. Vermutlich auch das Anlegen oder Entfernen von Wegen.