Osmosis: bbox gegen polygon

brogo · 2011-03-08T11:16:05.000Z

Hallo!

Hat es große Auwirkungen auf die Verarbeitungsgeschwindigkeit von Osmosis, wenn man statt einer Bounding-Box ein Bounding-Polygon benutzt? Ich denke mir, daß es doch umfangreicher zu berechnen ob ein Punkt innerhalb eines Rechteckes oder eines komplexen Polygons liegt. Andererseits muß ja bei einer Bounding-Box mehr geschrieben werden, was sonst rausgefiltert wird.

Christian

_i · 2011-03-08T12:18:53.000Z

Also ich habe nicht so viel Erfahrung damit, war aber positiv überrascht, dass es nicht wirklich viel kostet.

Soweit ich mich entsinne, wird das auch relativ klever gemacht, indem erst einmal eine BoundingBox je Polygon erstellt wird und gegen das geprüft wird. Danach wird eine innerste Boundingbox des Polygons erstellt und dagegen geprüft. Nur die verbleibenden Punkte sind unklar und müssen mit aufwendigeren Berechnungen geprüft werden.

aighes · 2011-03-08T13:43:13.000Z

Was nun schneller ist hängt ja primär von deiner Hardware ab. Auf einem Atom mit HighSpeed SSD geht wahrscheinlich --bb schneller und auf einer HighEnd-CPU mit USB1.1-Platte wohl eher --bp

Generell tut sich das aber nicht soviel, dass man sich da Gedanken machen müsste.

Garmin-User · 2011-03-08T14:07:32.000Z

Hi,

solbald Meer im Spiel ist, würde ich die Bounding Box bevorzugen, da die Tiles immer rechteckig sind und das Meer nur bis zum Rand aufgefüllt wird, wenn keine weiteren das Meer begrenzenden Daten vorhanden sind. Bei Verwendung eines Bounding Polygons verschwinden nämlich besonders auffällig Elemente wie Inseln oder Teile von Festland innerhalb der betreffenden Randkachel im Meer, wenn sie außerhalb der Polygongrenze liegen.

Viele Grüße
Mario

aighes · 2011-03-08T14:45:40.000Z

Das ist dann aber eine Frage der Festlegung des Polygons

brogo · 2011-03-09T08:39:05.000Z

Was mich jetzt sehr erstaunt hat, war die Tatsache wie langsam bz2 ist. Ich wollte aus einem pbf-Planet mittels bbox was ausschneiden und als bz2 speichern (für den Splitter von mkgmap). Nach mehreren Stunden habe ich den Vorgang abgebrochen. Schätzungsweise hätte das wohl sicherlich 6 bis 10 Stunden gedauert. Nachdem ich die Ausgabe auf XML (unkomprimiert) umgestellt habe, lief das Ganze in 25 Minuten durch. Ausgabe in PBF (compressed=none) ist noch etwas schneller schnell, nur kann der Splitter damit ja noch nicht umgehen.

Christian

aighes · 2011-03-09T08:50:17.000Z

doch…kann er sogar schon länger

Zumindest lesen. Schreiben kann er es noch nicht. mkgmap kann pbf ebenfalls lesen.

Marqqs · 2011-03-14T11:28:12.000Z

Osmosis ist im Allgemeinen akzeptabel schnell. Aus eigenen Versuchen weiß ich aber, dass es bei sehr komplexen Polygonen arg lange braucht. Solang das Polygon aus 100 oder 200 Punkten besteht, läuft alles wunderbar schnell, wenn man aber ein Grenzpolygon irgendwoher extrahiert und dessen Kanten nicht geglättet hat, dann kann es schon mal aus ein paar zigtausend einzelnen Punkten bestehen. Und dann läuft das Ausschneiden in Osmosis recht langsam. Hier kommen zwei Lösungen in Frage:

Polygon glätten
Falls das Polygon nicht exakt sein muss und man auf einige Punkte verzichten kann, kann man es glätten. Dazu gibt es das Tool “simplify-polygon.pl” von hier: http://trac.openstreetmap.org/export/24667/applications/utils/osm-extract/polygons/
Anderes Programm verwenden
Sehr schnell beim Ausschneiden komplexer Polygone ist das Programm “osmchange”: http://wiki.openstreetmap.org/wiki/Osmchange_%28program%29

Zu der Sache mit dem Packen:
bz2 packt zwar recht effektiv, ist aber wirklich sehr langsam. Viel schneller ist “lzop”. Die komprimierten Dateien sind dann zwar nicht so klein (ca. 60% größer als bei bz2), werden aber sehr schnell gepackt und auch entpackt. Sofern “lzop” nicht installiert ist und man es auch nicht installieren möchte, würd ich “gzip” mit der Option “-1” empfehlen - das ist auch noch relativ schnell.