"Parsed text" is een vooraf gedefinieerde eigenschap. Deze eigenschap is van te voren gedefinieerd (ook bekend als een speciale eigenschap) en komt met extra beheersprivileges, maar kan worden gebruikt net als elk andere door de gebruiker gedefinieerde eigenschap.
H
Deze pagina beschrijft welke stappen je doorloopt om een nieuw Hoppin' punt te creëren.
Hoe kun je hier digitaal aan meewerken ? Daar vind je hier meer uitleg over.
Raadpleeg het stappenplan
Het Departement Mobiliteit & Openbare Werken van de Vlaamse overheid maakte een draaiboek aan waar je de verschillende stappen terugvindt die je doorloopt bij het inplanten van een nieuwe Hoppin' punt. Je vindt het stappenplan hier . Het omvat onder andere:
Wat is een Hoppinpunt
Waaraan moet het Hoppinpunt voldoen?
Hoe pas je de huisstijl voor Hoppinpunten toe
Waar en wanneer is de huisstijl afdwingbaar (gewestwegen vs. gemeentewegen)
(dit stappenplan moet verder nog vorm krijgen)
Contacteer de verantwoordelijk van je vervoerregio
De concrete uitrol van Hoppinpunten wordt vooral gecoördineerd op niveau van de vervoerregio's. Contacteer de verantwoordelijk van je vervoerregio om te kijken welke ervaringen er al zijn in andere gemeenten en of je ondersteuning kunt krijgen vanuit de vervoerregio zelf. De lijst met vervoerregio's vind je op deze webpagina , als je doorklikt vind je de contactgegevens van het aanspreekpunt van de vervoerregio.
Contacteer een (buur)gemeente met ervaring
Tal van gemeenten hebben reeds een Mobipunt of Hoppinpunt gerealiseerd. Hierbij hebben ze waardevolle kennis opgedaan en informatie verzameld of documentatie aangemaakt die eventueel hergebruikt kan worden door jouw gemeente. Ga na bij de verantwoordelijke van de vervoerregio welke goeie voorbeelden zijn.
(Momenteel is er nog geen centraal overzicht beschikbaar met bestaande Hoppin' punten)
Registreer het Hoppinpunt
Registreer het Hoppinpunt op het digitale platform van de Vlaamse Overheid (dit is een verplichting om een vergunning / subsidies) te kunnen verkrijgen. Er wordt een Hoppin’ ID aangemaakt voor jouw Hoppinpunt. Op deze manier kunnen mobiliteitsaanbieders op termijn automatisch de data (zoals de beschikbaarheid, prijzen, ..) van hun diensten linken aan je Hoppin’ punt, en deze digitaal beschikbaar maken.
Deze pagina beschrijft welke stappen je doorloopt om een mobiliteitsdienst (deelfietsen, parkeerplaatsen, een pakjesautomaat, een bushalte, ..) toe te voegen aan een Hoppinpunt.
Ga op zoek naar de verantwoordelijke uitbater
Neem contact op met de verantwoordelijke wegbeheerder / gemeente om de verantwoordelijke uitbater te weten te komen. Dit kan bijvoorbeeld Agentschap Wegen en Verkeer zijn voor gewestwegen of de gemeente voor lokale wegen, maar ook de Werkvennootschap of Lantis. Volgens de nota van de Vlaamse regering: "De aanleg van Hoppinpunten wordt in het artikel 42 van het Decreet Basisbereikbaarheid toegewezen aan de wegbeheerder. Het is daarom van belang dat de beleidsvisie verspreid wordt en zijn doorwerking krijgt in het regionale en lokale mobiliteitsbeleid."
Neem contact op met de verantwoordelijke uitbater
Contacteer de uitbater van het Hoppinpunt en vraag de aansluitingsvoorwaarden en timings na om te weten te komen of er nog ruimte is voor de dienst die je wil toevoegen, aan welke voorwaarden die moet voldoen en op welke momenten extra diensten toegevoegd kunnen worden.
Zorg voor een digitale beschrijving van de mobilitetisdienst
Hou er ook rekening mee dat er specifieke voorwaarden zijn rond data-uitwisseling (met de mobiliteitscentrale). Het is belangrijk dat het aanbod goed digitaal beschreven is en de beschikbaarheid van de diensten ook digitaal raadpleegbaar is. Zo komt je dienst op de overzichten met Hoppingpunten, eventueel ook in routeplanners en kunnen weggebruikers op voorhand weten welke diensten er aanwezig zijn en wat de beschikbaarheid is. +
Deze pagina beschrijft welke stappen je doorloopt om subsidies aan te vragen voor een Hoppinpunt
Hoe kun je hier digitaal aan meewerken ? Daar vind je hier meer uitleg over.
Bepaal wie de verantwoordelijke wegbeheerder is
De subsidies hangen onder andere af van wie de wegbeheerder is van het Hoppinpunt. Dit kan bijvoorbeeld Agentschap Wegen en Verkeer zijn voor gewestwegen of de gemeente voor lokale wegen. Als u zelf niet de wegbeheerder bent, neem contact op met de verantwoordelijke wegbeheerder om af te stemmen.
Lees het besluit van de Vlaamse regering
De Vlaamse Regering keurde een besluit goed rond het subisidiëren van Hoppinpunten, daarin vind je de nodige achtergrondinformatie. Het besluit kun je hier raadplegen.
Bekijk de voorwaarden
Op deze pagina kun je een overzicht vinden van de voorwaarden waaraan je moet voldoen om subisdies te ontvangen. Het gaat ondermeer over de visuele identiteit van het Hoppinpunt, de toegankelijkheid en nodige vergunningen zoals een omgevingsvergunning.
Hou er ook rekening mee dat er specifieke voorwaarden zijn rond data-uitwisseling (met de mobiliteitscentrale). Het is belangrijk dat het aanbod goed digitaal beschreven is en de beschikbaarheid van de diensten ook digitaal raadpleegbaar is. Zo komt je Hoppinpunt op de overzichten, routeplanners en kunnen weggebruikers op voorhand weten welke vervoersmiddelen, parkeerplaatsen, dienst etc. er beschikbaar zijn.
Contacteer de verantwoordelijk van de vervoerregio
De concrete uitrol van Hoppinpunten wordt vooral gecoördineerd op niveau van de vervoerregio's. Contacteer de verantwoordelijk van je vervoerregio om te kijken welke subsidies van toepassing zijn. De lijst met vervoerregio's vind je op deze webpagina , als je doorklikt vind je de contactgegevens van het aanspreekpunt van de vervoerregio. +
Waarom digitale hoppinpunten?
Het samenbrengen van verschillende vervoersmiddelen op één fysieke locatie past perfect in een “overstapmodel” of het concept van "combimobiliteit". Daarbij willen we maatschappelijk een slimmere, performantere en ook meer duurzame en inclusieve bereikbaarheid bekomen. Wie vandaag de trein neemt kan dat in heel wat stations al ervaren. Het voor- en natransport zijn cruciaal om de trein als mobiliteitssysteem goed te laten werken. Sinds enkele jaren is met verschillende aanbieders van deelfietsen en steps onder de noemer micromobiliteit een enorm veel groter scala aan mogelijkheden ontstaan voor de zogenaamde “laatste kilometer”. En met de komst van allerlei apps en/of terminals die werken met betaalkaarten om bijvoorbeeld het slot van voertuigen te openen of je toegang tot vervoer te regelen is er nu ook controle op het correcte gebruik en betaling.
Voeg daarbij nog een app die je perfect kan vertellen waar je bent, die de verschillende vervoersopties in de buurt aanwezig weergeeft en die je ook de meest optimale route kan tonen tot je bestemming. De cirkel is zo rond voor de reiziger als "consument" van de mobiliteitsdiensten.
Dit model van fysieke overstapplekken of "hoppinpunten" met verschillende vervoersopties en daarbij horende "digitale infrastructuur" waarmee je deze opties kan consumeren, maakt het effectief mogelijk om ook zonder wagen slimmer - en soms zelfs sneller en goedkoper - je van A naar B te verplaatsen.
Hét werkpunt: data delen
Op zich lijkt deze digitalisering van het mobiliteitsaanbod al aardig te lukken: je kan trein- en bustickets kopen met een app of met je bankkaart aan een terminal. Je kan ook de dienstregeling raadplegen op een website of via een app. Je kan een slot van een fiets of een wagen openen met een app of een kaart. Het is evenwel wanneer alle data moet worden samengevoegd om geïntegreerde reisinformatie en -planning aan te bieden op zo'n overstapplek dat het nog niet loopt zoals het zou moeten. Of wanneer de data moet worden gedeeld met overheden of andere partijen die ze zouden kunnen gebruiken voor analyses of optimalisatie.
Iedere service provider, publiek of privaat, heeft voor zich wat hij of zij nodig heeft voor de eigen dienst, maar is bang om het te delen. Is het de vrees om klanten of controle te verliezen? Of is het een bezorgdheid ten aanzien van de klant? Want klein of groot, alle aanbieders zijn zeer gevoelig als het gaat om hun klanten, wat die denken over de service en wat ze effectief met de service doen.
De competitie die speelt tussen aanbieders van mobiliteit is reëel en moet zeker worden erkend. Maar voor de burger is net die competitie tussen de transportmodi interessant, zeker voor diegenen die zich zonder wagen willen verplaatsen. En ook voor de stad of gemeente is een divers aanbod béter want goedkoper en met méér marge om te onderhandelen en te zoeken naar de juiste oplossing op de juiste plaats.
De service provider heeft er alle belang bij dat zijn dienst veel wordt geconsumeerd, en dus dat er veel en trouwe klanten zijn. Het model van de nieuwe mobiliteit draait in grote mate om een geïntegreerd aanbod van verschillende diensten met een grote keuzevrijheid voor de reiziger. Hoe beter die individuele diensten geconnecteerd zijn en gebruikt worden, hoe meer ze elkaars gebruik gaan stimuleren. Je kan het zien als een winkelstraat: hoe meer aantrekkelijke winkels dicht bij elkaar in de winkelstraat, hoe meer mensen er op bezoek komen en hoe meer er wordt geconsumeerd.
De burger die beslist?
Dus naast een divers aanbod aan vervoersopties is data delen echt een belangrijke voorwaarde om de digitalisatie van het mobiliteitsaanbod via hoppinpunt te laten slagen. De vraag is dan, wie beslist er over de data?
Nu wordt de vraag om data altijd gesteld aan de leverancier van de dienst, maar waarom de vraag niet stellen aan de mensen/de reiziger zélf? De data over de verplaatsingen van reizigers komt immers in de eerste plaats die reizigers zélf toe. Het delen van data over verplaatsingen moethun keuze kunnen zijn. Dat een bedrijf met een mobiliteitsaanbod de data gebruikt om haar dienst te verbeteren is legitiem, dat het zich beschermt tegen concurrenten in een competitieve markt is logisch. Maar de consumenten van die diensten zouden zélf moeten kunnen beslissen om hun verplaatsingsdata te doneren aan de stad of een dienstverlener die haar kan helpen met analyses om betere diensten te bekomen. Laat dan duizend bloemen bloeien en de spelers groot en klein hun aanbod afstemmen op elkaar zodat iedereen er beter van wordt. Elke speler zal immers gedreven worden naar efficiëntie en waardecreatie en zijn plaats vinden in het overstapmodel.
Van het allergrootste belang is dan dat de mensen/burgers hun data (i) op een transparante en gestandaardiseerde wijze ter beschikking stellen, (ii) dat ze ze in vertrouwen kunnen afgeven aan wie ze gebruikt, (iii) dat ze ook zicht krijgen op wat er uiteindelijk met de analyse van de data gebeurt en (iv) dat ze in ruil een verbeterde dienstverlening krijgen.
De steden en gemeenten aan zet
Hoppinpunten hebben uiteraard altijd een fysieke aanwezigheid in de publieke ruimte. In het bijzonder op plaatsen waar we diverse activiteiten zoals winkels, kantoren, scholen, gezondheidszorg, sport, cultuur en ontspanning zich concentreren en dus veel mensen en goederen samenkomen is het meer noodzakelijk om dat te organiseren. Typisch dus het centrum van grotere steden. Zij zijn dan ook de voortrekkers vandaag in de uitrol van deze plekken en de bijhorende digitalisatie. Het is immers niet alleen de consument die digitale toegang nodig heeft, maar ook de stad kan onmogelijk evalueren en plannen zonder die data. Hoe groter de drukte, hoe belangrijker het wordt om alles in goede banen te leiden en hoe belangrijker het is om te weten wie zich wanneer en hoe verplaatst.
Deze regisseursrol is de steden op het lijf geschreven: ze wedijveren met elkaar op een positieve manier om het meest aantrekkelijk te zijn voor hun eigen inwoners, voor bedrijven die zich er vestigen en voor bezoekers die horeca en winkels bezoeken, die op hun beurt zorgen voor een bruisende stad. Ook kleine steden en gemeenten zoeken naar hun mogelijkheden in dat aanbod, want ook zij wedijveren met elkaar en met de andere steden - met een wens om het dorp klein maar aantrekkelijk te houden. En ook daar zie je dus dat men het centrum wil opwaarderen en dus de publieke ruimte slim wil transformeren om aantrekkelijker te zijn - lees: niet alleen maar parking. En ook die dorpen hebben op hun schaal nood aan data en afgeleide informatie. Werkt die deelwagen hier nu wel of niet? Wie gebruikt de uitleen/deelfietsen? Of het nu een grote stad is of een klein dorp, vanuit een andere perspectief stelt men dezelfde vragen.
Het bouwplan: de informatiearchitectuur van een mobipunt
Om gestructureerd en professioneel te werken aan hoppinpunten is er een bouwplan nodig. Dat is zo bij het bouwen van fysieke infrastructuur, maar ook bij initiatieven van digitalisatie. De "digitale informatie architectuur" van de hoppinpunten die in het kader van dit VLOCA traject zal worden opgesteld, moet ervoor zorgen dat data over de diensten en wie ze waar en wanneer consumeert op een veilige, gestructureerde en doelgerichte manier wordt ontsloten:
"Veilig" omdat we met persoonlijke data werken. Zelfs zonder iemands identiteit kan je met voldoende mobiliteitsdata heel wat persoonlijke informatie over iemand verwerven, dus moet dat veilig gebeuren, in lijn met de geldende regelgeving rond gegevensbescherming.
"Gestructureerd ” of ook wel “FAIR" genoemd. FAIR data voldoen aan principes van vindbaarheid, toegankelijkheid, interoperabiliteit en herbruikbaarheid. Werken met FAIR data biedt zekerheid en duidelijkheid voor alle betrokken partijen: voor diegene die data moeten leveren beschrijven deze FAIR data principes hoe data best georganiseerd en gestructureerd worden. Voor diegene die data consumeren geven FAIR principes meer duidelijkheid over wat men van de data mag verwachten.
"Doelgericht" omdat zowel burgers als service providers duidelijkheid moet worden gegeven over wie wat met "de data" kan, mag en gaat doen. Als duidelijk blijkt dat het doel van data delen gemeenschappelijk is, namelijk alle services te doen floreren naast en met elkaar en daardoor een betere en efficiëntere mobiliteit te organiseren, alleen dan kan de achterdocht verdwijnen en plaats maken voor samenwerking, ook binnen een commerciële en competitieve setting.
Presentatie
datum : 10/12/2020
Kennismaking presentatie
Voorstelling agenda en afspraken
Slides 1-3
Inleiding VLOCA trajecten (Annelien Dierick, ABB )
Slides 4-18
Combimobilititeit: waarom? (Anne-Marie Van Asbroeck ( IMEC ))
Intro
Slides 19-28
Er is een enorme shift op komst in mobiliteit en om ervoor te zorgen dat dit veilig, vlot en duurzaam kan gebeuren dient er goed afgestemd te worden. Hoppin- of mobipunten zijn daarbij een belangrijke schakel in het geheel: ze zijn herkenbaar, laten een vlotte overstap toe en diensten kunnen hierrond optimaal georganiseerd worden.
We gaan vermijden dat we eindigen met allerlei aangebouwde koterij door samen te werken aan een eengemaakte visie van die VLOCA en haar Standaarden . Waar zal in dit project aan gewerkt worden?
• Op het vlak van het Ecosysteem: mapping van de initiatieven in de markt - ook voor de EU, het in kaart brengen van data van steden en gemeenten, mobiliteit en service providers door kennisdeling.
• Onderzoeken: naar tools en services voor interoperabiliteit tussen spelers zoals steden en gemeenten, MOW , AWV , MaaS spelers, in samenwerking met OASC (Minimum interoperability mechanisms, etc); naar het instellen van een level playing field : de overheid faciliteert marktspelers met Standaarden , implementatie, business cases, afsprakenkader; naar verwachtingen ten aanzien van de digitale zuilen, verwachtingen ten aanzien van de data-infrastructuur.
• Rekening houden met OSLO mobiliteit door te participeren in de OSLO oefening om raakpunten met VLOCA te onderzoeken en te ontdekken ( NeTEx , Datex , ANPR ,..)
Er wordt rekening gehouden met de verschillende stakeholders in het landschap.
Overzicht initiatieven (gemodereerd door Anne-Marie van Asbroeck ( IMEC ))
De basisinfo over deze projecten bevindt zich in de slides 29-45.
Mobiliteitscentrale (Paul Theyskens, MOW )
Dit project heeft een sterke reizigersfocus en is gericht op het plannen, boeken en betalen van ritten. Hiervoor worden statische (locatie) en real-time data van verschillende partners geïntegreerd en in Hoppin-/mobipunten ontsloten. Interoperabiliteit is van groot belang.
National access point transportdata.be (Paul Theyskens, MOW )
Transportdata.be is een website om mobiliteitsdata te delen en moet dienen als centraal punt om die data ter beschikking te stellen voor hergebruikers in binnen- en buitenland.
Europese Standaarden en regelgeving (Paul Theyskens, MOW )
Dit project draait om de uitwerking van de EU richtlijn MultiModal Travel Information Services (MMTIS) en de Gedelegeerde Verordening van de EC waarbij in lijn met EU Standaarden mobiliteitsdata ter beschikking gesteld moeten worden van derden voor hergebruik. De implementatie gebeurt gefaseerd en gaat alsmaar meer details omvatten, zoals bv ook disruptie van bijvoorbeeld busvervoer etc.
Hoppin punten (Natascha Blommaert, AWV )
Het Agentschap voor Wegen en Verkeer ( AWV ) is verantwoordelijk voor het opzetten van de infrastructuur en de aanbestedingen voor de installatie van de Hoppin punten. Hiervoor worden raamcontracten uitgewerkt voor het opzetten van de zuilen als dienstverlening voor de gemeenten en om erover te waken dat de herkenbaarheid en uniformiteit van die punten verzekerd is doorheen heel Vlaanderen. Een deel van die punten zal geïnstalleerd worden op gewestwegen door AWV zelf, een 750-tal punten door de gemeenten; in totaal zo’n 1.000. Er is een analoge en digitale component. De data die gebruikt worden zijn die van de Mobiliteitscentrale.
IoT gestuurde mobi-punten (Ewout De Pauw, stad Stad Aalst )
Dit project dat gecoördineerd wordt door de intercommunale SOLVA (21 gemeenten in arrondissement Aals -Oudenaarde) is erop gericht om in de streek de inpassing van de Hoppin-punten te optimaliseren. Er is reeds vanalles gaande, maar een evaluatie dringt zich op. Hoe kan de kennis van vandaag gebruikt worden voor de Hoppin-punten van de toekomst. Een Proof-of-Concept evaluatiekader wordt uitgewerkt.
eHUBS - Smart Shared Green Mobility Hubs (Eli Nomes, stad Leuven )
De Vlaamse/ Leuvense component van dit EU project geleid door de stad Amsterdam en met deelname van 7 EU steden is erop gericht 50 mobipunten met geïntegreerde e-mobiliteit uit te rollen in het Leuvense . Er is een specifieke taak binnen het project rond data. Harmoniseren van datastromen is een belangrijke doelstelling en er wordt een bijdrage geleverd aan TOMP-API .
Slimme mobiliteit als hoeksteen van een levendige dorpskern (Kenny Stevens, Geetbets )
Om een veiligere en aangename dorpskern te realiseren worden allerlei sensoren toegepast, ANPR camera’s etc. Maar een deel gaat om politionele data die niet zomaar overal voor gebruikt kunnen worden. In dit project wordt gekeken naar welke technologieën ingezet kunnen worden tegen sluipverkeer in kleine gemeenten en tegelijkertijd wordt gekeken hoe ook met het zelfde doel de dorspkern heringericht kan worden waarbij toch een vlotte mobiliteit gevrijwaard blijft. Beslissingen hierover zullen gebaseerd zijn op mobiliteitsdata. Tegelijkertijd wordt gewerkt aan een raamovereenkomsten voor andere kleine gemeenten en dorpskernen zodat ook zij perkeerproblemen en sluipverkeer kunnen aanpakken..
Slimme mobipunten (Veerle Aerts, Peer )
Dit project is reeds afgelopen, maar heeft geleid tot een standaardisatie en modulariteit van de elementen die samen een mobipunt maken om ruimtelijke verrommeling te voorkomen en de prijzen te drukken en daarbij IoT ingebouwd zien op "Plug & Play" wijze. Welke data zijn bv nodig opm een mobipunt optimaal in te planten? Veel inspiratie voor het traject kan hier gevonden worden en hier wordt weer richting raamovereenkomsten gewerkt.
Mobipunt VZW API (Bram Roelant, Mobipunt VZW )
In dit project wordt data die gegenereerd wordt rond de fysieke locaties van mobipunten via API ontsloten naar het bredere palet aan mobiliteitsplatformen in Vlaanderen. Centralisatie van data is noodzakelijk. API en software in ontwikkeling met een sterke focus op gebruiksvriendelijkheid.
Velopark (Pieter Morlion, fiestberaad)
Velopark.be is een digitaal platform dat informatie over fietsenstallingen voor iedereen beschikbaar maakt. Door te koppelen met andere data zoals openbaar vervoer en data van steden en gemeenten, kan zo de velomobiliteit aangezwengeld worden. Deze afstemming is in nederland bijvoorbeeld al veel beter uitgebouwd. Er wordt statische data verstrekt en real-time waar mogelijk/ de applicatie is volledig gebaseerd op open data en is nu al volledig OSLO -compatibel.
OSLO mobiliteit: dienstregeling, uitvoering en planning (Dimitri Schepers, PWC Tim Coninx, De Lijn )
Dit OSLO -traject is erop gericht reizigersinformatie semantisch te verrijken en te structureren in samenspraak met de belanghebbenden (gemeenschappelijk begrippenkader). De eerste generieke standaard is reeds gemaakt en nu wordt er verder concreet gewerkt bv voor de dienstregeling. .
OSLO mobiliteit: trips en aanbod (Dimitri Schepers, PWC )
Dit OSLO traject draait om de ontwikkeling van een OSLO -standaard die erop gericht is vraag en aanbod van mobiliteit door data-analyse beter op elkaar af te stemmen.
OSLO mobipunten/hoppin-punten (Joshua Declercq, MOW )
Hier worden de Standaarden geconsolideerd tot 1 model met focus op de infrastructuur, i.e. de Hoppin/mobipunten.
OSLO fietsnetwerk/fietsinfrastructuur (Joshua Declercq, MOW )
Dit OSLO -traject loopt al langer en heeft dezelfde doeltellingen als bovenstaande OSLO -trajecten maar met een focu op velomobiliteit. Het bovenlokaal fietsnetwerk is een belangrijk deel van de modellen. Er wordt ook gekeken naar standaardisering van velomobiliteitsmetingen die hier en daar lokaal gebeuren, om ervoor te zorgen dat ze breder gebruikt kunnen worden. Men wil ook de verschillende projecten die zich enten op die fietsinfrastructuur beter linken.
Cityflows (Anne-Marie Van Asbroeck, IMEC )
CityFlows brengt multimodale stromen in een stad in één real-time zicht door mobiliteitsgerelateerde datastromen ( Slimme Verkeerslichten , Telecom , WiFi scanning , Floating Car Data , Slimme Camera ’s, open data …) te bundelen via datafusie . Dit project richt zich echt op alle stromen en behelst een grote verscheidenheid aan data. Focusgebied is de Antwerp Smart Zone .
Samen naar een gedeelde architecturale visie (Stefan Lefever, IMEC )
Slides 46-57
Op basis van de net voorgestelde projecten is het duidelijk dat er al veel in beweging is zowel in-the field als conceptueel, de OSLO -trajecten en dit alles zal ooit samen moeten komen. VLOCA zal niet alles oplossen en heeft ook die ambitie niet, maar wil daaraan bijdragen.
Er is ook veel aan de gang in de slimme steden zelf, waar het thema mobiliteit sowieso zal samenkomen met andere thema’s en daarbij moet die Open City Architectuur helpen. Zo is de EU bezig met standaardisering (CEN/TC 684), waarbij ook Agoria -ICT voor Vlaanderen de spiegelcommissie is. Het Wereld Economisch Forum erkent de nood aan zogenaamde Infratech, infrastrustuurtechnologie en daarin speelt de overheid een cruciale rol. Een voorbeeld daarvan zijn de hoppin/mobipunten. Interoperabiliteit en datakwaliteit staan centraal en data-uitwisseling is cruciaal.
In dit project zijn we begin dit jaar gestart met een blauwdruk als uitgangsbasis die een visie beschrijft en waaruit dan principes komen om die architectuur vorm te geven. Daarnaast komen daar ook, gebaseerd op de verschillende marketplaces modulaire Componenten die herbruikbaar zijn, digitaal connecteerbaar en deze kunnen gaan van sensoren tot een bruikbare applicatie voor de burger of overheid. We zullen in VLOCA rond deze principes werken en die gestandaardiseerde Componenten .
Aggregatie uit invulformulieren die door de deelnemers ingevuld werden:
Hieruit kwamen 3 domeinen naar voor die belangrijk zijn om mee te nemen in VLOCA (niet-exhaustief):
1. Gebruik: voor wie, wat zijn de noden?: multimodlaiteit, gebruikerssegmentatie, efficiente betaling en bruikbaarheid van real-time data.
2. Sturing: hoe willen we de data gebruiken om te kunnen sturen? : hoe kan de dienst geoptimaliseerd worden vanuit de data?, cross-domain koppelingen (luchtkwaliteit, veiligheid, parkeerbeleid), data voor multimodale stromen, optimalisering voor beleid, financieel etc.
3. Future-proof elementen: verdere elektrificatie van de mobiliteit (mobiele media als energie-opslag), combinatie met pakketdiensten etc.
Hoe nu een uniforme digitale architecturale aanpak realiseren om uiteindelijk te komen tot een cross-domain open urban platform?
Daarnaast werden ook de volgende meerwaarden die VLOCA kan leveren, geïdentificeerd: betaalbaarheid, herbruikbaarheid, versnelde implementatie, innovatie en adoptie, meer open beschikbare data als hefboom om sneller oplevering mogelijk te maken, betere datakwaliteit zodat er snelle en actionable data zijn, datafusie mogelijk maken, security, data-ownership ( IDSA ) en privacy, betere beleidsinschattingen en meer gerichte financiering. Voor al deze meerwaarden is data een bruikbare grondstof en voor deze data zijn er een aantal belangrijke aandachtspunten. Wat naar voor kwam uit deze bevraging blijkt net hetzelfde te zijn voor het thema water. Door te werken op deze aandachtspunten voor data wil VLOCA meehelpen om sneller, gerichter en dynamischer uit te rollen.
Om dit te doen is een werkwijze nodig, een structuur. Er bestaan al veel referentie-architecturen die dit toelaten. Het OpenDei project wil uit al die verschillende referentie-architecturen een model genereren dat applicatiedomeinen overstijgt en interoperabiliteit vooropstelt. Hierrond werden ook een aantal OpenDei principes gedefinieerd en het model is het 6C model (customization, community, content/context, computing, cyber en connection). Dit model willen we gebruiken als referentie om ons te gidsen; bovendien willen we deze pyramide top-down aanpakken waarbij we starten met customization. Zo hebben we ook de workshops georganiseerd, de eerste WS zal gaan om de value-proposition, welke applicaties, services en beleidsnoden? Deze Ws is eerder voor business en policy profielen. De tweede WS zal eerder gaan over het connect/context en compute gedeelte, eerder data gelinkt en voor data-profielen. De derde workshop over de infrastructuur, de digitale infrastructuur die nodig is om dit te doen ( ANPR , 5G , Tellus , andere sensoren) voor infra-ICT profielen. De laatste werkshop zoomt dan uit en gaat dan over de transversale thema’s zoals security, interoperabiliteit, cross-domain etc.
Semantische onderbouw als leidraad om babylonische spraakverwarring te voorkomen, een gezamenlijke taal. Alles staat op de kennishub, een online webplatform gebaseerd op mediawiki, goed geschikt om co-creatie te doen. Binnen die gemeenschappelijke taal van VLOCA zijn er een aantal belangrijke centrale termen. VLOCA adresseert cross-cutting concerns (bv security), heeft een aantal systeemeigenschappen (bv interoperabiliteit en schaalbaarheid) en bevat [[::Category:Bouwlagen| Bouwlagen]]. Principes zijn belangrijk om openheid te realiseren, het zijn essentiële termen en Componenten , er zijn Standaarden die die Termen & Concepten specifiëren, Organisaties en projecten die die Standaarden beheren en Componenten die Standaarden , Termen & Concepten implementeren.
Het project van Peer is een goed voorbeeld van dit alles. Hier werd gekeken naar wat de uitdagingen zijn van het realiseren van een mobipunt. Wat zijn de ruimtelijke en digitale uitdagingen? Wat is er nodig om er een digitaal knooppunt van te maken? Dit als voorbeeld, maar uiteindelijk moeten al die initiatieven samengebracht worden en moet binnen die gemeenschappelijke taal gebouwd worden aan die architectuur om een VLOCA schema te realiseren met aandacht voor wat nog kan komen in de toekomst.
Discussie en werkplan workshops (Nils Walravens/Mathias Vancompernolle ( IMEC ))
Slides 58-66
De timing van het traject met de verschillende workshops wordt overlopen. Naast de workshops zal een groot deel van het werk ook moeten gebeuren tussen de workshops in en daarvoor is de kennishub het platform om dat te doen.
De globale doelstelling van het traject wordt nog even geschetst. Doel is die VLOCA, maar we gaan niet in detail cases uitwerken.
Uit de input werden een aantal mogelijke vragen/topics gedistilleerd en voor elk van die topics met hun subtopics zullen 3 vragen gesteld worden:
1. Is dit het juiste topic? (werd dit correct gedistilleerd uit de geleverde input in de invulformulieren.
2. Zijn het de juiste / Ontbreken er subvragen?
3. Welke andere topics zijn er nog?
Klantrelatie
Wie heeft/wil de klantrelatie?
Issues hier zijn bv. veelheid aan toepassingen, combimobiliteit, een andere login voor elke toepassing...
Hoe organiseren we dat zonder dat de gebruiker daar last van heeft?
MaaS en betalen?
En die klantrelatie heeft natuurlijk zijn implicaties voor betalingen, want naast data zullen ook deze uitgewisseld moeten worden.
bv. derdebetalerssyteem mogelijk maken: alle bezoekers aan een event mogen gratis met de bus komen. --> de architectuur moet aandacht hebben voor verschillende types transacties.
Opmerking: MOW heeft een MaaS project ( Vlaams MaaS afsprakenkader ) waarin dit aan bod komt, dus best daarmee aligneren. Breng wat uit dat project komt ook hier in. Het is wel niet juridisch afdwingbaar, maar hier wordt overeengekomen tussen alle spelers in het ecosysteem.
A: Dit zal zeker gebeuren door VLOCA.
Worden er al architecturale aspecten meegenomen in dit Vlaams MaaS afsprakenkader?
A: Er is een werkgroep rond data en technologie waarin tech mapping ( OSLO , TOMP-API, …) bezig is, maar niet specifiek voor dit topic, doch aansluiting is zeker nodig.
Opmerking: In Vlaanderen wil men SOLID principes gebruiken om hiermee om te gaan (bestuurscomité kruispuntbank Vlaanderen) zodat personen zelf de regie hebben over hun gegevens.
Opmerking: Hou ook rekening met niet-Belgen en dat die mogelijk niet dezelfde mogelijkheden hebben.
welke visie is er voor die 1.000 Hoppin zuilen in Vlaanderen? We mogen de realiteit niet uit het oog verliezen en ook die visie mee te nemen. Theorie en praktijk dienen goed op elkaar afgestemd te worden.
A: Jazeker!
Opmerking: Opgepast voor het “techie” standpunt in SOLID , graag ook aandacht voor het gebruikersstandpunt, anders is het risico groot dat gebruikers afhaken.
A: Het identiteitsconcept en zelfbeheerconcept is belangrijk. Opmerking: Vanuit praktijk beginnen! MaaS en betalingsproblematiek is niet oplosbaar in de mobipunten. Er zijn al andere initiatieven mee bezig. Derdebetalerssytemen kunnen wel behandeld worden, maar dat is eerder een administratieve formaliteit. Wat vooral ontbreekt is dat bestaande user-journeys nog onvoldoende gebruikt worden. Dat gebeurt nu wel, maar we moeten vermijden dat elk mobipunt dat apart gaat doen met data van de Lijn, NMBS etc. Zet de mobiliteitscentrale als eerste gebruiker voorop en genereer iets generiek dat dan verder gebruikt kan worden en aan derden aangeboden kan worden. Anders wordt er dubbel werk gedaan. Bv. voetgangersstromen in Brussel om overstappunten af te stemmen op die stromen. Heb niet enkel aandacht voor de eindgebruiker maar ook voor de noden van de tussengebruikers. Laten we werken aan een continuous improvement, en start met prioriteits-use-cases. Kijk hoe AGILE improvements daarin ingebracht kunnen worden.
A: We vermijden techie-standpunten door co-creatief te werk te gaan in de trajecten.
Toegang tot data
Hoe organiseren we toegang tot data?
Belangrijke termen hier zijn: vindbaarheid, beschikbaarheid, toegankelijkheid (bv. ruwe data, visualisatie, dashboards…), bruikbaarheid (bv. detailniveau, real-time…) en openheid.
Bijvoorbeeld: de mogelijkheid om mobiliteitsdata te verkennen tot op straatniveau en aanpassingen te doen aan het netwerk om het effect ervan te kunnen inschatten.
We aligneren met OSLO .
Opmerking: De apetijt om data aan te leveren is kleiner bij bedrijven dan verwacht wordt op beleids- en tech-niveau. We moeten rekening houden met de economische realiteit en vraagstukken in deze voor die bedrijven in plaats van ons over te geven aan wishful thinking.
Opmerking: Een groot deel van wat hier op tafel ligt is al uitgewerkt door Mobipunt VZW , taxistop en E-Hubs project. Hou hier aub rekening mee want er wordt niet van nul gestart.
A: zeer waardevol, nemen we zeker mee.
Opmerking: Veel data zit vast in silo’s en achter betaalmuren.
Er zal een lijstje van potentiële topics voor de workshops gemaakt worden op de kennishub zodat deelnemers daar suggesties kunnen doen.
Data-Uitwisseling
Hoe organiseren we het uitwisselen van data?
Hoe kunnen mobiliteitsaanbieders bepaalde data delen/moeten delen zonder dat dit essentiële informatie vrijgeeft voor concurrenten in een moeilijke markt (deelfietsen, deelauto's, etc.)?
Kan een databroker dit mogelijk maken?
Data zit in silo’s en in verschillende (verouderde) vormen. Het is belangrijk om te komen tot hedendaagse databrokers, bruikbaar voor alle spelers, ook de kleine KMO.
A: toegankelijkheid en bruikbaarheid zijn belangrijke topics.
Wie beheert de data van de mobipunten? Hier is al aan gewerkt door allerlei organisaties , ook dashboards voor lokale besturen.
A: Dit gaat over het governance-vraagstuk. We zullen hiervoor aandacht hebben.
Meerwaarde voor (lokale) besturen
Vertaling naar de praktijk van het (lokaal) bestuur?
Mapping van digitale en fysieke inplanting van de benodigde overstap-infrastructuur (gemeentelijke/stedelijke planning).
Hoe kan data ontsluiting continu bijdragen tot een betere rollout van de combimobi infrastructuur?
Opmerking: Deze vertaling is zeer belangrijk voor lokale besturen, is een goede eerste stap. Maar ook voor bovenlokale overheden.
Opmerking: een goed overzicht van bewegingen is al zeer interessant voor lokale stakeholders (ook KMO’s), snel leren over lokale mobiliteit (bv over files en luchtvervuiling door verkeerde instelling van verkeerslichten). Hoe kan de lokale mobiliteitsambtenaar deze info overdragen naar lokale stakeholders?
Q: Kunnen we de koppeling maken met wat er gebeurt in de vervoersregio’s? Kunnen de mobipunten geëvalueerd worden over de regio’s heen?
Q: Hoe zit het met de governance van dit project zelf? Is er voldoende afstemming met MOW ? Hoe vermijden we dubbel werk en zorgen we ervoor dat dit alles versterkend werkt.
A: daarvoor is de kennishub opgezet en er zal zeker met MOW samengewerkt worden, ze zijn hier cvandaag ook aanwezig. Al wat impact heeft op het architecturale plaatje zal afgestemd worden.
A: er is sinds begin januari een nieuwe Hoppin medewerker bij MOW , dus maak daar gebruik van.
A: er is een ambtelijke stuurgroep in dit project met brede vertegenwoordiging van Vlaamse administratie ( MOW , AIV , VLAIO , ABB , VMM ).
Q: Zal ook de visie van de burgers meegenomen worden?
A: Er is een deelproject in het programma basisbereikbaarheid specifiek over mobipunten. Er is een manager op businessniveau die de stakeholders samenbrengen en het zou goed zijn dat deze oefening daarop kan aansluiten (via programmamanager Eric Sempels).
Voor MOW , mobiliteitscentrale is herbruikbaarheid van service belangrijk zodat anderen daarmee zelf aan de slag kunnen voor hun eigen lokale initiatieven.
Slotvraag : wat willen jullie concreet gerealiseerd zien op het einde van het traject ?
Vb. Gedeelde informatiemodellen, gedeelde semantiek, afspraken rond communicatie Standaarden en uitwisselings Standaarden , protocollen, voorbeeldclausules voor bestekken, gebruik bestaande bouwblokken, ...
Opmerking: Bezorgdheid mbt de timing van de workshops en alignering met allerlei projecten van MOW die pas opleveren in 2021 en 2022.
A: Timing is een belangrijke parameter in dit verhaal, we houden hiermee rekening; er zal een traject gemaakt worden rond data-brokers etc. VLOCA gaat net bijdragen aan alignering tussen de verschillende lopende initiatieven. VLOCA is geen eindpunt.
Opmerking: MOW kent zeer harde deadlines tov kabinet en timings zijn gebetonneerd. Ook de inzet van MOW in VLOCA wordt hier deels door gehypothekeerd. Er zijn reeds heel wat vertragingen. Het gaat niet alleen om timing, maar ook om capaciteit om hieraan te werken. Toch een beetje de indruk dat er dubbel werk gedaan zal worden, dus kijk goed wat al gebeurd is zodat MOW -ers niet extra belast worden.
A: We zullen waar mogelijk zaken ter hergebruiken en geen dubbel werk te genereren.
Q: Wordt het resultaat van dit traject overgedragen aan een operationele organisatie?
A: Dit is werk voor het governance werkpakket. Hiervoor worden een aantal realistische scenario’s opgesteld en voorgelegd en besproken in verkennende gesprekken.
Opmerking: Er is veel in beweging, breng zaken samen en kijk waar de missing links zitten in wat er al bezig is, misschien wordt daar best op gefocust en zo kunnen win-wins gerealiseerd worden. ,
Opmerking: Er zijn al vele harde deadlines van projecten die gehaald moeten worden en die deadlines veroorzaken/linken met silo’s. En toch is alles in constante evolutie. Zorg ervoor dat silo’s ge-elimineerd kunnen worden en duplicaties vermeden. Werk naar een toegankelijke service toe, eenvoudig op in te loggen. We moeten ons organiseren naar constante verandering.
Dank voor de waardevolle input!
Verdere feedback en voorbereiding workshop 1 (Piet Seuntjens ( VITO ) en Stefan Lefever ( IMEC ))
Slides 67-77
Piet schetst het belang van de kennishub als centraal gegeven in de trajecten.
Stefan legt uit hoe er praktisch gewerkt kan worden met de kennishub (aanmaken account, content toevoegen, taggen etc.).
Afsluitend woordje (Annelien Dierick, ABB )
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:
Thematisch:
Water in de Stad
Mobiliteit: Hoppinpunten
Technisch:
Databroker
Local Digital Twin
Topic en project gebonden
Lawaai
Linken van ongestructureerde data uit besluiten van lokale besturen (PROBE)
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.
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:
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.
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.
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:
Alle ideaalbeelden en gekoppelde data werden bij elkaar gebracht om tot drie algemene use cases te komen die tijdens de breakouts verder uitgediept werden:
Als (medewerker van) een lokaal bestuur, heb ik relevante data nodig om het gebruik van een hoppinpunt te evalueren.
Als dienstverlener/operator, wil ik aan de hand van data in de buurt/aan een hoppinpunt een nieuwe dienst aanbieden voor reizigers.
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.
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.
Class definitions aanpassen
In CSP Basis 1.8.0 the default sidebar was added, this allows you to have sidebars without having to create custom sidebar templates for each class definition. There are some customization options built into the default sidebar as well. It is recommended to use these customization options when possible and to only create fully custom sidebar templates when absolutely necessary, as the fully custom sidebar templates require a lot more maintenance work when for example some parserfunctions get deprecated. This document describes the various customization options.
Inhoud
1 Class definitions aanpassen
1.1 Parameters and formfield/display templates
1.2 Custom formfield/display templates
1.3 Custom sidebar template where you are adding to the default sidebar
1.4 Fully custom sidebar template
Parameters and formfield/display templates
Edit parameters on a class definition page, to configure what will show up on your sidebar.
Note that the parameter configuration is also used for setting properties, but you can use "(none)" as property name value if you don't want to set a property.
Only the "parameter name" field is required. When you only fill this, you will get default text fields in the sidebars.
Choose a displayTemplate to configure how a parameter is displayed in the view tab of the default sidebar.
Choose a formfieldTemplate to coinfigure what type of form field is used in the edit tab of the default sidebar.
DisplayTemplate and formfieldTemplate can both be set to "(none)" to not have a parameter show up in respectively the view and edit tabs of the default sidebar.
Custom formfield/display templates
It is possible to add custom template names in the displayTemplate and formfieldTemplate fields.
All fields that are filled for a parameter will be passed to the templates so they can be accessed through template parameters there. For example you can use {{{allowedValues|}}} in a formfieldTemplate. It might be useful to look at the ws-data slot of the class definition to see all of the parameters.
The values of parameters on a content page are also passed to the display/formfield templates as the "value" parameter.
In a display/formfield templates you cannot access values of other parameters directly, but you can do this by using {{#invoke:CspFunctions|getParentArgs|$pageData}}, which will return the $pageData parameter that is used in Template:Csp default sidebar (and contains an ArrayFunctions export with slotdata of the page).
It is possible to add fields to the json data in the ws-data slot that cannot be filled through the parameters form. For example CSP 1.8.0 does not yet include the option to specify a placeholder for your formfields, but you can add placeholder to the json data and then use {{{placeholder|}}} in a custom formfieldTemplate.
Custom sidebar template where you are adding to the default sidebar
In many cases you won't necessarily want to replace the default sidebar, but you may want to add another card above or below it with additional functionality. It is possible to use the default sidebar within a custom sidebar template. For example like the following code snippet: {{Csp default sidebar
|$pageData={{{$pageData|}}}
|$classData={{{$classData|}}}
}}
{{Csp sidebar tabs
|id=another-card
|canEdit=yes
|closeButton=
|title=Another card
|subTitle=Below the default sidebar
|view=<div class="card-body">viewtab content</div>
|edit=<div class="card-body">edittab content</div>
}}
Fully custom sidebar template
In a fully custom sidebar template you can do anything you want. You will still get the $pageData and $classData parameters passed to this template so you can use those. The following is an example of custom sidebar code that will produce a sidebar similar to the default one, perhaps this will give you some ideas for what's possible:
<div class="tab-content"><!--
--><input type="radio" id="sidebar-view" name="toggle-sidebar" checked="checked" class="d-none sidebar-view" /><!--
--><div class="card sidebar-view-tab">
<div class="card-header">{{#ifeq:{{#ifingroup:user |{{#if:{{#urlget:veaction}}{{#urlget:action}}||yes}} }}|yes |<span style="float:right"><label for="sidebar-edit" class="btn btn-secondary">Edit</label></span>}}
<b class="d-block">{{#af_get:{{{$pageData}}}|ws-base-props|Base properties|1|Class|_text}}</b>
{{#af_get:{{{$pageData}}}|ws-base-props|Base properties|1|Title|_text}}
</div><!-- end of .card-header -->
<div class="card-body">
{{Sidebar item
|Label=Title
|Value={{#af_get:{{{$pageData}}}|ws-base-props|Base properties|1|Title |_text}}
}}{{Sidebar item
|Label=TextInput
|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TextInput |_text}}
}}{{Sidebar item
|Label=TokenInput
|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TokenInput |_text}}
}}{{Sidebar item
|Label=AskTokenInput
|Value={{#af_join:{{#af_map:{{#af_split:{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|AskTokenInput |_text}}|,}}|@@|[[{{{@@}}}|{{#show:{{{@@}}}|?Title}}]]}}|<br>}}
}}{{Test date display
|Name=DateInput
|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|DateInput |_text}}
}}
{{Sidebar item
|Label=DateInputTwo
|Value={{#if:{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|DateInputTwo |_text}} |{{#time: j M Y H:i |{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|DateInputTwo |_text}} }} }}
}}{{Sidebar item
|Label=TextInputTwo
|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TextInputTwo |_text}}
}}{{Sidebar item
|Label=CheckboxInput
|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|CheckboxInput |_text}}
}}{{Sidebar item
|Label=TextAreaInput
|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TextAreaInput |_text}}
}}{{Sidebar item
|Label=NumberInput
|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|NumberInput |_text}}
}}{{Sidebar item
|Label=SelectInput
|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|SelectInput |_text}}
}}{{Sidebar item
|Label=TokenMultipleInput
|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TokenMultipleInput |_text}}
}}{{Sidebar item
|Label=Rob parameter
|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|Rob parameter |_text}}
}}<!--
--></div><!-- end of .card-body -->
</div><!-- end of .card
-->{{#ifeq:{{#ifingroup:user |{{#if:{{#urlget:veaction}}{{#urlget:action}}||yes}} }}|yes |<!--
--><input type="radio" id="sidebar-edit" name="toggle-sidebar" class="d-none sidebar-edit" /><!--
--><div class="card sidebar-edit-tab"><!--
--><div class="card-header"><span style="float:right"><label for="sidebar-view" class="btn btn-secondary" >Close</label></span>
<b class="d-block">{{#af_get:{{{$pageData}}}|ws-base-props|Base properties|1|Class|_text}}</b>
{{#af_get:{{{$pageData}}}|ws-base-props|Base properties|1|Title|_text}}
</div><!-- end of .card-header -->
<div class="card-body">
<form action="addToWiki"><!--
// _edits: no edit when formfieldType is set to "(none)"
--><_edit target="{{PAGEID}}" template="Base properties" formfield="Title" mwslot="ws-base-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="TextInput" mwslot="ws-class-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="TokenInput" mwslot="ws-class-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="AskTokenInput" mwslot="ws-class-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="DateInput" mwslot="ws-class-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="DateInputTwo" mwslot="ws-class-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="TextInputTwo" mwslot="ws-class-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="CheckboxInput" mwslot="ws-class-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="TextAreaInput" mwslot="ws-class-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="NumberInput" mwslot="ws-class-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="SelectInput" mwslot="ws-class-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="TokenMultipleInput" mwslot="ws-class-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="TestNoDisplay" mwslot="ws-class-props" />
<_edit target="{{PAGEID}}" template="Csp class properties" formfield="Rob parameter" mwslot="ws-class-props" />
<!-- end of _edits
// form fields
-->{{Sidebar item
|Label=Title
|Value=<input type="text" name="Title" class="form-control" required="required" value="{{#af_get:{{{$pageData}}}|ws-base-props|Base properties|1|Title|_text}}" />
}}
{{Sidebar item
|Label=TextInput
|Value=<input type="text" name="TextInput" class="form-control" required="required" value="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TextInput|_text}}" />
}}
{{Sidebar item
|Label=TokenInput
|Value=<_token id="token-{{lc:{{anchorencode:TokenInput}} }}" name="TokenInput[]" class="form-control" allowclear selected="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TokenInput|_text}}" options="Ay,Bee,Cee" />
}}
{{Sidebar item
|Label=AskTokenInput
|Value=<_token id="token-{{lc:{{anchorencode:AskTokenInput}} }}" name="AskTokenInput[]" class="form-control" required="required" multiple="multiple" input-length-trigger="1" query="[[Class::+]][[Title::!!!]](limit=999)(returntext=Title)" >
{{#af_join:{{#af_map:{{#af_split:{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|AskTokenInput|_text}} }} |$value|<option value="{{{$value}}}" selected="selected">{{#show:{{{$value}}}|?Title}}</option>}}|\n}}
</_token>
}}
{{Test date formfield
|Name=DateInput
|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|DateInput|_text}}
}}{{Sidebar item
|Label=DateInputTwo
|Value=<input type="datetime-local" name="DateInputTwo" class="form-control" value="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|DateInputTwo|_text}}" />
}}
<div class='alert alert-danger'>No template defined in parameter definitions</div>{{Sidebar item
|Label=<label for="checkbox-{{lc:{{anchorencode:CheckboxInput}} }}" >CheckboxInput</label>
|Value=<input type="hidden" name="CheckboxInput" value="" />
<input type="checkbox" id="checkbox-{{lc:{{anchorencode:CheckboxInput}} }}" name="CheckboxInput" value="Yes" checked="{{#ifeq:{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|CheckboxInput|_text}} |Yes|checked}}" />
}}
{{Sidebar item
|Label=TextAreaInput
|Value=<input type="textarea" name="TextAreaInput" class="form-control" >{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TextAreaInput|_text}}</input>
}}
{{Sidebar item
|Label=NumberInput
|Value=<input type="number" name="NumberInput" class="form-control" value="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|NumberInput|_text}}" />
}}
{{Sidebar item
|Label=SelectInput
|Value=<select name="SelectInput" class="form-control" allowclear selected="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|SelectInput|_text}}" options="Alpha,Bravo,Charlie" />
}}
{{Sidebar item
|Label=TokenMultipleInput
|Value=<_token id="token-{{lc:{{anchorencode:TokenMultipleInput}} }}" name="TokenMultipleInput[]" class="form-control" multiple="multiple" selected="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TokenMultipleInput|_text}}" options="Alpha,Bravo,Charlie" />
}}
{{Sidebar item
|Label=TestNoDisplay
|Value=<input type="text" name="TestNoDisplay" class="form-control" value="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TestNoDisplay|_text}}" />
}}
{{Sidebar item
|Label=Rob parameter
|Value=<input type="number" name="Rob parameter" class="form-control" value="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|Rob parameter|_text}}" />
}}
<!--
--><div class="text-right">
<label for="sidebar-view" class="btn btn-secondary">Close</label>
<input type="submit" value="Save" class="btn btn-primary" />
</div>
</form>
</div><!-- end of .card-body -->
</div><!-- end of .card -->
|}}<!-- end of #ifeq @allow sidebar edit == yes -->
</div>
Deze pagina is momenteel in opmaak door VLOCA en mogelijks nog geen reflectie werkelijke toestand organisatie.
Korte Beschrijving
Klimaatadaptatie: zeer lage waterpeilen en langdurige droogteperiodes, enerzijds, en verhoogde afvoeren en overstromingsrisico’s als gevolg van extreme neerslag anderzijds.
- Eenvoudiger en real-time kunnen raadplegen van data zorgt er voor dat tijdig kan worden geanticipeerd op droogte en wateroverlast.
- Waterbeheerders zullen beroep kunnen doen op continue en betrouwbare metingen in plaats van te moeten vertrouwen op handmatige, sporadische metingen.
- Op de langere termijn kan dit meetnet opportuniteiten en pijnpunten in en rond onze waterlopen aan het licht brengen.
- Het openbaar stellen van de metingen moet leiden tot een betere coördinatie en samenwerking met andere waterbeheerders (bv. landbouw of natuursector).
Beschrijving Architectuur
De architectuur is nog in opbouw en is nog onderhevig zijn aan veranderingen. Onderstaande afbeelding toont dan ook een schets van hoe de architectuur zal worden opgezet.
Schets van architectuur.
Sensor Toepassingen
Toepassingen
Type toepassing
Fase project (uitvoering, voorbereiding)
Type sensor
Meetfrequentie
Zendfrequentie
Netwerk keuze
Aantal sensoren
Belangrijkste meerwaarde sensor voor deze usecase?
1
Onbevaarbare waterlopen
Uitvoering
Peilsensoren
15m
15m
LoRa/GPRS
30 (doel = 80)
Real-time + veel locaties
Sensor evaluatie
Provincie Antwerpen
Parameters
Type Sensor
Fabrikant
Troeven
Beperkingen
Tips en Tricks
1
Waterniveau
Akoestisch
Fluves, Decentlab en Multiflexmeter
Makkelijk te plaatsen, real-time
Temperatuur correctie nodig, vegetatie e.d. onder sensor verstoren signaal
Hang de sensor zo dat het signaal niet kan weerkaatsen op constructies, zoals de kopmuur.
2
Waterniveau
Radar
VMM
Geen temperatuur correctie nodig, real-time
Vegetatie e.d. onder sensor verstoren signaal
Hang de sensor zo dat het signaal niet kan weerkaatsen op constructies, zoals de kopmuur.
3
Waterniveau
Druk
Keller
Geen problemen met vegetatie e.d., kan real-time
Aan duurdere kant, niet vandalisme-proof
Handig voor locaties zonder constructies of constructies die af en toe onder water komen te staan. Weliswaar eerder aan te raden op afgelegen locaties.
Lessons learned
- Het is echt nodig het beheer van de sensoren op voorhand mee in te calculeren om een realistisch zicht te krijgen op timing en workload.
- Beperkte datavalidatie valt te automatiseren (extreme outliers, foutmeldingen), maar de fijnere dingen blijven vooral handwerk.
Deze pagina is momenteel in opmaak door VLOCA en mogelijks nog geen reflectie werkelijke toestand organisatie.
Korte Beschrijving
Klimaatadaptatie: zeer lage waterpeilen en langdurige droogteperiodes, enerzijds, en verhoogde afvoeren en overstromingsrisico’s als gevolg van extreme neerslag anderzijds.
- Eenvoudiger en real-time kunnen raadplegen van data zorgt er voor dat tijdig kan worden geanticipeerd op droogte en wateroverlast.
- Waterbeheerders zullen beroep kunnen doen op continue en betrouwbare metingen in plaats van te moeten vertrouwen op handmatige, sporadische metingen.
- Op de langere termijn kan dit meetnet opportuniteiten en pijnpunten in en rond onze waterlopen aan het licht brengen.
- Het openbaar stellen van de metingen moet leiden tot een betere coördinatie en samenwerking met andere waterbeheerders (bv. landbouw of natuursector).
Beschrijving Architectuur
De architectuur is nog in opbouw en is nog onderhevig zijn aan veranderingen. Onderstaande afbeelding toont dan ook een schets van hoe de architectuur zal worden opgezet.
Schets van architectuur.
Sensor Toepassingen
Toepassingen
Type toepassing
Fase project (uitvoering, voorbereiding)
Type sensor
Meetfrequentie
Zendfrequentie
Netwerk keuze
Aantal sensoren
Belangrijkste meerwaarde sensor voor deze usecase?
1
Onbevaarbare waterlopen
Uitvoering
Peilsensoren
15m
15m
LoRa/GPRS
30 (doel = 80)
Real-time + veel locaties
Sensor evaluatie
Provincie Antwerpen
Parameters
Type Sensor
Fabrikant
Troeven
Beperkingen
Tips en Tricks
1
Waterniveau
Akoestisch
Fluves, Decentlab en Multiflexmeter
Makkelijk te plaatsen, real-time
Temperatuur correctie nodig, vegetatie e.d. onder sensor verstoren signaal
Hang de sensor zo dat het signaal niet kan weerkaatsen op constructies, zoals de kopmuur.
2
Waterniveau
Radar
VMM
Geen temperatuur correctie nodig, real-time
Vegetatie e.d. onder sensor verstoren signaal
Hang de sensor zo dat het signaal niet kan weerkaatsen op constructies, zoals de kopmuur.
3
Waterniveau
Druk
Keller
Geen problemen met vegetatie e.d., kan real-time
Aan duurdere kant, niet vandalisme-proof
Handig voor locaties zonder constructies of constructies die af en toe onder water komen te staan. Weliswaar eerder aan te raden op afgelegen locaties.
Lessons learned
- Het is echt nodig het beheer van de sensoren op voorhand mee in te calculeren om een realistisch zicht te krijgen op timing en workload.
- Beperkte datavalidatie valt te automatiseren (extreme outliers, foutmeldingen), maar de fijnere dingen blijven vooral handwerk.
HydroScan werd opgericht in 2003 en is een pionier in integrale watermodellering. De organisatie is een expert in holistische, geïntegreerde oplossingen voor een duurzamer en kosteneffectiever waterbeheer.
Meer informatie is hier beschikbaar. +
I
Voor een definitie van deze afkorting verwijzen we naar [1]
↑ https://nl.wikipedia.org/wiki/Informatietechnologie +
Een geschematiseerde voorstelling van IDA datastromen tussen Organisaties . +
International Data Spaces Association
International Data Spaces
Het uitwisselen van gegevens is de sleutel voor veel Organisaties . Binnen het domein van slimme steden worden gegevens gegenereerd door apparaten, opgeslagen in een database en gebruikt voor evaluatie door anderen. Bij alle drie de stappen zijn verschillende Organisaties betrokken. Ze willen weten, en bepalen hoe hun gegevens worden gebruikt of waar ze vandaan komen.
De International Data Spaces Association pakt dit probleem aan: het heeft een referentiearchitectuur en een formele standaard gedefinieerd die moet worden gebruikt voor het maken en beheren van “virtuele gegevensruimten”(virtual data spaces). De IDS-architectuur is gebaseerd op algemeen aanvaarde modellen voor gegevensbeheer die veilige uitwisseling en eenvoudige koppeling van gegevens binnen ecosystemen mogelijk maken.
De IDS-architectuur zorgt voor digitale soevereiniteit voor gegevenseigenaren die gegevens beschikbaar stellen voor de uitwisseling of het delen met met anderen. Het vormt daarmee de basis voor het ontwikkelen en aanbieden van slimme diensten en voor het opzetten van innovatieve bedrijfsprocessen. Het is gericht op het creëren van een veilige en vertrouwde ruimte waarin bedrijven hun gegevens soeverein kunnen beheren.
IDSA Organisatie
IDSA bestaat uit een groot aantal Organisaties uit verschillende domeinen zoals automotive, Telecom , retail, kennisinstellingen, software consultancy Organisaties en anderen. Ook FIWARE is lid en vertegenwoordigd in de IDSA Raad van bestuur. Verder is ook IMEC lid van IDSA .
Een volledige lijst is hier te vinden [1]
Certificatie
Naast software is het ook belangrijk ervoor te zorgen dat Organisaties die data delen, elkaar vertrouwen met betrekking tot data soevereiniteit . Om dit te garanderen kan IDSA ook Organisaties en software certificeren. Daartoe heeft het de volgende certificaten gecreëerd:
IDS READY Organisation. Certificering wordt afgehandeld door PWC of TUV SUD;
IDS Ready Component. Certificering wordt afgehandeld door Fraunhofer.
[2]
IDS Architectuur
De IDS-architectuur is gebaseerd op de volgende drie principes
Onbeperkte interoperabiliteit: IDS wil de standaard zijn voor de gegevensstroom tussen allerlei gegevenseindpunten;
Vertrouwen tussen verschillende beveiligingsdomeinen: uitgebreide beveiligingsfuncties bieden die een maximum aan vertrouwen bieden;
governance voor data-economie: gebruikscontrole en handhaving voor datastromen
[[File: IDSA trustworthy architecture.jpg|thumb|left|800px]]
IDS-connector
De belangrijkste IDS-component is de IDS-connector. Het is de softwarecomponent die verantwoordelijk is om gegevensuitgevers en gegevensconsumenten in staat te stellen gegevens uit te wisselen, te delen en te verwerken. Dit, rekening houdend met de soevereiniteit van de gegevenseigenaren.
De architectuurspecificatie van IDS is hier te vinden: [3]
Relatie tussen IDSA en Gaia-X
Hiervoor werd een heel interessante position paper gepubliceerd die een mapping weergeeft van de IDSA bouwblokken op de Gaia-X technische architectuur : https://internationaldataspaces.org/wp-content/uploads/IDSA-Position-Paper-GAIA-X-and-IDS.pdf
Dit ziet er als volgt uit :
IDSA architectuur +