Hmm, irgendwie check ich die Vorgehensweise noch nicht ganz. Zuerst hab ich mit phyghtmap die Alpen berechnet. Allerdings hab ich jetzt halt zu viele Tiles - daher möchte ich diese mergen. Mit osmosis ist das leider ein Krampf - bzw bekomme ich derzeit weder unter windows 7 noch unter opensuse osmosis zum laufen - also habe ich osmconvert versucht zu benutzen - jetzt hab ich aber obwohl ich max-nodes=250 bei phyghtmap benutzt hab -folgendes Problem:
openSUSE-114-64-minimal:/contourlines # ./osmconvert *.osm.gz --max-refs=2000000 --out-statistics -o=alps.osm .pbf --out-pbf -t=alps.osm.pbf.tmp
osmconvert Warning: wrong order at way 10000004 in file alps_lon5.56_6.00lat45.25_46.00_view1.osm.gz
osmconvert Warning: next object is node 10000005
osmconvert Warning: wrong order at way 10000009 in file alps_lon5.56_6.00lat45.25_46.00_view1.osm.gz
osmconvert Warning: next object is node 10000010
osmconvert Warning: wrong order at way 10000014 in file alps_lon5.56_6.00lat45.25_46.00_view1.osm.gz
osmconvert Warning: next object is node 10000015
osmconvert Warning: wrong sequence at way 217375200
osmconvert Warning: next object is node 217375201
osmconvert Warning: wrong sequence at way 217375213
osmconvert Warning: next object is node 217375214
osmconvert Warning: wrong sequence at way 217375224
osmconvert Warning: next object is node 217375225
lon min: 5.5754630
lon max: 16.6883333
lat min: 45.2852778
lat max: 48.6591667
nodes: 272668
ways: 1340850
relations: 0
node id min: 10000000
node id max: 217637655
way id min: 10000004
way id max: 217637656
keyval pairs max: 3
noderefs max: 250
Und anstelle des korrekten Outputs bekomme ich gar keinen output… – Außerdem scheint osmconvert nicht mit 11GB Memory zufrienden zu sein. Weil es lädt einfach den RAM voll (gut 1GB braucht OS)…
Auch folgender Aufruf ist nicht besser:
./osmconvert *.osm.gz --out-statistics -alps.osm
osmconvert Warning: wrong order at way 10000004 in file alps_lon5.56_6.00lat45.25_46.00_view1.osm.gz
osmconvert Warning: next object is node 10000005
osmconvert Warning: wrong order at way 10000009 in file alps_lon5.56_6.00lat45.25_46.00_view1.osm.gz
osmconvert Warning: next object is node 10000010
osmconvert Warning: wrong order at way 10000014 in file alps_lon5.56_6.00lat45.25_46.00_view1.osm.gz
osmconvert Warning: next object is node 10000015
osmconvert Warning: wrong sequence at way 217375200
osmconvert Warning: next object is node 217375201
osmconvert Warning: wrong sequence at way 217375213
osmconvert Warning: next object is node 217375214
osmconvert Warning: wrong sequence at way 217375224
osmconvert Warning: next object is node 217375225
lon min: 5.5754630
lon max: 16.6883333
lat min: 45.2852778
lat max: 48.6591667
nodes: 272668
ways: 1340850
relations: 0
node id min: 10000000
node id max: 217637655
way id min: 10000004
way id max: 217637656
keyval pairs max: 3
noderefs max: 250
und ich hab eine 0bit große alps.osm Datei als Resultat. Einzelne Kacheln zusammenfügen funktioniert aber…
Unter Windows dagegen kommt immer wenn eine Wildcard im Namen der Files ist folgendes:
osmconvert Error: could not get 183500800 bytes of memory.
na mit osmosis und --sort. marqqs hatte in irggendeinem post mal erwähnt, das osmconvert unter umständen probleme mit unsortierten daten hat. danach müssten dann alle warnings verschwunden sein, und eine mögliche fehlerquelle ist eliminiert.
dann reden wir unter umständen grad aneinander vorbei. ich hab dich so verstanden:
phyghtmap liefert eine menge kacheln
osmconvert soll die kacheln in eine große fläche mergen (die du dann vermutlich zuschneiden willst)
problem: osmosis-merge geht nicht und osmconvert-merge auch nicht.
meine vermutung: es könnte am ungeordneten input liegen. ich hatt mit osmosis immer das problem, dass ein paar funktionen einwandfrei liefen (u.a. --sort), während andere einfach nicht zum laufen zu kriegen waren. deswegen die idee, erst mit osmosis zu sortieren und dann mit osmconvert zu mergen.
Das mergen sollte angeblich auch per Skript gehen - aber dass wirll bei mir auch nicht - die Dateien liegen aber als *.osm vor (hab sie aus versehen alle entpackt).:
Edit – das Sortieren und in eine Datei packen per Skript funktioniert doch - hab nur blöderweise lange versucht ein Script auszuführen welches dos line endings hatte… mal schaun ob ich nachdem durchlaufen vom Script weiterkomme…
Wenn ich die Beschreibung von Osmconvert richtig interpretiere kommt bei --out-statistics nur die Statistik und sonst nichts.
Auf den Punkt bin ich auch zuerst herein gefallen.
Weiter scheint *.osm.gz laut der Wiki Seite nicht in der Liste der unterstützten Formate.
Allerdings sollte das wie im Beispiel mit bzcat auch per Pipe gehen:
You also can use compressed input files if you supply the data via standard input. Examples:
bzcat europe.osm.bz2 | ./osmconvert - -o=europe.o5m
./osmconvert norway.pbf | gzip -1 >norway.osm.gz
The option "-" informs the program to expect input data via standard input.
Zu deinem Windows-Problem kann ich mangels desselben nichts sagen.
Wie genau lautet der Dateiname einer Datei? Hast du vielleicht ein Suffix bei der Erstellung mit Phyghtmap angegeben? Dann müsste noch ein Platzhalter vor den variablen Dateinamen: lonlat.osm → lonlat.osm
Wenn ich mir deine zweite Komandozeile von Post #101 ansehe,
./osmconvert *.osm.gz --out-statistics -alps.osm
fällt mir auf, dass man die Ausgabe Datei eigentlich nur auf zwei Arten festlegen kann:
Mit Umleitung der Standardausgabe (Zeichen ‘>’)
Mit Angabe der Option -o=
(*.gz und --out-statistics hattest du ja bereits behoben)
Probiere also mal -o=alps.osm
Auch darüber bin ich bei meinen eigenen Versuchen gestolpert.
Das sollte vielleicht in der Dokumentation deutlicher z.B. durch einen eigenen Abschnitt hervorgehoben werden. Zur Zeit steht das nebenbei in der Liste der Ausgabe-Formate.
@Marqqs:
osmconvert und osmfilter ließen sich problemlos auf einem Mac übersetzen.
Lediglich der Parameter -march=native musste durch -march=apple (evtl. auch großgeschrieben) ersetzt werden.
Bei dem Shell-Skript bin ich auch in ein Problem gelaufen:
Manchmal paßt beim Merge die Dateireihenfolge nicht.
Die IDs sind dann in der Ergebnisdatei nicht mehr sortiert.
Dies ist bei mir z.B. dann aufgetreten wenn Kacheln geteilt wurden.
Ich habe mir für den Merge-Vorgang ein Perl-Utility geschrieben.
Wer Interesse an dem Programm kann sich per PM bei mir melden.
Eine Veröffentlichung des Utilities ist für später noch geplant.
Klaus
@extremcarver: Mit welcher Äquidistanz hast du die Höhenlinien der Alpen erzeugt?
Allerdings phyghtmap gepatched um von vornherein etwas weniger Tiles zu produzieren (1 pro Input – einfach nach 100.000 suchen im Sourcecode und 3 Nullen anhängen).
Dann mergen und sort per Skript
Anschließend mit osmconvert das osm file in ein osm.pbf umformatieren. Osmosis produziert allerdings auch mit obigem Skript sortierten File nur Fehlermeldungen…
Muss sagen - ist schon ziemlich umständlich das ganze ohne srtm2osm.
Außerdem spuckt osmconvert einige Fehlermedungen von wegen wrong sequence aus - scheint derzeit aber zu funktionieren und braucht viel weniger Speicher wie bei Benutzung von vielen Einzelfiles. Muss noch überprüfen ob der pbf output auch verwendbar ist.
20m…
(benutze ich für europaweit, außer Benelux).
BTW osmconvert für osm nach pbf ist extrem langsam. Etwa 1/4 der Geschwindigkeit die phyghtmap braucht - für Alpen wird mein Rechner also etwa 4 Stunden brauchen zum konvertierne - vs 1 Stunde die phyghtmap braucht. An einem Perl-Skript was zuverlässiger ist wäre ich auch interessiert - wobei schlauer wäre wohl phyghtmap entsprechend zu patchen, so dass dieser Schritt entfällt (dann bräuchte man nicht mal den mgkmap-splitter, da man die max-nodes ja im Sourcecode vorm kompilieren entsprechend anpassen kann), am besten wäre ja pbf support für phyghtmap.
ups zu früh gefreut… osm.pbf ist grad mal 420MB groß, da wird wohl ein Fehler vorliegen (Originaldatei 17GB). Mal schauen - lasse gerade mal splitter/und mkgmap drüberlaufen.
Das ist jetzt mal der Output von osmconvert:
openSUSE-114-64-minimal:/home/contourlines # ./osmconvert alps3.osm -o=alps3.osm.pbf
osmconvert Warning: wrong sequence at node 61343367
osmconvert Warning: next object is node 42707657
osmconvert Warning: wrong sequence at way 61343368
osmconvert Warning: next object is way 42707669
Allerdings unterschlägt osmconvert diese Warnings soweit ich sehen konnte sehr gerne nachdes es ein paar gemeldet hat…
Jip, und osmconvert hat auch irgendeinen Schrott gebaut. Die Daten lassen sich zwar splitten - aber mkgmap akzeptiert sie nicht:
Error parsing file
Error at line 1, col 1
Bad file format: 75280000.osm.pbf
usw…
Das ganze passiert auch schon mit dem ungesplitteten osmconvert Output:
Error parsing file
Error at line 1, col 1
Bad file format: alps3.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)
Das Problem scheint nicht osmconvert zu sein, sondern der Konvertierskript. Weil auch die 17GB osm Datei die daraus entstanden ist - funktioniert nicht mehr mit mkgmap.
Kannst du dein perl Skript mal irgendwo hochladen?
(die Grunddaten sind okay, weil die kann ich ungesplittet mkgmap vorlegen ohne Probleme)