103

Dat doen we de hele tijd al. Het is alleen niet wat jij wilt horen.

Laat ik je verzekeren dat ik al je argumenten nauwkeurig lees, alle links bestudeer en me daar een oordeel over vorm. De door jou geponeerde stelling dat ‘hij bij enige tegenargumenten weigert om zich verder te verklaren’ is ronduit onjuist en zeer storend.

== om je te plezieren een ‘constructieve’ bijdrage:

Een argument dat je gebruikt is dat wegen 1 object vormen omdat ze wegbeheerder ze zo ziet en ze dus als zodanig beschreven moeten worden en dat dit het routeren makkelijker maakt. Fietspaden zijn dan een nevenfunctie.
Als je deze gedachtengang consequent doortrekt zul je ook alle auto- en snelwegen moeten aanpassen. Deze worden nu gemapt als twee afzonderlijke wegen, die vaak ook nog eens niet op de goede plek liggen: 10 meter uit elkaar terwijl de middenberm in het echt 1 meter breed is. Dat komt natuurlijk door de AND import, die voor het routeren hier afzonderlijke wegen gebruikt (*). En als je uitzoomt vallen ze lelijk over elkaar. En er moeten steeds twee bruggen/viaducten getekend waar er maar 1 is. Ik zie dit niet terug in jou tagging schema.

(*) Kennelijk hebben afzonderlijke wegen een voordeel bij het routeren … ik zie deze manier van wegen opslaan terug in alle routerings-databases: als er een fysieke barriere is worden twee wegen getekend. Google maps doet het trouwens ook zo. In die zin is het mappen van fietspaden zoals het nu gebeurt aardig in overeenstemming met de ‘professionals’. En als Ligfietser de database in zijn Garmin stopt werkt het ook. Dus er moet toch iets goeds aan zijn dacht ik zo.
Zou het misschien zo zijn dat de huidige manier van werken juist prima aansluit bij het routeerbaar maken?