Gelöst&Howto: osmconvert "verliert" ways beim schneiden von srtm-daten

Communities Deutschland (Germany)
61

höhenlinien und immer noch kein ende…

vorab erstmal: --complete-ways arbeitet nach wie vor fehlerfrei

allerdings mit einem ergebnis, das ich so nicht vorausgesehen habe. da angeschnittene wege jetzt komplett drinbleiben und srtm2osm riesenlange wege erzeugt, dehnt sich meine karte, geschnitten an der indisch-nepalesischen grenze stellenweise bis weit nach tibet hinein aus. das kann ich durch anpassen der srtm2osm-kacheln noch optimieren, da ich aber nur rechteckige bereiche erzeugen kann, ist da das ende der fahnenstange schnell erreicht.

schneide ich ohne --comlete-ways, gibt’s entlang der schnittlinie jede menge artefakte, und zwar bei ways, die den schittbereich verlassen, einen bogen schlagen und zurück kommen. das passiert bei höhenlinien aller nase lang. die artefakte entstehen so:

srtm3

der way (grün) liegt über der schnittlinie (rot). beim schneiden werden node #2 und #3 gelöscht und zu broken-refs. die beiden übrigbleibenden abschnitte (#1 → #5 und #4 → #6) behalten aber denselben way id, so das der renderer später annimmt, er müsse #5 und #6 verbinden - schon ist das artefakt da. ein sauberer schnitt an dieser stelle müsste aus einem der beiden abschnitte einen neuen way erzeugen.

ich könnte mir zwei lösungen vorstellen:

quick and dirty: lange ways werden automatisch aller x nodes aufgetrennt - dann könnte man mit --complete-ways schneiden, und weil die die ways jetzt kurz sind, werden die schnittgrenzen im großen und ganzen eingehalten und nur mäßig weiter nach außen verlegt.

die bessere, aber sicher aufwendigere lösung: osmconvert erkennt, dass zwischen #5 und #6 broken-refs liegen und folgert daraus, dass bei #6 ein neuer way erzeugt werden muss.

@markus: ich weiß auch, dass ich hier mit einem sehr speziellen problem ankomme, und es gibt vielleicht wichtigeres - also sag an, wenn dir das zuviel aufwand für zu wenig nutzen ist

micha

62

@laufkaefer

Wenn ich das beo osmconvert richtig gesehen hab schneidet osmconvert nicht sondern Node 2 + 3 werden weggelssen.

Die z.B. Renderer folgern daraus das der way von Node 1 zu Node 4 verläuft.

osmconvert müsste erst am Schnittpunkt einen Node kreieren mit der selben Way-ID und in die Reihenfolge einsortieren (Anfang und Ende)!!! - das wird mommentan nicht gemacht.

In deinem speziellen Fall würde es sinn machen dem geschnittenen Way der wieder Teilweise zurückkommt einen neue ID mitzugegeben,aansonsten müsste der Way umsortiert werden das der Anfang und Ende stimmt!

Zusätzlich kommt das Problem bei “normalen” daten auf das Flächen auch als Way definiert werden bzw. noch schwieriger als Relationen werden meherere Way’s zu einer Fläche zusammen gesetzt das würd dadurch alles komplett verhauen!!

63

ah, ok. in dem falle könnte man ja auch die erste node außerhalb behalten und dafür mit complete-ways schneiden. das würde die neu-kreation von nodes vermeiden. ein neuer id für die 2. weghälfte müsste dann aber trotzdem sein.

funktionieren würde das so nur bei linien, bei polygonen müßte der way dagegen geschlossen werden (was ja beim momentanen verhalten auch passiert).

was bei komplizierten relationen kann ich grad nicht so richtig absehen.

64

ich hab jetzt mal schnell ein tool geschrieben, dass die langen wege in kürzere segmente auftrennt. in kombination mit --complete-ways kriegt man jetzt schöne saubere schnittkanten für höhenlinien.

falls ich nicht der einzige bin, der daran interesse hat, stell ich’s auch zur verfügung.

65

@laufkaefer, hatte daran Interesse.
bezüglich austauschen von osmosis, meinte ich bei der Erstellung von SRTM Höhenlinien im Garmin .img Format (also das zuschneiden - mehr nicht). Wenn da jemand die Anleitungen im Wiki ergänzen könnte (also etwa bei srtm2osm ) wäre super…

Mich ärgert das bei osmosis und dann mkgmap häufig einfache Geraden über irre Distanzen falsch und unschön sind. Das würde ich gerne vermeiden…

66

benutzung so: SRTM2OSMsegmenter input-file output-file max-nodes

http://geocaching-dresden.de/SRTM2OSMsegmenter.zip

das tool macht keinerlei berechnung/veränderung an irgendwelchen koordinaten, es sortiert einfach das xml neu, und zwar so:

  • durchlauf 1: alle nodes werden 1:1 von input nach output kopiert, id’s bleiben erhalten
  • durchlauf 2: alle ways werden in stücke aufgeteilt, die maximal max-nodes lang sind. der einfachheit halber hat der erste weg den id 1 usw. - d.h. sämtliche original-id’s gehen verloren, was bei reinen srtm-layern ja kein problem ist. ganz nebenbei ist output dann auch noch sortiert (type, id), d.h. der splitter sollte ohne --mixed auskommen (meine vermutung, nicht getestet)

das ist noch nicht mal ein tool, eher ein skript, d.h. ich habe sämtlichen firlefanz von wegen fehlerbehandlung oder so weggelassen - wenn irgendwas nicht stimmt, wird kommentarlos abgestürzt. scheint aber ganz stabil zu laufen, hat gestern anstandslos 18 gb srtm2osm-rohdaten umsortiert.

du kannst es ja mal testen. meine toolchain damit:

  1. srtm2osm
  2. SRTM2OSMsegmenter (ich nehme 250 als max-nodes), sämtliche langen ways verschwinden, damit weder beim schneiden noch beim splitten auch nur ein einziges artefakt
  3. osmcovert zum schneiden (mit --complete-ways, files > 2 gb geht z.z. nur unter linux weil unter win zlib irgendein problem hat)
  4. mkgmap splitter
  5. mkgmap

btw: ich rechne grad noch an den höhenlinien für indien rum, die werden in den nächsten tagen fertig, die fehlen ja bei openmtbmap noch - willste die haben?

micha

67

Schade, das tool ist eine .exe.
Damit kann ich als linuxler nix anfangen :frowning:

68

Hochladen könnte ich sie natürlich…
gibt es eigentlich irgendwelche Möglichkeiten die viewfinderpanoramas 1" Daten zu verarbeiten???

Das wäre mir am liebsten, um für Alpen wie Himalaya mal vernünftige Daten zu rendern… die 3" sind halt schon schlechter…

69

Schau Dir mal http://www.opendem.info/ an. Da gibts eine Anleitung “Open DEM SRTM DSM Processing Howto” wie man SRTM-Daten mit den viewfinderpanorama-Daten ergänzt, um die Löcher zu flicken.

Grüße, Max

70

@kellerma: das obige zip enthält jetzt auch den quellcode zum selberkompilieren, hatte ich gestern vergessen. nicht lachen, mein 1. gehversuch in c…

groundtruth (auch von igor brejc) enthält neuerdings fast dieselbe funktionalität wie srtm2osm - ich hab’s noch nicht gestestet, und konnte auf die schnelle auch nichts zu 1’'-daten finden, aber viell. bewegt sich da ja was.

71

Ah, ok, jetzt gefunden.

Mmmh, der gcc scheint nicht klar zu kommen, bricht beim assemblieren ab:

Daher hab ich mal clang genommen, der packt’s :wink:

Mmmh, das “out.osm” ist viel kürzer als das “input.osm”, durch die Wegaufsplittung muesste es nicht gerade umgekehrt sein?

Mmh die Wege scheinen keine Knoten mehr zu besitzen.

72

ich hab’s mit mingw kompiliert, da läufts ohne fehlermeldung: gcc SRTM2OSMsegmenter.c -o SRTM2OSMsegmenter.exe

out wird kürzer als in, weil 1. ein bisschen whitespace wegfällt und 2. srtm2osm mit way id=“1000000000” anfängt, der segmenter aber mit 1, spart also pro weg bis zu 9 byte.

das tool parst nicht wirklich das xml (weil ich befürchtete, das dann der speicher nicht reicht), sondern liest input zeile für zeile und entscheidet per string-match, ob node, way oder nd ref. das matching geschieht in

zeile 71: nodes
zeile 85: ways
zeile 91: nd ref
zeile 100: tags

kannst du mal eine kleine test-input von dir posten?

73

Ah ja,

wenn ich keine Output-Datei angebe, gibt es keine Knoten(-Referenzen) in den Wegen der output.osm:
./SRTM2OSMsegmenter input.osm

bei Angabe der Ausgabedatei schon :wink:
./SRTM2OSMsegmenter input.osm output.osm
bzw.
$ cat input.osm ; ./SRTM2OSMsegmenter input.osm output.osm 200

Lasse ich die Input-Datei als Parameter auch noch weg, gibt’s eine lustige Ausgabe:

reading from: input.osm, writing to: SSH_AGENT_PID=1884, segment length: 0

EDIT:
Der mingw meckert tatsächlich nicht:
$ /usr/bin/amd64-mingw32msvc-gcc SRTM2OSMsegmenter.c -o SRTM2OSMsegmenter.exe -Wall -std=c99
$

74

wie gesagt, mehr ein skript als ein tool, macht bei den parametern keinerlei tests. der 1. ist input, der 2. output, der 3. die max. länge der neuen ways. wenn du nicht alle 3 angibst, kommt das programm durcheinander

75

wiki update zum thema:

https://wiki.openstreetmap.org/wiki/Howto_render_Garmin_countour_layers_with_no_artefacts

76

Sehr schön! :slight_smile: Verlink es ruhig auf anderen Seiten und überleg dir, ob du noch Wiki-Kategorien hinzufügen kannst, damit die Seite auch gefunden wird.

Zum Zerlegen von langen Ways in kleine Häppchen:
Wenn diese Aufgabe sehr oft erledigt werden muss oder arg zeitraubend ist, kann man natürlich auch drüber nachdenken, eine entsprechende Option in osmconvert zu integrieren.

P.S.:
Wenn du deinen ersten Beitrag in diesem Thread editierst, dann kannst du den Thread-Titel ein bisschen anpassen. Aus der ursprünglichen Fehlermeldung ist inzwischen ja ein echtes How-To geworden, in dem du rausgefummelt hast, wie man SRTM-Daten vernünftig importieren kann.

77

ich bin mir nicht richtig sicher, ob es lohnt, das in osmconvert einzubauen. das scheint mir schon ein spezialfall zu sein, weiß nicht, ob das außer mir groß jemand braucht. ich würde viell. erstmal ein bisschen feedback abwarten. aber: wenn du es für sinnvoll erachtest, dann bedien dich an meinem source code, soviel du willst…

an der geschwindigkeit des segmenters hab ich nichts zu meckern. ich hab nicht wirklich einen benchmark gemacht, jedenfalls dauern 18gb rohdaten 20-25 min., damit kann ich leben. speicherverbrauch ist sehr gering, weil die daten immer zeilenweise gelesen und sofort wieder “vergessen” werden.

78

Danke für das howto bzw den segementer. Werde das Morgen mal ausprobieren…
Die Länderrohdaten von srtm2osm hab ich zum Glück noch gespeichert, genauso wie die Länderpolygone… Alle meine Höhenlinien upzudaten wird wohl trotzdem 1-2 Tage Arbeit und dann nochmal 2-3 Tage zum uploaden…

Für die viewfinderpanoramas 1" Daten gibt es also weiterhin keine Lösung, oder? (Soweit ich sehe vertragen die sich ja nicht mit srtm2osm…)
Groundtruth nur für Höhenlinien habe ich noch nicht so richtig verstanden bzw reingelesen. Müssen wir wohl mal Igor fragen ob das inzwischen geht. Andere Lösungen habe ich auch noch nicht gefunden…

79

Ups, groundtruth wurde inzwischen ja auch mehr oder weniger eingestellt (seit über 1 jahr keine upates mehr) und unterstützt viewfinderpanoramas 1" nicht! Maperitive - der Nachfolger kann SRTM1" verarbeiten - aber das wird wohl wenig bringen weil maperitive soweit ich sehen kann keinen .osm oder .pbf output erzeugt (oder hab ich da was übersehen?)…

80

Es gibt noch eine Lösung, die verwende ich und bin damit hoch zufrieden: http://katze.tfiu.de/projects/phyghtmap/
Kann SRTM1, SRTM3 sowie die Viewfinderpanoramas Daten.

Ich benutze allerdings noch ein paar Patches:
https://build.opensuse.org/package/files?package=phyghtmap&project=home%3Akukuk

Thorsten