Ich habe gestern Abend mal etwas mit der POI Funktion in BRouter gespielt.
Darf ich fragen, wie Du diese für die Wahoos aufbereiten willst/einbetten willst?
klar
Echte POIs kennen ja nur die neueren vollroutingfähigen Wahoos, beim Ur-Elemnt und Bolt 1 gibt's diese m.W. nicht. Bei den neueren Wahoos kann man POIs mit Boardmitteln anlegen oder per Zugriff von Außen direkt in die Geräte-Datenbank schreiben:
Ja, die Methode im Video ist mir bekannt. Allerdings will ich die bikerouter.de POI-Funktion ja einfach als Quelle für
Custom Cues nutzen, primär für die
Langstrecke, z.B. um an eine
strategisch günstige Wasserquelle o.Ä. erinnert zu werden deren Position ich beim Planen der Route als POI auf der richtigen Höhe der Strecke hinterlege.
Native POIs haben auf den routingfähigen Wahoos afaik nur den Vorteil, dass Du sie halt schnell als Navigations-Ziel auswählen kannst, und sie tauchen soweit ich weiß als Herz auf der Karte auf. Einen Hinweis, dass Du gleich beim POI vorbeirollst, wirst Du damit vermutlich nicht bekommen.
Das GPX Export-File, das BRouter auswirft enthält neben den Routenanweisungen die selbst erstellten POIs. Diese sind aber lose mit der eigentlichen Route verknüpft, also nur die GPS-Koordinaten und der Hinweistext:
<wpt lat="50.13515184016774" lon="8.529363393066719"><name>Break</name></wpt>
<wpt lat="50.13592169205342" lon="8.521594467997216"><name>PoiExt</name></wpt>
Ich stelle es mir schwierig vor, diese POIs an meinen alten Bolt1 so zu übergeben, dass er damit etwas anfangen kann. Die Routenanweisungen in der GPX-Datei werden ja sequentiell abgearbeitet, nicht anhand der GPS-Koordinaten, sondern anhand der Reihenfolge der Wegpunkte. Ich sehe keine Möglichkeit, die nicht verknüpften POIs (Koordinaten) richtig in diese Liste einzubetten.
Näherungsweise kann man mit etwas Mathematik versuchen die POIs anhand ihrer Koordinaten in die Liste einzufügen, je nach Komplexität der Route kann das aber sehr schwierig bis unmöglich werden.
Soweit richtig, mit dem sequentiellen Abarbeiten. Da ich für meine Langstrecken aber in der Regel einen nicht all zu komplexen Routenverlauf habe, ist das ganze durchaus praktikabel umsetzbar.
Ich glaube, wenn man die POI Funktion richtig nutzen will, dann muss man mindestens auf den Roam V1 updaten.
Für meinen persönlichen Usecase: nee, dafür ist kein Roam V1 nötig.
Aber ich wollte trotzdem mal schauen wies sich auf dem V1 verhält mit meinem aktuellen Ansatz.. Ergebnis: Funktioniert dort genauso. Der Roam v1 kann wie Du sagst zwar aus einer bikerouter.de gpx selbstständig die Turn-by-Turn Abbiegehinweise generieren, das scheint der einzige Unterschied zwischen dem Ur-Elemnt und dem Roam v1 zu sein. Aber da mein Ur-Elemnt das nicht kann, brauche und vermisse ich das Feature aktuell auch nicht und kann weiterhin auf meinen .tcx Workflow bauen und mir die Abbiegehinweise als Custom Cues "zweckentfremden".
Würde mich interessieren, wie Du das beim Ur-Elemnt machen willst. Rein interessemäßig, ich selbst nutze einen
Garmin Edge, meinen alten Bolt nutzt primär meine Frau, aber ich bin auch so ein kleines Spielkind, was der Hauptgrund ist, dass ich an diesem doch sehr speziellen
Wahoo Bolt1 <-> BRouter Projekt etwas experimentiert habe. Mich würde jetzt interessieren, ob ich vor lauter Bäumen den Wald nicht mehr sehe oder irgendeinem Denkfehler unterliege
Das Ganze ist aktuell ein Python-Script was alle .gpx Files im selben Ordner einliest, ein paar Dinge damit anstellt und dann jeweils eine gleichbenannte .tcx Datei rausschreibt. (ChatGPT ist hier wieder eine riesen Hilfe für sowas, weil ich keine tägliche Programmierpraxis habe und Sachen wie korrekte Syntax usw. bei mir seit dem Studium ganzschön eingerostet sind.)
Du hast die Limitationen schon richtig aufgeführt:
Die Cue-Liste wird linear abgearbeitet.
Ich schaue also alle Waypoints die nach meiner naming convention benannt sind ("
poi_typ_hier steht hinweistext") durch und suche den jeweils nächsten trkpt auf der Strecke. Mich interessiert ja nicht genau wo der POI liegt, ich will einfach an der richtigen Stelle der Route per Abbiegehinweis an den POI erinnert werden - ein Custom Cue halt.
Der POI bekommt also den nächstliegenden Punkt auf der Strecke als Position zugewiesen. Beim Erstellen der POIs muss man also den POI nicht genau auf die Strecke setzen sondern einfach auf die ungefähre Höhe auf der man erinnert werden will. Der Ur-Elemnt scheint dann gute 200m vor Erreichen des POIs den benutzerdefinierten Hinweis mit passendem Symbol anzuzeigen und zählt links die verbleibende Distanz in Metern zum POI herunter:
Für die Typ-Deklaration hab ich eine eigene Lookup-Table erstellt so dass ich den typ in der POI benennung etwas einfacher halten kann und die genaue Schreibweise gemäß der unterstützten Symboltypen mit .tcx Files vom Script dann vorgenommen wird:
Die mit .tcx verfügbaren Symbole, oder zumindest die, die ich identifizieren konnte, hatte ich ja schon weiter oben gepostet:
Was die Reihenfolge angeht: Den <trkpt> Elementen hab ich beim Einlesen der .gpx ein zusätzliches Attribut "id" verpasst so dass ich alle Trackpoints in diesem Attribut durchnummerieren kann. Anhand der zugehörigen IDs die ich auch auf die CoursePoints gebe kann ich die POIs dann hinterher sauber sortieren, so dass man beim Erstellen der POIs auf bikerouter.de nicht mehr auf die Reihenfolge achten muss.
Das Ganze sieht für
diesen Beispieltrack mit ein paar printouts in die Konsole aktuell dann so aus:
Das Ganze ist noch mit recht heißer Nadel gestrickt, also Spezialfälle wie überlappende Routensegmente (die bei mir auf Langstrecke eigtl. eh nicht vorkommen) fange ich jetzt nicht extra ab, aber es scheint soweit gut zu funktionieren. Muss halt noch etwas draußen getestet werden. Wie man das Ganze mobil nutzen kann hab ich mir auch noch nicht angeschaut, also momentan ist das halt nur was für die Planung am Rechner bei mir. Hatte mal ein paar Versuche mit Pythonista auf dem iPhone gestartet, aber hatte da noch keinen Erfolg damit eine .gpx so ins Filesystem zu bringen dass ich in Pythonista da rankomme... Und ein Android Smartphone besitze ich auch nicht.
Falls Interesse besteht kann ich das Script wenn sich das Ganze im Einsatz bewährt mal auf Github hochladen.
duck) Tipp für Kartenfans / Fans von Lidar-Daten bzw. Leute die sich gerne das Terrain visuell genauer anschauen (Vegetation und Gebäude werden aus den Daten herausgerechnet) - basemap.de ist ein schönes Angebot von Bund- und Ländern das u.A. einen Schummerungslayer mit ordentlicher Auflösung bundesweit zur Verfügung stellt. Da jedes Bundesland sehr unterschiedliche Handhabe praktiziert in den Daten oder Mapviewern die sie frei herausgeben ist das eine recht schöne Gesamtlösung, auch wenn die Auflösung nicht komplett an manche bundesland-eigenen Angebote heranreicht.
) wenn man sich schön im Terrain ansehen kann wie die geplante Route den Flusstälern folgt 