Ich beschäftige mich gerade ein wenig mit brouter und speziell mit den Profilen für den brouter. Den Text hier habe ich gelesen und im groben auch verstanden
Nun versuche ich bestehende Profile zu verstehen und stoße auf ein paar Probleme.
Gibt es hier Leute, die mir bei den Profilen weiterhelfen können? Bin ich hier überhaupt richtig? Wenn ich es richtig gelesen habe, ist hier ja auch der Entwickler von brouter angemeldet, oder?
Das bedeutet doch, das hier für highway=track|road|path|footway die Kosten abhängig vom tracktype=gradeX und der Variable probablyGood gesetzt werden, richtig?
Also z.B. bei highway=track und tracktyp=grade3 und probablyGood=true wäre es 1.5
wenn probablyGood in dem Fall false wäre, dann 3.0
Trifft zwar highway=track zu, aber tracktype ist nicht gesetzt, würde der Wert abhängig von probablyGood entweder 1.0 oder 5.0
So verstehe ich es auch.
Das Konstrukt ist eher wie ein verkettetes if - then - else-
Den vorgestellten Operator gibt es in einigen Programmiersprachen, ist aber nicht unbedingt intuitiv verständlich.
Die erste Zeile wäre geklammert
if (highway=track or highway=road or highway=path or highway=footway) then
(if ( ...
...
else if (probablyGood) then 1.0 else 5.0) ...))
Die schließenden Klammern je nachdem wieviel öffnende Klammern man gesetzt hat (-> @Vinzenz_Mai ).
In den meisten Programmiersprachen hat man wegen der unübersichtlichen else-if-Struktur das eigentliche switch-Konstrukt, das auf etwas wie
switch (tracktype) {
1: if probablyGood then 1.0 else 1.3
2:
default: if probablyGood then 1.0 else 5.0
hinauslaufen würde.
Das nur zum (hoffentlich besseren) Verständnis.
Einen eigenen Parser zu bauen gehört ja nicht unbedingt zum Pflichtprogramm eines Router-Anbieters, das soll also keine Kritik an @abrensch sein.
ja, das ist richtig. Ich habe mich noch nie um das offline-Routing gekümmert, nur mit den Profilen des brouter-web gearbeitet. Dort sieht das wie folgt aus und ist vielleicht leichter verständlich:
#
# tracks and track-like ways are rated mainly be tracktype/grade
# But note that if no tracktype is given (mainly for road/path/footway)
# it can be o.k. if there's any other hint for quality
#
else if ( highway=track|road|path|footway ) then
(
if ( tracktype=grade1 ) then ( if probablyGood then 1.0 else 1.3 )
else if ( tracktype=grade2 ) then ( if probablyGood then 1.1 else 2.0 )
else if ( tracktype=grade3 ) then ( if probablyGood then 1.5 else 3.0 )
else if ( tracktype=grade4 ) then ( if probablyGood then 2.0 else 5.0 )
else if ( tracktype=grade5 ) then ( if probablyGood then 3.0 else 5.0 )
else ( if probablyGood then 1.0 else 5.0 )
)
Sprich: die Online-Profile können Dir eventuell helfen, das offline-Profil zu verstehen und Deinen Wünschen gemäß zu modifizieren.
Die dritte Zeile ist lediglich eine Bedingung, da muss noch was kommen, also dann so was wie if (oneway='') then (junction=roundabout) else if (oneway=yes or oneway=true or oneway=1) then ...
Ja, die if-then-else syntax habe ich irgendwann implementiert, und auch die Klammern, beides ist aber nur “syntactic sugar”, weil die Klammern sind immer optional, und "switch <boolean> <true-expression> <false-expression>" ist exakt identisch zu "if <boolean> then <true-expression> else <false-expression>"
Die Klammern sind zwar optional, aber wenn sie da sind werden sie auch daraufhin geprüft, ob sie tatsächlich einen vollständigen Ausdruck klammern, sie sind also durchaus nützlich… Wichtig das Spacing, eine Klammer muss also immer auf beiden Seiten ein Blank haben, das will der Parser so.
Hmm, ich seh das tatsächlich anders. Vielleicht kann @abrensch hier noch mal erklären wie der Code zu lesen ist.
Im Profil steht es komplett so:
assign oneway
switch oneway=
junction=roundabout
or oneway=yes or oneway=true oneway=1
Der Variable oneway soll ein boolscher Wert zugewiesen werden.
Wenn der Tag oneway leer ist, wird das boolsche Ergebnis aus der expression junction=roundabout zugewiesen (wenn es ein Kreisverkehr ist → TRUE sonst FALSE).
Ist der Tag oneway nicht leer, wird geprüft ob der Tag oneway yes, true oder 1 ist. Wenn das so ist, wird die Variable oneway auf TRUE gesetzt, sonst auf FALSE.
Ja genau. Wenn oneway nicht explizit gesetzt ist kann es auch impliziert sein bei einem Kreisverkehr. Schwieriges Thema, weil es wohl auch andere implizite oneways gibt, etwas highway=motorway oder junction=circular. Aber es muss ja nur zu 99% passen
Die Formulierung “keine Aktion” ist eher irreführend, weil in dieser Syntax gibt es keinen ausführbaren Code wie in richtigen Programmiersprachen, sondern nur Ausdrücke, da kommt also immer eine Zahl raus, mir der Konvention false/true = 0/1
Jetzt muss ich noch ein paar weitere Fragen nachschieben:
Es gibt die Schalter validForCars, validForFoot und validForBikes. Was genau bewirken diese Schalter?
in manchen Profilen findet man diesen Eintrag mit dazugehörigen Parametern. Was macht dieser Eintrag? ---model:btools.router.KinematicModel
Kann mir jemand Grundlagen zu der Kostenberechnung erklären. In den Profilen gibt es ja Standardvariablen die vom Router benutzt werden. Zum Teil Kosten, zum Teil Faktoren. Ich habe verstanden, das der ideale Weg Kosten von 1 haben müsste. Mit den Profilen kann ich nun Regeln aufstellen und Kosten für Wege und Knoten berechnen. Wie werden da die pre-defined variables genutzt? Mir sind da die Zusammenhänge/Abhängigkeiten nicht klar. Von mir nicht gesetzte Variablen haben den Wert 1? In welchem Bereich bewegen sich die Werte für Kosten und Faktoren? Kosten scheinen ja durchaus auch mal größer zu werden (z.B. turncost = 90). Faktoren werden sich ja eher zwischen 0 und 2 bewegen, oder?
Ich spiele hier mit einem minimalen Profil rum, um die Grundlagen der Berechnung zu verstehen. Mittlerweile habe ich es geschafft auch für Anstiege und Abfahrten Kosten zu verursachen. Aber was bedeuten die Werte im Profil bezogen auf die Steigung.
Und bei den turncost ist mir noch nicht klar, welche Abbiegung bei der Berechnung genutzt wird. Wenn ich eine Kette von way Elementen habe, die am Anfang und Ende jeweils eine Abbiegung haben, welche der Abbiegungen wird dann für die berechnung der turncost dieses Elements genutzt?
Vielleicht können @seichter oder @abrensch ja noch mal auf meine Fragen (auch aus dem letzten Post) antworten. Ich wäre Euch sehr dankbar. Oder gibt es irgendwo noch eine Community die sich aktiv mit den Profilen beschäftigt?
Wer lesen kann ist klar im Vorteil Zumindest meine dritte Frage zu den Grundlagen der Kostenberechnung kann ich mir nun gröstenteils selbst beantworten. In dem Glossary Glossary · poutnikl/Brouter-profiles Wiki · GitHub steht unter Equivalent length beschrieben, wie der Wert berechnet wird. Auch einige andere Zusammenhänge werden beschrieben.
Die ersten beiden Fragen aus meinem vorletzten Post kann ich aber noch nicht beantworten. Dazu hab ich bisher nichts gefunden.