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…
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
@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.
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 
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.
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?
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 
./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
$
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
wiki update zum thema:
https://wiki.openstreetmap.org/wiki/Howto_render_Garmin_countour_layers_with_no_artefacts
Sehr schön! 
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.
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.
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…
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?)…
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
Hallo Thorsten,
ich wäre insgesamt an deinem Vorgehensmodell interessiert.
Hast du das schon irgendwo beschrieben?
Und was genau verändern / erweitern deine Patches?
Klaus
Hallo Klaus,
es lohnt sich, sich mit Phyghtmap näher zu beschäftigen. Der größte Vorteil für den Anfang: Die Daten sind schon gekachelt (prinzipiell 1°-Grenzen) und müssen nicht extra geschnitten werden und ab Version 1.23 gibt’s auch noch Unterstützung für das OSM-0.6-Format.
Wer neu schneiden möchte, kann die Daten recht einfach in eine einzelne Datei zusammenführen, Bounding-Polygon darauf ansetzen, splitten usw. - eben so wie man es vom Erzeugnis von srtm2osm kennt. So mache ich es jedenfalls: http://wiki.openstreetmap.org/wiki/User:Garmin-User#H.C3.B6henlinien
Grüße
Mario
@Thorsten. Warum ist den corrx und corry wieder entfernt? Ich finde ohne corrx /corry kann man die viewfinderpanoramas Daten komplett vergessen wegen dem gut 20m Versatz.
@garmin-user — warum benutzt die output in osm v6? mkgmap/mkgmap_splitter sollten doch auch mit ox m5 output klarkommen - der weniger Speicherplatz verbraucht. Dazu finde ich die 1° Kachelung eher blöd - wenn man die Daten deswegen vorher mit osmconvert mergen muss, um sie anschließend wieder zu splitten (wenn man eben ein Boundy Polygon aussschneiden möchte). Wird im Falle der Benutzung von phygtmap srtm2osmsegmenter nicht mehr benötigt?
Hi,
OSM-0.6, weil ich mein Verfahren (Merge per Script auf meiner Wiki-Seite) schon länger benutze, aber Osmosis kein 0.5 mehr liest. (Bei 0.5 musste nur zusätzlich je Element on-the-fly das Versions-Attribut hinzugefügt und im Header die OSM-Version auf 0.6 geändert werden.) Für den Bereich DACHCZ dauern die Downloads mit Umwandlung gerade mal ne halbe Stunde - mergen dann weniger als 5 Minuten. Osmosis würde beim Mergen von 159 Kacheln wirklich Zeit brauchen, bei gleichem Ergebnis. Ein Vielfaches davon dauert sogar, gleich srtm2osm unter Linux mittels Mono zu verwenden.
Grüße
Mario
Ich vergaß: Der SRTM2OSMsegmenter (musste erst nachschauen) wird nicht benötigt. Lange Linien werden an der 1°-Kachelgrenze korrekt abgeschnitten und bekommen im nächsten Tile eine neue ID, so wie auch Abschnitte der gleichen Linie innerhalb der aktuellen Kachel, wenn sie durch die Kachelgrenze unterbrochen wird weil der mittlere Teil außerhalb liegt. Und: Sind zu viele Nodes in einer 1°x1°-Kachel, werden automatisch 2 erzeugt mit 1°x0.5°.
In meinem Style File archive ist ein kurzes howto, aber eine ausführliche Beschreibung fehlt noch.
Die Weglänge ist konfigurierbar, aber max. 2000 Nodes lang. Bei Kanada gibt es Wege die sonst zu lang sind und wo Tools ausgestiegen sind. Ausserdem Bugfixes, die für die USA notwendig waren.
Und ja, ich habe die Patches an die Autoren geschickt, aber nie eine Antwort erhalten.
Thorsten
Hallo,
Wirklich mit phyghtmap oder mit Srtm2Osm? Da gab es vor einiger Zeit schon mal einige Diskussionen drüber. Ja, Srtm2Osm hat einen Versatz, was aber ein Srtm2Osm Bug zu sein scheint. Bei phyghtmap konnte mir bisher keiner eine Gegend mit Versatz zeigen. Ich habe aber den Patch angepaßt und wieder hinzugefügt.
Thorsten