Was man im Bereich Routing mit Open-Source-Software heutzutage machen kann und was für Software dazu man benutzen kann, das wird uns jetzt der Pierre-Main-Kalperer erzählen. Bitteschön. Ja, Dankeschön. Ich begrüße Sie so zum Einstieg ins Routing.

Und zwar sind wir eigentlich nicht eine Firma, die spezialisiert sind auf Routing. Wir machen Webgeist, wir machen Kugisentwicklung. Aber die Kunden kamen so von sich auf uns zu und haben gesagt, ja wir wollen aber auch noch Routing haben. Und das hat so im Verlauf der Jahre doch einiges an Erfahrung gebracht. Und ich werde jetzt anhand von einigen Projekten ein bisschen von dieser Erfahrung weitergeben.

Die erste Kunde war eine Plakatgesellschaft, die haben wir eigentlich ein Webgeist gemacht. Also es ging eigentlich um Open-Lehrers und da hat gesagt, können wir nicht auch nochmal unsere Zustellrouten ein bisschen optimieren.

Und dann kamen andere Sachen, ja wir haben so Plakate, wir wollen den Kunden anbieten, dass die Plakate gerade in einem optimierten Umfeld, zum Beispiel von einem Einkaufszentrum liegen, dass er nur eine bestimmte Einzugsgebiet an Plakaten mieten kann.

Wir konnten bis dahin den Kunden schon überzeugen, dass er mit Poskis arbeitet. Und deshalb haben wir gesagt, ja alles kein Problem, wir routen mit Poskis. Und haben da fröhlich begonnen, weil es gibt ja PGRouting. Und das ist so die Software, die wahrscheinlich viele schon gehört haben. Das ist eine Postgres Extension, die so die typischen Graph-Algorithmen kann.

Das heißt, man macht einen Routing-Graph, aus seinen Geodaten muss man die routenfähig machen. Und dann gibt es diese lange Liste an Funktionen. Die damals waren es noch nicht alle, also da die Wiki in Mexiko, die arbeitet wie wild in den letzten Jahren,

da kommt jetzt immer wieder was Neues dazu. Also die war vor ein paar Jahren noch halb so lang die Liste. Aber einfach die wichtigsten, da extra A-Stern, shortest pass, die kann natürlich schon lange. Und unter anderem ist einiges dazugekommen. Die Arbeit ist immer dasselbe, man muss zuerst die Daten in dieses Graph-Format bringen.

Und dann kann ich diese Postgres-Algorithmen laufen lassen. Also haben wir gesagt, ja keine Sache, machen wir. Es waren so Navdeck-Hierdaten, die haben wir reingekriegt. Wir haben ein bisschen Arbeit und haben diese Algorithmen laufen gelassen.

Oder wie wir sagen, wir haben es so durchgezettert und wunderbar, haben die Routen gekriegt, haben die gegeben. Also die sahen schön aus, haben die abgegeben. Der Kunde war zufrieden, hat sie dann seinem Logistiker gegeben. Und der Logistiker hat dann gesagt, das ist absolut unprachbar, was sie da ausgeliefert haben.

Aber es war nicht nur unsere Schuld, erst dann kam quasi das Kleingedruckte, was alles auch noch zu berücksichtigen wäre. Also zum Beispiel hatten wir Probleme in Fußgängerzonen, weil wir haben natürlich die Fahrverbote akzeptiert und berücksichtigt. Aber die fahren ja dann doch rein mit ihren Plakatwagen und hängen die auf.

Das geht, kann man abbilden, man macht eine Maximalgeschwindigkeit von einem Kilometer pro Stunde. Und schon geht es dann im Notfall auch in die Fußgängerzone rein. Man darf nicht zu hoch gehen, weil dann geht er auch durch, wenn er nicht sollte. Aber das kriegt man hin. Dann gibt es so blöde Probleme, dass halt diese Plakatzäulen und die Anhaltestellen nicht am gleichen Ort sind.

Das ist datenmässig nicht unbedingt automatisiert lösbar. Die mussten wir dann halt von Hand noch Haltestellen eintragen. Und dann gibt es so Gebäude wie Bahnhöfe, wo ganz viele Plakate hängen und wir natürlich keine Fahrtrouten finden mit Daten.

Das ist auch nicht so einfach zu lösen. Und dann kommen die wirklich schwierigen Probleme. Dann hat er gesagt, ja, wenn wir mit dem Fahrzeug fahren, dann gehen wir zuerst eine Richtung in der Straße, verteilen überall rechts. Und dann gehen wir den Retourweg und verteilen auf der anderen Straßenseite. Das ist dann schon ein schwierigeres Problem. Das heisst, wir haben gesagt, ok, kriegen wir hin.

Wir splitten jetzt alle unsere Routen auf und machen zwei Routen draus. Aber dann mit den ganzen Abbiegereien und so wird es schon sehr knifflig. Und dann gibt es auch noch diese Autobahnstellen, wo man eigentlich auch nicht hin dürfte, aber sie trotzdem irgendwie hinfahren.

Also auch die waren recht schwierig. Das heisst, wir haben noch ein, zwei Durchläufe gemacht und am Schluss konnten wir etwas Brauchbares bringen. Wir haben nicht die handoptimierten Routen hingekriegt, die sie über die Jahre erarbeitet haben, aber wir haben auch ein paar neue Ideen gebracht.

Was man machen muss bei Routing-Funktionen, das passiert immer auf dem Graph. Und da gibt es einen Kostenfaktor, der dann berücksichtigt wird. Und jetzt in dem Moment wäre das recht einfach. Kostenfaktor gleich Geschwindigkeit, das heisst die Zeit, die ich brauche, um wodurch zu fahren.

Eben noch mit dem Spezialfall für Fahrverbote und auch sonst mussten wir noch ein paar Faktoren reinbringen. Sie wollen nicht unbedingt durch, sie wollen schon auf den Hauptstraßen bleiben, wenn es irgendwie geht. Das heisst, sie wollen nicht beliebige Abkürzungen durch Quartiere machen. Das heisst, man schraubt dann schon sehr lange an diesen Kostenfaktoren.

Dann habe ich eben gesagt, dass die Fahrtrichtungsproblematik und die manuellen Pläne von Haltenpunkten. Was jetzt hier noch ein grösseres Problem war, wenn wir das für einzelne Städte gemacht haben, funktioniert das wunderbar mit der extra A-Stern, also performant. Aber wenn wir jetzt dann nationale Routen anschauen oder weitere Distanzen, dann sind diese Algorithmen schon nicht mehr so gut.

Weil die durchsuchen wirklich quasi alle Varianten. Und das heisst, sie machen nicht zuerst die Autobahnverbindung von A statt A nach statt B und dann die Feinverteilung, sondern sie suchen sich alle möglichen Routen. Das heisst, es wird sofort um Faktoren langsamer, wenn ich großflächiger werde, wenn ich auch international werde.

Funktionieren diese Grundalgorithmen rein für sich allein eigentlich nicht mehr, da muss ich schon andere Optimierungen finden. Und deshalb im Nachhinein, eigentlich ist jetzt hier PGRouting wahrscheinlich nicht das Richtige gewesen, war unser Fazit.

Und da ist aber ein paar Alternativen. Was jetzt eigentlich ein bisschen ausgerichtet ist auf diese Problematik ist Graf Hopper. Will ich jetzt aber nicht viel davon erzählen, ich habe gerade die Folie kopiert, die dann auch noch kommt im nächsten Vortrag. Es ist eine Java-Bibliothek, Webservice for Routing, kommt auch von OpenStreetMap her, kann aber auch eigene Daten verwenden,

bietet dieselben Algorithmen und noch einiges mehr und ist aber schon ein bisschen auf, hat mehr Logik drin. PGRouting ist wirklich Graf, Kosten, fertig. Es hat keine Business-Logik oder irgendwas drin, die muss ich alle selbst machen.

Und da gibt es dann schon Routing-Engines, die schon ein bisschen mehr Wissen vom Problemgebiet haben, die dann halt je nach Problematik bessere Konfigurationsmöglichkeiten bieten und auch bessere Resultate liefern dadurch.

Anwendung Nummer zwei, was ganz anderes, da hieß es, wir haben Kugis im Einsatz, online und offline, und wir wollen Straßenrouting machen. Online ist etwas ganz anderes als offline. Fürs Online ist es relativ einfach, das haben sie sogar selbst gesagt, wir wollen OpenRoute-Service nutzen.

Also es gibt Online-Services, wo ich halt Start und Ziel eingeben kann und kriege dann eine Route. Oder auch Isochronen, solche Sachen gibt es Online-Dienste. Offline ist eine andere Geschichte. Und da wäre jetzt auch Postgres kein Kandidat, deshalb war es für uns jetzt hier ein Fall für Spatial Light.

Und das kommt dann im übernächsten Vortrag noch im Detail. Und die Daten OSM. Deshalb hier noch eine Folie zu Spatial Light. Wie ist denn verunstaltet im Titel? Spatial Light ist eine Single-File DB, also ein einzelnes File, das man aber über SQL wie eine DB anspricht.

Und das hat eine Erweiterung Virtual Network oder jetzt neue, in der kommenden Version wird es Virtual Routing heissen. Die Algorithmen sind jetzt wieder so die Basis-Algorithmen, Dijkstra und A-Stern.

Was es hier gibt, das ist sehr praktisch. Es hat so eine Spatial Light OSM-Net, also ich kann direkt OSM-Daten einlesen. Was aber häufig der Fall ist, wenn man nur an gewissen, also es hat schon spezialisierte Importe, die sagen Spatial Light OSM-Net, Straßenverkehr und dann filtert er auch die entsprechenden Straßen raus.

Oder auch verschiedene, ich kann sagen Schienenverkehr, dann filtert er das. Aber je nachdem muss man auch noch vorfiltern, also man hat zuerst die OSM-Daten vorfiltert, bevor man sie dann dem Spatial Light füttert. Und dann geht es eigentlich sehr ähnlich, ich habe dann SQL-Funktionen, die ich dann zum Routing brauchen kann.

Das sah jetzt konkret so aus, also das ist jetzt das Desktop-Giz mit der Isochronen-Funktion. Und Offline funktioniert eigentlich sehr gut, also auch grössere Daten kann ich durchaus empfehlen.

Auch sehr einfach, ich habe die Kostenfunktion, ich muss einfach die Daten so aufbereiten, dass ich eine Kostenfunktion habe, die dann dieses Resultat liefert, das ich benötige. Aber jetzt eben schon das grundsätzliche Straßenrouting funktioniert man schon recht gut.

Also man ist noch nicht Weltklasse, aber so für die Anforderungen hat es gereicht. Jetzt gibt es hier noch weitere mögliche Anforderungen, das war jetzt einfach die Basisanforderung. Ich will Straßenrouting machen, ein bisschen komplizierter wird es, wenn es dann halt multimodal werden soll.

Also wenn ich eine Schiene-Bus-Fussweg mischen will und da bin ich dann eigentlich mit diesem Ansatz schon, da wird es schon sehr schwierig, wenn ich einfach den Graph für mich aufbereiten muss, dass er so etwas rauskriegt. Das heisst, da gibt es dann schon wieder spezialisierte Engines, die eigentlich diese Multimodalität schon voraussetzen oder unterstützen.

Also da wird es dann zu schwierig, wenn ich einfach den Graph so aufbereiten soll, dass er mir verschiedene sinnvolle Varianten gibt von verschiedenen Transportmitteln. Auch kompliziert wird es, wenn ich anfange Fahrpläne einzubeziehen.

Also wenn ich ÖV-Routing machen will, dann reicht eben nicht nur die Strecke, sondern ich muss ja auch noch den Fahrplan anschauen. Also ich muss die Zeit berücksichtigen, wann ich an dem Punkt bin, fahre dann ein Bus. Dann wird es auch nochmal eine Stufe komplizierter. Und auch da gibt es jetzt wieder andere Software, die das halt schon ein Stück weit eingebaut hat.

Und eben so Nahverkehr, Fernverkehr, was ich vorgesagt habe, dass halt ein Routing-Engine zuerst schaut, gehe ich mit dem Schnellzug ein paar hundert Kilometer und dann Feinverteilung mit lokalen ÖVs. Das sind auch wieder zusätzliche Algorithmen, die ich da für diese Fern-Nah-Unterscheidung berücksichtigen muss,

damit ich auch die Performance habe, um das Echtzeit machen zu können. Und dann hatten wir auch schon Anforderungen, wir wollen dann auch nicht einfach normale Autos routen, sondern Spezial-Transporte. Das heisst, dann muss ich bei allen Strassen noch berücksichtigen, kommen auch die grossen Lastwagen durch und hat Kreisel drin und solche Sachen.

Das sind dann mehr wieder Datenprobleme, dass ich halt wirklich die Daten so habe, dass ich das routen kann. Die Alternativen in dem Gebiet, vor allem im Open-Street-Map-Bereich, da hat es eine ganze Sammlung von Routing-Engines gegeben. Auch dadurch, dass es Open-Street-Map als weltweiten Datensatz gibt, haben da verschiedenste Leute Routing-Engines gemacht.

Und da habe ich jetzt gar nicht aufgelistet, was es alles gibt. Es gibt eine gute Wiki-Seite, die schon mal einen Startpunkt gibt. Hier raus gebickt habe ich jetzt Valhalla, das unterstütze ich jetzt z.B. Multimodal und Time-Based-Routes.

Das ist von Map10 entwickelt worden, das Team wurde dann von Mapbox aufgekauft und Map10 gibt es ja nicht mehr, aber Valhalla gibt es noch.

Und das wäre jetzt ein möglicher Startpunkt, wenn ich diese komplizierten Anforderungen habe, die ich vorgezeigt habe. Anwendung Nr. 3, wieder was ganz anderes, da kam jemand mit einer CO2, der will eine CO2-Plattform machen.

Da hat er gesagt, der will für Warentransporte CO2-Verbrauch errechnen und da muss er eigentlich die Transporte relativ genau kennen, die Distanzen. Und z.B. mit Eisenbahntransport will er unterscheiden zwischen elektrischen Strecken und Dieselstrecken. Er will auch nach Land unterscheiden, weil er da verschiedene Energieerzeugungsarten hat, wo er dann den CO2-Verbrauch rechnet.

Und dann Nr. 2, also haben wir immer noch gesagt, ja kein Problem, Eisenbahn-Routing, OSM hat das sicher. Dann kam er noch mit Shifts-Routing, da waren wir schon ein bisschen unsicher. Und zwar will er Shifts-Routing sowohl auf dem Meer, das ist etwas ganz Neues für uns, oder auch für uns nicht so naheliegend.

Aber dann kann er auch noch, ja die Flüsse muss er natürlich auch noch haben, also er will dann auch noch die Fluss-Transporte dazu haben. Gut, das ist eher dann wieder ähnlich den Strassen, aber eigentlich sind es zwei komplett verschiedene Dinge.

Eisenbahn hat sich bewahrheitet, OSM ist der einzige weltweite Datensatz, den es gibt. Sonst ist Eisenbahn ein ganz schwieriges Thema, haben wir jetzt festgestellt. Muss man dann national nachforschen, überall, wo ist jetzt wirklich Diesel und wo ist es elektrisch.

Jetzt haben wir gerade letzte Woche noch China herausgefunden, wo was ist, also da muss man viel recherchieren. Aber OSM hat ein weltweites Netz, mal ein Basisnetz, das sehr gut ist. Die Länder haben wir aus Natural Earth genommen. Zuerst war nur die Anforderung, Schienen nach Land, das war noch einfach,

mussten wir einfach die Strecke suchen und dann verschneiden mit den Ländern. Aber dann kam die Anforderung, wir müssen aber noch pro Land wissen, wie weit elektrisch, wie weit Diesel. Und das war dann schon nicht mehr so einfach, das heisst wir haben alle Daten vorverarbeitet und haben alle Segmente verschnitten mit den Ländern und die Elektrisch-Diesel-Attribute darauf getan.

Kostenfaktor war jetzt in dem Fall einfach, kürzeste Strecke plus noch so ein Diesel-Malus, dass man wenn möglich Dieselstrecken umfährt. Probleme, OSM-Daten sind super, aber man sieht noch viele Lücken, wo man jetzt, wenn man

es einfach anschaut, merkt man, es kann sicher nicht alles so sein, wie es da ist. Da hat es noch einige Lücken, die wir dann von Hand füllen mussten, mit viel Recherche. Zum Teil hat es auch zu viele Daten, da sind irgendwelche Rangierstrecken drauf, die man nicht so einfach rausfiltern kann, die dann auch wieder so 100 Meter Diesel ergeben im Resultat, was dann auch wieder seltsam war.

Beim Länderverschnitt hatten wir dann auch Probleme mit Bahnlinien, die ganz am Küstenrand oder an der Grenze verliefen und die Auflösung unserer Länder nicht genau übereingestimmt hat mit den Schienenauflösungen. Das heisst da hatten wir dann auch noch Handarbeit, um die Daten hinzukriegen,

aber wir haben es geschafft und die Resultate waren jetzt für die Anwendung gut. Hier ein Beispiel von Mailand nach Dresden, die kürzeste Strecke, die rein kürzeste Strecke. Ich kann das Deutschland nicht genau beurteilen, also die Schweizer Teil stimmt sicher. Wir haben schon einige Strecken prüfen lassen und das macht wirklich Sinn, was da rauskommt.

Da gab es und gibt es vielleicht noch Vorträge, die auf die Eisenbahnrouting speziell eingehen. Für unsere Zwecke war das schon mal gut, OSM-Daten aufarbeiten und so einen Graf-Algorithmus überlassen, dass es funktioniert.

Dann GIFs Routing ist wie gesagt noch ein anderes Kapitel. Daten haben wir in den Natural Earth genommen, haben wir zuerst auch OSM genommen, aber die Flüsse da waren viel zu detailliert. Da kommt jeder Bach, ist da drin und wir konnten sie nicht attributiv rausfiltern.

Das heisst, Natural Earth hat viel weniger drin, aber für uns genügend. Wir mussten dann die Liegenden segmentieren und ans Meer noch anbinden, zum Teil, weil die GIF-Lösung nicht überall stimmt. Das Meer haben wir ganz anders gelöst, da gibt es einerseits rasterbasierte Ansätze, aber wir waren jetzt schon auf diesem Graph-Ansatz.

Deshalb haben wir uns für dieses Gitternetz entschieden. Wir haben zuerst ein weltweites Gitternetz gemacht, haben die Landmassen rausgeschnitten. Hier ist jetzt 10 Grad, das ist natürlich viel zu grob, aber einfach, dass man etwas sieht.

Dann haben wir die Flüsse reingesetzt und alle häfen und haben die noch an den nächsten Knoten angebunden. Und sind so zu guten Resultaten gekommen. Wir mussten den Routing-Graph erstellen natürlich, Kostenfaktor, die Segmentlänge auf Wege 84.

Das ist da noch wichtig, weil die ganze Erde, da muss man schon schauen, dass man das richtig rechnet. Und das gibt es jetzt zum Beispiel für Basel, Mumbai, gibt es jetzt so eine Route, die auch jetzt für nicht-Seefahrer sehr plausibel aussieht.

Im Detail wird es da schon noch ein paar Sachen zu Bemängung geben, aber für unser Zweck, die Distanz muss zustimmen, das ist nicht für die Schichtfahrt direkt, sondern für diese Berechnung war das eigentlich schon sehr gut. Und wir können wirklich eine Route angeben.

Letzte Folie, Fazit zum Wissen. Also es gibt verschiedene Klassen von Routing-Engines, die man sich vor Augen führen muss. Es gibt so die Online-Engines, die decken schon sehr viel ab, das heisst vor allem im OSM-Bereich gibt es viele Engines. Dann gibt es die Kommerziellen, der Stern ist da, ich darf sie nicht für alles brauchen, ich darf zum Beispiel nicht Google-Routing machen, aber meine eigene Karte dahinter haben.

Das heisst da muss man aufpassen, dass man legal bleibt. Für die eigenen DBs, habe ich gesagt, gibt es hier OSM-Routing-Engines und Postgrespec-Routing. Und mobile-offline ist eigentlich so ein Geheimtipp, Spatial-Lite. Und auch da gibt es aber noch mehr Sachen.

Gut, Dankeschön, das war so die Einführung, dann haben wir noch seine Fragen. Super, das war eine Punktlandung würde ich sagen. Vielen Dank. Gut, Sie haben jetzt die Gelegenheit, Fragen zu stellen.

Bei den Fragen bitte darauf achten, bis einer von uns beiden mit dem Mikro da ist, damit wir das auch in den Saal und auf den Filmen übertragen können. Gibt es Fragen aus dem Plenum? Vielen Dank für den interessanten Vortrag.

Verbessern Sie auch OSM-Daten, wenn Sie jetzt einen Fehler in der Topologie feststellen, also dass dort irgendwie Linien nicht verbunden sind. Also dass Sie das auch wieder zurückspielen auf die OSM-Datenbank, gibt es da eine Routine? Also das, was wir gemacht haben, das hätten wir nicht zurückspielen können, weil wir halt wirklich die unbeliebten Massen-Eddies gemacht haben.

Das heisst, wir haben es im Cookies geöffnet, machen Rechtex-Selektion und sagen, das ist jetzt Diesel. Das dürfen wir nicht zurückspielen in OSM. Sonst, also wirklich Fehler in dem Sinn haben wir gar nicht gefunden. Also dass jetzt wirklich Löcher drin waren, also das Routing hat sehr gut funktioniert. Also das, da gab es jetzt gar nichts zu korrigieren an den Daten eigentlich.

Wir mussten wirklich ergänzen und halt so grob ergänzen, dass wir das nicht zurückspielen dürfen. Ja, ein Aspekt bei den Routen, der wäre auch ein Werkzeug für Open Street Map intern.

Wenn man zum Beispiel Routen zusammenstellen muss, dass man quasi den Anfangs- und den Endpunkt einfach festlegt, dann mit einer Routing-Engine das erstmal routen lässt und dann einzelne Punkte anfassen, bis man sie quasi auf die Routen draufgezogen hat.

Was fehlt, ist quasi ein Export in eine Relation, dass man diese Geschichte dann als Route in Open Street Map verwenden kann. Das wäre sehr hilfreich für viele Mapper, die sich mit Relationen nicht auskennen.

Und von daher, so eine Route sich selber zusammenstellen, das können Sie alle. Und wenn Sie ja wissen, ja der Bus fährt da lang, machen Sie es eben mit dem Routenplaner. Und Sie brauchen eigentlich nur eine Exportfunktion, die das als Relation rauswirft.

Gut, klar. Noch mal kurz eine Frage zu der Plakatierungsgeschichte. Ich hatte mit ähnlichen Sachen vor Jahren auch schon mal zu tun gehabt. Meine Erfahrung war eigentlich, wenn man anfängt, diese Bedingungen, die Sie angesprochen hatten von rechts, links und anhalten und talala,

wenn man die alle zu Fuss an diese Sachen anträgt, ist die Ersparnis durch automatisiertes Routing, also auf gut Deutsch, wenn man das manuell macht, ist man genauso schnell. Wie sind denn Ihre Erfahrungen? Sind die ähnlich oder kann man da tatsächlich Zeit sparen damit?

Ich habe es vielleicht nicht so klar ausgedrückt, aber ich muss auch sagen, für dieses Grafrouting ist die Problematik zu kompliziert. Ich kriege die Daten nicht, oder ich muss so einen riesen Aufwand in das Rechtbiegen der Faktoren reinstecken, dass sich das eigentlich nicht lohnt. Trotzdem würde ich sagen, es gibt zum Teil wirklich neue Ideen, also ich würde es halbautomatisch machen,

mir irgendwie Inspirationen von der automatischen Routing nehmen und dann handoptivieren jetzt in der Praxis. Meine Frage ist, Sie haben offenbar viel Erfahrung, jetzt Daten aus verschiedenen Quellen zu verarbeiten und in beliebige Engines zu packen. Da würde mich interessieren, wie gross ist der Model Mismatch, also wie gross ist die Arbeit, die man machen muss, um das hinzukriegen?

Also insbesondere, wenn die Strukturen komplizierter werden, wenn ich nicht nur Kostenfaktoren habe, sondern auch Abbiegebeschränkungen und solche Sachen. Ich kann es jetzt gar nicht so, ich kann noch generell antworten, die Hauptarbeit liegt immer in der Daten eigentlich. Also das ist eine Erfahrung, die wir gemacht haben, man steckt viel, viel Arbeit in die Daten rein.

Und schlussendlich ist man da am Korrigieren, am Feilen und eben die Mismatches haben wir und zum Teil gewisse Sachen kann man automatisieren, dass man die automatisch korrigiert, man merkt es am Anfang nicht, aber dann sieht man, aha, meine Länderauflösung stimmt jetzt nicht genau überein mit der Flussauflösung,

weil es sind andere Datenquellen, gewisse Sachen kann ich dann halt SQL-mäßig automatisiert lösen und dann kommt viel Handarbeit. Habe ich kein Patentrezept dazu. Also das sind zum Teil auch Kunden, nicht realistisch, die sagen, ja, wir wollen jetzt Routing haben, dann sagen sie,

dann einen Fußgänger müssen wir haben und Velos und Drums und so und wir sagen dann, okay, pro Medium, pro Typ, wir investieren mehrere Tage nur, um die Daten aufzubearbeiten. Das muss einfach bewusst sein, jede Routing-Art oder jedes Medium braucht eine andere

Aufbereitung der Daten oder andere sind andere Daten, das gibt einfach viel für die Arbeit. Gut, eine Frage machen wir noch.

Ich hätte mal eine Frage zu dem Spatial Light Routing, wie ist das denn im Vergleich zu anderen Lösungen wie zum Beispiel B-Router oder Graph Hopper, die funktionieren ja auch offline, wo sind da die Vorteile von Spatial Light oder wie vergleicht sich das vom Funktionsumfang? Also Funktionsumfang ist nicht sehr gross, es ist wirklich Dijkstra und A-Stern Routing, aber es ist ein File, es ist eine SQL-Schnittstelle,

d.h. ich kann ein Mini-Python-Programm schreiben, dass mir ein SQL-Aufruf auf ein File macht, also ich meine, das ist quasi der Vorteil, dass es so kompakt und einfach ist technologisch, ich brauche keine

Server-Komponente, ich kann sogar mit einem Script einfach eine Route rausspucken, also das ist eigentlich der Hauptvorteil von Spatial Light, dass es so minimal ist. Ja gut, vielen Dank. Wenn es sonst noch Fragen gibt, du bist ja noch ein bisschen länger hier.