Autofahren mit Glopus

... habe ich bisher nicht für sonderlich sinnvoll gehalten, solange man die routingfähige Navigon Strassenkarte hat. Die topografischen Karten taugen recht wenig im Strassenverkehr.

Aber jetzt bin ich doch mal längere Strecken mit Glopus gefahren. Und zwar mit der Generalkarte
http://forum.pocketnavigation.de/tid1063665-sid.htm
D.h. 1:20000 genaue Generalkarte + Strassenkarte mit den Hauptstrassen und Fernstrassenkarte.

Ich muss sagen, das macht schon sehr viel Spass. Auf die Idee bin ich während einer Stauumfahrung gekommen, wo der Navigator sowieso keine vernünftige Route gefunden hätte. Die Generalkarte mit all ihren Kuhdörfern war in dieser Situation sehr hilfreich. Aber auch sonst auf der Autobahn war es schön, immer zu sehen wo man sich gerade befindet.

Ein Punkt allerdings, in dem Glopus verbessert werden könnte: die GPS-Position wandert auf der Karte bis zum Rand und dann scrollt die Karte weiter. Allerdings hat man so die meiste Zeit keinen Überblick auf die Karte in Fahrtrichtung. Kann man das nicht einstellen, so daß die Karte schneller vorangeschoben wird? Z.b. jede halbe Minute einmal mittenzentrieren? Oder gar in Bewegungsrichtung mehr Kartenfläche anzeigen als "hintenherum".

Bei den Extras kannst du abhängig von der Stromversorgung "immer zentriert" einstellen. Das sollte dein Problem lösen.

Silver, du überschätzt den Programmieraufwand für Tools. So ein GMF-Programm ist in ca. 1 Stunde geschrieben, die kleinen Scripts in wenigen Minuten. I.d.R. geht das schneller, als solche Aufgaben manuell zu lösen. Da bleibt genug Zeit für's Geniessen. Mangels Regenschutz bleibt Glopus auf dem Rad aber ein reiner Schönwetter-Begleiter. Im Auto ist nun eine neue Erfahrung. Da hatte ich bisher mangels Kartenmaterial nur den Navigon Navigator benutzt.

Meistens kenne ich aber den Weg und brauche gar keinen Navi. Falls ich doch mal mit Navi fahre spare ich mir meist den ganzen Verkabelungsaufwand und leg das Teil einfach aufs Amaturenbrett. Also Akkubetrieb. Auf dem Rad ist sowieso Akku angesagt. Daher muss die Kartenverschiebefunktion schon energiesparend implementiert sein.

Die "zentrieren"-Funktion muss ich mal testen. Allerdings ist ein permanentes Zentrieren auch wieder schlecht für die Akkulaufzeit. Es wäre gut, wenn einfach nur der Randabstand für's Weiterschieben größer ist, bzw. konfiguriert werden könnte. Oder eine Zentrieren-Funktion, die nicht bei jedem Cursorupdate geht, sondern jedes x-mal oder 2/minute. Optimal wäre sicher eine gewisse Voraussicht, dass in Fahrtrichtung mehr Karte zu sehen ist als hintenherum. Ich denke das könnte mit relativ wenig Aufwand realisiert werden.

Drehen in Fahrtrichtung bzw. 3D ist keine Option bei der Generalkarte, weil dann u.U. auch die Karten-Beschriftung auf dem Kopf steht.

Hmm, eine ältere gmf-merge Version hatte mal den Bug, dass die Überlappungszone doppelt drin war, was vom Verhalten her dem einfachen gmf-add entspricht. Das ist aber in der aktuellen Version korrigiert.

Aktuelles Verhalten: aus der 2. GMF-Karte werden nur die Kacheln zur Gesamtkarte aufgenommen, deren 4. Kachelecken + Kachelzentrum alle bereits von Kacheln der 1. GMF-Karte abgedeckt werden. Also die Reihenfolge spielt eine Rolle und bevorzugt Kacheln der 1. Karte.

Sind die Teilgebiete als Kachelmatrix jeweils zusammenhängend sollte das allgemeingültig funktionieren. Jeden einzelnen Pixel zu überprüfen wäre zu aufwendig. Eigentlich sollten dann keine Bereiche ohne Karte auftreten. Bei mir im Test jedenfalls nicht. Kannst du dein Problem anhand eines kleinen Ausschnittes reproduzieren und mir die Kacheln schicken? Mit gmf-select kannst du den Problembreich isolieren.

Bei allen Prozeduren bitte beachten, dass die 4 Kalibrierpunkte etwa auf den Ecken liegen. Die werden automatisch genau auf die Ecken gesetzt. Das geht aber nicht bei den etwas merkwürdig platzierten Punkten der GMM-Kartenteilung, wo z.b. 3 Punkte auf einer Linie liegen können, wie hier im Bild zu sehen.

Mein geotiffsplit-Script setzt nach Kartenteilung die Kalibrierpunkte dagegen genau auf die 4 Ecken (bei geotransform-Kalibrierung, nicht GCP).

Puh, da hast du ja ein ganz schönes Patchwork zusammengestellt. Da kann ich mir vorstellen, dass es dann in den Lücken Probleme geben kann. Ich kann halt nicht jeden Pixel einzeln überprüfen. Die 4 Eckpunkte und Mittenpunkt sind einfach aus den Kalibrierdaten zu ermitteln. Wenn man die ganze Fläche betrachtet, müsste man jeden Pixel einzeln transformieren. So viel Aufwand habe ich dann doch nicht getrieben.

Man sollte also anmerken, dass die 2 zu vereinigenden Karten jeweils aus zusammenhängenden Flächen bestehen müssen und keinen Spalt enthalten dürfen. Mein Algorithmus ist nur für diesen Fall ausgedacht. Hat jemand eine Idee zur Verbesserung des Algorithmus?

Meine Anwendung von gmf-merge war, dass ich bei einer Fehlermeldung im GMM nicht nochmal alles neu machen musste, sondern die zusammenhängenden Teilflächen vereinigen konnte. Das klappte einwandfrei. Vielleicht kannst du die Teilstücke auch so organisieren. Per gmf-selection können sie zerstückelt werden (gmf2index Ansicht -> Markierung der Trennlinien in Google -> kml2ovl), gmf-add fügt alle zusammen, ohne Verlust von Kacheln.

Wenn dein altes Material so ein Patchwork ist, mach doch mit GMM die Karte einfach neu und erspar dir das Puzzle-Spiel.

NH-Toptrans? Benutzt du das noch? Bei mir hat alles mit GMM funktioniert, Top50-Karte und Top25-Karte. Für Top25 hab ich noch dieses Tool gebastelt, weil die Koordinaten nicht ins Clipboard kopiert werden konnten.

Top50 lief komplett durch, Top25 mit 2 Unterbrechungen (Kachelzeit mit 2 Sek. etwas flott gewählt). Nach einer Unterbrechung habe ich in Google mit Hilfe der gmf2index und ovl2kml Anzeigefunktion das Restgebiet nochmal neu eingestellt, ging mit dem Tool ganz flott. Die Überlappung der 3 Teilkarten konnte mit gmf-merge gut reduziert werden, ohne Lücken wie bei dir. Es kommt aber auf die Reihenfolge an. Die Kartengebiete sollten so erweitert werden, dass kein Spalt entsteht, der kleiner als eine Kachel breit ist.

p.s. hat sonst keiner Erfahrungen mit Glopus im Auto?
Mich hat es etwas mehr abgelenkt als Navigon, weil die Generalkarte viel schöner ist.

Ich fahre ständig mit Glopus - ich muss ja testen. Im Gegensatz zum Wandern fahre ich aber auch bei Glopus fast immer mit genordeter und gekippter Karte, weil man da besser vorausschauen kann. Beim Wandern ist man nicht so schnell und es kommt viel häufiger zu Richtungswechseln und da brauche ich eine genordete Karte.

Ich hab's auch lieber genordet. Aber wenn gekippt, dann nur in Fahrtrichtung. Ansonsten bringt es nicht so viel zur Übersicht. Das geht gut bei Topo-Karten. Die Generalkarte sollte man aber lieber nicht auf den Kopf stellen.

Ideal für die Generalkarte wäre wohl, wenn mehrere aufeinanderfolgende Geschwindigkeitsvektoren etwa in die gleiche Richtung zeigen, in dieser Richtung etwa 2/3 Karte zu sehen und hintenrum etwa 1/3 Karte. Sozusagen Geschwindigkeits-/Richtungsabhängige Kartenzentrierung. Die Mittelung mehrerer Vektoren würde bedeuten, dass nicht gleich jede Kurve, aber eine nachhaltige Kursänderung die Ansicht korrigiert. Für's Fahrrad fände ich so etwas auch gut. Tendenziell sehe ich immer zu wenig Karte nach "vorn".

Bei der letzten Fahrt hab ich nochmal etwas mit Glopus gespielt. Also, die zentriert&gedreht-Ansicht hatte sogar schon die ca. 2/3 vorn 1/3 hinten - Aufteilung der Kartenansicht. Es wäre ideal, wenn man auch in der genordeten Ansicht so viel Karte in Fahrtrichtung bekommen könnte.

Also ich halte davon leider gar nichts. Ich finde es sogar sehr verwirrend, wenn die aktuelle Position nicht mehr an einer bestimmten Stelle, sondern irgendwo auf dem Bildschirm ist.

Aber genau das ist doch deine Default-Einstellung von Glopus. Die Position wandert auf dem Schirm und die Karte "zieht nach".

Von der Performance her ist das Ok, weil ein permanentes Zentrieren wohl den Akku etwas schneller leersaugen würde. Nur ist eben im Default mehr von der bereits gefahrenen Strecke zu sehen als der Teil nach vorn. Wäre gut, wenn man das umkehren könnte. Die Richtungsbestimmung gibt's ja schon in der gedrehten Ansicht.