Bijfuncties van een weg

Ik zie hier wel wat in. Op de huidige manier is het ook voor renderers moeilijk om te zien welke wegen nou bij elkaar horen (naast elkaar liggen en tot dezelfde weg horen), en welke elkaar overlappen (de fietspaden die ‘onder’ de hoofdweg liggen). Voor een renderer is het veel makkelijker om de wegen op deze manier naast elkaar te leggen. En dit lijkt mij al helemaal handig voor voetpaden in woonwijken.

Zoals TaedeT zegt, denk ik dat het inderdaad handig is om ingewikkelde wegen op de huidige manier te mappen. Maar de meeste wegen zijn niet zo ingewikkeld en dan kan het dus wel.
Relaties lijken mij erg onhandig voor dit soort dingen.

Voordat we dit allemaal fanantiek op deze manier gaan mappen, denk ik dat het handiger is om eerst even te wachten totdat de renderers dit ook opgepikt hebben (ik bedoel, anders verdwijnen de fietspaden van de kaart!).

Maar misschien is het ook handig eerst ook goed naar relaties te kijken. Daarmee kun je denk ik ook mooie dingen doen, en is denk ik uiteindelijk veel uitbreidbaar dan het systeem van ZMWandelaar.

In het ZMW-systeem gaat het om de 80% van alle wegen waar meer functies samenvallen binnen een weg die in de volksmond onder 1 weg worden geschaard. En als uit veiligheidsoverwegingen het fietspad even een stukje van de hoofdbaan afwijkt omdat er toevallig die eeuwenoude Eik in de weg staat, of omdat het voor fietsers nu eenmaal veiliger is om een stukje van de kruising de zijstraat te passeren, wil nog niet zeggen dat je ook daadwerkelijk het fietspad die kronkels moet meegeven?
En ik denk dat de fietsbare routes in het ZMW-systeem helemaal niet verdwijnen. routering over een way(highway=cycleway) gaat volgens mij op gelijke wijze als over een way(highway=*,cycleway=track). Maar toegegeven ik mis wel het geile blauw gestippelde lijntje. :wink:

En verder gaat het er om dat in het huidige systeem geen ruimte is tot ordentelijk tekenen van de werkelijkheid. Neem nu dit voorbeeld. En zeg me niet dat dit de enige situatie is waarin het fietspad onder het wegdek van de auto’s verdwijnt. He is een gebruikelijk fenomeen. Ik erger mij er dood aan en bovendien kan het anders.

Het is misschien even wennen, maar het zegt gewoon hetzelfde als oneway=-1 op een normale highway. alleen in dit geval geldt he voor de cycleway-deel van de highway.

Wat ik overigens ook heel jammer vind is dat geen enkele kaartenmaker weet dat als je op die aparte fietspaden rijdt dat dat fietspad ook een naam heeft. Ooit wel eens het fietspad dezelfde naam gegeven als de hoofdweg? Lijkt me leuk zoeken voor een routeplanner. Komt de vraag boven: Wilt u Pietheinstraat(straat) of Pietheinstraat(fietspad) hebben?

Mijn idee is geïnspireerd op addr:* en dat is best duidelijk. Door dit systeem ontstaan er natuurlijk, zeker in complexe wegen, wel langere lijsten met tags, maar omdat ze gesorteerd worden, staan ze allemaal keurig bij elkaar en onder elkaar.

Als ik even kijk naar het plaatje van afbeelding 3 dan kan je toch gewoon de bestaande tagging gebruiken met cycleway=opposite_lane? Waarom een nieuwe verzinnen (hoewel die van jouw wel logisch klinkt).

Ligfietser,

Bedenk twee dingen:

  1. Ik wil he oude tag systeem niet omver gooien, sterker nog veel zal uiteindelijk het zelfde blijven.
  2. Ja, het klopt wat je zegt. Voorbeelden gaan altijd mank, maar dat was nu niet de issue.

De hoofdzaak is dat ik mij groen en geel erger aan:

  1. aparte fietspaden terwijl ze gewoon een deel van de weg zijn en dus als zodanig getagd dienen te worden. Aparte fietspaden zijn alleen gerechtigd wanneer ze a) of de hoofdbaan zijn b) of tijdelijk zo ver van de hoofdbaan afwijkt dat het tot absolute verwarring leidt.
  2. mapping technisch geen ruimte overlaat om ook de busbaan, het voetpad en andere wegonderdelen te tekenen.

Eigenlijk geef je hier wel een heel erg leuk voorbeeld van slechte tag. Deze tag vertelt namelijk twee eigenschappen terwijl iedere tag slecht 1 eigenschap dient te beschrijven. De tag zegt 1) Het fietspad is een lane (cycleway=lane) en 2) de toegestane richting is tegen de richting van de wegrichting (oneway=-1). De twee aparte is uiteindelijk in het gebruik veeeeel eenvoudiger. Afvoeren dus deze tag. :wink:

ZMWandelaar

Ik heb het idee dat de OSM data steeds meer in detail gaat, dus lijkt het me niet handig om wat gemakkelijk apart te tekenen/tracken is te blijven samenvoegen omdat je graag 1 way wil houden.

Bij tagging van 1 way is het nadeel dat het traject van de way behoorlijk kan afwijken van de bijbehorende paden etc. Bijvoorbeeld als aparte wandelpaden op een in het verlengde liggende stoep naast een straat aansluiten, vooral als er bijvoorbeeld een groenstrook/parkeerstrook tussen ligt levert dit problemen op. Je moet het pad dan via een bocht op het midden van de straat laten aansluiten. Zou de de stoep als aparte way naast de straat hebben dan is de stoep met in het verlengde het voetpad een mooie rechte lijn. Zoals het in de werkelijkheid ook is.

Ik vind die aparte fietspaden een ordentelijker manier van tekenen, zeker op gedetailleerde zoomniveaus, dan 1 way met eventueel wat extra arcering of aparte weergave van de randen. Dat meer uitgezoomd de secondary way over het fietspad komt te liggen is natuurlijk een renderer keuze, kan de fietspaden dan ook weglaten. Zoals het waarschijnlijk ook als de meerdere eigenschappen op 1 way getagged zijn de renderer de way over landuse/buildings POI’s laat lopen.

Het is natuurlijk wel zo dat met aparte ways er eigenlijk een manier zou moeten zijn om alle ways die bij elkaar horen te koppelen. Er is een relation street, maar geen idee of dit veel gebruikt wordt. Dat is natuurlijk ook het probleem met OSM, er zijn veel goede ideeën maar het is lastig om iedereen zo ver te krijgen dat iedereen dezelfde goede ideeën gaat gebruiken.

De oude discussie is weer terug. Prima, er zijn al postings hierover van meer dan 2 jaar oud. (http://forum.openstreetmap.org/viewtopic.php?id=1099)

Ik heb altijd het gevoel gehad dat er twee zaken een belangrijke rol speelde: als je cycleway=track gebruikt, is dat niet te zien op de kaart en al deze bijfuncties toevoegen is veel en nauwkeurig werk. Voor dat laatste is er een voorstel gedaan om dat sneller te maken met een land afhankelijke standaard waarde. Voor stoepen langs wegen geldt in Nederland: binnen de bebouwde kom is footway=yes een goede gok. Soms moet je hem dan veranderen in footway=no.

Het voorstel hoe datgeimplementeerd zou kunnen worden, kun je hier vinden: http://wiki.openstreetmap.org/wiki/SotM_2010_session:_Tag_Central:_a_Schema_for_OSM
Ik moet zeggen dat het nogal wat weerstand ondervond, met name van Steve Coast. Was me niet duidelijk waarom.

Wat betreft de navigatie: enige tijd geleden fietste ik langs een weg met een verplicht fietspad. Mijn route planner op de Garmin probeerde me steeds de hoofdweg op te sturen om dat ik over 10 km links af moest en de lichte kromming naar links, de hoofdweg (verboden voor fietsers uiteraard, maar niet op onze kaart als zodanig aangegeven) de kortere weg was. Ik ben dus een voorstander van cycleway=track, waar dat maar enigszins mogelijk is. het zelfde geldt voor footways.

Hugo

Punt 1 van je ergernis is werkelijk van de zotte.

-Fietspaden hebben dezelfde status als andere andere wegen. Er is dan ook geen enkele reden ze ondergeschikt te maken aan die andere wegen. Voor een fietser is een fietspad net zo belangrijk als een snelweg voor een automobilist. Ik stel toch ook niet voor om provinciale wegen naast het fietspad als bijfunctie van het fietspad te gaan taggen?

-Wanneer een fietspad niet als fietsstrook , maar als gescheiden pad langs een weg loopt zul je dit ook zo moeten tekenen.
We maken een kaart/database !!! en proberen dat zo nauwkeurig mogelijk te doen. Voor een fietser is dit ook nog eens relevante informatie, dus waarom zou je hem dit willen onthouden?

-Wanneer een renderer niet overweg kan met de ligging van wegen dan moet de renderer aangepast worden, niet de ligging van de wegen. Gouden regel: pas nooit tags aan omdat de huidige renderer er niet mee overweg kan!

-het voorbeeld van de Garderenseweg is iets gecompliceerder: de brede witte stroken naast de weg zijn niet zozeer het fietspad, maar opengelaten stroken door de invulling van groengebieden uit landuse . Het fietspad zelf is een blauwe stippellijn. Zou je die blauwe lijnen als toplaag renderen dan is de zaak omgekeerd.

Uiteindelijk is de database waar het om gaat. Zet daar zo veel mogelijk informatie in, en natuurlijk fysiek correct. En met alle tags die bestaan of niet bestaan maar die je relevant vindt. Wat een renderer of routeringssoftware daar dan uit haalt is een andere zaak. Een renderer is tijdelijk, de database niet.
Pas je de database aan omdat de huidige renderer er niet mee overweg kan, dan frustreer je alle toekomstige ontwikkelingen omdat de database incorrect is.

In een grote(re) plaats wordt de kaart onoverzichtelijk als je alle paden afzonderlijk op de kaart zet. Vanmorgen heb ik de fietspaden langs een iets drukkere weg bij mij in de buurt op de kaart gezet. Daarnaast zijn ook in sommige gevallen voetpaden. Eén weg met aan weerszijden een fietspad en een voetpad zorgt voor veel verwarring en fouten als de afslagen niet worden geknoopt.

@Hugo_H: Wat een geweldige uitwerking van een idee waar ik volledig achter kan staan. Wat zou dat een hoop incorrecte documentatie en zoeken op Wiki schelen. Vooral de land/taal afhankelijkheden die je daar dan in kunt verwerken. Geweldig.
Helaas lost dit niet het probleem op dat ik hier naar voren breng. De implementatie zal het wel veel makkelijker maken.

@Noordfiets: Het wordt tijd dat jij eens een keer anders op je fiets gaat zitten. Jouw rechtstreekse aanval op mijn vermeende feit dat ik de fietser ondergeschikt wil maken aan een andere weggebruiker. Geenszins. Als je nuchter een nachtje slaapt over het feit dat ik nog geen enkel fietspad heb gezien waar automatisch ook auto’s zijn toegelaten, maar dat er wel wegen voor auto’s zijn waar het automatisch ook geoorloofd is om met jouw fiets op te rijden geeft al iets aan dat ik de fiets niet op een bepaalde tree op de ladder zet, maar dat onze maatschappij dat doet.

@Noordfiets: Ik hoop nooit dat renderers de fietspaden in het vervolg als laatste tekenen. Dat zou betekenen dat de geile blauwe stippellijntjes op heel veel zoomniveaus dwars over wegen komen te liggen. Lijkt me niet niets iets wat de mapper heeft bedoeld.

@Mattheus: Ik denk dat jij in die mapsessie keihard tegen het probleem bent opgelopen waar ik een oplossing voor wil vinden. Ik denk dat het helle connectieprobleem nog eens een bijkomend dilemma wordt waarvan ik nu aan zie komen dat OSM nooit goed navigatiemateriaal zal kunnen leveren zolang dit pronbleem blijft bestaan. In mijn voorstel ben je in 1 klap van dat probleem verlost.
Ik heb ook eeens zitten rekenen. Als je 2 wegen laat kruisen waar keurig volgens het Noordfiets-concept de hoofdbaan, het fietspad en het voetpad apart getekend zijn, dan komt da neer op

  • 9 nodes
  • 24 ways
    In het ZMW-concept zijn het:
  • 1 node
  • 4 ways
    En wat is het uiteindelijk het verschil in de weergave van de werkelijkheid ten opzichte van de hedendaagse geschonden werkelijkheid omdat renderers niet snappen wat we bedoelen en niet kunnen navigeren omdat de potentiele foutkans 5 tot 6 keer groter is?

@Noordfiets: Kun jij eens een 3 tal voorbeelden (uit jouw omgeving) geven waarbij het samenvoegen van wegfuncties zoals ik dat in het ZMW-concept heb weergegeven) gaat leiden tot onacceptabele schending van de werkelijkheid?

Als beginneling laat ik de paden die ik op de kaart aanbreng, controleren door Eggie, een forumgenoot. Hij wijst mij op de dingen die ik anders kan doen. Ik loop nog niet tegen een probleem op, maar voorzie wel problemen. Ik heb nog maar één keer gefietst met de OFM. Mijn tracks zette ik uit op de OFK. Ik fiets tracks en geen routes, dus veel problemen met routering zal ik op de fiets niet krijgen. Op het platteland vind ik aparte fietspaden ideaal. Als ik een track maak, kan ik gelijk zien waar de mooie fietspaden zijn. De OFK kent alleen maar groene wegen en daardoor is die kaart behoorlijk onbetrouwbaar. De OFM kent vele voordelen en er komt regelmatig een update.

Dat iedere mapper individueel werkt, is wel een nadeel. Een ieder zet met de beste bedoelingen soms een fietspad of een ander pad op de kaart zonder verbindingen te maken , zodat een iedereen behoorlijke omwegen moet maken. Zo was er bij Havelte een rotonde, maar vanuit Havelte kon je niet op het fietspad komen zonder een flinke omweg te maken. Ik heb die rotonde aangepast, waarbij Eggie heeft gecontroleerd of ik het goed heb gedaan. Want het is wel de bedoeling dat iedereen zonder problemen deze rotonde kan opnemen in een route zonder routeringsproblemen.

Allemaal, zo als eerder gezegd om de enen of andere reden een zeer precair punt in de mapping community.

@Noordfiets: het gaat hier wat mij betreft over wegen waar de beheerder besloten heeft dat fiets verkeer en autoverkeer over verschillende delen van de weg rijden.De beide delen hebben dezelfde straatnaam. In mijn optiek blijft dat gewoon 1 weg. Als je jouw redenering strikt zo doortrekken zou je ook alle stoepen in moeten tekenen, dat is waar de voetgangers als verkeersdeelnemer zich voortbewegen en de auto en de fiets niets te zoeken hebben. Ik heb het niet nagerekend, maar de berekening van ZMWandelaar zou weleens 2 maal zo hoge getallen kunnen geven.

@Mattheus: Prima dat je op deze manier begint te werken. Ik hoop dat je je leerpunten ook verder deelt, want een initiatief als OSM moet het hebben van het delen van ervaring en inzichten met anderen zo dat de beste database verschijnt (liefst de beste van de wereld).

@ZMWandelaar: Ik zal eens contact opnemen met David en proberen uit te vissen of er ergens actie op zijn voorstel is genomen.

Hugo

Ik denk dat in sommige gevallen methode ZMW het meest praktisch is en in andere gevallen die van Noordfiets.
Voorbeeldje deze Utrechtseweg:
http://maps.google.nl/maps?q=amersfoort&oe=utf-8&client=firefox-a&ie=UTF8&hq=&hnear=Amersfoort,+Utrecht&gl=nl&ei=5VH7TNPFCcKy8gPg5bzMCw&oi=geocode_result&ved=0CCUQ8gEwAA&ll=52.144784,5.367545&spn=0.000892,0.006539&z=18&layer=c&cbll=52.144785,5.367548&panoid=4Vgetc0Dt8Dtnf2R94sm8w&cbp=11,229.83,0,10.09
http://www.openstreetmap.org/browse/way/6986262
Die is volgens de ‘methode Noordfiets’ ingetekend (twee blauwe stippellijntjes naast de hoofdrijbaan omdat ik toen dacht dat deze methode de meest aanvaarde was. Achteraf bleek er ook een cycleway=track tag te bestaan, dat had idd heel wat werk bespaard. Je hoeft immers niet bij elke zijstraat of oprit een aansluiting te maken, en een aparte fietsrotonde om de rotonde heen te tekenen. Op de openfietsmap krijg je dan een rood lijntje om de bruine of gele (resp secondaire / tertiare) te zien. Vooral bij het uitzoomen rendert dit ook beter, er verdwijnt niets onder de weg. Vooral als het gaat om één richtingsverkeer fietspaden aan weerzijden van de weg geef ik ZMW’s methode de voorkeur.

Iets verderop de Utrechtseweg zou ik wel voor apart ingetekende fietspaden (highway=cycleway) kiezen:
http://maps.google.nl/maps?q=amersfoort&oe=utf-8&client=firefox-a&ie=UTF8&hq=&hnear=Amersfoort,+Utrecht&gl=nl&ei=5VH7TNPFCcKy8gPg5bzMCw&oi=geocode_result&ved=0CCUQ8gEwAA&ll=52.141212,5.358925&spn=0.001784,0.013078&z=17&layer=c&cbll=52.141215,5.358927&panoid=rODNyHnbdxp4Z_-mBG7cvg&cbp=11,286.17,0,3.74

Ter hoogte van de Stichtse rotonde wordt de afstand dermate groot tussen de autorijbaan en het fietspad dat hier duidelijk sprake is van aparte gps tracks. Ga je verder richting Soesterberg dan verandert het fietspad nl af en toe in een ventweg naast de hoofdrijbaan voor autoverkeer om de woningen en/of kantoren te bereiken:
http://www.openstreetmap.org/?lat=52.124466&lon=5.298068&zoom=18&layers=M

Je moet je dingen niet direkt persoonlijk opvatten. Ik ben het absoluut oneens met de manier waarop jij OSM vorm wilt geven omdat het het een fundamenteel foute manier is als het om cartografie gaat. Daarbij speelt wie je bent of hoe je heet geen enkele rol. Daarnaast: als jij je groen en geel ergert aan een verschijnsel in OSM dan lijkt me dat evengoed een persoonlijke opvatting. Anderen maken zich daar vaak niet druk om.

Iedere renderer kan zijn eigen manier van weergeven bedenken. Dat is nu al voor een groot deel zo: zie de openfietskaart en de verschillende layers die je aan kunt zetten. Daarbij baseren ze zich op een zo accuraat mogelijke database waar ze naar keuze gegevens uithalen. Zoals Theun al aangeeft: op het 100% formaat is er niks aan de hand en worden alle wegen keurig gerendered, inclusief vrijliggende fietspaden. Dat bij het verkleinen een renderer niet alles goed kan weergeven is geen reden dan de database maar te veranderen, maar een reden een andere renderer te schrijven.

Hier toon je het fundamenteel verschil. Want wat wil je nu: een geografische database of een navigatiedatabase? Wil je de manier waarop je de kaartgegevens opslaat ondergeschikt maken aan navigatiesoftware? Dan vervalt de accuraatheid. Terwijl omgekeerd het correct registreren van geografische werkelijkheid het functioneren van routeringssoftware niet uitsluit. Ja, je moet meer knooppunten maken, maar wat is het probleem? Het is meer werk, maar dat kan geen bezwaar zijn.

Ieder fietspad. Zoals ik al eerder zei: fietsers bepalen hun route op een kaart aan de hand van de wegsituatie. Daarbij is er een groot verschil tussen vrijliggende paden en fietsstroken. De kaart moet daar dan ook duidelijk uitsluitsel over geven. In de huidige situatie kan ik op de kaart zien dat ik over een vrijliggend fietspad kan rijden. Dat is dus relevante informatie. Vrijliggende paden die zich slingerend langs een hoofdweg bewegen zijn over het algemeen aantrekkelijker en van de hoofdweg gescheiden door een bermstrook met bomen ( je voorbeeld van dat fietspad bij Putten ).
Als voorbeeld een citaat uit de Falk fietskaart:


Apart getekende paden met knooppunten. Gerenderd vanuit een complete database. Het kan dus wel.

Om in zijn algemeenheid af te sluiten: het aanpassen van een database omdat je (nog) niet in staat bent de gegevens weer te geven op een (persoonlijk aantrekkelijke) manier is geen ‘best practice’.

@Ligfietser: Bedankt voor je positief constructieve bijdrage. er zijn twee dingen die ik met deze draad NIET wilde bereiken:

  1. Afschaffen van de mogelijkheid om fietspaden apart te kunnen tekenen. In die zin is het dus een puur arbitraire zaak om eens met elkaar een aantal richtlijnen af te spreken waarbij het beter is om de NF-methode te gebruiken ten opzichte van de eventueel default ZMW-methode. Het eerste voorbeeld dat jij noemde is precies zo’n voorbeeld waar je ipv de ZMW- de NF-methode kunt gaan toepassen.
  2. Verminderen van het hoogwaardig kwaliteitsniveau dat we met elkaar binnen OSM nastreven. Ik heb immers gewezen op het feit dat door de NF-methode “overal” een ordentelijke invoeging van nog meer wegfuncties in de weg staat. Omdat, naar mijn bescheide mening, de ZMW-methode in meer dan 80% van alle gevallen om deze reden eenvoudiger, bruikbaarder en Datavriendelijker is, zie ik geen reden om deze methode verder uit te werken tot een volledig omschreven alternatief.
    De vrees van Noordfiets is echter wel terrecht. We moeten toezien dat de richtlijnen binnen de gebruikerskeuze tussen NF- of ZMW-methode niet leidt tot onacceptable verlies van werkelijkheidswaarde van de opgeslagen cartografische gegevens.

@Noordfiets: Zou jij een eventueel voorstel voor de ZMW-methode in een later tijdstip willen beoordelen op deze onacceptableheidsgrens? Uiteraard is deze uitnodiging alleen van kracht wanneer je niet alleen de nul-grens wilt aanhouden.

Ik dit moment zie ik een paar problemen:
cycleway=track wordt niet gerenderd, behalve in osmarender. Maar bijvoorbeeld niet op de openfietskaart! Cycleway=track geldt algemeen eigenlijk als noodoplossing als de exacte ligging niet bekend is. Het fietsnetwerk is in feite losgemaakt van het autonetwerk, en alleen daar waar beide fysiek samenvallen zijn knooppunten. Veel fietsers zijn zelfs met gps onderweg om de ligging van die paden te noteren en de tijdelijke cycleway=track te vervangen door highway=cycleway.

Lees ook eens de aanbeveling hier http://wiki.openstreetmap.org/wiki/NL:Bicycle/statement . Vanuit dit perspectief is jou voorstel zelfs een stap terug. ( lees vooral het stuk over de mogelijkheid oversteekplaatsen vast te leggen, iets wat met cycleway=track niet mogelijk is: het levert dus een extra routeringsprobleem op, want hoe moet de software nu vaststellen waar een fietser van de track af de weg op kan? Je moet dan ook nog een tag cycleway:track=crossing o.i.d. gaan invoeren, dus het aantal nodes neemt uiteindelijk niet af. De vraag is dan of bijvoorbeeld Garmin daar eigenlijk wel mee overweg kan … Ligfietser??)

Je kunt altijd een nieuwe weg mappen met cycleway=track. Maar als iemand een fietspad als highway=cycleway invoert denk dat je dat moet accepteren, en niet het fietspad verwijderen en terugzetten naar track. Dat zou voor mij onacceptabel zijn. Omdat het immers verlies van gegevens is en zelfs contraproductief voor het routeren.

Overigens is hier qua rendering ook al eens eerder de optie langs gekomen dat renderers een auto-shift functie zouden moeten hebben. Valt de breedte van een gerenderde weg over een naastliggende weg dan zou de naastliggende weg automatisch iets verschoven gerenderd moeten worden. Dat geldt dan niet alleen voor fietspaden, maar overal waar naast elkaar liggende wegen botsen ( ventwegen naast trunk etc. )

Ik ben het met Noordfiets eens dat we niet reeds ingetekende highway=cycleway moeten gaan weggooien om in plaats daarvan de tag cycleway=track op de hoofdweg te zetten. Laat staan highway=cycleway helemaal af te schaffen.

Ik heb bij mapnik al ooit een verzoek gedaan om cycleway=track te renderen (en meer zaken) maar niemand die dat oppikt. Ook bij de standaard mkgmap Garmin kaart wordt highway=cycleway niet eens standaard gerenderd (bijv op de kaarten van Lambertus) en een verzoek om daar iets te aan te doen wordt domweg genegeerd. Dus proberen de renderers te veranderen blijkt ook niet zo eenvoudig als men denkt, dus ben ik maar zelf begonnen een kaart te gaan maken. :wink:

Wat betreft oversteekplaatsen maak je toch gewoon een node waar de weg een zijweg kruist? Daar kan je toch gewoon afslaan als fietser/automobilist/whatever? En als auto’s daar niet in mogen maar fietsers wel zet je in die zijstraat een barriere (meestal staat er dan al een paaltje, barrier=bollard). Wordt het een wat ingewikkelder situatie dan gewoon de fietspaden apart intekenen als highway=cycleway, maar bij eenvoudige situaties met 2 rijbanen voor het snelverkeer en 2 aan weerzijden liggende fietspaden (bijv gescheiden van de weg door een kleine groenstrook of betonnen rand of alleen een strookje tegels) volstaat de tag highway=secondary met cycleway=track

Je weet gewoonweg niet aan welke kant van de weg dat ding ligt. Aan beide kanten, aan 1 kant, welke kant dan, hoever van de hoofdrijbaan af?

Buiten dat zijn sommige dingen gewoonweg nog niet mogelijk in de renderer. Zoals het maar aan 1 kant van een way tekenen van een object zoals een fietspad.

@Noordfiets: Ik apprecieer je constructievere meedenken in je laatste replay. Natuurlijk ga ik niet als een gek alle fietspaden uitbannen, maar weet je hoeveel boswegen er op de veluwe liggen die als highway=cycleway gemapt is en eigenlijk highway=track;cycleway=track is. De mapper heeft gewoonweg alleen het fietspaadje ingetekend en de track … ach vergeten, niet belangrijk. Het is geen verlies van gegevens wanneer ik deze 0mzet naar de ZMW methode en zo de fiets, auto en wandelfunctie samenvoeg.
Ik hoop in overleg met Ligfietser de ZMW-methode meer vorm te geven in de kaart om zo alle data zo efficient mogelijk te benutten in zijn kaart en zijn routering.

@Ligfietser: Als we denken een goede methode te hebben, zullen we het ook wereldkundig moete maken. Dat lijkt mij het beste door op jouw kaart de nieuwe mappingmethode vorm te geven. Wat denk je daar van. Ga ik de komende weken een document (wiki?) maken waar alle mogelijkheden voor de tag:cycleway staan beschreven en denk jij na over hoe je dat het mooite in een kaart gaat/kunt gieten.

@ZMWandelaar: Als je nu denkt dat je de fietspaden in het bos eigenlijk highway=track;cycleway=track is, dan ben je echt verkeerd bezig. :frowning:

Op de manier waarop in de relaties rollen uitgedeeld worden, kan in een tag ook aangegeven worden waar de fietsbaan ligt ten opzichte van de Way-ricchting.
Bijvoorbeeld: cycleway:side=right (Rechts van de weg als je met de wegrichting meekijkt.)

Noordfiets heeft gelijk als hij zegt dat je de invoer niet afhankelijk moet maken van de huidige mogelijkheden van de renderers. Je moet zien dat je de werkelijkheid zo realistisch mogelijk en vooral efficiënt mogelijk in de database gaat opslaan.
En hoever het fietspad van de weg af ligt is binnen de eerste 10 meter niet zo heel erg belangrijk. Voor de liefhebbers/mapper kan natuurlijk de tag cycleway:dist=* geïntroduceerd worden om de afstand op te geven tussen de wegas-hoofdweg-fietspad. Hoffelijk streven voor iedere mapper die deze detaillering belangrijk vindt. de renderer kan daar dan in zoomlevel 18 rekening mee houden. In hogere zoomlevels zijn die details irrelevant. Mappers zullen voor die tag overigens wel een meetlat mee moeten nemen omdat deze detaills niet opgehoest kunnen worden door een GPS track. Daar is de huidige satellietontvangst met alle schaduwwerking veel te onnauwkeurig voor.