Uitritconstructie, hoe verwerken, onderdeel van openbare weg.

Een inrit of uitrit is een deel van de zijweg, men spreekt bv van “voor een uitrit parkeren”. Dat dat niet mag dus. En “vanaf de weg een inrit inrijden, vanuit een uitrit de weg oprijden”. Daarbij kruis je trottoir en fietspad, maar de uitrit begint al daarvóór en eindigt daarna.

Praktisch nut van voorrang in OSM weet ik ook nog steeds niet goed… ik zou zowizo nooit 100% vertrouwen op informatie over snelheden en voorrang in een database die afhankelijk is van willekeurige bijdragen. Hoe goed bedoeld ook, garantie op volledigheid en juistheid heb je niet. Dus hou ik het praktisch: als voorrang uberhaupt wordt ingevoerd, dan hoort deze er ook bij.

Als je het aangeeft met een node, waar zou die dan precies moeten staan?

Het verschil is dat jij spreekt over de uitrit zelf en ik had het over de constructie die maakt dat de zijweg als uitrit moet worden gezien.

Ik heb de verschillende uitritconstructies nog even bekeken die ik aanhaalde.
Deze is in mijn woonplaats. Het vlak is veel breder dan het trottoir maar formeel valt waarschijnlijk de hele constructie onder het trottoir (BGT-functie: Voetpad).
Hier een voorbeeld waarbij het trottoir onverbreed doorloopt en slechts deel is van de verhoogde constructie (BGT-functie: Rijbaan lokale weg). Aan de zijstraatkant zijn er geen inrijblokken, slechts iets oplopende bestrating. Een half uitgevoerde uitritconstructie zou je kunnen zeggen maar goed genoeg om als zodanig te gelden.
En dan deze aangegeven zonder BGT-functie. Het belangrijkste kenmerk, een doorlopend trottoir in dezelfde bestrating, ontbreekt. Ik zou zeggen dat dit ondanks de uitritblokken niet als uitritconstructie kan gelden.

Een node kan in het midden van de uitritconstructie, dus in de praktijk op de zijweg dichtbij het kruispunt. Het voordeel van highway=give_way erbij is dat met deze al bestaande tag er meteen doorwerking kan zijn binnen de applicaties die rekening houden met voorrang. De uitritconstructie zelf kan dan met traffic_calming=* worden aangegeven. De reden voor uitritconstructie boven verkeersbord/haaientanden lijkt me daadwerkelijk het kalmeren van verkeer.
Wil je dat applicaties de voorrang middels de nieuwe tag laten doorwerken dan kan daar wel eens veel tijd en moeite overheen gaan. En dit inclusief rendering toepassen op een lijnelement i.p.v. node mogelijk nog meer.

Ik ben inmiddels flink aan het meedenken geweest hoe het eventueel gemapt zou kunnen worden. Mijn voorkeur is nog steeds om het gewoon helemaal niet te taggen of eventueel gewoon als verkeersdrempel aangezien de definities van een uitritconstructie niet goed zijn afgebakend.

Bedoel je: de node taggen met zowel highway=give_way als traffic_calming=[woord voor uitritconstructie] ?

Euh… ff kijken of ik dit wel begrijp. Je bedoelt, de uitritnode staat op de way van de zijweg, en op basis daarvan wordt het laatste stukje van die way anders gerenderd dan de way zelf vraagt?

Terug van vakantie zag ik dat dit draadje al een aardige baard heeft.

Discussie hier en elders gaat samen met niet altijd -of op handige plekken vastgelegde- definities, hoewel dat zeker weer niet betekent dat het allemaal arbitrair is (ik zou zeggen : in veruit de meeste gevallen duidelijk en zoals wel eens vaker ook regelmatig wat twijfelgevallen)

Voornaamste wat opvalt is dat *uitrit *en inrit in het huidige RVV *niet * zijn gedefinieerd:
http://wetten.overheid.nl/BWBR0004825/2017-07-01#HoofdstukI_Artikel1

Net als trottoir overigens, daarvoor moet je ook gebruik maken van de woordenboek/boerenverstand definitie, maar dat leidt in de praktijk toch ook vaak genoeg tot twijfelgevallen, zeker als de afwijkende bestrating niet verhoogd is of met een schuine band loopt. Hoewel steeds in één adem genoemd zijn in het RVV trottoir en voetpad twee verschillende dingen.

Tot mijn verrassing bleken uitrit en *inrit * -in tegenstelling tot trottoir- in het RVV1990 aanvankelijk *wel * te zijn gedefinieerd:

http://publicaties.minienm.nl/download-bijlage/9755/geef-je-verstand-eens-voorrang-informatiemap-nieuw-reglement-verkeersregels-en-verkeerstekens.pdf

Wanneer en om welke reden deze definities zijn geschrapt kan ik zo snel niet achterhalen. Reconstruerend lijkt het te zijn gebeurd bij een wijziging die door ouderdom net niet met via wetten.overheid.nl kan worden bekeken (1994?):
http://wetten.overheid.nl/BWBR0004825/2017-07-01/0/HoofdstukI/Artikel1/informatie

Bij de oudste geconsolideerde versie van het RVV die daar te vinden is na de initiële vaststelling (2002) waren de definities echter al verwenen
http://wetten.overheid.nl/BWBR0004825/2002-03-30#HoofdstukI

Heeft iemand misschien de toelichting bij het schrappen van die definities paraat?

Dit maakt toch benieuwd, deze lange discussie hier op het forum (en de op zich duidelijke eisen van de rechter aan alle verkeersdeelnemers, die echter niet bij iedereen bekend zijn) zijn toch wel illustratief :slight_smile:

–edit–

Ben des te benieuwder naar het stuk met de de reden van schrappen van de definities na het lezen van het gloedvolle betoog dat in de Nota van toelichting van het originele RVV 1990 juist werd gehouden voor het introduceren van die definities:

http://publicaties.minienm.nl/download-bijlage/9755/geef-je-verstand-eens-voorrang-informatiemap-nieuw-reglement-verkeersregels-en-verkeerstekens.pdf

Juist.

Nee, ik zal het beter verwoorden. Kies je voor een node met één of twee bestaande tag dan zal dit meer/versnelde kans op rendering en/of doorwerking van voorrang geven dan een node met nieuwe tag(s). Highway=give_way en traffic_calming=hump zijn bestaande opties.
Verder vermoed ik dat je gebruik door applicaties gemakkelijker voor elkaar krijgt wanneer je een node met nieuwe tags promoot dan wanneer je een lijnelement met nieuwe tag(s) promoot.

Steeds kreatievere bestrating was (en is) het probleem denk ik.

Ik deel de voorkeur van Andries van het taggen van de uitritconstructie op de node ipv op een way.
Als je het op en way doet, dan komt het in plaats van een andere -al wel bestaande breder geaccepteerde / beter passende- , en dan vind ik de nut/noodzaak discussie wel terecht (en persoonlijk niet in het voordeel van de uitritconstructie uitpakken).

Het apart taggen hiervan zou ik wel weer vinden passen als highways -naast lijnen- ook als areas worden gemapt (wat in andere gebieden ook naar mijn mening ook al geheel terecht gebeurd en wat wij hier ook al doen bij water, spoorwegen etc.)

Bij het taggen op de node als extra informatie (en niet ter vervanging van bestaande) is die nut-/noodzaak discussie niet (of veel minder sterk, afhankelijk van je visie) aan de orde: zowel give_way als traffic_calming zijn beide breed geaccepteerde en gebruikte tags, de voornaamste vraag is dan hoe (en dat was dan ook de originele vraag van Allroads die hij stelde in de openingspost.

Zelf denk ik dat het nog simpeler kan dan met een aparte -nieuwe- value voor traffic calming specfiek voor een uitritconstructie:
de definitie van traffic_calming=table is:

https://wiki.openstreetmap.org/wiki/Tag:traffic_calming=table

Dat zal voor veruit de meeste uitritconstructies voor veruit de meeste auto’s wel gelden (de wielbasis van de meest verkochte auto in 2017 is 2,6 meter), en als ie toch korter is, dan is de node een gewone traffic_calming=hump. Zo kan je toe met breed geaccepteerde tags.

Dit naast de *highway=give_way * met de bijbehorende *direction=**.
Waar vermelding van de specifieke uitritconstructie me wel handig lijkt, is als onderbouwing van de highway=give_way, zodat andere mappers weten waarom dat daar zo gemapt is, net zoals we de RVV-code van het fietspadbord taggen op de way naast de tags die de daaruit volgende access-bepalingen voor moped/mofa expliciet maken.

Dus iets in de trant van *traffic_sign=“uitritconstructie” * of een prefix in de trant van source:giveway=uitritconstructie.
Er zijn vast betere varianten te verzinnen, maar ging me even om een voorbeeld bij het principe.

Is dat iets waarmee hier geleefd kan worden, ook al vind je het zelf misschien een minder interessante drempel?

Er bestaan natuurlijk verschillende interpretaties van deze constructies, grijze gebieden en wat wordt toegevoegd moet natuurlijk onderhouden worden. Zelf vind ik dit ook niet de allerhoogste prioriteit, maar dat moet geen belemmering zijn voor andere mensen om hier moeite in te stoppen.

En anderzijds: als we de gevallen mappen die duidelijk voldoen aan de rechter gestelde voorwaarden, dan zijn het domweg dingen met een juridische betekenis die valt binnen geaccepteerde tags (give way / traffic calming) en al de bezwaren gelden voor veel meer dingen die we al wel mappen (ik zadel ons met eindeloos meer werk op door toevoegen van wandelnetwerken), grijze gebieden bestaan hier zelfs over de vraag of een verkeersbord op een andere onderbord nog wel een RVV-bord is, en zo extreem snel komen/ verdwijnen die dingen nou ook weer niet (bord plaatsen/weghalen gaat met veel minder werk dan drempel aanleggen/verwijderen).


edit: correctie highway=stop-> highway=give_way

@Multimodaal: interessante lectuur heb je gevonden. Inderdaad vreemd dat in- en uitrit niet meer gedefinieerd is.
@Peter en Andries: is traffic_calming=hump met highway=give_way_to_pedestrians een optie?

Als het eruit ziet als een uitrit en het kwaakt als een uitrit, dan is het waarschijnlijk een uitrit… maar helemaal zeker ben je nooit!

Alles is een optie, maar er hoeft geen hump te zijn en ook geen table, ook de schuine stoeprand kan ontbreken (gewoon een afritje van klinkers) en de voorrang is niet alleen dat je pedestrians voor moet laten gaan maar ook alle verkeer van links. Plus dat het van twee kanten werkt, dus ook bij inrijden voorrang voor alle weggebruikers.

  • De elementen/eigenschappen /gevolgen apart taggen vind ik ik zelf niet zo aantrekkelijk.

  • Eén node of één sectie van de al bestaande way taggen met één tag waaruit al het andere volgt, anders gaat het nooit aanslaan. Of laat ik voor mezelf spreken: anders ga ik mijn woonplaats er niet mee taggen.

  • Ik vind de observatie dat het hele geval een vorm van traffic_calming is wel juist, maar de bestaande traffic_calming tags vind ik geen van allen voldoen.

  • Als je van living_street zegt dat het niet kan omdat het al gebruikt wordt voor woonerven met een officieel erfbord, dan moet je voor give_way om dezelfde reden ook zeggen: kan niet, want dat wordt gebruikt voor een daadwerkelijk aanwezig officieel geefvoorrangbord.

Deze methoden zijn voor mij hanteerbaar en geven volgens mij qua data genoeg informatie voor eventueel routeren en renderen:

  1. Een node op het midden van de exit (vast aan de way waar hij voor geldt) met traffic_calming=street_exit of exit_style
  2. Het laatste stukje van de way (vanaf het begin van de uitrit tot het kruispunt van de ways) taggen met highway=street_exit of exit_style.
    2a. Het uitritstuk van de way gewoon highway=[whatever] laten en er traffic_calming=street_exit of exit_style aan toevoegen.
  3. De toepassing van highway=living_street (in de wiki, voor Nederland) uitbreiden met “Wordt ook toegepast voor weguitritten met een uitritconstructie”.

Toelichting bij 3: De wiki-definitie van living_street vereist niet de beperking tot straten/gebieden waar dat bord bij staat. De toepassingentabel laat veel meer variatie zien. Ik heb gezocht naar een nederlandse diskussie waarin de beperking tot beborde woonerven in beton gegoten is, maar heb dat niet gevonden.

Toelichting bij 2: Daarmee maak je een wegtype, vergelijkbaar met bv onverharde weg, wat (spreken we af) automatisch alle weggebruikers op de kruisende weg voorrang moet geven.

Toelichting bij 2b: Daarmee hou je het bestaande wegtype, maar vgl met optie 1 geef je precies aan waar de uitrit zit én kwa data hoef de renderer / router alleen de way te bekijken zonder op voorhand naar nodes te zoeken. Lijkt me een voordeel, maar ik zou er ook volledig naast kunnen zitten… dan hoor ik het wel.

Mijn voorkeur = 3:

Alles in 1x geregeld met bestaande tag
Zeer weinig werk.
Ik heb trouwens ff gekeken, 10 steekproeven gedaan: de uitritten van woonerven zijn vrijwel allemaal uitritconstructies, en worden bijna altijd meegetagd als living_street. Waarmee optie 3 al gangbare praktijk is.

Nee? Heb je een voorbeeld van een uitritconstructie zonder hump?

Ik vind trouwens traffic_calming=street_exit niet het juiste. De primaire functie is niet traffic_calming. De primaire functie is de bijzondere voorrang die geldt. Een stoplicht noemen we ook niet traffic_calming.
Dus ik pleit voor highway=street_exit op een node vlak voor de kruising.

De meeste uitritten zijn tegenwoordig bij de overgang zone 30 - gebiedsontsluitingsweg te vinden, vanwege het Duurzaam Veilig-beleid. Op die locaties heeft de uitrit niets met een (woon)erf te maken.

Zelf heb ik een sterke voorkeur voor opties 1 of 2a. Optie 2 heeft als nadeel dat het geen backward compatibility heeft. Het kan lastig ingevoerd worden zonder tijdelijk navigatie en kaarten ‘kapot’ te laten lijken. Optie 3 zorgt ervoor dat de consistente definitie van living_street wordt opgerekt naar allerlei compleet andere situaties. Het is misschien slecht uitgevoerd in Nederland, maar qua betekenis is het nu wel een erg duidelijke tag.

Dat is al gebeurd: de uitritten van woonerven zijn meegetagd als living_street. Niet onlogisch, want zo anders is het niet: het is gwoon voetgangersgebied waar je met je voertuig overheen mag als je maar alles voor laat gaan.

https://www.google.nl/maps/@51.964448,4.6072907,3a,75y,354.52h,62.33t/data=!3m6!1e1!3m4!1scZXBms0Eks-QNri-OJgTJQ!2e0!7i13312!8i6656?hl=nl

Er zijn er zat hier in de buurt, wij hebben niet zo’n konsistent verkeersbeleid dus wat je ook aan varianten wil, ik heb ze bij de hand!

Highway-tags op ways worden (bijna) nooit gebruikt voor microtagging. De hele straat is dan gewoon als woonerf getagd, tot aan de kruising. Dat het woonerfbord 10 meter van de kruising af staat, betekent niet dat dat korte stukje niet als woonerf getagd mag worden.

Daarnaast is een uitrit volgens mij geen voetgangersgebied. Je kruist de stoep, je rijdt er niet in de lengte overheen.

En dan renderen als een ikoontje?

Dus de uitritten zijn gewoon meegetagd als living_street, terwijl het daar geen Erf meer is. Dat valt gewoon binnen de omschrijving en de voorbeelden van living_street, geen probleem.

Welke kant je oprijdt maakt op een stoep niet uit. Je bevindt je op een stoep, dan gelden stoepregels.

Dat is geen uitritconstructie maar een uitrit. De kleine weg zou ik taggen als highway=service.

Degene waar ik mee begon is er ook zo een: https://www.google.nl/maps/@51.9664237,4.6073752,3a,75y,96.98h,82.37t/data=!3m6!1e1!3m4!1sNyiL_S1MFoYe8UAq9UWGYg!2e0!7i13312!8i6656?hl=nl

Dat is dus precies het verschil tussen micro-tagging (elk detail van een paar meter taggen) en macro-tagging. Normaal knippen we niet een mini-stukje van de weg af voor die paar meter tussen de kruising en het verkeersbord begin woonerf. De uitrit is dan getagd als living_street omdat de rest van de zijweg dat ook is, niet omdat het een uitrit is.

In het geval van de uitrit van een zone 30 gaat dit geheel niet op. Daar is helemaal geen sprake van een woonerf en wordt dus geen living_street gebruikt bij de uitrit.

Als de stoepregels gelden bij het kruisen van de stoep, dan zou je toch niet over de stoep mogen met de auto?