Heb toegang voor foot/bicycleop aantal paden hersteld, stond eerder op [permissive], maar was in deze changeset ten onrechte gewijzigd in [yes]. Dit echter zijn geen openbare wegen, maar paden die door de beheerder bij gedogen zijn opengesteld, zie de vermelding op de toegangsborden
https://www.mapillary.com/map/im/sVXQaF_zlT0j7Y7IjcVrQA en osm.wiki/Key:access

Dank voor je immer scherpe blik, was foutje bij maken routenetwerk.

Is nu gewist in
osm.org/changeset/68567082

Groet!

Bij het ontdubbelen van deze route is onbedoeld het oudere exemplaar (v70) verwijderd in plaats van het nieuwere exemplaar (v2).

Voor de navolgbaarheid van de geschiedenis hierbij alsnog de link naar het oudere origineel:

osm.org/relation/911890/history

Hey Math, thx, survey is hier geen straf (-:
En leuk dat we elkaar aanvullen in het gebied.

Zoals je in de geschiedenis kan zien zat ik daar zelf ook mee te worstelen en het blijft een grensgeval. Was eerst unclassified, daarna residential (op sommige delen track/footway..), heb er na eerste survey zelf service van gemaakt en na latere surveys -toen ik de structuur van de wegen in het gebied beter overzag toch weer terug naar de residential die andere mapper er ook al aan had gegeven.

Zelf vond ik dat uiteindelijk toch de beste (/minst slechte) keuze. Het doorgaande karakter is inderdaad beperkt, en daarom past "unclassified" echt niet goed. Maar tegelijkertijd is de weg die nu residential is wel echt de centrale ader in het gebied die de verschillende 'service' highways ontsluit naar twee kanten richting de openbare weg. De wegen die nu 'service' zijn hebben echt een ander karakter, lopen allemaal dood bij de verschillende woningen op het terrein.

In de service-categorie vond ik geen geschikte variant om die rol duidelijk te maken. Hoewel het doorgaande karakter beperkt is, kan het wel (wandelaars, ruiters, bezorgers) en residentials hebben vaker een beperkte functie in het netwerk en regimes die bepaalde soorten uitsluiten, openbaarheid is geen vereiste.

Ik snap dat het een beetje schuurt, maar serie zou naar mijn idee een achteruitgang zijn, omdat dan de relaties is het systeem niet meer goed te herleiden zijn. Maar wil er ook geen halszaak van maken (-:

Dank voor de oplettendheid en reparatie, Dick! En excuus voor de slordigheid.

1: zoals uitgelegd volgt foot=yes in OSM niet _per definitie_ uit footway, is dus (helaas!) niet dubbelop. Footway is immers NIET gedefinieerd als "only for ways the public where official, legally-enshrined right of access" (OSM-definitie van "yes"íin teremen van access). Een footway kan ook access=permissive hebben.

Zie oa ook https://forum.openstreetmap.org/viewtopic.php?pid=727116#p727116 en eerdere discussie daar.

2. Revert is wel mogelijk na deze tijd als je handmatig tags op de betreffende wegen terugplaatst, na eerst de wegen te hebben uitgesloten die in de tussentijd al wel weer een waarde voor foot=* gekregen

3. Ik heb alleen deze changeset (56160591) teruggedraaid en dan alleen voor het foot=yes betreft in die gevallen waar dat niet in de tussentijd is verbeterd.

Het verzoek ziet op de overige, nog niet herstelde tags en met name op de overige gelijksoortige changesets, waarvan ik er toevallig twee ben tegengekomen, maar ik weet niet hoeveel meer er nog zijn.

Als je dat niet zelf kan doen, dan zou ik het waarderen als je een link naar de changesets plaatst in https://forum.openstreetmap.org/viewtopic.php?id=64585

Daar zal ik ook verder inhoudelijk reageren.

Dit is een schadelijke undiscussed mechanical edit op meer dan 800 ways. In strijd met osm.wiki/Automated_Edits_code_of_conduct
Hierbij is data verloren is gegaan
Graag herstel. Zie verder

osm.org/changeset/56160591#map=9/52.5780/5.1031

https://forum.openstreetmap.org/viewforum.php?id=12

Dit is een schadelijke undiscussed mechanical edit op meer dan 1.700 ways. In strijd met osm.wiki/Automated_Edits_code_of_conduct
Hierbij is data verloren is gegaan en zijn wegen die in het echt toegankelijk zijn (en waren in OSM) dat nu niet meer zijn na verwijderen foot=yes (bijvoorbeeld in combinatie met access=no of access=private).

Graag herstel. Zie verder

osm.org/changeset/56160591#map=9/52.5780/5.1031

https://forum.openstreetmap.org/viewforum.php?id=12

Dit is een schadelijke undiscussed mechanical edit op meer dan 1.800 ways. In strijd met osm.wiki/Automated_Edits_code_of_conduct
Hierbij is data verloren is gegaan en zijn wegen die in het echt toegankelijk zijn (en waren in OSM) dat nu niet meer zijn na verwijderen foot=yes (bijvoorbeeld in combinatie met access=no of access=private).

Voor zover waarde van foot in tussentijd niet is teruggeplaatst of verbeterd (permissive ipv yes), is deze changeset teruggedraaid in osm.org/changeset/64845766

Zie bijvoorbeeld osm.org/way/88010524/history ; osm.org/way/508371523/history ; osm.org/way/376836104/history

Ook is in andere gevallen informatie over rechtsgrond van openstelling zonder lokale kennis verwijderd; foot=yes beoogt immers aan te geven dat een pad openbaar is, in tegenstelling andere waarden zoals foot=permissive of foot=customers.

Dit blijkt bovendien niet de enige vergelijkbare grootschalige schadelijke edit, zie bijvoorbeeld ook osm.org/changeset/56160165
(ca 1.750 wegen ) en osm.org/changeset/56160412
(ca 850 wegen)

Graag herstel van de gesloopte tags in bovenstaande en overige wijzigingen, dank alvast.

Zie verder https://forum.openstreetmap.org/viewtopic.php?id=64585

Reverted; outer for proper multipolygon was removed and replaced by overlapping huge patch of grass, (just like in
osm.org/changeset/52354931 ); leaving mulipolygon without its outer

Mapper has not responded to any of the 16 earlier changeset comments (including one earlier request from me to restore surveywork that was replaced by mapper with data from old aerial photo's):
http://resultmaps.neis-one.org/osm-discussion-comments?uid=1247041

Hi, thanks for pointing that out! It was a typo with autocomplete in JOSM, in was meant to be route=motorboat.

Corrected it in changeset for all cases with thisi tag osm.org/changeset/61698234

A question in return maybe you can help me with, so I can see my own mistakes in the future:
-is there a validation tool you use to find these strange values in relations?

-do you know a way to look at all the values at once in a key for _relations_ in JOSM, so you can spot the strange ones that need examination?

I kwow how to do it for ways, but with relations I still need to check one at a time..

Thanks for your help!

Hoi, dat stond me inderdaad ook bij, en de legger van Rijnland bevestigt dat ( http://rijnland.webgispublisher.nl/?map=Legger-watergangen ).

Heb de naam toegevoegd, ook op het deel aan de andere kant van de Vlietlanden bij de A4.

Op http://topotijdreis.nl/ is te zien dat het gewoon één sloot was (zonder naam op de topografische kaart, maar de legger is meer gedetailleerd en maatgevend als het om water gaat) en dat rond 1974 de zandafgraving er een plas van heeft gemaakt. Net als de Weegsloot even zuidelijker. Groeten.

Dank dat je hierop wijst, Dick, ik probeer zo goed mogelijk na te gaan of ik bij knippen geen andere relaties in de war gooi, maar op deze variant was ik nog niet bedacht.

Als de bestaande routerelatie voorafgaand aan knippen uit slechts 1 lid is, dan zou je na knippen dus eigenlijk niet alleen naar het verloop van het routevenster moeten kijken, maar ook of de eerste weg wel begint bij het knooppunt met het laagste van de twee nummers in [note].

Net toen ik dacht de workflow het nu wel in de smiezen te hebben komt er toch nog iets bij. Doe mijn best, maar kan niet garanderen dat er niet toch nog af en toe iets doorheen glipt (-;

Dank voor je niet aflatende kwaliteitscontrole!

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.