OV-planner via iOS 6?

[Geert]

Om je hier een beeld van te vormen: Connexxion is ruim een jaar bezig geweest met het aanbieden van een goede feed aan Google Transit. Google is erg nauwkeurig over de ontvangen data en heeft een validatieprogramma dat bijvoorbeeld detecteert dat een bus tussen twee haltes bizar hard moet rijden om de dienstregeling te kunnen rijden; dat soort zaken worden als fout teruggegeven. Te veel fouten = geen opname in Google Transit.
Maar Connexxion kwam er bijvoorbeeld ook achter dat allerlei haltes verkeerd ingemeten waren, vooral losse haltes in de provincie. Dat was niet eerder aan het licht gekomen doordat er toch geen haltes in de buurt waren waardoor de halteomroep in de war raakte.

Enfin, door onder meer dit soort redenen zijn niet alle vervoerders al in Google Transit zijn opgenomen.

[webguy]

Overigens geheel terecht dat Google zo strict is - anders krijg je een bagger product... (wacht, wie levert in Nederland ook al weer zoiets?)

[Chauf21]

Het is enerzijds wel goed dat er een goede controle is, maar anderzijds is een dienstregeling vaak ook iets dat voorkomt uit allerlei compromissen en bewuste keuzes. Heel star vasthouden aan een bepaald format werkt dan ook averechts. Zo kan men er bewust voor kiezen om rijtijden niet helemaal realistisch in een dienstregeling op te nemen. Ik kan me zo voorstellen dat niet alle vervoerders er op zitten te wachten om hun eigen keuzes te veranderen voor een partij die eigenlijk buiten hun formele netwerk staat.
Dat neemt overigens niet weg dat een universele standaard wenselijk zou zijn en ik het fijn zou vinden als er betere OV-data beschikbaar zou zijn :)

[iljitsch]

Hier is goed te zien hoe de ramp die Amsterdam heeft getroffen het Centraal Station volledig heeft weggevaagd… Alleen de paar treinsporen doen ons nog herinneren aan wat ooit was.

Het bizarre is dat de meeste stations er wel op staan. Een kleine steekproef: Den Haag HS zowel als Den Haag Hollands Spoor, Moerwijk, Laan van NOI, Voorburg, Ypenburg, Zoetermeer Oost, Rijswijk, Delft, Delft Zuid, Schiedam, Schiedam Nieuwland, Rotterdam Centraal (+ nog eens als Centraal Station), Rotterdam Hofplein, Rotterdam Zuid staan erop. Evenals de voormalige stations van de Zoetermeerlijn en de Hofpleinlijn en de meeste/alle Rotterdamse metrostations.

Maar niet Den Haag CS. Zoetermeer, Rotterdam Blaak en metrostation Beurs pas na 2 x extra inzoomen en opzichte van de meeste andere stations.

[Geert]

Het is enerzijds wel goed dat er een goede controle is, maar anderzijds is een dienstregeling vaak ook iets dat voorkomt uit allerlei compromissen en bewuste keuzes. Heel star vasthouden aan een bepaald format werkt dan ook averechts. Zo kan men er bewust voor kiezen om rijtijden niet helemaal realistisch in een dienstregeling op te nemen.

Een voorbeeld van wat Google niet wil en wat je soms wel zit in dienstregelingen is bijvoorbeeld:

12:30:00 Dorpsstraat
12:30:00 Grote Kerk
12:30:00 Winkelcentrum
12:30:00 Bejaardentehuis
12:38:00 Eindpunt

Dan moet je minstens 30 seconden tussen de haltes stoppen, bijvoorbeeld (afhankelijk van de afstand e.d.)

Andere checks van Google zijn op bijvoorbeeld haltes die op exact dezelfde plek liggen maar in de brondata als verschillende haltes zijn ingevoerd. Soms kan dat een bewuste (politieke) keuze zijn, maar in de meeste gevallen gaat het om slordig ingevoerde data.

[Somoht]

Het is enerzijds wel goed dat er een goede controle is, maar anderzijds is een dienstregeling vaak ook iets dat voorkomt uit allerlei compromissen en bewuste keuzes. Heel star vasthouden aan een bepaald format werkt dan ook averechts. Zo kan men er bewust voor kiezen om rijtijden niet helemaal realistisch in een dienstregeling op te nemen. Ik kan me zo voorstellen dat niet alle vervoerders er op zitten te wachten om hun eigen keuzes te veranderen voor een partij die eigenlijk buiten hun formele netwerk staat.
Dat neemt overigens niet weg dat een universele standaard wenselijk zou zijn en ik het fijn zou vinden als er betere OV-data beschikbaar zou zijn :)

Voor Nederland is die universele standaard er al, de BISON koppelvlakken. Voor de statische dienstregeling is dat Koppelvlak1.
Mijn inziens een beter standaard dan GTFS.
Toevallig draai ik dat validatieprogramma heel vaak en sterker nog samen met Stefan de Konink van OpenOV.nl hebben ik deze week wat vanuit Koppelvlak1 in GTFS omgezette feeds (Arriva,EBS,HTM) aangeboden via het Google Transit Partner programma. En daar ook de validatierapporten van ingezien etc. Je hebt overigens warnings&errors. Warnings zijn de dingen zoals 2 haltepunten exact op de zelfde plaats, bus rijdt gemiddeld 200 km/h tussen twee haltes etc. Errors zijn de foutmeldingen die eventuele import ook echt verhinderen. Kun je denken aan een bus die op halte 2 om 22:00 vertrekt en op halte 3 om 21:48 weer aankomt.
Zie hier bijvoorbeeld een validatierapport van de GTFS zoals 9292 die genereerd.
gtfs.openov.nl/9292/2012-08-16-validation-results.html#ErrorInvalidValue

En echt 99% van die too-fast waarschuwing komt omdat de meeste planningpakketten (Quintiq wat GVB gebruikt uitgesloten) op de minuut afronden. Dan krijg je dus het verhaal dat een bus die om 11:29:31 (wordt dus 11:30) van halte 1 vertrekt en aankomt op halte 2 om 11:31:29 (wordt dus 11:31), door de afronding een afstand van 2 minuten en 2 seconden afrond tot 1 minuut. Zo krijg je dus dit soort megasnelheden

En dan zwijg ik nog over sommige busbedrijven waar het echt een zooitje is en er hele ritten met dezelfde vertrektijd aanwezig zijn, haltepunten inderdaad verkeer ingemeten zijn. Of zelfs haltes met RD coordinaten 0,0 wat dus in Frankrijk ligt :X

[webguy]

Google wil inderdaad op de seconde precieze data - dat was geloof ik voor Connexxion ook lastig.

[Somoht]

Google wil inderdaad op de seconde precieze data - dat was geloof ik voor Connexxion ook lastig.

Connexxion heeft dat nog steeds niet overigens. Alleen GVB heeft dat voor elkaar
GVB is echt koploper qua reisinformatie, met Quintiq planning en straks een goede manier om snel dienstregelingswijzigingen te publiceren (KV1delta) en Kv6 (actuele voertuigposities) van de metrolijnen.

[Chauf21]

Maar is dat het allemaal wel waard? Google stelt m.i. te hoge en strikte eisen aan de dienstregelingdata en gaat voorbij aan achterliggende keuzes die gemaakt zijn. Ik ken genoeg ritten waar je binnen één minuut vier haltes kan passeren en met de ov-chipkaart kan het hartstikke handig zijn om aparte haltes aan te houden. Controle is prima, maar stel niet te hoge eisen aan je leveranciers omdat men anders onnodige kosten moet gaan maken en men daartoe niet bereid is.

Liever één extra rit dan een dienstregeling die enkel puur theoretisch op de seconde is uitgewerkt.

[Somoht]

Maar is dat het allemaal wel waard? Google stelt m.i. te hoge en strikte eisen aan de dienstregelingdata en gaat voorbij aan achterliggende keuzes die gemaakt zijn. Ik ken genoeg ritten waar je binnen één minuut vier haltes kan passeren en met de ov-chipkaart kan het hartstikke handig zijn om aparte haltes aan te houden. Controle is prima, maar stel niet te hoge eisen aan je leveranciers omdat men anders onnodige kosten moet gaan maken en men daartoe niet bereid is.

Liever één extra rit dan een dienstregeling die enkel puur theoretisch op de seconde is uitgewerkt.

Kijk in Nederland hebben we jaaaaren lang 9292 gehad, een beetje een garbage-in garbage-out fabriek, gespecialiseerd om alle troep die je er in gooide omvormde tot een enigszins werkende routeplanner.
Nu wil iemand een routeplanner maken die wel werkt, dus niet verstoord raakt omdat er wordt afgerond op een minuut.
Bij Quintiq van de GVB, kan je perfect een (ook een te ruimte) dienstregeling maken waar binnen 1 minuut 4 haltes aangedaan worden. Bijvoorbeeld 1=00:00:00, 2=00:00:15, 3=:00:00:30, 4=00:00:59. Bij de andere vervoerders wordt dat dus 1=00:00:00, 2=00:00:00,3=00:01:00,4=00:01:00. Hierdoor zegt de vervoerder in feite dus: van halte 1 naar halte 2 doe je 0 seconden, dat klopt gewoon niet. Het gaat om dit verhaal ook meer om de tijden tussen haltes dan de nauwkeurigheid van die tijden. Ook bij het voorspellen van de tijden op DRIS'sen is het buitengewoon nuttig als je een minimale of iig een gemiddelde tijd tussen 2 haltes hebt.
Beter vraag is waarom ooit geaccepteerd is van de leveranciers dat dit soort situaties kan ontstaan. Ik vermoed dat dit enigszins komt omdat reisinformatie is uitbesteed aan adviseurs & 9292 en er niet veel kennis aanwezig is bij bepaalde vervoerders

[Geert]

Liever één extra rit dan een dienstregeling die enkel puur theoretisch op de seconde is uitgewerkt.

Het is natuurlijk niet alleen Google die er wat aan heeft als de brondata op orde is. Verkeerde informatie kan erg hinderlijk zijn voor reizigers, zeker voor degenen die ergens niet vaak komen en fouten dus ook niet herkennen (een vervallen halte die nog in het systeem staat bijvoorbeeld). Met dit soort initiatieven komt er veel meer nadruk op een goede administratie (voor zover de ov-chipkaart daar al niet aan had bijgedragen). Initieel misschien een hoop werk, maar wel voor een goed doel.

[Chauf21]

Oh, controle op de datasets is ook niet verkeerd, maar de voorwaarden die nu worden gesteld zijn soms wel onnodig hoog om toetreding tot bepaalde diensten mogelijk te maken.

Dat dienstregelingen technisch allemaal preciezer kunnen worden gemaakt, dat geloof ik wel. En ik zie er ook wel de voordelen en mogelijkheden van in, maar wat mist is de afweging in hoeverre het ook daadwerkelijk nuttig is.
Decennialang, misschien wel eeuwenlang, heeft men dienstregelingen op minuten gemaakt. Dat volstaat in vrijwel alle gevallen. Het lijkt mij ook niet realistisch en verstandig om dienstregelingen tot op secondes te gaan publiceren (misschien bij metrosystemen of bij agv's, maar dan houdt het ook wel op). De exacte rijtijd tussen twee haltes is toch nooit zo precies voorspelbaar. Waarom moeten er nu dan ineens kosten (en soms ongewilde aanpassingen) worden gemaakt om te voldoen aan één of andere partij die dat wel eist?
Of het gebrek aan expertise daar een oorzaak of gevolg van is, durf ik zo niet te zeggen.

[Somoht]

Oh, controle op de datasets is ook niet verkeerd, maar de voorwaarden die nu worden gesteld zijn soms wel onnodig hoog.

Dat dienstregelingen technisch allemaal preciezer kunnen worden gemaakt, dat geloof ik wel. En ik zie er ook wel de voordelen en mogelijkheden van in, maar wat mist is de afweging in hoeverre het ook daadwerkelijk nuttig is.
Decennialang, misschien wel eeuwenlang, heeft men dienstregelingen op minuten gemaakt. Dat volstaat in vrijwel alle gevallen. Het lijkt mij ook niet realistisch en verstandig om dienstregelingen tot op secondes te gaan publiceren (misschien bij metrosystemen of bij agv's, maar dan houdt het ook wel op). Waarom moeten er nu dan ineens kosten (en soms ongewilde aanpassingen) worden gemaakt om te voldoen aan één of andere partij die dat wel eist?
Of het gebrek aan expertise daar een oorzaak of gevolg van is, durf ik zo niet te zeggen.

Juist op een dienstregeling waar de tijden tussen haltes relatief kort zijn, laten we zeggen de gemiddelde stadsbus doet per minuut één bushalte aan, is het statistisch gezien ontzettend belangrijk dat de tijden tussen halte-paren een gemiddelde of misschien zelfs beter de mediaan is van alle tijden over die dienstregelingsperiode. Zodoende is de tijd tussen twee haltes zo realistisch mogelijk.
Gaat die tijden altijd of zelfs vaak kloppen? Nee natuurlijk niet, het is onmogelijk om op de seconde te voorspellen zeker op een lange tijd vooruit, door bv. weersomstandigheden of onverwachte drukte. Het gaat erom dat gemiddeld zulke tijden in voldoende percentage kloppen. Ik kan je wel vertellen dat de kans dat een bus twee haltes in 0 seconden aan doet ongeveer even groot is als de kans dat pasen en pinksteren op dezelfde dag vallen.
Of het nuttig is? Ja dat is zeker nuttig bij het maken van een routeplanner, een routeplanner werkt door middel van de afstanden tussen twee knopen in een graaf. Ziet de routeplanner, heej ik kan daar 750 meter in 0 seconden afleggen dan gaat die planner daarvoor. Nu hebben de meeste planners daartegen wel algoritmes maar het is zeker ruis die de planning verstoren.
En het is niet één partij, het is één partij die tot nu toe daar nog nooit om heeft gevraagd. Onder andere omdat 9292 van de vervoerders is en dus doet wat de vervoerders willen.
Een andere partij die belang heeft bij een accuratere dienstregeling is een partij als GOVI (GOVI stuurt meer dan de helft van de DRIS'sen in Nederland aan) die Koppelvlak6(*) gebruikt om de op basis van die dienstregeling en op basis van de opgeslagen gemiddelde punctualiteit (gemiddelde van kv6 punctualiteit) en gemiddelde stoptijd, eigenlijk onmiddelijk na het beginnen van de rit de verwachte tijden gaat berekenen. Juist ja op de seconde.

Koppelvlak6 is het protocol wat bussen uitzenden met hoe ver ze voor/achter op schema rijden, wanneer ze arriveren op een halte en wanneer ze weer vertrekken. Ook wanneer een bus afwijkt van de normale route wordt die uitgezonden. Daarnaast ook nog de huidige positie en de afgelegde afstand. De bus stuurt zo'n bericht één keer per minuut en bij arriveren/passeren halte is ieder een apart bericht.
Koppelvlak 6 gaat al een stuk accurater worden als bussen vaker zo'n voorspelling doorgeven, de Finnen doen dat in Helsinki één keer per seconde (!). Er kan immers een hoop gebeuren in een minuut: stoplicht op rood, brug open, een halte waar het opeens heel druk is etc.

Waarom het vroeger nooit gedaan werd? Simpel zulke gegevens waren niet voorhanden, vroeg moest je op elke rit iemand met een stopwatch zetten. Nu heb je een schat aan gegevens met de gemiddelde tijden etc. Ook zijn planningspakketten dankzij technische vooruitgang ontzettend veel geavanceerder geworden. Vroeger moest dat allemaal gedaan worden in dure rekencentra.

Overigens ben ik niet helemaal op de hoogte hoe het gegaan is tussen Google & Connexxion, zover ik weet zijn te hoge snelheden niet direct een afkeurcriteria, ik kan wel vertellen dat er nog steeds onmogelijk hoge gemiddelde snelheden zitten in Connexxion dienstregelingen.

/edit wat voorbeelden.

High speed travel detected in trip CXX|L023|149173|7013|0: De Rips, Boswachterij to Milheeze, Kerk. 2996 meters in 60 seconds. (180 km/h).
High speed travel detected in trip CXX|L145|149216|4052|0: Eindhoven, Catharina Zh Oost to Eindhoven, Tempellaan. 2659 meters in 60 seconds. (160 km/h).
High speed travel detected in trip CXX|R032|149762|4059|0: Stompwijk, Meer- en Geerweg to Zoetermeer, Muzieklaan. 2306 meters in 60 seconds. (138 km/h).

[iljitsch]

Zijn er mensen die er wat voor voelen om alle treinstations op te zoeken zodat we bij Apple een lijst in kunnen dienen van welke ontbreken?

Eén of twee provincies moet in een uurtje wel te doen zijn, heel Nederland is me wat veel van het goede...

En eventueel ook metrostations.

[webguy]

Alle stations kunnen we zo doorgeven - somoht heeft alle perrons zelfs ingeklikt...

[Somoht]

Alle stations kunnen we zo doorgeven - somoht heeft alle perrons zelfs ingeklikt...

Jep, licentievrij hebben we zowat alle perrons in Nederland. Plus alle bushaltes(tot op niveau individuele haltes)/metrohaltes/tramhaltes/veerpunten. Licentievrij dus Apple kan er mee doen wat ze willen.

[iljitsch]

Het leek me handiger om alleen die die ontbreken door te geven. :-)

Maar misschien dat het mogelijk is de info met coordinaten en officiele namen door te geven. Ik zat net nog een formuliertje in te vullen met de vraag hoe deze info het best bij Apple ingediend kan worden.

Maar wellicht hebben ze ook interesse in de volledige lijst. Het lijkt me dat ze in principe ook de database van öpnvkarte.de moeten kunnen importeren. Het zou een enorme verbetering zijn als ze ook bus- en tramhaltes op de kaart zouden hebben.

[Somoht]

Het leek me handiger om alleen die die ontbreken door te geven. :-)

Maar misschien dat het mogelijk is de info met coordinaten en officiele namen door te geven. Ik zat net nog een formuliertje in te vullen met de vraag hoe deze info het best bij Apple ingediend kan worden.

Maar wellicht hebben ze ook interesse in de volledige lijst. Het lijkt me dat ze in principe ook de database van öpnvkarte.de moeten kunnen importeren. Het zou een enorme verbetering zijn als ze ook bus- en tramhaltes op de kaart zouden hebben.

De meeste bushaltes op OPNV karte/OpenStreetMap zijn 2-3 jaar geleden geimporteerd. De bushaltes uit de recente Koppelvlak1 bestanden zijn een stuk actueler.

[Chauf21]

/edit wat voorbeelden.

High speed travel detected in trip CXX|L023|149173|7013|0: De Rips, Boswachterij to Milheeze, Kerk. 2996 meters in 60 seconds. (180 km/h).
High speed travel detected in trip CXX|L145|149216|4052|0: Eindhoven, Catharina Zh Oost to Eindhoven, Tempellaan. 2659 meters in 60 seconds. (160 km/h).
High speed travel detected in trip CXX|R032|149762|4059|0: Stompwijk, Meer- en Geerweg to Zoetermeer, Muzieklaan. 2306 meters in 60 seconds. (138 km/h).

Dit zijn dus dingetjes waar Google zich wat mij betreft niet mee moet bemoeien.
Een dienstregelingminuut kan, zoals eerder gezegd, 89 tot eventueel 119 seconden zijn. Binnen die tijd kan je prima een afstand van 2,5 km afleggen. Zolang de dienstregeling op minuten wordt gepubliceerd, is de dienstregelingstijd dus gewoon goed.

Natuurlijk zijn er veel voordelen als je een dienstregeling preciezer kan publiceren. Je kan dan inderdaad preciezer voorspellen wanneer een voertuig arriveert. Hartstikke fijn als dat zo ontwikkeld kan worden.

Maar, als een vervoerder zijn of haar dienstregeling gewoon op minuten wil publiceren, dan moet daar ook gewoon de ruimte voor zijn. Want een vervoerder wil dat graag zo publiceren (anders had men het wel anders gedaan), dus waarom zou je dat dan tegenhouden? Een derde partij moet daar niet heel rigide tussen gaan zitten. Je krijgt dan namelijk dat andere partijen niet met je willen samenwerken (in dit geval de data willen of kunnen aanleveren) en je product of dienst weinig te bieden heeft.

Dus ja: harstikke fijn als dienstregelingen preciezer kunnen worden gepubliceerd en ik zou het ook toejuichen als vervoerders dat willen doen, maar als vervoerders het anders (maar dus niet fout) aanleveren, dan zou daar geen partij tussen moeten zitten die dat tegenhoudt omdat díe partij er een eigen denkwijze over heeft.

[Somoht]

/edit wat voorbeelden.

High speed travel detected in trip CXX|L023|149173|7013|0: De Rips, Boswachterij to Milheeze, Kerk. 2996 meters in 60 seconds. (180 km/h).
High speed travel detected in trip CXX|L145|149216|4052|0: Eindhoven, Catharina Zh Oost to Eindhoven, Tempellaan. 2659 meters in 60 seconds. (160 km/h).
High speed travel detected in trip CXX|R032|149762|4059|0: Stompwijk, Meer- en Geerweg to Zoetermeer, Muzieklaan. 2306 meters in 60 seconds. (138 km/h).

Dit zijn dus dingetjes waar Google zich wat mij betreft niet mee moet bemoeien.
Een dienstregelingminuut kan, zoals eerder gezegd, 89 tot eventueel 119 seconden zijn. Binnen die tijd kan je prima een afstand van 2,5 km afleggen. Zolang de dienstregeling op minuten wordt gepubliceerd, is de dienstregelingstijd dus gewoon goed.

Natuurlijk zijn er veel voordelen als je een dienstregeling preciezer kan publiceren. Je kan dan inderdaad preciezer voorspellen wanneer een voertuig arriveert. Hartstikke fijn als dat zo ontwikkeld kan worden.

Maar, als een vervoerder zijn of haar dienstregeling gewoon op minuten wil publiceren, dan moet daar ook gewoon de ruimte voor zijn. Want een vervoerder wil dat graag zo publiceren (anders had men het wel anders gedaan), dus waarom zou je dat dan tegenhouden? Een derde partij moet daar niet heel rigide tussen gaan zitten. Je krijgt dan namelijk dat andere partijen niet met je willen samenwerken (in dit geval de data willen of kunnen aanleveren) en je product of dienst weinig te bieden heeft.

Dus ja: harstikke fijn als dienstregelingen preciezer kunnen worden gepubliceerd, maar als de vervoerder het anders (maar dus niet fout) aanlevert, dan zou daar geen partij tussen moeten zitten die dat tegenhoudt omdat díe partij er een eigen denkwijze over heeft.

Nogmaals, Google is niet zo streng, deze dienstregeling van Connexxion is immers opgenomen in Google Transit. Google streeft echter naar nauwkeurigere dienstregelingen, om beter routes te kunnen geven. Dat doe ze door de datafeeds te valideren en de dingen die zij constateren terug te melden naar de vervoerders zodat deze weer een beter feed kan afleveren. Daarbij categoriseren ze dingen als fouten of als waarschuwingen. Een fout is bijvoorbeeld een haltepaal die te ver van het haltegebied staat, een halte zonder lengte/breedtegraad, een busrit waar tijden verwisseld zijn (halte 4 vind plaats voor halte 3). De rest zijn waarschuwingen waar Google, op transit partner validatie website, zelf over zegt dat het de bedoeling is om er zo veel mogelijk op te lossen waar mogelijk.
Een andere reden waarom ze de te hoge gemiddelde snelheid waarschuwingen geven is als een halte verkeerd is gepositioneerd, bijvoorbeeld een halte in Zaandam in Eindhoven.
Het probleem met afronden is precies zoals je zegt dat een dienstregelingsminuut 89 tot 119 seconden kan duren. Dit betekend dat de afrondingsfactor bijna 100% uit kan maken van de gepubliceerde tijden. En ik snap dan ook wel dat de tijd tussen haltes ontzettend flexibel kan zijn naar gelange de omstandigheden, maar het is best mogelijk om tijden tussen haltes te publiceren die in helft van de gevallen voldoende kloppen. De snelheden in voorbeelden die ik aanhaalde zullen in ieder geval nooit gehaald worden.
De dienstregelingstijd is dan wel goed genoeg voor een busboekje, maar een routeplanner kan op deze manier niet de tijdsduur te bepalen tussen twee haltes, dan krijg je dus dat Google een route voorschotelt om tussen halte 1 en 2 met de bus te gaan, terwijl het sneller kan zijn om dat stukje te lopen. Afronden op seconden is dan ook de denkwijze van meerdere partijen, niet alleen Google. Ik snap dan ook waarom Google zegt, dat er een minimale kwaliteit (die is niet zo hoog als jij denkt) aan de data moet zitten. GOVI stelt ook eisen aan de data en ik vermoed dat die een stuk hoger zijn dan Google.

Overigens zelfs als de vervoerder de tijden in seconden in de ruwe data zet, is het prima mogelijk om afteraf in busboekje, websites en DRIS'sen af te ronden op minuten. Iets wat op DRIS'sen in de praktijk ook gebeurd, aangezien het merendeel zijn opgemaakt vanuit de Mijkseneaar standaard die of aftelt op minuten of (bij geen locatieberichten) de dienstregelingstijd in minuten geeft. Intern krijgt zo'n DRIS de voorspelling tot op seconden.

[Klaasje]

Het plannen in kortere tijdseenheden dan minuten is helemaal niet vreemd in de ov-wereld. Het geeft gewoon een tijd die dichter bij het praktijkgemiddelde of praktijkpercentielwaarde uitkomt dan afronden op hele minuten. Dat niet alleen voor het plannen maar ook voor DRIS-sen is het van belang om het nauwkeuriger te doen.

In Almere is het bijvoorbeeld ook goed te merken. De rijtijd is net iets meer dan een minuut tussen de meeste haltes. Om de dienstregeling kloppend te maken wordt er tussen de meeste haltes een minuut gerekend en dan om de paar haltes twee minuten en bij bochten soms bij twee haltes achter elkaar.

Leuk, maar als de bus bij de laatste halte met een korte rijtijd die extra minuut al bijna opgebruikt heeft heeft die volgens de systemen +1 terwijl die bij de twee volgende haltes anderhalve minuut goed kan rijden. Dan krijg je op een DRIS te zien dat de bus "oponthoud" heeft en een paar minuten later vertrekt terwijl die gewoon op tijd vertrekt. De gemiddelde reiziger snapt dat niet en voor dit type reiziger wordt de reisinformatie onbetrouwbaar terwijl een reiziger die het snapt (en de gebruiksvriendelijkheid van de systemen ook niet nodig heeft) precies weet wat er aan de hand is.

[isadora]

Ik, als reiziger en niet zo ingewijd in de materie, kan (en wil) alleen maar het volgende zeggen.
Sinds mijn registratie in dit forum heb ik nog geen boeiender bijdrages gezien, als deze van Somoht.
Erg leerzaam en het getuigd mij van een prima kennis van zaken. :pos: :pos: :pos:

[Somoht]

Het plannen in kortere tijdseenheden dan minuten is helemaal niet vreemd in de ov-wereld. Het geeft gewoon een tijd die dichter bij het praktijkgemiddelde of praktijkpercentielwaarde uitkomt dan afronden op hele minuten. Dat niet alleen voor het plannen maar ook voor DRIS-sen is het van belang om het nauwkeuriger te doen.

In Almere is het bijvoorbeeld ook goed te merken. De rijtijd is net iets meer dan een minuut tussen de meeste haltes. Om de dienstregeling kloppend te maken wordt er tussen de meeste haltes een minuut gerekend en dan om de paar haltes twee minuten en bij bochten soms twee haltes achter elkaar.

Leuk, maar als de bus bij de laatste halte met een korte rijtijd die extra minuut al bijna opgebruikt heeft heeft die volgens de systemen +1 terwijl die bij de twee volgende haltes anderhalve minuut goed kan rijden. Dan krijg je op een DRIS te zien dat de bus "oponthoud" heeft en een paar minuten later vertrekt terwijl die gewoon op tijd vertrekt. De gemiddelde reiziger snapt dat niet en voor dit type reiziger wordt de reisinformatie onbetrouwbaar terwijl een reiziger die het snapt (en de gebruiksvriendelijkheid van de systemen ook niet nodig heeft) precies weet wat er aan de hand is.

De situatie die jij beschrijft word ook voornamelijk veoorzaakt omdat bussen nu maar eens per minuut en op aankomst/vertrek halte een positie&punctualiteitsbericht (KV6) versturen. Zoals je zegt, een bus kan in een korte tijd zijn vertraging oprijden. Hier wordt door GOVI (de instantie die de DRIS'sen in oa. Almere voedt) al in zijn voorspellingen rekening mee gehouden tot op zeker hoogte.
Als vervoerders net zoals in Finland per seconde, of in ieder geval bij grote puntualiteitswisselingen wordt verstuurd, zou dit probleem grotendeels getackeld worden. Finland heeft zelfs een website waar je continu bussen/trams kan volgen, dit is dan ook geen interpolatie zoals bij de kubus.mailspool treinkaart. http://transport.wspgroup.fi/hklkartta/

/edit

Oh ja in Mijksenaar standaardweergave, de betekenis van de tekst "oponthoud" is dat de voorspelling niet is opgeschoten. Beter gezegd, om 13:09 kwam bij de DRIS de voorspelling vertrek om 13:02:33 en om 13:10 de voorspelling dat dezelfde bus om 13:03:33 of later vertrekt. Dan begint de DRIS te knipperen "oponthoud"

[Klaasje]

De situatie die jij beschrijft word ook voornamelijk veoorzaakt omdat bussen nu maar eens per minuut en op aankomst/vertrek halte een positie&punctualiteitsbericht (KV6) versturen. Zoals je zegt, een bus kan in een korte tijd zijn vertraging oprijden. Hier wordt door GOVI (de instantie die de DRIS'sen in oa. Almere voedt) al in zijn voorspellingen rekening mee gehouden tot op zeker hoogte.

Dus een bus verstuurt niet ook zijn positie wanneer die een bepaald vast punt als een halte passeert? Bij ETCS Level 2/3 gebeurt het met een vast tijdsinterval (30 s) of wanneer een baken wordt gepasseerd.

[Somoht]

De situatie die jij beschrijft word ook voornamelijk veoorzaakt omdat bussen nu maar eens per minuut en op aankomst/vertrek halte een positie&punctualiteitsbericht (KV6) versturen. Zoals je zegt, een bus kan in een korte tijd zijn vertraging oprijden. Hier wordt door GOVI (de instantie die de DRIS'sen in oa. Almere voedt) al in zijn voorspellingen rekening mee gehouden tot op zeker hoogte.

Dus een bus verstuurt niet ook zijn positie wanneer die een bepaald vast punt als een halte passeert? Bij ETCS Level 2/3 gebeurt het met een vast tijdsinterval (30 s) of wanneer een baken wordt gepasseerd.

Ja, eens per minuut en op aankomst/vertrek. Dus als een bus aankomst&vertrek bij een timingpoint (halte/brugwachters/KAR punten/financierswissels/zonegrenzen) geeft deze een bericht ARRIVED/DEPARTURE. Als een bus langdurig stil blijft staan, komt er ook een bericht.
Ook als een bus afwijkt van de route zoals in de dienstregeling bepaalt wordt er een bericht verstuurd.