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 [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Talk-de mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-de
