QMapShack: berechnete Höhenmeter

  • Wenn ich die Punkte-Tabelle in QMapshack richtig interpretiere, dann werden Höhenänderungen erst ab einem Schwellwert von 5m aufsummiert. Woher kommt dieser Schwellwert? Für welche Situationen und welche Geräte ist er adäquat?


    Für meinen Testfall – die Route 10vorGraz, eine hügelige Runde von 93km im Westen von Graz – berechnete QMapShack folgende Anstiege:


    Anstieg Höhendaten
    1980 hm SRTM-3
    1690 hm SRTM-1
    1710 hm DEM 10m AT
    1645 hm Baro (Edge 1030)


    Zielwert: 1773 (1733 … 1801) hm


    Laut Tabelle ist der Schwellwert von 5m eigentlich gut gewählt: für die schlechtesten Höhendaten (SRTM-3) ist der berechnete Anstieg zu hoch und für die besten Höhendaten (Baro) zu niedrig.


    Diese mittige Lage hat den Nachteil, dass der Track mit den besten Höhendaten mit einem unnötig hohen Fehleranteil belastet wird. Wäre es nicht sinnvoll den Schwellwert variabel zu gestalten und an die Qualität der Höhendaten anzupassen?


    Eine gute Lösung ist bei GPS Visualizer (wähle "Yes" bei "Calculate elevation gain") zu sehen.

  • Der Wert und der Algorithmus sind über die Zeit empirisch entstanden und liefern für GPS Aufzeichnungen aller Art halbwegs realistische Werte. Die Diskussion zu den Höhenmetern gibt es seit dem es GPS Geräte gibt. Vorher hat man Höhenlinien gezählt.


    Im Grunde macht das auch QMapShack so. Es zählt die über- und unterschrittenen 5m Höhenlinien. Das liefert bei echten Anstiegen gute Werte, die halbwegs unabhängig von der Anzahl der Messwerte und den Fehlern des Gerätes sind. Für andere Experimente wie Radeln im Flachland und 20mal um den Parkplatz rennen ist diese Art der Berechnung nicht zu gebrauchen. Anderseits muss man sich auch ernsthaft fragen, warum man bei solchen Aktivitäten den Anstieg der Höhenmeter überhaupt wissen will.


    Der Schwerpunkt bei QMapShack liegt beim Planen, Auswerten und Archivieren von Touren. Und das für ein Publikum, das so etwas überhaupt noch auf dem PC macht. Als QMapShack noch von Bitbucket gehostet wurde lief eine Zeitlang Google Analytics mit. Das Publikum von QMapShack ist männlich und 45..70 Jahre alt. Für dieses Publikum sind die schon vorhandenen Möglichkeiten Dinge zu konfigurieren eine Zumutung bis hin zur Überforderung. Das ist aber die Zielgruppe.


    QMapShack kann vieles und auch vieles nicht. Wer wissenschaftlich mit Karten und GIS Daten arbeiten will, benützt eher QGis. Wer trainieren will benutzt Software in der Cloud. Wer noch tollere Experimente machen will, kann mit Skriptsprache und Datenbanken umgehen.


    Die Benutzer von QMapShack sind glücklich, wenn sie ihre Tracks auf dem Bildschirm sehen und ein paar Auswertungen dazu. Eine Diskussion, wie diese Daten zustande kommen und wie man Parameter einstellen müsste, um das Ergebnis zu optimieren interessiert die wenigsten.


    Deswegen müsste es schon sehr gute Argumenten für einen konfigurierbaren Parameter geben. Und dann stellt sich immer noch die Frage, wie man das kommuniziert, bzw sogar automatisch richtig machen kann. Es gibt schon zu viel Software, die in Konfigurationsparametern ertränkt wurden, nur weil man es jedem irgendwie recht machen wollte.


    Ich bin durchaus offen darüber zu diskutieren, ob der aktuelle Algorithmus und die aktuelle Parametrierung das gelbe vom Ei sind. Und wenn gezeigt werden kann, dass es etwas Besseres gibt, das für viele Geräte eine Verbesserung bringt, bin ich dabei. Eine Optimierung für einzelne Anwendungen bzw. Geräte kann aber nur passieren, wenn dadurch der Rest nicht leiden muss.


    In diesem Sinne der aktuelle Algorithmus ein halbwegs akzeptabler Kompromiss.

  • Wo radelst du, dass du 1773 hm Flachland nennst?

    :-))


    Ich verstehe das durchaus. Der Anwender muss etwas investieren, wenn er sich für dieses Thema interessiert. Wo die Interessen des typischen QMS-Anwenders sind, weiß ich nicht, darum poste ich die Frage ja hier.


    Gut möglich, dass deine Einschätzung zutrifft. Für mich ist auch das voll ok.

  • Wo radelst du, dass du 1773 hm Flachland nennst?

    :-))

    Natürlich nicht ;) Aber wenn ich deine Ausführung richtig verstanden habe, addierst Du alle Deltas und belegst das Ergebnis mit einem Korrekturfaktor, um das Rauschen zu kompensieren. Richtig?


    Kann man so machen. Naturgemäß kommt man damit auf etwas mehr Höhenmeter, da wirklich jeder Anstieg und sei er noch so gering, gewertet wird. Zudem ist das Ganze auch recht abhängig von der Menge der Messwerte. Je enger das Raster, je mehr Deltas könne zum Auf- und Abstieg beitragen.


    Man kann das natürlich auch anders sehen. Ein Bergsteiger würde jetzt nicht jede Bodenwelle mit einbeziehen, wenn er eine Tour einschätzen will. Es sei denn er will seine Leistung schön rechnen ;) Deswegen auch die Idee mit der Hysterese von 5m. Wenn die Bodenwelle 5m hat, dann wird sie mitgenommen. Ansonsten kann ich zwischen den 5m Linien so oft ich will ein paar Meter an- und absteigen, es bleibt eine Bewegung in der Ebene, die nicht beiträgt.


    Wie man das sieht und welchen Algorithmus man für besser hält ist eigentlich egal, wenn man zu mindestens zwei Dinge akzeptiert:


    * Einfach alle Deltas aufzuaddieren, ohne irgend etwas anderes zu machen, ist der denkbar schlechteste Algorithmus.


    * Um Touren über die Höhenmeter vergleichen zu können, sollte man konsequent immer beim selben Algorithmus und der selben Parametrierung bleiben.


    Nur so kann man zum Schluss sagen, dass die Tour A mit 1200 Hm anspruchsvoller ist als die Tour B mit 800Hm. Wenn ich mir teilweise die Angaben auf Tourportalen ansehe, dann wird das nicht eingehalten. Meine eigenes Tourenarchiv geht bis 2006 zurück und umfasst 3 Garmin Generationen. Die Ergebnisse für Touren, die ich während dieser Zeit mehrmals gegangen bin, sind erstaunlich ähnlich. Wie viele Höhenmeter es genau waren, werde ich nie wissen :D

  • Ach ja wie lustig. Da sieht man eigentlich nur den ganzen Wahnsinn des Themas. Bei QLandkarte habe ich genau das Gleiche gemacht und bin dann davon abgekommen. Also komplett die andere Richtung.


    Eine reine Mittelwertbildung mit einem linearen Filter, geht halt nur mit Aufzeichnungen, die die Abtastkriterien einhalten. Das trifft auf kaum einen Track zu, den man so im Internet findet. Und die meisten Benutzer sind sich dessen nicht bewusst und stellen ihre Geräte nicht dem entsprechend ein. Also habe ich mich eines Algorithmus aus der Bildverarbeitung von Satelliten beholfen. Dem Medianfilter (Hint: den gibt es heute noch in QMapShack) Nach einer Medianfilterung wurde der Auf- und Abstieg ganz klassich über die Summe der Deltas berechnet.


    Das Ergebnis war mir dann aber doch zu wenig nachvollziehbar und auch zu abhängig von der Qualität der Aufzeichnung. Mit der Hysterese ist die Streuung geringer. Klar, große Ausreißer schlagen hier voll zu Buche. Allerdings sind die Empfänger inzwischen dann doch etwas besser und wer solche Berechnungen nur mit der reinen GPS Höhe anstellt ist selber Schuld.


    Aber wie schon gesagt, hier darf jeder seiner eigenen "Religion" folgen. Wir kenne alle nicht den wirklichen Wert von Auf- und Abstieg.

  • kiozen

    Zitat

    > Aber wenn ich deine Ausführung richtig verstanden habe, addierst Du alle Deltas und belegst das Ergebnis mit einem Korrekturfaktor, um das Rauschen zu kompensieren. Richtig?

    Nein, es läuft anders. Ich beginne mit dem 1. Punkt der Aufzeichnung (=Ref1). Danach werden alle Punkte ignoriert, deren Höhendifferenzen zu Ref1 kleiner als ein Schwellwert sind. Der Punkt der den Schwellwert als erstes überschreitet ist Ref2. Die Höhendifferenz Ref2-Ref1 wird kumuliert. Das wiederholt sich nun mit Ref1 <-- Ref2.


    Ich hab mich nicht mit Algorithmen für Höhensummenberechnungen beschäftigt, das war das Erste, das mir eingefallen ist. Mir ging es primär um die Trennung von Nutz- zu Störsignal.



    Zitat

    Wir kenne alle nicht den wirklichen Wert von Auf- und Abstieg.

    Brauchen wir auch nicht. Wir sollten nur in die "Nähe" kommen, wobei "Nähe" natürlich quantifizierbar sein muss.




    JürgenB

    Zitat

    Ich komme beim SRTM1-Track auf 1643m, und beim SRTM3-Track auf 1691m

    Der geringe Unterschied zwischen SRTM-1 und SRTM-3 ist bemerkenswert gut. Änderst du die Filterparameter in Abhängigkeit vom Signal?


    Für den Track mit den Baro-Daten scheint die Filterung etwas zu kräftig zu sein: ShowGPX zeigt mir +1620 hm an, bei einem Erwartungswert von +1782 hm.