folgendes Problem:
Wir sind mit eurer Hilfe ganz gut voran gekommen und können nun aus unserer Datenbank Adressen auslesen und diese entsprechenden IDs zuordnen.
Nun das letzte große Problem: Unser Serveradmin kommt an der Stelle nicht weiter, wo die Daten pgrouting-fähig gemacht werden sollen.
Wir haben eine Tabelle “ways” (wurde wohl von OSM2PGSQL so angelegt) in der Datenbank und eine Tabelle “nodes”. Nun enthält die Tabelle “ways” natürlich (da es ja Wege sind) ein int-Feld mit “source” und eins mit “target” sowie Felder mit to_cost und reverse_cost.
Interessanter Weise ist das Feld mit “reverse_cost” immer mit Werten belegt - aber die Felder mit source, target und to_cost sind IMMER = NULL.
Ich habe es nun selbst einmal probiert dieses pgrouting-script laufen zu lassen - allerdings blicke ich (trotz der Readme-Datei die beiliegt) nicht so richtig durch - in meinen Augen ist die Dokumentation etwas dürftig.
Versucht habe ich mich an der Anleitung hier: http://www.pgrouting.org/docs/tools/osm2pgrouting.html
Aber so richtig funktionieren will es anscheinend trotzdem nicht - er macht zwar irgendwas, aber so recht weiterbringen tut mich das auch nicht - ich kann eben einfach keine Route ausführen, da ich weder source noch target in der ways-Tabelle habe.
Zur Zeit steht er schon ziemlich lange bei folgender Konsolen-Ausgabe:
Split ways
Nodes table created
Ways table created
Types table created
Classes table created
Passiert ist aber seit einigen Minuten nichts mehr …
Ich warte noch ab - vielleicht mache ich auch was falsch? Wenn jemand einen Tipp hat (vielleicht fehlt einfach nur ein SQL-Script?!) bitte posten. Wenn wir hier genauso fix vorwärts kommen durch euch, wäre ich euch SEHR verbunden.
Dein Ansinnen gefällt mir und auch ich bin an einer Lösung interessiert.
Das erste Problem ist das mit OSM2PGSQL wahrscheinlich das falsche Tool gewählt wurde. Denn hier geht es darum die OSM daten für einen Renderer bereitzustellen. Dementsprechend ist auch das Datenbankschema aufgebaut.
Für PG Routing gibt es ein Tool namens OSM2pgrouting. Dieses Tool hat die Aufgabe die OSM Daten in der Datenbank speziell für den Zweck des Routings aufzubereiten. Man kann alternativ auch Shapefiles in die Datenbank schreiben, aber eben nicht jene von OSM. Diese enthalten leider noch “Fehler”, welche das Routing unmöglich machen sollen. Daher wurde ja das neue Tool entwickelt.
Wenn du erfolgreich sein warst, würde ich mich natürlich über eine Rückmeldung freuen.
Wir haben die Daten zuerst mit OSM2PGSQL in die DB eingespielt um überhaupt Zugriff auf selbige zu haben.
Jetzt können wir mit Hilfe des Nomination-Tools zumindest schon einmal Adressen aus den OSM-Daten heraus ermitteln und kommen so an 2 (scheinbar eindeutige) IDs, mit welchen wir versuchen wollen zu routen.
Ob das klappt müssen wir sehen - gerade läuft noch das OSM2PGROUTING-Tool (und verbraucht heftig RAM und CPU) und wir hoffen, dass wir danach endlich einen routingfähigen Datensatz in der DB stehen haben.
Wenn es Neuigkeiten gibt melde ich mich - ansonsten, wenn jemand anderes hier noch Lösungsvorschläge hat: immer her damit.
Ansonsten haben wir am Mittwoch um 09.00 einen Termin beim dazugehörigen Professor - evtl. kann der uns helfen.
osm2pgrouting ist der richtige Ansatz. Ich hab auch lange gehabt bis es wirklich gelaufen ist. Die Datenbank muss richtig erstellt sein! Pgrouting, PGis, etc!
Also bei mir lief das Ganze nun mittlerweile seit über 30 Stunden (dieses osm2pgrouting) - ich habe überhaupt keine Ahnung, was nun mit dem Server los ist - weder via SSH noch sonst wie komme ich drauf. Die DB lässt keine Verbindung mehr zu, garnichts. Ich reboote jetzt um 18.00 den Server und schaue mal, ob überhaupt IRGENDWAS in der DB passiert ist.
Vermutlich ist das Teil einfach zu klein - ich werde mal einen größeren Server ausprobieren, vielleicht habe ich die Probleme dort nicht - mag sein, dass die paar MB RAM etwas zu wenig waren.
Wir spielen die DB gerade auf einen stärkeren Server mit etwas mehr Arbeitsspeicher und CPU-Leistung auf. Weg vom vServer hin zum richtigen Rootserver. Dort schauen wir mal weiter.
So, mal wieder was neues:
Es scheint zu funktionieren, man kann jetzt Routen über die DB berechnen.
Den Gazeteer-Kram (Nominatim) haben wir weggelessen - für das Projekt benötigen wir das wohl nicht.
Nun habe ich noch eine kleine Frage:
Wir bekommen von einem externen Gazetteer-Service für das Routing 2 Koordinaten - Startpunkt und Zielpunkt.
Dann bin ich ganz clever und führe auf die WAYS-Tabelle folgende Anfrage aus:
SELECT * FROM ways WHERE x1=‘12.136808’ AND y1=‘51.2891357’; (als Beispiel)
Damit bekomme ich dann A-Punkte, welche alle an diesem Punkt starten. Hieraus kann ich dann also meine “Start-ID” ermitteln. Gehe ich richtig in der Annahme, dass ich hierbei die Spalte “GID” auslesen muss?
Das gleiche mach ich für den Zielpunkt und bekomme durch die GID den Punkt B (B = GID von B)
SELECT the_geom, gid FROM dijkstra_sp(‘ways’, GID von A, GID von B);
Bekomme ich damit tatsächlich die richtigen ways heraus um von Punkt A nach Punkt B routen zu können?
Oder muss ich statt der GID den Wert aus der Spalte “Source” nehmen? Das scheint mir (wenn ich ehrlich bin) sogar etwas logischer zu sein, da der “Source”-Wert doch der Startpunkt des Wegstückchens, von dem aus ich losrouten will, sein sollte. Die GID ist vermutlich einfach nur eine laufende ID - und die wird ja auch dann größer, wenn das source/target-Paar unterschiedlich ist.