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

OSM Datenformate für Anwendungen

00:00

Formale Metadaten

Titel
OSM Datenformate für Anwendungen
Untertitel
Der Weg zu verlustfreien Vektor-Tiles
Serientitel
Anzahl der Teile
68
Autor
Lizenz
CC-Namensnennung 3.0 Deutschland:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Wie selbstverständlich haben wir uns daran gewöhnt, OSM-Daten speziell für den jeweiligen Anwendungszweck aufzubereiten: OBF, GHZ, MVT, PNG, PBF, IMG, MAP, RD5, HGT … Ein frischgebackener OSM-Anwender, der naiv fragt, wo er denn OSM-Daten laden kann, um all die tollen Sachen zu machen, die man damit machen kann, am besten offline – er verläuft sich in diesem Dschungel. Dieser Vortrag will zweierlei erreichen. Zum einen diesen Dschungel sichten. Was sind die einzelnen Anwendungsfelder, von A wie Adress-Datenbank bis Z wie Zoom-Level? Was sind die gängigen Lösungen, was sind ihre Download-Größen, ihre Beschränkungen und ihre Lizenzen und wie spielt das alles zusammen? Im Anschluss will dieser Vortrag hinterfragen: Warum ist das alles so, und muss das so bleiben? Beispielsweise erlaubt OsmAnds OBF-Format zwar viele Funktionen gleichzeitig, wie Routing, Rendering, Adress- und POI-Suche. Belegt dafür aber mehr Speicherplatz als seine Quelldaten, die üblicherweise im PBF-Format ausgetauscht werden. PBF besitzt keine Indexierung und ist daher für Random Access nicht geeignet. Auf der anderen Seite erobern Vektortiles den Desktop-Client, die es mit der Trennung von Datenzugriffs- und Präsentationsschicht wieder nicht so genau nehmen. Also warum kein gekacheltes, indexiertes PBF-Equivalent, das einfach alles kann? Vom Routing bis zur Overpass-API? Also "verlustfreie", oder besser verlustarme Vektortiles, mit dem vollem Informationsgehalt? Das alte Gegenargument, also die technischen Beschränkungen der Client-Hardware, die es erforderlich machten, OSM-Daten für den jeweiligen Anwendungsfall aufzubereiten, will dieser Vortrag über Bord werfen.
Schlagwörter
1
Vorschaubild
13:04
24
39
58
59
Vorschaubild
36:34
VektorVoting <Programmierung>DatenformatAnwendungssoftwarep-BlockSmartphoneComputeranimationVorlesung/Konferenz
RoutingBerechnungMathematikAnwendungssoftwareART-NetzSoftwareRouterRoutingCASE <Informatik>Vorzeichen <Mathematik>TypentheorieComputeranimationVorlesung/Konferenz
ServerDesktopSoftwareRoutingQuick-SortSoftwareSmartphoneDatenformatAnwendungssoftwareKanteRechter WinkelEinsTouchscreenVorlesung/KonferenzComputeranimation
MAPDesktopSoftwareLösung <Mathematik>RoutingSmartphoneAnwendungssoftwareFlächentheoriePunktRouterKanteNetzwerk <Graphentheorie>LängeSoftwareMomentenproblemArithmetische FolgeCASE <Informatik>Mooresches GesetzDickeDreiecksfreier GraphComputeranimation
RoutingAnwendungssoftwareRouterDownloadingComputeranimationVorlesung/Konferenz
Klasse <Mathematik>SmartphoneNachlauf <Strömungsmechanik>KanteComputeranimation
DownloadingNetzadresseChipkarteRoutingDateiRichtungRouterEnde <Graphentheorie>Vorlesung/Konferenz
TabelleMengeRoutingMultiplikationsoperatorRouterComputeranimation
DatenparallelitätLängeMathematikRouterRoutingComputeranimation
DateiDickeSchwellwertverfahrenWeg <Topologie>RoutingPunktMultigraphInformationLängeKanteComputeranimation
RoutingDesktopPolygonAnwendungssoftwareDesktopGraphUpdateRoutingDatenformatMobiles EndgerätAggregatzustandFlächeKanteMeterRouterAlgorithmusSoftwareGraphfärbungAlgorithmische ProgrammierspracheBus <Informatik>FlächeninhaltEinfach zusammenhängender RaumLokales MinimumWorkstation <Musikinstrument>VirtualisierungAbstandVorlesung/Konferenz
RoutingDesktopStreckeDateiGraphMAPPERComputeranimation
RouterDownloadingHumanoider RoboterRouterRoutingParametersystemAttributierte GrammatikMAPWorkstation <Musikinstrument>MereologieWeg <Topologie>Office-PaketVorlesung/Konferenz
RouterDownloadingHumanoider RoboterGEDCOMStatistikDownloadingKanteDickePhysikalische GrößeRouterOffice-PaketMeterRoutingDatenformatFaktorisierungDiagramm
BeweistheorieMetadatenQuellcodeKoordinatenVersion <Informatik>Filterung <Stochastik>AnwendungssoftwareFaktorisierungWeg <Topologie>ZählenSchätzung
KoordinatenAnwendungssoftwareZeitstempelMetadatenRouterRoutingSichtenkonzeptPunktZeichnung
BeweistheorieMetadatenQuellcodeKoordinatenVersion <Informatik>VariableBridge <Kommunikationstechnik>GRADEDatenformatZeichnung
Innerer PunktDatenmodellPolygonWendepunktMultiplikationsoperatorLeistungsbewertungRechenbuchFehlermeldungSichtenkonzeptRoutingAlgorithmusInverser LimesKontrollstrukturResultanteHierarchische StrukturDesign by ContractDatenbankNetzadresseObjekt <Kategorie>ZugriffListe <Informatik>AnwendungssoftwareDatenmodellHomepageComputeranimation
WendepunktDatenmodellRoutingSoundverarbeitungFehlermeldungMultiplikationPolygonNoten <Programm>KoordinatenPerspektiveNetzwerk <Graphentheorie>Element <Gruppentheorie>SchwellwertverfahrenVorlesung/KonferenzComputeranimation
ZoomDatenmodellInformationChipkarteMultiplikationsoperatorComputeranimation
ZoomDatenbankChipkartePolygonFreier LadungsträgerDatenmodellAchse <Mathematik>KoordinatenSummeInformationBefehl <Informatik>ZahlenbereichVektorpotenzialRoutingKategorie <Mathematik>Endliche ModelltheorieSchaltnetzPunktSchwellwertverfahrenMultigraphExtreme programmingDickeWasserdampftafelRFIDSoftwareKanteRouterLängeKennzahlMengeExtremwertVorlesung/Konferenz
ZoomRoutingBitAnwendungssoftwareRouterComputeranimation
ZoomHANS <Datenbanksystem>APIDatenformatDemoszene <Programmierung>RouterEbeneVolumenvisualisierungObjekt <Kategorie>Wald <Graphentheorie>DatenformatMultiplikationGebiet <Mathematik>PDF <Dateiformat>PolygonDateiformatMAPDesign by ContractHierarchische StrukturSchnelltasteMultiplikationsoperatorKnoten <Statik>InformationOrdnung <Mathematik>RoutingResultantePunktKontinuumshypotheseNeuroinformatikMaßerweiterungSoftwareZahlenbereichMeterFehlermeldungUnrundheitGraphKategorie <Mathematik>AlgorithmusRuhmasseKanteRechenzeitKennzahlRouterNetzwerk <Graphentheorie>Vorlesung/Konferenz
Demoszene <Programmierung>RouterVektor
Herzlich willkommen zum ersten Block am heutigen Tag. Das Thema der ersten drei Vorträge ist Rooting und Roland wird uns zuerst einen mathematischen Zugang zu diesem Thema vorstellen.
Bitte etwas 20 Minuten. Danke für die Gelegenheit hier vorzutragen. Also allzu mathematisch wird es nicht. Eigentlich habe ich die halbe Nacht damit verbracht, Mathematik rauszuschmeißen, weil das die Leute eher quält. Aber ihr seid natürlich frei, nach Details zu fragen. So, wir versuchen es mal einen anderen Zugang zu machen. Und zwar Anlass dazu war, dass ich mal praktisch das Radrouting ausprobieren wollte und habe festgestellt, es gibt drei Arten von Fahrradrouten.
Es gibt die ausgeschilderten. So, Schild führt zu Treppe.
Dann gibt es die tatsächlich Gefahrenen. Wissen wir nicht welche. Und die, die unser Router findet, der nämlich vorsorglich, in dem Fall Mepsen, vorsorglich um die Treppe drumherum routet. Und die Frage war jetzt eigentlich, wie sind die von uns gerouteten Routen? Sind die eher wie die ausgeschilderten oder sind die näher an den tatsächlich Gefahrenen?
Und was können wir überhaupt schaffen? Das heißt, es ist anders gefragt, welche Kanten sind fürs Nicht-Pkw-Routing wirklich wichtig? Wir sehen hier auf dem Bildschirm die Straßenkanten sehr schön hervorgehoben.
Beim PKW ist es nämlich einfach. Da gibt es das übergeordnete Straßennetz. Und im Grunde genommen, wenn man aufs übergeordnete Straßennetz gefasst hat, hat man alles richtig gemacht. In der Regel werden 90% oder 99% aller Routen so aussehen, dass man nach ein paar Kilometern auf einer Primary oder Autobahn ist. Und die fährt bis ein paar Kilometer vor das Ziel.
Beim Fahrrad wissen wir es nicht. Wir hatten tatsächlich in dem Fall dienstlich innerhalb von Menz eine große Diskussion, ob eigentlich, wenn man so deutschlandweites Fahrradrouting macht, dann tatsächlich jede Kante irgendwie ein Weg auch drin ist, weil das quasi so Schritt für Schritt über Deutschland wandert, die Wege. Oder ob es im Prinzip wieder dezidierte Wege gibt, auf denen das meiste abläuft. Also ob es quasi im Routinggrafen ein verstecktes Hauptverkehrswegenetz gibt.
Nicht unbedingt das ausgeschilderte, wir haben ja schon gesehen, da werden auch gerne mal Treppen ausgeschildert, die kein Router freiwillig nimmt. Ob es im Radverkehrsnetz, also ob es im Netz aller Radwege ein verstecktes Hauptverkehrsnetz gibt, auf das die Router bevorzugt schnappen. Stellt sich heraus, eine relativ schwierige Frage.
Man muss nämlich erst mal herausfinden, was jetzt eigentlich dann genau ein wichtiger Weg in diesem Sinne ist. Ehrlich gesagt, an der Stelle bin ich auch noch nicht so richtig weit vorangekommen. Ich habe mich jetzt erst mal auf das Fußgängerrouting und kleine Flächen zurückgezogen, weil momentan mache ich es relativ plump, nehme einfach einen Dykstra und mache Buchführungen darüber, welche Wege benutzt werden.
Und das geht, wenn man einen Dykstra auf allen Punkten eines Netzwerks macht, kommt man momentan mit der Rechenleistung hier nur für eine Stadt durch. Da muss man noch mal rangehen und ein ordentliches Pruning machen. Aber es geht jetzt erst mal um die Frage, ob das überhaupt was bei rauskommt. Der erste Versuch war, zu jeder Kante einfach die Länge der längsten Route, die dort verläuft.
Das führt nicht so weit, wie man gerne eigentlich möchte, weil wir gucken uns mal zum Beispiel diese Kante hier an. Dann kann ich problemlos eine beliebig lange Route hier finden, weil hier ist die Sackgasse zu Ende. Wenn ich hier hinten starte, werde ich zu einer Route, egal ob ich zur Stadtgrenze oder bis ans Schwarze Meer route,
werde ich immer über diese Kante gehen. Das heißt also, das ist überhaupt kein sinnvolles Kriterium zu sagen, ich nehme mir die längste Route, die über einen Weg führt, weil jeder Weg wird von einer beliebig langen Route benutzt werden. Der zweite Versuch, ein generelles Kriterium zu kommen, wie ich einer Kante ansehe, ob sie wichtig ist, war,
ich schaue mir nach, welcher Weg hat sowohl einen langen Vorlauf, also quasi nach Norden raus, als auch einen langen Nachlauf. Es ist immer noch nicht wirklich hilfreich, man schmeißt solche Sackgassen, wie wir sie gerade eben hatten, die schmeißt man raus, weil die in eine Richtung gibt, kommt man halt nicht mehr weit, da ist Schluss.
Aber es gibt diese Nebenstraßen, die, wenn ich knapp in der Nähe davon starte, in die eine Richtung benutzt werden können. Hier komme ich im Grunde genommen bis zum Atlantik, wenn ich das möchte, kriege ich hier also sehr große Werte rein. Oder hier käme ich im Grunde genommen bis zur Ostsee und würde hier auch große Werte rein kriegen, wenn ich das wollte.
Das heißt also, wir haben hier mit solchen Nebenstraßen, die an beiden Enden im obergeordneten Straßennetz hängen, kriegen wir auch wieder kein sinnvolles Kriterium raus. Deswegen ein dritter Versuch, wir nehmen uns mal von jeder Route den Mittelpunkt der Route.
Also man bedenkt, dass es sehr, sehr viele Routen gibt, wenn ich sage, ich habe eine Million Kanten, dann habe ich dazwischen potenziell eine Million mal eine Million durch zwei, sind eine halbe Billion potenzielle Routen, die ich mir anschauen könnte. Und im Grunde genommen nehme ich mir jetzt hypothetisch davon alle Mittelpunkte. Man sieht schon, dass man anschließend Mathematik braucht, weil man nicht mit einer halben Billion Mittelpunkten arbeiten möchte.
Aber im Prinzip suchen wir also jetzt, wir halten jetzt von jeder potenziellen Route den Mittelpunkt fest und uns interessiert zu einer Kante, was ist die Länge der längsten Route, deren Routenmittelpunkt, oder ich nenne es später Scheitelpunkt, eigentlich sollte da auch Scheitelpunkt stehen,
was ist die Länge der längsten Route, deren Scheitelpunkt auf diesem Segment oder dieser Kante liegt. Und es stellt sich heraus, damit kriegt man tatsächlich eine interessante Information über Kanten. Das wollen wir uns jetzt in ein paar Beispielen mal anschauen.
Also erst mal zum hübschen Anschauen und zum Erklären, wie die nachfolgenden Grafiken funktionieren. Das ist jetzt der Bahnhof, bei mir fast zu Hause, in Oberbahn. Und da gibt es im Grunde genommen eine Fußgängerüberführung abseits der Gleise und einmal den Bahnhofstunnel. Und wir haben hier also fast ein sternförmiges Netz mit irgendwie diesen beiden alternativen Verbindungen.
Die Farben sagen jetzt etwas darüber hinaus, sagen es etwas darüber aus, wie lang die längsten Routen sind, deren Mittelpunkte auf der jeweiligen Kante liegen. Das sind Meterangaben, die die Farben anzeigen. Und das heißt also zum Beispiel jetzt für diese blauen Wege, auf so einem blauen Weg,
ist die mindestens gemessene Entfernung 540 Meter. Und das heißt also die längste Route, die über so einem blauen Weg verläuft und deren Mittelpunkt auf der Kante liegt, ist mindestens 1080 Meter lang und für die anderen Farben entsprechend weniger. Aber das Grau ist das Unauffälligste, da liegen die kürzesten Routen drauf.
Und man sieht jetzt schon sehr schön vom Verfahren her grundsätzlich funktioniert das. Bei diesem fast sternförmigen System landen die wichtigsten Routen hier in der Mitte, wo ich auch auf jeden Fall durch muss. Und man fängt auch schon an, die ersten Details zu sehen. Zum Beispiel hier ist ein ganzer Busbahnhof, den kann man jetzt schlecht sehen. Und hier ist ein ganzer großer Vorplatz mit virtuellen Wegen über die Fläche. Und das Ding selektiert schon sehr schön heraus,
wie man hier an der richtigen Stelle über den Busbahnhof kommt und an der richtigen Stelle über die Fläche kommt. Die anderen Wege, die man hier, ich fürchte nur angedeutet, sieht, werden von dem Algorithmus schon selbstständig aussortiert. Gleiches hier mit dem Parkplatz und so weiter. Es ist noch keine Kunst, aber es zeigt uns, dass das Verfahren grundsätzlich funktionieren könnte.
Und jetzt wollen wir uns mal angucken, ob wir damit was über Passau lernen können. Wir hatten zum Beispiel eine heiße Diskussion. Das ist zwar jetzt eine Frage, die mich schlussendlich privat umtreibt, aber der Anlass war ein dienstlicher, weil wir hier mit den örtlichen Mappern aussortiert haben, wie wir jetzt eigentlich genau die Situation rund um Passau mappen wollen.
Insbesondere die Frage, ob dieser Poststeg eigentlich ein kleiner Bestandteil des Bahnhofs ist. In dem Fall ging es darum, ob wir einen Levelattribut dann kleben können, weil wir den Bahnhofsplan drin haben wollten. Die Frage ist, ist das irgendein Ding, was im Wesentlichen zum Bahnhof gehört und für die Stadt keine Rolle spielt? Oder ist das eventuell ein ganz wichtiger Fußweg für die Stadt?
Das können wir jetzt einfach nachgucken. Die Kante ist hier, die Kante ist blau. Das sagt uns also aus. Es muss ziemlich lange Wege geben, die über diese Kante verlaufen. Es gibt hier den Mittelpunkt einer 8 km lange Route,
mit deren Mittelpunkt auf dem Poststeg liegt. Das heißt, wir wissen also jetzt aufgrund dieser Berechnung, dass der Poststeg eine ganz wichtige Rolle spielt für das Routen. Wir müssen es gar nicht groß auf die Suche machen. Gibt es da was?
Sondern wir wissen jetzt, dass der Poststeg eine große Rolle spielt. Zweites Beispiel. Ich frage mal ins Publikum rein. Wir sehen hier so über den Daumen gepalt 50, 60, ich habe es nicht genau nachgezählt, Straßen hier auf dieser Halbinsel von der Altstadt Passau.
Wie viele davon sind wirklich für das durchgehende Fußwegrouting interessant? Ich möchte mal kurz Schätzungen hören. Okay, wir haben 2,25 geboten. Und jetzt schauen wir mal nach.
Macht er das? Nein, macht er nicht. So, jetzt macht er das. Es gibt tatsächlich im Wesentlichen das eine Ufer, das andere Ufer und quasi einen Weg, mit dem man von der Inn auf die Donaubrücke kommt. Und der ganze Rest der Altstadt ist im Grunde genommen nur Anlieger.
Aus Sicht des Fußgängers ist es eine reine Anliegerstrecke. Da wird der Router nur rein routen, wenn man auch sein Ziel da hat. Man sieht sogar sehr hübsch die Tatsache, dass hier der Weg nicht direkt kreuzt mit der Brücke, sondern dass man hier diese Umwegung hat, wo man von der Brücke erstmal runter muss, sorgt dafür, dass es attraktiv ist von der Brücke stattdessen einen anderen Weg durch die Altstadt zu nehmen,
die sich erst hier kurz vor der Donaubrücke wieder treffen. Aber im Grunde genommen könnte man den Leuten hier sagen, wenn ihr über den Inn wollt, geht hier geradeaus. Wenn ihr am Inn entlang wollt, biegt hier links ab. Und alles andere danach passiert nicht mehr. Und diese Straßen sind eigentlich, wenn man jetzt mal reinguckt nochmal in den Plan,
sind total unauffällig, aber leicht zu finden. Also insofern herzlichen Glückwunsch an diejenigen, der zwei getippt hat. War schon ziemlich nah dran. Die fünf waren auch ziemlich gut. Ich hätte ehrlich gesagt persönlich auch eher mit den zwanzig gerechnet. Insofern war ich da sehr überrascht, dass man ein so klares Ergebnis kriegt.
So, bevor jetzt alle Leute aufbrechen und sagen, das ist jetzt der nächste große heiße Scheiß. Also die Berechnungszeit ist so langsam, dass man derzeit kaum eine Stadt schafft. Das heißt also, das ist nicht dafür gedacht, dass man das als Routing-Algorithmus benutzt. Also vielleicht findet jemand irgendwas geniales, aber eigentlich mit den Contraction-Hierarchies
ist man so schnell, dass man ganz Deutschland mit einer Stunde Vorberechnungszeit nachher mit einer halben Sekunde oder weniger zum Radrouten machen kann. Das heißt, da gibt es auch wenig Bedarf, da noch weiter zu optimieren. Aber ein großes Thema sind Routing-Fehler. Es gibt eine Debugssicht der diversen Routing-Tools. Die ist auch echt gut für die Fehlerbeseitigung, weil die findet nämlich solche Sachen,
die zeigt einem solche Sachen an, wie die Bewertung durch die Geschwindigkeitsbegrenzung zustande kommt oder auch wo Löcher in den Inseln sind. Und das heißt also mit dieser Debugssicht, wenn ich einen Fehler habe, hilft das Tool ziemlich hilfreich,
um den Fehler auch zu finden und beseitigen zu können. Was ich damit nicht machen kann, ist die Fehlerfreiheit belegen. Und das ist das, wo eben dieses Tool dann auf einmal zu Hilfe kommt. Weil, wenn ich eben weiß...
Also wir waren stehen geblieben bei der Frage, wenn es darum geht, Fehler zu finden, wir haben ja gesehen, ich gehe nochmal auf die Folie zurück, die das betrifft, wir brauchen jetzt überhaupt nur noch diese zwei Wege anzugucken. Wenn die beiden Wege ordentlich geteckt und gemapt sind und für das Routing taugen,
dann haben alle anderen Fehler, die eventuell da sind, nur noch lokale Auswirkungen. Das heißt also, wir können hier, wenn wir uns die beiden Wege angeguckt haben, sagen, ok, Routing wird funktionieren, wir werden keine bösen Überraschungen erleben. Und insofern, das ist eigentlich das, wo ich den Zweck sehe, man kann jetzt aus den OSM-Daten tatsächlich Erkenntnisse gewinnen,
wo jetzt eigentlich die exponierten Elemente des Netzwerks stehen. So, und das ist auch das Fazit, was ich dann darüber ziehen möchte, nämlich die Routenscheitelpunkte liefern uns eine neue Perspektive auf die OSM-Daten, aber als Routing-Algorithmus sind sie weder gedacht, noch sind sie dafür geeignet.
So, dann sehe ich gerade, das Filmteam fluchen bin, aber ansonsten am Ende. Das heißt, wenn ihr noch irgendwie was reparieren sollt, sagt Bescheid. Gut, ok, dann danke ich für die Aufmerksamkeit.
Danke Roland für den interessanten Vortrag, wir haben jetzt ausreichend Zeit für Fragen. Warum jetzt der Scheitelpunkt der Route? Das scheint mir irgendwie total aus der Luft gegriffen zu sein,
gerade diesen einen Mittelpunkt der Route zu nehmen. Kann der nicht auch bei zwei Dritteln sein oder woanders? Oder müsste ich das nicht gewichten über die gesamte Länge der Route oder sonst irgendwas? Also nehmen wir mal das Extremum an. Nehmen wir mal an, wir würden den Punkt immer am Ende der Route nehmen. Dann sind wir exakt wieder in der Sackgassensituation. Dann habe ich nichts gewonnen, dann sehe ich genau die Sackgassen.
Und im Prinzip, je weiter ich mich von der Mitte entferne, desto uninteressanter wird die Information. Also sozusagen, der Mittelpunkt ist der Ort, weil der Anfang und der Ende sind langweilige Orte. Das heißt, der Mittelpunkt wäre der Ort, der maximal weit von den langweiligen Stellen entfernt ist. Und ansonsten, das ist jetzt nur ein Ansatz gewesen, der funktioniert hat.
Im Grunde genommen steckt da eigentlich ein mathematisches Konzept hinter. Dass man versucht, eine universelle Eigenschaft zu finden, die nur an der Kante hängt und wo ich keine Punkte für angucken muss, relativ dazu. Wenn ich eine Route bilde, dann ist alles, was ich über diese Route herausfinden kann, relativ zu Start und Endpunkt.
Und eben weil es so viele Kombinationen von Start und Endpunkten gibt, gewinnt man damit noch nicht viele Informationen, wenn man sich so viel anschauen müsste. Man kann sowas machen wie Erreichbarkeitsgrafen oder eben auch, es gibt diese wunderschönen Bilder mit, ich weiß nicht, wie es amtlich heißt, also funktioniert im Prinzip wie eine Wasserschalte, dass ich quasi zeige, über welche Wege ich irgendwo hinkomme.
Da hänge ich aber immer noch von einem Punkt ab, egal ob ich einen Start oder einen Zielpunkt wende, überlege. Und dann habe ich immer noch im Prinzip jeden Punkt des Netzwerks, zu dem ich relativ denken muss, zu dem ich die Kante zuweise. Dann habe ich immer noch viel zu viele Informationen zu einer Kante. Erst wenn ich das runterbreche auf eine Eigenschaft, wo ich eine Aussage über die Kante treffe, ohne eine Aussage über irgendeinen Punkt zu machen, wird es in dem Sinne interessant, dass ich sage, ich gewinne Erkenntnis über die Kante.
Nur dann habe ich eine handhabbare Menge Informationen. Und dass man jetzt Mittelpunkte dafür nimmt, das war jetzt mehr technisch, weil es gut greifbar ist und weil es auch nachher den Leuten erklärbar ist. Im Grunde genommen, man könnte auch hergehen, man könnte ein Potenzial definieren, zwischen welchen Orten wahrscheinlich Routing ist und anschließend berechnen, wie stark eine Kante von Routing belastet ist.
Damit könnte ich im Prinzip sogar ein Prognosemodell machen, wo wie viel Verkehr fließen wird. Aber dann sind wir natürlich schon in einem ganz anderen Aufwandsbereich. Das ist einfach unter all diesen universellen Kriterien, wo ich sage, ich schmeiße die Maschine an, und am Ende fällt eine Kennzahl über eine Kante raus, pro Kante. Es ist das einfachste Kriterium.
Ich glaube, was der Jochen andeuten wollte war, wenn du ein ganz kurzes Segment hast, ist die Wahrscheinlichkeit, dass dieser Mittelpunkt von den Routen gerade knapp daneben ist, relativ groß, und deswegen wird das kurze Segment irgendwie weniger bewertet als ein längeres, was aber eigentlich keinen Sinn macht.
Ich könnte mir vorstellen, dass das ein bisschen das Problem ist. Okay, dann sollten wir das vielleicht nochmal richtig stellen. Ich route von jedem Punkt, nicht jedem Knoten des Netzwerks. Das heißt, ich schaue mir das ganze Continuum von Punkten auf der Kante an. Das heißt also, wenn jetzt ein Mittelpunkt knapp daneben liegen würde, dann kann ich ja im Prinzip, dann gibt es aber auch einen Mittelpunkt, der auf der Kante liegt,
weil ich ja nämlich statt an dem Knoten anzufangen, an dem mein knapp daneben Routen startet, kann ich einfach die ersten zehn Meter vom Weg weglassen und da starten. Und schwupp liegt ein Mittelpunkt auch auf der kurzen Kante.
Du hast da von Contraction-Hierarchies gesprochen, und jetzt ist meine Frage, ist nicht, wenn ich eine Contraction-Hierarchie ausrechne, das Level, was an dem Shortcut steht innerhalb der Hierarchie, auch genau so ein Maß, was du suchst für die Wichtigkeit an der Kante? Also zunächst einmal ist es natürlich frei, beliebig viele weitere Maße zu definieren, aber ich hatte mit den Contraction-Hierarchies auch gearbeitet,
weil wir ja tatsächlich auch Routing-Ergebnisse gebraucht haben. Und es ist so, man ist bis darauf, dass man mit extra Rechenzeit bestraft wird beim Aufbau, kann man sich fast beliebig dämlich bei den zu kontrahierenden Kanten ausstellen. Eine gewisse Fehlerquote, wenn ich fünf Prozent der Knoten ungünstig wähle beim Kontrahieren,
dann komme ich immer noch durch, dann kriege ich immer noch einen Grafen, der sowohl von der Vorberechnungszeit, der erträglich ist, als auch von der Handhabbarkeit. Das ist eigentlich ein Feature von Contraction-Hierarchies, dass es einen Fehler bis zu einem gewissen Ausmaß verzeiht. Das sollte man nicht unterschätzen. Aber dadurch kann man diese Informationen nicht mehr so scharf gewinnen.
Es ist eben keine intrinsische Eigenschaft mehr der Kante, sondern es ist das, was der zum Kontrahieren verwendete Algorithm ist. Dann muss ich ja wählen, in welcher Reihenfolge ich die Knoten kontrahiere. Das ist etwas, was mir eine Information über diese Reihenfolge und die Kante aussagt und nicht nur über die Kante alleine. Da bin ich wieder in einem Problem, dass ich sehr, sehr viele Kennzahlen habe,
weil ich ja eigentlich potentiell jede denkbare Reihenfolger betrachten müsste. Also insofern würde ich sagen, da ist die Information nicht so scharf, wie bei diesem Kriterium, wo nur eine Kennzahl rauskommt. Gibt es weitere Fragen?
Wenn es keine weiteren Fragen mehr gibt, bitte noch einen Applaus für Roland.