DE:All in one Garmin Map

Hallo,

Ich habe folgende Problem mit der "DE:All in one Garmin Map" auf einem Garmin GPS MAP 60 CSx:

Verwendet man eine Garmin Karte z.b. City Navigator, so wird beim raus zoomen aus der Karte die Darstellung auf das Wichtigeste reduziert: Große Straßen und name der Städte sind sehr gut zu erkennen. So sollte das sein.

Die DE:All_in_one_Garmin_Map enthält meine Meinung nach einfach zu viele Details beim rauszoomen.
Es entsteht ein undurchschaubarer Strassenwirrwar.
Name der Stadt oder des Stadtteils ist nicht zu erkennen.

Zudem verdecken die Symbole z.b. für Pöller, Ampeln, Kreisverkehre den Straßenverlauf.
Besser wäre es diese Symbole nur bei höchster Zommstufe einzublenden.
Z.b. gibt es bei mir ein Straße mit zig Kleipen, aber vor lauter Symbolen mit Bierkrügen und gekreizten Gabel und Löffel.

Ich habe das hier mal versucht zu veranschaulichen: http://wiki.openstreetmap.org/wiki/User … Garmin_Map

Gruss
Lixus

Schon mal probiert die Detail niedriger zu stellen?

Eigentlich wäre es super klasse wenn sich einer mal der Sache antun würde und eine Garmin-Karte extra fürs Auto-Navigieren machen würde.
Also praktisch ein Ebenbild zur CityNaviator.

Gruß

Ja, der hat jeder wohl seine eigenen Vorstellungen wie die Karte aussehen möge.

Vorteil bei OSM ist aber, dass man seine eigene Karte kreiieren kann.

Ich selber nutze auch eine modifizierte (vereinfachte) Version der A1O.

Zb. interessieren mich Stromlinien und Grenzen überhaupt nicht.
Auch Stopschilder, Sackgassenschilder habe ich rausgeschmissen. 😉

Chris

Ja ich weiß...

Mir fehtl aber gerade wenig die Zeit und Motiovation mit OSM Composer ne eigene Karte zu kreireen ;-)

Aber ich finde es immer seeeeeeeeeeehr gut wenn Leute ihr Map veröffentliche und diese auch immer wieder updaten.

Gruß

Nach wie vor begeisterter Mapper und Anwender der Karten auf meinem GPS. Ich habe die Möglichkeit bei meinem Colorado 300 mehrere Karten mit unterschiedlichem Dateinamen auf das Speichermodul zu kopieren (ab 3.0). Das funktioniert sehr gut mit allen möglichen Karten, nur nicht, wenn ich versuche die All_In One Garmin Deutschland mit der All_in One Garmin Europa zu kombiniern. Kann es sein, dass die beiden Karten die gleiche FID verwenden? Ich finde die beiden Karten sehr gut und würde sie gerne gleichzeitig benutzen (wohne an der Grenze zu Frankreich).
Liebe Grüße Klaus

Hallo,
es könnte auch daran liegen, dass sie im Gerät den gleichen Namen tragen. Das ist bei meinen Karten, die aus dem Composer kommen leider so. Wenn ich diese über MapSource ans Gerät sende und einen Namen vergebe, erkennt mein Oregon auch mehrere.

Hallo aighes

könntest Du Bitte auch Deine Composer-Einstellungen auf der WIKI Seite veröffentlichen. Oder gibts da Konfigurationsfiles?
Das wäre super.

MfG
Achim

Also, das veröffentlichen der Einstellungen wäre kein Problem. Ich hab allerdings keine Ahnung, welche Dateien du alle benötigst.

Ich lad dir heute abend mal alle *.tbl-Files und meinen Icon-Ordner hoch und verlinke es auf der wiki-Seite.

Hallo aighes

vielen Dank fürs "Hochladen". Ich werde das mal mit eigenen Karten versuchen.

Herzlichen Dank
Achim

Ps: Eine Frage an den OSMComposer Entwickler (Nop?) wäre, wie man bewährte Konfigurationen austauschen kann?

Wo wird der "Clear.bat" file configuriert? (Final Batch File?)

Nachdem ich zuerst Computerteddy-Maps benutzt habe bin ich auf die Suche gegangen nach Karten, die für mein Garmin abgestimmt sind.
So hab ich mir die Europa-Karte auf die Karte geladen. Im eTrex Legend HCx kein Problem, ist das Nüvi205 etwas überfordert mit dem Bildaufbau. Scheinbar sind es die Höhenlinien. Könnten aber auch andere Details sein.

Im Auto auf dem Nüvi bräuchte ich sowas jetzt nicht unbedingt. Kann ich Höhenlinien aus dem Paket ausblenden? Das Typfile hierfür kann ich nicht identifizieren, wahrscheinlich steckt diese Info in der Basiskarte.

Betrifft das eTrex
Bei Computerteddy's Maps habe ich für jeden Strommast ein "Sonstige", für jeden Poller eine "Säule" in den geographischen Punkten.
Mit der All-In-One-Map gibt es diese nicht, aber nun häufen sich die "Zebrastreifen".
Kann man das ändern?

godofglow wrote:

Aber ich finde es immer seeeeeeeeeeehr gut wenn Leute ihr Map veröffentliche und diese auch immer wieder updaten.

Dies habe ich mal als Aufforderung aufgefasst und meine Deutschland-Map upgedated.
Zu laden über meine Wiki-Seite.

Features:

• See-Polygone
  
• Vereinfachte All-In-One Darstellung
  
• Keine Höhenlinien, Stromleitungen, Grenzen, Zebrastreifen, Stopschilder
  
• Rennradrouting: Option Mautstrassen-vermeiden am Garmin aktivieren, dann werden Tracks
  

ab grade2, sowie surface unpaved/sand etc. vermieden.

• Ersetzung impliziter maxspeeds (zB DE:urban durch 50)
  

Grüße
Chris

Hallo Chris, wie kommt man denn zu den See-Polygonen?
Das fehlt meinen Karten noch. Könntest du kurz erklären, was man machen muss?

aighes wrote:

Hallo Chris, wie kommt man denn zu den See-Polygonen?

Siehe http://forum.openstreetmap.org/viewtopic.php?id=4664

Chris

Hallo,

ich habe die DE_AllInOne Karte vom 20091016 im Einsatz und habe mit der Anzeige vom maxspeed noch Probleme.
In Wohngebieten wird der maxspeed sauber in dem Führungstext angezeigt, bei Bundesstrassen und Autobahnen leider nicht. Kann das bitte wieder eingeschaltet werden. Mein 60 CSx kann leider nicht
die kleinen Geschwindigkeitsschilder anzeigen, somit ist der maxspeed während der Fahrt nicht zu überprüfen.

Danke und Gruß
Kai

Ich hätte da mal eine allgemeine Frage zur Karte.:

Die Wiki-Seite der Karte (http://wiki.openstreetmap.org/wiki/DE:A … Garmin_Map) enthält die schöne Sektion "Featurewünsche". Werden diese Wünsche überhaupt noch berücksichtigt oder hat das Ganze nur mehr eine Alibi-Funktion?

chriss66, bei mir funktioniert der download von megaupload nicht, könntest du deine styles und dein mkgmap command line aufruf posten ?

lixus wrote:

chriss66, bei mir funktioniert der download von megaupload nicht, könntest du deine styles und dein mkgmap command line aufruf posten ?

Hi, das macht ja nicht viel Sinn da dann die Meerespolygone nicht drin wären.
Hab es gerade mit Firefox3.5.3 getestet, kein Problem mit dem Download.
Erst den Sicherheitscode eingeben, ca 1 Minute warten, dann auf Standardownload klicken. Eventuell
hast Du Javascript deaktiviert.
Chris

Ich verwende diese Karte im Oregon 300 und kann damit auch erfolgreich navigieren.
Im Setup kann ich auch auswählen, ob ich für Auto, Fußgänger oder Radfahrer routen möchte.

Öffentliche Verkehrsmittel werden mir beim Routing aber nicht angeboten.
Liegt das daran, dass die Karte keine Infos über Öffentliche enthält?
Prinzipiell sollte der Garmin Oregon doch auch dafür geeignet sein.

Walter

Die All_in_one Karte ist aus meiner Sicht derzeit die beste OSM-Karte für Garmin überhaupt, trotzdem scheint dieser Thread hier nicht gerade viel besucht zu sein.
Wird die Karte aktuell auch noch wo anders diskutiert?

Ich habe bei den POIs auf meinem Oregon 300 (Sprache: englisch / SW-Version 3.20 / GPS-SW-Ver 3.70) einige Unklarheiten entdeckt.

Museum/Historical (unter Attractions) scheint mir eine recht unübersichtliche Mischung aus Museen und sämtlichen Denkmälern, Monumenten, ... zu sein.
Auch Rest Area und Tourist Info (unter Auto Services) wäre besser in getrennten Kategorien, aber vermutlich ist das ja eine Einschränkung von Garmin und nicht vom Mapping.

Warum scheinen bei Garmin manche Kategorien dagegen wieder doppelt auf?
z.B.
Amusement/Theme Park ist nicht nur unter Attraction, nicht auch unter Recreation zu finden.
Dagegen sollte Park/Garden und Arena/Track nur unter Recreation und nicht auch unter Attraction eingeordnet werden.
Vermutlich genauso eine Vorgabe der Garmin-Firmware.

Die OSM-spezifischen POIs unter Attraction sind bei mir teilweise unter falschem Namen (Mosque, Church, Temple, Synagogue) statt [Schloss, Ruine, Denkmal, Monument].
Liegt das daran, dass ich die Standard Sprachdatei für Englisch ausgewählt habe?

Unter Community | City Hall sind zusätzlich zu town_hall auch alle public_building zugeordnet, das macht die Suche nach einem Gemeindeamt recht mühsam,
noch dazu, wo public_building ja eine eigene Kategorie hat (Government Office).

Einige für Camper interessante POIs gehen mir derzeit bei der Karte noch ab:
Geldwechselstube (amenity=bureau_de_change) ev. zu Bank/ATM
Toiletten (amenity=toilets); Duschen (amenity=shower); Trinkwasser (amenity=drinking_water)
ev. gemeinsam mit Dumpingstation für Fäkalien (amenity=recycling / excrement=yes) als neue Kategorie

Falls ich hier sinnvolle Änderungsvorschläge für die Karte habe, möchte ich diese im Wiki eintragen. Vorher aber bitte ich noch um Rückmeldung, was davon der Karte zuzuordnen ist.
Ich bin auch auf der Suche nach einer Übersetzungstabelle OSM-Tag <=> Garmin POI-Kategorie. Gibt es für die AllInOne so eine Mapping-Liste?

Grüße
Walter

Auch von mir zunächst mal ein großes Lob für die All-in-one Karte, damit kann man sich wirklich hervorragend orientieren, vor allem natürlich beim Mappen!

Ein paar kleinere Verbesserungsvorschläge hätte ich allerdings noch (zur Info, ich habe ein eTrex Vista HCx):

• Für KfZ-Werkstätten fehlt noch ein Symbol. EDIT: Korrektur, das Symbol ist vorhanden und wird auch angezeigt, allerdings nicht bei "meiner" Werkstatt...
• Ich finde Parkplätze etwas unpraktisch einsortiert in der Kategorie Auto Services. Neulich hatte ich eine Werkstatt im näheren Umkreis gesucht und keine einzige angezeigt bekommen, weil die Liste voll mit (überwiegend kleinen) Parkplätzen war...

Gibt es eigentlich eine Liste aller benutzen Symbole?

Moin!
Was ist eigentlich der Unterschied zwischen der EU und der DE Karte?
Ich denke aufgrund der Dateigröße müssen auf der DE-Karte im Verhältnis mehr Daten vorhanden sein. Die EU ist ja schließlich mehr als 3x DE oder? 😉

Hallo MHohmann,

bei mir ist Autoservice noch weiter unterteilt in Autovermietung, Autoreparatur, Händler/Autoteile, Parkmöglichkeit, Rastplatz/Besucherinfo, Autowaschanlage.

Hallo Spüli,

kann es sein, dass Deutschland wesentlich genauer erfasst ist als der Rest der EU.
Nicht umsonst sind die Deutschen ja auch als besonders gründlich bekannt.

Grüße aus Wien
Walter

Hallo Spüli,
wie Walter schon sagt, Deutschland bietet die meisten Informationen. Schau einfach mal unter http://download.geofabrik.de/osm/europe . Da bekommst du einen ungefähren Einblick, wie die Daten so verteilt sind.

Hey.

Schöne Karte.

Wie ist das jetzt eigentlich mit der Adresssuche.
Wenn ich es im Mobile XT auf Adresssuche gehe, kommt leider immer noch die Bundesstaat-Abfrage wo man nicht drüber kommt.
Wenn ich nur nach einer Stadt suche kann ich leider keine Straße eingeben.

Steh ich auf dem Schlauch oder ist es halt einfach noch nicht möglich?

Danke

Gruß

Walter Schlögl wrote:

Die All_in_one Karte ist aus meiner Sicht derzeit die beste OSM-Karte für Garmin überhaupt, trotzdem scheint dieser Thread hier nicht gerade viel besucht zu sein.
Wird die Karte aktuell auch noch wo anders diskutiert?

Da das Forum aus dem Wiki heraus nicht verlinkt ist, wird sicherlich noch ein Teil der Diskussionen auf der entsprechenden Seite im Wiki stattfinden - oder die User sind so zufrieden dass sie keine weiteren Anmerkungen haben 😉

Hallo Gemeinde,

ich denke mal, dass hier auch Fragen über EU:AllInOne gestattet sind?

Bei der Layerauswahl in meinem HCx 3.10/2.90 sind scheinbar die an/aus Funktionen vertauscht - wenn ich wähle 'alles an' habe ich nur noch die Grundkarte, bei 'alles aus' ist alles an.

Nachdem ich eine zeitlang die Höhenlinien gesucht hatte, nachdem ich diese angeschaltet hatte, habe ich es mit ausschalten versucht und - oh Wunder - da waren sie wieder.

Unterliege ich hier einem Denkfehler?

... wundert sich

Andreas

Walter Schlögl wrote:

bei mir ist Autoservice noch weiter unterteilt in Autovermietung, Autoreparatur, Händler/Autoteile, Parkmöglichkeit, Rastplatz/Besucherinfo, Autowaschanlage.

Danke für die Info, das wusste ich noch nicht - jetzt weiß ich auch, dass man im Menü "Autoservice" einfach noch mal auf Menü drücken kann und dann diese Unterteilung bekommt 🙂 Das macht die Sache schon deutlich übersichtlicher. Damit hat sich auch mein Einwand erledigt, die Parkplätze sind ja völlig richtig einsortiert. 🙂

Bei mir werden mit der Karte von gestern 20091028 viele Symbole (auf dem Garmin Display in der MAP-Darstellung) doppelt dargestellt.
Unter den blauen Telefon-Symbolen (mit Rechteck) liegt noch ein schwarzes Telefon-Symbol (ohne Rechteck).
Über vielen Symbolen (z.B. Ampel, Barriere, ...) liegt ein Symbol mit roter Raute.

Die alte Karte habe ich einfach durch die neue überschrieben.
Muss ich zusätzlich noch irgendwo alte Symbole aus einer POI Datenbank löschen?

Weiters ist mir aufgefallen, dass auf meinem Oregon keine Hausnummern angezeigt werden (erst beim Anklicken).
Stattdessen sehe ich lauter blaue Symbole, und das sogar bis 200m Auflösung, was die Darstellung in dieser Stufe etwas unübersichtlich macht.
Eine Anzeige nur bis 80m wäre vermutlich übersichtlicher.
Gibt es eine Möglichkeit, direkt die Nummer anzeigen zu lassen?

(Oregon 300 / SW-Version 3.20 / GPS-SW-Ver 3.70)

Walter

Hallo zusammen.

Mal ne Frage.

Nach Angaben sollte die Karte doch auch schon Adresssuchfähug sein?

Aber leider komt bei mir beim Garmin Mobile XT immer noch die erste Abfrage nach einem Bundesland wo man dann nicht weiterkommt...

habt ihr ne IDee?

Danke

Gruß

Hallo godofglow,

schau mal auf http://wiki.openstreetmap.org/wiki/DE:A … _Map#Karte ganz unten, da ist ein Workaround beschrieben.

"Bis es soweit ist, daß die Adress-Suche auch in dieser Karte funktioniert, habe ich folgende Zwischenlösung gefunden:
Ich kopiere parallel die City Navigator Karte auf die SD-Karte und schalte sie im Menü jedoch aus. ...."

Walter

Genau so mache ich es auch. Aber irgendwie muss ja dann die Infos der City Karte sich doch extraieren lassen...^^

Dank der neuen gesponsorten Server von Strato, kann die All-in-One-Map jetzt täglich frisch berechnet werden.

...kann man jetzt auf der Wiki-Seite lesen; nur welchen Sinn macht dies, wenn die Qualität auf der Strecke bleibt?
Die Liste der "Featurewünsche" wird immer länger, wäre es da nicht eventuell sinnvoll das Eine oder Andere mal umzusetzen; seit Wochen und Monaten scheint sich da nichts mehr zu tun.

Ich habe mir hier einmal die Mühe gemacht und ein paar fehlende und fehlerhafte Features der Karte aufgelistet, soweit mir aufgefallen ("vielleicht hilft's?!").

Fehlende Features:

Flächen:

Baugebiet (landuse=construction)
Gewerbegebiet (landuse=commercial)
Heide (natural=heath)
Küstenlinie (natural=coastline)
Mülldeponie (landuse=dump)
Öffentlicher Bereich (leisure=common)
Speicherbecken (landuse=reservoir)
Sperrgebiet (military=danger_area)
Spielfeld (leisure=pitch)
Sportstadion (leisure=stadium)
Sportzentrum (leisure=sports_centre)
Steinbruch (landuse=quarry)
Strand (natural=beach)

Symbole:

Bahnhof (railway=station)
Funkturm (man_made=communications_tower)
Kindergarten (amenity=kindergarten)
Kirche (amenity=place_of_worship)
Öffentliches Gebäude (amenity=public_building)
Schwimmen (sport=swimming)
Spielplatz (leisure=playground)
Trafostation (power=sub_station)
Umspannwerk (power=station)

Fehlerhafte Darstellung:

-In Ermangelung von Symbolen erscheint das Symbol für Supermarkt ebenso bei:
Tauchausrüstung (shop=diving)
Schmiede (shop=smithy)
Schneider (shop=tailoring)

-gleiches Symbol für Gaststätte und Imbiss

-Symbol "Tor" wird zugleich für die Schranke verwandt

-Symbole für unterschiedliche Sportarten sind zwar in der TYP-Datei enthalten, werden jedoch nicht dargestellt.

Fehlerhafte bzw. überflüssige Bezeichnungen in der TYP-Datei:

-Nachbarschaftsladen ("Was ist das, sollte dies nicht besser Tante-Emma-Laden oder einfach Laden heißen ?")
-Nationalpark ("Gibt es soetwas in Deutschland eigentlich?")
-Das Wort "Shopping" wird fälschlich ins Deutsche mit "Gewerbe" übersetzt.
-Der Tag "Farm" sollte an Stelle von "Acker" besser mit "Landwirtschaft" übersetzt werden da dieser auch für Obstanbaugebiete u.ä. verwendet wird.

Über diese Mängel hinaus besteht ein gravierendes Layer-Problem. Hier das Beispiel eines Krankenhausgeländes mit Waldbestand.

All-In-One Karte (MapSource)

Mapnik

Osmarender

bezüglich Adresssuche:

Also seit der letzen Version von openmtbmap ist es bei ihr voll integriert und funktioniert super!!!
schauts euch mal an:
openmtbmap.org

Da gibt ein extra-Installer für die mdx-Dateien und fertig.

Gruß

Hallo r-michael,

hast du auch das Verhalten, dass viele Symbole durch eine rote Raute überdeckt werden (siehe mein Posting #29)
und dass Hausnummern nicht direkt im Plan angezeigt werden.

Ich bin gerade dabei, eine Liste zu erstellen, welche Symbole es am Plan gibt und welche POIs bei der Suche angeboten werden.
Das ist noch nicht so ganz konsistent, allerdings kommen auch viele OSM-Tags laufend dazu.
Übrigens, Nationalpark kann ja wohl kaum als überflüssig bezeichnet werden, oder?

Walter

Hallo Walter,
dein Problem mit den Symbolen könnte eventuell die gleiche Ursachen haben wie mir gestern geschehen.
Ich hatte auch gestern die alten Kartendaten von vor 2 Wochen mit den neuen überschrieben und bekam daraufhin in MapSource ein "wildes Durcheinander".
Die Ursache war, dass die Bezeichnungen der TDB-Datei und der Overview-Map inzwischen geändert wurden und so ein Registrierungsproblem bestand. So musste ich nun die Karte neu registrieren und die zwei alten Dateien löschen.

Übrigens, Nationalpark kann ja wohl kaum als überflüssig bezeichnet werden, oder?

Gibt es denn in Deutschland überhaupt welche? Ich kenne soetwas eigentlich nur z.B. in den USA.

r-michael wrote:

Gibt es denn in Deutschland überhaupt welche?

14 Stück:

http://de.wikipedia.org/wiki/Liste_der_Nationalparks

chris

Hallo r-michael,

ich lade die gmapsupp Datei direkt ins Gerät, dort habe ich dann das Problem mit den doppelten Symbolen.
Hast du auch eine Möglichkeit gefunden, wie ich im Gerät selbst die doppelten Symbole wieder entfernen kann?

Walter

Walter Schlögl wrote:

Hallo r-michael,

ich lade die gmapsupp Datei direkt ins Gerät, dort habe ich dann das Problem mit den doppelten Symbolen.
Hast du auch eine Möglichkeit gefunden, wie ich im Gerät selbst die doppelten Symbole wieder entfernen kann?

Walter

Da muß ich leider passen Walter, denn ich besitze kein Navi.
Ich arbeite hier nur mit MapSource am PC.

Besten Dank auch an Chris für die Info über die Nationalparks.
Da habe ich doch wieder etwas dazugelernt!

Erstmal ein dickes Lob für die Bereitstellung der Karte! Inzwischen frage ich mich, warum ich nicht schon viel früher dazu umgestiegen bin...
Mir hat zwar die Aktualisierung jeweils vor und nach dem Wochenende gereicht, aber ich denke, mit der täglichen Aktualisierung läuft inzwischen alles vollautomatisch ab, so dass wieder Zeit ist, zusätzliche Features zu implementieren 😉.

Mein Wunsch ist, auch railway=preserved angezeigt zu bekommen. So eine Museumsbahn gibt es bei uns, komplett mit Bahnübergängen an der Bundesstraße und gelegentlichem Dampflokverkehr. Die AiO zeigt das bisher leider nicht an, eine Darstellung genauso wie "reguläre" Bahnstrecken wäre ok.
http://www.openstreetmap.org/?lat=54.64 … rs=B000FTF

womisa wrote:

Wo wird der "Clear.bat" file configuriert? (Final Batch File?)

Sorry, die Frage hab ich bisher leider überlesen.
Die Clear.bat hab ich mir selber geschrieben, um am Ende der Bearbeitung die temporären Dateien (außer Kontur-Files) zu löschen. Der Grund ist der, dass ich beim Erstellen einer neuen Karte mir vorher einen aktuellen Planetfile runterlade. Somit muss jedesmal alles neu geschnitten und bearbeitet werden. Da kann ich mir die Aufbewahrung der temporären auch sparen.

Falls es jemanden interessiert, ich habe mein Problem mit den überlagerten Symbolen lösen können.

Ich benenne die gmapsupp auf der Speicherkarte für gewöhnlich um, und habe auf diese Art mehrere Karten vorrätig.
Eine davon setze ich dann auf aktiv. Das funktioniert sehr gut, solange es nur um die Anzeige der Karte geht.

Leider kommen sich aber unterschiedliche TYP-Files in den Karten (auch in den deaktivierten) in die Quere.
Ich habe daher alle Karten bis auf eine verschoben, einen Werksreset durchgeführt, und nun funktioniert alles wieder normal.

Ich habe auch festgestellt, dass die POIs von deaktivierten Karten ebenfalls geladen werden.
Auch dafür ist es also besser, immer nur eine gmapsupp auf der Speicherkarte zu haben,
da sich bei überlappenden Karten (z.B. EU + D) die POIs sonst mischen und dann doppelt vorkommen.

Walter

Hallo Christoph,

könntest Du auch das "Vorprodukt", die gesplitteten, aber noch nicht mit mkgmap bearbeiteten Daten online stellen?

An dieser Stelle ein herzliches Dankeschön für diese detailreiche Karte und die regelmäßigen Updates!

Vielen Dank
Lothar

redbaron999 wrote:

Bei der Layerauswahl in meinem HCx 3.10/2.90 sind scheinbar die an/aus Funktionen vertauscht - wenn ich wähle 'alles an' habe ich nur noch die Grundkarte, bei 'alles aus' ist alles an.

Unterliege ich hier einem Denkfehler?

Du oder Garmin! ;-)

Die Anzeige im Kartenmenü ist nicht der aktuelle Status sondern der Befehl den Du beim Auswählen gibst.
Steht also im Kartenmenü z.B OSM an so ist die Karte inaktiv und die Auswahl dieses Punktes führt zum Einschalten. Ist sie dann an bietet das Menü den Befehl "OSM aus" an.
Ziemlicher Programmiererkram, der normale User denkt da normalerweise genau andersrum.

Bei der WAAS/EGNOS Funktion hieß das auch mal so, mittlerweile haben sie das in "aktiviert" und "deaktiviert" geändert.
Da war es so richtig verwirrend.

Moin!
Seit wann sind die OSM-Bugs eigentlich als Layer dabei?
Schiebe mir eigentlich immer nur die Karte vom PC auf SD in den eTrex. Jetzt sehe ich, das in meiner Gegend einige störende Bugs eingezeichnet sind.
Gehe ich recht in der Annahme, das ich die nur über MapSource weg bekomme?

Die müsstest du eigentlich auch direkt im eTrex abschalten können. Dafür gehst du ins Menü Einstellungen / Karte. Dort müsste die All in ine Map angezeigt werden. Dann drückst du noch einmal auf die Menütaste - dann erscheint noch eine Liste, in der die einzelnen Layer der Karte aufgelistet sind. Dort kannst du die OSB und FIXME Layer abschalten.

Eine andere Möglichkeit wäre natürlich, einfach mal dort hinzugehen und die Bugs zu beheben 😉

Danke!
Mit der verdrehten Logik (an ist off) klappt das.

Habe leider jemanden in der Gegend, der hier penetrant Bugs über Offmaps in die Karte bringt. Aber ich arbeite daran.

Nichmal ich wegen der Adresssuche...

Gibt s jetzt schon die Funktion hier wie Beispielsweise bei openmtbmap.org?

Wenn es felix von openmtbmap.org mit mkgmap hinkriegt sollte es doch hier auch kein Problem sein?
Oder täuscht mich das?

Danke

Gruß

Also ich habe es definitiv schon 2 Mal versucht (und auch geschafft) zu einer Straße zu routen. Nur ist die Eingabe auf meinem eTrex recht bescheiden. Mit den Joystick ist man da eher am Ziel wenn man sich etwas auskennt. Am Einfachsten geht es natürlich über gesetzte Zielpunkte.
Habe jetzt am WE etliche Hausnummern in OSM geloggt, werde also in den nächsten Tagen mal einen Versuch mit direkten Hausnummern machen. Aber funktionieren sollte es eigentlich.

Ich schließe mich einigen Vorrednern an: die wohl beste Downladkarte.

Kommen kyrillische, griechische etc. Namen eigentlich richtig an? Da mein GPSmap 60CSx diese ohne firmware update nicht darstellen kann, kann ich das derzeit nicht selbst überprüfen.

Es wäre hilfreich, wenn living_street als solches zu erkennen wäre. Es ist ja schon erklärt, daß es nicht genügend routbare Typen gibt, aber wenn anstatt oder zusätzlich zur Höchstgeschwindigkeit z.B. living_ angezeigt wird, würde das helfen.

Im Wiki gibt es jetzt eine sehr übersichtliche Tabelle mit allen Objekten aus dem Style (vielen Dank an Christoph).
http://wiki.openstreetmap.org/wiki/DE:A … rmin_Types

Ich habe eine Spalte erstellt, wie die POI-Kategorien im Oregon gemappt sind.
Dabei ist mir aufgefallen, dass noch einige wenige Kategorien fehlen, das möchte ich hier mal zusammenfassen.
Bei einigen bin ich mir relativ sicher, wie sie optimal gemappt werden könnten, bei anderen wieder nicht. Bitte daher auch um entsprechende Gegenvorschläge.

2b 04: tourism=resort (kommt zwar in OSM selten vor, ist aber bei Urlaubsort bestens aufgehoben)
2c 09: amenity=concert_hall (stimmt zwar nicht 100% mit Auditorium überein, einen besseren OSM-Tag konnte ich aber nicht finden)
2c 0a: shop=winery (Ein Weingut hat meist auch gleich einen Weinverkauf dabei, passt also bestens)
2c 0c: leisure=hot_spring (konnte ich in OSM nicht finden, gibt es etwas anderes stattdessen?)
2c 0d bis 2c 10: Diese 4 Typen sind wohl absichtlich "abweichend" gemappt, damit nach Schloss, Ruine oder Denkmal gesucht werden kann.

2d 04: amenity=casino oder leisure=casino oder tourism=casino (ist wohl leider nicht ganz eindeutig)
2d 0b: Für einen Sportflugplatz habe ich nichts passendes gefunden.
2e 02: bakers passt nicht mit Lebensmittel zusammen - keine Ahnung, ob das von Christoph Absicht war.
2e 10: Gerade der Supermarkt als häufigstes Tag ist nicht mehr in der POI-Liste und kann daher auch nicht gezielt gesucht werden.
Ich würde daher eher supermarket und bakers tauschen, dann kann aber nach Bäcker nicht mehr gesucht werden.
2e 03: shop=general (passt aus meiner Sicht hier zu Gemischtwaren bestens dazu)
2e 06: Was ist eigentlich der Unterschied zwischen Gemischtwaren und Bedarfsartikel und gibt es ein passendes OSM-Tag dafür?
2e 0a: Auch für Einzelhandel (Retail) habe ich in OSM nichts passendes gefunden, was haben die Garmin-Karten hier eigentlich gemappt.
2e 1a: Würde sich Kiosk als Convenience anbieten? Falls ja, sollte es besser auf 2e 06.

2f 04: aeroway=aerodrome (Der Flughafen passt hier am besten)
2f 07: shop=car_parts (Garmin hat Autohändler und Autoteile zusammengegeben, obwohl es nicht ganz das gleiche ist)
2f 0a: Ich habe keinen Auto-Schrotthändler in OSM gefunden, passen würde er hier her.
2f 0c: Für Rastplätze habe ich nichts passendes gefunden. Am besten würde noch picnic_site passen, dann kann danach wenigstens gesucht werden.
2f 0d: Auch für Automobile Club gibt es im OSM nichts eigenes, car_repair ist eigentlich nicht ganz passend.
2f 16: Truck Stop ist scheinbar auch noch nicht gebräuchlich.

30 00: Dieser Sub-Type wird in der POI-Liste nicht angezeigt. Es ist aber auch kaum notwendig, nach einem Public_Building zu suchen.
30 05 und 30 07: Für Gemeindezentrum und Regierungsstelle habe ich keine entsprechenden OSM-Tags gefunden.
30 06: barrier=border_control (kommt in OSM zwar selten vor, passt aber trotzdem)
4a 00: picnic_site siehe auch Punkt 2f 0c
59 00: aeroway=aerodrome ist wohl gebräuchlicher als airport (siehe auch 2f 04)

Folgende Tags würden sich aus meiner Sicht anbieten, noch gemappt zu werden:
2a 0b: cuisine=fish zu See-Food (auch wenn es nicht 100%ig passt)
2a 14: cuisine=traditional zu regional (passt hier am besten)
2f 06: amenity=bureau_de_change (Geldwechselstube zu Bank und ATM)
4e 01: amenity=shower oder amenity=toilets & shower=yes (Dusche)

Weiters habe ich noch einige Einträge in der POI-Liste gefunden,
die bei fehlendem Namen keinen Default-Namen entsprechend der Type zugeordnet haben,
und in MapSource dann nur anhand des Symbols teilweise zugeordnet werden können.
Tankstellen, Toiletten, Parks, ATM, place_of_worship, tourism=information, leisure=pitch, sports_centre

Woran liegt es eigentlich, dass viele gemappte Punkte in der POI Liste des Garmin ab einer bestimmten Sub-Type nicht angezeigt werden?
(Beispiel: 0x2a >12 / 0x2c >10 / 0x2d >0b / 0x2e >0b / 0x2f >17 / 0x30 >08)
Es scheint sich dabei wohl um eine Einschränkung in der Firmware zu handeln.

Viele Grüße
Walter

Danke für die Ergänzungstips. Werde das mal schnellstmöglich einbauen.
Sven hatte ja die Idee, die Stylefiles ins SVN zu knallen und halbautomatisch zu aktualisieren. Ich weiß nicht, ob das wirklich gut geht, aber dann könnte immerhin jeder direkt mitarbeiten.
Wär schon gar nicht so schlecht.

Zu den POI-Listen muss ich sagen, dass die Einträge im FIND-Menü scheinbar hard festgelegt sind. Wenn eben irgendwas auf einem speziellen Typ liegt, dann wird es als solches gefunden im Menü.
Ich wüsste gerne, wie man das verändern kann. Ich hab auch keine Ahnung, wie man die Kategorisierung benamsen kann. Wenn da ständig sonstiges steht ist das ja auch nicht hilfreich. Ich hatte gehofft der zieht die Info aus dem Typfile, aber scheinbar nicht.

Die Sache mit den Symbolen, die keinen Default namen haben, wenn sie in OSM nicht benannt sind, ist einfach die, dass ich nicht für alles einen Eintrag im Typfile gemacht habe. Ich wollte eben manchmal die Standardsymbole so lassen, weil die mir ganz sinnvoll erschienen. Leider kann ich dann den Default namen nicht setzen. Wobei - vielleicht klappts ja auch, wenn ich einfach kein Symbol im Typfile einstelle, aber den Default namen setze. Mal testen...

Danke im Übrigen für die vielen Verbesserungsvorschläge und kritischen Diskussionen. Obwohl das hier gerade mein erster Post im OSM-Forum überhaupt ist, habe ich das Topic hier natürlich schon ein Weilchen gelesen - spätestens seit es im Wiki verlinkt wurde. Einiges hab ich schon eingebaut, anderes fehlt leider noch.

BTW: Funktionieren die Openstreetbugs jetzt europaweit zufriedenstellend? Habs noch nicht so detailliert getestet.

Grüße
Christoph

Spüli wrote:

Danke!
Mit der verdrehten Logik (an ist off) klappt das.

Du musst das so sehen:
wenn da steht "AN Streetbugs" dann schaltest du das mit dem Joystick AN wenn du ihn drückst.
wenn da steht "OFF Streetbugs" dann schaltest du mit dem Joystick auf OFF

Es steht da also im Prinzip nur da was du mit Knopfdruck auswählst.

So hab ich das zumindest verstanden.

Gruß, Rudi

master wrote:

BTW: Funktionieren die Openstreetbugs jetzt europaweit zufriedenstellend? Habs noch nicht so detailliert getestet

Habe die Karte vom Freitag Nachmittag fürs Wochenende gezogen und festgestellt, dass in Hamburg alles zupflastert war mit erledigten OSBs ;-)
Vielleicht hast du das ja inzwischen korrigiert - konnte noch nicht in eine aktuellere Karte reinschauen.

Zartbitter wrote:

master wrote:

BTW: Funktionieren die Openstreetbugs jetzt europaweit zufriedenstellend? Habs noch nicht so detailliert getestet

Habe die Karte vom Freitag Nachmittag fürs Wochenende gezogen und festgestellt, dass in Hamburg alles zupflastert war mit erledigten OSBs ;-)
Vielleicht hast du das ja inzwischen korrigiert - konnte noch nicht in eine aktuellere Karte reinschauen.

Ähm jo, hab in meinem Eifer 0 und 1 verwechselt und eine Version mit verkehrten Bugs produziert. Hab den Fehler aber gleich korrigiert und ab Samstag müssten korrekte Karten da sein.

Hallo!

Ist das gmapsupp.img vom 16. und 17.11.2009 defekt? Vom gpsmap 60cx wird keine Karte erkannt.

Ich habe schon öfter mit dem gmapsupp.img der All in one Map gearbeitet und hatte bisher nie Probleme. Ich entpacke die Datei und kopiere sie immer mit dem Kartenleser auf die micro-SD-Karte ins Garmin-Verzeichnis. Ein anderes gmapsupp.img (Bayern routable von Lambertus) funktioniert ohne Probleme.

Viele Grüße

Sabine

Hotel und Restaurant in einem:
getagt:
tourism - hotel
amenity - restaurant

wird im auf dem Garmin weder als Hotel noch als Restaurant in den POI geführt. Eigentlich sollte es in beiden drin stehen.
Wird übrigens in T@H als Hotel mit kleinem Messer/Gabel dargestellt.

Hi,

SabineSW wrote:

Ist das gmapsupp.img vom 16. und 17.11.2009 defekt? Vom gpsmap 60cx wird keine Karte erkannt.

ich habe dasselbe Problem. Seit Deinem Beitrag hat es da schon mindestens drei neue Dateien gegeben, das Problem ist also augenscheinlich bekannt.

Weide

PS: Die Fassung von heute 12:13:27 geht bei mir auf eTrex Vista HCx auch noch nicht.

Weide wrote:

Hi,

SabineSW wrote:

Ist das gmapsupp.img vom 16. und 17.11.2009 defekt? Vom gpsmap 60cx wird keine Karte erkannt.

ich habe dasselbe Problem. Seit Deinem Beitrag hat es da schon mindestens drei neue Dateien gegeben, das Problem ist also augenscheinlich bekannt.

Weide

PS: Die Fassung von heute 12:13:27 geht bei mir auf eTrex Vista HCx auch noch nicht.

Auf einen nüvi 265 lassen sich die neuesten gmapsupp.img auch nicht laden.. :-(

look4book wrote:

Weide wrote:

Hi,

SabineSW wrote:

Ist das gmapsupp.img vom 16. und 17.11.2009 defekt? Vom gpsmap 60cx wird keine Karte erkannt.

ich habe dasselbe Problem. Seit Deinem Beitrag hat es da schon mindestens drei neue Dateien gegeben, das Problem ist also augenscheinlich bekannt.

Weide

PS: Die Fassung von heute 12:13:27 geht bei mir auf eTrex Vista HCx auch noch nicht.

Auf einen nüvi 265 lassen sich die neuesten gmapsupp.img auch nicht laden.. :-(

Betrifft das nur Deutschland oder auch Europa?

Ich muss mal sehen, wann ich wieder an richtiges Internet komme, damit ich auch mal wieder ein bisschen testen kann. Ich hasse Probleme, die nur bei größeren Datenmengen auftreten...

Grüße
Christoph

Hi,

master wrote:

Betrifft das nur Deutschland oder auch Europa?

Oops. Hab' grade erst auf den Absender gesehen. Erstmal ein dickes "Danke" für die ganze Arbeit!

Ich hatte noch einen alten Link ("osm.dxp-ev.de", Stand 7 oct) für die Europakarte im Gebrauch und kann zu den neueren Europa-Fassungen nichts sagen.

Die DE "18 Nov 2009 23:38:15 GMT" geholt als
http://www.juergen-frank.de/osm/gmapsup … pp.img.bz2
probier ich gerade aus. Dauert aber noch etwas (langsames DSL und USB-Übertragung ins Garmin)...
... geht nicht. Der Initialisierungsbalken läuft bis 19% und dann wird die Karte ignoriert.

Weide

PS: Die http://dev.openstreetmap.de/aio/germany … pp.img.bz2 von heute 10:54 klappt

Walter Schlögl wrote:

Falls es jemanden interessiert, ich habe mein Problem mit den überlagerten Symbolen lösen können.
(Ich habe) ... mehrere Karten vorrätig. Leider kommen sich aber unterschiedliche TYP-Files in den Karten (auch in den deaktivierten) in die Quere.
Walter

Hallo Walter,

da ich das gleiche Problem mit meinem Nüvi 205 (Software 5.0) habe, sah ich mir gerade die beiden von Garmin installierten Karten an:

* gmapbmap.img (Routingfähige Basiskarte mit DEM-Daten): Enthält keine Type-Files.
* gmapprom.img (NT-Straßenkarte 2009): Enthält ein Type-File, dieses jedoch ausschließlich ''Spezialsymbole in NT-Karten'' also die Firmensymbole von Werbekunden.

Überlagert werden die POIs aus der All-In-One nicht durch die genannten, sondern durch die eingebauten Symbole des Nüvi, die auch für eigene Favoriten zur Verfügung stehen. Da Sie jedoch nicht immer, bzw. verspätet überlagert werden, handelt es sich möglicherweise um einen Firmware-Bug.

Grüße Lothar

Hallo Lothar, es scheint ein Bug zu sein.

Hallo Christoph,

kann es sein, dass bei der Europa Karte der OSB Layer fehlt und dafür der Fixme Layer doppelt vorkommt?
Der OSB Layer war übrigens auf Deutschland begrenzt, Österreich war im Osten (Gegend um Wien) nicht mehr abgedeckt.

Grüße
Walter

Meine Beobachtungen zum Garmin Oregon 300:

Die neu angelegten Kategorien werden nun angezeigt und auch über die POI-Liste gefunden, vielen Dank für die rasche Übernahme.
Ausnahme: Ein Building mit amenity=concert_hall bleibt derzeit unsichtbar, bei anderen amenities wie z.B. hospital funktioniert es hingegen.

landuse=meadow ist farblich zu ähnlich zu natural=wood und ist daher kaum unterscheidbar
Beispiel: http://www.openstreetmap.org/?lat=48.19 … rs=B000FTF

POI Hotel/Motel listet beim Oregon nur Motels (Hotels werden nur unter "Unterkunft/Alle Kategorien" gelistet)
tourism=hostel und caravan_site fehlen sowohl in der Oregon POI-Liste als auch das Symbol im Plan (Symbole in MapSource sind vorhanden)
Da in OSM kaum zwischen camp_site und caravan_site unterschieden wird (nahezu alle Caravan-Plätze werden als camp_site getaggt),
würde ich vorschlagen, diese beiden Kategorien zusammenzulegen (auf 2b 03).
Hotel, Motel und Hostel wird in OSM wesentlich genauer unterschieden, hier zahlt es sich aus, getrennte Kategorien zu verwalten.
Kennt jemand eine Lösung, wie die Kategorien in die entsprechende POI-Liste und als Symbol in den Plan zu bekommen ist?

Einige Symbole wie z.B. Supermarkt, viewpoint, post_box, recycling werden beim Oregon nicht angezeigt.
Aus meiner Sicht sollte der Supermarkt auch gar nicht auf 2e 10 sondern auf 2e 02 (Grocery = Lebensmittel) gemappt werden,
damit wäre das Problem des fehlenden Symbols und der fehlenden Suche in der POI-Liste (zumindest für den Supermarkt) gelöst.

Vorschlag für frei verwendbares Dusch-Symbol (4e 01):
http://www.designofsignage.com/applicat … /bath.html

Vorschlag für ein Wrack-Symbol (historic=wreck): http://wiki.openstreetmap.org/wiki/DE:Map_Features
Vorschlag für ein Taxi-Symbol (amenity=taxi): http://www.netland.at/taxi/taxi-symbol.gif
Vorschlag für ein WLAN-Symbol (amenity=wlan oder internet_access=wlan): http://www.clker.com/clipart-16441.html
Vorschlag für ein Fährterminal (amenity=ferry_terminal): http://www.clker.com/clipart-25178.html
Vorschlag für eine Angelstelle (leisure=fishing): http://www.clker.com/clipart-map-symbol … white.html

Weitere Vorschläge ohne eigenes Symbol:
historic=monastery (ev. gleiches Symbol wie bei Kirchen)

In der Wiki-Tabelle wäre es aus meiner Sicht ausreichend, wenn wir in der Spalte "Icon" einfach nur Ja oder Nein eintragen.
Dann sieht man auf einen Blick, welche Symbole derzeit noch fehlen.

Noch ein Vorschlag für die Wiki Sammlung der Known problems bzw Featurewünsche.
Eine Trennung in Layer (OSM, OSB, SRTM, ..); MAP-Darstellung Polygons, Lines, Points; Routing, usw. würde hier für viel mehr Übersicht sorgen.

Grüße
Walter

Hallo,
ich habe mit der Europakarte (20091123) das Problem, dass der Oregon 400t nicht startet, wenn gleichzeitig die Karte von Computerteddy (elv_typ_gmapsupp.img.gz auf http://wiki.openstreetmap.org/wiki/User:Computerteddy) installiert ist. Einzeln funktionieren beide Karten.

Kann es sein, dass beide Karten identische Karten-Ids verwenden?
Gibt es eigentlich schon eine Liste der verwendeten Ids? Falls nicht, könnte man das ja mal zumindest OSM-weit anfangen.

Gruß
WanMil

Es gibt ID-Listen der kommerziell verkauften Karten. Soweit ich weiß aber noch keinerlei ID-Übersichten oder Absprachen für OSM-Karten.

Hallo Gemeinde,
ich habe festgestellt das in der AIO-Karte keine Friedhöfe dargestellt werden.

Ich habe hier meinen lokalen Friedhof versuchsweise zusätzlich mit AREA=YES versehen, das hat aber nichts gebracht.
Ich verwende die Karte mit einem Garmin eTrex Vista HCx (aktuelle Firmware).

Gruß Holger

DF6DBF wrote:

Ich habe hier meinen lokalen Friedhof versuchsweise zusätzlich mit AREA=YES versehen, das hat aber nichts gebracht.

Das wundert mich nicht.

1. Ist es bei den OSM-Tags ueblich, dass sie kleingeschrieben werden. Es gibt zwar natuerlich keine klare Definition, aber bei der Vielzahl von Renderern und Auswerteprogrammen kann man nicht davon ausgehen, dass alle Programme "YES" und "yes" gleich behandeln.

2. Hat das area Tag an einem Friedhof auch nichst zu suchen. Das Tag ist urspruenglich mal eingefuehrt worden, um Fussgaengerzonen nicht nur als Linien eintragen zu koennen, sondern auch als flaechenfoermige Plaetze. Das dafuer kein ordentliches neues Tag eingefuehrt wurde, sondern dieser area=yes Pfusch, ist sicherlich bedauerlich. Denn als Folge davon fingen die Mapper an, auch andere Strassen als Flaechen ein zu tragen, was beim Routing zu "interessanten" Effekten fuehrte. Und in letzter Zeit sieht man immer haeufiger, dass auch Elemente, die es grundsaetzlich nur als Flaeche gibt, zusaetzlich noch mit area=yes markiert werden. Das ist sicherlich ein schoenes Beispiel dafuer, wie ein kleiner Pfusch mit der Zeit weite Kreise ziehen kann.

Gruss
Torsten

Hallo an Alle,
lese gerade einen Artikel:

(openPR) - Auf das Jahr 2010 können sich Deutschlands Kartennutzer freuen:
Für OpenStreetMap (OSM) wird es zum Jahreswechsel ein komplettes Straßenverzeichnis mit allen verfügbaren Hausnummern geben.

Ist es das woran ich gerne glauben möchte, oder gibt es da einen Haken?
Neuwerk

Ließ mal ganz zuende. OSM+ klingt wie ein ziemlich kostenpflichtiges Angebot, nicht wie eine Datenspende.

Wahrscheinlichg hast Du Recht.
Ich habe dies aus dem folgenden Link zitiert:
http://www.openpr.de/news/378612/OpenSt … is-an.html
Gruß
neuwerk

seit 2 Tagen lädt mein Garmin etrex vista die KArten nicht mehr. Sowohl die Karte vom 17 und vom 18 bricht bei 37 bzw. 45 % beim Einlesen ab, 19. ging wieder, die vom 20 stoppt bei 42%.

Noch jemand?

Gruß,
Ansgar

Ansgars Feststellung kann ich bestätigen

+++ udo

Die Karte vom 18. lädt bei mir auch nicht.

Hmm,
die Datei vom 15.12. war die letzte, die ich gerade sauber herunter laden konnte. Alle neueren Dateien liefen nur bis etwa 50% durch.

beim Runterladen bricht er ab und an ab, nachdem ich aber die gesamte Karte auf meiner Speicherkarte habe, liest mein Gps ide nur bis zur oben erwähnten Prozentzahl...

die karte vom 21.12 bricht b eim Einlesen ins Garmin bei 41% ab.

Ja auf meinem Garmin Vista HCx bricht das Laden auch bei 41% ab.

Ich habe mir gestern vom Mirror die Karte vom 19.12. gezogen. Hat beim zweiten Versuch dann zum Glück funktioniert.

Hi zusammen,

als erstes mal DANKE für die tolle Karte und die viele Mühe, die darin steckt. Es ist wirklich toll, zu sehen, was für eine Energie dahinter steckt :-D Nun zu meiner Frage: ist es möglich, die Rettungspunkte (http://wiki.openstreetmap.org/wiki/Tag: … cess_point) auch zu rendern? Wäre super, wenn man die auch in der AIO-Karte sehen könnte, da sie ja eingetragen sind... Die Wander-/Reitkarte zeigt die Rettungspunkte auch an. Gibt es einen bestimmten Grund, warum die Punkte hier nicht gerendert werden?

Viele Grüße

Die Karte vom 22.12.09 konnte ich problemlos herunterladen, entpacken, auf mein etrex Vista HCx kopieren und dann loslegen. Kein Fehler beim Einschalten, keine Probleme bei kurzen Tests. Die letzte, die ich davor installiert habe, war die vom 12.12.09.

So,
auch hier konnte die heutige Karte einwandfrei geladen werden. Scheint also nur ein temporäres Problem zu sein.

Schön, wenn man die eigenen Eintragungen vom Vortag so schnell auf einer Karte wieder finden kann.

Hi,

Spüli wrote:

So,
... auch hier konnte die heutige Karte einwandfrei geladen werden. ...

Welche Karte war das? DE oder EU?

Und von welchem Datum? Der Zeitstempel der Datei vom 23.12 ist 10:27:15, der Beitrag ist von 10:57 Uhr; aber war die Datei beim Holen schon da oder war es die vom Vortag?

Hintergrund der Frage ist: Gibt es irgendeinen Unterschied zwischen verschiedenen Garmin-Geräten bei diesem Effekt? Es wäre ja schön, wenn wir überflüssigen Traffic vermeiden könnten und der erste Tester hier einfach eine Notiz hinterlassen könnte "Die EU-Karte von ... geht nicht.". Wenn das aber vom Gerätemodell oder gar seiner Version abhängt, dann ist das nicht mehr sehr sinnvoll.

Ich hab es am 24.12 versucht. Die DE mit Dateidatum vom 24. und vom 23. wurden von eTrex Vista HCx nicht akzeptiert. Die vom 22. ging.

Frohe Weihnacht!
Weide

Test war nicht erfolgreich:

Grundlage ist

http://dev.openstreetmap.de/aio/germany/

Die "gmapsupp.img.bz2" vom "24-Dec-2009 07:25" funktioniert nicht auf meinem Garmin-Oregon.

Weide wrote:

Hi,

Spüli wrote:

So,
... auch hier konnte die heutige Karte einwandfrei geladen werden. ...

Welche Karte war das? DE oder EU?

Ich hatte die "latest DE" ausgewählt, und zwar direkt auf dem Server. Wird sich also um die Datei vom 23. gehandelt haben. Die vom 22. lag glaube ich schon im Unterordner.

Weide wrote:

Gibt es irgendeinen Unterschied zwischen verschiedenen Garmin-Geräten bei diesem Effekt?

Keine Ahnung. Ich lade die Karten manuell herunter und packe sie mit WinRar aus. Dabei merke ich dann, wenn die Datei kaputt ist. Eine sauber ausgepackte Datei hat bei mir immer im Gerät funktioniert.
Gruß Ingo

Mein eTrex Vista Hcx bricht bei Deutschland vom 24 und vom 25.12. auch bei ca 41% ab

Hi,

Spüli wrote:

Ich lade die Karten manuell herunter und packe sie mit WinRar aus. Dabei merke ich dann, wenn die Datei kaputt ist. Eine sauber ausgepackte Datei hat bei mir immer im Gerät funktioniert.

Oh. Dann ist es ein ganz anderes Problem. Ich meinte Probleme des Garmin-Geräts, eine sauber ausgepackte Datei zu akzeptieren.

Dann würde es mich doch sehr interessieren, ob Du die Datei vom 22. oder vom 23. hattest, denn letztere wurde von meinem Garmin nicht akzeptiert. Die komprimierte Datei vom 22. hatte 497_944_306 Byte und die vom 23. hatte 497_932_565 Byte.

Weide

Hi,

Cyrond wrote:

Mein eTrex Vista Hcx bricht bei Deutschland vom 24 und vom 25.12. auch bei ca 41% ab

Danke für die Info!

Die Prozentzahlen sind übrigens nach meiner Erfahrung ziemlich willkürlich und sollen nur dem Benutzer zeigen, dass das Gerät nicht hängengeblieben ist. Ob's geklappt hat sieht man nur daran, dass man hinterher eine Karte hat. Ich hatte schon funktionierende Karten, bei denen das Ding nicht mal bis 20% gezählt hat...

Weide

Hmm,
keine Ahnung wie groß die gepackte Datei war. Jetzt sind es jedenfalls 660.226.048 Bytes auf der SD-Karte. Ausgepackt um 10:05, somit also wohl die Datei vom 22.12. die bei mir läuft.

Hi,

Danke!
Das ist die vom 22.; die tut's bei mir auch.

Weide

Hallo,

selbes Problem bei mir:
Die Datei vom 22.12. mit 660.226.048 Byte funktioniert, die drei neueren nicht mehr.
Bei mir auf einem nüvi 650.
Außerdem kann ich zur Zeit nur den Mirror erreichen - http://dev.openstreetmap.de/aio ergibt eine Fehlermeldung.

Gruß: Tycho.

die gmapsupp.img.20091228 läuft auf dem Vista HCx gar nicht. Bricht nach 40% beim einlesen ab. oder wenn das Gerät eingeschaltet ist wird gar nicht geladen.
Braucht man hier ein Zauberwort? oder sind das keine Garmin.img?

Mein Vista HCx bricht bei der Karte vom 29.12.09, 1:00 Uhr bei 42% ab.
Blöd, dass meine alte Karte schon 1 Monat alt ist.

Da ich auf der betreffenden Wikiseite keine Kontaktmöglichkeit gefunden habe, poste ich es mal hier. :-)

Falls Interesse an Notfallrettungspunkten für den (West-)Harz für die "DE:All in one Garmin Map" besteht, die habe ich auf meiner Homepage vorrätig. Einfach mal per PM bei mir melden. ;-)

Gruß
Lars

bei 29.12.09 funzt auf dem Vista Hcx ohne Probleme.

Nachtrag War die Karte Deutschland und heruntergeladen wurde die so gegen 13:00
Aber ob das jetzt was bringt - denn so wie ich das sehe wurde die Map auf dem Server am 29-Dec-2009 um 11:20
geschrieben und wird nicht mehr verändert bis zu dem Tag 30-Dec-2009 ich vermuhte mal es wird auch so gegen 11:20 oder 11:23 sein 😉

Hallo Leute,

danke für die Testberichte. Wäre gut, wenn ihr immer dazusagen würdet, welche Karte ihr genau getestet habt (Europa, Deutschland,...) und wann ihr sie runtergeladen habt.
Nachts um 0:30 Uhr, werden nur die Openstreetbugs erneuert und so Vormittag rum, die Karte mit den Daten der Geofabrik (also Daten vom Vortag).

Ich befinde mich gerade auf dem 26C3 und hab nur ab und zu mal n paar Pausen, in denen ich mir mal nen Laptop von Kumpels leihe, um hier was zu basteln. Könnte sein, dass es was hilft, könnte aber auch abkacken. Die Netzverbindung ist jedenfalls zu lahm, um mir hier ständig Europa zum testen runterzuladen.

Wenn die Karte nicht läd, hab ich ganz stark den Adresslayer im Verdacht. Der machte schon in der Vergangenheit gelegentlich Probleme. Ich habe keine Ahnung warum. Leider kann man auch den Logs nicht ansehen, ob das Ergebnis funktionieren wird oder nicht. Jedenfalls könnte ich den Adresslayer auch temporär mal rausnehmen, damit hoffentlich der Rest wieder geht.

Werd mal sehen, wie das hier so läuft. Auf Anfrage könnte ich auch kleinere Ausschnitte basteln (siehe Datenextrakte der Geofabrik). Hab das mal mit Berlin zum testen gemacht.

Grüße
Christoph

Hallo, ich bin Rolf meines Zeichens Elektronikbastler.

Mehr oder weniger erfolgreich - je nach Projekt.

Ich grüße alle im Forum hier. wünsche auch gleich einen guten Rutsch ins neue Jahr 2010.

Ich habe einen Garmin 510 auf dem Trödel gekauft und Ihn wieder zum rollen.

Ich habe auch eine Karte hier geladen, die wird auch anerkannt. auf der alten Karte ist eine Strasse in der Nähe nicht verzeichnet, auf der geladenen sehr wohl. Die neue Karte wird auch beim Navigieren genutzt.
Aber...

Es ist nicht möglich Stadt und Strasse einzugeben mit dem Menuepunkt Zieleingabe -> Adresse
Da steht In welchem Bundesstaat / welcher Provinz ist die >adresse...
ja und da ist das Problem - Keine Einträge gefunden...

Adressen die mit der alten karte eingegeben waren, werden sehr wohl verwendet, mit der neuen Karten und neuen Strassen die auch berücksichtigt werden. Werden auch mit den richtigen Namen bezeichnet - aber tauchen nicht im Menue Zieleingabe auf das ist bei der neuen Karte leer.

Was tun sprach Zeus...

So, bei mir läuft dier heutige "Deutschland komplett" auf dem Vista HCx!
Wahrscheinlich war die von 01:00 Uhr noch von gestern.

Um den Status der Aktuallisierung sehen zu können am besten den Link nutzen:

http://dev.openstreetmap.de/aio/

Rechts von den Dateien Steht das Datum und die Zeit wann diese Files auf dem Server abgelegt wurden.

Gruß
Sparkman

Habe heute Basecamp aktualisiert und siehe da:

Alle Karten von MS sind jetzt integriert.

Neuwerk

Hallo Christoph,

Danke fürs Reparieren!
Die Version vom 29.12.2009 wird wieder von meinem nüvi 650 angenommen.
Ich verwende immer nur die Deutschlandkarte, wegen der Ladezeiten, daher kann ich über die Europakarten keine Aussagen treffen.
Leider wird meine Abbiegeregelung nicht umgesetzt, aber vielleicht habe ich sie auch falsch gemappt.

Guten Rutsch!
Tycho.

neuwerk wrote:

Habe heute Basecamp aktualisiert und siehe da:

Alle Karten von MS sind jetzt integriert.

Neuwerk

Danke für die Info! Allerdings bringt es IMHO nicht viel: es scheint keine fertige OSM@Garmin Karte zu geben, die ein DEM enthält, so dass ich den 3D view nutzen kann.

Oder doch?

Habe die all-in-one, die Radkarte und eine eigene mit dem OSM composer generierte Karte probiert. Vielleicht gibt es aber doch eine fertige mit DEM???

mtb wrote:

neuwerk wrote:

Habe heute Basecamp aktualisiert und siehe da:

Alle Karten von MS sind jetzt integriert.

Neuwerk

Danke für die Info! Allerdings bringt es IMHO nicht viel: es scheint keine fertige OSM@Garmin Karte zu geben, die ein DEM enthält, so dass ich den 3D view nutzen kann.

Oder doch?

Habe die all-in-one, die Radkarte und eine eigene mit dem OSM composer generierte Karte probiert. Vielleicht gibt es aber doch eine fertige mit DEM???

Hoffentlich gibt's dann auch bald mal die Mac-Version, die Karten ohne DEM unterstützt. Da ist 2.0.1 die aktuellste (vom Juli 2009). Die PC-Version ist die 2.0.9 und seit 2.0.8 sollen auch Karten ohne DEM unterstützt werden.

Hallo Jürgen,

braucht man für den Mac unterschiedliche Karten?
Das ist mir völlig neu. Aber ich erweitere mein OSM-Mac-Seite gerne, wenn ich was übersehen habe: http://wiki.openstreetmap.org/wiki/User:Gmhofmann

gmhofmann wrote:

Hallo Jürgen,

braucht man für den Mac unterschiedliche Karten?
Das ist mir völlig neu. Aber ich erweitere mein OSM-Mac-Seite gerne, wenn ich was übersehen habe: http://wiki.openstreetmap.org/wiki/User:Gmhofmann

Hallo,

man braucht für den Mac keine anderen Karten, habe ich auch nicht geschrieben.
BaseCamp auf dem Mac (2.0.1) unterstützt momentan jedoch nur Karten mit DEM (Digital Elevation Model).
Das PC-Pendant von BaseCamp ist schon bei Version 2.0.9 und unterstützt seit 2.0.8 (laut Garmin Website) auch Karten ohne DEM.
Garmin RoadTrip hat leider einen so geringen Funktionsumfang, dass es kaum ernsthaft nutzbar ist. BaseCamp kann fast genau das, was MapSource auf dem PC konnte, und ein wenig mehr 🙂

Betrifft Product-IDs

Hallo Christoph,

wäre es möglich bei der Erstellung der einzelnen Kartenbestandteile (gbasemap, gaddr, OSB, gfixme, gboundary) Product-IDs zu verwenden, die zum einen möglichst einmalig sind, und zum anderen noch nicht bei den kommerziellen Karten vorkommen?
Momentan ist das Problem, dass Fixme und OSB identische PIDs und Family-IDs haben und fast alle verwendeten PIDs schon mal bei kommerziellen Garmin-Karten vorkommen (siehe: http://www.naviuser.at/forum/showthread.php?t=1203)

Wichtig ist dies insbesondere dann, wenn man die Karten mit anderen zusammen in ein gmapsupp packen will (z.B. mit MapInstall auf dem Mac).
Ich will beispielsweise die Garmin-Aio-EU zusammen mit der CityNavigator NT auf eine Karte packen.

Momentan wird folgendes verwendet:

MapID Family-ID Name
45 4 gbasemap
40 5 gaddr
33 3 Fixme
33 3 OSB
30 6 gboundary

Viele Grüße

Jürgen

Routingprobleme mit Nüvi200 in HH

Seit ein paar Monaten nutzte ich OSM mit der "DE:All in one Garmin Map" auf einem Nüvi 200.
Im Gegenzug mappe ich auch noch fehlende Straßen sofern sich das ergibt.

Die Navigation war mit der Europakarte vom 30.11.2009 fehlerfrei, soweit ich das beurteilen kann.

Mit dem Update auf die Karte vom 13.01.2010 sind mir massive Routingprobleme in Hamburg aufgefallen.
Die liegen vermutlich nicht an der OSM sodern an der generierten Garmin Karte, da das Routing in CloudMade fehlerfrei ist.

Vielleicht könntet ihr mal folgende Route mit eurem Garmin routen lassen und eine eventuelle Geräteabhängigkeit rauszufinden:

GPS Simulation
Koordinateneingabe
N 53°36'
E009°55'
Position setzten

1. Ziel, westlich A7, Routing ok
N 53°33'
E009°53'

2. Zeil, östlich A7, Routenberechnungsfehler!
N 53°33'
E009°56'

Bei der Karte vom 30.11.2009 tritt auch beim 2. Ziel kein Routenberechnungsfehler aus.

Wenn der rote Kasten das darstellt, was in der Europakarte ist:
Meine Wunsch waeren die Kanaren als extrafile.
Wenn ich hier das eu file runtelade, ist das netz doch einige Zeit zu..

tnx aus fuerteventura

guenter

Wenn der rote Kasten das darstellt, was in der Europakarte ist:
Meine Wunsch waeren die Kanaren als extrafile.
Wenn ich hier das eu file runtelade, ist das netz doch einige Zeit zu..

tnx aus fuerteventura

guenter

Largosss wrote:

Falls Interesse an Notfallrettungspunkten für den (West-)Harz für die "DE:All in one Garmin Map" besteht, die habe ich auf meiner Homepage vorrätig. Einfach mal per PM bei mir melden. ;-)

Hallo Largoss,

ich lese das gerade zufällig. Danke, die Positionen der Notfallrettungspunkte im Westharz sind allerdings schon seit längerer Zeit vollständig in OpenStreetMap integriert.

Viele Grüße
Ebbe73

Lückenfüller wrote:

Die Navigation war mit der Europakarte vom 30.11.2009 fehlerfrei, soweit ich das beurteilen kann.
Mit dem Update auf die Karte vom 13.01.2010 sind mir massive Routingprobleme in Hamburg aufgefallen.

Es scheint so, dass neuere AIOs Probleme mit dem Routing haben.

Das Routing auf einem etrex Vista HCx funktioniert bei mir mit neueren Versionen der AIO-Deutschland praktisch überhaupt nicht mehr. Die Berechnung bricht immer nach wenigen Prozent mit einem Routenberech.-Fehler ab.

Die letzte Karte mit bei mir funktionsfähigem Routing stammt vom 2009-12-30.

Die folgenden vier neueren Karten habe ich ausprobiert: 2010-01-19, 2010-01-20, 2010-01-23, 2010-01-27.
Bei allen bricht jede Berechnung mit einem Routenberech.-Fehler ab.

Was kann die Ursache dafür sein?

geopia wrote:

Es scheint so, dass neuere AIOs Probleme mit dem Routing haben.

Das Routing auf einem etrex Vista HCx funktioniert bei mir mit neueren Versionen der AIO-Deutschland praktisch überhaupt nicht mehr. Die Berechnung bricht immer nach wenigen Prozent mit einem Routenberech.-Fehler ab.

Die letzte Karte mit bei mir funktionsfähigem Routing stammt vom 2009-12-30.

Was kann die Ursache dafür sein?

Danke, da bin ich ja nicht allein. Hab vorhin mal diese Karte von Computerteddy ausprobiert:

http://openstreetmap.teddynetz.de/lates … upp.img.gz

Sieht nicht nur besser aus, sondern hat nach ersten Tests auch keine Routingfehler :-)

Ich habe inzwischen eine erste Route mit dem Fahrrad abgefahren. Folgendes ist mir aufgefallen:

- Vor dem Abbiegen zoomt das Garmin Vista immer raus, sodass die Straßen kleiner werden. Das nervt etwas, weil es das Lesen erschwert. Kann man das abstellen?

- Der Kompass scheint recht ungenau zu sein. Auch nach Kalibrierung steht die vor mir liegende Straße manchmal ca. 10 bis 15 Grad schräg gegen das Gerät. Ist sowas normal?

@Lückenfüller: Was meinst Du mit "sieht besser aus"? Ist die Darstellung von Strassen mit dem Kartenmaterial anders?

Hauptmenü --> Einstellungen --> Routing Einstellungen --> Abbiegekommando --> Aus

flux.

Danke, flux! Das wars. Kann man eigentlich die Vergrößerung dieser Abbildungshinweise irgendwo einstellen? An sich fand ich die Sache mit den Pfeilen ziemlich gut.

Was die Missweisung des eingebauten Magnetkompasses angeht: Auf einem Holztisch zeigt er in die gleiche Richtung wie mein mechanischer Kompass. Vielleicht liegt es am Metall des Fahrrades oder ähnlichem.

Die Zoomstufe der Abbiegehinweise scheint irgendwie nicht an bestimmte Regeln gebunden zu sein, zumindest erschließen sich mir keine, egal was ich probiert habe ...

flux.

Marvin33 wrote:

@Lückenfüller: Was meinst Du mit "sieht besser aus"? Ist die Darstellung von Strassen mit dem Kartenmaterial anders?

Ja, die Straßen (besonders Landes- und Kreisstraßen) und die Flächen werden anders dargestellt.

Routingprobleme der AOI im Hamburger Raum in Verbindung mit dem Nüvi 200 sind immer noch vorhanden.

Hat jemand Tipps für mich, wie man eine Karte ohne Routingprobleme selbst bastelt? Welche mkgmap Version taugt was?

mkgmap kannst du in der aktuellsten Version nehmen, ich habe keine Probleme damit.

Anleitungen zum Erstellen einer routingfähigen Karte aus OSM gibt es im Netz zur Genüge und sehr detailliert ... u. a. auf der AIO-Seite von Christoph selber.

flux.

flux wrote:

mkgmap kannst du in der aktuellsten Version nehmen, ich habe keine Probleme damit.

Anleitungen zum Erstellen einer routingfähigen Karte aus OSM gibt es im Netz zur Genüge und sehr detailliert ... u. a. auf der AIO-Seite von Christoph selber.

flux.

Hab es erstmal ohne Typfile getestet. Sieht noch nicht so gut aus und die Umlaute fehlen noch, aber es gibt keine Routingprobleme 🙂

\splitter-r105>java -Xmx1500m -jar splitter.jar ../germany.osm
\mkgmap-r1563>java -Xmx1500m -jar mkgmap.jar --remove-short-arcs --route --gmapsupp ./tiles/*.osm.gz

Hier siehst du, wie Lambertus es macht ... (Antwort #542)

flux.

Könnte sein, dass die Frage hier an der falschen Stelle steht:
Ist die öpnvkarte.de auch als downloadbare Version für den Garmin verfügbar, ggfs. wo?
Danke!
mihof

Meiner Meinung nach ist die AIO derzeit die beste OSM-Karte für die Garmins, vorallem aber auch die aktuellste.

Es sind mir aber ein paar Dinge aufgefallen:

1. Zuvor wurde schon beschrieben, dass Friedhöfe nicht dargestellt werden. Seltsamerweise werden aber einige angezeigt, andere nicht!?

2. In MapSource werden Polylinien 0x17 (Rennbahn) und 0x39 (Straßenbahn) nicht dargestellt, auf dem Gerät schon.
Und es ist egal, wie man das Typ-File ändert, in MS geht es nicht. Bei Typ-Files anderer Karten werden diese Elemente nicht verwendet.

3. Zumindest auf dem Oregon wird das Icon 0x2c 0x19 (Wasserturm) nicht dargestellt, auf MS aber schon.

Habe ich nur das Problem, oder ist das anderswo auch so?

Mike

mike_hd wrote:

1. Zuvor wurde schon beschrieben, dass Friedhöfe nicht dargestellt werden. Seltsamerweise werden aber einige angezeigt, andere nicht!?

2. In MapSource werden Polylinien 0x17 (Rennbahn) und 0x39 (Straßenbahn) nicht dargestellt, auf dem Gerät schon.
Und es ist egal, wie man das Typ-File ändert, in MS geht es nicht. Bei Typ-Files anderer Karten werden diese Elemente nicht verwendet.

zu 1) Werden vielleicht von anderen Flächen zB residential überdeckt ?

zu 2) Das ist richtig, MS kann nicht alle Lines darstellen, die das Gerät anzeigen kann, des weiteren sind nur
bestimmte Linientypen fürs Routing geeignet.

Chris

chris66 wrote:

mike_hd wrote:

1. Zuvor wurde schon beschrieben, dass Friedhöfe nicht dargestellt werden. Seltsamerweise werden aber einige angezeigt, andere nicht!?

2. In MapSource werden Polylinien 0x17 (Rennbahn) und 0x39 (Straßenbahn) nicht dargestellt, auf dem Gerät schon.
Und es ist egal, wie man das Typ-File ändert, in MS geht es nicht. Bei Typ-Files anderer Karten werden diese Elemente nicht verwendet.

zu 1) Werden vielleicht von anderen Flächen zB residential überdeckt ?

Nein, sie fehlen einfach. Aber wie gerade feststelle, fehlen alle Friedhofflächen. Meine das war früher anders.

zu 2) Das ist richtig, MS kann nicht alle Lines darstellen, die das Gerät anzeigen kann, des weiteren sind nur
bestimmte Linientypen fürs Routing geeignet.

Tja, dann könnte man doch für diese Linien andere Typen verwenden.

Noch was festgestellt: barrier = fence (0x33) wird in MS nicht angezeigt, auf den Geräten schon.

Also warum Mapsource hier manche Sachen nicht anzeigt, kann ich leider nicht sagen.
Ich habe in letzter Zeit verdammt viele Sachen umgebaut und neu gemacht. Schaut euch zum Beispiel mal den neuen Straßenlook an und gebt Meinung ab.

Es gibt jetzt auch für jede Teilkarte einen eigenen Mapsource-installer. Vielleicht nützt es dem ein oder anderen ja.

Die Sache mit den Friedhöfen lag an einem Schreibfehler meinerseits. Es heißt nicht cemetary sondern cemetery! 😉
Danke für den Hinweis.

Die nächste Version ab morgen sollte alle Friedhöfe korrekt enthalten!

Grüße
Christoph

master wrote:

Also warum Mapsource hier manche Sachen nicht anzeigt, kann ich leider nicht sagen.

Das warum ist klar, weil es Elemente sind die MS nicht kennt. Darum einfach andere Nummern nehmen.

Es ist halt typisch Garmin, dass die Geräte was können was MapSource nicht kann und umgekehrt, Hausaufgaben halt nicht gemacht ...

Ich habe in letzter Zeit verdammt viele Sachen umgebaut und neu gemacht. Schaut euch zum Beispiel mal den neuen Straßenlook an und gebt Meinung ab.

Es gibt jetzt auch für jede Teilkarte einen eigenen Mapsource-installer. Vielleicht nützt es dem ein oder anderen ja.

Das ist sicher eine gute Sache.

Die Sache mit den Friedhöfen lag an einem Schreibfehler meinerseits. Es heißt nicht cemetary sondern cemetery! 😉
Danke für den Hinweis.

Die nächste Version ab morgen sollte alle Friedhöfe korrekt enthalten!

Prima!

mike_hd wrote:

Das warum ist klar, weil es Elemente sind die MS nicht kennt. Darum einfach andere Nummern nehmen.

Es ist halt typisch Garmin, dass die Geräte was können was MapSource nicht kann und umgekehrt, Hausaufgaben halt nicht gemacht ...

Meinst du mich oder Garmin? Wenn die zu scheiße sind mal vernünftiges Standards zu machen, kann ichs auch nicht ändern.
Aber hast du ne Idee, welche Elemente nicht gehen?
Ich hab die Typen ja relativ beliebig belegt. Ich hab auch schon festgestellt, dass sich manche einfach mal anders verhalten als andere.
Das ist aber von Gerät zu Gerät verschieden und dann auch noch von Software zu Software, eben auch in Mapsource.

Ich persönlich benutze Mapsource höchstens um mal fix meinen Installer zu testen (hab mir extra n virtuelles WindowsXP zugelegt), aber sonst auch nicht.
Aber es soll ja Leute geben, die ernsthaft irgendwie sinnvoll mit Mapsource arbeiten.
Ich dachte ja, dass mit dem Typfile eigentlich festgelegt sein sollte, wie sich die Typen zu verhalten haben, aber das ist offenbar nicht so richtig der Fall.

Hast du vielleicht ne Idee, welche Typen ich vermeiden sollte und welche ich beruhigt nehmen kann? Gibts da ranges?

Eine Sache würde mich noch interessieren, falls die jemand weiß: Wie bekommt man es hin, dass im Find-menü neue Kategorien angelegt werden? Sind die wirklich hard gecodet oder geht da was?
Falls sie hardgecodet sind, würde mich trotzdem interessieren, ob man wenigstens die Unterkategorien benennen kann.
Beispielsweise habe ich ja einige Restaurants oder Shops dabei, die zwar in der entsprechenden Kategorie auftauchen, aber eben als Unterkategorie "Sonstiges" heißen.
Einen Namen im Typfile zu vergeben, reicht offenbar nicht. Kann man da noch was machen?

master wrote:

Die Sache mit den Friedhöfen lag an einem Schreibfehler meinerseits. Es heißt nicht cemetary sondern cemetery! 😉
Danke für den Hinweis.

Die nächste Version ab morgen sollte alle Friedhöfe korrekt enthalten!

Grüße
Christoph

In deinem Archiv http://dev.openstreetmap.de/aio/styles/styles.tar.bz2 (Datei masterstyle/polygons) sind beide Schreibweisen (cemetary und cemetery) enthalten. Es sollten also beide angezeigt werden.

Das styles-Archiv trägt das Datum 2009-10-23. Kann es sein, dass das Archiv nicht auf dem aktuellsten Stand ist?

Welche Styles und TYP-Dateien verwendest Du zur Zeit für den Bau der AIO?

Mich interessieren auch brennend die aktuell von dir verwendeten Aufrufparameter für mkgmap.

Sind die hier http://wiki.openstreetmap.org/wiki/DE:A … ap#Technik angegebenen Parameter aktuell?

Ich versuche gerade die seit dem Jahreswechsel massiv auftreteten Routingfehler mit der AIO zu ergründen.
Dazu habe ich die Karte in Anlehnung an die o.g. Anleitung im Wiki nachgebaut.

Folgende Dinge sind mir dabei aufgefallen:

- Die Datei mit den OSBs http://www.gary68.de/osm/qa/gpx/allbugs.gpx lässt sich nicht wie angegeben verarbeiten:
ungültige xml-Datei: Hinter </gpx> folgt noch weiterer Text.
Abhilfe: Text hinter dem ersten </gpx> entfernen.

cat␣download/allbugs.gpx␣\
|␣tr␣-d␣'\n\r'␣\
|␣sed␣'s|</gpx>.*|</gpx>|'␣\
|␣sed␣-E␣'s|closed>|name>|g;s|</?extensions>||g'␣\
|␣gpsbabel␣-i␣gpx␣-f␣-␣-o␣osm␣-F␣build/bugs_germany.osm

- OSBs haben immer den Text 0.
Wenn ich die original Datei fixme_layer_style/points

#␣Openstreetbugs:
note␣=␣*␣&␣name='0'␣[0x7111␣resolution␣20]
note␣=␣*␣&␣name='1'␣[0x7112␣resolution␣20]
note=*␣|␣fixme␣=␣*␣|␣FIXME=*␣|Fixme=*␣{name␣'Notiz:␣${note}'␣|␣'Notiz:␣${fixme}'␣|␣'Notiz:␣${FIXME}'␣|␣'Notiz:␣${Fixme}'␣}␣[0x7110␣resolution␣20]

durch folgende ersetzte ist die Anzeige wieder wie gewohnt:

#␣Openstreetbugs:
note␣=␣*␣&␣name='0'␣{name␣'${note}'}␣[0x7111␣resolution␣20]
note␣=␣*␣&␣name='1'␣{name␣'${note}'}␣[0x7112␣resolution␣20]
note=*␣|␣fixme=*␣|␣FIXME=*␣|␣Fixme=*␣{name␣'${note}'␣|␣'${fixme}'␣|␣'${FIXME}'␣|␣'${Fixme}'}␣[0x7110␣resolution␣20]

Zurück zu den Routing-Problemen mit etrex VISTA HCx:
Mit den Original-AIO Karten (Deutschland) gibt es neuerdings hier in einem relativ großflächigen Gebiet fast immer Abbrüche mit 'Routenberech.-Fehler'.

Die original AIO-Karten bis 2009-12-29 haben in dem Gebiet sehr gut funktioniert. Es kam extrem selten zu Abbrüchen.
Die folgenden original AIO-Karten die ich ausprobiert habe (2010-01-19, 2010-01-20, 2010-01-23, 2010-01-27, 2010-01-31, 2010-02-06) führen in 99% der Routing-Versuche zu einem Abbruch mit 'Routenberech.-Fehler'.

Ich habe mal als konkretes Beispiel irgendeine Straße in der Nähe als Start und einen 50 m davon entfernten Punkt als Ziel verwendet. Zur Verdeutlichung die Route mit Cloudmade:
http://maps.cloudmade.com/?lat=51.24344 … ened_tab=1

Das Problem tritt bei fast allen Start oder Zielpunkten in diesem Gebiet auf. Die zugrunde liegenden Daten der Straßen haben sich meines Wissens seit Dezember nicht verändert. Ich habe in dem Gebiet im Laufe des letzten Jahres sehr viele Straßen im Hinblick korrektes Routing aktualisiert und dabei das Verhalten der AIO-Karten ausführlich nach jeder meiner Änderungen getestet. Bis Dez. 2009 funktionierten hier die AIO-Karten hervorragend. Änderungen an den Straßen hatten (meistens) die erwarteten Auswirkungen.

Im Januar wurden lediglich in dem Gebiet sehr viele landuse-Flächen und Gebäude hinzugefügt. Das sollte aber keinen Einfluss auf das Routing haben.

Hat sich beim Bau deiner Karte mit dem Jahreswechsel etwas geändert was Ursache für die Abbrüche sein könnte?

Die beschriebenen Fehler treten übrigens nur bei neueren AIO-Karten auf. Aktuelle andere Karten (Radkarte, teddy-de-rout, Blue Map)haben in dem betreffenden Gebiet keine Routingprobleme.

Zur Ergründung der Ursache habe ich die AIO mit folgenden Befehlen nachgebaut. Die so erstellte Karte zeigt exakt die gleichen Routing-Probleme:

#␣Für␣den␣Bau␣werden␣mindestens␣12␣GB␣Festplattenplatz␣benötigt.

#␣aktuelles␣Verzeichnis␣für␣alle␣weiteren␣Befehle:

cd␣~/QLandkarteGT/Karten/Garmin/gmapsupp/all_in_one/own

#␣tilesplitter␣holen,␣auspacken␣und␣splitter.jar␣kopieren

[␣!␣-d␣download␣]␣&&␣mkdir␣download
(cd␣download;␣wget␣-N␣http://www.mkgmap.org.uk/splitter/splitter-r105.tar.gz)
[␣!␣-d␣download/splitter␣]␣&&␣mkdir␣-p␣download/splitter
tar␣xf␣download/splitter-r105.tar.gz␣-C␣download/splitter
[␣!␣-d␣bin␣]␣&&␣mkdir␣bin
cp␣./download/splitter/splitter-r105/splitter.jar␣./bin/.

#␣mkgmap␣latest␣holen,␣auspacken␣und␣mkgmap.jar␣kopieren:

[␣!␣-d␣download␣]␣&&␣mkdir␣download
(cd␣download;␣wget␣-N␣http://www.mkgmap.org.uk/snapshots/mkgmap-latest.tar.gz)
[␣!␣-d␣download/mkgmap␣]␣&&␣mkdir␣download/mkgmap
tar␣-xf␣download/mkgmap-latest.tar.gz␣-C␣download/mkgmap
[␣!␣-d␣bin␣]␣&&␣mkdir␣bin
tar␣-tf␣download/mkgmap-latest.tar.gz␣\
|␣grep␣'/mkgmap.jar$'␣\
|␣sed␣'s|^|cp␣download/mkgmap/|'␣\
|␣sed␣'s|$|␣bin/.|'␣\
|␣sh␣-x

#␣gmaptool␣holen,␣auspacken,␣kopieren:

[␣!␣-d␣download␣]␣&&␣mkdir␣download
(cd␣download;␣wget␣-N␣http://www.anpo.republika.pl/files/lgmt042a.zip)
[␣!␣-d␣download/lgmaptool␣]␣&&␣mkdir␣-p␣download/lgmaptool
unzip␣-o␣download/lgmt042a.zip␣-d␣download/lgmaptool/lgmt042a
[␣!␣-d␣bin␣]␣&&␣mkdir␣bin
cp␣./download/lgmaptool/lgmt042a/gmt␣./bin/.

#␣Styles␣holen␣und␣auspacken,␣kopieren,␣mit␣eigenen␣Aenderungen␣verschmelzen:

[␣!␣-d␣download␣]␣&&␣mkdir␣download
(cd␣download;␣wget␣-N␣http://dev.openstreetmap.de/aio/styles/styles.tar.bz2)
[␣-e␣download/styles-aio␣]␣&&␣rm␣-r␣download/styles-aio
[␣!␣-d␣download/styles-aio␣]␣&&␣mkdir␣download/styles-aio
tar␣xf␣download/styles.tar.bz2␣-C␣download/styles-aio
[␣!␣-d␣styles␣]␣&&␣mkdir␣styles
cp␣-R␣"download/styles-aio/osm/garmin/aio/styles/"*␣styles
[␣-d␣styles-own␣]␣&&␣meld␣styles␣styles-own

#␣OSM-Worldfile␣von␣geofabrik␣holen␣(ca.␣726␣MB␣download)

[␣!␣-d␣download␣]␣&&␣mkdir␣download
(cd␣download;␣wget␣-N␣http://download.geofabrik.de/osm/europe/germany.osm.bz2)

#␣OSM-Daten␣auspacken␣(ca.␣7.8␣GB␣ausgepackt):

[␣!␣-d␣build␣]␣&&␣mkdir␣-p␣build
[␣-e␣download/germany.osm␣]␣&&␣rm␣download/germany.osm
bunzip2␣-k␣download/germany.osm.bz2␣&&␣mv␣download/germany.osm␣build/

#␣tiles-Ordner␣anlegen␣und␣OSM-Daten␣splitten␣(ca.␣796␣MB):

[␣!␣-d␣build/tiles␣]␣&&␣mkdir␣-p␣build/tiles
rm␣build/tiles/*
(cd␣build/tiles;
java␣-Xmx1000M␣-jar␣../../bin/splitter.jar␣--mapid=63240345␣--max-nodes=1000000␣../../build/germany.osm)

#␣Daten␣für␣OSB-Layer␣holen:

[␣!␣-d␣download␣]␣&&␣mkdir␣download
(cd␣download;␣wget␣-N␣http://www.gary68.de/osm/qa/gpx/allbugs.gpx)

##␣Daten␣für␣OSB-Layer␣in␣OSM-Datei␣umwandeln:

[␣!␣-d␣build␣]␣&&␣mkdir␣-p␣build
[␣-e␣build/bugs_germany.osm␣]␣&&␣rm␣build/bugs_germany.osm
cat␣download/allbugs.gpx␣\
|␣tr␣-d␣'\n\r'␣\
|␣sed␣'s|</gpx>.*|</gpx>|'␣\
|␣sed␣-E␣'s|closed>|name>|g;s|</?extensions>||g'␣\
|␣gpsbabel␣-i␣gpx␣-f␣-␣-o␣osm␣-F␣build/bugs_germany.osm

#␣gmapsupp.img␣fuer␣einzelne␣Layer␣erstellen␣(ca.␣1.1GB␣ohne␣Hoehenlinien):

[␣!␣-d␣build/layer/basemap␣]␣&&␣mkdir␣-p␣build/layer/basemap
rm␣build/layer/basemap/*
(cd␣build/layer/basemap;
java␣-Xmx1000M␣-jar␣../../../bin/mkgmap.jar␣\
--max-jobs␣\
--description=`date␣+%d.`"␣$USERNAME␣"'OSM'␣--country-name=germany␣--country-abbr=DE␣\
--family-id=4␣--product-id=45␣--series-name='OSM-AllInOne-DE-bmap'␣\
--family-name=OSM␣--area-name=DE␣\
--latin1␣\
--mapname=63240345␣--draw-priority=10␣\
--add-pois-to-areas␣--make-all-cycleways␣--link-pois-to-ways␣--remove-short-arcs␣\
--net␣--route␣--gmapsupp␣\
--style-file=../../../styles/masterstyle␣\
../../tiles/*.osm.gz␣\
../../../styles/master.TYP)

[␣!␣-d␣build/layer/addr␣]␣&&␣mkdir␣-p␣build/layer/addr
rm␣build/layer/addr/*
(cd␣build/layer/addr;
java␣-Xmx1000M␣-jar␣../../../bin/mkgmap.jar␣\
--max-jobs␣\
--description=`date␣+%d.`"␣$USERNAME␣"'Adressen'␣--country-name=germany␣--country-abbr=DE␣\
--family-id=5␣--product-id=40␣--series-name='OSM-AllInOne-DE-Addr'␣\
--family-name=ADRESSEN␣--area-name=DE␣\
--latin1␣\
--mapname=63241345␣--draw-priority=20␣\
--no-poi-address␣--no-sorted-roads␣--add-pois-to-areas␣\
--transparent␣--gmapsupp␣\
--style-file=../../../styles/addresslayer_style␣\
../../tiles/*.osm.gz␣\
../../../styles/addr.TYP)

[␣!␣-d␣build/layer/boundary␣]␣&&␣mkdir␣-p␣build/layer/boundary
rm␣build/layer/boundary/*
(cd␣build/layer/boundary;
java␣-Xmx1000M␣-jar␣../../../bin/mkgmap.jar␣\
--max-jobs␣\
--description=`date␣+%d.`"␣$USERNAME␣"'Boundary'␣--country-name=germany␣--country-abbr=DE␣\
--family-id=6␣--product-id=30␣--series-name='OSM-AllInOne-DE-boundary'␣\
--family-name=boundary␣--area-name=DE␣\
--latin1␣\
--mapname=63240625␣--draw-priority=21␣\
--no-poi-address␣--no-sorted-roads␣\
--transparent␣--gmapsupp␣\
--style-file=../../../styles/boundary_style␣\
../../tiles/*.osm.gz␣\
../../../styles/boundary.TYP)

[␣!␣-d␣build/layer/fixme␣]␣&&␣mkdir␣-p␣build/layer/fixme
rm␣build/layer/fixme/*
(cd␣build/layer/fixme;
java␣-Xmx1000M␣-jar␣../../../bin/mkgmap.jar␣\
--max-jobs␣\
--description=`date␣+%d.`"␣$USERNAME␣"'Fixme'␣--country-name=germany␣--country-abbr=DE␣\
--family-id=3␣--product-id=33␣--series-name='OSM-AllInOne-DE-Fixme'␣\
--family-name=FIXME␣--area-name=DE␣\
--latin1␣\
--mapname=63242345␣--draw-priority=22␣\
--no-poi-address␣--no-sorted-roads␣\
--transparent␣--gmapsupp␣\
--style-file=../../../styles/fixme_layer_style␣\
../../tiles/*.osm.gz␣\
../../../styles/fixme.TYP)

[␣!␣-d␣build/layer/osb␣]␣&&␣mkdir␣-p␣build/layer/osb
rm␣build/layer/osb/*
(cd␣build/layer/osb;
java␣-Xmx1000M␣-jar␣../../../bin/mkgmap.jar␣\
--max-jobs␣\
--description=`date␣+%d.`"␣$USERNAME␣"'OSB'␣--country-name=germany␣--country-abbr=DE␣\
--family-id=3␣--product-id=33␣--series-name='OSM-AllInOne-DE-OSB'␣\
--family-name=OSB␣--area-name=DE␣\
--latin1␣\
--mapname=63243345␣--draw-priority=23␣\
--no-poi-address␣--no-sorted-roads␣\
--transparent␣--gmapsupp␣\
--style-file=../../../styles/fixme_layer_style␣\
../../bugs_germany.osm␣\
../../../styles/fixme.TYP)

#␣gmapsupp.img␣fuer␣Hoehenlinien␣Layer␣erstellen␣(ca.␣81␣MB):

[␣!␣-d␣download␣]␣&&␣mkdir␣download
(cd␣download;␣wget␣-N␣http://www.glade-web.de/GLADE_geocaching/maps/TOPO_D_SRTM.zip)
unzip␣-o␣download/Topo_D_SRTM.zip␣-d␣download/Topo_D_SRTM
[␣!␣-d␣build/layer/hoehe␣]␣&&␣mkdir␣-p␣build/layer/hoehe
cp␣"download/Topo_D_SRTM/Topo␣D␣SRTM/"*␣build/layer/hoehe/
[␣-e␣build/layer/hoehe/gmapsupp.img␣]␣&&␣rm␣build/layer/hoehe/gmapsupp.img
./bin/gmt␣-j␣-f␣5,25␣-m␣HOEHE␣-o␣build/layer/hoehe/gmapsupp.img␣build/layer/hoehe/*.img

#␣alle␣Layer␣zu␣einer␣gmapsup.img␣zusammenfuegen:

[␣-e␣gmapsupp.img␣]␣&&␣rm␣gmapsupp.img
./bin/gmt␣-jo␣gmapsupp.img␣\
build/layer/basemap/gmapsupp.img␣\
build/layer/addr/gmapsupp.img␣\
build/layer/boundary/gmapsupp.img␣\
build/layer/fixme/gmapsupp.img␣\
build/layer/osb/gmapsupp.img␣\
build/layer/hoehe/gmapsupp.img

Hallo master,

die Garmin-Kategorien scheinen hardcodet zu sein, noch dazu unterschiedlich je nach Gerät.
Es ist daher gar nicht so leicht, einen Plan für verschiedene Geräte zu erstellen.

Ich hatte vor, in meinem Oregon Plan ca. 25 bis 30 shops per Symbol zu unterscheiden.
Die ersten 11 (von 2e01 bis 2e0b) werden im Find-Menü zur Suche angeboten, die restlichen (bis 2e1f) leider nicht.
Das ist wohl von Garmin boshafterweise in der Firmware disabled worden.

Bei Restaurants war Garmin etwas großzügiger und zeigt bei der Suche alles bis 2a12 an, von 2a13 bis 2a1f wird wieder beinhart ausgeblendet.

So geht es dann auch weiter.
Bei Unterkunft kann nach 2b06, 2b07 nicht gesucht werden,
bei Sport findet er ab 2d0c nichts mehr,
Attraktionen sind ab 2c11 nicht mehr zu finden,
die Kategorie "Gemeinde" ist eine Mischung aus 2c.. 30.. und 2f..
Obstructions (1c01 bis 1c0a) hat ein etwas seltsames Verhalten, kann aber verwendet werden,
noch ärger sind Tides (1d03, 1d06) und Currents (1d05), aber ebenfalls verwendbar.
Geografische Punkte (64.. 65.. 66..) habe ich noch nicht vollständig erforscht, sind aber nur in 3 Gruppen untergliedert.
Others (2f09 bis 2f15) verwende ich recht gerne für Spezialsachen, hier habe ich auch die road-name-pois hingelegt.

Mit einer etwas sinnvolleren Suchmöglichkeit hätte Garmin sich leicht von anderen Navis deutlich absetzen können,
aber auch so ist bei geschickter Ausnutzung vieles aus einer OSM-Karte durchsuchbar anzulegen.

Walter

master wrote:

mike_hd wrote:

Das warum ist klar, weil es Elemente sind die MS nicht kennt. Darum einfach andere Nummern nehmen.

Es ist halt typisch Garmin, dass die Geräte was können was MapSource nicht kann und umgekehrt, Hausaufgaben halt nicht gemacht ...

Meinst du mich oder Garmin? Wenn die zu scheiße sind mal vernünftiges Standards zu machen, kann ichs auch nicht ändern.

War schon Garmin gemeint. Es ist so wie Du sagst ...

Aber hast du ne Idee, welche Elemente nicht gehen?
Ich hab die Typen ja relativ beliebig belegt. Ich hab auch schon festgestellt, dass sich manche einfach mal anders verhalten als andere.
Das ist aber von Gerät zu Gerät verschieden und dann auch noch von Software zu Software, eben auch in Mapsource.

Das ist ja das Elend, dass man nicht generell sagen kann, was geht und was nicht geht.
Es bleibt vermutlich nur try-and-error um heraus zu finden, was tatsächlich funktioniert. Oder man nimmt vorhandene Typ-Files, von den man weiss dass sie funktionieren, als Vorlage.

Ich persönlich benutze Mapsource höchstens um mal fix meinen Installer zu testen (hab mir extra n virtuelles WindowsXP zugelegt), aber sonst auch nicht.
Aber es soll ja Leute geben, die ernsthaft irgendwie sinnvoll mit Mapsource arbeiten.

Werden wohl die meisten sein. QLandkarte GT ist sicherlich nicht sehr weit verbreitet.

Ich dachte ja, dass mit dem Typfile eigentlich festgelegt sein sollte, wie sich die Typen zu verhalten haben, aber das ist offenbar nicht so richtig der Fall.

Jo, sollte man meinen, aber es ist halt Garmin 😉 ... Es ist wohl so, dass die Geräte alles das anzeigen können, was MapSource auch anzeigen kann. Zumindest hatte ich noch keinen Fall, wo das nicht so war.

Gibt es eigentlich irgendwo eine Übersicht, welche Typen sich auf welchen Garmin-Geräten wie verhalten? Falls ich diese übersehen habe, dann bitte ich um Nachsicht und einen Verweis dorthin, wo ich die Informationen finden kann. Falls nicht, möchte ich eine solche Übersicht anregen, bspw. als Wiki-Seite.

geopia wrote:

In deinem Archiv http://dev.openstreetmap.de/aio/styles/styles.tar.bz2 (Datei masterstyle/polygons) sind beide Schreibweisen (cemetary und cemetery) enthalten. Es sollten also beide angezeigt werden.

Das styles-Archiv trägt das Datum 2009-10-23. Kann es sein, dass das Archiv nicht auf dem aktuellsten Stand ist?

Au weiha! Ich hab festgestellt, dass ich seit Oktober den ganzen Stylekram mal überhaupt nicht aktualisiert hab. Ich hatte früher mal ne Routine, die immer den aktuellen Style ins downloadverzeichnis haut und bin einfach davon ausgegangen, dass das auch so klappt, ohne nachzuschaun. Jetzt hab ich gesehen, dass ich diese Funktionalität irgendwie rausgehaun hatte. Jetzt ists wieder drin und sollte klappen.
Ab morgen ist alles roger. Wer jetzt gleich aktuelle Styles braucht, schaue mal bei meiner Haiti-karte ins downloadverzeichnis rein.

Welche Styles und TYP-Dateien verwendest Du zur Zeit für den Bau der AIO?

Mich interessieren auch brennend die aktuell von dir verwendeten Aufrufparameter für mkgmap.

Sind die hier http://wiki.openstreetmap.org/wiki/DE:A … ap#Technik angegebenen Parameter aktuell?

Nö sind sie nicht. Ich müsste mal sehen, ob ich es hinbekomme die Parameter aus meinem Skript zu extrahieren und ständig aktuell irgendwo hinzulegen.
Das ändert sich einfach immer zu schnell und ich hab keinen Bock die Anleitung im Wiki ständig zu erneuern. Vor allem, wenn ich mal was testen will etc.

Ich versuche gerade die seit dem Jahreswechsel massiv auftreteten Routingfehler mit der AIO zu ergründen.
Dazu habe ich die Karte in Anlehnung an die o.g. Anleitung im Wiki nachgebaut.

Folgende Dinge sind mir dabei aufgefallen:

- Die Datei mit den OSBs http://www.gary68.de/osm/qa/gpx/allbugs.gpx lässt sich nicht wie angegeben verarbeiten:
ungültige xml-Datei: Hinter </gpx> folgt noch weiterer Text.

Nee, garys OSB-dumps benutze ich schon ne Weile nicht mehr. Ich habe mein eigenes Konvertierskript gebaut und verwurste damit den täglichen SQL-dump von Openstreetbugs.
Das hab ich auch etwas dokumentiert, schau mal hier:
http://wiki.openstreetmap.org/wiki/DE:A … streetbugs

Zurück zu den Routing-Problemen mit etrex VISTA HCx:
Mit den Original-AIO Karten (Deutschland) gibt es neuerdings hier in einem relativ großflächigen Gebiet fast immer Abbrüche mit 'Routenberech.-Fehler'.

Die original AIO-Karten bis 2009-12-29 haben in dem Gebiet sehr gut funktioniert. Es kam extrem selten zu Abbrüchen.
Die folgenden original AIO-Karten die ich ausprobiert habe (2010-01-19, 2010-01-20, 2010-01-23, 2010-01-27, 2010-01-31, 2010-02-06) führen in 99% der Routing-Versuche zu einem Abbruch mit 'Routenberech.-Fehler'.

Probier bitte mal ab morgen mittag den neuen Deutschlandauszug und sag mir, ob die Routingprobleme in der Art weiter bestehen. Ich konnte sie auf meinem Garmin 60CSx nicht nacherzeugen, hab aber auch nicht die Karten getestet, die du getestet hast, sondern neuere.
Ich hab den Verdacht, dass ich den Fehler unbewusst beseitigt hab, aber teste lieber erstmal.

Ach ja - für alle:
Die Karte ab morgen, hat ein etwas neues rendering und unterscheidet Wälder nach Nadel-, Laub-, und Mischwald.
Außerdem hab ich ein bissel am Nachtmodus bei einigen Sachen gearbeitet.
Dann könnt ihr mal schauen, ob das Meer da ist, wo es hingehört und nix überflutet ist.

Viele Grüße und viel Spaß dabei!
Christoph

master wrote:

geopia wrote:

Das styles-Archiv trägt das Datum 2009-10-23. Kann es sein, dass das Archiv nicht auf dem aktuellsten Stand ist?

Au weiha! Ich hab festgestellt, dass ich seit Oktober den ganzen Stylekram mal überhaupt nicht aktualisiert hab. Ich hatte früher mal ne Routine, die immer den aktuellen Style ins downloadverzeichnis haut und bin einfach davon ausgegangen, dass das auch so klappt, ohne nachzuschaun. Jetzt hab ich gesehen, dass ich diese Funktionalität irgendwie rausgehaun hatte. Jetzt ists wieder drin und sollte klappen.
Ab morgen ist alles roger.

Super.

master wrote:

Mich interessieren auch brennend die aktuell von dir verwendeten Aufrufparameter für mkgmap.
Sind die hier http://wiki.openstreetmap.org/wiki/DE:A … ap#Technik angegebenen Parameter aktuell?

Nö sind sie nicht. Ich müsste mal sehen, ob ich es hinbekomme die Parameter aus meinem Skript zu extrahieren und ständig aktuell irgendwo hinzulegen.

Das wäre schön.

master wrote:

Das ändert sich einfach immer zu schnell und ich hab keinen Bock die Anleitung im Wiki ständig zu erneuern. Vor allem, wenn ich mal was testen will etc.

Könntest Du nicht zu jeder Karte auf http://dev.openstreetmap.de/aio/ auch die zugrunde liegenden Styles und Parameter im Unterverzeichnis der Karte ablegen? Man könnte dann sehr gezielt die jeweiligen Änderungen testen und die Verbesserungen würdigen.

master wrote:

Zurück zu den Routing-Problemen mit etrex VISTA HCx:
Mit den Original-AIO Karten (Deutschland) gibt es neuerdings hier in einem relativ großflächigen Gebiet fast immer Abbrüche mit 'Routenberech.-Fehler'.

Die original AIO-Karten bis 2009-12-29 haben in dem Gebiet sehr gut funktioniert. Es kam extrem selten zu Abbrüchen.
Die folgenden original AIO-Karten die ich ausprobiert habe (2010-01-19, 2010-01-20, 2010-01-23, 2010-01-27, 2010-01-31, 2010-02-06) führen in 99% der Routing-Versuche zu einem Abbruch mit 'Routenberech.-Fehler'.

Probier bitte mal ab morgen mittag den neuen Deutschlandauszug und sag mir, ob die Routingprobleme in der Art weiter bestehen. Ich konnte sie auf meinem Garmin 60CSx nicht nacherzeugen, hab aber auch nicht die Karten getestet, die du getestet hast, sondern neuere.
Ich hab den Verdacht, dass ich den Fehler unbewusst beseitigt hab, aber teste lieber erstmal.

Das werde ich morgen testen. Bin gespannt.

master wrote:

Wer jetzt gleich aktuelle Styles braucht, schaue mal bei meiner Haiti-karte ins downloadverzeichnis rein.

Sorry, bin nicht ganz auf dem Laufenden - wo finde ich dieses ?

Die ganze All in one Garmin Map könnte nämlich entschieden brauchbarer sein, wenn sich mal bei den Styles etwas bewegen würde! 😉

Grüße, Michael

r-michael wrote:

master wrote:

Wer jetzt gleich aktuelle Styles braucht, schaue mal bei meiner Haiti-karte ins downloadverzeichnis rein.

Sorry, bin nicht ganz auf dem Laufenden - wo finde ich dieses ?

Hier: http://dev.openstreetmap.de/aio/haiti/styles.tar.bz2

Danke, hab's gefunden und getestet.
Leider kann ich gegenüber dem "alten Style-File" vom Oktober'09 keine grundlegende Verbesserung erkennen, außer dass die Hintergrundfarbe von Weiß auf Gelb gewechselt wurde.
Wahrscheinlich wirkt's sich nur in Haiti aus? 🤣

gmapsupp.img.20100213

Ein vernünftiges Routing ist in folgenden Fällen nicht mehr möglich. Regensburg - Düsseldorf bricht sofort mit einem Routenberechnungsfehler ab (Vista HCx und Oregon 300). Regensburg - Reutlingen wird trotz schnellster Route mit über 130 km Umweg berechnet, der Rückweg mit über 160 km Umweg (Vista HCx und Oregon 300).

Die Darstellung der Straßen auf dem Vista HCx ist überdimensioniert (ab der Zoomstufe 800 m und höher, also 1 km, 2 km und mehr sind die Straßen so breit, dass die Route nicht mehr angezeigt werden kann, der Kartenaufbau friert fast ein).

Ich vergleiche die heutige gmapsupp.img mit einer von Dezember 2009, die korrekt berechnete, keine Routingfehler hatte und von der Darstellung her in allen Zoomstufen in Ordnung war.

Wenn ich eine Karte aus OSM-Rohmaterial mit dem Stylefile vom September 2009 erstelle (auf dem Server als styles.tar.gz zu erhalten, masterstyle genannt), dann funktioniert die Karte top, bestes Routing, alles ok. Erstelle ich die gleiche Karte mit dem Stylefile von gestern (basemap_style), dann habe ich die oben genannten Probleme auch in meiner Karte. mkgmap ist die gleiche Version, die fehlerhafte Karte erhalte ich mit allen mkgmap-Version der letzen 2 Wochen und auch mit alten mkgmap-Versionen vom Herbst 2009, sobald ich das aktuelle Stylefile (basemap_styles) verwende.

Ich bitte das als Bericht zu sehen, nicht als Kritik an den bisher tollen Karten!!!

flux.

flux wrote:

gmapsupp.img.20100213

Ein vernünftiges Routing ist in folgenden Fällen nicht mehr möglich. Regensburg - Düsseldorf bricht sofort mit einem Routenberechnungsfehler ab (Vista HCx und Oregon 300). Regensburg - Reutlingen wird trotz schnellster Route mit über 130 km Umweg berechnet, der Rückweg mit über 160 km Umweg (Vista HCx und Oregon 300).

Vielleicht sind kürzere Strecken fürs Testen besser...

In Düsseldorf tritt der Fehler mit der o.g. Karte auf der geraden 500m langen Strecke von
Start: Ecke Ulmenstraße/Weißenburgstraße
Ziel: Ecke Ulmenstraße/Wörthstraße
auf.
Vista HCx, Auto/Motorrad, kürzere Zeit, folge Straße, vermeide nichts
http://www.openstreetmap.org/?lat=51.24 … 31&zoom=17

Weide

master wrote:

Ach ja - für alle:
Die Karte ab morgen, hat ein etwas neues rendering ...

Test mit etrexVISTA HCx: Oha! Die neuen Straßenbreiten erschlagen alles.
Damit ist die Karte nur noch in sehr großen Zoomstufen (<30m) lesbar.
Zoomstufen mit mehren hundert Metern oder Kilometern werden nur noch als Matsch dargestellt.
Kann man die Straßenbreiten nicht abhängig vom Zoom dünner machen?

master wrote:

Dann könnt ihr mal schauen, ob das Meer da ist, wo es hingehört und nix überflutet ist.

Die Ostsee überflutet große Teile von Meck.-Pomm.

master wrote:

Probier bitte mal ab morgen mittag den neuen Deutschlandauszug und sag mir, ob die Routingprobleme in der Art weiter bestehen. Ich konnte sie auf meinem Garmin 60CSx nicht nacherzeugen, hab aber auch nicht die Karten getestet, die du getestet hast, sondern neuere.
Ich hab den Verdacht, dass ich den Fehler unbewusst beseitigt hab, aber teste lieber erstmal.

Leider kann ich keine Verbesserung bezüglich des Routings mit dieser Karte gegenüber den Vorgängern feststellen:
Es bleibt dabei: In dem getesteten Gebiet kommt es fast immer zu Abbrüchen mit 'Routenberech.-Fehler.'
Schade.
Bei den heutigen Tests konnte ich die seit Jahresanfang gewohnten Routing-Fehler mit folgenden Karten beliebig oft reproduzieren:
- original-AIO-Karte 2010-01-13 http://dev.openstreetmap.de/aio/germany … 100213.bz2
- mit einer von mir selbst gebauten Karte
(OSM-Daten von Heute, mkgmap-r1568.20100210, mit deinen neuen styles von 20100212-2035 http://dev.openstreetmap.de/aio/germany/styles.tar.bz2)
- mit einer weiteren von mir selbst gebauten Karte
(OSM-Daten von Heute, mkgmap-r1568.20100210, mit deinen alten styles http://dev.openstreetmap.de/aio/styles/ … 3.tar.bz2)
Allerdings kenne ich noch nicht die von dir z.Zt. verwendeten Parameter für mkgmap. Ich habe noch die weiter oben von mir geposteten Parameter verwendet.

Der Fehler wurde soeben auch von Benutzer Weide in dem betreffenden Gebiet bestätigt. http://forum.openstreetmap.org/viewtopi … 556#p59556

Diesbezüglich hat sich also dein Verdacht leider nicht bestätigt.
Was kann die Ursache für die Abbrüche sein?

Die Fehler in Düsseldorf kann ich bestätigen (ich habe wieder eine kurze Strecke in der Eulerstraße berechnet, Routenberechnungsfehler auf Vista HCx und Oregon 300). Von Regensburg aus erreiche ich Düsseldorf per Routing nicht mehr.

Eine Karte mit den Styles vom 23.09.2009 (mit mkgmap von heute gerechnet) klappt dagegen fehlerfrei. Ich habe die Dateien aus masterstyle übernommen, lediglich lines und polygons bearbeitet.

flux.

flux wrote:

Die Fehler in Düsseldorf kann ich bestätigen (ich habe wieder eine kurze Strecke in der Eulerstraße berechnet, Routenberechnungsfehler auf Vista HCx und Oregon 300). Von Regensburg aus erreiche ich Düsseldorf per Routing nicht mehr.

Eine Karte mit den Styles vom 23.09.2009 (mit mkgmap von heute gerechnet) klappt dagegen fehlerfrei. Ich habe die Dateien aus masterstyle übernommen, lediglich lines und polygons bearbeitet.

Das mit den Styles vom 23.09.2009 würde ich gerne mal nachvollziehen.
Mit exakt welchen Parametern für mkgmap erzeugst Du deine Karten?
Die von dir verwendeten Styles vom 23.09.2009 stehen mir aber leider nicht zur Verfügung. Herunterladbar sind nur die vom 23.10.2009. Und die damit von mir gebaute aktuelle Karten führen auch zu besagten Abbrüchen. Kannst Du mir die Styles mal irgendwie rüber beamen?

Ein Fehler meinerseits, die Styles sind die vom 23.10.2009, sorry. Die liegen ja am Server.

Material: europe.osm.bz2 vom 12.02.2010
Tilesplitter: splitter-r105
mkgmap: mkgmap-r1568
Styles: styles.tar.bz2 vom 23.10.2009, da verwende ich nur das masterstyle-Verzeichnis (darin diese veränderte lines und veränderte polygons, alles andere bleibt wie es ist)

lines

aeroway=runway␣[0x27␣resolution␣20]

#␣Contours␣take␣their␣name␣from␣the␣elevation␣setting.
contour=elevation␣&␣contour_ext=elevation_minor␣{␣name␣'${ele|conv:m=>ft}';␣}␣[0x20␣resolution␣22]
contour=elevation␣&␣contour_ext=elevation_medium␣{␣name␣'${ele|conv:m=>ft}';␣}␣[0x21␣resolution␣20]
contour=elevation␣&␣contour_ext=elevation_major␣{␣name␣'${ele|conv:m=>ft}';␣}␣[0x22␣resolution␣18]

junction=roundabout␣&␣highway=trunk␣[0x0c␣road_class=1␣road_speed=5␣resolution␣16]
junction=roundabout␣&␣highway=primary␣[0x0c␣road_class=1␣road_speed=4␣resolution␣19]
junction=roundabout␣&␣highway=secondary␣[0x0c␣road_class=1␣road_speed=3␣resolution␣20]
junction=roundabout␣&␣highway=tertiary␣[0x0c␣road_class=1␣road_speed=3␣resolution␣20]
junction=roundabout␣&␣highway=unclassified␣[0x0c␣road_class=1␣road_speed=2␣resolution␣21]
junction=roundabout␣[0x0c␣road_class=1␣road_speed=1␣resolution␣21]

#␣Set␣highway␣names␣to␣include␣the␣reference␣if␣there␣is␣one
#highway=*␣{name␣'${name}␣(${ref})␣(${maxspeed})'␣|␣'${ref}␣(${maxspeed})'␣|␣'${name}␣(${maxspeed})'␣|␣'${name}␣(${ref})'␣|␣'${ref}'␣|␣'${name}'␣}
highway=footway|highway=cycleway|highway=track|highway=path|highway=bridleway|highway=byway|highway=pedestrian␣{name␣'${name}␣(${ref})␣(${maxspeed})'␣|␣'${ref}␣(${maxspeed})'␣|␣'${name}␣(${maxspeed})'␣|␣'${name}␣(${ref})'␣|␣'${ref}'␣|␣'${name}'␣}

highway=footway␣|␣highway=path␣|␣(highway=pedestrian␣&␣area!=yes␣&␣area!=true␣&␣area!=1)␣{add␣motorcar␣=␣no}␣[0x0d␣road_class=0␣road_speed=0␣resolution␣22]

highway=track␣&␣tracktype=grade1␣[0x0e␣road_class=0␣road_speed=2␣resolution␣22]
highway=track␣&␣tracktype=grade2␣[0x0f␣road_class=0␣road_speed=1␣resolution␣22]
highway=track␣&␣tracktype=grade3␣[0x10␣road_class=0␣road_speed=1␣resolution␣22]
highway=track␣&␣tracktype=grade4␣{add␣motorcar␣=␣no}␣[0x11␣road_class=0␣road_speed=0␣resolution␣22]
highway=track␣&␣tracktype=grade5␣{add␣motorcar␣=␣no}␣[0x12␣road_class=0␣road_speed=0␣resolution␣22]

highway=track␣|␣surface=unpaved␣|␣highway=unsurfaced␣{add␣motorcar␣=␣no}␣[0x0a␣road_class=0␣road_speed=1␣resolution␣22]

highway=steps␣{add␣motorcar␣=␣no;␣add␣bicycle␣=␣no}␣[0x13␣road_class=0␣road_speed=0␣resolution␣22]

#highway=path␣&␣sac_scale=hiking␣[0x3a␣road_class=0␣road_speed=0␣resolution␣22]
#highway=path␣&␣sac_scale=mountain_hiking␣[0x3b␣road_class=0␣road_speed=0␣resolution␣22]
#highway=path␣&␣sac_scale=demanding_mountain_hiking␣[0x3c␣road_class=0␣road_speed=0␣resolution␣22]
#highway=path␣&␣sac_scale=alpine_hiking␣[0x3d␣road_class=0␣road_speed=0␣resolution␣22]
#highway=path␣&␣sac_scale=demanding_alpine_hiking␣[0x3e␣road_class=0␣road_speed=0␣resolution␣22]
#highway=path␣&␣sac_scale=difficult_alpine_hiking␣[0x3f␣road_class=0␣road_speed=0␣resolution␣22]

highway=cycleway␣{add␣motorcar␣=␣no}␣[0x16␣road_class=0␣road_speed=1␣resolution␣22]

highway=bridleway␣[0x17␣road_class=0␣road_speed=0␣resolution␣23]
highway=byway␣[0x08␣road_class=0␣road_speed=0␣resolution␣23]

#␣motorways
highway=motorway␣{add␣oneway␣=␣yes;␣add␣bicycle␣=␣no;␣add␣foot␣=␣no;␣name␣'${ref|highway-symbol:hbox}␣${name}␣(${maxspeed})'␣|␣'${ref|highway-symbol:hbox}␣(${maxspeed})'␣|␣'${name}␣(${maxspeed})'␣|␣'${ref|highway-symbol:hbox}␣${name}'␣|␣'${ref|highway-symbol:hbox}'␣|␣'${name}'}
highway=motorway␣&␣(maxspeed>110)␣[0x01␣road_class=4␣road_speed=7␣resolution␣12]
highway=motorway␣&␣(maxspeed>90␣&␣maxspeed<111)␣[0x01␣road_class=4␣road_speed=6␣resolution␣12]
highway=motorway␣&␣(maxspeed>80␣&␣maxspeed<91)␣[0x01␣road_class=4␣road_speed=5␣resolution␣12]
highway=motorway␣&␣(maxspeed>60␣&␣maxspeed<81)␣[0x01␣road_class=4␣road_speed=4␣resolution␣12]
highway=motorway␣&␣(maxspeed>40␣&␣maxspeed<61)␣[0x01␣road_class=4␣road_speed=3␣resolution␣12]
highway=motorway␣&␣maxspeed<41␣[0x01␣road_class=4␣road_speed=3␣resolution␣12]
highway=motorway␣[0x01␣road_class=4␣road_speed=7␣resolution␣12]

highway=motorway_link␣{add␣bicycle␣=␣no;␣add␣foot␣=␣no}␣[0x01␣road_class=4␣road_speed=4␣resolution␣16]

#␣trunks
highway=trunk␣{name␣'${ref|highway-symbol:hbox}␣${name}␣(${maxspeed})'␣|␣'${ref|highway-symbol:hbox}␣(${maxspeed})'␣|␣'${name}␣(${maxspeed})'␣|'${ref|highway-symbol:hbox}␣${name}'␣|␣'${ref|highway-symbol:hbox}'␣|␣'${name}'␣}
(highway=trunk␣|␣highway=trunk_link)␣&␣motorroad=yes␣{add␣bicycle␣=␣no;␣add␣foot␣=␣no}
(highway=trunk␣|␣highway=trunk_link)␣&␣maxspeed>90␣[0x02␣road_class=3␣road_speed=6␣resolution␣16]
(highway=trunk␣|␣highway=trunk_link)␣&␣(maxspeed>80␣&␣maxspeed<91)␣[0x02␣road_class=3␣road_speed=5␣resolution␣16]
(highway=trunk␣|␣highway=trunk_link)␣&␣(maxspeed>60␣&␣maxspeed<81)␣[0x02␣road_class=3␣road_speed=4␣resolution␣16]
(highway=trunk␣|␣highway=trunk_link)␣&␣(maxspeed>40␣&␣maxspeed<61)␣[0x02␣road_class=3␣road_speed=3␣resolution␣16]
(highway=trunk␣|␣highway=trunk_link)␣&␣maxspeed<41␣[0x02␣road_class=3␣road_speed=2␣resolution␣16]
(highway=trunk␣|␣highway=trunk_link)␣[0x02␣road_class=3␣road_speed=6␣resolution␣16]

#␣primarys
highway=primary␣{name␣'${ref|highway-symbol:box}␣${name}␣(${maxspeed})'␣|␣'${ref|highway-symbol:box}␣(${maxspeed})'␣|␣'${name}␣(${maxspeed})'␣|'${ref|highway-symbol:box}␣${name}'␣|␣'${ref|highway-symbol:box}'␣|␣'${name}'␣}
highway=primary␣&␣maxspeed>90␣[0x02␣road_class=3␣road_speed=6␣resolution␣19]
highway=primary␣&␣(maxspeed>80␣&␣maxspeed<91)␣[0x02␣road_class=3␣road_speed=5␣resolution␣19]
highway=primary␣&␣(maxspeed>60␣&␣maxspeed<81)␣[0x02␣road_class=3␣road_speed=4␣resolution␣19]
highway=primary␣&␣(maxspeed>40␣&␣maxspeed<61)␣[0x02␣road_class=3␣road_speed=3␣resolution␣19]
highway=primary␣&␣maxspeed<41␣[0x02␣road_class=3␣road_speed=2␣resolution␣19]
highway=primary␣[0x02␣road_class=3␣road_speed=5␣resolution␣19]

highway=primary_link␣&␣maxspeed>90␣[0x03␣road_class=3␣road_speed=6␣resolution␣19]
highway=primary_link␣&␣(maxspeed>80␣&␣maxspeed<91)␣[0x03␣road_class=3␣road_speed=5␣resolution␣19]
highway=primary_link␣&␣(maxspeed>60␣&␣maxspeed<81)␣[0x03␣road_class=3␣road_speed=4␣resolution␣19]
highway=primary_link␣&␣(maxspeed>40␣&␣maxspeed<61)␣[0x03␣road_class=3␣road_speed=3␣resolution␣19]
highway=primary_link␣&␣maxspeed<41␣[0x03␣road_class=3␣road_speed=2␣resolution␣19]
highway=primary_link␣[0x03␣road_class=3␣road_speed=4␣resolution␣19]

#␣secondarys
highway=secondary␣{name␣'${ref|highway-symbol:oval}␣${name}␣(${maxspeed})'␣|␣'${ref|highway-symbol:oval}␣(${maxspeed})'␣|␣'${name}␣(${maxspeed})'␣|'${ref|highway-symbol:oval}␣${name}'␣|␣'${ref|highway-symbol:oval}'␣|␣'${name}'␣}
(highway=secondary␣|␣highway=secondary_link)␣&␣maxspeed>90␣[0x04␣road_class=2␣road_speed=6␣resolution␣20]
(highway=secondary␣|␣highway=secondary_link)␣&␣(maxspeed>80␣&␣maxspeed<91)␣[0x04␣road_class=2␣road_speed=5␣resolution␣20]
(highway=secondary␣|␣highway=secondary_link)␣&␣(maxspeed>60␣&␣maxspeed<81)␣[0x04␣road_class=2␣road_speed=4␣resolution␣20]
(highway=secondary␣|␣highway=secondary_link)␣&␣(maxspeed>40␣&␣maxspeed<61)␣[0x04␣road_class=2␣road_speed=3␣resolution␣20]
(highway=secondary␣|␣highway=secondary_link)␣&␣maxspeed<41␣[0x04␣road_class=2␣road_speed=2␣resolution␣20]
(highway=secondary␣|␣highway=secondary_link)␣[0x04␣road_class=2␣road_speed=5␣resolution␣20]

#␣tertiarys
highway=tertiary␣{name␣'${ref|highway-symbol:round}␣${name}␣(${maxspeed})'␣|␣'${ref|highway-symbol:round}␣(${maxspeed})'␣|␣'${name}␣(${maxspeed})'␣|'${ref|highway-symbol:round}␣${name}'␣|␣'${ref|highway-symbol:round}'␣|␣'${name}'␣}
(highway=tertiary␣|␣highway=tertiary_link)␣&␣maxspeed>90␣[0x05␣road_class=2␣road_speed=6␣resolution␣20]
(highway=tertiary␣|␣highway=tertiary_link)␣&␣(maxspeed>80␣&␣maxspeed<91)␣[0x05␣road_class=2␣road_speed=5␣resolution␣20]
(highway=tertiary␣|␣highway=tertiary_link)␣&␣(maxspeed>60␣&␣maxspeed<81)␣[0x05␣road_class=2␣road_speed=4␣resolution␣20]
(highway=tertiary␣|␣highway=tertiary_link)␣&␣(maxspeed>40␣&␣maxspeed<61)␣[0x05␣road_class=2␣road_speed=3␣resolution␣20]
(highway=tertiary␣|␣highway=tertiary_link)␣&␣maxspeed<41␣[0x05␣road_class=2␣road_speed=2␣resolution␣20]
(highway=tertiary␣|␣highway=tertiary_link)␣[0x05␣road_class=2␣road_speed=4␣resolution␣20]

highway=*␣{name␣'${name}␣(${ref})␣(${maxspeed})'␣|␣'${ref}␣(${maxspeed})'␣|␣'${name}␣(${maxspeed})'␣|␣'${name}␣(${ref})'␣|␣'${ref}'␣|␣'${name}'␣}

#␣residentials
(highway=residential␣|␣highway=living_street␣|highway=minor)␣&␣maxspeed>90␣[0x06␣road_class=0␣road_speed=6␣resolution␣22]
(highway=residential␣|␣highway=living_street␣|highway=minor)␣&␣(maxspeed>80␣&␣maxspeed<91)␣[0x06␣road_class=0␣road_speed=5␣resolution␣22]
(highway=residential␣|␣highway=living_street␣|highway=minor)␣&␣(maxspeed>60␣&␣maxspeed<81)␣[0x06␣road_class=0␣road_speed=4␣resolution␣22]
(highway=residential␣|␣highway=living_street␣|highway=minor)␣&␣(maxspeed>40␣&␣maxspeed<61)␣[0x06␣road_class=0␣road_speed=3␣resolution␣22]
(highway=residential␣|␣highway=living_street␣|highway=minor)␣&␣(maxspeed>20␣&␣maxspeed<41)␣[0x06␣road_class=0␣road_speed=2␣resolution␣22]
(highway=residential␣|␣highway=living_street␣|highway=minor)␣&␣maxspeed<21␣[0x06␣road_class=0␣road_speed=1␣resolution␣22]
(highway=residential␣|␣highway=living_street␣|highway=minor)␣[0x06␣road_class=0␣road_speed=3␣resolution␣22]

#␣service
highway=service␣&␣maxspeed>90␣[0x07␣road_class=0␣road_speed=6␣resolution␣22]
highway=service␣&␣(maxspeed>80␣&␣maxspeed<91)␣[0x07␣road_class=0␣road_speed=5␣resolution␣22]
highway=service␣&␣(maxspeed>60␣&␣maxspeed<81)␣[0x07␣road_class=0␣road_speed=4␣resolution␣22]
highway=service␣&␣(maxspeed>40␣&␣maxspeed<61)␣[0x07␣road_class=0␣road_speed=3␣resolution␣22]
highway=service␣&␣(maxspeed>20␣&␣maxspeed<41)␣[0x07␣road_class=0␣road_speed=2␣resolution␣22]
highway=service␣&␣maxspeed<21␣[0x07␣road_class=0␣road_speed=1␣resolution␣22]
highway=service␣[0x07␣road_class=0␣road_speed=2␣resolution␣22]

#␣unclassified
highway=unclassified␣{add␣name␣=␣unclassified}
highway=unclassified␣&␣maxspeed>90␣[0x08␣road_class=2␣road_speed=6␣resolution␣21]
highway=unclassified␣&␣(maxspeed>80␣&␣maxspeed<91)␣[0x08␣road_class=2␣road_speed=5␣resolution␣21]
highway=unclassified␣&␣(maxspeed>60␣&␣maxspeed<81)␣[0x08␣road_class=2␣road_speed=4␣resolution␣21]
highway=unclassified␣&␣(maxspeed>40␣&␣maxspeed<61)␣[0x08␣road_class=2␣road_speed=3␣resolution␣21]
highway=unclassified␣&␣(maxspeed>20␣&␣maxspeed<41)␣[0x08␣road_class=2␣road_speed=2␣resolution␣21]
highway=unclassified␣&␣maxspeed<21␣[0x08␣road_class=2␣road_speed=1␣resolution␣21]
highway=unclassified␣[0x08␣road_class=2␣road_speed=2␣resolution␣21]

#␣Mop␣up␣any␣unrecognised␣highway␣types␣but␣keep␣areas␣like␣pedestrian␣for␣polygons!
highway=*␣&␣area!=yes␣&␣area!=true␣&␣area!=1␣[0x09␣]

natural=coastline␣[0x15␣resolution␣12]
power=line␣{name␣'Stromleitung␣(${voltage}␣Volt)'}␣[0x29␣resolution␣22]

railway=light_rail␣[0x39␣resolution␣23]
railway=rail␣[0x14␣resolution␣17]
railway=subway␣[0x39␣resolution␣23]
railway=tram␣|␣railway=narrow_gauge␣[0x39␣resolution␣23]

route=ferry␣[0x1a␣road_class=0␣road_speed=0␣resolution␣18]

man_made=pipeline␣[0x28␣resolution␣22]

natural=cliff␣[0x31␣resolution␣22]
barrier=wall␣|␣barrier=retaining_wall␣|␣barrier=city_wall␣[0x32␣resolution␣24]
barrier=fence␣[0x33␣resolution␣24]
barrier=hedge␣[0x34␣resolution␣24]

aerialway=chair_lift␣|␣aerialway=drag_lift␣|␣aerialway=cable_car␣[0x38␣resolution␣24]

waterway=canal␣[0x1f␣resolution␣21]
waterway=drain␣[0x1f␣resolution␣22]
waterway=river␣[0x1f␣resolution␣18]
waterway=stream␣[0x18␣resolution␣22]

boundary=administrative␣{␣name␣'${mkgmap:boundary_name}'␣}
boundary=administrative␣&␣admin_level<3␣[0x1e␣resolution␣16]
boundary=administrative␣&␣admin_level<5␣[0x1d␣resolution␣18]
boundary=administrative␣&␣admin_level<7␣[0x1c␣resolution␣20]
boundary=administrative␣&␣admin_level<9␣[0x1c␣resolution␣21]
boundary=administrative␣[0x1c␣resolution␣22]
boundary=national␣[0x1e␣resolution␣17]
boundary=political␣[0x1c␣resolution␣17]

poygons

#␣-------------------------------------------------------------------
#␣This␣is␣the␣default␣mkgmap␣style␣file␣for␣converting␣closed␣OSM␣ways
#␣into␣Garmin␣polygons.
#␣Any␣line␣prefaced␣with␣#␣is␣a␣comment␣and␣will␣not␣be␣applied.
#␣Each␣line␣is␣a␣rule,␣of␣the␣generalised␣format:
#␣␣OSM_tag(s)_to_match␣␣[Garmin_type_code␣resolution]
#␣See␣http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules
#␣and␣http://wiki.openstreetmap.org/wiki/Mkgmap/help/Custom_styles
#␣for␣more␣information.

aeroway=airport␣[0x07␣resolution␣18]
aeroway=aerodrome␣[0x07␣resolution␣18]
aeroway=terminal␣[0x13␣resolution␣20]

amenity=kindergarten␣[0x0a␣resolution␣18]
amenity=college␣[0x0a␣resolution␣18]
amenity=grave_yard␣[0x1a␣resolution␣18]
amenity=hospital␣[0x0b␣resolution␣18]
amenity=parking␣[0x05␣resolution␣21]
amenity=school␣[0x0a␣resolution␣20]
amenity=supermarket␣[0x08␣resolution␣21]
amenity=university␣[0x0a␣resolution␣18]

landuse=allotments␣[0x4e␣resolution␣20]
landuse=basin␣[0x3f␣resolution␣18]
landuse=cemetary␣[0x1a␣resolution␣18]
landuse=cemetery␣[0x1a␣resolution␣18]
landuse=commercial␣[0x0c␣resolution␣18]
landuse=construction␣[0x0c␣resolution␣20]
landuse=farm␣[0x4e␣resolution␣18]
landuse=farmyard␣[0x4e␣resolution␣18]
landuse=forest␣[0x50␣resolution␣18]
landuse=greenfield␣[0x17␣resolution␣18]
landuse=industrial␣[0x0c␣resolution␣18]
landuse=meadow␣[0x17␣resolution␣18]
landuse=military␣[0x04␣resolution␣18]
landuse=quarry␣[0x0c␣resolution␣18]
landuse=recreation_ground␣[0x19␣resolution␣18]
landuse=reservoir␣[0x3f␣resolution␣18]
landuse=retail␣[0x08␣resolution␣20]
landuse=village_green␣[0x17␣resolution␣20]
landuse=vineyard␣[0x4e␣resolution␣20]

leisure=common␣[0x17␣resolution␣20]
leisure=garden␣[0x17␣resolution␣20]
leisure=golf_course␣[0x18␣resolution␣20]
leisure=marina␣[0x09␣resolution␣20]
leisure=nature_reserve␣[0x16␣resolution␣18]
leisure=park␣[0x17␣resolution␣20]
leisure=pitch␣[0x19␣resolution␣20]
leisure=playground␣[0x17␣resolution␣20]
leisure=recreation_ground␣[0x19␣resolution␣18]
leisure=sports_center␣|␣leisure=sports_centre␣[0x19␣resolution␣20]
leisure=stadium␣[0x19␣resolution␣19]
leisure=track␣[0x19␣resolution␣18]
leisure=water_park␣[0x09␣resolution␣18]

military=airfield␣[0x04␣resolution␣18]
military=barracks␣[0x04␣resolution␣18]
military=danger_area␣[0x04␣resolution␣18]
military=range␣[0x04␣resolution␣18]

natural=glacier␣[0x4d␣resolution␣16]
natural=marsh␣[0x51␣resolution␣20]
natural=mud␣[0x51␣resolution␣20]
natural=wetland␣[0x51␣resolution␣20]
natural=scrub␣[0x4f␣resolution␣20]
natural=water␣[0x3c␣resolution␣18]
natural=sea␣[0x32␣resolution␣10]
natural=wood␣[0x50␣resolution␣18]

place=village␣[0x03␣resolution␣18]

shop=*␣[0x08␣resolution␣20]

#␣squares␣and␣plazas
highway=pedestrian␣&␣area=yes␣[0x17␣resolution␣20]
#␣other␣highways␣that␣have␣area=yes␣set␣must␣be␣parking␣lots
highway=*␣&␣area=yes␣[0x05␣resolution␣21]

waterway=riverbank␣[0x46␣resolution␣20]

#␣building␣tag␣should␣be␣last
building=*␣[0x13␣resolution␣24]

So baue ich die Karte (ich verwende ausschließlich Linux, die Parameter sind aber wohl in Windows gleich):

#␣europe.osm.bz2␣splitten
name=EUROPA
java␣-Xmx2600M␣-ea␣-jar␣/pfad/zum/splitter.jar␣--no-trim␣--cache=cache␣--max-nodes=1000000␣--write-kml=$name.kml␣europe.osm.bz2
#
#␣gmapsupp.img␣erstellen
java␣-Xmx2600M␣-ea␣-jar␣/pfad/zum/mkgmap.jar␣--latin1␣--name-tag-list=name:en,int_name,name:zh_py,name:engels,name␣--route␣--gmapsupp␣--draw-priority=10␣--add-pois-to-areas␣--make-all-cycleways␣--link-pois-to-ways␣--remove-short-arcs␣--net␣--check-roundabouts␣--check-roundabout-flares␣--max-flare-length-ratio=5␣--adjust-turn-headings␣--location-autofill=1␣--index␣--road-name-pois␣--generate-sea=extend-sea-sectors␣--description=$name␣--series-name=$name␣--style-file=/pfad/zum/masterstyle␣--max-jobs=2␣6*

Die so erzeugte gmapsupp.img geht perfekt, egal wohin ich route, egal welche Optionen ich verwende, egal ob auf dem Vista HCx oder dem Oregon 300. Und die Darstellung ist die originale Darstellung des jeweiligen Garmin-Geräts und damit ist eine schnellstmögliche Reaktion beim Zoomen und Rechnen gewährleistet. Wer ein TYPfile verwendet, der büßt an Geschwindigkeit bei der Routendarstellung und beim Kartenaufbau beim Verschieben der Karte oder beim Zoomen ein --- und zwar erheblich.

flux.

@flux
Was bedeutet "6*" am Ende Deines mkgmap-Aufrufs?

Christian

Der Tilesplitter wird ja ohne Option hinsichtlich Kachelbezeichnung gestartet, deshalb legt er Tiles mit der Bezeichnung

63240001.osm.gz
63240002.osm.gz
...

an, bis das Kartenmaterial komplett gesplittet ist.

Und diese 6* übergebe ich an mkgmap (ich könnte auch 6324*.osm.gz schreiben).

flux.

flux wrote:

#␣europe.osm.bz2␣splitten
name=EUROPA
java␣-Xmx2600M␣-ea␣-jar␣/pfad/zum/splitter.jar␣--no-trim␣--cache=cache␣--max-nodes=1000000␣--write-kml=$name.kml␣europe.osm.bz2

Du verwendest beim splitter die Option '--no-trim'.
(aus SplitterParams.java: description = "Don't trim empty space off the edges of tiles.")

Ausgehend von meinen bisherigen Einstellungen beim Bau der Karte habe ich als einzige Änderung testweise '--no-trim' beim splitter hinzugefügt.
- OSM-Daten von gestern 2020-02-13
- splitter-r105 von 2010-01-28
- mkgmap-r1568 von 2010-02-10
- 'alte' AIO-Styles von 2009-10-23

Erstes Ergebnis nach 'ner Handvoll Tests zu verschiedenen Zielpunkten: Es treten keine Routing-Fehler mehr auf!

Danke @flux für die Angabe deiner exakten Parameter.
Für mkgmap verwendest Du auch von meiner Konfiguration stark abweichende Parameter. Hier muss ich noch testen.

@master:
Könntest Du bitte die exakten Parameter für den splitter und für mkgmap angeben welche Du für den Bau der original AIO-Karte verwendest?
Verwendest Du beim splitter die Option '--no-trim'?

Was steckt exakt hinter der Option '--no-trim'?

Das Anwenden der Option --no-trim macht keinen Unterschied beim Bau meiner Karten (--no-trim habe ich von Lambertus übernommen, der seine europaweiten Karten, die man länderweise oder als Kacheln laden kann, so baut, das hat für mich gut geklungen und ich habe es übernommen).

Sobald ich die neueren Stylefiles vom AIO-Server nehme, treten Routingfehler auf. Das Problem liegt mit an Sicherheit grenzender Wahrscheinlichkeit in den Stylefiles.

Im übrigen erhalte ich mit der aktuellen Karte von Computerteddy exakt die Fehler, die ich auch mit der AIO erhalte (Regensburg - Reutlingen geht nicht mehr --> Routenberechnungsfehler, Regensburg - Düsseldorg geht nicht mehr --> Routenberechnungsfehler).

Offensichtlich werden hier auch Stylefiles verwendet, die mit mkgmap kollidieren ... es muss ja jemanden geben, der sagen kann, wann er was bei seinen Stylefiles verändert hat!?

flux.

EDIT: Bitte unbedingt auch die Optionen von Garmin-User beachten!!! --> http://forum.openstreetmap.org/viewtopic.php?id=6383

Hallo Leute,

also die Sache mit den zu fetten Straßen ist mir auch schon aufgefallen. Ich werde sie demnächst wieder dünner machen.
Das Problem ist eben wirklich, dass man nicht in den einzelnen Zoomstufen die Renderingart unterscheiden kann - also dünner je weiter man rauszoomt.
Wenn doch, wäre ich dankbar, wenn mir jemand erklärt, wie das gehen soll.

Die Sache mit dem Routingfehler ist wirklich sehr seltsam.
Für Haiti habe ich ganz vorne sowas hinzugefügt:
highway=* & impassable=yes {add access=no}

aber das sollte so funktionieren und sonst nix beeinträchtigen.
Weiterhin habe ich noch den Teil für unpaved roads hinzugefügt (aus dem default mkgmap style kopiert), damit man bei den routingoptionen unbefestigte Straßen vermeiden kann.
Dann habe ich noch die unclassified auf einen anderen Typ gesetzt und primary und trunk auf den selben. Aber das is nix mit routing.

Ich kann sonst wirklich keinen krassen Fehler entdecken.
Ich habe gerade mal eingebaut, dass der einfach die verwendeten mkgmap-Parameter mit ausgibt und in ne Datei schmeißt, die dann ins downloadverzeichnis kommt.
Das sollte ab morgen funktionieren, bzw. schon heute bei der Haiti-karte im downloadverzeichnis:
http://dev.openstreetmap.de/aio/haiti

Ansonsten hätte ich mal ne andere Frage:
Ich hatte eigentlich nie so richtig vor, dass ich die ganze Karte immer wieder alleine anpasse. Ich meine es gibt ständig neue Tags und Dinge bei Openstreetmap, aber nicht alle interessieren mich gleichermaßen. Das einbauen in das Style- und Typfile ist ein klein wenig Aufwand, aber es hält sich in Grenzen.
Ich frage mich, ob es was bringen würde so eine Art svn (oder git?) zu machen und interessierten Leuten Zugriff zu geben. Ihr könntet dann direkt die Karte verbessern, wenn euch was offensichtliches ins Auge springt.
Nun klar - mir ist bekannt, dass die Geschmäcker oft verschieden sind, aber ich denke man kann sich da schon auf einen gemeinsamen Nenner einigen.
Der Vorteil von so nem repository ist auch, dass man dann Versionen hat und die direkt vergleichen kann, wenn wieder so wie jetzt, der Verdacht besteht, dass ich da was verkackt habe und deswegen das routing nicht geht. Vielleicht findet man ja dann den Fehler.

master wrote:

Ich frage mich, ob es was bringen würde so eine Art svn (oder git?) zu machen und interessierten Leuten Zugriff zu geben. Ihr könntet dann direkt die Karte verbessern, wenn euch was offensichtliches ins Auge springt.

Gute Idee, da wäre ich mit dabei, zumal ich schon Erfahrung im Umgang mit SVN habe und inzwischen auch mit mkgmap-styles. Die OSM-Tags werden schließlich von der Community "fest"gelegt, von daher macht es schon Sinn, wenn auch die Community (oder zumindest ein paar mehr Leute) sie in die AIO Map einbauen könnten.

Fände ich auch gut! Würde auch mitarbeiten.

master wrote:

Ich habe gerade mal eingebaut, dass der einfach die verwendeten mkgmap-Parameter mit ausgibt und in ne Datei schmeißt, die dann ins downloadverzeichnis kommt.
Das sollte ab morgen funktionieren, bzw. schon heute bei der Haiti-karte im downloadverzeichnis:
http://dev.openstreetmap.de/aio/haiti

Sieht gut aus.
Könntest Du das auch noch für die Ausgabe der Parameter des Splitters einbauen?
Welchen Splitter verwendest Du?

Die Parameter für den Bau des OSB-Layers fehlen.

Wie baust den OSB-Layer konkret.
Wenn ich deiner Beschreibung mit osbsql2osm in
http://wiki.openstreetmap.org/wiki/DE:A … streetbugs folge, dann erhalte ich ein anderes Ergebnis als in der original AIO-Karte:
- Bei der original AIO-Karte werden nur offene Bugs angezeigt
- Bei meiner mit osbsql2osm selbst gebauten Karte werden offene *und* geschlossene Bugs angezeigt.

Warum werden eigentlich die Layer für 'fixme' und 'OSB' im etrex VISTA HCx Layer-Ein-und-Abschalt-Menü beide mit dem gleichen Namen 'Fixme' angeboten?
Im Beispiel im Wiki werden beide Layer mit --family-id=3 und --product-id=33 erzeugt. Ist das korrekt?
Die TYP-Dateien fixme.TYP und osb.TYP sind identisch! Ist das korrekt?

master wrote:

Ansonsten hätte ich mal ne andere Frage:
Ich hatte eigentlich nie so richtig vor, dass ich die ganze Karte immer wieder alleine anpasse. Ich meine es gibt ständig neue Tags und Dinge bei Openstreetmap, aber nicht alle interessieren mich gleichermaßen. Das einbauen in das Style- und Typfile ist ein klein wenig Aufwand, aber es hält sich in Grenzen.
Ich frage mich, ob es was bringen würde so eine Art svn (oder git?) zu machen und interessierten Leuten Zugriff zu geben. Ihr könntet dann direkt die Karte verbessern, wenn euch was offensichtliches ins Auge springt.
Nun klar - mir ist bekannt, dass die Geschmäcker oft verschieden sind, aber ich denke man kann sich da schon auf einen gemeinsamen Nenner einigen.
Der Vorteil von so nem repository ist auch, dass man dann Versionen hat und die direkt vergleichen kann, wenn wieder so wie jetzt, der Verdacht besteht, dass ich da was verkackt habe und deswegen das routing nicht geht. Vielleicht findet man ja dann den Fehler.

Das mit einem svn wollte ich auch schon anregen. Damit wird die Erzeugung deiner Karte für alle transparent.
Das hätte in vielerlei Hinsicht Vorteile.

geopia wrote:

Könntest Du das auch noch für die Ausgabe der Parameter des Splitters einbauen?
Welchen Splitter verwendest Du?

den aktuellen 105.
Die Parameter lohnen kaum. Sind immer:
splitter.jar --mapid=63240345 --max-nodes=1000000
und ein Cache directory.

Die Parameter für den Bau des OSB-Layers fehlen.

Wie baust den OSB-Layer konkret.
Wenn ich deiner Beschreibung mit osbsql2osm in
http://wiki.openstreetmap.org/wiki/DE:A … streetbugs folge, dann erhalte ich ein anderes Ergebnis als in der original AIO-Karte:
- Bei der original AIO-Karte werden nur offene Bugs angezeigt
- Bei meiner mit osbsql2osm selbst gebauten Karte werden offene *und* geschlossene Bugs angezeigt.

Stimmt - ich schieb das hinterher noch durch osmosis und beschränke das auf die boundingbox des osmfiles (hab ein sed-skript, was die BBOX aus dem OSM-File holt und ein bisschen makefile-spaß), sowie alle offenen bugs:
osbsql2osm | osmosis --rx - --bb $(BBOX) --nkv keyValueList="type.0" --wx ausgabe.osm

Warum werden eigentlich die Layer für 'fixme' und 'OSB' im etrex VISTA HCx Layer-Ein-und-Abschalt-Menü beide mit dem gleichen Namen 'Fixme' angeboten?
Im Beispiel im Wiki werden beide Layer mit --family-id=3 und --product-id=33 erzeugt. Ist das korrekt?
Die TYP-Dateien fixme.TYP und osb.TYP sind identisch! Ist das korrekt?

Naja ursprünglich wollte ich das alles in einen Layer tun, aber so richtig ist das dann doch nicht geworden. Sauber getrennt hab ichs eben nie. Werde ich wohl mal machen müssen.
Der kommt aber auch damit klar, denke ich, wenn die Dateien eigentlich gleich sind.

Das mit einem svn wollte ich auch schon anregen. Damit wird die Erzeugung deiner Karte für alle transparent.
Das hätte in vielerlei Hinsicht Vorteile.

Hab das mal angefragt. Mal sehen, wann das läuft.

Grüße
Christoph

Weide wrote:

In Düsseldorf tritt der Fehler mit der o.g. Karte auf der geraden 500m langen Strecke von
Start: Ecke Ulmenstraße/Weißenburgstraße
Ziel: Ecke Ulmenstraße/Wörthstraße
auf.
Vista HCx, Auto/Motorrad, kürzere Zeit, folge Straße, vermeide nichts
http://www.openstreetmap.org/?lat=51.24 … 31&zoom=17

Dieser Fehler ist in der heute morgen geholten Karte weg. Die anderen auch?

Weide

Problem ist nach wie vor die Berechnung von Routen.

Beispiel:

Regensburg - Reutlingen wird mit 345 km und 3:18 Stunden berechnet, obwohl es eine Route mit 312 km und 3:04 Stunden gibt und eine mit 294 km und 2:56 Stunden.

Es wird also trotz "Kürzere Zeit" nicht die korrekte Route berechnet.

Die Style-files aus mkgmap ohne Bearbeitung routen die Strecke mit 312 km und 3:04 Stunden.

Dies tritt auf dem Vista HCx und dem Oregon 300 gleichermaßen auf. Die Geschwindigkeitsklassen in Verbindung mit den beiden Geräten scheinen nicht zusammen zu passen.

An einer Lösung wäre ich sehr interessiert.

flux.

Weide wrote:

Dieser Fehler ist in der heute morgen geholten Karte weg.

flux wrote:

Regensburg - Reutlingen wird mit 345 km und 3:18 Stunden berechnet, obwohl es eine Route mit 312 km und 3:04 Stunden gibt und eine mit 294 km und 2:56 Stunden.

Es wird also trotz "Kürzere Zeit" nicht die korrekte Route berechnet.

Das sieht nach zwei verschiedenen Problemen aus.

Bei der von mir erwähnten Strecke geht es um Bereiche der Karte, in denen jedes Routing im Garmin abbricht. Dieses Problem ist jetzt entweder gelöst oder es tritt jetzt an anderen Stellen auf.

Da wäre jetzt die Frage an alle, die reproduzierbare Berechnungsabbrüche bei Routen hatten, ob das Problem auch bei ihnen weg ist.

Beim von Dir erwähnten Problem geht es um schlechte Lösungen von Routingproblemen, weil augenscheinlich irgendwelche Möglichkeiten ausgeschlossen werden, die zur besten Lösung gehören.

Da wäre die Frage, ob man das Problem lokalisieren kann. Z.B. indem man auf der nicht gefundenen besten Route Teilstücke routen läßt. Mit etwas Glück werden die meisten Teilstücke optimal geroutet und man kann irgendwelche Besonderheiten im Rest erkennen.

Weide

Die Routingprobleme scheinen mit der Karte von gestern gelöst zu sein. Regensburg - Düsseldorf und Düsseldorf/Eulerstraße (das waren meine Teststrecken) gehen wieder.

Routing allgemein: Erstelle ich eine Karte mit den Style-files von mkgmap (default), dann wird von Regensburg nach Reutlingen richtig geroutet (kürzere und schnellere Autobahnstrecke). Das Problem tritt mit der AIO auf. Ich verwende identischen Routingeinstellungen.

Setze ich einen Routenpunkt irgendwo zwischen Regensburg und Reutlingen, wird sogar eine B300 mit berücksichtigt und die Strecke wird um mehr als 50 km kürzer und mehr als 20 Minuten schneller.

Erklärbar ist es nicht ...

flux.

flux wrote:

Setze ich einen Routenpunkt irgendwo zwischen Regensburg und Reutlingen, wird sogar eine B300 mit berücksichtigt und die Strecke wird um mehr als 50 km kürzer und mehr als 20 Minuten schneller.

Erklärbar ist es nicht ...

Das ist ein wichtiger Hinweis! Es ist also nicht so, dass die Route nicht genommen wird, weil sie irrtümlich als nicht passierbar gilt. Sie scheidet also vermutlich aus, weil sie bei einer Vorprüfung durchgefallen ist.
Diese Vorprüfungen entscheiden erstmal, welche Wegstücke überhaupt in welchen Richtungen in Frage kommen. Wenn man da zuviel drin lässt, dann wird das Routing elend lahm.

Die B300 ist in der Mitte des Stücks "highway=trunk" und sonst "highway=primary". Wenn also nach irgendeinem Plausibilitätskriterium für die Stücke weitab von den Wegpunkten nur z.B. motorway und trunk berücksichtigt wird, dann wäre das eine Erklärung. Vielleicht ist da bei der Umsetzung in Garmindaten eine Besonderheit...

Weide

Wenn die B300 als Nicht-Autobahn ohne zusätzlichen Routenpunkt nicht gewählt wird, dann ist das ja auch erklärbar.

Warum aber beide Garmin mit der AIO von Regensburg über Nürnberg nach Reutlingen fahren und nicht die kürzere und schnellere Strecke über München wie mit der Karte ohne spezielles Stylefile, das erschließt sich mir nicht.

Und warum die AIO beim Setzen eines Routenpunktes auf der A8 Höhe Ulm nicht die Autobahn über München fährt sondern die B300 wählt und damit plötzlich die kürzeste und schnellste Strecke, das bleibt auch ein Geheimnis.

flux.

flux wrote:

Warum aber beide Garmin mit der AIO von Regensburg über Nürnberg nach Reutlingen fahren und nicht die kürzere und schnellere Strecke über München wie mit der Karte ohne spezielles Stylefile, das erschließt sich mir nicht.

Und warum die AIO beim Setzen eines Routenpunktes auf der A8 Höhe Ulm nicht die Autobahn über München fährt sondern die B300 wählt und damit plötzlich die kürzeste und schnellste Strecke, das bleibt auch ein Geheimnis.

Ja.
Wenn das bei jedem Stylefile passieren würde, dann könnte man vermuten, dass das ziemlich lange Stück bis München gar nicht erst geprüft wurde: weite Strecke , kaum Annäherung ans Ziel, kann nicht sein. Beim Ziel Ulm liegt München schon eher in der Nähe der Luftlinie. Aber die Abhängigkeit vom Style-File kann ich mir so nicht erklären.

Weide

Weide wrote:

Weide wrote:

In Düsseldorf tritt der Fehler mit der o.g. Karte auf der geraden 500m langen Strecke von
Start: Ecke Ulmenstraße/Weißenburgstraße
Ziel: Ecke Ulmenstraße/Wörthstraße
auf.
Vista HCx, Auto/Motorrad, kürzere Zeit, folge Straße, vermeide nichts
http://www.openstreetmap.org/?lat=51.24 … 31&zoom=17

Dieser Fehler ist in der heute morgen geholten Karte weg. Die anderen auch?

Weide

Kann ich bestätigen:
Die ständigen Abbrüche mit "Routenberech.-Fehler." in diesem Düsseldorfer Bereich sind mit der original AIO-Karte von 2010-02-18 verschwunden. Klasse!
Die letzte von mir getestete Version mit dem Fehler war 2010-02-15.
@master: Was hast Du denn geändert?

Leider gibt es aber bei dieser Karte (2010-02-18) jetzt ein neues Problem das vorher nicht vorhanden war:
Abbiege-Restriktionen werden völlig falsch interpretiert.

Beispiel Route in Cloudmade:
http://maps.cloudmade.com/?lat=51.25360 … ened_tab=1

Der Router des etrex VISTA HCx berechnet mit der AIO-Karte den Weg von Punkt A nach Punkt C mit einem Umweg nach rechts mit Wende an der nächsten Kreuzung.
Der direkte Weg über die Kreuzung wurde vom Router mit alten AIO-Karten problemlos gefunden. Mit der neuen Karte kann der Router die Kreuzung nicht mehr direkt überqueren.

Ursache kann die dort kartierte Abbiege-Restriktion sein.
Es handelt sich um eine Restriktion 'only_straight_on'. Diese Restriktion wird scheinbar fälschlich als 'no_*' interpretiert.
Was läuft da falsch? Wenn ich nicht irre, haben Restriktionen mit der alten AIO-Karte durchaus korrekt funktioniert.
@master: Was hat sich diesbezüglich geändert? Es wird jetzt scheinbar bei Restriktionen statt 'only_*' immer 'no_*' angenommen.
Das ist extrem kontraproduktiv.

Hier die Stelle mit dem OSM Restriction Analyzer:
http://osm.virtuelle-loipe.de/restricti … yers=B00TT
(Achtung: Es kann Minuten dauern, bis man die Restriktion tatsächlich sieht.)

Die BlueMap routet dort gerade aus drüber.

Interessant ist noch folgendes CloudeMade Routing quer über den Friedhof:

http://maps.cloudmade.com/?lat=51.25654 … ened_tab=1

Wenn man A und B vertauscht kann er überhaupt keine Route finden, da sollte man sich die
Einbahnstrassen nochmal genau anschauen. Ich habe da das kleine Stück von
der "Am Nordbahnhof" Schleife und der Johannstraße im Verdacht.

Edit: Habe den Südzugang mal mit motorcar=no getaggt. Fahrräder dürfen ja nicht rein, deshalb gehe ich
davon aus, dass Autos auch nicht rein dürfen. 😉

Chris

chris66 wrote:

Die BlueMap routet dort gerade aus drüber.

Natürlich, alle Karten routen hier richtig. Auch alte AIO. Nur genau die neue AIO von 2009-02-18 eben nicht!

chris66 wrote:

Interessant ist noch folgendes CloudeMade Routing quer über den Friedhof:

http://maps.cloudmade.com/?lat=51.25654 … ened_tab=1

Wenn man A und B vertauscht kann er überhaupt keine Route finden, da sollte man sich die
Einbahnstrassen nochmal genau anschauen.

Es ist allgemein bekannt, dass Cloudmade nicht korrekt routen kann. Restriktionen wurden sehr lange völlig falsch behandelt, z.Zt. werden Restriktionen gar nicht mehr beachtet. Aber es geht hier nicht um die Fähigkeiten von Cloudmade. Ich habe Cloudmade hier nur verwendet, um die Route darzustellen. Man kann ja hier leider keine Screenshots des etrex VISTA hochladen.

chris66 wrote:

Ich habe da das kleine Stück von
der "Am Nordbahnhof" Schleife und der Johannstraße im Verdacht.

Oh. Als ich die Gegend kartiert habe, ist mir gar kein Bahnhof aufgefallen. ;-)

Ach ja, Danke für das fixme http://www.openstreetmap.org/browse/changeset/3918377. Die Stelle war ein Fehler von mir!

geopia wrote:

Es ist allgemein bekannt, dass Cloudmade nicht korrekt routen kann.

Die beiden Routingfehler am Friedhof lagen an falschen Daten (oneway, service-Roads ohne access rights).

geopia wrote:

Man kann ja hier leider keine Screenshots des etrex VISTA hochladen.

Nicht direkt. Aber mit Garmins ximage und einem Dienst wie picr.de gehts.
Chris

chris66 wrote:

geopia wrote:

Es ist allgemein bekannt, dass Cloudmade nicht korrekt routen kann.

Die beiden Routingfehler am Friedhof lagen an falschen Daten (oneway, service-Roads ohne access rights).

Du hast recht. Selbstverständlich lagen genau diese von dir zitierten Routingfehler an den falschen Daten.

Die Diskussion von Ergebnissen des Cloudmade-Routers halte ich in diesem Kontext allerdings nicht für zielführend.
Die korrekte Behandlung von Abbiege-Restriktionen durch Router ist ein Trauerspiel.
Mir ist, trotz intensiver Suche, kein einziger WEB-basierter Router auf Basis von OSM-Daten bekannt, der in der Lage ist, korrekt mit den OSM-Abbiege-Restriktionen umzugehen! Gibt es einen solchen der das kann?

Aber das lenkt vom eigentlichen Thema ab:
Der von mir zitierte Routing-Fehler mit der AIO-Karte liegt nicht an falschen OSM-Daten. Oder sehe ich das falsch?
Die neueste AIO-Karte scheint die Bedeutung von 'only_*' zu invertieren. Kann das irgendjemand bestätigen oder bilde ich mir das nur ein? Mit diesem Verhalten wäre die AIO-Karte in Gegenden mit korrekt kartierten Restriktionen für das Routing nicht mehr zu gebrauchen.

Im Gensatz zu den mir bekannten web-basierten Routern ist der im etrex VISTA HCx eingebaute Router sehr wohl in der Lage, mit den Abbiege-Restriktionen aus OSM-Daten korrekt zu arbeiten. Die bisherigen AIO-Karten waren der Beweis dafür. Mit der aktuellen AIO-Karte (2009-02-18) ist das allerdings leider vorbei.

Wie sieht es denn in deiner Region mit den kartierten Abbiege-Restriktionen aus?
Sind dort überhaupt welche erfasst?
Welche Erfahrungen hast Du mit deinem mobilen Router im Live-Betrieb im Zusammenhang mit Restriktionen?

chris66 wrote:

geopia wrote:

Man kann ja hier leider keine Screenshots des etrex VISTA hochladen.

Nicht direkt. Aber mit Garmins ximage und einem Dienst wie picr.de gehts.
Chris

Mir ist schon klar, wie ich Screenshots machen kann und dass man auf irgendwelchen anderen Servern auch Daten hochladen und hier verlinken kann. Das will ich nicht.
Hier in diesem Forum geht das Hochladen leider nicht!
Deshalb der Notbehelf mit dem Cloudmade-Link

Interessant wären für mich Stylefiles (insbesondere 'lines'), mit denen das Routing auch so funktioniert, wie man es erwartet. Also bei schnellere Route die schnellere, bei kürzere Route die kürzere.

Mein Beispiel ist Regensburg - Reutlingen: die AIO routet über Nürnberg, 25 km weiter als über München und auch 10 Minuten länger als über München.

Computerteddy's Karte routet über München, noch immer nicht die schnellste, aber besser als über Nürnberg, am Rückweg aber über Würzburg!!! Mehr als 90 km Umweg und wesentlich längere Zeit.

Beide Karten routen über die B300 nach Reutlingen, wenn ich Höhe Ulm auf der A8 einen Routenpunkt setze. Da wird dann plötzlich die schnellste und auch kürzeste Route berechnet.

Verstehen muss man das nicht ...

Wer hat ein Stylefile, das korrekt routet?

Danke,

flux.

flux wrote:

Interessant wären für mich Stylefiles (insbesondere 'lines'), mit denen das Routing auch so funktioniert, wie man es erwartet. Also bei schnellere Route die schnellere, bei kürzere Route die kürzere.

Also die Router-Einstellungen 'Kürzeste Zeit' oder 'kürzeste Strecke' sind auch ein sehr interessantes Thema.
Der Router des etrex VISTA HCx liefert hier mit der AOI-Karte schon mal Ergebnisse, die überraschend sind: Es kommt vor, dass die Route für 'kürzeste Strecke' deutlich länger ist als die Route für 'Kürzeste Zeit'.
Hier sind die Ergebnisse in der Tat nicht so wie man es Wortsinne 'kürzeste' erwartet.
Die Ursache hierfür vermute ich aber im Algorithmus des Routers und eher nicht in der Karte.

Dann wäre es aber bei allen Karten gleich und das ist es nicht ... die falschen Ergebnisse liefern Vista HCx und Oregon 300 gleichermaßen.

flux.

flux wrote:

Dann wäre es aber bei allen Karten gleich und das ist es nicht ... die falschen Ergebnisse liefern Vista HCx und Oregon 300 gleichermaßen.

flux.

Na ja. Hinter beiden steckt derselbe Router? Ich halte das defintiv für einen Fehler des Routers. Ein Algorithmus, der bei Einstellung 'kürzest' etwas längeres liefert als sonst, ist kaputt. Das gilt unabhängig von den zugrunde liegenden Daten.

geopia wrote:

Wie sieht es denn in deiner Region mit den kartierten Abbiege-Restriktionen aus?
Sind dort überhaupt welche erfasst?
Welche Erfahrungen hast Du mit deinem mobilen Router im Live-Betrieb im Zusammenhang mit Restriktionen?

In "meiner" Stadt bin ich bisher mit einer einzigen Turn-Restriktion ausgekommen. 😉

Eine schönes Testgebiet ist die Stadt Hameln, dort gibt es duzende Restriktionen.

http://osm.virtuelle-loipe.de/restricti … yers=B00TT

Chris

chris66 wrote:

geopia wrote:

Wie sieht es denn in deiner Region mit den kartierten Abbiege-Restriktionen aus?
Sind dort überhaupt welche erfasst?
Welche Erfahrungen hast Du mit deinem mobilen Router im Live-Betrieb im Zusammenhang mit Restriktionen?

In "meiner" Stadt bin ich bisher mit einer einzigen Turn-Restriktion ausgekommen. 😉

Na ja. Es gibt halt Gebiete wo man fast keine Restriktionen braucht.

chris66 wrote:

Eine schönes Testgebiet ist die Stadt Hameln, dort gibt es duzende Restriktionen.

http://osm.virtuelle-loipe.de/restricti … yers=B00TT

Chris

Oh ja. Sehr interessante Gegend.

chris66 wrote:

Eine schönes Testgebiet ist die Stadt Hameln, dort gibt es duzende Restriktionen.

http://osm.virtuelle-loipe.de/restricti … yers=B00TT

Wenn man das genau untersucht, könnte man dort aber auch einige rausschmeissen, da sie sich allein schon durch die Einbahnstraßenregelung ergeben.

Christian

brogo wrote:

chris66 wrote:

Eine schönes Testgebiet ist die Stadt Hameln, dort gibt es duzende Restriktionen.

http://osm.virtuelle-loipe.de/restricti … yers=B00TT

Wenn man das genau untersucht, könnte man dort aber auch einige rausschmeissen, da sie sich allein schon durch die Einbahnstraßenregelung ergeben.

Christian

Konkretes Beispiel?

Also ich hab mal ein paar Routingprobleme gezielt debuggt. Ich hab dazu Mapsource verwendet in der Annahme, dass dort der gleiche Routingalgorithmus verwendet wird, wie auf den Geräten.

Probleme scheint es immer dann zu geben, wenn Kachelgrenzen ins Spiel kommen. Es scheint für das Garmin deutlich besser bewertet zu sein, wenn es auf der gleichen Kachel bleibt, statt von einer Kachel in die andere zu fahren und an anderer Stelle weider zurück.

Beispiel:

Weg 2
_________________________________________
| |

---

|---------------------------------------------------------|---------- Kachelgrenze

| |
A B
| |
| |
| |
| |
| |
| Weg 1 |
| ________________________________________|

Um von Punkt A zu Punkt B zu gelangen, wird das Garmin immer Weg 1 vorschlagen (sofern Weg 2 nicht im Überlappungsbereich der Kacheln liegt) und damit den längeren Weg wählen, weil er auf der selben Kachel liegt.
Komplizierter wird es, bei meherern Kachelübergängen. Meistens gewinnt die Route mit den wenigstens Kachelüberschreitungen.

Ich frag mich, wieso Garmin solche bescheuerten Algorithmen baut.

Wenn meine Erkenntnis korrekt ist, dann ist das Routing sowieso eher Glückssache und ist stark von der Kachelung der Daten abhängig. So weit ich weiß, verwendet Computerteddy ein festes Raster. Ich nehme den Tilesplitter und habe dabei ein dynamisches Raster.
Wenn einige von euch testen, dann ladet ihr bestimmt euer Testgebiet in dem ihr euch auskennt runter und müsst eventuell gar nicht kacheln. Dann sollten die Routen sogar ganz gut aussehen.

Kann meine Beobachtung bezüglich der Kachelgrenzen jemand bestätigen?

Grüße
Christoph

master wrote:

Probleme scheint es immer dann zu geben, wenn Kachelgrenzen ins Spiel kommen.

Das Gebiet, in dem bei mir die häufigen Abbrüche lagen, scheint von einer Kachelgrenze durchzogen zu sein.
Bei Experimenten mit von mir selbst gebauten Karten konnte ich auch eine Abhängigkeit von den Splittereinstellungen feststellen.
Eine unterschiedliche Heapgröße für Java führte bei ansonsten gleichen Einstellungen zu unterschiedlicher Kachelung und auch zu unterschiedlichen Routingergebnissen. Routen über eine Kachel-Grenze hinweg waren teilweise unmöglich oder wurden mit sehr seltsamen Umwegen berechnet.
Deshalb habe seinerzeit auch so hartnäckig nach deinen exakten Splittereinstellungen gefragt.

master wrote:

Ich frag mich, wieso Garmin solche bescheuerten Algorithmen baut.

Na ja, möglicherweise werden aber die Daten vom Splitter an den Kachel-Grenzen zerstört. Kann der Splitter z.B. mit Abbiege-Restriktionen über Kachel-Grenzen hinweg umgehen.

Ich stelle mir diesen Split-Vorgang extrem kompliziert vor.

master wrote:

Wenn meine Erkenntnis korrekt ist, dann ist das Routing sowieso eher Glückssache und ist stark von der Kachelung der Daten abhängig. So weit ich weiß, verwendet Computerteddy ein festes Raster. Ich nehme den Tilesplitter und habe dabei ein dynamisches Raster.
Wenn einige von euch testen, dann ladet ihr bestimmt euer Testgebiet in dem ihr euch auskennt runter ...

... was dann natürlich zu völlig anderen Ergebnissen führen kann. Bei meinen Tests habe ich mit Bedacht immer die Karte für ganz Deutschland erzeugt.

p.s.
Deine aktuellen original AIO-Karten (2020-02-18 und 2010-02-22) haben jetzt keine ständigen Routing-Abbrüche in dem betreffenden Gebiet mehr.
Allerdings sind die Karten jetzt wegen des Fehlers mit den Abbiege-Restriktionen mit 'restriction=only_*' in dem betreffenden Gebiet wieder nicht zu gebrauchen. Ich konnte den 'restriction=only_*'-Fehler inzwischen auch noch an anderen Stellen einwandfrei nachvollziehen. Dieser Fehler war vorher nicht enthalten. Was hast Du denn diesbezüglich geändert?

Ich habe eine gegenteilige Erfahrung gemacht: Je kleiner die mit dem Splitter erstellten Kacheln sind, desto besser ist das Routing.

--max-nodes=600000

bringt mir ein völlig korrektes Routing von Regensburg nach Reutlingen, schnellste Route ist die schnellste! Über die B300, die sonst nur mit Zwischenpunkt berechnet wird.

Das schaut sehr gut aus ...

flux.

Möglicherweise führen in dem Fall dann alle Routen über irgendwelche Kachelgrenzen, mit der Folge, dass er keine "falsche" Route mehr ausgibt, nur weil die zufällig gerade auf einer Kachel liegt.

Nein, ich nehme alles zurück ...

Das waren wohl atmosphärische Störungen, die mein Vista HCx da geritten haben. Heute routet das Vista HCx wieder genauso falsch wie die Tage zuvor.

Ausschalten gestern abend in der Freude, dass alles passt, anschalten heute und Ernüchterung. Die Einstellungen sind unverändert, definitiv.

flux.

Ich überlege, ob es sinnvoll sein könnte aus dem OSM-File zunächst alle Straßen zu extrahieren und diese in einen separaten Layer zu packen.
Die Kacheln könnten somit aufgrund der geringeren Daten größer werden. Vielleicht sollte ich auch ein festes Raster verwenden.

Punkte, Flächen und übrig gebliebene Linien könnte ich dann in einen anderen Layer packen.
Ich könnte mir vorstellen, dass das funktioniert, müsste aber ganz schön viel testen dazu.

Mal sehen, ob da was geht. Vielleicht findet ja auch noch jemand was anderes raus, was hier helfen könnte.

Viele Grüße!
Christoph

PS: Seh ich eigentlich irgendjemanden von euch zur FOSSGIS?

master wrote:

Ich überlege, ob es sinnvoll sein könnte aus dem OSM-File zunächst alle Straßen zu extrahieren und diese in einen separaten Layer zu packen.

Eine Trennung der Straßen von anderen Objekten ist wahrscheinlich eine gute Idee.

Man könnte aber auch noch einen Schritt weiter gehen und sämtliche für das Routing relevanten Elemente vollständig von den Elementen für die Darstellung der Karte trennen.

• Dabei würde eine dedizierter (optisch unsichtbarer) Layer ausschließlich Informationen zum Routing enthalten.
  
• Weitere (sichtbare) Layer würden dann zusätzlich die Darstellung der Straßen (und Flächen, ...) enthalten.
  

Dabei hätte man dann zwar in Summe viele Elemente (nämlich die Wege) doppelt, aber man hätte eine völlige Trennung zwischen der Routing-Informationen einerseits und der grafischen Darstellung andererseits.

Der Routing-Layer könnte dann mit viel weniger, möglicherweise sogar ohne, Kachelung auskommen.

Das hätte auch den Vorteil, dass man bei der grafischen Darstellung nicht mehr auf Einschränkungen bei der Definition der routing-spezifischen Eigenschaften Rücksicht nehmen müßte.

Sagt wie ihr das anpacken wollt (technisch, mit splitter/mkgmap) und ich kann mithelfen, testen, habe Zeit dazu und Interesse auch!

flux.

Ich habe auch bereits Beeinträchtigungen beim Routing über Kachelgrenzen hinweg festgestellt,
habe es aber meist auf schlecht verbundene Wege geschoben.

Nach welcher Methode trennt der Splitter eigentlich die Kacheln auf, dass mkgmap über die Grenze hinweg überhaupt routen kann?
Vielleicht liegt ja gerade darin das Problem, dass diese Trennung nicht wieder sauber zusammengefügt wird.

Walter

Probleme grundsätzlicher Art beim Routen über Kachelgrenzen kann ich nicht feststellen, lediglich in Einzelfällen eine längere Route, die einer kürzeren vorgezogen wird.

Ich kann von Flensburg korrekt nach Novigrad routen, ohne Fehler, Route ist ok, ca. 18 Kacheln werden durchfahren.
Ich kann von Regensburg nicht korrekt nach Reutlingen routen, Umweg und längere Zeit wird geroutet, ca. 5 Kacheln werden durchfahren.

Ich habe auch schon verschiedene --overlap=WERT im splitter verwendet, keine Änderung (default WERT = 2000).

flux.

geopia wrote:

master wrote:

Ich überlege, ob es sinnvoll sein könnte aus dem OSM-File zunächst alle Straßen zu extrahieren und diese in einen separaten Layer zu packen.

Eine Trennung der Straßen von anderen Objekten ist wahrscheinlich eine gute Idee.

Man könnte aber auch noch einen Schritt weiter gehen und sämtliche für das Routing relevanten Elemente vollständig von den Elementen für die Darstellung der Karte trennen.

• Dabei würde eine dedizierter (optisch unsichtbarer) Layer ausschließlich Informationen zum Routing enthalten.
  
• Weitere (sichtbare) Layer würden dann zusätzlich die Darstellung der Straßen (und Flächen, ...) enthalten.
  

Dabei hätte man dann zwar in Summe viele Elemente (nämlich die Wege) doppelt, aber man hätte eine völlige Trennung zwischen der Routing-Informationen einerseits und der grafischen Darstellung andererseits.

Der Routing-Layer könnte dann mit viel weniger, möglicherweise sogar ohne, Kachelung auskommen.

Das hätte auch den Vorteil, dass man bei der grafischen Darstellung nicht mehr auf Einschränkungen bei der Definition der routing-spezifischen Eigenschaften Rücksicht nehmen müßte.

Naja, das ist dann wohl doch keine so super gute Idee! Ich habe mal spaßenshalber das Europafile genommen und mit Osmosis alle highways inklusive Relationen extrahiert und in ein separates File geschrieben:

bzcat␣europe.osm.bz2␣|␣osmosis-0.34/bin/osmosis␣--rx␣-␣--b␣--tf␣accept-ways␣highway=*␣--un␣idTrackerType=BitSet␣--wx␣-␣|bzip2␣>␣europe_roads.osm.bz2

Der Größenvergleich der Files zeigt, dass die Straßendaten viel ausmachen:

europe.osm.bz2 : 2,9G
europe_roads.osm.bz2 : 1,4G

Nur aus Gründen der Darstellung quasi die 1,4G doppelt einzubauen, halte ich für ziemlich unklug. Im Übrigen dauert die Extraktion auch seine Zeit. Ich meine ich müsste natürlich nicht vorher extrahieren und könnte einfach die mkgmap-styles entsprechend anpassen, dass sie einmal nur die Straßen bauen und einmal dann den Rest, aber dann kann ich wieder keine unterschiedliche Kachelung verwenden.
Bei der Kachelung weiß ich eh gerade nicht, ob das überhaupt was bringt, denn die wird ziemlich ähnlich der jetzigen aussehen.

Zum Thema routing über Kachelgrenzen hab ich auch nen interessanten Thread auf der mkgmapliste gefunden:
http://www.mkgmap.org.uk/pipermail/mkgm … 03396.html

Allerdings hab ich noch nirgends ne Lösung des Problems gesehen.

Mal sehen, ob da noch was kommt...

Ach so - ich hätte noch was zum testen bzw. rausfinden.

Ich habe in meinen Styles im basemapstyle bei den lines für die Straßen folgendes stehen:

highway=motorway␣&␣(maxspeed>110)␣[0x01␣road_class=4␣road_speed=7␣resolution␣12]
highway=motorway␣&␣(maxspeed>90␣&␣maxspeed<111)␣[0x01␣road_class=4␣road_speed=6␣resolution␣12]
highway=motorway␣&␣(maxspeed>80␣&␣maxspeed<91)␣[0x01␣road_class=4␣road_speed=5␣resolution␣12]
highway=motorway␣&␣(maxspeed>60␣&␣maxspeed<81)␣[0x01␣road_class=4␣road_speed=4␣resolution␣12]
highway=motorway␣&␣(maxspeed>40␣&␣maxspeed<61)␣[0x01␣road_class=4␣road_speed=3␣resolution␣12]
highway=motorway␣&␣maxspeed<41␣[0x01␣road_class=4␣road_speed=3␣resolution␣12]
highway=motorway␣[0x01␣road_class=4␣road_speed=7␣resolution␣12]

Das Beispiel für motorways zeigt, wie ich prinzipiell für Straßen je nach gesetztem maxspeed unterschiedliche road_speeds vergebe.
Ob das wirklich so klappt weiß ich nicht mal hunderprozentig, da sie ja alle auf den selben Garmintyp gemappt werden.

Allerdings sehe ich hier auch ein Problem, was passiert, wenn im maxspeed-tag keine zahl sondern ein text steht? Es gibt da so Texte, wie "DE:urban" oder "variable" oder "unlimited" etc.
Schlägt der Vergleichstest dann fehl oder wird da einfach 0 angenommen (könnte eine Schlechtbewertung von manchen Autobahnabschnitten erklären) oder was passiert da eigentlich genau?

Hab leider nicht die Zeit das alles im Detail rauszufinden - bin über Hilfe sehr dankbar!
Man könnte eventuell auch mal auf der mkgmap-dev nachfragen...

Grüße!
Christoph

Ich habe mit deinem Stylefile (lines) und mkgmap zwei Karten aus der germany.osm.bz erstellt.

Karte 1: Splitter mit --max-nodes=1900000 (mehr geht nicht) --> 32 Kacheln
mkgmap nur mit dem Stylefile lines (points und polygons vorher gelöscht) gestartet
Teststrecke Regensburg - Reutlingen geht über Nürnberg, nicht die schnellste und nicht die kürzeste Strecke, wie bisher also fehlerhafte Berechnung

Karte 2: Splitter mit --max-nodes=400000 --> 146 Kacheln
mkgmap wie oben
Teststrecke wird wie oben berechnet

Dann habe ich 2 Karten mit dem Default-Stylefile von mkgmap aus der germany.osm.bz2 erstellt.

Karte 1: alles wie oben, nur das Original-Stylefile
Routing Regensburg - Reutlingen geht über München, die kürzeste und schnellste Strecke per Autobahn (nur die Route über die B300 wäre noch kürzer und schneller, sind aber ca. 60 km Bundesstraße)

Karte 2: alles wie oben, nur das Original-Stylefile
Routing Regensburg - Reutlingen geht über München ...

Es muss also am Stylefile bzw. der Auswertung der Geschwindigkeit in der road_class liegen, die ja im Original komplett fehlt.

Soweit meine bisherigen Tests.

Das Routen mit einem Zwischenpunkt auf der A8 Höhe Ulm klappt mit allen 4 Karten korrekt, Regensburg - Reutlingen über BAB, B300, BAB = kürzeste und schnellste Strecke.

Getestet wurde auf dem Vista HCx (Kürzere Zeit, PKW, beste Route) und auf dem Oregon 300 (Schnellere Strecke). Die Ergebnisse auf beiden Geräten mit allen 4 Karten sind übereinstimmend.

flux.

Es muss also am Stylefile bzw. der Auswertung der Geschwindigkeit in der road_class liegen, die ja im Original komplett fehlt.

nur wenn --ignore-max-speeds gesetzt ist, sonst nimmt er eine Default-Logik.

Chris

Damit ich es richtig verstehe: Der Default-Style von mkgmap (/mkgmap-r*/resources/styles/default/) hat keine Geschwindigkeitsangaben in der Datei lines wie sie Christoph hat. Diesen Default-Style nehme ich als Original-Style zum Bauen der Karten und vergleiche die Ergebnisse mit der Karte mit Christoph's Style.

Die Original-Karte routet annähernd korrekt, die mit Christoph's Style erstellte nicht.

Die Default-Logik scheint also richtiger zu rechnen als die "getunte" ...

--ignore-maxspeeds macht dann was? Vielleicht wird ja dann sogar noch genauer geroutet?

flux.

Zwischenzeitlich habe ich zwei Karten mit dem Original-Style von mkgmap (Version r1584) erstellt (Splitter mit --max-nodes=400000, um viele kleine Kacheln zu erhalten und zu schauen, ob sich ein Unterschied zu großen Kacheln ergibt).

Karte 1: --ignore-maxspeeds
Karte 2: ohne --ignore-maxspeeds

Karte 1 berechnet Regensburg - Reutlingen über München, wie bisher zweitschnellste und zweitkürzeste Strecke (Vista HCx --> Kürzere Zeit, Auto/Motorrad, keine Vermeide-Optionen), Reutlingen - Regensburg wird über die B300 berechnet, schnellste und kürzeste Strecke

Karte 2 identisch

Karte 1 bricht Berechnung Regensburg - Freilassing mit Routenberechnungsfehler ab, Karte 2 berechnet korrekt.

Wird "Vermeide Kehrtwenden" aktiviert berechnen beide Karten von Reutlingen nach Regensburg über Würzburg (100 km länger als ohne "Vermeide Kehrtwenden").

Mit beiden Karten ist aufgrund der hohen Kachelzahl (146 Kacheln) die Suche nach Städten nicht mehr möglich, das Vista HCx schaltet nach ca. 4 Sekunden nach Beginn der Suche ab.

Heute werde ich diese Karte noch mit 32 Kacheln erstellen und dann das ganze Prozedere (einmal 146, einmal 32 Kacheln, einmal mit und einmal ohne --ignore-maxspeeds) noch einmal mit dem Stylefile von Christoph.

Dann weiß ich mehr.

flux.

Hallo,

bin auch relativ neu bei OSM. Erst einmal danke eine Super Arbeit die hier geleistet wird.
Ich verwende die AIO Europa auf meinem Oregon 300 und mir ist jetzt schon öfters aufgefallen, dass Brücken nicht sichtbar sind. Laut OSM.org sind die Brücken auch in der Karte.

Ist das Absicht, ein Fehler oder einfach noch nicht implementiert ? Danke für die Info.

Gruß
wmann

Hi,

ich bin gar nicht begeistert! Habe alle .exe Dateien der Europa geladen, installiert, habe jetzt in MapSource ein haufen Einträge, aber praktisch nur eine Karte, die anderen mit Linien usw. Aber, was am schwersten wiegt, ich kann die Karten nicht mehr deinstallieren! Es gibt keinen Eintrag unter Software! Ist offensichtlich unsauber programmiert. Wie bekomme ich diese wieder von meinem Computer weg!?

Gruß,
stevebiker

Hi stevebiker,

so ganz kann ich das noch nicht nachvollziehen, aber um die Karten zu deinstallieren lädst du dir MapSetToolkit runter.
Findest du unter http://cypherman1.googlepages.com/

Die Exe Datei einfach in einen Ordner kopieren und starten. Wird auch nicht in der Windows Reg eingetragen.
Dann unter Mapset installed die Karten auswählen und uninstall - fertig.

Gruß
mapfriend70

P.S. Ich denke du solltest dich noch ein wenig mit der Sache beschäftigen, dann wirst du sehen, dass OSM und Co. ne super Sache ist.

Hi mapfriend70,

danke Dir für die antwort. Mit OSM habe ich mich schon auseinandergesetzt, auch durch aktives Loggen. Die All in One habe ich auf eine Empfehlung aus dem Naviboard installiert. Hatte aber keine Zeit mich damit näher zu befassen, die Erklärung auf der Homepage ist meiner Meinung nach nicht außreichend. Bisher hatte ich mit den Karten von openmtbmap gute Erfahrungen, auch das Kartenbild hat mir besser gefallen. Momentan habe ich für langwierige Konfigurationsaktionen für OSM Karten weder die Zeit, noch die Lust, noch dazu, wo ich jetzt vermehrt mit einem Lowrance Safari neue Erfahrungen sammle.

Gruß, stevebiker.

Hallo,
ich habe heute am 26.2 die aktuelle Karte heruntergeladen ,beim Test im e trex habe ich festgestellt ,wenn man irgendeinen Punkt der unbelegt ist anklickt so wird der als Land angezeigt .Will man also einen Punkt markieren um ihn später zu erfassen ,so muss man ihn erst speichern -etwas umständlich -War früher nicht so.Kann man die freien Stellen nicht unbelegt lassen?

geopia wrote:

master wrote:

Probleme scheint es immer dann zu geben, wenn Kachelgrenzen ins Spiel kommen.

Das Gebiet, in dem bei mir die häufigen Abbrüche lagen, scheint von einer Kachelgrenze durchzogen zu sein.
Bei Experimenten mit von mir selbst gebauten Karten konnte ich auch eine Abhängigkeit von den Splittereinstellungen feststellen.
Eine unterschiedliche Heapgröße für Java führte bei ansonsten gleichen Einstellungen zu unterschiedlicher Kachelung und auch zu unterschiedlichen Routingergebnissen. Routen über eine Kachel-Grenze hinweg waren teilweise unmöglich oder wurden mit sehr seltsamen Umwegen berechnet.

Hmm, wieso gibt es überhaupt die Meldung "Routenberechnungsfehler". Das bedeutet doch, dass das Verfahren zu einem Fehler in der Lage ist und den auch noch erkennen kann!

Es gibt einen solchen Routing-Algorithmus. Der arbeitet mit Entfernungsschätzungen. Das Ergebnis ist exakt, aber die Schätzungen dürfen dann auf keinen Fall größer sein, als die wirkliche Entfernung. Als Schätzung kann man z.B. die Luftlinienentfernung nehmen, die kann nicht größer sein als die wirkliche Entfernung. Bessere Schätzungen würden das Verfahren aber erheblich beschleunigen und -- vielleicht noch wichtiger -- den Speicherhunger vermindern.

Vielleicht enthalten die Kacheln bislang unidentifizierte Daten für eine solche bessere Schätzung -- sowas in der Art "von unten nach oben mindestens 18,3km" usw.. Wenn diese Daten nicht stimmen, dann würden die beschriebenen Effekte auftreten. Routenberechnungsfehler, wenn die Schätzwerte größer sind als die realen Werte; lustige Umwege, wenn die Zahlen nicht korrekt sind; Routen mit möglichst wenig Kacheln, wenn überall dasselbe als Schätzwert eingetragen ist.

Nur so ne Idee...

Weide

Ich habe inzwischen mit der mkgmap-Option --ignore-maxspeeds und dem Original-Stylefile keinerlei Probleme mehr und eine korrekte Routenberechnung.

Mehr brauchts für mich nicht, die Fehlermeldung scheint sowieso niemand erklären zu können ...

flux.

Ich wollte mal eine Rückmeldung geben über die All-In-One-Garmin-Map Deutschland auf einem Nüvi 255t. Das Nüvi hab ich ganz frisch und hatte vorher auch noch kein Navi. Mit der OSMkarte fahre ich jetzt seit 3 Tagen.

Erster Eindruck (in Berlin):
- Adresseingabe funktioniert nicht.
- Die Ansagen beim Routing kommen teilweise reichlich früh. Nach "links abbiegen" kommen noch 3 Straßen vorher.
- Ziel auf der falschen Seite angesagt.
- Keine Maxspeed Angaben. (Oder sind das die Zahlen, die manchmal in Klammern hinter dem Straßennamen stehen? Mit den Garminkarten bekomme ich ein Verkehrsschild mit der Höchstgeschwindigkeit auf dem Display links neben der Straße angezeigt.)
- Die Namen der Querstraßen beim Vorbeifahren werden fast nie angezeigt. (Habe das Gefühl, dass nur kleine Wege von Gartenkolonien oder ähnlich angezeigt werden.)
- Neuberechnung im Kreisverkehr obwohl vorher korrekt angesagt wurde.

Gut gefallen mir die ein- oder ausblendbaren Höhenlinien und dass ich z.B. alle Wanderwege im Elbsandsteingebirge angezeigt bekomme, die sonst erst auf kommerziellen Karten 1:15000 auftauchen.

Also grundsätzlich kann man schon gut damit fahren. Besten Dank für die Arbeit.
Trotzdem wäre es natürlich noch besser wenn die obigen Probleme auch noch gelöst werden könnten.

Ich konnte übrigens die Europakarte nur feherhaft herunterladen. Ich habe nur so einen Surfstick mit 5GB Trafficlimit im Monat. Danach wirds langsam. Die Europakarte hatte ich bei einer Freundin mit DSL heruntergeladen und beim Auspacken zu Hause bekam ich nur Fehlermeldungen und Abbrüche. Die Deutschlandkarte hab ich mit meinem Surfstick und "Downloader für X" (ein Downloadmanager für Linux) zwei mal heruntergeladen. Die erste Datei konnte auch nicht entpackt werden.

Hm... Das mit den Höchstgeschwindigkeiten ist interessant. Ich hatte gedacht, dass mkgmap genau diese als road_speed in die Garmin-Karte einträgt. Aber anscheinend haben die Original-Garmin-Karten da noch eine andere Information.
Vielleicht erklärt das auch, warum diese road_speed Einträge scheinbar zu einem falschen Routing führen - oder zumindest, warum es sich durch --ignore-maxspeeds beheben lässt. Möglicherweise ist die Umsetzung maxspeed => road_speed => Höchstgeschwindigkeit in der Garmin-Karte bei mkgmap fehlerhaft.

Ach ja, die Zahlen in Klammern müssten tatsächlich die Höchstgeschwindigkeiten sein.

Ich habe leider (noch) überhaupt keine Ahnung wo das Nüvi sich welche Information her holt. Falls mir einer auf die Sprünge helfen kann könnte ich da mal nachsehen. Oder auch andersherum. Ich kann auch jemand eine Datei vom Nüvi senden im sie zu analysieren. Wäre dann auch interessant welche Datei.
Zum öffnen von komischen Formaten wäre es vielleicht noch wichtig, dass ich kein Windows besitze und ausschließlich Linux verwende.

Ich wurde gerade in einen Zaun geroutet! Auf dem Weg ist ein Node mit barrier=gate getagt. Zwei Meter hohes Tor nur für Firma zugänglich. Im Wiki steht: Standardmäßig ist access=no ist impliziert, deshalb sollten Zugangsberechtigungen für das Element vergeben werden. Weitere Zugangsberechigungen stehen da aber nicht in dem Node.

mkgmap wertet gewisse TAGs für's routing aus (z.B. bicycle=*, oneway=*, usw.), vielleicht ja auch maxspeed.
Leider wird von den Programmierern von mkgmap nur sehr oberflächlich dokumentiert, was da eigentlich programmiert wurde.
Oder ich habe diese Dokumentation einfach noch nicht gefunden.
Vermutlich muss man sich den Sourcecode herunterladen und durchforsten.

Walter

Schon wieder komisch gerouted worden.
http://www.openstreetmap.org/?lat=52.51 … rs=B000FTF
Ich kam von der Mühlsamstr., links von der Petersburger Str. in Fahrtrichtung Petersburger Straße und sollte letztendlich links auf die Petersburger Str. abbiegen. Nur sollte ich nicht einfach links rum fahren sonder rechts auf die Petersburger, um den Bersarinplatz und dann geradeaus auf der Petersburger (an der Mühsamstr. vorbei).
Warum soll ich so einen Schlenker fahren, wenn ich doch einfach links abbiegen kann? Ich habe keine Restriction oder so gefunden an der Kreuzung, die das Linksabbiegen verbieten würde.

Peter Maiwald wrote:

Schon wieder komisch gerouted worden.
http://www.openstreetmap.org/?lat=52.51 … rs=B000FTF
Ich kam von der Mühlsamstr., links von der Petersburger Str. in Fahrtrichtung Petersburger Straße und sollte letztendlich links auf die Petersburger Str. abbiegen. Nur sollte ich nicht einfach links rum fahren sonder rechts auf die Petersburger, um den Bersarinplatz und dann geradeaus auf der Petersburger (an der Mühsamstr. vorbei).
Warum soll ich so einen Schlenker fahren, wenn ich doch einfach links abbiegen kann? Ich habe keine Restriction oder so gefunden an der Kreuzung, die das Linksabbiegen verbieten würde.

Wer weiß schon genau, wie der Routing-Algorithmus der jeweiligen Firmware funktioniert? Vielleicht verwendet dieser die erstbeste Petersburger Straße die er findet und diese ist nunmal eine Einbahnstraße. Zwar erstmal weg vom Ziel, aber eine weitere Verfolgung bringt ja dann bald die Möglichkeit der Umkehr, weswegen der Algorithmus sich so entscheidet. Ist nur so ein Gedanke. Ob man (anspruchsvolle) Restriktionen überhaupt im Style-File für die Kartenerzeugung konfigurieren könnte, sei dahingestellt.

Peter Maiwald wrote:

Ich wurde gerade in einen Zaun geroutet! Auf dem Weg ist ein Node mit barrier=gate getagt. Zwei Meter hohes Tor nur für Firma zugänglich. Im Wiki steht: Standardmäßig ist access=no ist impliziert, deshalb sollten Zugangsberechtigungen für das Element vergeben werden. Weitere Zugangsberechigungen stehen da aber nicht in dem Node.

Um das zu erreichen gibt es die --link-pois-to-ways Option[1] bei mkgmap, zusätzlich muss man
es im Style-file triggern:

barrier=gate {add access=yes; add motorcar=no} [0x7000 resolution 24]

Durch access wird die --link-pois-to-ways Option getriggert und durch add motorcar=no
das Autorouting über die Schranke vermieden.

Chris

[1] --link-pois-to-ways
If this option is enabled, POIs that are situated at a point
in a way will be associated with that way and may modify the
way's properties. Currently supported are POIs that restrict
access (e.g. bollards). Their access restrictions are applied
to a small region of the way near the POI.

Verstehe mal wieder nicht viel. mkgmap habe ich nicht installiert.
Ich verwende die fertige All-In-One-Garmin-Map Deutschland. Nur heruntergeladen, extrahiert und auf microSD geschoben. Fertig.
Ich dachte die Karte ist für Routing?

Die All in One Garmin Map wird mit einem Programm namens mkgmap aus OpenStreetMap-Daten erstellt. mkgmap nimmt diese Daten und wandelt sie in das Garmin-Format um. Das Endergebnis ist dann eine Garmin-Karte. Das alles passiert aber nicht auf deinen Rechner (es sei denn, du würdest mkgmap installieren und direkt die OpenStreetMap z.B. von der Geofabrik runterladen), sondern auf einem Server. Bei deiner Vorgehensweise lädst du nur das fertige Endprodukt, also die fertige Garmin-Karte herunter - deshalb dürften dir die Optionen von mkgmap nicht viel sagen.

mkgmap kann routingfähige Garmin-Karten erzeugen, wenn man die dafür nötige Option mit auswählt. Genau das wird bei der Herstellung der All in One Garmin Map gemacht, d.h. die fertige Karte, die du herunterlädst, ist routingfähig. Allerdings ist die Routingfunktion der Garmin-Geräte nicht dokumentiert und Details über das Routing nicht bekannt - die Entwickler von mkgmap mussten also selbst ausprobieren, wie sie routingfähige Karten basteln können. Deshalb sind die Karten nicht "perfekt" an die Routingfumktion der Garmin-Geräte angepasst, was zu Problemen beim Routing führen kann.

... und deshalb macht es Sinn, verschiedene Karten (AIO, Computerteddy, Lambertus, eigene) zu testen, denn da kann es doch Unterschiede im Routing geben.

flux.

Konkretisierung unkorrekter Ansagen beim nüvi 255t und aio Deutschland:
Die Vorankündigung zum Abbiegen kommt mit den Garminkarten bei 350m und bei den OSM-Karten bei 750m!
Der Hinweis abzubiegen kommt mit Garminkarten bei 70m und mit OSM bei 350m.

Und die Annäherungsalarme (so heißt es im Etrex Vista HCx) kannst du nicht individuell einstellen?

flux.

flux wrote:

... und deshalb macht es Sinn, verschiedene Karten (AIO, Computerteddy, Lambertus, eigene) zu testen, denn da kann es doch Unterschiede im Routing geben.

flux.

Ich dachte, Computerteddy kann noch kein Routing?

Hat sich das zwischenzeitlich geändert?

flux wrote:

Und die Annäherungsalarme (so heißt es im Etrex Vista HCx) kannst du nicht individuell einstellen?

flux.

Ich habe einen Menüpunkt Annäherungsalarme gefunden. Da kann ich aber bloß einen Haken setzen bei "Garmin-Gefahrenzonen". Und im Untermenü kann man einstellen ob man mit einzelnem Ton oder dauerhaftem Ton gewarnt werden will.
Beim Fahren mit den Garminkarten funktionieren die Ansagen ja bei 350 und 70 Metern.

Hallo!
Ich habe probleme, die Europakarte (vom 11.03.2010) auf meinem Etrex Legend HCX zum Laufen zu bringen. Das Einlesen der Karte bricht immer bei 50% ab. Ich hatte es schon mit mehreren älteren Versionen probiert, immer wieder kam es zum Abbruch.
Die Deutschlandkarte läuft ohne Probleme.
Der Etrex hat eine Speicherkarte mit 4 GB.
Hat jemand eine Idee, was ich tun könnte?
Viele Grüße
Frank

Frank23germany wrote:

Hallo!
Ich habe probleme, die Europakarte (vom 11.03.2010) auf meinem Etrex Legend HCX zum Laufen zu bringen. Das Einlesen der Karte bricht immer bei 50% ab. Ich hatte es schon mit mehreren älteren Versionen probiert, immer wieder kam es zum Abbruch.
Die Deutschlandkarte läuft ohne Probleme.
Der Etrex hat eine Speicherkarte mit 4 GB.
Hat jemand eine Idee, was ich tun könnte?
Viele Grüße
Frank

Hat das Etrex eine aktuelle Firmware? Mit meinem GPSMap hatte ich Probleme, nachdem die Europaversionen über 2GByte gewachsen waren, bis ich die Firmware geupdated habe.

Baßtölpel

Hi,

Frank23germany wrote:

Hallo!
Ich habe probleme, die Europakarte (vom 11.03.2010) ...

Hmm, die von heute sehe ich nicht.
Ich sehe da nur die von gestern (Last-Modified: Wed, 10 Mar 2010 14:34:05 GMT)
Aber spielt ja keine Rolle.

Frank23germany wrote:

... auf meinem Etrex Legend HCX zum Laufen zu bringen. Das Einlesen der Karte bricht immer bei 50% ab. Ich hatte es schon mit mehreren älteren Versionen probiert, immer wieder kam es zum Abbruch.
Die Deutschlandkarte läuft ohne Probleme.
Der Etrex hat eine Speicherkarte mit 4 GB.

Das ist vielleicht die 2GB-Grenze für die Dateigröße -- die gilt auch in einigen Geräten die mit 4GB Plattengröße klarkommen. Hat bei Dir schonmal eine Karte mit über 2GB funktioniert? Wenn nein, ist es vielleicht diese Grenze und dann brauchst Du evtl. ein Firmware-Update.
Die Firmware-Version kann man mit:
Menü, Menü, "Einstellung", "System", Menü, "Softwareversion"
herausbekommen. Wenn Du die Softwareversion hier schreibst, dann kann vermutlich irgendein Legend-Besitzer sagen, ob das damit gehen sollte.

MfG
Weide

Hi,

Weide wrote:

...
Das ist vielleicht die 2GB-Grenze für die Dateigröße -- die gilt auch in einigen Geräten die mit 4GB Plattengröße klarkommen. Hat bei Dir schonmal eine Karte mit über 2GB funktioniert? Wenn nein, ist es vielleicht diese Grenze und dann brauchst Du evtl. ein Firmware-Update.
Die Firmware-Version kann man mit:
Menü, Menü, "Einstellung", "System", Menü, "Softwareversion"
herausbekommen. Wenn Du die Softwareversion hier schreibst, dann kann vermutlich irgendein Legend-Besitzer sagen, ob das damit gehen sollte.

Ich hatte noch nie eine Karte mit über 2GB laufen. Meine Softwareversion ist 2.70 und die GPS-SW-Version 2.60. Wie ich hier [1] gesehen habe, ist das nicht gerade die aktuellste Version. Ich werde mal ein Update machen und dann hier vom Erfolg/Misserfolg berichten.
Erstmal besten Dank für den Hinweis.

Viele Grüße

Frank

[1] http://www.tramsoft.ch/gps/garmin_etrex … rades.html

Frank23germany wrote:

...
Wie ich hier [1] gesehen habe, ist das nicht gerade die aktuellste Version. Ich werde mal ein Update machen und dann hier vom Erfolg/Misserfolg berichten.

Hallo!
Ein Update der Firmware auf 3.20 hat geholfen. Jetzt kann ich die Europakarte benutzen. Vielen Dank für eure Hinweise.

Viele Grüße

Frank

Was heißt "benutzen"?

Kannst du mit der Europa-Karte Orte/Adressen suchen?

Auf meinem Vista HCx geht das nicht, das Gerät schaltet dann nach ca. 10 Sekunden Suche ohne Vorwarnung einfach ab ... mit der Karte kann ich Ziele suchen, aber eine Suche per "Finde" geht nicht!

flux.

Hallo

Ich habe die All in one Karten auch getestet .

All in one Garmin Map funktioniert bei meinem Oregon 400 t sehr gut :http://forum.openstreetmap.org/img/smilies/smile.png
Routing geht auch gut aber mit seltenen Fehlern .

Die All in one Europa Map ( getestet mit Version vom 3. Und 7 März ) hat aber einige Fehler und was mich sehr stört :
es fehlen viele Strassen und vorallem die Wander-Wege/Pfade .

Aber in der OSM , wie ich sie auf meinem MAC sehe , sind diese Strassen und Wege vorhanden , also schon erfasst .
Das fällt mir insbesondere , aber nicht nur , auf Sardinien ( Italien ) auf .

Sardinien und Korsika sehen teilweise blau aus oder wo das Meer ist braun aus .

Außerdem ist mitten in Österreich/Kernten ein Meer .

Hallo,

kann nicht klagen. Im Gegenteil.

Deine Karte hat bei mir ordentlich eingeschlagen. Werde sie nächsten Monat auch für eine Mittelmeerkreuzfahrt benutzen.

Habe jedoch zwei (mehr kuriose) Fehler gefunden:

Tile 63240377, Grundfarbe ist "Land" statt Meer.
Tile 63240510, Grundfarbe ist "Meer" statt Land.

Benutze die neueste Ausgabe von Mapsource.

Gibt es eine Lösung?

Viele Grüße aus "de Palz",

Euer Pälzer

flux wrote:

Was heißt "benutzen"?

Kannst du mit der Europa-Karte Orte/Adressen suchen?

Auf meinem Vista HCx geht das nicht, das Gerät schaltet dann nach ca. 10 Sekunden Suche ohne Vorwarnung einfach ab ... mit der Karte kann ich Ziele suchen, aber eine Suche per "Finde" geht nicht!

flux.

Das Problem mit dem Abschalten kenne ich auch. Das lässt sich aber umgehen. Nach "Finden -> Städte/Orte" wird ja zunächst eine Liste der Orte in der Umgebung angezeigt. Mit der Menü-Taste kann dann in der Liste gesucht werden. Der Absturz tritt nur bei "Finden nach Namen" auf. Mit "Nächstgelegene mit..." kann man gut suchen.
Wenn der zu findende Ort weiter weg ist, dann suche ich mit mit "Ausgangspunkt ändern" einen Ort in der Nähe vom Ziel und suche dann mit "Nächstgelegene mit...".
Die Suche nach Adressen ist bei meinem Legend HCx völlig unbrauchbar oder ich bin noch nicht hinter die Logik gestiegen.

Viele Grüße

Frank

Ist für mich keine Option, da man ja einen Ort in der Nähe wissen muss. Wenn ich

Schwarzenbruck

suche, dann muss ich erst wissen, wo denn das liegen könnte!?

Ich nehme inzwischen den Ausschnitt von Europa, den ich brauche, Deutschland gesamt plus Österreich, Ungarn, Schweiz, Norditalien und Kroatien. Das ist eine Karte mit unter 1 GB Größe und damit voll nutzbar (inkl. Orts-/Adresssuche).

Alle Karten über 1 GB oder mehr als 100 Einzelimages sind nicht mehr brauchbar auf dem Vista HCx.

Danke für die Antwort,

flux.

flux wrote:

Ist für mich keine Option, da man ja einen Ort in der Nähe wissen muss. Wenn ich

Schwarzenbruck

suche, dann muss ich erst wissen, wo denn das liegen könnte!?

Ich nehme inzwischen den Ausschnitt von Europa, den ich brauche, Deutschland gesamt plus Österreich, Ungarn, Schweiz, Norditalien und Kroatien. Das ist eine Karte mit unter 1 GB Größe und damit voll nutzbar (inkl. Orts-/Adresssuche).

Alle Karten über 1 GB oder mehr als 100 Einzelimages sind nicht mehr brauchbar auf dem Vista HCx.

Danke für die Antwort,

flux.

Benutzt du eine vorgefertigte Karte oder baust du dir selber eine zusammen?
Anscheinend ist also die schlecht funktionierende Suche für Adressen keine Schwäche des HCx sondern der Karte.

Viele Grüße

Frank

Ich erstelle die Karten selber.

Die von Lambertus wären Klasse, allerdings nimmt er als Namen die englischen Namen, was hier bei uns nicht immer Sinn macht (Nouremberg statt Nürnberg, Munich statt München).

Damit wird eine Suche oft unmöglich. Leider.

flux.

Hallo zusammen,

Rosenheim im Meer ?

bei meinen letzten beiden downloads von http://dev.openstreetmap.de/aio/germany … pp.img.bz2 habe ich ein Darstellungsproblem unter Garmin XT 5 auf Nokia S60:

Im Südosten von München liegt ein großen Meer.

Ist das ein Karten oder ein Darstellungsproblem unter Garmin XT?

Gruß

mrtango

Problem der verwendeten mkgmap-Version. Ist mit späteren Versionen (wenn von Christoph verwendet) von mkgmap wieder verschwunden.

flux.

Wieder kaputtes Routing mit der aio germany und dem Nüvi 255t:

Auf diesem Kartenabschnitt http://www.openstreetmap.org/?lat=52.55 … rs=B000FTF sollte ich von links unten Streustr. in die Gustav-Adolf-Str. und weiter über den Kreisverkehr rechts oben auf der Gustav-Adolf-Str. bleiben.
Noch auf der Streustr. sagte das Nüvi: rechts abbiegen und in den Kreisverkehr einfahren. In 450m Entfernung vom Kreisverkehr (noch vor der Langhansstr.) bekam ich die Anweisung : In den Kreisverkehr einfahren.
Angezeigt wurde der Weg durch den Kreisverkehr richtig. Also die 2. Abfahrt wieder abfahren. Auf dem Abbiegehinweis oben auf dem Navi stand aber dass ich die erste Abfahrt nehmen soll und angesagt wurde dies auch.
Ich nahm dann aber die richtige 2. Abfahrt und es kam auch nicht zu einer Neuberechnung der Route.

Im Südosten von München liegt ein großen Meer.

Ist das ein Karten oder ein Darstellungsproblem unter Garmin XT?

Hi
Das kommt mir bekannt vor .
Aber nicht in Deutschland , sondern in den Urlaubsländern Österreich Korsika usw

Gruß

So, Hallo miteinander.

Ich bin gerade ganz neu in das Thema reingeplatzt, hatte bisher wenig Zeit zum Lesen aller Beiträge, war erfolglos bei der Google Suche und hoffe, dass meine Frage nicht bereits 10x beantwortet wurde.

Ich habe mir für meinen USA-Urlaub in den USA ein Nüvi 1200 gekauft. Bevor ich die (auch nicht immer fehlerfreien) Garmin-Karten für DE kaufe, möchte ich lieber die Openstreetmap-Karten nutzen.

Ich habe mir das aktuelle Image von hier:
http://wiki.openstreetmap.org/wiki/DE:A … Garmin_Map
und zwar die Karte Deutschland komplett (gmapsupp.img.bz2)

geladen, entpackt, auf die SD-karte kopiert und ins Nüvi geschoben. Die Karte wird geladen - klasse!. Ich kann mir Deutschland auch ansehen. Jedoch kann ich bei der Adresseingabe nur USA, Puerto Rico und die Virgin Island wählen, also die Länder der vorinstallierten Karten.

Screenshots habe ich unter folgender URL abgelegt:
http://my.pogoplug.com/share/tlTgWoCcQRrObY8zF9_fFw/

Mein Frage: Kann mir jemand beantworten, wie ich bei der Adresseingabe auch die deutschen Adressen angezeigt bekomme?

Ich würde mich sehr freuen, wenns dazu Hilfe gäbe. Wenn ich wieder in Deutschland bin, stehe ich dem Kartenentwickler auch gerne mit diesem Nüvi-Exoten (1200 gibts wohl nur in US) für Tests zur Verfügung.

Liebe Grüße
Benjamin

Benjamin D wrote:

Ich habe mir für meinen USA-Urlaub in den USA ein Nüvi 1200 gekauft. Bevor ich die (auch nicht immer fehlerfreien) Garmin-Karten für DE kaufe, möchte ich lieber die Openstreetmap-Karten nutzen.

Die Adresssuche scheint auf den Nüvis nicht zu funktionieren. Zumindest bei meinem Nüvi 255t. Ich kann zwar die Stadt, die Hausnummer, und die Straße eingeben (in der Reihenfolge) und die Straßen oder Stadt wird auch gefunden. Aber letzten Endes bekomme ich immer Eintrag nicht gefunden.

Überall Meer...

habe mir mal wieder aktuelle Karten (AiO Deutschland 16.03.10/17.03.10) gezogen und festgestellt, dass Flensburg, Kiel und Umgebung im Meer versunken sind. Bin gleich mal zur Tür raus, nee, die Füße blieben trocken ;-)

Ist schon bekannt, was die fehlerhafte Meeresdarstellung verursacht? Fehlerhafte mkgmap-Version? Änderung an der Coastline? Mich interessiert hauptsächlich, ob mit einer Abhilfe bald gerechnet werden kann, oder ob ich mich erstmal daran gewöhnen muss.

Ansonsten: Macht weiter mit der guten Arbeit an der AiO!

Ich kann nur vermuten, daß hier die Seegenerierung einer aktuellen mkgmap-Version zum Einsatz kommt. Bisher gibt es meines Wissens keine Version, die stabil funktioniert.

Nop wrote:

Ich kann nur vermuten, daß hier die Seegenerierung einer aktuellen mkgmap-Version zum Einsatz kommt. Bisher gibt es meines Wissens keine Version, die stabil funktioniert.

Man kann nur jedes neu erscheinende Release ausprobieren, bevor es richtig zur Anwendung kommt, notfalls auf das letzte funktionierende zurückgreifen. Enttäuschungen mit blauen Kacheln (und "verschmierte" Inseln) hatte ich nur zwischendurch immer wieder mal, deswegen bin ich von der Erstellung über Scripts weggekommen. Ich habe mir angewöhnt, im mkgmap-dev Archiv nachzuschauen was jeweils geändert wurde - oft ist die jeweils neueste Version nicht notwendig, oder eben fehlerhaft wenn an empfindlichen Codestellen wegen anderen Verbesserungen gerührt wurde.

http://www.mkgmap.org.uk/page/main (Mailing list => Archive => View by Author => svn commit)

Entscheidend ist wohl auch, wie die Ränder der verwendeten Rohdaten und somit alle Kacheln grad geschnitten sind. Deswegen wird man nicht generell gültig eine funktionierende Version benennen können.

Hallo zusammen,

bin fleissig mit dem MTB am Feld- / Waldwege sammeln. Allerdings sind die Mischwald-Symbole in der gmapsupp so dominant, da kann man die gestrichelten Waldwege richtig schlecht erkennen. Kann man das abschalten?
Ich benutze eine Vista HCX.

Gruß,

Martin

maerten32 wrote:

Hallo zusammen,

bin fleissig mit dem MTB am Feld- / Waldwege sammeln. Allerdings sind die Mischwald-Symbole in der gmapsupp so dominant, da kann man die gestrichelten Waldwege richtig schlecht erkennen. Kann man das abschalten?
Ich benutze eine Vista HCX.

Gruß,

Martin

Hey.

Für MTB würd ich dir die openmtbmap.org empfehlen.
Dort gibt es auch verschiedene Typ-Files.
Selber hab ich auch ein HCX und nutze dort das wide-Typfile.

Probiers mal aus.

Gruß

in meinem Oregon sehe ich leider gerade gar keine Waldwege (Track, grade2) trotz max Details :-( Die Karte ist aber schon in paar Tage alt. Ich werde wohl wieder zu Kleineisel zurückkehren. Schade um die Notes und Bugs, die bei der All In One dargestellt sind

Hab nach längerer Pause mal wieder eine AIO Europa (20100321) ausprobiert.
Positiv fällt vor allem auf, das es in meinem Testgebiet keine Routingabbrüche mehr gibt und das Meer nun blau ist 🙂
Vielen Dank für die Verbesserungen.

Allerdings meldet mein Nüvi 200 einen Speicherfehler beim ersten Laden der Karte, das hatte aber bisher aber keine Auswirkungen aufs Navi.

Ein generelles Problem scheint routing zu den Inseln zu sein. Nach Sylt führt der Autozug, der sogar mit "motorcar:yes" getaggt ist. Die Fähren z.B. Nordstrand nach Pellworm (ebenfalls mit "motorcar:yes") werden ebenfalls ignoriert. Die Garminkarte (City Navigator) routet da problemlos.

Seit einigen Tagen wird keine OSM-AllInOne-EU-basemap.exe mehr generiert, nur die OSM-AllInOne-EU-basemap.exe.md5 mit 0 Byte.

Und die gbasemap.tar.bz2 ist nur 41 kByte groß und enthält nur eine 63240345.img mit 0 Byte sowie die basemap.typ mit 61 kB.

Lückenfüller wrote:

Ein generelles Problem scheint routing zu den Inseln zu sein. Nach Sylt führt der Autozug, der sogar mit "motorcar:yes" getaggt ist. Die Fähren z.B. Nordstrand nach Pellworm (ebenfalls mit "motorcar:yes") werden ebenfalls ignoriert. Die Garminkarte (City Navigator) routet da problemlos.

Sollte ab mkgmap Version 1609 besser laufen (patch für ferry).

Die Fähre nach Norderney muss ich mir auch noch mal genauer angucken.

OpenRouteService routet zwar Fussgänger aber keine Autos dahin.

Edit Fähranleger Norderney habe ich korrigiert, Straße zum Terminal war als oneway und access=no
eingetragen. 🙁

Chris

mike_hd wrote:

Seit einigen Tagen wird keine OSM-AllInOne-EU-basemap.exe mehr generiert, nur die OSM-AllInOne-EU-basemap.exe.md5 mit 0 Byte.

Und die gbasemap.tar.bz2 ist nur 41 kByte groß und enthält nur eine 63240345.img mit 0 Byte sowie die basemap.typ mit 61 kB.

Hallo, ja das ist richtig. Es gab diverse Probleme auf unserem Server.
Nebenbei werden gerade Versuche für eine neue XAPI gemacht. Der Server ist deshalb ziemlich oft ausgelastet und mein Prozess stirbt ab und zu.

Morgen müsste ich nochmal ein neues europa und deutschland file rechnen können und Freitag bis Sonntag ist der Server nochmal belegt.
Wäre ja nicht so wild, wenn das morgen mal klappen würde.

Heute hab ichs leider selber verkackt - hab nen kleinen bug im Skript gehabt.

Die Sache mit dem mapsource installer ist leider etwas schwieriger. Scheinbar ist Europa mittlerweile so groß, dass der installer nicht mehr will.
Der stirbt leider ab und zu.
Weiß noch nicht, ob sich da ne coole Lösung finden lässt.

Na hoffentlich klappts morgen vernünftig.

Grüße
Christoph

Lückenfüller wrote:

Ein generelles Problem scheint routing zu den Inseln zu sein. Nach Sylt führt der Autozug, der sogar mit "motorcar:yes" getaggt ist. Die Fähren z.B. Nordstrand nach Pellworm (ebenfalls mit "motorcar:yes") werden ebenfalls ignoriert. Die Garminkarte (City Navigator) routet da problemlos.

Die Fähre Pellworm-Nordstrand funktioniert in ORS und in meiner mit dem Default-mkgmap-Style generierten Testkarte problemlos.

Der Sylt-Shuttle ist dagegen ein großes Problem, da Du keinen OSM Router finden wirst, der Autos über railways
schickt.

In meinem Garmin Nüvi (City Navigator) sieht die Linie anders aus als normale Bahnstrecken. Es scheint
so, dass die Autozug-Verbindung dort als ganz spezieller Weg drin ist.

Chris

Emden - Borkum kann ich auch nur berechnen, wenn ich einen Zwischenpunkt auf der Fährlinie setze!

mkgmap-r1620 wurde zum Erstellen der Karte verwendet.

flux.

Emden - Borkum kann ich auch nur berechnen, wenn ich einen Zwischenpunkt auf der Fährlinie setze!

Ja, bei mir hat der Patch auch nicht geholfen. Habe habe nur in MapSource geprüft. Es kann sein dass
das Gerät besser routet.

Der Sylt-Shuttle ist dagegen ein großes Problem, da Du keinen OSM Router finden wirst, der Autos über railways
schickt.

Die Verbindung habe ich jetzt als route=shuttle_train eingetragen, so dass das Routing mit einer
entsprechenden Regel nun möglich ist.

Chris

Hallo habt ihr auch das problem das ihr bei der all in one keine höhenlinien mehr habt?auch dauert es lange bis die daten aktuallisiert werden. desweiteren wurden vorher jede Menge mehr Wiesen angezeigt in den img.dateien. In der online Karte werden sie angezeigt... Jürgen

Habe mir die Karte von Kleineisel angesehen die hat zwar Höhenlinien aber auch hier fehlen die Wiesenflächen um Wipperfürth in der img. In der openstreetmap im www sind dagegen alle vorhanden.Sie fehlen erst seit ca 1 Woche.Mein Gerät ist der etrex legend hcx.Habt ihr ähnliches festgestellt?
Ansonsten sind die osm Karten sehr gut.Nutze sie eigentlich nur noch,egal ob zu Fuß Rad oder mit PKW.Nur des öfteren gibts Probleme mit der Adress-Suche im Garmin Gruß Jürgen

rasky wrote:

Hallo habt ihr auch das problem das ihr bei der all in one keine höhenlinien mehr habt?auch dauert es lange bis die daten aktuallisiert werden. desweiteren wurden vorher jede Menge mehr Wiesen angezeigt in den img.dateien. In der online Karte werden sie angezeigt... Jürgen

Ich habe eine der neuesten AIO (25.3.) heruntergeladen und mich gewundert, dass sie kleiner als der Vorgänger vom 21.3. war (788 MB statt 854 MB).
Die Differenz scheint von den fehlenden Höhenlinien zu kommen, die auch bei mir nicht (mehr) zu sehen und einzublenden sind 🙁

chris66 wrote:

Lückenfüller wrote:

Ein generelles Problem scheint routing zu den Inseln zu sein. Nach Sylt führt der Autozug, der sogar mit "motorcar:yes" getaggt ist. Die Fähren z.B. Nordstrand nach Pellworm (ebenfalls mit "motorcar:yes") werden ebenfalls ignoriert. Die Garminkarte (City Navigator) routet da problemlos.

Die Fähre Pellworm-Nordstrand funktioniert in ORS und in meiner mit dem Default-mkgmap-Style generierten Testkarte problemlos.

Dann sollte es mit der AOI ja auch irgendwann funktionieren 🙂

mapdiger wrote:

rasky wrote:

Hallo habt ihr auch das problem das ihr bei der all in one keine höhenlinien mehr habt?auch dauert es lange bis die daten aktuallisiert werden. desweiteren wurden vorher jede Menge mehr Wiesen angezeigt in den img.dateien. In der online Karte werden sie angezeigt... Jürgen

Ich habe eine der neuesten AIO (25.3.) heruntergeladen und mich gewundert, dass sie kleiner als der Vorgänger vom 21.3. war (788 MB statt 854 MB).
Die Differenz scheint von den fehlenden Höhenlinien zu kommen, die auch bei mir nicht (mehr) zu sehen und einzublenden sind 🙁

Die fehlenden Höhenlinien sind mir mit der Karte auch aufgefallen, ein Layer weniger zum Abschalten 😉 (zumindest im Auto)

Nicht so gut gefallen haben mir die Grenzlinien in violett, die gleiche Farbe wie die berechnete Route (Nüvi 200). Da die Ansagen doch oft unzuverlässig sind (zu früh, fehlend oder rechts/links vertauscht) hilft ein flüchtiger Blick aus Display vor dem Abbiegen. Wenn da aber eine Grenze verläuft ist das etwas unübersichtlich.

Das Routing hat sich auch irgendwie verändert, wobei ich da eher eine Verbesserung feststellen konnte.

Ich finde die Karte sowieso total klasse.Die grenzlinien schalte ich meist ab dann stören sie nicht.die aktuallität ist im Moment nur nicht gegeben,warum auch immer???? Ist dann auch oft schwierig beim mappen,da man nachher nicht mehr weiß ob Straßen und Punkte schon aufgenommen sind oder nicht. Weiß einer von euch woran es liegt das sich seit Tagen an dem Karten Download der All in One seitns der Aktuallität nichts mehr tut?

Gruß Jürgen

Liebe User,

ich würde gern eine Karte in Garmin Mobile PC verwenden.

1. Wo bekomme ich diese her (Gibt es eine OSM-Karte dafür?)
2. Wie kann ich diese dann in das Programm einfügen?

Gruß Marcel

Hi,

kann mir jemand sagen, welcher Unterschied im Tagging (bei der All-in-One Germany 29. Mär 19:46) dazu führt, das der Marktplatz von Hilden (N51°10.117', E6°55.975') im Garmin eTrex Vista HCx sichtbar ist, nicht aber der Warrington-Platz(N51°10.062, E6°56.064')?

Beide haben highway=pedestrian; area=yes; im Uhrzeigersinn.

MfG
Weide

An dieser Stelle wurde bereits vor einigen Wochen ein Routingproblem mit der AIO-Karte diskutiert.

Das Problem existierte bei alten AIO-Karten (von Ende 2009) noch nicht.
Die OSM-Daten der betreffenden Kreuzung sind seit Monaten unverändert.
Trotzdem tritt der Fehler in neuen AIO-Karten immer noch auf.

Ich habe die Stelle jetzt mal genauer analysiert.
Dazu habe ich einen Ausschnitt der OSM-Daten lokal gespeichert und damit eine Karte selbst gebaut.
Die Karte habe ich dann auf einem etrex VISTA HCx getestet.
Mit der selbstgebauten Karte konnte ich den Fehler reproduzieren.

Folgende Programme und Styles habe ich verwendet:
mkgmap: r1625 vom 2010-03-29
splitter: r106 vom 2010-03-29
Styles: http://dev.openstreetmap.de/aio/germany/styles.tar.bz2 vom 2010-03-30

Das Problem äußert sich wie folgt:
Der Router weigert sich, den Punkt http://www.openstreetmap.org/?mlat=51.2 … 32&zoom=17 von Süden nach Norden zu überqueren.
Der Fehler tritt sowohl mit der Einstellung 'Auto/Motorrad' als auch mit der Einstellung 'Fahrrad' auf.
Der Fehler tritt mit *alten* AIO-Karten, die auf exakt denselben OSM-Daten beruhen, nicht auf.

Die Ursache scheint die Auslegung der Abbiege-Restriktion http://www.openstreetmap.org/browse/relation/183515 zu sein.

Die Restriktion hat folgende Eigenschaften.
restriction = only_straight_on
from: http://www.openstreetmap.org/browse/way/41079727
via: http://www.openstreetmap.org/browse/node/253969721
to: http://www.openstreetmap.org/browse/way/32524422

Der folgende Auszug aus dem mkgmap Log zeigt die Auswirkungen der Restriktion.
Mkgmap sollte dabei vom via-Knoten ausgehend, alle Knoten (mit Ausnahme des nächsten Knotens in Richtung des 'to'-Weges) blockieren.
Im Log sind die zu blockierenden Knoten mit 'other'-nodes benannt.

Im Log taucht aber auch der Knoten http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17 als 'other'-node auf.
Das ist aber *der* nächste Knoten in Richtung des 'to'-Weges.
Dieser Knoten darf hier selbstverständlich nicht auftauchen. Das Auftauchen dieses Knotens verhindert die Überquerung des Punktes von Süden kommend.

Auszug aus dem mkgmap Log: (Den betreffenden Knoten habe ich fett hervorgehoben.)

Turn restriction http://www.openstreetmap.org/browse/relation/183515
at http://www.openstreetmap.org/?mlat=51.2 … 32&zoom=17

only_straight_on 'via' node is http://www.openstreetmap.org/?mlat=51.2 … 32&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17

only_straight_on 'to' node is http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17

only_straight_on 'from' node is http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17

only_straight_on added - allows routing to way http://www.openstreetmap.org/browse/way/32524422
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17

Die Situation ändert sich völlig, wenn ich in den lokalen OSM-Daten im 'to'-Weg http://www.openstreetmap.org/browse/way/32524422
das cycleway=track Tag entferne. Alle anderen Wege und insbesondere die Restriktion bleiben unverändert.

Der Knoten http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17 ist dann *nicht* mehr in der Liste der blockierten Knoten enthalten.
Die so erstellte Karte führt zu einem korrekten Routing (wenn man von dem dann fehlenden Radweg mal absieht).

Das mkgmap log sieht dann so aus:

Turn restriction http://www.openstreetmap.org/browse/relation/183515
at http://www.openstreetmap.org/?mlat=51.2 … 32&zoom=17

only_straight_on 'via' node is http://www.openstreetmap.org/?mlat=51.2 … 32&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17

only_straight_on 'to' node is http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17

only_straight_on 'from' node is http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17

only_straight_on added - allows routing to way http://www.openstreetmap.org/browse/way/32524422
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17

Warum führt das cycleway=track Tag zu einem solchen Routing-Fehler?

Seltsam ist auch, dass dieser Fehler nicht bei allen only_straight_on-Restriktionen auftritt.

Manche dieser Restriktionen funktionieren wie erwartet korrekt.

@Master:
Hast Du irgendeine Idee, was die Ursache dafür sein könnte, dass die Verwendung des cycleway-Tag dazu führt, dass der im mkgmap-Log sogenannte 'to'-node irrtümlich in die Liste der blockierten Knoten aufgenommen wird?
Ist das ein Fehler von mkgmap oder liegt die Ursache in der Behandlung von cycleway=track in den Styles?

Weide wrote:

kann mir jemand sagen, welcher Unterschied im Tagging (bei der All-in-One Germany 29. Mär 19:46) dazu führt, das der Marktplatz von Hilden (N51°10.117', E6°55.975') im Garmin eTrex Vista HCx sichtbar ist, nicht aber der Warrington-Platz(N51°10.062, E6°56.064')?

Beide haben highway=pedestrian; area=yes; im Uhrzeigersinn.

Mögliche Ursache: Der Warrington-Platz enthält noch ein note=...
Das könnte einen Einfluss auf die Darstellung haben (fixme-Layer).

@ geopia

Mit den identischen Programmen und dem default-Style von mkgmapr-1625 kann ich problemlos mit den heutigen OSM-Daten (europa.osm.bz2) von Süden nach Norden auf der Ulmenstraße routen (Vista HCx).

Mein Ausgangspunkt ist N 51° 15.175', E 006° 46.844', der Zielpunkt ist N 51° 15.354', E 006° 46.801'.

Nur zur Info ...

flux.

flux wrote:

@ geopia

Mit den identischen Programmen und dem default-Style von mkgmapr-1625 kann ich problemlos mit den heutigen OSM-Daten (europa.osm.bz2) von Süden nach Norden auf der Ulmenstraße routen (Vista HCx).

Mein Ausgangspunkt ist N 51° 15.175', E 006° 46.844', der Zielpunkt ist N 51° 15.354', E 006° 46.801'.

Nur zur Info ...

Wie sieht es denn aus, wenn Du die original AIO-Karte verwendest? Kannst Du den Fehler damit bestätigen oder kannst Du im Gegenteil bestätigen, dass der Fehler bei dir nicht auftritt?
Die zuletzt von mir getestete und definitiv mit dem dem Fehler behaftete original AIO-Karte stammt übrigens vom 2010-03-31.

Ich habe jetzt auch einen Test mit dem default-Style gemacht. Mit dem default-Style kann ich den Fehler ebenfalls reproduzieren!
Kannst Du bitte mal die exakten mkgmap-Parameter angeben mit denen Du deine Karte gebaut hast?

Ich habe folgende Parameter verwendet: basemap.args

max-jobs
draw-priority:␣10
description:␣Openstreetmap
country-name:␣germany
country-abbr:␣DE
area-name:␣DE
mapname:␣63240345
family-id:␣4
product-id:␣45
family-name:␣OSM
series-name:␣OSM-AllInOne-DE-basemap
gmapsupp
tdbfile
nsis
latin1
net
route
index
add-pois-to-areas
make-all-cycleways
link-pois-to-ways
remove-short-arcs
generate-sea:␣polygons,no-sea-sectors,close-gaps=2000

Mein mkgmap-Aufruf:

name=Europa-S
java␣-Xmx2600M␣-ea␣-jar␣../mkgmap-r1625/mkgmap.jar␣--route␣--net␣--latin1␣--description=$name␣--gmapsupp␣--country-name=$name␣--country-abbr=$name␣--family-name=$name␣--family-id=16␣--product-id=1␣--series-name=$name␣--remove-short-arcs␣--add-pois-to-areas␣--adjust-turn-headings␣--link-pois-to-ways␣--location-autofill=2␣--generate-sea=extend-sea-sectors␣--ignore-maxspeeds␣--max-jobs=2␣--style-file=../mkgmap-r1625/resources/styles/default/␣63240*

flux.

Hier noch ein Screenshot ...

Geroutet vom südlichen zum nördlichen Punkt der angezeigten Route (PKW/Motorrad) auf dem Vista HCx.

flux.

flux wrote:

Mein mkgmap-Aufruf:

name=Europa-S
java␣-Xmx2600M␣-ea␣-jar␣../mkgmap-r1625/mkgmap.jar␣--route␣--net␣--latin1␣--description=$name␣--gmapsupp␣--country-name=$name␣--country-abbr=$name␣--family-name=$name␣--family-id=16␣--product-id=1␣--series-name=$name␣--remove-short-arcs␣--add-pois-to-areas␣--adjust-turn-headings␣--link-pois-to-ways␣--location-autofill=2␣--generate-sea=extend-sea-sectors␣--ignore-maxspeeds␣--max-jobs=2␣--style-file=../mkgmap-r1625/resources/styles/default/␣63240*

flux.

Danke. Du verwendest also *nicht* den Parameter '--make-all-cycleways'. Das erklärt den Unterschied.

Ohne den Parameter 'make-all-cycleways' routet meine Testkarte den Fall auch korrekt:

mkgmap Log *ohne* Verwendung von 'make-all-cycleways'

Turn restriction http://www.openstreetmap.org/browse/relation/183515 (at http://www.openstreetmap.org/?mlat=51.2 … 2&zoom=17)

only_straight_on 'via' node is http://www.openstreetmap.org/?mlat=51.2 … 32&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17

only_straight_on 'to' node is http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17

only_straight_on 'from' node is http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17

only_straight_on added - allows routing to way http://www.openstreetmap.org/browse/way/32524422
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17

Mit 'make-all-cycleways' ist der Fehler wieder da:

mkgmap Log *mit* Verwendung von 'make-all-cycleways'

Turn restriction http://www.openstreetmap.org/browse/relation/183515 (at http://www.openstreetmap.org/?mlat=51.2 … 2&zoom=17)

only_straight_on 'via' node is http://www.openstreetmap.org/?mlat=51.2 … 32&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17

only_straight_on 'to' node is http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17

only_straight_on 'from' node is http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17

only_straight_on added - allows routing to way http://www.openstreetmap.org/browse/way/32524422
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17

Frage @Master:
Was bedeutet das jetzt für die AIO-Karte?
Gibt es eine Möglichkeit, einerseits Radwege zu sehen, und andererseits korrekt funktionierende Restriktionen zu haben?
Oder schließen sich die beiden Eigenschaften gegenseitig aus?

geopia wrote:

Mit dem default-Style kann ich den Fehler ebenfalls reproduzieren!

Dann sollte das in der mkgmap-dev Mailinglist als Bug gemeldet werden. Falls Du da nicht drin bist, kann ich
gerne forwarden, benötige das ganze dann aber in englisch.

Ich baue meine Karten mit --make-opposite-cycleways, weiss aber nicht
ob der Fehler damit auch auftritt.

Grüße
Chris

Ich habe die Karte noch einmal kompiliert, diesmal mit --make-all-cycleways, das Routing klappt genausogut wie vorher ...

Und hier die Einstellungen ...

flux.

flux wrote:

Ich habe die Karte noch einmal kompiliert, diesmal mit --make-all-cycleways, das Routing klappt genausogut wie vorher ...

http://mirror.live-modules.org/quax/flu … leways.jpg

Und hier die Einstellungen ...

http://mirror.live-modules.org/quax/flu … lungen.jpg

Ich habe die Karten nochmal ohne Styles gebaut:

mit 'make-all-cycleways' und Einstellung für 'Fahrrad': Fehler tritt auf!
mit 'make-all-cycleways' und Einstellung für 'Auto/Motorrad': Fehler tritt auf!

im Unterschied zu Deinen Einstellungen aber mit:
[ ] Kehrtwenden
[x] Mautstraßen

wie bei dir mit
[x] Kehrtwenden
[ ] Mautstraßen
dasselbe Ergebnis

ohne 'make-all-cycleways' und Einstellung für 'Fahrrad': Fehler tritt *nicht* auf!
ohne 'make-all-cycleways' und Einstellung für 'Auto/Motorrad': Fehler tritt *nicht* auf!

jetzt aber wie bei dir mit
[x] Kehrtwenden
[ ] Mautstraßen

und
[ ] Kehrtwenden
[x] Mautstraßen
führt zum selben Ergebnis

Hast Du auch wirklich nach dem ersten Test und dem Aufspielen der neuen Karte die Route neu berechnen lassen?

Wenn ich eine neue Karte lade, MUSS ich ja die Route neu berechnen lassen, da ich den angenommenen Standort Ulmenstraße verliere und erst wieder von mir hier nach Düsseldorf "verlegen" muss.

Ich habe die Route ganz sicher neu berechnen lassen!!!

flux.

Ich habe jetzt noch zweimal neu berechnet, nachdem ich zwischendurch andere Routen berechnet habe. Es wird fehlerfrei geroutet, egal welche Fahrzeuge und Optionen ich wähle.

flux.

chris66 wrote:

Dann sollte das in der mkgmap-dev Mailinglist als Bug gemeldet werden.

Der Fehler bei Kombination von 'make-all-cycleways' mit Wegen mit cycleway=track im 'to'-Weg von einer only_straight_on-Restriktion sehen sehr nach einem Fehler in mkgmap aus.
Die Logs zeigen eindeutig, dass der sogenannte 'to-node' in die Liste der geblockten Knoten aufgenommen wird. Das ist ziemlich sicher ein Fehler.
Warum der Knoten in diese Liste aufgenommen wird? Keine Ahnung.

chris66 wrote:

Falls Du da nicht drin bist, ...

Da bin ich nicht drin.

chris66 wrote:

... kann ich gerne forwarden, benötige das ganze dann aber in englisch.

Da muss ich passen!

chris66 wrote:

Ich baue meine Karten mit --make-opposite-cycleways, weiss aber nicht
ob der Fehler damit auch auftritt.

Könntest Du das mit deiner Karte mal testen.

flux wrote:

Wenn ich eine neue Karte lade, MUSS ich ja die Route neu berechnen lassen, da ich den angenommenen Standort Ulmenstraße verliere und erst wieder von mir hier nach Düsseldorf "verlegen" muss.

Ich habe die Route ganz sicher neu berechnen lassen!!!

War ja nur 'ne vorsichtige Frage.

Der angenommen Standort muss übrigens nicht unbedingt verloren gehen. Wenn man schnell genug nach dem Neustart 'ohne GPS nutzen' auswählt, dann bleibt der angenommene Standort auch erhalten.

Auch Teile der Route bleiben manchmal erhalten.

Ich berechne vorsichtshalber bei Tests immer mehrmals neu um Altlasten zu eliminieren.

Deshalb meine Nachfrage.

geopia wrote:

Mögliche Ursache: Der Warrington-Platz enthält noch ein note=...
Das könnte einen Einfluss auf die Darstellung haben (fixme-Layer).

Ja, vielleicht. Inzwischen denke ich aber eher an Zufälle bei Malreihenfolge, denn beim schnellen Scrollen sieht man den Platz manchmal kurz und bei einer weiteren heute selbst gebauten Karte sind beide Plätze weg.

Vielleicht muss das landuse=residential für Plätze Löcher bekommen...

Weide

Ich habe eine weitere Karte kompiliert, Option jetzt --make-opposite-cycleways, das Ergebnis ist wieder ein korrektes Routing (alle Fahrzeuge, alle Optionen durchprobiert).

Es liegt also definitiv nicht an einer der Optionen --make-all-cycleways oder --make-opposite-cycleways oder dem Fehlen derselben!

Es klappt bei mir in allen drei Fällen.

flux.

@geopia

Hat die Option --ignore-osm-bounds einen Einfluss ?

Ich hatte schon mal den Fall, dass TurnRestrictions ohne diese Option nicht richtig funktionierten,
bei lokal runtergeladenen Daten.

Bei mir korrektes Routing in MapSource mit --make-opposite-cycleways und meinem BlueMap-Style.
(mkgmap V1624).

EDIT: mit --make-all-cycleways routet er an der Kreuzung rechts, U-Turn an der Rather Straße und
zurück zur Kreuzung.

Chris

Mit mkgmap-r1625 geht es definitiv, nur um das noch einmal zu untermauern!!!

flux.

P. S. Mit mkgmap-r1626 geht es auch ...

geopia wrote:

Auszug aus dem mkgmap Log:...

Wenn wir mal im ersten Teil der beiden Logs statt der Links Namen einsetzen, dann erhalten wir (M=mitte, O=oben, U=unten, L=links, RR=zweiter Point rechts):

only_straight_on 'via' node is M
only_straight_on adding 'other' node L
only_straight_on adding 'other' node O
only_straight_on adding 'other' node RR
only_straight_on adding 'other' node U

only_straight_on 'to' node is O
only_straight_on adding 'other' node L
only_straight_on adding 'other' node RR

only_straight_on 'from' node is U

bzw.

only_straight_on 'via' node is M
only_straight_on adding 'other' node L
only_straight_on adding 'other' node RR
only_straight_on adding 'other' node U

only_straight_on 'to' node is O
only_straight_on adding 'other' node L
only_straight_on adding 'other' node RR

only_straight_on 'from' node is U

Es wird also mehrere Punkte unterschiedlich markiert. Ich habe in der Quelle nur "other"-Markierungen gefunden, wo "to" und "from" schon ausgeschlossen wurden (ich habe allerdings nie richtig Java gelernt, weil ich es unlesbar finde). Das passiert in Schleifen über Restriktionen, die mit einem Punkt zu tun haben. Das Log sieht für mich also danach aus, als ob an dieser Stelle irrtümlich weitere Restriktionen verarbeitet würden.

Man könnte also testhalber mal Nachbarrestriktionen beseitigen.

Weide

PS:
Man kann den Upload von Testdaten vermeiden, indem man im JOSM abspeichert. Dabei muss man allerdings (weil JOSM z.B. Löschungen speichern muss und mkgmap dann versucht, diese darzustellen) eine neue Ebene erzeugen, die alte komplett markieren und rüberkopieren und dann die neue abspeichern.

chris66 wrote:

@geopia
Hat die Option --ignore-osm-bounds einen Einfluss ?

Das habe ich noch nicht getestet.
Die Beschreibung verspricht aber

--ignore-osm-bounds
When reading OSM files, ignore any "bounds" elements.
With this option selected generate-sea sometimes works better,
but routing accross tiles will not work.

Das werde ich noch mal testen.

chris66 wrote:

Bei mir korrektes Routing in MapSource mit --make-opposite-cycleways und meinem BlueMap-Style.
(mkgmap V1624).

Das habe ich inzwischen auch getestet. Mit 'make-opposite-cycleways' gibt es keinen Fehler.

chris66 wrote:

EDIT: mit --make-all-cycleways routet er an der Kreuzung rechts, U-Turn an der Rather Straße und
zurück zur Kreuzung.

Genau das ist der besagte Fehler. Ich glaubte so langsam ich seh' weiße Mäuse.

Ich habe inzwischen auch alle vier möglichen Kombinationen von 'make-cycleways' und 'make-opposite-cycleways' getestet:
Nein Nein Ja Ja :Option 'make-cycleways' gesetzt
Nein Ja Nein Ja :Option 'make-opposite-cycleways' gesetzt

---

Nein Nein Ja Ja :Fehler tritt auf

Die Option 'make-all-cycleways' ist wohl nur eine Abkürzung für beide Optionen 'make-cycleways' und 'make-opposite-cycleways' gemeinsam.

Ich kann exakt reproduzieren, dass 'make-cycleways' und damit indirekt auch 'make-all-cycleways' an dieser Stelle zu dem Fehler führt.
Die Option 'make-opposite-cycleways' hat zumindest an dieser Stelle keinen Einfluss auf den Fehler.
Das werde ich aber nochmal mit einer einschlägigen geeigneten Stelle testen.

Weide wrote:

... Das passiert in Schleifen über Restriktionen, die mit einem Punkt zu tun haben. Das Log sieht für mich also danach aus, als ob an dieser Stelle irrtümlich weitere Restriktionen verarbeitet würden.

Man könnte also testhalber mal Nachbarrestriktionen beseitigen.

Ja, das werde ich mal testen. Die benachbarte Restriktion (links daneben an derselben Kreuzung) hat in übertragenem Sinne übrigens exakt dasselbe Problem. Auch hier hat der to-Weg einen Radweg.

Auch die nächste Restriktion weiter nördlich an der Esperantostraße hat einen to-Weg mit Radweg und macht Probleme.

Weide wrote:

PS:
Man kann den Upload von Testdaten vermeiden, indem man im JOSM abspeichert. Dabei muss man allerdings (weil JOSM z.B. Löschungen speichern muss und mkgmap dann versucht, diese darzustellen) eine neue Ebene erzeugen, die alte komplett markieren und rüberkopieren und dann die neue abspeichern.

Was meinst Du mit Upload von Testdaten? Ich teste einfach mit einer lokalen OSM-Datei. Die kann ich mit JOSM beliebig ohne hochzuladen verändern und abspeichern. Ich möchte selbstverständlich auf gar keinen Fall irgendwelche Testdaten hochladen.

flux wrote:

Mit mkgmap-r1625 geht es definitiv, nur um das noch einmal zu untermauern!!!

Ich kann den Fehler ganz sicher reproduzieren.

Die Option 'make-cycleways' und damit indirekt auch 'make-all-cycleways' führt an dieser Stelle zu dem Fehler.
Das gilt sogar unabhängig von der Verwendung von Styles.

Es ist eindeutig in den Logs von mkgmap zu erkennen, dass bei Verwendung von 'make-cycleways' der sogenannte to-node in die Liste der zu blockierenden Knoten aufgenommen wird. Und das ist widersinnig!

Es muss also noch einen anderen Seiteneffekt geben, der bei dir zu einem anderen Ergebnis führt.
Irgend etwas muss bei bei deinem Bau anders sein.

Also mit allen drei cycleway-Optionen routet mein Vista HCx richtig.

Mit welchen Optionen erstellst du dein logfile? Vielleicht finde ich da etwas ...

flux.

flux wrote:

Also mit allen drei cycleway-Optionen routet mein Vista HCx richtig.

Das glaube ich dir gerne. Nur, damit verschwindet der Fehler in der original AIO-Karte nicht.

flux wrote:

Mit welchen Optionen erstellst du dein logfile?

Etwa so wie hier beschrieben: http://wiki.openstreetmap.org/wiki/Mkgm … _Debugging
Also mit dem mkgmap Parameter

-Dlog.config=$(LAYER_CONF_DIR)/basemap-logging.properties

Damit erhält man auf der Konsole etwas mehr Ausgaben und es wird zusätzlich ein Logfile mit Namen mkgmap.log.0 im aktuellen Verzeichnis erstellt.
Aus dem so erstellten Logfile werden dann im makefile die Infos zu der fraglichen Restriktion 183515 mit etwas quick&dirty-grep-sed extrahiert und zitierfähig verdichtet:
Auszug aus dem makefile

␣␣␣␣␣cat␣$(LAYER_DIR)/basemap/mkgmap.log.0\
|␣grep␣183515\
|␣sed␣'s/.*\.osm\.gz:␣//'\
|␣sed␣'s/\(.*\)\(only_straight_on\)/␣\1\n\2/'\
|␣sed␣'1␣s/^␣//'\
|␣sed␣'s/^␣Turn.*//'\
|␣grep␣'.'\
>␣$(LAYER_DIR)/basemap/mkgmap.log.0.rel-183515

Die Logs werden nach dem Bau jeweils in extra Verzeichnissen zusammen mir der gmapsupp.img abgelegt.
So kann ich die einzelnen Versuche nachvollziehen und vergleichen.

@Weide: Du verwendest doch auch ein selbstgebautes AIO-Derivat. Richtig? Tritt der besagte Fehler eigentlich bei dir auf oder nicht?
Das hätten wir eigentlich am Mittwoch mal live ausprobieren müssen. Zu spät. Könntest Du das mal testen.

chris66 wrote:

@geopia

Hat die Option --ignore-osm-bounds einen Einfluss ?

Ich hatte schon mal den Fall, dass TurnRestrictions ohne diese Option nicht richtig funktionierten,
bei lokal runtergeladenen Daten.

Die Option 'ignore-osm-bounds' habe ich jetzt auch getestet. Hat keinen Einfluss auf diesen Fehler. Der Fehler bleibt erhalten.

@ geopia

Es gibt keine Fehlermeldung in dem genannten Bereich!!!

--make-all-cycleways wurde benutzt, ansonsten die Optionen aus meinem Post von gestern ...

flux.

P. S.: Hier die Route im Detail an der Kreuzung und dann die Terminalausgabe ...

flux wrote:

@ geopia

Es gibt keine Fehlermeldung in dem genannten Bereich!!!

--make-all-cycleways wurde benutzt, ansonsten die Optionen aus meinem Post von gestern ...

flux.

P. S.: Hier die Route im Detail an der Kreuzung und dann die Terminalausgabe ...

http://mirror.live-modules.org/quax/flu … tr-neu.jpg

http://mirror.live-modules.org/quax/flu … rminal.jpg

Was auch immer Du da tust. Die Restriktion muss unter allen Umständen, gleichgültig ob Fehler oder nicht, im Log auftauchen.

Wenn in deinem Log keine Einträge zu dieser Restriktion erscheinen, dann scheint es bei dir diese Restriktion gar nicht zu geben. Dann kann es folgerichtig bei dir auch keinen Fehler mit dieser Restriktion geben.

Versuche doch mal bitte testweise mit deiner Karte an dieser Kreuzung von Süden kommend direkt nach links abzubiegen. Das sollte eigentlich verboten sein und mit dieser Restriktion auch nicht vorgeschlagen werden. Schlägt der Router mit deiner Karte ein Linksabbiegen vor?

Kein Linksabbiegen möglich, weder als Auto/Motorrad noch als Fahrrad ... Startpunkt ist N 51° 15.143', E 006° 46.863', Zielpunkt ist B 1;b 8 Johannstrasse (Cycleway) N 51° 15.225', E 006° 46.664' ... die Route geht vom Startpunkt Richtung Norden an die Kreuzung, dann nach rechts, dann ein U-Turn an der Rather Straße, dann zum Zielpunkt ...

flux.

P. S.: Was mache ich denn anders? Nur weil ich Linux verwende?

geopia wrote:

@Weide: Du verwendest doch auch ein selbstgebautes AIO-Derivat. Richtig? Tritt der besagte Fehler eigentlich bei dir auf oder nicht?
Das hätten wir eigentlich am Mittwoch mal live ausprobieren müssen. Zu spät. Könntest Du das mal testen.

Ja, das gibt einen Umweg über Rather Straße (Auto und Fahrrad).

Weide

flux wrote:

Kein Linksabbiegen möglich, weder als Auto/Motorrad noch als Fahrrad ... Startpunkt ist N 51° 15.143', E 006° 46.863', Zielpunkt ist B 1;b 8 Johannstrasse (Cycleway) N 51° 15.225', E 006° 46.664' ... die Route geht vom Startpunkt Richtung Norden an die Kreuzung, dann nach rechts, dann ein U-Turn an der Rather Straße, dann zum Zielpunkt ...

Mensch Flux, Du machst mich wahnsinnig! Exakt das ist doch eine der Auswirkungen des Fehlers.
Der kürzeste Weg wäre hier geradeaus nach Norden und dann über die Wendeschleife hinter der Straßenbahnhaltestelle und dann nach rechts zum Zielpunkt. Der viel zitierte Fehler verhindert aber das Geradeausfahren und provoziert den unsinnigen Umweg über die Rather Straße.

Immerhin zeigt das, dass die Restriktion bei dir vorhanden ist.
Warum erscheint die Restriktion dann nicht in deinem Log? Gibt es bei dir noch weitere Log-Dateien
mkgmap.log.0
mkgmap.log.1
...

flux wrote:

P. S.: Was mache ich denn anders? Nur weil ich Linux verwende?

Wie jetzt? Gibt's denn noch was anderes?

Langsam ...

Ich sollte dort linksabbiegen, das geht nicht, weil es nicht erlaubt ist, richtig?

Ich kann dort aber geradeaus fahren, wenn der Zielpunkt nördlich der Kreuzung liegt! Dein Problem war ja, dass du NICHT geradeaus fahren konntest, richtig? Also Startpunkt südlich der Kreuzung und Zielpunkt nördlich der Kreuzung, richtig?

Das sind zwei verschiedene Ausgangslagen ...

flux.

geopia wrote:

Weide wrote:

PS:
Man kann den Upload von Testdaten vermeiden, indem man im JOSM abspeichert. Dabei muss man allerdings (weil JOSM z.B. Löschungen speichern muss und mkgmap dann versucht, diese darzustellen) eine neue Ebene erzeugen, die alte komplett markieren und rüberkopieren und dann die neue abspeichern.

Was meinst Du mit Upload von Testdaten? Ich teste einfach mit einer lokalen OSM-Datei. Die kann ich mit JOSM beliebig ohne hochzuladen verändern und abspeichern. Ich möchte selbstverständlich auf gar keinen Fall irgendwelche Testdaten hochladen.

Ja, so hab ich das im letzten Herbst auch gemacht. Der Originalkram war aus OSM, dann habe ich es im JOSM bearbeitet und lokal abgespeichert.

Das funktioniert aber nicht immer. Wenn man z.B. eine Linie löscht, kann JOSM die nicht einfach wegwerfen und beim Upload nur die neuen und geänderten Sachen zum Server schicken -- die Linie würde dann ja nie verschwinden. Die Linie bleibt daher im Datenbestand von JOSM und wird mit abgespeichert -- es steht nur zusätzlich dran "zu löschen" und sie ist in JOSM unsichtbar und unmarkierbar. "zu löschen" kapiert mkgmap aber nicht und stellt es dann (manchmal) dar.

Das Problem kann man vermeiden, wenn man im JOSM "alles" markiert, in eine neue Datenebene kopiert und die dann lokal abspeichert.

Weide

Weide wrote:

Ja, so hab ich das im letzten Herbst auch gemacht. Der Originalkram war aus OSM, dann habe ich es im JOSM bearbeitet und lokal abgespeichert.

Das funktioniert aber nicht immer. Wenn man z.B. eine Linie löscht, kann JOSM die nicht einfach wegwerfen und beim Upload nur die neuen und geänderten Sachen zum Server schicken -- die Linie würde dann ja nie verschwinden. Die Linie bleibt daher im Datenbestand von JOSM und wird mit abgespeichert -- es steht nur zusätzlich dran "zu löschen" und sie ist in JOSM unsichtbar und unmarkierbar. "zu löschen" kapiert mkgmap aber nicht und stellt es dann (manchmal) dar.

Das Problem kann man vermeiden, wenn man im JOSM "alles" markiert, in eine neue Datenebene kopiert und die dann lokal abspeichert.

Ah, jetzt verstehe ich was Du meinst. Das könnte in der Tat falsche Schlussfolgerungen nach sich ziehen. Danke für den Tipp.

Ach ja, hast Du schon mal versucht, mit deiner Karte den Fehler zu reproduzieren?

geopia wrote:

Ach ja, hast Du schon mal versucht, mit deiner Karte den Fehler zu reproduzieren?

Ja, steht auf der vorigen Seite :-) oder inzwischen vorvorigen?

Jedenfalls tritt der Fehler bei mir auf.

Weide

flux wrote:

Langsam ...

Ich sollte dort linksabbiegen, das geht nicht, weil es nicht erlaubt ist, richtig?

Ich kann dort aber geradeaus fahren, wenn der Zielpunkt nördlich der Kreuzung liegt! Dein Problem war ja, dass du NICHT geradeaus fahren konntest, richtig? Also Startpunkt südlich der Kreuzung und Zielpunkt nördlich der Kreuzung, richtig?

Das sind zwei verschiedene Ausgangslagen ...

Ja, das sind zwei verschiedene Ausgangslagen. Aber immerhin stellt sich bei dir bei einer der Ausgangslagen der fehlerhafte Effekt ein. Ich weiß, bei der anderen Ausgangslage stellt sich der Effekt bei dir *nicht* ein!

Deshalb sind jetzt deine Logs von Interesse. Warum taucht die Restriktion dort nicht auf?

Weide wrote:

geopia wrote:

Ach ja, hast Du schon mal versucht, mit deiner Karte den Fehler zu reproduzieren?

Ja, steht auf der vorigen Seite :-) oder inzwischen vorvorigen?

Jedenfalls tritt der Fehler bei mir auf.

Ups, diese Nachricht habe ich glatt übersehen.

Warum die Restriktion nicht auftaucht, kann ich nicht sagen. Ich habe log.0 bis log.3, in keinem ist sie gelistet.

Das Routing in diesem Kreuzungsbereich ist aber eher willkürlich. Route ich südlich der Kreuzung von der Ulmenstraße (Radweg Ulmenstraße N kurz vor der Kreuzung) auf den gegenüberliegenden Radweg (auch südlich der Kreuzung, aber Radweg Ulmenstraße S), dann geht die Route geradeaus Richtung Norden über die Kreuzung, dann ein U-Turn, wo die Straße zusammengeht (nördlich der Kreuzung), dann gerade Richtung Süden zum Zielpunkt.

Gehe ich mit dem Startpunkt weiter von der Kreuzung weg, dann wird an der Kreuzung rechts über die Rather Straße geroutet (dort U-Turn), zurück zur Kreuzung, dort rechts, ein U-Turn, wo die Ulmenstraße wieder zusammenläuft, dann südlich gerade über die Kreuzung zum Zielpunkt Ulmenstraße Cycleway S.

Irgendwie beliebig ...

flux.

Schau dir das an ...

Ulmenstraße südlich der Kreuzung ist Startpunkt, der Zeiger ist Zielpunkt:

Dann nur ein anderer Zielpunkt, der Zeiger zeigt ihn ...

Der Router macht an dieser Kreuzung, was er möchte!!!

flux.

flux wrote:

Warum die Restriktion nicht auftaucht, kann ich nicht sagen. Ich habe log.0 bis log.3, in keinem ist sie gelistet.

Es könnte sein, dass die Einstellungen in logging.properties

java.util.logging.FileHandler.limit=5000000
java.util.logging.FileHandler.count=4

deine Log-Dateien kürzen.
Nimm mal alle

uk.me.parabola.imgfmt.level=INFO
uk.me.parabola.mkgmap.build.level=INFO
uk.me.parabola.mkgmap.main.Main.level=INFO
uk.me.parabola.mkgmap.main.MapMaker.level=INFO
uk.me.parabola.mkgmap.general.RoadNetwork.level=INFO
uk.me.parabola.mkgmap.general.MapLine.level=INFO
uk.me.parabola.mkgmap.osmstyle.level=INFO
uk.me.parabola.mkgmap.reader.osm.level=INFO
uk.me.parabola.mkgmap.reader.osm.xml.level=INFO

raus und lasse nur noch

uk.me.parabola.mkgmap.reader.osm.RestrictionRelation.level=FINE
uk.me.parabola.mkgmap.reader.osm.Restriction.level=FINE

drin.

flux wrote:

Das Routing in diesem Kreuzungsbereich ist aber eher willkürlich. Route ich südlich der Kreuzung von der Ulmenstraße (Radweg Ulmenstraße N kurz vor der Kreuzung) auf den gegenüberliegenden Radweg (auch südlich der Kreuzung, aber Radweg Ulmenstraße S), dann geht die Route geradeaus Richtung Norden über die Kreuzung, dann ein U-Turn, wo die Straße zusammengeht (nördlich der Kreuzung), dann gerade Richtung Süden zum Zielpunkt.

Gehe ich mit dem Startpunkt weiter von der Kreuzung weg, dann wird an der Kreuzung rechts über die Rather Straße geroutet (dort U-Turn), zurück zur Kreuzung, dort rechts, ein U-Turn, wo die Ulmenstraße wieder zusammenläuft, dann südlich gerade über die Kreuzung zum Zielpunkt Ulmenstraße Cycleway S.

Irgendwie beliebig ...

Das ist allerdings seltsam. Zum Teil kann man das aber mit der zweiten Restriktion erklären die das selbe Problem hat.
Seltsam ist aber, dass der Startpunkt weiter weg ein anderes Ergebnis liefert.

Die Bilder in #284 hast du gesehen? Also auch ein anderer Zielpunkt im Kreuzungsbereich ändert das Routing!!!

flux.

flux wrote:

Die Bilder in #284 hast du gesehen? Also auch ein anderer Zielpunkt im Kreuzungsbereich ändert das Routing!!!

Gesehen und mit Verwunderung zur Kenntnis genommen.
Solche zufällig erscheinenden Ergebnisse konnte ich durchaus schon häufiger beobachten. Ich teste deshalb auch möglichst mehrmals und mit unterschiedlichen Punkten. Erklären kann ich diese seltsamen Effekte aber nicht.

Aber was lehrt uns das? Aussagen über ursächliche Zusammenhänge sind in diesem Kontext immer sehr gewagt!

Mit dem gekürzten logging.properties werden keine img-Dateien mehr erstellt. Ich arbeite mit --max-jobs=2, d. h. es werden zwei leere img-Dateien erstellt, die CPU läuft auf 100%, es bleibt aber nach Anlegen der beiden img-Dateien der Prozess stehen, 0 Byte Inhalt und nichts geht weiter ... ausser der Lüfter und die auf 100% arbeitende CPU ...

Ich lege diese Kreuzung jetzt zur Seite ...

flux.

ist es normal, dass mich die AIO über barrier=block und einen grade2 Track mit motor_vehicle=agricultural routen möchte? Cloudemate schlägt die gleiche falsche Route vor (jetzt weiß ich, wo die Skobbler-Fehler herkommen), OpenRouteService macht es richtig.

SunCobalt wrote:

ist es normal, dass mich die AIO über barrier=block und einen grade2 Track mit motor_vehicle=agricultural routen möchte? Cloudemate schlägt die gleiche falsche Route vor (jetzt weiß ich, wo die Skobbler-Fehler herkommen), OpenRouteService macht es richtig.

Weil ORS geschickterweise Autos generell nicht über tracks routet. 😉

Was die AIO angeht: Man muss es im Style so programmieren, der default-mkgmap Style kann das nicht.
Ist denn die Barriere mit den korrekten access-tags versehen?

Chris

chris66 wrote:

Ist denn die Barriere mit den korrekten access-tags versehen?
Chris

oops, ich dachte die Technik wäre soweit und wusste, dass Autos nicht über auf dem Weg liegende Steinblöcke hüpfen können ;-)
Aber dann versehe ich die Barriere mal mit den entsprechenden Access Tags. Wobei mir nicht ganz klar ist warum das helfen sollte. Wenn motor_vehicle=agriculatural des Weges ignoriert wird, warum sollte dann bspw motorcar=no des Barrieren-Knoten beachtet werden? *grübel*

Vielen Dank für die Info bezüglich ORS.

Grüße
Thomas

Hallo an alle die hier aktiv sind und viele neue Dinge ausprobieren.
Habt ihr Interesse direkt an der AiO mitzuarbeiten und Zugang zu den Styles und build skripten zu bekommen?
Ich schau hier alle paar Tage mal rein und denke manchmal mich erschlägts, wenn hier so viele Dinge ausprobiert werden und die AiO hier und da Blödsinn macht etc.
Manchmal ist wohl nur hier und da was in den Styles zu ändern oder hier und da ne mkgmap option mehr zu setzen oder rauszunehmen.
Manchmal liegen die Fehlerchen ja auch in den OSM-daten, aber das prüf ich auch nicht alles nach und es kann ja auch von den Leuten selbst berichtigt werden.

Ich fänd es jedenfalls super, wenn die AiO mehr zum Gemeinschaftswerk werden könnte und ich nicht alles selbst einbauen muss, vor allem, wenn ich oftmals weniger Ahnung habe als ihr.
Wenn ihr Lust habt, können wir auch ne kleine Mailingliste einrichten oder sowas, denn das Forum hier, find ich manchmal ganz schön krampfig und es wird auch nicht gerade übersichtlicher je länger es wird.

Die Verwaltung der Stylefiles läuft ja momentan mit git - ich hoffe das ist ok. Ich müsste jetzt noch meine skripte auf dem server irgendwie tracken, denn das Makefile ist mittlerweile recht komplex geworden und sollte ja auch für euch zugänglich sein, wenn ihr mitmachen wollt.

Außerdem wollte ich noch fragen, ob ich irgendwie mal die mkgmap logs zur Verfügung stellen soll und wie ich das am schönsten mache - hab da auch keine Ahnung von.
Wie sollte denn so ein logging.properties aussehen? Kann ich den ganzen Kram in ne Datei umleiten oder schreibt mkgmap immer ins aktuelle Verzeichnis irgendeine logdatei?
Nützt das überhaupt?

Viele Grüße!
Christoph

master wrote:

Hallo an alle die hier aktiv sind und viele neue Dinge ausprobieren.
Habt ihr Interesse direkt an der AiO mitzuarbeiten und Zugang zu den Styles und build skripten zu bekommen?

Aber sicher.

master wrote:

Die Verwaltung der Stylefiles läuft ja momentan mit git - ich hoffe das ist ok. Ich müsste jetzt noch meine skripte auf dem server irgendwie tracken, denn das Makefile ist mittlerweile recht komplex geworden und sollte ja auch für euch zugänglich sein, wenn ihr mitmachen wollt.

Bevor man mitmachen kann, muss man allerdings nachvollziehen können wie die Karte entsteht. Das kann man in weiten Teilen nur erraten. Die Styles sind ja mittlerweile verfügbar. Die mkgmap-Paramter waren zeitweise ebenfalls verfügbar. Z.Zt. enthalten die Dateien aber nur noch einen Teil der Informationen. Viele Parameter wurden wohl ausgelagert mit z.B -c /osm/garmin/aio/germany/gbasemap/template.args. Der Inhalt dieser Datei bleibt unbekannt.

Genaueres über den Splitvorgang ist nicht bekannt. Seit einigen Wochen splittest Du wohl völlig anders als vorher. Die Kacheln haben jetzt sprechende Namen mit Ortsangaben. Wie machst Du das?

Warum machst Du nicht auch dein Makefile und die dazugehörige Toolchain zugänglich?

Ich denke, es ist unerlässlich, dass man lokal für Tests die Karte bauen kann. Dazu muss aber der gesamte Bauvorgang bekannt und nachvollziehbar sein.

master wrote:

Außerdem wollte ich noch fragen, ob ich irgendwie mal die mkgmap logs zur Verfügung stellen soll und wie ich das am schönsten mache - hab da auch keine Ahnung von.
Wie sollte denn so ein logging.properties aussehen?

Ich denke, Logs machen nur dann Sinn, wenn man ganz gezielt auf eine bestimmte Eigenschaft schaut. Ein pauschales Log für alles wäre wohl gigantisch groß.

Log-Ausgaben des Packetes 'RestrictionRelation' für den basemap-Layer erstelle ich z.B. mit folgender Datei 'basemap-logging.properties':

#␣The␣default␣level␣FINE,␣WARNING,␣INFO,␣SEVERE
.level=SEVERE
handlers:␣java.util.logging.FileHandler
#␣package␣or␣class␣name␣with␣.level␣appended␣and␣then␣the␣level
uk.me.parabola.mkgmap.reader.osm.RestrictionRelation.level=FINE
#␣For␣FileHandler
java.util.logging.FileHandler.level=FINE
java.util.logging.FileHandler.formatter=uk.me.parabola.log.UsefulFormatter
java.util.logging.FileHandler.limit=5000000
java.util.logging.FileHandler.count=9
java.util.logging.FileHandler.pattern=mkgmap.log
java.util.logging.FileHandler.append=false

Dieses Log wächst für die Deutschlandkarte auf 5 Dateien mit je fast 5MB an.

Aus diesen Log-Dateien wird dann die gewünschte Information gezielt extrahiert. z.B. die beteiligten Knoten an den Abbiege-Restriktionen an der hier diskutierten Kreuzung. Auszug aus dem Makefile:

define␣LAYER_MKGMAP_basemap_LOG_FILTER_SHORT
sed␣'s/)␣/\n/'␣|␣sed␣'1␣s/^␣//'␣|␣sed␣'s/^␣.*//'␣|␣grep␣'.'\
|␣sed␣'/␣node␣is␣/␣s/^/\n/'␣|␣sed␣'/␣added␣/␣s/^/\n/'
endef

define␣LAYER_MKGMAP_basemap_LOG_FILTER
[␣-e␣$(@D)/mkgmap.log.0␣]␣&&\
(␣cut␣-d␣'␣'␣-f␣3,4,6-␣$(@D)/mkgmap.log.*␣>$(@D)/mkgmap.mlog\
;␣sed␣-n␣'/183514/␣s/^/␣/p'␣$(@D)/mkgmap.mlog␣|␣$(LAYER_MKGMAP_basemap_LOG_FILTER_SHORT)\
>␣$(@D)/mkgmap.mlog.rel-183514\
;␣sed␣-n␣'/183515/␣s/^/␣/p'␣$(@D)/mkgmap.mlog␣|␣$(LAYER_MKGMAP_basemap_LOG_FILTER_SHORT)\
>␣$(@D)/mkgmap.mlog.rel-183515\
;␣sed␣-n␣'/194488/␣s/^/␣/p'␣$(@D)/mkgmap.mlog␣|␣$(LAYER_MKGMAP_basemap_LOG_FILTER_SHORT)\
>␣$(@D)/mkgmap.mlog.rel-194488\
;␣grep␣'WARN'␣$(@D)/mkgmap.mlog␣>␣$(@D)/mkgmap.mlog.WARN\
);␣exit␣0
endef

Für die Restriktion 183515 sieht das so aus:

FEIN (RestrictionRelation): Turn restriction http://www.openstreetmap.org/browse/relation/183515 (at http://www.openstreetmap.org/?mlat=51.2 … 32&zoom=17

only_straight_on 'via' node is http://www.openstreetmap.org/?mlat=51.2 … 32&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17

only_straight_on 'to' node is http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17

only_straight_on 'from' node is http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17
only_straight_on adding 'other' node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17

only_straight_on added - allows routing to way http://www.openstreetmap.org/browse/way/32524422
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 35&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 24&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 85&zoom=17
only_straight_on blocks routing to node http://www.openstreetmap.org/?mlat=51.2 … 22&zoom=17

Hier kann man sehen, dass der sogenannte to-node (fett hervorgehoben) fälschlicherweise in die Liste der blockierten Knoten aufgenommen wird (ebenfalls fett hervorgehoben).

Die mkgmap.mlog.WARN enthält z.B. haufenweise Hinweise auf fehlerhafte oder nicht unterstüzte (z.B. no_u_turn) Restriktionen.

master wrote:

Kann ich den ganzen Kram in ne Datei umleiten oder schreibt mkgmap immer ins aktuelle Verzeichnis irgendeine logdatei?

Den Namen der Logdatei (relativ zum aktuellen Verzeichnis) kann man in der .properties-Datei festlegen. (siehe oben)

geopia wrote:

Bevor man mitmachen kann, muss man allerdings nachvollziehen können wie die Karte entsteht. Das kann man in weiten Teilen nur erraten. Die Styles sind ja mittlerweile verfügbar. Die mkgmap-Paramter waren zeitweise ebenfalls verfügbar. Z.Zt. enthalten die Dateien aber nur noch einen Teil der Informationen. Viele Parameter wurden wohl ausgelagert mit z.B -c /osm/garmin/aio/germany/gbasemap/template.args. Der Inhalt dieser Datei bleibt unbekannt.

Genaueres über den Splitvorgang ist nicht bekannt. Seit einigen Wochen splittest Du wohl völlig anders als vorher. Die Kacheln haben jetzt sprechende Namen mit Ortsangaben. Wie machst Du das?

Warum machst Du nicht auch dein Makefile und die dazugehörige Toolchain zugänglich?

Ich denke, es ist unerlässlich, dass man lokal für Tests die Karte bauen kann. Dazu muss aber der gesamte Bauvorgang bekannt und nachvollziehbar sein.

Sorry, ich hatte früher da noch Passwörter drin und so. Mittlerweile aber nicht mehr. Ich hab jetzt mein Makefile mal zugänglich gemacht, bin mir aber nicht sicher in wie fern da jemand anderes durchsehen kann.
Ich hab mal angefangen ein bisschen zu kommentieren - vielleicht hilfts ja.

http://dev.openstreetmap.de/aio/Makefile

Ich habe eine Ordnerstruktur für jede Region, die ich durchrechnen möchte. Die Regionen kommen ursprünglich von den namen der geofabrik extrakte.
Prinzipiell funktioniert das Makefile nach anpassen der Pfade und besorgen der benötigten programme so:

Erstmal eine Ordnerstruktur für eine Region anlegen:
make REGION=europe structure

dann einfach:
make REGION=europe

und schon wird europa gerechnet.

Weiterhin gibt es eine beliebig erweiterbare Regionlist mit Regionen, bei denen IS_PART_OF auf europa gesetzt wird.
Das bedeutet, dass die entsprechenden Kacheln der Region aus den bereits berechneten Kacheln von Europa zusammengesucht und neu verbunden werden.
Deutschland wird quasi aus Europa extrahiert. Das löst das Küstenproblem und gibt gleich noch ein bisschen mehr Karte über die Landesgrenzen hinaus.
Es werden per Postgis alle Kacheln verwendet, die das Länderpolygon Deutschland beispielsweise berühren. Also auch Kacheln, die nur nen winzigen Zipfel in deutschland haben, gehören zum Deutschlandauszug.

Ein weiterer Parameter ist USE_OLD_AREAS_LIST, um dem splitter mitzuteilen, dass er die areas.list vom vorherigen Mal nehmen soll, um Rechenzeit zu sparen.

Das makefilel hat mehrere Targets.

das gmapsupp.img erstellt die gmapsupp durch zusammenfassen aller Teilkarten (basemap, addr, fixme...)
Die wiederum haben alle ihre eigenen Targets und sind abhängig vom splittertarget.
Kern von den ganzen Teilkartenbasteleien ist die do_stuff Funktion (eigentlich so ne Art Variable, die durch die call-funktion mit parametern expandiert wird).
$(1) enthält den namen der teilkarte also z.B. "basemap" oder "fixme" und $(2) die mkgmap parameter.
$(3) enthält die mkgmap input daten bzw. die -c template.args vom splitter. In den template.args stehen keine weiteren mkgmap optionen außer die namen und ids der inputdateien. Im Prinzip das, was der Tilesplitter ausgibt, nur ein wenig mit sed-magie angepasst.

Interessant ist vielleicht noch, wie die mkgmap optionen zustande kommen.
Ich habe oben mehrere variablen definiert.
Einmal OPTIONS für allgemeine mkgmap optionen.
Dann GBASEMAPOPTIONS für die optionen des basemaplayers, da die sich wesentlich von denen der anderen transparenten overlays unterscheiden.
NOBASEMAPOPTIONS ist also für die restlichen overlays.

In jedem target, wird das nochmal erweitert mit der entsprechenden family- und product-id des jeweiligen layers und fertig.

Dann gibts noch hier und da ein paar Tricks und Kniffe und etwas sed-mystik, aber ich glaube, das ist nicht so wesentlich und man kann das auch leicht selbst ausprobieren, wenn man möchte.
Stehe für jegliche Rückfragen gerne zur Verfügung 😉

Magst du mir bei dem ganzen Loggingkram helfen und das mit in mein makefile einbauen? Ich seh mal zu, dass ich das auch in ein git repository bekomme, vielleicht in das von den stylefiles oder ein extra repo?

Grüße
Christoph

master wrote:

Erstmal eine Ordnerstruktur für eine Region anlegen:
make REGION=europe structure

dann einfach:
make REGION=europe

und schon wird europa gerechnet.

Na ich seh gerade, ganz so einfach wirds wohl doch nicht zu hause zum ausprobieren gehen. Ihr habt ja auch kein webverzeichnis in das ihr das kopieren wollt und so.
Da müsste man aus der do_stuff funktion erstmal alle teile rausschmeißen, die sachen ins WEBDIR kopieren und da symlinks anlegen und so. Ist ja aber nicht so stressig.

master wrote:

Ich hab jetzt mein Makefile mal zugänglich gemacht, ...
http://dev.openstreetmap.de/aio/Makefile

Danke, das ist doch schon mal was...

master wrote:

Stehe für jegliche Rückfragen gerne zur Verfügung 😉

Davon werde ich später noch Gebrauch machen.

master wrote:

Magst du mir bei dem ganzen Loggingkram helfen und das mit in mein makefile einbauen?

Was möchtest Du denn konkret loggen? Wie gesagt, 'alles' ergäbe gigantische Dateigrößen.

master wrote:

Ich seh mal zu, dass ich das auch in ein git repository bekomme, vielleicht in das von den stylefiles oder ein extra repo?

Wie wäre es mit einem Repo in dem alle Bestandteile deiner Befehlskette enthalten sind: makefile, styles , TYP-Files, ...

Ich habe mir für meine Experimente eine make-basierte Befehlskette bestehend aus mehreren makefiles mit zugehörigen config-Dateien erstellt:

- Die make-basierte Befehlskette erzeugt eine Datei gmappsupp.img ähnlich der AIO-Karte

- Es wird automatisch eine geeignete Verzeichnisstruktur erstellt für:
- heruntergeladene Daten
- ausgepackte Programme
- kompilierte Programme
- installierte Programme
- Archiv der Programmversionen
- splitter Cache
- Kacheln
- Styles
- getrennte Verzeichnisse für Layer: basemap, addr, boundary fixme, osb, ...
- jede fertige gmapsupp.img erhält ein Verzeichnis mit Datum im Namen und den Logfiles

- Sämtliche benötigten Dateien für Programme und OSM-Daten werden bei Bedarf automatisch heruntergeladen:
- osm: http://download.geofabrik.de/osm/
- splitter: http://www.mkgmap.org.uk/splitter/
- mkgmap: http://www.mkgmap.org.uk/snapshots/
- osmsql2osm: http://tuxcode.org/john/osbsql2osm/
- gmt: http://www.anpo.republika.pl/files/
- styles: http://dev.openstreetmap.de/aio/
- contours: todo

- Die benötigten Programme werden automatisch heruntergeladen, ausgepackt und, wenn notwendig, kompiliert.

- Es werden bei Änderungen an den Konfigurationsdateien abhängigkeitsgesteuert immer nur genau die notwendigen Schritte bis zu einer gmapsupp.img durchgeführt.
z.B.: Bei Änderung an mkgmap Parametern für den Layer basemap wird automatisch nur genau der basemap-Layer neu gebaut und dann mit gmt alles zusammengefügt.

Hier ein Auszug aus der Beschreibung der makefile Ziele:

make [all]
- erzeugt eine fertige gmapsupp.img
- vorhandene Programme werden ohne Überprüfung auf Aktualität verwendet.
Programme werden nur dann heruntergeladen, wenn sie nicht vorhanden sind
- vorhandene OSM/OSB-Daten werden ohne Überprüfung auf Aktualität verwendet.
OSM/OSB-Daten werden nur dann heruntergeladen, wenn sie nicht vorhanden sind.

make osb.download osm.download all
- erzeugt eine fertige gmapsupp.img
- Vorhandene Programme werden ohne Überprüfung auf Aktualität verwendet.
Programme werden nur dann heruntergeladen, wenn sie nicht vorhanden sind
- Vorhandene OSM/OSB-Daten werden online auf Aktualität geprüft.
Die vorhandenen OSM/OSB-Daten werden verwendet, wenn keine aktuelleren Daten verfügbar sind.
OSM/OSB-Daten werden nur dann heruntergeladen, wenn sie nicht vorhanden oder veraltet sind.

make archive osb.download osm.download all
- erzeugt eine fertige gmapsupp.img
- Vorhandene Programme werden online auf Aktualität geprüft.
Vorhandene Programme werden verwendet, wenn keine aktuelleren Programme verfügbar sind.
Programme werden nur dann heruntergeladen, wenn sie nicht vorhanden oder veraltet sind
- Vorhandene OSM/OSB-Daten werden online auf Aktualität geprüft.
Die vorhandenen OSM/OSB-Daten werden verwendet, wenn keine aktuelleren Daten verfügbar sind.
OSM/OSB-Daten werden nur dann heruntergeladen, wenn sie nicht vorhanden oder veraltet sind.

Damit kann man gezielt experimentieren ohne immer alles komplett neu zu bauen.
Diese Eigenschaft wäre für deinen einmal täglich laufenden Job sicher nicht so wichtig. Aber zum Testen ist das sehr nützlich.

Ich denke, eine solche Befehlskette sollte in dein Repo.

Erst einmal ein großes DANKE an die Erfinder der Aio! Das ist eine ganz prima Karte.
Ich benutze die Karte auf einem Oregon 550 zum Radeln, Wandern und Autofahren.
Mit dem Original-Typ-File ist die Karte auf dem Oregon jedoch nur schwer ablesbar. Die Wege sind zu dünn und die Landschaften zu dunkel. Mittels des Online-Typfile-Editors habe ich mir das angepasst, so dass die Karte jetzt fast perfekt aussieht.

Folgende Verbesserungen wären noch schön:

- Auf Bundes- Landes und Kreisstraßen beim Routen den Namen einblenden, nicht nur die Nummer
- beim Routen Vermeidung von allen nicht asphaltierten Wegen.
- größere Städtenamen
- Bundes- Landes und Kreisstraßen mit Namen beschriften, nicht nur die Nummer.
- beim Routen auf Autobahnen die Nummer und den Namen der Ausfahrt einblenden.

Wie das technisch alles zusammenhängt verstehe ich nicht. Falls ich selbst irgendetwas von oben genannten Punkten einstellen kann, bitte für Dummis erklären.

So sieht´s aus:

speichennippel wrote:

Erst einmal ein großes DANKE an die Erfinder der Aio! Das ist eine ganz prima Karte.
Ich benutze die Karte auf einem Oregon 550 zum Radeln, Wandern und Autofahren.
Mit dem Original-Typ-File ist die Karte auf dem Oregon jedoch nur schwer ablesbar. Die Wege sind zu dünn und die Landschaften zu dunkel. Mittels des Online-Typfile-Editors habe ich mir das angepasst, so dass die Karte jetzt fast perfekt aussieht.

Naja, vielleicht sind deine Verbesserungen ja für alle gut. Du kannst mir ja am besten mal dein verbessertes Typfile schicken und sagen, was du alles verbessert hast.
So wie dein Screenshot aussieht, hast du wohl auch einige Symbole ersetzt.

Folgende Verbesserungen wären noch schön:

- Auf Bundes- Landes und Kreisstraßen beim Routen den Namen einblenden, nicht nur die Nummer

Gabs neulich nen update in mkgmap dazu. Ich seh mir das mal an.

- beim Routen Vermeidung von allen nicht asphaltierten Wegen.

Gibts schon. Du musst einfach nur irgendwo in deinen Routingoptionen ein Häckchen setzen bei:
"Vermeide ungeteerte Straßen" oder so.

- größere Städtenamen

Weiß gerade nicht, ob und wie man besten die Schriftgröße einstellt, aber könnte im Typfile gehen.

- Bundes- Landes und Kreisstraßen mit Namen beschriften, nicht nur die Nummer.

Wie gesagt - gabs neulich nen update bei mkgmap...

- beim Routen auf Autobahnen die Nummer und den Namen der Ausfahrt einblenden.

Muss mal sehen, was sich da machen lässt.

Wie das technisch alles zusammenhängt verstehe ich nicht. Falls ich selbst irgendetwas von oben genannten Punkten einstellen kann, bitte für Dummis erklären.

Naja, ich glaube da kannste erstmal selber nicht so viel machen, wenn du dich nicht gerade mit den stylefiles von mkgmap auseinandersetzen willst, die allerdings nicht sehr schwer zu verstehen sind 😉
Ich schau mal, was so geht.

Grüße
Christoph

http://www.arndt.homepage.t-online.de/40947.html

Auf der Seite ganz unten ist das Typ-File zum runterladen.

Ich habe im Grunde nur die Farben heller gemacht und alle Straßen dicker. Autobahnen sind blau mit rotem Rand, große Straßen sind gelb, alle anderen weiß. Die unbefestigten Wege sind auch ganz dick und sehen alle gleich aus. Teilweise habe ich sie umbenannt (z.B. Gerade2 in Fußweg).

Die Städtenamen bekomme ich nicht groß. Im Typ-File kann man zwar sagen, "große Beschriftung", aber das hat keine Auswirkung. Im Bild oben, wäre das "Lennep". Mit den Textgrößen vom Oregon kann man einstellen, was man will, da ändert sich nichts.

Das Bild oben hat den Fehler, dass die Straßennamen nicht angezeigt werden. Das passiert, wenn man im Oregon die Option "Textgröße der Kartenpunkte" nicht auf "kein" gestellt hat. Dann erscheinen auch irgendwelchen komischen Symbole, z.B. werden Ampeln durch rote Rauten auf weißem Grund ersetzt.

Ich hänge noch mal ein neues Bild an.

Da sieht man auch, dass das mit dem Routing auf unbefestigten Wegen nicht hinhaut. Mit Mapsource geht es auch nicht.
Eingestellt ist: "Fahrrad", "kürzere Zeit" und "unbefestigte Wege vermeiden". Bei Mapsource zusätzlich noch "wenig befahrene Straßen bevorzugen". Diese Einstellung hat das Oregon jedoch nicht. Damit MS und Oregon gleich routen muss dass so sein. Hat das Typ-File, welches ich ja verbogen habe, Einfluss auf die Streckenberechnung?

stylefiles von mkgmap. Dem Stichwort gehe ich mal nach.

speichennippel wrote:

Da sieht man auch, dass das mit dem Routing auf unbefestigten Wegen nicht hinhaut. Mit Mapsource geht es auch nicht.
Eingestellt ist: "Fahrrad", "kürzere Zeit" und "unbefestigte Wege vermeiden". Bei Mapsource zusätzlich noch "wenig befahrene Straßen bevorzugen". Diese Einstellung hat das Oregon jedoch nicht. Damit MS und Oregon gleich routen muss dass so sein. Hat das Typ-File, welches ich ja verbogen habe, Einfluss auf die Streckenberechnung?

Soviel ich weiss nicht. Damit es mit der "Unbefest.Straßen vermeiden" klappt müssen im Style File einige
Zeilen hinzugefügt werden. Im default-mkgmap-style ist das aber schon drin (mkgmap:unpaved Attribut).

Klappt bei mir in MS und aufm Etrex prima.

Grüße
Chris

Außer dem Typ-File habe ich wissentlich nichts geändert. Die Karte habe ich mir gestern neu von der Wiki-Seite geladen, die Europakarte. Mit MapSetToolkit habe ich die in MS eingebaut.

In dem typ-File gibt es Linie #10) Typ 0x0a [Unpaved Road-thin] /unbefestigt. Vielleicht wirkt die Routingeinstellung nur darauf?
Das sind jedoch die wenigsten Wege. Die meisten sind irgendwas mit "Grade" oder halt Linie #12) Typ 0x0d [Pedestrian area]

Was ist das "style-File" und wo finde ich das?

LG
Arndt

Hallo Arndt,

das "Style-File", oder besser "die Style-Files" sind Dateien, die für die Erzeugung mit Mkgmap festlegen, welche Targets aus den Rohdaten ausgewertet werden (also welche Linien, Flächen, POIs), welchen Garmin-Typ (Integer) sie jeweils erhalten und sie bekommen weitere Eigenschaften wie die Zoomstufe, Routing-Flags etc. zugewiesen. Das Beispiel einer unbefestigten Straße beinhaltet mindestens folgende Infos:
highway=* & surface=dirt {add mkgmap:unpaved=1} (macht Straßen/Wege mit diesem surface-tag zu "unbefestigt")
highway=track & tracktype=grade4 [0x11 road_class=0 road_speed=0 resolution 22] (nimmt diese Wege in die Karte auf)
Das bedeutet, tiefergreifende Änderungen, die über das Aussehen hinausgehen, erfordern einen kompletten Eigenbau der Karte.

Die Größe der Straßenbeschriftung lässt sich übrigens direkt am Gerät beeinflussen: Einstellung -> Karte -> Erweiterte Karteneinstellungen. Eine dahingehende Änderung im Typfile wirkt da eher nur in Mapsouce, nicht im Gerät.

Grüße
Mario

Das habe ich verstanden. Aber eine Karte selber bauen ist mir zu hoch 😉 Die AiO ist ja nahezu perfekt.
Die Straßennamengröße ist kein Problem, sondern die Größe der Ortsnamen. Aber da kann man ja einfach die boundarys einschaltet, dann sieht man auch, wo welcher Ort ist.

Ich habe mir das Routing noch mal genau angeschaut. Tatsächlich werden unbefestigte Wege vermieden. Auch Grade 2-5.
Nur der Typ Typ 0x0d [Pedestrian area] "Fuß/Wanderweg" wird nicht vermieden. Das ist zumindest hier in Remscheid zu 99% Waldweg, untauglich fürs RR.

Also das mit den unpaved roads sieht im default mkgmap style und bei mir so aus:

#␣Flag␣unpaved␣roads.
highway=*
&␣(surface=cobblestone␣|␣surface=compacted␣|␣surface=dirt␣|
surface=earth␣|␣surface=grass␣|␣surface=grass_paver␣|
surface=gravel␣|␣surface=grit␣|␣surface=ground␣|␣surface=mud␣|
surface=pebblestone␣|␣surface=sand␣|␣surface=unpaved␣|
mtb:scale=*␣|
tracktype␣~␣'grade[2-6]'␣|
smoothness␣~␣'.*(bad|horrible|impassable)'␣|
sac_scale␣~␣'.*(mountain|alpine)_hiking'␣|
sport=via_ferrata)
{␣add␣mkgmap:unpaved=1␣}
(highway=bridleway␣|␣highway=path␣|␣highway=track␣|␣highway=unsurfaced)
&␣surface!=*␣&␣tracktype!=*␣&␣smoothness!=*␣&␣sac_scale!=*
{␣add␣mkgmap:unpaved=1␣}

Ich hatte das schon vor langer Zeit bei mir mal eingebaut und es sollte eigentlich funktionieren.
Das ist auch unabhängig von dem benutzten Garminlinientyp.

Grüße
Christoph

speichennippel wrote:

Nur der Typ Typ 0x0d [Pedestrian area] "Fuß/Wanderweg" wird nicht vermieden. Das ist zumindest hier in Remscheid zu 99% Waldweg, untauglich fürs RR.

Hi, dann ist der Weg halt unvollständig getaggt. Wenn der unbefestigt ist, sollte ein surface=unpaved oder so dran stehen.
Chris

chris66 wrote:

speichennippel wrote:

Nur der Typ Typ 0x0d [Pedestrian area] "Fuß/Wanderweg" wird nicht vermieden. Das ist zumindest hier in Remscheid zu 99% Waldweg, untauglich fürs RR.

Hi, dann ist der Weg halt unvollständig getaggt. Wenn der unbefestigt ist, sollte ein surface=unpaved oder so dran stehen.
Chris

Das wird wohl die Lösung sein 🙂. Ich habe mal in meiner Umgebung bei mir bekannten Wegen ein "unpaved" angehängt und werde das testen, sobald die Daten durch die Instanzen gewandert sind.

geopia wrote:

master wrote:

Magst du mir bei dem ganzen Loggingkram helfen und das mit in mein makefile einbauen?

Was möchtest Du denn konkret loggen? Wie gesagt, 'alles' ergäbe gigantische Dateigrößen.

Naja ich stell mir das so vor, dass es Logausgaben gibt, die auf Fehler in den Daten hinweisen.
Diese könnte man ja für Mapper veröffentlichen, damit sie da mal nachsehen können.
Quasi mkgmap als Datenanalysetool 😉

Und dann gibts noch die Art von Logs, die auf Skriptfehler oder bugs in mkgmap oder was weiß ich hindeuten.
Die sind dann eher für Entwickler interessant.

Beides würde ich jedenfalls am liebsten getrennt voneinander haben. Meinst du das geht?

master wrote:

Ich seh mal zu, dass ich das auch in ein git repository bekomme, vielleicht in das von den stylefiles oder ein extra repo?

Wie wäre es mit einem Repo in dem alle Bestandteile deiner Befehlskette enthalten sind: makefile, styles , TYP-Files, ...

Ich habe mir für meine Experimente eine make-basierte Befehlskette bestehend aus mehreren makefiles mit zugehörigen config-Dateien erstellt:

- Die make-basierte Befehlskette erzeugt eine Datei gmappsupp.img ähnlich der AIO-Karte

- Es wird automatisch eine geeignete Verzeichnisstruktur erstellt für:
- heruntergeladene Daten
- ausgepackte Programme
- kompilierte Programme
- installierte Programme
- Archiv der Programmversionen
- splitter Cache
- Kacheln
- Styles
- getrennte Verzeichnisse für Layer: basemap, addr, boundary fixme, osb, ...
- jede fertige gmapsupp.img erhält ein Verzeichnis mit Datum im Namen und den Logfiles

- Sämtliche benötigten Dateien für Programme und OSM-Daten werden bei Bedarf automatisch heruntergeladen:
- osm: http://download.geofabrik.de/osm/
- splitter: http://www.mkgmap.org.uk/splitter/
- mkgmap: http://www.mkgmap.org.uk/snapshots/
- osmsql2osm: http://tuxcode.org/john/osbsql2osm/
- gmt: http://www.anpo.republika.pl/files/
- styles: http://dev.openstreetmap.de/aio/
- contours: todo

- Die benötigten Programme werden automatisch heruntergeladen, ausgepackt und, wenn notwendig, kompiliert.

- Es werden bei Änderungen an den Konfigurationsdateien abhängigkeitsgesteuert immer nur genau die notwendigen Schritte bis zu einer gmapsupp.img durchgeführt.
z.B.: Bei Änderung an mkgmap Parametern für den Layer basemap wird automatisch nur genau der basemap-Layer neu gebaut und dann mit gmt alles zusammengefügt.

Also du brauchst nicht mehr gmt zu benutzen. mkgmap kann das jetzt selber korrekt mit der --gmapsupp option.
Ansonsten hab ich das ähnlich wie du, außer dass ich die ganzen Programme nicht automatisch baue und hinwerfe.
Das hatte ich früher mal so gemacht, aber das ist nicht wirklich klug. Wenn da mal n bug reinkommt, hab ich den sofort in meinem Prozess.
Außerdem aktualisieren sich die Programme nicht so oft, als dass ich sie nicht manuell updaten könnte, betrifft ja eigentlich hauptsächlich nur mkgmap.

Ich denke, eine solche Befehlskette sollte in dein Repo.

Also mein Makefile liegt jetzt mit in meinem Repo. Vielmehr ist es eigentlich nicht, was ich so mache.
http://github.com/aiomaster/aiostyles
Ich bastel auch immer wieder n bissel dran rum, also ab und zu mal reinschaun lohnt sich.

Grüße
Christoph

Hallo Christoph,

seit ein paar Tagen ist unser Neckar in deiner Karte weiß dargestellt. Hast du was an den Flüssen geändert?

Grüße aus Heilbronx ... Gerd

Die AiO Map ist schon die meiner Meinung beste OSM-Karte für Garmin, aber ich hätte trotzdem noch einen Wunsch:

Um sich den langen Download der Karte zu ersparen, wäre es vielleicht sinnvoll, ähnlich wie die Karten von Raumbezug (http://www.raumbezug.eu/ag/internet/osmGarmin.htm) einzelne Bundesländer anzubieten.
Das würde wahrscheinlich den meisten hier reichen, da man die Karte meist nur in seiner näheren Umgebung zum Mappen braucht.
Falls doch jemand mehr braucht, kann er sich ja immer noch ganz Deutschland herunterladen.

Einige Abraumhalden in meiner Umgebung habe ich mit natural=hill statt natural=peak getaggt, da es keine richtigen Berge mit einem höchsten Punkt sind, sondern nur oben ebene Hügel. Es wäre schön, wenn die auch in der Karte erscheinen würden, wenn auch nur wie ein normaler Berggipfel, das würde mir schon reichen.

Achso: Und als Sahnehäubchen noch natural=valley einbauen, das ist in den Bergen beim Wandern immer ganz praktisch.

Warum der Neckar weiß ist, weiß ich nicht. Geändert hab ich in an den Flüssen nichts!
Am besten weiter beobachten das Problem.

Ich habe heute noch ein bissel gebastelt und ab jetzt gibt es Bundesländerextrakte! Jeah!
Ich hab gerade keine Lust die ganzen Links ins Wiki zu tun. Möchte das jemand übernehmen?

Ihr findet den ganzen Kram wie üblich hier:
http://dev.openstreetmap.de/aio/

Außerdem gibts jetzt für alle Karten in den tar.bz2 files einen windowsinstaller, der die files in die richtigen Verzeichnisse kopiert.
Die files sind dabei nicht mehr im installer drin.
Somit sollte auch Europa wieder installierbar sein. Das Problem war, dass nicht mehr als 2GB in so nen doofen Windowsinstaller passen.

Für die kleineren Ausschnitte baue ich dennoch zusätzlich einen Windowsinstaller, der die Files enthält, wie bisher.

Viele Grüße
Christoph

Frage: Das sind jetzt aus der Deutschlandkarte herausgesplittete Karten der einzelnen Bundesländer, die zusammengesetzt wieder routingfähig sind!?

Also Bayern und Baden-Württemberg zusammen im Garmin und beide aktiviert ermöglichen ein Routing von München nach Stuttgart!?

Oder sind das nur die als bundesland.osm.bz2 erhältlichen Rohdaten in Karten umgerechnet und nur innerhalb des Bundeslandes routingfähig?

Danke,

flux.

Hey,

super Karte!

Laut der Bedienungsanleitung meines eTrex Legend HCx müsste für einen aufgezeichneten Track eine "Track Profile Page" (zeigt Höhenverlauf des Tracks) verfügbar sein, wenn die benutzte Karte über ein Digital Elevation Model (DEM) verfügt. Das liefert DE:All wohl leider nicht.

Lässt sich sowas aus SRTM-Daten erzeugen und in eine OSM-basierte Karte für Garmin integrieren? Wäre ein super Feature für Radfahrer.

flux wrote:

Frage: Das sind jetzt aus der Deutschlandkarte herausgesplittete Karten der einzelnen Bundesländer, die zusammengesetzt wieder routingfähig sind!?

Stimmt genau. Das bedeutet nämlich wenig zusätzlichen Rechenaufwand (das aufwändigste ist momentan das komprimieren)

Also Bayern und Baden-Württemberg zusammen im Garmin und beide aktiviert ermöglichen ein Routing von München nach Stuttgart!?

Naja, also wenn du Bayern und Baden-Württemberg runterlädst, hast du garantiert ein paar Kacheln doppelt.
Was dann genau passiert, wenn du routen möchtest, kann ich nicht sagen. Würde vorschlagen du probierst es mal aus. Könnte vielleicht klappen...

NufRadler wrote:

Hey,

super Karte!

Laut der Bedienungsanleitung meines eTrex Legend HCx müsste für einen aufgezeichneten Track eine "Track Profile Page" (zeigt Höhenverlauf des Tracks) verfügbar sein, wenn die benutzte Karte über ein Digital Elevation Model (DEM) verfügt. Das liefert DE:All wohl leider nicht.

Lässt sich sowas aus SRTM-Daten erzeugen und in eine OSM-basierte Karte für Garmin integrieren? Wäre ein super Feature für Radfahrer.

Hab ich auch schon drüber nachgedacht. Weiß jemand, ob das einfach geht und wo ich so ein DEM herbekomme? Hab da leider nichts passendes gefunden.
Anscheinend hatte mkgmap mal sowas eingebaut - wurde aber sofort wieder rausgenommen, afaik wegen lizenztechnischer Probleme...

Weiß da jemand genaueres?

Grüße
Christoph

Ich habe das "unbefestigt vermeiden" noch mal getestet. Die AiO routet richtig und vermeidet Wege, wenn das Attribut "unpaved" dabeisteht. Leider ist das in den OSM-Daten oft nicht eingetragen. Aber man kann ja selbst Hand anlegen 🙂

Was nicht vermieden wird, sind Treppen. surface=stairs oder stairs=yes, diese beiden Schreibweisen habe ich gefunden.

highway=steps muss es heißen. Habe "meine" Treppe korrigiert und warte nun ab, wie das Routing sich damit verhält.

speichennippel wrote:

Ich habe das "unbefestigt vermeiden" noch mal getestet. Die AiO routet richtig und vermeidet Wege, wenn das Attribut "unpaved" dabeisteht. Leider ist das in den OSM-Daten oft nicht eingetragen. Aber man kann ja selbst Hand anlegen 🙂

Was nicht vermieden wird, sind Treppen. surface=stairs oder stairs=yes, diese beiden Schreibweisen habe ich gefunden.

Hmm, na ich hab mal die treppen (highway=steps) zu den unpaved Dingen hinzugetan, so dass die auch nicht verwendet werden, wenn man das unbefestigt vermeiden einstellt...

Wirkt sich erst morgen aus.

Ach ja, und ab morgen gibts nen maxspeed-layer, wenn alles klappt. Mal schaun.

Was soll denn surface=stairs oder stairs=yes aussagen? Es gibt doch eigentlich highway=steps.

Grüße
Christoph

Hallo an Alle!

Erstmal: Danke für diese geniale Map!

Aber, seit neuestem hab ich eben so eine Grafik.
Sollte sie nicht so aussehen?

Was mache ich falsch?

Die Styles habe ich nicht auf meinem Garmin Oregon 300, brauch ich bei der kompletten Europa-Map ja nicht. Hatte sie drauf, sah aber noch schlechter aus.

Irgendjemand eine Idee?

Danke,

Rosiv

Edit meint: Ich weiß, daß die Graphiken nicht gleich sind, aber so dunkel und unerkenntlich wars bisher eben noch nie, immer heller usw.

Super. Danke!
Ich habe mir mal die Anleitung zum mappen genauer durchgelesen. Verstehe das jetzt besser. Vor allem stehen da die korrekten keys 😉

Rosiv wrote:

Hallo an Alle!

Aber, seit neuestem hab ich eben so eine Grafik.
Sollte sie nicht so aussehen?

Was mache ich falsch?

Die Styles habe ich nicht auf meinem Garmin Oregon 300, brauch ich bei der kompletten Europa-Map ja nicht. Hatte sie drauf, sah aber noch schlechter aus.

Irgendjemand eine Idee?

Danke,

Rosiv

Hallo,

es funktioniert nicht, das Aussehen in Mapnik und in gedownloadeten Karten miteinander zu vergleichen. Mapnik rendert die Karte mit eigenem optischen Stil in Tiles als PNG, fertige Karten für Mapsource oder für's Gerät aber haben ein anderes Aussehen welches im Typfile definiert wird, letzteres wird wunschgemäß teilweise variieren. Außer dem Vergleich ist nichts falsch.

Grüße