Een zeer groot deel van de getagde wegen in Nederland is afkomstig uit de AND-import. De huidige kaart van Nederland is voor een belangrijk deel een evolutie van deze data en dus niet ‘nieuw’ getagd op basis van afspraken zoals jij die noemt. Ik vermoed dat de AND-data geen onderscheid maakte tussen unclassified en residential wegen en op veel plekken heeft niemand de moeite genomen dit later aan te passen. Wat niet zo vreemd is, aangezien bij de meeste afnemers/renderers er weinig tot geen verschil is tussen beide classificaties, zowel visueel als functioneel.
Jazeker, in de basis:
woonstraat = residential
erf = living_street
Uit jouw onderzoek blijkt dat deze afspraken niet altijd worden nageleefd. Tja, dat is ook OSM, maar onvolkomenheden in de bijdragen van anderen kunnen worden gecorrigeerd.
Als je een uitritconstructie zou mappen als een kort stukje highway=living_street lijk je het gewenste effect te krijgen. Binnen een met borden gemarkeerd erf (voorheen woonerf) mogen voetgangers de gehele breedte van de straat benutten om te lopen en te spelen. In de praktijk lijkt dit ook voor een trottoir te gelden, ook ter hoogte van een uitrit van een woonhuis of als onderdeel van een uitritconstructie: je mag stilstaan op het trottoir, je mag links en rechts lopen en over de breedte. Kortom: je hoeft de route niet vrij te houden maar pas vrij te maken als dat nodig is.
Een erf is een wegdeel waarop bepaalde afwijkende verkeersregels gelden. Een uitritconstructie is een constructie BINNEN een wegdeel. Een uitritconstructie bevat een trottoir die de weg kruist, binnen een erf ontbreken trottoirs.
Als je het juist aangeven van de werkelijke infrastructuur ondergeschikt maakt aan het effect voor de kaart/routering, dan botst dit (althans in mijn beleving) met je redenering in de andere discussie over landuse/landcover. Een uitritconstructie is niet ‘een kort stukje erf’.
Denk ook aan de verwarring voor navigatie als je de melding krijgt: “u rijdt nu een erf binnen” en enkele seconden later “u verlaat nu een erf”.
Het was wel een interessante optie om te onderzoeken maar uiteindelijk is het al niet werkbaar omdat er wel degelijk een belangrijk verschil in effect is.
Een uitritconstructie beïnvloedt de voorrang t.o.v. de kruising of de kruisende weg (incl. trottoir) meteen grenzend aan de uitritconstructie. Een erf beïnvloedt alleen verkeersregels BINNEN het erf.
Dus als bij het begin van een zijstraat een bord staat van begin/einde erf dan heeft die zijstraat gewoon voorrang van rechts… tenzij een uitritconstructie is toegepast (of tenzij het een voorrangskruising is uiteraard).
Dus behalve het feit dat er meestal geen ruimte is om het verkeersbord begin/einde erf te plaatsen tussen uitritconstructie en kruisende weg, is dit ook niet nodig omdat erf en uitritconstructie los staan van elkaar.
Verder is het zeker waar dat er nog een grote inhaalslag is te maken in de classificatie van wegen binnen de bebouwde kom. Residential zou in de meeste dorpen en steden overheersend moeten zijn en unclassified weinig voorkomend.
Een uitritkonstruktie is wel degelijk een een wegdeel. Het is juist niet een ding op de weg, zoals een drempel, een streep of tekens en borden; dat stuk weg ís een uitritconstructie, een stuk weg uitgevoerd als ware het een uitrit. Meestal is hij zo breed als de weg waar hij het einde van is.
In het buitenland wordt de uitrit/inrit rustig als onderdeel van de living_street genomen, de borden staan dan buiten de uitrit zeg maar. Vaak zijn er helemaal geen duidelijke regels. De aanwezigheid van het bord is vaak niet wat bepalend is. ik heb gezocht naar duidelijke Nederlandse afspraken, maar die lijken er niet te zijn. Je zou MI best kunnen afspreken om de uitritten erbij te nemen. Maar dat stel ik niet voor, ik stel wel vast dat het taggen van het laatste stukje weg voldoende data geeft om de situatie vast te leggen tbv renderen en routeren.
Desalniettemin, het zou handiger zijn om een speciale highway=[goed woord voor uitritconstructie] te hebben. Ik zou er dan wel voor zijn om het te taggen zoals ik met een stukje living_street gedaan heb, dus niet allemaal losse kenmerken of regels aan willen geven, met kruisingen, voorrangsaanduidingen met extra voetgangersuitbreidingen, drempeltypes e.d.
Gewoon het laatste stukje weg als uitrit benoemen, geeft alle informatie die er nodig is, de regels en gevolgen kunnen gewoon beschreven en voor renderen en toepassingen gebruikt worden.
Bijvoorbeeld:
highway=exit_way
highway=exit_type
Ik denk dat ik voor exit_type zou gaan.
Rendering: gelijk aan living_street en pedestrian.
Routering: doorgankelijk voor verkeer.
Rechts rijden blijft gelden.
Voorrang: verkeeer komend van exit_type moet voorrang geven aan alle verkeer.
Op, bij het oprijden, en bij het verlaten van een wegdeel van exit_type moet rijverkeer alle andere weggebruikers voor laten gaan.
Wat ik eigenlijk wilde aangeven is dat een erf niet zomaar op een kort stukje weg wordt toegepast en een uitritconstructie wel. Verkeerstechnisch zou je een uitritconstructie als wegdeel kunnen beschouwen maar een drempel of verhoogde kruising valt daar dan ook onder, naar mijn idee. In de BGT zie ik ze allemaal als aparte vlakken aangegeven.
Verder is het net hoe je ertegenaan kijkt. Als je de constructie benaderd vanuit het doorlopende trottoir dan hoort de uitritconstructie primair bij de kruisende weg want het trottoir hoort immers bij die weg. Als ik kijk naar een uitritconstructie in mijn dorp dan staat die in de BGT als één vlak met als functie Voetpad. In een andere gemeente zag ik zo’n vlak dan weer aangegeven als Rijbaan lokale weg en in weer een andere gemeente staat geen functie aangegeven. De uitritconstructie wordt dus ook door gemeenteambtenaren met verschillende ogen bekeken.
Het knippen van korte stukjes weg ben ik niet erg enthousiast over. Voor rendering en routering zou een node kunnen volstaan net als bij een drempel of verhoogd kruispunt (stel je voor dat men die allemaal aan vier kanten gaat verknippen…).
Voor de doorwerking van de voorrang begrijp ik dat het handig kan zijn als het als wegdeel aansluit op de kruisende node, al kan dat volgens mij net zo goed met de toevoeging van highway=give_way op een node die ook de uitritconstructie zelf aangeeft.
Ik begrijp het praktische nut van die voorrang nog steeds niet goed. Krijg je dan een melding van de navigatie “u moet hier alle andere weggebruikers voor laten gaan”?
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)
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:
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
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:
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.
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:
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).
@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:
Een node op het midden van de exit (vast aan de way waar hij voor geldt) met traffic_calming=street_exit of exit_style
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.
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.
