[osm-pfenz] Code-Repository für Statistik, Slippy-Map, ...

Detlef Reichl detlef.reichl at gmx.org
Sa Nov 29 17:57:48 CET 2008


> Von: "Lutz Horn" <lutz.horn at fastmail.fm>
> 
> Eine der ersten Änderungen, die ich für den bestehenden Code vorschlage 
> ist das Entfernen von absoluten Pfaden. Die Aufgabe der Erzeugung der  
> Statistik und der txt-Dateien für die Slippy-Map sollte getrennt werden  
> vom Kopieren dieser Dateien auf den Web-Server.

Hallo,

meinst Du mit absoluten Pfaden die in der config.rb? Die habe ich extra für den Einsatz bei dir statisch gemacht.

Ich bin bereits dabei den Code in großen Teilen umzugestalten. Hierbei soll es zu einer weit aus stärkeren Teilung kommen, so das die Generierung und Verarbeitung der Daten auf mehrere Rechner verteilen kann (optional).

Meine bisherigen Vorstellungen in kürze:
- Holen der Daten von OSM:
die Daten werden Kachelweise geholt und auf der Platte unbearbeitet ablegt (die Daten werden in einer Verzeichnisstruktur die den Kachel-X und Y-Positionen entspricht abgelegt). Jede Kachel entspricht der Größe eines tiles bei Zoomstufe 12 ( http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames ). Dies wird auch nicht mehr über die OSM API gemacht, sonder über die XAPI ( http://wiki.openstreetmap.org/wiki/DE:Osmxapi ). Dieser Part ist mit - derweil auch vernüftigen Fehlerhandling - weitestgehend fertig.

- Holen der Daten zum Abgleich:
Straßenverzeichnisse und ähnliches werden, wenn sie nicht als statisch deklariert sind über plugins geholt. Welches plugin genutzt wird wird aus den boundarys ermittelt. Wenn keine statischen Daten vorhanden sind oder für einen Ort(steil) dynamisch beschafft werden können, fallen die entsprechenden parts für die Statistik, die Slippy, oder was noch sonst kommen mag raus.

- Aufbereitung der Daten:
die Daten der Kacheln werden geparst und separiert nach nodes, way und relations auch wieder auf der Platte abgelegt. Dies geschiet im jeweiligen "Kachel-Verzeichniss". Um den exponentialen Verarbeitungszeiten entgegen zu wirken werden die nodes und ways je auf 64 Einzeldateien aufgeteilt. Die zuständige Datei ergibt sich aus einem 8x8 Raster über der Kachel.

- Generierung der Statistik und der Slippy werden eigene Programme

- Für die Generierung der Statistik wird von den Stammdaten eine Kopie erstellt, die nur die Daten enthält die sich innerhalb des boundary des gewünschten Orts befinden.

Durch diese Aufteilung wird es möglich zum einen nur das zu nutzen, was man benötigt und zum anderen die Aufbereitung der Daten wenn nötig verteilt laufen zu lassen.

Als namespace würde ich Ow vorschlagen, schön kurz und kollidiert mit niemanden. Eigentlich wollte ich es MapCruncher nennen, habe dann aber festgestellt, das es das schon von M$ gibt *grrr*. Ow steht übrigens für OsmWolf

> 
> Außerdem würde ich die bisher drei existierenden Arten von Dateien
> besser  
> unterscheiden:
> 
> * statische Dateien für die Slippy-Map (map.html, map.js, Stylesheets,  
> Grafiken)
> * osm-stat.rb samt seiner Module und Konfigurationsdateien
> * die von osm-stat.rb erzeugten Dateien (2008-11-29.html, map.png,  
> bank.txt, usw.)
> 
> Die dritte Art von Dateien sollte nicht im DVCS bekannt sein.

Jep, das gehört mal vernünftig aufgeräumt.

> 
> Soweit erstmal. Der vorhandene Code ist auf alle Fälle  
> verbesserungswürdig. Ich hoffe, dass wir auf diese Art effektiv mit  
> mehreren Leuten gemeinsam an den schon sehr coolen Toools arbeiten
> können.  
> Denn schließlich soll ja Pforzheim auch die erste Stadt sein, bei der
> alle  
> Briefkästen nachweislich vollständig erfasst sind :)

Aber bitte mit Öffnungszeiten ;-)

Grüßle, detlef