letzer versuch mit “/bin/sh merge_osm_user.sh”
aber auch hier wird /n nicht als neue Zeile betrachtet…
Und wieder nur die erste Kachel als topo.osm ausgegeben…
(btw der sh merge Command führte zu komplett leerer topo.osm).
Probier doch mal ‘\n’ statt “/n”.
Das ist die in Unix/Linux übliche Notation für ‘Neue Zeile’.
Nur geraten.
Edbert (EvanE)
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
So, dann hat es vor ein paar Tagen bei Dir nicht funktioniert, richtig?
Gut, dann haben wir alle Fehler geklaert:
Perl-skript Fehler mit 8 Stellen, (ba)sh-script mit newline.
Ende gut, alles gut 
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.
bye
Nop
… ist ja richtig spannend dieser Thread …
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.
Defekt (2x):
foreach my $ghtdata_id ( sort keys %processing_hashmap ) {
Korrekt (2x):
foreach my $ghtdata_id ( sort {$a <=> $b} keys %processing_hashmap ) {
Klaus
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.
Thorsten
Könnte das hier (hikebikemap):
im Vergleich zu (Wanderreitkarte):
an den Kachelgrenzen 50°Nord /10° Ost damit im Zusammenhang stehen?
Gruß,
ajoessen
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)
(splitter mit java -Xmx6000m -jar splitter.jar --max-threads=4 --max-nodes=10000000 --mapid=75280000 --mixed --overlap=20000 alps*.osm.pbf ; osmconvert topo.osm -o=kaputt.osm.pbf)
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.
Zumindest bei srtm2osm Alpen Ausgangsdaten hab ich weiter
Error at line 1, col 1
Bad file format: 85280001.osm.pbf
als Problem. Ist direkt gesplittet ohne osmconvert/osmosis.
Hallo,
also die Fehlermeldung:
kommt daher, das phyghtmap mit den letzten Änderungen nur noch mit matplotlib < 1.0.0 funktioniert. Debian benutzt noch immer 0.98 in stable, daher funktionert es dort, während openSUSE schon lange 1.0.1 bzw. 1.1.0 verwendet.
https://build.opensuse.org/package/files?package=phyghtmap&project=home%3Akukuk enthält einen Patch “matplotlib-1.0.0.diff”, damit funktioniert es bei mir wieder. Aber ich habe die Ausgabe noch nicht vergleichen können.
Kann jemand mir eine einzelne Kachel mit phyghtmap 1.24 oder 1.25 und matplotlib < 1.0.0 zukommen lassen, sowie die verwendete Kommandozeile? Und bitte von einem ungepatchten phyghtmap. Dann kann ich das mal bei mir Vergleichen.
Besten Dank,
Thorsten
Das gleiche habe ich, wenn ich die SRTM Daten mit osmosis 0.40.1 ausschneide. Wenn ich osmosis 0.39 verwende, funktioniert es. Gab es da Änderungen in osmpbf? Jedes Javatool kommt ja leider mit seiner eigenen Kopie 
Thorsten
Und was passiert wenn du sie gar nicht schneidest? Weil bei mir gehts ja auch nicht wenn ich einfach die 17GB Rohdaten als Einzeldatei versuche per splitter>mkgmap zu benutzen. Osmosis läuft sowieso nicht bei mir (bekomme nur Version 0.29 noch zum laufen).
Evtl liegts bei mir ja auch daran, dass ich NICHT osmosis 0.39 benutze. Weil mkgmap splitter gibt die Daten ja auch als pbf aus, und schreibt evtl denselben Fehler wie neue Osmosis Versionen…
Nett wäre übrigens ein vollständig gepatchtes phyghtmap – die patches bekomme ich zumindest nicht automatisch gemerged, und händisch ist nicht wirklich ein Spaß…
Werde mal versuchen matplotlib 0.98 unter opensuse zu installieren.
Meine Patches werde ich mergen sobald ich das points=0 Problem final gelöst habe. Solange würde ich mit der phyghtmap 1.23 + patches weiterarbeiten, ich sehe in 1.24 und neuer noch keinen Vorteil.
Thorsten
Hallo,
ok, alle Patches sind auf phyghtmap 1.25 portiert. Ich habe auch den matplotlib 1.0.0 Patch getestet, die Ausgabe ist identisch zu phyghtmap 1.23:
https://build.opensuse.org/package/files?package=phyghtmap&project=home%3Akukuk
Ich habe meine --max-nodes Option nach --max-way-nodes umbenannt, also bitte Scripte anpassen 
Thorsten
Sehr schön!
Selbst mit den 88 Byte großen, “leeren” Dateien wie lon-17.00_-16.00lat27.00_28.00_srtm3.osm bei den Kanaren klappt das.
Nur die “Bounding Box”-Zeile befinde ich als etwas befremdlich.
Wie auch unter
http://wiki.openstreetmap.org/wiki/OSM_XML
zu lesen bin ich von osmconvert
gewohnt.
Dein
mmmh, strange
Hi,
da muss noch ein Fehler sein, der bei mir nicht auftritt.
Die Bounding Box bilde ich so ab, wie sie von Osmosis (dort aber meist mehr Nachkommastellen mit 0 aufgefüllt) erzeugt wird, z.B:
Beim “Extrahieren” der Koordinaten aus den Dateinamen läuft wohl was falsch. Wie lautet denn die (fast letzte) Bildschirmausgabe in Zeile “Bereich: …”?