Hola, On Tue, Oct 07, 2025 at 07:56:10AM +0200, Markus Bärlocher wrote:
Hi Flo,Ich meine den Platz auf der PostgreSQL-/PostGIS-DB.Bisher dachte ich, XML sei kein "richtiges" DB-Format (da Text-basiert, aufgebläht und in keiner Weise performant) und stattdessen verwende man für ein performanentes Rendering ein "richtiges" dafür optimiertes Format?Machen wir da möglicherweise etwas Suboptimales?
XML ist eher Datenaustausch format und OSM hatte initial die Daten als osm.xml Schema definiert. Das wurde irgendwann eher unhandlich von
der Datenmenge, deshalb wurde .pbf entwickelt basierend auf coolen space saving methoden aus den google protobufs.Deine Postgres/Postgis legt die daten völlig anders ab. Und ja - da ist nicht "Space efficient" wie z.b. das PBF weil es immer ein trade-off
zwischen space savings, access patters und computation ist.Das liegt aber daran das die Anforderungen völlig anders sind. Im PBF file sind erst alle nodes nach node-id sortiert, dann alle Wege nach way id sortiert und dann alle Relationen nach id sortiert.
Nur so will ja niemand auf die Daten zugreifen. Ich will ja oft alle OSM objekte die in einem Rechteck sind. Z.b. beim Rendering. Also brauche ich indexe die mir alle Objekte innerhalb eines Rechtecks geben. Dazu kommt das der "Node" im OSM Datenmodell das einzige objekt ist dasüberhaupt eine location hat. Ein Way an sich hat keine location sondern nur referenzen auf nodes, entsprechend haben relationen nur referenzen auf nodes oder ways.
Wenn du jetzt auch alle ways haben willst die innerhalb eines rechteckes liegen musst du beim import in die postgres/gis erstmal die node referenzen auflösen, und dann ein Postgis objekt eines "Ways" erzeugen
das an sich eine location hat und damit indizierbar ist.Denn beim Zugriff in der Postgres über nodes und dann eine node->way->nodes tabelle zu gehen wäre zu langsam.
D.h. beim import werden u.a. informationen "dupliziert" um andere Zugriffspatterns zu ermöglichen, oder zumindest in endlicher zeit zu ermöglichen.
Das alles macht "osm2pgsql" für dich. .pbf ist ein reines transport format das maximal space efficient ist, aber für mehr als "wir prozessieren das ganze file am stück als stream" nicht zu gebrauchen. Selbst das prozessieren um einen einzelnen way zu extrahieren musst dudas ganze file lesen, erst alle nodes - die musst du im ram cachen, dann den way suchen und alle node referenzen auflösen.
Flo -- Florian Lohoff [email protected] Any sufficiently advanced technology is indistinguishable from magic.
signature.asc
Description: PGP signature
_______________________________________________ Talk-de mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-de
