Radkarte aus OSM-Daten selber bauen

Hallo,
wenn Compe mitspielt und eine VMAP oder ein neues Format aus "unseren Daten" generiert werden kann, wird keine für uns relevante Größenbeschränkung vorliegen. Das Thema sollte bei Compe diplomatisch angegangen werden, damit die Vorteile von Onroadnavigation outdoor dort erkannt werden. Ich persönlich brauche es nicht, doch für eine nicht PC gestützte Outdoornavigation sehr interessant.

Nachdem Compe sehr viel Augenmerk auf TwoNav die letzten Monate verwendet hat, sollte jetzt CGPSL, bis jetzt ein kleiner Rohdiamant, Fortschritte machen.

Beispiele für CGPSL Modifikationen:
in eine Cach.wpt sollten die Spoiler Bilder im Batchmodus integriert werden können, ohne ein extra Tool bemühen zu müssen.
Das erstellen von mpvf's, ohne spanisch Kenntnisse und mit einer Doku, wäre hilfreich.
VMAPS müssen in CGPSL routable sein
Hypermaps sollte in CGPSL und TWONAV direkt erstellt werden können

Wir sollten uns nur um die relevanten Daten kümmern müssen, den Rest erledigen die Tools.

Hallo Dieter,
danke für die Info.

Zitat von Sockeye

Hallo Jürgen,

ich erstelle diese Overlays für Magellan Geräte. Wie im OSM Forum schon geschrieben habe ich mir hier ein Addon gebaut. Im Prinzip funktioniert es folgendermaßen:

1. map.osm -> map.mp (mit lioshas letzter Version / nicht die developement) Darauf achten, das der Konmentar mit der Way ID in der MP Datei erhalten bleibt. way_id=123456789)

2. meine makeway.exe ausführen und die Ursprungs OSM Datei und die MP Datei als Parameter übergeben. Das Progrämmchen lädt nun alle hike und bike Relationen aus der OSM Datei, sucht sie in der MP Datei und fasst sie in einer neuen MP Datei zusammen.

Da ich die Wander und die Radwege in einem Overlay verwende und ein Weg beides sein kann, habe ich noch den Parameter HIKE=NO eingebaut, damit haben Radfahrer Vorfahrt. Bei HIKE=YES (default) sind es Wanderwege.

Das Programm kannst du dir hier:http://maps4me.net/freemaps/makeway.exe (18kb) runterladen, aber

- es benötigt Windows
- .NET muss installiert sein
- es ist eine Kommandozeilenversion
- Hilfe erscheint bei Aufruf ohne/ mit falschen Parametern

Recht flott ist es auch noch... 1 GB MP Datei + 24 GB OSM Datei nur ein paar Minuten.

VG
Sockeye

Alles anzeigen

Super, an diese Variante hatte ich auch gedacht um Relationen aus OSM herauszuziehen. Aber mangels Zeit nicht weiterverfolgt, schön das ud es gemacht hast
Wenn ich die Posts von liosha richtig interpretiere, gehen Relationen wirklich nicht sind aber für zukünftige Versionen geplant.
Alleine deswegen wird es sich lohnen von .cfg auf .yml umzustellen.
Soweit .yml gesehen habe (ist ein freies Format) sollte es selbsterklärend sein, wenn man sich die Bspe. anschaut.

Es gibt im engl. Teil des Compe-Forum einen Thread zu VMP(F)-erstellung, es wäre sicherlich nicht von Nachteil wenn die "neuen" Interessenten an diesen Thema sich dort melden.

Jeder von uns hat wahrscheinlich eine andere Vorstellung, wie man die OSM-Daten darstellen sollte.
Ich habe hier eine OSM-basierte Kanaren Topo verlinkt, einmal mit SAC-Wanderwegklassifzierung und einmal mit MTB-S-Stufenklassifizierung.
Es wäre nett wenn sich das jemand anschaut (ich habe meine Fokus dabei auf La Palma gelegt und Wanderwege aus anderen Quellen eingefügt)
Ich habe lange mit der Darstellung gespielt und das war in meine Augen die beste Darstellung, die mir am Aventura beim Biken auf La Palma auch gut erkennbar und somit eine gute Ergänzung zur Rasterkarten-Topo war.
Tip: mit der tablet Version von TwoNav das am Rechner testen, da es anders ausschaut als unter CompeGPS Land!

Wenn ich @Juventura richtig verstehe, will er Fernwanderwege (ncn, lcn,rcn) und Radwege in ein VMPF packen.
ncn hast du dabei vergessen!

Wenn man mit Sockeyes Tool die Relationen rauszieht, sehe ich da auch keine unlösbaren Probleme.
Autorouting würde ich dabei aber erst einmal zurückstellen.

Ray

Hallo,
das erstellen von nicht routbaren MPVF Overlays aus unterschiedlichen Daten-Quellen ist jetzt schon problemlos möglich. Globalmapper bietet dabei auch einiges im Vektorbereich. Notfalls müssen eben 2 oder 3 Maps erstellt werden, wenn einem zu wenig Lines-Klassifizierungen von CGPSL angeboten werden. Vorteil: Die Rastermaps bleiben zusammen mit den VMAPs übersichtlich, wenn nur gezielt VMPF's für MTB Strecken bzw. für Radfernwege/Trekkingtouren usw aktiviert werden. Manchmal ist für Wanderer sehr gut zu wissen, wo die Gefahren durch Radler/MTBler drohen .

Wer kein Routing im Auge hat, kann sich mit der TTQV 5 diverse Vektoroverlays mit sehr vielen freien Gestaltungsmöglichkeiten auf eine Rastermap legen und als Einheit übertragen. Minimaler Zeitaufwand.

Privat arbeite ich zur Zeit an einem Projekt die Wanderwege des Schwäbischen Albvereins (120.000 Mitglieder) zu erfassen. Diese Daten integriere ich in TTQV (Kontrolling+Zusammenführung von diversen Datenquellen). Zur Weiterverarbeitung bzw. laufenden Ergänzung für mich die einfachste Möglichkeit. Ausgabe der Daten in shp, mp, img für CGPSL.

Hi,Alex

Zitat von Cylex73

Vielleicht findet sich ja eine gemeinsame Linie...wäre sicher sinnvoll...

Ich denke jeder hat seine eigenen Sehgewohnheiten, der eine mag sie dick, der andere dünn, der andere mags es bunt, die eine eher weniger.
Das was Typ-files bei den Garmin-img bieten, also Verwendung von Bitmap-Mustern für alle Objekte also auch Polylinien und evtl. Polygone(obwohl ich persönlich die nur selten verwende bzw. auch unsichtbar schalte, so das man zwar nichts davon sieht aber immer noch den Tooltip bekommt), sollte bei CLAY-files auch gehen. Da sollte man CompeGps animieren dies zu ermöglichen. Das gehört für mich auch ins Pflichtenheft für die Weiterentwicklung des Vektormoduls von CompeLand. Vielleicht schaffen wir es ja, da etwas auf die Beine zu stellen in dr kommenden dunklen Jahreszeit. Auf meiner Agenda steht das ja schon seit ich meine Sportiva habe, aber die Sommerszeit wollte ich dann doch eher fürs biken nutzen.

Die CLAY-Files an sich bieten ja durch aus noch ganz andere Möglichkeiten wie Garmins-Typ files, z.B Anpassung der Symbolgrösse bei POI. Und wenn man einen externen Editor betreibt, kann man dies auch noch im Gerät machen(ok, nur was für Bastler, aber machbar)

Zitat von Cylex73

Fehlt da ein Anhang?

Ray meint wohl das HIER #14

Gruss Gert

Danke Gert, genau diesen Thread meinte ich.
Da ich seit 2 Tagen mit Fieber un dKopfschmerzen zuhause liege ist meine Motivation nicht sehr hoch. Der Gedanke die Zeit zuhause für liegengebliebenes zu nutzen ist da, nur in der Umsetzung scheitert es mangels Antrieb.

Das CLAY-Format ist sinnvoll aufgebaut, man kann neben Typ-Namen, Linientyp, Farbe, Poi-Symbol und Größe, Zoomverhalten auch Geschwindigkeiten und Wegetyp definieren.
Das alles gibt das CLAY-File her!
Ich hatte deswegen ein Script geschrieben um CLAY-Files zu "pimpen".
Nur wird nicht alles von TwoNav interpretiert, entsprechend groß war damals meine Enttäuschung.
Man muss daher all diese Dinge händisch in Compe Land einstellen.
Evt. kann ein VBA-Entwickler hier eine Automatisierung reinbringen.

Ich meine Namen, Farbe, Linientyp, POI-Symbol/Größe werden aus den CLAY interpretiert.

Zum CLAY-Format gibt es einen eigenen Thread, ich habe versucht das Wissen im CLAY-Extractor- und -Modifier-Script zusammen getragen.
Das Script benutzt sprechende Name in der Konfiguration.
Ein Nutzwert ist also noch da, wenn man das Format nicht auswendig lernen will.

Ray

Hallo Alex,

Zitat von Cylex73

Was verstehst du unter richtigem Routing, vermutlich meinst du damit flächendeckendes Outdoor-Routing mit Fußwegen etc.

Unter richtigem Routing verstehe ich die automatische Berechnung einer Route unter Berücksichtigung vorgegebener Kriterien.
Während dies im Onroad-Bereich ja noch halbwegs überschaubar ist( Strassentypen,Geschwindigkeiten, Einbahnstrasse, Zugansbeschränkungen,Maut etc.),
ist im Offroadbereich zum einen die notwendige Erfassung aller relevanter Daten(Wegebeschaffenheit,Breite Untergrund, Steigung, Schwierigkeitsgrad, Schönheit etc.)
und die laufende Wartung dieser Daten erheblicher aufwendiger.(wenn du dir beispielsweise das Südtirol Wegeprojekt anschaaust, bekommst du eine Vorstellung was da an Arbeit drin gesteckt.) Auch ist die subjektive Wertung bestimmter Eigenschaften(Schwierigkeit, Schönheit) stärker ausgeprägt.
Für die Auswertung dieser Daten braucht es dann auch noch eine performante Routingengine.

Flächendeckend???Als Wanderer oder Radfahrer brauche ich im Normalfall immer nur das Gebiet in dem ich mich bewege.
Bei MPVF gibt es derzeit keine Kachel/Karten übergreifendes Routing. Das wäre zu berücksichtigen. Bei VMAPS geht dies allerdings.
Kartenübergreifendes Routing bei MPVFs könnte Teil eines Pflichtenheftes für das CGPSL-Vektormodul sein.

Je kompletter die Erfassung der Wege, desto besser das Routing(sofern alle anderen Kriterien erfüllt sind. Strassen/Wege die nicht befahrbar/begehbar( alles wo z.B. ein Fahrverbot für Radfahrer ist also Autobahn,Autostrassen)
sind könnte man weglassen.

Zitat von Cylex73

Wie hast du die Overlays erstellt. Ein Dreizeiler, um das Verfahren einzuordnen würde mir reichen.

Also mein Touren/Wegeoverlay hat als Basisdaten früherGPX heute TRK-Daten die in TTQV4 importiert werden, dort nachbearbeitet und als
mp-file exportiert werden. Diese werden in das bestehende MP-Wegeoverlay importiert und dort die entsprechenden Routingknoten verbunden.
Dieses MP-File wird in CGPSL importiert.
Der primäre Import wird durch das Types.dbf-File in CGPSL gesteuert. Es lässt sich mit Excel anpassen, allerding gibt es keinerlei Dokumentation hierzu.
Soweit ich weiss ist dies auf Eigeninitiative eines TwoNavusers entstanden. Es kann dort sehr viel für den Rohimport eingestellt werden.
Das hinzufügen evtl. fehlender Codes muss hier erfolgen.
Wichtig ist hier die Drawpriority, die nur hier verändert werden kann und später nicht mehr.
Die Designeinstellungen kann man ja später auch noch mit dem CLAY-File vornehmen.
Hast du die MP-Datei importiert, musst du die Einstellungen, wie Symbole, Linientyp, Sichtbarkeit etc. vornehmen soweit sie nicht schon durch die Tyxes.dbf erledigt wurden.
Für die POI-Symbole kannst auch eigene Dateien zusammenstellen und anwenden.(Karteneienschaften POI icons file)
Wenn du das gemacht hast ist es empfehlenswert, diese Einstellungen durch Speicherung als CLAY-File zur säteren nochmaligen Verwendung zu sichern(EBENEN- Kontextmenu Speicher Layer als)
Dann brauchst du bei einem Neuimport des MP-Files oder eines aus gleichen Objekten bestehenden File nur noch dieses zu importieren und mit EBENEN- Kontextmenu Import layers file
das CLAY-File zu laden und sofort sind die Einstellungen gemacht. Die Zuordnung erfolgt über den CGPSL-Objektcode.
Anmerk: der Objektcode im MPV entspricht nicht dem Garmin-typ und ist auch wieder anders wie der Code in den MPVF.
Deshalb ist ein MPV-CLAY-File nicht für ein MPVF zu gebrauchen. Noch etwas was unbedingt gerade gezogen werden müsste bei einer möglichen Weiterentwicklung des Vektormoduls.
Alle Zoomlevel bis auf das unterste entfernen. Ohne Dokumentation kann ich nur spekulieren was man damit machen kann.
Jetzt das MP als MPV speichern. Dieses lässt sich im Gegensatz zu MPVFs später auch noch bearbeiten.
Wenn du nun kein Routing willst kannst du das MPV dann einfach noch als MPVf speichern.
Es wird jetzt weitesgehend mit den Einstellungen des MPVs gespeichert.
Allerdings wird für den nahen Zoom immer 17m/pixel eingetragen. Ich habe derzeit keine Ahnung woran das liegt. Möfglicherweise gibt es da noch einen Zusammenhang mit der Zoom-Ebenen.
Die einzige Möglichkeit daran etwas zu ändern ist ein CLAY-file für das MPVf zu erstellen wo die Werte für die Objekte entsprechend angepasst werden.
CLAY-File und Karten-file haben den gleichen Prefix.(WKR100.clay WKR100.mpvf)
Wenn du Routing willst, auf MPV-Karteneintrag Kontextmenu-EDIT-Vektorkarte ändern. Dort den Button ganz rechts(Erzeuge Netzinformationen..)
drücken. Alles weiter erstmal so lassen und bestätigen. Nachdem Ende der Berechnung die Karte als MPVF speichern.
Leider kann man in der MPVF nicht prüfen was an Daten aus der MPV übernommen wurde. Die entprechenden Zähler stehen alle auf 0.
Sollte die Datei nun deutlich kleiner als die Hälfte der MPV, ist vermutlich etwas schiefgegangen(kommt bei mir häufiger vor. liegt evtl. aber auch an meinen bescheidenen Resourcsen)
Dann CGPLS neustarten und den Vorgang(MPV-ROutinginformationen-MPVF) wiederholen. Es kann aber auch ein Konfigurationsfehler vorliegen.(meine 3 Zeilen sind aufgebraucht)

Für OSM-Daten benutze ich 2 Varianten:
1. .OSM mit mkgmap in IMG => imG mit Mapedit in MP und weiter wie oben
Vorteil: mittels der mkgmap Styles habe ich eine gut Steuermöglichkeit für die Auswahl und Präsentation der Daten(wenn man weiss wie)
Nachteil: zusätzlicher Schritt über Gpsmapedit
2.-OSm mit osm2mp ins MP-format bringen und weiter wie oben
Nachteil: bis dato keine Abbildung von Relationen

Sorry, kürzer konnte ich nicht(und es gäbe noch sehr viel mehr anzumerken.)

Gruss Gert

P.S
die aktuelle CGPSL 7.0.9a ist buggy im Vektormodul.

hier der vergessene Screenshot vom Sportiva zum Routing auf selbserstelltem Overlay. Die geraden Abschnitte werde noch etwas "kurviger" wenn man sich dem Abschnitt nähert.

Zitat von papaluna

Unter richtigem Routing verstehe ich die automatische Berechnung einer Route unter Berücksichtigung vorgegebener Kriterien.
Während dies im Onroad-Bereich ja noch halbwegs überschaubar ist( Strassentypen,Geschwindigkeiten, Einbahnstrasse, Zugansbeschränkungen,Maut etc.),
ist im Offroadbereich zum einen die notwendige Erfassung aller relevanter Daten(Wegebeschaffenheit,Breite Untergrund, Steigung, Schwierigkeitsgrad, Schönheit etc.)
und die laufende Wartung dieser Daten erheblicher aufwendiger.(wenn du dir beispielsweise das Südtirol Wegeprojekt anschaaust, bekommst du eine Vorstellung was da an Arbeit drin gesteckt.) Auch ist die subjektive Wertung bestimmter Eigenschaften(Schwierigkeit, Schönheit) stärker ausgeprägt.
Für die Auswertung dieser Daten braucht es dann auch noch eine performante Routingengine.

Das Offroad-Autorouting schon wegen aufwendigeren Datenerfassung wesentlich aufwendiger ist kann man nur unterstreichen. Zudem wird es bei den Nutzern noch unterschiedliche Auffassungen darüber geben, wie die einzelnen Daten in einem Gesamtergebnis zu gewichten sind. Und zudem sind einige Daten auch zeitlich variabel. Z.B. in der Mittaghitze wird man einen schattigen Weg ohne Aussicht bevorzugen, zu anderen Zeiten dann den im offenen Gelände mit viel Aussicht. Oder der Weg ist bei trockener Witterung gut zu begehen, bei nassem Wetter aber ein Schlammloch.

Zitat von papaluna

Flächendeckend???Als Wanderer oder Radfahrer brauche ich im Normalfall immer nur das Gebiet in dem ich mich bewege.

Ein kommerzieller Kartenhersteller sollte die Daten "flächendeckend" in die Karte bringen, da ein Kunde sehr entäuscht sein wird wenn für "seine" Region die Daten und somit die versprochenen Features fehlen.

Zitat von mkossmann

Ein kommerzieller Kartenhersteller sollte die Daten "flächendeckend" in die Karte bringen, da ein Kunde sehr entäuscht sein wird wenn für "seine" Region die Daten und somit die versprochenen Features fehlen.

Zustimmung.

Ich bezog flächendeckend jetzt mehr auf die Frage, was derzeit mit CGPSL /TwoNav in dem Zusammenhang vernünftigerweise(Performancegründe) zu machen ist. Da hat sich wohl 60MB für ein MPVf-file als sinnvolle Grenze gezeigt. Damit läßt sich aber z.B. Deutschland als ganzes nicht abdecken.
Da ich mich im Normal aber nur in einem begrenzten Gebiet bewege, ist das erstmal nicht so tragisch, solange ich mir das benötigte Teilstück aus dem natürlich die gesamte Fläche abdeckendem Ganzen raussuchen kann.