Archief NDOV berichten

[Adriaan van Natijne]

Beste allemaal,

Sinds februari 2011 log (ook) ik de treinbewegingen, eerst de website van de NS, later ook de berichten die via het NDOV worden doorgegeven. Deze historische data bevat een schat aan informatie over de treinenloop tijdens extreem weer, storingen of tijdens een 'gewone' dag. In de loop der jaren heb ik deze data voor uiteenlopende analyses gebruikt, zoals de vraag of het nu sneller was Dt -> Gvc -> Ut of Dt -> Rtd -> Ut te reizen (dat laatste was toen sneller). En hoewel de focus altijd op het spoor is geweest worden sinds 2015 ook de BISON berichten opgeslagen. Het aantal berichten is de laatste jaren explosief gegroeid en inmiddels bestaat de collectie uit zo'n 8 miljard berichten van verschillende soort en hoewel de logger verre van perfect is zijn er weinig echt grote gaten in de data. Het geheel is opgeslagen als een collectie XZ gecomprimeerde CSV bestanden, in totaal een verzameling van zo'n 570 GB (gecomprimeerd). Kortom: een enorme berg data.

Via https://trein.fwrite.org/ heb ik de collectie nu ontsloten, gesorteerd naar logger, kanaal en datum. Het zijn dus ruwe 'opnamen' zonder enige garantie op compleetheid en/of juistheid. De licentie van de berichten zelf is, voor zover verspreid via het NDOV, naar mijn beste weten CC0. Uitzondering hierop zijn de DSI berichten (scans van de NS website) en HAFAS berichten (aankomststaten uit de internationale reisplanner) welke niet via het NDOV zijn binnengekomen - van de inhoud van deze berichten zijn de precieze licentievoorwaarden onduidelijk. De collectie zelf heb ik onder CC-BY geplaatst (oudere versies waren CC-BY-NC-SA, wie deze heeft mag deze nu als CC-BY beschouwen) omdat de verzameling zelf een nieuw archief betreft waar ik zelf een significante bijdrage aan heb geleverd. Uitzonderingen hierop zijn mogelijk, al is het NDOV Loket zelf wat mij betreft de eerste plaats voor (betaalde) bulk data. Ik hoop dat het publiek beschikbaar maken van de data nieuwe (hobby) projecten een snelle start kan geven en ben benieuwd welke toepassingen er voor gevonden zullen worden.

Tot slot een aantal praktische zaken:

• De DSI en HAFAS bestanden hebben de structuur: Tijd, Station, Bericht, (UUID). De overige bestanden hebben de kolommen: Tijd, Bericht, (UUID). De kolom UUID is naar mijn beste weten tegenwoordig in alle bestanden aanwezig, de ZeroMQ envelope is nooit opgeslagen (en dus verloren gegaan).
  
• De naamgeving DVS/DVSPPV etc. geeft aan via welk kanaal de data is binnengekomen en is dus geen voorselectie van de berichten.
• Er is geen deduplicatie tussen loggers, uitgezonderd berichten in 'dedup', die kunnen als uniek worden beschouwd.
  
• Naast de XZ gecomprimeerde archieven slingeren er ook (nog) een aantal GZ en BZ2 archieven. Vaak zijn dit de (beschadigde) originelen die niet als XZ gecomprimeerd konden worden. Daarnaast zijn er archieven die automatisch, min of meer succesvol, hersteld zijn, de originelen daarvan zijn apart beschikbaar.
• De XZ berichten zijn dmv. multi-threading gecreëerd en bestaan uit meerdere blocks, sommige libraries hebben problemen om dergelijke archieven te openen (lezen stopt na het eerste block).
• De encoding klopt niet altijd. In principe zijn de archieven UTF-8, maar helaas zijn hier een hoop uitzonderingen op.
  
• Van bijna elk bestand is naast .csv.xz ook een .hash.csv.xz en .stats.csv beschikbaar.
• .csv.xz bevat de ruwe berichten.
• .hash.csv.xz bevat Tijd, Station, CRC32 (van het bericht) en Type per bericht, in dezelfde volgorde als de berichten. Deze bestanden zijn hoofdzakelijk bedoeld om berichten te kunnen scannen op duplicaten - de type detectie is verre van perfect.
  
• .stats.csv bevat de geaggregeerde statistieken per uur (en station) over de hoeveelheid berichten.
  
• Bij hele oude berichten (2011-2012) is er sprake van een significante clock drift. De berichten zijn wel sequentieel, maar de precieze tijd van ontvangst heeft een marge van ± 5 minuten.
• Het is niet de bedoeling 'live' archieven te verzorgen, de archieven zullen dus weken tot enkele maanden achterlopen.
• De Last-Modified header klopt, doe er je voordeel mee tijdens het maken of bijwerken van een mirror (wget: --timestamping).
  

En tot slot: wees een beetje aardig voor de server! De uplink is niet overdreven (100 mbit) en als iedereen tegelijk een mirror probeert te maken kan het ongetwijfeld kapot (wget verzoek: --limit-rate=3m --waitretry --wait=1 --timestamping).

Hartelijke groet,

Adriaan

[Thomas ten Cate]

Dit is echt supermooi Adriaan, hartstikke bedankt! Goede kans dat we dit binnenkort gaan mirroren, maar we zullen lief zijn voor je server :)

--
Je hebt dit bericht ontvangen omdat je bent geabonneerd op de groep 'openov' van Google Groepen.
Als je je wilt afmelden bij deze groep en geen e-mails van de groep meer wilt ontvangen, stuur je een e-mail naar openov+un...@googlegroups.com.
Ga naar https://groups.google.com/d/msgid/openov/60310298-c50f-4d6f-8928-8d8b0f7a99ac%40googlegroups.com om deze discussie op internet te bekijken.

[Stefan de Konink]

Goedemiddag,


Het lijkt me goed om ook nog even een "officiele" reactie te geven.
Allereerst zijn wij blij dat meer partijen het belang zien van historische
data, iemand moet er mee beginnen en het is dus fijn dat er een ecosysteem
ontstaat waarin meerdere bronnen worden opgeslagen en verrijkt. Er is zowel
met Simon als met Adriaan overlegd dus denk als lezer niet dat dit uit de
lucht komt vallen.

Doet het financieel pijn? Stichting OpenGeo is een algemeen nut beoogende
instelling, er is geen winstoogmerk en we draaien (mede door) historische
informatie zwarte cijfers. Dat gezegd hebbende kregen alle universiteiten
en hogescholen het hele archief al voor niets en zijn we al tijden met
DANS-KNAW bezig om de historische dataset volledig beschikbaar te maken.
Dat historische data geld oplevert was dus een soort van first mover
advantage die het andere ndov-loket niet zag en waarmee wij de begroting
rond kregen. De logging heeft altijd buiten het distributie netwerk
gedraaid, dus OpenGeo had geen technisch voordeel ten opzichte van een
willekeurige andere partij die dit ook als kans zag.

De reden dat de dataset nog niet bij DANS-KNAW staat is omdat al onze data
redundant wordt verzameld. Ik ben technisch geinteresseerd of wij cijfers
kunnen publiceren hoe goed onze beschikbaarheid is geweest. Dat kan alleen
door alle ontvangers te vergelijken. We loggen "row" based met een tijd
prefix en in het begin hebben niet alle KV6-loggers dezelfde versie
gedraaid dus bij sommige berichtjes ontbraken er coordinaten die volgens de
oude KV6 standaard niet mochten. Dat vereist een intelligente vergelijking
op meer dan 2TB aan data...

Het is tof dat we nu historische berichten hebben. Een maandje geleden heb
ik op verzoek een poging gedaan om alle IFF-dienstregelingen te verzamelen
uit alle backups, ook dat is gelukt... nu weet ik dat we daarmee een beter
archief dan NS zelf hebben. Ik ben via-via op zoek naar een IFF bestand van
eerder dan NDOV. Dat zou helemaal interessant zijn voor academische
vergelijkingen :)


Ik denk wel dat we Adriaan met z'n allen kunnen ondersteunen. Op dit moment
is de download via HTTP. Ik kan me voorstellen dat we iedere dag een nieuw
bittorrent bestand maken waardoor de data via een groot aantal bronnen
gedownload kan worden. Bijvoorkeur wel in 1 compressie formaat en wellicht
kunnen we ook het compressie algoritme primen met de datasets, waardoor de
omvang nog iets kleiner wordt.


Adriaan, keep up the good work!


--
Met vriendelijke groet,

Stefan de Konink
(namens Stichting OpenGeo)