Beiträge von JürgenD

Garmin fenix 7X und epix Gen 2 im Test

Der Schwerpunkt dieses Tests und Vergleichs der Garmin Fenix 7X Solar und Garmin Epix Gen 2 liegt auf den Sensoren wie Höhenmesser, Positionsbestimmung und Herzfrequenz. Was unterscheidet die beiden GPS-Outdoor-Smartwatches? Und wie gut ist die Taschenlampe der Fenix 7X für den Outdoorbereich? Hier geht es zum Test der Outdoor-Smartwatches ...

    DEM steht für mich im Moment nicht auf der Tagesordnung, kommt aber irgendwann. Trotzdem ein Hinweis: MapTk erstellt eine detaillierte Analyse mit den Abmessungen ( Tools -> TDB analysis ).


    An dem Begriff 3-Byte-Codes bin ich möglicherweise indirekt schuld. Mit der Erzeugung von TYP-Dateien sind mir diese Codes bekannt geworden. Um sie in der PRJ-Datei, und auch später in der MP-Datei, einfach unterscheiden zu können habe ich zu den Codes 0x10000 addiert, also 3 Byte daraus gemacht im Quelltext. Das war im Oktober 2007 mit der Version 1.2 von MapTk. Diese Schreibweise haben andere übernommen oder parallel neu erfunden. In den Bereichen RGN2, 3 und 4 sind die Objekte getrennt speichert ( im Gegensatz zu RGN1, wo alle einen gemeinsamen Bereich teilen ). Soweit ich das überblicke sind einige Grenzen gefallen. Z.B. die 4 MByte-Grenze des Subfile RGN im herkömmlichen Format und natürlich viele Möglichkeiten Objekt sehr detailliert zu beschreiben. Welches Potential wirklich dahinter steckt wird man noch sehen. Aber auch diese Aktivität ruht bei mir in der nächsten Zeit, nicht zuletzt weil MapEdit damit noch nicht umgehen kann.

    Zitat

    looks like 0x11... is a DEM type but i don;t know if anyone have done some progress on the .DEM file.


    Das verstehe ich nicht. Die V2Types haben mit DEM nichts zu tun, sie werden nur in einem anderen Format organisiert und gespeichert.


    Gruß
    JürgenD

    @extremcarver


    Es stimmt, 0x17 wird in MapSource nicht dargestellt. Da hab ich mich geirrt. Auch die anderen Hinweise werde ich in die Doku aufnehmen (MyCodes.pdf). Eine reine 3-Byte-Karte habe ich noch nicht gesehen, es war immer reine Mischung aus den bekannten Codes und eben den 3-Byte.Codes. Das diese Objekte in der IMG-Datein in unterschiedlichen Strukturen gespeichert sind erwarte ich bei den 2-Byte-Codes das bekannte Verhalten. Die 3-Byte-Codes scheinen keine speziellen Funktionen zu haben ( wie z.B. die Höhenangabe bei 0x20...0x22 ). Decompilieren von 3-Byte-Karten kann MapTk schon lange. Es gibt da aber einige Datenfelder, die ich noch nicht verstehe, zum decompilieren auch nicht gebrauche. Was damit beim Compilieren ist wird sich herausstellen. Das Compilieren habe ich dann zugunsten der TYP-Dateien zurückgestellt. Nun drängelt sich auch noch die Einbindung von Wegen in die Südtirol-Karte vor - und Fehlerbehebung an MapTk ( hab' gerade wieder einen entdeckt ).


    Was sich da in Spanien tut ( fast 20% der MapTk-Downloads ) scheint sehr interessant zu sein. Leider kann ich mit den spanischen Texten nichts anfangen. Das Thema DEM ist aber schon interessant.

    Ich hab mal die Daten der Region von OSM heruntergeladen ( die *.img-Version, ist bequemer für mich ), die Wege und POIs extrahiert in eine Overlay-Karte gebracht. Kann man herunterladen. Darf auch in das Verzeichnis der topografischen Karte installiert werden.


    Das ist ein Experiment für den Fall, dass der AVS stur bleibt - wie leider zu erwarten ist. Die Daten sind unbearbeitet, was einen Eindruck der Qualität vermitteln soll. Deshalb sind auch doppelte Wege und POIs drin. Als Ziel werde ich die Daten in die Karte integrieren. Das soll weitgehend ohne Handarbeit gehen. Ein Programm ist dafür in der Entstehung begriffen, damit keine Straßen und Wirschaftswege überschrieben, Wege gefiltert, mehrfache Wege zur Verbesserung gemittelt und mehrfache POIs entfernt werden. Bis dahin wird es wohl Frühjahr werden, also Zeit zum Sammeln vieler Daten.


    Der Server wird schon gefunden, viel öfter als erwartet ( > 3880 Downloads der Version 1.03 bis jetzt ) und mehr als die ADSL-Leitung und der Server immer hergeben können.

    Moin,


    den Schuh mit dem Lob für den Kartenzeichner ziehe ich mir nicht an. Das Lob gebührt der Verwaltung in Bozen. Bis auf ein paar POIs und Wege ( 0x16 ) sind das Daten der Amtes für Raumordnung in Bozen. Dort sind die Wanderwege nicht erfasst. Das hat dann der AVS bei einem Budget von rund 4.800.000 € gemacht. 80% davon von der EU. Die wenigen Wege und zusätzliche POIs stammen von mir oder aus dem Internet.


    Es ist tatsächlich so, dass der AVS mauert. Ich versuche erfolglos seit Mitte Juni 2008 an die Daten heranzukommen. Ich habe dem AVS angeboten die Daten in die bestehende Karte völlig kostenfrei zu integrieren und die Karte zu pflegen, auch kostenlos. Ich habe sogar angeboten die Karte exklusiv dem AVS zum kostenlosen Download zu überlassen. Außer einem Bescheid ( Ende Juli ), dass man das intern im Team diskutieren müsste und der Kopie einer AVS-internen Mail ( Ende August ) habe ich keine Antwort bekommen. Die interne Mail mit der Empfehlung das Angebot anzunehmen war wohl eher ein Unfall. Der Absender hat hoffentlich keine Probleme bekommen. Am 16.9.2008 habe ich dann noch einmal mein Angebot bekräftigt. Bis heute ohne Antwort.


    Die moralische Situation scheint mir ziemlich klar zu sein. Die Bürger der EU haben die Aktion bezahlt, und wer bezahlt bestimmt welche Musik gespielt wird. Die rechtliche Situation ist dagegen weniger übersichtlich. Aus der Anonymität heraus lassen sich gut Vorschläge machen wie Fakten schaffen oder einfach kopieren. Ich scheue das Risiko, denn außer Arbeit habe ich nichts davon, schon gar kein siebenstelliges Budget. Schadensersatz wäre da zum Beispiel denkbar, da der AVS ab 2009 die Daten verkaufen könnte. Wenn ich den Abschlussbericht richtig verstehe geht die Reise in genau diese Richtung. Oder strafrechtliche Verfolgung wegen Verletzung irgendeines Copyrights.


    Ich werden noch eine letzte Mail an den AVS verfassen. Sollte ich in absehbarer Zeit keine befriedigende Antwort erhalten, werde ich alle Nutzer der Karte auffordern mir ihre Tracks verfügbar zu machen ( Mail an maptk@gmx.de oder Upload auf http://www.maptk.dnsalias.com ). Ich werde dann davon ausgehen, dass diese Daten selbst aufgenommen wurden. Eine Überprüfung auf Plausibilität mit Google-Earth, trekking.info oder einer Papierkarte kann sicher nicht schädlich sein. Meine Hoffnung, dass da etwas brauchbares herauskommt ist allerdings eher gering. Notfalls lasse ich das Projekt ganz einschlafen und aktualisiere nur für meinen privaten Bedarf.


    Der Beitrag von Isartrails erweckt den Eindruck von Insiderwissen und einer ordentlichen Portion Frust bezüglich AVS. Sollte jemand Kontakte in Südtirol haben ( z.B. Journalisten, Hoteliers, Politiker, ... ) könnte man über diesen Weg Informationen sammeln oder auch etwas anschubsen. Quellen, die nicht genannt werden möchten, werde ich sicher nicht weitergeben. Zeitung oder Gaststättenverband haben bestimmt ein größeres Gewicht als ein Frosch, der gern eine perfekte Karte den Freunden Südtirols bieten möchte - und selbst nicht so genau weiß warum er sich das eigentlich antut.


    Schönen Sonntag noch
    JürgenD

    Moin,


    war grad mal ein paar Tage weg. Zuerst mal ganz allgemein. Zu Versionsangaben ist es immer gut Beispiele anzuführen. Als Quellenangabe ( Beispiel: Topo D V2 Kacheln Geesthacht und Lüneburg: weißer Steifen an der Nahtstelle ), als Anhang, per Mail oder auf den Server schieben. Das macht das Leben viel leichter. Dann in der Reihenfolge:


    Nachtansicht werde ich nicht implementieren, kann Colorado und Oregon ohnehin nicht. Ich drehe lieber die Helligkeit runter und habe das gewohnte Kartenbild der topografischen Karte, die ich mir auch beim Autorouting anzeigen lasse.


    Streifen an Kachelrändern entstehen durch überlappende Hintergründe und wenn zudem im Überlappungsbereich die Linien und Flächen bei einer der Kacheln fehlen. Das ist einfach schlampige Arbeit beim Erstellen des Karten. Im Beispiel oben sind das ganze 14 m. Für unbearbeitbare ( 'locked' ) Karten hilft es 0x4b aus der TYP-Datei zu entfernen. Die Farbe des Hintergrundes wird dann allerdings von Garmin bestimmt. Die Kachel ist dadurch aber nicht transparent. Im Original der Topo D V2 TYP-Datei gibt es kein 0x4b. Bei bearbeitbaren Karten sollte man den leeren Teil des Hintergrundes entfernen.


    Die schwarzen Rändern an POIs habe ich bisher nur in MapSource der Version 6.13.7 gesehen. Das hat mich einige Stunden Arbeit gekostet weil ich nach einem Fehler in MapTk gesucht habe. Deshalb benutze ich immer noch 6.13.6. Das hat alles nichts mit der Größe der Icons zu tun. MapTk bearbeitet von 1 Pixel bis 32 * 32.


    Linien 0x17 werden zumindest mit TYP-Datei auf den neueren Geräten wie GPSMap60C(x), Colorado oder Oregon angezeigt. Meine Beobachtungen zeigen, dass alle POIs, Linien und Flächen in den bekannten Bereichen mit entsprechender TYP-Datei angezeigt werden können. Ohne TYP-Datei werden wohl nur die Standard-Typen angezeigt, wobei sich die Geräte möglicherweise unterschiedlich verhalten. Die anzeigbaren Typen sind für POIs 0x0100...0x6f1f, Linien 0x00...0x2b und Flächen 0x00...0x54. Dazu kommen die 3-Byte-Typen: Linien 0x10e00...0x10e1f, 0x10f00...0x10f1f, Flächen 0x10f00...0x10f1f, 0x11000...0x1101f. Bei topografischen Karten hat der Typ einer Linie oder Fläche meist keine erkennbare Funktion. Ich kenne nur eine Ausnahme: 0x14 wird nie in höheren Leveln angezeigt. Bei Autrouting ist das bei Straßen möglicherweise anders. Bei POIs ist der Typ für die Sichtbarkeit und die Suchfunktionen wichtig. Was mit anderen Geräten und ggf. anderen Typen ist interessiert mich für die Doku.


    Scönen Sonntag !
    JürgenD

    Hallo Woodi,


    der Eintrag soll der vollständige Pfad zu einem PDF-Anzeigeprogramm sein, also Ordner + Programmname. Der Versuch das im Programm gegen Fehler abzusichern ist leider missglückt. Korrektur in der nächsten Version. Dann wird es auch möglich sein das Feld leer zu lassen um den Viewer zu verwenden, der mit *.PDF verknüpft ist.


    Gruß
    JürgenD

    POIs sind 2 Byte lang ( 1 Byte Type + 1 Byte Subtype = 16 Bit ). Orte werden oft als 1 Byte-Typen angegeben. Aus 0x07 ( Stadt ~ 100000 Einwohner ) wird dann 0x0700. Das hat sonst keine weitere Auswirkung, dient nur der Vereinheitlichung.


    Den aktuellen Ordner beim Beenden von MapTk für den nächsten Start aufzubewahren widerspricht der empfohlenen Arbeitsweise. Die Empfehlung ist: Für jedes Projekt ( in der Regel ein Satz Karten) sollte eine eigenes Verzeichnis angelegt werden. In jedem dieser Verzeichnisse liegt dann ein MapTk.prj. Ein Link im selben Verzeichnis oder eine Verbindung für den Doppelklick auf *.prj mit MapTk.exe startet dann genau in der gewünschten Umgebung mit der dort liegenden Projektdatei MapTk.prj. Bei mir ist *.PRJ mit MapTk.exe verbunden. Die PRJ-Datei für meine TYP-Datei von CN9 liegt im Verzeichnis der Karten, wo dann auch die TYP-Datei hinkommt. Damit ist dann alles schön beieinander.


    Nun scheint es aber so zu sein, dass viele MapTk als TYP-File-Editor 'missbrauchen'. Dafür ist schon der neue Menüeintrag gedacht. Die nächste Version wird dann noch etwas weiter gehen: Doppelklick auf eine PRJ-Datei startet MapTk mit genau dieser Datei ( angezeigt in der Teítelleiste ). Das erspart die Auswahl mit dem neuen Menueintrag. Das sollte dann eigentlich genug Komfort sein.


    Gruß
    JürgenD

    Ich habe gut zu tun meine virtuellen und den realen Briefkasten von Werbemüll frei zu halten. Eigentlich bin ich Anarchist, trotzdem meine Bitte an einen Administrator diesen und Beitrag #87 schnell und rückstandsfrei zu entsorgen, den Schreiber gleich mit !


    JürgenD

    Hallo,


    so ist es, schreibweise immer hexadezimal. Die Typen > 0x10000 sind die sogenannten 3-Byte-Typen wie sie z.B. von der Topo D V2 verwendet werden. Die erlauben pro Grundtyp 32 Subtypen extra. Auch bei Linien und Flächen. Das macht sie interessant und ist deshalb für MapTk in Vorbereitung. Leider kann MapEdit damit noch nicht umgehen.


    Grüß
    Jürgen

    Hallo,


    POIs sind 16-Bit-Werte für Typ + Subtyp ( Seite 29 Manual 2.3 deutsch ). Subtypen sind aber vom Prinzip her auf 0x00 bis 0x1f beschränkt. Die Angabe von z.B. 0x48 heißt also Type=0x00 mit Subtyp 0x48. Das ist nicht möglich, also Fehlermeldung.
    MapEdit expandiert 1-Byte-Typen auf 16 Bit unter der Annahme des Subtyp 0x00. In der nächsten Version wird MapTk das genau so machen. Das Manual wird erweitert.
    MapTk behandelt alle Typen völlig gleich ( mit Ausnahme der Polygone 0x4a und 0x4b ). Abweichungen von dieser Regel sind Unsymetrien bei Garmin.


    Gruß
    Jürgen

    Die neue Version 2.3 von MapTk steht zum Download bereit.


    Neu: Die Farbe der Beschriftung kann geändert werden. Neue Dokumentation.


    Alle bekannten Fehler wurden beseitigt.


    Gruß
    Jürgen

    Hallo morgen1,


    ich hab es erstmal aufgegeben. Bei der ersten, viel zu oberflächlichen Besichtigung der Karte habe ich etwas wesentliches Übersehen: Bis auf die Flüssen und die Hauptstraße sind die Linien viele, nicht zusammenhängende Schnipsel mit einer Länge von 10 bis 50 m. Ohne Massive Nachbearbeitung gibt das nie eine ordentliche Vektorkarte, die ich als Beispiel hernehmen könnte. Also werde ich mir ein anderes Opfer suchen müssen. Per Programm habe ich noch keine Lösung diese Schnipsel zusammenzuführen. Meine Überlegungen zu einem GPX-Filter könnten irgendwann mal einen Algoritmus liefern um die Lücken von mehreren Metern zu überbrücken.


    Trotzdem war der Versuch nicht ganz vergebens. POIs mit Type<0x100 wurden brutal of 0x00 gesetzt. Korrektur kommt mit der nächsten Version.


    Gruß
    Jürgen

    Hallo morgen1,


    die Fehlermeldungen mit einer Zeilennummer auszustatten geht natürlich. Für Compiler und Co ist das etwas umständlich da aus einer Datenbank heraus gearbeitet wird. Ich gehe zur Zeit einen anderen Weg: Typ, Name und Koordinaten des Übeltäters angeben. Der Grund dafür ist, dass ich eigentlich nie einen Texteditor anwerfe. MapEdit ist für mich das Werkzeug. Koordinaten aus der Fehlermeldung kopieren, in MapEdit einfügen und der Übeltäter steht in Bildschirmmitte. Zeilennummern kommen trotzdem auf die 'todo'-Liste. Bei Scripten ist das etwas komplizierter. Die Meldungen kommen aus dem Laufzeitsystem, wenn überhaupt. Wenn sie dann kommen wurden die Kommentarzeilen nicht mitgezählt und beginnen für Header, POI, Polyline und Polygon jeweils neu. Um das zu verbessern fällt mit nichts gescheites ein.


    Die Quelle der Toskana-Karte erklärt fast alles. Anfangs war ich ganz wild auf Scannen von Papierkarten. Hab ich schon lange aufgegeben. Nachzeichnen macht genauso viel Arbeit. Hab ich auch für ganze Karten verworfen. Jetzt suche ich mir Einzelteile im Internet zusammen und bearbeite das. Das Rohmaterial für die Südtirol-Karte war ein ausgesprochener Glücksfall wie er mir sonst noch nicht wieder begegnet ist. Von den ersten Downloads bis zur fertigen Südtirol-Karte hat mit vielen Umwegen ( und gleichzeitiger Entwicklung von MapTk, nach Umwegen über cgpsmapper und verschiedene Scripte ) mehr als 3 Jahre gedauert.


    An ganze Karten mach ich mich nur im Notfall. Notfall heisst, dass es nichts brauchbares zu kaufen gibt. Sonst nur Verbesserung und Erweiterung.


    Ich mach mich jetzt an die angekündigte Bearbeitung der Toskana-Karte. Ich bin entschlossen das zur Keimzelle für ein Karten-Kochbuch zu machen. Wenn ich hier im Board von den Probleme beim Erstellen von Karten lese, scheint mir das fast wichtiger als neue Funktionen in MapTk einzubauen. Schaun wir mal.


    Gruß
    Jürgen

    Hallo morgen1,


    ich habe mal ganz kurz in die Datei hineingeschaut. Ich bin immer interessiert was die Anwender mit MapTk so alles anstellen. Ich habe da einiges gesehen, wie ich es nicht machen würde, mal abgesehen von den Typen. Es gibt da doch ein paar Regeln und Möglichkeiten die nicht offensichtlich sind und auch nicht im Manual stehen. Zum Wochenende werde ich die Karte mal in eine Form bringen wie ich sie mir vorstelle ( und begründen warum ). Das könnte auch für andere Anwender eine interessante Lektüre sein.


    In der nächsten Version werde ich Fehler bei der Typisierung in der MP-Datei mit einer ordentlichen Warnmeldung abfangen.


    Gruß
    Jürgen

    Hallo zusammen,


    "In allererster Linie ist das Programm für meine Bedürfnisse." Diesen Satz hätte ich gleich fett anlegen sollen. Der Aufwand zum Kultivieren des Programms, d.h. Beschreibung, gelegentlicher Support und halbwegs DAU-sichere Handhabung kosten schon genug Zeit. Für 'Kundenwünsche' bleibt da wenig Spielraum.


    Autorouting für eine topografische Karte brauche ich wirklich nicht. Ich gehe sogar noch weiter: Ich lasse mich doch in der Natur nicht anpiepsen oder gar anquatschen ! Dass Radler auf Autorouting ganz scharf sind könnten kann ich zwar verstehen, die sollten ihr Problem aber anders lösen. Bergauf sehen sie vor lauter Anstrengung die Natur nicht und fahren in der Spur an allem vorbei. Bergab sind sie dann voll beschäftigt sich nicht auf die F.... zu legen und Fußgänger von Weg zu scheuchen. Da kommt man schon leicht vom richtigen Weg ab. Motorisierte Zeitgenossen sollten die 0x16 sowieso nicht benutzen. Auf den anderen Wegen funktioniert die CN-Karte.


    Aber im Ernst: Zur Planung von Routen sollte ein Höhenmodel, das in MapSource funktioniert ( siehe Topo D V2 ) interessanter sein. Das ist sicher ein lohnenderes Betätigungsfeld. Im Colorado ist es allerdings überflüssig weil die Basiskarte diese Funktion übernimmt. Leider erst wählbar wenn man die Route starten Will.


    Und zur Beruhigung: 3-Byte-Typen kommen ja.


    Gruß
    Jürgen

    Hallo Gert,


    die Frage nach der Zukunft vom MapTk habe ich mir auch schon gestellt. Wenn ich Geld damit verdienen wollte - oder gar müsste - sähe die Zukunftsvision sicher anders aus. Ich bleibe aber dabei: In allererster Linie ist das Programm für meine Bedürfnisse. Etwas Statistik ( Länder aus der IP-Adresse :(


    Auch die Statistik bringt mich zu keiner anderen Einstellung. Das bedeute konkret, dass ich keine Zeit in Funktionen investieren werde, die ich selbst nicht gebrauchen kann. Meine Bedürfnisse sind aber durchaus veränderlich.


    Die nächsten Schritte, etwa in der geplanten Reihenfolge:


    • Filter für GPX-Dateien. Die Qualität der ohne professionelles Gerät aufgenommenen Tracks ist ohne Nachbearbeitung kaum als Weg in eine Karte zu übernehmen. Die Tracks enthalten aber mehr Information als nur die Koordinaten.
    • Eintragen und Löschen von Kartensätzen in die Registry ( natürlich nicht unter Linux ).
    • 3-Byte-Codes. Das hängt wesenlich davon ab, ob MapEdit das unterstützt. Lesen derartiger IMG-Dateien und TYP-Dateien sind schon lange implementiert, wobei ich keine derartigen IMGs ohne Lock kenne. Das ist eigentlich erste Priorität um für topgrafische Karten detailierter darstellen zu können. IMG-Dateien zu erzeugen ohne geeigneten Editor ist ziemlich sinnlos, deshalb am Ende der Liste. MapEdit das wohl irgendwann beherrschen.


    Kleine Funktionen und naturlich Fehlerkorrekturen sind jederzeit möglich.


    Auturouting: Brauche ich nicht weil


    • Unter meinen Topo-Karten liegt immer ein CityNavigator, d.h. Topo-Anzeige mit Autorouting. Das erspart das Umschalten.
    • Zuvor wären Fragen zu klären: Über welche Linien ( z.B. auch über 0x16 ) kann im Gerät geroutet werden ? In der Firmware fetsgelegt ? Ich habe keine routingfähige Topo-Karte um es auszuprobieren und werde auch nicht in eine solche Karte investieren.
    • Vernünftiges Kartenmaterial zu erstellen ist fprivat nahezu unmöglich ( Einbahnstraßen, Geschwindigkeitsangaben, verbotenes Abbbiegen, ... ). OSM mag da eine Zukunft haben, ist aber sicher noch lange Handelsklasse 2.


    Nebenbei arbeite ich an Funktionen ( z.Zt. separates Programm ) die komfortabel Wege in bestehende Karten einfügen und dabei bestehende Straßen nicht überschreiben.


    Gruß
    Jürgen

    Hallo Werner,


    als eifriger Wanderer hast Du sicher alle Punkte besucht und die Position korrigiert. Damit liegt das Copyright bei Dir. Mit Deiner Erlaubnis kann ich die Daten in die Karte übernehmen und weitergeben.


    Bitte öffne die GDB- oder GPX-Dateien mit MapEdit und klassifiziere die Punkte anhand dieser Datei: http://maptk.dnsalias.com/download/mycodes.pdf. Das ist für mich aus der Ferne sehr viel schwieriger und vermeidet Fehler - und reduzirt meinen Aufwand :D. In der Datei sind die blauen Einträge bevorzugte Typen, das reduziert die Vielfalt für die Suchfunktion. Durch die TYP-Dateien und MapEdit 1.0.50.1 ist das sonst für die Darstellung nicht mehr so wichtig. Trage auch bitte vorhandene Adressen oder Telefonnummern in MapEdit nach. Alle Punkte dürfen dann in einer MP-Datei gespeichert werden. Diese Datei dann bitte in das Upload-Verzeichnis kopieren oder per Mail an maptk@gmx.de.


    Danke !
    Jurgen