Ik krijg veel foutmeldingen in JOSM dat wandelroutes over een weg lopen met foot=use_sidepath.
Volgens de wiki zou dat moeten betekenen dat er een verplicht apart voetpad moet zijn ingetekend, maar in veel gevallen is dat niet gebeurd.
Dan lijkt de tag te zijn gebruikt als: er is een trottoir.
In feite betekent het als access tag dan niks, want een (kleinere) weg zonder foot=* tag kan gewoon belopen worden. Dat je dan op de stoep moet lopen tag je niet, dat is alleen een verkeersregel. Toch?
Het betekent hetzelfde als bij bicycle=use_sidepath, dus je mag niet op deze way lopen maar op het parallelle voet- of fietspad dat als aparte way is ingetekend. Als er geen aparte way is, dan klopt de tag niet en zou de tag sidewalk=* gebruikt moeten zijn om aan te geven dat er een stoep is.
Veel wandelroutes lopen nog over de hoofdrijbaan… net als sommige fietsroutes. Vaak zijn er wel een apart fietspaden ingetekend.
Dan is het weer een hele klus om die routes te verleggen. Mijn advies zou dan zijn om foot en bicycle=use_sidepath tijdelijk te verwijderen tot de routes zijn verlegd.
edit Hier dus zo’n goed bedoelde actie om bicycle=use toe te voegen met als resultaat dat de routering op de relatie niet meer werkt.
In eerste instantie bicycle=use_sidepath weer verwijderd en toen ik tijd had de routes in 2de instantie verlegd.
https://www.openstreetmap.org/changeset/114718907#map=17/51.47569/5.14206&layers=C
Het lijkt mij juist goed om bicycle/foot=use_sidepath toe te voegen aan wegen met een fiets - of wandelroute, wanneer die over een naastgelegen fiets- of voetpad zou moeten lopen. Op die manier komen dat soort routes in de foutcontrole en kan de route verlegd worden.
Als je goed met routerelaties bent, dan kun je de route natuurlijk ook meteen zelf verleggen.
Zo zie ik het ook. De waarschuwing in de tools is dan prima op zijn plaats, terwijl de route gewoon ‘werkt’ (niet voor routers, maar wel voor gerenderde kaarten met wandelroutes). Als je wel van A naar B langs die weg routeert, dan wordt je netjes over het parallelle pad geroutereerd. Dat wijkt dan ietsjes af van de ingetekende routerelatie.
Als er geen parallel pad is ingetekend mag foot=use_sidepath wel weg natuurlijk.
Kom je dit in een bepaalde regio veel tegen?
Wat ook nog wel eens voorkomt is dat bicycle=use_sidepath wordt toegevoegd terwijl het naastliggende fietspad een G13bord heeft.
Dan haal ik die tag weg en laat de fietsroute gewoon over de hoofdrijbaan lopen.
Enige wat mij met routes niet goed afgaat is het forward en backward gedeelte met fietspaden links en rechts van de hoofdweg.
Heeft iemand misschien een uitleg ergens liggen/linkje beschikbaar?
Er zijn twee dingen die ik vaak fout zie gaan:
Verkeerde interpretatie van forward en backward als heenweg en terugweg. De correcte betekenis is forward: route loopt in de richting van de way, backward: route loopt tegen de richting van de way in. De rol forward komt dus het meeste voor, eenrichtingsfietspaden hebben eigenlijk altijd de rol forward. Backward komt vooral voor bij zijwegen op een kruising, waar de route al gesplitst is in een heen- en terugweg, maar nog niet op de eenrichtingsfietspaden zit.
De terugweg is verkeerd om gesorteerd. De terugweg kun je volgen door in het relatiebewerkingsvenster van onder naar boven te gaan. Van boven naar onder ga je dus tegen de route in, ook op de gesplitste stukken.
Dit is een voorbeeld van een route met een splitsing en zowel forward als backward rollen.
PS. Ik zie de heenweg als de routelijn van boven naar onder en de terugweg als de routelijn van onder naar boven.
De bicycle=use_sidepath is dan inderdaad niet nodig, maar de route zou ik wel over de G13 doen als dat makkelijk kan. Voor fietsers is het doorgaans de voorkeursroute (recreatief zeker), en routebeheerders maken daar vaak ook gebruik van.
Ook handig om te onthouden: bij conventie gaat de volgorde in Nederland als het goed is dat altijd van het lagere knooppuntnummer naar het hogere. Dus als je van een 81 naar een 25 routeert volg je de relatie van onder naar boven.
@Jeroen… Vaak twijfel ik om het aan te passen richting G13 fietspad. Wat je nogal eens ziet is dat de routebebording de hoofdrijbaan volgt en niet het fietspad.
Dan is het prima natuurlijk.
Ik let vooral op lopen en wandelroetes. Voor wandelen is er geen rechtshoudregel, en wandelroetes geven dus meestal niet de kant van de weg, dat zoekt de loper wel zelf uit wat-ie wil en wat er kan of moet. Bij fietsen is dat veel strakker.
Bij wandelen op kaart maakt het ook niet uit. Maar bij navigeren op gpx wel, en de ontwikkeling gaat voor wandelen dezelfde kant op als voor fietsen. Steeds meer wandelapps bouwen navigatie en stembegeleiding in.
Dat betekent wel dat ik in de wandelroetes niet wil kiezen aan welke kant de wandelaar wandelt, want dat ligt niet vast; het wordt aan de wandelaar/router/navigatie overgelaten. De markering zegt niks, die kan rechts, links, in het midden of afwisselend zitten, als je hem maar kan zien. Hij wijst de richting maar meestal niet de zijde van de weg, dat mag je zelf weten.
Maar ik begrijp dat we het eens zijn over de tag. Het side path moet wel gemapt zijn, zo niet dan sidewalk=yes|left|right|both gebruiken.
Bij wegen waar beide voetpaden los liggen (of fietspaden of ventwegen) moet je toch een keuze maken. Over de hoofdweg is dan wat vreemd omdat je er niet mag lopen, ook al gebruik je het als een manier om een kant kiezen te voorkomen. Als de routebeheerder GPS-traces toont op hun eigen website (Marrekrite doet dat bijvoorbeeld) dan kun je de kant kiezen die de beheerder zelf gelopen heeft.
Als dat niet duidelijk is en de bordjes geven geen uitsluitsel, dan kies ik zelf de kant die het fijnst loopt. Vaak is dat ook de meest logische kant wanneer onnodig oversteken vermeden wordt.
Individuele wandelaars kunnen zelf immers altijd alsnog de andere kant kiezen ter plekke. Door een kant in te tekenen kies je dus niet voor de wandelaar per se waar deze loopt; je geeft enkel één van de valide routes aan.
In Duitsland (is?)was een mapper actief die doorlopend bicycle=use_sidepath toevoegde aan de wegen terwijl er geen fietspaden los waren ingetekend.
Wel cycleway=track Dat geeft dan natuurlijk het effect van een aanliggend parallelfietspad op sommige fietskaarten. o.a. de OFM.
Maar die fietspaden staan dan wel op slot door de toegevoegde tag use_sidepath!
Deze mapper was van het type ‘Ik heb altijd gelijk’ en met mijn argumenten had hij niets te maken. Iedereen zoekt het maar uit en zeker de ‘router’. Mapper was niet bereid om verder van gedachten te wisselen.
Dat is niet verplicht, dus als je erop wil vertrouwen bij het aanpassen van knooppuntroutes, dan moet je het zelf wel kontroleren en ev omsorteren. Voor andere routes is er geen conventionele volgorde. Dus als je het wil leren dan kan je beter niet op een zichtbare volgorde rekenen!
Ik doe (met dank aan Dick) altijd eerst de heenweg, vanaf het splitspunt tot aan het samenkomstpunt. Dan daar de juiste rollen aangeven. In JOSM relatiebewerker => continuïteitslijn: Pijltje omlaag krijgt forward (want met de rijrichting mee), pijltje omhoog krijgt backward (want tegen de rijrichting in), en dan hoort het een mooi aansluitend lijntje links van het midden te worden, aansluitend aan het splitspunt. Met rechts van het midden het onderbroken lijntje waar je de terugrichting moet denken.
Dan zet ik de kaart weer op het splitspunt en voeg alle wegen van de terugweg in, vanaf het splitspunt tot het smeltpunt. Dus die keten komt in die volgorde onder de heenweg te staan. Dan daar de rollen aan geven: pijltje omhoog krijgt forward (want met de terugweg-rijrichting mee), pijltje omlaag krijgt backward (want tegen de rijrichting in).
En dan hoort die terugwegketen een mooi aansluitend lijntje rechts van het midden te worden, met links van het midden de onderbroken streep waar je de heenrichting moet denken.
Om eerlijk te zijn zit ik hier nog steeds vaak mee te knoeien, vooral als de heenrichting op de kaart omhoog loopt! Want dan is het precies tegen mijn intuïtie in om het in de relatiebewerker andersom te zien.
Het is wel fijn (met dank aan Jeroen) dat JOSM het nu meestal goed kan sorteren, als je de juiste rollen hebt gebruikt. Zelfs als de complete route gespitst is, dus geen enkele gezamenlijke way. Alleen als bijvoorbeeld een stuk weg zowel op de heenweg als op de terugweg in dezelfde richting bereden wordt (ja ja, dat komt echt voor!) dan lukt het niet.
Het toekennen/controleren van de rollen is eigelijk heel simpel, als je naar de relatiebewerker kijkt, de kleine pijltjes in de continuïteitslijn.
Maar dat zijn precies de situaties waar de markeerder ook een keuze moet maken, meestal is het duidelijk genoeg, al zit ik er soms toch naast in mijn meest waarschijnlijke keuze. Voor routewandelaars heel gemakkelijk oplosbaar, en meestal hoor ik het later wel een keer of heeft iemand het na survey even verbeterd.
Aan kaartjes op wandelwebsites heb je meestal niet veel, die zetten zulle dikke strepen dat er een kanaal met aan weerszijden een snelweg en een spoorlijn inpast, en als download geven ze een oorspronkelijke verkenningstrack met smartfoonkwaliteit, waar je de sanitaire pauzes nog in kan zien. Maar eerlijk is eerlijk, er zit verbetering in. Langzaam, maar toch.
Ongebrijpelijk. cycleway=track is toch genoeg, het zegt waar fietsers moeten rijden, daar hoef je niet nóg een aanwijzing aan toe te voegen waar fietsers moeten rijden.
Los daarvan vind ik cycleway=track een rare tag, omdat hij niet op een cycleway staat. Je zou een variant op bicycle=lane verwachten. Het enige verschil is toch dat er een iets duidelijker scheiding is?
highway=cycleway + cycleway= zou ik logischer vinden, als typeringstag voor een cycleway dus.
@Peter, bedankt. Eerst het gezamenlijke stuk doen. Slim.
Gebruik je voor de terugweg hetzelfde splitspunt als op de heenweg, of z’n “eigen” splitspunt?
Nou, dat is per definitie zo, denk ik.
Op de heenweg heb je een splitspunt A en later een samenkomstpunt B.
Op de terugweg zijn het dezelfde punten, alleen is B nu het splitspunt en A het samenkomstpunt.