Apologies, that was a type from my side.
It should have been "lock=yes"
Thanks for pointing that out, just corrected it.

Added the "water_system" as separate key, that really is important as a distinction in the Dutch Water Systems
(millions of waterways in the polder that you will never see when navigating your boat, because they are behind the dyke, on a lower water level)

Will add the water_system=lock value to the wiki later as to document this value.

Graag gedaan (was leuk peddelen) en excuus!
Was onbedoelde fout, nu hersteld:
osm.org/changeset/61130141

JOSM kwam na poging tot upload met 60+ conflicten (steeds name ipv rpn_ref_). Ik begrijp niet goed waarom.
Heb ze stuk voor stuk proberen op te lossen met behoud van de correcte bestaande data, maar deze was er zo te zien tussendoor geglipt.

Blik op netwerk geeft bij mij het idee dat dit de enige was, mocht ik iets missen, laat het weten, dan repareer ik dat.
osm.org/relation/8438301

edit: source=survey 2018-06-27 (geen bestand gebruikt)

Done!
Dank voor bericht, je was me net voor met wezencheck (-;

Changeset comment is abuis: betreft Deelerwoud en obv Survey 2018-05

Hoi, tagging van conditionals tijd en bepaalde vervoerswijzen is altijd even gemeen, heb het aangepast, zie osm.org/way/508247670/history

De algemene tag [access=permissive] geeft onbedoeld toegang aan alle vervoersvormen binnen de gestelde tijd.

De algeme tag [access=no] kan je ook beter niet gebruiken als er uitzonderingen op zijn, als de datagebruiker de uitoznderingen niet begrijpt, blijf je over met een onterechte uitsluiting. Beter is het om uitsluitende tags te gebruiken ipv uitzonderingen op een meer globale tag.

Dat kan door de algemene acces:conditional om te draaien naar een no (in het donker mag niemand ering: dan gelden er geen uitzonderingen) en voor de vervoerswijzen die -in de andere periode- wel erin mogen een foot:conditional te maken.

Dus
access:conditional = no @ (sunset-sunrise)
foot:conditional =permissive @ (sunrise-sunset)

Door de definitie van footway (iets anders dan default), hoeven andere vervoerswijzen niet.

Laat maar weten als andere conditionals vragen oproepen.

Hoi, heb de situatie aangevuld, zie de wijzigingen tov de vorige versie hier:
https://overpass-api.de/achavi/?changeset=58825439

Hopelijk helpt die vergelijking je op weg.
Er is zowel aan de kant van Zoeterwoude als aan de kant van Leiden wordt het voor ons als mappers wel lastig gemaakt met de inconsistente / missende verkeersborden, wellicht is aan die kant nog winst te boeken.

Hoi, ik heb ook even meegekeken en ben er even langs gefietst. Het is daar een potpourri van ontbrekende danwel onbedoeld stringente borden, asymmetrische situaties en fysieke beperkingen.

Helemaal geen slechte eerste edit in die lastige context (-:

De nieuwe tags op de bollard geven de feitelijke situatie behoorlijk weer, er staat weliswaar een C1 bij de barriere, maar de uitvoering van de barriere (laat fysiek geen auto's door, wel tweewielers) en alle overige borden ter plaatse en aansluitende fietspaden maken overduidelijk dat dat bord iets te enthousiast / foutief geplaatst is (een andere variant of een onderbord was duidelijk de bedoeling).

De tags op de brug zijn ongewijzigd en routeren wel voor fietsers:
osm.org/directions?engine=graphhopper_bicycle&route=52.14554%2C4.51527%3B52.14288%2C4.51883#map=19/52.14350/4.51846

Vehicle=yes is misschien niet strikt noodzakelijk, maar op zich niet per definitie fout en in ieder geval expliciet / verduidelijkend in een situatie met veel verboden. Alleen hier staat de C1 net wat eerder en kunnen/mogen motorvoertuigen er niet in.

Zal het nog wat verfijnen adhv mijn foto's
@steady-eddy: laat maar weten als dat nog vragen oproept en welkom inderdaad!

Goed initiatief, en mooi dat dit wordt opgepakt!

Voor routeren zal "private" wss idd hetzelfde resultaat als "no" geven (beide beter dan "permissive"), maar no lijkt me hier toch beter passen bij de situatie, aangezien het geen privéweg is (dat is waar "private" doorgaans betrekking op heeft"), maar een openbare weg (in beheer bij de gemeente) met toegangsbeperkingen, waarvoor ontheffingen / vergunningen worden verleend. Dat is op zich heel gebruikelijk, enige bijzondere is dat het hier op een onderbordje expliciet is vermeld.

In theorie is het zelfs mogelijk dat de gemeente niet de eigenaar is, maar wel het onderhoud / beheer doet.

Ook zou het kunnen dat er een bepaald beleid voor vergunningen is, waardoor iedereen die voldoet aan bepaalde voorwaarden recht heeft op een vergunning. Bij private kan een eigenaar de toegang weigeren ook zonder opgaaf van reden / met willekeur. Maar het blijft complex..

Hoi, je hebt deze weg op motor_vehicle=permissive gezet vanwege het onderbord mbt vergunninghouders
osm.org/way/25012342/history

Het nauwkeurig taggen van de toegangsvoorwaarden is een grote meerwaarde in OSM, alleen deze klopt net niet helemaal.

Permissive betekent dat _iedereen_ op basis van de bebording er met een motor_vehicle in mag, maar dat de eigenaar dat recht wel weer kan intrekken zonder bestuursrechterlijke waarborgen (itt tot een openbare weg: daar moet de wegbeheerder een verkeersbesluit of onttrekkingsbesluit nemen om dat te doen en dat kan je bij de bestuursrechter aanvechten als de belangenafweging niet evenwichtig is gemaakt).
Zie voor de algemene uitleg osm.wiki/Key:access

Het onderbord mbt de vergunningen zegt voor de access-tagging in OSM eigenlijk niet zoveel/niets, zal in de praktijk vooral zorgen voor iets meer begrip bij fietsers voro passerende auto's die daar wel met toestemming rijden.

Ontheffingen voor het negeren van verboden kunnen ook worden ontleend op wegen waar dergelijke onderborden niet staan.

Ik zet motor_vehicle daarom weer op no, want het is "No access for the _general_ public"

Groet

Hoi, je hebt hier een slagboom verwijderd met vermelding "Geen slagboom aanwezig". Deze staat er echter wel degelijk. Zie bijgaande foto van afgelopen augustus.
https://www.mapillary.com/map/im/Ym1zA911Iv9ltBfPBS9RkA

Toevallig was ik hier een paar dagen na jouw edit en zag 'm toen ook nog. Mijn fotot staat binnenkort op Mapillary. Ik zet de slagboom weer terug. Groet.

Thx! Heb het verwerkt. Aan beide kanten van de weg staan dus ander snelheidslimieten en net een ander onderbord. De wegbeheerder maakt het weer uitdagend voor ons (-:

Heb ook mijn foto van het onderbord (en afwezigheid van bord A1-60 bij einde bebouwde kom aan de zuidzijde net op Mapillary gezet, zal over paar uurtjes zichtbaar zijn. Weer een fixme opgeruimd en samen de database verbeterd (-:

Thx!
Ik zal het aanpassen zodra de foto op Mapillary staat.

De implicaties van een bord horen op de weg (daar gelden ze en anders is het bijna onmogelijk om borden aan wegvakken te koppelen. Zie ook onderstaand citaat uit de wiki.

Om het echt sluitend te krijgen zal ik traffic_sign:forward toevoegen, alleen op die manier weten andere datagebruikers dan jij en ik dat beide kanten zijn bezien en hetzelfde bord bevatten, anders moet je dat maar raden (en vaak genoeg staat er aan de ene kant van de weg een ander bord dan aan de andere, maar vaak zien we wegen maar vanaf een kant met mappen)

Groet!
osm.wiki/Key:traffic_sign
The implications of a traffic sign should always be tagged on the concerned section of the road itself as well. When mapping a speed limit sign for example: always add a maxspeed=* and a source:maxspeed=sign tag to the road itself.

Hi Otto,

I fully agree with Eggie, who formulates the Dutch (and I think more general concensus outside Gemany) on this point

Example way of the point Eggie makes:
wayhttps://www.openstreetmap.org/way/16818187/history

This change does not improve the situation, but really makes is worse, could you please revert all these kind of changes you made in the Netherlands and inform the German community about this, so we can avoid messing up/revertig each others work?

Many thanks!

Dank voor wijzigen in osm.org/changeset/57747009.

Zag net ook C12 het verbodsbord thv de Doornlaan staan op Mapillary, maar dat was ook al door Allroads verwerkt in de tagging van dat wegdeel, zie osm.org/way/6779978

Zolang het verbodsbord echter niet -in beide richtingen- is herhaald bij het tussenliggende punt waar de highway=service van Vijverdal ( osm.org/way/58914636 ) uitkomt op de Molenweg (hier: "het midden") mag je met motorvoertuigen niet vanuit het noorden/zuiden naar het midden, maar wel vanuit het midden naar het noorden (en ook naar het zuiden, maar daar kom je door de bollard niet zo ver). En dat is nu juist wat de precieze tagging van Allroads vertelde.

Zijn er (nieuwe?) ook verbodborden C12 bij de kruising met de highway=service van Vijverdal geplaatst?

Waarom deze aanpassing? (die ook niet voldoet aan de omschrijving "name change").

De situatie was precies gemapt door een andere mapper (alleen gesloten in één richting en dan voor motorvoertuigen in de RVV-zin, conform het getagde bord C12).

Na jouw wijziging is het in beide richtingen gesloten, en niet alleen voor auot's/motorfietsen, maar ook voor brommers/snorfietsen. Dat is niet in overeenstemming met het getagde bord.

Is de situatie ter plekke gewijzigd tov wat te zien is op https://goo.gl/maps/EAnRhdo43Lv
(ook bord aan andere kant van de weg en nieuw bord dat brom-/snorfietsen uitsluit) ?
In dat geval zou de traffic sign beter aangepast kunnen worden adhv nieuwe situatie.

Zo niet, dan is deze wijziging een verslechtering ipv een verbetering in de database en zou je het dan terug willen draaien?
Of heeft de oorspronkelijke mapper je gevraagd dit zo te doen?

Zou je ajb de foot=yes en bicycle=yes die je hebt verwijderd willen terugplaatsen? Dat zijn correcte tags die zijn geplaatst door andere mappers, die de tagging compleet en duidelijk maken. Overeenkomst met een defaultwaarde is geen reden om ze te verwijderen (defaults zijn bedoeld om een goede gok te kunnen doen bij ontbrekende data, niet om data te doen verdwijnen. We verwijderen immers ook niet de maxspeed=50 omdat dat nu de default is binnen de bebouwde kom, net zo min als we maxspeed=130 verwijderen van een motorway. Dank alvast.

osm.wiki/NL:Good_practice#Verwijder_NOOIT_tags_die_je_niet_begrijpt.21.21

Correctie omschrijving: Kamerik - edits kanoroute

Hoi,

Het is idd een C06 ipv G06, thanks, is gecorrigeerd.

De access=yes was wel nuttig, want icm met de overige tags is daarmee voor alle voertuigen de access vastgelegd in de tagging.

Default-tabellen zijn een hulpmiddel bij ontbrekende informatie, geen reden om informatie weg te laten of te verwijderen, is uitgebreid in forum aan de orde geweest (topic door mij gestart, zoek op "needless" )
Bij weglaten moet je maar raden of access voor de betreffende type voertuigen ook zo is geconstateerd, of dat het wordt aangenomen bij gebrek aan informatie.

Heb tagging wel verfijnd en gewoon positief benoemd ipv met uitzonderingen op globale access=yes, is beter te verteren voor datagebruikers.

En heb weg opgesplitst vanwege toegangbord Staatsbosbeheer iets verderop, zie onderstaande en verder.

https://www.mapillary.com/map/im/D5UyFrSIN3ROD2haAJ5tbA