Velomaps mit mkgmap konvertieren

Hallo,

ich verstehe Dein Problem nicht (richtig):
Wenn es um die Karten auf dem Navi geht,
die 1. Frage: Kann Dein Navi mit mehreren Karten img's umgehen? Dann die die fertigen img's auf das Navi schieben und gut ist.
Wenn das Navi nur mit einer "gmapsupp.img" umgehen kann, dann must Du basteln.

Wenn es um die Karte in QM geht:
Hier kannst Du auch die fertigen Karten-Img's anzeigen lassen und (im Gegensatzt zu BaseCamp / MapSource) mehrer Karten gleichzeitig (übereinander) aktivieren.

PS: M.E. ist die FID, die Du bei mkgmap angibst, nicht die, die die Karte hat, sondern die, die die fertige gmapsupp.img bekommen soll.
D.h. alle Kacheln in ein Verzeichnis schmeißen und mkgmap laufen lassen.
Ein Problem hast Du "nur" wenn die Karten gleiche Kachel-Nr. benutzen.

Zu 2. normalerweise geht es genau anders herum : aus den HGT Dateien wird ein DEM generiert. Dazu gibt es den Parameter dem=<hier pfad zu den hgt-files> und dem-dists= 3312,13248... Du must die Werte Deinen eigenen Vorstellungen entsprechend und den Levels im arg-file gemäß wählen. Dann noch den Parameter overview-dem-dist= 110000 (oder anderen Wert nach Deinem Gustos). Als HGT-File stehen zur Verfügung z.B. die der Nasa bis 60° nord, die von Copernicus und in einigen Ländern sehr genaue der zuständigen Behörden. In Austria z.B. gibt es 10 m Linien. Von der Nasa 3 " und 1" weltweit. Copernicus beschränkt auf Europa, und von den Breiten größer 60 ° Nord die von Ferranti. Die Beschaffung der besten HGT ist ein eigenes Kapitel...
Falls Du deine cmd-line um die zitierten Optionen erweiterst, dann wird in die Karte von mkgmap ein DEM-Modell eingebaut. Das DEM Modell hat aber mit den Höhenlinien nichts zu tun. Das DEM -Modell erkennst Du daran, dass am Mauszeiger die Höhe eingeblendet wird und die Karte insgesamt schattiert ist. Höhenlinien sind nur ein Overlay, das je nach Erzuegung ein DEM haben kann oder auch auch nicht.
zu 1.Falls Du die Kartenkacheln und die Höhenlinienkacheln breits vorliegen hast, dann kannst Du in einem zusätzlichen Durchlauf beide in eine Karte zusammenbacken und/oder eine gmapsupp erzeugen. Die Befehlszeile könnte in etwa lauten

java -Xmx11000m -XX:-UseGCOverheadLimit -jar mkgmap.jar -c creation.txt 6*.img  7*.img

Wobei in der creation.txt bei mir alle sonst in der cmd stehenden Optionen wie family-name, series-name, index, max-jobs, show-profiles, overview-levels, gmapi, ...usw.usw. stehen. Die Option gmapsupp nutze ich nie, weil meine Karten reglmäßig > 4 GB sind. Die gmapsupp erzeuge ich aus Mapsource heraus. gmapi erzeugt ja die Mapsource/Baecamp -installation.

Das ist nur als grober Handlungsfaden zu verstehen, damit du ungefähr weist, wo du Dich einarbeiten solltest.
Die FID bei mkgmap ist die der erzeugten Karte. Eine gmapsupp hat keine spezielle FID, weil die gmapsupp ein Contaienr ist, der mehrere verschiedene Karten enthalten kann und demenstprechend auch mehrere FID's.

morgen1
edit : meine Ausführungen zu 1. muß ich korrigieren bzw. ergänzen. Ein DEM als Subfile in den Kartenkacheln kannst Du nur erzeugen, wenn Du die Kacheln mit mkgmap aus den OSM-Daten erzeugst. Da du aber fertige Kacheln mit Deiner cmd nur zu einer gmapsupp vereinigen willst, wird es wohl nicht funktionieren nachträglich ein DEM hinzuzufügen. Die Optionen betreffs DEM-Erzeugung funktionieren vermutlich nur bei der Kachelerzeugung aus den Rohdaten. Zumindest habe ich es nie versucht, später hinzuzufügen, weil es m.E. nach nicht zielführend ist.

Ein paar lose Gedanken....
- Höhenlinien und DEM Daten sind 2 unterschiedliche Dinge.
- Die mkgmap Option show-profiles=1 bewirkt, zumindest in BaseCamp, dass bei einer Route ein Höhenprofil gemacht wird. Nicht aber bei Tracks. Ein Garmin-Gerät kann damit auch nichts anfangen. QMS vermutlich auch nicht. Will heißen, Wenn du Punkt 1 umsetzt, gibt es immer noch kein Höhenprofil.
- Es gibt Karten, die als gmapsupp vorliegen und Höhenlinien enthalten. Meine Speichenkarte zum Beispiel. Oder die velomap Premium
- gmt kann gmapsupp miteinander verbinden. (gmaptool für linux)
- DEM in einer gmapsupp wird von QMS ignoriert. Keine Schattierung der Karte, kein Höhenprofil. Habe mich noch nicht damit beschäftigt, wie man das von außen über die Karte legen kann.
- Zu Punkt 2: Aus Höhenlinien kann man keine DEM machen. mkgmap kann DEM herstellen, als Input benötigt man Höhendaten, zum Beispiel von Sonny

Zitat von morgen1

Die FID bei mkgmap ist die der erzeugten Karte. Eine gmapsupp hat keine spezielle FID, weil die gmapsupp ein Contaienr ist, der mehrere verschiedene Karten enthalten kann und demenstprechend auch mehrere FID's.

Da sehe ich mal wieder meine höher Halbbildung.

Zitat von Konstantin_Opel

Hallo zusammen,
Danke für die Aufklärung. Habe das gerade noch mal nachgelesen und ja, ich habe mich vertan. DEM ist für mich nice to have. Eigentlich will ich aber Höhenprofile bei der Planung. Ich meine mich zu erinnern, dass ich das bei Basecamp auch immer hatte, kann mich aber irren (wüsste nicht, dass ich ständig Routen gebaut hätte). Im Zweifel muss ich halt zukünftig ausschließlich Routen bauen.

Redest Du von der Planung auf dem Gerät oder in QMapShack? Bei QMapShack benötigst Du DEM Daten um ein Höhenprofil zu bekommen. Um etwas lesen wirst Du nicht herumkommen:

https://bitbucket.org/maproom/…/wiki/DocQuickStartGerman

https://bitbucket.org/maproom/…-of-supported-map-formats

Dafür ist das dann auch komplett unabhängig von der Karte.

Du kannst auch versuchen unter Linux Basecamp oder Mapsource mit Wine zu starten. Die Meisten kommen dann doch lieber wieder zurück zu QMapShack. Einarbeiten lohnt sich Wenn man eine aktuelle Version benützt hilft einem Anleitung, die man beim öffnen einer neuen Kartenansicht als erstes sieht.

kiozen

Wegen dieser Threads habe ich mich auch noch mal näher mit QMS befasst. Gefällt mir mittlerweile ganz gut.

Die Anleitungen sind OK. Ich habe es damit geschafft, HGT Dateien von
http://data.opendataportal.at/user/sonny
in das Werkzeug VRT Builder zu stecken und eine DEM Karte zu bekommen.
Die Schummerung ist einstellbar, das finde ich gegenüber BaseCamp super, da man dann auch im Mittelgebirge was davon hat.
Mit den DEM hat man dann auch die vom TE gewünschten Höhenprofile. Die Höhendaten werden vermutlich auch in den Track geschrieben, so dass man auch auf dem Gerät das Höhenprofil hat. (Wobei das Gerät ja auch die DEM von der velomap lesen kann und dem Track oder Route gibt, wenn da nichts ist)
Ich würde für das Gerät 2 gmapsupp empfehlen. Eine mit der Karte und eine mit Höhenlinien. Die Höhenlinien stören eigentlich nur, wenn man einen Track abreitet. Wenn man was plant, will man die natürlich sehen. Im Kartenmenü kann man je nach Bedarf die Linien Ein-bzw- Ausschalten.
QMS kann übrigens auch nichts mit dem Routing in der gmapsupp anfangen. Das Vorgehen ist ähnlich wie mit den DEM: Bei geofabrik das gewünschte Land als pbf laden und in das Werkzeug Routino stecken. Dann kann QMS auch routen. Allerdings anders, wie die Garminkarte.
Bei der Velomap ist in den beschreibeneden Dateien eine Anleitung dabei, wie man mit mkgmap unter Linux eine gmapsupp erstellt.....Wobei man die als Premium-Mitglied auch direkt runterladen kann.

Also erst mal zu meiner "Arbeitsumgebung":
Ich habe auf meinem Windows-Rechner die openmtb-Karte. Die dürfte sich aber nicht grundlegend von der Velomap unterscheiden.
Für Windows gibt es eine Installationsroutine. Hier hat man drei Optionen:
- Nur die "Basiskarte" (ohne Höhenlinien) erzeugen
- Die Höhenlinien in die Karte integrieren
- Jeweils für die Basiskarte und für die Höhenlinien (als transparentes Overlay) einen separaten Kartensatz erzeugen lassen.
Ich habe mich für die letzte Variante entschieden.

Zitat von Speichennippel

Ich würde für das Gerät 2 gmapsupp empfehlen. Eine mit der Karte und eine mit Höhenlinien.

Genau so.
Auch in QMS kann ich jede Karte einzeln aktivieren. Und ich kann auch die Höhenlinien über jede beliebige andere Karte drüberlegen (sowohl in QMS wie auch auf meinem Garmin).

Zitat von Konstantin_Opel

Um die geht es. Wenn ich beide Karten übereinander lege, wird die eigentliche Karte da, wo viele Höhenlinien liegen, einfach nur (dunkel-)grau.

Kann ich irgendwie nicht nachvollziehen. Bei mir sind die Höhenlinien klar als scharf abgegrenzte Linien zu erkennen wie in Bild 1. Vielleicht kann man es erkennen: Die Hangneigung beträgt an der Stelle des Mauszeigers mehr als 60°. Die Höhenlinien liegen hier also schon relativ dicht beieinander.

Zitat von Konstantin_Opel

Ich vermute, das liegt daran, dass die Höhenlinien-Karte als img an der Stelle mehr Grauanteile hat.

Sollte eigentlich nicht sein. Die Karte mit den Höhenlinien sollte eigentlich überhaupt keine Flächen enthalten.
Vielleicht kannst du ja auch mal einen Screenshot machen wie das bei dir ausschaut.

Wenn es bei dir so ähnlich ist wie bei meinem zweiten Bild:
Vermutlich hast du bereits ein DEM geladen und die Schummerung aktiviert (mit mehr oder weniger starker Transparenz).

Zitat von Konstantin_Opel

Was mir aber gerade auffällt: zumindest Höhenangaben bekomme ich bei einem Mouseover auch auf der 6er genannt. Irgendwas muss also da sein.

Auch das lässt mich auf ein bereits vorhandenes DEM schließen.

P.S.:
Kommt vielleicht auch auf die Bodenbeschaffenheit der betreffenden Fläche drauf an. Eng beieinander liegenden Höhenlinien findet man ja auch oft zb bei Karen oder Felsen. Die werden mit dem Standard-Typfile der openmtb/velomap "ziemlich" grau dargestellt. Das sind sie aber eigentlich immer. Egal ob mit oder ohne eingeblendete Höhenlinien.

Was mit bei der Ansicht der Screenshots mal wieder auffällt: OSM hat immer noch keinen guten Algorithmus um Höhenlinien zu berechnen. Gerade im steilen Gelände fällt das immer wieder auf. Eigentlich kann man davon nur abraten. Wer unbedingt Höhenlinien haben will und den Aufwand nicht scheut, benützt gescannte topographische Karten auf dem Gerät.

Zitat von kiozen

.. OSM hat immer noch keinen guten Algorithmus um Höhenlinien zu berechnen.

kannst Du bitte mal erläutern wie Du das meinst ?. Die OSM -Files, egal welches Format (osm, pbf ...usw.) haben prinzipiell keine Höhenlinien. Die Höhenlinien werden aus verschiedenen externen Quellen vom Kartenerzeuger hinzugefügt. Und der Erzeuger hat es in der Hand, den Abstand zu wählen. Und klar : bei engem Abstand in steilem Gelände ist alles dunkel... Aber mit OSM hat das nichts zu tun. Oder verstehe ich hier was nicht ?
morgen1

Ok, falsch ausgedrückt Die Software zum Erstellen der Höhenlinien, die üblicherweise bei freien Karten, basierend auf OSM, benutzt wird, ist Mist.

Kommt drauf an, was man macht. Für Wanderungen auf Wanderwegen reichen die verfügbaren Quellen allemal aus, um sich einen ungefähren Eindruck vom Gelände zu verschaffen. OSM steuert dann noch weitere Infos dazu, wie Schwierigkeitsgrad etc.
Hier im Beispiel 3 mal das selbe Loch.
Links BaseCamp Sonny Höhendaten (Lidar)
Mitte BaseCamp Viefinder
Rechts QMapShack Sonny bzw. DEM mit Sonny HGT und VRT Builder

[Blockierte Grafik: https://fstatic1.mtb-news.de/v3/23/2319/2319320-rm2a1qddwukl-loch-large.jpg?1]

Da sieht man sehr schön, dass das individuelle Können der Kartenerzeuger bei den digitalen Karten genauso wichtig ist, wie das früher bei den Kartenzeichnern der Papierkarten schon war. Es macht halt einen Unterschied, ob man ohne eigenes Zutun die von mkgmap bereitgestellten default Werte nimmt, oder sich die Mühe macht, die besten DEM Modelle aufzutreiben. Und NASA SRTM 1" ist nicht das beste, wohl aber aus Bequemlichkeit meistgenutzte. Ich hatte für meine eigenen Zwecke mir ein Vergeichstools programmiert, welches HGT verschiedener Anbieter vergleicht. Und da waren erhebliche Unterschiede zwischen NASA, Copernicus und sonny. Leider kann man als Anwender aber nicht entscheiden, welches genauer ist, weil man vor Ort nicht selbst nachmessen kann. Und insofern war der Wissensgewinn nur, dass es Unterschiede gibt.
Ich persönlich bin zu der Meinung gekommen, dass die die Daten der Landesämter allesamt besser sind als per Satelitt gewonnene. Für die Provinz Latium (Italien ) habe ich jetzt sehr genaue gefunden, leider aber nur im PDF -Format. Und damit momentan noch nutzlos. Für Trentino gibt es die auch, aber eben nur in nicht Vektorkartenkompatiblen Formaten.

Schlimmer geht immer. Aber nach oben sind halt auch Grenzen gesetzt. Wenn man im Garmin Format halbwegs gute Linien im alpinen Gelände haben will, dann wird die Datei schnell unhandlich. Gerade bei steilen Flanken bieten die zum Teil grob quantisierten Garminkarten nur noch wirre Linien. Punktuell mag das mit dem nötigen Aufwand besser gehen. An eine gute Topokarte kommt man trotzdem nicht heran.

Anderseits spielt das auch keine Rolle, wenn man sich auf größeren Wegen bewegt. Dann ist eher das etwas aufgeräumter Vektorformat, das weniger Details in der Umgebung hervorhebt, von Vorteil.

Wegen den PDF Dateien: GDAL hat eine PDF Treiber:

https://www.gdal.org/frmt_pdf.html

Wenn der funktioniert sollten sich die Daten doch in jedes andere Format umwandeln lassen.