Hallo,
ich melde mich mal hierzu, weil ich fuer die Wheelmap den Code aufgesetzt habe, der die Polygon-POIs verarbeitet.
Wheelmap rendert nicht selbst, das ist ja schon gesagt worden.
Das urspruengliche Wheelmap-System konnte ja nur mit Punkt-POIs umgehen, und vom User Interface her war das ja auch voellig OK - irgendwelche Polygone in der Web-Karte haetten da nur verwirrt.
Dieses System funktioniert so, dass die Wheelmap eine - relativ kleine - MySQL-Datenbank hat, in der sich nur die interessanten POIs befinden, und die in kurzen Abstaenden anhand von .osc-Files von OSM aktualisiert wird.
Wir haben uns bei der Polygonverarbeitung fuer einen Ansatz entschieden, bei dem an diesem existierenden System fast nichts veraendert werden muss. Wir haben einen zweiten Server aufgesetzt, auf dem eine relativ normale PostGIS mit osm2pgsql und minuetlicher Aktualisierung per osmosis laeuft, also im Grunde genau die gleiche Technologie wie fuer einen normalen Tile-Server, allerdings mit einer reduzierten osm2pgsql-Style-Datei, so dass wir da z.B. keine Landuse-Flaechen und keine Liniengeometrien und so drin haben. Als zusaetzlicher Kniff sorgt ein PostgreSQL-Trigger dafuer, dass jedesmal, wenn das osm2pgsql irgendwas an der planet_osm_polygons-Tabelle dreht, was uns interessiert (z.B. einen neuen shop=supermarket eintraegt), der Mittelpunkt dieser Geometrie berechnet und in eine separate Tabelle (die heisst bei uns “pseudo_nodes”) geschrieben wird.
Ein einfaches Skript holt nun regelmaessig alle neuen oder geaenderten Eintraege aus der pseudo_nodes ab und erzeugt daraus etwas, das wie ein ganz normales .osc-File aussieht, nur dass die “node IDs” dort negativ sind. Dieses .osc-File kann dann direkt vom Wheelmap-Produktionssystem, das ja nur mit Nodes arbeitet, geladen werden.
Diese Loesung mag auf den ersten Blick etwas kompliziert aussehen, aber sie hat zwei wertvolle Vorteile: Erstens kann das Produktionssystem unveraendert bleiben und muss sich nicht mit Polygongeometrien herumschlagen. Zweitens ist die relativ “teure” Polygonverarbeitung - die ja das Vorhalten aller 1,5 Milliarden Nodes von OSM erfordert, nur fuer den Fall, dass sie ploetzlich zur Konstruktion eines neuen shop=supermarket gebraucht werden - komplett auf einer separaten Kiste und beeintraechtigt nicht die Performance des Produktionssystems; sollte da mal was klemmen, ist der worst case, dass die Updates ins Stocken kommen - nicht aber, dass die ganze Wheelmap langsam wird.
Das Meer sind eigentlich nur die erwaehnten vielen “auf Vorrat” vorgehaltenen Nodes in der Polygon-Aufbereitungs-Datenbank. Was bei der Wheelmap ankommt, also die tatsaechlichen Polygon-Mittelpunkte, ist durchaus handhabbar.
Bye
Frederik