für ein Projekt benötige ich etwas hilfe:
Wir haben die Aufgabe, eine OSM-Datei in eine pgsql-Datenbank einzutragen und daraus einen Routing-Service zu entwickeln.
Hierfür wollen wir eine Webschnittstelle schaffen, an die jeweils der Startpunkt und Endpunkt übertragen wird und nachher die Route (die via PGRouting erstellt wurde) zurückgibt.
Die Frage ist jetzt: Wie bekomme ich denn überhaupt raus, an welchem Punkt der Benutzer starten will und wo er hin will?
Irgendwo muss es da im PGSQL ja eine Datenbank geben, die mir sagt wo welche Straße in welchem Ort liegt.
Dass das Routing an sich später über Nodes und ways funktioniert, ist mir soweit erstmal klar - die Frage ist halt nur, wie ich erstmal “von der eingegebenen Straße oder dem Ort” zum “node” oder “way” komme.
Was genau muss ich denn da importieren? Bisher sind eben nur NODES und WAYS in der DB drin. Da sind aber nirgends Ortsnamen, Postleitzahlen o.ä. gespeichert. Was genau muss ich da denn noch importieren in die PGSQL Datenbank?
Vielleicht hilft es, wenn Du die Ortsnamen, Postleitzahlen, Strassennamen usw. importierst
(addr_country=, addr_housenumber=, addr_postcode=, addr_street= und is_in=*)
Falls das nicht weiterhilft, dann bitte erkläre, um was es genau geht und was Du genau machen willst und was Du brauchst… dann kann man detailierter drauf eingehen…
Hallo efred - genau da liegt das Problem.
Ich habe die Daten selbst nicht importiert, sondern von einem Kommilitonen importieren lassen.
Haben wir vielleicht vergessen irgendeine Datei zu importieren?
Welche Dateien genau müssen denn heruntergeladen und importiert werden, um das passende Kartenmaterial zu erhalten? Ich blicke bei dem Dateijungel nicht ganz durch - und unser Admin hat scheinbar irgendwas vergessen zu importieren. Oder muss man das Ganze irgendwie als Parameter beim osm2pgsql angeben, was man importiert haben will?
Schau dir doch mal das Projekt Nominatim unter http://wiki.openstreetmap.org/wiki/Nominatim an. Nominatim wird auch auf der Startseite von OSM genutzt, wenn man nach einer Adresse sucht.
Auf der verlinkten Seite ganz unten findest du auch den Source Code des eigentlichen Such-Algorithmuses (“Indexing and search are performed using a combination of c, plpgsql and php. …”).
Vielleicht hilft dir das weiter.
was für Dateien habt ihr eigentlich importiert? eigentlich muss man nur eine Datei importieren: planet_latest.osm (klar, wenn man den aktuellsten Stand will, muss man noch die dailys auch noch hinzufügen). jedenfalls sind da auch die Strassennamen drin.
vielleicht hilft dir auch der Quelltext und die js-dateien von your navigation weiter. siehe auch http://www.yournavigation.org/about.html und http://wiki.openstreetmap.org/wiki/YOURS und natürlich auch wie Nodefinder schreibt Nominatim…
Alles klar, danke. Ich werde mal in Richtung unseres Admins Kontakt aufnehmen, dass er mal die Datei bitte importieren möge.
In unserer Datei sind im übrigen auch Straßennamen drin. Allerdings fehlen hier eben die Zugehörigkeit zu diversen Städten (ich glaube Hausnummern haben wir auch nicht drin). Und das wäre an sich ja schon noch wichtig, denke ich. Sonst macht so ein Routing-Service ja gar keinen Sinn
Wir schauen mal, dass wir “Norminatim” installiert bekommen - scheinbar liefert uns das ja schonmal zumindest einen Teil der Sachen, die wir wollen. Wenn man das anpasst, bekommt man bestimmt auch einen entsprechenden “NODE” aus der Datenbank herausgegeben …
Vermute ich zumindest mal, dass das irgendwie geht. Da muss ich morgen in RUHE mal den Quelltext der search.php überfliegen, was dort zurückkommt, wenn man eine Suche ausführt.
lat/lon bekommt man ja zurück, ebenso eine osm_id und eine place_id … schauen wir mal, ob sich das mit dem Datenbestand in der DB irgendwie überdeckt. Wäre ja super.
So wie es aussieht, hat euer admin schon alles richtig gemacht. Der Standard-Import in die Datenbank ist nämlich lediglich auf die Darstellung in Mapnik optimiert. In welchem Ort eine Straße nun liegt, steht so in den Rohdaten von OSM nämlich garnicht drin (von ein paar is_in-Einträgen abgesehen). Dazu muß man anhand der Grenzrelationen (soweit vorhanden) ermitteln, in welcher Gemeindefläche die Straße liegt. Das ist für die Datenbank relativ einfach, wenn man es ihr beibringt.
Wenn es keine Grenzrelation gibt, muß man die Straße nach dem nächstliegend eingetragenen Gemeindeknoten einsortieren, was natürlich auch schon mal falsch sein kann.
Für Hausnummern (die in OSM noch lange nicht flächendeckend drin sind) gilt im Prinzip das gleiche.
Da fängt eben das postprocessing an, das sich kommerzielle Router gut bezahlen lassen.
Ja schon, aber bitte nicht die Internetseite belästigen, weil er dann früher oder später geblockt wird. Er wird das schon auf seiner lokalen Datenbank aufsetzen müssen.
Dass es in die lokale Datenbank kommt, ist soweit klar.
Die Frage ist halt dann wirklich nur, WIE bekommt man die nötigen Daten in die Datenbank. Inwiefern das dort in der Installationsanleitung erklärt ist weiß ich allerdings nicht.
Dennoch finde ich es komisch, woher ein Ortsname kommen soll (im Sinne von: IN welchem Ort liegt eine Straße), wenn diese Ortsnamen (ich konnte sie zumindest nicht finden) gar nicht in der DB liegen?
Wenn man nach der Installationsanleitung vorgeht, sollte man aber eigentlich ALLE Daten haben, die man benötigt (und das auch in der lokalen Datenbank) - richtig?
Sollte dem so sein, befinden wir uns auf einem guten Weg. Ansonsten wird das wohl ein ziemlich schwieriges Projekt… Oder wir stellen uns einfach nur dumm an?
Gibt es im Web vielleicht ein Tutorial, dass uns hierbei helfen kann - sollte die Installation von diesem genannten Tool nicht weiterhelfen?
Der Name alleine reicht nicht, du musst ja auch wissen, ob die Straße innerhalb der Grenzen dieses Ortes liegt. Und die sind in OSM als Relation, d.h. als Aneinanderkettung von Grenzwegen definiert.
Der Name des Ortes ist dann als name-tag an der Relation vorhanden, ein Knoten ist dann nicht notwendig.
Wenns keine Grenzen in der Datenbank gibt, ist man dagegen auf den Knoten mit place=* angewiesen. Das ist aber dann eher Raterei über die Entfernung zu den nächstliegenden place-Knoten.
Die addr:-tags kann man natürlich auch noch auswerten.
Also “drin” sind die Informationen schon; nur nicht auf Adressuche optimiert.
wir haben mittlerweile “Nomination” installiert und auch ausprobiert - die Karte lässt sich zoomen, Ortsnamen werden angezeigt usw. - nun funktioniert jedoch die Suche nicht.
Bei der Beispielsuche nach “Berlin” liefert uns das Programm folgenden Querystring:
select word_id,word_token, word, class, type, location, country_code, operator from word where word_token in (’ berlin’,‘berlin’)
Dieser kann aber (im Grunde logischerweise) keine Ergebnisse liefern, da die Tabelle “word” leer ist (so wie einige andere, von denen er scheinbar Daten will auch).
Kann uns jemand sagen, ob man hier evtl. noch irgendwas installieren oder ausführen muss um diese Tabelle zu füllen? Unser Admin hat soweit eigentlich alles nach der Anleitung ausgeführt - aber die Tabelle bleibt leer. Soll das so sein? Ich hoffe doch nicht - oder haben wir beim Import eventuell was übersehen/vergessen? Müssen hier noch nachträglich Daten eingefüttert werden, kann das einer sagen?
Ansonsten würden wir noch mal (zum Xten mal) die Daten in die Datenbank neu einspielen - eventuell diesmal zu zweit, nicht dass wir was übersehen haben.
Mittlerweile sind wir scheinbar ein Stück weiter - haben jetzt schonmal ein paar Datensätze in der DB drin, die da wohl auch reingehören.
Mittlerweile funktioniert es - scheinbar haben wir schlicht und einfach vergessen, die Datenbankverbindung in einem SQL-Script zu aktualisieren. Jetzt läuft es aber soweit - und er findet auch die Adressen, die wir ihm reinfüttern.
Müssen wir mal schauen, wie wir das mit pgrouting verknüpfen - mal schauen ob man auch von “way” zu “way” und von “way” zu “node” die Route berechnen kann.
Ansonsten muss ich mir da noch was ausdenken.
