VDV454

54 views
Skip to first unread message

Stefan de Konink

unread,
Feb 13, 2024, 7:09:29 PMFeb 13
to ope...@googlegroups.com
Hoi,

Achtergrond: VDV454 een Duitse standaard waar SIRI-ET op is gebaseerd.
Enkele jaren geleden hebben voor Arriva en AVV wat software geschreven
om de Duitse actuele data in VDV454 uit te wisselen. KV6 werd omgezet in
VDV454 en was te zien op de borden. Andersom heeft het ook een tijd
gewerkt, maar zoals wellicht bekend in het geval van RET, is een KV6
stroom met slechts vertrek momenten niet echt hoogwaardig.

In het kader van transparantie dan nu de volgende vraag. Een ruime maand
geleden hebben we aangekondigd dat we wat met SIRI-ET en MQTT hadden
gemaakt. Hoe zouden we om moeten gaan met brongegevens die (nog) niet
onder NDOV vallen, of niet voldoen aan de nationale standaarden hier in
Nederland zijn afgesproken?

1. Wordt verwacht dat we brongegevens in dezelfde kwaliteit delen. In
dit voorbeeld: VDV454 is dan ergens op een message bus beschikbaar, ook
al is dat nergens formeel afgesproken. We beschouwen die ruwe
brongegevens dan als een soort "NDOV-plus".

2. We standaardiseren brongegevens in andere formaten zo goed mogelijk
naar een "nationale" standaard toe en ontsluiten dat resultaat. De
worstenfabriek is niet toegankelijk, het resultaat wel. We beschouwen
dat als hoe openOV in de afgelopen jaren heeft gewerkt.


In de eerste variant zou ik bijvoorbeeld de ruwe ovfiets data uit de
scraper expliciet als een NDOV-plus data product neerzetten. En
hetzelfde doen met deze VDV454 van AVV of positie-informatie van veren
in AIS-formaat. Door de originele bron data aan te bieden kunnen andere
partijen hun eigen conversies maken. Ik vind het bijvoorbeeld jammer dat
andere partijen niet proactief delen wat ze aan broninformatie hebben
verzameld.

De tweede variant aggregeert en standaardiseert, neem de nationale GTFS
data, de GBFS van OVfiets. Een nationale NeTEx-export, SIRI-ET, etc. Het
uiteindelijke product is de defacto standaard wat iedereen gebruikt.

--
Stefan
OpenPGP_0xDA0A21EE7E3D2959.asc
OpenPGP_signature.asc
Reply all
Reply to author
Forward
0 new messages