OpenStreetMap logo OpenStreetMap

Changeset When Comment
56160412

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

changeset/56160591#map=9/52.5780/5.1031

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

56160165

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

changeset/56160591#map=9/52.5780/5.1031

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

56160591

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 changeset/64845766

Zie bijvoorbeeld way/88010524/history ; way/508371523/history ; 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 changeset/56160165
(ca 1.750 wegen ) en 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

62015144

Reverted; outer for proper multipolygon was removed and replaced by overlapping huge patch of grass, (just like in
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

61668612

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 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!

60886347

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.

61479308

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!

61139679

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.

61061207

Graag gedaan (was leuk peddelen) en excuus!
Was onbedoelde fout, nu hersteld:
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.
relation/8438301

60230594

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

60183861

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

59113192

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

58871107

Hoi, tagging van conditionals tijd en bepaalde vervoerswijzen is altijd even gemeen, heb het aangepast, zie 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.

58820331

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.

58820331

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!

57925320

Goed initiatief, en mooi dat dit wordt opgepakt!

58553251

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..

58553251

Hoi, je hebt deze weg op motor_vehicle=permissive gezet vanwege het onderbord mbt vergunninghouders
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 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

58553191

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.

57925320

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 (-: