Beiträge von Papaluna

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

    :tup:GPSMapEdit 1.0 (update 58.0)


    (August 16th, 2009) Download version 1.0.58.0 (1280 K).


    • New feature: New concept "bookmark" is introduced: bookmark is a marked map place (being non-POI) used to keep various comments like errors found at map and so on. Any bookmark has type, sub-type and attributes from the list defined by textual user-customizable schemas which are stored in the subfolder \_BookmarkTypes. A bookmark may also define heading.
      To create a bookmark, please use menu item 'Tools | Create Object | Bookmark'. Bookmarks are stored only in MP files; they do not affect any "target" map formats to export (like .IMG or .NM2).
    • New feature: Import and export of Navitel speedcams (please see menu items 'File | Import | Navitel Speedcams to Bookmarks' and 'File | Export | Bookmarks to | Navitel Speedcams').
    • New feature: Export to Lowrance .LCM (thanks to Fiz Stein).
    • New feature: Type set "Lowrance" is introduced.
    • Fix: The support of Google Maps is updated.
    • Enhancement: Loading from Garmin .IMG now supports routing graph.
    • New feature: Find routing node by ID (please use menu 'Edit | Find | Routing Node by ID...').
    • New feature: Find road by RoadID (please use menu 'Edit | Find | Road by RoadID...').
    • Enhancement: Loading GPX tracks is made faster.
    • Fix: Crash while loading some .GPX files (thanks to Artem).
    • Enhancement: The attribute "LeftSideTraffic=Y" in the header of MP files is supported.
    • Enhancement: The datum EPSG:7059 and the projection EPSG:3785 is recognized for raster maps in .ECW format.
    • Fix: Selection by rectangle and by polygon now takes into account only visible objects (thanks to olavin, AlexPro).
    • Fix: Sticking now takes into account only visible objects (thanks to P.Platonov).
    • Enhancement: Current map skin for the default type set is used in the shapefile import wizard.
    • Fix: Crashes while editing entry points (thanks to Andrew2910, _Michael_).
    • Enhancement: Sticking to entry point.
    • Fix: Visualization of entry points in some cases.
    • Fix: Crash in 'Tools | Verify Map' while checking polygons overlapping in some cases (thanks to eprosso).
    • Fix: 'Tools | Verify Map' - the step in 'too close nodes' is diminished to 2.3 m for Garmin maps (thanks to Jeroen Boomgaardt).
    • Fix: Crash while exporting to .NM2 for Navitel 3.2.6 (thanks to Trufanov A.N., Alexander Snezhnevsky).
    • Fix: The message "Ignore invalid city" previously preventing export to .NM2 for Navitel 3.2.6 is removed (thanks to Eugene Zyatkov).
    • Fix: Loading 3-byte types of points from TXT/TYP map skins in some cases (thanks to k2roble).
    • Fix: Non-optimal routes in 'Tools | Test Routing Graph' in "fastest path" mode in some cases (thanks to Dust65).
    • Fix: Crash while saving MP in some cases (thanks to Dust65).
    • Fix: Crash while copying in some cases (thanks to Dust65).
    • Fix: Crash while some map changes (thanks to Dust65).

    Hallo arcoban,
    die Aussage von chris1234 ist absolut richtig.
    Bei dieser Karte werden die Routenberechnungsdaten bei der Kartenübertragung per Voreinstellung mit übertragen. Bei anderen Kartenprodukten kann/konnte man dies je nach Bedarf ein/ausschalten und so wenn erforderlich Platz im Kartenspeicherbereich( z.B: bei Geräten wo diese noch nicht auf der SD-Karte gepseichert wurden) sparen.


    Wenn diese Daten aber nicht mit übertragen werden, ist aber auch kein Autorouting mehr auf dem Gerät möglich.


    Von daher ist die Aussage von Kirchem, das diese Daten keine Rolle für die Routenberechnung spielen nicht richtig.


    Er meinte das eine in MS berechnete Route nach Übertragung auf dein Gerät evtl. nicht 1:1 abgebildet wird, da bei den Handgeräten eine Neuberechnung erfolgt. Basis bleibt dabei aber dennoch die Routenberechnungsdaten in der Karte + deine Route incl. der Routenwegpunkte. Sind die Routenberechnungsdaten nicht auf dem Gerät(s.o) ist kein Autorouting möglich.
    Aber wie erwähnt werden diese bei dem Kartenprodukt automatisch mit übertragen.



    Gruss Papapluna


    ein Garmin-Gerät routet automatisch AFAIK immer nur auf einer (1) routingfähigen Karte im jeweiligen Gebiet.


    AS FAR AS ANTON KNOWS :D
    Ok, sofern es sich um mehrere Karten mit vergleichbarer Informationsdichte handelt bzw. wenn gemeint war das die Routenberechnung erstmal grundsätzlich auf einer Karte erfolgt und nicht die Wege von mehreren Karten eines Gebietes gemeinsam zur Ermittlung der Route verwendet werden, ist dies richtig(sagt zumindest meine bisherige Erfahrung mit dem 60csx).


    Ich verwende aber z.B. auch selbst erstellte routingfähige Overlays der von mir erfahrenen Wege, welche natürlich eine geringere Informations(Wege)dichte haben als z.B. eine CN. Da habe ich nun folgenden durchaus brauchbaren NebenEffekt beobachtet.


    Route ich auf einer auf meinem Overlay erstellten Route und weiche von dieser ab so erfolgt(sofern gewünscht) eine Neuberechnung. Sofern noch Wege meines Overlays in der Nähe sind werden diese genommen. Wenn dies nicht der Fall ist und die CN oder OSM aktiv sind, erfolgt die Neuberechnung der Route dann auf Basis der Wege dieser Karte(n).
    Normalerweise scheint immer die Karte mit der höheren Drawpriority genommen zu werden wenn mehrere routingfähigen Karten aktiv sind.
    Inwieweit dies durch Einträge in entsprechenden KartenfileRegionen(siehe TRE etc.) möglicherweise beeinflusst werden kann, entzieht sich meiner Kenntnis.


    Gruss Papaluna

    Hi, Bernhard


    Ich habe einen Pentium 4 2,6 ghz 1GB RAM + einfachste 128 mb agp-Grafikkarte
    und bei mir ist z.B. der Kartenscroll in der 6.15.6 deutlich SCHNELLER als mit der parallel installierten 6.13.7.


    Gruss Papaluna

    Ok,


    dann kannst du dich ja bei Bedarf mit dem Thema Typ-file und deren Anpassung beschäftigen (oder es sein lassen).


    Eine relativ einfache Möglichkeit in Verbindung mit der Einbindung vorgefertigter Typ-Files findest du hier:
    http://familiehuzzel.spacequad…/GPS/Typefiles/index.html


    Hier geht es zum Online-Editor:
    http://ati.land.cz/gps/typdecomp/editor.cgi


    Oder hier bei MAPTK:
    http://maptk.dnsalias.com/
    Findest du eine Software zur Erstellung von Karten im Garmin img-Format, welche auch eine Möglichkeit zur Erstellung von Typ-files bietet.
    Allerdings erfordert dies schon, je nach Vorwissen, einige Zeit der Einarbeitung.


    Gruss Papaluna

    Hallo Bernd,

    Habe ich ein Problem mit dem Typefile


    Ich denke nein, aber wie kommst du darauf das es an diesem liegt. Hast du dieses denn manipuliert?


    Kl. braun-schwarzes Dreieck ist ja das Standardsymbol im Topo D V2 Typefile.
    Welche MS-Version verwendest du ?


    Ich habe es mal mit MS 6.13.7 + 6.15.6 probiert und habe festgestellt das mit Version 6.13.7 das dunkelbraune Dreieck in einem schwarzen Kasten, eher Kästchen, dargestellt wird. Ich vermute mal das du dies meinst.


    In der 6.15.6 ist die Darstellung hingegen korrekt.( dafür hat diese ganz andere Probleme aber das ist ein anderes Thema)

    Wenn ich im MS den Berg suche und dann einen WP anlege, dann schägt MS auch schön das Bergsymbol vor.


    Ja dabei handelt es sich aber um das Symbol für Wegpunkte.
    Symbole sind nicht immer gleich. Weder zwischen GPS+MS noch unbedingt innerhalb. So ist halt die Darstellung eines Kartenobjektes( wie z.B. eines Gipfelpunkte) evtl. anders, als das Symbol das du einem Wegpunkt zuordnen kannst.


    Gruss Papaluna

    1. Dein Track wurde bei mir immer vollständig angezeigt
    2. Verbindungslinie habe ich auch keine


    zu 2. fällt mir im Moment nur ein
    -Luftliniennavigation aktiv ? Linie von akt. Position zum Track?
    -Trackabschnitte wurden in nicht korrekter Richtung zusammengefügt.
    Bsp: ich teile einen Track und kehre dann die Reihenfolge der Trackpunkte von TrackHälfte2 um. Dann verbinde ich die beiden Hälften wieder. Dann werde ich plötzlich eine Verbindungslinie haben vom Ende Track1 zum Anfang Track2 (was ja eigentlich das Ende des Gesamttracks war vor der Umkehrung).


    Gruss Papaluna


    P.S. kein Anhang zu sehen

    Es liegt möglicherweise doch an der Datei , obwohl ich sie mit Mapsource unter Xp SP3 einwandfrei aufs Gerät laden konnte und auch wieder herunter.
    Wenn ich den Upload wie von dir beschrieben mittels Gpsbabel mache, habe ich dann zwar den Track im Speicher für die aktuelle Trackaufzeichnung, aber der Versuch diese nunmehr wieder mittels Mapsource herunterzuladen geht nicht. Es erfolgt eine Fehlermeldung im Sinne von das irgendwas mit dem Track nicht stimmt und ich ihn doch im Gerät löschen soll. Na ja würde einen ja nicht weiterbringen. Interessanterweise kann ich den Track aber intern im Gerät in einen der Trackspeicher vollständig abspeichern (waren im Beispiel ja nur 350 Trackpunkte). Wenn ich dann die Akt. Aufzeichnung lösche kann ich zumindest den gespeicherten Track mit MS herunterladen.
    Wie dem auch sei, irgendwie liegt es an der Übertragung durch Gpsbabel bzw. am Track.


    Ich habe dann den Trackpunkten mittels TTQV mal timestamps verpasst.
    Danach konnte ich den daraus resultierenden Track mittels GPSbabel ins ACTIVE LOG des GPS übertragen und von dort mit MS auch wieder ohne Fehlermeldung herunterladen.



    Gruss Papaluna

    Hallo CFJH,


    1. dein Track ist ok. Ich konnte ihn vollständig mit Mapsource auf mein GPS(60csx) hochladen und auch wieder runterladen.
    2. Tracks mit 350 Punkten passen doch auch in einen der 20 "normalen" Trackspeicherplätze(max. 500 Punkte)
    3. Ist dein Speicher für die Aufzeichnung des ACTIVE LOG ="Trackaufzeich" im Trackmenu auch auf "überschreiben"(unter Einstellung) eingestellt?
    oder kann es ein das
    4. dieser Speicher bei dir voll ist und 3. nicht erfüllt ist?
    Dann würde der zu übertragende Track gegebenenfalls gekürzt.




    Gruss Papaluna

    Hallo Schunter,

    Kann ich die Abweichung vom Track irgendwo sichtbar oder hörbar machen (Kursabweichung, Signale?)


    Ich habe ja selbst nur ein 60csx.
    Dort habe ich hierfür gelegentlich den Kursabweichungsalarm ( Einstellung-Marine) beim TrackBack verwendet.
    Ich habe mir gerade mal das Oregon-Manual runtergeladen und auf Seite 30 gesehen das es so etwas beim Oregon auch zu geben scheint.


    Gruss Papaluna

    @Klaus
    Du hast dbzgl. natürlich recht(DEMO-Modus Gpsmadedit, Speedclass etc.), dies ist mir soweit selbst auch bekannt.
    Aber wie ich mich zwischenzeitlich schon selbst korrigiert hatte, habe ich mein 60er zu 99 % nur als Radler oder Fussgänger benutzt und meine Aussage im Beitrag #10 war da leider betriebsblind und missverständlich formuliert und sollte eigentlich nur für die Modi Radfahrer/Fussgänger gelten ( Kam wohl auch ein wenig daher weil glücki in #5 von einem konkreten Fall im Fahrradmodus gesprochen hatte).
    In diesen Modi( und nur dort) lassen meine Erfahrungen mit dem 60er auf feste Durchschnittsgeschwindigkeiten schliessen.


    In den KFZ-Modi sieht das natürlich anders aus.



    @Glücki
    wie gesagt meine Aussage zu den festen Durchschnittsgeschwindigkeiten
    gilt nur für Modus Radfahrer / Fussgänger.
    Karten:
    MG9
    CN9
    OPENMTB
    Eigene routingfähige Overlays



    Gruss Gert

    @klawo


    sorry das ich dich vergessen hatte.
    Du hast mich schon richtig verstanden aber wie ich zu Andreas schon anmerkte, habe ich es nur aus der Perspektive des Radlers/Wanderers betrachtet und da werden anscheinend feste Geschwindigkeitswerte verwendet.
    Im AUTOrouting jedoch werden die Attribute der Strassen (speedclass) entsprechend ausgewertet und fliessen in die Berechnung der ETA ein


    Habe gerade z.B. mal von meinen 60er 2 Routen als Radfahrer berechnen lassen:
    1: Köln-Leichlingen 25,3 km in 1Std:22min
    2: Köln-München 651 km 34Std:08min
    ~18,5km/std im Durchschnitt
    Und nach meiner Beobachtung wird dieser Wert unterwegs immer angewendet um die ETA zu bestimmen egal welche tatsächliche Geschwindigkeit ich fahre.


    Gruss Papaluna

    @Andreas
    Da bin ich in der Tat eine wenig betriebsblind, da ich seit langer Zeit kein Auto mehr mein eigen nenne.
    Du hast natürlich recht sofern man sich motorisiert bewegt. Dann werden mit der Einstellung des entsprechenden Fahrzeugtypes auch Attribute der Strassentypen im Kartenmaterial wie die Speedclass etc. ausgewertet.


    Ich habe das aus reiner Gewohnheit aus der Perspektive des Radlers und Wanderers gesehen. Und da konnte ich keinen Einfluss der speedclass auf die Berechnung der Ankunftzeit etc. feststellen. Nach meiner Beobachtung werden im Fahrrad/Fussgänger feste Geschwindigkeitswerte(Rad ~18,5km/std) genommen. Eine Anpassung an die tatsächlich gefahrene Geschwindigkeit habe ich nicht festgestellt.


    Gruss Papaluna

    Nach meiner Erfahrung mit dem 60er, scheinen dort fixe Werte für die Durchschnittsgeschwindigkeiten der einzelnen Fahrzeugtypen hinterlegt zu sein.


    Die ETA wird dann sukzessive angepasst. Wenn ich z.B. mit dem Rad noch 9 km vor mir habe mit 10% Steigung, liegt die ETA bei Aktueller Zeit + ca. 30min (fürs Rad wird ein Wert von ca. 18km/Std angenommmen). Na das dürfte wohl nur Contador schaffen:D.


    Von diesem Extremfall mal abgesehen benutzte ich die ETA durchaus um mir einen groben Überblick zu schaffen, wann ich z.B. meinen Zielbahnhof für die Rückfahrt und den entsprechenden Zug erreiche.
    Im Allgemeinen funktioniert dies durchaus brauchbar.


    Der Automodus zeigt entsprechend immer utopische ETAs an.
    Nur kurz vor dem Ziel kommt es dann zu einer Näherung des ETAs. Aber das ist dann reine Mathematik.
    Eine Anpassung an die tatsächlich gefahrene Geschwindigkeit gibts es beim 60er wohl nicht. Andere Garmin-Geräte(wie oben erwähnt) können dies aber wohl.


    Eine Auswirkung des Kartenmaterials habe ich dabei bisher nicht festgestellt. Weder bei selbst erstellten noch kommerziellen Karten.


    Gruss Papaluna

    Nur der Vollständigkeithalber:


    Die von Wilfried beschriebene Methode der Trackzusammenführung mit MS funktioniert im vorliegenen Fall da es sich um einzelne Anschnitte letztlich einer Trackaufzeichnung handelt, d.h. die Trackpunkte in einer chronologischen Richtung nach einander liegen.
    Versucht man Trackabschnitte z.B. von unterschiedlichen Aufzeichnungen zusammenzuführen funktioniert dies dann gegebenenfalls nicht mehr.
    Da müsste man dann in diesem Falle die Timestamps entsprechend anpassen was mit MS nicht möglich ist.
    (Mit dem bereits erwähnten TTQV geht das dann wiederum kinderleicht. Allerdings vermisse ich da eine paar ganz einfache Tools wie z.b. den Radiergummi den es bei MS zur Trackbearbeitung gibt.)


    Gruss
    Papaluna

    Hi Elster ,


    In MAPSETTOOLKIT gibt es einen Button mit "Check Registry" beschriftet.
    Benutze den doch mal und schaue nach ob dort ein Fehler gefunden wird.


    Zur Kombination Mapsource+Vista und evtl. dadurch auftretenden spez. Problemen kann ich leider nichts beitragen.


    Gruss Papaluna

    @Toby


    Zur Info:


    MAPTK unterstützt keinen Differenzierung in Tag+Nachtmodus.


    Wenn du das möchtest musst du auf cgpsmapper und seine etwas andere Beschreibung für die Typ-files ( Stichwort: xpm-Definiiton etc.)zurückgreifen.


    Als Basis könntest du dann die von MAPTK generierte txt-Datei( siehe Menuepunkt TYP=> PRJ-File to MAPEDIT skin) nehmen und die fehlenden Definitionen für den Nachtmodus sowie die für cgpsmapper fehlenden Einträge des Headers nachtragen.



    Gruss Papaluna