Ersatz für osm2pgrouting gesucht

Ich habe gute Erfahrungen mit OSRM gemacht. Der initiale Import der Daten dauert etwas, aber anschließend steht eine brauchbare API und extrem schnelle Routenberechnung zur Verfügung: http://project-osrm.org/

Weil Routing nicht gleich Routing ist, solltest du schildern auf welche Kriterien es in deinem Szenario ankommt.

Augustus Kling wrote:

... solltest du schildern auf welche Kriterien es in deinem Szenario ankommt.

Ich habe kein Anforderungsprofil, ich will doch nur spielen 😉

Also eigentlich hätte es mir vollkommen gereicht, wenn ich mir aus OSM-Daten mal schnell einen GPX-Track zusammenklicken könnte: Drei Klicks auf die beteiligten Wege und daraus dann automatisch ein GPX erzeugen.

Dummerweise geht so ein OSM-Weg oft weiter als bis zur Kreuzung wo ich abbiegen muss. Ich müsste also den gewählten Weg aufschneiden, an der Kreuzung den Anschlussweg suchen und den weiter verfolgen. Der letzte Satz ist ungefähr die Beschreibung der Tätigkeit eines Routers. Und so kam ich zum Routing.

pgrouting hab ich ausgesucht, weil ich postgres-Datenbanken halbwegs bändigen kann und dachte, es sei gut, die Daten fürs Rendern und fürs Routing in der gleichen DB zu haben. Der Vorteil ist auch da, ich kann z.B. recht unkompliziert die Routen mit einem Höhenprofil versehen, oder mal schnell zum Testen alle Pfade mit sac_scale=X ein bisschen teurer machen und dafür Mitglieder einer "route=hiking"-Relation billiger.

Zielgruppe ist ein Fussgänger in Wald und Wiese, also alles ohne no-left-turn oder oneway oder maxspeed. Performance ist mir egal und bei meiner Serverausstattung auch nicht interessant, ich kann auch gerne mal ne Kaffepause machen 😉

Das funktioniert auch alles ganz gut, kleinere Rundwege sind schnell zusammengeklickt und in schwieriges Gelände gerät nur, wer das ausdrücklich wünscht. Nur geht das halt mit ziemlich viel Bastelei nach dem Importieren. Da würde ich mir was schöneres wünschen 😉

Grüße, Max

Glaubst du wirklich das du mit einer pgrouting Datenbank noch rendern möchtest?

viw wrote:

Glaubst du wirklich das du mit einer pgrouting Datenbank noch rendern möchtest?

Nein. Die DB fürs Rendern hab ich ja schon. Das Routing ist dann nur eine zusätzliche Tabelle mit den aufgebrochenen Wegstücken (ohne die ganzen Attribute, weil die sind auch schon da).

Edit: Obwohl so ein gerenderter Routinggraph auch hübsch aussieht...

maxbe wrote:

viw wrote:

Glaubst du wirklich das du mit einer pgrouting Datenbank noch rendern möchtest?

Nein. Die DB fürs Rendern hab ich ja schon. Das Routing ist dann nur eine zusätzliche Tabelle mit den aufgebrochenen Wegstücken (ohne die ganzen Attribute, weil die sind auch schon da).

Edit: Obwohl so ein gerenderter Routinggraph auch hübsch aussieht...

http://geo.dianacht.de/tests/thu_routinggraph.png

Wie hast du denn die Wege aufgebrochen?

viw wrote:

Wie hast du denn die Wege aufgebrochen?

Das macht osm2pgrouting. Das frisst eine .osm-Datei, grübelt darüber nach, wo sich Wege kreuzen und füllt eine Tabelle mit (Knoten -> Weg ->Knoten). Die Wege da drin sind die Teilstücke der OSM-Wege jeweils zwischen zwei Kreuzungen (oder was er eben dafür hält s.o.).

maxbe wrote:

[…]Ich habe kein Anforderungsprofil, ich will doch nur spielen 😉

In dem Fall würde ich zwei grundsätzliche Ansätze unterscheiden: Komplette Berechnung im Graph (beispielsweise pgRouting) und Kontraktionshierarchien (beispielsweise OSRM).

Komplette Berechnung im Graph: Vorteil ist, dass die Parameter für jede Route einfach angepasst werden können und damit viele Variablen in die Berechnung einfließen können. Nachteil ist die Langsamkeit.
Kontraktionshierarchien: Vorteil ist extrem schnelle Berechnung der Route weil beim Datenimport Abkürzungen angelegt werden. Nachteil ist, dass zur Erstellung der Abkürzungen klar sein muss wie teuer die Segmente sind und daher schon alle Parameter bekannt sein müssen.

maxbe wrote:

Also eigentlich hätte es mir vollkommen gereicht, wenn ich mir aus OSM-Daten mal schnell einen GPX-Track zusammenklicken könnte: Drei Klicks auf die beteiligten Wege und daraus dann automatisch ein GPX erzeugen.[…]

OSRM bringt dafür eine nette API mit: https://github.com/DennisOSRM/Project-O … Server-api

maxbe wrote:

[…] • Die "Länge" eines Weges ist nicht die Länge, sondern der Abstand der Endpunkte, egal wie geschwungen die Wegführung ist.

Die Länge der Wege ist egal. Es kommt nur auf die Kosten für die Segmente an. In pgRouting ist das die Spalte „cost“, in OSRM kommen Profile in Form von LUA-Skripts zum Einsatz.

maxbe wrote:

[…] • Wege werden an den Berührungspunkten mit anderen Strichen aufgetrennt. Allerdings auch an Strichen, die nichts mit dem Wegenetz zu tun haben. Falls z.B. eine Strasse auch Grenze eines landuse ist oder einer Postleitzahl, ist jeder Node der Strasse auch Trennstelle. Das führt dann zu sehr vielen sehr kurzen Wegstückchen.

In nehme an, dass osm2pgrouting stupide alle Verbindungen auftrennt und es daher einer Vorfilterung der Eingangsdaten bedarf.

maxbe wrote:

• Wege die einen Punkt mit sich selbst verbinden, sind aus Sicht des Routers völlig nutzlos und werden weggelassen.[…]

Es ist eine Einschränkung von pgRouting, dass Routen nur an Endpunkten von Wegen (nach Splitting durch osm2pgrouting) beginnen oder enden können. Ich meine pgRouting betrachtet nur den Graph und weiß nicht was eine Geometrie/Weg ist.

Augustus Kling wrote:

Komplette Berechnung im Graph (beispielsweise pgRouting) und Kontraktionshierarchien (beispielsweise OSRM).

ok, dann schau ich mir OSRM mal an, wenn ich Zeit hab, man muss ja alles mal gesehen haben. Ich hab übrigens "Länge" und "Kosten" synonym verwendet. Meine "Kosten" sind "(Weglänge + x*Höhenunterschied)*(Faktor für schöne/unschöne Wege). Weglänge ist wirklich die Länge der Geometrie, Höhe ist derzeit die Differenz der Endpunkte. Auch so eine Baustelle, gut dass es kaum Wege gibt, die lange genug sind, dass das auffällt.

Augustus Kling wrote:

In nehme an, dass osm2pgrouting stupide alle Verbindungen auftrennt und es daher einer Vorfilterung der Eingangsdaten bedarf.

Jo. Ich hab nicht rausgefunden, was alles einen Weg trennt. Aber landuse gehört jedenfalls dazu, was manche Straße, die zugleich Waldrand ist, schon sehr zerfetzt. Aber ich muss sowieso die bbox aus einem Geofabrik-Extrakt ausstanzen, da filter ich alles weg, was nicht highway=* ist.

Augustus Kling wrote:

Es ist eine Einschränkung von pgRouting, dass Routen nur an Endpunkten von Wegen (nach Splitting durch osm2pgrouting) beginnen oder enden können.

Bei Dijkstra und A* ist das so, ja. Das erfordert ein paar Kopfstände beim ersten und letzten Wegstück und führt zu lustigen Ergebnissen, wenn man nur 1 oder 2 Wegstücke weit routet.
Es gibt noch ein "Shooting Star" bei pgRouting, das hangelt sich von Kante zu Kante. Aber ich bleib erst mal bei Dijkstra, das ist der einzige Algorithmus aus dem Bereich, den ich verstehe. Die unimportierten Kreisel hebe ich mir noch auf, da weiss ich gerade gar nicht, wie ich die finden und reparieren soll.

Danke für die Erklärungen,
Max