Graag gedaan en geen probleem, overkomt ons allemaal wel eens (-:

Hoi emvee,

Ik kreeg nogal bijzondere routeringsresultaten met de fiets rond de Marnixstraat. Oorzaak bleek dat de bicycle=use_sidepath die in deze changeset terecht was toegevoegd op het meest noordelijke wegvak op de gehele Marnixstraat was gekomen (dus ook op het deel waar geen fietspad langs loopt).

Zie v17 in
https://osmlab.github.io/osm-deep-history/#/way/7450303

Ik zal de Marnixstraat opknippen en op het zuidelijke deel de "use_sidepath" vervangen door "yes"

De werking van verkeersverboden in de lengterichting is tegenwoordig nog meer iets om scherp op te blijven (ook voor mijzelf) nu in OSM wegvakken worden samengevoegd. Daarmee wordt de kans op te grote werking van verboden in OSM groter dan als elke wegvak (tussen elke zijweg zoals bedoeld in de Wvw) een eigen OSM-way is.

Groet!

Goed bezig hier met die watervlakken die op elk zoomlevel de juiste verhouding tussen land en water blijven aangeven en die -net als in het echt- niet overal haakse hoeken maken!

Beste FM2441, fijn dat je reageert.Ik twijfel er niet aan dat je veel goede edits doet en dat waardeer ik zeker ook, en iedereen maakt weleens een foutje, ik ook.Alleen hier gebeurt iets bij herhaling vanuit een insteek die niet in Openstreetmap past, namelijk het bewust verwijderen van -binnen OSM correcte- namen omdat ze niet in BAG/NWB staan.
Ik vraag je zeker niet om te stoppen met mappen -alsjeblieft niet, daarvoor waardeer ik je bijdragen te veel- alleen wel specifiek met het stoppen van het op deze manier verwijderen van correcte data uit OSM.Dat dit nu gaat om een edit van een jaar geleden komt juist door de werkwijze die frictie geeft, namelijk het verwijderen van data die door een andere mapper is toegevoegd -die niet onjuist is- zonder dat af te stemmen met die vorige mapper.En omdat er niet is afgestemd met de vorige mapper zie ik die verwijdering dus alleen achteraf bij toeval -, en daar gaat dan inderdaad wat tijd overheen. Dat maakt het juist des te vervelender en dat had voorkomen kunnen worden door even af te stemmen over wat nu een handige werkwijze is in zulke gevallen.  En als er dan geen reactie komt op berichten hierover, dan helpt dat ook niet bij het humeur (-; 
En zoals aangegeven wil ik ook best meedenken over hoe je in OSM kan aangeven dat een bepaalde naam wel in OSM voorkomt, maar niet in overheidsbestanden zoals BAG / NWB daar zijn echt wel dingen voor te bedenken.En bij verschil tussen namen in OSM / BAG zijn er ook dingen te verzinnen waarbij de informatie behouden blijft, zoals het verplaatsen van een van de twee naar official_name of alt_name  
Juist door af te stemmen kunnen samen de data verbeteren zodat het past voor de verschillende gebruiksdoelen die allemaal een plek verdienen in OSM, maar dat bereiken we niet door correcte data zonder afstemming weg te gooien.Dat is ook verwoord in de good practice van OSM: osm.wiki/Good_practice#Don't_remove_tags_that_you_don't_understand
Vandaar wil ik wel mijn verzoek herhalen:
1. kan je aangeven in welke changesets je nog meer namen hebt verwijderd die binnen OSM correct (kunnen) enkel omdat die niet in BAG/NWB etc. staan ?

2. wil je die verwijderingen herstellen?

Ik kan je ook helpen bij het vinden van changesets en met tips voor herstel, maar het is niet aan mij om alle changesets na te gaan lopen.

Vriendelijke groet

Hoi, in deze changeset zijn op het van het Kraanvrouwenpad ten onrechte waarden van name= verwijderd , terwijl deze in het veld zijn aangegeven.
Dat deze niet in het NWB of de BAG staat doet er voor name= in OSM niet toe -zoals eerder aangegeven-, de werkelijkheid in het veld (of lokaal gebruik) gaat voor, zie osm.wiki/Key:name

Wil je dit alsjeblieft niet meer doen en andere verwijderijderingen die je hebt gedaan herstellen?

Als je een kenmerk wilt toevoegen dat de betreffende naam niet in een overheidsbestand voorkomt dan kan dat (documenteer bijvoorbeeld een tag als noname:official=yes oid), maar verwijderen van correcte OSM data is niet de manier, zeker niet zonder eerst af te stemmen met de mapper die dat heeft toegevoegd.

Ik heb je twee keer eerder om herstel van die verwijderingen gevraagd, maar daarop kreeg ik helaas geen reactie. Zie osm.org/changeset/87156667 en osm.org/changeset/92127868

Drie keer is hopelijk scheepsrecht?
Groet!

Dank voor het corrigeren, Dick!
Mijn knooppuntenkunde was een beetje roestig geraakt (-;
Groet!

Sorry, door eerdere ervaringen heb ik hier te snel op gereageerd Bij start van het herstel zag ik dat de naam op andere delen wel was blijven staan en dat de nieuwe afbakening beter overeenkomt met die van de legger oppervlaktewater dan de oude.
Jouw changeset was dus een verbetering ten opzichte van mijn oude.

Groet!

Hoi, je hebt hier namen verwijderd van watergangen die correct in OSM stonden en overeenkwamen met de legger Oppervlaktewater van Rijnland.

Waarom?

Dat een naam niet voorkomt in een bestand dat je zelf gebruikt (wegenlegger?) betekent niet dat die naam daarom uit OSM verwijderd kan worden.

Deze zal ik zelf hersteld, zou je zelf andere namen willen herstellen die je hebt verwijderd?

Ik heb geen tijd en zin om al je changesets te moeten controleren hierop.

Bedankt alvast hiervoor.

==
Zie https://osmcha.org/changesets/90258992/ en https://rijnland.maps.arcgis.com/apps/webappviewer/index.html?id=25694eb316fc45e08a47413f80ae8f9f

Bedankt voor je opmerkzaamheid. Had in de haast een typo gemaakt, is nu gecorrigeerd (-:

Hoi, ik heb place=island even hersteld (en man_made=polder behouden). De eerste is niet onjuist en de tweede is een mooie aanvulling daarop die duidelijk maakt dat het geen "typisch" eiland is.

Wijzigen van de place=* kan altijd nog als er een meer specifieke place-waarde wordt ingestemd.

Zie ook
https://community.openstreetmap.org/t/polder-als-place-island/3973/7

Groet!

Hier is correct onderscheid path/track verwijderd uit de data en op sommige wegen ook foot=* en bicycle=*

Per weg hersteld obv informatie in de historie om schade door conflicten te voorkomen.

hersteld, niet afgestemde verwijdering van correcte data. Helaas is access:conditional de ingestemde tag voor tijdelijke sluitingen, terwijl opening_hours makkelijker werkt en ook gebruikt / ondersteund wordt
osm.wiki/Conditional_restrictions#Condition

Reverted; incorrecte wjzigingen permissive->yes op wegen met art 461 openstellingregels; te algemene vervanging doro vehicle=no zonder dat bekend is of carriage daar wel/niet mag rijden etc

Reverted:

Hier is informatie weggegooid, naast onderscheid path/track ook tracktype

osm.wiki/Tag:highway%3Dtrack#Access : "highway=track does NOT imply any particular access=* value".

Reverted.

-wijziging zat nog in de conceptlijst..
eerder opgesteld bericht
- Hoi Ankeric, in deze changeset gaan een aantal zaken niet goed en raakt -zonder afstemming met de betreffende mapper- informatie verloren uit onze database ( zie ook https://osmcha.org/changesets/87805072/ ), oa:

1. De redenering op basis waarvan track in path wordt omgezet (vehicle=no) is onjuist. Dat "vehicle=no, dus geen track" volgt niet uit de wiki en is ook geen gevestigd gebruik onder mappers in NL. Zie bijvoorbeeld osm.wiki/Tag:highway%3Dtrack#Access : "highway=track does NOT imply any particular access=* value". Als jij of ik een tractor kopen mogen we daar niet rijden, de beheerder kan en mag dat wel en kan naar eigen goeddunken toestemming geven aan derden om daar met een tractor of ander voertuig te rijden. (als je heel erg hecht aan consistentie zou zou je op voor voetgangers opengestelde eigen wegen vehicle=private ipv no kunnen taggen, maar dat is niet erg gebruikelijk). Path heeft nooit beoogd om track te vervangen (wel cycleway, bridleway en footway), zie de proposal.

Nu zie je niet meer dat deze weg breed genoeg is om met z'n 2-en naast elkaar te lopen (path ipv track).

2.Tracktype=* is verwijderd, hierdoor is informatie over de mate van verharding is verloren gegaan

3. Ook hier is de daarvoor (helaas..) ingestemde gebruikelijke notatie van access:conditional vervangen door het hiervoor niet gebruikelijke en minder goed ondersteunde opening_hours. En helaas nog niet gerepareerd ondanks onze eerdere discussie in osm.org/changeset/72420330

4. Op een weg in dit gebied met een seizoensgebonden sluiting (15 maart - 1 juli; link naar foto van bordje staat NB in de tags..) heb je vervolgens de informatie over de seizoenssluiting helemaal verwijderd https://osmlab.github.io/osm-deep-history/#/way/453086379

5. Ook expliciete aanduidingen van seasonal heb je verwijderd. De afwezigheid van seasonal=yes betekent bepaald niet dat een mapper heeft vastgelegd dat er geen seizoenssluiting is ("argument from ignorance") . Zelfs als mappers openingstijden taggen gebeurt dat vaak nog onvolledig; dat hebben we beiden eerder ook zelf gedaan.

6. Je wijzigt foot=permissive ten onrechte in foot=yes, terwijl dit conform de bebording geen openbare weg in de zin van de wegenwet is en de toegang tot deze specifieke wegen niet wettelijk gewaarborgd is (voor het gebied als geheel kan dat misschien anders liggen, maar het gaat in deze tahs om de specifieke wegen). Dit heb ik je al eerder aangegeven / gevraagd bij op osm.org/changeset/87804237 , helaas bleef reactie uit

Ik vind zulke slordige edits van eerder werk ontmoedigend en helemaal als dat zonder overleg gebeurt. Foutjes herstellen is natuurlijk goed, maar als je het idee hebt dat een frequente mapper structureel dingen verkeerd doet dan is de weg voorwaarts niet om het zonder overleg aan te passen, maar om dat aan te kaarten. Op die manier kunnen we elkaar aanvullen in plaats van elkaar onbedoeld tegen te werken.

Hoi, ik heb het verbod gister opgenomen in OSM, Brouter heeft het al verwerkt:
http://brouter.de/brouter-web/#map=14/52.1249/4.7475/standard&lonlats=4.759947,52.131267;4.752182,52.119237&profile=car-fast

De routers op osm.org moeten de update nog doorvoeren:
osm.org/directions?engine=fossgis_osrm_car&route=52.13075%2C4.75987%3B52.11906%2C4.75191#map=14/52.1202/4.7596

Heb voor 1 januari 2023 een reminder in mijn agenda gezet om op te zoeken of er al iets bekend is over het voortzetten / opheffen van de afsluiting. Als jij eerder iets ziet in de lokale krant ben je natuurlijk welkom om het op te nemen.

Tijdelijke afsluitingen zijn inderdaad een punt van discussue, wat je in ieder geval niet wil is dat je een onderweg een afsluiting ziet die maar een paar dagen zal duren, dat als een verbod in OSM zet en er vervolgens niet meer naar omkijkt waardoor het lange tijd ten onrechte als gesloten in OSM staat.

Naar mijn mening gaat het erom dat je het zo doet dat er op de meeste dagen de info in OSM overeenkomt met die in het veld.

Het oude argument van oflline updates eens in de x maanden is steeds meer achterhaald geraakt nu ook offline apps zoals Osmand dagelijks automatisch nieuwe updates binnenhalen zodra je aan de wifi hangt. Oude kaarten gebruiken is een keuze, dat zou het actueel houden van OSM niet moeten belemmeren, zeker niet niet gevallen als deze waar je zo'n 10km moet als je op weg naar de kano-overstapplaats met onder het verbod tegen de afsluiting aanrijdt (bij Zuidhoek was mij niet duidelijk of je die vanaf daar nog wel/niet kon bereiken, blijkt dus niet zo te zijn)

Groet!

Dank je!
Ik had gezocht naar een verkeersbesluit in de Staatscourant en kon daar niets vinden, stond dus in het Gemeenteblad..

Zelf ben ik geneigd om de aflsuiting die in het veld staat en die nog meerdere maanden van kracht is (en misschien ook langer blijft) wel in OSM op te nemen om ook in de komende tijd correcte route-adviezen te krijgen (kan anders aardig omrijden worden als je dit bord tegenkomt) en tzt bij de gemeente te checken of het verbod blijft / verdwijnt.

Vind je dat erg bezwaarlijk?
Groet!

Hoi, dank voor het bijwerken van de Ziendweg. Vanuit Zuidhoek zag ik vandaag een aankondiging van een verbod voor alle motorvoertuigen (RVV C12) " over 1300 meter).

Volgens onderstaande link van de gemeente zou dat op (een deel van) dit OSM- wegsegment moeten zijn, maar in jouw recente edit zie ik dat verbod niet.

osm.org/way/1093948920

Weet jij hoe het daar precies zit in het veld?

Bedankt voor je reactie!

Info van de gemeente:
https://www.alphenaandenrijn.nl/Onderwerpen/Bouwprojecten_en_reconstructies/Zwammerdam/Projectpagina_Ziendeweg

Dank nog voor dit herstellen Dick,
ik zie het nu bij toeval en snap niet waarom die tag network=rwn in mijn vorige changeset was verwijderd, moet per ongeluk zijn gegaan. Groet!

https://osm.mapki.com/history/relation/8417824

Hoi Baggeraar, heb ook deze hersteld, zie : osm.org/changeset/124977317

Groet!