Dat is wel erg kort door de bocht. Het is besloten aan het begin van het project dat een way een rijbaan voorstelt, dus de baan-netwerktopologie uit Allroads’ post. Daarna zijn er allerlei OSM-kaartstijlen en OSM-apps ontwikkeld. Deze nemen aan dat een way een rijbaan is. Een dergelijke principiële keuze kun je niet 15 tot 20 jaar later overhoop gooien, want dat zijn alle kaartstijlen en apps op verkeerde aannames gebaseerd.
Een rijbaan loopt van rand verharding tot rand verharding. Bij een doorgetrokken streep is dus geen sprake van de rijbaanscheiding.
In de volksmond wordt een rijstrook vaak een rijbaan genoemd, maar het lijkt me niet handig om de termen door elkaar te gebruiken als we het juist over het verschil tussen rijbanen en rijstroken hebben. Op deze locatie is een busstrook, geen busbaan. Deze hoort dus gewoon met lane-tags ingetekend te worden. OSM Carto geeft geen rijstroken weer, dus daar hoef je niet naar rijstroken te zoeken. We taggen ook niet voor één renderer.
En dit is wat er gebeurt als een mapper al een aantal dagen die aparte afslagen naar voren haalt en aparte banen intekent.
Reageren doet hij helaas niet, maar maakt momenteel alle routerlaties stuk in Tilburg met af en toe uitstapjes naar Denemarken https://www.openstreetmap.org/user/Rodejong/history#map=6/53.726/8.486
Leo en ik hebben geprobeerd contact te krijgen, maar hij gaat stug door.
Waarom sommige mappers niet reageren … ook op PB’s is me een raadsel.
edit Het is ergens wel logisch als mappers die kruispunten willen aanpassen (Ik deed dat jaren geleden ook) in de vorm van vervroegde afslagen, maar dat pakt in dit geval heel slecht uit. Er lopen tientallen busroutes die allemaal stuk waren.
Wanneer mapper straks de computer openklapt ben ik toch bang dat het weer verder gaat.
In zijn algemeenheid zul je altijd hoeken hebben in kruispunten waar je als dataconsument mee om moet kunnen gaan. Bij een eenvoudig kruispunt zonder voorsorteerstroken kun je niet eens een vloeiende bocht tekenen. Voor het geven van informatie over boogstralen is het intekenen van area:highway vermoedelijk een robuustere oplossing die algemener toepasbaar is.
In dit geval zijn er wel (kleine) geverfde puntstukken, dus in theorie zou je hier wel een aparte highway=*_link voor het bochtje kunnen tekenen (als we het uitgangspunt van fysieke scheiding zouden loslaten), maar zelfs dan is er geen reden het stuk daarvoor waar de voorsorteerstroken nog gewoon parallel lopen ook te splitsen.
Het kaartbeeld ziet er chaotischer uit, en bevat niet-vloeiende knikken op het punt waar de voorsorteerstroken splitsen.
In mijn ervaring levert het intekenen van aparte ways voor verschillende voorsorteerstroken een veel groter risico op fouten op (ongeacht of dat nu wel of niet terecht is omdat er wel of geen fysieke scheiding aanwezig is). Behalve de tagging van de ways zijn ook de turnrestricties vaak fout/onvolledig. Als je bij een verkeerslichtenkruispunt met vier armen alle linksaf- en rechtsafbewegingen als aparte ways zou intekenen, heb je enorm veel mogelijkheden om fouten te maken.
Ook in dit voorbeeld van Otto had de strook voor rechtsaf bijvoorbeeld een andere wegbeheerder dan de strook voor rechtdoor.
Niets houdt navigatiesystemen tegen om change:lanes te analyseren en daaruit af te leiden dat een instructie om van rijstrook te wisselen eerder moet worden gegeven. Doen alsof één rijbaan twee gescheiden rijbanen zijn is ongewenste mapping for the renderer.
Uiteindelijk kan een navigatiesysteem bovendien instructies van hogere kwaliteit geven als het een volledig beeld van de gehele rijbaan heeft, inclusief kennis van wat er aan de andere kant van een doorgetrokken streep aanwezig is. (In de screenshots van Allroads zie je bijvoorbeeld al dat de busstrook een speciale weergave heeft.) En hulpdiensten kunnen bijvoorbeeld gewoon over doorgetrokken strepen heen rijden.
Het is toch logischer om in plaats van De Boelelaan voor die twee korte stukjes op te knippen omdat er een afslag zit; de afsplitsing gewoon te laten starten daar waar hij start en dan loopt de Boelelaan gewoon door.
Niet meer dan de nu gekozen oplossing; nu laat je de weg over een puntstuk lopen op een punt waar de automobilist niet eens in mag voegen.
en hier laat je iemand recthsaf slaan waar die echt niet meer geacht wordt rechtsaf te slaan. Niet alleen voor de dataconsumer; maar ook voor de visuele consumer (de mens) die een kaart voor zich ziet.
Heren vertel, waar zet je nu de Stop-Spot op de weg, meeste andere gevallen een yield spot? De ‘oprit’ heeft een dikke vette scheidings-streep, is ongeveer 150m lang, de gedachte dat je dan je snelheid met het verkeer op de hoofdweg kan synchroniseren, maar er nog niet op mag. Dat stuk staat er nu met turn:lanes:forward=through|merge_to_left + de 50 meter dat je echt mag invoegen en de stop staat er nu meer als 150 meter terug gemapped op de ‘oprit’ waar de navigator dus een foute instructie krijgt, M.I.
(Geleend van google maps, gisteren weer op mn fiets gepasseerd voor fast track op de 1 meter brede shoulder en de hele resterende weg al peinzend me afvragende “Is this for real?”.)
De highway=give_way|stop zetten we dacht ik waar de stopstreep staat, dus als de streep verplaatst is moet die ook verplaatst. Bedoel je dat dat niet kan omdat de invoegstrook niet apart gemapt is?
(Ja, ik denk een beetje langzaam vandaag…)
merge2left houdt wel automatisch in dat je voorrang moet geven, en de lane houdt gewoon op dus een navigatie kan dat weten en weergeven.
Dat is juist het verhaal, lanes:forward=2, backward is 2, waar the turn:lanes:backward als through|slight:right getagged is, no problem. Bij voorwaards kan ik die stop dus niet op het juiste punt zetten verwegen het closed-box idee dat je de aangeplakte parallelle oprit dus deel van de hoofdweg gemaakt is. Dat er verkeers technisch voorrang gegeven moet worden is een ding, het verplichte stoppen een ander.
Dat gezegd hebbende ik heb op heel oude mappings stop=* yes/forward/backward/both gevonden of wegen en niet op nodes, dus waar de stop spot is weet ik niet anders dan dat ze er zijn. Gaat hier niet of er moet een nieuwe tag bedacht worden… stop:forward=|yes. Echt helemaal KISS(sarc). Van lieverleed de traffic signs dan maar gemapped op de juiste plek naast de weg.
PS Ik neem aan dat de merge_to_left de instructie is die routers laat weten dat er voorrang gegeven moet worden.
