survey:date heeft alleen betekenis binnen een afgekaderd systeem waar de betekenis (min of meer) afgesproken is.
Hoewel, op een natural of een simpele amenity is het misschien wel waardevol om aan te geven dat bv het water of het bos of het bankje op een bepaald moment in ieder geval (nog) bestond. Maar over de geometrie en andere kenmerken kan je denk ik weinig met zekerheid afleiden, niet meer dan uit de geschiedenis.
Ik heb deze mapper een bericht gestuurd. Hij/zij geeft in de reactie aan dat dit nu niet meer gebeurt en dat het terecht is dat ik hier vragen over stel. Ik zal betreffende wegen samenvoegen en de link verwijderen. De foto’s zijn hoe dan ook toch wel te zien op mapillary.
1 Like
Survey_date zegt iets over de data en iets over de mapper die het heeft toegevoegd/gewijzigd maar is geen attribuut van het object en daarmee m.i. metadata waar een dataconsumer niet veel (en waarschijnlijk helemaal niets) mee zal doen.
Knooppuntnet Planner gebruikt survey:date voor weergave van knooppuntnetwerken met kleuren gebaseerd op hoe lang de survey geleden is. Knooppuntnet Planner is een eindgebruikers-toepassing. Maar andere toepassingen ken ik niet.
De betekenis is eigenlijk alleen “waargenomen”, “bestaat”. Voor de knooppuntpaaltjes mag je aannemen dat dan ook de _ref of _name klopt. Voor de routes mag je aannemen dat de route gezien is, maar ik zou er mijn hand niet voor in het vuur durven steken dat de hele relatie ook precies klopt met de markeringen. Gelukkig maakt dat voor knoopppuntroutes eigenlijk niet uit: je volgt de markeringen en dan kom je bij het volgende knooppunt uit!
Grappig dit illustreert dat er -zoals ook aangestipt in de Engelstalige wikipedia- er ook verschillende duidingen van de term metadata zijn.
De omschrijving in de geciteerde Nederlandse Wikipedia omvat ook direct waarneembare kenmerken van het omschreven object (in OSM: de feature) zelf:
Metadata zijn gegevens die de karakteristieken van bepaalde gegevens beschrijven. Het zijn dus eigenlijk data over data. De metadata bij een bepaald document (de gegevens) kunnen bijvoorbeeld zijn: de auteur, de datum van schrijven, de uitgever, het aantal pagina’s
Zaken als het aantal pagina’s zijn ook vast te stellen als je het boek in je handen hebt (net zoals je naar een knooppuntpaal kijkt of omschrijft of een route wel / niet een rondje is). En die direct waarneembare kenmerken van het object zelf worden hier ook tot metadata gerekend.
Ben het eens dat dat soort informatie van een andere orde is dan niet direct object gebonden informatie (aantal verkochte exemplaren van het boek, of “wanneer voor het laatst in de inventaris van onze boekwinkel geconstateerd”).
Misschien geeft voor ons doel hier een onderscheid in de trant van “feature gerelateerde tags” vs “mapping gerelateerde tags” minder kans op verschillende interpretaties.
En “feature gerelateerde tags” kunnen weer worden onderscheiden naar of ze wel of niet zijn af te leiden uit de (geo)data van OSM (zoals de lengte op van een way in length, was als beginner erg verrast dat ik in Qgis die echt als variabele aan elke way moest toevoegen om lengtes van groepen wegen te kunnen sommeren)
De survey:date zegt inderdaad niet zozeer iets over de feature zelf, maar wel over de mapping (en ik gebruik 'm zelf wel als eindgebruiker als indicator voor de onzekerheid over de actualiteit bij features die bovengemiddeld aan verandering onderhevig zijn)
anders dan source
Die is ook interessant, daar kan een grijs gebied zitten tussen wel/geen betrekking hebben op kenmerken van de feature zelf:
- een source:name=sign geeft bijvoorbeeld aan dat er ter plekke een bord staat met die naam erop (en kan handig zijn als er een andere mapper denkt dat de waarde in name fout is omdat het element lokaal onder een andere naam bekend is, dan kan je meerdere name-keys gebruiken in plaats van de oude waarde vervangen
- een source:maxspeed=zone30 vertelt ook iets over de reikwijdte van die snelheidslimiet; een gewoon bord vervalt bij de volgende kruising, een zone 30 niet
(en dit kan voor een volgende mapper ook verklaren waarom hij op dat wegvak zelf geen bord ziet, die limiet is correct want het zonebord kan honderden meters (en meerdere kruisingen) eerder staan
Als zulke tags helpen om de kwaliteit te verbeteren en ook om onnodige vragen tussen mappers (3 jaar later weet ik wellicht niet meer of ergens een bordje stond) of onterechte verwijdering van correcte data te voorkomen, dan zijn het wat mij betreft goed bestede bytes 
1 Like
Het is zo gelopen, het gebruik van traffic_sign op een way, omdat iemand, dat zo heeft bedacht. Het wel logisch vond. Ik het overnam. Nu later, denk ik daar anders over.
Ik vindt dat het source:traffic_sign=NL:G12a moet zijn.
De paal met daaraan bevestigd het verkeersbord, fysiek zichtbare, dat is traffic_sign=NL:G12a.
De source voor.
Wat op de way getagt is, dat is een afgeleide van wat de paal verkeersbord aan geeft. Vandaar source:traffic_sign=NL:G12a
Een tijd geleden zag ik een onderzoek met data van OSM, hoeveel verkeersborden zijn er in de landen getagt.
Daar stond Nederland aardig bovenaan in aantallen, met al zijn G11 en G12a.
Waarbij ik dacht, klopt dit wel.
Is elk stukje way, geknipt, een apart verkeersbord.
Je kan uit de OSM data niet halen hoeveel fysieke borden er getagt zijn.
Hiermee wil ik het “afgeleide” aangeven.
1 Like
Deze omschrijving is inderdaad wat duidelijker dan het onderscheid metadata vs niet-metadata. Misschien dat het onderscheid dat ik probeer te maken ook meer gebaseerd is op wat een renderer/router er mee zal doen. En dan bedoel ik renderer/router voor het algemene doel dus niet bv specifiek voor OSM-mappers gemaakte renderers.
1 Like
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…
1 Like
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:
- Het moet wereldwijd OSM-breed werken, zonder dat alle dataverwerkers alle landspecifieke details hoeven te kennen
- Oftewel, wat wij hier verzinnen moet niet puur op Nederland gericht zijn.
- Of een verkeersbordenknoop op de way geplaatst moet/mag worden, of precies op de plek waar het bord staat, vind ik minder belangrijk. Wat mij betreft hoeft dat niet wereldwijd gelijk te zijn.
- En ook of je op de weg de daar geldende verkeersborden tagt hoeft niet vast te liggen, als de uitwerking van de borden+regelgeving maar OSM-breed eenduidig getagd kan worden.
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.
1 Like
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.