Speichenkarte

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.

Die Speichenkarte ist bisher nur für Garmin gemacht. Dafür gibt es das nette Tool MKGMAP.
Gelegentlich nutze ich ORUX auf meinem Androidgerät, das kann Garmin-gmapsupp anzeigen. Das ist aber nicht so optimal. Besser wäre ein Format, welches direkt zu Android passt. Bei Openandromaps hat das die Endung xxx.MAP.

Wie kann man diesen .MAP herstellen? Gibt es vergleichbares Tool wie mkgmap?

Mit mkgmap kann man neuerdings abfragen, ob ein Element in einem residentiel-Polygon liegt.

service, residential, grade1 sind recht dünn gezeichnet, in Städten mit hoher Wegedichte ist das auch nötig. Außerorts könnten diese Wegetypen durchaus dicker dargestellt werden.
Das habe ich mal so umgesetzt, ist gar nicht so schlecht.

Welche Anwendungen dieses Parameters wäre noch denkbar?

hallo hast du dafür eine Lösung gefunden ? da ich auch Orux nutze wäre das interessant !

gruss

Leider nein, ich habe mich nicht weiter damit beschäftigt. Mittlerweile habe ich ein leistungsstärkeres Telefon (DoogeeS60), damit läuft Orux in Verbindung mit einer “gmapsupp” ganz annehmbar.

Bin gerade zufällig auf diesen älteren Beitrag gestoßen. Kämpfe auch immer wieder mit Geister- oder völlig unsinnigen Höhenlinien, vor allem in den Alpen.

Wie kann ich denn splitter zwei Dateien angeben? Einfach so?

java -Xmx1500M -ea -jar splitter.jar (--...) osm.pbf srtm.pbf 

Gruß, T.

Geisterlinien bekommst Du wahrscheinlich, wenn die ids in der Srtm Datei sich mit denen von OSM überschneiden. Da wäre dann das Mischen der Dateien mittels splitter genau verkehrt. Man kann entweder eigene Kacheln nur mit den Höhenlinien machen oder - wenn die IDs passen - alles zusammenmischen. Dabei gibt es dann entweder die Option, das vorab mit osmosis zu machen, so dass die Daten nach Typ und Ids sortiert sind, oder in splitter, dann sollten die Ids zumindest aufsteigend sein, sonst must Du auf die keep-complete Funktionalität verzichten,
was gerne mal zu einem leeren Bodensee oder so führt.
Wenn Du die SRTM Daten mit srtm2osm erzeugst, dann möglichst die Optionen -firstnodeid , -firstwayid und -incrementid verwenden, z.B.
für die startids dann einen sehr großen Wert, z.B. 2^40 =1099511627776. Damit bist Du weit weg vom Maximum 2^63 und auch vom aktuellen höchsten Wert in OSM.

Ja, genau.
keep-complete auf true setzen, sonst sind einige Polygone unvollständig

keep-complete is per default auf true

OK, ich erwähnte es, weil ich hier schrieb, dass es nur mit false klappt.
Das war aber nur, weil ich viele srtm Dateien auf einmal in den Splitter steckte

Ok, danke! Werd ich mal ausprobieren.

Irgendwie werde ich nicht ganz schlau aus dem Resultat meiner Versuchsreihe. Habe den splitter mit verschiedenen Parametern gestartet:

  • Ohne --keep-complete
    splitter und mkgmap laufen zügig durch. In der Karte sind fehlerhafte Höhenlinien zu sehen (Sechseck- oder Rautenform, sehr große Höhensprünge).

  • Mit --keep-complete=false
    Gleiches Resultat wie ohne --keep-complete.

  • Mit --keep-complete=true
    splitter marschiert durch und bleibt dann in einer Art Endlosschleife stehen. Muss den Vorgang abbrechen.

Geisterlinien habe ich keine mehr. Die Alpen-Höhenlinien lade ich mit srtm2osm. Evtl. sind die Höhendaten bereits fehlerhaft…

Gruß, T.

Ja, es gibt Lücken in den SRTM Daten, insbesondere in denen, die srtm2osm per default runterlädt.
Endlosschleife in splitter hört sich nach Speichermangel an.
Falls Du das Programm srtm2osm verwendest, schau mal bitte bei https://wiki.openstreetmap.org/wiki/Srtm2Osm#Garmin
nach, ob Du auch alle dort erwähnten Optionen verwendet hat. Ich tippe mal, dass Du nicht -maxwaynodes 5000 dabei hast und deswegen
elend lange Wege bekommst, die wiederum den Speicherverbrauch in die Höhe treiben. Für eine genauer Analyse bräuchte ich die Ausgaben vom splitter.