Je kan pas bicycle=no vermelden als het C verbod vanuit beide richtingen geldt, bij de rotonde en de westelijke t-splitsing staat geen C bord, van die kant kan je met een fiets breder als 75 cm (use_sidepath kunnen zij gebruken) bij de boerderij komen. Als je bij de boerderij weg wilt gaan kan je niet links en rechts de N352 op. En moet je door het bos en het pad ( waar de status ook tegenstrijdig is, verplicht onverplicht)

Zie in tijd wel geen G12a en G13, nu 2022 is het bord weer weg. Weet ik uit survey. Overgang wegbeheerder Provincie / Gemeente. Daar al eerder melding van gemaakt.
https://www.google.nl/maps/@52.6392429,5.7226121,3a,59.7y,325.56h,78.88t/data=!3m7!1e1!3m5!1sPgvEga4YjRT7Nnvg0UsmSA!2e0!5s20220401T000000!7i16384!8i8192

Wanneer er aan 1 kant een C bord staat moet je eigenlijk een klein stukje op slot zetten, het is wettelijk toegestaan van de andere kant te komen en ergens op de weg te draaien/keren. En terug te rijden. Het is dan meer een inrijverbod.

Conclusie die bicycle=no moet er af want het wordt al geregeld met bicycle:forward en :backward.

Dat is een beetje hetzelfde als je de maxspeed regelt waar op een wegdeel twee regimes gelden, maxspeed:forward maxspeed:backward dan zet je ook geen maxspeed op de weg.

En voor moped en mofa zetten we er ook geen =no op.

foot=no is ook niet correct, er staat geen c bord die voetganger verbied, dan gebruiken we waar nodig use_sidepath.

Gezien bij de rotonde en de wegen voor de t-splitsing, de verplichting het fietspad te gebruiken komt op dat stuk ook use_sidepath

Ik heb alle stukken tussen de rotonde en t-splitsing bekeken, maar zie in de history nergens bicycle=yes staan.

way/6544254

Dit is het oudste history way vanuit de AND import, daar ook geen =yes.

Klopt, fout van mij, oneway verwijderd.
Over het hoofd gezien, En dan probeer je het nog zo goed te doen. Helaas. Bedankt, weer wat geleerd. Routering is lastig te controleren. Pas na een tijd als de routerings sites deze data heeft opgepakt.

je gaat voorbij aan dat er al bicycle:forward en :backward op staat, vanwege de bebording.
https://smoothefiets.ddns.net/html/verkeersbordenkaart/index.php?lat=52.639649608&lng=5.718359649&z=19
dus =no in bepaalde richtingen geldt.
bicycle=use_sidepath is dan niet correct.
verwijderd.

Hier ligt een route relatie over. Pionierspad - 04 Dan kan het niet staan op private.
De Gemeente plaatste op meerdere plaatsen andere borden terwijl de dijk van het Waterschap Zuiderzeeland een ander regime heeft. Wacht nog op antwoord.
Ik heb hier de private er af gehaald.

You changed (partly) back (southside) to key cyclestreet, we use cyclestreet with this traffic_sign, okay, but has no legal status, but why bicycle=designated on the north part there is no legal mandory, but also bicycle=yes and vehicle=yes, by default all can use it.

cyclestreet=*#Netherlands

Als je er vehicle=no op zet is het gesloten voor alle vervoersvormen behalve foot en horse, dus de fietser kan er niet langs, routering neemt een omweg.

Lastig, we hadden er al eens eerder naar gekeken, changeset/110295121#map=18/52.99045/6.29181 met vraag.

de tijden dat het begaanbaar is. Het kan dus heel wisselend zijn.
Meest aannemelijk is het aangeven van de winkeltijden, ook veranderlijk, en dus lastig. Dan moet je wel de winkeltijden weten om het uit voeren. Waarbij je ook nog de rolluik kan invoeren als barrier met access en tijden.

Mijn reactie was gebaseerd op "kan geen auto langs " en de uitvoering.
Waarbij tunnel=building_passage meer een een no go voor auto is.
En hoe live-op er mee om gaat.
Je moet OSM niet zo uitvoeren zodat live-op beter werkt vanwege programma keuze intrepetatie pedestrian t.o.v. footway
Nu is de keuze voor highway=footway niet verkeerd, pedestrian gebruiken we vooral voor bord "zone G7" (voetpad). Dan ook de stukjes links en recht tunnel uit op footway zetten.

De discussie "openbaar" volgens de Wegenwet, doet de gemeente het onderhoud, hoe lang is het publiekelijk toegankelijk, etc.
Het is lastig.
Binnen OSM tekenen we alle wegen/paden in, waar nodig als er een verbod is, bord of een afgesloten hek etc.

Hetzelfde ( changeset/120158229) geldt hier, pedestrain in footway verandering.
Nu was daar pedestrian al verkeerd, zo ook footway er staan geen G7 of zone G7 borden, en dus mag daar een fiets brommer snorfiets, zelfs motor en paard langs dus kan je geen highway=footway van maken.
En dan wordt dat stuk tussen de winkels highway=path. Er staat daar wel een paaltje barrier=bollard, waarbij men er van uit gaat dat bicycle en foot er langs kan (default) de andere vervoervormen moet je op *=yes zetten voor de routering als deze er fysiek langs kunnen.

Ik heb het aangepast.
https://overpass-api.de/achavi/?changeset=121513000

Bollard op een path zal waarschijnlijk al genoeg aanleiding geven om niet te routeren.
Bollards kunnen jullie verwijderen om ergens te komen, of je er dan fysiek kan komen wordt niet aangegeven, wellicht helpt width en height.
Zo heb je dan twee vormen fysiek width om bollard heen of fysiek bij bollard weg, wat op de highway kan worden gezet.

Zo is er een key maxwidth:physical=*
Als dat niet helpt extra nieuwe tags zoals aangeven in andere bericht.

En de problematiek heeft ook een wheelchair kan ik er langs.
Extra tags om het fysieke aan te geven.
barrier=cycle_barrier#Passability_for_cargo_bikes,_trailers,_wheelchairs_etc.

Goedendag, u veranderd de highway van pedestrain naar footway.
In OSM algemeen betekend beide, dat je er niet met de auto/car vrachtwagen/hgv langs mag, access.

"kan" is een andere insteek, fysiek, die wordt in principe aangeven door de"width", of het vehicle er langs kan of nog door de hoogte "height", hier tunnelpassage, maar kan ook overhangende reclameborden zijn.

Wij begrijpen u insteek van uit veiligheidsregio emergency standpunt, u zoek een mogelijkeheid om bij routering om aan te geven of het veiligheidsvoertuig er langs kan.

De redenatie bij een pedestrian kan dat wel bij footway kan dat niet is niet correct. Gaat niet in alle gevallen op.
En doet vaak/soms ook geen recht aan hoe een mapper de locatie bekijkt t.o.v. pedestrian of footway gebruik.

Dit is een specifiek gebruik emergency,
als width en height niet voldoet bij routering.

Dan zou men ook
emergency=no kunnen gebruiken, dat dekt de lading weer niet, in geval van een calamiteit, zou men met een motor fiets te voet er wel langs kunnen.
Het systeem van OSM is niet zo doorontwikkeld dat men rekening houd met de verschillende emergency voertuigen, men zou dan kunnen denken aan emergency:car=no emergency:hgv=no. Tags die helemaal nog niet worden gebruikt. Mits zulke tags worden opgenomen in de live-op applicatie.

C12
motor_vehicle=no & moped=yes & mofa=yes & traffic_sign=NL:C12

nu is het afgesloten voor bromfietsen en snorfietsen

https://smoothefiets.ddns.net/html/verkeersbordenkaart/index.php?lat=53.178899349&lng=5.808160007&z=19

Het zou daar gepast zijn dat de gemeente onderborden met afstand plaatst. Anders moet je gehele weg op slot zetten voor C12 en zijn gebouwen niet bereikbaar.

Ik gebruik geen streetcomplete, maar wat is de exacte vraag die je krijgt?

Ook de omschrijving die Streetcomplete geeft voor de width, interpetatie.

Dan heb je nog dat AR gebeuren, dat je op basis van de foto het programma laat bepalen hoe breed de rijbaan is.

Dat meten heb je op basis van deze methode gedaan? Gezien source ARCore tag.

Dat is bepalend om tot goede vraagstelling te komen.
Waar ligt de problematiek.
-vraagstelling
-advies interpretatie
-meting AR

Ik keek nog even bij width
https://github.com/streetcomplete/StreetComplete/issues?q=width
Of daar al opmerkingen over zijn gemaakt.

Dan heb je nog het feit dat de mapper zelf moet controleren of wat men voor stelt correct is.

Lastig, wat is de rijbaan, wat is "de weg".
width moet iets zeggen over het effectief gebruik in mij optiek.
https://en.wikipedia.org/wiki/Carriageway
verge, de berm wordt gerekend tot de carriageway, wat wij benoemen als "de weg"
https://wetten.overheid.nl/BWBR0001948/2021-07-01
De rechthebbende op en de onderhoudplichtige van een tot den weg behoorenden berm hebben alle verkeer over den berm te dulden, voor zoover het door omstandigheden wordt gebillijkt.

Er wordt "usualy" geschreven, het is een leidraad. Dan ga je een Nederlandse discussie aan, rijbaan, lane op de rijbaan parkeren of apart aangegeven parkeervakken. Zone P, parkeren alleen in de parkeervakken, blauwe lijn P symbool (tegel) in Urk. De Gemeente tekenend het apart in.

Streetcomplete gaat van een basisvergelijking uit, twee wall lijnen achter elkaar (vanwege area), en ook niet rekening houdend met de trap er voor of en achter, deze controle hebben ze dan niet verwerkt in hun mechanisme.

rechterkant parkeervakken

Hoi hier ook waarschijnlijk een streetcomplete melding.

way/6546193

width 6.5
source ARCore

Maar in werkelijkheid zijn er aan de rechter kan parkerrvakken
http://mijndev.openstreetmap.nl/~allroads/NLOSMOK/OSMOKNL.html#map=21.26/52.6607/5.5931/0

Dan meet ik in JOSM 4,43 meter.

BGT Omtrekgericht laag.

Netjes, waarschijnlijk gaf streetcomplete daar een melding zonder rekening te houden met de trappen en omdat de wall als area was ingetekend, het je twee stiles vlak naast elkaar getekend.

Als de trappen al ingetekend zijn hoort daar nog niet eens twee stiles te worden getagged.

Hoi, ik heb deze landuse residential een revert gegeven omdat hij op vele plaatsen aan de highway lijn vast zat, wat we niet doen.
Tevens de begrenzing is onduidelijk, o.a. Flevoweg hoort niet onder het beoogde gebied.
Er ligt al een landuse residential.
Vermoedelijk was de opzet om de naam 't Stadscentrum op de kaart te krijgen. Dat kan je ook als node met place neer zetten. Dat doen we vaker bij buurten, ergens midden in het gebied, omdat grenzen vaak discutabel zijn.
name='t Stadscentrum
place=quarter
Al betwijfel ik of dit de juiste naam is met 't .
Vandaar dat ik het niet heb toegevoegd.
CBS buurten beschouwd heel Vollenhove als een buurt.
https://nl.wikipedia.org/wiki/Wijken_en_buurten_in_Steenwijkerland
Een statische grens en soms ook een statische naam om iets te duiden.
Zo wijken statische grenzen wel eens af van gemeentelijk grenzen.
Vandaar de keuze van een node om een buurt te duiden.

t.o.v pagina 6 kaartje is de BGT zie eerste link, de gegevens wel goed, zie de nieuwe parkeerplaats die al ingetekend is.
De weg er naar toe, vanaf de Voosterweg, naar parkeerplaats hebben op pagina 6 en BGT geen naam. Even verder staat Scheve weg, vroeger liep het daar door nu is er de parkeerplaats gekomen. Vandaar de bocht.
Dat building adressen Voorsterweg hebben, houd niet gelijk in dat de toegangsweg ook zo heet.
De gemeente bepaald, de straatnamen.
Maar dit is eigen terrein, waar het waterlab wegnamen aan gaf.
Scheveweg pag 6 lijkt helemaal door te lopen tot aan de openbare weg Voorsterweg of stopt op de hoek 9bocht) waar het een stuk Deltaweg is.
Hier een oude bevestiging:
https://www.google.com/maps/@52.6757797,5.9221249,3a,75y,232.02h,83.79t/data=!3m6!1e1!3m4!1szXauCoR9acWTfF9NMmhIDg!2e0!7i13312!8i6656
Ahh, dat stuk heet dus Deltaweg.
https://www.google.com/maps/@52.676359,5.9228664,3a,75y,275.02h,77.56t/data=!3m6!1e1!3m4!1sziEFpkO1LJl2Gd8eZeiPlA!2e0!7i13312!8i6656
Zo was het dus, zal nog wel zo zijn.

Dat wilde ik ook net aangeven, ik heb bewust deze paden op "path" gezet, omdat er niet per bord G7 aangegeven is dat het een "footway" is en er access tags op gezet worden op basis van een directe vertaling van de art. 461 gebiedstoegangbordjes.