NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

Frankl2009 · 2014-02-02 12:29:41

PeeWee32 wrote:

PeeWee32 wrote:
Het voordeel van taggen als punt is dat je niet hoeft uit te zoeken tot waar de restrictie geldig is. Als je zo'n bord ziet kun je het taggen met de forward/backward en that's it.
Frankl2009 wrote:
Het probleem is dat je hierdoor de betekennis van de RVV-borden cat. C verandert van "Geslotenverklaring" naar "Inrijverbod".
... Het verschil tussen een "Geslotenverklaring" en een "Inrijverbod" zie ik niet zo. Volgens mij geldt toch gewoon dat als je zo'n bord ziet dat voor jou van toepassing is je er niet voorbij mag rijden.

Dat klopt. Als je daar rijdt, zie je dat je daar niet mag komen, en doe je dat niet. Basta. Maar daar gaat het me niet om.

Nu kom ik dit tegen als OSMer. (Want net als bij Allroads en zijn vraag aan de bevriende politeagent, vind ik het uitmaken of je daar langs komt rijden of dat je probeert kaartgegevens te leveren voor een betrouwbare kaart o.i.d.).

Als ik daar kom als OSMer, zie ik dat [categorie] niet mag rijden en kijk ik of er hier sprake is van een geslotenverklaring voor een wegvak of dat het alleen zo'n inrijverbod is. Bij een inrijverbod tag ik op een knoop (of op een stukje weg, dat maakt me niets uit). Maar als ik verder onderzoek wat er aan de hand is, en de weg inderdaad gesloten is voor [categorie], dan tag ik toch de weg.

Vergelijk het met (on)verplichte fietspaden: stel, er loopt langs een zandweg een onverplichte fietspad van beton en aan het eind is dat ook zo aangegeven; halverwege is er een zijpad en men heeft verzuimd een bord opnieuw te plaatsen (of het is weggeraakt enz. enz.), maar er is verder niets anders te zien aan de inrichting van de weg; dan tag ik toch dat betonnen geval over de hele lengte als onverplicht fietspad. Ik redeneer niet dat het geen onverplicht fietspad is omdat er iets ontbreekt halverwege want de borden en inrichting laten (m.i.) zien wat de bedoeling is.

Als ik alleen traffic_sign gebruik zal er toch ergens een vertaallijst moeten komen, met een verwijzing naar RVV 1990 Bijlage I. De definitie die we erbij doen kan niet de betekennis van borden C6 t/m C22a veranderen van "gesloten" naar "niet inrijden". Ieder router zal echter begrijpen dat als je daar niet mag zijn, je daar ook niet mag inrijden, en dus er niet overheen routeren.

Last edited by Frankl2009 (2014-02-02 13:21:59)

Allroads · 2014-02-02 13:26:25

Restriction met een relation from to
restriction:motorcar=no_entry
duidelijk
maar nu staat er ook een onderbord
uitgezonderd tractoren
hoe dan te handelen?
restriction:agricultural=yes_entry

Komt dat goed bij de routeerder?

ligfietser · 2014-02-02 13:46:59

Allroads wrote:

Restriction met een relation from to
restriction:motorcar=no_entry
duidelijk
maar nu staat er ook een onderbord
uitgezonderd tractoren
hoe dan te handelen?
restriction:agricultural=yes_entry
Komt dat goed bij de routeerder?

Uitzonderingen geef je aan met except=vervoermiddel x;vervoermiddel y etc

PeeWee32 · 2014-02-02 14:51:35

Als we met een turn-restriction gaan werken dan is het m.i. zo dat je vanuit de Geeresteinselaan zowel vanuit noord als vanuit zuid de Ekris niet in mag rijden met de auto. Als je op dat kruispunt een turn restriction wilt gebruiken moet je er dan eigenlijk 2 maken? Eén met een "from" vanuit het noorden Geeresteinselaan en 1 met een "from" vanuit het zuiden. Klopt dat of kan het toch eenvoudiger? (en dan bedoel ik even niet de huidige)

Edit: op de mailinglijst schrijft Jo "The 4th option is to use turn restrictions on the crossing where the 'virtual' sign is placed." Dat doet mij vermoeden dat de huidige restriction dus ws wel het eenvoudigst is.

Last edited by PeeWee32 (2014-02-02 14:59:09)

PeeWee32 · 2014-02-02 16:28:38

Ik heb vandaag een rondje gefietst met OSM-tracker en daarna met JOSM wat verkeersborden ingevoerd. Ziet er best aardig uit zo met de kleine bordjes. Ik heb nog wel de mapcss wat aangepast omdat bv een C12 werd weergegeven als een C1. Dat kwam door het ontbreken van de 0 in de C01 .

Allroads · 2014-02-02 20:28:16

PeeWee32 wrote:

Ik heb vandaag een rondje gefietst met OSM-tracker en daarna met JOSM wat verkeersborden ingevoerd. Ziet er best aardig uit zo met de kleine bordjes. Ik heb nog wel de mapcss wat aangepast omdat bv een C12 werd weergegeven als een C1. Dat kwam door het ontbreken van de 0 in de C01 .

Ik heb de set van Ilpo voor Nederland, de vernieuwde versie. zeg maar set 2
Hier vandaan
I had some more fun... please check this one with JOSM:
http://ijjarvin.kapsi.fi/osm/trafficsigns/nlsigns.zip

Daar geeft hij bij C1 gelijk een C1 bord weer
Daar geeft hij bij C12 gelijk wel het goede bord weer. C12
C15 is C15

PeeWee32 · 2014-02-02 20:42:15

Allroads wrote:

Daar geeft hij bij C1 gelijk een C1 bord weer
Daar geeft hij bij C12 gelijk wel het goede bord weer. C12
C15 is C15

Ja dat klopt wel. Ilpo heeft obv de naam (bv NL:C1) van het plaatje de mapcss gemaakt. Daarin gebruikt hij de Finse methode dus de naam van bv de NL:C1 moet dan exact overeen komen. Maar als je een tag NL:C1,NL:OB54 gebruikt dan werkt de mapcss van Ilpo niet meer. Hoewel er nog geen onderborden in zitten wilde ik ook dan de C1 zien. Toen heb ik het zo aangepast dat er in de tag een NL:C1 voor moest komen. Dat leek te werken totdat ik een NL:C15 invoerde en een NL:C1 zag. Dat kwam dus omdat NL:C15 ook begint met NL:C1.

Edit: die laatste versie is hier te vinden.

Last edited by PeeWee32 (2014-02-02 21:06:36)

Allroads · 2014-02-02 21:16:59

Ja, ik vindt ook, dat je moet kunnen zien welke onderbord bij welk hoofdbord hoort. En werken.

Last edited by Allroads (2014-02-02 21:38:54)

PeeWee32 · 2014-02-02 21:27:45

Hoewel ik natuurlijk in dat andere draadje had moeten posten ga ik toch hier maar even verder. Die methode om alle borden achter elkaar in een value te stoppen (en onderborden gescheiden met een , ) heeft uiteraard wel als nadeel dat je dan niet weet welk hoofdbord je te zien krijgt. Ik denk dat dat (1 van) de redenen is dat de Finse methode ontstaan is.

Frankl2009 · 2014-02-03 16:13:16

De vraag van Allroads bij het begin van deze draad was:

De zin/onzin om verkeersborden te taggen.
en
Ik vraag me af waarom een afgeleide taggen als je expliciet het bord kan taggen, op een node in het stuk weg.

Het lijkt me zinnig om de borden ook te noteren in OSM. Daar hebben we tags voor (traffic_sign=NL:xx) en het geeft extra informatie. Open blijven de vragen of je dat naast of op een weg doet (ik denk dat we tenderen naar op ipv naast de weg) en de vraag HOE je dat op de weg doet (tag op een knoop of op de weg/het pad zelf). Deze worden momenteel op tagging besproken.

Maar dan de vraag “waarom een afgeleide taggen als je expliciet het bord kan taggen?”

Er zijn verplichte fietspaden of (brom-)fietspaden, duidelijk uitgevoerd als zodanig, waar men heeft verzuimd om een bord te plaatsen (a) opnieuw na een kruising en/of (b) aan het eind van het pad een bord C2 (eenrichtingsweg, in deze richting gesloten).

Ook komt het voor dat men geen bord plaatst op een (brom-)fietspad na een aansluiting (voor (brom)fietsverkeer die de naastgelegen weg kruist), of geen bord C4 daar plaatst om het feit dat het éénrichting is opnieuw aan te geven (en in welke richting).

Wij kunnen echter vaak afleiden door de inrichting van de weg/het pad wat de bedoeling is, met name als het duidelijk doorzetting is van het (brom)fietspad. In die gevallen tag ik het geheel als verplicht (brom-)fietspad ondanks het feit dat borden op een stukje ontbreken. (Voor de duidelijkheid: ik tag het niet als fietspad als er in zijn geheel geen bebording is.)

Er is dus behoefte om zowel traffic_sign tags te plaatsen als tags die aangeven wie het pad wel/niet mag gebruiken.

Als we kiezen om traffic_sign tags te plaatsen op de weg / het pad, dan ga ik die traffic_sign tags niet plaatsen op een stukje van een fietspad waar de borden in werkelijkheid ontbreken (maar ik ga dat stukje wel als (brom)fietspad taggen).

Op andere wegen dan fietspaden gelden wellicht andere overwegingen. Maar ik wil ook niet twee regimes hanteren, een voor fietspaden en een voor andere wegen. Overal dezelfde regels lijkt me beter.

M.a.w.: we moeten inderdaad expliciet blijven taggen al gaan we op het juiste plekje de borden ook opnemen in OSM.

Last edited by Frankl2009 (2014-02-03 16:30:21)

PeeWee32 · 2014-02-03 19:44:17

Zoals bekend heb ik al op verschillende manieren de traffic_sign key toegepast. Dat is voor mij geen reden om niet ook de gebruikelijke (bv access) tags toe te passen. Echter, het staat een mapper vrij te mappen wat ie wil hoewel het wel verstandig is dat te doen met instemming van de community. Als er iemand is die alle verkeersborden als losse punt naast de weg wil taggen en verder niets dan is daar volgens mij niet veel mis mee maar ik zal wel proberen de implicaties ook te taggen.

Als ik de traffic_sign Wiki lees zijn er vele mogelijkheden en persoonlijk ben ik nog een beetje zoekende wat we het best kunnen doen. Ook ik neig er naar om deze op de weg te plaatsten zodat er iets aan te geven is over de geldigheidsrichting maar dan is nog steeds de vraag hoe. Ik heb het idee dat we in deze NL verkeersborden wiki uit moeten breiden met per bord aan te geven of het in principe een bord is voor een punt/knoop/node of voor een way/wegvlak. Ik denk dat een aantal (nee niet alle ) C borden punten zouden moeten zijn tenzij aan beide einden van een weg zo'n C bord staat. Dan zou het denk ik ook op de weg getagd kunnen worden en ik denk dat dit wel handig is al heb je dan wel weer 2 methodes die voor het zelfde bord gebruikt kunnen worden. Dat maakt het weer wat onduidelijk. Lastig.

En dan is er verder nog de vraag of een bord en de implicatie daarvan in principe op het zelfde element (way of node) getagd moeten worden of niet. Als de meeste C borden die maar aan 1 kant van de weg staan dan getagd moeten worden op de node (of een klein stukje daar vandaan op de weg) en de implicatie met een turn restrictie dan wordt ik daar nog even niet echt blij van maar zie ook niet hoe dat beter kan.

Ook is het wel fijn als we in NL consensus krijgen over hoe we de value willen toepassen. Alle borden op een paal in 1 value en de onderborden gescheiden met een komma? Of toch iets a la de Finse methode? Ik neig naar de eerste methode.

Ook over de naamgeving van de borden moeten we een ei leggen. C1 wordt zowel als C1 als als C01 aangeduidt. Zie bv hier: . Met alleen een RVV codering komen we er niet. Een maximum snelheidsbord van 50km/h is een A1 maar dan weet je nog niet welke snelheid dat is. Dan is een A0150 een ondubbelzinnige notatie. Uiteraard kunnen we ook nog een A1[50] oid verzinnen maar daar ben ik geen voorstander van omdat dit zo te zien geen gebruikelijke notatie is in NL. Ik stel dan ook voor om de fabrieksnummer/modelnummer notatie te hanteren. Dat maakt het ook veel eenvoudiger voor de overpass queries en het mapcss voor JOSM.

Frankl2009 wrote:

Open blijven de vragen of je dat naast of op een weg doet (ik denk dat we tenderen naar op ipv naast de weg) en de vraag HOE je dat op de weg doet (tag op een knoop of op de weg/het pad zelf). Deze worden momenteel op tagging besproken.

Welke discussie doel je hier op?

PeeWee32 · 2014-02-03 20:24:54

Ik heb een reactie van de Gemeente Rotterdam.

De antwoorden op je vragen:
Weet je welke verkeersborden waarschijnlijk opgenomen zullen worden in de BGT/IMGeo? (bv ook onderborden?)
- Alle. Ook onderborden staan in het beheersysteem van de gemeente, ik weet niet of het vanuit daar ook gekoppeld wordt met info aan de BGT. In de BGT staat wel waar borden staan (maar volgens mij niet per definitie wat voor bord het dan is)
Weet jij of er afspraken zijn gemaakt over RVV codering? In Rotterdam zie ik bv de C01 (met voorloopnul) en niet C1.
- We hanteren de RVV codering, maar i.v.m. de veldeninput wel soms met een voorloop nul om te zorgen dat er geen achtervoegsel bij kan.
Zal er nog data opgenomen worden zodat te zien is vanaf welke kant (n/o/z/w ??) het bord zichtbaar is?
- Dit wordt niet opgenomen in het beheerssysteem van de Gemeente Rotterdam. Wellicht komt dit in een vervolg als we een de verkeersbesluiten echt gaan digitaliseren. Echter op dit moment is dat nog geen concreet project.
Heb je nog tips/links mbt dit onderwerp die voor OSM van belang kunnen zijn?
- De antwoorden hierboven zijn afkomstig van mijn collega xxxxxxxxxxxx. Zij werkt bij het cluster Stadsbeheer, zij beheren het buitenruimtesysteem waar alle objecten in de buitenruimte zijn opgenomen. Voor meer achtergrondinformatie over objecten in de buitenruimte, kun je het beste contact met haar opnemen. Zelf werk ik bij de afdeling Verkeer en Vervoer. Verkeer en Vervoer gaat allerlei verkeersdata beschikbaar stellen (vooral parkeerdata (actueel en niet actueel). Mogelijk is dat interessant voor OSM.

Over het laatste puntje heb ik nog gevraagd HOE dat beschikbaar gesteld gaat worden. Net als de verkeersborden?

Frankl2009 · 2014-02-04 13:47:39

PeeWee32 wrote:

Frankl2009 wrote:
Open blijven de vragen of je dat naast of op een weg doet (ik denk dat we tenderen naar op ipv naast de weg) en de vraag HOE je dat op de weg doet (tag op een knoop of op de weg/het pad zelf). Deze worden momenteel op tagging besproken.
Welke discussie doel je hier op?

https://lists.openstreetmap.org/piperma … 16400.html
(De antwoorden daar gaan iets verder dan de vraag die je stelde over fictieve eenrichtingsbarriëren; ik neem aan dat je hier t.z.t. de discussie verder zet, maar ik wilde een ander aspect aan de orde stellen)

Last edited by Frankl2009 (2014-02-04 16:17:54)

PeeWee32 · 2014-02-05 17:37:32

Frankl2009 wrote:

https://lists.openstreetmap.org/piperma … 16400.html
(De antwoorden daar gaan iets verder dan de vraag die je stelde over fictieve eenrichtingsbarriëren; ik neem aan dat je hier t.z.t. de discussie verder zet, maar ik wilde een ander aspect aan de orde stellen)

Ok helder. Ja zoals in mijn vorige post aangegeven weet ik ook nog niet wat de beste manier is van taggen van verkeersborden en hun implicaties. In een mailwisseling met Ilpo heb ik net ook aangegeven dat we misschien moeten proberen een soort hierarchie af te spreken voor verkeersborden (en nog even niet de implicaties) . Iets in de trend van:

1 Als het op de way kan (ondubbelzinnig) dan kiezen we dat. (bv de A1 borden met Maxspeed, of C borden die aan alle uiteinden van een weg helderheid bieden)
2 Zo niet maar het kan wel op een node, dan kiezen we die (bv. een aantal C-borden)
3 Als dat ook niet lukt dan misschien maar alleen een bord als los staande node mappen (bv dit voorbeeld van Ilpo een OB502 als je op een T-splitsing af rijdt en het bord staat op het eind waar de wegen samenkomen.)

Het is maar een idee hoor dus schieten wordt op prijs gesteld

PeeWee32 · 2014-02-05 17:40:41

En nog een reactie van Rotterdam. Die zijn lekker bezig met open data. TOP.

Alle Rotterdamse data zal in ieder geval worden vermeld op rotterdamopendata.nl
- Het beschikbaar stellen van actuele parkeerdata zal via een landelijke registry gebeuren. Elke gemeente zorgt zelf voor de ontsluiting. Op dit moment wordt gewerkt aan een standaard voor actuele parkeerdata. Rotterdam zal dit in maart of april beschikbaar hebben.
- Landelijke statische parkeerdata is beschikbaar via het parkeerregister, zie http://www.nationaalparkeerregister.nl/ … ar-49.html
- Het beschikbaar stellen van actuele reistijden en intensiteiten vindt plaats via het NDW, zie http://rotterdamopendata.nl/dataset/ndw
- Daarnaast komt Rotterdam nog met data over verkeerslichten, brugopeningen e.d. (verwachting maart - april)

PeeWee32 · 2014-02-05 17:46:51

Ik ben ook nog even aan het zoeken geslagen naar een uniforme manier van aangeven welk bord wat is. Dat valt niet mee. Ik ben nu al diverse notaties tegen gekomen voor de borden. Hier een aantal varianten . 1 Erdi , 2 TSNED, 3 POL, 4 CROW .

Ik heb maar een mail naar de VNFV gestuurd in de hoop dat die iets van helderheid kunnen bieden.

Frankl2009 · 2014-02-06 10:59:40

PeeWee32 wrote:

Ik ben ook nog even aan het zoeken geslagen naar een uniforme manier van aangeven welk bord wat is. Dat valt niet mee. Ik ben nu al diverse notaties tegen gekomen voor de borden. Hier een aantal varianten . 1 Erdi , 2 TSNED, 3 POL, 4 CROW .
Ik heb maar een mail naar de VNFV gestuurd in de hoop dat die iets van helderheid kunnen bieden.

Ik zou CROW gebruiken. Lijkt me een prima referentiepunt. Die lijst is toch ook nog van NEN en VNFV?* Meer normalisatie dan dit krijgen we nergens. De websites en catalogi van een van de fabrikanten zou ik juist niet volgen, want er is kans op coderingsverschillen tussen fabrikanten (en ik dacht dat de leden van VNFV er toch op die lijst overgingen**).

Kolom "Fabrieksnummer/modelnummer" bij CROW is zeker een optie.

Een extra "0" bij bord C01 enz. lijkt me prima. Het verandert niets aan de betekenis of herkenbaarheid van de borden. En het heeft (zoals je citeert van Rotterdam) ook voordelen.

Variabelen zoals snelheid enz. verwerken in een referentiecode zoals traffic_sign=A0130zb heeft voordelen (want ondubbelzinnig).

Het betekent wel dat sommige dingen anders wordt getagd op een weg dan in de tag traffic_sign=. Het wordt ook een systeem alleen voor Nederland (want andere landen hebben andere referentiecodes om naar de borden te refereren), dus uitbreiden naar andere taggingsvormen zal niet mogelijk zijn.

----

* Verkeerstekens (NEN/CROW-normcommissie 353.73)
Taak van de normcommissie is het voorbereiden, begeleiden en ondersteunen van de Nederlandse inbreng in de Europese normeringactiviteiten, met name de activiteiten voor werkgroep 3 ‘Verkeerstekens’ (Vertical Signs) van het Technical Committee 226 ‘Road Equipment’ (Weginrichting) van het ‘Comité Européen de Normalisation’ (CEN TC 226, WG3).
CROW en NEN voeren gezamenlijk het secretariaat van deze NEN-normcommissie. In het werkpakket is NEN de trekker van de normen en CROW de trekker van de richtlijnen.

** Bordennummering
Er worden op deze site twee nummeringen aangehouden.
Allereerst de RVV-nummering. Deze vindt zijn basis in de wet- en regelgeving. Deze nummering wordt onder andere gebruikt bij handhaving en vergunningverlening.
Daarnaast is er, in de NEN-CROW commissie Verkeerstekens, een fabrieksnummering (ook wel modelnummering genoemd) ontwikkeld, waarin ieder bord een gedetailleerder code krijgt om bij bestellingen van borden misverstanden te voorkomen tussen leveranciers en bestellers. Deze fabrieksnummering is uitgewerkt voor RVV-borden, maar tevens ook voor de niet-RVV-borden en tijdelijke (werk in uitvoering) borden. Reeds bestaande niet-RVV borden krijgen vanwege de logica van de systematiek veelal ook een nieuwe code.

Edit: Onderborden: hier. Dus, bijvoorbeeld: OB52 "Uitgezonderd fietsers".

Last edited by Frankl2009 (2014-02-06 11:37:08)

Allroads · 2014-02-06 12:33:35

Plaatjes van ook niet RVV borden, CROW heeft ze niet beschikbaar. Ze werken zelf met lage kwaliteit plaatjes.
PNG en SVG plaatjes vanwege transparantie en niet rechthoekig.

Frankl2009 · 2014-02-06 22:12:15

PeeWee32 wrote:

In een mailwisseling met Ilpo heb ik net ook aangegeven dat we misschien moeten proberen een soort hierarchie af te spreken voor verkeersborden (en nog even niet de implicaties) . Iets in de trend van:
1 Als het op de way kan (ondubbelzinnig) dan kiezen we dat. (bv de A1 borden met Maxspeed, of C borden die aan alle uiteinden van een weg helderheid bieden)
2 Zo niet maar het kan wel op een node, dan kiezen we die (bv. een aantal C-borden)
3 Als dat ook niet lukt dan misschien maar alleen een bord als los staande node mappen (bv dit voorbeeld van Ilpo een OB502 als je op een T-splitsing af rijdt en het bord staat op het eind waar de wegen samenkomen.)
Het is maar een idee hoor dus schieten wordt op prijs gesteld

Ik geloof dat we de gebruikelijke tagging niet moeten vervangen met traffic_sign= (om redenen die ik hierboven al noemde), maar het aanvullend te doen.

Daarom zou ik traffic_sign= plaatsen op een knoop vlakbij de werkelijke locatie en loskoppelen van pogingen om het routeerbaar te maken. Of los, naast de weg, of als knoop in de weg/het pad.

Eigenlijk net als met tourism=information;information=board enz.

De keuze varianten zijn dan niet nodig.

Hendrikklaas · 2014-02-06 22:46:26

Allroads, de plaatjes van de niet RVV borden kan ik misschien toch nog wel losweken, je hoort nog. Dat zijn er redelijk veel tegenwoordig, er worden er nogal wat bijgemaakt, het proces is geDTP'd en daarmee voor veel mensen een optie.

PeeWee32 · 2014-02-07 08:02:40

Frankl2009 wrote:

Ik geloof dat we de gebruikelijke tagging niet moeten vervangen met traffic_sign= (om redenen die ik hierboven al noemde), maar het aanvullend te doen.

Helemaal mee eens. Het was ook niet mijn bedoeling dat voor te stellen hoor. Ik vind de implicaties belangrijker dan de borden maar de borden zijn veelal de oorzaak ervan. Daarom zou het mooi zijn als we in OSM ondubbelzinnig kunnen zien welk bord waar van toepassing is. Ook voor bv controle doeleinden of het mappen van de implicaties.

Frankl2009 wrote:

Daarom zou ik traffic_sign= plaatsen op een knoop vlakbij de werkelijke locatie en loskoppelen van pogingen om het routeerbaar te maken. Of los, naast de weg, of als knoop in de weg/het pad.
Eigenlijk net als met tourism=information;information=board enz.
De keuze varianten zijn dan niet nodig.

Gezien de reacties op tagging (al gaat dat meer over de implicaties op een node dan over de traffic_sign tag) vraag ik mij dus af wat wijsheid is. Is het zinvol om bv een traffic_sign:forward=NL:C6 te mappen op een node die onderdeel uitmaakt van de weg en tegelijkertijd de implicatie als een restrictie (met 2 wegen en een andere node) te mappen. Iets zegt me dat dit in tegenspraak is maar.. misschien ben ik wel op zoek naar iets dat niet kan. Zie als voorbeeld de Ekris zoals deze nu in OSM staat.

De rode weg is 1 van de wegen die onderdeel uitmaakt van de restriction (restriction:motorcar=no_entry). Het verkeersbord is een losse node op deze weg (traffic_sign:backward=NL:C6) vlak bij de node van de restriction. Op zich ondubbelzinnig maar is het verstandig om die traffic_sign:backward=NL:C6 op de node te mappen. Het geeft wel aan voor welke richting die geldt en dat vind ik relevante informatie. Als we het bord helemaal als losse node naast de weg mappen dan zit je volgens mij met de vraag hoe we aan gaan geven voor welke weg en richting deze geldt. Bij de Ekris is wel helder voor welke weg dat is maar zeker bij punten waar veel wegen bij elkaar liggen zal dat een uitdaging worden.

Even hardop denkend zouden we misschien nog het volgende kunnen doen aangenomen dat een restriction relatie hoe dan ook nodig is.

1 Zet de traffic_sign tag weer terug op de node die onderdeel uitmaakt van de restrictie. De traffic_sign heeft dan geen forward/backward meer nodig omdat de restrictie al aangeeft over welke richting het gaat.
2 Geeft de restrictie relatie een extra tag : traffic_sign=NL:C6 (naast de restriction:motorcar=no_entry en type=restriction)

Zomaar een paar ideeen.

PeeWee32 · 2014-02-07 14:31:19

Op de tagginglist verscheen een item over speed cameras. Al lezende kwam ik op de wiki hoe men deze tagged en zag parallelen met verkeersborden die in 1 richting geldig zijn. Op deze wiki example 3b staat uitgelegd hoe dat werkt. Daar staan ook een paar filmpjes. Hier de JOSM variant. Kort samengevat:

Men plaatst een losse node naast de weg daar waar de camera staat. Op de weg worden een stukje ervoor en een stukje erna 2 losse nodes geplaatst. Al deze 3 nodes zitten in een relatie (ook to en from) zodat bekend is wat de richting van de camera is. Een voordeel van deze methode is dat de weg helemaal niet opgeknipt wordt en de camera ook in OSM exact staat waar ie in werkelijkheid staat.

Is dit een insteek die voor dit type verkeersborden te gebruiken is? Wat vinden jullie?

Frankl2009 · 2014-02-07 16:47:31

PeeWee32 wrote:

Kort samengevat:
Men plaatst een losse node naast de weg daar waar de camera staat. Op de weg worden een stukje ervoor en een stukje erna 2 losse nodes geplaatst. Al deze 3 nodes zitten in een relatie (ook to en from) zodat bekend is wat de richting van de camera is. Een voordeel van deze methode is dat de weg helemaal niet opgeknipt wordt en de camera ook in OSM exact staat waar ie in werkelijkheid staat.
Is dit een insteek die voor dit type verkeersborden te gebruiken is? Wat vinden jullie?

Ingewikkeld.
En je moet dan twee keer (of meer) relaties gaan invoeren: tenminste een keer voor de weg (turn restriction) en nog een keer voor het bord zelf.

Ik ben niet bang voor relaties (in OSM, ) maar turn restrictions invoeren is al geen lol.

Ik zie me zelf het niet doen en betwijfel ook of de editors het gaan invoeren (misschien m.u.v. JOSM).

Frankl2009 · 2014-02-07 16:52:38

PeeWee32 wrote:

Even hardop denkend zouden we misschien nog het volgende kunnen doen aangenomen dat een restriction relatie hoe dan ook nodig is.
1 Zet de traffic_sign tag weer terug op de node die onderdeel uitmaakt van de restrictie. De traffic_sign heeft dan geen forward/backward meer nodig omdat de restrictie al aangeeft over welke richting het gaat.
2 Geeft de restrictie relatie een extra tag : traffic_sign=NL:C6 (naast de restriction:motorcar=no_entry en type=restriction)
Zomaar een paar ideeen.

Ja.
Ik denk dat er iets met turn restriction nodig is.
en dan traffic_sign=NL: op de node en het aan de renderer overlaten waar het geplaatst moet worden.

(Daar is ook het e.e.a. over te zeggen, maar voordeel is: eenvoud.
Eenvoudiger dan dit kunnen we het niet maken.)

PeeWee32 · 2014-02-08 13:24:56

Frankl2009 wrote:

PeeWee32 wrote:
Even hardop denkend zouden we misschien nog het volgende kunnen doen aangenomen dat een restriction relatie hoe dan ook nodig is.
1 Zet de traffic_sign tag weer terug op de node die onderdeel uitmaakt van de restrictie. De traffic_sign heeft dan geen forward/backward meer nodig omdat de restrictie al aangeeft over welke richting het gaat.
2 Geeft de restrictie relatie een extra tag : traffic_sign=NL:C6 (naast de restriction:motorcar=no_entry en type=restriction)
Zomaar een paar ideeen.
Ja.
Ik denk dat er iets met turn restriction nodig is.
en dan traffic_sign=NL: op de node en het aan de renderer overlaten waar het geplaatst moet worden.
(Daar is ook het e.e.a. over te zeggen, maar voordeel is: eenvoud.
Eenvoudiger dan dit kunnen we het niet maken.)

Bij nader inzien stel ik toch voor om in het voorbeeld van de Ekris de traffic_sign maar als aparte node naast de weg te mappen en in de turnrestriction relatie op te nemen als een location_hint. . De aparte traffic_sign node heeft dan ook geen forward/backward. Op die manier hebben we alle nodes en ways die iets met die restrictie te maken hebben ook opgenomen in de relatie. Daarnaast staat het verkeersbord keurig naast de weg waar ie in werkelijkheid ook staat zodat zelfs zonder de relatie in ogenschouw te nemen iemand wel kan vermoeden vanuit welke richting je daar met de auto niet in mag rijden. Wat vinden we hiervan?

Announcement

#151 2014-02-02 12:29:41

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#152 2014-02-02 13:26:25

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#153 2014-02-02 13:46:59

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#154 2014-02-02 14:51:35

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#155 2014-02-02 16:28:38

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#156 2014-02-02 20:28:16

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#157 2014-02-02 20:42:15

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#158 2014-02-02 21:16:59

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#159 2014-02-02 21:27:45

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#160 2014-02-03 16:13:16

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#161 2014-02-03 19:44:17

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#162 2014-02-03 20:24:54

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#163 2014-02-04 13:47:39

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#164 2014-02-05 17:37:32

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#165 2014-02-05 17:40:41

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#166 2014-02-05 17:46:51

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#167 2014-02-06 10:59:40

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#168 2014-02-06 12:33:35

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#169 2014-02-06 22:12:15

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#170 2014-02-06 22:46:26

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#171 2014-02-07 08:02:40

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#172 2014-02-07 14:31:19

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#173 2014-02-07 16:47:31

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#174 2014-02-07 16:52:38

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

#175 2014-02-08 13:24:56

Re: NLVB: Verkeersborden en taggen. (Algemeen, start/voortgang discussie)

Board footer