Hoi Gri,

het conflict zit erin dat je als fietser op basis van de algemene key access=no er niet zou mogen fietsen en op basis van bicycle=yes (wat incorrect is op een opengestelde eigen weg) niet. Dat moet vervolgens worden opgelost met het overschrijven van de ene waarde de andere, wat bij simpele gevallen nog wel goed gaat, maar bij exotische values en conditionals niet.

Daarom wordt even verderop in access=*#Transport_mode_restrictions ook geadviseerd om de algemene key:access te vermijden en specifieke keys te gebruiken als de toegang verschil per vervoerswijze.

Het voorbeeld dat je aanhaalt gaat ook niet over de algemene key:access

Het zijn ook geen paden waarop de omschrijving van access=no op van toepassing is "The access=no tag indicates that the object is not to be used by the general public" , de paden staan immers wel open voor het openbaar verkeer dat voldoet aan de toegangsvoorwaarden (zie ook uitspraak mtb route Schoorl)

Zie verder ook oa https://community.openstreetmap.org/t/hoe-tag-je-de-path-en-track-in-dit-gebied/85934
en https://community.openstreetmap.org/t/broedseizoen-en-hond/94104/13

Vriendelijke groet!

https://community.openstreetmap.org/t/hoe-tag-je-de-path-en-track-in-dit-gebied/85934/2

Eens met Allroads,
zie changeset/133212532

Eens met Allroads, het is niet de bedoeling om eerdere correcte bijdragen van andere mappers te verwijderen en te vervangen door een minder informatierijk element (hier een tag op een ander element in plaats van een eigen geometrie).

En ook het doorgaan met zulke edits in plaats van te reageren op een eerdere changesetcomment is niet de bedoeling:
changeset/132970794

@Seat Ibiza: wil je deze verwijderingen ajb terugdraaien? Dank alvast!

Hoi Dick, vervelend om te lezen dat je het als negatief hebt ervaren, maar ik snap niet zo goed wat hier nu is misgegaan:
zoals ik schreef heb ik Peter Elderson gevraagd om naar de routes te kijken en nadat hij aangaf dat te zullen gaan doen heb ik [20] terug verplaatst naar de plek waar die werkelijk staat.

Je had hier verder geen moeite in hoeven steken, wat Peter zou de routeproblemen -die samenhangen met bijzondere karakter van dit netwerk- oplossen.

Hopelijk toch nog een fijne avond verder en met vriendelijke groet.

Hoi Dick, ik was daar gister en zoals het nu in OSM was gedaan was het voor gebruikers in het veld echt verwarrend omdat het niet overeenkomt met de werkelijkheid: het nummer stond bij de verkeerde kruising van wegen.

Natuurlijk is de positie bij benadering, want we taggen _op_ de kruising, terwijl de paal _naast_ de kruising staat, maar we taggen wel op de kruising waar de paal in werkelijkheid bij staat.

Ik heb nr 20 weer verplaatst naar de kruising waar die daadwerkelijk staat, maar omdat ik het ook snap dat het prettig als als je geen validatorfouten hebt, heb ik ook Peter Elderson -die de knooppuntroutes hier heeft gemaakt- gevraagd om naar de routes te kijken en hier te reageren.

En omdat het een beetje atypisch knooppuntennet is, met overlappende en verschillende routes en wel/niet genummerde "knoop"punten, vind ik het ook prima om dat expliciet te maken binnen network:type , zodat Vmarc deze bijvoorbeeld buiten de lijsten laat. Ik dacht aan network:type=spaghetti (-;

Hartelijke groet

Hoi Dick, je had in deze changeset lwn_ref=20 verplaatst naar een noordelijke kruising, maar hij stond eerst op de juiste locatie en en na deze changeset niet meer.

Zie bijvoorbeeld deze foto op Mapillary: https://www.mapillary.com/app/?pKey=124630650085294

Ik was hier gister en 20 stond nog steeds op de zuidelijke kruising waar ik 'm eerder ook al had gezet na survey.

Zou jij 'm weer terug willen plaatsten?

Hartelijk bedankt alvast!

Hoi, ik neem aan dat de discussie ging over de foto die aangehaald is in "soure: " bij de Changeset?

Van dat bord heb ik een tijdje terug een foto op Mapilary gezet, die mag je wel gebruiken voor OSM

Foto: https://www.mapillary.com/app/?pKey=482144582889477

Licentie:
https://www.mapillary.com/osm?locale=nl_NL
"Rechten voor OpenStreetMap
Je hebt het recht om elk beeld van Mapillary te gebruiken, de metagegevens te bewerken en op te halen om bij te dragen aan de inhoud van OpenStreetMap. Dergelijke metagegevens kunnen bijvoorbeeld huisnummers, verkeersborden, straatnamen, beschrijvingen van gebouwen en de staat van wegen omvatten. Afgeleide metagegevens kunnen rechtstreeks worden gepubliceerd in OpenStreetMap conform de . Mapillary-beelden zijn beschikbaar op basis van een open licentie

Mapillary waardeert de toeschrijving van afgeleide metagegevens. Dit kan bijvoorbeeld door de tag source=Mapillary te gebruiken of een koppeling naar mapillary.com bij te voegen. Dit stelt ons ook in staat om bij te houden en inzicht te krijgen in welke typen gegevens en beelden het nuttigst zijn voor OSM en deze kennis mee te nemen bij de ontwikkeling van onze tools."

Groet!

https://www.mapillary.com/app/?pKey=482144582889477

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 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 changeset/87156667 en 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