Presentatie

Workshop 1 presentatie

Attendance List

  • Anne-Marie Van Asbroeck
  • Bram Roelant
  • Ann Verhecken
  • Dieter Cuypers
  • Nele D’haese
  • Annelies Decraene
  • Bart Deproost
  • Annelien Dierick
  • Eli Nomes
  • Ewout Depauw
  • Gert De Tant
  • Rik Hendrix
  • Erwin Hermans
  • Koen Triangle
  • Natasha Blommaert
  • Nils Walravens
  • Philippe Michiels
  • Pieter Dresselaers
  • Pieter Morlion
  • Stijn Piette
  • rob van den berg
  • Bart Scheenaerts
  • Dimitri Schepers
  • Stefan Lefever
  • Stijn Michiels
  • Paul Theyskens
  • Tim Coninx
  • Tjalle Groen
  • Guido Vaganée
  • Maarten Van Loo
  • Gilles Van Onacker
  • Ziggy Vanlishout
  • Gert Vervaet
  • Vincent Van der Linden

Terugblik: het VLOCA Project & mobiliteitstraject

VLOCA Project

Vloca heeft als doel om een Open City Architectuur uit te werken in Vlaanderen. Dit kan gezien worden als een gezamenlijk digitaal bouwplan voor de toekomst. Aan de hand van thematische, technische en projectmatige use cases worden gestandaardiseerde architectuur Componenten vast gelegd die de groei richting slimme steden en gemeenten moet ondersteunen. Co-creatie en inspraak van de vele betrokken partijen (besturen, bovenlokale en regionale overheden, het middenveld, technologiespelers en smart city bedrijven) staat hierbij centraal. Op die manier willen we komen tot gedeelde principes, kennisdeling en Componenten. Dit vertaalt zich in afspraken rond smart city toepassingen, de API’s voor gegevensstromen, data Componenten en afspraken rond technische architectuur. Participatie wordt erg gewaardeerd. Dit kan gebeuren door deel te nemen aan de discussies in de werksessies en op de kennishub. Op dit moment lopen verschillende VLOCA trajecten:

Sinds eind 2024 is de opzet van VLOCA gewijzigd. Meer informatie kan je terugvinden op https://www.vlaanderen.be/lokaal-bestuur/digitale-transformatie/vloca.

Mobiliteitstraject

Deze Workshop 1 bouwt verder op de kennismakingssessie van 10 december 2020 waarbij vele initiatieven rond slimme mobiliteit en in het bijzonder rond hoppinpunten werden gepresenteerd. Het verslag en de verdere verwerking is terug te vinden op de kennishub.

Doelstelling van de workshop vandaag

De doelstelling van de workshop vandaag is om inzicht te krijgen in de informatienoden (behoeftes) en achterliggende waarde van gegevens (doelstelling) ten aan zien van hoppinpunten. Achterliggend idee is dat wanneer we tot efficiënte en effectieve IoT-systemen willen komen; er een context nodig is waarbij data tussen partijen in ver vertrouwen kan uitgewisseld worden. Hiervoor zijn spelregels of governance nodig die verduidelijken waarbinnen data worden gebruikt. Zo is het mogelijk om gericht innovaties te gaan ontwerpen met een maatschappelijke meerwaarde. Hierbij vertrekken we in eerste instantie van uit wensen van gebruikers (in dit geval gedefinieerd als de ‘reiziger’) en de noden vanuit innovatiestandpunt. Om dit te bekomen werd in de werksessie gewerkt in twee opeenvolgende break-out sessies. Tijdens de eerste break-out sessie werd gefocust op het perspectief van professionals en organisaties betrokken in het mobiliteitsveld en hoppinpunten. Dit gebeurde in 4 kleinere groepen. Hierbij stonden telkens volgende vragen centraal: Wat is de ideale toepassing vanuit het perspectief van de professional? Wat ontbreekt er op dit moment om hier toe te komen? Wat zijn specifieke condities om data te delen. Deze vragen werden door verschillende deelnemers en organisaties voorafgaand aan de workshop voorbereid en in de break out sessie toegelicht en gaven de overige deelnemers hier feedback op. Vervolgens, in een tweede sessie werd deze bovenstaande vragen herhaald maar vanuit het standpunt van de reiziger, die gebruik kan/wil maken van de diensten in de context van een hoppinpunt.

Inventarisatie van gewenste applicaties

Lokale Overheden – Intercommunales - Vervoersregio

  • De output van een IoT-systeem moet hapklare informatie aanleveren, zoals hoeveel passanten er zijn bij een bepaald hoppinpunten, welke vervoersmodi er het meest worden gebruikt, op welke manier reizigers hun vervoer reserveren, etc. Steden en gemeenten zullen die informatie dan wel zelf linken aan cijfers over criminaliteit, verkeersongevallen, en dergelijke meer; om in te zetten dus bij de beleidsplanning
  • Vanuit het oogpunt van intercommunales is het belangrijk de vervoersvraag te kunnen opvolgen en linken door gebruik te maken geaggregeerde lokale gegevens en zo beleidsevaluatie toe te laten.
  • Ideale toepassing laat toe om regiospecifieke diensten uit te werken. Hiertegenover staat wel de nuancering dat top-down en op een grotere schaal zaken aanpakken wel nut kan hebben; de ideale oplossing ligt in het midden van deze twee perspectieven.
  • Toepassingen maken monitoren gemakkelijk: Hoeveel reizigers? Hoe vaak worden deelauto’s gebruikt? Wanneer precies? Etc. Met dergelijke informatie kunnen doordachte investeringskeuzes worden gemaakt. Tegelijkertijd kan ook gepeild worden naar de maturiteit van een hoppinpunten.
  • Ideale toepassing denkt vanuit reizigerstrajecten en doorstroming ipv grondgebied of punt in de gemeente
  • Oude haltes als Vervoer_Op_Maat hotspot via derdebetalerssyteem door lokaal bestuur gedragen?

Regionale overheid (AWV)

  • Het Agentschap staat in voor de organsiatie van raamcontracten om hoppin zuilen te plaatsen en ze kenbaar te maken aan gebruikers. Raamcontract dient voor AWV zelf als voor lokale besturen.
  • Dit betreffen analoge zuilen (OTL-standaard) en Digitale zuilen.
  • Sensoren (lees ook het artikel Hoe kies ik een geschikte sensor?) om data te capteren en real time ter beschikking te stellen

Data & ICT Integrator (Digitaal Vlaanderen - gov)

  • In een ideale toepassing faciliteert het agentschap de publicatie van de data en datastromen; geënt op het ecosysteem van de smart city data space: een publicatieketen om realtime data met statische data te koppelen; hoppinpunten zijn hier een onderdeel van, maar de Smart City Data Space of SCDS gaat nog verder
  • Via de Smart City Data Space zullen inplugbare software componenten aangeleverd worden die bedrijven kunnen inpluggen in eigen software. Zodat data niet meer "gelocked" is in één toepassing, maar ook door andere kan aangesproken worden
  • Ambitie is om individuele databrokers met elkaar te doen communiceren
  • Bouwblokken voor managed services tov Open Data

Data & ICT Integrator (privé)

  • Platform voor het samenbrengen van vele databronnen
  • Technologieën en applicaties die op zichzelf data kunnen zoeken en eenmaal geïntegreerd moet die data terug kunnen stromen naar de gebruiker die bepaalde vragen en queries kan stellen. Applicaties zelf moeten de diensten kunnen gaan zoeken. Dus gebruik maken van een gefedereerd platform en data discoverable maken (lees ook het artikel Hoe deel ik mijn data?)
  • Niet alleen data-integratie maar ook nieuwe data generen

Middenveld ((Fietsberaad; Taxistop; Mobipunten vzw) =

  • Sterke visuele weergave van beschikbaarheid van fietsparkeermogeliljkheden en overdekte fietsenstallingen inclusief beschikbaarheid van extra fysieke diensten zoals fietspompen, lockers, herstelautomaat
  • Verdere uitbouw Velopark
  • Eén abonnement voor alle hoppinpunten
  • Gestandaardiseerde verwerking van gegevens van alle vervoersaanbieders adhv TOMP-API

Reizigers

  • Gebruikers zullen waarschijnlijk een aantal verschillende apps ter beschikking hebben, multimodale routeplanners, die hem/haar zullen adviseren. Dergelijke apps zouden volgende functionaliteiten moeten hebben:
  • Zouden alle informatie moeten aanreiken m.b.t. de kortste/snelste/etc. manier om van A naar B te gaan, en dit gebaseerd op (een selectie uit) verschillende vervoersmodi.
  • Zou statische zowel als dynamische info moeten geven. Waar overstappen? Welke faciliteiten zijn er op dit punt allemaal aanwezig? Hoe druk is het op tram of bus? Als ik even wacht, hoe druk is het dan nog op tram of bus?
  • Reserveren van deelauto, deelfiets, etc.
  • Gemakkelijk betalen, en dit voor verschillende formules (abonnement, betalen per rit, maandelijks betalen van vervoerskosten, betalen via facturatie, betalen via palen waarlangs geswiped wordt met een kaart, etc.) of volledige traject in 1 profiel en 1 ticket.
  • Ingeven van bepaalde specificaties moet mogelijk zijn, bv. personen met een motorische of visuele beperking moeten dit kunnen aangeven, personen die een deelauto aanbieden moeten kunnen aangeven dat ze hun eigen auto wensen te gebruiken, etc.
  • Adviseren reizigers op basis van gegevens over trajecten die vaak worden afgelegd, mobiliteitsonkosten die worden gemaakt, etc. in de richting van trajecten die sneller zijn, milieuvriendelijker zijn, gezonder zijn, etc. Ook zou advies kunnen worden gegeven over betalingsformules: Reizigers attent maken op het feit dat ze te veel betalen, bv., en dat het zinvol zou zijn om over te stappen naar een andere betalingsformule.
  • Rekening houden met bestaande digitale kloven: bv interactieve interfaces waarop zoekopdrachten kunnen ingegeven worden op de kiosken
  • Integratie met parkeren en parkeergeleidingssystemen
  • Mogelijkheid tot afweging maken tussen prijs vs tijd
  • Bushaltes die een uniek nummer krijgen om overstap te vergemakkelijken
  • Privacy van de reiziger/burger moet bewaakt worden (lees ook AVG of GDPR)

Benodigdheden om dit te overbruggen

Lokale Overheden – Intercommunales - Vervoersregio

Databronnen en ontbrekende data

  • Methode van reservering van een flexbus (online vs telefonisch)
  • Data up-to-date houden
  • Specifieke data van deelmobiliteit aangeleverd door spelers: bv gebruikersprofielen, trafieken, wachttijden, afgelegde trajecten
  • Voorafgaand voor lokale besturen zijn er gegevens nodig over het potentieel en het toekomstig gebruik van hoppinpunten om de meerwaarde te kunnen berekenen tov andere geografische punten (bv bushalte) en andere infrastructuur en uitrusting (ikv ruimtelijke planning); zoals data over de omgeving van de punten (locatie, densiteit van de buurt, bereikbaarheid, sociale mix, attractiepolen, ..) als ook data over actuele reizigers. Er wordt gewerkt aan een maturiteitsmodel om hoppinpunten te managen, op te volgen en te verbeteren
  • Inzicht en beter begrip over het concept ‘overstappen’ en data van gebruikers hierover
  • Data over de ervaring van de reiziger en de gebruikers van hoppinpunten
  • Data over het gebruik van deelfietsen

Datastromen

  • Eenvoudige visualisaties/dashboarden voor lokale ambtenaren, gezien beperkte capaciteit, kennis en tijd
  • Belang van databrokers om de data te delen, vooral gezien dit data over personen gaat en dus gevoelig zijn
  • Data moeten toegankelijk zijn voor lokale besturen om er hun beleid mee af te stemmen
  • Rol Mobiliteitscentrale is vaag, maar idealiter ondersteunt ze de verschillende stromen in de vorm van een Vlaams Datacenter
  • Bovenlokale inspanningen zijn nodig om datastromen te faciliteren en dus ook vertrouwen tussen partijen

Interoperabiliteit

  • Lokale datastromen, ook die van buiten de gemeentegrenzen integreren
  • Advertenties in applicaties geven de voorkeur aan lokale handelaars
  • Inzetten van de TOMP-API en data standaarden

Businessmodel

  • BM gebaseerd op een eerlijke kost die de klant betaald
  • Kwalitatieve data als basis voor de uitbouw van een business model
  • Samenbrengen van verschillende subsidiebronnen (lokale, toegankelijke infrastructuur;…) openliggend vraagstuk is de plicht/wens/mogelijkheid van lokale besturen om zelf ook mee een deel van de kost te dragen.
  • Onduidelijkheid over bijdrage van lokale spelers en hun bijdrage (Mobiliteitscentrale)
  • Governance model nodig over de te verzamelen data, de correctheid, de verzekering van de dienstverlening,…
  • Nieuwe overheidsdiensten (bv publieke taxi) mogen niet marktverstorend zijn
  • Price-setting mag geen reden zijn om geen data te willen delen
  • Niet alleen samenwerking en openheid nodig tussen providers, maar ook tussen naburige gemeenten vanuit het idee van trajecten.

Regelgevend kader

  • Onduidelijk en ontbrekend regelgevend kader om gegevens uit te wisselen tussen aanbieders en lokaal bestuur en afdwingbaarheid; huidig kader is een gentlemen agreement en afdwingbaarheid onduidelijk (bv samenwerking als toetredingsvoorwaarden)
  • Aanbestedingen door lokale besturen worden beïnvloed door MobCent maar ook van lokale besturen (is nog onduidelijk)
  • Wie kan gebruik maken van de hoppinpunten?
  • Hoe ook info krijgen van niet-aangeslotenen via Mobiliteitscentrale?
  • Modelclausules om inzicht te krijgen hoe data stroomt (lijkt taak voor hogere overheid; ook voor de uitbating op technisch vlak)
  • Huidige contracten tussen overheid en aanbieders zijn vaak niet voorzien voor het visionaire concept

Regionale overheid (AWV)

Databronnen en -stromen

  • Er ontbreekt ‘data’ over welke ‘data’ de gebruiker wenst digitaal te raadplegen via hoppinzuilen en wat dan de nodige databronnen zijn. De use cases zijn nog niet gedefinieerd.
  • Data mbt betalingen tussen verschillende aanbieders onderling: bv De Lijn vs MaaS providers

Interoperabiliteit

  • OTL standaard lijkt aangewezen evt via OSLO MaaS applicatieprofiel

Standaarden

  • Data Standaarden: OSLO MAAS + OSLO Wegen en Verkeer (OTL),
  • Datauitwisselingens Standaarden: Datex II ?, NSGI-LD ?, JSON-LD (is eerder afspraak)?, … andere waarschijnlijk nog ???
  • Geo Standaarden: streaming data binnen geo toepassingen (Cityflows ed), 3D-gewijs.
  • Op EU vlak: ETSI (JSON-LD, maar geospatial niet toereiken

Architecturale specs (breed)

  • Keuzes moeten gemaakt worden ovv Hardware specs, Software specs, keuze databronnen, keuze data Standaarden en keuze data-uitwisselingss Standaarden

Data & ICT Integrator (Digitaal Vlaanderen - gov)

Businessmodel

  • De incentive voor leveranciers om diensten te creëren op de data ontbreekt nog, maar ook het inzicht wat een werkbaar model voor deze partijen zou kunnen zijn. Andere manier dan contractuele bepalingen zoeken is nodig omdat die vaak niet doeltreffend genoeg zijn.

Data & ICT Integrator (privé)

Datastromen

  • Om nieuwe data te genereren zijn meer sensoren nodig maar ook niet typische partijen die inzicht geven over drukte of passage, zoals naburige koffiebars
  • Nood aan ‘data’ over waar de hoppinpunten ingepland zijn/zullen worden

Interoperabiliteit

  • De keuze voor een platform houdt risico in van vendor-lock in en de facto intra-operabiliteit (link met governance)

Standaarden

  • Afspraken rond het formaat dat beschrijft hoe data ontsloten worden
    • Duidelijkheid over verplichte karakter van de Standaarden

Businessmodellen

  • Duidelijkheid nodig over gewenste en (niet-)toegelaten verdienmodellen

Governance

  • In verlengde hiervan is communicatie (korte tot midellange termijn) over locaties en timing van nieuwe hoppinpunten en hoe deze beslissingen lopen
  • Wie mag data gebruiken en/of inzien en/of verwerken?
  • Veel Standaarden opleggen vraagt ook veel technische implementaties voor bedrijven

Middenveld (Fietsberaad, taxistop en Mobipunten vzw)

Databronnen en ontbrekende data

  • Overzicht fietsenstallingen aan hoppinpunten
  • Realtime bezetting van de fietsenstallingen en fietskluizen

Datastromen

  • Écht kwaliteitsvolle real time data van de beschikbaarheid van fietsen
  • Onderscheid voor- of natrajectgemeente, functie van profiel vd gemeente: eigen fietsen en/of deelfietsen
  • Uitdaging om alle mogelijke data samen te brengen (rol voor MobC en Maas-operatoren
  • Data van micromobiliteit: bv deelsteps

Interoperabiliteit

  • IOP met de LODstandaard van Velopark

Standaarden

  • Linked open data standaard van Velopark JSON Structure & Vocabulary + standaard voor real-time bezettingsdata
  • gbfs gtfs
  • Semantische definiering van het concept ‘Fietsenstalling’

Architectuur

  • Is er nood aan een geïntegreerde back-end, en gediversifieerde frontends; om zo te vermijden dat de reiziger overspoeld wordt met verschillende applicaties en aanbieders

Businessmodellen

  • Kunnen beinvloed worden door de overheid die Standaarden oplegt in aanbestedingen door overheden; op die manier is de overheid niet marktverstorend maar eerder sturend

Governance

  • Afspraken nodig over eigenaarschap van data en het uitwisselen als open data (al dan niet in een gesloten circuit)
  • VLOCA principes kunnen meerwaarde zijn om dit concept van hoppinpunten te ondersteunen, gezien er gestart is maar ook nog veel ontwikkeld moet worden en nog nieuwe inzichten te wachten staan en vandaaruit verdere keuzes zullen gemaakt worden

Reiziger

Databronnen en ontbrekende data

  • Inzicht in real-time aanbod moet in het aanbod verwerkt zitten, wat betekent dat data uit de silo’s van applicaties, software en Organisaties gehaald wordt
  • Er moet een verzekering naar de reiziger komen dat het geplande traject effectief afgewerkt kan worden.

Datastromen

  • Gezien de meeste gebruikers beroep doen op de diensten van Google (Maps) zouden de hoppinpunten geintegreerd moeten kunnen worden hierin.
Overgenomen van "https://vloca-kennishub.vlaanderen.be/index.php?title=VlocaSessie:Hoppinpunten_Workshop_1:_Behoeftes_%26_doelstellingen&oldid=11012"