Dank voor jullie reacties! We hebben eerder gekeken om inderdaad kruisjes te plaatsen ipv die paarse stippen, maar er was een reden dat dat niet werkte (was alweer even geleden). Ik weet zo snel niet meer of dat lag aan de aangeboden opties in de rendering in dit kader of omdat het dan op mobiele telefoons niet meer goed te zien was. We hebben het dus in ieder geval in de legenda vermeld. Maar ik zal binnenkort weer eens een update draaien (netwerk is weer geactualiseerd, dode links bijwerken etc.) en zal er dan nog eens naar kijken.
In plaats van een kruisjeslijn x x x x zou je ook een plusjeslijn + + + + of een bolletjeslijn o o o o kunnen kiezen voor een gesloten route.
Mooi gedaan.
Fietsrouteplanners zouden ook eens gebruik moeten gaan maken van access:conditional. Als fietser stuit je ook nog wel eens op een afgesloten pad of een veerpont.
Bij mij kwam nog een ideetje op.
Namelijk de tagging voor honden.
Ik weet niet hoe het in het westen is, maar hier zijn nogal wat paden afgesloten voor honden. Met name paden, die door of strak langs weilanden lopen. Ook zijn er diverse paden waar honden alleen aangelijnd mogen lopen.
Zelf tag ik die dingen altijd als ik bordjes zie, die dat aanwijzen.
Maar het is het zelfde probleem als met afgesloten paden. Je wandelt fijn met Wodan en dan in eens mag je een pad niet in. Kun je een heel eind omlopen of terug gaan.
@multimodaal, blij te kunnen constateren dat er sprake is van voortschrijdend inzicht op het punt van het gebruik van de ‘name’ tag! 
Ik was van plan onze duscussies over de tagging van seizoens-sluitingen op (boeren) wandelpaden en de daarin opgenomen veerpontjes te laten rusten, maar nu je zelf dit onderwerp hier aanhaalt en daarbij zelfs mijn naam noemt, wil ik hierbij op dit forum me nog eens afvragen of hier geen sprake van tagging voor de renderer, of voor de routering (b.v. de boerengoed.com kaart, waarvoor overigens alle lof!).
Als voorbeeld de Boerenlandpaden in de Blankaardpolder & Geerpolder met daarin het trekpontje over de Ommedijkse Watering:
https://www.openstreetmap.org/#map=18/52.09683/4.48786
In het geval aangegeven moet worden dat de voetpaden en het pontje tijdens het broedseizoen zijn gesloten, dan zou het m.i. voldoende zijn om dit te doen met opening_hours. Die tag is ook gebruikt, zowel op de paden alsook op het pontje: opening_hours=Mar 15-Jun 15 off; “Gesloten tijdens broedseizoen”. Maar op de paden staat daarnaast ook nog een access:conditional en foot:conditional (met ook nog een waarschuwing voor een mogelijk onjuiste syntax) en op het pontje staat een access=permissive en access:conditional. Die ‘permissive’ op het pontje is mogelijk bedoeld om aan te geven dat je alleen met toestemming (dus alleen buiten het broedseizoen) op het pontje mag, maar dat is toch een beetje overkill omdat op het wandelpad al is aangegeven wanneer je er niet mag komen en dan is het pontje ook automatisch niet te bereiken - dus geen extra tag nodig. Blijft de vraag over het nut van de extra acess:conditional.
Bij mij blijft bij dit alles toch hangen dat de (combinaties van) de access:conditional tags bovenop de opening_hours voor het beoogde doel “Gesloten tijdens het broedseizoen” niet nodig zijn. Gebruik je ze toch, dan ben je bezig met tagging om tekortkomingen van bestaande renderers en/of routeerders te compenseren. Boodschap: maak een renderer en/of een routeerder die dit wel kan. Misschien weet iemand wel een slimme programmeur die dit zou kunnen?
Ik gooi dit balletje hier op, niet uit rancune of ‘mijn gelijk willen halen’, maar uit nieuwsgierigheid of ik er nou helemaal naast zit of niet.
edit: typo
Ik probeer toegankelijkheid voor honden inderdaad ook zo goed mogelijk te taggen conform https://wiki.openstreetmap.org/wiki/Proposed_features/Key:Dog . Dat kan zowel fijn zijn voor mensen die met de hond willen lopen als voor mensen die loslopende honden willen vermijden.
Ik kan wel kijken of ik daar in de komen de tijd iets mee kan in een kaartje, misschien met een variant op een van de interactieve kaarten op openstreetmap.nl zoals http://mijndev.openstreetmap.nl/~ligfietser/fiets/
Een van de leukste ontdekkingen van de wandelkaart vond ik zelf dat je, ondanks het geringe aantal wandelpaden in het gebied toch een ns-marathonwandeling kan maken die bijna alleen maar over wandelpaden gaat (de betreffedne paden vind je elders niet in een bron bij elkaar, alleen op osm):
Het noemen van je naam was bedoeld als bedankje (anders had ik hier niet zo veel geleerd over mappen), maar als ik had geweten dat het zou leiden tot het heropenen van deze discussie dan had ik het niet gedaan, was erg blij dat die na een paar lange mailwisselingen tussen ons (en ook met hulp van Ligfietser) was afgerond.
Om niet alles opnieuw te hoeven doen een paar quotes met toelichting uit eerdere mails:
December 2016
Augustus 2017
Mogen we dit alsjeblieft laten rusten?
–
edit: data
Je kunnen zeggen: access:conditional is voor de situatie als je er wel kan komen, maar het mag niet. In heel veel natuurgebieden is het niet toe gestaan om er 's nachts te zijn. Het kan wel, maar het mag niet.
Buiten de opening tijden van een winkel kan je er gewoon niet naar binnen. Het zou ook raar zijn om op een winkel een access:conditional te zetten. Zou wel weer kunnen op een winkelcentrum waar je wel in kan, maar dat dan niet mag.
Dus bij dat pontje, als ie aan de ketting ligt, zou je kunnen zeggen opening_hours. Als je de pont wel kan gebruiken, maar het mag niet, dan is denk ik access:conditional de meest logische oplossing.
@multimodaal: misschien heeft deze discussie zich veel te lang bilateraal afgespeeld via PB’s en mail en had wat mij betreft beter van begin afaan op het forum kunnen plaatsvinden. Het lijkt nu persoonlijk, maar dat is het wat mij betreft niet en als het zo voelt, excuses daarvoor.
Algemeen.
Laten we het eens omdraaien. Als je ervan uitgaat dat de tags ‘access’ en access:conditional’ beter geschikt zijn om aan te geven wat wel en niet mag en wat wel en niet kan (gesloten hek, pont aan de ketting, deuren van een passage in een winkelcentrum gesloten, etc.) - snap ik best - en je de access:conditional tag ook gebruikt om periodieke toegankelijkheid aan te geven, zoals bijvoorbeeld “Gesloten tussen zonsondergang en zonsopgang” of gesloten in een bepaalde periode, dan vraag ik me af wat de toegevoegde waarde is als met de tag ‘opening_hours’ nogmaals dezelfde restricties worden aangegeven.
Voor mij lijkt dat dubbel en derhalve overbodig, maar misschien kan iemand mij uitleggen waarom het correct is om die twee tags gezamenlijk te gebruiken. Daar wringt bij mij dus de schoen.
Dus (te?) kort samenvattend zoals mij dan logisch lijkt:
- als toegang of gebruik fysiek onmogelijk is gemaakt met hek / toegangsdeur op slot, pont aan de ketting, etc., dan gebruik je ‘opening_hours’ voor tijden en periodes en eventueel access tags voor zaken als private, permissive, etc., maar niet voor dezelfde tijden en periodes.
- als toegang niet mag, maar wel kan, dan gebruik je access:conditional voor de tijden en periodes en eventueel access voor overige zaken, maar dan ook niet nog eens opening_hours om dezelfde tijden en periodes aan te geven.
En als er consensus lijkt te bestaan voor het gebruik van de combi ‘access’ en ‘opening_hours’ zoals in mijn aangehaalde voorbeeld van de wandelpaden bij Stompwijk, of juist niet combineren als het gaat om het aangeven van dezelfde tijd/periode restricties, zouden we dat dan niet moeten toepassen voor alle wegen en paden, dus ook fietspaden, de bos paden/wegen van Natuurmonumenten, etc. en vooral ook de Wiki aanpassen?
Jullie visie hierop wordt zeer op prijs gesteld, ook als ik het allemaal bij het verkeerde eind heb en/of het niet blijk te snappen.
Beste BikePC, dank voor je toelichting, die valt hier heel wat beter dan het bericht van gisteravond.
Wat me wel van het hart moet over de context:
-de hele kwestie van access + opening_hours IS al besproken op het forum: https://forum.openstreetmap.org/viewtopic.php?pid=567377#p567377
-deze oplossing (niet van mij) kwam van een van de meest ervaren en scherpe mappers en renderers op het forum
-niet alleen wij hebben hier uitgebreid over gemaild (heb mijn best gedaan om je vragen te beantwoorden met zo goed mogelijke inhoudelijke argumenten zonder dat er veel inhoudelijk tegenwerpingen kwamen), maar je hebt ook aan een Ligfietser (eveneens zeer ervaren) voorgelegd, die eveneens bevestigde dat de tagging correct was
-wat me wel in het verkeerde keelgat schoot was de eerdere suggesties
en gister:
Dat vooral omdat de hele aanleiding van deze langslepende kwestie nu juist een renderingswens aan jouw kant is:
de weergave van dit pontje in Basecamp/Mapsource in combinatie met de OFM staat je niet aan (lange tekststrings, rode bolletjes), en daarom het verzoek om de tagging aan te passen.
Zowel Ligfietser als ik hebben je aangeraden om -als dat je niet aanstaat- een andere weergaveprogmamma te gebruiken of een andere OSM-kaart te hanteren in je Garmin-programma. Mijn initiële tagging is aangepast door ervaren formumleden hebben gedaan nav de dicussie (en die heb ik ook elders weer toegepast) en vervolgens heb ik -met veel hulp- een renderer gemaakt die daarmee werkt. Dan is het wel raar als je vervolgens te horen krijgt dat je maar in een eigen hoekje moet terugkruipen of weer een andere renderer moet maken die wel iets kan.
Ik en benieuwd: ben je zelf nog aan de slag gegaan met de mogelijkheid op zelf een kaart te maken met mkg-map om iets te krijgen dat we aan jouw renderingswensen voldoet? Of heb je een andere OSM-kaart gevonden die beter bevalt op dit punt?
Dat zou ik veel leuker vinden om hier te bespreken (ik zou dat ook wel willen doen als ik tijd had) dan om die oude discussie weer te gaan herkauwen.
Ik ben gaan mappen omdat ik wil bijdragen aan het maken van leuke en nuttige dingen en kom hier op het forum om te leren en proberen elkaar vooruit te helpen vanuit onze specifieke ervaringen / expertise. Te vaak merk ik echter dat ik hier het gevoel heb dat het eerder gaat om afbreken van andermans werk of blijven hangen in kritiek / discussie zonder dat dat tot iets leidt.
Dat was juist een van de redenen dat ik dit draadje startte, om te delen dat er uit een oude discussie iets leuks was gekomen dat wellicht ook voor anderen nuttig kan zijn. Daarom vond ik het des te vervelender dat het weer een stap terug leek, maar misschien had ik een andere titel moeten kiezen.
Maar aan de andere kant moet ik toegeven dat de wiki best behulpzamer zou kunnen zijn en in je mail van vandaag zie ik ook wel zeker wat opbouwends. Dus toch maar…
De optie in de post van vandaag (aanvliegen vanuit access en afvragen of opening nodig is) lijkt me een veel beter vertrekpunt dan het overwegen om access te gaan verwijderen. Access is immers een van de kernbegrippen/ingangen bij routeren.
Bij een winkel is opening een logische ingang als attribuut van het element, maar daar routeer je niet op. Hier gaat het juist steeds over verbindingen, en daarvoor is access je ingang.
Als er *per se * een tag zou moeten verdwijnen, dan wat mij betreft veel liever de opening_hours verwijderen dan access, anders sloop je echt de informatie eruit die veruit de meeste mensen en informatiegebruikers zullen zoeken als ze willen weten of ze ergens mogen komen. Er is immers niet voor niets een access:conditional variant op access gemaakt.
Met een schaartje proberen te knippen waar toegang op een pad/ferry niet kan en waar het niet mag en aan de hand daarvan OF in access OF in opening_hours zetten lijkt me het paard achter de wagen spannen: dan is met maar afwachten waar je je data kan vinden, er zijn veel twijfelgevallen (wanneer is een hek een overstapje of barriere, of onbekend: je moet na sluiting gaan kijken wat er gebeurt…).
En bovendien: het gaat hier doorgaans niet om openbare gelegenheden: als je er niet in *kan * omdat er een hek staat, dan *mag * het daardoor ook niet (overtreding BW). Het niet mogen kan dus voortkomen uit het niet kunnen, uit een bord of uit beide. Dus niet iets waardoor je zou moeten willen besluiten om uit een van de twee categorieën data weg te gooien
Bovenstaande geldt wat mij betreft zowel voor de paden als de pontjes, want het gaat access is een van de variabelen “to use in combination” bij route=ferry: https://wiki.openstreetmap.org/wiki/Tag:route%3Dferry
Alleen dan kom je wel op een praktisch punt: veel bedieningstijden van veerponten zijn (alleen) met opening_hours aangegeven. Ik zou zelf die data daar niet weghalen om het te verplaatsen naar access, hoewel toevoegen van access me wel zinvol lijkt, zoals op sommige plekken ook gebeurt.
Dat is misschien voor een groot deel dubbelop, maar de vraag is wat hier uiteindelijk te erger is:
een paar extra bytes voor een tag die misschien niet zo heel veel toevoegt ten opzichte van een een reeds aanwezige wellicht dubbele tags of een situatie waarin mensen of andere datagebruikers niet vinden wat ze zoeken.
Juist omdat de OSM-categoriën niet perfect zijn en vaak ook moeilijk passend zijn te krijgen op de grillige buitenwereld (en onze regelgeving) zou ik een niet al te star/principieel willen zijn en vooral kijken wat -binnen de grenzen van het redelijke- tot het meest praktische resultaat leidt. Of zoals een DWG-lid schreef toen ik eerder -in algemene zin- vroeg of ze een misschien standpunt hebben met betrekking tot “needless-tagging”: “Adding a few unnecessary foot=yes just to make things extra clear doesn’t hurt anyone”
opening_hours hoort niet op een highway en nodes in de highway.
https://wiki.openstreetmap.org/wiki/Conditional_restrictions
De toegang tagging wordt afgeleid van traffc_sign en access_sign borden en mogelijk fysieke beperkingen. De basis.
De borden, daar staan vooral beperkingen/verboden op.
Dit wat anders dan een bordje met openingstijden. Een informatief bord.
Het access wordt er mee geregeld (zie link)
met
The general syntax of the tag is as follows (fields in square brackets […] are optional):
<restriction-type>[:<transportation mode>][:<direction>]:conditional
= <restriction-value> @ <condition>[;<restriction-value> @ <condition>]
is dan de toegang access
access:motorcar= mag dan ook als motorcar= gebruikt worden, zie link.
Zo zijn er gebieden/wegen, waar de eigenaar, zonder aankondigen het kan sluiten, een slot aan kan hangen, dan permissive.
Wanneer per bord een verbod/gebod wordt kenbaar gemaakt voor een bepaalde tijd is het :conditional, bijvoorbeeld verboden van zonsondergang en zonsopgang.
[:]: het verbod kan ook gelden van 1 kant dan op plaats van direction forward backward gebruiken. zie link
Nodes in een highway kunnen barriers zijn en daar horen toegang tags op, access tags, access:bicycle=, wat voluit geschreven zou kunnen worden volgens general syntax, maar ook bicycle= is voldoende. (korte versie, volop in gebruik)
De enige overeenkomst met openingstijden is het gebruik van de syntax van de tijden. En daar ontstaat waarschijnlijk de verwarring.
Men ziet de tijden syntax, ohh, dan zal het wel opening_hours zijn.
Een mooie kaart, mijn complimente!
Duidelijk en met de optie van de extra informatie (streekinfo).
De sluitingen m.b.t. het broedseizoen zijn zinvol.
Een evt. toevoeging op een wandelkaart dat wandelpaden gesloten zijn tussen zonsondergang en zonsopgang vind ik zelf minder zinvol. Het maakt de kaart druk en de meeste mensen gaan in het donker het bos niet in (of laten zich niet tegenhouden door een verbod).
Er zijn 2 elementen die ik hier zo snel niet zie maar wel waardeer van wandelkaarten: zitbanken/picknicktafels en laarzenpaden.
Laarzenpaden staan ingetekend op wandelkaarten om aan te geven dat je er beter niet met lage schoenen gaat lopen.
In de praktijk zijn laarzenpaden meestal paden langs sloten waar je meer last van de begroeing hebt dan van modder (behalve als de sloot pas gemaaid is)
Of er trouwens een tag in osm voor een laarzenpad bestaat weet ik niet.
Ik heb dat geinterpreteerd als goedkeuring van technisch kennelijk correcte tagging, maar dat wil niet zeggen dat het voortaan alleen zo moet en mag.
De Wiki is hierin ook niet eenduidig en al eerder en elders op dit forum wordt steeds gerefereerd aan de problematiek rond het voor OSM correct taggen van wat op de grond bestaat. Een 100% match is een utopie. Dat de diverse mappers hier verschillend tegenaan kijken en verschillend interpreteren en dus verschillend taggen is voor mij daarom evident. Je hoeft en kan het niet altijd met elkaar eens zijn.
Ik heb geen enkele tag van jou verwijderd hoor, alleen gepoogd zaken ter discussie te stellen - de manier waarop, daar mag je je eigen gedachten over hebben. Inderdaad is de discussie begonnen over het oneigenlijke gebruik van de name-tag en later over een m.i. onnnodige combinatie en overvloed van tags, alleen om duidelijk te maken dat er sprake is van seizoensgebonden toegangsbeperkingen op een wandelpad waar toevallig ook nog zo’n schattig trekpontje in zit.
Gevoelsmatig (en nu blijkt niet goed geinformeerd) zou ik alleen de tag ‘opening_hours’ gebruiken om b.v. “Gesloten tijdens het broedseizoen” aan te geven, maar de verwijzing van Allroads naar de Wiki [link]https://wiki.openstreetmap.org/wiki/Conditional_restrictions[/link] brengt me op andere gedachten. Daar wordt aangegeven dat opening_hours op nodes moet staan en niet op wegen. Dus concluderend na alle discussies en bijdragen van de andere mappers in dit draadje voortaan ‘access:conditional’ gebruiken om openingstijden van paden en pontjes aan te geven. Dus dan toch liever acess…
Mijn insteek bij het mappen is ‘lean and mean’ - alleen aangeven wat minimaal nodig is om aan te geven hoe, voor wie en wanneer een weg bedoeld is, eventueel aangevuld met zaken als wie de beheerder is, etc…
Aan de andere kant kun je natuurlijk nastreven om alle nodige en mogelijke tags aan te brengen op alle wegdelen om een bijna perfecte match van tags op OSM te hebben met wat er in het veld op elk moment in alle omstandigheden voor alle soorten gebruikers geldt en eventueel ter plaatse is aangegeven met verkeersborden en/of informatieborden, etc… Verschillende mensen, verschillende benaderingen.
En dan nog een (voor mij essentieel) punt. Stel dat het zou lukken om een bijna perfecte match tussen de tagging op OSM en de grillige buitenwereld te realiseren, wat heb je daar dan aan als de huidig beschikbare GPS navigatietoestellen en de daarin geimplementeerde routeringsalgoritmes helemaal geen raad weten met al die fijne nuances die op de wegen, etc. zijn aangebracht? De beschikbare routeringsopties op die toestellen zijn veel beperkter. Denk aan vermijden van snelwegen, tolwegen, veerponten, onverharde wegen, routeberekening voor kortste weg of snelste tijd en een enkel model kan hoogtemeters beperken en dan houdt het wel zo’n beetje op. Maar een toestel dat een route kan berekenen en daarbij rekening houdt met openings-tijden en de vaartijden van een pontveer ken ik niet. Prima, dan omzeil ik dat toch door eerst online op een fraai geprogrammeerde kaart die daar allemaal wel reking mee houdt een route te maken en deze te exporteren naar mijn gps-toestel… En wat gebeurt er dan? Het toestel krijgt alleen een lijst van startpunt, tussen- (via-)punten en eindpunt en gaat vervolgens altijd een route berekenen aan de hand van de wegen/paden die beschikbaar zijn op de in dat toestel geladen kaart aan de hand van de beschikbare routeringsparameters. Bijna 100% zeker dat er dan een andere route op het toestel staat dan die gemaakt werd op de online kaart…
Alternatief is om online op genoemde slimme kaart die wel om kan gaan met openingetijden, etc. een route te bepalen, deze te converteren naar een track (kruimelspoor) en deze op het GPS-toestel te zetten. Een track is niet gebonden aan de kaart - een algemene OSM-kaart op het toestel is in principe voldoende - en je kunt op weg. Enige nadeel is dat je met een track geen afslagaanwijzingen krijgt, maar ik denk dat wandelaars daar minder behoefte aan hebben dan b.v. fietsers. Een papieren kaart is vaak ook zeer bruikbaar en zeker als dit een afdruk is van die slimme online wandelkaart met daarop getekend de af te leggen wandelroute. En het leuke is dan dat je in het broedseizoen een heel andere route van de Dokter van Noortstraat (Stompwijk) naar 't Geertje loopt dan daar buiten.
Edit: nu stop ik maar met dit draadje
Even hier op inhaken. Oudere Garmins piepen wel als je een track volgt. Om hetzelfde effect te krijgen op een nieuwere Garmin zet een track om naar een route met max. 250 punten. Dan piept ie te vaak, maar in ieder geval ook als ik af moet slaan
Heb de afgelopen dagen gewerkt aan een projectje dat al te lang stil lag: een kleine website om een paar eigen kaartjes te kunnen publiceren en wat links te verzamelen naar handige kaarten / tools / info van anderen.
Heb daarbij ook dankbaar voortgebouwd op de erg handige en krachtige overpass-kaart die @Noordfiets, @PeeWee32 and @ligfietser hebben ontwikkeld (origineel op http://mijndev.openstreetmap.nl/~ligfietser/fiets/ , broncode te downloaden via https://github.com/ligfietser/Bicycle_Tags_Map )
Heb een Hiking-variant gemaakt op de fietskaart, en daarbij ook access voor dogs meegenomen (de overkoepelende categorie “pets” nog niet. Hier gecentreerd rond Deventer:
Het lukt me nog niet om areas te laten zien, zal een vraag daarover plaatsen in het draadje over dit framework.
Het oorspronkelijke doel wat ik met dit kaartje voor ogen had was het kunnen opsporen van verschillen tussen LAW’s/ Streekpaden van Wandelnet in PDOK en de NWN’s in OSM, zodat we (a) OSM hier kunnen verbeteren of (b) wandelnet met een simpele url kunnen wijizgen op locaties waar hun data verbeterd kan worden (ook omdat ze zo vriendelijk zijn dat we hun NWN data en de RWN-data van wandelen123.nl mogen overnemen in OSM)
Vergelijking NWN WandelNet / OSM:
http://www.openkaart.net/wandel/hiking-tags/?map=route&zoom=13&lat=52.28241&lon=6.19603&layers=000B00FTFFFFFFFFTT
ps. Ik ben geen programmeur en moet woekeren met tijd (het duurt nog wel even voordat ik met pensioen kan ;-), zowel in code/werking van de website als in de aanpassingen aan het kaartje zullen programmeurs genoeg vinden wat afgrijzen zal wekken, mijn excuus alvast 
Helaas heb ik ook niet veel tijd om uitgebreid in te gaan in verzoekjes voor de website, maar mocht ik een tip krijgen over een site / renderingsmethode die ik ook interessant vindt, dan kan ik niet uitsluiten dat die erop komt 
edit: NWN-kaart toegevoegd
Dank je, Jan!
De sluiting van zonsondergang tot zonsopgang heb ik hier inderdaad maar niet toegevoegd. Bne het eens met je praktische argument en daarnaast zou de access:conditional tagging nog complexer maken dan die al is (het zijn helaas paden die zich lastig in het keurslijf van OSM laten passen 
De bankjes hebben we niet apart weergegeven, de overweging was dat die in de basiskaart bij een bepaald zoomniveau vanzelf oppoppen (net als bijvoorbeeld molens) en we probeerden het aantal vinkjes te beperken, ook met het beoogde gebruik op mobiele telefoon icm plaatsbepaling (kaart bedoeld voor zo breed mogelijk publiek, niet alleen gps-nerds zoals ikzelf ) .
Die laarzenpaden is wel een goede, ja. Ik weet toevallig dat zo’n beetje alle echte wandelpaden hier buiten de droge periode in de zomer laarzenpaden zijn, maar in OSM ben ik nog niet verder gekomen dan surface=grass.
surface:conditional met “grass” in summer en “bog” in fall-atumn zou misschien accuraat zijn, maar zou de tagging nog moeilijker maken dan ie al is.
Smoothness=bad zou nog wel in de buurt komen, daarbij mag je ook wel nattigheid verwachten icm grass in bij slecht weer of heeft iemand een betere suggestie?
Smoothness is gebaseerd op voor welk voertuig een weg/pad nog wel geschikt is.
‘bad’ is gedefineerd is als ‘(robust_wheels) trekking bike, normal cars, Rickshaw and all below’
Als het erg nat is dan lopen een toerfiets of een auto misschien vast.
‘very_bad’ is ‘(high_clearance) Car with high clearance, light-duty off road vehicles’
Dus die misschien meer geschikt voor een nat pad.
Impliciet blijft dan als fiets alleen de MTB over (die doet mee tot ‘very_horrible’ )
Net als bij fietsen kunnen we wandelaars misschien onderverdelen aan de hand van het soort rubber ze hebben ondergebonden (-:
Al lijkt het veenweidelandschap zo ruig dat zelfs de lokale mountainbikers klagen over de blubber en slecht onderhoud en we misschien een categorie fatbikes moeten gaan onderscheiden (-;
http://www.mtbroutes.nl/route/806/Leiden
Over het eerder in de discussie genoemde routeren via Garmin gps danwel Mapsource/Basecamp (en hoe die geen rekening houden met veel van de informatie de we met zoveel liefde en moeite in de database stoppen):
Ik heb al zo’n twintig jaar zo’n allergie voor de manier waarop Garmin computerprogramma’s kaarten weergeven (op de gps valt het gelukkig mee…), dat ik heel wat duizenden trackpoints handmatig heb aangeklikt in Ozi om gpx’jes te maken…
Tegenwoordig hoeft dat gelukkig niet meer met allerlei fijne osm-routers, zoals deze die ik persoonlijk erg fijn vindt:
http://brouter.de/brouter-web/
(verschillende fietsprofielen, wandelprofiel, zelfs een “river” voor varen.
Ben benieuwd naar jullie favorieten
Die routes kan je ook maken met een andere kaart ernaast, zoals een kaart die osm-tags naar believen weergeeft, zodat je de specifieke osm-data toch kan gebruiken in de gpx die je maakt. Vindt het persoonlijk ook fijn dat je de route naar je gps sturut “as-is”, anders is het maar afwachten of je gps er met herrouteren misschien iets anders van maakt zonder dat je het weet.
Met wandelen (als recreatie) gebruik ik nooit een route, altijd een track (op een garmin outdoor gps).
Soms maak ik de track handmatig, soms gebruik ik een knooppunten routeplanner (op de routebureau limburg website).
Als ik ergens naar toe loop (bv. in een stad) gebruik ik maps.me op de smartphone. Dan wil ik de kortste weg nemen.
Deze vind ik wat soepeler in het gebruik dan osmand.
Luie mountainbikers. Willen natuurlijk een perfect aangeharkt gazon.
Ik heb ook een hekel aan basecamp. Maar ik gebruik mkgmap om met routering te spelen. Dus dan moet ik wel basecamp gebruiken. Of er moet een goed open source programma zijn dat garmin image formaat snapt.