Hoppinpunten Workshop 3: Details

Presentatie

Presentatie VLOCA Hoppinpunten workshop 3

Attendance List

• Bart De Proost (MOW)
• Axel Verstrael (Streetwaves)
• Kenny Stevens (VERA)
• Gert Vervaet (Geosparc)
• Emilie Couwenberg (Stad Antwerpen)
• Philippe Michiels (imec)
• Tjalle Groen (Taxistop)
• Frederik Schodts (Vlaanderen)
• Tim Coninx (De Lijn)
• Ziggy Vanlishout (Digitaal Vlaanderen)
• Annie Pinxten (Cronos)
• Pieter Dresselaers (Igemo)
• Koen Dereu (Haviland)
• Koen Triangle (imec)
• Tijl Dendal (MOW)
• Wouter Luyckx (Arcadis)
• Guido Vaganée (VVSG)
• Ewout Depauw (SOLVA)
• Bram Roelant (Mobipunt)
• Natasha Blommaert (MOW)
• Rik Hendrix (VITO)
• Bart Scheenaerts (ABB)
• Wim Michiels (ANYWAYS)
• Annelies De Craene (Digitaal Vlaanderen)
• Stephen T'Siobbel (MOBLT)
• Rob Van Den Berg (imec)
• Anne-Marie Van Asbroeck (imec)
• Pieter Morlion (imec)
• Nils Walravens (imec)
• Mathias Van Compernolle (imec)
• Stefan Lefever (imec)

Introductie

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

VLOCA gaat over richtlijnen, standaarden en afspraken rond City Digitale architectuur. Het wil zo veel mogelijk openheid creëren in de digitalisering. Binnen een stad zijn er silo’s en domeinen (eg. Mobiliteit / Verlichting) en deze systemen zijn gelaagd en zijn onderhevig aan verschillende lock ins (eg. use case, domain lock in, vendor, cloud,...). VLOCA gaat over het management van deze lock ins om op die manier de samenwerkingen tussen deze systemen te faciliteren. We aligneren ook met andere initiateven (zoals GAIA X). VLOCA bestaat uit een aantal trajecten (zie slides). Deze trajecten hebben als doel te capteren en te inspireren. En het doel is dat deze trajecten aan elkaar worden verbonden via de Kennishub. Daar worden de onderleggende principes samen gebracht.

Wat zijn de concrete deliverables van VLOCA:

• Digitaal informatie model op te zetten en dit kan worden gemakt met Linked data en OSLO trajecten
• Hopping Traject consolidatie op de Kennishub -> leidt tot een hoppincompliant template
• Co-creatie is hiervoor nodig op de Kennishub.
• Heel veel activiteit van VLOCA gaat zich nu verplaatsen naar deze Kennishub
• In het najaar zouden we graag deze elementen uit Hoppinpunten combineren met de andere trajecten in een Vlaamse Open City Architectuur

Samen naar kwaliteitsvolle hoppinpunten

Er wordt eerst ingegaan op de visie vorming en de beleid. Daarna wordt er ingegaan op de subsidiëring en regelgeving. Daarna meer over de huidige situatie.

Evolutie van een aanbod-gedreven aanpak naar een vraag-gestuurde aanpak Mobipunten beginnen hun plaats te krijgen in het landschap Er is ook een nieuwe governance structuur in leven gelopen in proefregio’s In 2020 is MOW dan gekomen tot een besluit van de Vlaamse Regering.

Evolutie van basismobiliteit naar basis bereikbaarheid. Daar zit ook het STOP Principe in, en dus ook combimobiliteit Het hoppinpunt moet alles met elkaar gaan verbinden. En daardoor kan vervoer op maat worden aangeboden. Er moet dus goed worden gecommuniceerd tussen de spelers en het landschap.

Er was visievorming in 2019 die zich heeft verankerd in een Besluit van de Vlaamse Regio. In de mededeling aan de Vlaamse Regering zijn 2 dingen belangrijk: Er moeten genoeg punten zijn & het moet bottom up gebeuren en iedereen moet er zijn schouders onder zetten.

Het visie werk is dan vertaald in regelgeving -> Besluit van de Vlaamse overheid (11/11/2020) Dit bevat een categorisering van de mobipunten – er zijn 5 types. 4 van de 5 types moeten worden geïntegreerd in het regionaal mobiliteitsplan

BVR bevat ook de definitie van de zuilen en de stijl van de zuilen Er zijn ook een aantal eisen gedefinieerd:

• Toegankelijkheid (inclusief naar iedereen)
• Minimale uitrusting voorzien
• Parkeerplaatsen
• Fietsenstallingen
• Er moeten informatiedragers zijn
• Informatiestructuur om data uitwisseling mogelijk maken

Uitzondering, want normaal worden nutslevering niet gesubsidieerd (eg glasvezel en 5G) Er is een subsidiemechanisme gekoppeld aan de BVR voor de (her-) aanleg voor de mobipunten. (zie slides voor meer uitleg) Andere spelers als AWV zijn ook belangrijke spelers in dit landschap Er zijn ook talrijke partijen actief op de hoppinpunten. En daarboven ook de regionale spelers die het beheer op zich nemen. Er zijn dus verschillende stakeholders betrokken.

Huidige Situatie:

• Er zijn tal van initiatieven en MOW zou graag in dialoog gaan met deze initiatieven.
• Hoppinpunten bestaat sinds 2020 en dit zal verder worden uitgerold.

Wat zijn de volgende stappen:

• Hoppinpunten (her) inrichting in samenwerking met de stakeholders
• Kwaliteit bewaken van de hoppinpunten
• Basis leggen voor uitwisselen van data en integratie vergroten aan de hand van standaarden (OSLO) en digitalisering VLOCA.

Vraag Pieter Dresselaers: Hoe wordt er gekeken naar de timing van het invoeren van de hoppinpunten De Timing moet worden bekeken in functie van de rest van de nota basis bereikbaarheid. Tijl is ook nog maar een maand bezig en gaat er proberen een lijn in te brengen en gaat proberen om dit te laten samen sporen met basisbereikbaarheid.

Vraag Pieter Morlion: Op welke manier kan er worden samen gewerkt om bestaande en digitale punten te integreren – vraag is eerder aan Bram (Mobipunten vzw) Er is op dit moment een databank met de diensten (eg eten, toilet,...), maar ook met mobiliteitsdiensten Zij zijn ook vragende partij om de data correct te houden en bekijken op welke manier ze kunnen aligneren met de Mobiliteitscentrale. In aanvulling op het antwoord van Bram, geeft Tijl ook aan dat er heel wat verschillende spelers zijn en dat die verder in kaart moeten worden gebracht zodat er goede afspraken mee kunnen worden gemaakt. Er is een heel landschap aan spelers -> bekijken hoe we ermee verder gaan en definiëren hoe dit kwaliteitsvol kan worden verder gezet. Tijl treedt graag in dialoog met de verschillende partners om samen verder te bouwen en te leren over initiatieven.

Hoppin Informatie

Op basis van de voorgaande workshops heeft imec al zelf nagedacht over een informatie architectuur. We hebben zelf voorstel gedaan op basis van de informatie die we hebben verzamelt. Een hoppinpunt bestaat niet op zich. Het linkt aan een MaaS afsprakenkader (=financiële regeling), maar ook met het technisch (APIs) en semantisch kader (= OSLO, data moet duidelijk zijn beschreven) En wat betekent dit voor de hoppinpunten. Dit kan diensten en informatie aanbieden.

Daarom zijn er verschillende zaken:

• Informatie architectuur
  • Welke diensten krijgen we op het punt
  • Trein / Bus / deel auto / Taxi
• Historische informatie – op welke manier wordt het gebruikt
• Connectiviteit met andere wegen
• Data modellen
  • Hoe gaan we om met de data – Link met OSLO en zorgen dat we OSLO compliant zijn
• Service provider – zijn onafhankelijk van het hoppinpunt
  • Deze geven leven aan het hoppinpunt
  • De lijn / NMBS / Pakket dienst of een betaalservice die voor een hoppinpunt geldt.
  • Als we spreken over de busdienst willen we weten welke lijnen het zijn en time tables
  • Het is belangrijk dat deze zaken duidelijk gedefinieerd zijn omdat dit combineren van data faciliteert.

Peer als voorbeeld

Ze wouden 2 zaken voorkomen:

• Dat een hoppinpunt geen rommeltje zou worden, geeft onduidelijkheid voor de gebruiker
• Digitale rommel en dat je 28 apps moet hebben en 4 abonnementen om die diensten te combineren

Concreet onderzocht waar ze dit mobipunt willen plaatsen in Peer. Er zijn verschillende groottes en verschillende plaatsen, dus nood aan flexibiliteit bij het inplanten.

Mobipunt is zoals een supermarkt, of zoals een publieke markt.

• Deze analogie met de verschillende marktypes geeft ook aan dat de rol van de overheid duidelijk moet worden bepaald.
• Wat wel duidelijk was is dat er een samenwerking nodig was met private spelen.
• Deze zouden graag schaal zien om te vermijden dat ze op verschillende aanbestedingen moeten intekenen.

Alle aanbieders hebben hun manier om de data aan te bieden en dat was complex.

Een zuil is belangrijk en die kan zowel digitaal als fysiek bestaan. Er zal dus sowieso veel data digitaal moeten beschikbaar zijn voor de gebruikers en voor de verschillende applicaties. Ook rekening houden met burgerinclusiviteit (geen gsm / 4G) dus op de zuil ook digitale zaken aanbieden.

Eye opener voor het project was om het gesprek aan te gaan met de burgers.

Het eerste begrip was dat dit meer was voor bezoekers van Peer. Daarna werd de vraag gesteld of dit nodig is voor de inwoners van Peer?

De voornaamste vragen van de burgers gingen over welke services en hoe kan ik die services gebruiken. Daarnaast kwam het telkenmale terug dat er een routeplanner nodig was waarin je de verschillende diensten kan combineren en kan betalen. Kunnen betalen en hoe je betaalt en hoe je de route van A -> B aflegt zonder eigen voertuig was voor de burgers cruciaal.

De volgende vraag was dan: wat kunnen we doen en wat moeten we doen als overheid?

• Fysiek mobipunt inrichting kan de overheid doen
• Zuil en elektriciteit voorzien kan ook
• Deelfiets kan worden aanbesteed
• Geïntegreerde dienst was nog niet duidelijk.

In het project werd er dan wel een voorstel gedaan tot welk niveau een overheid zou kunnen gaan op gebied van architectuur (fysiek en digitaal):

Voor de hardcore mobiliteit (NMBS / De lijn) daar is informatie beschikbaar. deelfietsen en deelauto’s daar was toen nog veel werk – er was toen nog geen digitale back bone / infrastructuur Postvakjes – hoe integreren we dit? Een tip: open street maps gebruiken om de diensten te definiëren. er is een datamodel dat je kan gebruiken als stad / gemeente en dan heb je ook een cmmunity die daarmee iets kan doen. Op basis daarvan kan je open data publiceren.

Conclusie: Om koterij te vermijden is het nodig dat je een goed bouwplan nodig hebt Hetzelfde geldt digitaal -> bouwplan nodig om structuur te voorzien waaraan de verschillende partijen moeten voldoen.

Vraag van Guido: Is er nog een vervolgtraject van S-Lim? Op dit moment is het bij S-Lim geen prio en zit het niet in hun opdracht. We moeten vooral vermijden dat iedereen eigen lastenboeken begint te schrijven

vraag Pieter: Apart op OSM publiceren of samen als hoppinpunten Hoppin is een Vlaams merk en het is niet de bedoeling om op OSM merken te plaatsen OSM heeft al een uitgebreid model om Hoppinpunten te definiëren Nadeel is wel dat het allemaal statische informatie is Hoe gaan we Hoppinpunten afbakenen op een kaart (op OSM)? De mogelijkheid om iets te publiceren kan op OSM Een aanbieder zelf kan dit ook aanmaken

Workshops

Meer details te vinden op |Miro.

Groep 1: Welke informatie ontbreekt in het luik hoppin-informatie architectuur?

• Data rond beheer
  • Info over beheerder: er is niet 1 bron over verantwoordelijkheden, belangrijk om referentie te hebben wie punt beheert
  • Beheer van het punt zelf: maintenance informatie voor technische dienst
• Toegankelijkheid dienst zelf
• POI’s
• Drukte
• Locatie
• Weer data
• Data rond gebruik / gebruikers
  • Score gebruikers beperkingen
  • Usage data
• Andere diensten
• Specifiek voor de service provider:
  • Info dienstverlening
  • Real time beschikbaarheid diensten
  • Bezettingsgraad
  • Hoe je kan plannen, booken

Welke beschrijvingen ontbreken in het luikt service provider?

• Naast de diensten die worden beschreven: Hoppin-punten kunnen ook andere impulsen geven – meer dan mobiliteit!
  • Markkramen
  • Uitleendienst
  • Boxen: Concert geven op hoppin-punten via een box (app).
  • Link naar 15 min stad
  • Gamification hoppin punten (Azie).
  • Lokale economie, leefbaarheid boosten.
  • Moet je dit willen beschrijven? Hoe ver wil je gaan? Wel optie aanbieden om dit te kunnen beschrijven: type diensten wel opnemen. En zo modulair verder uitbouwen.
• Ook andere mob diensten:
  • Deelsteps
  • Disruptieve aanbieders: uber ...
  • Waterbus
  • Carpool

Hoe zou je deze informatie en beschrijvingen gebruiken in je toekomstig werk rond hoppinpunten? Welke richtlijnen zijn wenselijk?

• Vertaling naar leesbare omgeving voor de gebruiker: hoe in praktijk de leesbaarheid voor gebruiker realiseren? Herkenbaarheid, user experience van hoppin punt moet ook aandacht krijgen!
• Opschaling hoppin-punten: moet gemakkelijk gaan – niet ten kost van experience.
• Gebruikersinfo: sturend zijn voor beleid.
• Richtlijnen rond accuraatheid van de data:- standaarden
• Duidelijk kader, afspraken rond gebruik data (data sharing commerciele partijen!)
• Uitbreidbaarheid van informatiemodel
• Metadata over gebruikte databronnen
• Semantiek: data moet zichzelf beschrijven
• Specifiek: Koppeling met mobiliteitscentrale (vervoer op maat) (ook info over de muziekboxen!): specifiek voor MOW als soort van MaaS speler.

Welke andere initiatieven moeten in rekening worden gebracht om dit informatiemodel zo volledig mogelijk te maken zoals MaaS afsprakenkader, OSLO mobility, ITS-BE?

• Belgisch kader! Internationaal kader! -> OSLO houdt er rekning mee, ook ITS.be.
• Vorige learnings: Peer, Mobipunt vzw, ...
• CDS-M: Nederlandse standaard – data dit naar steden terug moet gaan en verwerkt worden.
• States: grote aanbieders ja, maar lokaal – kleine aanbieders, zij hebben het niet gemakkelijk -> hoppinpunten kan soort tussenoplossing bieden, in te pluggen in grotere oplossingen. Hier in Vlaanderen is er ook al moeheid bij de Limes van deze wereld -> Vlaanderen moet hier rol spelen om initiatieven over de steden te standaardiseren!!!
• Kleine aanbieders begeleiden! Kleine initiatieven zijn vaak heel duurzaam, geworteld, dicht bij mensen.

Groep 2: Uit intro Koen De Reu (Haviland): Belangrijke rol intercommunales om om te gaan met uitdagingen lokale besturen, zeer weinig lokale kennis aanwezig, ondersteunen met de in planning en linken naar Vlaanderen.

Welke informatie ontbreekt in het luik informatie architectuur?

• Welke (toekomstige) voorzieningen
• Ruimtelijke situering (punt en/of polygoon)
• Beschrijvingen aanwezige sensoren
• Nood aan info die zich bij andere bestuursniveaus bevindt, diensten die inwerken op het lokaal hoppinpunt. Daarvoor bvb een identificator nodig per hoppinpunt om zo ook naburige hoppuinpunten in kaart te brengen.
• Mogelijkheid tot feedback: basic contactinformatie van de beheerder, bvb kapotte ruit van een wachthokje. Info kan ook in 2 richtingen gaan, bvb sterbeoordeling geven aan en hoppinpunt, of vragen stellen over een hoppinpunt aan de gebruiker, mogelijkheid om klachten of feedback te geven. Zeker voor lokale besturen kan dat belangrijk zijn als ze beheerder zijn van een hoppinpunt.
• Feedback zou ook via sensoriek kunnen gebeuren, bvb geluidsmetingen, druktemetingen.
• Naar wie sturen ze die boodschap dan is de vraag natuurlijk, link naar governance en beheersvraagstuk. Haltebeheer is ook een uitdaging en iets om mee te nemen in het geheel. Dat zijn specifieke spelers die verantwoordelijkheden hebben, wordt vaak uitbesteed naar JC Decaux etc. Meestal zijn de gemeenten wel beheerder. Zou eventueel wel samen aanbesteed kunnen worden, omdat bvb door de sociale economie te doen.
• Overlast: gemeentes willen soms geen extra diensten aanbieden omdat ze extra verkeer zouden kunnen aantrekken (bvb extra verkeer voor pakjesautomaten).
• Compliance andere punten: is nu toegespitst op IoT gebeuren, maar voor kwaliteitscriteria kan compliance belangrijk zijn, voor de ruimtelijke aspecten en dienstverlening.

Welke beschrijvingen ontbreken in het luikt service provider?

• Mobcentrale: boeken via de mobiliteitscentrale. Welke diensten? Moeten nog aanbesteed worden, deelmobiliteit in het algemeen. Gaat een landschap zijn waar een aantal vervoer op maat deelfietsen en auto’s worden aangeboden, naast anderen. Zullen dus expliciet vermeld moeten worden. Zuilen geven nu aan wat er op een punt beschikbaar is, meer niet, maar idee mobiliteitscentrale is daar ook een boekingsplatform van te maken. In de beschrijving van de dienst moet dus een link voorzien worden naar de dienst waar je kan boeken.
• Verplichting tot reserveren of niet, maximale gebruiksduur etc.
• Metadata over betaling: betaalmiddelen, wanneer betalen, currency,…
• Nood aan abo of niet?
• 1 betaalsysteem: eerder een wensdroom, gebruiksgemak vooropstellen en via 1 systeem alles betalen, maar zal mogelijk moeilijk zijn.
• Back to many of back to one: waar kan je je deeltransport achterlaten?

Hoe zou je deze informatie en beschrijvingen gebruiken in je toekomstig werk rond hoppinpunten? Welke richtlijnen zijn wenselijk?

Welke andere initiatieven moeten in rekening worden gebracht om dit informatiemodel zo volledig mogelijk te maken zoals MaaS afsprakenkader, OSLO mobility, ITS-BE? Wie zijn mogelijke hergebruikers van dit model? Belang lokale initiatieven en hiermee afstemming vinden Kernwoord: afstemming

Groep 3: Welke informatie ontbreekt in het luik informatie architectuur?

• TYPE mobipunt : regionaal, lokaal, buurt, ... als deel van de identificatie
• VERANTWOORDELIJKE / BEHEERDER / AANPSREEKPUNT. Contact informatie, bijvoorbeeld voor klachten of suggesties ter verbetering (bv netheid, onderhoud,...). Relatie tot HOPPIN label ?
• SERVICE INFO: naast de services, bijvoorbeeld ook momentele verstoringen van services op HOPPIN impact niveau vertaald (“Hoppin verstoord” symboolke groen-rood-oranje)
• RUIMTELIJKE info : link naar authentieke gegevensbronnen (bv adres, gebouw, wegsegment), uniek ID van een hoppinpunt, toegankelijkheidsinfo, ...
• GEBRUIKERS info : mogelijke gebruikers perspectief data (dynamisch) dus ook voor service suppliers en niet alleen voor de reiziger. LINK met TYPE mobipunt.
• Vraag: hoe kunnen we data over gebruikers van de service suppliers hierover integreren.
• TOETREDINGSMODALITEITEN : waar moeten vragen neergelegd worden ? Rol van gemeente, mobiliteitscentrale, ...
• CONNECTIVITEIT : (huidige) beleving van het HoppinPunt => ge-aggregeerde informatie. Luchtsensoren, wachttijden, ...
• UITBREIDBAARHEID is belangrijk, levenscyclus van het model.

Welke beschrijvingen ontbreken in het luik service provider?

• Lockers, lokale handelaars, fietsherstelzuilen, wachtaccomodatie, toiletten, AEDs, foodtrucks, slimme sloten/micro mobiliteit, ...
• Bijvoorbeeld deelauto-‘s : via digitaal slot, of via sleutel in de Delhaize ? Zo breed mogelijk houden op niveau van kleine gemeenten en grote steden.
• Hoe types van services omschrijven ?
• Waar stopt het Hoppin punt en zijn services ? Fysieke afstand ?

Beheer/governance van het Hoppin punt kan ook een service worden op een Hoppin punt.

• Governance van de services zelf ? De lat hiervoor op de relevante hoogte leggen voor de service en het belang.
• CONCLUSIE : types services beschrijven en hun common elementen capteren => best af te werken via de KH.
• Cfr. Groep 1 : Hoppin als ontmoetings- en belevings plaats

Welke andere initiatieven moeten in rekening worden gebracht om dit informatiemodel zo volledig mogelijk te maken zoals MaaS afsprakenkader, OSLO mobility, ITS-BE? Wie zijn mogelijke hergebruikers van dit model?

• PAYMENTaaS : Compliance rond betalingsmogelijkheden ? Uniforme betaling als service.
• Voorbeelden : Londen, Yelbi Berlijn
• Pitch : parkeerrechtendatabank => mobiliteitsrechtendatabank ?
• Harmonisering van licentiemodellen ivm toelaten toegang tot Hoppin Punt. Overbrengen van data uniformiseren naar nieuwe services.
• Relance plannen : Sensor Data Platform en Mobiliteit van Digitaal Vlaanderen.

Vooruitblik naar volgende workshop

Volgende workshop zal in het najaar plaats vinden. Dit is een consolidatie workshop. In de tussentijd verwerken we de informatie die we hebben ontvangen uit de workshops en delen we die op de Kennishub. Dit dient als basis voor de verdere cocreatie en daarnaast zal er worden bilateraal afgestemd om de deliverables verder inhoudelijk te verfijnen.