Richtig, dann stehe ich am Straßenhand, da hält die Bahn aber nicht … 
Ja, so wie grashopper es macht, wäre gut 
Noch steht da kein Verbot … 
Scheinbar, ich bekomme mit v68 mittlerweile auch nur 'ne weisse Seite. Vor 1-2 Wochen ging das noch.
Ja, bei dem Release am Freitag kam dynamischer Import (import()) dazu, das wird erst ab Firefox 67 unterstützt (68 sollte demnach eigentlich gehen?). Ich hatte allerdings angenommen, dass sich das erst beim Hinzufügen der Vector Tile Layer auswirkt und nicht schon beim Laden der Seite, da war mein Test wohl unzureichend.
Könnt Ihr zur Bestätigung bitte mal den Fehler aus der Browser Konsole (F12) kopieren.
Vermute, Du meisnt sowas mit Fehlermeldung?
SyntaxError: expected expression, got keyword ‘import’ brouter-web.js:55:7723
Ja, genau, Danke. Ich vermute, da meckern alte Browser ein reserviertes Schlüsselwort an, das sie noch gar nicht unterstützen.
Was ist der Grund, dass Ihr keine aktuelle Version verwenden wollt oder könnt (alte Plugins die es nicht als Web Extension gibt, 32-bit)? Ich hatte mich schon gefragt, ob sich der extra Aufwand zur Unterstützung älterer Versionen noch lohnt.
Bei mir ist es bei FF die letzte Version, mit der Plugins alter Art noch funktionieren, auf die ich als Tab-Messie nicht verzichten wollte und für die sich damals und paar mal zwischendrin noch kein adäquater Ersatz fand, damit mein FF so funktioniert, wie ich ihn gerne haben will …
Da aber immer mehr Seiten nicht mehr wollen (iD auch nicht mehr), muss ich mir wohl doch mal verschärft Gedanken um Ersatz machen, aber da werden noch viele Monate ins Land ziehen, bis das mal erledigt ist …
Der Browser, den ich hilfsweise für in FF-uralt nicht mehr richtig funktionierende Sachen wie iD nutze, wird es wohl eher nicht …
Hab keinen 68 hier aber nen Seamonkey, der die 68 nutzt.
Ich bekomme in SM nur den Header und den Footer.
Ja, “weisse Seite” war etwas verkürzt, s.o.
Ich nutze hauptsächlich Seamonkey, wegen dem Browser, aber auch wegen der Addons. Die meisten gehen in FF nicht mehr, und die die gehen, funktionieren komplett anders und unzureichend.
Wenn Du sowas nicht unterstützen möchtest ist das schade, weil bisher gings ja prima.
Achja, Fehlermeldung ist hier die selbe wie bei MitteloberrheinischerWaldameisenschreck
Und btw. grad geschaut, iD geht tatsächlich auch nicht mehr, aber da isses sicher nicht schade drum… 
Danke für die Infos, ich denke ich habe eine halbwegs einfache Unterstützung für ältere Browser gefunden, muss ich aber noch testen.
Zurück zum eigentlichen Problem der Bahnsteige:
Way 937994901 ist u.a. als railway=platform getaggt. Das wird zwar in den BRouter Daten prinzipiell unterstützt, siehe lookups.dat, aber bisher in keinem Profil verwendet, siehe Issue #45 highway=path nicht indiziert ?.
Die Probleme mit älteren Browsern (Firefox < 67) sollten jetzt behoben sein (ggf. Strg-F5 zum Cache leeren).
Läuft, danke.
Jau, läuft wieder! Danke!
Das Bahnsteigproblem scheint daran zu klemmen, dass zu viele Inseln befürchtet werden?
Ja, Routing-Inseln. So werden Teile des Wegenetzes genannt, die nicht mit dem Rest verbunden sind.
Was bei Bahnsteigen vielleicht schon öfters vorkommen kann. Ein Router, der das nicht berücksichtigt, sucht für eine Route zu einer solchen Routing-Insel ewig die ganze Welt ab, nur um dann festzustellen, dass es gar keine Verbindung gibt. Oder erkennt das zwar, kann dann aber gar keine Route erstellen.
https://github.com/abrensch/brouter/issues/45#issuecomment-306765741
Mir scheint, das wurde inzwischen implementiert, somit gäbe es kein Problem mehr:
automatically ignore islands · abrensch/brouter@599a24f
Solche Routing-Inseln kann man in der entsprechenden Ansicht im OSM Inspector sehen, z.B. hier:
http://tools.geofabrik.de/osmi/?view=routing&lon=11.62409&lat=48.13579&zoom=19&baselayer=Geofabrik%20Standard&overlays=islands_all
Beim Routing zu dieser Plattform (way 467285364) wird halt nur zum nächsten Punkt außerhalb dieser Routing-Insel geroutet. Innerhalb der Routing-Insel, also in diesem Fall entlang der Bahnsteigkante, kann man auch routen (geht hier wegen highway=platform, da das Trekking-Profil alle highway=* unterstützt). Also für mich alles gut.
Der dynamische Ausschluss der Inseln vom Wegpunkt-Matching war nur eines der Probleme.
Das andere war ein Memory-Leak, weil solche Inseln in einem Zwischenspreicher des Decoders “hängen” blieben. Letzeres sollte aber auch gelöst sein durch die Einführung des “Direct Weaving”, das diesen Zwischenspeicher obsolet gemacht hat, weil der Decoder damit immer komplette Mikro-Kacheln direkt in den Routing-Graphen “hinein webt”.
Also sollten Inseln mittlerweile unbedenklich sein, solange sie weniger als 500 Knoten haben ( Siehe RoutingEngine.MAXNODES_ISLAND_CHECK )
Auch etzt nicht, wo er im Betrieb ist, nur Radfahren ist verboten, Mofas, Fußgänger, Reiter, Kutschen, Viehtrieb, … dagegen nicht …
Aber mal was ganz anderes …
Bin heute geradelt und habe hinterher die vorher per brouter angedachte Route noch mal spaßeshalber auf die geradelte Praxis angepasst.
Dabei fiel mir auf, dass brouter hier das direkte Abbiegen über den 2. Zwischenpunkt vermeidet wie der Teufel das Weihwasser und lieber ein Stück gegen die Einbahnstr. zum 3. Zwischenpunkt zurück routet, ohne dass ich einen Grund finde. das bicycle=use_sidepath kann es nicht sein, darüber routet er beim 1. Zwischenpunkt ja. Als Unterschied finde ich nur foot=no am weihwasserbesprenkelten Kriegsstraßenstück … Andere Profile schlucken es klaglos …
Ja genau. bicycle=use_sidepath verbietet, aber über die Fussberechtigung gehts dann doch. Wenn man die auch wegnimmt ist es gesperrt.
Das fastbike-profil wertet use_sidepath dagegen nicht aus
Die Instanz von Marcus Jaschen macht das nur im hiking (beta)-Profil, in allen anderen wird es wie (vermutlich) gewünscht geroutet:
https://bikerouter.de/#map=19/49.00577/8.37707/standard&lonlats=8.375339,49.005252;8.377113,49.005585;8.377638,49.00562;8.377833,49.005672;8.377994,49.006003&profile=trekking
Hmmm … Irgendwie bissele suboptimal … use_s. soll ja gerade nicht absolut sperren, erst recht nicht, wenn man einen Zwangspunkt draufsetzt …
Interessant (noch) das Wandern: Wird über den kürzeren Flügel des absolut gesperrten Stücks, also hintenrum geroutet zum Zwischenpunkt, um dahin zu kommen, nimmt es die Busspur, die (eben noch) nur mit vehicle=no ohne foot=no getaggt war …
Wird eigentlich bicyle:*ward ausgewertet? Bzw. wo sieht man, welcher Stand der Daten zugrunde liegt? Wollte das an anderer Stelle gerade testen …
Entweder Taste “H” drücken oder auf “About” klicken, im Popup im Abschnitt “Data” sind die “data files” verlinkt:
Die Instanz https://bikerouter.de aktualisiert viermal täglich, siehe https://www.marcusjaschen.de/blog/2020/brouter-web/#anleitung-und-tipps-zum-umgang-mit-brouter-web, ich zitiere
Danke, also aktuell genug und damit wird gegen bicycle=no und bicycle:*ward=no geroutet hier und dort, die no’s sind da jeweils an den Zufahrten am Anfang, während die Gegenrichtungen nicht über no’s laufen sollten, weil “oben am Seehof” (die Kreuzung ungefähr an beider Ziel von B3 und Karlsruher Straße) stehen keine Verbote (und an einigen anderen Stellen, wo man fröhlich raufradeln darf, Fußgänger-, Reiter- und Viehtriebverbote stehen gleich überhaupt nirgends …), schon seit Jahren nicht.
Nur “sicherste Route” routet nur bis zum Zwischenpunkt und dreht dann evtl. um … Wenn der Zwischenpunkt näher zum verbotenen Ende liegt, gerne auch über das Verbot …
Nach einem tödlichen Unfall eines Radfahrers, der gegen die erste Route wieder von der B3 links runter wollte in die Bulacher, habe ich die Standorte und Nichtstandorte der 254’s noch mal kontrolliert und paar tags gerade gebogen, u.a. waren paar fehlgetaggte motorroads drin …
Die 3 “eingebauten” routen in die verbotene Richtungen nicht, in die erlaubten teils ja, teils nicht.