Selbst erstelltes Routingfähiges Overlay optimieren

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 ...
  • Moin, moin,


    nachdem ich mit bisher damit zufrieden gegeben hatte mir nur transparente Overlays der von mir erfahrenen und erwanderten Wege zu erstellen, habe ich mich nunmehr entschlossen diese autoroutingfähig zu machen.


    Um es klar zu sagen, auch wenn einem Programme wie Gpsmapedit eine Menge Arbeit abnehmen, bleibt noch eine Menge übrig. Ich spreche hierbei nicht von 1,2,3... Std. sondern evtl. hunderte von Stunden. In dem Zuge ist mein Respekt für die Arbeit die in kommerziellen Produkten steckt (bitte keine Diskussion hier über- von wem unter welchen Konditionen)nochmals angestiegen und 150€ für eine CN relativieren sich da doch gewaltig.


    So, mein MTB/Wanderoverlay ist jetzt in groben Zügen sowohl in MS als in meinem 60csx autoroutingfähig. Es funktioniert prinzipiell. Jetzt geht es ums Feintuning bzw. evtl. auftretende Probleme bzw. Fallstricke.


    Hier habe ich z.B. wg. der Meldung "Routenberechnungsfehler" in Verbindung mit dem 60csx um eure Infos nachgefragt.
    http://forum.pocketnavigation.…vb/showthread.php?t=33123


    Die Trennung Hardware-Software-Kartendesign ist ja nicht immmer zu ziehen. Das Ganze funktioniert ja als Einheit.


    Hier geht es mir aber darum Informationen, Erfahrungen zu erhalten wie das Overlaydesign optimiert werden kann um optimale Routingergebnisse zu erhalten.
    D.h. ich würde es gerne etwas sicherer steuern können.


    Um eines direkt klarzustellen
    - man wird immer, geräteabhängig mehr oder weniger,mit dem Problem konfrontiert sein das die Routenberechnungergebnisse von Ms nicht notwendigerweise mit denen des jeweiligen Gerätes übereinstimmen.
    - die Annäherung zw. beiden vermutlich umso grösser sein wird, jemehr Zwischenziele( beim 60csx ma. 50) verwendet werden.


    -Autorouting bzgl. der Gerätesoftware und Wegtypen+Parameter für die Bedürfnisse eben des Autoroutings konzipiert sind und nicht nicht fürs wandern und radfahren.


    -all die Informationen leider nur aus persönlichen Erfahrungen und nicht aus verfügbaren Informationen seitens Garmins zu erhalten sind und letztlich mehr in Versuch und Irrtum-Strategien gewonnen werden/wurden.


    Bisher hatte ich also ein Overlay meiner Wege wo ich durch Zuordnung unterschiedlicher Weg/Polylinetypen und Gestaltung mittels Typ-File, diese Wege Klassifiziert und optisch entsprechend dargestellt habe.
    Ich habe dazu die normalen Strassentypen halbwegs passend zugeordnet (0x16=Singletrail,0x0a=Besonders netter sonstiger Weg,0x7 Wirtschaftsweg,0x6 Wirtschaftsweg asphaltiert,....,0x2 Hauptstr, etc.)


    In Bezug auf das Autorouting möchte ich nun, im Rahmen der Möglichkeiten,
    das Overlay so anpassen, das ich z.B. eher über Singletrail oder mehr über asphaltierte Wirtschaftswege geroutet werde, je nachdem, welche Vorgaben ich mach.


    Als Gestaltungsmöglichkeiten in Bezug auf das Overlay stehen zur Verfügung:
    1. Linientypen (routingfähige)
    2. RoutingParameter der Linientypen in der Karte ( Routeparam=...... in mp-files)Hier wird die Routeclass (Autobahn, Nebenstr,Anlieger etc., Speedclass, Eonbahnstr,Mautstr, Restriktionen für die einzelen Bewegungs/Fahrzeugtypen) eingestellt
    3. Parameter der Route-Nodes(Turn-Restrictions)
    [Restrict]Nod=2897...[END-Restrict] in MP-file


    Als Gestaltungsmöglichkeiten in Bezug auf GPS+Mapsource stehen zur Verfügung:
    1. Einstellmöglichkeiten bzgl. des Berechnugsverhaltens beim Autorouting im Gerät/Mapsource
    2. Setzen der Routenpunkte/Zwischenziele


    Ich möchte das Overlay so gestalten das ich z.B. vorgeben kann, das wenn möglich über Singletrails geroutet wird, auch wenn es eine parallele evtl. kürzere/schnellere Route über eine Strasse gibt oder auch umgekehrt.


    Das das ganze auf grund der obigen Beschränkungen nur näherungsweise zu realisieren ist, ist mir klar, nichtsdestotrotz will ich mal den Winter nutzen um mich dem zu nähern.


    Evtl. ist es notwendig die verwendete LinienTypenanzahl zu verkleinern.
    Dann würde ich mir ein Overlay für die grafische Darstellung(mit mehr Typen) und eines nur fürs Routing(mit weniger Typen) basteln.


    Also wenn Ihr Ideen habt oder schon eure eigenen Erfahrungen gemacht hat, ich bin dankbar für Tips, Anregungen, Infos, Beispiele.


    Gruss und Dank
    Papaluna

  • Hallo papaluna,


    es erstaunt mich immer wieder wie die Entwicklungen parallel laufen! :) Vor ein paar Wochen habe auch ich, nachdem ich mir bisher eigentlich immer Overlaykarten erstellt habe, meine erste "experimentellen", routingfähigen Karten erstellt. Leider stehen ja dafür, wie Du schreibst, nicht allzu viele Informationen zur Verfügung! Beruht alles nur auf Untersuchungen und Experimenten.


    Als Unterlagen für meine Untersuchungen habe ich nachstehende Quellen verwendet. Vielleicht ist ja was Neues für dich dabei und gibt Neues her:


    http://v-dorogu.narod.ru/article/routemap.htm Ist zwar auf russich, aber Google Sprachtools reichen für das Verständnis des Artikels aus


    http://rotweilermaps.com/files…lersAuto-routingGuide.pdf nicht mehr ganz aktuell, da die neuen Möglichkeiten von GPSMapEdit noch nicht beschreiben sind.


    http://www.malsingmaps.com/wik…php/Making_a_Routable_Map


    Ich fand eigentlich, dass die Arbeit zum Erstellen der Knoten, ... in GPSMapEdit gar nicht so schlimm ist. Knoten erzeugen geht leicht von der Hand, schwierig ist eher das Nacharbeiten und Zuweisen von Abbiegevorschriften. Wobei man darauf bei Fahrrad- oder Wanderkarten wohl eh meistens verzichten kann. Aufwendiger wird es aus meiner Sicht mit dem Zuweisen der Eigenschaften zu den Straßen, Wegen. Ich habe dazu meine Straßen, Wege bereits nach späteren Klassen auf verschiedenen Dateien unterteilt, die ich dann einzeln lade, Eigenschaften zuweise und dann wieder abspeichere. Erst am Ende erzeuge ich dann die Knoten und erstelle eine Karte daraus.


    Leider weist GPSMapEdit den routingfähigen Polylinien nicht automatisch eine "Default" Eigenschaft für das Routing zu (Z.B: Typ Autobahn ==> Route Class = (4)Major HW, Speed Limit = (7)No Speed Limit). Die haben immer erst einmal nur die Einstellung Route Class = (0), Speed Limit = (0) und müssen so immer erst einmal richtig zugewiesen werden, außer man möchte diese Voreinstellungen behalten.


    Das Routing in GPSMapEdit hat dann meistens auch wie erwartet geklappt. Kürzerer Weg oder kürzere Zeit in MapSource funktioniert auch. Am GPS (VISTA HCx bzw. 60Cx) habe ich nur einfache Versuche gemacht. Was mir z.B. bisher nicht gelungen ist, ist zdie Einstellung zur Vermeidung "unbefestigter Straßen", die sich in GPSMapEdit scheinbar direkt nach dem definierten Linientyp richtet, in MapSource aber überhaupt keine Auswirkungen hat. Gerade diese Eigenschaft ist aber für die Unterscheidung von Rennrad- (bei mir Tandemtouren) auf denen ich weitestgehend asphaltierte Wege und Straßen bevorzuge, normalen Fahrradtouren und ggf. MTB Touren für mich das Hauptkriterium.


    In MapSource scheinen sich, zumindest entnehme ich das der russischen Beschreibung so, nur die Einstellungen für Speed Limit, Route Class und die sonstigen Einstellungen (Einbahnstraße, Maut, ...) auf dem Karteireiter Routing einer Polylinie in GPSMapEdit auszuwirken. Der Linientyp selbst hat keinen Einfluss.


    Man muss wahrscheinlich daher an dieser Ecke ansetzen. Ich wollte über den Winter mal ein bisschen weiter experimentieren. Z.B. mit der Option Mautstraße als Eigenschaft für Routen die ich nur mit dem MTB befahren kann. Tragestrecken, Starke Steigungen, ... bekommen dann die Eigenschaft Mautstraße. Oder an den Geschwindigkeiten schrauben um bei "Kürzere Zeit" den Rennradstrecken eine hohe Geschwindigkeit zuzuweisen, die dann zu deutlich kürzeren Zeiten führt (das hat bei meinen Versuchen bisher als Einziges geklappt). Leider Hab' ich da nicht so viel Zeit.


    Etwas scheint manchmal zu Fehlern zu führen. Wenn Du z.B. eine Strecke mit einer bestimmten Option berechnen lassen willst (z.B. vermeide Mautstraßen), der Algorithmus dann aber keine durchgängige Strecke ohne Mautstraßen findet, kommt eine Fehlermeldung, dass keine Route möglich ist.


    Vielleicht tut sich ja in der nächsten Zeit etwas an der OSM Ecke. Da geht es ja mit schnellen Schritten voran.


    Zurzeit habe ich es erst einmal bei einfachen "A nach B" Routingkarten belassen. Berechne Track oder Route, die exportiere ich dann und lade sie in GPSMapEdit. Dann Aufbereitung zur routingfähigen Karte, Import in MapSource, Setzen von Wegpunkten auf dieser neuen Karte (Anfangspunkt, Endpunkt, ggf. Zwischenpunkte) damit ich aussagekräftige Namen habe, Route auf dieser neuen Karte neu berechnen. Routet dann natürlich nur auf dieser einen "A nach B" Routingkarte. Das Ganze lade ich dann aufS GPS (Karte, Route und Wegpunkte). Karte liegt hinter meiner TOPO D. Dann am GPS Route neu berechnen auf der "A nach B" Routingkarte. Route folgt dann natürlich exakt der von mit gewünschten Strecke, ich bekomme Abbiegehinweise, kann die Autobahnseite benutzen, ... Ist natürlich noch keine vollständige Lösung, aber für die Aufbereitung meiner Touren besser als das Nachfahren eines einfachen Tracks. Und wer keine Arbeit macht, der macht sich eben welche :) Benötige aber zurzeit weniger als eine Stunde zur Erstellung einer "A nach B" Routingkarte. Für eine Mehrtagestour lohnt sich das dann schon.


    Grüße


    weoli

  • Hallo Weoli,


    schön das es noch jemanden gibt, der sich damit beschäftigt. Danke für deine Links, welche mir bis auf die Russische Seite bekannt waren.


    1. Arbeitsaufwand
    Wenn man erstmal den Dreh herausgefunden hat, ist es im Prinzip wirklich recht schnell gemacht, da stimme ich dir zu.
    Wenn man allerdings wie ich ca. 10.000 Polylines mit derzeit ca. 12.000 Routingnodes hat, ist das schon etwas aufwendiger. Ich habe die "blauen" Nodes nicht gezählt, aber ich sitze seit 2 Monaten dran die nachzuarbeiten.


    2.Gpsmapdedit Default für Routeparam
    Wenn du den routinggraph erstellen lässt, werden Default Werte wie z.B. 6,4,0,0,0,0,0,0,0,1,1,0 bei typ=0x1 etc. automatisch vergeben.


    3. Einfluss des Linientyps auf das Routingverhalten
    Im Testing des Routinggraphs bei Gpsmapedit scheint es wie du es beschreibts in der Tat über den LinienTyp zu gehen.
    Für MS + 60csx habe ich den Eindruck gewonnen(ohne 100% sicher zu sein das), das der Linientyp keine Rolle zu spielen scheint.
    Das finde ich wichtig zu wissen, denn dann könnte man z.B. die generelle Priorität beim Routing durch entsprechendes setzen von Routeclass +Speedclass umzukehren.


    Anmerk.:
    Bei Typ 0x1a (Fähre) ist mir allerdings aufgefallen, das der anscheinend nur vernünftig bei 1zu1 Anschlüssen funktioniert während Typ 0x1b(auch Fähre) auch 1zuN Anschlüsse verarbeitet.


    4. Routeparam
    Die denied_Fahrzeugtyp Einstellungen stellen wohl KO-Parameter da. Wenn die gesetzt sind kann mit der Entsprechenden Fahrzeugtypeinstellung im Gerät nicht darüber geroutet werden.
    One-Way wird wohl genauso restriktiv ausgelegt.
    Maut/Toll vermutlich auch. Wäre wie du auch erwähntest evtl. ein Parameter um zumindest eine "Richtung" zu forcieren.


    5. Vermeidungseinstellungen
    Dies sind wohl nur Vorgaben im Sinne von "sofern es möglich ist".
    Wenn es keine Alternative gibt wird halt doch darüber geroutet.
    Evtl. wirken sich auch noch andere Einstellungen wie z.B.der Fahrzeugtyp aus.
    Insgesamt sind die Ergebnisse für mich bisher nicht eindeutig.
    Man müsste halt ein Testnetz bauen um die Wirkung der Parametereinstellungen und evtl. Wechselwirkungen herauszufinden.


    Es wäre interessant zu wissen womit die jeweilgen Einstellungen korrespondieren
    60csx...................Gpsmapedit
    Maut....................routeparam(toll)
    Ungeteerte Strassen.....Routeclass ??? evtl. doch Linientyp ???
    Fernstrassen............Routeclass ??? evtl. doch Linientyp ???
    Kehrtwendungen..........Routeclass ??? evtl. doch Linientyp ???
    Fahrgemeinschaftsspuren.Routeclass ??? evtl. doch Linientyp ???


    6. Einstellung "Kürzere Zeit" oder "Kürzere Strecke"
    Wird wirklich jeweils die kürzere Strecke genommen.? Um welche Strecke handelt es sich dann? zum nächsten Node oder nächsten Zwischenziel oder Gesamtweg?
    Wird Kürzere Zeit aus Speedclass und Strecke ermittelt?


    Die Idee die Speedclass und "Kürzere Zeit" zu benutzen um eine best. Routenführung zu forcieren kam mir auch schon. Habe es bisher jedoch noch nicht ausprobiert.


    7. Routenberechnungsfehler
    Treten auf:
    - wenn ich z.B. versuche mit Fahrradeinstellung mit Routeparam=6,4,0,0,0,0,0,0,0,1,1,0 bei typ=0x1 über den Typ zu routen und es keinen anderen Weg zum gewünschten Ziel gibt.
    Hast du ja auch ähnlich beschrieben.
    - wenn die Anzahl der Abbiegeanweisungen zwischen zwei Routenwegpunkten zu gross wird
    (eine im Vorfeld kaum zu bestimmende Grösse da z.B. MS und 60csx unterschiedliche Anzahl Anweisungen generieren)


    8. Karte
    Einzelne Tourenkarten haben auf jeden Fall einen Vorteil. Man hat eine 1 zu 1 Übertragung der Route zw. MS und Gerät.
    Das ist bei meiner Komplettwegekarte nicht unbedingt der Fall. Hier muss ich im Prinzip im Gerät überprüfen ob die dort berechnete Route mit der in MS geplanten übereinstimmt oder micht überraschen lassen wo ich hingeführt werde(kann ja auch mal ganz witzig sein).
    Dafür kann ich dann aber on the trail gegebenfalls die Route anpassen.
    Wo Licht ist ist halt auch Schatten.


    Ich lege zur Zeit meine Karte als Overlay über die Topo. Durch grafische Gestaltung mittels Typ-file habe ich dann noch direkt Infos über den Wegtyp im Blick. Allerdings wird durch die vielen verwendeten Linientypen die Übersicht über das Routing sicherlich nicht leichter.



    Gruss Papaluna

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen, bitten wir Euch, über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben!
    Alternativ sehr gerne auch per Paypal spenden.
    Vielen, vielen Dank ...
  • Hallo papaluna,


    habe zurzeit leider nicht sehr viel Zeit zum Testen. Vielleicht wird es zwischen den Feiertagen etwas .


    Bei der OSM Ecke habe ich noch die folgenden Diskussionen zum Thema gefunden. Vielleicht kannst Du da noch einiges rauslesen, falls Du die nicht eh schon kennst:


    http://forum.openstreetmap.org/viewtopic.php?id=2008
    http://forum.openstreetmap.org/viewtopic.php?id=666
    http://forum.openstreetmap.org/viewtopic.php?id=1162


    http://wiki.openstreetmap.org/wiki/Mkgmap/routing
    http://wiki.openstreetmap.org/wiki/Talk:Mkgmap/routing


    Mir war z.B. die Option -e für cgpsmapper zum Unterdrücken der Fehler bei zu dicht zusammenliegenden Knoten (das sind diese ominösen 5.4 m, die cGPSMapper anmahnt) neu. Der Rest gibt aus meiner Sicht auch nicht allzu viel Neues her. Das ist genauso ein Stochern im Nebel und Rumprobieren, wie wir es hier betreiben. Schade, dass über den Routingalgorithmus oder besser gesagt über den Einfluss der verschiedenen Parameter so wenig bekannt ist.


    Zitat

    Ich habe die "blauen" Nodes nicht gezählt, aber ich sitze seit 2 Monaten dran die nachzuarbeiten.


    Ich vermute mal, dass Du deine Tracks in TTQV verwaltest. Ich mache dass zumindest mit meinen Zeichnungen und Tracks für meine selbst erstellten Karten so. Und dabei fällt mir immer wieder auf, dass selbst dann, wenn ich in TTQV die Polylinien mit der Option VORHANDENE PUNKTE FANGEN erstelle, und diese in TTQV somit eigentlich exakt aufeinander liegen, die Knoten in GPSMapEdit dann doch einen Abstand zueinander haben. Hast Du das Problem auch? Ich muss die Knoten dann immer mit Verify Map in GPSMapEdit suchen. Ist aber, wie Du schreibst, mühsam, ...


    Ob die Option kürzere Strecke ein sinnvolles Routing ergibt, weiß ich nicht so Recht. Ich habe nur die diversen Diskussionen hier im Forum im Hinterkopf man solle beim Routing für das Rad immer die Option kürzere Zeit wählen, das kürzere Strecke zu den seltsamsten Ergebnissen führt.


    Als Unterschied beim Routen für das Fahrrad und Fußgänger ist mir bisher nur aufgefallen, dass ich als Fußgänger durch eine Einbahnstraße in beide Richtungen geroutet werde. Als Fußgänger hingegen nicht.


    Werde mir jetzt wohl erstmal eine kleine Testkarte erstellen und damit weiter versuchen.


    Schöne Weihnachten


    weoli

  • Hallo Weoli,


    1. zun Herumstochern
    Um überhaupt ein Chance zu haben muss man schon sehr sehr systematisch heran gehen.
    Scheinbar wenige Parameter(MS,GPS,Kartenparameter) ergeben jedoch schnell eine Unzahl an Möglichkeiten wo es mir von aussen schwer fehlt jeweils das Ergebniss zu beurteilen. Die Ergebnisse scheinen mir dabei nicht immer unbedingt eindeutig zu sein. Ohne den Routingalgorhytmus zu kennen wird das recht mühsam und wohl auch nur Stückwerk bleiben.


    2. RouteParam
    Im Moment scheint mir das experiementieren mit den PolylineParametern Routeclass und Speedclass am ehesten Erfolg zu versprechen da sich das Autorouting in der Basis hier daran orientiert. Entprechend sucht die Routingsoftware erstmal nach der Autobahn und erst wenn keine da ist die nächst tiefere Strassenklasse usw.
    Entsprechend werde ich jetzt erstmal probieren bei den Typen die Routeclass zu wechseln und die Speedclass anzupassen. Grob gesagt 0x16 erhält Routeclass 4 und 0x01 fortan Routeclass 0 usw.
    Ich habe mir heute ein Perlskript geschrieben mit dem ich die Routeparam=-Einträge im mp-file anpassen kann.


    Toll und oneway sind für mich auch noch interessant.
    Oneway z.B. für Trails die für mich nur in eine Richtung fahrbar sind.(Über Ambulanz/Fussgänger kann man das zur Not wieder ausschalten).


    KO-Kriterien scheinen wirklich nur die denied-Parameter zu sein. Evtl. kann man die benutzen, z.B. in der Art alle unbefestigten Wegetypen(wie man sie definiert hat) für einen Fahrzeugtyp ausschließen und diesen dann fürs RR fahren nehmen.


    3.Vermeiden-Einstellungen
    Bei
    -Fahrgemeinschaftsspuren/carpool lane/HOV(high occupacy vehicle).HOV gibt es nicht im europäischen Kartenmaterial.
    -Fernstrassen
    -Kehrtwendungen
    wäre es erstmal nett die betroffenen Polylinetypen zu kennen.


    Unpaved roads/ungeteerte unbefestigte Str. bezieht sich wohl ausschließlich auf Type 0x0a. Type 0x16 habe ich bisher nicht in autoroutingfähiger Garminkarte
    gesehen.(habe allerdings auch nicht komplett alle Kachel einer Karte untersucht, sondern nur Stichprobenartig).


    In MS wird Fahrrad von sich aus nicht über 0x0a geroutet. Man muss schon ein Zwischenziel setzten. Die Einstellung Fussgänger routet direkt darüber.
    Im 60csx wird mit Fahrrad auch direkt über 0x0a geroutet. Vermeide "Ungeteerte Strassen" versucht entprechend wenn machbar solche Wege zu umgehen.


    4. Fahrzeugtypen
    Fussgänger routet gegebenenfalls über Einbahnstr. wie du angemerkt hast.
    In MS wird auch bevorzugt über 0x0a geroutet sofern vorhanden.
    Die ETA(EstimatedTimeArrival)) ist allerdings immer auf Durchschnittsfussgängertempo berechnet und passt sich auch nicht der tatsächlichen Geschwindigkeit an( von daher für mich fürs Rad uninterresant).
    Wie sich die ETA bei den motorisierten Typen verhält müsste ich nochmal ausprobieren. Irgendwie habe ich zu diesem Thema nichts eindeutiges gefunden.


    5. Schneller-kürzer
    Mit dem kürzer Zeit als besserer Einstellung in Verbindung mit Rad habe ich auch gelesen. Eine Gewichtung fällt mir bei den nicht so ganz transparenten, teilweise gar skurillen Ergebnissen des Autoroutings mit dem Rad nicht leicht.


    Trotzdem werde ich mal versuche dies in Verbindung mit der Speedclass zu Nutzen.
    Ich denke daran z.B. die Speedclass meiner asphaltierten Wege entsprechend Höher anzusetzen als die der weniger befestigten Wege. So kann ich evtl. mit "Kürzere Zeit" ein Routing mit Schwerpunkt auf diese Wegtypen forcieren.


    6. Datenverwaltung, TTQV, Mapedit, cgpsmapper
    Im Moment habe ich in TTQV eine Datenbank für die Karte mit Tabellen für die einzelnen Wegtypen, welche jeweils auch Polylinetypen sind(z.B. Tabelle Trails für 0x16)


    Das Problem mit dem Fangen der Punkte tritt gelegentlich auf. Soweit ich das sehe, liegt das daran das an der Stelle mehre fangbare Objekte dicht beieinander leigen. Das können z.B. auch Punkte aus einer angezeigten Karte oder/und einem darüberliegenden Overlay sein.
    Die tausenden von Blauen Nodes kommen bei mir einfach dadurch, das ich für die Karte bisher nicht auf Anschlüsse der Linien geachtet hatte, da es für ein einfaches Overlay eigentlich völlig egal ist. Hätte ich das von den ersten Tracks an gemacht, hätte ich jetzt nicht soviel Arbeit auf einmal damit.

    VERIFY in Mapedit hilft leider nicht beim finden fehlerhafter Nodeverbindungen.
    Lediglich "too close node" "duplicated nodes" werden gefunden aber eben nicht diejenigen die nicht connected sind(oder habe ich das was übersehen??)


    option -e CGPSMAPPER kenn ich, allerdings eliminiere ich Fehler doch lieber.
    Beim ersten Versuch hatte ich so ca. 400 Fehlermeldung mit Verify. Mittlerweile treten diese zum Glück nur noch selten auf, da die Karte langsam "sauber" ist und nur durch die Nachbearbeitung gelegentlich neue Fehler reinkommen.


    Auch dir Frohe Weihnachten und schöne Tage


    Papaluna

  • Hallo papaluna,


    im map_authors Forum bei yahoo habe ich gerade die folgende Frage gefunden:



    Vielleicht erklärt das, warum das "Vermeide unbefestigte Wege" in Mapsource und am Gerät nicht richtig funktioniert. Leider hat bei yahoo keiner darauf geantwortet. Aber wenn Stan schon sagt, dass das nicht implementiert ist ...


    Du hast dich ja in der Zwischenzeit ein bisschen intensiver mit den OSM Karten und dem Routing auseinander gesetzt, wie ich an den übrigen Beiträgen hier im Forum sehe. Funktioniert das "Vermeide unbefestigte Wege" denn da besser?


    grüße


    weoli

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen, bitten wir Euch, über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben!
    Alternativ sehr gerne auch per Paypal spenden.
    Vielen, vielen Dank ...
  • Hi weoli,


    Vielleicht erklärt das, warum das "Vermeide unbefestigte Wege" in Mapsource und am Gerät nicht richtig funktioniert. Leider hat bei yahoo keiner darauf geantwortet. Aber wenn Stan schon sagt, dass das nicht implementiert ist ...


    In gewisser Weise funktioniert das ja schon. Nur ist ohne Kenntnis der eigentlichen Routingsoftware in den GPS-Geräten und von MS nicht vorhersehbar wie es sich letzlich auswirkt. Viele der Ergebnisse die ich auf meinem 60csx erhalten habe sind für mich einfach nicht wirklich nachvollziehbar.
    Ausser der Feststellung das sich Linientyp, Routeparam, Routeclass und Speedclass sich auf das Routingverhalten auswirken, kann ich keine definitive Aussage machen. Nach vielen Experiementen bin ich z.B.wieder dazu gekommen, die Linientypen möglichst entsprechend wie in den Original-Garminkarten zu verwenden. Damit erhalte ich die besten Routingergebnisse.
    Wege die ich unter allen Umständen nur in eine Richtung fahren will, erhalten das "one way" Flag in den Routeparam. Das funktioniert einwandfrei. Wege die ich unbedingt vermeiden will werden als "toll" gekennzeichnet. "Vermeide Mautstrassen" funktioniert dann hervorragend.


    Die Vermeidungseinstellungen sind Bestandteil der GPS-Routingsoftware und solange der Typ 0x0a in den img ist, wird sich das gegebenenfals auf diesen auswirken. Die Aussage nach Hörensagen in dem verlinkten Beitrag, das dies in cgpsmapper nicht implementiert ist, macht da keinen Sinn für mich.



    Du hast dich ja in der Zwischenzeit ein bisschen intensiver mit den OSM Karten und dem Routing auseinander gesetzt, wie ich an den übrigen Beiträgen hier im Forum sehe. Funktioniert das "Vermeide unbefestigte Wege" denn da besser?


    Soweit ich das im Moment beurteilen kann, funktioniert dies weder besser noch schlechter. Wie ich ja schon oben anmerkte, ist dies im wesentlichen eher eine Sache der Routingsoftware im GPS/MS.


    Gruss Gert

  • Hallo papaluna,


    deine Anmerkung


    Zitat

    Die Aussage nach Hörensagen in dem verlinkten Beitrag, das dies in cgpsmapper nicht implementiert ist, macht da keinen Sinn für mich.


    hat mich mal veranlasst im Yahoo Forum nachzufragen. Der dort angemerkte Stan, von dem die Aussage sein soll, ist ja schließlich nicht irgendwer sondern der Entwickler von cgpsmapper.


    Und im Nu gab's auf die Anfrage eine rege Diskussion (es reicht wenn Du den oben angegebenen Link anklickst, dann siehst Du die gesamte Diskussion). Scheinbar arbeitet Stan daran.


    Grüße


    weoli

  • Hi Weoli,
    war mir schon klar wer wohl mit Stan gemeint war.
    Ich bin bisher immer davon ausgegangen, das der Ausschluss von unpaved im Prinzip funktioniert, da ich das ja in Verbindung mit Original-Garmin-Karten so gesehen habe. Das die Ergebnisse dann in meinen Karten nicht so eindeutig waren, habe ich dann eher auf "Mängel" an meinen Karten zurückgeführt.
    Aber interessant zu hören das sich auch noch andere damit beschäftigen. Auf die Variante des Auschlusses via toll bin ich ja auch recht schnell gekommen.


    Gruss Papaluna

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen, bitten wir Euch, über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben!
    Alternativ sehr gerne auch per Paypal spenden.
    Vielen, vielen Dank ...
  • Papaluna,


    neue Version cGPSMapper 098


    ver98
    New: Avoid unpaved roads implemented
    New: Avoid ferry implemented
    New: Changed routing maximum resolution from 5.4 m to 2.3 m

    Fix: Fix distance calculation
    New: Sample installation script prepared (to be used with Inno Setup) - to install map on PC - to be used by MapSource
    Sample in gdansk_routing\CustomSetup
    Fix: Catch the problem when RoadID is higher than maximum accepted by cGPSmapper - 0xFFFFF ( 1048575 )
    Fix: Index creation - corrections


    New: Maproute:
    New way to define turn restrictions in the input data (format to be explained in the manual)


    Da hat sich ja einiges an den Routingfunktionen getan. Habe leider zur Zeit keine Zeit es auszuprobieren.


    Grüße


    weoli

  • Hallo,


    ich versuchte Overlaykarten selbst zu erstellen, die nur POIs enthält.
    Aber leider funktioniert dies bei mir nicht. Ich sehe keine POIs oder/und MS zeugt einen Fehler.


    Welche Software verwendet ihr?
    Wie geht ihr vor (Kurzanleitung)?


    Für Hilfe und Tipps wäre ich dankbar.
    Habe hier im Forum noch nichts gefunden.


    Gruß Tom

    ---------------------------------------------
    Zumo 660 FW 4.80, GTM-12, mit aktueller NT, OSM-Karten, Mapsource V6.16.3, Scala-Bluetooth-Headset

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen, bitten wir Euch, über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben!
    Alternativ sehr gerne auch per Paypal spenden.
    Vielen, vielen Dank ...
  • Hallo Bergdohle,


    vielen Dank für die schnelle Info.
    Habe auch gleich das Tool getestet, aber schon treten die ersten Fehler auf.


    Error E032: Layer 0 of the map cannot be empty


    Sorry.


    Meine Vermutung: GPX-Datei muss aus tracks oder waypoints bestehen und keine POIs !?
    Richtig?



    Habe die POIs in Waypoints gewandelt und schon ist der Fehler weg. Jetzt muss ich nur noch auch die Icons ändern.

    ---------------------------------------------
    Zumo 660 FW 4.80, GTM-12, mit aktueller NT, OSM-Karten, Mapsource V6.16.3, Scala-Bluetooth-Headset

  • Hallo,


    Ich bin selbst gerade am erstellen einer Auto Routing Fähigen Ovlerlay Karte für Garmin.


    So da es nur eine Wanderkarte ist, ist der Parameter Typ ja immer gleich deshalb wollte ich fragen welches Programm rendert die Map (ohne Wasserzeichen) in eine Routing Fähige Garmin IMG????


    für die Parameter benutze ich GPSMapEdit und Hexeditor



    Gruß
    Ferdinand

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen, bitten wir Euch, über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben!
    Alternativ sehr gerne auch per Paypal spenden.
    Vielen, vielen Dank ...