Routes uit OSM gebruiken in GIS tbv wandelrouteplanner.

Bij fietsroutes zijn de forward/backward stukken essentieel. Dus die heb je in je routes nodig.
Als je een fietsroute hebt samengesteld uit rcn routes, zoals jij hebt gedaan met de Limes route, dan heb je nog een heel ander probleem, namelijk de tentakels bij gesplitste knooppunten. In Alphen aan den Rijn, heb ik dat bij knooppunt 85 opgelost door de tentakels te vervangen door een route 85-85. Anders heb je een raar zijstukje aan de fietsroute.
Ander probleem is dat ik veel rcn routes heb “rond gebreid”. Dwz als een route over 2 eenrichting fietspaden loopt en bij een knooppunt aankomt, heb ik op dat punt heen-en terugrichting doorverbonden. Als je beide stukken los laat liggen, lijkt het in een relatiewindow of de route niet compleet is.
Die tentakels zijn ook de reden, dat ik er vanaf gezien heb, LF routes uit rcn routes samen te stellen. Dat zou op zich wel kunnen, want de LF routes zijn nu voor 99% met het rcn gesynchroniseerd.
Een ander probleem zijn de Europese fietsroutes. Die zijn nu overlappend met de LF routes in OSM ingelegd en eigenlijk zouden die uit de LF routes moeten worden samengesteld, ware het niet dat er toch weer lichte afwijkingen zijn.
Bij de LF routes speelt ook nog dat men zich in OSM het gemakkelijk gemaakt heeft en maar 1 LF route heeft gemaakt ipv de a en b route, die er buiten ligt. Je kunt je afvragen hoe erg dat is, maar het is naar mijn idee wel puntje waarover moet worden nagedacht.
En dan nog de al jaren aangekondigde herziening van de LF routes. Hoe dat gaat uitwerken, is nog niet helder

Ik zou daar op dit moment geen oplossingen voor weten. Voor afbeelden op een kaartje lukt het allemaal wel, foutjes en varianten kan je gewoon zien en snappen, maar voor geautomatiseerd datause levert dit een veelvoud van problemen op, waar ik geen strukturele oplossing voor zou weten! Iets voor een werkgroep, lijkt mij. Zou ik wel aan mee willen doen als de belangrijkste LAW’s en SP’s export-proof zijn gemaakt.

Even sparren: Ik heb de Limes indeling iets gewijzigd: 1 relatie voor de hoofdroute vanaf Katwijk, en 1 relatie met de alternatieven. Dat zijn de variant startetappe vanaf Rijswijk/Voorburg, plus 3 kleinere alternatieven zoals hoogwatervarianten (elk op zich een routerelatie met een klein aantal ways) .

Nou zou ik de hoofdroute en de varianten-relatie nog weer samen kunnen voegen tot een totaal, maar heeft dat nut?

En als ik een totaalrelatie zou maken, kan ik dan niet beter daarin de hoofdroute en de afzonderlijke variantrelaties in toevoegen?

Dus 3 opties:
A. De gewone etappes => relatie Hoofroute (H);
Alle varianten => relatie Varianten (V)

B. H+V => Totaalrelatie T

C. H + losse varianten => T

H wordt tevens het NL-deel van de internationale Limes-superroute.

Nu gaan er heel veel schouders omhoog, en een paar mensen gaan heel hard denken… hoop ik.

Ik heb een paar voorbeelden genomen en gekeken hoe ik het goed kan doen. Uiteindelijk ben ik voor variant C gegaan (namen zijn voorbeelden):

  1. Losse varianten zoals aanlooptakken, hoogwatervarianten, extra wandelingen, hebben allemaal een eigen routerelatie

  2. Er is 1 hoofdroute “Blablablapad - Hoofdroute”, opgebouwd uit losse etappes. Hierbij wordt de indeling van de operator gevolgd.

  3. De hoofdroute én de losse variantenvormen samen een totaalrelatie: “Blablablapad- Alle varianten”

*Tot zover is alles nwn en met de nationale tags. *

  1. Als de hoofdroute deel uitmaakt van een internationale (super)route, is er een iwn-relatie “Euroblablablatrail part NL” met alle internationaal belangrijke en meertalige tags, en met als enige lid: de “Blablablapad - Hoofdroute” relatie.

  2. De iwn (super)route bevat voor het Nederlandse deel die ene hoofdroute maar…

6a. Als er een internationale variant via een andere Nederlandse LAW door Nederland loopt, wordt die op dezelfde manier opgebouwd en toegevoegd aan “Euroblablablatrail part NL”.

6b. Als een internationale variant géén nationaal pad is, worden de etappes van het NL deel wel eerst samen in één relatie gestopt maar dit kan gelijk allemaal iwn zijn. Daarna wordt dit als één variant toegevoegd aan “Euroblablatrail part NL”

  1. Als het nationale deel van een iwn een mengseltje is van losse delen en etappes van een aantal andere LAW’s, soms in omgekeerde richting, zoals bij het NL deel van de GR5, dan kan het soms nodig zijn om etappes te kopiëren, gesorteerd voor de omgekeerde richting, speciaal voor het NL-deel van de internationale route.

Deze aanpak zorgt er MI voor dat je op alle niveaus bruikbare gpx-tracks kan extraheren. Bruikbaar definieer ik dan als: 1 gpx-bestand met 1 volledig gesorteerde en ononderbroken track.

Kontrole en onderhoud zorgen er dan voor dat zo’n bestand gelijk bruikbaar is voor data-users.

Ik heb een paragraaf aan de wandelwiki toegevoegd, met praktische aanwijzingen.

https://wiki.openstreetmap.org/wiki/WikiProject_Nederland_Wandelroutes#Ontwikkeling%3A_datagebruikers

Ik hou me aanbevolen voor op- en aanmerkingen en aanvullingen.

Ontwikkeling: datagebruikers
In toenemende mate worden routes gebruikt als bron voor andere systemen: websites, GIS-systemen. Dit stelt hogere eisen aan de invoer in OSM. Immers, als het alleen om kaartweergave gaat maakt het niet veel uit als er onderbrekingen, verdubbelingen en sorteerfouten inzitten, maar als je een bestand wil exporteren naar een ander systeem, leveren die onvolkomenheden allemaal storingen op waar extra kontroles en bewerkingen voor nodig zijn. Door de open opzet van OSM kunnen we geen garantie geven dat routes op elk willekeurig moment geschikt zijn voor digitale dataverwerking. Maar we kunnen wel een aantal dingen doen waardoor kontrole en reparatie vóór de export makkelijker wordt.

Indeling in hoofdroute en varianten apart: maak een hoofdroute waarin een doorlopende reeks staat van deelroutes die precies kopstaart op elkaar aansluiten. Beoordeel zelf per variant of deze een eigen relatie moet krijgen (aanlooptak, gekoppelde rondwandeling) of in een relatie voor een variantenverzameling.

Sortering en richting: Zorg dat de sorteringen en richtingen van de hoofdroute allemaal dezelfde kant op gaan.

Overkoepelende relatie voor alle varianten: dit kan nuttig zijn, maar soms is het ook niet nodig.

Internationale routes: Neem alleen de hoofdroute (type=nwn) op in een relatie met type=iwn en de tags (name:nl=, symbol=, operator:NL=, symbol=,, osmc:symbol=*) zoals je die internationaal wil laten zien. Die “tussenrelatie” (iwn) voeg je dan toe aan de internationale routerelatie (iwn).

Onderbrekingen: extra takjes door verlengde, verplaatste of geknipte wegen; gaten door verwijderde wegen; in de route opgenomen area’s, losse knopen, dit alles moet gewoon in JOSM opgelost worden, zodat er 1 ononderbroken route is die in 1 gpx-bestand geëxporteerd kan worden.

Richtingen met rollen: Bij wandelingen is het heel ongebruikelijk dat de beide richtingen verschillen. Indien dit voorkomt kan meestal 1 richting vervallen. Mocht er een echt en belangrijk verschil zijn (bijvoorbeeld, een veerverbinding die heen anders is dan terug), hou dan de heenroute aan in de hoofdroute, en maak een variant voor de terugroute.

Sortering en aansluiting: Kontroleer vlak voor de export of dit goed is.

Kontrole: Een snelle methode: exporteer de gpx uit waymarkedtrails (wmt lost de hiërarchie netjes op) en lees de gpx in in bijvoorbeeld garmin Mapsource of in afstandmeten.nl. Fouten springen dan direkt in het oog.

Ik geloof niet dat dat altijd mogelijk is.
Ik heb heel weinig ervaring met routes, maar als ik kijk naar mijn enige ervaring, het klompenpad Eeskoterpad met verschillende aanlooproutes, verkortingen, verlengingen en overstaproutes, dan zie ik toch een probleem.

Je kan inderdaad niet alle details in 1 routelijn vangen, maar ook dat klompenpad heeft een hoofdroute.

Deze aanwijzingen zijn vooral bedoeld voor doorgaande wandelingen die onderdeel zijn van grotere doorgaande wandelingen. Het is erop gericht om de hele route als een gpx-track zonder onderbrekingen en verdubbelingen en volledig gesorteerd (semi)-automatisch te kunnen exporteren voor gebruik in een andere toepassing. Dus niet alleen voor weergeven maar ook voor verdere verwerking.
Zoals op deze site: https://www.longdistancepaths.eu/nl/ die de hoofdroutes van LAWen koppelt aan lijsten POI’s, OV-haltes en plaatsnamen, en je dan een routeplan met afstanden en hoogteprofiel geeft van een willekeurig beginpunt naar een willekeurig eindpunt.

Voor de klompenpaden ken ik zo’n toepassing niet, maar stel dat die er was dan zou die ook eisen stellen aan de vorm en de kwaliteit van de brongegevens.

Nou kan je natuurlijk zeggen “moeten ze maar rechtstreeks op OSM werken”, maar zo zit de wereld niet in elkaar. Ik word er heel gelukkig van als het vele werk wat in de OSM gestoken wordt, op deze manier goed gebruikt kan worden!

Voor professioneel gebruik zou nog meer nodig zijn, maar dit komt een heel eind in de richting. De knooppuntennetwerken zijn nog verder, daar zit een kwaliteitskontrolesysteem op (vmarc.be) . Helaas ken ik nog geen knooppuntrouteplanners die hier rechtstreeks gebruik van maken.

Even piepklein muggeziftertje: VMarc heet nu https://knooppuntnet.nl/nl/overview of eventueel dat overview weglaten.

Ja, ik weet dat nog steeds niet uit mijn hoofd en de oude naam wil er niet uit…

Eigenlijk blijft het een vervelende kwestie dat wandelroutes, buslijnen, spoorlijnen, e.d. aan de kaart vastgeplakt worden.
Het is natuurlijk wel makkelijk voor zij die die data gebruiken, maar ik krijg de indruk dat de meer serieuze planners en navigatie systemen die op dat gebied actief zijn, niet afhankelijk zullen willen zijn van de data van OSM waar iedereen op elk ongewenst moment de boel in de war kan sturen.
Op veel interessante wandelsites zijn de routes niet volgens de paaltjes, die je van de ene horeca-gelegenheid naar de andere voeren, maar gebruiken ze hun eigen data. Vandaag nog ontdekte ik: https://nl.bergfex.com/sommer/vorarlberg/touren/nordic-walking/45342,breitach-runde/ met een prachtige OSM achtergrond, maar de geboden wandel-informatie wordt uit geheel andere bron geput.

Trouwens eerst zal een kaart toch compleet en accuraat moeten zijn voordat we paaltjes kunnen gaan prikken
en ik geloof, dat er op dat punt nog wel het nodige aan de kaart te doen is.

Hoe bedoel je? Wie gaat er paaltjes prikken?

Sorry voor de beeldspraak.
Ik bedoelde dat als je een route uit wilt zetten op de kaart.
De wegen op die kaart aanwezig moeten zijn en op de juiste plaats moeten liggen.

Een route teken je alleen in als die werkelijk bestaat. Je moet dat in het echt kunnen zien, dus er moeten moeten voldoende markeringen zijn om van een op de weg aanwezige route te mogen spreken. Daardoor is de route aan de kaart verbonden.

Omgekeerd kan je dan konkluderen dat als de route op de weg aanwezig is, dat er een weg moet zijn. Al is het maar een spoor door een bos. Dus liggen er wegen die ingetekend kunnen worden als dat nog niet het geval is. Je hebt wel bevestiging nodig, bv met eigen ogen zien, opnames van anderen bv mapillary beelden, luchtfotomateriaal e.d.

Ik snap hoe het één en ander werkt.
Wat ik in twijfel trek is het nut van al die routerelaties die het tekenen en aanpassen van de kaart maar in de weg zitten of in ieder geval een redelijke hoeveelheid extra werk bezorgen, terwijl die gegevens door de wat serieuzere planners en en navigatiesystemen niet gebruikt worden. Althans dat laatste vermoed ik.

De OFM kaart gebruikt voor de fietsroutering bij voorkeur wegen waar een fietsroute op ligt, dus dat is al nuttig gebruik.
Verder zijn er diverse routeplanners op internet, die het fietsknooppuntnetwerk in OSM gebruiken.
Mapper multimodaal heeft vaker een link gegeven naar een routeerder, die gebruik maakt van de diverse routes in OSM; iets van brouter
De kaart Way Markedtrail toont de routes en er zullen mensen zijn, die die kaart gebruiken, alleen kun je niet weten hoeveel mensen dat zijn.
Ook zie ik dat diverse mappers en mensen aangeven dat er iets aan routes gewijzigd is, voor mij het bewijs dat er wel degelijk naar de routes gekeken wordt.
Op allerlei mogelijke manieren wordt er gebruik gemaakt van de routes. Alleen je zult niet eenvoudig kunnen vast stellen hoeveel dat gebruik is.

Inderdaad. Je kunt zelfs nog verder gaan (vermoed ik) en dat is: je kunt niet vaststellen of ze werkelijk de gegevens van OSM gebruiken of toch de gegevens uit een andere bron hebben?

Het feit dat de routerelaties binnen OSM nogal makkelijk verstoord kunnen worden, zal er toch voor zorgen dat serieuze planners misschien toch liever en andere bron gebruiken.

Terechte twijfels en bedenkingen, wat mij betreft. Toch zie ik zoveel serieus gebruik van OSM inklusief de gemarkeerde wandelroutes dat voor mij de meerwaarde overweegt. Niet voor niks biedt de ANWB alles aan met OSM als ondergrond.

Ik zie ook de worsteling bij Wandelnet om met een enorm leger vrijwilligers en een hele kleine vaste organisatie met minimaal budget de boel min of meer professioneel op te zetten. Die kunnen de hulp van het OSM-leger (mappers en wandelaars) goed gebruiken!

Daarom zet ik (in navolging van anderen en met behulp van een groeiend team en netwerk) in om voor de LAWen en SPen en een aantal themaroutes, met name waar het duidelijk is wie de aanbieder is en bij wie het routeonderhoud ligt, de wandelingen zo goed mogelijk in kaart te brengen. Kernwoorden zijn dan: volledigheid, juistheid en aktualiteit. Inderdaad, 100% garanderen kan niet, maar ten eerste kunnen “serieuze” organisates dat zelf ook niet en springt OSM er juist gunstig uit, ten tweede kun je wel degelijk een kontorle- en kwaliteitssysteem in OSM opzetten.

Foutdetektie, systematische kontrole en reparatie vind je terug bij bijvoorbeeld het hoofdwegennet, het openbaar vervoer, de wandelknooppuntennetwerken. Daar zit dan per onderwerp een ploeg OSM-ers op die zich daarvoor sterk maken en ook aandacht hebben voor voortzetting van het werk.

In de kleinere/lokale/parkgebonden wandelingen (paaltjesroutes en zo) zie ik zelf vooralsnog ook niet hoe (en waarom) je die systematisch zou moeten onderhouden, maar anderen vinden ze de moeite waard om in te voeren. Klompenpaden worden centraal aangeboden, aktueel gehouden en goed onderhouden, ik zou ze graag op OSM ondergrond zien maar zie dan zelf geen duidelijke meerwaarde om ze ook in OSM te registreren.

Beschadigde relaties
Inderdaad is het wat mij betreft een stevig probleem dat basaal kaartwerk de vele routerelaties kan beschadigen. Ik vind eigenlijk niet dat je van het volledige mapperspubliek moet eisen om met de immer toenemende hoeveelheid relaties rekening te houden: dat doet af aan het principe dat iedereen kan bijdragen: het wordt dan “iedereen die een kursusweek en een stage heeft gelopen en een diploma heeft gehaald”. Gelukkig is het zover nog niet, het is nog wel te redden met foutdetektie, begeleiding, tips en veel zelf opzoeken en uittesten, maar de trend is zichtbaar.

Ik hoop dat er een online relatie-editor komt waarmee je kan doen wat nu alleen in JOSM kan.
Ik hoop ook dat Id aangepast wordt om te zorgen dat relatiebeschadigende wijzigingen van een stevige drempel worden voorzien, dat het in ieder geval niet ongemerkt kan gebeuren. En dat niet een wijziging die eigenlijk geen beschadiging hoeft op te leveren, rücksichtlos de sortering van de relatie overhoop gooit.
En ik hoop dat het een keer gaat lukken om voor wandelroutes een kontrole- en waarschuwingssysteem ala https://www.knooppuntnet.nl/ op te zetten.

In grote lijnen ben ik het met je eens Peter.
Alleen zal het nog wel enige tijd duren voor die situaties bereikt worden.
Ondertussen zit iedere kaartmaker met de last van een groeiend aantal relaties.

Ik zou echter graag zien dat routerelaties (wandel, fiets, spoor, bus) los van de kaart zouden komen.
Technisch lijkt me dat niet onoverkomelijk.
Nu zit je bijvoorbeeld met een doorgaande weg, die vanwege diverse relaties, in allemaal kleine brokjes geknipt is. Dat is niet echt handig en overzichtelijk.

Hm… Wegen worden natuurlijk lang niet aleen vanwege routerelaties in stukken geknipt. Elke apart te taggen wijziging aan een wegdeel vergt een knip. Volgens mij heb je daar niet veel last van, routers en renderers kunnen daar gewoon mee omgaan. Volgens mij is alleen het omgekeerde een probleem: als om een “wegtechnische” reden een weg wordt opgeknipt hebben de routerelaties die eroverheengaan daar last van.

Moeten routes aan de kaart gekoppeld worden? Ja, anders ga je de meerwaarde er niet uithalen. Een lijntje over een kaartondergrond is geen bruikbare route en garandeert niet dat je eroverheen kan, dat wordt het pas als het lijntje bestaat uit werkelijke aan elkaar geknoopte wegen waarvan je de kenmerken ook ter beschikking hebt als je routeert of presenteert.
Eenvoudig voorbeeld: je kan wandelroutes weergeven met het percentage onverhard erbij, daadwerkelijk rechtstreeks afgeleid van de wegkenmerken. Sterker nog, zo’n kaart bestaat, ik heb de url alleen even niet bij de hand.

Nee, net anders om.
In mijn ogen kan elk apart wegdeel weer extra tagging verlangen. Zo ben ik al geregeld tegengekomen dat verschillende wegdelen een verschillende spelling voor de naam hanteren, om maar eens wat te noemen.

Routers en renderers hebben er geen last van, maar ik misschien wel.:slight_smile:
Ik heb weinig ervaring met relaties, dus als ik er eentje zie blijf ik er bij voorkeur van af.
Net zo goed als je als beginner ook in een grote boog om multi-polygonen heen gaat.

Ach, er zijn er verscheiden.
Deze bijv. https://www.wanderservice-schwarzwald.de