QMapShack: berechnete Höhenmeter

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.

Zitat von robhubi

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

Hallo,

ich hatte auch mal einen Algorithmus mit Schwellwert und Hysterese. Inzwischen glätte ich die Höhenwerte und addiere die Intervalle dann nur noch. Ich komme beim SRTM1-Track auf 1643m, und beim SRTM3-Track auf 1691m.

Gruß

Jürgen

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.

Zitat

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