osm2pgsql und Relationen

Tag zusammen,

kann mich bitte jemand zur Doku schicken, wo der Umgang von osm2pgsql mit Relationen beschreiben ist?

osm2pgsql dröselt z.B. Grenzen, die als bondary-Multipolygon angelegt wurden auf und legt die in planet_polygon ab. Sollte eine Exklave dabei sein, werden mehrere Polygone abgelegt, die an ihrer osm_id als zusammengehörig erkannt werden können. Ausserdem wird das gleiche Spiel nochmal in planet_line wiederholt. Auch dort gibt es dann mehrere Grenzlinien.

Bei Relationen vom Typ "route=train" ist das nicht so. Die werden nur in planet_line abgelegt. Falls flächige Gebilde Teil der Relation sind, ein Bahnsteig z.B., werden die sogar ihrer Fläche beraubt und als Umrisslinie mit der osm_id der Relation in planet_line gespeichert. Als eigenständiges Objekt unter ihrer eigenen Id sind sie natürlich auch in planet_polygon.

Bei Grenzen hat das Sinn, die kann man ja entweder als Fläche oder als Grenzlinie sehen. Bei Zugstrecken ist das Verhalten auch gut. Man wüsste ja gar nicht wohin mit den großen linienartigen Teilen einer Strecke.

Ich habe noch keinen Fall gefunden, wo Relationen nur als Polygon abgelegt werden. Ich habe aber auch noch nicht durchschaut, wie das überhaupt abläuft, und deshalb wäre eine Doku sehr hilfreich. Im "default.style" steht nur ein vager Hinweis auf "hard coded support for area=1/yes" und den Quelltext verstehe ich nicht.

Ein Hinweis, dass es den Fall "nur in planet_polygon abgelegt und nicht planet_line" nicht geben kann wäre schön.... Ich würde nämlich gerne osm-Elemente als GPX darstellen. Bei einfachen Flächen und Ways ist das kein Problem. Aber Polygone mit Enklaven bekomme ich einfach nicht hin, ausser ich hole sie mir aus planet_line, wo die schon schön linearisiert drinliegen.

viele Grüße,

Max

Edit: "natural=water ; waterway=riverbank" sowie "landuse=forest" scheinen Vertreterinnen der "Nur-Polygon"-Relationen zu sein. Da hab ich also anscheinend verloren, was meine Hoffnung auf planet_line betrifft. Grenzen scheinen eher die Ausnahme zu sein...