We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Routing über Flächen

00:00

Formal Metadata

Title
Routing über Flächen
Title of Series
Number of Parts
56
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language
Production PlaceSalzburg

Content Metadata

Subject Area
Genre
Abstract
Routing über Flächen, Vorstellung Masterthesis.
2
Thumbnail
17:32
13
Thumbnail
42:55
40
Thumbnail
27:36
Computer scienceInterface (chemistry)Router (computing)SurfaceRoutingGRADEEckeGeomaticsGraph (mathematics)AlgorithmLecture/Conference
Abbildung <Physik>Router (computing)Run time (program lifecycle phase)WikiPLANNEROpen sourceAlgorithmPAPSurfaceLecture/Conference
Löschen <Datenverarbeitung>9 (number)Abbildung <Physik>AlgorithmRouter (computing)ZahlInterface (chemistry)MetreSmart cardGraph (mathematics)Computer animationLecture/Conference
Degree (graph theory)EckeDirection (geometry)InternetLengthAlgorithmLinieSkelettieren <Bildverarbeitung>KanteComputer animationLecture/Conference
EckeHidden surface determinationSurfaceRun time (program lifecycle phase)LaptopInterface (chemistry)KanteAlgorithmGraph (mathematics)MetreNoten <Programm>Smart cardEngineering drawingDiagramLecture/Conference
Skelettieren <Bildverarbeitung>Run time (program lifecycle phase)Degree (graph theory)Run time (program lifecycle phase)AbschätzungVariable (mathematics)Bindung <Stochastik>ZahlHidden surface determinationDiagram
Smart cardAlgorithmMetreRouter (computing)Point (geometry)RoutingLecture/ConferenceComputer animation
Run time (program lifecycle phase)Degree (graph theory)Skelettieren <Bildverarbeitung>Graph (mathematics)User interfaceKanteSurfaceGraph (mathematics)VolumenvisualisierungVapor barrierRoutingAlgorithmNoten <Programm>Network topologyRouter (computing)PolygonMAPPERForestPlane (geometry)ForceLebendigkeit <Informatik>Programmer (hardware)Computer animationEngineering drawingLecture/Conference
CW-KomplexAlgorithmMessage sequence chartDigital object identifierPolygonRoutingMountain passMultiplicationUniform resource locatorData structureComputer animationLecture/Conference
Data qualityAlgorithmGraph (mathematics)RoutingRun time (program lifecycle phase)SurfaceAlgorithmKanteRoutingPolygonRouter (computing)Smart cardHierarchyPixelRun-time systemJunction (traffic)Open sourceProgrammer (hardware)Convex setGraph (mathematics)Plane (geometry)Interface (chemistry)Absolute valueDigital filterComputer animationLecture/Conference
Router (computing)SurfaceAlgorithmCoroutineComputer programCurveDistanceFactorizationMetadataRoundingCarriagewayLinieCalculationInstanz <Informatik>Programmer (hardware)MetreRoutingEnergieLecture/Conference
Transcript: German(auto-generated)
Hallo miteinander, also mein Name ist Jakob Micksch. Ich stelle euch heute meine Masterarbeit vor, an der ich momentan gerade noch arbeite. Ich studiere hier an der Uni Salzburg angewandte Geoinformatik und
schreibe meine Masterarbeit aber an der Uni Heidelberg momentan. Genau und fange gleich mit dem Beispiel an. Das ist einfach jetzt von der ganz normalen OpenStreetMap-Seite ein Routing über einen Platz drüber und wie man sieht geht die Route außen am Platz entlang und nicht gerade rüber wie man sich vorstellen würde und das ist eigentlich gar nicht so das große
Problem, weil jeder Mensch natürlich gerade drüber laufen würde und diese Ecke nicht laufen würde und das eigentliche Problem ist in dem Bild ganz gut erkennbar und zwar fängt jetzt von oben von dem Punkt nach
unten wird geroutet und zwar ist der gleiche Anfangspunkt aber drei unterschiedliche Endpunkte einmal also minimal versetzt. Die blaue Route führt eben hier am Ausnahmen an der Fläche entlang und ist wesentlich zu
lang und die andere Route versucht gar nicht erst an dieser Außenfläche entlang zu gehen sondern nimmt einen komplett zu langen Weg und die schwarze
Route habe ich selber eingezeigt das wäre die optimal Route und wir womöglich wirst du das Routing mit OpenStreetMap funktionieren so dass aus den bestehenden Wegen ein Graph generiert wird und die Flächen sind in diesem Graph so integriert dass quasi nur die Randfläche erfasst ist aber
nicht eben quer durchgeroutet wird und es erzeugt eben solche seltsamen Routen und manchmal gibt es eben auch richtig falsche Routen wie diese hier und das ist ein Problem das ich eben mit meiner Masterarbeit eben angehen will. Es gibt dazu auch schon Ansätze und zwar ist
es die nachträgliche Begradigung dass man eine bestehende Route die an der Fläche entlang führt wird dann geht ein Algorithmus nachträglich noch mal drüber und schaut welche Wegstücke an der Fläche entlang gehen und die werden dann durch die Fläche durchgelegt also im Fall von dieser
Braunroute wird dann nachträglich noch mal gerechnet dass eben nicht hier am Platz entlang gegangen wird sondern einfach gerade durch das wird sich aber nicht anwenden lassen auf diese rote Route weil diese quasi schon mal von vorne rein gar nicht also hauptsächlich nicht an Plätzen entlang geht das heißt der Ansatz funktioniert nicht immer dann gab es
da noch ein anderes Paper das überlegt hat dass man auf einen kompletten Platz so einen Spidergrid einfügt und dass dann eine Route quasi in diesen Grid entlang führt und die dann nachträglich noch mal begradigt wird. Das erfordert aber dass quasi der bestehende
Algorithmus eben noch nachträglich verändert wird was ein bisschen ungewöhnlich ist aber könnte man eben implementieren dann man könnte Sichtverbindungen implementieren und das ist die beiden Bilder sind vom OpenStreetMap Wiki. Da gab es so eine sehr sehr lange Diskussion was man eben
machen soll mit diesem Flächenrouting und dieser Wiki Eintrag ist, wie ich es verstanden habe, eine Zusammenfassung und da wird eben vorgeschlagen dass man so Sichtverbindungen einfügen kann und das Problem bei diesen Sichtverbindungen ist dass die erst mal sehr rechnen intensiv sind weil jeder Node mit jedem verbunden wird und das geht da von der Rechenzeit
ganz ganz schnell nach oben gehen und vor allem wenn zum Beispiel hier sind Fahrradstände auf diesem Platz eingezeichnet und die haben jeweils vier Nodes und das schießt quasi die Anzahl der gerechneten Linien schießt dann durch die Decke und man kann das aber wiederum nachträglich die
wieder reduzieren, der Wiederaufwand und dieses Konzept das ist auch schon integriert in den OpenTrip Planner das ist auch eine Open Source Java Routing Engine und da kann man scheinbar, also so wie ich es mal getestet habe, kann man eben anhand von diesen Sichtverbindungen über Blätze drüber
routen. Ich habe jetzt mal mehrere Algorithmen oder also mehrere Möglichkeiten wie man jetzt eine Fläche in einen Graph verwandeln kann habe ich mal beispielhaft gezeigt und zwar einmal könnte man eben so ganz normales
Grid drüber legen das mit 5 Meter Rasterreite oder mit Diagonalen dazu und da geht dann natürlich die Kantenzahl sehr nach oben und es ist die Frage ob man das will und man kann natürlich auch die Größe variieren
das wäre dann hier im nächsten Bild da hatten wir eine 10 Meter Auflösung und man kann natürlich wie man sieht das ist jetzt einfach nord-süd ausgerichtet und manchmal die Plätze ist ja nicht immer nord-süd da kann man eventuell noch überlegen ob man die diese Grits jetzt quasi in Platz an der Hauptrichtung ausrichtet. Eine andere Möglichkeit dass man mit den
Delonay oder Voronoi Algorithmen drüber legt. Manchmal bringt es gute Ergebnisse manchmal ein bisschen schlechtere. Also diese blaue Linie hier die zeigt eben den Weg den es von der einen Seite vom Platz zu anderen machen gehen würde und das geblau gepunktelte ist die optimale
Linie und bei dem Voronois ja je nachdem und die Launay hat zufällig halt hier keine Kante deswegen gibt es hier so eine seltsame Ecke. Dann ein Skeleton das ist ganz grob gesagt wandern die Nodes alle in die Mitte und bilden dann sozusagen eine Linie und ziehen sie so zusammen. Das bringt
manchmal ganz gute Ergebnisse manchmal ziemlich schlechte hier ist auch eine so eine Ecke drin und hier bei Visibility oder Sichtverbindung eben das Problem dass hier eben jetzt kein Node ist deswegen wird hier keine Sichtverbindung gerechnet und deswegen wird hier auch so eine Ecke eingeschlagen. Das sind einfach mal so ein paar Möglichkeiten wie man
ein Graf über eine Fläche legen kann und ich habe das für ganz Baden-Württemberg mal ausgerechnet also in 5800 Flächen und wenn man also ich hab dazu Grafhopper benutzt eben auch so ein Java Routing Engine und wenn man jetzt Baden-Württemberg
normal durchrechnen lassen würde wäre es oder halt auf meinem Laptop speziell das natürlich Maschinenabhängen hat jetzt 17,5 Minuten gedauert und es werden 2,6 Millionen Kanten erzeugt und dann habe ich einfach separat mal gerechnet wie das wäre wenn man jetzt alle Flächen mit den
jeweiligen Algorithmen belegen würde und dann geschaut wie viel länger das dauern würde und wie viel mehr Kanten produziert würden und zum Beispiel über diesen Spider-5 also bei dem 5 Meter-Grid mit Diagonalen drin wird die Rechenzeit und die Kantenzahl wird sich ungefähr verdoppeln
was natürlich ein Problem darstellt wenn man jetzt ganz Europa prozessiert dann hat man wahrscheinlich mehrere Gigabyte an Routing-Grafen wenn man das plötzlich nochmal verdoppelt dann ist es schon einiges und dann Grid 5 hat dann weniger hat nicht die Diagonalverbindungen und dann Visibility
ist die Rechenzeit dann bis zu 40 Prozent mehr und genau das ist einfach mal so eine grobe Abschätzung wie die Rechenzeit und die Kantenzahl eben nach oben geht und ich habe jetzt beispielhaft diesen den Grid 5
Algorithmus mal implementiert das habe ich ein Video genauso das jetzt in Innenstadt von Heidelberg und also diese Plätze hier die beiden sind normal
kann man also mit dem normalen Routing kann man eben nur außen umgehen und jetzt habe ich also diesen 5 Meter-Grid reingelegt und das kann man eben auch quer durchgehen und manchmal sind die Ergebnisse auch noch sehr zackig aber zumindest auf jeden Fall besser als vorher und man hat eine wesentlich realistische Route genau ist auf jeden Fall noch ein Prototyp
und werde ich noch an einen noch vielen Punkten verbessern müssen genau
genau und der Graf sieht dann nachträglich so aus also man sieht ganz eindeutig welche Flächen jetzt hier prozessiert wurden und man sieht
dass auf jeden Fall wesentlich mehr Kanten erzeugt werden das ist erst mal die eine Sache und wenn ich jetzt die Grafen also die diese Kanten einfügen will dann habe ich das Problem was ich am Anfang ja einen ursprünglichen Way habe und den muss ich ja auch verändern weil neue Nodes
hinzukommen damit quasi überhaupt auf den Graf gegangen werden kann und das in diesem Grafhaberprogramm ist es eben so dass jeder geschlossene Way auf eventuell vorhandene Barrieren geprüft wird damit das Routing eben
gegebenfalls richtig handelt also manchmal gibt es eben private Wege oder es gibt irgendwelche Absperrungen und deswegen und es wird eben noch geprüft das heißt erst habe ich den ursprünglichen Weg fügt dann alle neuen Anschlusspunkte ein dann wird dieser Weg auf Barrieren geprüft und dann später kommen erst diese neuen virtuellen Wege rein die ich dann
mit diesem mit dem Algorithmus eben implementieren sie noch mal in groß also hier das sind die ursprünglichen Nodes dann kommen neue Nodes hinzu und dann eben noch zusätzlich dieser Graf innen drin genau und jetzt gibt es da schon also ein paar Probleme oder
Herausforderungen sag ich mal es gibt schon über manche Flächen bestehende Wege die allerdings nicht real existieren also das ist in der Uni Heidelberg und diese Wege die existieren in Realität nicht und die sind eben gemapt worden für den Router damit man drüber routen kann und ist halt immer so eine Sache ob man das will oder nicht man soll ja
nicht für den Renderer mappen und auch den Router nicht und wobei ja es ist eben halt eine persönliche Entscheidung muss jeder wissen und hier sieht man sind sie eben sichtbar es gibt aber auch eben Flächen wo sie eben unsichtbar sind wo sie dann irgendwie als Player minus eins oder irgendwie quasi als Pseudotunnel angegeben sind und das ist
natürlich auch nicht schön und bei mir ist jetzt so dass diese bestehenden Wege sind nicht mit meinem Graf kompatibel das heißt wenn man quasi auf dem Platz ist dann kann man nicht mehr da muss man auf meinem Graf bleiben und kann aber nicht auf die bestehenden Wege rübergehen und muss ich über hat muss ich mal wenn man eine groß angelegte Lösung hat muss mich halt mal überlegen wie man das dann machen will genau die eine
Sache dann was auch ein Problem ist eben die Topologie zum Beispiel habe ich hier ein erstmals Polygon und da gibt es eben eine Straße die hier so vorbei führt und die teilen sich die meisten Nodes aber ich mal eben halt auch nicht weil nämlich der Mapper dann genau daneben den Note gesetzt hat und nicht und passt da nicht zusammen und hier habe ich jetzt künstlich ein bisschen rausgezogen damit man
sieht aber oft sind diese Nodes halt nur ein Millimeter nebeneinander so gefühlt und wenn man dann hier auf dieser Straße startet und hier runter wird dann muss man erst zu diesem Note rüber und dann runter und kann nicht direkt in Platz betreten das sind solche Sachen die ein bisschen ein Problem darstellen und vor allem wenn ich das prozessiere dann ist dieser Weg schon im Routing
drin vielleicht und ich kann den nicht mehr so also ich kann diesen Weg jetzt nicht mehr noch ran snappen oder es zumindest technisch momentan schwierig und das eben die Daten Qualität von OpenStreetWeb wo es halt manchmal gut ist manchmal nicht so gut muss man eben das jeweils lösen genau und dann noch eine Sache wo ich noch gar nicht mich herangemacht habe ist dann Relationen hatten wir vorher eh schon und die
sind halt teilweise sehr komplex also hier ist irgendwie Säge weg bei Donau Eschingen da habe ich mich völlig erschlagen dass es sowas gibt so ein riesen Polygon Multipolygon und hier jetzt hier ist vielleicht ein bisschen normaler dass der Bismarck Platz in Heidelberg wo dann hier ein Gebäude ausgeschnitten ist und da es eben die Daten Struktur
ein bisschen komplizierter beim Passen muss ich mir dann quasi erst mal selber das Multipolygon wie zusammen setzen es geht auch aber muss man eben machen und dann ist eben so dass die ganzen Ways aus denen diese Relation besteht oft schon im Routing Grafen drin sind und ich sie nachträglich nicht mehr bearbeiten kann das heißt ich kann diese Anschlusspunkte jetzt nicht mehr diese Ways
reinsetzen und das kann man also das ist eben noch ein Problem das kann man wahrscheinlich auch technisch lösen aber halt wiederum macht alles komplizierte und meine momentane Idee ist dass man einfach einen kompletten Way oder eine komplette Außenlinie einfach noch mal separat rüberlegt das heißt man hat am Rand vom Platz hat man quasi zwei übereinander liegende
Linien und ich also ich muss erstmal testen wie das sich in der Realität eben wie das funktioniert und genau sind so mögliche Ansätze genau jetzt nur zusammengefasst also ich will hier das Routing über die Flächen machen Probleme sind die Daten Qualität von OpenStreetMap
dann das die Multipolygone machen noch zu schaffen und dann muss ich noch den passenden Algorithmus finden dass eben nicht zu viele Kanten produziert werden und auch die Rechenzeit nicht so hoch geht und dann noch ein Fernziel ist natürlich dass die Route die berechnet wird auch einigermaßen nah an der Route ist wie Leute laufen würden und genau
und wenn jetzt jemand Kommentare oder Fragen hat dann höre ich mich sehr freuen dazu Ich glaube wenn du den Graphhopper gefüttert mit den Datentütern vielleicht musst du eine OSM-File erstellen wo zusätzliche Nodes und Graphways eingefügt werden oder hast du das irgendwie in eine Graphhopper Datenhandlung gemacht? Also das ist so bei also prinzipiell habe ich einfach
mit Graphhopper kann man sich einen OSM-File durch passen lassen und ich habe quasi in diesem Passing Prozess eingegriffen und habe und da das filtern er filtert dann eben durch je nachdem ob es ein Way ist oder nicht und dann habe ich quasi mehr oder weniger wenn das ein Polygon ist dann füge noch zusätzlich
diesen Gritz Graph ein genau also quasi im Programm Ich habe nämlich in letztens bei meinem Rollstuhlrouting Projekt genau das selbe Problem gehabt mit Flächenrouting Wunderbares Routing bis auf die Flächen Ich habe dann, ich verwende die Open Source Routing-Machine für das Ganze und es gibt sicherlich auch mehr Routing-Algorithmen und die ideale Lösung wäre
eigentlich wenn es ein extraes Programm gibt wo es ein OSM-File nimmt die Flächen irgendwie die Wege zusätzlich bereichern und die dann in dieses OSM-File einfügt, dass sie von jeden Routing-Algorithmen verwendet werden kann Das wäre eigentlich glaube ich die ideale Lösung dann könnte man das mit jedem Algorithmen verwenden Das ist etwas was ich mir wünschen würde ich habe noch ein paar Anfänger selber was zum
Schreiben mit Gesture usw. aber die Rechnzeit hat mich dann natürlich getötet und der ideale Algorithmus wäre meiner Meinung nach indem man alle Eintrittspunkte auf einer Fläche nimmt z.B. alle Gebäudeeingänge, alle Übergänge zu Straßen und von denen aus jeden möglichen Routen quer, also ich habe das so gemacht
dass ich zusätzliche Wege reingelegt habe von jedem Punkt zu jedem Punkt also von jedem Eingangspunkt der Sinn macht weil irgendeine Hauswand die sich vorbeischlägt wenn man den sehr rund macht es keinen Sinn da runter wegzuberechnen weil das ist ja auch kein Eintrittspunkt bei Konvexen würde es durchaus Sinn machen wenn man z.B. um einen rum und rum
etwas zu berechnen aber bei allen konkafen Knoten die kein Eintrittspunkt sind die habe ich gleich mal rausgeschrieben und dann würde ich dann soweit kommen dass es ideal wäre alle Kanten reinzuwenden und dann einen Routing-Algorithmus von jedem Eintrittspunkt zu jedem Austrittspunkt und die Kanten zu behalten die eben auch
im Endeffekt mit irgendeiner Route verwendet werden und alle anderen wieder rauszuwerfen das Programm müsst ihr noch jemals schreiben ja genau das ist eine gute Idee das habe ich mir auch schon überlegt und momentan ist es einfach erst mal zu testen mit Grafhaber aber das in jeden Fall in projektlosen Zukunft in jeden Fall interessant wäre genau und das mit dem nachträglichen rausfiltern das eben auch macht auf jeden
Fall Sinn dass man nicht irgendwie tausende Visibilität also diese Sichtverbindung hat weil die ja auf der Ebene nicht das Ziel führen sind ja ich bin eben gerade auf das Problem gekommen wenn auf einen Knotenpunkt mehr als 10-15 Wege weggehen die Open Source Routing-Maschinen mit ihrem Contraction Hierarchies hat ein wahnsinniges Kohlen damit also sobald da mehr als 10-15 Wege aus einem Knoten weggehen geht die
Rechenzeit exponentiell nach oben und man kann es eigentlich vergessen ok ich glaube hinten war es der ich wollte so anmerken muss werden was hast du da dein Ansatz ist ja jetzt auch das was der mir gesagt hat ist praktisch so wie Versuchung mal weil wir die Rechen nicht umgehen können
versuchen wir die Rechen auf Kanten runter damit können wir umgehen und dann ist alles gut genau das ist das was ich denke eigentlich ist es ein bisschen schade ich hab mal vor 2-3 Jahren auf der SOTN-OS habe ich so einen Film gesehen von einem Vortrag den da einer gemacht hat da hat er über einen Algorithmus gesprochen der praktisch bitmap-basierend
Routing über Flächen hat also du bist praktisch das Problem dabei ist du kannst da nicht einfach einen kantenbasierten Algorithmus benutzen du musst dafür echt einen extra anderen Algorithmus nehmen weil der funktionierte halt so dass er gesagt hat ok ich rastere diesen so wie es beim Wenden auch passiert ich rastere diesen Platz auf
den keine Ahnung und dann machen wir ein Pixel und ich befinde mich jetzt an diesem Pixel ok gut welche Nachbarpixel kann ich betreten wenn da jetzt irgendwo ein Haus ist oder ein Springbrunnen dann kann ich den Pixel nicht betreten wenn da auch so grau ist sozusagen dann kann ich den betreten und dann hat er praktisch wie so ein Flagspiel-Algorithmus im Grafikprogramm
halt versucht auf die Weise den nächsten den besten Weg zu finden das fand ich eigentlich ziemlich cool an weil ja natürlich kann man das machen
daraus dann wiederum nachher das führt aber dann dazu dass du keinen Routen mehr machen kannst zu bestimmen so macht es jetzt der Micherdemain gesagt dass du alle denkbaren Ein- und Ausschnittspunkte in den Platz nimmst und das Kanten dann hier
und du hast dann jetzt die gute Aufgabe ok ich will aber jetzt diesen Punkt auf den Platz hin routen oder ich stehe an diesem Punkt auf dem Platz mit und gehe weg dann musst du sozusagen im Augenblick erst auf der nächsten Kante finden bei so einem kleinen Platz, wo die Luftlinie hängen aber eigentlich wollten wir ja gerade weg von diesen Luftlinien hier irgendwo hin sondern wir wollten, dass der Algorithmus einen
den letzten Weg finden kann auch wenn man eine Umgebung noch hat also diese Mitnetzzahne fand ich ganz spannend aber ich hab nie versucht das zu implementieren und ich glaube das insbesondere schwierige ist dass man ja dann so eine Art Übergabepunkt braucht zwischen irgendwas wie Grafhauern wo ich dann irgendwie längeren Fußweg in der Stadt treche und dann füllen durch so einzelne Plätze
wo ich dann irgendwie so einen Mitnet Algorithmus ansprechen müsste aber an den Händen ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ... Algorithmen nehmen kann und eben halt den Algorithmus nicht neu schreiben, aber das wäre natürlich auf jeden Fall eine Idee, dass man quasi diesen in den
Algorithmus selber reingeht. Das wird zielführender, eben lösen. Das stimmt ja. Genau, denn der nächste. Ja, bei mir geht es eigentlich in dieselbe Kerbe. Es hat mich eigentlich irgendwie wundern, dass wir jetzt so weit suchen müssen. Ich hätte mir irgendwo gedacht, dass es in der großen, weiten Grafikwelt
eigentlich schon sowas gibt. Dass man das nicht nochmal neu finden muss. Dass die Leute, die ja so jetzt was weiß ich, irgendwo hinkriegen, oder dass in den kleinen Programmen da schon so Werkzeuge drin sind. In der Grafik ist das ja eigentlich nicht ein Problem.
Das könnte so gut sein. Ja. Ja, genau. Ja, genau. Man hat aber... Also es hat... Die gibt es da schon eine Menge, Album. Er hat ja auch drei vorgestellt. Ja, das hat mich irgendwie wundert, dass man überhaupt danach suchen muss. Genau, ja. Da gibt es schon was, was in Prinzip genau das macht.
Ja doch, das muss man auf jeden Fall nochmal schauen. Ja, das ist ein guter Punkt, ja. Genau, da war noch eine Anmerkung. Ja, bitte. Ich sage jetzt mal, abhängig von dem akademischen Nutzen dieser Forschungsarbeit, welchen Nutzen siehst du da drin?
Ja, man kriegt halt bei speziell für Fußgängerrouten halt bessere Routen. Vor allem schließt man aus, dass man eben falsche Routen bekommt, wie bei dem Beispiel da am Anfang, dass man sowas eben vermeidet. Also wenn man jetzt in der Stadt sich nicht auskennt, dann kann es eben sein, dass man diese komische falsche Route geroutet wird.
Das ist schon eher schon klar. Ich sage mal, so ein Platz ist ja aber in der Regel so gespeichert, dass man immer als Fußgänger entweder rüberkehren kann oder halt nicht. Das siehst du in dem Augenblick, wo du vorerst jetzt deine Routen nicht ausverrungen von deinem Computerprogramm vorgeweckt kriegst, dann ist dir von vornherein klar, der macht dann Fehler. Wenn du diese Zickzack-Linie so wie du es dann in deinen verschiedenen Ansätzen ausrechnest,
ist dir auch sofort klar, da stimmt irgendwas nicht. Das ist die menschliche Entscheidung vor Ort, die du fällst. Also richtig praktisch ist das eigentlich glaube ich nicht. Es gibt da weiter das Problem hinzu. Der Rechner ist die schnellste Route von Punkt A nach Punkt B. Wenn jetzt unser Platz in der Mitte ist,
ist die schnellste Route nicht mehr die durch, sondern außenrum. Da könnte es sein, dass er die kompletten Wege und Kilometer wegschiebt, weil in der Mitte auf der schnellsten Route irgendwie so ein Zickzack-Linie ist. Das heißt, die schnellste Route ist dann nicht mehr die schnellste. Das ist das Problem. Es ist auch so, wenn du so große Campus-Anschaustagen von Universitäten, wo die Schüler praktisch Fahne durchkrampeln.
Das ist auch nicht immer die kürzeste Route, sondern das bildet sich einfach so, weil es der bequemste Weg ist, oder weil einfach alle gehen. Da nimmst du einfach den Weg, weil die Leute schon vorher gegangen sind, oder du nimmst den Weg abkürz, und dann bildet sich ein neuer Weg. Das ist nicht der kürzeste Weg, das ist der Weg, den alle gehen.
Naja, aber es gehen ja nicht alle draußen rum. Das ist einfach nur falsch. Ja, aber ich sage jetzt mal, wenn die Leute durch den Park durchgehen, dann werden sie auch nicht die direkte Linie nehmen, sondern die gehen halt irgendwie so eine leichte Kurve oder so. Das bildet sich halt dann so emotionierend heraus. Und da gehen einfach alle entlang. Ja, aber ich sehe das jetzt aus der Sicht des Touristen, der sich überhaupt nicht auszieht,
und der den Platz noch nicht einmal sieht und sagt nur so ein Roten Programm, gehe jetzt Straße links, rechts, links, rechts. In Wirklichkeit wäre aber gerade rechts, links, rechts das Kürzere. Weil halt jetzt der Roten Algorithmus da den Fehler gemacht hat und die Schreiken künstlich verlängert hat. Ja, ja, aber wenn ich das Tourist irgendwo hin, wenn jeder möchte, vielleicht auch mal einen kleinen Umweg in Kauf nehmen, wenn man das anschaut, es ist ein Park, wäre es in 10 Minuten durchgekehrt sein können, ja.
Ja, das ist vielleicht gut, wenn du auf Fuß gerätst, wenn du Rollstuhltourist bist, dann wirst du bitte die kürzeste Runde haben. Ja, das ist vielleicht ein Argument. Ja. Wenn es einen Weg gibt, ja. Ja, genau, noch ein kurzer Kommentar dazu. Also die ästhetische Route ist natürlich auch eine Sache. Gerade wenn man beim Platz entlang geht, dann geht ja wirklich keiner exakt am Rand vom Platz entlang,
sondern wahrscheinlich mit 2 m Abstand auf jeden Fall. Das ist so eine Sache, die man vielleicht auch noch einbauen könnte. Aber das ist nur als Zukunftsmusik, ja. Dann, ja. Meine Frage, man hat zuerst so Redrecks gesehen, waren das GPS-Spuren, wo dann irgendwo ein Fahrradständer in der Mitte war, wo dann mehrere Spuren hingeführt haben, oder war das nicht so richtig geworden?
Das waren Sichtlinien. Das waren Sichtlinien, okay. Also meine Frage. Das hier, oder? Über, das sieht mir genau aus. Also ob das sieht mir, also wir merken vor Ort die Buchbilder und so weiter, aber die kommerzielle Kartenindustrie, die kommerziellen Navigationssysteme, die verlassen sich jetzt immer mehr, habe ich das Gefühl,
auf GPS-Spuren, die übers auch kommerziell ankauft werden. Gibt es da eine Chance aus der Sicht der Buchbilder, dass wir auch ungefähr solche Daten erhalten können, und dass man dann so eine Dreckwolke sieht, wo also die meisten Fußständer sind,
oder sind es da, die eigentlich auch künftig, also die bei der Nutzverwaltung stehen? Weil dort geht es auch um autonomes Fahren, wo also dann sozusagen das Gesetz der Herde, dann oft auch für Routenwahl herangezogen wird. Diese Welt, habe ich das Gefühl, geht ein bisschen weiter.
Ja. Also mein Ansatz ist jetzt erst mal, nur mit dem bestehenden Open-Street-Nap-Daten-Flächen-Routing zu ermöglichen. Und das mit den GPS-Tracks, auf jeden Fall wäre interessant halt mal zu schauen, wie Menschen über Flächen überhaupt drüber gehen, aber ich habe da jetzt keine dazu, aber es wäre auf jeden Fall ein interessanter Forschungspunkt,
das zum haben. Und mit der Möglichkeit, GPS-Tracks hochzuladen auf Open-Street-Nap, da kann man durchaus ebenso Cloud-Bildungen sozusagen verfolgen, wenn genügend Datenmaterial im Hand ist. Das ist halt eine Frage der Qualität, wie gut sind da diese Daten? Wir haben jetzt nicht nur von Open-Street-Nap auf GPS-Tracks,
man sieht GPS-Tracks ja auch im Chosun, beim normalen runterlade Fenster, da gibt es rechts oben versteckten GPS-Tracks runterladen, und dann gibt es zusätzlich noch die GPS-Tracks von Michael-Lehrer, die man sich anzeigen lassen kann, und zusätzlich gibt es noch von Strava, das ist eben auch eine Firma, die teilweise mit Open-Street-Nap arbeitet, die haben einen eigenen ID-Editor, wo du so ein paar Tracks auf den mittenwert von GPS-Tracks hinziehen kannst.
Und die kriegt man sicher eigenbar. Wahrscheinlich ist das eine Kombination aus solch einer Arbeit, aus einer Datenwolke, an GPS-Tracks, und dann vielleicht auch noch mitischen Vorgaben, wo man sagt, wie man will, zu gewisser Zeit,
zu gewissen Tageszeitungen, den Strom, den Verkehrssprung, den Fußgängerstrom, vielleicht nicht gerade zu diesem Punkt hinlosen, sondern irgendwo zieht, vielleicht in eine andere Rute ein bisschen aus, weil es dort vielleicht einen Stau gibt, dass mit einer gleichen Umgehung
es da möglich wäre, dass es dort zu einer verkehrstechnischen Verbesserung kommt. Also da gibt es keine vielen Faktoren, was da noch einpissen könnten in solch einer Arbeit, wo das ein Aspekt ist, solch eine Arbeit, dass man versucht, das perfekt zum Unteren von anderen Faktoren noch wieder einpissen kann,
und so eine Art Form von Routine. Ja, das ist ein guter Punkt. Ich kann mir vorstellen, dass bei so großen touristischen Plätzen ist ja ganz viele Menschen irgendwie, dass man da vielleicht nicht direkt durch will, sondern eher in eine andere Rute, aber das ist dann quasi der zweite Schritt. Also wenn es mal funktioniert, dann kann man das nachträglich immer noch einbauen mit diesen Metadaten. Aber das ist auf jeden Fall ein guter Punkt, wo man sich noch Gedanken machen kann, ja. Könnte ihr eigentlich diese Arbeit hier auch noch
zugelüßen, um gewisse Selzige-Routen zu optimieren, wo gewisse Punkte, also als Operationsroute, da steht da, dann wurde es das Programm machen, eine optimierte Route planen für den Touristen, wo die möglichst viele interessante Plätze auf gutem Wetter reichen. Ja.