Adressen finden in OSM mit Garmin

Mit BaseCamp 3.2 (OS X, Windows) wurde das interne Routing geändert.
D.h. das Autorouting (genauer die access-Flags) funktionieren nicht mehr.
Ich erwarte diesen Effekt zukünftig auch im GPSr.
Frage: Wurde ggf. eine neue Firmware ins eTrex eingespielt oder handelt es sich beim Gerät um die neue eTrex-Serie?

Klaus

Das Gerät wurde im Mai oder so mal gegen ein neues getauscht, weil sich die Gummi-Ummantelung ablöste. Aktuelle Firmware ist 3.30. Es ist das Etrex Vista HCx.

Ich vermute jedoch, dass dieses Verhalten mit meiner neu generierten Karte, bzw. der Railrun-Karte erst entsteht. Sonst wäre es mir wohl schon früher aufgefallen.

Frage: Wie erstellst du dann die gmapsupp.img?

Wenn ich deine Befehlskette verwende und zum Erstellen der gmapsupp.img die Option --gmapsupp mit einfüge, erhalte ich eine gmasupp.img, aber wenn ich sie auf die SD-Karte kopiere, dann fehlt mir die Adresssuche. Mit deiner Karte habe ich eine Adresssuche …

Hier fehlt mir die Erklärung.

Danke,

Thomas.

Eine GPSr-Karte mit Adresssuche kann nicht direkt vom mgkmap-Compiler erzeugt werden.
Hierzu sind die gewünschten Kacheln via BaseCamp / MapSource ans GPSr zu übertragen.

Klaus

Ok, danke, habe ich mir schon gedacht, denn das war die einzige Erklärung.

Die hier zum Download angebotene Karte ist dann quasi die komplett via MapSource ans Gerät übertragene Karte, die dann hier als gmapsupp.img.zip bereitgestellt wird!?

Thomas.

Ja, deswegen danke ich auch jeden Morgen Richtung Vatikan, Mekka, etc dafür, dass wir jemanden haben, der das macht.

Da schließe ich mich dann mal an und sage auch

DANKE!!!

Thomas.

Hallo Martin,

habe Deine Karte vom 25.9. auf mein nüvi 1390tpro geladen. Die Adresssuche funzt gut mit Ausnahme der Hausnummern. Aber wie wir alle wissen kann es noch nicht funktionieren weil viele
Hausnummern noch gar nicht getaggt sind.

Routing klappt ohne Probleme und die Karte sieht ganz gut aus.

Gruß Wolfgang

Der Hauptgrund ist, dass das Garmin .img Format in Bezug auf Hausnummern noch nicht
decodiert wurde.
Chris

Ich habe jetzt die aktuelle Karte von Ralf Kleineisel auf Routing überprüft. Hier funktioniert es noch (Beispiel Hamburg). Daher kann ich die Firmware meines eTrex wohl ausschließen. Ralf Kleineisel nutzte für seine Karte mkgmap-r2009 (http://www.kleineisel.de/blogs/index.php/osmmap/2011/08/14/august-2011).

Wäre es möglich, dass es beim Zusammenführen der Locator-Branches mit der Hauptlinie von mkgmap zu Einbußen beim Routing gekommen ist? An wen müsste man diese Frage stellen?

Was für ein Gerät hast Du genutzt? Welche Einstellungen? Klappt Fahrrad-Routing auch über mehr als 30 km?

Hallo Martin,

ich habe mir das mal in josm angesehen. Die Engelbertus Strasse hatte den ungewöhliche Tag=is_in =Wipperführt. Dieser Tag ist umstritten.

Ich habe ihn (tag) gelöscht. Mal sehen was beim nächsten Render passiert.

Gruss Wolfgang

Hallo Wolfgang

Falls deine Schreibweise so in der Datenbank war (statt Wipperfürth), dann sollte das die Ursache sein.
Allerdings finde ich es übertrieben gleich den is_in Tagg zu löschen. Der ist alt eingeführt und sollte auch passend ausgewertet werden.

Wie auch immer, es ist auf jeden Fall ein Test, ob das is_in Tagg an einer Straße die Ursache sein kann.

Was das umstritten angeht, so gibt es halt Leute, die meinen, dass es gut wäre, alte Sachen gleich über Board zu kippen, nur weil es eine andere (ggfs. indirekte) Art gibt, den gleichen Sachverhalt herauszufinden.
Nach meiner Meinung schadet ein wenig Redundanz in einem Projekt wie OSM mit seinen vielen Möglichkeiten von kaputten/unvollständigen Daten überhaupt nicht.

Edbert (EvanE)

Aber mit der aktuellen Index Karte funktioniert doch die Engelbertusstraße in Wipperfürth.

Warum also ändern?

Gruß Jürgen

Nüvi 1390Tpro mit SD-Karte. Fahrrad-Routing bis 15km getestet. Ich teste weiter.

Gruß Wolfgang

Danke für den Hinweis. ich hab es in die Anleitung übernommen.

Seit kurzem gibt es jetzt auch Hamburg-Nord etc. als boudary, deswegen klappt es mit meinem Stylefile nicht mehr.
2 Möglichkeiten:

  1. Ein admin-level=6 um Hamburg legen

  2. man riskiert Dörfer/kleine Gemeinden zu verlieren und setzt die Priorität im Style nach oben (aktuell 8>6>7>9>10>4; dann 8>6>7>4>9>10)

Ich denke wir werden noch mehr Probleme bekommen, wenn man nicht eindeutig regelt, wie man die admin-levels verteilt. In vielen Ländern Europas werden nur wenige Admin-Level eindeutig verwenden (z.B. 4 für Region, 6 Stadt, 8 Village).

@wind: Mit Auto-Routing hab ich keine Probleme. Die gleiche Strecke mit dem Fahrrad funktioniert nicht. Welches Style verwendest du? Ich hab meins fürs Auto versucht zu optimieren… Vielleicht kommt daher das Problem?! Deswegen könntest du probieren das Default-Style erst einmal zu testen. Oder zu checkst dir eine alte Mkgmap-Version aus und schaust, ab wo das Problem auftaucht.

Hamburg sollte m.E. als “Ganzes” durchsucht werden können.

Fragen:

  • Welche Auswirkung hätte die Einführung eines “admin-level=6” um Hamburg?
  • Und wie ist das für Berlin geregelt?

Klaus

MIt der letzten Version habe ich das Problem, dass ich von Regensburg nach Hamburg auf eine abenteuerliche Strecke komme und der Router ab Nürnberg einfach nicht Richtung Norden weiterroutet. Es geht rüber bis ins Rheintal und dann schräg hoch nach Hamburg. Völlig daneben und auch unabhängig von den Routingoptionen, die die Strecke betreffen (schnellste oder kürzeste).

Möglich, dass es auch an den OSM-Daten liegt, das hatte ich vor einem Jahr auch von Regensburg nach Reutlingen, da ging es es auch nur über Frankfurt …

Thomas.

Routingfehler

ich benutze die Karte von railrun vom 31.8. mit einem Nüvi 255t und wurde heute über diese Straße gerouted http://www.openstreetmap.org/browse/way/55526861
Dort steht motor_vehicle = private an der Straße und die Tore waren geschlossen.

Das Routing hat tatsächlich mit den Style-Files zu tun. Bislang hatte ich im Wesentlichen die Stylefiles von railrun verwendet, mit minimalen Änderungen an den Points und Polygon-Dateien, hauptsächlich um die Namen von POIs zu verändern.

Jetzt habe ich mal testweise einfach die lines-Datei durch die default\lines der mkgmap-r2049 ersetzt und oben noch den Adress-Block aus der railrun-lines eingefügt. Die ersten vier Routingversuche (für Fahrrad, kürzere Strecke, bessere Route) damit waren tadellos.

Die ersten Test-Adressen waren darüber hinaus auch über die Adress-Suche zu finden. Allerdings hatte ich Schwierigkeiten, die Schleswig-Holstein-Strasse in Hamburg suchen zu lassen. Hamburg ist in dieser Version zweigeteilt (es gibt nicht mehr die Stadt Hamburg, sondern nur Hamburg-Nord und Hamburg-Mitte). In beiden war besagte Straße nicht drin. Auch nicht in Norderstedt.

@railrun: Leider überblicke ich noch nicht, welche von Deinen Stylefile-Änderungen für die Adress-Suche notwendig sind und welche das Routing beeinflussen. Ich hoffe, einen Kompromiss zu finden, bei dem beides gut geht. Über jede Hilfe bin ich dankbar.