Beiträge von Rhadamanthys

    Aktion: Tracktabelle markiert , "Liste in Windows-Zwischenablage kopieren" geklickt, in Texteditor kopiert. Schalter Koordinaten (...) umrechnen auf ein oder aus


    Ergebnis:
    Je nach Schalterstellung ist Zeit in UTC oder Zonenzeit.
    Als Offset wird aber nicht die Zeitzone des Tracks verwendet, sondern die in den GPS-Einstellungen.


    Wohl ein Relikt aus den Tagen, da Tracks noch keine Zeitzone hatten, ist in 4.0.127 noch immer so.

    Zitat von "jockel"

    Probleme gibt es m E. , wenn mehrere Übertragungen stattfinden, ohne daß das Gerät nach der Übertragung vom PC getrennt und gestartet wurde ...
    ... mal abgesehen von langen Tracknamen, Sonderzeichen in Namen und
    ausführlichsten Infofeldern mit Links drin.....


    Mein 62st V2.44beta mag keine diakritischen Zeichen (öäü) in der von QV4.0.127 erstellten tmp.gmx.


    Ursache: gpx encoding ist "ISO-8859-1"
    Editiere ich die Datei auf "UTF-8" und speichere sie dann auch mit dieser Zeichenkodierung(!), ist alles bestens.


    Ließe sich vielleicht gleich in QV einbauen. gpx-Dateien und Screenshots vor/nachher auf Wunsch verfügbar.


    Tatsache, geht! Setzt die ganze QV-Datenbank mit Tracks, Waypoints und Routes in die tmp.gpx um. Mit "...vom GPS holen" wird dann aber die \Garmin\GPX\Current\Current.gpx gelesen, richtig?


    Meine Beobachtung (62st V2.40, QV 4.0.127):


    62st im "Normalbetrieb", damit ist Fahrzeugnavigation mit PVT möglich, Gott sei Dank:
    Tracktabelle markiert, Button "Senden zum GPS" geklickt, QV meldet Übertragung der Tracks. Der 62st nimmt sie offenbar, speichert aber nichts.
    Wegpunkttabelle markiert, Button "Senden zum GPS" geklickt, QV meldet fehlende Geräteunterstützung.


    62st im Massenspeichermodus:
    Tracktabelle markiert, Button "Senden zum GPS" geklickt, QV meldet GPSgarmin_uError...


    Daß QV selbst den Massenspeichermodus erkennt, ist in meiner 4.0.127 noch nicht implementiert.


    Der 62st wird im Normalbetrieb auch von BaseCamp erkannt, man kann auch Daten reinziehen, BaseCamp tut als wäre alles super, aber im 62st kommt nichts an. Insofern weiß auch bei Garmin der Softwareentwickler nicht, was der Firmwareentwickler treibt :roll:


    GPSmap 62st V2.40, heute gekauft und gleich upgedatet.
    QV 4.0.127
    62st nicht im Massenspeichermodus, sonst ja kein "an GPS senden" möglich.


    Obiges geht bei mir nicht. QV sendet, kommt aber nichts an. Ganze Datenbank senden endet mit Fehlermeldung, weil Routen und Waypoints nicht unterstützt werden.
    Das proprietäre Garmin-Protokoll, ursprünglich für RS-232 entwickelt, wird wohl nur noch rudimentär unterstützt.


    Lösung: 62st in den Massenspeichermodus, Datenbank als gpx in \Garmin\GPX exportieren. QV beenden (wg. Freigabe), 62st mit "Hardware sicher entfernen" (nicht einfach Kabel abreissen), wieder einschalten im Normalbetrieb, alles da, Tracks, Routen, Waypoints.


    Ich könnte mir vorstellen, daß QV selbständig nach dem Verzeichnis auf dem Wechseldatenträger sucht und den gpx-Export veranstaltet (und vielleicht sogar das Laufwerk wieder freigibt!). Das wäre Komfort für den Benutzer. Mit VBA könnte ich das ganz leicht. Vielleicht kommts in V5.

    Hallo sardinien,
    du bist ja, glaube ich, auch an Skitouren interessiert. Für mich ist es einfach interessant, die Hangneigung möglichst auf der gewohnten AV-Karte zu sehen. Hier das Ergebnis eines kurzen Versuchs mit GM (weiß ist transparent, Rest 50%):


    [Blockierte Grafik: http://up.picr.de/4115323.jpg]


    Der Weg 323 zum Tuxer-Joch-Haus über den Sigreider wäre schon spannend.
    Leider mag mein GM die AV-Karten nicht lesen, also Export mit QV incl. .cal. Dann mag GM den Export nicht kalibrieren, also mit QV importieren, dann .cal löschen (!), neu exportieren, jetzt mag GM die .cal :grin:
    Schon etwas mühsam, aber was läßt sich nicht alles automatisieren...

    Zitat von "weoli"

    1. 1" SRTM Kachel N47E011.hgt geladen und sofort wieder im Float/Grid Format exportiert. Dabei in den Exportoptionen, wie von Mike im GM Forum beschrieben, auf "Export Slope Values Instead of Elevations" gesetzt und die ganze Kachel exportiert.


    Hast du oder jemand anders eine Ahnung, wie der GM Elevations in Slopes umrechnet? Man könnte die Differenzen in Ost-West oder Nord-Süd-Richtung berechnen oder (komplizierter) durch mehrere Höhenpunkte eine Ausgleichsebene legen oder was könnte der sonst machen?

    Zitat von "pezie"

    Hallo Jockel,


    habe mir die Karwendel-Demo mal angeschaut.
    Die Idee ist sehr gut und hilft beim Einschätzen der Hangneigung auf alle Fälle weiter.


    Ist es aber auch möglich diese Neigungskarte in TTQV als Overlay zu verwenden?


    Meine Antwort darauf hier im Forum war vor 3 Jahren auch schon ziemlich alt:
    "Ist ja schon ewig her und der letzte Winter war auch nicht so toll - aber -
    Ich habe die 1"-DEMs (siehe Beitrag wynetwix) zu Overlaykarten verarbeitet. Hangneigung in 2-Grad-Stufen von 26° bis 42° selektierbar, sodaß man je nach LG sofort sieht, wo die kritischen Hänge sind und entsprechend planen kann. 31 Karten im qvm-Format ca. 7GB, gezippt 1,1GB. Interessenten einfach mal melden."


    Eine Pixelkarte ähnlich wie die von Jockel hatte ich getestet und verworfen, weil das 2-Fenstersystem einfach zu stressig ist zum Touren planen.

    Zitat von "loopguru"


    Spannend. Was mich hier interessiert (und ich wohl nicht so ganz begriffen habe): Erzeugt man so eine Karte am besten mit einer Zone? Kanada geht ja ca. von Zone 3 bis 21 - kann man das bequem in ein ECW einbinden oder muß man pro Zone ein eigenes ECW erstellen?


    Ein ecw, eine Projektion, bei UTM eine Zone!
    Die Zonen sind ja nicht spasseshalber Bestandteil der UTM- oder Gauß-Krüger-Projektion. Jede Projektion versucht, die Kugel- bzw. Ellipsoid-Oberfläche der idealisierten Erde plan abzubilden. Das geht nicht ohne Verzerrungen. Versuch: Orange schälen und die Schalenstücke platt drücken. Je größer, desto ächz ;-)
    UTM macht daher den Kompromiss nur in 6° breiten Streifen mit und TTQV hält sich dran. GM ist emotionslos, aber besser wird es damit nicht.


    Das Ganze ist ein Problem der Kartographie und hat nichts mit der Art zu tun, wie Bitmapkarten gespeichert sind, bmp, png, gif, tif, ecw usw.


    Bin gespannt, wie Gerd das für Kanada löst.

    Das stimmt natürlich, vorausgesetzt es handelt sich um Gradabschnittskarten. Ein Beispiel wäre die topographische Karte der Deutschen Landesvermessung, die die GK-Projektion verwendet, deren (Papier-) Blätter aber von Längen- und Breitengraden begrenzt werden. Da würde aber in GM e.E. auch "Geographic" gehen.


    Anders die u.A. Blätter der LK Schweiz.


    Wenn du Karten unterschiedlicher Herkunft z.B. zu einer Alpenkarte zusammen bauen möchtest, kommst du um Reprojektionen und Datumsänderungen eh nicht rum, aber wem sage ich das ;-)

    Zitat

    Nachdem das WGS84/Mercator ja in Compe Probleme macht: Spricht irgendetwas dagegen, diesen Vorschlag von Gerd prinzipiell zu verwenden, d.h. alle Karten auf UTM Zone 32 auszugeben? Oder hat UTM wieder irgendeinen anderen Nachteil hier?


    UTM ist eine konforme Abbildung, d.h. Strecken und Winkel bleiben im Kleinen erhalten (von Gauß entwickelt und von Krüger verbessert, deshalb im deutschen Sprachraum als Gauß-Krüger-Projektion bekannt). Für topographische Karten DIE Projektion!


    "Für die meisten Karten größerer Bereiche ist die Merkatorprojektion wenig geeignet, da die Verzerrungsbeträge stark anwachsen und die Pole nicht darstellbar sind" (Hake, Kartographie I, ISBN 3110084554). Einziger Vorteil: Loxodrome (Linien konstanen Kurses) erscheinen auf der Merkatorkarte als Gerade, deshalb in der Seefahrt recht beliebt gewesen. Interessiert heute keinen mehr, auch dort ist GPS schon angekommen.


    Mit Google Maps habe ich mich nicht so beschäftigt. Google Earth verwendet offenbar eine schiefachsige stereographische Projektion, wie man sehen kann, wenn man den ganzen Globus zoomt und die Gitterlinien einblendet. Die ist auch konform und bei kleinen Kacheln in Bildschirmgröße, z.B. Sichthöhe <3000m ist der Unterschied zu einer UTM-Projektion < 1 Pixel. Man kann dann im GM lässig UTM unterstellen und Karten in voller Streifenbreite erstellen.


    GE mag ich übrigens auch für seine API, mit der man so schön automatisieren kann :grin:

    Zitat von "loopguru"

    Wenn ich selbst die PNGs auf 8 bit reduziere - passt das cal nicht mehr. Kann man das irgendwie elegant wieder zurückbiegen?


    Mein Versuch:
    1. Karte mit TAC erstellen für TTQV ->blabla.png, 55Mb +blabla_png.cal
    2. Karte in TTQV 4.0.127 installieren und anzeigen -> meine Tracks passen astrein.
    3. TTQV beenden.
    4. balabla.png mit Corel Photopaint öffnen, in 8bit Palettenbild konvertieren (ungerastert, optimierte Palette) und speichern -> blabla.png, 30MB
    5. TTQV starten, lädt blabla.png gleich wieder, kein Problem.


    In der .cal steht übrigens nichts über das Rasterformat, ergo auch nichts falsches :grin:

    Zitat von "Polarlys"

    QV4 kann KML-Dateien nicht direkt importieren. Du mußt die Dateien zuerst mit z.B. GPS Babel konvertieren, als Zielformat würde ich GPX nehmen.


    Das müßte sich ja inzwischen (4.0.127) geändert haben, zumindest gibt es die Option gleich zweimal ("Google Earth KML" und "LOC, GPX...").


    Habe gerade versucht, eine Skitour von http://www.alpintouren.com/AT2…kml/21500_Gloecknerin.kml zu importieren mit merkwürdigem Ergebnis: sieht so als, als würde die Höhenangabe 0.000000 in lauter Trackpunkte umgewandelt... :roll: In GE kommt das aber astrein. Der KML-Standard ist ja recht umfangreich, die TTQV-Implementation beim Import wohl eher fragmentarisch.


    Der Weg über GPS Babel ist auch hier erfolgreich, könnte man vielleicht direkt in TTQV einbauen ;-).

    Alle Achtung für die superschnelle Behebung des Bugs angesichts sicher erschwerter Bedingungen am Neujahrsmorgen :lol:
    Besonders erfreulich: die Glückwunschfunktion ist auch nach dem Update aktiv!


    Kann ich mich nur anschließen, echt enorm!

    Zitat von "reinim19"

    Wenn die Punkteanzahl gleich wäre und nur sich nur die Lage einiger Punkte geändert hätte wäre es leicht, z.B. zeilenweiser Vergleich im Excel. Was aber, wenn in Version 2 z.B. Punkte eingefügt wurden und somit die Punkteanzahl nicht mehr gleich ist...


    Da sehe ich eine einfache Lösung: Du merkst Dir, was Du gemacht hast und fügst dann in Excel entsprechend Leerstellen ein.
    Anspruchsvoller: ein Makro, das für jeden Punkt im kurzen Track den nächsten im langen findet. Da kann die Rechenzeit natürlich eine Rolle spielen: Für m+n Punkte sind m*n Vergleiche fällig, außer man sucht nur in der näheren Umgebung.

    Zitat von "reinim19"

    es geht mir hier vor allem um selbst-erstellte Trackverläufe, also nicht Tracklogs von GPS-Empfängern, wo natürlich die Trackpunkte nie völlig identisch wären.
    Ich will dann sehen ob und wo es z.B. zwischen 2 Versionen dieses Tracks Änderungen gab.


    Damit ein selbst erstellter Track umfangreich wird, ist wohl harte Arbeit nötig, Respekt! Du könntest natürlich mit "Punkte fangen" dafür sorgen, daß beide identisch werden, aber das ist wohl nicht der Sinn der Übung. Außer der von polarlys vorgeschlagenen numerischen Methode mit Excel etc. fällt mir nur die grafische mit TTQV ein: Testtrack mit Signalfarbe und Strichstärke 1 darstellen (ggf. ohne Linien), Referenztrack mit Deckfarbe und Strichstärke in Toleranzbreite drüber. Was jetzt in Signalfarbe rausspitzt, ist ein "Ausreisser". Geht auch mit Tracklogs.

    Zitat von "Polarlys"

    "nahezu identisch" halte ich für extrem unwahrscheinlich, dazu müßten zwei Empfänger für fast jeden Punkt bis auf die letzte Kommastelle die exakt gleichen Koordinaten ermitteln. Sieh dir bitte mal die einzelnen Koordinaten an, du wirst kaum in beiden Tracks exakt gleiche Koordinaten finden.


    Das reicht noch nicht mal. In aller Regel speichern 2 Empfänger die Trackpunkte nicht zum selben Zeitpunkt: Auch wenn ich einen Punkt alle 60 Sekunden speichern lasse, macht mein Garmin das noch lange nicht zur vollen Minute, sondern nach Gutdünken bzw. bestmöglich.


    Man müßte also allgemein von einem Trackpunkt des Testtracks das Lot auf einen Abschnitt des Referenztracks fällen und dann die Lotlänge auf Schmerzgrenze prüfen. Kein Problem mit Excel, ein wenig analytische Geometrie (und Kartenprojektion, falls der Track in Ellipsoidischen Koordinaten vorliegt), dann läufts.