PS Zie ook osm.wiki/Key:name

Hoi,

Dank voor je bijdrage. Mooi dat je BAG-namen toevoegt aan OSM! Je hebt hierbij oude namen verwijderd en vervangen door BAG-namen.
Als een naam niet echt fout is, dan is het beter om 'm niet weg te gooien, maar om verschillende naamvelden te gebruiken, zodat de verschillende namen naast elkaar kunnen blijven bestaan.

in key:name plaatsen we in OSM de meest gehanteerde naam, en dat is niet altijd de BAG-naam.

In dit gebied speelt dat er meerdere namen zijn voor een weg, bijvoorbeeld andere waarde op borden langs de weg dan in BAG of andere namen die zijn ingesleten bij het publiek en die je ook in de BRT / op Topkaarten ziet.

Dan zetten we de bag-waarde niet in name maar in official_name=*

Het is hier wel een puzzel, heb een poging gedaan om alle namen een plek te geven, ook obv foto's van eerder veldwerk met afwijkende namen zoals:
- https://www.mapillary.com/app/?pKey=3303137146456475
- https://www.mapillary.com/app/?pKey=773932400178334
- https://www.mapillary.com/app/?pKey=738184296850110 (die laatste is in ref gekomen, hier zie je 3 namen in verschillende bronnen.. )

Zie osm.org/changeset/110559314

Groet!

Hoi Leo, ik heb die naam niet zelf toegevoegd, dat was Wyo in v2: osm.org/way/525469285/history#map=16/53.1308/5.9397

Maar omdat ik je kwaliteitszorg erg waardeer heb ik er wel even naar gekeken:

-BGT (die punten bevat voor BAG-openbare ruimtes , ook water) noemt hier niets
-BRT (en Top25)noemen alleen "It Wiid"
-Een snelle google-zoekopdracht op "It Wild Ernerwoude" leverde bij snelle blik niet veel herkenbaars op (misschien een vorm van description in de name?)
-"Eernewoudsterwijd" levert wel veel relevante hits op, de mooiste :
https://books.google.nl/books?id=EmJeAAAAcAAJ&pg=PA66&lpg=PA66&dq=%22Eernewoudsterwijd%22#v=onepage&q=%22Eernewoudsterwijd%22&f=false

Mijn voorstel zou zijn om de huidige naam te verplaatsen naar "alt_name" en de naam die jouw contact opgaf te plaatsen bij "name"

Wil jij dat doen of zal ik dat doen?

Voor mij is dit weer een goede stimulans om eraan te denken steeds source:name te gebruiken (-:

Groet!

Thx!

Hoi, dank voor je opmerkzaamheid. Heb mijn foto's nog even bekeken en volgens mij heb je gelijk.

Wil jij het wijzigen of zal ik dat doen?

Groet!

Hoi, dank voor je bijdrage. Als een pad overwoekerd is, dan is het beter om een lifecycle-prefix te gebruiken dan om het helemaal te verwijderen uit OSM. Zie osm.wiki/Lifecycle_prefix . Ik heb het als disused:highway hersteld.

In een ander seizoen of na een maaibeurt kan het er weer anders uitzien en het voorkomt ook dat een andere mapper het pad opnieuw toevoegt bijvoorbeeld op basis van oude data uit luchtfoto's, AHN, Strava Heatmaps etc. Hartelijke groet!

Hoi, canoe=portage geeft aan dat je over dit stuk waterway niet kan varen, maar dat je je daar omheen moet via land. Waar dat dan precies gebeurt is een tweede, in dit geval zal dat inderdaad via de steigers gaan en voor zover ik dat vanaf het fietspad kon zien zou dat als je vanaf het water komt nu goed moeten gaan. Maar omdat dat nog niet 100% zeker is (eerder 90%..) heb ik nog geen pad tussen de steigers gemaakt waarmee je naar de andere kant kan routeren. Ik ga binnenkort eens vanaf het water kijken en heb in de tussentijd nav je bericht een fixme op de canoe=portage gezet. Groet!

Daarom staat er ook canoe=portage: je kan hier niet varen en dus moet je overdragen, en dat doe je over land (-; Het is een verfijning op "no", net zoals bij bicycle=use_sidepath.

Dank nog voor het toevoegen van deze overdraagsteigers (-: Fietspad langs de Limietsloot was vandaag nog steeds dicht.

ALS een weg openbaar is in de zin van de Wegenwet (door plaatsing op de wegenlegger of verjaring) dan moet zowel voor het plaatsen van een bord "eigen weg" als voor een "Verboden toegang" bord een ontrekkingsbesluit worden genomen , tussen die twee borden zit in dat opzicht geen verschil.

Recht van overpad doet er daarbij niet toe, want dat gaat niet het recht van het algemene publiek, maar dat is het recht van de eigenaar van een heersend erf ten opzichte van een dienend erf. Dat is dus iets tussen de respectievelijke grondeigenaren.

Beste R van Velthoven,
In aanvulling op wat de andere mappers al hebben gemeld (bij wie ik mij aansluit) nog het volgende:

-Als u de term "eigen weg" toch nog aanvullend wilt plaatsen in de OSM-database op een manier die niet de hierboven genoemde fouten geeft, dan kan dat met de tag designation:NL:wegenwet=eigen_weg

-Uit uw berichten maak ik op dat het uw bedoeling is om mensen te weren van de betreffende weg. Ik zag deze foto van de borden zoals ze afgelopen september aanwezig waren: https://goo.gl/maps/YtbUwoMH2JzyJdZx6.

Als dat nog steeds klopt, dan is het goed om in het achterhoofd te houden dat een bord "eigen weg" nog geen verbod aangeeft, het geeft alleen maar aan dat de rechthebbende naar wens de toegang kan ontzeggen zonder een publiekrechtelijk verkeers- of onttrekkingsbesluit. Vrijwel alle wegen/paden in onze opengestelde (en drukbezochte) natuurgebieden zijn ook eigen wegen in plaats van openbare wegen

Ook het links geplaatste bord met een rode rand houdt geen verbod voor voetgangers in, dat werkt slechts voor voertuigen.

Als u daadwerkelijk de toegang wilt sluiten voor het algemene publiek te voet, dan kunt u een bord "verboden toegang" plaatsen (zonder de toevoeging "voor onbevoegden").

Als dat er hangt dan kan de weg in OSM worden getagd als access=private.

Met vriendelijke groet.

Hoi, volgens mij is die foot=permissive hier terecht. De gemeente Ermelo plaatst op dergelijke paden access_signs met verwijzing naar art 461WvS, waardoor het dus geen openbare weg in de zin van de Wegenwet is, maar een eigen weg. En daarbij is permissive de passende tag. Zie ter https://goo.gl/maps/4BQifxjb1tskm1FP7 en een leesbare versie van het bord https://www.mapillary.com/app/?pKey=3921300981258893.
Overigens is permissive de juridische default in ons recht; het is aan degene die zich beroept op openbaarheid is om te bewijzen dat een weg openbaar is.

Hoe dan ook is het prima dat wordt aangegeven dat je hier mag lopen (of het nu met yes of permissive is ;-)

edit.. "maar het is een stuk ongebruikelijker dan oneway:bicycle=yes (volgens taginfo wordt die tweede meer dan 100x zo vaak gebruikt). "

Hoi, ik deel hier de voorkeur van BikePC.

Op zich klinkt bicycle:forward=use_sidepath mij ook niet onjuist in de oren, maar het is een stuk gebruikelijk dan oneway:bicycle=yes (volgens taginfo wordt die twee meer dan 100x zo vaak gebruikt).

oneway:bicycle=yes is volgens mij ook correct en de kans dat datagebruikers dat correct verwerken lijkt me veel groter dan bij de weinig gebruikte samentrekking van forward en use_sidepath (helaas wordt zelfs de gewone bicycle=use_sidepath lang niet door alle datagebruikers goed ondersteund, ook niet door een betaald app als Komoot, zag dat ook mis gaan bij routers van navigatiefabrikant Bryton). Groet!

Beste Dick, zoals ik ook eerder heb aangegeven denk ik natuurlijk graag mee bij oplossingen als tagging die ik heb toegevoegd tot problemen leidt bij jou goede werken met knooppuntvalidatie.

Maar in dit geval zit het probleem toch echt in het gebruik van Knooppuntnet en is de nu gebruikte tagging naar mijn mening de meest geëigende.

Alternatieve vormen van tagging leiden tot meer problemen: algemene access=no wordt genegeerd bij een positieve waarde voor foot (wat op de fietspaden al leidde tot weggooien van correcte data) en voor foot kiezen veel routers om begrijpelijke redenen om ook te routeren over highway=construction, want in de praktijk gaat dat doorgaans ook vaak prima.

Knooppuntnet merkt nu geheel terecht op dat de routes niet toegankelijk zijn, en dat klopt met de situatie in het veld. Dat is dus op zich geen reden om de tagging aan te passen.

Maar wat natuurlijk wel vervelend is, is dat het voor gebruikers van Knooppuntnet, zoals jij, lastiger is om nieuwe feiten die _wel_ en fout in de OSM-tagging zijn te zien.

De oplossing ligt dus in het maken van onderscheid tussen wel vs niet in OSM-oplosbare feiten. Dat doen we ook al bij RouteIncomplete met een fixme=incomplete. Dan weet je dat je daar als mapper nu ook geen gat in een route hoeft te plakken.

Ik heb daarvoor een voorstel gedaan op Github en een fixme toegevoegd op de betreffende paden.

Als je Marc tijd wil besparen zou je een pull-request kunnen maken. Zie
https://github.com/vmarc/knooppuntnet/issues/193

Hartelijke groet.

Hoi, ik neem aan dat je de rijbaan van de Industrieweg bedoelt?
(zoals https://osmlab.github.io/osm-deep-history/#/way/7436667 )

Inderdaad merkwaardige assymetrische situatie daar en oneway is dan inderdaad beter dan use-sidepath( want die laatste geldt wel in ZO-richting, maar niet in NW).
Voor het mooie misschien nog even de richting van de way in OSM omkeren zodat het oneway:bicycle=yes wordt ipv het minder gangbare -1?
Groet!

Hoi, Eggie geeft het belangrijkste al aan: Komoot zou gewoon niet over deze weg moeten routeren voor fietsers, ongeacht of het "no" of "use_sidepath"is. Er gaat wel meer mis bij die app en ze geven idd lang niet altijd thuis bij problemen, ook beheerders van landgoederen/natuurgebieden hebben last van onjuist gebruikt van/door Komoot .

Vanaf de "oprit" bij pannekoekenboerderij staat er idd een C15, maar die is strikt genomen maar geldig tot de volgende zijweg (hoofdrijbaan N446). Ook als dat bord daar zou zijn herhaald blijft het lastig, vanaf de ene kant gezien is er een G12a, dus use_sidepath, vanaf de andere kan zou het no zijn. Hier wreekt zich dat we in OSM teveel vragen tegelijk willen beantwoorden in de ene access-key, dat hadden we beter op kunnen splitsen, nu moet je bijvoorbeeld bij positieve waarden ook verplicht kiezen tussen "yes" en "permissive", ook als je wel weet _dat _ je er mag komen, maar niet weet wat de juridische grondslag is. Ook met designated is dat lastig, want dan kan je die grondslag weer niet kwijt. Al dat soort nuances zouden we beter in een sub-key kunnen zetten en de access key simpel houden, bijvoorbeeld "toegang zonder beperkingen"/ "toegang met beperkingen" / "geen toegang". Maar dat is helaas in de huidige setting nauwelijks meer haalbaar..

Voor nu deze weg gewoon maar zo laten en probeer Brouter of Osmand eens als site / app voor fietsen (-:

Hoi Dick, hopelijk weet je hoezeer ik al jouw dagelijkse werk voor de kwaliteitscontrole voor routes in OMS waardeer en dat ik ook vin ddat er daarvoor best wat water bij de wijn mag om dat werkbaar te houden (zie gekleurede lussen/wandelknooppunten Overijssel). Persoonlijk vind ik de het in tact laten van deze wegen niet optimaal, aangezien een deel echt disused -of erger- is door beschadigingen en obstakels. Maar als dat jou voor nu helpt vind ik het prima. Laten we wel samen kijken hoe we dit kunnen oplossen aan de kant van de validator, want dat is de bron in dit geval.
Ik heb in dit gebied erg veel werk gestopt in de access-tags (en nog genieg werk te doen). Om goed herstel van wijzigingen mogeljk te maken zou ik je wel graag willen vragen om hier access-tags niet te verwijderen, maar om die aan te passen in de key. Dus bijvoorbeeld foot=yes -> disused:foot=yes oid. Dat geeft zelfde effect en is veel beter te herstellen als de gebieden weer opengaan. Een van de overwegingen bij die constructie (zoals ook in disused:highway) is dat deopenstelling waarschijnlijk bloksgewest zal gaan en revert dan ook niet werkt (los van de risico's bij tussentijdse wijzigingen). Dank en groet!

Hoi Dick, ik heb direct contact met mensen die daar bezig zijn met herstel en bewust voor deze aanpak gekozen. Met access=no kom je in de knel als er positieve access-tags staan voor bepaalde vervoerswijzen (zoals bicyle=yes en bicycle=permissive die het verschil aangeven tussen openbare wegen en eigen wegen, wat hier speelt).
Daar helpt een algemene access=no niet, want specifieke waarden overschijven algemene waarden.
Het overschrijven van die specifieke waarden maakt herstel erg lastig, zeker als er nieuwe bewerkingen volgen en een revert niet werkt.
In dit geval is er ook haast bij, mensen komen onverwachts in de problemen als ze voor een heel afgesloten gebied komen. En als dat gebeurt is er een groter risico dat ze alsnog dit gevaarlijke gebied in gaan. Als er een functioneel forum was dan had ik dat graag gebruikt, maar de ervaring met het OSM-NL forum is helaas dat mensen vooral kritiek verzinnen (of off-topic gaan) ipv samen tot een goed compromis te komen. Zie bijvoorbeeld het voorbeeld van de mtb-routepaaltjes in dit gebied waar ondanks de constructieve opstellen van PeeWee dit pagina's lang niet verder komt.

En als een validator een route door dit gebied als afgesloten ziet: dat is helemaal terecht: ook de fietspaden in dit gebied zijn afgesloten. Ik wacht nog op bevestiging mbt Let de Stigterpad ten westen van N226 (die heb ik dus opgengelaten). Groet!

Hoi mannen. Het zijn hier met name impliciete verboden (die voortkomen uit aanwezigheid van een parallel verplicht te gebruiken fiets- / bromfietspad; G12a en geen C15. Zoals te zien in verkeersbordenbestand van Smoothefiets en ook met fotoś op bijvoorbeeld https://goo.gl/maps/zY9UMkKT3sU1rY8m8 en https://goo.gl/maps/MWV4E7TJYe38tLJV8 .

Vanaf een andere kant staat er weliswaar een C15, maar als we het toch strikt gaan bekijken: die geldt maar tot de aantakken op de "echte" N446.

Zoals Eggie zegt zouden beide varianten (no / use_sidepath) hetzelfde effect moeten geven voor routeerders (fietsers hier niet overheen sturen). Naast de bijzondere gebakjes die toch op de rijbaan mogen vertelt use_sidepath je ook ook nog iets: er is een parallele weg die je wel mag gebruiken. Bij no verwacht je dat niet. Groet!