Bijfuncties van een weg

Communities Nederland (Netherlands)
61

Mag ik dan ook nog cycleway:track:left:width, cycleway:track:right:width, cycleway:track:left:surface, cycleway:track:right:surface, cycleway:track:left:MTB, cycleway:track:right:MTB, cycleway:track:left:access:moped=, cycleway:track:right:access:moped= etc. etc.
En een correctie op landuse, want als al die tracks dwars door het gras lopen is het ook geen gezicht.

Ik wel wel het volgende nog even kwijt:

Een discussie op dit forum is niet zomaar maatgevend voor aanpassingen aan de wiki. Daarvoor is een discussie tab op de wiki zelf. Het introduceren van nieuwe noodzakelijke tags is ook al iets wat normaal gesproken met een proposal gaat. Ik meen me zelfs nog een discussie te herinneren waarbij iemand nogal fulmineerde tegen het lukraak gebruik van nieuwe tags …
Het aanpassen van een wiki op basis van een persoonlijke ergernis lijkt me nogal misplaatst en in strijd met de normale gang van zaken binnen OSM.

De zin ‘Zo nu eerst nog de laatste hand leggen aan de huidige Kaarteigenschappenpagina en dan de WegenBijfunctie pagina uitwerken en promoten bij onze (buitenlandse) mappende vrienden en renderers in binnen en buitenland’ is mij een gruwel: dit is de omgekeerde gang van zaken!
Ik heb net eens na lange tijd op de kaarteigenschappen gekeken en lang niet iedere wijziging van het afgelopen jaar lijkt me even correct ( zie de history). Sommige wijzigingen zijn zelfs zonder meer fout te noemen t.o.v. de internationale wiki. Ik erger me daar aan, maar zelfs dat is voor mij geen reden alles zomaar terug te zetten.

Normaal wijzig ik niet zoveel in de wiki, omdat ik vind dat anderen daar goed werk doen. Maar ik verzet me tegen het solistisch introduceren van een heel nieuw systeem dat ingaat tegen bestaande afspraken, niet uitgewerkt is, geen relevante tags kent en al helemaal niet gerenderd wordt, en bovendien de openfietskaart/opencyclemap minder waard maakt.

Ik citeer hier Ligfietser: ‘Als jij je als wandelaar nou met jouw stoepen bezig houdt en afblijft van onze fietspaden vind ik het best’ maar dan zonder smiley.

62

Ik bespeur op z’n zachts gezegd enige ergernis van jullie kant. Dat kan ik mij uiteraard goed voorstellen. ZMW is op geen enkel manier van plan bestaande methodes omver te werpen. Ik erken de vrije wil van een ieder binnen OSM en de wil van de massa. Hiermee schaar ik mij volgens mij geheel binnen dezelfde gelederen als waar jullie je bevinden.
Ik kan me dan ook niet voorstellen waar jullie kritiek op hebben. Nieuwe ideeën zijn/waren altijd welkom binnen OSM, wanneer ze de integriteit van OSM database maar niet zouden aantasten. De ZMW methode doet dit niet, schaft geen methodes af en verbiedt geen tags. ZMW probeert met een frisse blik te kijken naar de nieuw ontstane situatie om uiteindelijk alle groepen (Fietsers, Voetganger, Bejaarden, Vrachtwagens e.d.) voldoende ruimte te geven haar data ook kwijt te kunnen.

In ruil daarvoor worden er zaken beweerd die m.i. onwaar en onterecht zijn:

  • “het solistisch introduceren van een heel nieuw systeem”.
    Een idee begint altijd bij 1 persoon die deze uitwerkt in wiki ( zoals gebruikelijk als proposal) medestanders probeert te vinden die het vervolgens kunnen overnemen. Solistisch?

  • “Om de terreur van fietspaden de kop in te drukken.”
    Zo wil ik het zelf niet noemen. :wink:

  • “Ik heb net eens na lange tijd op de kaarteigenschappen gekeken en lang niet iedere wijziging van het afgelopen jaar lijkt me even correct”. Als ik veel tijd en energie steek in het bijwerken van de belangrijkste pagina van Wiki:NL, dan is het min om je er op deze laatdunkende manier over uit te laten. Voorheen was er veel meer fout op deze pagina dan nu, en als je (Noordfiets) zelf niet de moeite neemt om dit werk te doen, moet je je zeker niet op deze manier er over uitlaten. Schandalig. Ik wil je eerder uitnodigen om de vermeende fouten bekend te maken, dan kunnen we met elkaar streven naar een foutloos document. Heel veel (nieuwe) mappers gebruiken deze pagina als handvat voor hun werk.

  • “Als jij je als wandelaar nou met jouw stoepen bezig houdt en afblijft van onze fietspaden vind ik het best”.
    Allereerst zijn het inderdaad ONZE fietspaden. En als ik vind dat onze fietspaden er voor zorgen dat SOMS deze fietspaden voorkomen dat onze VOETPADEN niet juist getagd kunnen worden, dan lijkt het mij gerechtigd om daartegen in verzet te komen en een alternatief te verzinnen. Het enige wat ik hierbij tegen kom zijn fietsende vrienden die uit alle macht vasthouden aan indertijd verzonnen methode.Verzonnen in een tijd toen de kaart in opbouw was en de hoeveelheid data nog relatief klein was. Vanaf het begin heb ik gehoopt een groep fietsende vrienden te vinden die konden inzien dat oude afspraken in het licht van de tijd het beste was dat heeft kunnen gebeuren, maar dat deze beslissingen in het licht van de huidige situatie (ook mappen van stoepen en voetpaden, denk ook aan het door jullie gememoreerde blindenproject in Duitsland) wel eens niet meer zo optimaal is en wellicht aan revisie toe is. In reactie op nieuwe initiatieven graven ze zich in en gebruiken woorden als: “geen relevante tags kent en al helemaal niet gerenderd wordt, en bovendien de openfietskaart/opencyclemap minder waard maakt.”
    OSM TAGT NIET VOOR EEN RENDERER EN OOK NIET VOOR EEN KAART. TOCH? Of is de OpenFietsMap daarin een uitzondering. :frowning:

@Michiel Faber: Ik ben in mijn telling uitgegaan van alleen node A en B. zoals jij het stelt zijn het dus 5 wegsegmenten.

63

De hoeveelheid tags opperde ik al vrij in het begin als een bezwaar. Echter met het kiezen van redelijke standaarden en het gelijk stellen van links en rechts als standaard gaat het nog meevallen.
Je moet in elk geval voor de eigenschappen van de weg, evenveel tags invoeren als op een andere manier. Nu komt er alleen in de key een aanduiding bij om welk fietspad het gaat (:left of :right). Waarom er ::access:moped=* in moet zie ik niet in. Het kan toch gewoon met track:left:moped=*? Dat gebeurt op een individuele way ook.

Voor een weg

  • aan beide kanten een fietspad
  • met links wel moped
  • rechts een ondergrond
  • met de breedte aan beide kanten
  • en iets met MTB.

ZMW:
highway=*
cycleway=track
track:width=*
track:left:moped=yes
track:left:mtb=*
track:right:surface=*
track:right:mtb=*

Valt toch mee?

Anders zou het worden:
highway=*
highway=cycleway
width=*
mtb=*
moped=yes
highway=cycleway
width=*
mtb=*
surface=*

Hoe meer dingen overeenkomen tussen beide kanten, hoe minder tags nodig zijn ten opzichte van het taggen van alle wegen individueel.
Zijn de wegen verschillend, dan moeten er evenveel eigenschappen getagged worden.

Dat heeft niets te maken met een methode om een fietspad te omschrijven. Ik zou altijd graag een correctie op landuse zien als de landuse niet goed in de databade staat.

Verder wil ik nog duidelijk maken dat het volgens mij geen poging is om de nu gehanteerde manier overboord te gooien, maar juist om een al bestaande manier te verbeteren. Met als doel, de database en daarmee ook de kaart nauwkeuriger en beter ‘werkbaar’ te maken. Dat willen we toch allemaal?

64

@Michiel Faber: Klopt, ik hoop ooit te komen tot een alternatief welke ik kan aanwenden wanneer de noodzaak daartoe is. En dit alternatief wil ik graag geaccepteerd zien door de bestaande fietsmappers. Beginnend bij de Nederlandstaligen en vervolgens via de Engelstalige community.
Ik kan daar wel beginnen, maar als ik voor het internationale veld mijn eigen landgenoten op mijn nek krijg, dan voel ik mij helemaal in mijn hemd gezet. En daar had ik nu net geen trek in. Vandaar eerst deze draad met een beperkte uitwerking.
Maar precies wat je zegt: Ik ontwikkel door op een ooit door de fietsers ingeslagen weg.

65

Hierbij zal ik je nog maar eens wijzen op de router voor blinden, waarvoor het nodig is alle stoepen en afstapjes afzonderlijk te mappen.

Dat is de richting waarin OSM gaat. “dubbele punt diarree” daarentegen wordt meestal aangehaald als een voorbeeld van hoe het niet moet.

66

Dat kan toch.

footway=yes/right/left
footway:width=1
footway:rigth:surface=paved

Op een node waar men kan oversteken kun je dan toch een tag opnemen met crossing=yes. Die node moet anders ook getekend worden.

Nogmaals: Het enige nadeel zijn (of is het ‘is’?) de vele tags (en voor sommige wellicht onduidelijke/onoverzichtelijke) op een way.

67

Als dit idee dan toch verder uitgewerkt gaat worden, moet het punt van overzichtelijkheid zwaar meewegen binnen het advies inzake het mappen als 1 way of x ways.

In het voorbeeld van Ligfietser bij Dierenpark Amerfoort hebben we overigens de afslag helemaal vergeten. Die moet ook op een of andere manier er nog tussen gepruts worden. De huidige manier zou vlak bij de kruising in dat geval, mits we alle wegfuncties gelijkwaardig mappen, 7 lijntjes (footway, cycleway, serviceway, highway 1, highway 2, cycleway, footway) naast elkaar krijgen. En daar zal iedere renderer gedwongen mee om moeten kunnen gaan. Op de alternatieve manier doe je het met tags en dan kan iedere kaartmaker er uitpikken wat hij belangrijk vindt. In beide manieren staat de informatie in OSM. En dat is voor de community toch doel nummer 1.
Smaak of gewenning bepalen welke van de methodes je voorkeur heeft.

68

crossing=yes
crossing:length=7m
crossing:angle_at_start=75degree
crossing:angle_at_end=90degree
crossing:single_step_at=1.5m;5.5m
…

Allemaal om een oversteekplaats in een bochtje te beschrijven.

Waarom zo je in in godsnaam allerlei geometrische informatie in tags gaan stoppen als je een geografische database hebt.

Nee, meer geometrisch detail heeft de voorkeur. Alleen als dat detail er nog niets was en je zelf geen zin in hebt om het toe te voegen kun je minder details plaatsen, maar je moet niet gaan zeuren als een ander dat later alsnog doet.

Hé dat klikt bekend: Dat is namelijk zo voor al het mappen in OSM, of het nu een weg of landuse of een kustlijn of een adres of … is.

69

Het is een lap tekst, maar graag zou ik jullie willen vragen dit rustig en met een ‘open mind’ te lezen.

Ik ben erg gecharmeerd van het idee van ZMWandelaar om meer eigenschappen onder te brengen in 1 way. Echter, ZMWandelaar heeft het over “bijfuncties van een weg”. Deze naamgeving is naar mijn mening niet goed. Graag wil ik dan ook de manier van taggen verduidelijken en de systematiek erachter beschrijven om zo de manier van taggen te krijgen.

Het huidige OSM tagging systeem is gebaseerd op key=value paren. Hier wijk ik natuurlijk niet van af, maar ik zou het graag willen aanvullen.
Een weg wordt momenteel in kaart gebracht met de tag ‘highway’. Deze kan verschillende waarden hebben, waaronder primary, cycleway en footway.
Aan deze weg worden dan eigenschappen meegegeven, waaronder ‘access’, ‘surface’ en ‘oneway’ eigenschappen. Ook kan er vermeld worden of er een naastliggend fiets- dan wel voetpad is met de tag ‘cycleway=track/lane’ of ‘footway=yes’.

Dit is natuurlijk allemaal duidelijk, maar toch heb ik het opgeschreven. Juist om aan te tonen wat er nu gebeurt.
Bij bovenstaande methode wordt het al lastig om van het naastliggende fietspad de ondergrond of de breedte op te geven. Met ‘oneway’ is een poging gedaan (opposite_lane), maar dat is dan ook het enige.

Mijn voorstel is om de key uit te breiden. Met name moet dan duidelijk worden van welk weggedeelte we de eigenschap willen omschrijven.
Dat gebeurt nu impliciet ook al, alleen kan het alleen op het eerst beschreven weggedeelte.

Voorbeeld:
highway=primary
oneway=yes
cycleway=track

Eigenlijk is alleen de weg een ‘oneway’ en is het fietspad van zand. Hoe dit te taggen?

Je zou het voorbeeld ook kunnen schrijven als :
Highway=primary
highway:oneway=yes
cycleway=track

Met de eigenschap dat het fietspad van zand is:
cyclway:surface=sand

Nu blijkt dat het fietspad alleen links ligt. Links is hier met de wegrichting (in database) meegekeken.
cycleway:left=track
cycleway:surface=sand

Bij de omschrijving van de oppervlakte is het niet meer van belang dat ik ‘left’ toevoeg. Dat blijkt al uit de voorgaande tag. Er is dus geen rechter fietspad.

Nu kunnen we er ook een stoep bij doen.
footway=yes

Klaar! Nu heb ik voor de hele lengte van de weg een stoep er naast getekend.

Echter, de stoep ligt hier ook alleen aan de linker kant van de weg.
footway:left=yes

Samenvattend komt het neer op:

Ons key=value paren bestaan nu ineens uit way:which:property=value paren, waar ‘way’ een van de bestaande ‘highway’ values is. De waarde ‘which’ is ‘both/left/right’ en de waarde ‘properties’ heeft alle bestaande waarden die we nu ook al kennen, zoals ‘oneway’, access, surface, etc.

Als men nu goed heeft opgelet, gebruiken we dit nu ook al.

Het voorbeeld nu compleet uitgeschreven.

Highway:both:type=primary
highway:both:oneway=yes
cycleway:left:type=track
cycleway:left:surface=sand
footway:left:type=yes

Als we nu goede defaults kiezen kunnen we de key’s verkorten.
defaults:
way=highway
which=both
property=type

Dan komen we met ons voorbeeld (weer) op:
Highway=primary
oneway=yes
cycleway:left=track
cycleway:surface=sand (left hoeft niet, want dat hebben we hierboven al gedefineerd)
footway:left=yes

Nu we dit weten/gebruiken zijn de mogelijkheden eindeloos.
In plaats van nu een vrijliggend fietspad met een stoep als 2 losse ways te tekenen, kunnen we nu af met 1 way.
highway=cycleway
footway=yes

In Utrecht heb je ook busbanen met aan beide kanten fietspad en aan een kant een stoep.
highway=unclassified (of highway=psv)
acces=no (niet nodig, zie boven)
psv=yes (idem)
cycleway=track
footway:right=yes

Deze manier van taggen is niet tegen het apart taggen van de fietspaden. Alleen een manier om de huidige manier van taggen te verbeteren door hem consistenter en uitgebreider te maken. Je kunt namelijk nu en alles in 1 way doen, en je fietspad apart tekenen naast de weg. Voor de renderers en kaarten maakt het nu ook niet uit, want ze hoeven maar 1 manier van taggen te weten. Wie veel detail wil kan zijn gang gaan, wie minder wil tekenen ook.

Ik heb hier alleen de basis uitgelegd, met maar simpele voorbeelden. Echter, mogelijkheden zijn echt eindeloos.
Voor een land met nog erg weinig wegen een snelle manier om te beginnen:
Highway=motorway
oneway=yes
seperated=yes
left:max_speed=120
right:max_speed=130

Ik zou nog verder willen gaan, maar dat bespaar ik julie (nog even).

Kunnen jullie hier weer met een fris inzicht naar kijken en jullie mening geven?

70

Michiel en anderen,

is in de richting waarin ik ook denk en wat ik dus ondersteun. Het lijkt er op dat we nu proberen met extreme voorbeelden (zanderig fietspad naast een hoofdweg) of een ingewikkelde oversteekplaats in een bocht (van Cartinus) de keuze voor de een of andere benadering te vinden. Als je fietspaden en stoepen gescheiden tekent en de geometrische nauwkeurigheid wilt halen die Cartinus wil, zou het ook vereisen dat we voor alle wegen netjes de breedte aangeven, evenals dat van het fietspad. Verder zul ook je alle fietspaden, stoepen aan elkaar moeten koppelen, (de "belongs-to"tag zou dan geintroduceerd moeten worden), je kunt namelijk volgens mij niet aannemen dat als ze bij elkaar in de buurt liggen zullen ze ook wel bij elkaar horen, dat was namelijk een van de argumenten tegen het als 1 weg tekenen, dat ze ver uit elkaar kunnen liggen.

Ik denk wel dat Cartinus een ander punt even duidelijk maakt, namelijk dat er een geometrisch aspect is en een inhoudelijk aspect. Hij heeft heel duidelijk een keuze voor het geometrisch aspect, waar ik denk dat het over de inhoudelijke kant gaat (kun je hier oversteken en is er een opstap of afstap). Of we die op 1 m nauwkeurig moeten aangeven is volgens mij niet nodig en ook voorlopig niet mogelijk.

Hugo

71

Hugo,

Michiel en ik hebben dit weekend wat overleg gehad en duidelijk onderkend dat het Geometrische aspect niet uit het ook verloren mag worden. we willen niet voor niets allemaal het zelfde en dat is een uitstekende kaart die nog eens veel meer compleet is ook veel multi inzetbaarder dan alle andere kaarten.
Binnenkort komen we met een document waarin zo veel mogelijk scenario’s beschreven en uitgewerkt zijn. Als eerste om te zien of ons idee strookt met de werkelijkheid en ook ‘eenvoudig’ toepasbaar is. Verder is het nodig om alle partijen snel te laten gewennen aan de nieuwe manier van het beschrijven van ALLE functies van een weg.

Maar ik ben blij dat je ons ondersteund.

Graag wil ik direct van deze gelegenheid gebruik maken om ** jullie te vragen input te leveren en in deze draad links te posten van wegsituaties **welke zeker om een oplossing vragen. Wegen waar fietsers, bussen, auto’s, servicewegen en wandelaars samen gaan en allemaal hunplaats moeten gaan krijgen in OSM.

72

Als beginneling volg ik met belangstelling deze discussie en inmiddels heb ik een aantal ontbrekende fietspaden op de kaart gezet. Maar als een mapper ALLE functies van een weg moet aangeven, vrees ik dat je op zoek zult moeten gaan naar professionele cartografen. Wat jij wilt, lijkt me niet te doen voor amateurs.

73

Of anders gezegd: maken we een GIS of een routeringsdatabase. Een nogal fundamentele beslissing. Waarbij ik al eerder beargumenteerd heb: een GIS sluit routering niet uit, een routeringsdatabase sluit een mooie kaart wel uit.
Het apart tekenen van fietspaden maakt voor een automobilist niet uit, de zmw-manier is voor fietsers wel een ramp.

Even terug naar het begin: ZMW kwam met dit voorbeeld als ultieme ellende: http://tile.openstreetmap.nl/?zoom=17&lat=52.25218&lon=5.62395&layers=B000000FFFF
Het ontgaat me volkomen wat er mis mee is. Dit is wat een kaart hoort te zijn. Duidelijk en overzichtelijk voor alle weggebruikers. En met extra informatie voor fietsers, die juist heel erg belangrijk is.

Als ik kijk naar de ideeen zie ik een wildgroei aan nieuwe tags.
En tegelijk een enorme achteruitgang in kwaliteit voor fietsers, waarbij goede initiatieven als de openfietskaart het onderspit delven. Het geheel lijkt op een geval van ernstige regeldrift om een probleem op te lossen wat er niet is.

74

Wat defineert dan een GIS? Als ik in een spreadsheet 2 coordinaten invoer met beschrijving van die 2 punten, kan je al spreken van een GIS.
De zmw-manier breidt het huidige tagging schema uit en zal niets of niemand beperken. Er verandert daarom ook niets aan het type van de database.
In de database staat gewoon geografische informatie beschreven op een vooraf gedefineerde manier. Uit deze database kan je informatie halen om een mooie kaart te maken en je kunt er ook informatie uithalen waarmee men een route kan bepalen van punt A naar punt B, en zelfs via C t/m Y naar Z.

Waarom is de zmw-manier een ramp voor fietsers? Een vrijliggend fietspad kan ook op de zmw-manier worden beschreven. De informatie die een fietser nodig heeft, staat ook gewoon in de database.

Deze weg en de fietspaden zijn met de zmw-manier getagged. De “ultieme ellende” (dat is niet zijn bewoording) komt voort uit het feit dat de ingetekende fietspaden niet evenwijdig en met genoeg afstand van de weg ingetekend zijn. Daardoor overlappen de wegen elkaar en ontbreekt er juist informatie. Er is nog geen manier om het fietspad aan de weg te koppelen, zodat een renderer/router begrijpt dat deze wegen bij elkaar horen. Dat zou het renderen/routeren vergemakkelijken. Dit kan wel met de zmw-manier, maar is hier niet gedaan. En wat mij betreft hoeft dat hier ook niet. Het beter inteken van de fietspaden lijkt mij beter. Zoals ik al eerder zei, dan nog gebruik je de zmw-manier.
Daarnaast zie ik ook niet in, waarom zo’n kaart niet gemaakt zou kunnen worden met de zmw-manier waarbij maar een weg is ingetekend? De weg ligt er, de fietspaden liggen er ook, de maximum snelheid kan beschreven worden, de ondergrond en ook of het eenrichtingsverkeer betreft of niet.

Er is niet meer wildgroei aan tags, dan nu er nu al is. Sterker nog, er wordt een soort standaard voorgesteld, waar heel veel mee kan.

Het oversteekplekje welke Cartinus bedoelt kan hij gewoon intekenen op zijn manier. Hij gebruikt dan eigenlijk ook de zmw-manier, alleen heeft hij het niet door.
Als Noordfietser zijn fietspaden intekent, doet hij dat gewoon op zijn manier. Hij gebruikt echter direct ook de zmw-manier, alleen heeft hij het niet door.

Ik zie geen kwaliteitsverlies voor fietsers. Er komen alleen meer mogelijkheden bij om fietsstroken in kaart te brengen. En waarom zou de openfietskaart het onderspit moeten delven? Waar is je argumentatie? Er wordt op een correcte manier een fietspad beschreven, zowel als onderdeel van een way met meerdere functies, als ook met een losse way.
Als je verschillende internetpagina’s leest, waaronder proposed features, zie je een aantal problemen waar men tegenaan loopt. Die zouden met deze manier erg goed opgelost kunnen worden.

Tevens kun je gewoon door blijven gaan met waar je mee bezig was. Aparte ways tekenen voor fietspaden, stoepen en al wat niet meer kan gewoon. Dat is niet tegenstrijdig met ons idee.

  • Je kan een stoep/fietspad/busbaan naast een weg beschrijven
  • Je kan een weg tekenen en je kan een busbaan/fietspad/stoep ernaast tekenen.

Hoe kun je met de huidige mogelijkheden voor de verschillende richting van een weg, verschillende maximum snelheden beschrijven? Dat kan nu niet, op het tekenen van 2 ways na dan.
Hoe kun je op een kruispunt de drie voorsorteervakken aangeven voor links, rechtdoor en rechts? Dat kan op de huidige manier niet, behalve als je 3 ways gaat tekenen. Dat gaat dan erg leuk kruispunten opleveren.
Hoe kun je een eenrichtingsweg beschrijven met 3 rijstroken waarvan de middelste alleen bestemd is voor een bus/taxi? Dat kan op dit moment niet, of je moet 3 ways gaan tekenen.

De ZWM-manier kan dat wel. En zelfs als je het zou intekenen met allemaal ways, dan nog doe je het op de zmw-manier. Dat is nu juist het mooie. Er verandert niets, maar toch verandert er wat. Er komen namelijk ontzettend veel mogelijkheden bij, zonder andere mogelijkheden te beperken.

75

Voor welke doelgroep is de kaart die jij voor ogen hebt, geschikt?

76

Zoom maar eens even 1 stapje uit, en je ziet het probleem. Het fietspad verdwijnt dan gedeeltelijk onder de weg. Nu kun je natuurlijk de renderer hiervan de schuld geven, maar feit blijft dat met de ZMW manier dit niet gebeurd was.
Ook moeten we denk ik het gebruiksgemak van de mapper niet vergeten. Het is vele malen makkelijker (en nauwkeuriger) om van een bestaande weg aan te geven dat er een fietspad naastloopt, dan een extra fietspad intekenen die exact evenwijdig loopt aan de weg (gesteld dat dit in werkelijkheid ook zo is). Hier zie je voorbeeld van een weg waar de OSM map suggereert dat het fietspad ten noorden dichter tegen de weg aanligt dan te zuiden: http://www.openstreetmap.org/?lat=52.220981&lon=6.860695&zoom=18&layers=M. De werkelijk is niet zo: http://tinyurl.com/2vupqqf. Ook hier kun je de mapper de schuld geven, maar feit blijft dat met de ZMW manier dit niet gebeurd was.
Ook vergeten mappers heel vaak de fietspaden te laten kruizen met de zijwegen (http://tinyurl.com/3a53tva). Ook hier weer de schuld van de mapper, maar met de ZMW manier niet voorgekomen.
Oftewel met de ZMW methode voorkom je heel veel fouten en het scheelt behoorlijk wat werk.

77

Ik heb niet een specifieke kaart voor ogen. Iemand die een kaart wil maken, moet de benodigde informatie uit de database kunnen halen. Dat is mijn doel. Als iemand nu een kaart wil maken met een overzicht van de rijstroken op een kruispunt, kan dat niet. Dat zou hij wel kunnen als we met de zmw-manier ook de rijstroken gaan omschrijven.

78

Ik heb de OFK ruim 1 1/2 jaar gebruikt. De OFK is een echte fietskaart, maar is nog te ruim opgezet. Een tourfietser stelt andere eisen aan een fietspad dan een mountainbiker. De OFM is een verademing om te gebruiken, want ik kan aan de rode fietspaden zien wat de mooie fietspaden zijn.

Nu heb ik in een grotere plaats een aantal fietspaden op de kaart gezet. Dat kan problemen geven omdat ik een aantal verbindingen over het hoofd kan zien waardoor de kaart niet goed routeert. Op zich is de door jou voorgesteld manier goed bruikbaar in een plaats. Fietsers zoeken toch de rechterkant van de weg op of eventueel een fietspad. Zelf zou ik het als fietser vreselijk jammer vinden als ik niet op de kaart kan zien wat voor soort fietspad het is en waar de mooie fietspaden zich bevinden.

79

Maar waarom zou je de fietspaden dan niet meer zien? Dat snap ik niet. De kaartmakers kunnen toch gewoon de info uit de database halen en een mooie kaart maken? Met losliggende fietspaden. Ook al zijn ze als 1 way getekend. Met een cycleway=track beschrijf je losliggende fietspaden. Dat kan toch ook op de kaart aangegeven worden?

80

Nu kan ik op de OFM zien of het een verhard fietspad is of een schelpenpad. Beide zijn rood aangegeven, het ene pad is niet gestippeld, het ander pad wel.
Helaas ben ik niet deskundig genoeg om te zien hoe de kleur zou uitpakken. maar het lijkt me moeilijk voor een kaartenmaker om een weg waarnaast een fietspad ligt en waarbij de weg getagt is als zijnde: een snelweg, een fietspad en een voetpad om dat duidelijk d.m.v. verschillende kleuren zichtbaar te maken, zpdat de gberuiker precies weet wat voor een (mooi) pad dat is.