[Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event

[aighes]

Am 04.07.2012 14:10, schrieb Ronnie Soak:
>> Sinnvoll nutzbar wäre die Overpass-API, wenn sie direkt die Kacheln liefert.
>> Idealerweise als pbf, mit xml ist mkgmap 5-7mal langsamer. Und die Frage
>> ist: Ist das von der Last her sinnvoll. splitter erzeugt recht wenig Last
>> und der RAM-Verbrauch hält sich sehr in Grenzen.
> Wenn die (CPU?) Last gering ist und auch der RAM nicht voll, dann wird
> I/O die Grenze sein, an der er sich 1h aufhält.
> Da kann ich mir schon vorstellen, das ein vorgefiltertes .osm (ich
> schätze mal 50% der Originalgrösse) was bringt.
>
> Allerdings hast du recht, dass wir von der API nur XML bekommen. Wenn
> pbf wirklich so viel schneller ist, werden wir nichts gewinnen, wenn
> wir in der Toolchain noch eine Umwandlung haben. Gilt das 5-7x auch
> für splitter?
Hallo,
primär kommt der Unterschied ja aus der I/O-Bremse. Bei xml muss 
deutlich mehr eingelesen werden. Die Zahlen stammen aus der Zeit, als 
splitter und mkgmap pbf gelernt haben. Wenn ich mich recht erinnere 
beziehen sie sich nur auf splitter, der ja primär Daten schaufelt. Bei 
mkgmap ist das Einlesen nur ein Teil der Arbeit. Hier sollte es etwas 
weniger werden. Aber es ist schon deutlich schneller ein pbf einzulesen 
als ein xml.

Was mir noch eingefallen ist: Sinnvoll ist der Weg über die OverpassAPI 
natürlich nur, wenn das über schnelles LAN angebunden ist oder auf dem 
gleichen Server läuft und ob dann die OverpassAPI schneller ist als 
osmfilter bzw. mkgmap intern würde ich erstmal verneinen. Aber wenn du 
es testen willst nur zu. Wäre ja mal interessant zu wissen, wie es 
wirklich ist.

Henning