Super bedankt voor jouw reactie! Constructieve feedback is erg fijn en nuttig om de software gebruiksvriendelijker te maken. Hartelijk dank daarvoor!
Jij bedankt voor je tegenbericht!
Zoals ik al vermoedde, zat er toch meer in dat ik zo op het eerste oog zag. Ik had me beter wel geregistreerd
De methodes zijn deels gebaseerd op mijn promotieonderzoek aan de TU/e
Interessante materie. Ik zal het een dezer dagen zeker eens door lezen.
Hiervooer heb ik de API gemaakt. Met de API kan een developer deze methodes inbedden. Je zou bijv. op basis van de actuele verkeerstoestand periodiek de beste blokstructuur kunnen bepalen. Om zo afhankelijk van de actuele verkeerssituatie de meest efficiënte blokstructuur te gebruiken.
Klinkt goed! Alleen jammer dat mijn programmeer-skills niet goed genoeg zijn om dat te kunnen. Maar goed dat het wel mogelijk is
In drukkere verkeerssituaties worden lange termijneffecten juist erg belangrijk (lange termijn opbouw van wachtrijen); doordat starre regelingen periodiek zijn kan je deze lange-termijn effecten heel goed meenemen (je kan als het ware oneindig ver in de toekomst kijken omdat je al weet wat er gaat gebeuren). In drukke situaties werken starre regelingen (of regelingen die de bijbehorende blokstructuur gebruiken) daarom juist erg goed.
Hier snijd je een interessant punt aan. Het is zonder meer waar dat in zwaar (over)belaste situaties een regeling -- hetzij voertuigafhankelijk, hetzij verkeersafhankelijk -- het
gedrag gaat vertonen van een starre regeling. Daarmee is niet gezegd dat het ook daadwerkelijk een starre regeling is. Een starre regeling voorziet namelijk, in de meest strikte definitie, dat iedere richting op vooraf gespecificeerde momenten groen/geel/rood
moet zijn, ongeacht het verkeersaanbod. Dat is in de praktijk echter hoogst inefficiënt, zeker als het een kruising betreft met langzaam verkeer: niet iedere cyclus is het aanbod van fietsers en voetgangers dermate hoog dat het gerechtvaardigd is om zoveel groen voor die richtingen uit te delen. Daarom bestaan er -- in ieder geval in Nederland -- half-starre regelingen. Die zijn in feite een mix van voertuig-/verkeersafhankelijke regelingen en starre regelingen: binnen een vaste cyclustijd is voor iedere richting is vooraf gedefinieerd van wanneer tot wanneer die groen mogen worden. Mocht er echter voor een richting geen aanbod zijn, dan wordt die richting ook niet groen. Of mocht de wachtrij van een richting al zijn afgewerkt nog voordat het vooraf gespecificeerde eindgroenmoment is aangebroken, dan kan die richting eerder naar geel en rood gestuurd worden. Daardoor kunnen andere (conflicterende) richting iets eerder realiseren en/of alternatief realiseren, waardoor je effectief in speelt op het verkeersaanbod binnen een vooraf gedefinieerde cyclustijd en fasediagram. Hier kun je nog allerlei aanvullende instellingen aan hangen, zoals hoeveel seconden een richting maximaal eerder mag beginnen dan zijn fixed startgroennoment en tot wanneer hij sowieso groen moet blijven ongeacht aanbod van verkeer. Zeker in zwaar (over)belaste situaties presteert een halfstarre regeling erg goed.
Daarnaast nog een kleine nuance: de situatie waarin starre regelingen het beste regelen op straat, is als alle richtingen tot hun maximum zijn verzadigd. Dat is echter maar zelden het geval. Daardoor zal een volledig starre regeling in de praktijk vaak minder goed presteren dan een voertuig-/verkeersafhankelijke of halfstarre regeling, bijv. door veel (onnodig) wachten.
Het zou helemaal ideaal zijn als je automatisch tussen deze twee soorten regelingen kan wisselen.
Mits een halfstarre regelstructuur in de VRI aanwezig is incl. bijbehorend fasediagram, kan een regeling al automatisch wisselen tussen die twee. Het mooie zou nu zijn -- en daarvoor is jouw API mogelijk erg interessant -- om als dan eenmaal gewisseld is, dat het fasediagram automatisch geüpdatet wordt o.b.v. de situatie op straat.
Je kan visueel een kruispunt invoeren met 3 of 4 armen. Daarnaast heb je de mogelijk om signaalgroepen op een ‘niet-visuele manier’ in te voeren (zie tabblad ‘signaalgroepen’ aan de rechterkant ‘Overige signaalgroepen’). Hier kan je bijv. de 5e arm, of volgrichtingen invoeren (voor deze signaalgroepen wordt overigens geen voorstel gedaan welke richtingen met elkaar conflicteren).
Ik zal de volgende keer mezelf registreren en er op die manier wat dieper induiken. Dan had ik het misschien al gevonden ^.^'
Er zijn meerdere mogelijke doelfuncties om te minimaliseren/maximaliseren. De meest voor de hand liggende is de gemiddelde verliestijd die weggebruikers ervaren. Er zijn een aantal verschillende formules beschikbaar om deze verliestijd te benaderen. Op het moment wordt in de desktop applicatie een formule van Akcelik gebruikt die de lange termijn verliestijd afschat (ik geloof dat Cocon graphium ook en benadering van Akcelik gebruikt). Helaas is deze alleen bruikbaar wanneer er geen sprake is van oververzadiging. Akcelik heeft ook een variant waarmee je in verzadigde situaties de verliestijd kan afschatten (in dat geval wordt de gemiddelde verliestijd van het verkeer dat in een ingestelde horizon aankomt geminimaliseerd):
https://www.researchgate.net/profile/Ra ... 1ae544.pdf). Deze zal zeer binnenkort ook beschikbaar zijn in de applicatie. Als een andere benadering voor de verliestijd gewenst is, dan is het geen probleem om deze optie ook toe te voegen.
Akçelik is inderdaad een vrij aardige schatter. Al kwam ik in mijn thesis onderzoek erachter dat de foutmarge t.o.v. de simulatie of de straatversie best groot is. Webster is daarin nog slechter, in zekere zin. Ik kwam er achter dat de doelfunctie voor delay van de Highway Capacity Manual best aardig in de buurt komt, omdat die aanzienlijk beter kan omgaan met zwaar (over)belaste situaties, al komt dat ook doordat aanzienlijk parameters gebruikt worden. Ik zou zeggen: vergelijk die uitkomsten eens met Akçelik. Ik ben benieuwd naar wat jij ervan denkt
Wat is nu het verschil met Cocon (en andere pakketen zoals bijv. VRIgen)? Ten eerste de rekentijden. Cocon graphium en VRIgen gebruiken een aanpak die één-voor-één alle mogelijke blokstructuren probeert. Dit noemt men ook wel een brute-force aanpak. Dit schaalt qua rekentijden erg slecht aangezien het aantal mogelijke blokstructuren erg snel stijgt in de probleemgrootte (sneller dan exponentieel!). Voor grotere problemen is deze aanpak daarom niet in staat binnen redelijke tijd een antwoord te geven. Je zal hier dus ‘slimmer’ moeten zoeken naar de beste oplossing. Je wil de optimale oplossing vinden zonder alle oplossingen te proberen, hier zijn gelukkig wiskundige technieken voor; ik gebruik veel grafentheorie samen met linear integer programming.
Het tweede grote verschil is de kwaliteit van de oplossing. Zo worden in cocon graphium een aantal aannamen gedaan (zodat het aantal te evalueren blokstructuren beperkt blijft). Één daarvan is bijv. dat alleen de blokstructuren worden beschouwd waar het aantal blokken gelijk is aan het minimaal aantal benodigde blokken. De optimale oplossing hoeft niet aan deze eigenschap te voldoen. Er worden hierdoor dus (veel) goede blokstructuren uitgesloten; hoe meer oplossingen je buiten beschouwing laat hoe groter het mogelijke verlies in kwaliteit. Verder heeft de nieuwe methode ook de optie om het aantal gewenste groenfasen te kiezen; zo kan je een aantal signaalgroepen meerdere keren groen geven (dit heeft wel invloed op rekentijden).
Nice, klinkt goed. Ik ben niet zo wiskundig onderlegd dat ik precies weet wat grafentheorie e.d. betekent, maar ik kan mij goed voorstellen dat het een slimmere oplossing is dan "brute force". En als je dan ook nog eens slimmer de mogelijkheden afgaat. Ja, ik zal daar eens wat dieper induiken om het eens uit te proberen
Deze snap ik niet helemaal. Het is nu mogelijk om meerdere rijstroken per signaalgroep op te geven (dit kan in het tabblad ‘intrasignaalgroep’ door op het plusje helemaal rechts in de tabel te klikken). De afrijdcapaciteit (per rijstrook) is nu een input die ingevoerd dient te worden; als je een rijstrook toevoegt dan wordt de totale afrijdcapaciteit van deze signaalgroep dus automatisch groter. Is dit wat je bedoelt?
Ja, dat bedoelde ik. Ik had dat knopje over het hoofd gezien ^.^'
De ontruimingstijden kan je momenteel al in tienden (of zelfs honderdsten) van een seconde invoeren. Je kan namelijk getallen achter de komma invoeren. Hetzelfde geldt voor andere informatie zoals minimale groentijden, geeltijden, etc. Daarbij moet ik wel melden dat we nu een starre regeling optimaliseren waarvoor de start van iedere groentijd en de start van iedere roodtijd op een gehele seconde valt. Dit zal ik uitbreiden zodat je in de toekomst ook de optie hebt om met tienden te werken (waarschijnlijk wordt dit de nieuwe default); er is al rekening mee gehouden dat dit later toegevoegd zou worden, dus dit is zeker te doen.
Ik zal dan wel het verkeerde teken (punt i.p.v. komma of andersom) gebruikt hebben. Maar goed dat het dus al wel kan. En nog mooier dat je het verder wilt ontwikkelen met startgroenmomenten e.d. ook op tienden seconden. Dat vind ik nu toch nog te vaak een tekortkoming in bijv. COCON, want hoewel je daarin ook ontruimingstijden e.d. in tienden seconden kan aangeven, doet hij er qua fasediagram bijzonder weinig mee.
Klopt het dat intergroen vooral een manier is om negatieve ontruimingstijden toe te staan (ik baseer mij even op het volgende:
https://www.nm-magazine.nl/artikelen/me ... %E2%80%99/)? Je kan namelijk momenteel al negatieve ontruimingstijden invoeren (hier heeft de optimalisatie geen problemen mee). Ik kan de optie om intergroentijden in te voeren natuurlijk toevoegen (weinig moeite), maar zie niet direct het verschil met een ontruimingstijd; bij een geeltijd van g seconde, is een intergroentijd van x dan niet hetzelfde als een ontruimingstijd van x-g? Of zie ik hier iets over het hoofd?
Ja, klopt volledig. In het buitenland al heel gebruikelijk. De negatieve ontruimingstijd wordt dan toegestaan tot op zekere hoogte: is de ontruimingstijd van bijv. fc02 naar fc09 -5.0s maar de geeltijd van fc02 is 3.0s, dan wordt als maximale negatieve ontruimingstijd -3.0s toegestaan, om zodoende te voorkomen dat twee conflicterende richtingen tegelijk groen zijn. Immers, op startgeel weet je pas zeker dat een richting naar rood gaat.
De grap is nu alleen dat intergroentijden iets anders worden berekend. Ja, het zijn negatieve ontruimingstijden, alleen, zoals gezegd, moet je rekening houden met de geeltijd. Dat wordt standaard gedaan in de berekening van intergroentijden, waardoor je effectief geen negatieve waarden meer hebt. Bovendien worden ontruimings- en intergroentijden vaak in een apart programma berekend (met als uitvoer o.a. csv-bestanden) of worden die uit een oud applicatie-bestand gehaald. Als je die meteen kan importeren vanuit dat dergelijke bestanden en direct in het juiste format (ontruimingstijd vs. intergroentijd), dan scheelt dat een hoop werk qua overtypen en het maakt het minder foutgevoelig met het overnemen van die tijden.
Ik snap jouw punt. Dit is een afweging geweest. Als iedere start-/eindgroen moment wordt gemarkeerd, dan staan deze tijden (bij grotere kruispunten) erg dicht op elkaar, waardoor het weer onoverzichtelijk wordt. Als je met de muis op een groenfase hangt worden de bijbehorende waarden getoond. Het is dus niet zo dat je deze tijdstippen niet kan achterhalen.
Logisch
Met jouw tweede punt heb ik ook eerder geworsteld. Een signaalgroep mag meerdere keren groen zijn in 1 periode. In dit geval zouden er niet 2 maar 4 (of nog meer) tijden in de tabel moeten komen. In dat geval wordt de tabel weer groot. Heb jij hier een idee/voorstel voor? Wat wel al mogelijk is, is al deze tijden kopiëren (voor bijv. gebruik in Excel); dit levert een tabel op met 1 rij per groenfase.
Export naar Excel zou inderdaad prachtig zijn. Voor in het programma zou je kunnen denken dat je daar iets voor verzint om te kunnen switchen van de eerste groenfase naar de tweede en terug. Je zou ze waarschijnlijk niet allebei te gelijk willen zien, maar wel inzichtelijk kunnen maken. Dus een soort filter waar je als gebruiker kunt kiezen wat je wilt zien: (a) beide groenfases bij elkaar m.b.t. verzadiging, effectief groen, delay, maar zonder start-/eindgroenmomenten en (b) per groenfase de volledige lijst (verzadiging, effectief groen, delay, start-/eindgrienomenten, etc.), en dan dus eerste dat voor de eerste groenfase, dan de tweede etc.
Deze kan ik zeker toevoegen. Had hem nog niet toegevoegd omdat deze in het schema zelf zichtbaar is.
Goed voorstel: ik ga dit tabblad hernoemen. In principe kunnen de intensiteiten (en capaciteiten) ook in mvt/h ingevoerd worden (zolang voor de capaciteit en de intensiteit van dezelfde signaalgroep ook dezelfde eenheid wordt gebruikt: dus ofwel beiden mvt/h ofwel beiden pae/h. Ik zal nadenken hoe dit duidelijker te maken in het programma.
Klinkt goed
Je kan een starre regeling compleet naar eigen inzicht aanpassen; je kan groenfasen verschuiven in tijd, groenfasen toevoegen/verwijderen, en de cyclustijd aanpassen (dit kan je allemaal op een intuitieve manier doen: bijv. groenfasen in tijd verschuiven door hem met de muis te verslepen).
Ik kreeg nog geen fasediagram, omdat ik me niet had geregistreerd

. Maar ik zal dat de volgende keer wel doen en het dan helemaal ontdekken
Ik ben benieuwd naar je volgende versie. Ik houd me aanbevolen als testpubliek
