Dit is zo oorspronkelijk ingetekend.
Doorgaans gebruik ik voor wegen in een park highway=footway; ik heb het pedestrian gelaten en er areas van gemaakt:
Maar goed dat staat los van de discussie omtrent het routeren over pedestrian areas.
Tot op een zekere hoogte is alle details en toevoegingen welkom, maar wat naar mijn mening hier fout gaat is dat de basis vergeten word, deze paden zouden we in eerste instantie taggen met een lineaire highway=footway/path. Dat je dan ook nog een area wilt taggen is prima, maar dat zie ik eerder als aanvulling dan als vervanging.
Highways als area mappen klinkt in theorie leuk maar in de praktijk werkt het niet, het is niet eenvoudig om vlakken om te zetten naar routerbare graaf. Ik vind niet dat we dat kunnen verwachten van iedere routering engine.
Ik denk dat het beter zou zijn om helemaal geen area:highway of highway=*+area te mappen, voor vlakken zou het beter zijn om het materiaal te mappen dus puur aangeven, hier is asphalt hier is paving stones etc.
Zeker omdat door de vlak naar lijn conversie, je plekken hebt waar een lijn een surface/classificatie heeft die in de 3d wereld niet die surface/classificatie heeft. Op het moment dat je dan wegvlakken van een lijn naar een vlak wilt tekenen krijg je bij de kruisingen hele rare vlakken.
Net even getest met OSRM, Valhalla en graphhopper op osm.org. Ze keizen het randje, dat is een routeerbare way. Ze steken de ped area niet over waar geen routeerbare way is.
Een router die een routerelatie kan gebruiken voor routering (OsmAnd kan dat voor wandelroutes) kan dus ook niet de routerelatie volgen als er een gebied in zit.
Een toepassing die de routerelatie als data uit osm haalt als gpx of vergelijkbaar, voor een hoogteprofiel of een routerende app, kan ook geen route over een gebied invullen, dus die heeft daar gewoon een gat.
Als we dit niet aan de OSM databasekant zouden opvangen, zou elke datauser dit zelf moeten oplossen; er is geen algemeen bruikbaar voorbeeld wat ze kunnen jatten, ik bedoel onder dankzegging overnemen, en inbouwen. Ik heb wel theoretisch oplossingen en modellen gezien die een oplossing beloven dmv een combinatie van heuristische en brute force technieken, en zelfs een stukje code wat voor een beperkt deel van de mogelijke gevallen gebruikt zou kunnen worden, maar niks wat voor algemeen gebruik ingebakken kan worden met voldoende betrouwbaarheid en snelheid.
Nou moet gezegd dat ik de ontwikkelingen niet echt op de voet volg, want ik ga ervan uit dat als er een doorbraak was dat iemand dat wel ergens vol trots even zou melden.
Tot die tijd blijft het recept: way trekken over die areas, en geen areas in routerelaties opnemen als het routeerbaar moet zijn. Als er één van de grote routeerders dit standaard inbouwt wil ik het graag testen op werkbaarheid en dan ben ik de eerste die zegt: dit kan aan de datauserkant opgelost worden, dus niet meer in de data.
Dus? Is de conclusie dat we in Nederland:
En hoe geef je dan vlakken met verschillende bestrating dan goed weer?
De wegbeheerder heeft er hier een mooi schouwspel van gemaakt; maar het is wat het is:
Ter verduidelijking, ik bedoelde dus dwars over en niet langs het randje voor die ene Nav… een ruwe krabbel, voetpad A, punt A, punt B en voetpad B met daartussen die virtuele link over het plein.
De gene die dit schreef had het over een trukendoos die erin zat. Nu dan hoe die router dat oplost als er bijv. een grote fontein of een gebouw middenop dat plein staat is vraag 65.
Volgens de wiki map je beiden, een voor de vulling, de ander voor de routing.
Wat je hier ziet is een pedestrian area die overgaat in een pedestrian street, die overgaat in een fietspad wat gekruisd wordt door een weg:
ok… maar blijf dat een lelijke oplossing vinden 
Er is een gelijkluidende discussie gaande over waterwegen die door meren gemapped worden… de Rijn die de Bodensee in gaat er doorheen en er weer uitkomt ergens bij Basel. Hier heb ik een stuw meer waarin 2 stromen en 1 rivier lopen. In September is het bijna leeg en kan je de oude beddingen zien. 3 erin, 1 eruit bij de dam.
Zelfde heb je ook in Nederland.
Gemapped als kanaal door een meer. Ik snap volledig dat je de vaarroute wilt mappen en dat moet je ook vooral doen. Maar waarom de tag waterway=canal wordt gebruikt dat snap ik niet en lijkt mij ook fout. Want het is simpelweg geen kanaal, het is alleen een vaarroute.
(Maar dit is weer een andere discussie)
Ik heb de tagging maar meteen aangepast naar waterway=fairway: Changeset: 149138488 | OpenStreetMap
Ergens in de discussie kwam de term ‘fairway’ voorbij… niet die op een golfbaan, quasi de route door een meer bijv.
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dfairway
Sommigen hebben de layer=-1 tag eraan geplakt voor rendering redenen neem ik aan. Het blijft apart natuurlijk om de waterweg namen midden in een meer de zien.
edit: slow typing… FG was sneller.
Lelijk, dat hangt van de renderaar af toch?
Deels. Je kunt het de renderer niet kwalijk nemen weer te geven wat in de database staat.
En hoewel ik het weergeven van de vaargeul / rivier / kanaal binnen een wateroppervlak nog wel iets anders vind. Zou je in het wel kunnen gebruiken om vergelijkbaar niet én een pedestrian area met een pedestrian street te combineren, maar binnen een area gewoon een footway te gebruiken voor ‘de doorgaande route’.
Ja, maar in elk geval niet zoals de routerelatie uitgezet is.
Routers doen gewoonlijk weinig tot niets met een routerelatie. Routers wilen zelf wegen vinden die van A via … naar Z gaan, en een routerelatie schrijft die wegen al precies voor. Dan krijg je de gekte dat een wandelrouterelatie eerst als gpx (=lijst punten) geëxporteerd moet worden, dan importeren in een router, die hem als een lijst via-punten beschouwt en tussen elke twee punten een route gaat zoeken. Als je geluk heb recreëert die dan precies de oorspronkelijke route. Soms ook niet, dan vindt-ie een variant (die je niet wil) toch beter.
OsmAnd kan ook anders, die kan je met wat moeite instrueren bij wandelen een hoger gewicht te geven aan wegen die lid zijn van een wandelrelatie. Maar je kan dan weer niet bepalen wélke of wat voor wandelrelatie.
OsmAnd doet dat door bij de conversie vanuit OSM naar de locale OsmAnd database (tijdens updates) het lidmaatschap van een wandelrelatie te vertalen naar een eigenschap van de weg. In het routeprofiel voor wandelen kan je aanzetten dat wegen met die eigenschap een tamelijk veel hoger gewicht moeten krijgen.
Volgens mij is dat ook de bedoeling, die moet dan ook de tag krijgen footway=link. Als ik het goed heb begrepen.
Even uit het hoofd; maar als ik het goed hebt is die link in de Wiki heel specifiek bedoelt voor op een parkeerterrein.
Wat ik dan weer een volledig onzinnige tag vond; maar ongetwijfeld ergens ter wereld zonnig zal zijn.
Je kunt in een Garmin etrex icm met de juiste instellingen en de juiste kaart een fietsroute volgen.
Bij de Openfietsmap zet je dan de instelling op Tolwegen Vermijden en routeren met motorvoertuig. Ik kies dan voor motorfiets.
Heel handig in een onbekende stad in het buitenland.
Dan moet een route wel werken over liniaire elementen.
Hoe weet-ie dan welke route je wil volgen?
