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

Reverted:

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

highway=track#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 highway=track#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 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 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!