Beiträge von robhubi

    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.

    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.

    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.

    Hi,

    Ich habe einen Tiff-File georeferenziert und als VRT in QMS eingebunden. Mein Problem damit ist, dass ich nicht weit genug hineinzoomen kann. Rauszoomen geht hingegen bis zur Stecknadelgröße. Den Skalierungsbereich anzupassen hat nicht geholfen.



    Das Bild oben zeigt die maximale Zoomstufe, bei der die Rasterkarte noch sichtbar ist.

    In der Mitte ist eine Stufe hineingezoomt, die Rasterkarte ist weg, die darunterliegende Karte wird sichtbar.

    Ganz unten ist die Rasterkarte bei 100% Skalierung im Tiff-File zu sehen. Zumindest so weit würde ich gerne hineinzoomen können.


    Hat jemand einen Tipp für mich?

    Mein System: QMS1.14.0; win7 Pro 64bit


    Vielen Dank!

    Robert

    Seit kurzem fahre ich mit der Luxos U von Bumm. Mit dem Licht bin ich sehr zufrieden nur der USB-Betrieb mit dem Oregon 650 machte Probleme. Zur Analyse habe ich die Stromaufnahme gemessen.


    Messbedingungen
    Displaybeleuchtung aus, Gerät liegt ruhig am Tisch und wird nicht berührt. Alle übrigen Einstellungen wie bei Echtbetrieb. Bei den 3 Versuchen werden die USB Datenleitungen und der Batterietyp variiert.


    Ablauf
    Der USB-Anschluss wird auf 5V gelegt und die Stromaufnahme über die Zeit gemessen.



    Zoom


    Ergebnisse
    Es sind 3 Stromniveaus vorhanden:


    0,77 A
    Der höchste Strom fließt, wenn die USB-Datenleitungen kurzgeschlossen sind und der interne Akku geladen wird.


    0,46 A
    Der mittlere Strom fließt, wenn die USB-Datenleitungen offen sind und der interne Akku geladen wird.


    0,17 A
    Der kleinste Strom fließt bei Batteriebetrieb (Schalter im Batteriefach ist nicht gedrückt). Die USB-Datenleitung hat keine Auswirkung.



    Das Original USB-Kabel von Bumm hatte die Datenleitungen kurzgeschlossen. Damit war die Stromaufnahme für die Luxos U viel zu hoch.
    LG Robert

    Ich hab mit gmaptool die TYP-Files der funktionierenden und der nichtfunktionierenden Europakarte extrahiert und hochgeladen. Mit dem Typ-File "000TK_EU_ok.TYP" werden die Wanderwege dargestellt.
    Der zweite File "000TK_EU_notok.TYP" ist die Variante, die keine Wanderwege anzeigt, stattdessen aber die Namen.


    Vielleicht kann es ja jemand gebrauchen.

    Ich sehe auch keine Tracks aus diesem IMG.


    Vielen Dank fürs Ausprobieren!
    Hast du ein Windows System?

    Auch die Europa Wanderwege von der ThKukuk Homepage zeigt nix an.


    Bei der aktuellen Europa TK-Wanderwege seh ich auch nichts. Interessanterweise habe ich noch eine ältere Version aus dem Vorjahr, die funktioniert.
    Der Autor meinte zwar, er habe schon lange nichts mehr geändert, aber die Daten ändern sich, die Tools ändern sich, das OS ändert sich ...
    Es wäre schon hübsch, wenn man dem Autor einen konkreteren Problemhinweis geben könnte, als nur geht nicht.



    Installieren hab ich nicht ausprobiert.


    Ich auch nicht, da ich kein Basecamp/Mapsource verwende.

    Hallo und einen guten Abend!
    Es ist merkwürdig, bei manchen Wanderwege-Layer von ThKukuk sehe ich in QMS keinen einzigen Wanderweg, im Garmin Oregon 650 hingegen alle. Beispiel Island:
    Oregon:



    QMapShack:



    Den Autor der Karten habe ich bereits angesprochen, er meinte auf MapSource und seinem GPS funktionieren sie einwandfrei. QMapShack kennt er nicht – wie kann das sein ;-)



    Geht das nur bei mir nicht? Kann das bitte, bitte jemand bei seinem System ausprobieren?



    Der Island-Overlay ist so klein, dass ich ihn als Anhang hinzufügen kann.





    Vielen Dank!
    Robert


    P.S.: mein System: QMapShack 1.12.1; Win 7pro, 64bit

    ... Mir scheint allerdings, als wenn mein 2000er Kringel etwas verrutscht ist. Wie man das wohl korrigieren kann?


    Vielleicht ist auch der Gipfel verrutscht:
    [Blockierte Grafik: https://abload.de/img/omm_cl0397e1d.jpg]
    In basemap.at liegt die Roßkopfspitze 43m südwestlich derselben Spitze in OSM. Damit passt dein Kringel ganz gut.
    Aber: 43 m Differenz ist ein wenig viel, oder ???



    Nachtrag 07.10.2018
    OSM Chronik des Höhenknotens Roßkopfspitze:

    • Eintrag: 10. Oktober 2009
    • Quelle: estimated from NASA elevation data


    Da die 1” Daten erst 2014 veröffentlicht wurden, war die Grundlage vermutlich der 3“ (90m) Scan. Eine Differenz von 43m ist da schon möglich.

    Seit einigen Monaten gibt es ja die OpenMTBmap-Karten mit richtigeren Höhenlinien. Um den Qualitätsunterschied für mich greifbar zu machen, habe ich mir die Höhenschichtlinien einiger Österreichkarten angesehen.



    Das Vergleichsobjekt ist die Roßkopfspitze in der Nähe von Innsbruck. Auf die Idee brachte mich Max von dianacht.de. Hier meine Ergebnisse:



    [Blockierte Grafik: https://abload.de/img/omm_cl01xafm0.jpg]



    Die schlechte Qualität der SRTM-Höhendaten sind in der OpenCycleMap unübersehbar. Das 300m-Loch schaut attraktiv aus, ist aber leider nicht real. Die SRTM-Daten von viewfinderpanoramas in der 4Umaps sind überraschend gut, zwar etwas weichgezeichnet, bedingt durch die 30x30m Auflösung, aber in diesem Rahmen zumindest richtig.



    Die LiDAR-Daten von Österreich haben eine Auflösung von 10x10m. Der Bergcharakter kommt dadurch in den Karten von OpenMTBmap und dianacht.de sehr viel besser hervor. Die Höhenlinien der beiden Karten sind leicht unterschiedlich. Das könnte auch daran liegen, dass OpenMTBmap die geglätteten LiDAR-Daten von Sonny und dianacht.de die 10x10m Basisdaten verwendet.



    Das nächste Vergleichsquadrat zeigt die Roßkopfspitze vergrößert. Der Maßstab der Ausschnitte ist wieder ident, nur die basemap.at ist noch einmal stark vergrößert:



    [Blockierte Grafik: https://abload.de/img/omm_cl02n4ikx.jpg]



    Die Referenz ist natürlich basemap.at, mit einer Höhenlinienauflösung von 5m. Bergfex scheint diese Linien direkt zu verwenden, zumindest vermute ich das, wegen der identischen Form der Höhenlinien. Interessant ist die Renderregel von Bergfex: wenn es eng wird, hört die Höhenlinie auf.



    Die OpenMTBmap und die OpenAndrMap verwenden beide Höhendaten von Sonny. Welche genau konnte ich nicht herausfinden. Sonny bietet 1“ (Bogensekunde), 3“, 20m und 50m als Rastereinheit an. Etwas merkwürdig ist der leicht „unsaubere“ Verlauf der Höhelinien in der OpenMTBmap. Ob das Rechenungenauigkeiten sind?

    Resümee


    Die einzelnen Karten unterscheiden sich erheblich in der Qualität der Höhenlinien. Sofern man auf Höhenlinien Wert legt, lohnt sich der kritische Blick auf die eigene Karte.



    LG Robert



    Nachtrag 08.10.2018
    Info von Max (geo.dianacht.de): "Ich hab übrigens nicht die originalen 10m-Daten verwendet, sondern hab sie auf ca. 30m verschlechtert ..."

    Nachtrag für Mitleser: „Eigene“, blattschnittfreie Karten lassen sich sehr einfach online generieren. Link: https://extract.bbbike.org/


    Adresssuche und Routing funktionieren. Für den Garmin gibt es 8 Styles, jeweils in Latin1 und UTF8, zur Auswahl. Mir hat der OpenTopoMap-Style besonders gefallen.



    @ Trailsucher: Sorry, hab' deinen Nachtrag erst jetzt gesehen. Von der Garmin-SW halte ich lieber Abstand, aber der Map Composer klingt sehr interessant. Werde es mal versuchen. Danke!

    @ trailsucher
    Dankeschön für die Verortung des Problems, mir fehlte bisher der Anfang des Suchfadens …


    @ kiozen
    Da hast du recht, darstellen ohne routen ist eine halbe Sache. Auch der Garmin Oregon routet nicht selbständig über die Grenze. Der Tipp mit der Freizeitkarte Plus ist super. Danke!
    LG Robert

    Hallo und guten Abend!
    Ich plane gerade eine Tour im Grenzbereich von Österreich und Ungarn, wo ich mehrmals die Staatsgrenzen quere. Die Österreich-Karte vom Felix habe ich immer im Einsatz, nun brauchte ich also noch Ungarn. Runtergeladen und beide Karten aktiviert – und Überraschung, im Grenzbereich verdecken sich die Karten gegenseitig:



    [Blockierte Grafik: https://abload.de/img/athuallqvfh8.png]


    Mit den Transparenzreglern gelingt es beide Karteninhalte sichtbar zu machen, allerdings leidet dann der Kontrast.




    Beobachtung 1


    Aufgefallen ist mir noch, dass mein Garmin Oregon mit den Karten kein Problem hat (li: QMS; re: Garmin):



    [Blockierte Grafik: https://abload.de/img/qms_oregon1ii20.jpg]



    QMapShack und der Garmin verwenden dieselben Karten, im Garmin sind aber in der Überlappungszone alle Objekte sichtbar. In QMapShack waren noch die Trad-Typfiles aktiv, die das Kartenbild am PC angenehmer machen. Das Löschen der Typfiles änderte aber am gegenseitigen Verdecken nichts.



    Beobachtung 2


    In QmapShack sind zwei der Autobahnanschlüsse unterbrochen, die im Garmin durchgezogen sind:

    [Blockierte Grafik: https://abload.de/img/unterbrlfi6g.jpg]




    Das schaut zwar etwas komisch aus, aber es stört nicht wirklich.



    Fragen zum Verdecken



    • Wo könnte das Problem lokalisiert sein: Benutzer, Karte, QMS oder OSM?
    • Gibt es eine Möglichkeit das gegenseitige Verdecken von Karten in den Übergangszonen zu verhindern?


    Jeder Tipp ist willkommen!


    LG Robert

    Mein System: Win7 64 Pro; QMapShack 1.12.0; Openmountainbike-Karten: AT vom Juli 2018; HUN vom Sept. 2018

    Hallo und guten Abend!
    Vor einigen Monaten habe ich 2 Projekte bearbeitet und abgeschlossen. Wenn ich sie in der Datenbank abwähle verschwinden sie aus dem Arbeitsplatz. Nach dem Neustart von QMapShack sind diese 2 Projekte aber wieder im Arbeitsplatz zurück. Immer wieder. Kennt jemand dieses Problem und weiß Abhilfe?



    Vielen Dank für eure Tipps!
    Robert



    Mein System:
    QMapShack 1.12.0
    Win 7 pro 64bit