Unbegrenzte Darstellung routingfaehiger Wege

Wer fuer Garmin Geraete Karten erstellt, wird ziemlich bald genervt feststellen muessen, dass die Routingfaehigen Typen 0x00-0x13, 0x16, 0x1a (0x1b begrenzt) einfach nicht ausreichen um gut klassifizierte Wege darzustellen.

Umgehen kann man dies recht einfach (zumindest wenn man mgkmap mit "continue patch" benutzt). So nimmt man einfach einen der obenstehenden Typen als reine unsichtbare Routingdarstellung (im Typfile komplett transparente Linie zeichnen, bei maptk muss man dies zurzeit im textfile machen - da es vom GUI Editor sonst zerstoert wird) und dann mit extended Types einfach unbegrenzte Moeglichkeiten fuer die Darstellung genießen.

Der unsichtbare Weg mit den Routinginformationen verlangsamt nicht die Kartendarstellung / oder beinflusst das Routing. Sprich unsichtbarer Weg plus extended Type mit der Darstellung ist genauso schnell gerendert wie ein einzelnen sichtbarer Weg, und kann sogar Geschwindigkeitsvorteile bringen. Etwa indem man Objekte in eine Linie zusammenfasst, die man sonst mit zwei Linien dargestellt haette.

Mit diesem Trick kann man a) eine Karte mit zwei verschiedenen Ansichtstypen je nach Zoommaßstab bauen (etwa resolution 24 breitere Straßen wie resolution 22) - oder auch einfach die breite der Straßen von der realen Breite (etwa da in OSM angegeben) abhaengig machen - ohne das Problem der nicht ausreichenden Typen zu haben.

Dargestellt im extended Lines bereich wird u.a.:
0x100* - 0x108*
0x109* (Konturlinien)
0x10a*
0x10b01 - 0x10b04
...
0x10d01- 0x10d04
0x10e*
0x10f*

also wirklich mehr oder weniger Unbegrenzt Spielraum um die perfekte Straßenabbildung zu erreichen.

Es sind zwar nicht sooooo viele (ich frage bei osm fuer fahrbare Wege etwa 50.000 Tag Kombinationen ab - also kann ich nicht jede unterschiedliche Tagging Kombination mit einer unterschiedlichen Darstellung benutzen) aber mehr als genug ohne das Problem zu bekommen dass die Unterschiede visuell nicht mehr wahrgenommen werden koennen.

Man sollte versuchen, dies nur fuer "exotische" Straßen zu machen - da dies natuerlich etwas mehr Speicherplatz braucht - da man die unsichtbare Straße aber nur in resolution=24 schreibt, ist dies gar nicht mal so viel (bei mir ist die gezippte Groeße der Karten nur um rund 1-2% gestiegen - da ich bei anderen Linientypen "sparen" konnte).

Außerdem ermoeglicht einem die Trennung von Routing infos und Darstellung auch einige Lines im style-file (wenn man sehr komplexe style-files benutzt).

Was nun leider weiterhin noch fehlt, ist die Moeglichkeit in mkgmap Straßen mit unterschiedlichen Routingprioritaeten zu schreiben die man durch access tags voneinander absondert. Dann waere es naemlich wirklich moeglich eine Karte fuer alle Benutzer zu schreiben die genauso gut fuer Autos routet - wie fuer Fahrradfahrer (dies wuerde dann aber die Karten schon recht stark aufblasen in der Groeße - und evtl das Routing verschlechtern).

Klingt genial! Und ist es wohl auch!
Hast Du mit Nop schon diskutiert, ob man die erweiterte Differenzierung der Liniendarstellung mit irgendeinem raffinierten Programmiertrick auch in den Composer einbauen kann? Der direkte Zugriff, wie Du ihn beschreibst, ist für einen gewieften Kartenbauer wie Dich sicherlich wesentlich sinnvoller. Aber ich komme mit dem Composer ganz gut klar und würde mich über so eine Erweiterung sehr freuen.

Mit weiteren Render-Experimenten (auch wegen der POIs) muß ich bis nach Weihnachten warten. ZZt ist einfach viel zu viel zu tun.

Viele Grüße
Eli

Hallo extremecarver,
ich würde mich dem Vorschlag von Wanderreiter anschließen wollen. Nop hat dazu im OSM-Forum nach hilfe gesucht. Ihm fehlt einer, der sich mit Routing in Verbindung mit mkgmap auskennt. Du hast auf diesem Gebiet eine Menge KnowHow und könntest hier sicherlich helfen, die Erstellung von routingfähigen OSM-Karten einer Menge Usern zu ermöglichen.

Viele Grüße,
Henning

OSM Composer finde ich einfach nur schrecklich kompliziert. Wenn du im Wiki von osm Composer (englische Version) besonders auf der Diskussionsseite mal in die Anfaenge gehst, siehst du eh dass ich damals "seitenweise" Verbesserungsvorschlage gemacht habe, oder Bugs aufgedeckt.

Die Gruende warum Routing mit meinen Karten meist sehr gut funktioniert, liegen daran dass mein lines File alleine fast 50.000 Linien Code umfasst - also zig Tag Kombinationen abfragt - das laesst sich sowieso nicht in osm composer integrieren. Meiner Meinung nach haette Nop statt einen Preprocessor zu schreiben, eher den Code dafuer in mkgmap einfließen lassen sollen, bzw bestehende mkgmap Funktionen fuer seine Sachen benutzen, anstelle von osm composer der a) Speicherhungrig ohne ende ist, b) saulangsam im Vergleich zu mkgmap alleine. Bis auf die Multilayersymbole fuer Wanderwege die verwendet werden, koennte man IMHO auch alles in mkgmap direkt umsetzen (braucht halt ein paar Zeilen Code mehr in den Style-Files).

Der Composer kompliziert? - Hmm. - Das ist eine Frage der Sichtweise. Er ist so gebaut, daß man auch dann zu einer Karte kommt, wenn man die Voreinstellungen läßt, wie sie sind und nur seine Koordinaten eingibt. Das finde ich als Einstieg sehr praktisch.

Nop entwickelt den Composer ständig weiter und er funktioniert für den Zweck, für den er gedacht ist inzwischen recht gut. Ohne ihn wäre ich wohl kaum dazu gekommen, eigene Karten zu generieren.

Eine routingfähige Karte zu bauen, interessiert mich nicht so sehr. Was mich neugierig macht, ist die von Dir erwähnte Möglichkeit, mit Hilfe von extendet Files die Darstellung des Wegenetzes zu differenzieren.

Anwendungsbeispiel:
Ich generiere die Tracks nach tracktype untergliedert:
tracktype 1 = schwarz
tracktype 2 = rot
tracktype 3 = gelb
tracktype 4 = mittelgrün
tracktype 5 = hellgrün
alle mit Rand = grün

Format: RMMR
(R=1 Randpixel / M= 1 Mittelpixel)

Fahrradweg = grau mit blauem Rand
Das ist nur eine Notlösung, da ich für weitere Differenzierungen keine IDs frei habe. Schöner wäre, wenn die mittlere Farbe ausgetauscht werden könnte und dadurch Hinweise auf die Wegdecke (Teer/Schotter etc.) geben würde.

Reitweg = sandfarben mit blauem Rand
Schöner wäre auch hier, wenn die Farben der Tracktypes erhalten blieben und die Randfarbe den Weg als Reitweg klassifiziert. Denkbar wäre auch, den Reitweg mit der Sandfarbe hervorzuheben (so wie ich es jetzt mache und dann mit Hilfe der Randfarbe auf die Art der Wegdecke hin zu weisen.

Umsetzbar sind die verschiedenen Layoutkonzepte nur, wenn man das ID-System erweitern kann.
Daß es prinzipiell geht, hast Du ja aufgezeigt. Nur leider ist der von Dir angedeutete Weg für mich zur Zeit nicht realisierbar.

Daher meine Frage.

Viele Grüße
Eli

extended types sind mit mkgmap bestimmt seit rund 200 revisionen moeglich, ob composer etwas von erweiterten types weiß, erschließt sich mir allerdings nicht. Noch dazu nehme ich nicht an, dass der osm composer mit "continue" patch funktioniert. Dafuer ist der Grundaufbau einfach viel zu verschieden.

tricksen muss man nur, wenn es einem um die Routingfaehigkeit geht.

Danke für die Info.

Viele Grüße
Eli

Hallo extemecarver,

Zitat von extemecarver

Wer fuer Garmin Geraete Karten erstellt, wird ziemlich bald genervt feststellen muessen, dass die Routingfaehigen Typen 0x00-0x13, 0x16, 0x1a (0x1b begrenzt) einfach nicht ausreichen um gut klassifizierte Wege darzustellen.
Umgehen kann man dies recht einfach (zumindest wenn man mgkmap mit "continue patch" benutzt).

genau dies versuche ich schon seit längerer Zeit erfolglos.
Ich will einfach das default-style von mkgmap ein bisschen erweitern, um track, path , cycleway und footway unterscheiden zu können.
Könntest du kurz skizzieren, wie die entsprechenden Einträge im style aussehen müssen?
Dass ich dann noch ein entsprechendes Typ-File bauen muss, sollte ich hoffentlich hinbekommen.

Besten Dank für deine Mühe.

Gruß Ralf

mkgmap mit "multiple elements" patch patchen (findest du auf der mailingliste) und dazu die erklaerungen lesen und dann halt Regeln wie highway=* & bicycle=* ... [0x*] verwenden. Nur um Track/Path/Cycleway/Footway auseinanderzuhalten, brauchts aber meinen obengenannten Hinweis garnicht - sind eh noch genug typen frei bzw Linien ohne Routing lassen sich umbelegen. Musst halt nur noch ein Typfile dazu anpassen.

Hallo extemecarver,

Zitat von extemecarver

Nur um Track/Path/Cycleway/Footway auseinanderzuhalten, brauchts aber meinen obengenannten Hinweis garnicht - sind eh noch genug typen frei bzw Linien ohne Routing lassen sich umbelegen. Musst halt nur noch ein Typfile dazu anpassen.

ein Routing über Track/Path/Cycleway/Footway würde ich aber gerne beibehalten. Und wenn ich es richtig sehe, müssten die von dir genannten routingfähigen Wege "aufgebraucht" sein.
Welche weiteren Linien sind denn frei und wie kann ich die umbelegen?

Gruß Ralf

Es sind nur die Typen 0x00-0x13 sowie 0x16 klassisch routingfaehig (plus 0x1a 0x1b fuer Faehren wobei 0x1b irgendwie sehr komisch funktioniert). Was du wie belegst ist vollkommen egal - du musst es nur im Typfile zuweisen.

Wenn dir die genannten routingfaehigen typen nicht ausreichen, dann musst du dir einfach einen davon auswaehlen, den du per typfile komplett unsichtbar machst, und wo du nun alle typen die Darstellbar sind zusaetzlich fuer die Anzeige zuweist - Auflistung siehe oben.

Soweit mir dein Kommentar erscheint, hast du noch nie einmal das "lines" File geoeffnet bzw weißt ueberhaupt nicht einmal die Basics fuers Kartenerstellen. Les dir einfach mal die cgpsmapper Anleitung von vorne bis hinten durch um die Grundlagen zu kapieren.

Zitat von extemecarver

Was du wie belegst ist vollkommen egal - du musst es nur im Typfile zuweisen.

hallo extremecarver,

da kann ich nur zur Göttin beten dass dein Beispiel nicht weiter "Schule" macht
http://imagemperegrinafunchal.blogspot.com/

Anton

@ Anton
Wo ist das Problem?
Erstellst Du selbst ebenfalls Karten?
Kannst Du erklären, warum Du die "freie" Verwendung von Typfiles ablehnst?

@ Felix
Im Prinzip sehe ich das ähnlich wie Du.
Bei einigen Linien scheint es aber doch nicht so ganz egal, zu sein, wie man diese verwendet. Bei der Verwendung von 0x23 und 0x24 erhielt ich in MapSource statt des erwarteten Hinweises auf den einprogrammierten Objekttyp immer die Anzeige "unerlaubte Tiefe" (oder so ähnlich/hab mir die Formulierung nicht so genau gemerkt). Diese IDs scheinen damit fest für die Darstellung von Untiefen programmiert zu sein. Oder hab ich da völlig falsche Schlußfolgerungen gezogen?

Gruß
Eli

Ja, es gibt 0x20-0x26 sowie 0x109* die Konturlinien darstellen - diese sind nur fuer Konturlinien benutzbar. Es gibt noch ein paar weitere solcher Sonderlinien - ich beziehe mich auf den Rest.

Zitat von Wanderreiter

@ Anton
Wo ist das Problem?

Hallo Eli,

das Thema haben wir hier schon ausführlich behandelt - daher nur in Kürze:
- die "freie" Verwendung von Vektor-Typen verstösst gegen das Prinzip der Wahrheit und Klarheit. Die so konvertierte Karte ist für andere Anwendungen nutzlos.

Zitat

Erstellst Du selbst ebenfalls Karten?

ja ich erstelle Vektor-Karten seit mehr als 5 Jahren - ich bin aber kein Konvertierer

Zitat

Kannst Du erklären, warum Du die "freie" Verwendung von Typfiles ablehnst?

wie kommst du darauf?
Nicht die Typ-Files sind das Problem sondern die falschen Objekt-Typen. Eine Tiefenlinie ist eine Tiefenline - selbst wenn das Typ-File auf dem Display eine Stromleitung darstellt (beispielhaft)

Grüsse - Anton

Zitat von macnetz

Hallo Eli,

das Thema haben wir hier schon ausführlich behandelt - daher nur in Kürze:
- die "freie" Verwendung von Vektor-Typen verstösst gegen das Prinzip der Wahrheit und Klarheit. Die so konvertierte Karte ist für andere Anwendungen nutzlos.

Dieses Argument ist einfach Schwachsinn und konnte von dir noch nicht belegt werden.
Klar gibt es Linien wie die Tiefen/Hoehenlinien die eine spezielle Funktion haben, so auch faehren, oder eben dass bestimmte Linien routingfaehig sind, der Rest aber nicht. Wie man Linien ohne Spezialfunktion belegt, ist aber komplett egal - nur gibt es halt Programme wie TTQV deren Programmierer es noch nicht geschafft haben TYPFiles korrekt umzusetzen - korrekt bedeutet so wie Garmin es eben macht. Diese Programme koennen aber meist auch nicht korrekt mit extendet types umgehen. Es gibt von Garmin schlicht und einfach keine fixe Zuordnung.

Garmin Fietsroute NL etwa hat die Typen auch komplett anders als andere Karten. Bei der Transalpin wurde auch viel veraendert. Nur weil Garmin sehr lange eine fixe Zuordnung hatte, heißt dies eben nicht dass da auch spezielle Funktionen mit verbunden waeren.

Warheit und Klarheit ist Bullshit so wie du es dir vorstellst.

z.Bsp benutzt Garmin bei der Fietskart 0x29 fuer Fahrradrouten - dies sind sonst meist Stromleitungen.

Bei der Garmin Transalpin braucht man eigentlich erst gar nicht anfangen die anders benutzten Typen aufzuzaehlen, da ab 0x08 bis 0x13 alles "willkuerlich" benutzt wurde ohne Zusammenhange mit klassischen Karten ohne Typfile. Auch bei den extended types ist von Karte zu Karte eh alles unterschiedlich.

Zitat von extemecarver

Warheit und Klarheit ist Bullshit so wie du es dir vorstellst.

Hallo Felix,

ich bin schon ganz gespannt auf die angekündigte OSM-Hardware.
- ob das eigene Vektorkartenformat ebenso "flexibel" sein wird
oder
- ob weiter das Garmin-Format "zurechtgebogen" werden wird.

Es kann Gründe geben um "Abkürzungen" zu nehmen. Beim OSM-IMG-Konvertieren sehe ich die Notwendigkeit für "Umbiegungen" nicht.
Stichworte: Autobahn, Maut, Auto, Fussgänger . . .

Grüsse - Anton

Zitat von extemecarver

Dieses Argument ist einfach Schwachsinn und konnte von dir noch nicht belegt werden.

Hallo Felix,

vielleicht denkst du mal darüber nach dass deine OSM-IMG-Konvertierungen nur deshalb möglich sind weil die Karten-Autoren von OSM nicht "kreativ" mit der Kennzeichnung der Vektor-Objekte umgehen. Eine befahrbare Brücke ist eine befahrbare Brücke und ein gesperrter Minengürtel ist ein gesperrter Minengürtel etc.

Grüsse - Anton

Hallo extemecarver,

Zitat von extemecarver

Wenn dir die genannten routingfaehigen typen nicht ausreichen, dann musst du dir einfach einen davon auswaehlen, den du per typfile komplett unsichtbar machst, und wo du nun alle typen die Darstellbar sind zusaetzlich fuer die Anzeige zuweist - Auflistung siehe oben.

das file "lines" kenne ich und habe es auch schon geringfügig modifiziert, aber mein Knackpunkt liegt wohl bei folgenden Einträgen (geschweifte Klammern gelöscht):

highway=cycleway [0x16 road_class=0 road_speed=1 resolution 23]
highway=footway [0x16 road_class=0 road_speed=0 resolution 23]
highway=path [0x16 road_class=0 road_speed=0 resolution 23]

Ich habe nicht mehr genug routingfähige Linien, ich verwende also für alle 3 Wege die 0x16 und mache die mittels Typfile transparent.
Zusätzlich muss ich nun 3 unterschiedliche "extended" Linientypen zuweisen und im Typ-File entsprechend formatieren?
Nur hier ist mein Problem: Wie weise ich einen 2. Linientyp zu?

Für ein kleines Beispiel wäre ich echt dankbar.

Gruß ralf

Wenns so einfach ist:

highway=cycleway [0x123 road..... ]

Dazu im "overlays" file (neu anlegen falls noch nicht existierend):

0x123: 0x16; 0x10a00

0x16 machst du transparent im Typfile. 0x10a00 bekommt die Darstellung die du fuer cycleway haben moechtest. Dazu brauchst du mkgmap nicht einmal patchen.

0x123 da so ein Typ nicht existieren kann (entweder 0x?? oder 0x???? (nur marine types) oder 0x????? ist das Format real benutzbarer Typen).