In regelingen waar in DSI data aanwezig is, bijvoorbeeld van KAR meldingen en/of selectieve detectie lussen (zoals VECOM) is het mogelijk de tijdsduur te bepalen tussen de inmelding en het startgroen moment. Dit kan behulpzaam zijn bij het analyseren van de afwikkeling van het OV.
De inmelding wordt als volgt bepaald:
Bij een DSI melding zonder lus nummer (selectieve detectie index 0) wordt gekeken naar het type bericht: in of uit
Bij een DSI melding met een lus nummer (selectieve detectie index 1 of groter) wordt gekeken naar het type lus: in of uit
Het type lus wordt hierbij bepaald op basis van data uit de geladen configuratie.
Merk op: in de huidige versie van YAVV is het bewerken van deze configuratie data nog niet mogelijk
De meting wordt uitsluitend gestart indien de DSI melding een correct signaalgroep nummer heeft, en uitsluitend tijdens status rood van de gerelateerde signaalgroep
Bij een uitmelding tijdens rood wordt de meting afgebroken.
Merk op: voor het juist functioneren van deze analyse is een correcte configuratie van de selectieve detectie nodig. Deze wordt, indien aanwezig, uitgelezen uit de VLOG config (.cfg, .vlc, etc.). Indien afwezig, zal ten minste het type lus juist ingesteld moet worden (in of uit).
De weergave van analyse data gebeurt binnen YAVV en YAVC op een generieke manier: de opbouw van de gebruikersinterface is overal nagenoeg gelijk. De bron van de analyse data kan uiteen lopen:
het kan gaan om analyse data op basis van één bestand of reeks bestanden, zoals gebruikelijk in YAVV; dit is beschikbaar via de knop op de toolbar:
wordt gewerkt met YAVV big-data, dan kan het gaan om gemiddelde data over meerdere dagen, of over data van één specifieke dag uit een reeks
in YAVC-client geldt ook dat het kan gaan om een weergave van data van één specifieke dag, of een gemiddelde over meerdere dagen
Ongeacht de bron: de weergave van de resultaten is steeds hetzelfde opgebouwd. Dit artikel omschrijft die opbouw en geeft een overzicht van de mogelijkheden qua visualisatie (en export) van analyse data.
Een opmerking vooraf: zowel in YAVV als in YAVC wordt bij wisselen van analyse en/of dag altijd zoveel mogelijk gezorgd dat de instellingen worden overgezet (bv: interval, type grafiek, type analyse, etc.). Soms is dit niet mogelijk en moeten bepaalde weergave instellingen na een wisseling van analyse en/of dag opnieuw worden opgegeven.
Opbouw gebruikersinterface
Hieronder wordt de grafische interface voor weergave van analyse data weergegeven:
De volgende onderdelen zijn hier te zien:
Weergave type: tabel, grafiek of lijst met alle metingen
Type grafiek (alleen zichtbaar bij weergave type grafiek)
Waar van toepassing is hiernaast nog een vinkje zichtbaar: weergeven alle metingen
Interval tbv. maken tijdvakken
Knop openen extra analyse opties
Lijst met items binnen de analyse
Snelkoppelingen om alle items van een bepaald type aan/uit te vinken
Selectie van items
Items (signaalgroepen, detectoren, of cyclustijden) kunnen afzonderlijk worden aan- en uitgevinkt (5). Tevens is het mogelijk alle signaalgroepen van een bepaald type in één keer aan of uit te vinken (6).
Wanneer een bepaald item geen metingen heeft, krijgt het een donkergrijze kleur en wordt dit default uitgevinkt.
Type weergave
De volgende weergaven zijn beschikbaar:
Tabel: een reguliere tabel met data per item per tijdsinterval in een grid
Grafiek: dezelfde data geplot in de vorm van een grafiek (lijn, balk, heatmap, etc.)
Alle metingen: een “ruwe” lijst met alle metingen onder elkaar; dit is de brondata
Tabel
Default wordt altijd de tabel weergave geopend. Hierin is een lijst met data te zien, waarbij de data per item wordt weergegeven (kolommen), en wordt opgedeeld in tijdblokken (rijen).
De grootte van de tijdblokken is instelbaar via het interval (3).
Let op: momenteel wordt nog niet gevisualiseerd wanneer er evt. sprake is van onvolledige of ontbrekende data.
Grafiek
Bij weergave in grafiek vorm is er al naar gelang het type analyse de keuze uit:
Lijn – weergave van data middels een lijn per item die loopt in de tijd
Balk – weergave van data middels een balk per item per tijdblok; die is vooral nuttig (want overzichtelijk) bij weergave van weinig items, of een zeer groot interval (bv. 3 uur)
Heatmap – bij deze weergave wordt er per item per tijdblok een kleur geplot; de kleur geeft de hoogte van de meting voor dat tijdblok en dat item aan; hierdoor worden bv. zwaartepunten snel visueel en inzichtelijk
Boxplot – dit is alleen beschikbaar waar het nuttig is: bij analyses die een verdeling van metingen hebben, zoals wachttijd eerstwachtende; de boxplot geeft een indicatie van de spreiding van de metingen
Ook hier geldt: de grootte van de tijdblokken is instelbaar via het interval (3).
Bij weergave in grafiek vorm is het waar sprake is van afzonderlijke metingen met een waarde (bv. wachttijd eerstwachtende) mogelijk alle metingen in de lijn-grafiek weer te geven; wanneer dit mogelijk is verschijnt hiervoor een vinkje rechtsboven de grafiek. Dit levert geen zeer overzichtelijke grafiek, maar maakt het wel mogelijk eventuele pieken in de data te visualiseren en snel te vinden. Stel, in één interval is een met van 10 en 90 sec.; het gemiddelde komt dan uit op 50 sec, waardoor de piek van 90 sec. wegvalt; door gebruik van dit vinkje is de piek toch zichtbaar te maken.
Lijst met alle metingen
Deze weergave toont de achterliggende data: de afzonderlijke metingen die ten grondslag liggen aan de cijfers in de tabel/grafiek. Alle metingen staan hier in een lijst onder elkaar. De data is qua inhoud gelijk voor alle analyses, maar de betekenis van de cijfers loopt soms uiteen.
Deze lijst is vooral handig om snel hoge waarden te filteren uit de data (zie hieronder bij Extra waargave opties bij 5). Daarnaast is het mogelijk te dubbelklikken (of enter toets) op een item in de lijst om naar het betreffende tijdstip te manouvreren.
Extra weergave opties
Middels de tandwiel knop (4) is het mogelijk een aantal aanvullende zaken in te stellen rond de visualisatie van de analyse data:
De opties hier zijn als volgt:
Instellen vanaf waar tot waar de data gevisualiseerd moet worden. Dit is begrent door het begin en einde van de huidige data (in YAVV is dat de geopende data, in YAVC doorgaans de geselecteerde dag)
Let op: start/einde moeten eigenlijk liggen op “hele” interval afstanden vanaf de start van de data. Dit wordt momenteel evenwel niet afgedwongen door de applicatie.
Max. Y-as grafiek: normaal gesproken schaalt de grafiek automatisch mee met de data. Middels deze optie kan de maximale waarde van de Y-as worden vastgezet; hiermee kunnen grafiek op basis van uiteenlopende data gemakkelijk worden vergeleken
Geen kleur voor verborgen items: de applicatie neemt bij elk volgende item de volgende kleur lijn uit een lijst. Ook uitgevinkte items krijgen normaal gesproken een kleur toegewezen. Soms is het handiger als dit niet zo is, zodat tussen verschillende grafieken de kleuren van de lijnen identiek zijn (bv.: intensiteit en intensiteit-fietsers).
Dit is de knop waarmee de extra opties weergegeven/verborgen kunnen worden.
Minimale/maximale waarde meting: dit is enkel van toepassing op de weergave “Alle metingen”; de lijst is middels deze opties in te perken, zodat extreme waarden makkelijker vindbaar zijn. Let op! Vergeet niet dit weer op te heffen, anders lijkt het soms onterecht alsof er geen metingen zijn.
Export
In de toolbar bovenaan het applicatie venster bevinden zich een aantal knoppen waarmee het exporteren van analyse data mogelijk is:
Van links naar rechts zijn hier de mogelijkheden:
Export van de tabel naar Excel (.xlsx)
Export van de tabel naar het klembord (als .csv data, gescheiden met 😉
Export van de grafiek naar een plaatje (.png)
Export van de grafiek naar het klembord
De bigdata addon heeft hier nog een extra optie: exporteren van meerdere dagen tegelijk naar één of meer .csv bestanden. Zie hierover verder de documentatie rond bigdata.
Bij voertuigverliesuren (VVU) gaat het om het totaal aan verloren tijd als gevolg van wachten voor een verkeerslicht voor een bepaalde richting of kruising gedurende een bepaalde periode. Elk afzonderlijk voertuig heeft een bepaalde verliestijd, bijvoorbeeld 10 of 20 seconden. De totale verliestijd voor een bepaald tijdvak omgerekend naar uren geeft de hoeveelheid “voertuigverliesuren”.
Op basis van detectie data zoals deze in de VLOG data zit kan de exacte verliestijd nooit worden bepaald. Immers, het exacte aankomst proces is onbekend. Er zal dus een versimpelde inschatting moeten worden gemaakt. YAVV/YAVC doet dit als volgt:
Verzamelen data:
Bepalen wachttijd eerstwachtende
Bepalen tijdsduur afrijden wachtrij: dit is de tijd na startgroen tot er een voldoende groot hiaat valt
Tellen aantal voertuigen in de wachtrij: voertuigen worden geteld vanaf startgroen tot er een voldoende groot hiaat valt
Voertuigen die afrijden nadat de wachtrij is afgereden hebben een veronderstelde verliestijd van 0 seconden.
Gegeven de verzamelde data:
Het aantal voertuigen in de wachtrij is [N]
Delen van de wachttijd eerstwachtende op het aantal voertuigen uit de wachtrij: dit is [A]
Delen van de tijdsduur afrijden wachtrij op het aantal voertuigen uit de wachtrij: dit is [B]
Met deze drie grootheden wordt de verliestijd per voertuig bepaald:
Voertuig n heeft een verliestijd van [A] * ([N] - n) + [B] * n
Uitleg:
er wordt van uitgegaan dat een voertuig met plaats n in de wachtrij een recht onevenredig aandeel van de wachttijd eerstwachtende heeft gewacht.
er wordt van uitgegaan dat een voertuig met plaats n in de wachtrij een recht evenredig aandeel van de totale tijdsduur afrijden wachtrij heeft gewacht.
de som van deze twee waarden levert de complete verliestijd per voertuig
De totale verliestijd gedeeld door 3600 levert de VVU waarde.
De totale verliestijd van alle voertuigen uit de wachtrij die zijn afgereden levert een waarde per realisatie. Momenteel wordt die waarde weggeschreven op start rood. Bij opdelen van de metingen in intervallen wordt de complete verliestijd waarde op basis van dit tijdstip aan een interval toegedeeld.
Overstaan wordt bepaald door te kijken naar het vallen van een voldoende groot hiaat op de korte of lange lus; gebeurt dit niet, dan wordt de totale verliestijd van de cyclus meegenomen naar de volgende cyclus. Er wordt afgevlakt, en vervolgens krijgt elk voertuig uit de volgende cyclus de afgevlakte verliestijd erbij. Bij meerdere opeenvolgende realisaties met continu overstaan cummuleert zo de berekende verliestijd (met afvlakking).
Merk nog op: deze aanpak kent beperkingen, zie ook hieronder.
Beperkingen
Zoals hierboven reeds benoemd: het gaat bij VVU’s op basis van detectie data altijd op een inschatting. Het algoritme is een extreme versimpeling van de werklijkheid. Deels zal er sprake zijn van onderschatting, deels van overschatting. Middels microsimulaties (met SUMO) is bekeken hoe accuraat het algoritme functioneert. Over het algemeen komt het algoritme redelijk in de buurt van de werkelijke (=in de simulatie gemeten) verliestijden. Bij een normale vormgeving en normale omstandigheden is de afwijking doorgaans niet groter dan 5-10 %.
In de praktijk is er soms sprake van bijzonderheden, waar het algoritme geen rekening mee kan houden. Dit gaat bijvoorbeeld om:
Korte opstelvakken: wanneer verkeer het opstelvak, en dus de detectie, van een richting niet kan bereiken, bijvoorbeeld vanwege een wachtrij bij een aangrenzende richting, zal sprake zijn van een onderschatting van de werkelijke verliestijden.
Overstaan: de analyse houdt rekening met overstaan, maar bij structureel overstaan zal de huidige implementatie komen tot een overschatting van de werkelijke verliestijden; de reden is dat in de praktijk er een maximale wachtrij zal ontstaan, terwijl het algoritme bij opeenvolgend overstaan de wachttijden continu (afgevlakt) cummuleert.
Desalniettemin: wordt rekening gehouden met de genoemde beperkingen, dan biedt de analyse een goede basis om te komen een beoordeling van een kruispunt, en/of een vergelijking te maken tussen een oude en nieuwe situatie.
Instellingen
De volgende instellingen zijn beschikbaar voor deze analyse (default in [blokhaken]):
Minimaal hiaat [1,2 sec.]: het minimale hiaat op de koplus (tussen voertuigen) om de wachtrijmeting (tijdens groen, gedurende het afrijden) af te ronden
Minimaal hiaat korte/lange lus [3.0 sec. / 0.5 sec.]: indien minimaal dit hiaat valt op de korte/lange lus, wordt geconcludeert dat er géén sprake is van overstaan de betreffende realisatie
Afvlak factor overstaan [0.75]: de mate waarin de gecummuleerde verliestijd wordt afgevlakt gedurende overstaan
Check overstaan [waar]: wel/niet kijken naar overstaan
Check status regelen [waar]: indien dit uit staat, loopt de meting door ongeacht de regelstatus [WPS]
Deze analyse zoekt de tijd van start tot einde groen. Indien is ingesteld dat alleen primair groen moet worden gezocht kan dit worden aangevinkt bij de instellingen. In dat geval wordt op einde groen gekeken of het alternatief realiseren bit (BIT7, dus het 8e significante bit in het GUS bericht) op staat. Een realisatie die halverwege wisselt van alternatief naar primair telt dus altijd mee.
Bij wachten zonder reden gaat het om situaties waarin een weggebruiker moet wachten voor een rood licht, terwijl daar gezien de verkeerssituatie geen goede reden voor is. Dit wordt door YAVC/YAVV als volgt bepaald:
Tijdens rood wordt start wachten geregistreerd op basis van koplussen of knoppen
Tijdens groen wordt activiteit op de koplus genomen om voor conflicten van de betreffende richting het wachten te markeren als “met reden”
Hierbij geldt vanaf start groen een instelbare minimale tijd sowieso als “goede reden”
Voor voetgangers is apart een minimale (en vaste) tijd in te stellen die geldt als “goede reden”
Voor voetgangers is mogelijk in te stellen dat de groen hier voor conflicten altijd geldt als “goede reden” om te wachten
Voor wachtende richtingen wordt voortdurend bekeken: is er recent, rekening houdend met de geel- en ontruimingstijd/intergroentijd, nog activiteit gezien op een conflict?
Zo ja: dan wacht de richting met een “goede reden”; was eerder sprake van wachten zonder reden, dan wordt dat op dit moment beëindigd
Hierbij geldt: het moet minimaal een instelbare tijd rood zijn, voordat sprake kan zijn van wachten zonder reden
Zo nee: dan is er sprake van wachten zonder reden
Op start groen worden resultaten verzameld:
Alleen wachten-zonder-reden blokken langer dan een ingesteld minimum worden meegenomen
Er wordt enkel een resultaat weggeschreven indien de totale tijd wachten-zonder-reden hoger is dan een instelbaar minimum
Gezien VLOG als databron en de omschreven aanpak gelden er enige beperkingen:
Er wordt geen rekening gehouden met verkeersregelkundige situaties waardoor bepaalde richtingen “legitiem” niet realiseren, zoals gelijkstarten en andere synchronisaties
Er wordt geen rekening gehouden met verkeersregelkundige situaties waardoor bepaalde richtingen extra groen krijgen anders dan door activiteit op de betreffende richting, zoals nalopen en andere interne koppelingen
Voor voetgangers is de activiteit na start groen normaal gesproken (behoudens bv. bij aanwezigheid van radar) onbekend, en wordt daarom gebruik gemaakt van een instelbare vaste tijd vanaf startgroen die voor conflicten geldt als geldige reden om te wachten
De instellingen die beschikbaar zijn en hierboven zijn genoemd worden hieronder normaals opgesomd, met de default instelling tussen blokhaken:
Minimale tijd wachten zonder reden [2.0]: blokjes wachten zonder reden korter dan deze tijd worden genegeerd
Minimale totale tijd wachten zonder reden [8.0]: indien gedurende een roodfase in totaal minder dan deze tijd zonder reden is gewacht, wordt geen resultaat aangemaakt op start groen
Minimale benutte groentijd [4.0]: gedurende deze tijd vanaf start groen geldt voor conflicten van een richting dat die ongeacht activiteit wachten mét reden
Minimale benutte groentijd voertgangers [4.0]: idem apart voor voetgangers
Controleer status regelen [waar]: indien niet waar, wordt tijdens status anders dan regelen niets gelogd
Groen bij voetgangers geldt altijd als goede reden [onwaar]: indien waar, geldt de complete groentijd bij voetgangersrichtingen voor conflicten als goede reden om te wachten
