Hoe tag je een een weg met een verplichte rijrichting maar een uitzondering daarvoor voor fietsers en een fietsstrook aan beide kanten?
Zoals ik al aangaf, met oneway:bicycle=no + cycleway=lane
1 Like
Ah, ik zie het probleem. Dat zou dus moeten worden oneway:bicycle=no + cycleway:left=lane + cycleway:right=lane
Precies, en voor entiteiten met *:right=X met *:left=X met dezelfde waarde X is *:both=X een afkorting. Vandaar cycleway:both=lane.
Dit is een conventie die ook wordt toegepast bij sidewalk:left|right|both en parking:left|right|both en afgeleide tags daarvan (conditionals, orientation, en zo).
1 Like
Nee, voor entiteiten met *:right=X en *"left=X hebben we *=X. Helemaal geen both nodig.
Straks gaan we ook no access:all taggen. Want ja, access alleen is verwarrend.
Wat er misgegaan is, is dat oneway=yes invloed heeft op de betekenis van cycleway=lane. Dat is jammer, maar niet veel aan te doen.
Dan moet je niet overal both gaan taggen. Het voorbeeld waar deze discussie mee begon had helemaal geen oneway=yes.
Dus gewoon left en right taggen als er een oneway geldt met uitzondering voor fietsers. Dan kunnen we in alle normale gevallen gewoon cycleway=lane gebruiken.
cycleway:both is meer dan een miljoen keer gebruikt; tienduizenden keren in Nederland. Als je van mening bent dat deze niets toevoegt boven cycleway, dan heeft het weinig zin om daar hier een discussie over te voeren alsof de tag compleet nieuw is. Dan is het nuttiger om in de bredere OSM-gemeenschap te vragen waarom deze tag bestaat (tip: begin bij de discussiepagina). Maar de tag heeft volgens veel mappers wel degelijk bestaansrecht, en is zelfs populairder dan cycleway. Een data-consumer zal er dus rekening mee moeten houden.
Zo complex is dat trouwens niet. In de JOSM Map Paint Style voor voetgangers houd ik ook rekening met sidewalk, sidewalk:both, sidewalk:left, en sidewalk:right. Specifiekere waarden overschrijven generiekere.
Dat maakt niet uit, want cycleway:both=X heeft een duidelijke definitie: beide kanten van de weg zijn X. Dat is gewoon valide. Je hoeft het zelf natuurlijk niet te doen met die tag, en vaak wordt cycleway=X doorgaans als equivalent genomen, maar de acceptatiegraad van de tag is zo hoog (en de definitie helder) dat je moeilijk kan zeggen dat andere mappers er fout mee zitten.
Draai het eens om: met cycleway:right|left|both zijn er geen ambigue gevallen zoals met oneway=yes, dus als je die overal toepast loop je er ook nooit tegenaan. Minder nadenken, dus makkelijker taggen. 
Ik vond en vind die hele cycleway tagging buitengewoon verwarrend, en een van de verwarrende dingen is dat ik bij cycleway=* verwachtte om soorten cycleway als values te zien. Volgens het ook vrij veel toegepaste beginsel van hierarchisch indelen door de value van de main key als key voor de onderverdeling te gebruiken, en dat desgewenst te herhalen voor een volgend detailniveau.
Dus highway=cycleway + cycleway=soort_cycleway
Dus ik moet er nog steeds iedere keer weer wennen aan dat cycleway=* een subtag op een niet-cycleway is, waar een cycleway naast kan lopen. Maar ook wel eens niet, en dan staat er nog steeds cycleway=*.
En dan al die oude en nieuwe tags door elkaar, allemaal uit verschilende schema’s die ook nog allemaal gebruikt worden, omdat de aanhangers verschillende fietsinfrastrukturen voor ogen hebben… edit tools, presets en wiki’s die er verschillende meningen op na houden omdat de bestaande schema’s elkaar tegenspreken en ze er dus maar eentje kiezen…
En weer door.
Waarvan >90% met de waarde “no” wat dus helemaal niets toevoegt. 3x raden waar dat vandaan komt.
Juist: StreetComplete:quest_type AddLanes
https://taginfo.openstreetmap.org/keys/cycleway%3Aboth#values
3 Likes
Ja, dat is inderdaad verwarrend bij deze key.
Het is een survey-tag die expliciet zegt „geen fietsstroken”. Als iemand nu in een gebied alle wegen met fietsstroken in kaart wil brengen, dan kan die alle wegen waar een van de vier cycleway-tags op staat dus negeren; bijvoorbeeld met een Overpass-query die alle wegen met zo’n tag (ongeacht de waarde) die minder dan drie jaar geleden nog zijn aangepast in eerste instantie negeert.
Bij een weg zonder cycleway*-tags weet je niet of er fietsstroken zijn of niet. Dat is het verschil.
StreetComplete vind het leuk om de OSM database te gebruiken/misbruiken om te weten of een challange gedaan is of niet. Daarom voegen ze onnodige tags toe.
Je zou je af kunnen vragen hoe ethisch dat is.
1 Like
Gaan we echt voor iedere tag die er bestaat overal waar die tag niet van toepassing is er =no zetten?
Dus iedere weg waar geen verlichting is? Iedere weg waar geen trotoir is. Iedere node in een weg die geen bollard of zebra pad is. Iedere weg die geen eenrichtingverkeer is?
Wat een vervuiling.
Het is een enorme vervuiling, helemaal mee eens.
Zo snel mogelijk verwijderen die troep.
Ik kom ze tegen op wegen, die never, nooit fietsstroken zullen krijgen.
En verder waar eindigt dit?
Welke wegen krijgen geen cycleway:both=no en welke wel?
Of krijgen in de visie van StreetComplete alle wegen die tag?
1 Like
Op zich snap ik de behoefte om af te vlaggen wat er al bekeken is wel. Ik heb me er zelf ook wel aanbezondigd, in de note tag bv, maar dan voor projektjes die ik ook zelf wil afhandelen. Maar niet in een specifieke tag, door een algemene tool die voor iedereen bedoeld is. In het algemeen is in OSM niet ingevuld=niet het geval|niet bekeken, en de data user / renderer / checker moet met die onzekerheid leren leven, vind ik.
Het zou wel fijn zijn als OSM een ingebouwde methode hiervoor had. Hoe dat zou moeteen werken weet ik niet, want het zou voor alle tags moeten werken dat je kan aangeven dat je die tag bewust niet hebt gezet. Een Aan/Uit/Grijs-tagstatus met datum en user. Aan is: bewust een waarde gegeven, Uit is bewust géén waarde gegeven, Grijs is: niet bekeken / weet ik niet.
En dat dan onder de motorkap, bijvoorbeeld via verborgen tags. Statustag ontbreekt is dan Grijs, Statustag=datumtijdstempel is user heeft tag op dag/tijd bewust gezet, Statustag=-datumtijdstempel, user heeft op die dag/tijd tag overwogen maar niet gezet.
datumtijdstempel van zetten zie ik in de geschiedenis staan, dus die is er in enige vorm al; ontbrekende statustag hoef je niks voor te doen; toe te voegen: statustag met negatief datumtijdstempel. Of een andere clevere methode die voor iedereen desgewenst uit te lezen en te bekijken valt.
Dan staat het dus wél in de database, en voor mijn gevoel klopt dat wel want het is een met echte survey en met de bekeken objecten verbonden gegeven, je wil het alleen niet altijd moeten zien.
(Ik brainstorm even vrij, dat mag ik want -voor wie wel eens zo’n modieuze management drives sesie heeft gedaan- ik ben kanariegeel).
Vraag het ze. Waarschijnlijk alles vanaf highway=tertiary, wat op zich logisch is.
lit=nowordt al toegepast, sommige mensen vinden dat interessant vanuit het oogpunt van veiligheid 's avonds (met name binnen de bebouwde kom).- Ja, want wegen hoger in de hiërarchie (
secondary, etc.) met voetgangerstoegang maar zonder stoepen kan een router voor voetgangers bij voorkeur vermijden. Het komt door ons fietspadennetwerk niet veel voor in Nederland vanwegefoot=use_sidepath. - Nee, dat is onzin.
- Nee, dat is ook onzin (behalve waar de situatie onduidelijk is en
oneway=noer staat om te voorkomen dat een mapper zonder inzicht in de situatie daaroneway=yesvan maakt).
Wat je aangeeft is dat in een bepaalde context zo’n tag zin kan hebben. Omdat bijna alle wegen binnen de bebouwde kom verlichting hebben, kan het zin hebben om taggen als het niet zo is.
Maar als je alle wegen buiten de bebouwde kom met lit=no zou gaan taggen wordt het vervuiling.
Ik snap je andere voorbeeld nog niets wat voor zin het heeft om een weg zonder stoep te taggen. Gaat een router dan bij wegen die niet getagd zijn voetgangers daar overheen routeren? Er staat geen tag dus het zal wel veilig zijn. In dat geval zou voor de router de default moeten zijn dat zonder een tag het gevaarlijk is. En dan heeft die tag dus weer geen zin.
Het eerste geval is een van de uitzonderingen waar het omgekeerd is, binnen de bebouwde kom is vrijwel iedere straat verlicht. Dus als er geen tag is dan zal wel verlichting zijn. Moet een router wel precies weten waar de bebouwde kom ophoudt. Dus grote kans dat een router alles zonder tag toch als geen verlichting beschouwt en dan is die lit=no ook weer onzin.
Maar om terug te komen op die cycleway:both (of er nu yes of no staat): gewoon vervuiling.
Naar aanleiding van andere discussies lijkt het mij verstandig om te bespreken hoe we de toegang voor elektrische snor fietsen op G13 fietspaden willen taggen. Er worden verschillende tags genoemd voornamelijk electric_mofa en mofa:electric. Maar zelf zie ik een elektrische snorfiets niet als een ander type voertuig dan een snorfiets met een verbrandingsmotor. Het zijn beiden snorfietsen.
Zou een conditionele toegangs tag beter passen?
Iets zoals mofa:conditional=yes@electric
https://wiki.openstreetmap.org/wiki/Conditional_restrictions
Daar loopt al een proposal over: Proposal:ElectricScooters - OpenStreetMap Wiki
En bijgaande discussie: Feature Proposal - RFC - "scooter" type (electric) vehicles
Ik heb me laten vertellen dat conditionele access maar heel beperkt wordt ondersteund door toepassingen, terwijl voertuigtype-afhankelijke access algemeen zeer breed ondersteund wordt.
Zou iemand ook de pagina op https://wiki.openstreetmap.org/wiki/NL:Tagging_van_Nederlandse_wegen willen aanpassen op de nieuwste inzichten qua electrische snorfietsen bij onverplicht fietspad?