Extrakte mit OSMConvert zusammenbauen

[Bernhard_Hiller]

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.
Angeblich kann OSMConvert beliebig viele Dateien kombinieren. Hab mir das aktuelle OSMConvert (Version 0.7P) geholt und ausprobiert:

"C:\Program Files (x86)\OpenStreetMap\OSMConvert\osmconvert.exe" E:\Maps\Raw\bayern.osm.pbf E:\Maps\Raw\thueringen.osm.pbf E:\Maps\Raw\sachsen.osm.pbf E:\Maps\Raw\czech_republic.osm.pbf -o=E:\Maps\Raw\BBST.osm.pbf

Und was passiert?
Fehlermeldung:

"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…

[wambacher (Walter Nordmann)]

@Bernhard Hiller

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

"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

[Bernhard_Hiller]

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

[quasilotte]

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)!

[wambacher (Walter Nordmann)]

@quasilotte

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.

[Marqqs]

@wambacher

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

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

[kellerma]

@Marqqs

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

Ja! Wissen wollen

@Marqqs

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?

[wambacher (Walter Nordmann)]

@kellerma

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”

[Bernhard_Hiller]

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.

[Marqqs]

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

@Marqqs

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…”)

[wambacher (Walter Nordmann)]

@Bernhard Hiller

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/Osmosis/Polygon_Filter_File_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/Osmosis/Detailed_Usage#Area_Filtering_Tasks

@Bernhard Hiller

• 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”.

[Marqqs]

@Bernhard Hiller

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.

[kellerma]

@Marqqs

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 )

[Bernhard_Hiller]

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…

[Bernhard_Hiller]

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

[viw]

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.

[wambacher (Walter Nordmann)]

@Bernhard Hiller

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

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?

[wambacher (Walter Nordmann)]

@Bernhard Hiller

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

[Bernhard_Hiller]

@viw

4 GB Ram oder mehr?

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

[Marqqs]

Guten Morgen ihr!

@wambacher

• 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

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

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…