Speichenkarte

Ich habe ein paar Fragen zum Thema Höhenlinienintegration in die Speichenkarte fĂŒr Garmin-Systeme mit mkgmap. Vielleicht kann mir jemand weiterhelfen:

Ziel ist es, die Höhenlinien HINTER die Wege zu bekommen. Das gelingt mir mittlerweile, jedoch sind Schönheitsfehler dabei:

  1. Erzeugen der Höhenlinienkarte und der OSM-Karte mit mkgmap MIT Option --transparent → BaseCamp zeigt die gmapsupp mit Geisterlinien an
  2. Erzeugen der Höhenlinienkarte und der OSM-Karte mit mkgmap OHNE Option --transparent → Auf dem Oregon kann man die Wege nicht anklicken, es erscheint dann kein Name, nur Koordinaten.
  3. –transparent nur bei den Höhenlinien → Höhenlinien ĂŒberdecken die OSM-Wege, das sieht doof aus.
  4. Vor dem splitten die Höhenlinien mit den OSM Daten verheiraten → Es entstehen Unmengen von Geisterlinien. Irgendetwas lĂ€uft da schief.

Ich denke 4) kann am Ende funktionieren, wenn ich die Geisterlinien wegbekomme.

  • phyghtmap --polygon=nordrhein-westfalen.poly --max-nodes-per-tile=0 phyghtmap --max-nodes-per-way=250 --no-zero-contour --start-node-id=1 --start-way-id=1 -s 10 -c 40,20 --source=view1,view3,srtm3 --pbf -o 66668008
  • OSM Daten als pbf von der Geofabrik
  • osmconvert 66668008.osm.pbf -o=SRTM_NRW.o5m
    osmconvert --drop-version SRTM_NRW.o5m nordrhein-westfalen-latest.osm.pbf -o=NRW.o5m

??

Mit einer kleinen Canaren-Karte habe ich es hinbekommen.
Also vorher die OSM Daten von der Geofabrik mit Höhenlinien von “phyghtmap” mit “osmconvert” verbunden, dann mit mkgmap-splitter geplittert und mit mkgmap verarbeitet.
Diese Karte funktioniert hervorragend. Sogar MapSource zeigt nun auch die Höhenlinien :slight_smile:

Nur bei einer NRW-Karte will das nicht funktionieren, da kommt es zu einem Haufen Geisterlinien. Woran könnte das liegen?

Nur so ein Tip am Rande: Du musst die Dateien nicht verbinden. Einfacher ist es, wenn du Splitter beide Dateien mit gibst, wobei die OSM-Datei die erste sein sollte.

Was meinst du mit Geisterlinien? Darauf geachtet, dass die Höhenlinien in einem anderen ID-Bereich sind hast du schon, oder?

Mitten durch die Karte gehen mehr oder weniger gerade Linien.

Geisterlinien 
 vermutlich kollidieren IDs.

Gruß Klaus

Es klappt, wenn ich splitter OSM und SRTM Daten in einem Aufruf mitgebe :slight_smile:
Hat ein wenig gedauert, bis es gestartet ist. --keep-complete=false musste ich angeben.

Das Thema “ID” ist mir völlig fremd. Was meint ihr damit?

Jeder Node und Way hat eine ID. Im Way ist gespeichert, welche Nodes zu ihm gehören. Die Zuordnung erfolgt mittels Node-ID.

Wenn du nun SRTM-Daten erzeugst, werden auch Nodes und Ways angelegt. StandardmĂ€ĂŸig fangen die wie die OSM-IDs bei 1 an. mkgmap kann dann nicht mehr auseinanderhalten, ob er jetzt den SRTM-Node mit der ID 1234 oder den OSM-Node mit der ID 1234 in den Weg einfĂŒgen soll. So kommt es zu deinen Linien. Du kannst phyghtmap aber auch sagen, er soll bei einem anderen Startwert anfangen. Bspw. 10 Mrd oder so.

Zum Splitten:

java -Xmx10000M -XX:+UseCompressedOops -XX:+UseParallelGC -jar ./bin/splitter.jar --status-freq=0 --output=o5m --max-areas=2048 --max-threads=$threads --overlap=0 --keep-complete --split-file=resources/areas.list ./data/planet.o5m ./data/srtm.o5m

Ganz herzlichen Dank fĂŒr diese Infos!

Wobei ich das nicht wirklich verstehe. Bisher habe ich phyghtmap immer --start-node-id=1 --start-way-id=1 mitgegeben, ohne zu wissen, weshalb. Das funktionierte auch immer. Erst als ich versuchte die Höhenlinien hinter die Wege zu bringen, kamen die Fragen auf. Die NRW-Karte ist jetzt OK, trotz ID=1 bei phyghtmap.

Die Karten mĂŒssen in die Registry von Windows eingetragen werden. Dabei gibt es diese Zeile:
reg ADD %KEY%\Families\Speiche_NRW /v ID /t REG_BINARY /d 481F /f

Dieses “481F” entspricht der ID der Karte, “8008”.

Eine Karte mit “8118” hat “B61F”.

Wie kommt man von der ID auf den Wert, der in die Registry gehört? Kann man das irgendwie umrechnen?

Ausgehend von diesen beiden Beispielen wĂŒrde ich einfach mal raten:

8008 (dezimal) = 1F48 (hexadezimal) → erstes und zweites Byte vertauschen → 481F
8118 (dezimal) = 1FB6 (hexadezimal) → erstes und zweites Byte vertauschen → B61F

Zum Umrechnen von Dezimal- auf Hexadezimalsystem sollte der Windows-Taschenrechner taugen.

Herzlichen Dank! Da bin ich nicht drauf gekommen.

Habe mir mit OpenOffice Calc einen Umrechner gebastelt :slight_smile:

RECHTS(DEC2HEX(A1);2)&LINKS(DEC2HEX(A1);2)

Bisher biete ich die Speichenkarte in 2 Varianten an_

  • Einmal als gmap, die Karte muss einfach in C:\ProgramData\GARMIN\Maps oder auf einem Apple in /Library/Application Support/Garmin/Maps/ kopiert oder verknĂŒpft werden. Aufs GerĂ€t kommt die Karte via MapInstall.

  • Zum anderen als gmapsupp direkt fĂŒr das GerĂ€t. Beiliegend ist das Program gmt und eine .bat Datei, welche gmt veranlasst, die gmapsupp in BaseCamp-lesbare Kacheln zu splitten. Die Dateien fĂŒr die Adresssuche liegen separat bei. Die .bat trĂ€gt die Sachen auch in die Windows-Registry ein.

Eine dieses beiden Varianten soll wegfallen, um Upload-Traffic zu sparen. (Habe nur 1 Mbit/s ins Internet rein)
Ich habe zunÀchst die Variante mit der bat Datei eingespart, da gmap flexibler ist, da das auf PC und Apple lÀuft. Allerdings wollen viele Windows-Nutzer lieber die bat Variante, was in der Handhabung einfacher ist. gmapsupp aufs GerÀt, bat starten, fertig. Das klappt nur auf einem Apple nicht.

Gibt es eine einfache Möglichkeit, eine gmapsupp auf einem Apple zu splitten und das Ergebnis in BaseCamp einzubinden?

Neben der Speichenkarte fĂŒr Radler und Wanderer gibt es jetzt eine Straßenversion zum ausprobieren.
Die Straßen werden nicht durch eine Typdatei gezeichnet, sondern es wird der Default-Wert von BaseCamp bzw.dem GPS benutzt.
Dadurch verÀndert sich die Breite der Wege passend zur Zoomeinstellung, unabhÀngig vom Detailgrad. Das ergibt ein nett anzuschauendes Kartenbild. WÀre toll, wenn man dieses Verhalten auch mit Typdatei nachbilden könnte. Ansatzweise geht das, aber nicht so fluffig.
FĂŒr Motorradfahrer werden BenutzungseinschrĂ€nkungen angezeigt.
Das Routing ist primĂ€r fĂŒr Autos eingestellt. Mit Zwischenzielen kann man radeln und laufen.
Hinter allen Elementen ist eine Quick-Info. So erfĂ€hrt man in welches GewĂ€sser ein Fluss mĂŒndet, zu welchen Zeiten eine Straße nicht mit MotorrĂ€dern befahren werden darf, um welche Art Wald es sich handelt, wieviele Fahrspuren eine Straße hat oder wie schnell gefahren werden kann und noch weitere Dinge.

Die Karte ist noch Beta, fĂŒr Hinweise auf UnzulĂ€nglichkeiten wĂ€re ich dankbar.

WĂ€re es da nicht gĂŒnstiger die Dateien zum Download bei einem Sharehoster zum download zu parken?
Wenn der Speicherplatz nicht reicht, legt man sich mehrere Accounts zu.

Der Flaschenhals ist die Verbindung von meinem PC in das Internet. DSL ist asynchron
 

Mittlerweile habe ich 50MBits was etwa 10,MBits Upload bedeutet. Damit könnte ich durchaus wieder 2 Varianten machen. Aber die Sache mit gmt klappt gut. Ein Download fĂŒr Alles, PC Mac und GPS das ist doch prima

Was toll wÀre: Die Karten nicht auf meinem PC zuhause rechnen zu lassen, sondern auf den Server, von wo aus sie spÀter runtergeladen werden.

Was hindert dich? Solange du keine GUI-Frontends benötigst, tut jeder handelsĂŒbliche Linuxserver den Job, möglicherweise muss man halt die eine oder andere Sache installieren. Theoretisch ginge auch GUI-Kram, aber im Normalfall will man sowas nicht auf ‘nem Server.

Ich habe leider keinen Plan, wie ich das anstellen könnte. :frowning:
Ich habe “1&1 unlimited.” https://hosting.1und1.de/webhosting?linkId=hd.mainnav.webhosting.home

Ach so, nur Webspace. Damit wird’s nicht tun, man brĂ€uchte schon ’nen Server mit Shellzugang.

In der aktuellen Version der Speichenkarte habe ich mich ein wenig nĂ€her mit den Ortsnamen beschĂ€ftigt. Die bevorzugte Einblendung der Ortsnamen gegenĂŒber Straßennamen funktioniert jetzt besser, aber immer noch nicht so gut, wie ich es mir wĂŒnschen wĂŒrde.

Bei der Gelegenheit fiel mit auf, dass mein Oregon 600 die StĂ€dtenamen in der POI-Suche enwandfrei finden kann. Das tat es bisher nie, da kam immer nur “keine Suchergebnisse”.
Ich freute mich schon, doch der Test erfolgte auf der NRW-Karte. Mit der Deutschlandkarte klappt das immer noch nicht. Beide Karten werden mit haargenau denselben Einstellungen und Dateien erzeugt.
Mir scheint, die D-Karte hat einfach zu viele Ortsnamen fĂŒr das Oregon. Das Oregon scheint hier einen Bug zu haben.
Hat jemand eine Idee oder Anregung zu dem Thema?

Witzigerweise findet das Oregon Ortsnamen in der Adresssuche absolut zuverlĂ€ssig und schnell. Nur bei der POI-StĂ€dte-Suche scheitert es. Vielleicht habe ich auch einfach insgesamt zu viele POIs. Ich mag es halt, möglichst viel, auch unnĂŒtzes Zeug, aus der OSM Datenbank rauszuholen.