Ik begrijp wel dat mappers metadata ( = “mapping gerelateerde tags”) willen toevoegen maar omdat deze allen tussen de “feature gerelateerde tags” in staan heeft dat momenteel wat nadelen.
Om die reden splits ik ze (voor eigen gebruik).
Ik begrijp ook de wens om in OSM zelf een splitsing te maken tussen deze 2 typen data maar ik vermoed dat als dit technisch al mogelijk zou zijn het in de praktijk lastig toepasbaar wordt wegens discussies over de definitie.
Als je "source:traffic_sign=NL:G12a " toevoegt (op de highway , neem ik aan) dan is het toch logisch dat er tevens een “traffic_sign=NL:G12a” is want een source zonder verwijzing lijkt mij onlogisch.
Zou je dan ook de maxspeed=* van alle highway af willen halen en vervangen door source:traffic_sign=NL:A01 of wellicht source:traffic_sign=NL:A01-50 ?
Ik zie de NL:G11, NL:G12a en NL:G13 als onderverdeling van highway=cycleway waar m.i. niets mis mee is. Dit is nationaal toepasbaar en een mooie oplossing om het onderscheid te kunnen maken tussen de verschillende fietspaden. Dat ze zijn afgeleid van een verkeersbord is inherent aan hoe een wegbeheerder duidelijk moet maken welke regels er gelden op de wegen.
Dan zouden data users overal ter wereld de NL verkeersborden en hun wettelijke gevolgen moeten kennen en toepassen, om de snelheidsbeperkingen te kunnen gebruiken/weergeven.
Net als met de access tags, taggen we hier de voor dat stuk weg geldende maxspeed die voortvloeit uit de bebording/markering/regelgeving, zodat data users wereldwijd kunnen werken zonder alle nationale en lokale verkeerstekens en verkeersregelgeving te hoeven kennen.
We mappen trouwens ook niet de weg, maar een streep die de weg voorstelt, dus eigenlijk is dat een meta-object…
Ik vind dat Allroads wel een punt heeft:
als ergens een straatlantaarn staat, dan taggen we het fysieke object met highway=streetlamp en de weg die door de aanwezigheid van die lantaarn de eigenschap krijgt dat die verlicht is, krijgt de tag lit=yes
Bij traffic_sign gebruiken we letterlijk dezelfde tag zowel voor het fysieke object (als feature-tag) als voor de eigenschap die een ander fysiek object daardoor krijgt (als property-tag).
Het zou netter zijn geweest als de twee tags (feature vs property) een verschillende bewoording hadden gehad.
Een stuk weg kan bovendien meerdere verschillende verkeersborden hebben, sterker nog dat is heel vaak zo. Dit werkt dus alleen als je de toepassing heel erg inperkt, tot zeg maar fietspaden. Willekeurig voorbeeld, natuurlijk 
Of je neemt een lijst borden op in de value.
Anderzijds vind ik het ook weer niet zo erg. Je kan ook zeggen: het verkeersbord zelf is highway=traffic_sign, traffic_sign=… en dan is traffic_sign een property tag bij de impliciete hoofdtag voor verkeersbord.
Als een weg meerdere verkeersborden en/of onderborden heeft, dan kun je dat gescheiden door puntkomma’s in de traffic_sign zetten Zie bijv. deze weg Way: Beekhuizenseweg (6835791) | OpenStreetMap met nog een leuk foutje in de conditional
Ja, highway way, die source is fysiek aanwezig, naast de rijbaan (paal), alleen de source zelf is vaak niet getagt in OSM. Dat hoeft ook niet.
Nee, want dat is de werkende (afgeleide) net zoals we ook moped=designated taggen.
En multimodaals voorbeeld: lit=yes.
maxspeed=* Het belang van “human readable” values, het naast elkaar gebruik van leesbaar en codes.
Die duidelijke verkeersbordcode, heb je nodig om het afgeleide te kunnen controleren.
Daar zijn we ooit het verkeersborden draadje mee begonnen. Duidelijkheid ook bij de fietspaden, wat goed wordt gebruikt. Mede door presets. taginfo wereldwijde verhouding.
Dus ons kikkerland loopt voorop met het aantal node/waystukjes.
In General forum, is een lange discussie over
traffic signs national id and human readable values (traffic_sign=* and traffic_sign:id=*
Daar wil men ook zaken omgooien, ik vroeg me dan ook af, klopt het en naar aanleiding van deze topicstart over “meta data” en de verhouding tot source. Wat moet je gebruiken als key.
In het verleden heb ik vaak gecommuniceerd met deze, spaanse, osm bedenker.
Dit omdat hij ook een verkeersborden presets had gemaakt voor vele landen. (niet overal kloppend)
Hij is voorstander van om alle verkeersborden met node te taggen op de highway wayline. En dan aangeven of het verkeersbord links of rechts van de weg staat, waarbij hij aan geeft dat 3D Kenzi het mooi kan verwerken.(visualisatie, het naast de weg zetten, dan moet er ook een afstand aangegeven zijn, hoe ver uit de wayline of placement wayline het bord staat) Daarbij vraag ik mij af hoe controleerbaar is dat. We hebben al moeite om op hekjes de breedte aan te geven.
En zodoende een puntwerking (node) wil creëren in een bepaalde richting.
Waar we vroeger in het draadje, ingang bij weg Ekris bespraken, eenzijdige C bebording. Met als uitkomst, zet het afgeleide, maar op een klein stukje weg, zodat routeringstechnisch omkeren mogelijk blijft van de andere kant.
In de basis tag je in Openstreetmap, zaken, fysiek waar het staat, Dat geldt mijn inziens ook voor verkeersborden. (op node naast de weg) Wat we minder doen vanwege NDW verkeersborden database en werk.
Deze (Spaanse) alles op de wayline methode, hoe moet ik daar tegenaan kijken, immers we hebben wel een source tag nodig om de werkende afgeleide tagging (accces=, maxspeed=) te kunnen taggen en te controleren.
Vandaar dat ik zit te denken aan source:traffic_sign=* en bekijk ook gelijk die andere variant traffic_sign:id, waar moet die dan staan, wat de zij gevolgen van zo’n verandering.
Ik ook, maar hoe weergeven.
Als men daar ovet gaat stemmen.
traffic_sign:id=NL:G12a
Na een proposal kan er zomaar een keycombinatie zijn. Met als doel het op een bepaalde manier te gebruiken. Men wil zelfs het andere, verwijderen, deprecated.
Dat blijf je altijd houden, met de meerdere scheidingstekens ( ; ) in de value string.
Wat is dan gewenst? Of we laten alles, zoals het nu wordt gebruikt.
En waar staat deze op de highway way?
Afwegingen. De materie van verschillende kanten bekijken.
Dat vind ik een mooie oplossing!
Ik kende die highway=traffic_sign niet omdat die niet staat bij https://wiki.openstreetmap.org/wiki/Key:highway#Values
Maar via de internationale taginfo zie ik dat die al wel in beperkte mate wordt gebruikt en dat de tag wel een eigen wiki-pagina heeft.
In Nederland lijken we deze nog niet te gebruiken (taginfo) , terwijl we al wel ruim 28.000 nodes hebben met traffic_sign=
Wellicht goed om deze toe te voegen aan de wikipagina’s van https://wiki.openstreetmap.org/wiki/Key:highway#Values
Hmm, zie dat op https://wiki.openstreetmap.org/wiki/Key:traffic_sign#Possible_tagging_mistakes highway=traffic_sign als een “possible tagging mistake” wordt omschreven, maar in de wiki en ook in de Talk geen verklaring daarvoor. Ik zou het -als aanvulling- juist een verbetering vinden. Kans op lange discussies dus, heeft iemand energie / tijd daarvoor?
Precies en volledig taggingsysteem voor alle verkeersborden heb ik niet, maar belangrijk vind ik:
Voor de Nederlandse fietspaden geldt dat de drie fietspadborden typisch Nederlandse subtypes aanduiden. Dus het bord onderscheidt de types, maar dat heeft OSM-breed geen gevolgen, die kijken alleen naar de access tags. Uit de access tags kan je zien voor welke voertuigen het pad bedoeld is en welke voertuigen er daarnaast ook op mogen.
Een subtag zou daarnaast ook kunnen, die zou dan de designation aanduiden, maar als dat alleen in Nederland van toepassing is dan heeft het MI geen toegevoegde waarde want dat zit ook al in de access tags.
Mogelijk kunnen dergelijke situaties dan ook opgelost worden:
Ik rijd in Frankrijk een dorp uit: max snelheid verandert na het bord einde bebouwde kom van 50 naar 90. OsmAnd op mijn dashboard geeft echter eerst nog 70 aan.
Ik kijk daarop in mijn achteruitkijkspiegel en zie dat op het punt waar ik het dorp uit rijd en de max 90 wordt, voor het verkeer dat het dorp in rijdt een bord 70 staat.
Samengevat: 1 weg, 2 rijstroken met in beide richtingen een verschillende max snelheid.
Daar is maxspeed:forward=90 en maxspeed:backward=70 voor.
Pragmatisch. Van 50 versnellen naar 90 heb je altijd even voor nodig, en je zit er niemand mee in de weg. Van 90 ineens naar 50 moet je op je rem gaan staan en dat is risico. Dus laten ze je tijdig eerst naar 70 gaan.
Ik snap je punt maar ik ben wel benieuwd welke waarden we dan op de highway willen zetten. Zoals we het nu doen heeft het als voordeel dat het 1 op 1 te linken is aan het verkeersbord. Overigens ben ik gestopt met het mappen van losse verkeersborden omdat het m.i. niet bij te houden is. Ik weet zeker dat er een groot aantal niet meer juist zijn omdat bv een G12a inmiddels een G11 geworden is. Ik heb zelfs overwogen om alle losse nodes met traffic_sign die ik heb toe gevoegd te verwijderen omdat er te weinig mappers zijn die dit kunnen/willen onderhouden. Voor traffic_sign op fietspaden lukt het gelukkig wel redelijk goed.
edit: typo
In theorie is het een mooie oplossing maar ik denk dat het in de praktijk niet zal werken omdat al die losse verkeersborden nooit goed bijgehouden zullen worden en dan hun waarde zullen verliezen.
Goed dat je dat doet hoor. Het is vrij lastige materie waarbij een theoretische oplossing weer afgewogen moet worden t.o.v. een praktische toepasbaarheid/wenselijkheid. De consensus , als die er al komt, zal er ergens tussenin komen te liggen denk ik. Het blijft schipperen.
Navigare is Latijn voor schipperen. Navigatie=navigatio=“het schipperen”. Best wel toepasselijk!
Allereerst zal ik zeggen Sorry voor mijn slechte Engels en het gebruiken voor vertalen met Google Translate.
Ten tweede: waarschijnlijk zijn verkeersborden niet het belangrijkste van de wereld, maar ik weet niet of er enig element in twijfel zou worden getrokken over de kaart zelf. Op sommige plaatsen kun je lezen “het in kaart brengen van verkeersborden is niet nodig”. Ik ben het daar niet mee eens.
Ten derde: de optie die ik had gekozen met betrekking tot verkeersborden is gevestigd in een aantal gebouwen:
OSM is realiteit, verkeersbord is een knooppunt dat zich op een specifieke plaats bevindt. Juist…maar: Als onafhankelijk knooppunt heb je nodig dat de richting op het verkeersbord gericht is (met JOSM zou het gemakkelijk kunnen zijn, niet op straat, ik zal geen kompas gebruiken om in kaart te brengen.) Zo niet, dan heb je een relatie nodig om op een of andere manier uit te drukken in welke richting u dit verkeersbord zult tonen. Omdat een verkeersbord op een manier werkt, is het gemakkelijk om deze op deze manier te lokaliseren, als oorspronkelijke stop, voorrang geven en stadslimiet (ik weet dat de wiki evolueert, maar toen deze twee tags een van de eerste knooppunten waren die waren getagd met snelwegsleutel in de wiki, kan “verkeersbord” lezen. Toen ik in 2013 begon, was dat zo. Ook kunt u de tagrichting in de wiki vinden.
Het idee was dit uitgangspunt plus het Finse systeem van orde te nemen, waar je meer dan één verkeersbord hebt (ik heb het Finse systeem gezegd omdat je het op die pagina van de wiki kunt lezen https://wiki.openstreetmap.org/wiki/Finland/ Verkeersborden #How_to_Map)
Side was een oplossing die Kendzi me hielp Kendzi3D te gebruiken (hij deed het model met blender, ik weet niets van programmeren, zoveel mensen hebben me door de jaren heen geholpen, ook Allroads.) om in een relatieve positie van die manier de belangrijkste te lokaliseren reden voor het bestaan van het verkeersbord (zoiets als: we brengen de boom in kaart, maar moeten we het gat in kaart brengen dat is gevuld met beton om de boom in een stad te plaatsen?)
Met het voorstel was het nooit mijn bedoeling om welk systeem dan ook af te schaffen. Waarschijnlijk is mijn Engels niet zo goed om op te merken dat het mijn voorkeur was, de voorkeur van de persoon die het voorstel doet. Ik kan denken wat ik wil, maar de Gemeenschap kan het voorstel gebruiken, en de methoden op de manier waarop schattingen mogelijk zijn (zoals de Finse optie, of jouw optie (verkeersbord in kaart brengen … als een tag op een gesegmenteerde manier). Ik heb het vetgedrukt gemaakt in het voorstel, maar mensen blijven zeggen dat ik iets wil afschaffen waar ik nog nooit over heb nagedacht (probeer het systeem af te schaffen door de OSM-gemeenschap van één Europees land te gebruiken - veel succes).
Verkeersbord:id was niet van mij. Ik heb het gevonden met honderd resultaten in Taginfo (ook iemand schreef in het Duits dat het in 2008 vermeldde) en het begint de noodzaak van kaartverkeersborden met zijn code (voor geëxperimenteerde mappers) en/of de voor mensen leesbare waarden (nieuwe mappers geleid door completers of iD-presets.) Ik weet niet wat de oplossing is, maar we hebben 20 voor mensen leesbare waarden en Nederland is een van de eerste resultaten met behulp van ISO-verkeerswetcodes.
De vraag hier is of u één verkeersbord in kaart brengt… of twee. Omdat elk verkeersbord een betekenis heeft, is het moeilijk om het in een “unieke combinatie” te verenigen, zelfs taginfo is onmogelijk om het te verwerken. Op dezelfde positie, op dezelfde plaats, heb je maar één verkeersbord (voor mij is elk verkeersbord, dat zijn eigen code had in de verkeerswetgeving van elk land, zo belangrijk om het in kaart te brengen.)
Ik weet niet wat daar de perfecte oplossing voor is. Het omzetten van het verkeersbord naar snelweg=verkeersbord zou een enorme uitgavebeweging zijn. Zoals ik met het voorstel heb getest, is het moeilijk om zulke grote veranderingen door te voeren.
Ik ben het ermee eens dat de beste oplossing een wereldwijde oplossing zou zijn. Om deze reden zijn ISO-codes met identificatie van de nationale verkeerswetten en voor mensen leesbare waarden een goede optie (en ik wil de twee mogelijkheden behouden - niet twee verplichtingen).
De meerwaarde is ook de specifieke afbeelding van dat verkeersbord. Er zijn vergelijkbare verkeersborden, maar niet dezelfde, en voor grafisch ontwerp is het interessant om elk specifiek ontwerp in kaart te brengen, niet alleen de gevolgen van het verkeersbord in de weg, maar ook van het verkeersbord zelf.
Als u het verkeersbord in kaart brengt, zal OSMand nooit een fout maken, want in werkelijkheid is het verkeersbord hetgene dat u laat zien welke snelheid u moet rijden.
Overigens ben ik gestopt met het mappen van losse verkeersborden omdat het m.i. niet bij te houden is. Ik weet zeker dat er een groot aantal niet meer juist zijn omdat bv een G12a inmiddels een G11 geworden is. Ik heb zelfs overwogen om alle losse nodes met traffic_sign die ik heb toe gevoegd te verwijderen omdat er te weinig mappers zijn die dit kunnen/willen onderhouden. Voor traffic_sign of fietspaden lukt het gelukkig wel redelijk goed.
Ik denk niet dat regeringen die wegen aanleggen het eens zijn met dat “onmogelijk te onderhouden”. Oké, het is moeilijk, maar als een verkeersbord verouderd is, zal de overheid dit waarschijnlijk wijzigen, dus met een viaductquery is het mogelijk om de code bij te werken. In de straten hebben we kleine en massieve elementen als vuilnisbakken, bomen, verkeerslichten, straatlantaarns en ik ken geen enkele mapper die zegt: hé, het is onmogelijk om de vuilnisbakken van heel Nederland te beheren. Moeten we stoppen met het in kaart brengen van deze gemeenschappelijke elementen? Wat kunnen we doen met de mensen die met deze elementen ‘werken’?
Ik stel niets spannends of origineels voor 
(zoals @Peter_Elderson al hier schreef en zoals ook wordt voorgesteld in deze wiki )
OK helder. Ik was even bang dat we de traffic_sign niet meer op de highway zouden mogen zetten.
Zoals eerder gemeld ben ik gestopt met de losse nodes voor verkeersborden dus die wiki is aan mij niet besteed. En al helemaal niet als daar staat dat we ook de metadata tag " source:maxspeed" moeten mappen. Vroeger kon je gewoon mappen wat je zag maar tegenwoordig lijkt het erop dat er voor iedere tag een verantwoording moet worden opgenomen met een losse meta tags "source:xxxx = " . Als ik die behoefte al zou hebben dan zou ik het gewoon toevoegen op de changeset zodat een ieder die wil weten waarom ik iets map het daar kan vinden.
Met het beschikbaar zijn van de NDW dataset is het ook grotendeels overbodig geworden.
Ik ben wel benieuwd hoe lang die NDW dataset up-to-date blijft, wat ik begrijp is dat de begintoestand is gebaseerd op een vrije recente scan langs alle wegen maar dat vanaf nu wegbeheerders het moeten gaan bijwerken.
Als NDW up-to-date blijft dan zou ik het geen gek idee vinden om een keer de NDW dataset te importeren en daarna blijven syncen.
Wat betreft “verkeersborden met node te taggen op de highway wayline”, ik zag dat voor het eerst met een A1-30-ZB bord ergens in Friesland en sindsdien ben ik het meer en meer gaan gebruiken omdat het voor maxspeed taggen handig is:
Behalve NL:A1-30-ZB en NL:A1-60-ZB gebruik ik ook highway=city_limit.