Extrakte mit OSMConvert zusammenbauen

Bernhard Hiller wrote:

Ich benötige den Bereich von 49-51°N und 10-14°O für eine Karte. Dazua lade ich von Geofabrik die Extrakte für Bayern, Sachsen, Thüringen und Tschechien herunter.
Mit Osmosis kann ich jeweils 2 Dateien kombinieren, das Zusammenbauen geht also in drei langsamen Schritten, dann einer zum Ausschneiden.

geht auch einfach in einem Rutsch.

#!/bin/bash

#␣OSMembrane␣auto-generated␣pipeline␣for␣osmosis
#␣Name:
#␣Date:␣Fri␣Feb␣22␣19:32:01␣CET␣2013
#␣Comment:
#

osmosis␣\
--read-pbf␣file=a.pbf␣outPipe.0=1␣\
--read-pbf␣file=b.pbf␣outPipe.0=2␣\
--read-pbf␣file=c.pbf␣outPipe.0=3␣\
--read-pbf␣file=d.pbf␣outPipe.0=4␣\
--merge␣inPipe.0=1␣inPipe.1=2␣outPipe.0=5␣\
--merge␣inPipe.0=3␣inPipe.1=4␣outPipe.0=6␣\
--merge␣inPipe.0=5␣inPipe.1=6␣outPipe.0=7␣\
--bounding-polygon␣file=my.poly␣completeWays=true␣completeRelations=true␣inPipe.0=7␣outPipe.0=8␣\
--write-xml␣inPipe.0=8␣file=out.osm

Bernhard Hiller wrote:

"osmconvert␣Error:␣more␣than␣one␣.pbf␣input␣file␣is␣not␣allowed."

Geht das tatsächlich nicht? Jede pbf-Datei nach o5m zu konvertieren und dann zusammenzubauen, dauert gewiss auch recht lange...

Jo, osmconvert kann das - blöderweise - nicht. Da hat sich der Programmierer wohl nicht rangetraut.

Gruss
walter

p.s. osmosis mag zwar langsam sein aber mit den richtigen Tools bekommt man ganz einfach tolle Pipelines hin. Hier: OSMembrane

Nachtrag:
das müsste schneller sein:

osmosis␣\
--read-pbf␣file=a.pbf␣outPipe.0=1␣\
--read-pbf␣file=b.pbf␣outPipe.0=2␣\
--read-pbf␣file=c.pbf␣outPipe.0=3␣\
--read-pbf␣file=d.pbf␣outPipe.0=4␣\
--bounding-polygon␣file=my.poly␣completeWays=true␣completeRelations=true␣inPipe.0=1␣outPipe.0=5␣\
--bounding-polygon␣file=my.poly␣completeWays=true␣completeRelations=true␣inPipe.0=2␣outPipe.0=6␣\
--bounding-polygon␣file=my.poly␣completeWays=true␣completeRelations=true␣inPipe.0=3␣outPipe.0=7␣\
--bounding-polygon␣file=my.poly␣completeWays=true␣completeRelations=true␣inPipe.0=4␣outPipe.0=8␣\
--merge␣inPipe.0=5␣inPipe.1=6␣outPipe.0=9␣\
--merge␣inPipe.0=7␣inPipe.1=8␣outPipe.0=10␣\
--merge␣inPipe.0=9␣inPipe.1=10␣outPipe.0=11␣\
--write-xml␣inPipe.0=11␣file=out.xml

Danke an den Meister der Kommandozeile! Ich werd's mal ausprobieren.

Wenn es in osmosis zu lange dauert sollte man bedenken das osmnconvert für solche Aufgaben 10-20 mal schneller ist.
osmconvert kann man auch parallel laufen lassen (=alle 4 pbf gleichzeitig in o5m konvertieren) und diese dann zusammen pappen.

Bei diesen doch relativ kleinen pbf.-Dateien ist die Zeit aber wohl nicht das kritische!

z.B beim Ausschneiden aus der europa.osm.pbf ist allerdings Zeitlich welten zwischen osmosis (ca. 30min) und osmconvert (2:30min)!

quasilotte wrote:

osmconvert kann man auch parallel laufen lassen (=alle 4 pbf gleichzeitig in o5m konvertieren) und diese dann zusammen pappen.

macht osmosis automatisch. in diesem Fall 4 thread fürs clippen und + 3 threads fürs mergen, die schön brav aufeinander warten.

wambacher wrote:

geht auch einfach in einem Rutsch.

Richtig, Osmosis (mit oder ohne OSMembrane) ist flexibler, wenn es darum geht, komplexe Pipes aufzubauen. Überhaupt ist der Funktionsumfang größer als bei osmconvert. Andersrum hat auch osmconvert ein paar Funktionen, die bei Osmosis fehlen. In 95 % aller Fälle wird man die Aufgaben mit jedem dieser beiden Werkzeuge erledigen können. Es ist also meistens Geschmacksache und kein "das eine ist immer besser als das andere". :-)

wambacher wrote:

Jo, osmconvert kann das - blöderweise - nicht. Da hat sich der Programmierer wohl nicht rangetraut.

So ähnlich. Ich hatte keine Angst davor, aber das verantwortliche (und recht unübersichtliche) Stück Code ist auf ganz andere Weise entstanden: Um das PBF-Format wirklich zu erlernen, wollte ich PBF-Daten nicht einfach nur mit einer fertigen Bibliothek einlesen, sondern jedes Byte mit einem selbst geschriebenen Programm konvertieren (mit Ausnahme von gzip). Das ist mir schließlich gelungen, und das Ergebnis war das Programm "pbftoosm". Es war, was den Quellcode betrifft, wahrlich kein schönes Programm, aber sehr wahrscheinlich das schnellste PBF-Leseprogramm, das es bis dahin gab. Das daraufhin zu osmconvert übertragene PBF-Lesemodul war und ist nicht in der Lage, mehr als eine PBF-Datei zur gleichen Zeit zu verarbeiten.

Ein Ergebnis dieses PBF-"Workshops" war übrigens das Format o5m. Ich wollte ein Format haben, das seine Daten möglichst gut komprimiert, aber schneller zu verarbeiten ist als PBF.

So, genug gebabbelt, zurück zum Thema. :-)

Wenn man zum Mergen nicht Osmosis, sondern osmconvert einsetzen will, empfiehlt es sich, die regionalen Dateien gleich als .o5m herunterzuladen. Da es dafür leider noch keine Quelle gibt, wandelt man einfach beim Runterladen um. Das hat zudem den Vorteil, dass sich die Daten dann später schneller verarbeiten lassen. Beispiel:

wget␣download.geofabrik.de/openstreetmap/europe/germany/bayern.osm.pbf␣-O␣-␣|␣osmconvert␣-␣-o=bayern.o5m

(Das Linux-Download-Tool wget gibt es auf für Windows, keine Sorge.) Bei dieser Art des Umwandelns kann man auch gleich nicht benötigte Informationen rauswerfen, das spart später Zeit und Speicherplatz (siehe z.B. Option --drop-author).

Hat man nur zwei PBF-Dateien, die man mergen will, geht es auch mit osmconvert per linearer Pipe:

osmconvert␣bayern.osm.pbf␣--out-o5m␣|␣osmconvert␣-␣thueringen.osm.pbf␣-o=zwei_laender.pbf

Will man mehr als zwei Länder GLEICHZEITIG mergen, die NUR als PBF vorliegen, dann muss man entweder vorher in .o5m umwandeln oder (so ähnlich wie auch in Osmosis) komplexe Pipes verwenden. Diese Pipes sind allerdings bei osmconvert nicht "eingebaut", sondern über das Betriebssystem verfügbar. Bei Linux geht das recht einfach mit "mkfifo", Beispiele liefere ich gern. Wie und ob es unter Windows geht, weiß ich leider nicht... Tipps willkommen! :-)

Alternativ kann man auch schrittweise arbeiten:

osmconvert␣land1.pbf␣-o=a.o5m
osmconvert␣land2.pbf␣a.o5m␣-o=b.o5m
osmconvert␣land3.pbf␣b.o5m␣-o=a.o5m
osmconvert␣land4.pbf␣a.o5m␣-o=alles.pbf

Oder man baut eine ganz lange lineare Pipe:

osmconvert␣land1.pbf␣--out-o5m␣|␣osmconvert␣-␣land2.pbf␣--out-o5m␣|␣osmconvert␣-␣land3.pbf␣--out-o5m␣|␣osmconvert␣-␣land4.pbf␣-o=alles.pbf

Grüße
Markus

Marqqs wrote:

Bei Linux geht das recht einfach mit "mkfifo", Beispiele liefere ich gern.

Ja! Wissen wollen 😉

Marqqs wrote:

osmconvert␣land1.pbf␣--out-o5m␣|␣osmconvert␣-␣land2.pbf␣--out-o5m␣|␣osmconvert␣-␣land3.pbf␣--out-o5m␣|␣osmconvert␣-␣land4.pbf␣-o=alles.pbf

Mmh, was macht aber bei 8 CPUs? (und 8 GPUs 😉
Oder:
Was ist schneller? Ein lineares osmconvert oder 7 wambacher-threads?

kellerma wrote:

Mmh, was macht aber bei 8 CPUs? (und 8 GPUs 😉
Oder:
Was ist schneller? Ein lineares osmconvert oder 7 wambacher-threads?

Kann ich in einigen Wochen beantworten (*), wenn ich mich endlich zwischen Intel i7-3770 & Amd fx-8350 entschieden habe - ein 4x2 oder 8-Core wird es auf jeden Fall. Alle einschlägigen Benchmarks kümmern sich um Gamer aber ich suche nen starken Lunix-Rechenknecht zum Rendern und für Postgresql.

Vielen Dank an Markus für sein Statement. Beide Programme haben ihre Stärken und Schwächen und es steht ja jedem frei, "seine" Favoriten zu benutzen. Ich mache das jeweils passend zur aktuellen Aufgabenstellung.

Gruss
walter

• ) ich tippe mal auf osmconvert, da ein Spezialist wohl performanter ist als eine "Eier legende Woll-Milch-Sau"
  

Zwei Nachfragen habe ich noch:
- wie schaut das Format der "my.poly"-Datei aus, die osmosis eingefüttert werden soll? Die "area.poly", welche splitter liefert, wird als unbekanntes Format abgelehnt.
- wie bringe ich osmosis bei, die Kerne meines Rechners ordentlich zu nutzen? Der betreffende Java-Prozess belegt rund 30% CPU, also nur knapp mehr als einen der 4 Kerne.
Die ursprüngliche Abfrage (mit bounding-box statt bounding-polygon) benötigte auf meinem Rechner 16 Minuten. Die optimierte habe ich noch nicht ausprobiert.

Walter, genau das meine ich. Sogar für die Aufgaben, die beide Programme beherrschen, ist es gut, wenn es mehrere Programme gibt. Denn was macht man, wenn man am Ergebnis zweifelt und einen Programmfehler vermutet? Man nimmt ein anderes Programm und schaut, ob das Ergebnis das Gleiche ist.
Osmosis und osmconvert sind von der Programmierung her grundverschieden, so dass es äußerst unwahrscheinlich ist, dass ein Fehler auf die gleiche Art in beiden Programmen auftritt.

kellerma wrote:

Marqqs wrote:

Bei Linux geht das recht einfach mit "mkfifo", Beispiele liefere ich gern.

Ja! Wissen wollen 😉

OK, ein Ausflug in die "Röhren". Normalerweise hast du nur eine Pipe und kannst sie nutzen, um die Ausgabe von einem Programm als Eingabe für ein anderes Programm zu verwenden. Das geht mit dem Pipe-Operator "|".

Zusätzliche Pipes kannst du dir bauen, indem du Puffer anlegst, so genannte FIFOs. Den Fifos kannst du Namen geben, sie erscheinen dann im Verzeichnis ähnlich wie eine normale Datei. Ich hänge an den Namen ".o5m" an, damit osmconvert später weiß, dass es in die Fifos die Daten im Format o5m schreiben soll. Beispiel:

mkfifo␣fifo1.o5m␣fifo2.o5m␣fifo3.o5m

osmconvert␣land1.pbf␣-o=fifo1.o5m␣&␣osmconvert␣land2.pbf␣-o=fifo2.o5m␣&␣osmconvert␣land3.pbf␣-o=fifo3.o5m␣&␣osmconvert␣fifo1.o5m␣fifo2.o5m␣fifo3.o5m␣-o=alles.pbf

Das "&" nach einem Linux-Befehl bewirkt, dass dieser in einem eigenen Prozess im Hintergrund abläuft. Nur nach dem letzten Kommando ist kein "&", das heißt, es läuft im Vordergrund. Alles in allem laufen dann 4 Prozesse parallel. Das nutzt die CPU sicher schön aus, ist aber nicht ganz so geschickt wie bei Osmosis, weil die einzelnen Prozesse ihre Daten nicht im Binärformat sondern im o5m-Format austauschen. Sollte aber trotzdem recht schnell sein, möglicherweise sogar schneller. Aber Geschwindigkeit ist wirklich nicht alles. :-)

Hier findest du einen sehr guten Artikel über das Thema: http://www.freiesmagazin.de/freiesMagazin-2011-03
(Kapitel "Datenströme...")

Bernhard Hiller wrote:

Zwei Nachfragen habe ich noch:
- wie schaut das Format der "my.poly"-Datei aus, die osmosis eingefüttert werden soll? Die "area.poly", welche splitter liefert, wird als unbekanntes Format abgelehnt.

Huch, da hatte ich gedacht, du würdest schon längst ein Polygon für deine Wunschecke verwenden.
hier ist das Format beschrieben: http://wiki.openstreetmap.org/wiki/Osmo … ile_Format und so sieht mein Poly-File aus:

my
1
11.962802␣␣␣50.669635
11.678070␣␣␣50.544960
11.704181␣␣␣50.396182
11.768836␣␣␣50.227054
11.972749␣␣␣50.121142
12.227640␣␣␣50.090041
12.412902␣␣␣50.132302
12.593191␣␣␣50.287469
12.598165␣␣␣50.406485
12.531022␣␣␣50.513344
12.350734␣␣␣50.592344
12.114493␣␣␣50.639680
11.962802␣␣␣50.669635
END
END

Das ist aber nur ein willkürlich mit Josm erstelltes Polygon und stellt in etwa eine Fläche um das Dreiländer-Dreieck dar. Kann man in Josm mit dem Poly-Plugin ganz einfach erstellen: Leere Ebene, Polygon malen, als Polygon abspeichern, fertig:

Und für Profis: Wunschgrenze (Relation) laden, in einen Way konvertieren (c für Linien verbinden), als Poly abspeichern, fertig.
Format siehe http://wiki.openstreetmap.org/wiki/Osmo … ring_Tasks

Bernhard Hiller wrote:

- wie bringe ich osmosis bei, die Kerne meines Rechners ordentlich zu nutzen? Der betreffende Java-Prozess belegt rund 30% CPU, also nur knapp mehr als einen der 4 Kerne.
Die ursprüngliche Abfrage (mit bounding-box statt bounding-polygon) benötigte auf meinem Rechner 16 Minuten. Die optimierte habe ich noch nicht ausprobiert.

Ich vermute mal einen IO-Bound (*) kann es aber noch nicht mit 4 oder 8 Cores testen, da ich nur einen klapprigen Athlon 64 2X habe und der ist bei dieser Aktion voll ausgelastet. Hier

kann man den Anstieg der Auslastung bei beiden Cores gut sehen. Was will ich mehr - ausser 'ner besseren Kiste. 😉

Es gibt in Osmosis aber noch einen weiteren Befehl zum Tunen: Osmosis/Tuning und hier der Befehl --buffer Da ist bestimmt noch was zu holen.

Gruss
walter

• ) Nachtrag zum IO-Bound: Wegen der 64-Bit-Problematik verwende ich Osmosis ohne die Clipping-Option idTrackerType. Dann wird als Default idTrackerType=Dynamic genommen und das bedeutet, dass Osmosis beim Clippen temporäre Daten in Temp-Files ablegt obwohl er die Daten spielend im Memory halten könnte. Das verursacht verd.... viel IO. Mal sehen ob der Bug in osmosis 0.42 raus ist.
  

walter@wno-server:~$␣ls␣-lah␣/tmp/af*
-rw-rw-r--␣1␣walter␣walter␣␣51M␣Feb␣23␣22:30␣/tmp/afn5169826647196828359.tmp
-rw-rw-r--␣1␣walter␣walter␣323M␣Feb␣23␣22:36␣/tmp/afn642703322552175748.tmp
-rw-rw-r--␣1␣walter␣walter␣␣84M␣Feb␣23␣22:31␣/tmp/afn8186091037333075132.tmp
-rw-rw-r--␣1␣walter␣walter␣367M␣Feb␣23␣22:33␣/tmp/afn822235863446617160.tmp
-rw-rw-r--␣1␣walter␣walter␣6,3M␣Feb␣23␣22:35␣/tmp/afr2790118068294005220.tmp
-rw-rw-r--␣1␣walter␣walter␣1,8M␣Feb␣23␣22:31␣/tmp/afr4147008938441278370.tmp
-rw-rw-r--␣1␣walter␣walter␣3,4M␣Feb␣23␣22:36␣/tmp/afr7104361024340531822.tmp
-rw-rw-r--␣1␣walter␣walter␣1,2M␣Feb␣23␣22:30␣/tmp/afr8558165384252636479.tmp
-rw-rw-r--␣1␣walter␣walter␣139M␣Feb␣23␣22:36␣/tmp/afw2019786724539200888.tmp
-rw-rw-r--␣1␣walter␣walter␣␣23M␣Feb␣23␣22:30␣/tmp/afw3870572578763475746.tmp
-rw-rw-r--␣1␣walter␣walter␣␣41M␣Feb␣23␣22:31␣/tmp/afw430517774483349815.tmp
-rw-rw-r--␣1␣walter␣walter␣148M␣Feb␣23␣22:35␣/tmp/afw5529171820357334263.tmp
walter@wno-server:~$

Nachtrag2: ist mit --bounding-box fertig und hat 20 Minuten gebraucht. Allerdings die 2. Methode "Erst clippen, dann mergen".

Bernhard Hiller wrote:

Zwei Nachfragen habe ich noch:
- wie schaut das Format der "my.poly"-Datei aus, die osmosis eingefüttert werden soll? Die "area.poly", welche splitter liefert, wird als unbekanntes Format abgelehnt.
- wie bringe ich osmosis bei, die Kerne meines Rechners ordentlich zu nutzen? Der betreffende Java-Prozess belegt rund 30% CPU, also nur knapp mehr als einen der 4 Kerne.
Die ursprüngliche Abfrage (mit bounding-box statt bounding-polygon) benötigte auf meinem Rechner 16 Minuten. Die optimierte habe ich noch nicht ausprobiert.

Warum eigentlich diese Eile? Die Karten, die ich im Netz hab, werden maximal einmal täglich upgedated, da ist es egal, ob das Update in einer halben Stunde durchläuft oder 3 Stunden braucht. Insofern würde ich das Programm (z.B. Osmosis oder osmconvert) nicht unbedingt nach dessen Laufzeit auswählen - es gibt genügend andere, wahrscheinlich wichtigere Kriterien.

Ich hab trotzdem dein Beispiel mal auf meinem Server durchlaufen lassen. Das ist die Maschine, die die openptmap.org rendert (4 Kerne), also mit Walters Rechner nicht zu vergleichen.

$␣./osmconvert␣bayern.osm.pbf␣-o=1.o5m␣&␣./osmconvert␣thueringen.osm.pbf␣-o=2.o5m␣&␣./osmconvert␣sachsen.osm.pbf␣-o=3.o5m␣&␣./osmconvert␣czech_republic.osm.pbf␣-o=4.o5m␣&␣time␣./osmconvert␣1.o5m␣2.o5m␣3.o5m␣4.o5m␣-o=alles.pbf

Braucht ca. 2 Minuten.

Und als Variante mit Walters Poly-Datei:

$␣./osmconvert␣bayern.osm.pbf␣-o=1.o5m␣&␣./osmconvert␣thueringen.osm.pbf␣-o=2.o5m␣&␣./osmconvert␣sachsen.osm.pbf␣-o=3.o5m␣&␣./osmconvert␣czech_republic.osm.pbf␣-o=4.o5m␣&␣time␣./osmconvert␣1.o5m␣2.o5m␣3.o5m␣4.o5m␣-B=my.poly␣-o=alles.pbf

Dauert ungefähr 44 Sekunden.

Marqqs wrote:

Warum eigentlich diese Eile? Die Karten, die ich im Netz hab, werden maximal einmal täglich upgedated, da ist es egal, ob das Update in einer halben Stunde durchläuft oder 3 Stunden braucht. Insofern würde ich das Programm (z.B. Osmosis oder osmconvert) nicht unbedingt nach dessen Laufzeit auswählen - es gibt genügend andere, wahrscheinlich wichtigere Kriterien.

Nö, runtime ist ein extrem wichtiges Auswahlkriterium:
a) Umweltschutz: Waram soll für die _gleiche_ Aufgabe zehnmal soviel Energie verprutzelt werden?
b) Lebenszeit: Wenn Bernhard statt 20 min 2 min vor seinem Compi, ist das besser handlebar für ihn.

named pipes scheint es auch für Windows zu geben, allerdings gibt es wohl in der Defaultkonfig kein "mkfifo", jenes müsste man sich noch per cygwin aut simile nachinstallieren.

Das Thema mit den multi-pipes wäre noch eine schöne wiki-Ergänzung (hint, hint 😉 )

Da habe ich wohl nen Fehler reingebracht, als ich die Parameter in Walters zweitem Vorschlag anpaßte...
Aber für ein Rechteck, bei dem exakt 4 Koordinaten genügen, ist so ne Datei schon arg aufwändig.
Wer hat sich eigentlich dieses Format ausgedacht? Ein Cobol-Programmierer? Oder Mumps-Programmierer? Ist ja ähnlich antediluvial wie BDT/GDT im Gesundheitswesen...

Marqss' Variante mit der poly-Datei habe ich an Windows angepaßt (mal mit paralellem Abarbeiten, mal sequentiell mit START /B CMD /C)

ECHO␣%TIME%
SET␣OSMCONVERT="C:\Program␣Files␣(x86)\OpenStreetMap\OSMConvert\osmconvert.exe"
SET␣INPUTDIR=E:\Maps\Raw\
CALL␣%OSMCONVERT%␣%INPUTDIR%bayern.osm.pbf␣-o=%INPUTDIR%bayern.o5m
CALL␣%OSMCONVERT%␣%INPUTDIR%thueringen.osm.pbf␣-o=%INPUTDIR%thueringen.o5m
CALL␣%OSMCONVERT%␣%INPUTDIR%sachsen.osm.pbf␣-o=%INPUTDIR%sachsen.o5m
CALL␣%OSMCONVERT%␣%INPUTDIR%czech_republic.osm.pbf␣-o=%INPUTDIR%czech_republic.o5m
CALL␣%OSMCONVERT%␣␣%INPUTDIR%bayern.o5m␣%INPUTDIR%thueringen.o5m␣%INPUTDIR%sachsen.o5m␣%INPUTDIR%czech_republic.o5m␣-B=E:\Maps\Development\Ski\areas.poly␣-o=%INPUTDIR%Mittelgebirge.osm.pbf
ECHO␣%TIME%

sie endet stets mit:

osmconvert␣Error:␣could␣not␣get␣183500800␣bytes␣of␣memory

Der letzte Aufruf an OSMConvert nach vorheriger Konvertierung genügt für das Hervorrufen des Fehlers - d.h. Probleme mit Zugriffen auf die konvertierten Dateien sind als Fehlerursache ausgeschlossen.
Lasse ich das Ausschneiden des gewünschten Bereiches weg, tritt kein Fehler auf.
Wenn ich dann mit Osmosis ausschneiden will, kracht Osmosis weg:

SCHWERWIEGEND:␣Thread␣for␣task␣1-read-pbf␣failed
java.lang.OutOfMemoryError:␣Java␣heap␣space

Beide Fehlermeldungen sind eigentlich recht aufschlussreich!
Du hast schlicht einen kleineren Hauptspeicher zur Verfügung als von den Programmen vorausgesetzt oder angenommen wird.
Vielleicht musst du das mergen und zuschneiden doch auch sequentiell abarbeiten. Eventuell ist aber auch dein Polygon zu aufwendig. Interessant wären an dieser stelle auf jeden Fall mal die technischen Daten deines Rechners. 4 GB Ram oder mehr? 32 bit oder 64 bit und wieviel vom den Ram ist eigentlich noch frei und nicht durch andere Programme bereits belegt.

Bernhard Hiller wrote:

Da habe ich wohl nen Fehler reingebracht, als ich die Parameter in Walters zweitem Vorschlag anpaßte...
Aber für ein Rechteck, bei dem exakt 4 Koordinaten genügen, ist so ne Datei schon arg aufwändig.
Wer hat sich eigentlich dieses Format ausgedacht? Ein Cobol-Programmierer? Oder Mumps-Programmierer? Ist ja ähnlich antediluvial wie BDT/GDT im Gesundheitswesen...

Moin Moin,

ne, das ist für Leute gedacht, die einen Thread richtig und vollständig lesen können 😉

#!/bin/bash

#␣OSMembrane␣auto-generated␣pipeline␣for␣osmosis
#␣Name:
#␣Date:␣Fri␣Feb␣22␣19:32:01␣CET␣2013
#␣Comment:
#
...

und

wambacher wrote:

aber mit den richtigen Tools bekommt man ganz einfach tolle Pipelines hin. Hier: OSMembrane

ok, hier einige Links:

- http://wiki.openstreetmap.org/wiki/OSMembrane
- http://code.google.com/p/osmembrane-gui/
- http://forum.openstreetmap.org/viewtopic.php?id=13801

Wenn es das Teil nicht gäbe, hätte ich nie was mit Named Pipes gemacht 😉

Das Teil ist ziemlich alt und wird leider nicht mehr gepflegt. Es hat sogar (mindestens) 2 Bugs, mit denen ich ganz gut klarkomme:

- wenn man einen --tee-change machen will (ja, sowas gibt es), generiert er das Kommando change-tee; das muss man dann halt im Script ändern.
- wenn man Verbindungen zwischen den Boxes löscht und neu erstellen will, gibt es schon mal nen Runtime-Fehler. Da weiss anscheinend irgend ein Pointer nicht mehr, wohin er zeigen soll 😉.
Lösung: Abspeichern und neu Laden, dann gehts weiter.

Gruss
walter

wegen Java: wer osmosis benutzt, hat eh Java installiert. Und wenn das nicht von Oracle ist, gibt es auch keine Security-Leaks.

p.s. Die Bildchen hab ich nicht gemalt - das sind Screenshots. Alles klar?

Bernhard Hiller wrote:

Wenn ich dann mit Osmosis ausschneiden will, kracht Osmosis weg:

SCHWERWIEGEND:␣Thread␣for␣task␣1-read-pbf␣failed
java.lang.OutOfMemoryError:␣Java␣heap␣space

Hatte und hab kein Problem.

Ubuntu, 2GB Memory, keinerlei Java-Optionen bzgl Memory: rennt

Poste doch bitte mal den aktuellen Script.

Gruss
walter

viw wrote:

4 GB Ram oder mehr?

8 GB RAM unter Windows 7 (64bit). Und fast alles davon verfügbar.

Guten Morgen ihr! :-)

wambacher wrote:

- wenn man einen --tee-change machen will (ja, sowas gibt es), generiert er das Kommando change-tee; das muss man dann halt im Script ändern.

Ja, wirklich schade, dass OSMembrane zurzeit nicht gepflegt wird. Ich hoffe, es findet sich wieder jemand, der sich um das Programm kümmert.
Aber zu diesem Bug: Soweit ich weiß, wird Osmosis recht gut gepflegt, dort könnte man bestimmt sehr leicht einbauen, dass "change-tee" als inoffizielles Synonym für "tee-change" akzeptiert wird!

Bernhard Hiller wrote:

osmconvert␣Error:␣could␣not␣get␣183500800␣bytes␣of␣memory

SCHWERWIEGEND:␣Thread␣for␣task␣1-read-pbf␣failed
java.lang.OutOfMemoryError:␣Java␣heap␣space

Klingt beides wirklich so, als hätte dein Windows ein Problem mit der Speicherverwaltung. :-( Der letzte Schritt mit dem Grenzpolygon sollte eigentlich nicht mehr als 1 oder 2 GB RAM brauchen.

kellerma wrote:

Das Thema mit den multi-pipes wäre noch eine schöne wiki-Ergänzung (hint, hint 😉 )

Stimmt, wär sicher hilfreich. Als Linux-Anfänger hatte ich von den tollen Möglichkeiten auch keine Ahnung, bis ich dann mal durch Zufall drauf gestoßen bin. Muss mal schauen, wo man das am besten einbaut...

Marqqs wrote:

Klingt beides wirklich so, als hätte dein Windows ein Problem mit der Speicherverwaltung. :-( Der letzte Schritt mit dem Grenzpolygon sollte eigentlich nicht mehr als 1 oder 2 GB RAM brauchen.

Hi ich werd hier wohl etwas offtopic - aber das Wort Speicherverwaltung hat nee Frage ausgelößt:

Im wiki steht für

--complex-ways und --complete-ways
Bei dieser wie auch bei der nachfolgend beschriebenen Option gilt für 32-Bit-Windows eine Größenbeschränkung für die Eingabedatei: Da die Datei mehrfach gelesen werden muss – es wird in der Datei "gesprungen" – darf ihre Größe 2 GiB nicht überschreiten.Für 64-Bit Windows sowie für 32- und 64-Bit-Linux gilt diese Einschränkung nicht.
Ebenfalls für diese und die nachfolgende Option wird empfohlen, als Eingabeformat .o5m zu verwenden, da .pbf-Dateien in der Regel intern komprimiert sind und deswegen deutlich länger benötigen um (mehrfach) eingelesen zu werden.

Beim Ausführen von:
osmconvert.exe --complex-ways --drop-version --drop-author --emulate-osmosis -b=8.7,49.75,9.75,50.5 G:\OSM\europe.osm.pbf -o=G:\OSM\Test.pbf

bekomme ich allerdings immer noch den Üblichen Fehler das nicht in Dateien gehüpft werden kann die größer wie 2GiB sind.

Stimmt die Aussage im Wiki oder ist beim compilieren was zu beachten oder gilt das nicht für pbf...?

System Win7 64-Bit mit 16GB
Compiliert: C:\mingw64\bin\gcc.exe osmconvert07P.c -lz -O3 -o osmconvert.exe

und auch

C:\mingw64\bin\gcc.exe osmconvert07P.c -m64 -lz -O3 -o osmconvert.exe
kein Unterschied

quasilotte:

Hier muss ich auch passen. Vielleicht ist die zlib nicht auf dem neuesten Stand oder liegt nur in der 32-Bit-Version vor? Mit -v oder -v=2 sollte osmconvert die Versionsnummer der zlib ausgeben - wenn ich mich jetzt recht erinnere.

kellerma wrote:

Das Thema mit den multi-pipes wäre noch eine schöne wiki-Ergänzung (hint, hint 😉 )

Erledigt. :-)

Karlsson_vom_Dach wrote:

Marqqs wrote:

kellerma wrote:

Das Thema mit den multi-pipes wäre noch eine schöne wiki-Ergänzung (hint, hint 😉 )

Erledigt. :-)

Der welt bester Maqqs!

Marqqs wrote:

quasilotte:

Hier muss ich auch passen. Vielleicht ist die zlib nicht auf dem neuesten Stand oder liegt nur in der 32-Bit-Version vor? Mit -v oder -v=2 sollte osmconvert die Versionsnummer der zlib ausgeben - wenn ich mich jetzt recht erinnere.

Danke leider ist es nicht die zlib = Version 1.2.7
auch hab ich den gcc neu aufgespielt Version 4.7.2

Jetzt weis ich auch nicht mehr weiter!!!

Wenn jemand eine osmconvert hat die mit Win 7 auch grosse PBF verarbeiten kann mit --complex-ways und --complete-ways bitte bei mir Melden!

kellerma: Bitte nicht übertreiben. :-)

quasilotte wrote:

Jetzt weis ich auch nicht mehr weiter!!!

Helfen kann ich zwar auch nicht, aber wenn du noch probieren magst, ob es tatsächlich irgendwas mit der zlib zu tun hat, könntest du versuchsweise die Konstante read_GZ ändern und danach neu compilieren:

#define␣read_GZ␣3␣␣//␣determines␣which␣read␣procedure␣set␣will␣be␣used;
//␣==0:␣use␣open();␣␣==1:␣use␣fopen();
//␣==2:␣use␣gzopen()␣(accept␣gzip␣compressed␣input␣files);
//␣==3:␣use␣gzopen()␣with␣increased␣gzip␣buffer;

Normal steht read_GZ auf 3, aber wenn du keine gezippten Dateien liest, kannst du es auch mal mit dem Wert 0 oder 1 versuchen. Wahrscheinlich läuft das Programm dann sogar 1 oder 2 % schneller.

Marqqs wrote:

#define␣read_GZ␣3␣␣//␣determines␣which␣read␣procedure␣set␣will␣be␣used;
//␣==0:␣use␣open();␣␣==1:␣use␣fopen();
//␣==2:␣use␣gzopen()␣(accept␣gzip␣compressed␣input␣files);
//␣==3:␣use␣gzopen()␣with␣increased␣gzip␣buffer;

Normal steht read_GZ auf 3, aber wenn du keine gezippten Dateien liest, kannst du es auch mal mit dem Wert 0 oder 1 versuchen. Wahrscheinlich läuft das Programm dann sogar 1 oder 2 % schneller.

Mit

read_GZ 0

funkioniert der Zugriff mit --complex-ways auf die europe.osm.pbf
alle anderen Werte (1,2,und 3) ergeben sich Fehlermeldungen.
Leider ergibt sich da kein Zeilicher Vorteil (Wie erhoft!)

Auschneiden dauert dabei ca. 5:10min
Wie bisher mit Vorauschnitt (=+ 2 Grad drumrum [Ergibt o5m-Dateien die noch gut unter 2GiB sind!]) dauert 2:30 + 30 sek das Ausschneiden aus dem Ausschnitt mit --complex-ways
Bin also mit Vorausschnitt deutlich schneller.

Allerdings ist der Auschnitt verschieden groß - was ich Hauptsächlich auf Ways und Nodes zurückzuführen ist die Über Realtionen noch in den Randbreich des Ausschnitts gehören.
Habe allerdings noch keine Auswirkungen auf den Kernbereich festgestellt!

Noch der Statistik halber:
mit complex-ways direkt: 10763263 nodes, 1688143 ways and 22252 relations
mit Vorausschnitt dann compex-ways: 10736353 nodes, 1687917 ways and 22252 relations