Bedankt in elk geval voor de moeite om dit (opnieuw) aan te kaarten. Zal er voortaan ook beter op proberen te letten (wordt een vraag over een weg die ik al beantwoord heb opnieuw gevraagd dan eerst thuis even controleren)
Als wij een cycleway zien, segregated, getagd met surface=asphalt, maar het voetgedeelte blijkt fine_gravel te zijn, taggen we dan:
a. surface=asphalt + footway:surface=fine_gravel, of
b. bicycle:surface=asphalt + footway:surface=fine_gravel?
Indien het tweede: dan kun je detectie zetten op segregated=yes + surface=* + surface:=. Afhandeling lijkt me handmatig dus een MapRoulette missie ihkv de PvdM zou wel kunnen, denk ik.
Als ze verschillend zijn tag je cycleway:surface=asphalt en footway:surface=fine_gravel (en geen surface).
Tenzij het voetgangersdeel als sidewalk=right of zo getagd is, dan is het surface=asphalt en sidewalk:right:surface=paving_stones (bijvoorbeeld).
Het probleem met StreetComplete is dat ze een gedeeld pad met scheiding waar surface=asphalt op staat nu behandelen als een pad waarop geen surface-informatie staat. Dat is best wel arrogant, want het is immers prima om zo’n pad te taggen met alleen surface=asphalt als de hele breedte van de weg dat heeft.
Nu laten ze StreetComplete-gebruikers dubbel werk doen, en negeren ze ingevulde informatie, alleen omdat ze zeker willen weten dat er zowel naar de voetgangers- als fietserskant van het pad is gekeken, en dat het werk van andere mappers die gewoon surface toepassen niet betrouwbaar is.
Erg jammer. StreetComplete toont zich hier niet een als een betrouwbaar instrument.
@Tjuro Liep nog tegen een ander probleem aan, en dat is dat StreetComplete bij een combinatie van segregated=yes en sidewalk=right ook gaat schreeuwen dat cycleway:surface en footway:surface nodig zijn. Alleen maar omdat segregated=yes er dubbelop bij staat (want een losse sidewalk impliceert immers als segregated=yes). Ik vermoed dat als je segregated=yes weghaalt dat voorbeeld in Deventer niet meer aangeboden wordt, maar dat zou niet nodig moeten zijn.
Zo staat het wel in de surface-wiki.
Als er geen surface instaat is het wel terecht dat SC erom vraagt. De tagging in onderdelen is dan niet fout; je geeft zelf aan dat dat jouw voorkeur heeft.
Al zou je ook kunnen zeggen, als het object een cycleway is dan slaat surface=* op het cycleway-object, en footway:surface op de voetstrook die meelift op het object.
Dit klopt in principe wel. StreetComplete zoekt de randen op van een mechanische edit door onervaren gebruikers, die geen verstand van taggingsrichtlijnen hebben, de tagging aan te passen. Doordat ze geen lokale OSM-gemeenschap overtreden ze hierbij de regels rond mechanisch mappen.
In het geval dat we dit zien als een mechanische edit, lijkt het mij terecht om massaal StreetComplete-edits die tegen de Nederlandse afspraken ingaan, terug te draaien. Misschien is dit ook wel iets voor de DWG.
1 Like
Er staat dus wel een surface, en StreetComplete vraagt alsnog omdat hun aanname volgens de GitHub-issue is dat surface wijst op ontbrekende informatie. Dat hebben @Tjuro en @erik1984 nagekeken bij deze way.
Nee, bij een gedeeld voet-/fietspad, die bij ons getalsmatig zwaar in de minderheid zijn, zijn de twee gelijk aan elkaar. Dus:
- óf je tagt
surface=*voor het hele pad, - óf
cycleway:surfaceenfootway:surfacevoor de twee kanten, - óf je hebt een normaal fietspad met een stoep ernaast, en tagt
surface=*ensidewalk:right:surface(mag ookleftofboth).
Je kan wel surface=A doen en footway:surface=B, dan override je bij de voetkant de surface, maar het staat wat raar en wekt de indruk van een taggingfout. Omgekeerd werkt surface=B met cycleway:surface=A ook.
Wellicht ten overvloede maar of er ook om de ondergrond van het voetpad wordt gevraagd of alleen van het fietspad hangt af van foot=yes blijkbaar. In mijn voorbeeld heb ik alleen vraag gekregen over het fietsgedeelte, om footway:surface is niet gevraagd. foot=yes wordt lang niet altijd toegepast op fietspaden in NL (omdat het impliciet al zo is?).
Dan is het eigenlijk nog ongelukkiger want dan wordt alleen cycleway:surface gespecificeerd maar alsnog niet expliciet vastgelegd hoe het zit met het voetgangersgedeelte, wat volgens mij wel het doel is van SC met die specifieke tagging op ‘gedeelde’ fietspaden.
Deze SC-vraag past gewoon heel slecht bij de Nederlandse situatie ja. De beste manier om dit te nu te voorkomen is denk ik om lokaal te kijken waar segregated=yes ten onrechte staat aangegeven (en daar sidewalk aan te geven indien van toepassing).
1 Like
Dat is dan geen cycleway toch?
Zou het kunnen dat dit inmiddels is opgelost in SC? Ben even op zoek gegaan met Overpass naar plaatselijke fietspaden met segregated=yes zonder sidewalk en heb er een paar aangepakt in deze changeset: Changeset: 156352518 | OpenStreetMap . Juist vanwege jouw opmerking heb ik segregated niet verwijderd en SC vraagt nu bij deze wegen (gelukkig) niet meer om wegdek van het fietspad (ook niet voor voetpad).
Overigens is er nog 1 weggetje hier die ik qua sidewalk wat lastiger vind:
Hoe moet bij dit stukje eenrichtingsfietspad sidewalk worden aangegeven?
Dat rode stukje, daar zou ik geen sidewalk tag op zetten. Er is zowizo geen loper die daar dat stukje zou nemen, want het is 5 stappen meer!
1 Like
Ja dat lijkt mij ook, maar zou segregated er dan vanaf kunnen? Want nu vraagt SC voor dat ene stukje nog wel om wegdek van het fietspad.
1 Like
segregated=no voor dat stukje.
segregated an sich wel laten staan, anders begint de validator van JOSM weer te zeuren als iemand foot=yes op dat stukje zet.
Overigens zou ik geen foot=yes op dat stukje zetten, de looplijn is duidelijk aan de bovenzijde.
Als het verder een G12a is met iets wat toch echt geen stoep valt te noemen als een soort lane erop, tja, eigenlijk wel.
Aparte oplossing hebben ze daar gekozen om het tegelpaadje naar het fietspad aan de overkant te leiden.
Voor segregated=yes moet je toch een fysieke scheiding hebben? Een wandelsuggestiestrook blijft denk ik segregated=no.
footway=lane?
Op het moment dat er fysieke scheiding tussen een voetpad en fietspad is dan is er helemaal geen sprake van segregated=*. Dat map je door highway=footway+footway=sidewalk voor het voetpad, en highway=cycleway+sidewalk=seperate voor het fietspad.
1 Like
Ja, het is een opvallende oplossing. Ik heb ook nog niet helemaal begrepen waarom dit zo gedaan is. Makkelijker dan een echte stoep? Natuurlijk mag je ook doorlopen over het (normale) fietspad als voetganger richting het kruispunt, maar dat zal qua hoeveelheid minder zijn.
Nee, segregated=yes vereist alleen dat de voetgangers en fietsers aparte stroken hebben.
-pets- o ja! Ik maak er toch nog steeds fouten in.
Bij fietsen had je toch ook nog cycleway=track op een weg, om een apart maar niet ingetekend fietspad aan te geven? Zou dan bij een highway=cycleway dan footway=track niet logisch zijn, om een apart maar niet ingetekend voetpad aan te geven?
Dan is het nog steeds een aangewezen fietspad met een suggestieve voetstrook voor de voetgangers die er zowizo mogen lopen, toch? Anders moeten ze er ook nog een voetpadbord of zo’n samenspelensamendelen bord neerzetten. Maar het gaat er wel naartoe, als dit gewoonte wordt.
Ik heb in R’dam ook een echt gedeeld pad gezien, segregated met een onononderbroken streep ertussen, en het fietsdeel tweerichtings, met logo’s op de paden getekend. Alleen, dat is een creatieve tijdelijke oplossing, zodra de werkzaamheden afzijn maken ze vast weer een mooi verplicht brom/fietspad met stoep.
Dat is hier ook het geval: om de zoveel meter icoontjes van fietsen (in de rijrichting van de strook) en een voetganger. Ik heb er alleen geen foto van. Op de PDOK 8cm-beelden valt het wel net te zien als je weet waar je naar kijkt. 
In ieder geval. ik gebruik StreetComplete niet meer omdat ik te vaak onnodige vragen en telkens dezelfde vragen krijg, en het resultaat IMO te vaak niet goed of niet volledig is. Dan moet ik dus toch alles nakijken, en dan kan ik het beter in één keer goed in JOSM doen.