also zuerst möchte ich mal ein Missverständnis klar stellen: DIe Daten von der Deutschen Post und die OSM Daten werden niemals miteinander in Verbindung gebracht. Sie werden nicht miteinander vergleichen und Ergebnisse aus dem professionellen AdressCheck werden auch nicht in die OSM Daten überspielt. Das lässt die Lizenz der Deutschen Post nicht zu.
Was wir aber mit unserem AdressCheck machen können, ist eine Vergleich der OSM Daten gegen sich selbst. Lässt sich am einfachsten in folgemdem Beispiel erklären:
Es gibt (weil ich noch nicht alle geschafft hab Immer noch adressen in OSM, deren Ortsangabe “Ilmenau-Manebach” ist.
Der Ort heißt aber tatsächlich Manebach und ist nur ein Ortsteil von Ilmenau. Wenn wir aus den OSM Daten eine solche Adresse gegen die FreeAddressCheck prüfen, könnte ein sogenannter Mehrfachtreffer entstehen.
Daraus ließe sich zumindest ein Datensatz für manuelle Überprüfung erstellen. Bei Bestätigung könnte die Korrektur automatisch über die API an OpenStreetMap übertragen werden.
Das ist aber vorerst nur ein Grobkonzept bzw. eine Idee. Muss aber noch genauer untersucht werden.
@wambacher: die OpenStreetMap Datenbank wird auch als XML File als Download angeboten (http://planet.openstreetmap.org/). Aber es gibt auch Extraktionen davon, welche dann nur ein Land enthalten.
ist mir selbverständlich bekannt.
der nächste - vernünftige - schritt, ist, das zeug in ne db zu übernehmen und die dann als quelle aller weiteren aktionen zu benutzen. dazu noch der regelmäßige update mit den minute-files und dann wird ein schuh daraus.
aber BITTE lasst die finger von der sog. hstore-db mit osm2psql. die andere, “richtige” db (osmosis simple) in der neuen version ist klasse. kann sogar hstore.
gruss
walter
p.s. ich hatte das thema mit den daten nur deshalb angesprochen, weil manche “semi-profis” mit der api direkt auf die live-daten zugreifen, massendownloads machen und damit das ganze system blockieren.
sollten das alles “olle kamellen” für euch sein, wäre ich echt erfreut.
also wir nutzen das osm2psql tool für den import in die Postgres Datenbank. Auf der Nominatim Installationsseite (http://wiki.openstreetmap.org/wiki/Nominatim/Installation) gibt es leider noch keine Anleitung für osmosis und ich wusste nicht ob Nominatim mit osmosis funktioniert (hab nur gesehen, das es einen Abschnitt dazu gibt).
Die Indizierung läuft noch müssen uns dann den Code von der gazetteer webseite mal anschauen um rauszukriegen wie wir das für unseren Export nutzen können.
die osm2psql-variante ist eine “speziallösung” osm->db, die mal von einiger zeit entwickelt wurde, um osm-karten zu RENDERN.
sie steht zwischen osm und mapnik. d.h. sie erstellt eine postgres-db, die alles enthält, was man zum rendern braucht.
zudem enthält sie den sog HSTORE, wo alle tags der objekte zu finden sind.
das “speziele” an dieser lösung ist, dass sie nur die daten enthält, die der autor (nicht bretth) für relevant hielt und das noch in einem format, dass es mapnik einfach macht.
es kam dann vor, dass genau die daten, die ich jetzt eigentlich brauche, nicht drin sind.
osm2psql wird aus mindestens 3 gründen gerne verwendet:
a) viele wollen rendern
b) man kann leicht abfragen über objekte machen (was ist wo)
c) sie ist etabliert (bei obiger zielgruppe)
die osmosis-simple version wird vom autor von osmosis (bretth) betreut und enthält ALLE daten in einer form, die - für mich - wesentlich einfacher zu verwenden ist.
der haupt-nachteil (fehlendes hstore) ist in der beta-release 0.37 beseitigt und damit ist die db “sauschnell” geworden.
portieren von 0.36 nach 0.37 ist kein problem, wenn man erst mal ohne hstore arbeiten will.
auch osm2pslq verwendet osmosis, denn immer wenn es ums “datenschaufeln” geht, macht osmosis den job. ohne osmosis wäre osm tot.
Wenn osmosis so viel besser ist, dann werd ich mal ne zweite Datenbank damit erstellen und ma gucken wie die Daten da drin aussehen.
Wenn ich beide DBs hab kann ich ja mal schauen wo die unterschiede sind und ggf. die gazetteer webseite anpassen, wenn die es nötig hat.
Den hstore werden wir auf jedenfall brauchen um später die korrektur an den tags vornehmen zu können.
Ich schau’s mir mal an.
genau so hab ich es auch gemacht. mit osm2psql/hstore angefangen und dann nach einigen wochen zu osmosis/simple und dann zu 0.37 mit hstore.
da gibt es beim anlegen der db die möglichkeit, bbox und linestring - sprich die geometrie - gleich in die tabellen aufzunehmen. das macht wie bei osm2psql geom-abfragen möglich. auch in 0.36
ACHTUNG: bei der Beurteilung des simple-schemas nicht voreilig sein.
das hat sich gravierend unter 0.37 verändert. in 0.36 sind die ganzen tags in separaten tabellen, so wie man es gelernt hat (strikt relational). das hat die einfachsten abfragen (z.b. “liste alle nodes mit tag=xzy”) zur qual gemacht.
hab osmosis 0.37 jetzt aus dem svn ausgecheckt bzw. auch das developement build versucht. Bei beiden krieg ich ne Exception mit der Message:
"09.10.2010 12:26:36 org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager waitForCompletion
SCHWERWIEGEND: Thread for task 1-read-xml failed
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Cannot begin reading in Add stage, must call complete first."
Ich versuch nen Karten ausschnitt zu importieren, den ich über die OpenstreetMap Homepage exportiert habe (wollt nicht gleich mit nem planet file anfangen :-).
Das liegt nicht gezippt vor (bz2). Glaub auch nicht das es daran liegt. Aber ich werds dann gleich mal versuchen. Mit der Datenbank scheint es nichts zu tun zu haben, das die Messages noch darauf hindeuten, das das einlesen nicht funktioniert hat.
Ich guck nochmal im Trac von osmosis, aber google hat bisher nix gefunden.
Bei download.geofabrik.de findest du auch kleinere Extracts. Bspw. ganz Thüringen. Auch im neuen osm.pbf-Format.
Zu dem Fehler wäre es hilfreich, wenn du deinen Aufruf von osmosis posten könntest.
Meiner sieht so bspw. aus:
set java=C:\Programme\Java\jre6\bin\java.exe -Xmx7000M
set osmosis_file=D:\OpenStreetMap\mkgmap\bin\osmosis
%java% -cp “%osmosis_file%\lib\default\plexus-classworlds-2.2.2.jar” -Dapp.home=“%osmosis_file%” -Dclassworlds.conf=“%osmosis_file%\config\plexus.conf” org.codehaus.classworlds.Launcher --read-pbf data\europe.osm.pbf […] %*
Wenn du nicht die osm.pbf-Dateien versendest, sondern die osm.bz2 musst du statt --read-pbf file=…, --read-xml file=… compressionMethod=bzip2 verwenden.
das sind so die “anfangsschwierigkeiten” bei osmosis. an 0.37 liegt es nicht.
genau, dein test-script wäre schon was.
es kommt ziemlich darauf an, was du JETZT vorhast.
zum testen:
osmosis --read-xml file=“xxx.osm.bz2”
–write-xml file=“out.osm” macht ne kopie so zum “spielen”
osmosis --read-xml file=“xxx.osm.bz2”
–bounding-box left=8 right=9 …
oder ein --bounding-polygon “file=filter.poly” \ filtert
–write-xml "file=out.osm
zum vorbereiten für die db:
osmosis --read-xml file=“xxx.osm.bz2”
–write-pgsql-dump
directopy=“dump-dir”
enableBboxBuilder=yes
enableLinestringBuilder=yes dumpt die daten in ein flat-format
für den import in osmosis/script
der import und alles dazu im scrip-verzeichnis
zum live-update:
osmosis --read-replication-interval \ macht später mal den update
–simc \ simc ist extrem wichtig und extrem schlecht beschrieben
–write-pgsql-change host=“wno-server” database=“gis” user=“gis”
meld dich nochmal wenn du die db anlegen willst. da gibt es noch nen paar kleinigkeiten
gruss
walter
p.s. nagelt mich nicht auf jeden punkt oder komma fest, hab ich gerade mal so reingeklopft.
ach ja: es ist hier wie im richtigen leben: wenn man erst mal weiss, wie osmosis funktioniert, versteht man auch die wiki-beschreibung
nach meinen kenntnissen merkt osmosis das selber mit dem bzip.
und die klimmzüge mit dem externen dekomprimierer spar ich mir sowieso, da meine kiste schnell genug ist.
lg
walter
Hallo Walter,
ich bin mittlerweile auf das neue Format umgestiegen, was a) den Download beschleunigt und b) den Entpackvorgang (ob nun extern oder live) überflüssig macht. Ich weiß aber nciht, ob es auch einen Planet-File darin gibt oder ob es sowas mal geben wird.
meinst du das binary-format? wenn ja, ist wohl ok so. hab ich zwar noch nicht probiert aber das ist für das projekt eigentlich egal, welches format ihr für die rohdaten nehmt. osmosis “frißt” alles
ich würde aber dennoch erst mal mit .osm oder .osm.bz2 anfangen. damit klappt alles bis hin zum automatischen update der daten - im extremfall im minutentakt.
der download der daten einer stunde dauert bei mir ca 60 sekunden und das importieren in die db 10-15 min. da sind - für mich - alle fragen in bezug auf downloadzeit oder komprimierungsfaktor irrelevant geworden.
das macht wein rechner so nebenbei mit.
auf das bin-format umzusteigen, ist nur eine winzige änderung beim einlesen. danach bleibt alles so wie vorher.
Ja, ich meine das binary-Format (*.osm.pbf). Das lohnt sich aber nur, wenn man häufiger die Extracte nutzt. Bei den Diffs merkt man keinen Unterschied.
also ich hab’s mittlerweile hingekriegt. das Problem war tatsächlich das bzip2 Format. Mus ich bei gelegenheit nochmal nachschauen. Einen weiteren Fehler den ich bekommen hab, hab ich mittlerweile auch nicht mehr. Ziemlich seltsame Geschichte. Krieg’s aber im Moment nicht mehr reproduziert.
Jetzt will ich versuchen abfragen gegen die Datenbank zu machen. Hab da aber noch keinen richtigen Plan. Habt ihr da zufällig auch ne Anleitung dafür?
gehts bitte etwas genauer? “abfragen machen” kann alles bedeuten. schließlich ist das der sinn einer datenbank.
walter
könnte ne sql-abfrage, ne integration in eine web-anwendung, eine kartenerstellung und sonst noch was sein.
ich schlag mich z.b gerade mir uDig rum, um die db zu visualisieren.
natürlich geht’s genauer ;-).
Ich will natürlich die Datenbank abfragen per SQL am Besten. Im wesentlichen will ich rausfinden, in welchem Ort eine Straße liegt. Aber eigentlich interessiert mich das ganze GIS Zeug im Allgemeinen. Hab aber bisher nicht viel gefunden. Hab aber auch nur oberflächlich geschaut. Dachte ihr habt vielleicht ein paar Hinweise.
also für dich erstmal: psql aufrufen und mit sql rumspielen
etwa so. select id,tags from ways geht so nur ab simple 0.37
where tags->‘name’ = ‘pumuckelweg’
danach wirds kompliziert: viele objekte haben addr:* tags (addr:city, addr:country, addr:housenumber,…) → easy
andere sind in relationen → mittel easy
und noch andere “sind einfach da”. die kriegt man nur mit geometrischem suchen raus. nicht trivial und auch nicht schnell. (aber hochinteressant
leider ist der 3. fall der häufigste.
es gibt da noch ein system “nominatim”, dass sowas macht. benutzt auch osm-datan, hat aber so seine macken.
Ja Nominatim war unser Einstieg in die Problematik. von da aus sind wir auf osm2pgsql gekommen und dann hier übers forum eben auf osmosis.
Das ich mit psql rumspielen muss is klar. Unsere “GUI” bzw. unsere Testwebseite hat allerdings überhaupt nichts mit dem Problem zu tun, da der service nicht direkt auf den osm daten arbeitet, sondern nur auf einem subset in einem eigenen Format. Um dieses subset zu erstellen haben wir einen eigenen kleinen exporter geschrieben, in den wir die Analyse der Hierarchie einer Straßen (->Ort->Kreis->Bundesland …) einbauen wollen.
Das das nicht trivial ist ist klar, deshalb such ich ja Hinweise dafür.
Zu den “addr:" Tags. Unser bisheriger Exporter arbeitet auch damit, aber halt auf Basis des XML-Files. Aber das ist egal. Das Problem ist, das nur bestimmte nodes solche "addr” tags haben, wie zum Beispiel Häuser. Aber es sind nicht in allen Orten in Deutschland nodes gemapped, die mit solchen Tags versehen sind.
Im Klartext: Ist in einem Ort kein Haus gemapped, gibt es auch keinen node mit “addr:*” tag, aus dem eine Adresse ableitbar ist.
Ich werd mich dann mal bissel mit den möglichkeiten von postgis auseinander setzen.
Immer noch adressen in OSM, deren Ortsangabe “Ilmenau-Manebach” ist.
