Hallo Leute!
Hier ein wenig Licht in der Dunkelheit:
1) Ein Routing wird niemals auf den OSM-Way-IDs arbeiten, da dies schlichtweg nicht funktioniert.
2) Die Daten müssen vorher konvertiert werden und wenn das gesuchte Programm gut ist, dann liefert es vielleicht zusätzlich die ursprüngliche OSM-ID zurück.
3) Es gibt nun grundsätzlich zwei Zielgruppen. Die einen suchen ein schnelles Routing (z.B. als C+±API), andere eher für geografische Fragestellungen. Bei letzteren liegt der Fokus auf Datenmanipulations-Möglichkeiten. z.B. um externe Sachen hineinzumischen, Visualisierung in GIS-Programmen, etc.
Die ursprüngliche Frage in diesem Thread bezog sich jedoch auf Geschwindigkeit und Handhabung.
4) Den ersten Platz belegt da ein Programm, geschrieben in purem C, was die Konvertierung und das Routing übernimmt und zusätzlich kompatibel in alle Richtungen ist. Ein solches Programm kenne ich nicht.
5) Die alternative ist pgRouting (reines Datenbankrouting) - eher für Analysezwecke geeignet, wo die Laufzeit keine Rolle spielt. Dann hätten wir den MoNav von OSM. Entweder als fremden Dienst anzusteuern (=Abhängigkeit) oder lokal zu installieren. Allerdings braucht man für letzteres eine etwas anspruchsvollere Rechner-Landschaft. MoNav ist aber sauschnell.
6) osm2po arbeitet entgegen der obigen Behauptung weder auf XML noch auf der Datenbank.
Richtig ist: Es liest osm.xml, osm.bz2, osm.pbf und konvertiert dies in ein eigenes Format.
Als Nebenprodukt fällt dabei auch noch SQL für PostGIS/pgRouting ab.
osm2po kann über HTTP-GET oder SOAP angesprochen werden.
osm2po kann auch als Java-Library eingebunden werden.
7) Ein A* Algo ist kein Hexenwerk. Es ist und bleibt ein Dijkstra mit’m bisschen Heuristik drin. Was die Routing-Algos betrifft, kochen eigentlich alle nur mit Wasser. Wenn ein A* behauptet, er sei schneller als ein anderer, dann wird an der Heutistik gedreht und geschummelt. Es gibt für A* eine ganz eindeutige Heuristik-Vorschrift (Formel), die ihn sogar “optimal” werden lassen kann.
8) Ach ja… und es kann sogar passieren, dass ein Dijkstra performanter läuft als ein A*. Das hängt von geografischen Besonderheiten ab oder davon, ob man sich vom Rand des Kartenausschnitts in die Mitte bewegt oder eben anders herum.
9) Schneller kriegt man diese Kisten meistens dadurch, dass man von beiden Seiten gleichzeitig losroutet und wenn man sich dann in der Mitte trifft, dann hat man den Weg gefunden. Eine weitere Opti-Maßnahme ist die Vorausberechnung von Transitstrecken. Oder eben contraction hierarchies (MoNav). Diese Dopplungen, Überlagerungen und Relaxionen benötigen allerdings meistens wesentlich mehr Arbeitsspeicher.