Voorstel: NDW verkeersbord-ID’s optioneel toevoegen aan OSM-verkeersborden

Communities Nederland (Netherlands)
,
1

Beste OSM-community,

Ik wil graag een voorstel doen om optioneel NDW-verkeersbord-ID’s toe te voegen aan verkeersborden in OpenStreetMap. Het gaat hierbij om de unieke ID’s die te vinden zijn in de NDWVerkeersborden, bijvoorbeeld:

:link: Wegkenmerken - NDW

In deze URL is cd6bc8f4-43e4-4bee-bdbe-a1dee036a6ea het ID van een specifiek verkeersbord in de NDW-dataset.

Voordelen:

Betere koppelbaarheid met officiële (open) data van NDW.

Uniformiteit bij het documenteren van verkeersborden.

Toekomstige data-analyse en synchronisatie met overheidsdata mogelijk. Bijvoorbeeld als het bord in de overheidsdata wordt verwijderd.

Ondersteuning van QA-tools en validatie van verkeersregels.

Voorstel:

Voeg een optionele tag toe aan verkeersborden in OSM zoals:

ndw:traffic_sign_id=cd6bc8f4-43e4-4bee-bdbe-a1dee036a6ea

Of – indien een andere naam beter aansluit bij conventies – iets als:

ref:ndw=cd6bc8f4-43e4-4bee-bdbe-a1dee036a6ea

Toepassing:

Alleen gebruiken als er een duidelijke match is tussen het bord in OSM en de NDW-data. Het is niet verplicht, maar biedt meerwaarde voor wie met open data werkt of verkeersborden nauwkeurig wil registreren.

Ik hoor graag jullie mening! Zijn er bezwaren, aanvullingen of andere suggesties qua tagging? Of bestaat er al een conventie hiervoor die ik over het hoofd heb gezien

2

Vraag me in dit geval altijd af wie dat gaat toevoegen. De over grote meerderheid van onze mappers zal dat nooit toevoegen.

Wat is de doelgroep voor dat gegeven?
Ik zie nog geen renderers of kaartgebruikers die er iets aan hebben om dat gegeven te kunnen raadplegen.

Dat iets kan worden vastgelegd in OSM wil nog niet zeggen dat we dat ook moeten doen.

3

Meestal mappen we de verkeersborden niet eens los, maar mappen we de verkeersregels die eruit volgen op relevante delen van het wegennet. Naar mijn idee levert dit idee vooral extra onderhoudswerk op.

2 Likes
4

Niks is zo onstabiel als een verkeersbord. Binnen een beetje stad worden er constant borden verplaatst, vernield, herplaatst, aangepast, of weggehaald. De uitwerking van de borden is stabieler; iets is een bromfietspad of een 30 km/h-zone, en dat verandert niet heel snel. Waar het wel verandert, wordt het ook wel opgepikt. Bij losse verkeersborden is dat niet echt het geval.

OpenStreetMap is nu geen database met daarin alle verkeersborden, of zelfs maar 5% van de borden. Deze vraag is eigenlijk pas relevant wanneer dat wel het geval zou zijn. Of dat ook wenselijk is hangt van veel meer factoren af.

2 Likes
5

Er worden verkeersborden in OSM gemapt, maar niet heel veel of heel systematisch. We mappen vooral de uitwerking van de borden op het wegennet, dwz toegang, voorrang, snelheid etc als tags op een wegdeel; daarbij worden ook wel referenties getagd naar de verkeersborden. In de vorm van het nummer in div officiële en afgeleide publicaties, in de vorm NL:Xn. Dat is een redelijk stabiele verwijzing: de uitvoering van de borden wijzigt wel eens, maar het Xn nummer blijft hetzelfde.

VZIW doet geen enkele end-user-toepassing iets met die refs: het kan wel handig zijn bij het mappen in Nederland, bijvoorbeeld bij het mappen van fietspaden in JOSM mbv de speciale NL fietspad-presets.

Je mag het NDW-id-nummer wel mappen, maar mijn vraag zou zijn: levert het Id-nummer een verbetering tov de refs, voor eindgebruikers of mappers?

1 Like
6

Ook ik ben geen voorstander van het mappen van losse verkeersborden (node) in OSM. Ik heb het vroeger veel gedaan voor fietsborden (G11, G12a, G13) als een soort van verantwoording waarom ik bicycle=*, mofa=* etc. mapte op de highway. Zie het als een soort source tag. Tegenwoordig doe ik dat niet meer en eigenlijk zou ik al mijn losse traffic_signs moeten verwijderen want… welke data consumer doet er iets mee en wie houdt het nog bij?

We hebben inmiddels al heel veel manieren om die borden te gebruiken.Dagelijks wordt er een geopackage klaargezet die je in Qgis kunt gebruiken.Er is een Qgis plugin om de borden te tonen, selecteren etc. en daarvandaan naar JOSM te springen om snel te editen. En zo zijn er ongetwijfeld nog wel een paar andere manieren om deze data te gebruiken om OSM te verbeteren.

Ik denk dus dat het meerendeel van zowel mappers als dataconsumers niet zitten te wachten op al deze data in OSM.

1 Like
7

Ik vind het op zich helemaal niet zo’n gek voorstel van @adam020 : we taggen verkeersborden, zowel als node en -nog veel vaker- de implicaties daarvan op highways. De koppeling met NDW-ref geeft kansen voor verschil-detectie, zowel om huidige fouten op te sporen als om nieuwe wijzigingen te detecteren die we anders missen.

Dat er nu geen applicaties zijn die dat gebruiken, dat is natuurlijk ook een kip-ei-probleem. Zo’n koppeling met NWB-id kan juist ook een manier zijn om de kwaliteit van de bestaande verkeersbord-nodes in OSM te kunnen blijven checken (staan ze er nog?)

Ik zou zeggen: als je hier iets mee wil, start eens op een proefgebiedje (met aanvullenden tags op bestaande OSM-nodes, geen grote import van nieuwe nodes), en laat de een aantal opties / uitkomsten zien.

Een interessante eerste vraag is: welke huidige verkeersbord-nodes in OSM zijn te matchen met een NWB-bord id met status “verwijderd” ?
En is dat een reden om de node - en implicaties op de highway in OSM aan te passen?

Voor wijzigingen in de toekomst waar NWB een nuttige bron is kan je je wel afvragen of een andere manier van koppelen aan bord-id niet kansrijker is:

Als je gewijzigde / nieuwe borden in NWB koppelt aan locatie in plaats van bord-id in OSM, dan kan je aan veel meer OSM-wegvakken koppelen, namelijk ook de wegvakken waarbij we geen traffic_sign node in OSM hebben. Dan zou je de verschildetectie wellicht ook kunnen doen zonder aan de voorkant extra data in OSM op te nemen

Mijn advies zou wel zijn om heel voorzichtig te zijn met automatische koppelingen van verkeersbord-nodes aan wegvakken. Heb daar best wat voorbeelden van bekeken en dat gaat vaak niet goed, komt vaak toch nog best wat mensenwerk bij kijken om te bepalen op welk wegdeel een bord betrekking heeft en tot hoe ver dat bord doorwerkt.

Die tweede variant lijkt me beter aan te sluiten bij de tagging-conventies in OSM, zie

PS

We hebben toch meer traffic_sign nodes in NL dan in aanvankelijk dacht, zo’n 39k (tov 184k vermeldingen daarvan op lijnstukken, 1 node kan natuurlijk op meerdere lijnstukken van toepassing zijn). 14k van die 39k zijn voor komborden, daarna veel A1 , B6 en G-fietspadborden

1 Like
8

Die mogelijkheid hebben we ook al zonder dat deze losse verkeersborden in OSM staan. Die verschillen detectie worden dagelijks al op diverse manieren gedaan. In deze lijst vind je diverse NDW (verkeersborden) kaartjes/WMS met “fouten” in OSM. De vraag is … wie gaat die verschillen allemaal bekijken en oplossen? Hebben we daar binnen OSM voldoende mensen en draagvlak voor? Dat is m.i. nu al een probleem voor de traffic_sign implicaties op highways. Het laat zich raden wat dit gaat betekenen voor de kleine 2 miljoen NDW nodes mochten die ooit allemaal in OSM komen.

Die NDW data is nu al vrij eenvoudig verkrijgbaar bij de bron dus als een data consumer dat wil hebben zullen die dat daar halen. Dat geldt uiteraard alleen voor NL maar welke buitenlandse afnemer wil er iets doen met NL losse verkeersborden? Natuurlijk .. in theorie kan dat. Maar als we echt die losse nodes in OSM willen opnemen moeten we wel balans nut/noodzaak vs inspanning voor de community meenemen. Voor mij is duidelijk naar welke kant de balans zal doorslaan.

Natuurlijk maakt iedereen een afweging maar bij mij zou dit niet op mijn prioriteitenlijstje staan.

1 Like
9

Ik vermoed dat we het over twee verschillende dingen hebben. In het bericht van @adam020 lees ik niet iets over importeren van alle bord-nodes (zou ik ook niet direct voorstander van zijn, de implicaties van die borden op highways hebben voor mij ook prioriteit), maar wel over het toevoegen van tags aan bestaande OSM-data, met als doel :

En als ik zag hoe wisselend de resultaten van het automatisch koppelen van de implicaties van bord–nodes aan wegvakken eerder ging, dan lijkt dit me wel de moeite van het onderzoeken waard (maar misschien is dat ondertussen heel erg verbeterd? Als dat nu wel goed zonder koppeling via bord-id op osm-node of osm-wegvak kan, dan is dat alleen maar mooier.)

Zou toch mooi zijn als er uit mutaties in NWB-bordenbestand een zinvol gefilterd checklijstje kan komen waar we in OSM kunnen kijken of wij aan onze kant nog iets moeten aanpassen.

PS
De link naar dit kaartje werkt bij mij momenteel niet:

10

Het ging mij er meer om dat ik met het beschikbaar komen van de NDW data geen heil zie in het opnemen van losse traffic_sign nodes in OSM. Handmatig of geautomatiseerd/gesynchroniseerd. Er zijn nu voldoende middelen om implicaties te mappen op wegdelen. Als we nu NDW-ids willen opnemen in OSM kun je er op wachten dat er straks nog meer losse traffic_sign gemapt gaan worden en dat heeft m.i. weinig nut.

Geen idee wat er aan de hand is. Bij mij werkt het wel en de kaart staat op “public” .

TS
TS1187×773 306 KB

TS_Public
TS_Public647×278 22.4 KB

11

Hoi, webkaartje doet het ook hier weer :+1:

Geen idee wat er speelde, andere kaartjes in die lijst deden het hier wel. Nu tijdje op pad, als ik weer thuis ben zal ik er eens rustig naar kijken

Had eerder gemist dat jouw geopackage met borden nu dagelijks wordt ververst, top werk :star_struck: !

(en dan snap ik ook dat je zegt dat er al veel bestaande mogelijkheden zijn om deze data te gebruiken die we kunnen benutten voor dat we nieuwe tags gaan toevoegen) .

Misschien goed om die dagelijkse update ook te vermelden bij de startpost in dit draadje?

https://community.openstreetmap.org/t/ndw-verkeersborden-geopackage-qgis/7594

En als je een permanente connectie maakt (zoals hieronder beschreven), betekent dat dan ook dat je automatisch de nieuwste versie van het bestand raadpleegt en deze niet steeds handmatig hoeft te downloaden? Of is die connectie met een bepaalde versie van het bestand en moet je wel zelf iets doen om naar de actuele versie over te gaan?

12

Ik was ook op pad vandaar de late reactie.Mooi dat het kaartje weer werkt. Om e.o.a. reden kan ik die oude post niet editen om aan te geven dat het dagelijks ververst wordt. Heel erg is dat niet want de Verkeersborden Qgis plugin is wellicht voor de meesten een betere optie.

Voor zo’n “permanente” connectie is het wel nodig de geopackage te downloaden (als vervanger van de oude met de zelfde naam en locatie). Je kunt een Qgis projectbestand maken (met al jouw gewenste instellingen en opmaak) die dan telkens verwijst naar die geopackage waardoor je weer “actueel” bent.

Overigens moet je dat “actueel” wel met een korrel zout nemen want er zitten nog best veel niet bijgewerkte borden in dat bestand. Ga er dus zeker niet vanuit dat het allemaal klopt.

1 Like