osm2pgsql und "--expire-tiles"

Tag zusammen,

ich habe mich ein bisschen mit der --expire-tiles-Funktion von osm2pgsql beschäftigt, aber so ganz steige ich nicht durch. Stimmen meine bisherigen Forschungsergebnisse?

  • Eine Kachel wird immer als “veraltet” markiert, falls dort eine Änderung passiert. “Änderung” ist alles, was zu Schreiben / Ändern / Löschen in der Datenbank führt.

  • Bei einer punktförmigen Änderung wird die betroffene Kachel markiert und die Nachbarkacheln, falls der Punkt weniger als 10% vom Rand entfernt ist (TILE_EXPIRY_LEEWAY in expire-tiles.c)

  • Bei einer Änderung in einem Strich wird jede Kachel markiert, die von diesem Strich geschnitten wird, auch wenn kein Node dieses Ways in der Kachel liegt (deshalb wird in expire_tiles_from_line() der Strich zwischen den Nodes interpoliert)

  • Bei Veränderung in einer Fläche werden alle Kacheln innerhalb der bounding box dieser Fläche markiert. Die Notbremse wird bei grossen Flächen gezogen (“gross” ist alles was grösser als EXPIRE_TILES_MAX_BBOX ist). Bei grossen Flächen wird nur der Umriss der Fläche markiert.

Falls das so stimmt, wäre meine wichtigste Frage, ob es irgendwo eine Liste gibt, mit der man osm2pgsql sagen kann, was man für wichtig hält. Ich hab z.B. den “operator”-key in der Datenbank, weil ich den für manche Dinge brauche. Für Karten brauche ich den allerdings nicht und da wäre es praktisch, Änderungen dieses Schlüssels zu ignorieren.

Alternativ: Wie markiert man sonst seine Kacheln als “abgelaufen”? Ich weiss, dass z.B. Tirex auch eine Schnittstelle hat, seine Renderwarteschlange aus den Diff-Files zu generieren. Aber Tirex verwende ich nicht und ich habe das Gefühl, dass osm2pgsql schon die richtige Stelle ist, Veränderungen zu bemerken…

viele Grüße, Max

… Deine Interpretation ist richtig.

Nein, soweit ich weiss, gibt es das nicht.

Tirex hat keine solche Schnittstelle. In Produktion bei OSM wird ein separates Skript eingesetzt, das die osc-Files analysiert: https://trac.openstreetmap.org/browser/subversion/applications/utils/export/tile_expiry.

Eine alternative Herangehensweise ist es, einfach (mit niedriger Priorität) konstant alle Tiles, die auf dem System herumliegen, neu auszurechnen - die ältesten zuerst. Das ist gewisssermassen die Holzhammer-Methode, aber sie ist relativ simpel.

Bye
Frederik

Das ist schade… Da könnte mir der nächste Massenedit den Cache wegputzen, wenn die betroffenen Punkte breit gestreut sind, auch wenn er noch so scheinbar belanglose Dinge ändert. Und der Revert am nächsten Tag dann gleich noch mal… :wink:

Dann schau ich mir dieses tile_expiry mal an. Bisher lösche ich alles, was älter als 2 Wochen ist. Ein paar Wochen hinter der Datenbank ist so die Schmerzgrenze, schliesslich wird bei OSM ja immer auf Aktualität Wert gelegt. Bei den meisten Kacheln dürfte das aber unnötige Arbeit sein: Bei niedrigen Zoomlevel ändert sich zwar dauernd irgendwas im Bereich einer Kachel, aber selten etwas was man im kleinen Maßstab auch darstellt und in hohen Zoomleveln ändert sich in abgelegenen Gebieten monatelang nichts.

Danke, Max