Eerder schreef iemand op dit forum: “Tilburg heeft zo te zien wel meer problemen. Ik zie veel grote wegen met naastliggende (brom)fietspaden waar met name foot=use_sidepath en mofa=use_sidepath steeds ontbreken.”
Nu ben ik me daar eens in gaan verdiepen, maar het is me niet altijd duidelijk wanneer use_sidepath moet worden gebruikt. Op dit forum is het er al meerdere keren over gegaan (o.a. hier), maar deze discussies zijn inmiddels wel wat ouder.
En dan zijn er ook nog tags om aan te geven dat er wel of niet een trottoir is, maar deze tref ik maar zelden aan.
Alvast een paar concrete situaties, waarvan ik graag hoor hoe deze verbeterd kunnen worden:
De Tilburgseweg is een tertiaire weg (alleen voor motorvoertuigen), met daarnaast een vrijliggend fietspad voor beide richtingen (voor fietsers, maar ook voor voetgangers). Wat zou hier correct zijn: sidewalk=no, cycleway=use_sidepath, foot=use_sidepath?
De Gildestraat is een residentiële weg waarvan (bij een deel) de trottoirs gescheiden zijn van de weg door parkeerplaatsen en groenvoorziening. Moeten deze apart worden ingetekend, moet er iets bij van sidewalk=both of is dat overbodig?
De Broekhovenseweg heeft een apart fietspad (dus ik begrijp bicycle=use_sidepath), maar er is geen apart voetpad ingetekend (foot=use_sidepath verwijst dan dus naar het fietspad als ik het goed begrijp, waar dan weer een sidewalk=right aan toe is gevoegd.
Het fietspad naast de Tilburgseweg heeft NL:G12a borden wat betekend een G12a Fiets/bromfietspad. Bij de kruispunten van de Tilburgseweg staan geen NL:C15/NL:C9 borden dus het is niet expliciet verboden voor fietsen dus geen foot/bicycle/mofa/moped=no. Het fietspad is wel verplicht en daarmee voor de weg foot/bicycle/mofa/moped=use_sidepath. Bij foot=use_sidepath is sidewalk=no overbodig.
De Gildestraat heeft zover ik kan zien maar een stoep aan één kant, sidewalk=left. Als je stoep apart intekent dan kan de straat foot=use_sidepath krijgen maar met maar aan één kant een stoep zou ik dat niet doen. Let ook op dat de stoep goed verbonden is met de rest van OpenStreetMap
De Broekhovenseweg heeft NL:G11 fietsen en ook geen C15/C9 borden dus foot/bicycle/mofa=use_sidepath.
Goede, uitgebreide informatie is te vinden op NL:Cycleway
Mits trottoir, fietspad, goed aansluitend is ingetekend en voor de vervoersvormen op de rijbaan geen C verkeersborden staan. Dan kan je use_sidepath gebruiken.
Per type fietspad (preset JOSM). Er zijn soms stukken, waarbij je forward backward moet gebruiken wegens verspringing in de aansluitingen. Je neemt dan ook gelijk mofa en moped mee.
Niks ingetekend ( trottoir fietspad) dan kan je op de rijbaan waylijn sidewalk=* zetten.
Is het wel ingetekend, dan geef je aan welke kant het is ingetekend, sidewalk=separate of met right of left
Toen ik een wijk aan het aanvullen, verbeteren was, heb ik veel gehad aan deze visualisatie om inzicht te krijgen of het klopt bij sidewalk en foot. Ik gebruikte de Qgis methode.
Zo zie je hoeveel footway=sidewalk (zwart) er is ingetekend in Tilburg.
Reeshof meer dan elders.
Met sidewalk op de rijbaan. Bij zwart (footway=sidewalk) er naast mag je geen paars en rood zien, bij beide kanten een trottoir ingetekend. En hoor je groen (separate ingetekend) te zien, aan de kant van de zwarte footway.
Om je ergens in te verdiepen moet je eerst een goed overzicht krijgen en ik een sterk vermoeden dat iD niet laat zien wat ik en anderen in Josm en de Road Extended paint style zien.
Road Extended laat zien met pictogrammen het verschil tussen bicycle=no en bicyle=use_sidepath of een pad/weg een sidepath heeft en aan welke kant en veel, veel meer.
Het is maar net vanuit welk model je het beredeneerd, je aanhangt.
Een render, visualisator, kan een sidewalk model hebben voor sidewalk op de rijbaan visualisatie
Aan de use_sidepath kan je bij foot niet zien of dat is op basis van een sidewalk of een naastliggend fietspad. Je ziet aan use_sidepath ook niet van welke kant deze restrictie komt.
Er is niet voor niets sidewalk=separate dat is juist om een bepaalde visualisatie, dat te geven, dat hij aan die kant niets uitbeeld. Apart de ingetekende highway sidewalk uitbeeld.
Dus het heeft nut.
Hoe nuttig is een andere discussie.
Het bekijken vanuit een topografisch perpectief, uitbeelden, of het bekijken vanuit een routegrafisch perspectief, routering.
use_sidepath is vanuit een routering oogpunt.
Daarom heb ik mij al eens afgevraagd of sidewalk op de rijbaan of fietspad kaartdekkend moet worden ingevuld. Een model werkt als er genoeg data is van een bepaalde kwaliteit.
Kaartdekkend, ik denk van wel, wil het goed werkend zijn en dan vooral in urban omgeving.
En zo bij gescheiden rijstroken en aan een kant een fietspad, aan beide zijde een trottoir.
Bij rijbaan en fietspad groen (offset) is separate, rood (no)
Gisteravond bovenstaand .qgz visualisatie uitgebreid met use_sidepath voor andere vervoersvormen en vergelijking met fietspaden. OSM_use_sidepath_wfs_NL.qgz
Zo kan je cycleway G12a vergelijken met moped. G11 met mofa en bicycle.
Zet je moped access aan, dan zie je veel *=no daaronder ligt vaak een G11 cycleway, m.a.w. zet je alleen G11 en moped access, dan hoor je geen blauwe lijntjes te zien, en zo kan je spelen met vergelijkingen. Er hoort op een G11 moped=no te staan.
Missende use_sidepath voor moped en mofa, deel G11 wat een G12a moet zijn.
Ik heb nog geen kaart o.i.d. gezien die moeite heeft om een goed plaatje neer te zetten omdat sidewalk=no op een weg mist. Er is een kleine mogelijkheid dat fout zit, een concreet voorbeeld liefst met code is welkom.
Je kan duidelijk zien waarom het overbodig is. foot=use_sidepath in combinatie met sidewalk=left/right/both is fout, de enige mogelijkheid is dus dat betekend dat de weg geen sidewalk heeft en als het de enige mogelijkheid dan is het impliciet default en hoeft het dus ook niet getagd te worden.
Zolang niemand mij kan uitleggen waarom secondary=separate geen goed idee is vindt ik separate geen goed idee.
Niet geheel onverwacht komt separate voor op die plaatsen waar helemaal geen tagging daarvoor nodig is. Dat komt omdat het iets zegt een ander object en niet over het object zelf.
Bedankt voor alle reacties. Ik ga me er binnenkort eens in verdiepen. Altijd lastig dat het niet altijd eenduidig is en het ook bij de ervaren mappers discussie oplevert. Maar de grote lijn is me wel duidelijk.
Voordat bepaalde zaken op voorhand als overbodig worden gekwalificeerd is het goed om een aantal dingen in het achterhoofd te houden
Onze database kent meer toepassingen dan alleen routeren en het renderen van kaarten, ook data-analyse is een valide toepassing waarvoor je kan taggen
Specifiek voor trottoirs is er momenteel maatschappelijke discussie over risico’s rond en maatregelen bij wegen met een maximumsnelheid hoger dan x zonder trottoir
ook vragen als heeft de voetganger een eigen voorziening, of loopt deze tussen de (brom-fietsen) en is er een voetgangersvoorziening aan beide zijden van de rijbaan, of alleen aan een kant / hoe vaak moet je oversteken zijn relevant
complicerende factor bij een goede inventarisatie is dat [bij toepassing op highway=*] het begrip “way” in OSM beperkter is dan “weg” in het RVV : een weg in het RVV kan uit meerdere parallele ways in OSM bestaan
we hebben in OSM geen breed gebruikte manier om die verschillende ways die samen een weg vormen te bundelen in een relatie, dat gebeurt dan meer met tags op het ene element die iets zeggen over (de aanwezigheid van) een ander element
daarbij heb je als dataverwerker ook nog onzekerheid over de vraag
(a) hoe het gemodeleerd is in OSM: met de way voor de rijbaan die ook de andere wegdelen (zoals fietspad, trottoir) representeert, of met elk wegdeel een eigen way
(b) en of bij afwezigheid van een tag is geconstateerd dat een bepaald element niet aanwezig is, of alleen niet beoordeeld is
Kortom: soms kunnen dingen net iets minder vanzelfsprekend / overbodig zijn dan ze misschien op het eerste gezicht lijken.
Tegelijk is het veel ruimer, want elke lijn is een way, en die kan een weg voorstellen, of een deel van een weg, of een ander lang object, en ook een vlak of een gebouw. Ik begrijp wat je bedoelt, helemaal mee eens, maar zoals het hier staat klopt die stelling niet!
Zo’n toepassing kan bepalen wat je wil mappen, het kan de mapper ook een voorkeur voor een bepaald alternatief geven, maar het is een dunne lijn naar taggen voor een bepaalde toepassing.
We taggen allemaal voor rendering, dwz renderbaarheid, maar niet een bepaalde renderer. Dun lijntje.
We taggen allemaal voor routing, dwz routeerbaarheid, maar niet een bepaalde router. Dun lijntje.
We kunnen taggen voor data-analyse, dwz analyseerbaarheid, maar niet voor een bepaalde analyse. Dun lijntje.
Het was een forumpost en geen proefschrift
Maar je hebt een punt, heb nu expliciet gemaakt “bij toepassing op highway=*” ,
voor zover dat uit de context al niet duidelijk was
We taggen allemaal voor rendering, dwz renderbaarheid, maar niet een bepaalde renderer. Dun lijntje.
Ook als je tagt met het oog op gebruik van een bepaalde renderer / router / data-analyse hoeft daar helemaal niets mis mee te zijn, zolang je maar correcte data op een correcte manier invoert.
Het is dan ook jammer dat het invoeren van slechte data om een gewenste uitkomst te krijgen de te algemene naam “Tagging for..” heeft gekregen, zorgt voor veel misverstanden.
Het “Lying to the..” dekt de lading veel beter, de kern zit echt in de “incorrect tags” / “otherwise skewing the data”
“Tagging for the renderer”, also known as “lying to the renderer”, is the bad practice of using incorrect tags (or otherwise skewing the data) for the map features, so that they show up in the mapper’s renderer of choice.
