Scenarionetwerk Openbaar Vervoer

Scenarionetwerk OV

De Mobiliteitsscan maakt voor het uitgangsscenario  een gereduceerd OV-netwerk. Hiervoor worden buiten het studiegebied bepaalde haltes uit het netwerk verwijderd. De selectie van haltes voor het gereduceerde netwerk gaat als volgt:

• Alle OV-lijnen uit het bronnetwerk worden geselecteerd, mits deze in het relevante dagdeel een headway (volgtijd) groter dan 0 hebben (lees: ze rijden in het betreffende dagdeel).
• Alle haltes uit het bronnetwerk worden geselecteerd welke:
  • In het studiegebied liggen; of
  • In het relevante dagdeel modaliteit trein of metro hebben; of
  • In het relevante dagdeel haltetype ‘begin/eindhalte’ of ‘eerste overstaphalte’ hebben.
• Er moet altijd minimaal een modaliteit en haltetype voor het dagdeel bekend zijn, zelfs als de halte in het studiegebied ligt. Dit kan alleen als in dat dagdeel tenminste één OV-lijn gebruik maakt van de halte.
• De halteparen van de geselecteerde OV-lijnen worden samengevoegd waar deze haltes bevatten die niet geselecteerd zijn. Er blijven daarmee alleen halteparen over bij geselecteerde haltes. Hierdoor ontstaat een gereduceerd netwerk.
• Bij het samenvoegen van twee halteparen worden de reistijden van beide halteparen bij elkaar opgeteld en er wordt 30 seconden extra halteertijd (dwell time) toegevoegd.

Scenarioreistijden OV

De Mobiliteitsscan berekent reistijden OV tussen zones op basis van het scenarionetwerk voor OV.  Hiervoor wordt een kortste-paden (Dijkstra) algoritme gebruikt. Hiervoor worden de volgende stappen uitgevoerd:

Voedingslinks genereren (tussen zones en haltes)

In een OV-netwerk stellen voedingslinks het voor- en natransport voor vanaf een zone naar de opstaphalte en vanaf de uitstaphalte naar een andere zone. Voedingslinks worden niet bij het OV-netwerk geïmporteerd, maar worden door de Mobiliteitsscan gegenereerd.

Het genereren van voedingslinks gebeurt analoog aan de berekening bij auto en fiets altijd aan het begin van de scenarioberekening voor het zoeken van de kortste route (middels Dijkstra-algoritme). Dit geldt zowel voor de berekening van het uitgangsscenario als bij het berekenen van maatregelen.

Bij het genereren van voedingslinks gelden de volgende regels:

• Gevonden haltes binnen een bepaalde afstand worden doorlopen op volgorde van kortste afstand van de zone naar de langste afstand.
• Een halte wordt alleen geselecteerd als er een lijn stopt die niet bij een eerder geselecteerde halte voor deze zone ook al stopte.
• De volgende 4 stappen worden voor iedere scenariozone uitgevoerd:
  • Selecteer alle haltes binnen 2 kilometer hemelsbreed.
  • Indien er nu géén HOV-haltes (HOV-bus of HOV-tram) zijn geselecteerd:
    Selecteer maximaal 1 HOV-halte tussen 2 en 4 kilometer hemelsbreed.
  • Indien er nu nog niet op 2 unieke OV-lijnen wordt aangesloten:
    Selecteer alle haltes binnen 10 kilometer hemelsbreed totdat er op 2 unieke OV-lijnen wordt aangesloten.
  • Selecteer alle treinstations binnen 10 kilometer hemelsbreed.

Dit levert voor de scenariozone een lijst haltes op, de voedingslinks worden dan tussen de zone en iedere halte getekend.

De voedingslinks die nu gegenereerd zijn hebben een hemelsbrede lengte, deze moeten we voorzien van een reistijd. Dit gebeurt  als volgt:

• De hemelsbrede afstand wordt vermenigvuldigd met 1,2
• Afstand 0 tot 333 m: lopen à Snelheid 4 km/h
• Afstand 333 m tot 4,08 km: fietsen à Snelheid 15 km/h
• Afstand boven de 4,08 km: auto à Snelheid 50 km/h

Bij een gecorrigeerde afstand van 333 m of meer zijn er dus meerdere snelheden op de voedingslink van toepassing, dit vertaalt zich uiteindelijk in één ‘gewogen’ snelheid (gewogen o.b.v. afstand).

De gecorrigeerde hemelsbrede afstand samen met de gewogen snelheid leiden tot een reistijd welke in het Dijkstra algoritme gebruikt kan worden.

OV-netwerk inlezen en voedingshaltes aanwijzen

Het OV-scenarionetwerk wordt ingelezen als een lijst haltes en een lijst halteparen. Bij de halteparen is vastgelegd welke OV-lijn er overheen rijdt, inclusief modaliteit en headway.

De lijst met haltes kan gefilterd worden op haltes waar een voedingslink op aangetakt is. Deze haltes geven we de term ‘voedingshaltes’. Deze voedingshaltes hebben een aparte status. Er hoeven bijvoorbeeld alleen halte-halte-reistijden tussen voedingshaltes bepaald te worden.

Looplinks genereren

Tussen alle haltes die binnen een bepaalde afstand van elkaar af liggen, wordt een looplink gelegd. De looplink staat voor de tijd die het een reiziger kost om zich lopend van de ene naar de andere halte te verplaatsen (en vervolgens de reis te vervolgen). Dit is bedoeld als onderdeel van een overstap. Een looplink kan in beide richtingen gebruikt worden.

Looplinks worden geplaatst tussen alle haltes die maximaal 200 meter uit elkaar liggen. Als één van de haltes een trein- of metrostation is dan mogen de haltes 500 meter uit elkaar liggen.

OV-netwerk opblazen met wachttijden

De halteparen bevatten de zogenaamde in vehicle reistijden, en de looplinks bevatten looptijden tussen haltes, maar er zijn ook twee soorten wachttijden van belang. Namelijk:

• wachttijd voor instappen aan het begin van de reis
• wachttijd bij overstap (op dezelfde halte, of na lopen naar een andere halte)

Die wachttijd is afhankelijk van de headway van de OV-lijn waar opgestapt wordt, aangezien dit bepaalt hoe vaak per uur die bus of trein langskomt.

Het zou handig zijn als deze wachttijd als kosten op een halte gezet konden worden, en dat die kosten dan afhankelijk zouden zijn van de volgende knoop/lijn in de route. Maar zo werkt het Dijkstra-algoritme niet. Daarom wordt het netwerk opgeblazen met ‘virtuele haltes’ en ‘virtuele links’ om hetzelfde te bereiken. Dit gaat als volgt:

Allereerst worden de OV-lijnen uit elkaar getrokken. Op iedere halte wordt een virtuele lijnspecifieke halte gemaakt per passerende OV-lijn. Ieder haltepaar mag nu alleen gebruik maken van de virtuele lijnspecifieke haltes die horen bij de OV-lijn van het haltepaar.

De oorspronkelijke haltes doen nu niet meer mee, en de looplinks zijn tijdelijk ‘ontkoppeld’.

In onderstaand plaatje is dit te zien. Om de weergave te verduidelijken zijn de virtuele haltes los van elkaar getekend, maar in het rekennetwerk hebben deze dezelfde coördinaten.

Nu moeten de lijnen aan elkaar geknoopt worden zodat het weer mogelijk is om over te stappen. Voor dit doel wordt een virtuele overstaphalte aangemaakt op iedere halte waar er meerdere virtuele lijnspecifieke haltes liggen. Er wordt een overstaplink toegevoegd tussen iedere virtuele overstaphalte en virtuele lijnspecifieke halte. Op deze overstaplink komt de wachttijd bij het overstappen, gebaseerd op de headway van de OV-lijn waar de link op aansluit.

Er worden ook virtuele overstaphaltes en overstaplinks toegevoegd voor de haltes waar oorspronkelijk looplinks mee verbonden waren.

Nu dit is gebeurd kunnen de looplinks opnieuw in het netwerk worden gehangen. Deze worden enkel tussen de virtuele overstaphaltes geplaatst en dit zorgt ervoor dat ook na het lopen tussen haltes de wachttijd van toepassing is.

Als laatste worden de virtuele instaphaltes en instaplinks toegevoegd. Een virtuele instaphalte wordt aangemaakt voor iedere ‘voedingshalte’, dus iedere halte waar een reis kan beginnen. Een virtuele instaphalte verbindt met iedere virtuele lijnspecifieke halte op die halte.
Op de instaplink komt de wachttijd bij het instappen aan het begin van de reis, gebaseerd op de headway van de OV-lijn waar de link op aansluit.

Op deze manier kan de route berekend worden zonder bij het instappen last te hebben van de wachttijden bij het overstappen.

Let wel: Ondanks dat we hier de term instaphaltes en -links hanteren, worden deze ook gebruikt als uitstaphaltes en -links aan het einde van de reis. Echter bevat de link in die richting geen wachttijd.

Rekennetwerk met reistijden opbouwen

Het opgeblazen netwerk kan nu in het Dijkstra-algoritme worden geladen. Het betreft hier de halteparen, overstaplinks, looplinks en instaplinks.

Voor iedere link moet een reistijd in minuten worden vastgelegd. Deze reistijd wordt gebruikt om de totale reistijd van de snelste route tussen twee haltes te bepalen.

In onderstaande paragrafen worden deze reistijden toegelicht. Voor halteparen is de reistijd de in-voertuigtijd rekening houdend met halteertijd. Aangezien halteparen éénrichting zijn, is de reistijd op de terugweg ‘oneindig’, dat wil zeggen: deze route kan niet genomen worden.

Halteertijd (dwellTime)

Halteertijd is de wachttijd bij tussenliggende haltes als onderdeel van je reis, wanneer je reeds in een eerdere halte bent ingestapt. In de Mobiliteitsscan wordt een halteertijd van 30 seconden gehanteerd.

Het opgeblazen OV-netwerk heeft hier géén voorziening voor. Dit is op te lossen door de halteertijd toe te voegen aan de in-voertuigtijd van een haltepaar. Er is er dan echter altijd één te veel. Als bijvoorbeeld een route wordt gevonden met drie aansluitende halteparen A -B - C - D, dan betreft het twee tussenliggende haltes (B en C). Dit wordt gecorrigeerd door de halteertijd weer te verwijderen van de instaptijd en de overstaptijd, aangezien instaplinks en overstaplinks gebruikt moeten worden om een haltepaar te kunnen bereiken.

Een incorrecte situatie is als een route via een looplink naar de uitstaphalte gaat. Er moet dan vanaf de looplink eerst een overstaplink worden genomen, voordat de uitstaplink te gebruiken is. Die overstaptijd is dan onterecht en tevens wordt éénmaal halteertijd teveel verwijderd. Deze situatie zal echter zelden voorkomen door de combinatie van een hoog aantal voedingslinks en de aggregatie van halte-reistijden naar zone-reistijden. Er is dan een grotere kans dat er al een betere uitstapmogelijkheid is voordat de looplink wordt genomen.

Overstaptijd (transferTime) en instaptijd (accessTime)

Overstaptijd wordt berekend op basis van de headway van de lijn waar naar overgestapt wordt.

transferTime = headway_0–20min × 50% + headway_20–60min × 25%

Bij een headway van 30 minuten is de som dus 20 × 0,5 + 10 × 0,25 = 12,5 minuten. In deze formule kan de wachttijd nooit boven 20 minuten uitkomen.

De wachttijd bij het instappen aan het begin van de reis is lager, omdat een reiziger meestal rekening houdt met vertrektijden. Ook dit is op basis van de headway van de lijn waar ingestapt wordt.

accessTime = headway_0–15min × 50% + headway_15–30min × 25% + headway_30+min × 15%

In beide gevallen is er in de tegengestelde richting (‘uitstappen’) geen wachttijd/reistijd.

Looptijd (walkTime)

Voor looplinks is de omrijfactor op de hemelsbrede afstand gelijk aan 1,5, omdat bij overstappen vaak extra tijd nodig is voor bijvoorbeeld trappen en kruispunten. De looptijd op looplinks is bepaald op basis van die gecorrigeerde hemelsbrede afstand en een loopsnelheid van 4 km/h. De looplink kan in beide richtingen gebruikt worden.

Gewogen reistijden voor kosten

Snelste routes worden met het Dijkstra-algoritme gezocht op basis van de (laagste) link-kosten. Voor het OV-netwerk worden de kosten gevuld met een gewogen versie van de hierboven beschreven reistijden. Hierdoor kunnen de gevonden routes net iets anders uitpakken. In de reistijdenmatrix wordt wel de ongewogen reistijd van die route opgeslagen. Het wegen vindt plaats als volgt:

Waarbij:

• inVehicleTimeFactorPerMode: 0,8 voor trein, metro, tram en HOV-tram; 1,0 voor bus, HOV-bus, veerboot, overig
• waitTimeFactor: 1,5
• transferPenalty: 3,8 minuten
• accessPenalty: 0 minuten
• walkTimeFactor: 1,5

Routes zoeken om halte-halte reistijden te berekenen

Nu er per link gewogen en ongewogen reistijden bepaald zijn, kunnen de routes worden gezocht en wordt er een halte-halte reistijdenmatrix (in geheugen) gemaakt.

Het is niet de bedoeling dat binnen een route een instaplink als ‘sluiproute’ wordt gebruikt, dus dat deze ergens halverwege een gevonden route voorkomt. Dit wordt opgelost op dezelfde manier als voor voedingslinks in de autotoedeling.

De voedingshalte  wordt opgedeeld in een instapknoop en een uitstapknoop. Het routezoeken moet altijd beginnen op een instapknoop en routes worden opgevraagd tot aan een uitstapknoop. Omdat het éénrichtingslinks betreft kan een route nooit door een voedingshalte heen gaan.

Deze methode kan niet voorkomen dat een route via een instaplink het netwerk opgaat, en dan direct via een andere uitstaplink het netwerk weer verlaat. We beschouwen dit als een ongeldige OV-reis.

Een ongeldige OV-reis is een route welke geen enkel haltepaar raakt. In de halte-halte reistijdenmatrix wordt deze cel op een hele hoge waarde gezet die staat voor onbereikbaar.

Het is goed om te realiseren dat dergelijke routes alleen achteraf als ongeldig verklaard kunnen worden. Het is niet mogelijk om tijdens het routezoeken deze routes weg te filteren en daarmee op het beste geldige alternatief uit te komen.

Wel is het zo dat bij het bepalen van de zone-zone reistijden deze ongeldige OV-reizen door de hoge reistijd alsnog als weggefilterd kunnen worden beschouwd, aangenomen dat er geldige alternatieven aanwezig zijn tussen twee zones. Gegeven het hoge aantal haltes waarop via voedingslinks wordt aangetakt, is dit aannemelijk.

Ook wordt de diagonaal van een halte-halte reistijdenmatrix op onbereikbaar gezet, zodat bij het bepalen van de zone-zone reistijden er geen routes beschouwd worden die dezelfde instap- en uitstaphalte hebben (en desondanks toch halteparen raken).

Voedingslinks en halte-halte reistijden combineren tot zone-zone reistijden

Reistijden tussen zones kunnen nu worden bepaald zonder routes te zoeken. Het is de snelste combinatie van een voedingslink vanaf herkomstzone (voortransport) + halte-halte reistijd + voedingslink naar bestemmingzone (natransport).

In vergelijking met auto en fiets heeft een zone voor OV veel meer en langere voedingslinks naar omliggende haltes, en daarmee zijn er ook veel meer mogelijkheden tot het vinden van een snelste combinatie. Omdat halte-halte relaties zonder halteparen op onbereikbaar zijn gezet, zal er bijna altijd een reistijd gebruikt worden welke een OV-lijn benut. Is zo’n reistijd niet te vinden dan is de zone-zone relatie ook onbereikbaar voor OV.

De voortransport en natransport tijden op de voedingslinks worden gewogen. Het gaat om een wegingsfactor van 1,3 op de looptijd. Dit simuleert dat mensen liever iets langer in de bus zitten ten opzichte van langer moeten lopen. Deze weging wordt alleen gebruikt voor het vinden van de snelste combinatie. De reistijd welke in de zone-zone reistijdenmatrix terecht komt blijft ongewogen. Door de maximale loopafstand van 333 meter op voedingslinks heeft deze weging alleen in zeldzame gevallen effect.

De diagonaal van de uiteindelijke zone-zone reistijdenmatrix wordt op 0 gezet, aangezien dit gebruikelijk is voor scenariomatrices.

Dit is de laatste stap in de scenarioberekening van OV-reistijden. Er is nu een scenariomatrix welke op de standaardwijze gebruikt kan worden in de Mobiliteitsscan. Bijvoorbeeld het bekijken van een verschilkaart in de module “Reistijd van/naar een zone” zodra er een maatregel is genomen die invloed heeft op het OV-netwerk of de scenariozones.