Hoppinpunten Workshop 2: Data

Presentatie

• Presentatie VLOCA traject mobiliteit Workshop 2: Data
• Resultaten Mentimeter Stemmingen

Attendance List

• Nils Walravens (imec)
• Stefan Lefever (imec)
• Erwin Hermans (MOW)
• Pieter Morlion (Fietsberaad)
• Eli Nomes (Leuven)
• Bart Scheenaerts (ABB)
• Tjalle Groen (Taxistop)
• Wouter Luyckx (Arcadis)
• Ziggy Vanlishout (AIV)
• Guido Vaganee (VVSG)
• Paul Theyskens (MOW)
• Dimitri Schepers (AIV)
• Bruno Herman (imec)
• Pieter Dresselaers (Igemo)
• Gert Vervaet (Geosparc)
• Ewout Depauw (SOLVA)
• Philippe Michiels (imec)
• Mathias Van Compernolle (imec)
• Anne-Marie Van Asbroeck (imec)
• Koen Triangle (imec)
• Bart Verbeeck (Cegeka)
• Wim Michiels (ANYWAYS)
• Annelies De Craene (AIV)
• Emilie Couwenberg (Stad Antwerpen)
• Rik Hendrix (VITO)
• Rob Van den Berg (imec)
• Gert De Tant (Sirus)
• Natasha Blommaert (AWV)

Introductie

Herhaling van de VLOCA-doelstellingen & Hoe bij te dragen.

Toelichting AIV Relanceplan: Relanceproject MAAS

Door Annelies De Craene (AIV). Doelstellingen:

1. Realiseren we open & interoperabele mobiliteitsdatastromen voor multiple hergebruik: routes, haltes, real-time locatie voertuigen, dienstregeling via het sensor data platform --> datastromen aanbodzijde maas voor multiple hergebruik door Mobiliteitscentrale, Hoppin/Mobipunten, Lokale besturen, etc.
2. Een nieuwe mobiliteitstroom van cameragegevens op (ANPR – Automatic Number Plate Recognition) aangesloten op het sensor data platform. Op deze manier komen ANPR-data geanonimiseerd ter beschikking voor de ontwikkeling van toepassingen.
3. Gepersonaliseerde mobiliteitsdata door een referentie implementatie voor de use case 'mymobility profile' op te zetten.

Momenteel nota in opmaak voor de Vlaamse Regering.

Toelichting OSLO en VLOCA

Door Dimitri Schepers (AIV)

Raakvlakken tussen OSLO en VLOCA-traject mobiliteit:

• Betrokkenheid OSLO in VLOCA-traject vanwege synergie,

maar ook teneinde dubbel werk te voorkomen

• Raakvlakken met reeds bestaande OSLO-trajecten:
  • OSLO Mobiliteit
    • Trips en Aanbod
    • Dienstregeling (in ontwikkeling)
    • Fietsinfrastructuur (nog op te starten)
    • Mobipunten (wordt bekeken)
  • OSLO Openbaar Domein
  • Agentschap Wegen & Verkeer Object Type Library (OTL)

Synergie tussen OSLO en VLOCA

• Van OSLO naar VLOCA
  • Aanreiken van bestaande datastandaarden die ondergebracht kunnen worden in VLOCA
• Van VLOCA naar OSLO
  • Identificeren van noden voor het ontwikkelen van data standaarden

Toelichting data-attributen

Door Stefan Lefever (imec-edit).

De verschillende relevante data-attributes die in de workshop gebruikt werden, zijn toegelicht en op de bijgevoegde slides terug te vinden.

Breakouts

Doel van de breakouts:

• Beter begrijpen wanneer welk type data belangrijk is.
• Beter begrijpen welke data-attributen belangrijk zijn.
• De uitdagingen hierrond goed capteren.
• Lessen trekken naar wat dit betekent voor architectuur en infrastructuur.
• (de volgende workshop)

Input uit de vorige workshop:

1. Alle ideaalbeelden en gekoppelde data werden bij elkaar gebracht om tot drie algemene use cases te komen die tijdens de breakouts verder uitgediept werden:
2. Als (medewerker van) een lokaal bestuur, heb ik relevante data nodig om het gebruik van een hoppinpunt te evalueren.
3. Als dienstverlener/operator, wil ik aan de hand van data in de buurt/aan een hoppinpunt een nieuwe dienst aanbieden voor reizigers.
4. Als reiziger, wil ik de hoppinzuil gebruiker om een vervoersmiddel te boeken en te betalen voor mijn reis.

Voor elke use case werden volgende stappen doorlopen:

• Prioriteren welke soorten van data meest belangrijk zijn
• Welke data-attributen meest belangrijk zijn
• Bespreken waarom dit zo is en wat dat betekent voor architectuur en infrastructuur

Dit in 2 rondes van 30min en gebruik makend van mentimeter als ondersteunende tool. De resultaten van de mentimeter stemmingen kan je | hier raadplegen.

Onderstaande geeft per use case weer welke de belangrijkste datasets bleken en hoe belangrijk bepaalde data-attributen zijn. Er wordt een samenvatting gegeven van het gesprek, per data-attribuut dat besproken werd in de sessie.

Use case 1: Evaluatie van een hoppinpunt

Als (medewerker van) een lokaal bestuur, heb ik relevante data nodig om het gebruik van een hoppinpunt te evalueren.

In deze breakout werden in eerste instantie de datatypes “Aantal passanten”; “Gebruikersprofielen” en “Afgelegde trajecten en overstappen” besproken.

Aantal passanten

• Volume:
  • Big data is belangrijk voor fit-for-purpose oplossingen.
  • Open data is een vereiste.

• Ownership:
  • Verantwoordelijkheid voor aanleveren data

• Semantics:
  • Geen standaardisatie beschikbaar

• Quality:
  • Nauwkeurigheid tellingen passanten is vandaag niet voldoende
  • Hoe kan de data relevant gemaakt worden?

Gebruikersprofielen

• Protection:
  • Bv. Medische gegevens
  • Beschermen privacygegevens
  • Moet op hoger niveau behandeld worden (maas)

• Security:
  • Impliciet gezien vertrouwelijke data

• Ownership:
  • Gevoelig informatie
  • Maas afsprakenkader in ict
  • Middle man om ownership te regelen

Afgelegde trajecten en overstappen

• Volume:
  • Trusted party nodig voor opslag?

• Variety:
  • Veel verschillende formaten en diverse bronnen
  • Connecties tussen mobi-punten
  • Goed catalogiseren

Densiteit

• Semantics:
  • Densiteit moet beter gedefinieerd worden.

Attractiepolen

• Ownership:
• Google heeft hier bepaalde data over die aangekocht kunnen worden.

• Semantics:
• Uniform formaat
• Prioriteren

Sociale mix

• Protection:
  • Moet voldoende geaggregeerd zijn

• Quality:
  • Relevantie van de informatie?

Use case 2: Operator wil nieuwe dienst aanbieden

Als dienstverlener/operator, wil ik aan de hand van data in de buurt/aan een hoppinpunt een nieuwe dienst aanbieden voor reizigers.

In deze break out werden 2 datatypes besproken: “wachttijden” en “trajecten en overstappen”.

Wachttijden

• Protection: 100% zou geanonimiseerd moeten zijn
• Quality:
  • Data moet up to date zijn en betrouwbaar (belangrijkste)
  • Volledigheid/context:
    • Reden waarom wachttijden lang zijn
    • Kadering van de data
    • Redenering van de reiziger: stuctureel versus incidenteel
  • Metadata rond kwaliteit
    • Betrouwbaarheid
    • Juistheid
    • Meetmethode
    • Resolutie
    • …
  • Belangrijke bedenkingen:
    • Vanaf wanneer verandert het gedrag en stopt men met wachten
    • Wachtverzachters: welk effect?
• Semantiek:
  • Betekenis van data moet worden vastgelegd. Wat willen we meten?
    • De tijd dat iemand wacht
    • De tijd voor het volgende beschikbaar vervoersmiddel
    • Rekenen we iemand die onmiddellijk een fiets neemt mee?
• Volume:
  • Risico: Datavolume moeilijk in te schatten
  • Hoeveel data moeten we bijhouden en hoe lang?
    • Retentie en archiveringsbeleid
    • Voor simulatie en predictie: voldoende data nodig (cycli van 1 jaar)
• Eigenaarschap:
  • • Belangrijk om te weten van wie de data komt (onafhankelijk?)

Trajecten en overstappen

• Bemerking rond trajecten en overstappen:

Het meet de status quo en levert opportuniteiten op binnen het bestaande kader. Het meet echter niet de trajecten van autogebruikers. Die trajecten en de motivering van automobilisten zijn een verborgen bron van ov-optimalisatie.

• Protection:
  • Zaak van privacy by design / deontologische code / GDPR
  • Uiteraard wel belangrijkste en een aandachtspunt, anonimiseren moet juist gebeuren

• Volume:
  • Grote volumes
  • Zinvolle data destilleren kan een uitdaging zijn
  • Datavolume groot en moeilijk te voorspellen
    • Retentie en archiveringsbeleid nodig
    • Voor simulatie en predictie: voldoende data nodig

• Semantiek:
  • Wat is overstappen? Ook het laatste stuk te voet is een deel van het traject.
  • Overstappen tussen twee stations op grotere afstand?

Use case 3: Reiziger wil een reis boeken en betalen

Als reiziger, wil ik de hoppinzuil gebruiker om een vervoersmiddel te boeken en te betalen voor mijn reis. In deze break out werden 2 datatypes besproken:

• Tijdstip en frequentie van modi
• Reservatiedata

Tijdstip en frequentie van modi

• Velocity:
  • Een vertraging wil je onmiddellijk weten
  • Snelheid van data is afhankelijk van de issues op het net
  • Dit is enorm gelinkt aan kwaliteit
  • Wat werkt de snelheid tegen?
    • Ondergronds niet het signaal kunnen capteren
    • Onvoldoende devices en niet alle bussen/deelsystemen geven locatie aan -> als je het niet weet, kan je de data niet genereren
    • Je moet weten waar de verschillende modi zijn
  • Infra / architectuur aandachtpunten voor velocity:
    • Detecteren van posities via gps apparaten -> kan makkelijk worden gebruikt om uit te rusten
    • Fietsen hebben geen accu aan boord - wordt het moeilijker
    • Hoeveelheid data die wordt gegenereerd valt mee dus voor architectuur valt dat dan mee, het is belangrijker om een goede dekkingsgraad te hebben om voldoende te weten en te kunnen plannen

• Ownership:
  • Ownership van de data is gekoppeld aan kwaliteit - omdat er dan ook SLA's aan kunnen worden geboden

• Semantics:
  • Is semantiek een probleem?
    • Voor de trein kan je 3 verschillende momenten krijgen wanneer dat die aankomt (op perron, op de app, op het bord). Probleem is dat dit een voorspelling is en dat dit in de toekomst is, maar je weet wel waar hij is voorbij gereden (timestamps) weet je wel of waar de data is verloren en dit dan ook aangeven. Het blijft een voorspelling en dus aangeven op welke manier de voorspelling wordt gemaakt
    • Metadata is hier ook wel belangrijke context mee te geven aan de voorspellingen waarom er bepaalde voorspellingen zijn gedaan.
    • Metadata = de bijsluiter van data en er moet zeker opstaan wat de oorsprong is van de data (officiële instanties,...)
    • Citymapper voorspelt aan de hand van modellen de reistijd als je geen connectie hebt en dat maakt de ervaring beter is
  • Semantics definieert duidelijk wat de inhoud van de data is en wat je ermee kan doen en dus als reiziger waar je op kan rekenen
  • Via linked data heb je op zijn minst al de attributen die erin staan, maar we zijn er vandaag nog niet helemaal
  • Wordt vaak ook beschreven als de ijsberg - maar alles wat onder ijsberg zit rond semantics en die onderlaag is niet te onderschatten

• Quality:
  • Belangrijk dat als je op een mobipunt staat en je een dienst wil gebruiken dat de data correct is om gebruik te maken van de modi. Weten waar de bus naartoe rijdt en in welke richting,...
  • Bij werken/evenementen/afwijkingen -> dit moet ook perfect worden door gegeven
  • Beste app: CityMapper doet het uitstekend, maar de app werkt maar zo goed als de data die wordt ontvangen van de voertuigen
  • Correctheid van de data heeft een ongelofelijke impact op de reiservaring en op de snelheid van jouw reis
  • Wat is een oorzaak van foute data? Trackingdevices moeten worden geïnstalleerd op het voertuig en heel de keten moet worden afgedekt en constant live is in real time (=full stack approach) En hierdoor hangen snelheid en quality wel sterk samen
  • De connectie valt soms weg in de metro -> hiervoor verlies je tracking en dus verlies je de input
  • Ook gegevens van de fietsen zijn belangrijk - real time aangeven hoeveel fietsen er zijn - zodat de verschillende modi beschikbaar zijn / ook de taxi’s hun gegevens real time beschikbaar hebben
  • Antwerpen haalt de data op van Poppy en de laatste 2 weken lag de data plat -> er wordt gekeken naar een SLA afspraak + Transformatie van de data wordt door Antwerpen gedaan zodat de data kan worden mee genomen intern op hun data broker
  • In het vergunningsregelement voor deelvoertuigen worden formaten opgelegd op welke manier ze de data moeten aanleveren, maar dit wel in dialoog met de aanbieders zodat ze op de hoogte zijn van wat er gebeurt

• Architectuuroplossingen:
  • Gebruik maken van de mensen zelf -> via smartphone eigenlijk weet je waar de mens is en waar het voertuig is -> proberen beter in te schatten waar de bus is dan de vervoersmaatschappij zelf
  • Zelf als stad sensoren voorzien op de voertuigen die in jouw stad rijden en op die manier een eigen netwerk opzetten en end 2 end oplossing voorzien
  • Dataformaten verplichten via aanbestedingen en vermijden dat providers op de data blijven zitten omdat ze daar eigenaar van zijn - dit moet worden doorbroken -> Via standaard apis en applicaties aanbieden, en ook op Europees niveau standaardisatie
  • De stap van big data naar smart data -> voorspellende modellen en AI om te weten hoe je jouw reis kan plannen (eg tijdstip dat er geen fietsen zijn op vrijdag omdat een AI systeem dat voorspelt - cfr drukte van google). In hoeverre smart data slim houden en hoe dat verder onderhouden en blijven up to date houden -> Zullen zelf lerende systemen moeten zijn.
  • Bouwblokken laten inbouwen in de eigen applicaties die interopdata uitspuwt -> decentrale gedachten die ervoor zorgt dat data kan worden ontsloten

Reservatiedata

• Security:
  • Er zijn 2 dingen betrokken: persoonsgegevens en het financiële/rekening dat gekoppeld is aan de reserveren -> dit zijn belangrijke items waardoor security belangrijk is
  • Er is een internationale context -> als je naar Helsinki gaat wil ik daar ook kunnen reserveren en door aparte standaarden en lokale standaarden is het moelijk om jouw identiteit kunnen mee nemen op een veilige manier. (quid a-kaart vs de lijn kaart)
  • Hoe kan je dit tackelen?
    • Mydata.org/solid/itsme/kbc
    • Componenten die aligneren met internationale betalings/privacystandaarden (eg. Ik ga naar Londen en ik neem enkel mijn betaalkaart mee -> ik vertrouw mijn bank om dit te regelen)
    • Hoe kan ik mijn identiteit vrijwaren? Personal data management -> pseudonimisering / hashing
    • Ook belangrijk dat je uw eigen data kan beheren en dat je zelf eigenaar bent van uw data (=solid)
  • Ook als je een kind / valies mee hebt wil je dat mee nemen in jouw betaling -> je moet uw profiel kunnen beheren zodat het planningssysteem hiermee rekening houdt - solid bepaalt wie mag welke data zien en dus vermijdt dat de data real time wordt verkocht
  • Hoe kan je dit tacklen - de juiste standaarden gebruiken om forward compatible te zijn
  • Toch nodig om zo veel mogelijk data te hebben, omdat je altijd wel veel zaken wilt weten en dat je bij meta data of afgeleide van data moet weten
  • Architectuur aanpassen aan privacy by design - de dataproducent geeft akkoord om data te gebruiken (eg je moet ervoor betalen als je de data wilt doorverkopen)
  • Goed weten wat je wilt analyseren om te weten welke data je nodig hebt (eg edge computing)
  • Duidelijk bepalen wat er kan gebruikt worden (wettelijk) en dus ook kunnen aangeven tot hoe ver de data kan worden gebruikt.

Volgende Workshop

• De volgende workshop zal focussen op infrastructuur.
• Datum volgende workshop: 8/4 -> In de paasvakantie – nieuw voorstel is 6/5 tussen 13.30 – 16.00 en 4/6 tussen 13.30 – 16.00
• In de tussentijd nodigen we alle deelnemers uit om op de Kennishub bij te dragen aan de inhoud van VLOCA op basis van jullie expertise.