Beiträge von robhubi

kiozen herzlichen Dank!

Mit dieser tollen Anleitung war es ein Kinderspiel und das Ergebnis ist super.

Danke für alle Antworten!

Die fragliche Karte macht leider keine Angaben zum Koordinatensystem. Sie schaut so aus:

Das blaue Gitter hat nur Zählnummern aber keine Koordinatenwerte. Das viel gröbere schwarze Gitter hat Lat/lon-Werte.

Bei einer optisch ähnlichen Karte, von denselben Verlag, hat das blaue Gitter UTM-Werte in 2000 m Abstand und ebenso die Lat/Lon-Werte. Die 2000 m Gitterweite hat auch etwa die fragliche Karte.

Das ist leider alles, was ich zur Karte weiß. Ist meine Vermutung zum Koordinatensystem unplausibel?

Hallo,

Ich versuchte eine Karte mit geographischen (Lat/Lon) Gitter mit dem Gitterwerkzeug in QMapTool zu referenzieren. Meine Eingaben waren:

Projektion: Mercator

Datum: WGS_1984

Ostwert links oben: 15.833

Nordwert links oben: 47.25

Horiz./vert. Abstand: 0.08333

Nach dem Platzieren der Gitterpunkte schaut der gcp-File sehr merkwürdig aus:

#V1.0
#gcpproj: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs
-gcp 739 1384 0.0004273145771 0.0001422302589
-gcp 2205 1388 0.0004273145771 0.0001429788251
-gcp 3670 1392 0.0004273145771 0.0001437273912
-gcp 5136 1396 0.0004273145771 0.0001444759573

Auch im Tool-Fenster sind die Werte viel zu klein:

Irgendwo ist da der Wurm drinn. Hat jemand eine Idee wo?

Besten Dank für alle Tipps!

Mein System: Win10 64 bit; QMapTool V1.14.0

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:

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.

Ei verflixt, Benutzerfehler.

Beim Verschieben ist der Tiff-File zurückgeblieben. So hat QMS nur *.vrt und *.vrt.ovr gesehen.

Sorry.

Liebe Grüße

Robert

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

Nachtrag 02
Kommentar von ThKukuk ist hier.

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.

Danke an alle für die Abklärung!
Ich werde Th. Kukuk auf den Thread hier hinweisen.

Zitat von limex

Ich sehe auch keine Tracks aus diesem IMG.

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

Zitat von limex

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.

Zitat von limex

Installieren hab ich nicht ausprobiert.

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

Zitat von limex

Hilft es die Details zu erhöhen? Statt Details = 0 einen Wert von 1 oder 2.

Danke für den Tipp, leider tut sich nichts bei Details 0...5 . Auch ganz hineinzoomen auf den Parkplatz von Skogafoss hilft nicht.

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

Zitat von Wolfgang16

... Die Diskussion dazu ist im OAM Forum

Vielen Dank für den Link. Ein tolles Know-How tritt hier zum Vorschein.

Zitat von Speichennippel

... 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