Beiträge von kiozen

Gebraucht wird nur mit dem Gerät zusammen gehen. Die Karte wird über Basecamp mit der Geräte ID gekoppelt. Danach kann sie auf keinem anderen Gerät verwendet werden.

Was Du vor hast, ist gegen die von Dir beim Kauf akzeptierten Nutzungsbedingungen der Karten. Für das was Du vor hast, hättest Du die DVD Version kaufen müssen . Diese ist an das Gerät gebunden. Die Karten auf der SD Karte sind an die SD Karte selber gebunden.

Wer im Netz intensiv sucht, findet Software mit der sich die Karten entsperren lassen. Diese zu benutzen ist in Deutschland gegen die geltende Rechtsprechung.

https://bitbucket.org/maproom/qmapshack/wiki/DocGisItemsTrk

Speziell alles zu "Select Range"

Stell Dir vor, die Drift deines Wertes passiert nur im letzten Drittel. Dann würdest Du mit einer so einfachen Korrektur, wie Du sie jetzt gemacht hast, zwei drittel der guten Werte schlecht machen, um die Werte im letzten Drittel zu korrigieren.

Bei deinem aktuellen Beispiel würde man das sofort sehen und es besser bleiben lassen. Bei anderen Tracks fällt es hingegen nicht so schnell auf.

Wenn man nicht genau weiß, was man macht, dann kann das eher nach hinten losgehen.

Zitat von StefanR

Warum die Korrektur wichtig ist? Naja, da ist ein systematischer Fehler (Änderung des Luftdrucks) und so ist er in 1. Näherung korrigiert. Die Daten sind so näher an der Realität als vorher. Mir ist das so lieber.

Grundsätzlich richtig. Es setzt nur voraus, dass man den systematischen Fehler auch genau kennt. Bei deiner einfachen linearen Näherung ist das so grob, dass aus technischer Sicht das eine Ergebnis nicht wirklich besser ist, als das andere. Wie Anton schon sagt, es ist gefälliger.

Besser wäre es, so viele Referenzpunkte wie möglich zu setzen. Bei ausreichender Anzahl, kann man dann von einer wirklichen Korrekturkurve sprechen.

Aber das ist schon sehr speziell.

Zitat von nordlicht

@Ulmer Spatz: Klasse!

aaaalt. Und angeblich soll der Student Niels Bohr gewesen sein...

Zitat von trailsurfer

kiozen: Du hattest das auch empfohlen, aber dann festgestellt, das dies nicht geht ?

Stefan will ja keine Höhenkorrektur durch SRTM Daten, sondern über eine Korrekturkurve. Und das geht auch mit GTA nicht.

Bei BW müsstest Du versuchen an die offiziellen DEM Daten, wie sie mit der Top10 geliefert werden zu kommen. Ist aber so eine Sache mit dem proprietären Format.

für welches Gebiet müssten den die DEM Daten sein?

Edit: Du könntest mal schauen ob gps-track-analyse in der Richtung etwas bietet.

Edit2: Nö, sieht nicht so aus.

Eine Software kann ich Dir leider nicht nennen.

Aber ich habe mich öfters gefragt, ob man so etwas als Filter in QMapShack einbauen sollte. Bisher ist es immer daran gescheitert, dass ich nicht wüsste, wie man die richtige Korrekturkurve angeben sollte. Und das auch noch in einer Art, die für absolute Laien verständlich ist.

Eine lineare Korrektur wäre einfach. Man gibt den Korrekturwert am Anfang vom Track an und am Ende. Dazwischen werden die Werte um die lineare Interpolation korrigiert. Aber ist das immer Richtig? Eher nicht. Und deswegen habe ich das Problem bisher jedes mal wieder vertagt.

Wenn ich mal einen Track mit einem total verpfuschen Profil habe, dann übernehme ich lieber die Daten aus dem Höhenmodel. Das scheint mir vernünftiger zu sein, als irgendeine erratische Fehlerkurve.

Zitat von Emvau

Danke für deine Antwort!
Windows10 in 32-bit spielt aber gerade bei handlichen und stromsparenden Tablets eine große Rolle, weil 32-bit hier oftmals Ressourcen-freundlicher ist. Insgesamt ist es sicherlich verbreiteter als Linux. Insofern ist es fast absurd, dass man diese Software nicht mehr für 32-bit anbieten möchte. Aber ich verstehe schon, es gibt einfach niemand, der das machen möchte.

Ist es denn wirklich resourcenfreundlicher? Die These ist gewagt, da die meisten verwendeten Datentypen immer noch 32bit sind. Nur dort wo es 64 Bit Typen benötigt, kann ein 64Bit System diese Typen nativ verarbeiten. Ein 32Bit System muss mit vielen extra Zyklen das Problem umgehen.

Zitat von Emvau

Was müsste ich denn können? Ich habe nie kompiliert und verfüge auch nicht über Programmierkenntisse. Ich habe neben einem Tablet einen Desktop Windows-10-Rechner mit 4gb Arbeitsspeicher. Kann ich irgendwo effizient lernen, wie ich aus der Source einen Win32-Installer macht? Und wie konkret muss ich die Probleme speziell bei Win32 einordnen?

Hier geht es um Probleme bei der Speicherverwaltung und darum das Microsoft die plattformübergreifenden APIs schlampig und inkonsequent programmiert hat. Das führt zu Abstürzen und komischen Verhalten. Die Lösung wäre, diese Stellen durch die proprietäre Microsoft API zu ersetzen. Oder anders gesagt: Hier braucht es jemanden der wirklich Ahnung vom programmieren hat. Und auch Poweruser von QMS ist, um alle diese Stellen zu finden und zu beheben. Nicht gerade das Thema um mit dem Programmieren anzufangen

Ich unterstütze nur den Sourcecode

Helmut, der sich um die Windows Installation kümmert, hat die Portierung auf 32 Bit aufgegeben. An einigen Stellen machen die 32 Bit Probleme und es müsste sich jemand aktiv darum kümmern. Da Helmut schon seit Jahren auf 64 Bit umgestiegen ist, hat er wenig Lust Zeit in eine Technologie zu stecken, die getrost als überholt zu bezeichnen ist.

Wer also meint, er braucht unbedingt 32 Bit, der muss sich in Zukunft selber aktiv werden.

Quellen für Karten und DEM Dateien werden in der Dokumentation erwähnt:

https://bitbucket.org/maproom/qmapshack/wiki/DocBasicsMapDem

Unter "Sources of Maps and DEM files"

Wenn du dich im "+" Mode den Endpunkten näherst, werden nur diese rot. Nicht das ganze Segment. Einfach mal ein wenig mit der Maus jonglieren. Ist nur der Punkt rot, kann ein weiterer Punkt am jeweiligen Ende hinzugefügt werden.

Über Garmins Format bezüglich der Höhendaten ist leider nicht genügend bekannt, als dass man diese verwenden könnte. Zudem benützen die Karten mit Höhendaten Datenstrukturen, die nicht bekannt sind. Das schon genannte Problem mit der Verschlüsselung kommt oben drauf.

Das war bei QLGT nicht anders und wird bis auf weiteres so bleiben. Es ist auch gar nicht das Ziel ein zweites Basecamp zu schaffen, sondern alles was an freien Karten und Daten vorhanden ist unter einen Hut zu bekommen. Und das funktioniert meiner Meinung nach inzwischen ganz gut.

Für Nicht-Programmierer gibt es im Menü "Werkzeug" einen "VRT Builder". Wozu das ganze? Höhendaten werden selten als eine große Datei angeboten sondern in kleineren Kacheln. Für ein ganzes Gebiet brauch man folglich mehrere Dateien. QMS muss aber wissen welche Dateien als Satz zusammengehören. Da man ja alle möglichen Dateien haben kann, ist es für ein Programm nicht so ohne weiteres zu erkennen, was zusammengehört. Deswegen braucht es die VRT Datei,

Das ist eine etwas kryptische Textdatei die einfach neben ein paar geodätischen Informationen die einzelnen Dateien auflistet. Und wenn man das weiß, dann sollte der VRRT Builder sich mehr oder weniger von selbst erklären. Man gibt an welche Dateien einen Satz bilden. Man gibt an wo die VRT Datei erstellt werden soll. Und wie sie heißt. "Start" drücken. Und mit ein wenig Glück gibt es keine Fehlermeldung.

Bei der Organisation der Dateien ist QMS recht flexibel. Bei mir sieht das so aus:

Ich habe einen Ordner "Karten". Und in diesem zwei Ordner: "Maps" und "DEM". Den Ordner "Maps" habe ich unter "Datei->Kartenverzeichnis angeben" hinzugefügt. Und den Ordner "DEM" unter "Datei->DEM Verzeichnis angeben".

In diesen beiden Ordnern liegen alle meine Karten, die aus nur einer Datei bestehen. Also alle Dateien mit *tms, *.wmts und *vrt als Endung. Zu einer *vrt Datei gehört ja immer mindestens eine Datei mit den eigentlichen Daten. Für diese lege ich pro Kartensatz ein weiteres Unterverzeichnis an.

Also in etwa so:

[COLOR=Blue]Karten[/COLOR]
    [COLOR=Blue]Maps[/COLOR]
        [COLOR=Blue]MeineKarte1[/COLOR]
            [COLOR=SeaGreen]karte.tif
        [COLOR=Blue]MeineKarte2[/COLOR]
            karte1.tif
            karte2.tif
[/COLOR][COLOR=SeaGreen]        MeineKarte1.vrt[/COLOR]
[COLOR=SeaGreen]        MeineKarte2.vrt[/COLOR]

Blau sind Verzeichnisse
Grün sind Dateien

Und die Welt ist in der Zwischenzeit nicht untergegangen Ufff....

Zitat von mountainrescue

Ich kann mit dem Anima zur Trackaufzeichnung nichts Schlechtes sagen; ich habe die besten Erfahrungen!

Wenn man mit festen Intervallen zufrieden ist. Verglichen zu einer Aufzeichnung im Automode von Garmin fehlen dann schon ein paar Details. Und der Automode von TwoNav macht in der aktuellen Funktion wenig Sinn. Aber wie Du schon schreibst, für einen Trackback reicht es.

Zitat von mountainrescue

Für mich ist der Anima, als Bergwanderer/-steiger/Tourengeher die ideale Lösung und für dich halt dein Garmin!

Von der Hardware her ist das sicherlich so. Da haben Touchscreengeräte schon grundsätzliche einen schweren Stand bei mir.

Von der Software her überzeugt mich allerdings die Tracknavigation und der Tripcomputer bei TwoNav definitiv mehr. Einzig die Trackaufzeichnung könnte noch ein wenig Aufmerksamkeit vertragen.

Wie ist das eigentlich mit dem Lipo Akku in der kalten Jahreszeit. Wenn ich es richtig im Kopf habe, trägst Du das Gerät in der Jacke, oder? Schon mal ausprobiert in wie weit sich Minusgrade auf die Laufzeit auswirken, wenn man das Gerät offen trägt? Beim Sportiva hatte ich bisher nur Touren bei Kälte und Sonne. Da war es ok.

Nee war natürlich mein Garmin :p Das Sportiva hat einen Gummischaden. Aber gut zu lesen, dass der Empfang beim Anima besser geworden ist. Das war auch immer so ein Punkt beim Sportiva, mit dem ich gehadert habe. Mensch wenn Compe jetzt mal noch ein schönes Tastengerät herausbringen würde...

Danke Am Taubenkogel/Gjaidstein sieht es ähnlich aus. Aber das Gipfelkreuz stimmt nicht. Wir hatten da vor 4 Wochen richtig Nebel, dafür keinen Schnee.

War das am Dachstein?