Knooppunt 5 in Amsterdam (bij het Centraal Station) heb ik hier al eens vaker langs laten komen, want het is een intrigerend ding. Er staan routes op van de orde “Voor knooppunt 70, volg de borden Zaanstad”.
Nu heb ik de route eens wat grondiger bekeken en zowaar: als je braaf doet wat de kaart bij Knooppunt 5 zegt (Zaanstad aanhouden), dan staat er precies op de juiste momenten, of eigenlijk is er geloof ik maar een zo’n moment, een bord met extra informatie zodat je knooppunt 70 bereikt: namelijk bij de pont over het Noordzeekanaal een bord: “70 - volg Zaandam 3 km”. En op ongeveer 2,2 kilometer staat er dan, zowaar, een heus bord richting de 70.
Maar nu komt het: andersom heb ik zo’n aanduiding niet kunnen vinden. Wie van 70 naar 5 wil fietsen, heeft pech.
Dus wat nu? Een even geestige als correcte oplossing leek me om de route aan te geven met uitsluitend “forward” tags (eventueel omgedraaid als de wegrichting daartoe noopt), om zo aan te geven dat het de facto een eenwegroute betreft. Een oplossing zonder gekheid weet ik niet. Een van de trouwe lezertjes hier nog verhelderende ideeën?
Dat is denk ik op dit moment de correcte oplossing. Alleen schijnen die forward en backward tags niet door de renderer gezien te worden, dus op de kaart ga je het niet terug vinden. Hetzelfde geldt natuurlijk voor die lokale rondritten (waarvan de meeste opgeheven gaan worden): die lopen ook maar 1 kant op.
Aangezien een relatie een geordende lijst is had ik zelf verwacht dat er in een fietsrouterelatie maar 1 richting zit, met de ways (en nodes) netjes op volgorde van startpunt naar eindpunt. Op die manier kan je in de editor ook eenvoudig zien of er nog gaten in de route zitten. Er zitten nu bijvoorbeeld wat gaatjes (naast minstens 1 echt gat) in fietsroute LF4 (Midden Nederland route) - hoe kan ik die vinden?
Yep, enige manco voorzover ik het kan zien, is dat het optellen van de km’s tussen de knooppunten niet werkt; Ik zou nl. tevreden zijn met een lengte die bestaat uit het gemiddelde van de heenweg en de terugweg.
Is het forward/backward principe niet toereikend om een waterdichte formule hiervoor te verkrijgen? (Mijn - theoretische - pogingen er een te vinden, zijn tot nu toe op niets uitgelopen.)
Ik render de geometrie zoals die aangemaakt wordt door osm2pgsql. Deze deelt de routes op die forward/backward splitsingen op in aparte geometrieën, vandaar dat er geen simpele, nu al werkende oplossing is.
Of in osm2pgsql zal de handling anders moeten, of je moet zelf in de db wat nabewerking doen. Dat laatste is weer niet zo voor de hand liggend, als je er elke minuut wijzigingen op verwerkt.
Nu volg ik het niet meer. Op opencyclemap.org zijn eenrichtingsstukken inderdaad te zien met gele driehoekjes, maar daar staan toch helemaal geen afstanden op.
Waarom zou je het gemiddelde willen hebben, ik wil gewoon de 2 afstanden A->B en B->A zien. De renderer moet daar dan maar wat moois van maken: de afstand bij een eenrichtingsstuk zetten of een pijltje bij het getal.
Volgens mij kan je vanaf een van de 2 netwerk nodes de ways volgen naar de andere node, en op elke (tussenliggende) node is er als het goed is maar 1 weg die je kan nemen. Je moet dan wel bijhouden welke ways je al gehad hebt. Als je de lengtes van de gevonden ways optelt heb je natuurlijk de afstand tussen de netwerk nodes in die richting. Als je de afstanden voor de 2 richtingen hebt dan is het gemiddelde ook uit te rekenen.
Die gele driehoekjes op opencyclemap.org waren mij niet opgevallen; wel mooi trouwens. (Die pijltjes op het onderste stuk was een foutje en inmiddels gecorrigeerd in de db.) Ik had het echter over openfietskaart.nl
Ja, dat is natuurlijk ook goed. Ik dacht dat het wat makkelijker berekenen zou zijn met gemiddelden door gewoon het hele pakket ways met forward en backward roles op te pakken als volgt:
D1: Lengtes van alle secties zonder forward/backward op tellen
D2: Lengtes van alle forward ways in de way-direction + backward ways tegen de way direction_in op tellen
D3: Lengtes van alle forward ways tegen de way-direction in + backward ways met de way direction mee op tellen.
D4: ((D1 * 2) + D2 + D3) /2
Maar er zit een probleem in IMHO. Wanneer weet je nou of een forward-way met de rijrichting mee gaat of er tegen in, zonder de software node voor node de ways bij langs te laten lopen en te laten ‘zien’ hoe de route loopt. En als je een routine hebt die de ways echt een voor een oppakt aan de hand van die koppel-nodes, kan je inderdaad net zo goed een lengte voor de heen- en voor de terugreis bepalen en displayen, alhoewel het verschil nooit meer dan tientallen meters zal zijn, denk ik. Of kent iemand een voorbeeld waarbij het honder(en) meters scheelt?
Ik zou eerst gaan proberen het gemiddelde te berekenen. Dat is veel simpeler.
Jouw formule kun je iets vereenvoudigen. Omdat je D2 en D3 bij elkaar optelt, is het niet nodig om daar een onderscheid tussen te maken.
E1: Lengtes van alle secties zonder forward/backward op tellen
E2: Lengtes van alle secties met forward/backward op tellen
E4: ((E1 * 2) + E2) /2
Maar er is nog wel een ander probleem. Een sectie zonder forward/backward kan naar een way verwijzen met oneway=true. Die hoort dan dus bij E2. Dan wordt het dit:
E1: Lengtes van alle secties zonder forward/backward op tellen die niet oneway zijn
E2: Lengtes van alle secties met forward/backward op tellen
E3: Lengtes van alle secties zonder forward/backward op tellen die wel oneway zijn
E4: ((E1 * 2) + E2 + E3) /2
