Automatisch en in enkele seconde de beste (starre) regeling

Forum waar gediscussieerd kan worden over (dynamisch) verkeersmanagement.

Moderator: Moderatoren

StijnFleuren
zandpaadje
Berichten: 13
Lid geworden op: za 23 feb 2019, 11:02

Automatisch en in enkele seconde de beste (starre) regeling

Bericht door StijnFleuren » wo 18 nov 2020, 11:12

Sinds 2011 houd ik mij bezig met onderzoek naar de optimalisatie van verkeerslichtenregelingen. Met trots kan ik mededelen dat dit heeft geresulteerd in de snelste methode om optimale starre regelingen te vinden (enkele seconde voor zelfs de meest complexe kruispunten); erg belangrijk in drukke verkeerssituaties en de ideale basis voor een iVRI!

Ik denk dat dit werk erg nuttig kan zijn in de praktijk en vind het doodzonde als dit onderzoek (zoals de vele onderzoeken aan de universiteit) op een stoffige plank komt te liggen en niet zijn weg vind naar de praktijk. Vandaar dat ik heb gewerkt aan een tweetal services:
  • Desktop software waarmee data gemakkelijk ingevoerd kan worden en de gegenereerde starre regelingen op een intuïtieve manier naar wens aangepast kunnen worden. Hieronder een tweetal screenshots om jullie een idee te geven: Afbeelding

    Afbeelding
  • Een API, o.a. aan te roepen vanuit python (https://pypi.org/project/swift-cloud-api/). Met deze API kunnen ontwikkelaars deze snelle optimalisatie methoden integreren in een real-time smart traffic oplossing. Deze API heeft verschillende mogelijke usecases. Denk aan smart traffic control, monitoring en strategic decision making. Een voorbeeld van hoe simpel het gebruik is:

    Code: Selecteer alles

    fixed_time_schedule, phase_diagram, objective_value = SwiftMobilityCloudApi.get_optimized_fts(
            intersection=intersection, arrival_rates=morning_rates, initial_queue_lengths=estimated_queue_lengths,
            objective=ObjectiveEnum.min_delay)
Beiden zijn voorlopig gratis te gebruiken (op langere termijn zal ik hier helaas een bedrage voor moeten vragen om het rendabel te houden). Ik sta altijd open voor feedback; dus mis je functionaliteit, of heb je ideeën voor verbetering. Laat het dan gerust weten.

De desktop software is gratis te downloaden vanaf https://www.swiftmobility.eu/downloads
De API kan je installeren via python –m pip install swift-cloud-api. Voor toegang tot deze api (credentials zijn nodig) kan je een mail sturen naar: stijn.fleuren@swiftmobility.eu.

Iedereen die bereid is mij hiermee te helpen wordt zeer gewaardeerd. Daarom beloof dat het gebruik gratis blijft tot ten minste eind 2021 wanneer je het in 2020 voor het eerst gebruikt; daarna beloof ik korting t.o.v. nieuwe gebruikers.

In ieder geval dank voor jouw aandacht tot nu toe!

Martinus
zandpaadje
Berichten: 12
Lid geworden op: di 16 jun 2015, 19:24
Locatie: Hoogstraten

Re: Automatisch en in enkele seconde de beste (starre) regeling

Bericht door Martinus » wo 18 nov 2020, 18:13

Mooi idee. Ik heb ook meteen even gekeken wat ik er als verkeersregelkundige uit de praktijk van vind, want je belooft wat ;)

Maar eerst: Je hebt over een onderzoek van de universiteit, daardoor vermoed ik dat dit programma daaruit is voortgekomen. Welk onderzoek of welke onderzoek zijn/waren dit? (Ik ben nieuwsgierig aangelegd).

Dan nu wat ik er inhoudelijk van denk (en vooraf excuses als het misschien wat mierenneukerig over komt of omdat ik niet alles goed heb kunnen uitzoeken omdat ik me niet had geregistreerd):
  • Ten eerste: waarom een starre regeling? Ik kan mij voorstellen dat je het zou willen gebruiken om de ideale blokvolgorde te bepalen die als basis geldt voor een VRI. Maar je hebt het nadrukkelijk over een iVRI. Als ik kijk naar de markt, dan zie ik dat steeds meer partijen iVRI's op straat zetten die niet afhankelijk zijn van zo'n pre-defined blokstructuur maar juist regelen op basis van onderling compatable signaalgroepen of verschillende blokstructuren die op dat specifieke moment het meest efficiënt is (en dat hoeft niet iedere cyclus dezelfde te zijn). Dus als bouwsteen vooraf voor een iVRI zie ik markt-technisch niet direct de meerwaarde. Maar ingebed in een iVRI die real-time dit principe gebruikt om de juiste signaalgroepafhandeling te kiezen voor dat moment, dat zou wel mooi kunnen zijn. Moet je het alleen nog wel aan zo'n marktpartij weten te verkopen en te integreren ;)
  • Je hebt het over complexe kruispunten, maar ik heb het (nog) niet voor elkaar gekregen om een kruising met 5 armen, of met verschillende volgrichtingen erin te configureren (bijv. fc02 -> fc62 -> fc102). Is zoiets wel mogelijk?
  • Waarop is de ideale/optimale regeling exact gebaseerd? Hoe verhoudt zich dit tot hoe bijvoorbeeld COCON het e.e.a. bepaalt? En ook: ten opzichte van wat zoal (COCON?) presteert jouw programma beter?
  • Is het ook mogelijk om meerdere rijstroken per signaalgroep op te geven en dat daaruit automatisch de afrijdcapaciteit wordt bijgewerkt?
  • Wat ik ook echt een gemiste kans vind -- maar die je gelukkig, hoop ik althans, makkelijk kan oplossen -- is dat ik de ontruimingstijden in hele seconden moet invoeren. Je ziet steeds meer wegbeheerders kiezen voor ontruimingstijden in tienden seconden. Als je op een druk kruispunt met 4 blokken voor de maatgevende conflictgroep onderlinge ontruimingstijden heb berekend van bijv. 4×2.5s, dan moet ik dat in jouw programma ingeven als 4×3.0s, waardoor ik effectief 4×0.5s=2s verliestijd introduceer. Zeker op (over)belaste kruisingen, kan dit verkeerskundig heel lelijk uitpakken.
  • Daaruit volgend: steeds meer wegbeheerders kiezen bovendien voor intergroentijden (tijd tussen eindgroen van de ene richting naar het startgroen van de volgende richting, waardoor je effectief tijdens geel kunt ontruimen en dus ook de conflicterende richting naar groen zou kunnen sturen). De optie intergroen kan ik ook niet selecteren.
  • Net zoals ik de ontruimingstijden niet in tienden seconden kan ingeven, kan ik ook de geeltijden niet in tienden seconden ingeven. Ook dit is steeds gebruikelijker, eens te meer omdat de richtlijnen in Nederland bijvoorbeeld voorschrijven dat afslaande richtingen standaard 3.0s geel krijgen, rechtdoor à 50km/h 3.5s, rechtdoor à 60km/h 4.0s, rechtdoor à 70km/h 4.5s en rechtdoor à 80km/h 5.0s. Maar goed, waarschijnlijk is ook dit eenvoudig alsnog te implementeren.
  • Kijk ik naar het fasediagram, dan vind ik het aan de ene kant prettig dat een aantal start-/eindgroen momenten gemarkeerd zijn op de x-as met bijbehorende tijd, maar vind ik het tegelijkertijd erg onprettig dat dat niet voor ieder start-/eindgroenmoment is gedaan. Wat ik bovendien mis -- en zelf toch wel vaak gebruik -- is gewoon een tabel ernaast waarin die tijden staan, zodat het in één oogopslag zichtbaar is. De tabel is er, ik mis dus alleen die twee waarden nog.
  • Bovenaan je fasediagram benoem je de delay en het capaciteitsoverschot. Ik zou daar toch ook graag de cyclustijd terug zien. Wederom om het in een oogopslag te kunnen zien bij je voornaamste performance indicators.
  • Is het mogelijk om zelf de cyclustijd nog op te rekken of in te korten o.b.v. eigen inzicht? Ik ben zelf namelijk zelden tevreden met het automatisch gegenereerde fasediagram, ook omdat ik soms juist ergens oververzadiging wil toestaan en een andere keer juist niet.
  • Tot slot: het tabblad "scenario's" zou ik hernoemen naar "intensiteiten". Ik was daar namelijk naar op zoek en pas toen ik daar aankwam, ontdekte ik dat ik het daar moest zoeken. Bovendien, ik zou ook de optie toevoegen dat je intensiteiten in mvt/h kan ingeven i.p.v. alleen pae/h. Het aantal pae/h is immers niet altijd bekend.
Al met al een best lijstje -- en vanwege een aantal voorname tekortkomingen (bijv. tienden seconden) niet direct toepasbaar in de meeste praktijk situaties, vermoed ik --, maar laat je niet ontmoedigen: Je idee is hartstikke goed en het ziet er ook goed uit. Zie voorgaande dan ook als opbouwende kritiek om je product nog beter te maken. Daardoor wordt het ook praktisch beter toepasbaar en ook dat komt weer ten goede aan je product.

Succes!

StijnFleuren
zandpaadje
Berichten: 13
Lid geworden op: za 23 feb 2019, 11:02

Re: Automatisch en in enkele seconde de beste (starre) regeling

Bericht door StijnFleuren » wo 18 nov 2020, 22:21

Super bedankt voor jouw reactie! Constructieve feedback is erg fijn en nuttig om de software gebruiksvriendelijker te maken. Hartelijk dank daarvoor!

Ik zal mijn antwoord opsplitsen in meerdere berichten aangezien het anders een heel lang bericht wordt.

De methodes zijn deels gebaseerd op mijn promotieonderzoek aan de TU/e: https://pure.tue.nl/ws/portalfiles/port ... leuren.pdf. Dit werk stamt alweer uit 2016 en is een basis geweest voor de verdere ontwikkeling in de afgelopen jaren.
Ten eerste: waarom een starre regeling? Ik kan mij voorstellen dat je het zou willen gebruiken om de ideale blokvolgorde te bepalen die als basis geldt voor een VRI. Maar je hebt het nadrukkelijk over een iVRI. Als ik kijk naar de markt, dan zie ik dat steeds meer partijen iVRI's op straat zetten die niet afhankelijk zijn van zo'n pre-defined blokstructuur maar juist regelen op basis van onderling compatable signaalgroepen of verschillende blokstructuren die op dat specifieke moment het meest efficiënt is (en dat hoeft niet iedere cyclus dezelfde te zijn). Dus als bouwsteen vooraf voor een iVRI zie ik markt-technisch niet direct de meerwaarde. Maar ingebed in een iVRI die real-time dit principe gebruikt om de juiste signaalgroepafhandeling te kiezen voor dat moment, dat zou wel mooi kunnen zijn. Moet je het alleen nog wel aan zo'n marktpartij weten te verkopen en te integreren
Je hebt hier helemaal gelijk. Als bouwblok vooraf is dit voor een iVRI niet interessant, voor een VRI wel. Voor een iVRI wordt het pas interessant als je het kan inbedden. Hiervoor is de desktopapplicatie niet direct nuttig. 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.

De vraag die je hier stelt (predefined blokstructuur vs. ad-hoc het beste blok kiezen) vind ik een hele goede. Ik zie deze ontwikkeling ook. Deze twee soorten regelingen hebben beiden hun nut; echter hebben ze een ander regiem waar ze goed werken. Regelingen die continue de best volgende actie (blok) bepalen werken vooral goed onder minder drukke verkeerssituaties. 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. Het zou helemaal ideaal zijn als je automatisch tussen deze twee soorten regelingen kan wisselen. Hiervoor kan je de API ook gebruiken; deze heeft namelijk de mogelijkheid om af te schatten in welk regiem je zit (zie ook de sectie 'automatically switch between control strategies' op https://pypi.org/project/swift-cloud-api/).

StijnFleuren
zandpaadje
Berichten: 13
Lid geworden op: za 23 feb 2019, 11:02

Re: Automatisch en in enkele seconde de beste (starre) regeling

Bericht door StijnFleuren » wo 18 nov 2020, 22:35

Je hebt het over complexe kruispunten, maar ik heb het (nog) niet voor elkaar gekregen om een kruising met 5 armen, of met verschillende volgrichtingen erin te configureren (bijv. fc02 -> fc62 -> fc102). Is zoiets wel mogelijk?
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).
Waarop is de ideale/optimale regeling exact gebaseerd? Hoe verhoudt zich dit tot hoe bijvoorbeeld COCON het e.e.a. bepaalt? En ook: ten opzichte van wat zoal (COCON?) presteert jouw programma beter?
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.

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).

StijnFleuren
zandpaadje
Berichten: 13
Lid geworden op: za 23 feb 2019, 11:02

Re: Automatisch en in enkele seconde de beste (starre) regeling

Bericht door StijnFleuren » wo 18 nov 2020, 22:38

Is het ook mogelijk om meerdere rijstroken per signaalgroep op te geven en dat daaruit automatisch de afrijdcapaciteit wordt bijgewerkt?
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?
Wat ik ook echt een gemiste kans vind -- maar die je gelukkig, hoop ik althans, makkelijk kan oplossen -- is dat ik de ontruimingstijden in hele seconden moet invoeren. Je ziet steeds meer wegbeheerders kiezen voor ontruimingstijden in tienden seconden. Als je op een druk kruispunt met 4 blokken voor de maatgevende conflictgroep onderlinge ontruimingstijden heb berekend van bijv. 4×2.5s, dan moet ik dat in jouw programma ingeven als 4×3.0s, waardoor ik effectief 4×0.5s=2s verliestijd introduceer. Zeker op (over)belaste kruisingen, kan dit verkeerskundig heel lelijk uitpakken.
Net zoals ik de ontruimingstijden niet in tienden seconden kan ingeven, kan ik ook de geeltijden niet in tienden seconden ingeven. Ook dit is steeds gebruikelijker, eens te meer omdat de richtlijnen in Nederland bijvoorbeeld voorschrijven dat afslaande richtingen standaard 3.0s geel krijgen, rechtdoor à 50km/h 3.5s, rechtdoor à 60km/h 4.0s, rechtdoor à 70km/h 4.5s en rechtdoor à 80km/h 5.0s. Maar goed, waarschijnlijk is ook dit eenvoudig alsnog te implementeren.
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.

StijnFleuren
zandpaadje
Berichten: 13
Lid geworden op: za 23 feb 2019, 11:02

Re: Automatisch en in enkele seconde de beste (starre) regeling

Bericht door StijnFleuren » wo 18 nov 2020, 22:40

Daaruit volgend: steeds meer wegbeheerders kiezen bovendien voor intergroentijden (tijd tussen eindgroen van de ene richting naar het startgroen van de volgende richting, waardoor je effectief tijdens geel kunt ontruimen en dus ook de conflicterende richting naar groen zou kunnen sturen). De optie intergroen kan ik ook niet selecteren.
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?

StijnFleuren
zandpaadje
Berichten: 13
Lid geworden op: za 23 feb 2019, 11:02

Re: Automatisch en in enkele seconde de beste (starre) regeling

Bericht door StijnFleuren » wo 18 nov 2020, 22:45

Kijk ik naar het fasediagram, dan vind ik het aan de ene kant prettig dat een aantal start-/eindgroen momenten gemarkeerd zijn op de x-as met bijbehorende tijd, maar vind ik het tegelijkertijd erg onprettig dat dat niet voor ieder start-/eindgroenmoment is gedaan. Wat ik bovendien mis -- en zelf toch wel vaak gebruik -- is gewoon een tabel ernaast waarin die tijden staan, zodat het in één oogopslag zichtbaar is. De tabel is er, ik mis dus alleen die twee waarden nog.
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.

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.

StijnFleuren
zandpaadje
Berichten: 13
Lid geworden op: za 23 feb 2019, 11:02

Re: Automatisch en in enkele seconde de beste (starre) regeling

Bericht door StijnFleuren » wo 18 nov 2020, 22:48

Bovenaan je fasediagram benoem je de delay en het capaciteitsoverschot. Ik zou daar toch ook graag de cyclustijd terug zien. Wederom om het in een oogopslag te kunnen zien bij je voornaamste performance indicators.
Deze kan ik zeker toevoegen. Had hem nog niet toegevoegd omdat deze in het schema zelf zichtbaar is.
Tot slot: het tabblad "scenario's" zou ik hernoemen naar "intensiteiten". Ik was daar namelijk naar op zoek en pas toen ik daar aankwam, ontdekte ik dat ik het daar moest zoeken. Bovendien, ik zou ook de optie toevoegen dat je intensiteiten in mvt/h kan ingeven i.p.v. alleen pae/h. Het aantal pae/h is immers niet altijd bekend.
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.

StijnFleuren
zandpaadje
Berichten: 13
Lid geworden op: za 23 feb 2019, 11:02

Re: Automatisch en in enkele seconde de beste (starre) regeling

Bericht door StijnFleuren » wo 18 nov 2020, 22:49

Is het mogelijk om zelf de cyclustijd nog op te rekken of in te korten o.b.v. eigen inzicht? Ik ben zelf namelijk zelden tevreden met het automatisch gegenereerde fasediagram, ook omdat ik soms juist ergens oververzadiging wil toestaan en een andere keer juist niet.
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).

Martinus
zandpaadje
Berichten: 12
Lid geworden op: di 16 jun 2015, 19:24
Locatie: Hoogstraten

Re: Automatisch en in enkele seconde de beste (starre) regeling

Bericht door Martinus » do 19 nov 2020, 9:43

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 :top:
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.
:top:
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 :facepalm: . 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 ;)

StijnFleuren
zandpaadje
Berichten: 13
Lid geworden op: za 23 feb 2019, 11:02

Re: Automatisch en in enkele seconde de beste (starre) regeling

Bericht door StijnFleuren » do 19 nov 2020, 19:25

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.
Je hebt helemaal gelijk. Ik bedoelde ook zeker niet te zeggen dat starre regelingen de beste keuze zijn in overbelaste situaties; in overbelaste situaties lijkt het mij echter verstandig om de regeling te baseren op een geoptimaliseerd fasediagram (dus bijv. de maximale groentijden en blokstructuur afleiden uit het fasediagram en deze als basis gebruiken voor je regelen) maar ook sensordata te gebruiken (overslaan blokken, inkorten groentijden,…). Al met al: helemaal met jou eens.
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
Interessant! zou jij mij jouw thesis kunnen sturen? Ik ben benieuwd naar de resultaten. Highway Capacity Manual lijkt mij inderdaad een veel gebruikte en goede schatter. Een goede om mee te nemen denk ik. De schattingen van Webster (maar ook Akçelik) zijn natuurlijk al een paar decenia oud; ze zullen dus niet altijd spot-on zijn, maar ze worden nog altijd veel gebruikt.
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.
Ik zal deze hoog op het prioriteitenlijstje zetten. In de tussentijd kan je met de hand het schema achteraf aanpassen (bijv. groentijden net wat verlengen). Het kan handig zijn bij het ‘uitrekken’ van de groenfasen de middelste muisknop te gebruiken. Dan ‘snapt’ de muis automatisch naar interessante tijdstippen (bijv. tijdstippen waar nog net aan de ontruimingstijden is voldaan).
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.
Dit lijkt mij een heel goed argument om de optie voor intergroentijden toe te voegen; misschien kan je de een wel in de ander omzetten, maar dat is wat omslachtig als je ze al in een csv-bestand hebt. Het lijkt mij ook nuttig om hier een import-functie voor toe te voegen. Heb jij toevallig een voorbeeldbestand van veelgebruikte bestandsformaten die je hier zou willen inladen? Dan zou ik hier een import-functie voor kunnen maken.
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.
Een andere mogelijkheid is om een optie toe te voegen om alle tijden te visualiseren (wellicht ook met keyboard short-cut aan en uit te zetten). Deze tijden worden nu al weergegeven wanneer je de tijdstippen van een groenfase via het toetsenbord wil invoeren, zie hieronder. Zou dit helpen?
Afbeelding
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
Super! Dit is echt heel fijn. Jouw constructieve feedback is heel nuttig. Waarschijnlijk ga jij als verkeersregelkundige uit de praktijk nog veel meer nuttige tips hebben :top:

Martinus
zandpaadje
Berichten: 12
Lid geworden op: di 16 jun 2015, 19:24
Locatie: Hoogstraten

Re: Automatisch en in enkele seconde de beste (starre) regeling

Bericht door Martinus » vr 20 nov 2020, 17:40

Interessant! zou jij mij jouw thesis kunnen sturen? Ik ben benieuwd naar de resultaten. Highway Capacity Manual lijkt mij inderdaad een veel gebruikte en goede schatter. Een goede om mee te nemen denk ik. De schattingen van Webster (maar ook Akçelik) zijn natuurlijk al een paar decenia oud; ze zullen dus niet altijd spot-on zijn, maar ze worden nog altijd veel gebruikt.
Maar natuurlijk: http://resolver.tudelft.nl/uuid:2edfd4e ... bb61505297

Wel kleine spoiler: het is niet zo technisch of uitgebreid zoals jouw promotieonderzoek ;)
Dit lijkt mij een heel goed argument om de optie voor intergroentijden toe te voegen; misschien kan je de een wel in de ander omzetten, maar dat is wat omslachtig als je ze al in een csv-bestand hebt. Het lijkt mij ook nuttig om hier een import-functie voor toe te voegen. Heb jij toevallig een voorbeeldbestand van veelgebruikte bestandsformaten die je hier zou willen inladen? Dan zou ik hier een import-functie voor kunnen maken.
Natuurlijk. Ik zal wel een voorbeeld mailen van zo'n csv bestand. Heb je een mail-adres daarvoor? (Je mag het ook via een persoonlijk bericht sturen hoor ;) )
Een andere mogelijkheid is om een optie toe te voegen om alle tijden te visualiseren (wellicht ook met keyboard short-cut aan en uit te zetten). Deze tijden worden nu al weergegeven wanneer je de tijdstippen van een groenfase via het toetsenbord wil invoeren, zie hieronder. Zou dit helpen?
Het helpt inderdaad al, al is het nu wel weer jammer dat de vakjes met de tijden overlappen met realisaties, waardoor je bijv. niet meer perfect visueel ziet waar een geelfase zit.

Ik zou dan denk ik toch opteren voor het opnemen van de start- en eindgroentijden in de tabel naast het fasediagram, met daarin de mogelijkheid om te kiezen voor welke realisatie (de eerste of de tweede) je die tijden wilt zien. In COCON zit bijvoorbeeld al zoiets, al werkt dat iets minder intuïtief. Je kan dan wel de verschillende start-/eindgroen momenten per realisatie zien, maar bijv. niet de effectieve groentijd, etc. per realisatie. Die worden dan meteen berekend voor de twee groenfases tezamen.

Wat me daarnaast ook nog opvalt: in het deelschermpje "Tijden aanpassen" dat je erbij hebt geopend, staat dat voor signaalgroep 01 de realisatie duurt van startgroen tot eindgeel. In de praktijk is het echter gebruikelijker om de realisatie te zien van startgroen t.e.m. eindgroen. Het vermelden van eindgeel zou je best kunnen laten staan maar dat zou ik dan wel hernoemen naar "start rood" i.p.v. "eind geel". Mocht je dat echter willen gebruiken om de lengte van een realisatie te wijzigingen, dan zou dit beter kunnen wijzigen in "eind groen". De reden dat een realisatie in de praktijk van startgroen t.e.m. eindgroen wordt weergegeven, is dat als je bijv. een halfstar plan in geeft, dat je daarin het startgroen-moment in geeft en -- je raadt het al -- het eindgroen-moment. Eindgeel is in dat opzicht dus (a) erg ongebruikelijk en (b) erg onhandig omdat je dan, als je zo'n halfstar plan wilt vullen, van dat eindgeel-moment eerst nog de geeltijd met aftrekken om tot het gewenste eindgroen-moment te komen ;)
Super! Dit is echt heel fijn. Jouw constructieve feedback is heel nuttig. Waarschijnlijk ga jij als verkeersregelkundige uit de praktijk nog veel meer nuttige tips hebben :top:
Fijn om te horen! Zoals beloofd zal ik een dezer dagen nog wat dieper testen om misschien hier en daar nog een tip te kunnen geven.

StijnFleuren
zandpaadje
Berichten: 13
Lid geworden op: za 23 feb 2019, 11:02

Re: Automatisch en in enkele seconde de beste (starre) regeling

Bericht door StijnFleuren » za 21 nov 2020, 12:13

Super ik ga deze doornemen!
Natuurlijk. Ik zal wel een voorbeeld mailen van zo'n csv bestand. Heb je een mail-adres daarvoor? (Je mag het ook via een persoonlijk bericht sturen hoor ;) )
Fijn! Ik zal jou een prive bericht met mijn email-adres sturen.
Het helpt inderdaad al, al is het nu wel weer jammer dat de vakjes met de tijden overlappen met realisaties, waardoor je bijv. niet meer perfect visueel ziet waar een geelfase zit.
Hier kan ik beide voorgestelde opties implementeren; de vakjes met tijden zouden ook semitranparant gemaakt kunnen worden zodat je gemakkelijker de realisaties kan zien. Verder zal ik een optie toevoegen om in de tabel te tijden weer te geven. Wellicht dat ik deze zo ga maken dat je hierin ook direct de startgroen en eindgroen tijden kan aanpassen.

Ik heb een lijst gemaakt van jouw feedback punten. Deze ga ik de komende tijd oppakken :D. Ze zullen niet allemaal in de eerstvolgende release zitten, maar ga mijn best doen om ze snel door te voeren.
  • Toevoegen van benadering voor verliestijd (HWCM)
  • Mogelijkheid toevoegen voor optimalisatie fasediagrammen met tijden in tienden van een seconde.
  • Toevoegen mogelijkheid om intergroentijden in te voeren.
  • Import functie voor intergroentijden en ontruimingstijden.
  • Mogelijkheid om startgroen en eindgroen weer te geven in de tabel die weergegeven wordt naast een fasediagram. Mogelijk ook optie toevoegen om alle tijden weer te geven in het fasediagram zelf. Wellicht ook de mogelijkheid geven om in de tabel zelf de startgroen en eindgroen tijden te wijzigen.
  • Bij het aanpassen van tijden van een groenfase (eerdere screenshot) werken met startgroen en eindgroen i.p.v. stargroen en eindgeel.
  • In het overzicht boven het weergegeven fasediagram naast de verliestijd en het capaciteitsoverschot ook de periodetijd van het fasediagram weergeven.
  • Duidelijk maken dat ook in mvt/h ingevoerd kan worden voor de intensiteiten en capaciteiten.
  • Hernoemen tabblad ‘scenario’s’ naar ‘intensiteiten’.