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
Hallo,
der Versatz ist schon in den Rohdaten vorhanden, das liegt nicht an den Programmen. Wäre aber schön, wenn diese die Möglichkeit des Ausgleichens mitbringen - eben wegen des Unterschieds zwischen SRTM und Viewfinder. Am Übergang sieht man es zu deutlich. (Mich stört es nicht so sehr, da ich an dieser Stelle den Linien-Abstand von 20m auf 50m ändere und da einen sichtbaren Übergang habe.)
Grüße
Mario
Jip, auch nach meiner Erfahrung liegt der Versatz in den Rohdaten. Wobei ich zugeben muss, nur srtm2osm bisher verwendet zu haben. Da habe ich aber mit unterschiedlichem Versatz arbeiten müssen… Natürlich möglich dass srtm2osm hier bei viewfinderpanoramas 3" sich anders wie bei SRTM 3" verhalten hat - gleichzeitig aber beide falsch behandelt hat…
@Thorsten, dein gzip Patch hat einen Syntax error:
SyntaxError: (‘invalid syntax’, (‘c:\program files\python_2.7.2\lib\site-packages\phyghtmap-1.23-py2.7.egg\phyghtmap\osmUtil.py’, 43, 12, ‘\t\tif (gzip)\n’))
da fehlt soweit ich sehen kann ein Doppelpunkt. So sollte der Patch IMHO ausschauen (bitte korrigier mich wenn ich falsch liege)
-
if (gzip): -
os.system("gzip -9f " + fname + " &")
wenn bei phyghtmap die max. weglänge konfigurierbar ist, dann brauchst du den segmenter nicht. eine max. weglänge von 250 nodes dehnt bei nutzung von osmconvert mit --complete-ways das originale poly ungefähr 2-4 km nach den seiten aus, bei 2000 nodes als default werden es also wohl 15-20 km sein.
micha
BTW der gzip patch ist (zumindest auf windows) nicht benutzbar. hab ihn wieder rausgenommen, neukompiliert, und phyghtmap rennt auch unter Windows sauber durch.
@bezüglich srtm2osmsegmenter – okay dann fragt sich jetzt ob -max-nodes=2000 ausreicht, oder man bei phyghtmap noch kleiner werden muss…
Hallo,
Ok, der richtige gzip patch für phygthmap ist jetzt auch hochgeladen.
Ansonsten: Wie ich die Ausgangsdaten für tilesplitter/mkgmap erzeuge habe ich jetzt hier dokumentiert: http://osm.thkukuk.de/srtm.html
Ich frage mich jetzt gerade nur, ob man daraus nicht einen neuen Thread machen müste …
Thorsten
okay werde ich nochmal ausprobieren. Bei probs schreib ich hier nochmal. BTW ein pbf patch wäre noch genialer…
gzip patch funktioniert noch immer nicht bei mir, ohne Doppelpunkt syntac error, mit Doppelpunkt:
Traceback (most recent call last):
File “C:\Program Files\python_2.7.2\Scripts\phyghtmap-script.py”, line 9, in
load_entry_point(‘phyghtmap==1.23’, ‘console_scripts’, ‘phyghtmap’)()
File “C:\Program Files\python_2.7.2\lib\site-packages\phyghtmap-1.23-py2.7.egg\phyghtmap\main.py”, line 185, in main
processHgtFile(hgtDataFileName, opts)
File “C:\Program Files\python_2.7.2\lib\site-packages\phyghtmap-1.23-py2.7.egg\phyghtmap\main.py”, line 140, in processHgtFile
opts.startId = output.done()
File “C:\Program Files\python_2.7.2\lib\site-packages\phyghtmap-1.23-py2.7.egg\phyghtmap\osmUtil.py”, line 43, in done
if (gzip):
NameError: global name ‘gzip’ is not defined
Könntest du evtl einfach eine fertig gepatchte Version (also Sourcecode) irgendwo hochladen, bzw osmutil.py sowie main.py gepatcht auch im repository aufnehmen? Weil die Diff Files kann ich mit SVN zumindest einmal nicht mergen, und einen Checkout für das Projekt finde ich bei suse auch nicht. Kenne mich allerdings auch nicht damit aus. Standard SVN oder GIT wäre für mich etwas verständlicher…
Ausserdem: irgendwie wäre es schon cool wenn phyghtmap gleich ein einziges osm oder osm.pbf ausspucken würde. Da man das im Prinzip ja eh braucht (die Kacheln sind einfach zu klein, die Alpen haben bei mir z. Bsp 308 Kacheln gebraucht mit Option view1) bzw sonst nicht ums mergen rumkommt.
Dazu würde es Sinn machen, in deinem Prozess osmosis durch osmconvert auszutauschen, oder gibt es dabei Probleme?
Hi,
Das ist noch immer der alte Patch … ich sehe da im diff:
-
if self.gzip: -
os.system("gzip -9f " + self.fName + " &")
(ist natürlich nicht die einzige Änderung)
Ich werde den gzip Patch auch noch mal überarbeiten, damit die Daten gleich komprimiert geschrieben werden.
Ich habe kein SVN oder GIT dafür. Ich werde mir morgen nachmittag was überlegen, vorher werde ich wahrscheinlich keine Zeit haben.
Wenn der Kram nur nicht in Python geschrieben wäre …
Es gibt 2 Programmiersprachen, die ich nicht mag: Python und Java, leider ist fast alles für OSM darin geschrieben 
Du kannst verwenden was immer Du möchtest. Ich habe osmosis installiert, weil ich es für einige andere Sachen brauchte und osmosis das erste Tool war, was ich gefunden hatte und alle meine Anforderungen erfüllte. Da ich keine Lust habe, mehrere Tools für die gleiche Aufgabe zu verwenden bzw. alle Scripte anzupassen, werde ich erstmal bei osmosis bleiben.
Thorsten
ups, hast recht - ich hab da einen Fehler gemacht. Aber auch mit neuem Patch will es noch nicht…
evtl geht “import os” nicht?? bzw der Patch funktioniert NUR wenn gzip als Befehl bekannt ist. Unter Windows geht das Standardmäßig natürlich nicht.
Die Fehlermeldung ist jetzt nämlcih:
‘gzip’ is not recognized as an internal or external command, operable program, or batch file.
Das ganze lässt sich natürlich lösen, indem gzip.exe nach c:/windows kopiert… (und es sich vorher hier runterlädt: http://www.gzip.org/ – entpacken und gzip.exe nach windows oder alternativ installieren und Installationsverzeichnus zum path hinzufügen).
Letzteres ist die elegantere Lösung.
höhö 
Stimmt gottseidank nicht so ganz, C, Ruby, Perl, Flash, Javascript, psql, OSM ist multi-lingual… 
Gibts außer C wirklich noch andere brauchbare Programmiersprachen? Nö, glaub ich nicht. 