Data
Aan de slag met open OV data
Vandaag heeft Google naar buiten gebracht dat zij in samenwerking met OpenOV en 9292 actuele reisinformatie beschikbaar stellen. Nederland is hiermee het eerste land ter wereld waar deze informatie voor het gehele land beschikbaar is.
Onlangs heb ik tijdens één van mijn treinreizen geprobeerd om zelf iets in elkaar te “hacken”, wat beter aansluit bij mijn informatiebehoefte.
Hierbij kwam ik snel bij OpenOV, waar veel datasets aanwezig zijn. Helaas is het niet altijd even duidelijk hoe alles werkt en waar de data zelf te vinden is.
Met dit blog geef ik antwoord op die vragen en laat ik zien hoe je er zelf mee aan de slag kunt.
Totstandkoming
In Nederland is de projectgroep GOVI bezig geweest met het standaardiseren van reisinformatie. Dit heeft gezorgd voor een goede interoperabiliteit.De standaarden die hieruit zijn voortgekomen worden ook wel koppelvakken genoemd. De meeste koppelvlakken zijn bedoeld voor het dynamische reizigersinformatiesysteem (DRIS).
De gegevens worden ontsloten via OpenOV het NDOV loket. Dit zijn beide projecten van Stichting OpenGeo.
Verkrijgbaarheid
De geplande (statische) dienstregeling (Koppelvak 1) is voor iedereen verkrijgbaar bij OpenOV. Wil je ook gaan werken met actuele informatie, zoals de vertrektijden per halte dan is deze onder voorwaarden ook verkrijgbaar na aanmelding. Als alles in orde is gemaakt en je IP-adres is toegevoegd aan de firewall, kun je de gewenste gegevens via een messages-queue verkrijgen.
Vlak |
Omschrijving |
Verkrijgbaar via |
KV1 |
geplande dienstregeling en informatie over routes en haltes voor een bepaalde periode |
OpenOV, ND-OV |
KV6 |
berichten waarin elk voertuig minimaal elke minuut meldt waar het zich bevindt en wat de afwijking is van de dienstregeling |
ND-OV |
KV7 |
geplande dienstregeling per haltepaal voor een paar dagen |
|
KV8 |
actuele vertrektijden per halte op basis van positie voertuigen |
|
KV7/8 turbo |
variant van KV 7/8 waarmee voor alle haltes efficiënt de benodigde informatie wordt verzonden voor internet en mobiele toepassingen |
OpenOV |
KV15 |
vrije teksten van de verkeersleiding voor schermen bij haltes (extreem weer, stakingen, wegopbrekingen) |
ND-OV |
KV17 |
wijzigingen van de geplande dienstregeling door de verkeersleiding voor schermen bij haltes (‘rit vervallen’). |
ND-OV |
KV19 |
actuele passagetijd per halte |
Real-time OV informatie via REST API
Mocht je het niet echt zien zitten om eerst een hele backend op te zetten voordat je weet of je er iets mee kunt, dan kun je ook kiezen om snel aan de slag te gaan met een REST API.
Hierbij wordt wel uitdrukkelijk verzocht om niet te veel requests te doen. Gelukkig zit de REST API prettig in elkaar, en kun je met één request informatie over meerdere entiteiten opvragen. Ook is er code te vinden waarmee je zelf een REST API op kunt zetten met behulp van de gegevens uit de message-queue.
Werken met de real-time gegevens via PubSub
Voor de meeste toepassingen is de real-time feed natuurlijk het meest interessant.
Hoewel de voorbeeldcode die te vinden is in de mailinglist en op Github veelal in Python is geschreven, ben je daar niet toe verplicht. Voor vrijwel elke programmeertaal (ook JavaScript) zijn er bindings beschikbaar.
Het principe is simpel, je opent een verbinding naar de berichtenserver en abonneert je(subscribed) op het kanaal die de berichten bevat die je wilt ontvangen.
Deze ontvang je via push-berichten, hierdoor hoef je zelf niet steeds een request (pull) te doen zoals bij de REST API wel het geval is. Afhankelijk van de feed moeten er nog nabewerking-stappen uitgevoerd worden voordat je de data kunt gebruiken.
Bij KV78turbo is het doel efficiënt de benodigde data over te sturen ten behoeve van de volgende use-case:
Een haltepaal server heeft de actuele tijden van de passerende bussen nodig.
Hierbij wordt ervan uitgegaan dat de statische gegevens al aanwezig zijn en alleen de afwijkingen daarop worden doorgegeven. Dit geeft de gelegenheid om de relaties tussen koppelvlakken uit te leggen en zal ik daarom verder als voorbeeld gebruiken.
KV8turbo is een variant op KV8, de niet-turbo variant is in XML formaat en daarmee een stuk groter dan dat eigenlijk nodig is, zeker gezien veel zaken zoals de plaats van de bushalte altijd hetzelfde blijft.
Je kunt twee soorten “pakketten” verwachten:
- KV8turbo_passtimes: actuele passeertijden en passage gerelateerde berichten
- KV8turbo_generalmessages: berichten voor een halte
Deze berichten worden verstuurd in het CTX-formaat. Het is een functioneel alternatief voor CSV. Hierdoor kunnen meerdere objecten verpakt (serialized) worden in één bericht met een lage overhead.
De documentatie is erg volledig in zowel het formaat als de structuur van de berichten, dus ik ga hier niet dieper op het formaat in.
De berichten bevatten identifiers naar de statische planning (KV7):
Verwijst met (DataOwnerCode, DestinationCode) naar DESTINATION. Verwijst met (DataOwnerCode, LocalServiceLevelCode, OperationDate) naar LOCALSERVICEGROUPVALIDITY. Verwijst met (DataOwnerCode, UserStopCode) naar USERTIMINGPOINT. Verwijst met (DataOwnerCode, LocalServiceLevelCode, LinePlanningNumber, JourneyNumber, FortifyOrderNumber, UserStopCode, UserStopOrderNumber) naar LOCALSERVICEGROUPPASSTIME. Verwijst met (DataOwnerCode, LinePlanningNumber) naar LINE. Verwijst met (DataOwnerCode, TimingPointCode) naar TIMINGPOINT
(Bron documentatie pagina 7)
Hiermee kun je net zoals de halte-displays de vertraging tonen in een app zoals OVDelay doet.
General Transit Feed Specification Reference (GTFS)
De GTFS specificeert een gemeenschappelijk formaat voor openbaar vervoerschema’s en de bijbehorende locatiegegevens, dit is ook de specificatie die het mogelijk maakt om planningen en geografische informatie naar Google Maps en andere diensten te sturen.
Een feed bestaand uit een aantal tekstbestanden in een ZIP-archief. Bij Google kun je uitgebreide uitleg vinden over deze tekst-bestanden.
De gegevens van de Nederlandse vervoerders zijn via OpenOV ook in GTFS beschikbaar.
De specificatie maakt het tevens mogelijk om via GTFS-RT realtime wijzigingen op de planning door te geven.
Toepassing van open OV data
Leuke en nuttige toepassingen van de open OV data zijn ook:
http://plannerstack.github.io/whitelabel/ – Open source multi-modale reisplanner (op basis van GTFS)
http://www.ovradar.nl – Realtime locaties van openbaar vervoer-voertuigen in Nederland
http://www.rijdendetreinen.nl/ – App met treinlengtes bij vertrektijden
Ik ben benieuwd wat jij gaat bouwen, veel succes!
Djuri Baars
Laatste berichten van Djuri Baars (toon alles)
- Aan de slag met open OV data - 2 juni 2015
Leuk artikel!
Misschien nog wel aardig als toevoeging: behalve de koppelvlakken (KV)-standaarden zijn er voor het spoor (alle vervoerders samen) nog specifieke NS-standaarden die ook via NDOV en openOV worden ontsloten.
De backend achter de vertrektijden op rijdendetreinen.nl is open source:
https://github.com/geertw/rdt-infoplus-dvs en https://github.com/geertw/rdt-serviceinfo
Ook hier nog even bedankt voor je reactie, leuk dat je je backend open source beschikbaar stelt!
Ik ben zelf op zoek naar de manier hoe Syntus (Twents) de real-time data deelt, met name de posities. Weet jij dat toevallig? http://www.flyabb.com/livetrein/fullscreen.php heeft ze bijvoorbeeld wel, maar ze zitten niet de KV78turbo / vid strems…
De posities van de bussen zouden als het goed is via BISON koppelvak 6 gedeeld moeten worden (via NDOV). De treinen zullen daar waarschijnlijk niet bij zitten.
De kaart van flyabb.com ziet er erg mooi uit, maar is niet actueel: het lijkt de dienstregeling van een aantal jaar geleden. De posities zullen waarschijnlijk geextrapoleerd zijn op basis van de vertrektijden en de afstand tussen de stations.