Ik ben echt benieuwd of je iets kunt produceren dat simpeler is dan dat ik heb geconstrueerd.
Wat gebeurt er dan als je dat doet? (Beetje van de zotte dat ik het moet vragen, maar gezien de snelheid van mapupdates krijg ik gewoon nog geen kans om het zelf uit te proberen).
De kruisverbinding van de meest linkse afrit van onderen zou kunnen worden veranderd in een jump; de andere kruisverbindingen zijn niet noodzakelijk zolang er nooit een route wordt gezocht of herberekend vanaf een plek binnen de rotondetandem. Doe je dat wel, dan krijg je routes die je soms over de snelweg heen en weer sturen ipv. simpelweg een geoorloofde (doch onder normale omstandigheden af te raden) baanwijziging te laten uitvoeren. Ze zijn in de huidige versie dusdanig gewogen dat ze geen negatieve gevolgen hebben voor de (long-distance) routing van buiten de tandemrotondes.
a. Duh. Dit is hoever ik wil gaan voor een voorsortering. Geen voorsorteeropdracht zonder de bypasses. Bovendien kan de rotonde dichtstaan door verkeer uit twee richtingen en de bypass gaat er omheen. Kan nog net met Waze. Vergelijk Randweg Geleen, Turborotonde, met 3 bypasses, 6 turnrestrictions, klaar. Maar nog nèt teveel space tussen de bypass en de rotonde om in de client echt goed uit te zien. Let je ook even op de ontbrekende fietspaden?
b. Vind ik mooier. Jij niet? “ingetekend zoals de echte (bypass) route loopt” doen ze maar bij het kadaster. Nee, serieus, met een onnauwkeurigheid tussen de 5 en de 50 meter in de iPhones van vandaag (en volgende jaren ook nog, toekomstgericht hè) is ook het GPStrack nooit zoals de route loopt.
Vanavond nog even geknutseld. Volgens mij is dit de simpelste manier om de boel in kaart te brengen. Aangezien er tussen de rotondes nog van rijbaan gewisseld kan worden, heb ik hier zogenaamde ‘Mapcat bowties’ van gemaakt. Zo krijg je tussen de rotondes altijd nog een mogelijkheid om van baan te wisselen. Hierdoor kan het ook zijn dat je, komend vanaf zuidwest en gaand richting Eindhoven, op de eerste rotonde nog over de buitenste baan geleid wordt, ondanks dat de borden anders aangeven. Dat is in de huidige situatie ook het geval.
De bovenste rotonde blijft wel lastig trouwens… Ben er nu zo lang mee bezig dat alle banen me voor de ogen dansen, dus laat ik het even zo.
Ik heb nu alle aan/afvoerbanen van de rotondes uit jouw model overgenomen zodat elke rotonde maar 1 keer per doorgang gesneden wordt. De Mapcat bowties begrijp ik, echter die zorgen er inderdaad voor dat de voorsorteerbanen weer gelijke penalties krijgen in combinatie met de andere rotonde. Dit zorgt er juist weer voor dat er verkeerd voorgesorteerd gaat worden (soms). Is dit wat er nu staat enigszins verteerbaar? Want als het nog verder vereenvoudigd wordt, kloppen de voorsorteeradviezen niet meer altijd, en dan krijg je dat mensen tussen de rotondes van baan moeten wisselen; hetgeen wel gaat, maar doorstromingstechnisch niet aan te raden is.
Ik heb de meeste extra junctions die ik hiermee geintroduceerd heb weer verwijderd. Moet nog 1 keer nalopen om te controleren dat ook daadwerkelijk de separating line uit gaat, want hij blijkt bij een merge meestal het separating line attribuut over te nemen voor het hele segment.
Ziet er netjes uit, ik zou alleen eens moeten opletten hoeveel het uitmaakt qua voorsortering, ben benieuwd wanneer die bij de spoorsingel eindelijk erin zit, zodat ik eens kan zien in de client wat hij zegt en wanneer. Wat betreft fietspaden, ik neem aan dat dit niet een oproep is om ze toe te voegen, maar dat je wilt benadrukken hoe schoon het oogt zonder? ;-).
Ik weet eerlijk gezegd nog niet wat ik mooier vind, maar een estethische reden is er ook een, had ik alleen zonder te vragen niet kunnen raden.
Hey, bedankt, heb er ook nog een paar gevonden en had de indruk dat “separating line” juist altijd verdwijnt - however. Wil je de fietspaden niet ook nog in overweging nemen? Zo gauw ze knopen maken met straten zitten ze eigenlijk al in de weg…
Vanwege de extra junction penalties?
Of vanwege de extra turn restrictions?
Of vanwege de mapclutter?
Er is nl. niet altijd een eenduidige oplossing (vind ik), er soms verschillende redenen waarom je ze wel wil, maar om een goede afweging te kunnen maken is het natuurlijk dan ook belangrijk te weten waarom je ze niet wilt.
Ik weet dat bij bepaalde snelweg op- en afritten hier in de buurt met enige regelmaat een (brom)fietser geschept wordt. De (brom)fietsers snijden de op/afritten, maar bevinden zich op de voorrangsweg, en hebben dus gewoon voorrang. Auto’s die die op/afritten nemen zijn dus verplicht om telkens te controleren of er (brom)fietsers zijn die voorrang moeten krijgen. Dat checken kost daadwerkelijk tijd, dat kost zelfs meer tijd dan wanneer er een weg van rechts komt en je moet kijken of er een auto aankomt die voorrang heeft (die bromfietsers zijn moeilijker te zien, en ze kunnen van beide richtingen komen op die fietspaden).
D.w.z. die junctions in zo’n geval lijken dan juist wenselijk, omdat ze de correcte penalty introduceren die op zo’n weg verbruikt wordt.
Ok, fair enough. Maar dat argument kan natuurlijk gebruikt worden voor elk segment en alle junction penalties. Is er dan nog een goede reden om vanuit de server voor een junction een extra tijdpenalty uit te delen?
Waarbij we overigens weer rond zijn, want als de server geen penalty zou uitdelen voor de junctions, zijn ze ook niet bezwaarlijk om aanwezig te zijn.