Zie namelijk dat ik dat al eerder had gedaan, maar dat @Famlam dit weer heeft weggehaald in een latere changeset. Nu ben ik onlangs weer een keer voorbij hetzelfde stukje gelopen en kreeg toen weer een vraag over dat pad. Heb toen blind op asfalt getikt, al was ik wel een beetje verbaasd een vraag over dat pad te krijgen. Dat komt denk ik omdat StreetComplete dit blijft vragen door de segregated=yes icm ontbrekende cycleway:surface, klopt dat?
Dit probleem hebben we al een keer of 3 aangegeven bij street complete, maar een echte oplossing is er nog steeds niet.
Het probleem is dat paden zowel voor fietsers als voetgangers met segregated=yes een apart opervlak kunnen hebben voor het loop en het fiets gedeelte. Dit bestaat in Nederland vrijwel niet. Hier is bijna alles of een fietspad of een voetpad waarbij een fietspad de mogelijkheid heeft tot het hebben een stoep. Dit kan dan toegevoegd worden met sidewalk=left/right/both/no/seperate.
Bijna alle huidige situaties waarbij een highway=cycleway een segregated=yes is eigenlijk een highway=cycleway met een stoep.
Binnen street complete komt de oppervlak informatie vanuit twee plekken, de quest en het oppervlak overlay.
Binnen de quest is het nu zo dat als een cycleway een sidewalk heeft getagd dat er geen cycleway:surface word toegevoegd.
Maar binnen de surface overlay word dit genergeerd en kan de dus cycleway:surface toevoegen, ook als het fietspad een sidewalk getaged heeft.
Ik denk dat we binnen Nederland beter helemaal geen segregated=* meer moeten gebruiken. Voor ons zou de sidewalk tag beter de situatie beschrijven. Hiermee bedoel ik niet dat segregated= helemaal geen goede tag is, in Duitsland werkt het prima.
Ik heb zo gauw geen voorbeeld bij de hand, maar ik kom toch geregeld tegen dat ik denk: segregated is hier van toepassing, op een path, een cycleway met foot=yes (vooral op de niet-verplichte fietspaden) of een footway met bicycle=yes.
Er is zeker niet overal een stoep (dwz met een stoeprand ertussen).
sidewalk=yes impliceert segregated=yes, maar sidewalk=no impliceert geen segregated value.
Anders gezegd: Als foot en bicycle beide toegestaan zijn: bij sidewalk=yes hoef je geen segregated aan te geven, maar anders wel.
no is gewoonlijk de default segregated value voor data users denk ik?
Hier kun je de pictogrammen op de stroken niet zien, maar die zijn er ook. De zuidelijkste is dus voor voetgangers. Overigens alles wel met dezelfde surface.
Algemene renderers zullen zowizo weinig met segregated doen, denk ik. Fiets/wandel-gespecialiseerde renderers, zou kunnen, maar ik heb het nog niet gezien. Fietsrouters, misschien een penalty toepassen? Als ik erover na zou denken, zou ik voor foot=yes op cycleways en voor bicycle=yes op footways een nadeeltje toepassen, tenzij er segregated=yes geldt. En dat komt neer op segregated=no als default.
Dat is in mijn voorbeeld ook het geval (geen harde overgang, zelfde oppervlak), is het dan nog steeds nodig om de surface apart te taggen voor het fietspad? m.a.w. zal ik mijn wijziging weer terugdraaien? Dan is het wel wachten op de volgende SCer die weer de cycleway:surface gaat toevoegen.
Het kan afhankelijk van het interne model ook andersom: pas bij segregated=no een kleine boete toepassen voor voetgangers, of juist beide doen en alleen bij het ontbreken ervan niets.
Lijkt mij niet nodig. Het is wel explicieter, maar surface dekt gewoon de hele highway, ook bij segregated=yes tenzij anders aangegeven. Ik zou het als een bug opvatten als StreetComplete om cycleway:surface vraagt als surface al aanwezig is.
Vraagt StreetComplete echt bij een way met surface=* en segregated=yes alsnog naar het type bestrating?
Er zijn uitzonderingen. Maar hierbij heb ik ook het gevoel dat het beter zou zijn om de sidewalk tagging op te rekken naar de uitzonderingen, i.p.v. het gebruik van segregated bijvoorbeeld met sidewalk:<side>:kerb=no.
Het probleem is dat een sidewalk (stoep) iets anders is dan een gedeelde weg. Het onderscheid zit hem onder andere in de plaats van de OSM-way (middenlijn van het fietspad vs. middenlijn van de gehele gedeelde breedte) en in de ruimtelijke betekenis. Daarnaast blijft dit concept van een gedeelde weg met (zachte) scheiding sowieso bestaan in de rest van de wereld, dus heeft het weinig zin het niet te gebruiken voor Nederland.
Bedankt voor de screenshots. Is dit specifieke geval van vragen naar de *:surface als er al een surface-tag is al gemeld bij StreetComplete?
Nee, die ga je niet binnenhalen. Ik denk dat segregated cycleways wereldwijd niet zo mooi geregeld zijn als in Nederland, en dat alleen surface= vaak een verkeerd beeld geeft. Een ander formulering van de vragen zou misschien helpen. Bijvoorbeeld: “Als het fietsdeel en het loopdeel verschillende ondergrond hebben, wat is dan de ondergrond van het fietsdeel?” en “Als het fietsdeel en het loopdeel verschillende ondergrond hebben, wat is dan de ondergrond van het loopdeel?”
Of een voorafvraag bij segregated=yes: Hebben het fietsgedeelte en het loopgedeelte nog steeds dezelfde ondergrond?" Zo ja, doe niks. Zo nee, vraag de gedeeltes apart uit.
Kan deze hele quest niet uitgezet worden voor Nederland? Dat gebeurt ook met andere quests. Aangezien de StreetComplete-tagging niet overeenkomst met wat volgens de Nederlandse community wenselijk is, druist hun werkwijze in tegen het OSM-principe dat lokale kennis leidend is.
Ik heb het gezien, lijkt erop dat er niks gaat gebeuren aan de situatie.
Als je een editor bent en je kiest ervoor om mappen zo abstract te maken als SC doet, dan neem je zelf de verantwoordelijkheid over om ervoor te zorgen dat de tagging voldoet aan de lokale en globale standaarden.
SC lijkt een design filosofie te hebben om uit te gaan van de meest ingewikkelde situatie, op het moment dat deze minder ingewikkeld uitpakt heb je dus allemaal extra onzin tags. Het zou beter zijn als SC eerst uitgaat van een minder ingewikkelde situatie en dan doorvraagt voor meer info.
SC is een verkapte mechanische edit, de keuzes van een select groepje niet diverse mensen bepaald wat vervolgens in de rest van de wereld elke dag geforceerd word toegevoegd.
We zullen moeten kijken naar oplossingen niet uitgaan van medewerking van SC.
, maar ik heb het andere issue ook aangemaakt: