Speichenkarte

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.

Super, danke; ist das eigentlich ein Garmin Feature oder hast du das selbst gebastelt? Ich hab keine andere Garmin Karte gefunden, die das rendert, auch die Opentopomap nicht.

Der Way muss nicht unbedingt geschlossen sein. 2 nebeneinanderliegende mit dem entsprechender Richtung reichen.

Das ist eher zufällig und daher falsch in der Karte gelandet. In erster Linie ist das eine Rad/Wanderkarte. Viele Radwege verlaufen auf alten Bahntrassen, die auf einem Damm verlaufen. Daher fand ich es sinnvoll, das darzustellen. Nur habe ich dabei das embankment, was als Zusatz an einem Radweg hängt, mit dem embankment als eigenständige Linie, in einen Topf geworfen.

Rendern kann man fast alles. Im Grunde gibt man nur den OSM-Tag an und weist den einer Schlüsselnummer zu. Und dann malt man noch zu dieser Schlüsselnummer eine Grafik für die Darstellung.

Ich bin dankbar für jeden Hinweis auf Fehler oder Dinge die fehlen oder Verbesserungsvorschläge!
.
.
.
Gerade habe ich entdeckt, dass bei Mountainbikerelationen statt des Namens nur “MTBRoute” erscheint. Das ist ein Fehler.
.
.
.
Entweder hier oder per Mail an info(ät)speichenkarte~de

Seit gut 3 Jahren bin ich jetzt mit start-node-id 10000000000 in den SRTM Daten klar gekommen. Neuerdings klappt das nicht mehr. Wenn ich 1099511627776 benutze, funktioniert es.

Woran liegt das? Sind in den OSM Daten jetzt IDs größer 10000000000 ?

Ja:
https://www.openstreetmap.org/node/10000000000
http://osmstats.neis-one.org/?item=elements

Andere hatten auch Probleme damit:
https://twitter.com/geofabrik/status/1566763301350014977

Eigentlich ein gutes Thema für die Data Model Diskussion: hab’s mal hierhin gepostet: https://github.com/osmlab/osm-data-model/discussions/20