sehr schön dass die patches dann wohl innerhalb der nächsten Wochen integriert werden. Mir ist heute leider beim upgraden auf opensuse 12.1 der Server böse abgeschmiert - daher bin ich seitdem zu nichts mehr gekommen. Hab noch immer nicht wieder alles am laufen da sich die Backups nicht alle fehlerfrei einspielen ließen…
Auf opensuse 12.1 bekomme ich phyghtmap >=1.24 aber genausowenig zum laufen (selber Fehler) wie unter Windows 7 x64 oder opensuse 11.4 (und das opensuse 12.1 ist grad frisch aufgesetzt, da kann es nicht an irgendwelchen alten Sachen liegen…) -
Und evtl liegt bei mir der Fehler auch daran dass das bash skript mit phyghtmap 1.23 inkompatibel ist ??? – 1.24 oder 1.25 bekomme ich ja leider nicht zum laufen. Wenn ich die Daten direkt an mkgmap ohne sortieren usw geschickt hab- hat es ja bei mir immer funktioniert.
ich habe heute erst eine neue Version eingestellt, die ich meinte.
Der Versuch von vor paar Tagen lief mit kleinen Dateien, die zu schnell erzeugt waren (gleicher Zeitstempel). Das kann auch bei großen Gebieten mit nur sehr wenigen Höhenlinien in einer Kachel oder bei sehr schmalen Kacheln mit x.9- bzw. x.1-Grad-Grenzen passieren, weswegen ich jetzt statt der Erstellungs-Zeit die erste vorkommende Node-ID zum Sortieren auswerte. Das dauert aber zusätzliche Sekunden (bis zur halben Minute für Mitteleuropa). Was ich jetzt besser finde: Er werden nicht die geschriebenen Dateien ausgegeben, sondern zur Kontrolle der Reihenfolge die erste Node- bzw. Way-ID der aktuell übertragenen Datei.
das wäre möglich. Ich weiß nicht, ab genau welcher Version Phyghtmap direkt in OSM-0.6 schreiben kann. Da hatte ich im Script nachgebessert (Header: osm version auf 0.6) - ließe sich aber mühelos wieder einfügen. Ich kopiere es aus der History hier hin.
Ach ja: Nicht vergessen, den Schalter “–versions-Tag=1” bei Phyghtmap mit reinzunehmen. Oder eben doch gleich den Splitter auf die topo.osm ansetzen, aber dabei version 0.5 lassen:
bei “cat $onefile | head -n 2 | sed ‘s/=“0.5”/=“0.6”/’ > topo.osm” den sed-Befehl aus der Pipe nehmen.
#/bin/sh
cd maketopo
onefile=$( ls lonlat.osm | head -n 1 )
cat $onefile | head -n 2 | sed ‘s/=“0.5”/=“0.6”/’ > topo.osm
bounds="lon([0-9.])_([0-9.])lat([0-9.])_([0-9.])."
minlon=$( ls lonlat*.osm | sed “s/$bounds/\1/” | sort -n | head -n 1 )
maxlon=$( ls lonlat.osm | sed “s/$bounds/\2/” | sort -n | tail -n 1 )
minlat=$( ls lonlat.osm | sed “s/$bounds/\3/” | sort -n | head -n 1 )
maxlat=$( ls lonlat.osm | sed “s/$bounds/\4/” | sort -n | tail -n 1 )
echo “<bound box="$minlat,$minlon,$maxlat,$maxlon" origin="SRTM3-VIEW3"/>” >> topo.osm
for file in lonlat.osm ; do
echo “Nodes $file => topo.osm”
cat $file | grep ‘^<node id=’ >> topo.osm
done
for file in lonlat.osm ; do
echo “Ways $file => topo.osm”
cat $file | grep ‘^<way id=’ >> topo.osm
done
cat $onefile | tail -n 1 >> topo.osm
echo -n “Enter-Taste”
read REPLY
Nein osm-0.6 kann phyghtmap schön seit 1.21 schreiben und benutze ich auch… - dein neuestes bash will bei mir gar nicht (läuft dafür aber innerhalb von 3min durch):
openSUSE-121-64-minimal:/home/contourlines # bash merge_osm_user.sh
Erstelle nach ID sortierbare Datei-Liste…\n
Nodes ab 34342532 => topo.osm
Dann fertig und topo.osm mit 391.4MB erstellt (anstelle 17GB). Scheint evtl auch irgendwie an den Daten zu ersticken?? Ausserdem passen die Koordinaten nicht überein!
(phyghtmap command weiterhin “phyghtmap --area=5.5:45.2:16.7:48.7–jobs=1 --max-nodes=250 --osm-version=0.6 --start-node-id=10000000 --step=20 --output-prefix=alps --line-cat=500,100 --viewfinder-mask=1” — ist halt Version 1.23 samt patches von kukuk ---- werde morgen mal ohne patches von kukuk das ganze durchlaufen lassen, dann halt leider auch ohne max-nodes=250)
Edit: Mir scheint eher so, dass dein neuestes bash bei mir einfach nur das erste Tile einliest und wieder ausgibt - die größe stimmt überein. Keine Ahnung was da falschläuft…
Phyghtmap 1.25-1 schmiert bei deiner Befehlszeile bei mir auch ab. Nach Entfernen von --max-nodes=250 läufts. Da muss der Fehler liegen. Ist 250 zu klein? Explizit 1000000 angegeben - läuft.
Nein. --max-nodes hab ich sogar 1000000000 angegeben bzw auch komplett weggelassen. Fehler bleibt immer identisch. Habs ja mit 1.24 genauso probiert (ungepatcht) – das akzeptiert ja nicht einmal max-nodes…
Ich sehe oben an den Ausgaben mit “\n”, was eine extra Leerzeile ausgeben müsste, dass etwas bei der Interpretation nicht stimmt. Ich gehe davon aus, dass sich meine Dash etwas anders als bei Dir verhält. (Script vielleicht auf Bash umgestellt?) Gerade bei den Kleinigkeiten gibt es da doch paar Unterschiede. Vielleicht sollte ich es auch mit der Bash versuchen, die sollte bei jedem Linux drauf sein.
ups, versuche es gerade mit “sh merge_osm_user.sh” anstelle bash merge… muss sagen dass ich alle skripte (bis auf perl) zum mergen bisher mit bash aufgerufen hab, weil ich davon ausging dass es mehr kann wie sh… mal schauen was jetzt passiert (Daten hab ich jetzt mal mit ungepatchter 1.23 erstellt).
… selbes Problem auch unter Opensuse sh - siehe Output:
openSUSE-121-64-minimal:/home/contourlines # bash merge_osm_user.sh
Erstelle nach ID sortierbare Datei-Liste…\n
Nodes ab 34410538 => topo.osm
Ways ab 34410556 => topo.osm
Eck-Koordinaten: kaputt_45.25,kaputt_10.00,kaputt_45.62,kaputt_11.00\n
Enter-Taste
openSUSE-121-64-minimal:/home/contourlines # sh merge_osm_user.sh
Erstelle nach ID sortierbare Datei-Liste…\n
Nodes ab 34410538 => topo.osm
Bei mir läuft es unverändert auch in der Bash (nur mit #!/bin/bash statt sh).
Ein Fehler ist erstmal, dass ich nicht an den Präfix (sieht man bei den Eckdaten) gedacht habe. Entsprechende Zeile müsste auf
bounds=“.lon([0-9.])([0-9.])lat([0-9.])([0-9.]).”
.* vor lon, hat aber auf die Dateiliste keinen Einfluss.
Das \n stört mich. Wahrscheinlich wird die Dateiliste mit den ersten Node-IDs zum Sortieren anders aufgebaut. Sobald man diese in eine Variable gibt, werden die Zeilenenden zum Leerzeichen und jede Zeile ist fortlaufend in einer. Dem begegne ich mit \n, um die Ausgabe dann doch wieder zeilenweise mit dem sort-Befehl auswerten zu können. Bei deinem Linux funktioniert das \n etwas anders, in dem Fall gar nicht. Ich suche eine neue Möglichkeit, evtl. etwas mit \x0A.
ich lasse es gerade mit dash nochmal durchlaufen, mal schauen was passiert.
…so mit dash funktionierts. hab die erste Zeile auch in bin/dash umbenannt, so kommen weniger Zweifel auf…
Etwas blöd dass es mit bash nicht funktioniert (bzw hätte ich gerne früher gewusst)…
ich kann shell-skripte lesen und habe sehr wohl die beiden zu unterscheiden gewusst
Deine neue Version braucht leider bei mir schon 14 minuten fuer das Einlesen der IDs
bei den 305 Dateien bei den 17 GB.
Da ist die alte schon halb fertig
Ist jetzt nicht mehr so. Das Einlesen der IDs dauert nichtmal mehr 'ne Sekunde bei 160 Dateien. War so wohl nicht optimal und liest jetzt für den Zweck nur noch die dritte Zeile und bricht mit der vierten ab.
Genau kann ich Dir das nicht sagen, ich verwende die Höhenlinien so wie sie aus gdal_contour rausfallen und hab in einer mir bekannten Gegend mal überprüft, ob sie zu den Wegen passen, sprich ob die Straße im Tal auch wirklich im Tal verläuft.
Bei meiner Eigenimplementierung für Garminkarten ist mir allerdings aufgefallen, daß man Abweichungen bekommt, je nachdem wie die Software das Raster der Höhendaten interpretiert. Also ob die Höhendaten an der oberen, linken, rechten, unteren Kante oder in der Mitte eines Rasterrechtecks angenommen werden. Bei einer Rastergröße von 90m für SRTM ließe sich die von Dir beobachtete Abweichung damit erklären, daß ein Tool die Rasterecken verwendet und ein Tool die Kästchenmitte.
Zum Perl-Skript (mit ungeplantem Betatest):
An den 8-stelligen IDs liegt es nicht - vielmehr werden String und keine Ganzzahlen sortiert.
Ich werde dies, zusammen mit dem Defekt der leeren Dateien, in Kürze mal korrigieren.
Wahrscheinlich sind die Daten für den Hill-Layer mit Srtm2Osm erzeugt worden ohne x/y Korrektur. Srtm2Osm hat einen 50m Versatz. Irgendwo hier im Forum gab es mal in einem Thread ein paar Koordinaten, wo man die Abweichung sehr schön sehen konnte. Die phyghtmap Daten sind eigentlich ziemlich genau. Es gibt Leute, die behaupten die viewfinderpath Daten hätten 12m Versatz, aber ich habe noch kein Beispiel gesehen.
Leider nein… bin mir nicht sicher ob dash richtig funktioniert. Ja osmconvert zeigt keine Fehler mehr an. Splitter läuft auch ohne Probleme durch. Aber mkgmap verweigert mal wieder den Dienst (egal ob ich jetzt die gesplitteten Daten oder die von osmconvert rausgegebenen Daten, oder die Daten die nur durch das Skript gelaufen sind nehme):
openSUSE-121-64-minimal:/home/contourlines # java -ea -jar -Xmx6000M mkgmap.jar --max-jobs=1 --reduce-point-density=5.4 --transparent --overview-mapname=mapset00 --keep-going --gmapsupp kaputt.osm.pbf
Error at line 1, col 1
Bad file format: kaputt.osm.pbf
Error parsing file
Exception in thread “main” java.lang.NullPointerException
at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:139)
at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:413)
at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126)
at uk.me.parabola.mkgmap.main.Main.main(Main.java:112)
BTW wenn ich die Alpendaten von 1.23 mit kukuk’s patches für osmconvert nach dem dash merge_osm.sh verwende, dann läuft osmconvert nicht korrekt durch, sondern gibt folgende Fehlermeldung:
./osmconvert topo.osm -o=alps_user.osm.pbf
osmconvert Error: way 140118426 has too many refs.
osmconvert Error: way 140297241 has too many refs.
osmconvert Error: way 140519102 has too many refs.
