[Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp

[Florian Lohoff]

On Thu, Oct 03, 2013 at 09:26:12PM +0200, Jörg Frings-Fürst wrote:
> 1.) Eine Zuordnung PLZ <--> Grundstück wird bestritten.

Meine mail ging auch an die Liste wie du vielleicht feststellen
konntest.

Hier der Kontext:

> > > Jörg Frings-Fürst wrote
> > > PLZ ist ein Merkmal eines geografischen Zustellgebietes. Und sie ist in
> > > diesem Gebiet für alle Grundstücke gültig.
> > > Damit gibt es eine eindeutige Zuordnung PLZ <--> Grundstück.
> > 
> > Das alleine bestreite ich schon. Eine Postleitzahl ist ein Technisches
> > Hilfsmittel der Deutschen Post um Gruppen von Adressen zu bilden. Diese
> > hat den Zweck der einfachen überregionalen Logistik.

Guck dir einfach mal die PLZ Polygone an und geh mal an den Rändern durch
und such die Postleitzahlen mal auf der Webseite der Deutschen Post
raus. Du wirst einige überraschungen erleben wo das gefundene so einfach
mit Polygonen NICHT abbildbar ist es sein wir fangen jetzt auch 
mit en und exklaven an.

Die Post benutzt keine Polygone sondern Adresslisten zur zuordnung
der PLZ. Das das in kleinen Dörfern oft auf ein schönes einfach Polygon
hinausläuft bestreite ich nicht. Das geht aber Orten mit mehr
als einer PLZ schief. Dort hat man keine Polygone mehr sondern wenn
es gut laeuft sieht das am ende aus wie ein Tintenfisch vielleicht
aber auch eher wie Dalmatiner.

Und ich habe schon diverses an PLZ polygonen versucht so hinzubiegen das
das passt und an einigen stellen habe ich das einfach aufgegeben.

> 2.) Bis heute war ich der Meinung ein optimaler Weg Daten zu verarbeiten
> wäre das Vorhalten in einer Datenbank. Jetzt scheint es besser zu sein
> Daten auszulagern und zu komprimieren. 

Du hast damit argumentiert das es 380MByte sind die Postcode in Deutschland
zusaetzlich zu erfassen.

Ich habe gesagt das es sogar mehr ist - und wenn man es kompremiert auch
gerne mal nur 18MByte. 

Nicht jedes byte im Planet muss und wird exakt so in der Datenbank stehen - Wir
betreiben ja keinen geocoder auf dem planet als XML file sondern daten werden
vorverarbeitet und dann nur extrakte die fuer diese aufgabe noetig sind
in die Datenbank geschrieben.

Wenn es nicht um OSM Daten gehen würde würde man sogar die Postleitzahlen
in einer - und die Adressen in einer anderen tabelle halten - Relationales
datenmodell und so ...

> Und 19.000.000 Datensätze müssen in der Datenbank gespeichert, indiziert
> und verarbeitet werden. Und das kostet Zeit und Platz.

Diese aussage ist auch mal wieder spannend. Das hat doch ganz schwer
was mit dem Schema zu tun.

In einer mit osm2pgsql erzeugten datenbank stehen die GAR NICHT
drin. Bei dem snapshot schema von osmosis sind sie nur ein attribut
an einem node oder way in einem hstore. Damit sind sie kein eigenständiger
Datensatz sondern vielleicht eine spalte wobei das bei hstore nichtmal
eine eigenständige spalte ist.

Wenn wir auf Nominatim eingehen berechnet dieser die Hierarchie ja vorab,
d.h. selbst wenn ich keine PLZ eingebe ist die doch in der Datenbank.

Und jetzt koennen wir nochmal die CPU und DiskIO kosten ausrechnen 
ob es sinn macht in einem varchar index zu suchen oder eben alle
adressen via gist index der geometrien in der Datenbank gegen ein
Multipolygon zu matchen.

In dem einen Fall suche ich in einem index nach der Postleitzahl,
im anderen Fall suche ich den gist index der Gebäudeumrisse bzw Nodes
ob diese mit ST_Intersect via bounding box auf das extent eines Polygon 
matched. Den rest mache ich dann zu Fuß ohne Index.

Ich tippe mal drauf das letzteres etwa 4-8 mal so viel CPU zeit braucht
und vermutlich von der IO last faktor 2.
Der IO Faktor könnte noch deutlich höher legen je nachdem
welche geometrien alle in dem index stehen. 

Um es noch mal klar zu machen:

Vorberechnen -> Kein platzgewinn in der Datenbank
So speichern -> CPU intensiver bei der Abfrage.

D.h. das einzige ueber was wir hier so reden sind die 18MByte die zusaetzlich
im Planet file stehen.

Der letzte Planet war 30GByte (http://planet.openstreetmap.org/planet/)
bz2 XML. Wenn wir es dann mal schaffen alle PLZ in D
zu erfassen haben wir da 18MByte mehr. Das sind 0.05% oder 0.5 Promille
bei dem Planet von heute.

Bis dahin wird der Planet vermutlich aber auch 100-200GByte haben und
die paar Postleitzahlen sind - ähm - lächerlich.

Flo
PS: Ich propose highway demnaechst als hwy zu schreiben. Spart pro way
in der Datenbank 4 byte - Macht bei 199406145 ways derzeit einen Gewinn
von 760MByte - Oder nur h= - dann wären es 1.3GByte. building muesste
dann b= sein - landuse ist l= - waterway ist w= --- Läuft.
-- 
Florian Lohoff                                                 f at zz.de
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 828 bytes
Beschreibung: Digital signature
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20131003/fcb6c098/attachment.sig>