Op-/Afrit snelwegen aan het begin ipv eind uitvoegstrook

Toen ik laatst van Leeuwarden naar de buurt van Eindhoven reed, merkte ik dat mijn navigatie (Osmand) eigenlijk altijd te laat is met afslagen en rijbaan wissels.
Wanneer je dan bij onbekende ingewikkelde knooppunten komt rij je zomaar verkeerd. Nu ben ik eens naar de kaart gaan kijken en het valt mij op dat afslagen vaak aan het eind van een uitvoegstrook splitsen. Soms staat het punt voor de op-/afrit op het witte vlak aan het eind van de uitvoegstrook.

Het ziet er netjes en overzichtelijk uit maar het werkt niet zo goed. Ik ben geneigd de ingewikkelde plekken die ik ken aan te passen. Ik hoop alleen dat ik dan geen ruzie krijg met mensen die veel tijd in het tekenen van de snelwegen hebben gestoken. Wanneer het punt aan het begin van de afrit staat gaat navigeren met OSM een stuk mooier denk ik.

Bij de navigatie-instellingen van OsmAnd kun je aangeven of je aankondigingen “op tijd” “vroeg” of “laat” wilt ontvangen. Standaard is “laat”, don’t ask me why. Wellicht helpt het om dit aan te passen?

Dat gaat over stembegeleiding en die staat bij mij uit. Het gaat voornamelijk om de ‘lane assist’ functie die op deze manier van mappen, te laat begint. De juiste rijbaan zie je wanneer je de afslag voorbijrijdt.

Het is eigenlijk al jaren een probleem en is niet alleen in Nederland. Ik heb ook afslagen in Duitsland bekeken en daar doen ze hetzelfde. Ook daar heb ik problemen gehad met afslagen die ik vaak met goed kaartlezen kan voorkomen maar bij afslagen die een tijdje parallel aan de vorige snelweg lopen, zoals bij Almere, loopt het fout. Bij Eindhoven zijn ook een aantal snelwegen die wat moeilijk te lezen zijn.

Niet aanpassen.
Het is een probleem van de navigatie app. (meerdere).
Laatst achter Amsterdam heb ik ook een afslag gemist, te kort er op om nog uit te voegen.
Dus herkenbaar, op een andere plek had ik er al eens naar gekeken.
Edit: tussengevoegd, dat is ook het goed aangeven van lanes en afslag icoon, op het juiste moment wanneer je dit verwacht. (afslag 15 RWS) Waar ik ook naar kijk.

Welke aanwijzing verwacht je en wanneer, als een bijrijder een “pace note” zou oplezen. Over “…”.
In Openstreetmap is er voor gekozen om motorway=junction zo te zetten. Dat gaan we/kunnen we niet in Nederland veranderen.

Neem nu afslag 15 Sneek

motorway=junction node. De placement=transition.

Vanaf deze node moet je de uitvoegstrook er vanaf trekken. Dat zou het punt moeten zijn die de navigatie aan geeft, corresponderend met de RWS bewegwijzering afslag 15.
Dat is 231 meter.

En hier verwacht je de tekst “neem de afslag” “Sneek” of “15”,
Zou mooi zijn als men de lengte van de uitvoegstrook vermelde (tekst of woord
Zo ook dat men hier de lanes zichtbaar maakt.

hectometerpaal 66,4

Ze moeten de lengte van de lane extra uitvoegstrook (3) met value slight_right er van aftrekken.
Dan kom je bij de punt uit waar Rijkswaterstaat de uitrit aan geeft.

Dat is het punt dat je wil weten/horen als je op dit punt rijdt.
Een veilige navigatie geeft op tijd de mogelijkheden aan.

En als je hier rijdt, dan ben je nog zoveel meter voor dit bewegwijzeringsbord, dan wil je horen neem de afslag over 600 meter, en niet (600+230) 830 meter, een mogelijkheid die zeer gevaarlijk is.


hectometerpaal 76,0 - 66,4 = 600 meter.
Rijkswaterstaat geeft afstanden tot aan begin uitvoegstrook. De afslag, 15.

Gemeten afstand tussen bewegwijzeringsborden.

Ik heb mij dan wel eens afgevraagd, hoe moeten de afstanden van de bewegwijzeringsborden taggen in Openstreetmap? Immers we taggen, wat we zien, en hoe zou men dat moet gebruiken is weer een ander vraag. Natuurlijk, weet ik een antwoord, dat kan de navigatie berekenen.

Deze afstanden moeten overeenkomen met wat je hoort.
Op tijd gegeven bij een bepaalde snelheid , wanneer je leesbaar het bord nadert (eventueel met zo’n vertragingsmogelijkheid, maar dat kunnen de apps ook berekenen, als je een bepaalde snelheid rijdt.)

Dit zou de verkeersveiligheid ten goede komen.

Wellicht moeten bepaalde navigatie spraak methodes verboden worden, vanuit het oogpunt van verkeersveiligheid.

motorway=junction turn:lanes controle met slight_right Hebben we ze allemaal ingevoerd in Nederland?

Je kan niet meer doen dan deze tags er goed op zetten.
De rest is aan de navigatie apps.

Het is wel een probleem.

Wanneer je de tag Highway=motorway_junction opzoekt

Citeer ik : "This node should be positioned as the last point before the splay at which it is still possible to make a smooth turn.¨ Dat is dus niet op het witte vlak. Dan kun je nog een discussie voeren waar je nog wel een soepele afslag kan maken maar de praktijk is dat dit vaak niet meer lukt.

Ik heb lane assist maar uitgezet omdat dat waarschijnlijk nooit gaat werken. De stem staat bij mij sowieso al uit.

Ik vind het wel wat vreemd om naar de software te wijzen, terwijl de kaart en software samen moeten werken. Waarvoor maak je de kaart? Is theorie belangrijker dan de werkelijke wereld?

1 Like

Aantal lanes wordt bij een uitvoegstrook (vrijwel) altijd met 1 verhoogd om aan te geven dat er een turn_lane komt
lanes=3
turn:lanes=none|none|slight_right
Als de lane assist functie van de software hier niet mee om kan gaan, is het toch geen gebrek van de kaart?

1 Like

Dit is een probleem van jouw navigatiesysteem en niet van OSM. De way van de afrit vangt aan waar de fysieke scheiding begint, dus bij het puntstuk. Daarvan afwijken opent een doos van Pandora van problemen voor andere toepassingen en software, inclusief intelligentere navigatiesystemen die visualiseren waar de uitvoegstrook ligt en de instructie “neem de afrit” op het scherm laten staan tot het einde van de uitvoegstrook. De uitvoegstrook zelf is ook gemapt met turn:lanes=*, dus alle informatie om goede navigatie-instructies te maken is aanwezig.

N.B. Op de bewegwijzering telt Rijkswaterstaat de afstand tot het “nu moet je echt gaan uitvoegen als je het nog niet gedaan hebt”-moment, wat bij simpele uitvoegstroken hetzelfde is als het begin van de uitvoegstrook.

2 Likes

Ok ik ga eens verder zoeken naar de oorzaken. Ik snap dat het punt verplaatsen geen optie is.

Ik heb vandaag met een commerciële kaart en navi gereden en zag dat de afstanden voor afslagen kloppen met het eind van de afrit. Misschien kloppen de rijbanen en tags op sommige plekken niet en gaat het daarom mis.
Lane assist werkt volgens mij namelijk soms wel. Ik zit alleen te weinig op de snelweg om dat even goed te checken. Ik weet wel dat het aantal rijbanen dat Osmand aangeeft niet altijd klopt.

In ieder geval bedankt voor alle input.

Ik vind juist dat OSMand te vroeg afritten aangeeft, mijn ervaring is wel 3 km van te voren…

Betse Jeroen,

Je hebt de wijziging die ik twee maanden geleden bij Entrada in Duivendrecht weer verwijderd. Nu ben ik er helemaal voor dat OSM community effort is waar we doorbouwen op elkaars wijzigingen; maar in dit geval had ik enige ruggespraak vooraf wel netjes gevonden.

Als je gebruik maakt van lane assist of van bijvoorbeeld zelfrijdende auto’s dan is de keuze om een scherpe bocht te maken bij een afslag niet gewenst.

Dan is dit vele malen vloeiender een bovendien getrouwer der werkelijkheid:

Dan wat jij er nu van gemaakt hebt:

2 Likes

Ben absoluut geen fan van wat ik zie als google style mapping, dan moet je een stuk hoofdweg opsnijden voor de lengte van de afrit die nog aan de hoofdweg meeloopt tot waar ze splitsen, het aantal lanes daarvoor met 1 of meer verhogen, turn:lanes toevoegen met through|through|slight right bijv. en ook destination:lanes zodat je ziet waar elk spoor heengaat om het compleet te maken met de connectivity regels. Te veel mogelijkheden om de boel te vernaggelen. En dan ook die scherpe verbindings hoeken waar de echte splitsing begint ipv de vloeiende ‘on de ground’. OttoR voorbeeld 1 dus voor mij. Mijn navigator doet een vokale aankondiging op 2km 1km 0.5km en waar de afrit begint, voorbeeld 2 dus eigenlijk te laat want dan ben je er al voorbij. Liever een beetje te vroeg als net die 18 meter truck in het rechter spoor bij 80 het zicht op de richtingborden blokkeerd. Ik kijk trouwens maar heel weinig op de navigator. Ik luister, zeker als het druk is.

PS de meeste ramps hier zijn 40km, ook nog snelheid per spoor instellen!

1 Like

Niet verbazend, maar eens @SekeRob; maar ik zie ook de toegvoegde waarde van turn:lanes. Zeker als je de juiste ‘view’ aan hebt staan.

De keuze waarom de splitsing pas ‘hoort’ daar waar het puntvak is snap ik dan ook niet. Overigens ook niet voor een niet-snelweg. Ik zie en hoor liever op de navi dat ik verderop een eigen rijstrook heb voor rechtsafslaan dan dat ik op een T kruising met een weg heb met twee stroken.

Wat ik in dit soort gevallen vooral merk - tenminste zo interpreteer ik het - is een botsing tussen twee werelden:

  1. Die van de proffesionele GIS-ers, en misschien ook wel vanuit een tradtitionele kaartenmakers achtergrond, waarbij de filosofie is dat een kaart zo simpel mogelijk moet zijn. Ik vermoed overgeleverd vanuit het fysieke kaarten tijdperk, waarbij je op een bepaalde schaal te veel detail onoverzichtelijk wordt.

vs

  1. Die van de digitale enthousiastelingen die bijdragen aan OpenStreetMap veelal vanuit een andere achtergrond en die dus op een andere manier naar de kaart kijken. Meer vanuit een gebruikersachtergrond of een esthetische achtergrond en ook toepassingen zien waarbij meer detail juist van toegevoegde waarde is. En die zien het nut niet van die versimpelde weergave omdat een digitale kaart je de mogelijkheid geeft om in- en uit- te zoomen en detail te verbergen of toe te voegen.

De splitsing hoort op het punt waar de rijbaanscheiding begint. In het begin van OpenStreetMap is een principiële keuze gemaakt dat ways rijbanen voorstellen en dat rijstroken worden getagd met aanvullende tagging (zoals lanes). Dat is het model waar we al bijna 20 jaar op voortbouwen.

Het lijkt dat Jeroen gewoon het begin van de rijbaanscheiding op de correcte plek heeft gelegd. Dat lijkt mij juist een verbetering.

1 Like

Dit is geen Google style tagging, maar de manier hoe we het bij OSM afgesproken hebben. Het is absoluut niet de bedoeling om rijstroken als ways te gaan mappen, omdat je de lanes-tags onhandig vindt.

1 Like

Lees wel vaker over ‘wij hebben afgesproken’, dan gaarne waar dat beschreven is in de OSM wiki want blijkt dat er heel velen zijn die dat memo niet ontvangen hebben.

De discussie of een way een rijbaan of een rijstrook/voorsorteervak voorstelt heeft inderdaad aan de begindagen van OpenStreetMap plaatsgevonden, toen de meesten van ons (inclusief mezelf) er nog niet bij waren.

Dit zijn wel de principes waaruit het hele project is opgebouwd en die dus gevolgd horen te worden.

Als je een voorsorteervak als aparte way intekent, geef je daarmee aan dat het een fysiek gescheiden rijbaan is en dat klopt niet.

1 Like

Voor de voorsorteerstroken hebben we de turn:lanes tag. Dat werkt prima, en alle programm’s en kaarten die daar niet (correct) mee werken missen deze belangrijke info. Daar hoeven wij OSM niet voor aan te passen.
Tot zover mijn mening.

2 Likes

‘We hebben het altijd zo gedaan, dus we hoeven het niet te veranderen’; dat vind ik een erg gevaarlijk regel.

Dus omdat het ooit zo besloten is, betekent dat niet dat die tot in de eeuwigheid gevolgd horen te worden. En met nieuwe inzichten kan je tot andere uitkomsten komen.

Bovendien is er de interpretatie van een ‘fysiek’ gescheiden rijbaan. Een berm, stuk gras of stoeprand is duidelijk; dat is fysiek gescheiden.

Maar als het een doorgetrokken lijn is; dan is de rijbaan opeens niet fysiek gescheiden? En dus een blokmarkering ook niet?

Terwijl die blokmarkering wel degelijk ‘een andere’ rijbaan aanduidt. Met een andere bestemming en soms ook een andere max snelheid. En ja je kunt dit allemaal als complexe lane attributen meegeven; maar is het dan niet gewoon simpeler te houden door een aparte baan in te tekenen.

En voordat je zegt ‘verf op de weg is niet fysiek’; daar is men ook niet erg consistent in; want een puntstuk is dan opeens wel weer een fysieke scheiding:

Ik vind dat logisch, want de weg de ene kant op heeft andere attributen dan de weg de andere kant op en als je ook nog eens op de kaart de werkelijkheid wilt weergeven dan lopen die wegen best uit elkaar.

Dit is ook zo’n voorbeeld:
image

Om van de Europaboulevard vanuit het zuiden af te slaan naar de Boelenlaan moet je ongeveer 100 meter van te voren al voorsorteren. De ‘fysieke’ scheiding is daar een busbaan. Dit is nu allemaal met lanes ingetekend:

access:lanes=yes|no|yes|yes|yes|yes
change:lanes=no|no|not_left|yes|yes|yes
psv:lanes=|yes||||
turn:lanes=left|none|through|through|right|right

Terwijl het fysiek op de kaart lijkt alsog je na de kruizing pas naar links afslaat.
En voor software zijn die lane attributen prima leesbaar; maar voor de human eye is dit complex. En waarom dan niet dus de baan die afsplitst naar links (desnoods busbaan en afslag gecombineerd als je het ‘simpel’ wilt houden)

En hier is het eigenlijk onjuist weergegeven:


De oprit is tot en met de brug, waarbij verkeer op de 4e rijstrook van de A10 niet naar rechts mag uitvoegen en verkeer op de invoegstrook wel de A10 op mag invoegen, maar wel pas zo’n 40 meter verder dan dat nu staat ingetekend ‘Omdat we 20 jaar geleden hebben afgesproken dat een invoegstrook zo schuin mogelijk moet’. De afslag begint daarna pas.

En dit is overigens een prima voorbeeld waarom afslagen heel nuttig zijn als lane attribuut. Begrijp me niet verkeerd, ik ben niet tegen lane en sich; ik ben vooral van mening dat het geen heilig huisje moet zijn.

Hier wil je natuurlijk niet een aparte weg intekenen met allemaal kruisverbindingen:

Maar die splitsing kan toch wel netter ingetekend worden?

Als ‘we’ toch bezig zijn, maxspeed:lanes of maxspeed:lanes:forward/backward als de enkele richting meerdere sporen heeft met bebording of schilderwerk op de bestrating. Niet eerder gebruikt maar komt in het repertoire en bij 18K gebruik alleen al voor maxspeed:lanes=* bijv. 90|90|40 op de expres wegen, slechts een tiental keren gebruikt in het halve land, zo populair, in de lage landen ook niet bepaald overdadig ingezet.

image

Navigatie is een vak apart, wat sluit het beste bij jouw aan is verschillend, bepalend of je een keuze maakt voor vooruit berekende route A naar B, of keuzes maakt ter plekke, op een topografische kaart rijdt.
Het links of rechts aanhouden op een meerstroken weg, bij topografisch houd je daar zelf al rekening mee, voor het kruispunt. Van A naar B verwacht je aanwijzingen, voice op tijd, de route lijn, links/recht aangevend, de stroken visualisatie die overeenkomt met de zichtbare situatie. Liefst meerdere situaties achter elkaar aftellend in km, op tijd. rekening houdend met je snelheid (Dat laatste, daar schort het nog wel eens aan)

Na de bijeenkomst vele jaren geleden bij RWS heb ik meermaals met de betreffende organisator gesproken, na die tijd kwam ik een schrijven tegen waar het Ministerie/RWS vermelde, dat men aan het kijken was naar een Openstreetmap+++, benieuwd wat men daar mee bedoelde, het model dat toen bestond was niet geschikt voor de toekomst.
Binnen dat proces, moeten keuzes worden gemaakt. Netwerkopologie.
En zo is er binnen Openstreetmap ook een keuze gemaakt, deels ontstaan door ontwikkeling van tags. Op basis van Baan netwerktopologie.

Daar is men mee bezig gegaan.


link.

En zo is er binnen Openstreetmap, het baanmodel verder vormgegeven. Je kan zelfs stellen dat men van een wegmodel in de loop der tijd, nog steeds naar het baanmodel aan het overstappen is. (Zie ook de los getekende sidewalk)
Een strook model, wereldwijd zal/kan er niet komen.

Afslaan De Doelelaan:
In Magic Earth (gps uitgeschakeld, met keuze punten op kaart) DEMO route gebruik.

Op dit punt moet je al anticiperen om links te gaan rijden.
Dat moet duidelijk zijn in de lanevisualisatie.
Dat gaat hier fout. Lanevisualisatie. De keuze voor het verkeerslicht moet al gemaakt zijn.
De linkerafslagpijl moet helder wit zijn.


Op de rechtsaf kruising

Met style, zie je gelijk t.o.v. beeld (luchtfoto) of het goed staat.

De navigatie heeft nog wat werk te doen.

Zelf anticiperen, waar gaat de blauwe lijn naar toe gaat, is anticiperen, links/rechts aanhouden.
afbeelding

Een strokenmodel is niet de oplossing.
Dan heb je een lanevisualisatie, die niet past bij het wegbeeld, overzicht.
Navigatie, werkt met het baanmodel.

Strooknavigatie, moet er dan een relatie komen tussen associated stroken om de lane visualisatie weer te geven, wat overeenkomt met de werkelijkheid en de bewegwijzering.

Vooral dat overeenkomen met de bewegwijzering is voor mij belangrijk, zo ook in spraak, wat ik in een eerdere post in dit topic al aan gaf.

Verschil tussen alle geeft verwarring. En dus onveilige situaties.

3 Likes