Speichenkarte

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.

Sorry für die späte Rückmeldung. Bin erst heute dazu gekommen, einen Test mit neuen Höhenlinien durchzuführen.

“-maxwaynodes 5000” war’s auch nicht. Nach wie vor gibt’s diese seltsamen Höhenlinien-Fehler:

Gruß, T.

Der Parameter kann auch nicht die fehlerhaften SRTM Daten korrigieren. Es ging dabei um die Endlosschleife.
Bessere DEM Daten bekommt man so nicht.
Vielleicht aber hier:
http://viewfinderpanoramas.org/dem3.html

man_made=embankment ist ein einseitiger Abhang, wird in Carto auch so gerendert als Linie mit kurzen Spitzen auf einer Seite. Auf der Speichenkarte (Basecamp) sieht es aber eher wie ein Wall mit beidseitigem Abhang aus, also beidseitige Spitzen. Ist das so gewollt?

Das erste stimmt, das zweite (für einen linearen, nicht-geschlossenen Way) halte ich daher für falsches Rendering. Ein Wall mit beidseitigem Abhang muss als geschlossener Way gemappt werden, gegen den Uhrzeigersinn, da der Abhang immer rechts vom Way ist. Führt ein anderer Way drüber, wird der Wall als embankment=yes an den Way getaggt.

–ks

Danke für den Hinweis, wieder was dazu gelernt. Wird korrigiert.