Op eigenschap zoeken

Deze pagina biedt een eenvoudige bladerinteractie voor het vinden van entiteiten met een eigenschap met een bepaalde waarde. Andere beschikbare zoekinteracties zijn de zoekpagina voor pagina-eigenschappen en de querybouwer.

Lijst van resultaten

Template:Managed {{Uploaded Image |Page= <required> }} +
Test +
Text +
This is a property of type Text . +
Template:Managed {{Standaard sidebar }} $base array is defined in MediaWiki:Ws-sub-header $page array is defined in MediaWiki:Ws-sub-header +
Template:Managed {{Technologie properties |Abstract= <text> |Tags= <text> }} +
Template:Managed {{TermenConcepten pro … Template:Managed {{TermenConcepten properties|Abstract= <text>|CoCreatieAanvraag= <text> (csv)|VlocaSessie= <text> (csv)|Draaiboek= <text> (csv)|Actoren= <text> (csv)|Organisatie= <text> (csv)|Organisaties= <text> (csv)|Standaard= <text> (csv)|Maturiteitstype= <text>|Status= <text>|SmartCityDomein= <text> (csv)|SmartCityComponent= <text> (csv)|Website= <text>|VlocaTraject= <text> (csv)|SessieType= <text>|ArchitectuurComponent= <text> (csv)|ArchitectuurBouwlaag= <text> (csv)}}ocaTraject= <text> (csv) |SessieType= <text> |ArchitectuurComponent= <text> (csv) |ArchitectuurBouwlaag= <text> (csv) }} +
Template:Managed {{TermenConcepten sidebar }} $base array is defined in MediaWiki:Ws-sub-header $page array is defined in MediaWiki:Ws-sub-header +
Template:Managed {{Uploaded File |Page= <required> |Title= <optional> }} +
Template:Managed {{VlocaSessie propert … Template:Managed {{VlocaSessie properties|Abstract= <text>|CoCreatieAanvraag= <text> (csv)|VlocaSessie= <text> (csv)|Draaiboek= <text> (csv)|Actoren= <text> (csv)|Organisatie= <text> (csv)|Organisaties= <text> (csv)|Standaard= <text> (csv)|Maturiteitstype= <text>|Status= <text>|SmartCityDomein= <text> (csv)|SmartCityComponent= <text> (csv)|Website= <text>|VlocaTraject= <text> (csv)|SessieType= <text>|Datum= <text>|Tijd= <text>|Locatie= <text>|ArchitectuurComponent= <text> (csv)|ArchitectuurBouwlaag= <text> (csv)}}t;text> |Datum= <text> |Tijd= <text> |Locatie= <text> |ArchitectuurComponent= <text> (csv) |ArchitectuurBouwlaag= <text> (csv) }} +
Template:Managed {{VlocaSessie sidebar }} $base array is defined in MediaWiki:Ws-sub-header $page array is defined in MediaWiki:Ws-sub-header +
Template:Managed {{VlocaTraject proper … Template:Managed {{VlocaTraject properties|Abstract= <text>|CoCreatieAanvraag= <text> (csv)|Jaar= <text> (csv)|ServiceType= <text> (csv)|VlocaSessie= <text> (csv)|Draaiboek= <text> (csv)|Deliverable= <text> (csv)|Actoren= <text> (csv)|Organisatie= <text> (csv)|Organisaties= <text> (csv)|Standaard= <text> (csv)|Status= <text>|SmartCityDomein= <text> (csv)|SmartCityComponent= <text> (csv)|Initiatief= <text> (csv)|Website= <text>|VlocaTraject= <text> (csv)|SessieType= <text>|ArchitectuurComponent= <text> (csv)|ArchitectuurBouwlaag= <text> (csv)|TrajectID= <text> (csv)}}ect= <text> (csv) |SessieType= <text> |ArchitectuurComponent= <text> (csv) |ArchitectuurBouwlaag= <text> (csv) |TrajectID= <text> (csv) }} +
Template:Managed {{VlocaTraject sidebar }} $base array is defined in MediaWiki:Ws-sub-header $page array is defined in MediaWiki:Ws-sub-header +
Template:Managed This is the "Property values" template. It should be called in the following format: {{Property values |1=Class name |2=Property requested }} +
Template:Managed This is the Initiatief … Template:Managed This is the Initiatief properties template. It should be called in the following format: {{Initiatief properties|Abstract= <text>|CoCreatieAanvraag= <text> (csv)|VlocaSessie= <text> (csv)|Draaiboek= <text> (csv)|Actoren= <text> (csv)|Organisatie= <text> (csv)|Organisaties= <text> (csv)|Standaard= <text> (csv)|Maturiteitstype= <text>|Status= <text>|SmartCityDomein= <text> (csv)|SmartCityComponent= <text> (csv)|Website= <text> (csv)|VlocaTraject= <text> (csv)|SessieType= <text>|ArchitectuurComponent= <text> (csv)|ArchitectuurBouwlaag= <text> (csv)|Initiatief= <txt> (csv)}}(csv) |SessieType= <text> |ArchitectuurComponent= <text> (csv) |ArchitectuurBouwlaag= <text> (csv) |Initiatief= <txt> (csv) }} +
Template:Managed This is the Organisatie overview template. It should be called in the following format: {{Organisatie overview }} +
Template:Managed This is the Organisatie … Template:Managed This is the Organisatie properties template. It should be called in the following format: {{Organisatie properties|Abstract= <text>|CoCreatieAanvraag= <text> (csv)|VlocaSessie= <text> (csv)|Draaiboek= <text> (csv)|Actoren= <text> (csv)|Organisatie= <text> (csv)|Organisaties= <text> (csv)|Standaard= <text> (csv)|Maturiteitstype= <text>|Status= <text>|SmartCityDomein= <text> (csv)|SmartCityComponent= <text> (csv)|Website= <text>|VlocaTraject= <text> (csv)|SessieType= <text>|ArchitectuurComponent= <text> (csv)|ArchitectuurBouwlaag= <text> (csv)}}ocaTraject= <text> (csv) |SessieType= <text> |ArchitectuurComponent= <text> (csv) |ArchitectuurBouwlaag= <text> (csv) }} +
Template:Managed This is the Organisatie properties template. It should be called in the following format: {{Page properties |Is page= 'Yes' or leave blank }} +
Template:Managed This is the Page metadata template. It should be called in the following format: {{Page metadata }} +
Template:Managed This is the Page sidebar template. It should be called in the following format: {{Page sidebar }} $base array is defined in MediaWiki:Ws-sub-header $page array is defined in MediaWiki:Ws-sub-header +
Template:Managed This is the Project sidebar template. It should be called in the following format: {{Project sidebar }} $base array is defined in MediaWiki:Ws-sub-header $page array is defined in MediaWiki:Ws-sub-header +
Template:Managed This is the Technologie sidebar template. It should be called in the following format: {{Technologie sidebar }} $base array is defined in MediaWiki:Ws-sub-header $page array is defined in MediaWiki:Ws-sub-header +
Termen & Concepten Een term is een … Termen & Concepten Een term is een relevant begrip of afkorting, een concept is een relevant idee, or verzameling ideeen die gerelateerd zijn: een plan, model of toestanden. Voorbeelden hiervan in VLOCA zijn zowel meer high level concepten als software architectuur, maar ook meer toegepaste als context broker. 3 3D referentie architectuur E-LSP A ANPR API API-first API-led Algemene Verordening Gegevensbescherming of AVG Apache Druid Applications Architectuur Authentieke gegevensbron B Backward compatibility Basisregister Beheerder Beleidsdomeinen Bouwlagen C CDS-M Citizen participation Classificatie Combimobiliteit Componenten Context Information Coock Open Stad/Building trust and value in data ecosystems Coock Open Stad/Connecting and storing sensor data Coock Open Stad/Connecting, storing and publishing sensor data Coock Open Stad/Healthy Indoor Quality of Living Coock Open Stad/IoT and Air Quality in Cities part 1 Coock Open Stad/IoT and Air Quality in Cities part 2 Coock Open Stad/Learnings from international and local smart city initiatives Coock Open Stad/Mobile environmental sensing Coock Open Stad/Open City and its Citizens Coock Open Stad/Publishing and using sensor data as linked open data Coock Open Stad/Smart Towards a high-quality living environment Cross-Domain Cross-cutting concerns D DATA-first Data Formaat Data Governance Data Lineage Data Ownership Data Portability Data Quality Data Scheme Data Spaces In Flanders Data Variety Data Velocity Data Veracity Data Volume Data attribuut Data cataloog Data enrichment Data fusion Data kwaliteit Data management Data protection Data security Data semantiek Data space Data-gedreven beslissingsondersteuningssysteem Data-soevereiniteit Database Database vs contextbroker Dataretentie Devices D meer Digital administration Digital twin E EIRA (European Interoperability Reference Architecture) Ecosysteem Edge Effectiviteitsprincipes English Speaking Europese Interoperabiliteitsarchitectuur (EIRA) F Fair data Five star open data Floating Car Data G GAIA-X technische architectuur Geaggregeerde data Geanonimiseerde data Governance Graph-database H HPAdmin HPBuurt HPGebruiksStats HPIdentificatie HPLayout HPLokaal HPRegionaal HPServices HPStatus HPType Hoe bijdragen Hoppin Punt informatie model Hoppin informatie architectuur Hoppin punten Hydrostatische meting I ICT ISA²: Interoperability solutions for public administrations, businesses and citizens Informatie-architectuur Infrastructure Interoperabiliteit IoT J JSON-LD K Knowledge graph L Legacy Linked open data LoRaWAN Luchtkwaliteitsmodellen M MaaS Operator Machine readable Metadata Mobility as a Service Monitoring N NB-IOT National Access Point Personenvervoer Network & connectivity No-sql O OASC MIMs OSLO - Fietsinfrastructuur OSLO Mobiliteit - Dienstregeling en Planning OSLO Openbaar Domein OSLO Standaarden OSWALD Object Type Library Ontologie Open DEI Principles Open Data Open Smart City Architectuur O meer Open Street Map Open slimme stad Open software service Open urban digital twins OpenDEI 6C P PostGIS Preventieve gezondheid Privacy by design Pub-sub Public infrastructures and urban equipment Q QUARK R REST-API Randvoorwaarden Referentie "start" blauwdruk Referentiearchitectuur beschrijving Relational-database S SOLID STOP-principe Security Semantic annotations Semantics Semantische Interoperabiliteit Semantische annotaties Sensordata Service Level Agreement (SLA) Sigfox Slimme Camera Slimme Verkeerslichten Slimme stad Smart City Domeinen Smart Economy Smart Environment Smart Government Smart Living Smart Mobility Smart People Sound Event Detection Standaarden Swagger Syntax Systeemeigenschappen T TOGAF Taxonomie Telecom Tellus TestGzG Traffic and transport U URI Urban Sound Tagging Urban environment V VLOCA Internationaal VLOCA Principes VLOCA traject VLOCA-OSLO proces voor CoT trajecten VLOCA projectwerking Vervoer Op Maat Vocabulary W Waste management Water vocabularium OSLO Watersensor WiFi scanningcabularium OSLO Watersensor WiFi scanning +
Test Niveau 2 Vereisten … Test Niveau 2 Vereisten Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) – Halle 2022 Versie: 0.2 VLOCA analyse - Vlaamse Open City Architectuur | vloca@vlaanderen.be Beschrijving en aanpak: https://vloca-kennishub.vlaanderen.be/Deliverable:_VLOCA-model Strategie van de open city uitdaging Status Toelichting Beschrijving Visie Voorstel Wat is de bestaansreden ? Corona heeft grote impact gehad op lokale handelszaken. Aanbod van lokale handelszaken is weinig bekend bij inwoners en nog minder bij bezoekers. Digitale Infoschermen in het straatbeeld zouden een oplossing kunnen zijn, maar tonen vooral advertenties voor multinationals en webshops, en de lokale besturen beperken zich vaak tot aankondiging voor evenementen. Missie Voorstel Wat willen we bereiken ? Mensen (shoppers) via digitale schermen aanzetten tot het lokaal kopen. Doel Voorstel Wat is het doel van dit project ? 1.Laagdrempelig gebruiksvriendelijke app voor de handelaars om hun advertentie te kunnen posten, 2. Performance platform voor centrum manager (data verzamelen, data analyseren, campaign performance analysis, tips and tricks,...) 3. Advertenties op slimme infoborden (interactief, inlog mogelijkheden, met QR code, ...) => nudging van markt naar binnenstad en vice versa. Succesfactor Voorstel Hoe meten we succes ? (SMART) indien de lokale adverteerders 'meer' verkopen nadat ze hun advertentie hebben kunnen plaatsen. Use cases ID Status Samenvatting Beschrijving UC1 Voorstel UC1: Digitale Scherm Digitale Scherm die al dan niet 'interactief' een advertentie van de lokale winkels laat zien UC2 Voorstel UC2: Media Centrale Een pseudo media centrale die de advertenties controleert, toekent en 'factureert' ifv regels en GRP (Reach, frequentie, enz.) UC3 Voorstel UC3: App Een app die gemakkelijk door de lokale adverteerder toelaat om zijn eigen advertentie te kunnen inplannen en projecteren. UC4 Voorstel UC4: Inzichten Rapportage van performantie van campagnes met inzichten van wat heeft gewerkt en wat niet (Tips en Tricks), incl beleidsrapportering. UC5 Voorstel UC5: Schaalbaarheid Oplossing is uitbreidbaar (en interoperabel) naar andere steden en gemeenten zonder veel aanpassingen Metadata Metaveld Beschrijving Meta1 Beschrijving meta 1 Meta2 Beschrijving meta 2 Business capabilities, data vereisten, functionaliteiten en techniciteiten volgens use cases ID Type Samenvatting Beschrijving UC1 Use case UC1: Digitale Scherm Digitale Scherm die al dan niet 'interactief' een advertentie van de lokale winkels laat zien BC1.1 Business capability Samenvatting Roterende visualisering van advertenties DV1.1.1 Data vereiste advertentie id, locatie, type van advertentie, adverteerder, pricing, datum, tijd (verleden, heden en toekomst) FC1.1.1 Functionaliteit rotationele planning BC1.2 Business capability Samenvatting interactieve opzoek mogelijkheden (via touchscreen of via handgebaren...) DV1.2.1 Data vereiste search data historiek, tijd, locatie,... FC1.2.1 Functionaliteit Search capability BC1.3 Business capability Samenvatting snelle begeleiding of kortingen bvb via QR codes ID Type Samenvatting Beschrijving UC2 Use case UC2: Media Centrale Een pseudo media centrale die de advertenties controleert, toekent en 'factureert' ifv regels en GRP (Reach, frequentie, enz.) BC2.1 Business capability Samenvatting Bepalen van de advertentieregels (bvb maar 7% van schermtijd voor de corporates/niet lokale handelaars) DV2.1.1 Data vereiste rules databank (type adverteerder, tijd, prioriteit, economische omzet, enz.) FC2.1.1 Functionaliteit rule based decisioning BC2.2 Business capability Samenvatting Roterings Planning opmaken DV2.2.1 Data vereiste rules databank (type adverteerder, tijd, prioriteit, economische omzet, enz.) DV2.2.2 Data vereiste aangevraagde tijd door adverteerders DV2.2.3 Data vereiste advertentie id, locatie, type van advertentie, adverteerder, pricing, datum, tijd (verleden, heden en toekomst) FC2.2 Functionaliteit Planning TV2.2 Techniciteit Planningstool (ERP) BC2.3 Business capability Samenvatting facturatie van de adverteerders DV2.3.1 Data vereiste Advertentie id, GRP, pricing afspraken, bedrag te betalen, kortingen DV2.3.2 Data vereiste Heeft betaald of niet per factuur FC2.3.1 Functionaliteit facturatie TV2.3.1 Techniciteit ERP BC2.4 Business capability Samenvatting Aanbieden van een advertentie templates met tips en tricks DV2.4.1 Data vereiste Templates per 'onderwerp' DV2.4.2 Data vereiste Feitelijk gebruik van de templates in de advertentie databank DV2.4.3 Data vereiste Voorstel van ideale momenten en locatie ifv het gevraagde advertentie type FC2.4.1 Functionaliteit Optimalisatie van inhoud, locatie en planning FC2.4.2 Functionaliteit Drag & Drop functionaliteiten BC2.5 Business capability Samenvatting Controle op de te vertonen advertentie (ethische richtlijnen moeten gevolgd worden, enz.) DV2.3.1 Data vereiste rules databank van ethische regels DV2.3.2 Data vereiste afbeeldingen en teksten van de geplande advertentie FC2.3.1 Functionaliteit Via Artificiele Intelligence ontdekken van bvb 'niet wenselijke afbeeldingen of misleidende teksten' ID Type Samenvatting Beschrijving UC3 Use case UC3: App Een app die gemakkelijk door de lokale adverteerder toelaat om zijn eigen advertentie te kunnen inplannen en projecteren. BC3.1 Business capability Samenvatting Keuze uit templates met drag en drop van foto materiaal en logo met bijhorende tekst BC3.2 Business capability Samenvatting Ontwikkelen van een prijs settings mechanisme die pragmatisch last minute advertenties toelaat BC3.3 Business capability Samenvatting Registratie met validatie van een nieuwe adverteerder DV3.2.1 Data vereiste Databank van de lokale ondernemers (via bvb KBO) DV3.2.2 Data vereiste Adverteerders id voor toegekende registratie FC3.2.1 Functionaliteit Authenticatie FC.3.2.2 Functionaliteit Validatie ID Type Samenvatting Beschrijving UC4 Use case UC4: Inzichten Rapportage van performantie van campagnes met inzichten van wat heeft gewerkt en wat niet (Tips en Tricks), incl beleidsrapportering. BC4.1 Business capability Samenvatting Het meten van passanten DV4.1.1 Data vereiste Passanten DV4.1.2 Data vereiste Profielen/Segmenten van de passanten FC4.1.1 Functionaliteit Meten van 'passage' BC4.2 Business capability Samenvatting Het meten van 'viewers' DV4.1.1 Data vereiste Viewers (ook in seconden) DV4.1.2 Data vereiste Profielen/Segmenten van de viewers FC4.1.1 Functionaliteit Capteren van de 'ogen' van passanten FC4.1.2 Functionaliteit AI om viewers te identificeren BC4.3 Business capability Samenvatting Het meten van gezichtsuitdrukkingen van de 'viewers' DV4.1.1 Data vereiste Viewers DV4.1.2 Data vereiste Gezichtsuitdrukkingen FC4.1.1 Functionaliteit Capteren van de gezichtsuitdrukkingen FC4.1.2 Functionaliteit AI om de 'mood' van de viewer te meten BC4.4 Business capability Samenvatting Het bepalen van de ROI van een campagne door de binnenstappers en besteders te bepalen van de 'viewers' DV4.4.1 Data vereiste link viewers en binnenstappers DV4.4.2 Data vereiste controle groepen of controle momenten DV4.4.3 Data vereiste Verkoopscijfers van de adverteerder en algemeen in de straat of omgeving BC4.5 Business capability Samenvatting Mogelijkheid om (experimentele) AB testen te doen (vergelijken van verschillende advertenties op de commerciele resultaten van de adverteerder) DV4.1.1 Data vereiste Advertentie id met type van advertentie en kost DV4.1.2 Data vereiste Omzet of Binnenstappers van de 'viewers' ID Type Samenvatting Beschrijving UC5 Use case UC5: Schaalbaarheid Oplossing is uitbreidbaar (en interoperabel) naar andere steden en gemeenten zonder veel aanpassingen BC5.1 Business capability Samenvatting Bepalen van de OSLO standaarden voor de app en media centrale DV5.1.1 Data vereiste datamodel BC5.2 Business capability Samenvatting uitbreidbaarheid van de media centrale en de app voor andere steden mits afspraken op delen van budgetten/kosten DV5.2.1 Data vereiste Welke steden gebruiken en hoeveel volume gegenereerdveel volume gegenereerd +
Text Note: this property page is intentionally of type Text and not Number, to allow for version numbers such as 6.2.7 that are not valid values for property type Number. +
Text/string property generated wordcloud {{#ask: [[TermenConcepten::+]] |?TermenConcepten |format=tagcloud |limit=250 |link=all |headers=show |tagorder=alphabetical |increase=log |widget=wordcloud ... +
The aim of this workshop is to unite knowl … The aim of this workshop is to unite knowledge institutions, policy makers, andcompanies in order to make Flanders an exemplary region in the field of smartmonitoring and management of the living environment. A good livingenvironment is experienced as pleasant, invites healthy behavior and causes thelowest possible pressure on health. Within the Coock project the emphasis ison noise, air, and electromagnetic radiation. In addition to monitoring thesituation and the impact on residents and users, a smart policy also requires alink to the pressure that activities exert on this living environment. Traffic andtransport are important, but certainly not the only driving forces. Date: Tuesday January 12 th 2021, 13:00 Registration: https://share.hsforms.com/1cgEjeBmvQk-PC-AcpUQQcw42q9f Registered participants will receive the zoom-link a few days before themeeting. Topics From data to knowledge and prediction; trend analysis; interpolation between measurements; ... Living environment quality data: how to deal with a diversity of data; exchange of data between initiatives; ... New sensors in a smart city context and their integration; personal exposure monitoring; ... Agenda (4h online event) Ongoing policy initiatives (introduced by government institutions) Introduction of topics Noise, Electromagnetic, Air quality – followed by workshop with stakeholders Introduction data collection, modelling, knowledge extraction – followed by workshop with stakeholders Contributions from: Van Campenhout Karen / Hans Reynders (Departement Omgeving), Christophe Stroobants ( VMM ) Dick Botteldooren / Luc Dekoninck (UGent), Wout Joseph / David Plets ( IMEC ) Martine Van Poppel ( VITO ) Valerio Panzica La Manna ( IMEC ) PresentationsManna ( IMEC ) Presentations +
Thematische werkgroep 1: Mobiliteitsbudget … Thematische werkgroep 1: Mobiliteitsbudget voor burgers - doelgroep: lokale besturen Context Initiatief Om een omslag te maken naar duurzame personenmobiliteit in Vlaanderen moeten de duurzame mobiliteitsvormen worden gestimuleerd en drempels worden weggenomen. De alternatieven voor een traditionele diesel- of benzinewagen die geparkeerd staat in je straat voor de deur zijn zeer divers: trein, bus, deelfiets en step, deelwagen, parkeergarages en het publiek kunnen laden van een elektrische wagen zijn in onze steden steeds meer beschikbaar. Met de uitrol van mobipunten versterkt ook de Vlaamse Overheid dit aanbod. Als je volwaardig van de veelheid aan mobiliteit in je stad of gemeente wil kunnen genieten dan zou je al die diensten makkelijk en flexibel moeten kunnen consumeren. Elk van die mobiliteitsaanbieders heeft nu een eigen app met telkens een aparte account en daaraan verbonden ‘rekening’, waarborgen en gebruiksvoorwaarden, en dat is niet handig. In een B2B setting werd er de afgelopen jaren werk gemaakt van de opzet van MaaS of MoDi: Mobiliteit als een Dienst. Eén app of kaart met soms een abonnementsformule waarmee je alle mobiliteitsdiensten kan consumeren waar en wanneer het je past. Ook zijn er enkele grootbanken die een dergelijk aanbod hebben opgenomen in hun app. Met het Mobiliteitskrediet voor burgers willen we hen via een MaaS aanbod toegang geven tot een mobiliteitsbudget. We organiseren het mobiliteitsbudget zo dat elke stad of gemeente haar beleid gericht kan vertalen in voordelen voor specifieke modi op specifieke locaties. Burgers die in het centrum wonen kunnen daarbij andere voordelen genieten dan deze die buiten het centrum wonen omdat hun noden anders zijn en het beleid in het centrum (bv. voor parkeren) anders is. Met extra ‘nudging’ technologie geven we zo op een zeer efficiënte manier een push aan de alternatieven. Door slim gebruik te maken van de gebruiksdata kunnen we de publieke middelen inzetten waar ze het meest renderen. Bovendien waken we als stad erover dat iedereen mee is: inclusie is een essentieel element van het Mobiliteitskrediet van de burger, ook als die geen smartphone heeft of om welke reden dan ook kwetsbaar is in het dagelijkse leven. Economie is mobiliteit. Zonder dat wij ons als persoon kunnen verplaatsen kan een gezonde economie niet draaien. Burgers verplaatsen zich om te gaan werken, winkelen ontspannen en om elkaar op te zoeken. Met het mobiliteitsbudget voor de burger geven we dan ook iederéén de kans om zijn of haar verplaatsingen naar werk, school, winkel of voor vrije tijd duurzaam te maken. Minder wagens op de weg betekent ook minder congestie, en dat is op zijn beurt rechtsreeks een economische winst voor wie noodzakelijk wél met de wagen, bestelwagen of vrachtwagen de weg op moet. De scope van het project is het inhoudelijk testen van een mobiliteitsbudget voor burgers. Het mobiliteitsbudget is een budget dat door de lokale overheid aangeboden wordt aan burgers ter besteding aan mobiliteit in de brede zin van het woord. Cfr. federaal mobiliteitsbudget. Waarom? Alternatieven bieden voor straatparkeren Het sturen van mobiliteitsgedrag van burgers Het verder verduurzamen van personenmobiliteit Bijdragen tot leefbare stad Bruikbare data die inzichten verwerft en ondersteuning geeft aan beleidsbeslissingen Bestuursakkoord Stad Hasselt Hoe? Via een bestaand geoptimaliseerd (MaaS) platform Testen gedurende 6 maanden Min. 100 testpersonen per stad Implementatie Maasplatform: Het project maakt gebruik van het bestaande mobiliteitsplatform Olympus Mobility om kosten en tijd te besparen. Testperiode: Gedurende zes maanden wordt het mobiliteitsbudget getest onder burgers in Hasselt en Leuven. De testperiode loopt tot 1 december 2024. Bevindingen tot nu toe Gebruik van Budget: Het budget wordt voornamelijk besteed aan treindiensten (NMBS), busdiensten (De Lijn), en deels aan deelwagens. Gebruikers: Testers omvatten een diverse groep van bewoners, inclusief studenten en mensen met lagere inkomens, om de impact op verschillende demografische groepen te evalueren. Budgettoewijzing: Er zijn verschillende budgetgroepen die een maandelijks budget ontvangen, variërend van niet-overdraagbaar tot spaarsystemen. Het gemiddelde budget per persoon bedraagt ongeveer 200 euro over de testperiode. Toekomstplannen Analyse en Rapportage: Resultaten en data zullen in de zomer worden geanalyseerd om een business case te ontwikkelen. Uitbreiding en Finetuning: Evaluatie van het potentieel om dit mobiliteitsbudget breder uit te rollen en eventueel te combineren met andere budgetten of incentiveringsacties van handelaren. Financiële Aspecten Kosten vs. Baten: Het project moet aantonen dat de voordelen voor de stad of gemeente de kosten rechtvaardigen. Er wordt gekeken naar een combinatie van lokale en federale budgetten en mogelijke bijdragen van externe partijen. VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. VLOCA model ID Beschrijving UC1 Overkoepelende platform die toegang heeft aan alle participerende mobiliteitsaanbieders, opdat een intermodaal transport traject mogelijk maakt UC2 Een budget beheer platform die alle 'transacties' bijhoudt en toelaat UC3 Een owner platform die de 'eigenaars' van dit overkoepelende platform alle rechten en plichten beheert UC4 Een donor platform die de 'donors' toelaat om budget te geven, storten en evt recupereren UC5 Een gebruikers platform die de 'gebruikers' toelaat om tickets te bestellen, betalen en beheren UC6 Een platform die de overheid een overzicht geeft van alle transacties in dit ecosysteem UC7 Participerende spelers 'transport' : Alle 'variabele' transport leveranciers die hun aanbod op het platform willen aanbieden UC8 Participerende spelers 'mobiliteit' : Alle andere mobiliteits leveranciers (bvb fietsenwinkels, ed) die hun aanbod op het platform willen aanbieden UC9 Variabele subsidies naar openbaar vervoer ipv 'vaste' bedragen UC10 Incentiveringsplatform waarbij goed gedrag gecapteerd en beloond wordt door een 'donor' op de 'mobiliteitsbudget' Focus vandaag: UC 4, 6 en 9. Het project begint met een duidelijke visie en missie, die ambitieuze doelen stellen voor wat we willen bereiken. Om deze doelen te realiseren, hebben we het project opgedeeld in behapbare onderdelen volgens het Vloka-model. Deze aanpak zorgt ervoor dat elk onderdeel essentieel bijdraagt aan het succes van het project. Centraal in het project staat het overkoepelende platform dat alle stakeholders, zoals donoren en lokale besturen, met elkaar verbindt. Dit platform biedt een interface voor lokale overheden en hoopt ook bedrijven aan te trekken die bepaald gedrag willen belonen en stimuleren. Daarnaast is er een gebruikersinterface ontwikkeld, die momenteel wordt getest. Deze testfase geeft waardevolle informatie over hoe gebruikers de interface ervaren, hun behoeften en eventuele obstakels waar ze tegenaan lopen. Een ander cruciaal onderdeel is de transportaanbodinterface. Deze interface zorgt voor de koppeling tussen transportbedrijven en het platform, zodat gebruikers weten welke diensten beschikbaar zijn voor hun trajecten. Hiermee wordt informatie correct uitgewisseld en kunnen bedrijven hun aanbod gemakkelijk plaatsen. Het transactieplatform is ook van groot belang. Hier wordt het mobiliteitsbudget beheerd en worden transacties bijgehouden na elk gebruik. Dit platform zorgt ervoor dat de financiële afwikkeling soepel verloopt, of het nu gaat om donortransfers of gebruikstransfers. Voor de overheid is er een Business Intelligence (BI) component geïmplementeerd. Dit biedt rapportages en inzichten die de overheid helpen het project te evalueren en bij te sturen. Het doel is om te zien of het project goed werkt en het gewenste gedrag stimuleert, en om alle benodigde gegevens op een gestructureerde manier aan de lokale besturen te leveren. Tot slot is er ook een incentiveringsplatform, vergelijkbaar met een project in Geel. Dit platform beloont goed gedrag van burgers met een budget dat zij kunnen besteden. We moeten nadenken over hoe we dit platform goed kunnen integreren met het bestaande systeem. Met deze opzet hoopt het project duurzame mobiliteit te stimuleren en waardevolle data te verzamelen om toekomstige beleidsbeslissingen te ondersteunen. Brainstormsessie Doel Het doel van de brainstormsessie is het volgende: Identificatie van de meerwaardecreatie Inzicht in wat je nodig hebt om de meerwaardecreaties te realiseren Platform vereisten lokale besturen Opsommen van valkuilen en potentiële principes waaraan de oplossing moet voldoen Verduurzamen van de oplossing Oefening 1+2 Bij deze oefeningen stonden we stil bij de volgende vragen: 1) Wat is de meerwaarde van een mobiliteitsbudget voor een lokaal bestuur? Hoe draagt deze oplossing bij tot het behalen van de beleidsdoelstellingen? Welke zijn dit? Voorbeeld: -Minder verkeersdrukte maakt een stad aantrekkelijker 2) Wat heb je nodig om de geïdentificeerde meerwaardecreaties uit oefening 1 te realiseren? Lijst de acties op Voorbeeld: -Door alternatieve mobiliteit te gaan sponsoren, gaan er minder auto’s zijn in de binnenstad. Dit maakt een stad aangenamer/aantrekkelijker. Overzicht Identificatie meerwaardecreatie Beleidsdoelstellingen Acties Meer veiligheid in het stadsverkeer Het gebruik van de auto verminderen Koppeling met Hoppin App Een platform voor zowel deelfiets, openbaar vervoer als- deelauto aanpak vervoersarmoede gebruik van de bestaande deelsystemen stimuleren Aanpak van vervoersarmoede Mindermobielenbeleid integreren in verkeersstromen gebruiker meer vrijheid geven (subsidies door de gebruiker zelf te laten beslissen hoe dat hij het gaat gebruiken) deelmobiliteit stimuleren = minder autobezit en minder parkeerdruk Parkeerplaatsen kosten geld, zowel naar aanleg of onderhoud toe. Dit geld kan als mobiliteitsbudget worden ingezet. verkeersveiligheid en mobiliteit voor iedereen --> verkeersarmoede beperken Klimaatdoelstellingen naar infiltratie (water door ontharden) toe Ontharden van parkeerplaatsen Parkeerdruk verlagen in de centra door mobiliteitsbudget tegenover autobezit te plaatsen Verbetering van de luchtkwaliteit Bestaande budgetten/subsidie systemen gerichter en efficienter besteden Verduurzaming van mobiliteit: Vermindering van CO2-uitstoot Vermindering van verkeersopstoppingen en een vlottere doorstroming van het verkeer en dus ook OV. Financiering vervoer op maat voor specifieke doelgroepen transparantere subsidiestromen Aantal geparkeerde auto's verminderen en zo leefbaarheid verbeteren Economische voordelen: Lagere infrastructuurkosten: Minder auto's op de weg betekent minder slijtage aan wegen en dus lagere onderhoudskosten. Minder investering in parkeerplaatsen. Drempels voor gebruik deelwagens verlagen door toekennen (eenmalig) budget Gezondheidsvoordelen: Stimuleren van lichaamsbeweging: Door fietsen en wandelen te promoten. Verminderen van geluidsoverlast Sturen van gedrag ifv verplaatsingen Aanbod deelauto's en deelfietsen uitbreiden Perceptie belonen tov bestraffen ter verbetering van het citizen wellbeing duurzamere mobiliteit, verlaging CO2 uitstoot verkeersdrukte en parkeerdrukte verminderen Sociale inclusie: Toegankelijkheid van mobiliteit voor iedereen: Een mobiliteitsbudget kan ervoor zorgen dat mensen met een lager inkomen ook toegang hebben tot verschillende vormen van vervoer, wat bijdraagt aan sociale gelijkheid. openbaar domein kan anders ingericht worden bv ontharding (groen = gras & parken-blauw = water) => ipv de vrijgekomen parkeerplaatsen De wagen zal een onmisbare modus blijven in het mobiliteitslandschap. Omarm de autogebruiker door kwalitatieve alternatieven aan te bieden in de vorm van OV en deelsystemen. Maar ook door in te zetten op het vergroenen van een deel van de wagenverplaatsing. M.a.w. kwalitatieve P&R op mobiliteitshubs waar er makkelijk overgestapt kan worden op OV of deelsysteem en vervolgens de belangrijkste plaatsen in de stad worden bereikt vergroening van het patrimonium parkeerplaatsen reduceren in functie van toenemend percentage deelmobiliteit Leefbaarheid verbeteren CO2 reductie Dit is voor OV en deelsystemen, dus gaan we de modal split bevorderen, mensen aanmoedigen om OV en deelsystemen te gebruiken gebruik OV en deelsystemen bevorderen app bekendmaken (vooral ook bij doelpublieken zoals jongeren, kansarmen, ouderen,… beter klimaat app ontwikkelen & incentives bedenken en toekennen in de app minder uitstoot van fossiele brandstoffen gemeente voorziet budget reduceren cost of ownership eigen wagen : alternatief tonen om te vermijden bvb om een tweede wagen te verschaffen Modal split verwezenlijken door gebruik duurzame vervoersmiddelen te promoten, mensen sturen naar openbaar vervoer en deelwagens Bezoekers sturen naar de gewenste parking en deze belonen (aan de rand van de stad bvb P&R belonen) ESG beleid corporates (maatschappelijk ondernemersschap 2025 => certificatie) => donors = marketing = win win win Betere toegang tot mobiliteit kan kansen creeren voor specifieke doelgroepen budget voor de juiste doelgroep ipv huidig derdebetalersysteem van de lijn (puur leeftijdscategorie, minder op inkomens, alleenstaanden bvb is daar geen onderscheid in) Inclusief - budget doneren aan anderen mogelijks vervaldatum ipv niet gebruikt = niet gekregen Transparantie : communicatie naar de burger wat er met de budgetten gebeurd is (naar goede doelen bvb) bewonersparkeren digitaliseren (bvb bezoekers tickets) en maatschappelijk laten impacteren Meer openbare ruimte beschikbaar Minder verplaatsingen verhoogt de verkeersveiligheid en -leefbaarheid personen in vervoersarmoede beter begeleiden Discussie Veiligheid en Stadsverkeer: Discussie over de vermindering van auto's in stadscentra. Argumenten voor en tegen het verhogen van het gebruik van alternatieve vervoersmiddelen zoals fietsen en openbaar vervoer. De invloed van verkeersveiligheid op de algemene veiligheid in de stad. Alternatieve Vervoersmiddelen: Integratie van deelfietsen, openbaar vervoer en deelauto’s op een enkel platform. De haalbaarheid en effectiviteit van een geïntegreerd platform. Voordelen en nadelen van het aanbieden van verschillende vervoersopties op één platform. Klimaat en Milieu: Discussie over de impact van verminderde autogebruik op het milieu. Argumenten over de effectiviteit van groene vervoersopties in het verminderen van CO2-uitstoot. Voorbeelden van steden die succesvol zijn in het verminderen van milieuvervuiling door autobeperkingen. Leefbaarheid van de Stad: Invloed van minder auto's op de leefbaarheid van stedelijke gebieden. De relatie tussen verminderde verkeersdrukte en verbeterde kwaliteit van leven voor stadsbewoners. Discussie over de voordelen van meer voetgangers- en fietsvriendelijke stadsinfrastructuur. Economische Impact: Discussie over de economische voordelen en nadelen van het verminderen van autoverkeer in stadscentra. Argumenten over hoe alternatieve vervoersmiddelen de lokale economie kunnen stimuleren of belemmeren. Voorbeelden van economische impact in steden die soortgelijke maatregelen hebben ingevoerd. Technologische Innovatie: De rol van technologie in het faciliteren van alternatieve vervoersoplossingen. Bespreking van innovaties zoals apps en digitale platforms die de mobiliteit verbeteren. Toekomstige ontwikkelingen en hun potentieel om het stadsverkeer te transformeren. Overheidsbeleid en Regelgeving: Discussie over bestaande en voorgestelde beleidsmaatregelen ter bevordering van duurzame mobiliteit. Voor- en nadelen van strengere regelgeving voor autoverkeer. Analyse van beleidssuccessen en mislukkingen in verschillende steden en landen. Oefening 3 Bij deze oefening stonden we stel bij de vraag hoe een platform voor het beheer van een mobiliteitsbudget eruit moet zien voor een lokaal bestuur? Wat wil je ermee kunnen doen? Wat heb je hiervoor nodig? Zijn er bepaalde linken die je wenst te hebben? Hoe komt je mobiliteitsbudget terecht bij de juiste person? Voorbeeld: -Als stad of gemeente wens ik controle te hebben over de regels en voorwaarden rond het gebruik van een mobiliteitsbudget -Geld transfereren Overzicht Platform vereisten Toelichting eenvoudig in gebruik doelgroepeen bepalen en daar budgetten aan koppelen - ook de modaliteiten en vervaldatum intuïtief data verzameling/analyse per gemeente gebruik/saldos per doelgroep? Bijsturen ifv gebruiksdata op betrekking van modaliteiten bvb meerdere gebruikers mogelijk per gemeente mobiliteit, financiën, sociale dienst, ... Intuïtief, duidelijke landingspagina data kunnen exporteren / importeren (toevoeging lijsten ipv handmatig & documenten centraliseren zoals sharepoint, ...) vlot en gemakkelijk in te loggen Inzicht hoe het budget gebruikt wordt rapporten trekken uit het systeem per vervoersmiddel of per gebruiker eenvoudig gebruik wat met digibeten? (=burgers) foolproof (=burgers) gebruik monitoren als gemeente zelf voorwaarden bepalen koppeling met boekhouding? (Bestelnummer met factuur) Financieel beheer ifv diensten intern & donoren ambtenaar moet zich kunnen inloggen in naam van burger E-inclusie - Andere Tools dan een app? (=burgers) Feedback/ terugkoppeling van de burgers Compatibel met reeds bestaande software (vb boekhoudprogramma stad), om dubbel werk te vermijden regio-overschrijdend (staan we dat toe ? hoe gaan we daarmee om ?) analyse gebruik ifv bv campagnes sturen van gedrag nr bv bepaalde parkings opzetten van tijdelijke campagnes één systeem voor alle vervoersmodi. geen App voor dit dan een app voor dat etc. integrale koppeling van de verschillende systemen (=Burgers) Vlotte uitbetaling van de partners rollenbeheer (wie mag wat doen op het platform) opvolgen hoeveel van het totaalbudget er al gebruikt is redelijke kostprijs, ook voor kleinere gemeente 1 app voor alle OV en deelsystemen, dus medewerking van aanbieders dit systeem combineren met platform ihkv basisbereikbaarheid => er zou een platform in ontwikkeling zijn vanuit Vlaanderen om één ticket systeem => ook een lokale initiatief van bvb gratis bussen vanaf 22h je moet bv kunnen bepalen dat een rit met de nachtbus geregistreerd geraakt maar niet aan de gebruiker aangerekend wordt Discussie Toepassing en controle van budgetten Lokale besturen moeten kunnen bepalen waarvoor budgetten worden gebruikt, inclusief het vaststellen van modaliteiten. Gebruik en gebruiksduur van het platform Het is belangrijk om einddatums en modaliteiten vast te stellen. Flexibiliteit in termijnen kan de efficiëntie verbeteren. Het platform moet intuïtief zijn en dataverzameling per gemeente mogelijk maken. Rapportage en data-analyse Meerdere mensen per gemeente moeten toegang hebben tot het systeem voor rapportage. Een dashboard voor analytisch gebruik kan helpen bij het bijsturen van strategieën op basis van data. Importeren van gegevens Het is belangrijk om lijsten zoals gebruikersgegevens te kunnen importeren. Gemeenten moeten criteria kunnen hanteren voor het toekennen van budgetten. Gebruiksgemak en toegankelijkheid Het platform moet gebruiksvriendelijk en toekomstbestendig zijn. Inclusiviteit is cruciaal, zodat ook niet-digitale burgers bediend kunnen worden. Compatibiliteit en integratie Het platform moet compatibel zijn met bestaande boekhoudsoftware. Regioverschrijdend gebruik moet mogelijk zijn om optimaal gebruik te kunnen maken van middelen. Flexibiliteit en aanpasbaarheid Het moet mogelijk zijn om tijdelijke campagnes op te zetten en het systeem aan te passen aan specifieke situaties. Eén geïntegreerd systeem voor alle vervoersmodi is wenselijk om complexiteit te verminderen. Financieel beheer Een koppeling met boekhoudsystemen en een goed budgetbeheer zijn cruciaal voor de werking van het platform. Feedback en verbetering Feedback van burgers en lokale besturen is essentieel voor continue verbetering van het systeem. Samenwerking en coördinatie Lokale initiatieven zoals gratis nachtbussen moeten in het platform geïntegreerd kunnen worden. Het is belangrijk dat Vlaanderen gemeenten betrekt bij de ontwikkeling van nieuwe systemen. Oefening 4 Verder werden potentiële valkuilen geïdentificeerd en, op basis hiervan, formuleerden we principes waaraan de oplossing moet voldoen: 1) Welke zijn de valkuilen waar we volgens jou rekening mee moeten houden? 2) Formuleer enkele basisprincipes waaraan de oplossing moet voldoen Voorbeeld: •Afhankelijkheid van bepaalde leverancier platform •Interoperabiliteit van de oplossing •Betrouwbaarheid, en dus ‘vertrouwen’ in de applicatie •Digitale kloof Overzicht Valkuilen Principes gebrek aan personeel om het platform op te volgen Zoveelste platform voor mobiliteitsambtenaar? Huidige budgettaire beperkingen (als donor alsook personeel) bij lokale overheden lokaal bestuur bepaalt enkel budget en doelgroep. Burger beheert zelf zijn budget. Zo weinig mogelijk zorg /werk voor overheid. Privacy en GDPR Inclusiviteit privacy burgers, wie kan aan welke data? Zeker bij meerdere gebruikers per stad/gemeente bvb er zijn maar 2 deelauto's aanwezig => niet beschikbaar => slechte ervaring ! in geval van piek kort na uitrol: kan het aanbod de vraag invullen? gekoppeld aan een duidelijke doel waarde incentivering/budget ifv gebruik/gedragsverandering frequentie looptijd (=het wordt een gewoonte en de frequentie gaat dan dalen) => blijven stimuleren (cfr. RFM modellen in de marketing) GDPR voordelen voor iedereen of enkel doelgroepen? Wie? Schatten we dat juist in? - vooral in het begin Incentives - wat en hoe? kunnen we dat inschatten? bereiken we het gewenste resultaat? - 'misbruik' vermijden Cfr. Parkeerplatform in Antwerpen => dus een cambio krijgt maar een licentie in mijn regio indien ze meedoen met mobiliteitsbudget bvb Discussie Personeelsbezetting en opvolging van het platform: Er is bezorgdheid geuit over het gebrek aan personeel om het platform effectief te beheren en op te volgen na de lancering. Het is cruciaal om niet alleen toegang te hebben tot het platform, maar ook om voldoende personeel beschikbaar te hebben om het dagelijks te beheren. Interoperabiliteit en afhankelijkheid van leveranciers: Een belangrijke valkuil die werd genoemd, is de afhankelijkheid van specifieke leveranciers van het platform. Dit kan problemen veroorzaken met interoperabiliteit en belemmeren dat andere applicaties op hetzelfde platform kunnen opereren. Budgetbeperkingen bij lokale overheden: Het gebrek aan voldoende budgetten en middelen bij lokale overheden kan een hindernis vormen voor het succesvol implementeren en ondersteunen van het mobiliteitsplatform. Privacy en GDPR-compliance: Er is nadruk gelegd op het belang van privacybescherming en het voldoen aan de GDPR-richtlijnen, vooral gezien de gevoelige aard van de gegevens die op het platform worden verwerkt. Inclusiviteit en toegang voor alle gebruikers: Het platform moet inclusief zijn en toegankelijk voor alle gebruikers, ongeacht hun sociaaleconomische status. Het is van essentieel belang om ervoor te zorgen dat lagere inkomensgroepen ook profiteren en kunnen deelnemen. Incentives en gedragsverandering: Discussie was er over de effectiviteit van incentives om gedragsverandering te stimuleren, zoals het gebruik van deelmobiliteit. Het is belangrijk dat de incentives aantrekkelijk genoeg zijn om gebruikers te motiveren hun gedrag te veranderen. Registratie en betrokkenheid van doelgroepen: Er werd gesproken over hoe lokale overheden moeite kunnen hebben om de juiste doelgroepen te bereiken en te betrekken bij het platform, en hoe dit kan leiden tot minder registraties en participatie. Technische infrastructuur en capaciteit: Het belang van een robuuste technische infrastructuur en capaciteit om het platform te ondersteunen, vooral tijdens piekperiodes of onverwachte vraag, werd benadrukt om uitval en frustratie bij gebruikers te voorkomen. Samenwerking met mobiliteitsaanbieders: Het platform moet samenwerken met verschillende mobiliteitsaanbieders om een breed scala aan diensten aan te bieden, zoals deelauto's en fietsen, om zo de mobiliteitsbehoeften van de gemeenschap beter te kunnen bedienen. Uitdagingen bij uitrol en acceptatie: Ten slotte werden er uitdagingen besproken met betrekking tot de uitrol van het platform en hoe ervoor te zorgen dat het wordt geaccepteerd en gebruikt door de beoogde gebruikersgroepen. Oefening 5 Tot slot bekeken we hoe we de oplossing duurzaam kunnen implementeren: -Welke expertise (rollen/profielen) hebben we nodig? -Hoe kunnen we de kosten beperken? -Zijn er applicaties die noodzakelijk zijn om de oplossing draaiende te houden? -Wie kan, los van subsidies, mee financieren aan de oplossing? Overzicht Verduurzamen aanbod ondersteuning /vorming (=assistentie krijgen, trainingen van het platform) Aanbieders deelwagens/deelfietsen/deel-... kunnen mogelijks meefinancieren (in ruil voor zichtbaarheid?) Duurzame gebruikers ook belonen met punten die kunnen worden ingeruild bi voor duurzame mobiliteit bij bv. Decathlon aankoop fiets. Een bedrijf zoals Decathlon kan dan mee financieren. Samenwerking / integratie met bestaande ontwikkelingen (= bvb hoppin app) Rekeningrijden voor de wagen introduceren (=wagengebruik minderen). De opbrengsten hiervan gebruiken om te investeren in duurzame en sociale mobiliteit (=duurzame mobiliteit verhogen) hogere overheid moet zorgen voor platform/app - lokaal bestuur bepaalt welk budget ze voorzien naar burgers toe en waarvoor dat moet dienen OV (NMBS, De Lijn, etc) en aanbieders deelsystemen moeten meewerken <- essentieel voor gebruik Organisaties betrekken zoals '30 dagen minder wagen' of 'strapdag' voor scholen per x-aantal gereden, duuurzame km's plant het lokaal bestuur een boom samenwerking met bestaande platformen die reeds verschillende modaliteiten integreren Discussie Financiering en duurzaamheid van het platform Discussie over hoe het platform zelf de kosten kan dragen en waar de budgetten vandaan moeten komen. Mogelijkheden van financiering door de overheid of privésector, inclusief subsidies en Europese financiering. Eigenaarschap en betrokkenheid Hoe zorgen we ervoor dat het platform gedragen wordt door verschillende belanghebbenden? Rol van lokale overheden, private partners en gebruikers bij het ondersteunen en financieren van het platform op lange termijn. Integratie met bestaande systemen Belang van integratie met bestaande mobiliteitsdiensten zoals openbaar vervoer en de rol van deze aanbieders in het succes van het platform. Voorbeelden van samenwerkingen en financieringsmodellen die dit kunnen ondersteunen, zoals beloningen voor duurzaam gebruik. Operationele en technische aspecten Specifieke technische vereisten voor het platform, inclusief data-integratie, gebruikerservaring en operationele efficiëntie. Impact van platformgebruik op lokale gemeenschappen en hoe dit geoptimaliseerd kan worden. Toekomstige stappen en planning Bespreking van de volgende stappen na de thematische werkgroepen, inclusief het verwerken van input in het VLOCA-model en het delen van kennis via een kennishub. Planning van verdere sessies en strategieën voor de implementatie van mobiliteitsbudgetten op grote schaal. Opname en Miro bord Miro bord Het Miro bord kan je consulteren via deze link . Opname De opname van deze sessie is te bekijken via deze link . Volgende stappen Wat na deze werkgroep? Verwerking van de input van de brainstorm oefening. Verder onderzoek en voorbereiding van de volgende thematische werkgroep. Publicatie op de Kennishub Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Thematische werkgroep 1 Data en informatie werkgroep 2024-06-11 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-07-02 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-07-09 13u-16u Teams +
Thematische werkgroep 2 MLaaS: Wegen De t … Thematische werkgroep 2 MLaaS: Wegen De tweede thematische werkgroep rond MLaaS 'Wegen' vond plaats op 16 april 2024. Context Initiatief De stad Roeselare beschikt reeds over verschillende machine learning algoritmes die data genereren op basis van fotomateriaal en is hiervoor in contact met verschillende partijen. Deze data wordt gebruikt in zowel operationele processen als bij het nemen van beleidsbeslissingen. Naast het voeden van eerder traditionele databanken stellen ze die intern ook ter beschikking via GEO loketten, en dit op een automatische manier. Deze kennis en ervaring willen ze verder uitbouwen en de algoritmes en processen tegelijkertijd ter beschikking stellen voor ieder bestuur, gaande van het kleinste lokaal bestuur tot bovenlokale overheden als Vlaanderen. Het concept van “machine learning as a service” laat de gebruiker om gebruik te maken van de data en de algoritmes zonder kennis te moeten uitbouwen van de technische achtergrond. Het moet als het ware een “dummy proof” platform worden waarbij men op een éénvoudige manier kan kiezen uit een overzichtelijke catalogus en kunnen “inpluggen” voor de processen die men nuttig acht. Door deze ontzorging kunnen meer besturen stappen zetten richting een sterker data gestuurde beleidsvorming en –voering. Met het streven naar het opschalen van bestaande machine learning processen, het uitrollen van nieuwe mogelijkheden en deze via een platform als een service ter beschikking te stellen van alle overheden willen ze niet alleen zorgen voor meer data op Vlaams niveau maar ook voor “massa productie” aan een betaalbare prijs. Dit alles kadert een groter geheel rond het City dashboard dat Roeselare enkele jaren geleden opgestart is. Hierbij is men gestart met het verzamelen van mobiele beelden en luchtbeelden. Deze data heeft men verzameld en verwerkt in een City dashboard. Uit dit dasboard kan heel wat informatie uit gehaald worden, waaronder ook informatie rond wegen waarrond we vandaag zullen brainstormen. Wegen inventaris De focus van deze toepassing binnen het MLaaS-project is het volgende: monitoring kwaliteit wegmarkeringen monitoring kwaliteit wegdek Nazicht wegmarkeringen vs verkeersborden plannen & budgetteren herbelijning wegen plannen & budgetteren herstel/heraanleg wegen Het onderzoek richt zich momenteel op het gebruik van luchtbeelden voor het detecteren en analyseren van wegmarkeringen. In een volgende stap worden satellietbeelden gebruikt. Verder wordt machine learning wordt toegepast om beelden te analyseren en relevante informatie te extraheren. Uiteraard is de beeldkwaliteit van groot belang voor de resultaten van de algoritmes. Roeselare werkt samen met GIM die algoritmes ontwikkelen en deze ook testen op beelden van verschillende kwaliteit. Resultaten van tests met verschillende beeldmaterialen zijn veelbelovend met goede herkenning van standaardsymbolen en wegmarkeringen. Er is veel potentieel voor het gebruik van eenvoudige orthofoto's voor het detecteren en analyseren van wegmarkeringen. We onderzoeken momenteel de limieten van verschillende soorten beeldmateriaal, waaronder luchtfoto's en satellietbeelden, voor nauwkeurige detectie. Daarnaast richten we ons op het identificeren van extra types wegmarkeringen en symbolen, evenals het beoordelen van de kwaliteit van het wegdek volgens OCW-normen en andere criteria. Dit omvat ook het opzetten van monitoringssystemen om de kwaliteit van het wegdek te bewaken en analyses uit te voeren voor operationeel beheer. Roeselare is van plan om hun activiteiten uit te breiden naar andere gemeenten, waaronder Brugge, Knokke-Heist, enzovoort. Het ML as a Service platform (MLaaS) dat ze ontwikkelen zal verschillende functies omvatten: Het opladen of bestellen van beeldmateriaal, Het selecteren van het juiste machine learning proces, Het uitvoeren van het proces en het downloaden van de resulterende data. VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. VLOCA-model ID Samenvatting Beschrijving UC1 UC1: beleidsacties datagedreven wegen beleidsacties gebaseerd op inzichten UC2 UC2: Dashboard Performantie beleidsacties ifv beleidslijnen, meten is weten UC3 UC3: DWH Wegen Datawarehouse of Dataspace met alle historische en geprojecteerde data mbt wegen UC4 UC4: BI Rapportering, Analyse op trends en Data Science op de verrijkte data UC5 UC5: (manuele) Opmetingen Het opladen van reeds gemeten wegen attributen om zo het beeld in gans Vlaanderen te vervolledigen stap per stap UC6 UC6: AI ML automatische metingen Gebruik van AI Machine Learning om via bvb foto's de wegmarkeringen, haar kwaliteit alsook wegdek materiaal en kwaliteit te identificeren UC7 UC7: Helpdesk & Monitoring Contact info bij vragen, FAQ, feedback op het platform en zijn werking, inclusief het monitoren van het platform UC8 UC8: kwaliteit feedback Kwaliteit en andere attributen van zowel de opgeladen data als de modellen UC9 UC9: Onderhoudsplanning Het kunnen opstellen van proactieve en preventieve acties, lees onderhoud, om 'defecten' te vermijden UC10 UC10: Duurzaamheid Afhankelijkheid van technologie en leveranciers Brainstormsessie Doel Het doel van de brainstormsessie is het volgende: Identificatie van de meerwaardecreatie Inzicht in wat je nodig hebt om de meerwaardecreaties te realiseren Beschrijven van mogelijkheden om de oplossing te verduurzamen Opsommen van valkuilen en potentiële principes waaraan de oplossing moet voldoen Oefening 1+2 Bij deze oefeningen stonden we stil bij de volgende vragen: 1) Waarom is een ML voor wegen (wegmarkeringen en wegdek) belangrijk? Laat ons uitgaan van ‘the worst case’: we doen het niet.. Wat zijn de gevolgen? Voorbeeld: Slechte wegmarkeringen kunnen voor gevaar zorgen 2) Wat heb je nodig om de geïdentificeerde meerwaardecreaties uit oefening 1 te realiseren? Lijst de acties op Voorbeeld: -Adhv foto’s kan ik de staat van het wegdek/wegmarkeringen idenficeren en acties plannen om deze te repareren -Aan preventie doen dmv door AI gededecteerde defecten op de wegen Overzicht Identificatie meerwaardecreatie Acties Beter inschatting van de onderhoudskosten (vb. hoeveel liter verf) Inventarisatie van de oppervlakte wegmarkeringen Bepalen hoeveel liter verf nodig beter/pro-actief plannen van onderhoudswerken (kosten reduceren door efficient plannen) = hoe vroeger hoe goedkoper (damage is groter bij langer wachten) Tijdsreeks analyse van de wegen inventarisatie m.b.t. staat van het wegdek/wegmarkering (extra type ML om predictief de defecten te identificeren) Regelmatig onderhoud is kosten efficiënter dan te laat onderhouden wegen risico op schadeclaims o.w.v. slechte wegkwaliteit (defecten aan wagens) => stad kan aangeklaagd worden en zijn zijn ervoor verzekerd. (historische) inventaris met beeldmateriaal als staving van de aan/afwezigheid van wegmarkering risico op betwistingen bij ongevallen t.g.v. onduidelijke wegmarkeringen controle wegmarkering vs verkeersbord vs reglementen mobiliteit Pothole monitoring (preventief, mitigatie) in winter maanden Foto's in de wintermaanden via sat beelden Bulten Detectie tijdens zomer maanden (preventief & mitigatie) Omleiding veilige route voor speciaal transport (bvb glastransport) ook bij burgerverkeer afhankelijk van de ernst van het probleem Juiste markering op de juiste plaats m.b.t. verkeershandhaving (verkeersbord <> wegmarkeringen, of <> 'reglementen' databank van de lokaal bestuur, of dat de markering nog niet overeenkomt met de reglementering die gewenst is) Analyse relatie tussen wegen en markeringen (met datum) controle facturatie onderhoud markeringen (hoeveel vierkante meters, aantal stuk = prijs per stuk of per vierkante meter of lopende meter alsook per kleur) inschatting van kwaliteit verf, leverancier, machine Na combineren met verkeerstellingen (bvb telramen, camera's,...) (en weer, type wegdek/ondergrond) en vergelijken met andere wegen (benchmarking) Predictief onderhoud Monitoring overeenkomst verschillende wegelementen (vb verkeersbord en wegmarkering, wegdek in slechte staat en waarschuwingsverkeersbord...) ifv opbouwen van verschillende weggerelateerde basisinventarissen op juiste locaties Aan de hand van de inventarisatie kwaliteit wegdek kan er een prioriteitenprogramma opgesteld worden ikv onderhoud wegen Optimalisatie/prioritisatie planning van het onderhoud Zoektocht naar aanwezige putdeksels / aansluitputten (voor waterleiding, gas, glasvezel,enz.) / rioolputjes (ronde of rechthoekige) ook voor de brandweer, bij infrastructuurwerken of onderhoud Slechte' belijning zorgt er voor dat weggebruikers verkeerd rijden => kan een tool zijn in mobiliteitsplan bijv? Evolutie verkeersveiligheid en/of -drukte in de stad nav reële (tijdsreeksen) of conceptuele (Digital Twin) aanpassingen = 'mobiliteit' Volledige up-to-date basisinventaris van wegelementen en verkeerstellingen (via Camera's en Telramen) andere toepassing: tellen van geparkeerde wagens/ vrachtwagens => ruimtelijke planning/'overlast' Verkeersmodellen die rekening houden met extra parameters zoals wegmarkeringen, staat van het wegdek, verkeersborden… percentage bezetting openbare parkeerplaatsen (via markeringen geteld) en afleiden (via communicatie) bij hoge bezetting naar verder gelegen parkeergebieden Discussie Belang van tijdig onderhoud: Er werd besproken dat het wachten met het uitvoeren van onderhoud aan wegen kan leiden tot grotere schade, wat uiteindelijk meer kosten met zich meebrengt. Kostenbesparing door regelmatig onderhoud: Regelmatig onderhoud werd als kostenefficiënter beschouwd dan het laten verwaarlozen van wegen. Voorspellend onderhoud: Er werd gesproken over het gebruik van tijdreeksanalyse en machine learning om voorspellingen te doen over de staat van wegen en wegmarkeringen, waardoor onderhoud proactief kan worden uitgevoerd. Risico's op schadeclaims: Er werd gewezen op het risico van schadeclaims als gevolg van slechte werkkwaliteit en wie hiervoor verantwoordelijk is. Monitoring van wegmarkeringen: Discussie over het gebruik van monitoring, zoals het nemen van foto's in de wintermaanden, om de kwaliteit van wegmarkeringen te controleren en schade te voorkomen. Identificatie van weggerelateerde elementen: Er werd gesproken over het identificeren en inventariseren van verschillende elementen in het wegdek, zoals putdeksels en aansluitputten. Gebruik van data voor mobiliteitsplanning: Het idee om data over wegmarkeringen, verkeersveiligheid en verkeersdrukte te gebruiken bij het opstellen van mobiliteitsplannen en het beheren van verkeer. Technologieën zoals AI en computer vision: Het gebruik van kunstmatige intelligentie en computervisie om wegmarkeringen en wegmaterialen te analyseren, onregelmatigheden te detecteren en prioriteiten te stellen voor onderhoud. Oefening 3 Bij deze oefening keken we naar manieren om de voorgestelde oplossing duurzaam te implementeren: Hoe kunnen we ML voor wegen (wegmarkeringen en wegdek) duurzaam implementeren? -Welke frequentie en accuraatheid zijn hiervoor nodig? -Hoe kunnen AI en ML bijdragen tot het verduurzamen van de oplossing? -Welke expertise hebben we nodig? -Hoe kunnen we andere organisaties laten participeren in de kosten? -Zijn er applicaties die noodzakelijk zijn om de oplossing draaiende te houden? Overzicht Verduurzamen oplossing Toelichting aanleveren ML-output (=verwerkte data obv foto's), zodat dit geïntegreerd kan worden op een eigen BI/GIS-analytics platform en gecombineerd kan worden met andere beschikbare data binnen de organisatie stabiel bronmateriaal m.b.v. exacte spec's (beelden en ML-algoritmes) AI & aardobservatie expertise binnen de lokale overheden/intercommunales Beeld materiaal geschikt voor de verschillende use cases Raamovereenkomst voor foto's, databronnen, dataplatform en bijhorende diensten Transparantie over kosten / duidelijk model (vb wie gaat wat betalen ? wie is de owner ? wie gaat de aankopen doen ? Storage en rekenkracht ? wie heeft de lead voor verdere groei van het platform ?) Intellectual property van wie ? Hoe incentiveren ? hosting platform, beelden, AI /ETL modellen, runtime (prijs per uur van processing => efficiente 'tiling' van de foto's) Datamodellen, uniformiteit = herbruikbaarheid en opschaling mogelijkheid voor andere steden/gemeenten over de type data heen (vb databank moet op dezelfde manier werken voor datatype x als datatype y, compatibiliteit tussen de verschillende modellen) GeoICT, Geodata & AI expertise voor het opzetten van het platform, leveren van de modellen, geografische post-processing van de AI output Soort marketplace voor applicaties, modellen, data (wet overheidsopdrachten => als overheid mag je niet zomaar in zee gaan met één leverancier zonder 'raamovereenkomst' anders via besteding/bestek) Intercommunale kan dit wel in hun eigen werkingsgebied ? Bibliotheek van raamovereenkomsten (je moet die nominatief vermelden die potentieel/met budget die ze daaraan willen spenderen kunnen meedoen) maintenance van het platform Discussie Behoefte aan Data Integratie: Integratie van machine learning output met het bestaande Business Intelligence (BI) Analytics Platform en andere beschikbare data binnen de organisatie. Platform Nodig voor Data-Integratie: De noodzaak van een platform waarop alle data kunnen worden geïntegreerd en gecombineerd, mogelijk in een data warehouse. Stabiel Materiaal Vereist: Belang van het leveren van stabiel materiaal, zonder de ambitie om alles op het platform te doen, maar met de garantie van consistentie. Transparantie over Kosten: Discussie over het duidelijk maken van kostenmodellen en -berekeningen, inclusief verborgen kosten. Intellectuele Eigendomsrechten: Overwegingen over de beloning en bescherming van het intellectueel eigendom van algoritmes en machine learning modellen. Efficiënt Beheer van Data: Noodzaak van efficiënt beheer van data, inclusief tiling van foto's voor kosteneffectieve verwerking en opslag. Uniformiteit in Datastructuur: Belang van uniformiteit in datastructuur voor herbruikbaarheid, opschaling en compatibiliteit tussen verschillende modellen en data. Marketplace voor Applicaties en Modellen: Idee van het opzetten van een marketplace voor applicaties en machine learning modellen, mogelijk geregeld via overheidsopdrachten. Overheidswetgeving en Raamovereenkomsten: Noodzaak om te voldoen aan overheidsopdrachtwetgeving en mogelijkheid van raamovereenkomsten voor het gebruik van modellen en applicaties. Onderhoud van het Platform: Onderhoud van het platform, inclusief technologische evoluties en ondersteuning van gebruikers. Oefening 4 Tot slot werden potentiële valkuilen geïdentificeerd en, op basis hiervan, formuleerden we principes waaraan de oplossing moet voldoen: Voorbeeld: •Self-service zonder goede training kan een risico vormen •Afhankelijkheid van leverancier •Interoperabiliteit van de oplossing •Betrouwbaarheid, en dus ‘vertrouwen’ in de output en dashboard cijfers •Stabiliteit, en dus ‘continuiteit’ van de metrieken in de rapporten en dashboards Overzicht Valkuilen Principes wat gebeurt er als er wegenwerken in uitvoering zijn. Wijziging van wegprofiel/markering. Duur der werken 1à2 jaar. Wat geeft het systeem aan? wegenwerken database (vb link met GIPOD, maar die is niet volledig) projectzones definieren (over die periode zal er werken zijn, of waren er werken op die plaats) risico op vendor lock-in (te weinig leveranciers van beelden / ML-algoritmes, leveranciers die wegvallen) spec's scherp definiëren als basis (beeldmateriaal + ML-algoritmes + combinatiemogelijkheden) efficiënte (via optimalisatie bvb tiling&clipping van de foto's) AI processing chain => impact op running kost algoritmes geöptimaliseerd voor de use case spagetti verhaal Standardisatie modellen metadata, datasstructuur. Goed nadenken over de opzet van het systeem (data, modellen) om zo voldoende standardisatie te hebben. OSLO is op een bepaalde niveau, maar in praktijk ga je fijnere niveau nodig hebben, en daar is ook standaardisatie nodig beeldmateriaal / algoritmes zijn onvoldoende stabiel, waardoor trendanalyses niet mogelijk zijn beperkte budgetten versnippering wet overheids-opdrachten (probleem van raamovereenkomsten) om te schalen naar de andere steden. representativiteit van de resultaten (evolutie van de technologie zorgt voor verbetering van resultaten of is het werkelijk verbeterd?) Te hoge verwachtingen => AI geeft geen 100% nauwkeurigheid Voldoende frequente opnames voor de verschillende use cases (invloed van weersomstandigheden, provider afhankelijke aspecten (vb. vaste opname frequentie om trends analyse te kunnen doen) diversiteit / evolutie aan ML algoritmes en de gebruikte technologie (alles "inplugbaar" in één platform?) : via python, arcgis suite met bijhorende addons en plugins,... Discussie Gebrek aan standaardisatie: Het ontbreken van standaardisatie in gegevensformaten en processen kan problemen veroorzaken bij de integratie van verschillende systemen en het delen van informatie. Beperkte budgetten: Budgetbeperkingen kunnen de ontwikkeling en implementatie van een effectief monitoring- en onderhoudssysteem belemmeren. Versnippering van middelen: Het risico bestaat dat elk bestuursniveau zijn eigen systemen en oplossingen implementeert, wat kan leiden tot versnippering van middelen en inefficiëntie. Risico op vendor lock-in: Afhankelijkheid van een beperkt aantal leveranciers voor beeldmateriaal en machine learning-algoritmen kan het risico op vendor lock-in vergroten. Onvoldoende frequentie van opnames: Als de frequentie van opnames niet voldoende is, kan dit leiden tot onnauwkeurige analyses en trendvoorspellingen. Impact van weersomstandigheden: Weersomstandigheden kunnen de kwaliteit en frequentie van opnames beïnvloeden, wat de nauwkeurigheid van analyses kan verminderen. Evolutie van technologieën: Technologische vooruitgang kan leiden tot verbetering van resultaten, maar ook tot nieuwe uitdagingen, zoals veranderende algoritmes en veroudering van beeldmateriaal. Gebrek aan diversiteit in technologieën: Afhankelijkheid van een beperkt aantal machine learning-algoritmen en technologische oplossingen kan de diversiteit en veerkracht van het systeem beperken. Opname en Miro bord Miro bord Het Miro bord kan je consulteren via deze link . Opname De opname van deze sessie is te bekijken via deze link . Volgende stappen Wat na deze werkgroep? Verwerking van de input van de brainstorm oefening. Verder onderzoek en voorbereiding van de volgende thematische werkgroep. Publicatie op de Kennishub Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Thematische werkgroep 1 Data en informatie werkgroep 2024-03-14 9u-12u Teams Thematische werkgroep 2 Technologie werkgroep 2024-04-16 9u-12u Teams Thematische werkgroep 3 Technologie werkgroep 2024-05-15 13u-16u Teams +
Thematische werkgroep 2: Mobiliteitsbudget … Thematische werkgroep 2: Mobiliteitsbudget voor burgers - doelgroep: mobiliteitsaanbieders Context Initiatief Om een omslag te maken naar duurzame personenmobiliteit in Vlaanderen moeten de duurzame mobiliteitsvormen worden gestimuleerd en drempels worden weggenomen. De alternatieven voor een traditionele diesel- of benzinewagen die geparkeerd staat in je straat voor de deur zijn zeer divers: trein, bus, deelfiets en step, deelwagen, parkeergarages en het publiek kunnen laden van een elektrische wagen zijn in onze steden steeds meer beschikbaar. Met de uitrol van mobipunten versterkt ook de Vlaamse Overheid dit aanbod. Als je volwaardig van de veelheid aan mobiliteit in je stad of gemeente wil kunnen genieten dan zou je al die diensten makkelijk en flexibel moeten kunnen consumeren. Elk van die mobiliteitsaanbieders heeft nu een eigen app met telkens een aparte account en daaraan verbonden ‘rekening’, waarborgen en gebruiksvoorwaarden, en dat is niet handig. In een B2B setting werd er de afgelopen jaren werk gemaakt van de opzet van MaaS of MoDi: Mobiliteit als een Dienst. Eén app of kaart met soms een abonnementsformule waarmee je alle mobiliteitsdiensten kan consumeren waar en wanneer het je past. Ook zijn er enkele grootbanken die een dergelijk aanbod hebben opgenomen in hun app. Met het Mobiliteitskrediet voor burgers willen we hen via een MaaS aanbod toegang geven tot een mobiliteitsbudget. We organiseren het mobiliteitsbudget zo dat elke stad of gemeente haar beleid gericht kan vertalen in voordelen voor specifieke modi op specifieke locaties. Burgers die in het centrum wonen kunnen daarbij andere voordelen genieten dan deze die buiten het centrum wonen omdat hun noden anders zijn en het beleid in het centrum (bv. voor parkeren) anders is. Met extra ‘nudging’ technologie geven we zo op een zeer efficiënte manier een push aan de alternatieven. Door slim gebruik te maken van de gebruiksdata kunnen we de publieke middelen inzetten waar ze het meest renderen. Bovendien waken we als stad erover dat iedereen mee is: inclusie is een essentieel element van het Mobiliteitskrediet van de burger, ook als die geen smartphone heeft of om welke reden dan ook kwetsbaar is in het dagelijkse leven. Economie is mobiliteit. Zonder dat wij ons als persoon kunnen verplaatsen kan een gezonde economie niet draaien. Burgers verplaatsen zich om te gaan werken, winkelen ontspannen en om elkaar op te zoeken. Met het mobiliteitsbudget voor de burger geven we dan ook iederéén de kans om zijn of haar verplaatsingen naar werk, school, winkel of voor vrije tijd duurzaam te maken. Minder wagens op de weg betekent ook minder congestie, en dat is op zijn beurt rechtsreeks een economische winst voor wie noodzakelijk wél met de wagen, bestelwagen of vrachtwagen de weg op moet. De scope van het project is het inhoudelijk testen van een mobiliteitsbudget voor burgers. Het mobiliteitsbudget is een budget dat door de lokale overheid aangeboden wordt aan burgers ter besteding aan mobiliteit in de brede zin van het woord. Cfr. federaal mobiliteitsbudget. Waarom? Alternatieven bieden voor straatparkeren Het sturen van mobiliteitsgedrag van burgers Het verder verduurzamen van personenmobiliteit Bijdragen tot leefbare stad Bruikbare data die inzichten verwerft en ondersteuning geeft aan beleidsbeslissingen Bestuursakkoord Stad Hasselt Hoe? Via een bestaand geoptimaliseerd (MaaS) platform Testen gedurende 6 maanden Min. 100 testpersonen per stad Implementatie Maasplatform: Het project maakt gebruik van het bestaande mobiliteitsplatform Olympus Mobility om kosten en tijd te besparen. Testperiode: Gedurende zes maanden wordt het mobiliteitsbudget getest onder burgers in Hasselt en Leuven. De testperiode loopt tot 1 december 2024. Bevindingen tot nu toe Gebruik van Budget: Het budget wordt voornamelijk besteed aan treindiensten (NMBS), busdiensten (De Lijn), en deels aan deelwagens. Gebruikers: Testers omvatten een diverse groep van bewoners, inclusief studenten en mensen met lagere inkomens, om de impact op verschillende demografische groepen te evalueren. Budgettoewijzing: Er zijn verschillende budgetgroepen die een maandelijks budget ontvangen, variërend van niet-overdraagbaar tot spaarsystemen. Het gemiddelde budget per persoon bedraagt ongeveer 200 euro over de testperiode. Toekomstplannen Analyse en rapportage: resultaten en data zullen in de zomer worden geanalyseerd om een business case te ontwikkelen. Uitbreiding en finetuning: evaluatie van het potentieel om dit mobiliteitsbudget breder uit te rollen en eventueel te combineren met andere budgetten of incentiveringsacties van handelaren. Financiële aspecten Kosten vs. baten: Het project moet aantonen dat de voordelen voor de stad of gemeente de kosten rechtvaardigen. Er wordt gekeken naar een combinatie van lokale en federale budgetten en mogelijke bijdragen van externe partijen. Vragen Met welk MaaS platform gingen jullie in zee? - met Olympus Mobility Wie is de doelgroep van het budget? - voor de testfase golden er selectieciteria voor de deelnemers, voor Hasselt werden enkel deelnemers geselecteerd die binnen de grote ring woonachtig zijn omdat het aanbod van deelmobiliteit daar het grootste is. Verder werd er ook geselecteerd op personen en gezinnen met een auto om het autogebruik te evalueren. Voor Leuven werd gefocust op lagere inkomens om te evalueren of een mobiliteitsbudget inclusie kan verhogen op vlak van mobiliteit. Elke deelnemer ontving een budget van ongeveer 200 euro, in 1 geheel, in schijven, al dan niet overdraagbaar. De bedoeling is om aan te tonen dat het budget een positieve stimulans geeft aan het gebruik van gedeelde mobiliteit. Er zijn heel wat uitbreidingsmogelijkheden bvb parkings, korting bij aankoop van een fiets etc. Het zou dus mogelijk zijn om het federale mobiliteitsbudget uit te breiden en dit door lokale besturen of derden te laten aanbieden aan de gebruikers. Hoe wordt de link gemaakt met het mobiliteitsbudget in de privé? Dit is fiscaal ingewikkeld? - Deze vragen maken deel uit van het onderzoek. Momenteel worden beide budgetten gescheiden voor het onderzoek maar het zou interessant kunnen zijn om er 1 grote pot van te maken die nationaal kan uitgerold worden. Zou Hasselt open staan om de bewonerskaart in het mobiliteitsbudget te steken? Momenteel is deze gratis maar indien bewoners zonder wagen een compensatie krijgen via het mobiliteitsbudget kan dit interessant zijn? - Dit was het uitgangspunt van het project. Uiteraard is het beleid ook nog onderhevig aan de resultaten van de verkiezingen. Testen jullie de werking van een MaaS platform? - Dit is niet de bedoeling, het onderzoek omvat niet het testen van Olympus Mobility. Er wordt enkel gebruik gemaakt van dit platform omdat het het dichtste in de buurt kwam van wat er nodig was. Tot nu toe werd duidelijk dat er een aantal hiaten zijn waarvoor niet onmiddellijk een oplossing kon gevonden worden. Nu wil men vooral duidelijkheid krijgen rond wat de gebruikers nodig hebben. Op basis van deze analyse kan er in de toekomst, binnen het kader van een nieuw project, een opdracht uitgeschreven worden om een mobiliteitsplatform aan te passen naar de geïdentificeerde noden en behoeften van de lokale besturen die interesse hebben om dit uit te rollen. MOW Rol binnen project Het departement Mobiliteit & Openbare werken neemt actief deel aan de werkgroepen rond dit project. In 2021 werd een Vlaams MaaS afsprakenkader afgeklopt. Hierbij werden verschillende stakeholders betrokken: MaaS aanbieders, vervoersaanbieders, lokale besturen, data makelaars en gebruikers. In dit document werden een aantal basis afspraken opgenomen die gezien werden als een startpunt voor een MaaS afsprakenkader. Het document bevat daarnaast een aantal beleidsaanbevelingen. In september 2022 werd daarnaast de interfederale MaaS visie gepubliceerd. Hiertoe werden begin 2024 verschillende werkgroepen georganiseerd rond verschillende onderwerpen: Bewustwording & communicatie, waarvan MOW trekker is In deze werkgroep wordt dieper ingegaan op de definitie van MaaS: wat houdt het in, wat zijn de grenzen, componenten Data-harmonisatie Deze werkgroep werd pas in mei 2024 opgestart. Harmonisatie betalingsinfrastructuur Werkgroep nog niet opgestart Reglementering Werkgroep nog niet opgestart Verder werkt men binnen het kader van de interfederale MaaS visie aan een code of conduct (ITS.be) Dit is een afsprakenkader op interfederaal niveau Deadline: september 2024 Vanuit het departement wordt er binnenkort (najaar 2024) van start gegaan met een onderzoek naar een informatieplatform voor deelsystemen. Ter ontwikkeling van een beleid rond deelsystemen met daarbij monitoring en evaluatie heeft het departement (maar ook lokale besturen) nood aan data. Dit ter opvolging van vergunningen met deelaanbieders en rapportering Met het onderzoek wenst men de noden & behoeften van de stakeholders in kaart brengen op vlak van data. Daarnaast wenst het departement scenario's uit te werken waarbij de Vlaamse informatie op het platform niet enkel voldoet aan eigen noden maar ook nuttig kan zijn voor andere stakeholders. In het najaar gaat men van start met een eerste fase (data nog onbekend) waarbij men inzet op verkenning. Hierbij gaat men een nodenbevraging doen bij verschillende stakeholders op vlak van data. Bestaande systemen/platformen rond deelsystemen worden alsook in kaart gebracht. Link met Mobiliteitsbudget traject: kan al inzicht geven in noden betrokken actoren, wat kan meegenomen worden in het najaar om meer gerichte vragen te stellen. In een tweede fase wordt bekeken waar er synergiën mogelijk zijn tussen de verschillende stakeholders. Tot slot worden in de derde fase een aantal scenario's uitgewerkt omtrent de invulling van een informatieplatform. Bij elk scenario zal een (beperkte) business case uitgewerkt worden. Vragen Hoe en wanneer worden de uitnodigingen uitgestuurd voor het nieuwe onderzoek? - mailings worden nog uitgestuurd, zal rond einde van de zomer gebeuren VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. VLOCA model ID Beschrijving UC1 Overkoepelende platform die toegang heeft aan alle participerende mobiliteitsaanbieders, opdat een intermodaal transport traject mogelijk maakt UC2 Een budget beheer platform die alle 'transacties' bijhoudt en toelaat UC3 Een owner platform die de 'eigenaars' van dit overkoepelende platform alle rechten en plichten beheert UC4 Een donor platform die de 'donors' toelaat om budget te geven, storten en evt recupereren UC5 Een gebruikers platform die de 'gebruikers' toelaat om tickets te bestellen, betalen en beheren UC6 Een platform die de overheid een overzicht geeft van alle transacties in dit ecosysteem UC7 Participerende spelers 'transport' : Alle 'variabele' transport leveranciers die hun aanbod op het platform willen aanbieden UC8 Participerende spelers 'mobiliteit' : Alle andere mobiliteits leveranciers (bvb fietsenwinkels, ed) die hun aanbod op het platform willen aanbieden UC9 Variabele subsidies naar openbaar vervoer ipv 'vaste' bedragen UC10 Incentiveringsplatform waarbij goed gedrag gecapteerd en beloond wordt door een 'donor' op de 'mobiliteitsbudget' Het project begint met een duidelijke visie en missie, die ambitieuze doelen stellen voor wat we willen bereiken. Om deze doelen te realiseren, hebben we het project opgedeeld in behapbare onderdelen volgens het Vloka-model. Deze aanpak zorgt ervoor dat elk onderdeel essentieel bijdraagt aan het succes van het project. Centraal in het project staat het overkoepelende platform dat alle stakeholders, zoals donoren en lokale besturen, met elkaar verbindt. Dit platform biedt een interface voor lokale overheden en hoopt ook bedrijven aan te trekken die bepaald gedrag willen belonen en stimuleren. Daarnaast werd een gebruikersinterface ontwikkeld, die momenteel wordt getest. Deze testfase geeft waardevolle informatie over hoe gebruikers de interface ervaren, hun behoeften en eventuele obstakels waar ze tegenaan lopen. Een ander cruciaal onderdeel is de transportaanbodinterface. Deze interface zorgt voor de koppeling tussen transportbedrijven en het platform, zodat gebruikers weten welke diensten beschikbaar zijn voor hun trajecten. Hiermee wordt informatie correct uitgewisseld en kunnen bedrijven hun aanbod gemakkelijk plaatsen. Het transactieplatform is ook van groot belang. Hier wordt het mobiliteitsbudget beheerd en worden transacties bijgehouden na elk gebruik. Dit platform zorgt ervoor dat de financiële afwikkeling soepel verloopt, of het nu gaat om donortransfers of gebruikstransfers. Voor de overheid is er een Business Intelligence (BI) component geïmplementeerd. Dit biedt rapportages en inzichten die de overheid helpen het project te evalueren en bij te sturen. Het doel is om te zien of het project goed werkt en het gewenste gedrag stimuleert, en om alle benodigde gegevens op een gestructureerde manier aan de lokale besturen te leveren. Tot slot is er ook een incentiveringsplatform, vergelijkbaar met een project in Geel. Dit platform beloont goed gedrag van burgers met een budget dat zij kunnen besteden. We moeten nadenken over hoe we dit platform goed kunnen integreren met het bestaande systeem. Met deze opzet hoopt het project duurzame mobiliteit te stimuleren en waardevolle data te verzamelen om toekomstige beleidsbeslissingen te ondersteunen. Vragen In Nederland hebben een aantal MaaS-pilots plaatsgevonden waarbij een groot verschil vastgesteld werd tussen de steden onderling maar ook tussen de steden en het platteland. Elk van deze actoren hebben verschillende doelstellingen. Hoe kan je met een dergelijk platform de lokale doelstellingen ondersteunen? - Tijdens de vorige werkgroep hebben we ons gefocust op de beleidsdoelstellingen. Vandaag is het niet de bedoeling om technisch te gaan maar in te zoomen op de motivatie van een mobiliteitsaanbieder om deel te nemen aan een dergelijk traject Is het nodig om actief betrokken te zijn als mobiliteitsaanbieder wanneer er via API's standaard afspraken en informatie gedeeld wordt? Of is het voldoende om gewoon data te delen? - Dit is de discussie die we vandaag gaan voeren Dergelijke discussies zijn zeer complex! Hoe willen we dit doen, wie is de klant, wat met betalingsgarantie, budgetbepaling etc. Producten blijven evolueren waardoor telkens de vraag komt of de MaaS mee met producten zal evolueren, gaat die doorverwijzen? Wat we nu zien is dat de MaaS-speler het volledige ecosysteem wenst te gaan beheren richting de klant. Is dit hier het geval? Of enkel als doorverwijzende functie met de functionaliteiten van betaling, budgetten etc die met elkaar communiceren? Belangrijk is om duidelijk te krijgen van wie de klant is! Waar start en stopt de verantwoordelijkheid van aanbieder vs MaaS? Is het de bedoeling om een Vlaams MaaS platform te bouwen zoals in Brussel? - Wordt ook vandaag besproken. Voor de ontslagnemende minister was het de bedoeling om effectief een MaaS platform aan te bieden. Binnen het departement is men daarvan niet overtuigd maar alles hangt af van de visie van de volgende minister. Is er een visie rond de governance van de oplossing? Wie beheert het platform? Wie neemt de beslissingen? - Eerst moeten de business recuirements identificeren. Vervolgens bekijken we de functionaliteiten en rollen. Vandaag is het de bedoeling om eerst de noden te identificeren van de mobiliteitsaanbieders. Brainstormsessie Doel Het doel van de brainstormsessie is het volgende: Identificatie van de meerwaardecreatie Inzicht in wat je nodig hebt om de meerwaardecreaties te realiseren Platform vereisten mobiliteitsaanbieders Opsommen van valkuilen en potentiële principes waaraan de oplossing moet voldoen Oefening 1+2 Bij deze oefeningen stonden we stil bij de volgende vragen: 1) Wat is de meerwaarde van een mobiliteitsbudget voor een mobiliteitsaanbieder? Hoe draagt deze oplossing bij tot het behalen van hun doelstellingen? Welke zijn dit? Voorbeeld: -Hoe minder mensen gebruik maken van een personenwagen, hoe meer ze op zoek (moeten) gaan naar een duurzaam alternatief. -Potentieel aantal klanten wordt groter 2) Wat heb je nodig om de geïdentificeerde meerwaardecreaties uit oefening 1 te realiseren? Lijst de acties op Voorbeeld: -Aanbod real-time aanbieden om aan vraag te voldoen. Overzicht Identificatie meerwaardecreatie Beleidsdoelstellingen Bijdragen aan duurzaam mobiliteitsgedrag Treingebruik stimuleren door korting te geven aan specifiek doelgroepen via derde-betalers systemen via duidelijk gecadreerde acties modal shift realiseren Stimuleren duurzame combimobiliteit treingebruik stimuleren bij niet-treinreizigers treingebruik stimuleren bij niet frequent treinreizigers Extra shop-window naar (nieuwe) klanten / doelgroepen Bereik potentiele klanten groter MOW: onmiddellijk klantenbereik in nieuwe operationele regio ? Toegang tot diensten makkelijker maken voor burgers om zonder eigen wagen door het leven te gaan (technische) interoperabiliteit Meer 'kwalitatieve' klanten (niet enkel nieuwe klanten) => opportuniteit als bezorgdheid Toegang tot data (DMOW) Door te faciliteren hopen we op meer vraag en dus aanbod te hebben om de eigen wagenpark te doen dalen anticiperen op verplichting via erkenningskaders (bv autodelen, andere kaders in Gent, A'pen en Leuven) Inzichten verkrijgen in gebruikers van het mobiliteitsbudget (socio-demografisch + mobiliteitsuitgave + drivers & barri res voor gebruik priv wagen) Toegang tot data Qua beleidsdoelen en toegevoegde waarde van het openbaar vervoer is het onderstaande artikel een goede basis. Met een focus op five E s: Effective mobility, Efficient city, Economy, Environment and Equity. https://nielsvanoort.weblog.tudelft.nl/the-wider-benefits-of-high-quality-public-transport-for-cities/ Beleidsvragen zijn eerder voor een autorieit (lange termijn) of de politiek (korte termijn) Focus deze discussie op het wegnemen van de barrieres om (lokale) mobiliteits-aanbieders mee te laten doen. stimuleren van ondersteund aanbod op niet rendabele plaatsen (autodelen) Geeft keuze aan burgers om vervoerwijze te kiezen naargelang behoefte Oefening 3 Bij deze oefeningen stonden we stil bij de volgende vragen: Hoe moet een platform voor het beheer van een mobiliteitsbudget eruit zien? Ownership? Wat wil je ermee kunnen doen? Wat heb je hiervoor nodig? Zijn er bepaalde linken die je wenst te hebben? Hoe komt je mobiliteitsaanbod terecht bij de juiste persoon? Link Dataspaces? Voorbeeld: -Als mobiliteitsaanbieder wens ik dat de gebruiker op een eenvoudige en eenduidige manier aankopen kan doen -Transparante voorstelling, alle aanbieders op een duidelijke en neutrale manier voorstellen -Beheerrechten om zelf te kunnen inloggen voor rapporten bvb Overzicht Platform vereisten Belang van Dataspaces en het dragen op hoger niveau -> Vlaams ,Europa, ... ? Dit is het IMEC whitepaper tav bicycle data. Met onder andere generieke use cases. https://www.imec.be/sites/default/files/2023-10/IMEC-Whitepaper%20on%20Bicycle%20Data%20Spaces.pdf Veel eerdere werkgroepen ronde Maas platformen - hergebruiken van feedback en focus op heel specifieke cases Eén factuur voor ganse trip (clearinghouse nodig) Een open platform met gestandaardiseerde info Mogelijkheid om reis te plannen in combi (OV + deelauto, -fiets; ...) Ownership best bij (semi) publieke speler Oefening 4 Bij deze oefeningen stonden we stil bij de volgende vragen: Welke zijn de valkuilen/drempels waar we volgens jou rekening mee moeten houden? Use cases voor de verschillende mobiliteitsaanbieders. Formuleer enkele basisprincipes waaraan de oplossing moet voldoen Voorbeeld: - Complexiteit - Geen directe contact met klanten - Bereidheid tot delen van data en producten van de mobiliteitsaanbieders Overzicht Valkuilen/drempels Principes 1 je koopt een bestaand product aan of je ontwikkelt zelf => 2 verschillende procurements (vb Skipper project Brussel - Deloitte verder bouwen op bestaande project) Generieke richtlijnen en regulatie nodig op landniveau, gewest, gedragen door overheid Hoppin App geen Maasplatform en voorlopig ook niet het plan. Geen ontwikkeling lopende voor ticketing etc. Nood aan één platform Olympus: niet consistent In sommigen gevallen moet je geld voorschieten en wordt het terug betaald betalingsgarantie nodig, eventueel door overheid Betalingsgarantie, wie neemt verantwoordelijkheid over de factuur -> komt snel aan tafel als je bezig bent met transactie. => Hoe ver is zo'n integratie afgespronken onder de venoten onderling (Duitsland is de norm bv deeplinken: integratie bij Maasplatform de keuze bij de lokale apps Mobi-aanbieders -- Maas moet continu op tempo van de Mobi-aanbieders updates doen -> Keuzes die veel implicaties hebben. = toewijding Maasplatform maar vanaf de stap dat klant keuze zit de verantwoordelijkheid bij mobi-aanbieders). Platform geleidelijk opbouwen en dan wagonnetjes aanhangen ("the theory of everything" werkt niet) Belangrijk om deze gevolgen tijdig door te geven aan lokale besturen die voornamelijk kijken vanuit invalshoek vanuit userfriendly en niet de complixiteit erachter. De beslissing moet goed afgewogen worden -> Kan naar boven komen tijdens ontwikkelingsproject, aanbesteding -> Uitschrijven van Massplatform wordt heel snel heel complex Geen individueel contract tussen aanbieder en klant (gewone ticketting met 'reglement') Olympus maar 2 profielen:Prive en onderneming maar er zijn meerdere persona's - Persoon die werknemer is of persoon als privé gebruik. Doelgroep gebruik als burger bestaat nog niet. Zo'n platform bestaan nog niet omdat er nog geen markt is voor dit. Product aan markt overlaten begin met bvb OCMW clienten, beheersbaar en gecibleerd => bekijk dat als een vervoersaarmoede ipv puur mobiliteit. Integratie met aanbod NMBS en systemen: welke klantaccount?, Voucher systeem (zoals bij voorbeeld Abo via B2B-portaal (derde-betaaler facturatie)?, ... Tegemoetkoming voor bepaalde doelgroepen (sociaal tarief) ifv vervoersarmoede Hoppincentrale Principes gelijk trekken met mobiliteitsbudget voor werknemers De Hoppincentrale helpt u bij het plannen van uw verplaatsing. Zo komt u te weten met welk vervoermiddel u zich het best verplaatst en waar u moet overstappen. Starten met doelgroep? Beheer van rechthebbende (Wie krijgt welke korting?) Toegang tot data https://www.vlaanderen.be/basisbereikbaarheid/combimobiliteit/hoppincentrale "Op langere termijn kunt u bij de Hoppincentrale ook uw ticket kopen voor uw volledige verplaatsing met verschillende vervoersmiddelen." begin met bvb OCMW clienten, beheersbaar en gecibleerd => bekijk dat als een vervoersaarmoede ipv puur mobiliteit. Toegang tot diensten Afspraken rond klachtenbehandeling Indien we werken met een private speler, is er een liability gevaar bij bvb faillissement vrij veel vragen die op voorhand een antwoord nodig hebben: Van wie is de klant? Wie doet de intake? volledige integratie Wie neemt betalingsgarantie? Wie zet in op aanbod? Welke mogelijkheid heeft het platform in afwijking van het basisproduct. (vb goedkoper aanbieden van de dienst, markup nemen) is er financieie ondersteuning van de aanbieder? Zijn er erkenningsvoorwaarden nodig (wie mag er op aanbieden) .... (technische) interoperabiliteit Met wie gaat de klant (inwoner) de relatie aan (gemeente, platformaanbieder, mobiliteitsaanbieder) & wat betekent die relatie? (klachten, terugbetalingen, schade, overlast...) Correcte afspraken nodig rond Derdebetaler-systemen & verkoop / weggeven tickets of ritjes ==> vb. verkopen onder de marktprijs (treedt de aanbieder op als reseller v intermediary) Afspraken rond Liability - wie is wanneer verantwoordelijk Hoe verloopt contractering? Per gemeente? Op Vlaams niveau? Met wie gaat de klant (inwoner) de relatie aan (gemeente, platformaanbieder, mobiliteitsaanbieder) & wat betekent die relatie? (klachten, terugbetalingen, schade, overlast...). Vb. enkel mensen met wagen een budget aanbieden sluit net de zwakkere doelgroepen uit Nog geen zicht op Aanbesteding Minimaal Op Vlaams niveau COT 2025 dan op Vlaams niveau Risico's bij het relatief klein te houden -> je moet groter kijken vanaf het begin over de grenzen heen. Ook Rekening houden met de lokale mobiliteitsaanbieders als Velo, Mecheln is er vb een energiecoöperatie Klimaan die deelwagens aanbiedt (lokale burgercoöperatie), ... verplichting om via Maasplatform uw producten aan te bieden moeilijker voor mobi-aanbieders omdat ze afhankelijk zijn van hun Voorwaarden Generieke platform >< verschillende eisen bv kortingen aanbieden enz, andere regelgeving per stad. => Meerwaarde verlies door verschillende prijzen ---> Transparantie naar klant qua prijzen verdeling (adminkost, maasplotform, mobi-aanbieder) Hoe om te gaan met gemeente / gewest overschrijdend verkeer Valkuil: hoe wordt de markt betrokken / ge consulteerd in de voorbereidingsfase Een lastenboek op functionele eisen beperkt het antwoord op de vraag => functionele eisen + Europese aanbesteding Welke aanbestedings-procedure wordt gekozen. Als de vraag standaard wordt aanbesteed, krijg je ook een standaard antwoord. Oplossing: Aankoop van een innovatieve oplossing volgens de EAFIP-methodiek: https://eafip.eu/toolkit/ Oplossing: Contact SPIN4EIC voor een gratis introductie van de EAFIP-methodiek Belgie kent volgens mij nog maar 1 aankoop van een te ontwikkelen innovatieve oplossing (PCP, gericht op TRL tussen 1 -8) Het zijn tot nu tot standaard aankoop procedures. Gericht op TRL9. Valkuil: geen aandacht voor reeds bestaamde oplossingen die reeds elders in Europa bestaan Valkuil: een te complexe probleemstelling. Zonder duidelijke fasering. Valkuil: een product ontwikkelen, met een ingewikkeld data integratie, dat achterhaald wordt door de mobility data space ontwikkeling. Valkuil: een MaaS-product is voor haar functioneren grotendeels afhankeijk van (de kwaliteit) data van derden. Waar een MaaS-operator geen directe invloed op heeft. Oplossing: het gebruik van de data spaces integreren in de uitdaging van de ontwikkelingsfase Valkuil: alleen aandacht voor de technische eisen van het product, maar niet voor de onderliggende juridische eisen voor het data delen. Noch voor de business case. Valkuil: een te complexe probleemstelling. Opname en Miro bord Miro bord Het Miro bord kan je consulteren via deze link . Opname De opname van deze sessie is te bekijken via deze link . Volgende stappen Wat na deze werkgroep? Verwerking van de input van de brainstorm oefening. Verder onderzoek en voorbereiding van de volgende thematische werkgroep. Publicatie op de Kennishub Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Thematische werkgroep 1 Data en informatie werkgroep 2024-06-11 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-07-02 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-07-09 13u-16u Teams +
This document This document is intended … This document This document is intended to be an open and evolving draft that reflects the current thinking around Open Urban Digital Twins. At certain points in time, a pdf will be created and circulated over various media. Anyone is warmly invited to review and contribute to the document. Urban Digital Twins are also referred to as Local Digital Twins. We proposed that most of what is discussed in this paper also applies to Local Digital Twins. Open Urban Digital Twins In this paper, we bundle and explain insights on the added value, architecture and design of Urban Digital Twins as cross-domain urban decision support systems. In doing so, we aim to facilitate a common understanding of the concept of Urban Digital Twins. Such an understanding is much needed, as Urban Digital Twins are currently defined and understood in different ways by different people. We hope this paper will help readers, especially from the public and private sector, to consolidate a common understanding of the topic. In recent years, the idea to build Urban Digital Twins representing entire cities and regions has gained increasing attention. Yet, as cities consist of complex ecosystems, it is not straightforward to build such Urban Digital Twins. Questions arise about how Urban Digital Twins can exactly be used to support decision making processes within the local government and how this affects design principles and architecture. These are the overall questions which we aim to address in this paper, in addition to establishing a common understanding of what Urban Digital Twins are and what they can be used for. Digital Twins in general Since its inception around the turn of the century, the definition of a Digital Twin has been debated and challenged by various authors (e.g. Grieves and Vickers 2017, Alam and El Saddik 2017, Tao et al. 2018, Zheng et al. 2019). One of these definitions, which we will adopt in this paper, describes a Digital Twin as a “virtual representation of a physical entity with a bi-directional communication link” (adapted from Tao et al 2018). One of the key terms in this definition is the bi-directional communication link, which can be split-up into a communication link from the physical entity to the Digital Twin and a communication link from the Digital Twin back to the physical entity. Communication link from the physical to the Digital Twin The communication link from the physical to the Digital Twin refers to a constant use of several data collection techniques and devices (like sensors connected through Internet of Things technology) to collect and combine data about the physical entity. This data allows the virtual Digital Twin to constantly learn from and evolve along with its physical counterpart, mirroring its lifecycle. As a result, a Digital Twin can be used to get insights in the current state of the physical enitiy as well as predict future states of the physical entity through causal data models and simulation algorithms. Communication link from the Digital to the physical twin The Digital Twin may transform the physical entity by either automatically driving actuators connected through Internet-of-Things technology or by informing human decision makers who can make adaptations to the physical entity. The latter can be made through daily operational management or through long-term policy planning. In either case, the Digital Twin should be able to capture the changes made to the physical entity so that it can use those changes and their impact to update its data models. Thus a Digital Twin is not merely a detached virtual representation of a physical twin, but rather an evolving representation that constantly interacts with - and tests the impact of - novel configurations in the physical entity that it represents. Local Digital Twins With our improved understanding of Digital Twins in general, we can now better understand what is intended by a "Local" Digital Twin: it is a version where the physical entity is a city, a rural or a local entity and which is used to support decisions that pertain to this location. We will define them as: "Local Digital twins are dynamic, data driven, multi-dimensional digital replica of a physical rural, local or urban entity. They encompass potential or actual physical assets, processes, people, places, systems, devices and the natural environment. Their aim is to capture reality for supporting reactive and predictive decision making processes at relevant decision making levels in order to ensure minimum environmental impact, improved quality of life and enhanced performance of the local entity."Urban Digital Twins are just one type of urban decision support systems, next to information systems like Geographical Information Systems (GIS) and IoT data dashboards. Given these different types of already-existing systems, the question arises whether there is a need to create Urban Digital Twins and, more specifically, which distinguishing tasks such Digital Twins could fulfil. These are the kind of questions we have been discussing with multiple local urban decision makers through a number of workshops (with the cities of Bruges, Antwerp, Ghent, Pilzen, Athens and the Flemish region) from which emanated a list of possible use case descriptions. Each use case was formulated as a “how could we” question, for example “How could we quickly evaluate the water quality of a waterway to find out if it is safe to swim?”. The results of these insights were translated into a typology of the functional scope of an Urban Digital Twin: Decision support scope Design Operations Human decision making Automated decision making Intervention evaluation Decision support horizon Short Medium Long Decision support domain Air quality Mobility Sound Water Pandemics Tourism Urban planning End-users Policy makers Public servants Urban planner Emergency responder Citizen Decision support scope In terms of decision support, a first type of use cases are those that aim to make changes to the physical space of the city itself by redesigning it. These for example include the support of decisions on where to create infrastructure that would prevent certain areas of the city to suffer from floods due to heavy rain. These are typically use cases where the decisions that are supported are implemented over a longer period of time. A second type of decision-support use case occurs in the daily operations of the city, where decisions are made based on an up-to-date operational insight in the state of the city. An example would be to achieve a better understanding of the numbers of tourists at certain locations in the city, in order to take measures related to COVID-19. In such use cases, decisions can be taken and actuated by a human, or by a machine. In the latter case, an Urban Digital Twin could for example be used to build an up-to-date overview of the city, which serves to change the state of traffic lights. In such a use case, an algorithm takes the decisions and changes the state of the traffic light accordingly. Finally, the Intervention-evaluation use cases apply the Urban Digital Twin to evaluate the effects of certain measures that have been taken to address urban challenges. An example of this would be the use of an Urban Digital Twin to first establish a baseline of air-quality data and then to establish a low-emission zone to reduce air pollution. The Urban Digital Twin can then be used to assess the impact of the intervention. Decision support horizon The time interval between the decision horizon and the effect of the horizon is a defining factor to distinguish between various use cases of Urban Digital Twins. We have defined three such horizons: ‘short’ is less than a day, ‘medium’ is between a day and a year and ‘long’ is more than a year. Medium and long-term use-case scenarios have existed in city contexts for a while. The short term horizon, sometimes described as "real-time" (of which the exact time unit depends on what is right for the use case and therefore also called “right-time”) has emerged more recently with the deployment of IoT technologies in urban contexts. Decision support domain Various use case domains have emerged as relevant to cities. Air quality was top of mind for many of the consulted stakeholders as the primary application domain for an Urban Digital Twin. Indeed, many cities struggle with problems due to air pollution, caused by e.g., mobility or logistic flows. Not surprisingly, mobility problems like road congestion were also identified as key areas. The city stakeholders also mentioned use cases regarding sound pollution, e.g. the noise produced by students at night around a university. In the water domain, they mentioned use cases related to floods and droughts. Pandemics are also top of mind in cities, as decision support is direly needed to address COVID-19. Tourism was another concern of various cities, aiming to better valorise touristic flows and to guide tourists through the city in specific ways. Finally, city stakeholders also mentioned several use cases related to urban spatial planning, like how to change the city towards paradigms like the “15-minute city”, in which the aim is to allow residents to meet most of their needs within a short walk or bike ride from their place of residence. For completeness, use cases for digital twins can come from any of the Smart City Domains . End-User types Various end-users exist that can take decisions pertaining to the city and can therefore be end-user of Urban Digital Twins. First, there are the public servants that work in the various city administrations and that overlook a specific domain of the city. They are specialists in a certain domain, like e.g. mobility or water management. Another type of end-user are policy makers. These are typically people that have been appointed through a political process and of whom the domain knowledge is often less deep than the public servants that provide them with the evidence that is needed to take well-informed decisions. Urban planners, as another distinct end-user type, aim to make long-term, structural changes to the city. Emergency responders are the police, fire department or health services. Citizens represent a final type of end-users of an Urban Digital Twin. Cross domain decision support as key feature for Urban Digital Twins Although many of the decision support domains discussed in the previous paragraphs have already been addressed by specific individual information system (IS) in the urban context, these existing IS's usually build on data silos in one particular disciplinary domain. As an example, the city water department and the mobility department often have IS that operate completely independently without any exchange of data. If an exchange of data occurs, this more than often still happens via an asynchronous data extraction, like through csv files that need to be uploaded into the other system. Most of the stakeholders that we consulted recognised that there is value in connecting data sources through a Digital Twin to support decisions. This, we propose, is the main added value of Urban Digital Twins with regards to other pre-existing IS types: they allow interconnecting various urban data sources and modelling algorithms in a way that can grow with the city and reflects its complexity. In doing so, the Urban Digital Twin mirrors the vibrant, complex and evolving nature of its physical urban counterpart. This is all easier said than done, as data exists in a wide diversity of formats, time domains, organisational silos and disciplinary epistemologies. Fortunately, advances in the field of computer science and IS design have provided key design principles on how Urban Digital Twins can be built, on which we will expand later in this paper. Architecture Figure 1: Open Urban Digital Twin architecture, based on the architecture developed in the DUET EU Horizon 2020 project In exploring Urban Digital Twins and researching their purpose, we have built a number of prototypes to address end-user needs. A first prototype was an Urban Digital Twin of the city of Antwerp in 2018. It focussed mainly on traffic and air quality. The main idea was that, by changing the traffic situation, this would also affect the air quality. Air quality is a major concern to the city of Antwerp, as a logistic hub through which a big part of Western European freight is transported from maritime ships to trucks and the other way around to and from the hinterland. A second Urban Digital Twin was built for the city of Pilzen in the Czech Republic. Finally, an Urban Digital Twin is currently being constructed for the city of Bruges, in Flanders. Discussions are ongoing to build Urban Digital Twins for various other cities in Flanders. From the scope analysis with prospective end-users and our experiences with the development of Urban Digital Twins, we have drafted the architecture in Figure 1 as a basis on which to create future Urban Digital Twins. Figure 2: User interface of the first Urban Digital Twin created for Antwerp in 2018 Data Sources The proposed Urban Digital Twin architecture has been built with the main objective of supporting cross-domain decision making in mind. In order to do so, it is essential that data sources coming from a number of different domains can be interconnected. This is what is shown in the top part of the architecture, where we see various types of data sources that can be connected in the system. We differentiate between dynamic and static datasources, to indicate that some datasources change a lot and some do not. In the dynamic category, IoT datasources are salient, as they provide the real-time link between the virtual entity (i.e. the city) and its digital representation. In addition to IoT timeseries (a timeseries is a type of dataset in which each sensor measurement is associated with the time at which it was taken), the dynamic data category contains "context data". This is the type of data that is needed to better understand certain sensor measurement, like e.g. the GPS location of where the sensor measurement was taken, the type of sensor or the sensor’s calibration settings. Beside dynamic data, there is static data. In order to build a virtual representation of a city, static data sources like geodata (e.g. 3D model data that represents the structures in a city, like buildings, bridges, etc…) are essential. A lot of the data that pertains to a city resides in other types of static data sources which we have grouped in the category "Urban Data". An example would be demographic data that reflects the number of inhabitants in a certain part of a city as well as the type of inhabitants, categorised according to age, profession, etc. Although these data sources are currently still siloed in different urban domains, we expect that in the coming years, data spaces with marketplace functionalities will see the light which allow distributed access to datasets. Such data spaces would then handle the details of the value exchange (monetary or open) and would make sure that datasets can be trusted and are offered using common standards. We are already seeing the contours of such developments, for example within the Flemish "Datanutsbedrijf", which translates to “data-oriented utility companies” in English. Models With models, we refer to algorithms that add value to the datasets which are part of the Urban Digital Twin and that can be accessed to support cross-domain decisions. Raw data, as produced by e.g. an air quality sensor, is in it itself almost never enough as a basis on which to take decision. Models are necessary to enrich and transform the raw data to support urban decision making. Urban Digital Twins are premised on the idea that they should be able to grow with the city and in time incorporate new models as they are developed. The Urban Digital Twin should thus be extensible in terms of model integration. Furthermore, models need to be able to use each other's outputs. For example an air quality model that predicts air quality at certain locations at certain times, can greatly benefit from accessing the output of a traffic model that predicts the number and type of vehicles. Being able to interconnect these models and standardise their communication is a crucial part of the Urban Digital Twin research and development roadmap as we perceive it. In terms of model implementations, we distinguish between two types: process-centric and data-centric models. Process-centric models These are algorithms, built on human knowledge of real-world processes to make predictions based on data. This can for example be done for air quality, based on an understanding of how crucial parameters like wind, traffic intensity or the 3D layout of a city can influence the air quality at any particular location in the city. The advantage of such process-centric models is that they have been in development and use for decades and that many of them offer accurate results. Their main disadvantage is that they do not have the ability to learn when the real-world environments change, as shown by measured data. Each time a major change in the data emanating from the physical world occurs, the modelled processes need to be re-evaluated and if necessary adapted manually, which can be a long and costly process. Also, the initiative to make changes to the model lies with the human maintainers of the model, who are limited in their ability to grasp real world changes as they are reflected in the large data volumes that are produced by IoT sensor deployments in urban environments. To take into account all the relevant dimensions that are embedded in the data, machines are better suited than humans. Data-centric models With the surge in artificial intelligence research and development, data-centric models are becoming increasingly available. Such models learn from the data that is measured through IoT infrastructure that captures the real-time state of the city. As the amount of data that is produced by the IoT networks is often too large for any one person to comprehend, algorithms are necessary that can look at the data as it presents itself and learn from this data the patterns that are needed to improve urban decision making. An example of such an approach is not to build a physical model of air quality, but to measure air quality at a high number of locations in the city and then use an artificial intelligence algorithm to extrapolate to all locations in the city. Such a model knows next to nothing of the processes (wind, traffic, etc...) that influence air quality in an urban environment, but constantly learns patterns based on new incoming data. Data-centric models have the advantage that they can constantly learn from new and changing real-world conditions. Building models that incorporate the human knowledge from process-centric models and at the same time are flexible enough to update this knowledge based on new incoming data is a challenge when creating new Urban Digital Twin models. Brokers In order to interconnect various datasets and models, a broker is essential and constitutes the heart of the Urban Digital Twin. A broker is a software component on which data sources can publish data, while consumers of data can subscribe to certain types of data. As the amount of data that is being plugged into the Urban Digital Twin grows, the broker will have more and more data to deal with, which is why performance and scalability are prime concerns when designing and developing brokers. Also, the heterogeneity of dataset types is set to increase over the years, which is why semantics and standards are essential. Brokers are discussed in many different ways in the current Urban Digital Twin domain, which is why we make an attempt at disambiguating the topic in this section. Context broker A context broker is an element that was introduced by the FIWare foundation, to manage context data. Context data is a type of “data about data” or meta-data, which allows a better understanding of certain measurements. For example, a raw measurement of air quality is hard to understand, if it does not also include the time and exact location of when the measurement was performed. The main actor in the development of context broker technology in the EU is the FIWare foundation. The FIWare context broker specification has been incorporated in the Connecting Europe Facility initiative, which aims to provide EU countries with reusable building blocks to facilitate the building of digital services. Even though a context broker is important in IoT deployments to contextualise sensors data, the heart of an Urban Digital Twin requires a different type of broker, to which we refer as a data broker. Data broker The components within the red circle in the architecture on Figure 1 is what we refer to as a data broker. It does not store data, but collects data from different sources and allows it to be redistributed and understood by various consumers and producers of data. As a data broker is able to handle different types of data sources, a component is needed that allows these data sources to be findable, i.e. a data catalogue. In addition, a data broker needs to be able to make sure that the different data sources are understandable by other components. In order to allow the cross-domain decision making that is the central tenet of the Urban Digital Twin, various datasources and models need to be able to talk to each other. Just like human communication requires semantic alignment to make sure that concepts are understood in the same way between people, so does communication between machines. This is where the knowledge graph comes in, to provide metadata on the different constituents of each datasource. A knowledge graph is constructed of nodes and edges. Each node contains a concept and the edges describe the relationships between concepts. The types of nodes and edges that can be used in a knowledge graph are described in an ontology. An ontology is thus an abstract description of a knowledge graph. At the heart of the data broker is a message broker, also known as a message queue. This is a technology for managing large amounts if incoming data points and redistributing them as needed. Candidates for implementation of the message broker are technologies like Apache Kafka ( https://kafka.apache.org/ ) and systems that apply the OASIS MQTT messaging protocol ( https://mqtt.org/software/ ). Data brokers make datasets findable and accessible but it takes more to unlock the full potential of data, which is why we also need smart data management and governance. Smart Data management & governance A digital twin needs smart data management, to make the data interoperable and reusable. Smart data, according to Pieterson (2017) focusses on: Utility: the potential utility derived from the data Semantics: the semantic understanding of the data Data Quality: the quality of the data collected Security: the ways data are managed securely Data Protection: how privacy and confidentiality are guarded These are all key aspects to take into account when building Urban Digital Twins. For example, the quality of the data needs to be made explicit. One of the big risks of chaining models is that drift or inaccuracy in one element of the data value chain can lead to error-propagation. This would weaken the ability of an Urban Digital Twin to support accurate decision support. Trust (e.g. data protection) is also a key element to manage and the concept of "verifiable data organizations" is key. To address these concerns, the Urban Digital Twin should use tools and best practices, and align with the state-of-the-art on federated smart data platforms, like the Gaia-X (www.gaia-x.eu) initiative. In order to do so, smart data management and data governance principles should be put in place. Smart data management addresses activities such as schema versioning, data storage at scale (e.g. in data lakehouses), data discovery, publishing, metadata management, querying and data lineage. Data governance is the collection of agreements, processes and rules at the data level on how to maintain and operationally manage the data ecosystem with verifiable data organizations. Model management & governance Explicit model management is used to register models, chain their inputs and outputs, train Machine leaning based models in secure sandboxes and to define and register simulation scenarios. These functionalities require model management, service and process management techniques. Workflow and process orchestration are key challenges for the architecture. Context graph The context graph allows the different models that exist in the Urban Digital Twin to react to changes that are made by the end-user to the state representation of the city. When the end-user decides to change the properties of the city and want to understand the repercussions, a representation is needed that shows the new and the previous state of the city. Say for example, that the end-user wants to close a street to traffic and understand what this would mean to the air quality in the city: this would require a new traffic layout of the city to be published to the air quality model. The representation of the state of the city is handled by the context graph, while the publication of the changes is handled by the message broker. Microsoft has been one of the most active players in this field, with their Digital Twin Definition Language, which integrates with their Azure Digital Twins offering. Their approach has been to combine the ETSI Saref4City and the ETSI-CIM NGSI-LD ontologies and create a combined DTDL mapping with which context maps can be created. Figure 4: Microsoft DTDL mapping of ETSI-CIM NGSI-LD and ETSI Saref4City, cf https://github.com/Azure/opendigitaltwins-smartcities Standards As the value of an Urban Digital Twin lies in the interconnection of different datasets and algorithms, making sure that their interaction is standardised is key. This is both true at the level of the Application programming interfaces (API) and data models that are used by the various parts of the system as to the data models that are deployed. An API controls the ways in which different components can interact with each other in terms of actions and data. A data model organises data elements to represent properties of real-world entities in an information system, like e.g. how to represent the different parts of a street or a building. Choosing API's and data models that are widely used and supported by a large, relevant and vibrant community is key. There are quite a few components of an Urban Digital Twin and as a result, there are a considerable number of possible standards to look at. We will only discuss the standards that we have been using without aiming to provide an extensive review and comparison of the various relevant standards that are available. An important set of standards comes from the FIWare foundation. This European organisation has proposed the NGSI-LD standard API. It provides a REST API for getting access to IoT data. NGSI-LD provides guidance on how data can be described in terms of form (JSON-LD), while the FIWare data model provide commonly agreed upon ways to describe real-world measurements in terms of content. Many data model have already been described for the cities domain, which provides a relevant set of resources on which to build Urban Digital Twins.[Todo: further expand and discuss the list of used standards] Figure 3: Example NGSI-LD representation of a parking spot, using the ParkingSpot data model, cf https://fiware-datamodels.readthedocs.io/en/latest/Parking/ParkingSpot/doc/spec/index.html User Interfaces An often-made assumption is that the main added value of an Urban Digital Twin compared to the state-of-the art in urban IS resides in its user interface and/or the 3D models of the city that it shows. Our position is that this is not the case and that the bulk of the contribution of an Urban Digital Twin resides in the data sharing backend on which the user interface is built. Still, user interfaces for Urban Digital Twins are a challenge. Indeed, the main idea of an Urban Digital Twin is that it constitutes a platform in which gradually multiple datasources and models can be plugged-in to support cross-domain decision making. As we have detailed in the section on end-user types, various types of people are expected to work with the Urban Digital Twin, each with their own set of needs and expectations. As the user interface of the system is the main channel through which such needs and expectations are typically addressed, it means that the Urban Digital Twin user interface must be highly versatile. Public servants constitute the type of end-user that is most deeply specialised in the domain that they oversee. As a result, they are highly knowledgeable about the type of decisions that they need to take or support and therefore have a capability to wield user interface elements that are powerful, complex and that express concepts that require deep domain knowledge. Beside the public servants, city administrations also count what we have described as policy makers. These are individuals that are typically appointed by some form of democratic process or a derivative thereof and that remain in office for a shorter time than the public servants. Policy makers also want to understand the current state of the city and also need to be involved in decisions that pertain to their city. However, they are less deeply embedded in a specific domain, which means that providing them with deep and complex domain-specific user interfaces may limit their perceived usability of the Urban Digital Twin. Finally, citizens have an interest in understanding what is going on in their city and better understand the impact of decision that have been made. Using an Urban Digital Twin to make decision on the future state of the city is most often beyond the agency of individual citizens. Therefore, they should be provided user interface functionalities that are more about being informed of the impact of future decision, rather than to use the Urban Digital Twin to support decisions of their own. Overall, the different expectations and needs that exist towards the user interface of Urban Digital Twins remains one of the key challenges to address. In addition, the UI needs to be able to deal in a flexible way with the variety of current and future states that the city will reside in. This requires an event publication mechanism that used the semantic data in the context graph to allow the user interface to present the right type of information to each specific type of end-user. Actuators Actuators are here to be understood as non-human elements that can effect a change in the real-world. These can be rather “dumb”, like the streetlights in the city, or can have a limited degree of autonomous decision making capability, like an autonomous grocery delivery drone. Actuators require automated (as opposed to human) decision making to function properly. Such decision making can also use the datasets and models that are offered by the Urban Digital Twin. At the time of writing, the number of actuators that are active in cities is very limited. An often-discussed example are traffic lights that react to the state of the traffic that they regulate. However, R&D is actively ongoing at a global scale to introduce new types of actuators in cities, like autonomous vehicles (cars, trucks, barges, trains, trams, drones, …) that transport people and goods. We expect the number of Autonomous actuators that will populate our streets and that will benefit from the presence of an Urban Digital Twin to grow over the coming years.Actuators actuators can have a large positive impact, but can also be a hazard if not functioning correctly. In order to be certain that an automated actuator performs as expected, it can be trained and tested in a virtual simulated environment before it sets out in the real world. This simulation environments is a role which an Urban Digital Twin can play, besides providing researchers with access to clean, standardised and semantically annotated urban datasets. Figure 4: DHL parcel delivery drone, cf. https://en.wikipedia.org/wiki/Delivery_drone Digital Twin Composition The definition that we use of a Digital Twin, i.e. as a virtual representation of a physical object, can ultimately apply to many of the physical objects that exist in the real world. This means that over the years, many of the objects that surround us will have a Digital Twin that exists in the digital realm. As a result, Digital Twins can be composable in different ways. By this, we mean that a new Digital Twin can be built that uses the outputs of a number of other Digital Twins. For example, an Urban Digital Twin could build on the outputs of various other Digital Twins of physical objects, like trams, busses, buildings, street lights, etc. Therefore, a main area of investigation for the coming years lies in the interaction of Digital Twins. This is also the idea that is being followed by Cambridge University's Center for the Digital Built Britain (CDBB, https://www.cdbb.cam.ac.uk/DFTG/GeminiPrinciples ) and expressed by the FIWare foundation. Following such a Digital Twin composition approach would allow the creation of Digital Twins of an ever greater scale, as is also the objective of the EU's Destination Earth program ( https://ec.europa.eu/digital-single-market/en/destination-earth-destine ). Design principles Through design principles, we mean to discuss various aspects that are worth paying attention to when applying the architectural elements which we have discussed in the previous sections to create Urban Digital Twin instances. A first aspect to take into account is that a once-size-fits-all user interface that suits the needs of all Urban Digital Twin end-user is unlikely to be effective. Instead, user interfaces should be fit for purpose, aiming to strike a balance between power and simplicity that matches the needs of the end user. The various expectations that end users have towards the Urban Digital Twin is also reflected in the responsiveness of the models. Indeed, a trade-off often exists between accuracy of a model and the time it takes to compute. Both process centric and data-centric models can take a long time to compute, even on high-performance computing (HPC) infrastructure. Yet, not all end-user types require the highest degree of accuracy of models. Therefore, when integrating models in an Urban Digital Twin, model responsiveness is an important aspect to consider. To make sure that the lifecycle of the Urban Digital Twin is extended and therefore the investments that are made in its development can yield returns over many years, it is important to make the Urban Digital Twin as open as possible. With this, we mean technical openness, but also organisational openness. The Open Urban Digital Twin should make sure that various components can be integrated over the years, from a variety of organisational actors. This means great emphasis should go to standardising interaction between the various parts of the architecture, but also to make sure that the business models of the actors that contribute to the Open Urban Digital Twin are respected. This means working by default with open data, open source code and open knowledge, but also allowing proprietary contributions where needed. Finally, to allow an evolving set of functionalities of the Open Urban Digital Twin that supports decision making in the city as it evolves over time, the model architecture should be pluggable. By this, we mean that it should be possible to easily integrate new models and to replace operational models with new ones, with minimal effect on the other parts of the Open Urban Digital Twin. Urban Digital Twin maturity levels We see currently see 3 Urban Digital Twin maturity levels. Many cities have systems that are at level 1, and quite a few are moving towards level 2. Level 3 remains out of reach for most cities at the moment, yet is expected to become more prevalent in the near future. Level 1: data dashboard The first level Urban Digital Twin works with static or dynamic data sources and shows these data sources on a dashboard, using little to no modelling capabilities. This means that the data is presented in the Digital Twin dashboard mainly as it is being measured by the sensors that are deployed in the city. Level 2: model-based human decision support In this second maturity level, process-centric or data-centric models are deployed to increase the value of data sources to the decision making process. Different models can be operational in the Urban Digital Twin, provided by various actors. One models can use another model's output and models can be replaced by others without hindering the functioning of the Urban Digital Twin as a whole. Level 3: model-based human and automated decision support A final maturity level occurs when the Urban Digital Twins does not only support human decisions, but also allows automated decision support. The Urban Digital Twin is conductive to the training of new algorithms and the testing of their effectiveness, before the algorithms are deployed in the real world. In addition, the algorithms that are plugged in to the Urban Digital Twin can provide the necessary decision support basis to allow the functioning of advanced actuators. The Urban Digital Twin ecosystem The discussed architecture can not be delivered by one party alone. Its various constituting parts will be contributed by various actors. We now discuss some of the roles within the Open Urban Digital Twin ecosystem: cloud infrastructure providers, model providers, IoT stack providers, integrators and research institutes. Cloud infrastructure providers are the commercial actors that sell access to cloud services on which the various architectural components can run. Although there is no real reason why cities could not host their Urban Digital Twin "on premises", i.e. on physical servers which they administer themselves, the societal trend has for years clearly been to move to the cloud infrastructure of large US vendors like Amazon, Google and Microsoft. European alternatives like OVHCloud exist, but have less market share than non-EU vendors. Model providers are the companies that specialise in providing access to models in the specific domains that are important to cities (e.g air quality, mobility, sound and water). Many of these model providers currently sell models that come with their own user interface and that do not set out to read outputs from models in other domains or to allow models in other domains to use their outputs. Given a large uptake of Urban Digital Twins that follow specific standards that regulate model interaction, a market could be created in which such model vendors would be able to valorise API access to their models, valorising IP. IoT stack providers are the vendors, developers and maintainers of IoT infrastructure. They specialise in sensor deployments, their maintenance and the quality of their data outputs. Without their continued efforts, there can be no stable reliance on real-time IoT data. Integrators are the development parties that design and develop the various constituting parts of the architecture. They are responsible for making sure the overall Urban Digital Twin functionality is delivered to its end-users. Finally, research institutes are important to drive the innovation in many of the constituting parts of the Urban Digital Twin, as numerous research challenges still exist. A key challenge is in the modelling area. As more real-time sensing data becomes available from various sensors in the city, the possibility arises to create data centric models that constantly learn to improve decision support based on data as it emerges from the city. Machine learning approaches like neural network based supervised learning and reinforcement learning can be instrumental in breaking new modelling ground. Yet numerous other research challenges exist, in both the technological and the organisational context of Urban Digital Twins. Related initiatives Besides the above roles, we also would like to point to a number of highly related initiatives of which we are aware. European Union At the EU level, the objective of GAIA-X is to create a data sharing infrastructure that would stimulate the European economy and that would be built on European values, e.g. with regard to privacy and trust (von der Leyen, 2020). It aims to work on architectural specifications, development of open source components and certification, all geared towards the inception of trusted data sharing data spaces that allow the development of new applications. Open Urban Digital Twins are a prominent example of the type of application that could be facilitated through GAIA-X, as it builds on the data spaces that are coordinated by it. Open & Agile Smart Cities (OASC, oascities.org), is a highly relevant initiative, aiming to unite cities beyond country borders to build a global market for data-centric solutions and services. OASC has been working on the development of Minimum Interoperability Mechanisms (MIMs) that are essential to bringing about this market in the cities domain. Context information management (MIM1), Common Data Models (MIM2) and marketplace enablers (MIM3) pave the way for the adoption of Open Digital Twins by creating some of the building blocks that are essential to Urban Digital Twin deployments. The FIWare foundation has been referred to at various locations in this paper. It aims to encourage the adoption of open standards and open source technologies in various domains, among which cities. The acitivties of FIWare are highly relevant to the development and deployment of Open Urban Digital Twins in cities across the EU and beyond.The EU's Connecting Europe Facility (CEF) aims to boost European digital capabilities by providing a number of reusable digital building blocks that are common to many innovative information systems. CEF has made available a context broker component that can be of use when creating Urban Digital Twins. The context broker CEF building block can certainly be a part of most if not all of the Urban Digital Twin implementations that would be created by various municipalities throughout the EU, like the eID authentication and the EBSI blockchain building blocks. The European Commission itself will help build cities’ capacity to create their own, “AI-powered local digital twins”, specifically geared towards environmental and climate-related objectives, to help them better understand issues and trends and strengthen the evidence-based analytical capability of policy-makers at local level. In order to build their capacity, preparatory work is ongoing to identify examples from European cities, using Digital Twins for areas relevant to the environment and climate change and to explore how they could be replicated and what combination of generic tools could help in these efforts. In this context, a stakeholder webinar and a technology workshop were organised recently ( https://digital-strategy.ec.europa.eu/en/events/workshop-local-digital-twins-technology ). At the most recent Digital Day ( https://digital-trategy.ec.europa.eu/en/news/eu-countries-commit-leading-green-digital-transformation ), Member States have committed to ….’ work with local authorities and other relevant stakeholders to set up a European network of Digital Twins of the physical environment and support EU cities and regions to use green digital solutions in their transition to climate neutrality’. Flanders At the Flemish level, there is the "Datanutsbedrijf" or data utility company which has been commissioned by the Flemish Minister President (Legrand, 2020). The roadmap is currently being drafted and the exact specification are still unclear, but what it already known is that the core intent would be to stimulate the Flemish data economy by allowing more data sharing to occur. This is exactly the type of functionality that is needed for Urban Digital Twins to be able to fulfil their promise of cross-domain decision support. Another initiative that is currently running in Flanders is VLOCA project ( https://vloca.vlaanderen.be/ ), aiming to specify the "Vlaamse Open City Architectuur" together with a wide variety of stakeholders from the quadruple helix. The main objective of this project is to inform Flemish cities on how to avoid situation where their IoT infrastructures would become vendor locked in, without interoperability between stacks and cities, nor data sovereignty. Clearly, Open Urban Digital Twins needs to build on interoperable IoT stacks, which makes the VLOCA initiative highly relevant. Beyond the European Union Beyond the EU, Cambridge University's Center for the Built Digital Britain (CDBB) Digital Twin hub, is building up knowledge on how Digital Twins in the built are to be built and interconnected. The focus in this initiative is to connect Digital Twins among each other and to look at standards to do so. At a global level, we note the Digital Twin Consortium ( https://www.digitaltwinconsortium.org/ ), in which different types of Digital Twins are discussed, for example in health, aerospace engineering and infrastructure. The infrastructure work group is particularly relevant to Urban Digital Twins. Use Cases Given the above Urban Digital Twin scope, architecture and design principles, we now discuss a number of possible use cases in some of the domains that are top-of-mind in the cities that we have spoken with. Pandemics The Luxembourg Institute of Science and Technology (LIST) is leading an initiative regarding the deployment of a Nation-Wide Digital Twin (NWDT) in Luxembourg. The NWDT will serve as both a test-bed and living lab (1) for researchers associated with different research and innovation organizations in Luxembourg, (2) for private and public stakeholders (planners, designers and engineers) testing new products and services, (3) for policy makers using sandboxes to explore different scenarios and to assess the impact of different policies and of new regulatory instruments and (4) for citizens, who have to be fully empowered regarding their participatory governance and the privacy of their data.The COVID-19 pandemic offered an opportunity to illustrate the value of a Nation-Wide Digital Twin in a live real case. A “Cross-Functional COVID Dashboard” has been designed and implemented as a joint effort of Luxembourgish Institutions to give a comprehensive overview of the situation to researchers and stakeholders.This Luxembourgish Nation-Wide Digital Twin offers features (1) to access data, (2) to process data, (3) to visualise data with the goal (4) to support decision making. In the overall concept of the Cross-Functional COVID Dashboard, several verticals such as health, socio-economic impact and logistics have been identified with the domain experts from Luxembourgish Research Institutions and other national stakeholders. For decision-makers, the purpose was to give the broadest possible overview of an evolving situation that is very difficult to grasp due to its complexity. A specific challenge was to propose the appropriate level of granularity in the data displayed. For researchers, the dashboard helped to assess the quality of the various datasets, to connect the dots between different models and to assess the quality of model outputs to provide the best possible advice to the decision-makers. A key question to deal with concerned the availability and access to data. Depending on the specific facet of the pandemic under examination, different data sources would be required: (1) existing data produced in the past like socio-economic statistics, (2) data collected via surveys, (3) data produced by simulations based on models. The formats of these data sources proved to be very heterogeneous, and the technical means offered to access them were not all standardised. A decisive element to the success of this project has been the willingness and the commitment of the stakeholders to give access to the data they owned. The support of the decision-makers of the Research Luxembourg ecosystem (LIST, the Luxembourg Institute of Socio Economic Research LISER, the Luxembourg Institute of Health, LIH, and the University of Luxembourg) and beyond (e.g. Luxinnovation) played a key role in the Luxembourgish context. A progressive enrichment methodology was followed, starting with a few datasets that were available at the beginning of the crisis (e.g. number of available beds in hospitals) and progressively adding new datasets along the way as they became available. Thanks to the LISER research institute, the impact of the crisis on the global or sectorial GDP was modelled and estimated for several parameters such as the infection rate or the behaviour of cross-border commuters. These models allowed the design of multiple “what-if” scenarios. For instance, what if the cross-border flows are reduced or what if social interactions are restricted? More than 2,000 different scenarios were available for the interactive exploration of the socio-economic consequences of the pandemic. The Cross-Functional Dashboard is based on a common architecture, which is in turn based on LIST’s DEBORAH middleware to get the data from various sources and to display them on the various interconnected devices available in the LIST Command and Control Room, in particular the wall-sized display system nicknamed viswall (7 m x 2 m, +/- 50 Mio pixels, multi-touch) and interactive tables, as shown in Figure 3. The Cross-Functional dashboard is highly interactive and is particularly suited to support collective decision making in complex situations. The most appropriate visualisation and interaction techniques have been selected to best support the understanding of the ongoing situation as well as to support both researchers and decision-makers in their respective tasks. The latest version of the Cross-Functional Digital Twin Dashboard can display various types of charts illustrating collected data and simulation runs, interactive maps, 3D models of the city, live video streams, and live multimedia streams from social media. To sum up, the Cross-Functional COVID Urban Digital Twin Dashboard played an important role in raising awareness among national and international stakeholders about the relevance and the need of a Nation-Wide Digital Twin. It has also demonstrated the importance of the collaboration between research institutions and national stakeholders to deliver such a complex, cross-domain initiative. Cross-functional Urban Digital Twin dashboard developed by LIST Air Quality and traffic A use case which we have encountered in multiple cities in Flanders, is the impact of mobility on air quality. Flanders is a very densely populated area that sees a lot of movement of people and freight. As a result, certain Flemish cities are generally considered to have bad air quality due to car and truck traffic. Low Emission Zones have been installed in multiple urban regions, in which only vehicles that have certain specifications in terms of emissions can circulate. Additionally, circulation plans have been installed to change the way in which traffic moves through the city. However, there is a lack of decision support tools to understand what the impact of certain changes in urban circulation plans and Low Emission Zones will be on particulate matter or black carbon emission and thus on air quality. Models exist of both how changes in the traffic plan (max speed, traversal direction,...) will influence the amount of vehicles moving through it. Models are also available of how predicted traffic will influence air quality. Still, the traffic prediction models are not linked to the air quality prediction models. Therefore, an important use case in which work is ongoing is to make sure that the output of traffic models can serve as a basis for air quality models in the city of Bruges, in Flanders, Belgium. In 2018, a similar use case has already been deployed as a prototype in the city of Antwerp. It is important to note that the objective is to obtain a pluggable model architecture, in which an operational traffic model can be replaced by another one, while having minimal effect on the functioning of the air quality prediction model. These models can be provided by research organisations or commercial companies, can be process- or data-centric and can use real-time data or static data. A concern when integrating air quality models is the fact that they require a lot of computation and can run for hours or days even on High-performance computing (HPC) infrastructure, before results can be observed by end users. The more accurate the model needs to be, the longer the time it takes to compute, which requires a focus on both the fit-for-purposeness of the user interface (not all end-users require the highest accuracy level) and model responsiveness (not all end-users are willing to wait a long time for a response from the model). In terms of advances in traffic modeling which aligns with the notion of Urban Digital Twin, we refer to the Horizon 2020 Polivisu ( https://policyvisuals.eu ) and DUET ( https://www.digitalurbantwins.com ) projects. Urban Digital Twin User interface showing the impact of closing a street in Antwerp on air quality, developed for the second Urban Digital Twin prototype, developed in 2020-2021 Flooding and traffic As our climate changes, it is predicted that there will be more heavy rainfall during short times in specific areas, causing flash floods. These floods have a large influence on emergency responders, like police, fire department and ambulances. Indeed, floods that occur in streets and roads have a big impact on traffic circulation. Being able to predict such flash floods can be done hours in advance, based on meteorological radar data as well as data that describes the structure of the sewer system and the denivelations in the city, as available from GIS data. The output of this data can then be used to inform the way in which the traffic situation in the city is predicted to evolve in the coming e.g. 3 hours, which is of great value to emergency responders. Both types of models already exist and have been developed by multiple parties, yet the output of the flood prediction models are not connected to the traffic models, which is typically the work that needs to be done in the context of Urban Digital Twins and that will be the focus on the upcoming PRECINCT H2020 project. This project will build on a previous, Flemish funded project called “Flooding” in which the flood prediction models were developed, deployed and tested. Flood prediction model visualisation, developed as part of the Flooding VLAIO project ( https://www.imeccityofthings.be/en/projects/flooding-predicting-flood-levels ) Sound and traffic Noise pollution generated by traffic is an issue in many cities. This is true for different types of traffic, like cars, trucks, busses and trams. Understanding how changes to the traffic situation will influence the amount of noise pollution at street level can be supported by existing models, yet these are not coupled and can not work with different models from different vendors. Making sure that these models become pluggable in the Urban Digital Twin platform is therefore needed in order to allow them to be integrated in an Open Urban Digital Twin. Pandemics and people flows The COVID-19 pandemic has installed the need for cities to monitor and control the number of people that are present at specific locations. This is required to reduce contagion, as the virus will spread more easily in situations where many people are close to each other. Monitoring the location of people can be done by counting them manually, as is currently often done in many cities, to monitor the number of people in shopping streets. However, algorithms are available which can count the number of people in real-time. For example, mobile operator data is available that can indicate the number of people at a city block level. In addition, it is possible to get people counts based on aggregated Wifi MAC address data. Where these technologies could easily be made more accurate and numbers could be offered in a disaggregated and therefore less anonymous way, this would infringe on the privacy of the public and is therefore not an option. Still, data fusion algorithm are becoming available that can take a number of aggregated people flow data sources and refine them into more accurate people counts, while preserving privacy. This allows city decision makers to monitor the flow of people and if necessary take measures, based on a simulation of the result that would ensue after taking certain measures. Touristic optimalisation Touristic cities want to understand the spending behaviour of the tourists that visit the city and the provenance of the tourists. Such insights can provide the city with a fine-gained insight in the attractiveness of commercial real-estate in the city to certain tourists groups and the provenance of tourists in general. This can be done by combining cell tower data from mobile operators, with economic demographic provenance data and payment details from payment companies (Haeck, 2021). Both payment and mobile operator cell tower data are highly personal and sensitive and it is therefore absolutely crucial to make sure such use cases are deployed in an Urban Digital Twin with a high respect of citizen privacy, respecting all the legal bounds that apply. Conclusion We have aimed to better frame the concept of an Open Urban Digital Twin. We have explained that its main added value is to allow cross-domain decision making and that it can grow with the city to reflect its complexity and vitality. The architecture which we have developed based on ongoing research and implementation projects has been presented and we have explained the various parts of the architecture. We have discussed a number of design principles which can be taken into account when designing and implementing new Urban Digital Twins. Finally, we have have explained a number of Open Urban Digital Twin cross-domain decision support use cases which are important to various consulted cities. Whereas the presented cross-domain use cases are important, they are only examples that scratch the surface of what Open Urban Digital Twins are capable of. A more encompassing approach towards capturing city data and combining these data streams with ML applications will allow for more and more relevant use cases. The question now remains how Open Urban Digital Twins can be deployed in cities across the EU. This will require an investment program which recognises the complex ecosystem that is needed to realise and maintain Open Urban Digital Twins. Achieving this will necessitate, besides the technical challenges, an understanding of the business models that each actor in the Open Urban Digital Twin ecosystem, discussed above, utilise. References Alam, K. M., & El Saddik, A. (2017). C2PS: A digital twin architecture reference model for the cloud-based cyber-physical systems. IEEE access 5, 2050–2062 Legrand, R. (2020). Vlaams datanutsbedrijf moet uiteindelijk 100 procent privé worden, De Tijd, https://www.tijd.be/tech-media/technologie/vlaams-datanutsbedrijf-moet-uiteindelijk-100-procent-prive-worden/10267823.html Grieves, M., & Vickers, J. (2017). Digital twin: Mitigating unpredictable, undesirable emergent behavior in complex systems. Transdisciplinary perspectives on complex systems, 85–113. Springer. Haeck, P. (2021), Steden volgen bezoekers tot in hun portemonnee, https://www.tijd.be/ondernemen/technologie/steden-volgen-bezoekers-tot-in-hun-portemonnee/10292453.html Pieterson, W. (2017), Being smart with data, using innovative solutions, https://ec.europa.eu/social/BlobServlet?docId=17367&langId=en Tao, F., J. Cheng, Q. Qi, M. Zhang, H. Zhang, and F. Sui. (2018). Digital twin-driven product design, manufacturing and service with big data. The International Journal of Advanced Manufacturing Technology, 94(9-12), 3563–3576. von der Leyen, U. (2020), State of the Union Address by President von der Leyen at the European Parliament Plenary, https://ec.europa.eu/commission/presscorner/detail/en/SPEECH_20_1655 Zheng, Y., S. Yang, and H. Cheng. (2019). An application framework of digital twin and its case study. Journal of Ambient Intelligence and Humanized Computing, 10(3), 1141-1153. Raes L., Michiels P., Adolphi T., Tampere C., Dalianis T., Mcaleer S., Kogut P. (2021). DUET: A Framework for Building Secure and Trusted Digital Twins of Smart Cities, IEEE Internet Computing Lefever S., Michiels P., Van den Berg R. (2019) City of Things: An Open Smart City Vision and Architecture. https://www.imeccityofthings.be/drupal/sites/default/files/inline-files/open_city_vision_paper_final_0.pdf Lefever S., Michiels P., Buyle R. (2020) Building Urban Digital Twins. https://inspire.ec.europa.eu/sites/default/files/inspire2020_dt_philippemichiels_rafbuyle.pdf +
This is a property of type Text . The allowed values for this property are: Burgers Kennisinstellingen Overheden Industrie +
This is a property of type Text . The allowed values for this property are: Idee Proof of concept Project Voorstel tot architecturale standardisatie +
This is an example service to illustrate t … This is an example service to illustrate the Hoppin Punt Service information This page describes the information model for a service to be deployed on a HoppinPunt A service is defined by the following elements Identification A name for the service ServiceName mybike a Formal identifier ServiceIdentifier hp.gent.12 a version of the service Version 1.0 the service type type mobiliteit MobilityType fietse type type mobiliteit MobilityType fiets +
This is the "Add version history item" tem … This is the "Add version history item" template. It should be called in the following format: {{Add version history item|Type= (value options: minor, major) |Description= (text) note description might have comma's wrapped around it which should be filterd, e.g. ",Example description,"}} or {{subst:Add version history item|Type=major|Description=Example description}}=major |Description=Example description }} +
This is the "Alert" template. It should be called in the following format: {{Alert |yourmessagehere |Text=orlikethis |Type=danger/warning/info/success (default 'danger') |Fa icon=default 'exclamation-triangle' }} +
This is the "Class definition" template. I … This is the "Class definition" template. It should be called in the following format: {{Class definition|Defines class= (text) value that is used for Class property in content pages of this type|Pagetitle format= (value options: title, next_available) the wscreate in "Template:Create page form" will be based on this option, default "next_available"|Allowed namespaces= (optional: comma-separted namespaces) namespaces in which pages of this class are allowed to be created, e.g. "(Main), Project, Article"|Short description= (optional: text)|Has version history= (optional: true) if true, then {{Show version history}} will be added to generated sidebar template codelayout settings (used to order chameleon components)|Areas= (components) for example 'sidebar main'. Base csp components are: sidebar, sub-header, main|Columns= (size attribute of components) for example: 15em 2fr|Rows=storage templates|Base properties template= (optional: page) default "Template:Base properties"|Page properties template (optional: page) default "Template:{{{Defines class|}}} properties"component templates|Sidebar template= (optional: page) default "Template:{{{Defines class|}}} sidebar"|Sidebar form= (optional: page) no default|Sub header template= (optional: page) no default|Parameters= (multiple instance template){{Parameter definition |...|...}}{{Parameter definition |...|...}}}} Pagetitle formats: title will result in a pagetitle with format Class/title-entered-by-user such as Organization/wikibase-solutions next_available will result in a pagetitle with format Class/incremental_number such as Organization/1 Organization/2 Organization/3 etc. Different Chameleon components can be ordered for different page classes Base csp components are: sidebar, sub-header, main They are defined in the Chameleon skin XML and the default values are set in layout.css You can define different layouts on the Areas parameter, see grid-template-areas for syntax You can define sizes for the columns and rows for this layout, see grid-template-columns and grid-template-rows for syntax Example The example below creates to rows on all pages with the Article class The first row holds the Sidebar and the Sub-header components the Sidebar is set to be 15em wide and the Sub-header is set to 1 fraction, the hieght of this row is set to Auto The second row holds the Main content component it spans over two columns the height of this row is set to 1 fraction {{Class definition|Defines class=Article|Areas='sidebar sub-header' 'main main'|Columns=15em 2fr|Rows=auto 1fr}} main' |Columns=15em 2fr |Rows=auto 1fr }} +
This is the "Create page form" template. I … This is the "Create page form" template.It should be called in the following format: {{Create page form|Class options= <text, can be multiple with sep ","> classes that can be selected in the form. If only 1 class is entered, then no select field is shown. Example: "Article, Organization"}} Please log in first.cle, Organization" }} Please log in first. +
This is the "Generate page properties temp … This is the "Generate page properties template code" template. It should be called in the following format: {{Generate page properties template code|Class= (text) class for which a "Class definition" page exists}} Test Some use of " " in your query was not closed by a matching " ". <noinclude>This is the '''''' template. It should be called in the following format:<pre>{{}}</pre></noinclude><includeonly>{{#set:}}</includeonly>/pre> </noinclude><includeonly>{{#set: }}</includeonly> +
This is the "Generate sidebar template cod … This is the "Generate sidebar template code" template. It should be called in the following format: {{Generate sidebar template code|Class= (text) class for which a "Class definition" page exists|Has version history= (optional: true) if true, then {{Show version history}} will be added to generated sidebar template code}} Test Some use of " " in your query was not closed by a matching " ". Some use of " " in your query was not closed by a matching " ". <noinclude>This is the '''''' template. It should be called in the following format:<pre>{{}}</pre></noinclude><includeonly>{{#vardefine:@allow sidebar edit |{{#ifingroup:user |{{#if:{{#urlget:veaction}}{{#urlget:action}}||yes}} }} }}<div class="tab-content">{{#tag:_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:{{#var:@allow sidebar edit}} |yes |{{#tag:label|Edit|for=sidebar-edit|class=btn btn-secondary}}}}{{#caprint:$base[Base properties][Class]}}{{#caprint:$base[Base properties][Title]}}</div><div class="card-body"></div></div>{{#ifeq:{{#var:@allow sidebar edit}} |yes |{{#tag:_input||type=radio|id=sidebar-edit|name=toggle-sidebar|class=d-none sidebar-edit}}<div class="card sidebar-edit-tab"><form action="addToWiki">{{#if:{{#casize:$class}}||<_create mwwrite="{{FULLPAGENAME}}" mwtemplate="" mwslot="ws-class-props" mwfields="" />}}<div class="card-header">{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}{{#caprint:$base[Base properties][Class]}}{{#caprint:$base[Base properties][Title]}}</div><div class="card-body"><div class="text-right">{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}<input type="submit" value="Save" class="btn btn-primary" /></div></div></form></div>|}}</div></includeonly>Close|for=sidebar-view|class=btn btn-secondary}} <input type="submit" value="Save" class="btn btn-primary" /> </div> </div> </form> </div> |}} </div></includeonly> +
This is the "Initiatief" template. It shou … This is the "Initiatief" template.It should be called in the following format: {{Request|field_request_status=|field_initiatiefnaam=|field_maturiteitstype=|field_domein=|field_sleutelwoord=|field_locatie=|field_actoren=|field_partners=|field_traject=}} Edit the page to see the template text. Edit the page to see the template text. +
This is the "Layout" template. It should be called in the following format: {{#widget:Layout |rows= |columns= |areas= |display= }} Widget for css layout block +
This is the "Layout" template. It should be called in the following format: {{Layout}} It genarates CSS for grid layout based on the class of the current page +
This is the "Parameter definition" templat … This is the "Parameter definition" template. It is used as multiple-instance template in Template:Class definition . It should be called in the following format: {{Parameter definition|Name= (text) name of the parameter|Property name= (optional: text) use this when you want to set a different property name than the parameter name|Required= (optional: true) use this when the form field for this parameter should have the required attribute|Multiple= (optional: true) use when the parameter can have multiple values (both for the property and formfield)|Formfield type= (optional: value options "text", "textarea", "date", "number", "checkbox", "select", "token", "ask token") defaults to "text"|Allowed values= (optional: comma-separated values or (for ask token) SMW query with round brackets) only for field types "checkbox", "select", "token", "ask token". Examples: "Applied, Notified, Reported" or "((Class::Work instruction))?Title"|Sorting number= (optional: number) for sort order in default properties and sidebar template code|Slot= (optional: value options "ws-class-props", "ws-base-props") defaults to "ws-class-props". }}-props") defaults to "ws-class-props". }} +
This is the "Sidebar item" template. It should be called in the following format: {{Sidebar item |Label= (text) |Value= (text) }} Test Test label Test value +
This is the "Vloca default sidebar" template. It should be called in the following format: {{Vloca default sidebar |$pageData=... (arrayfunctions export) |$classData=... (arrayfunctions export) }} +
This is the Application page properties template. It should be called in the following format: {{Application page properties |Type= (optional: text) value options: CSP Basis Core, CSP Basis Examples |Origin= (optional: text) }} +
This is the Application page sidebar template. It should be called in the following format: {{Application page sidebar}} +
This is the Application page subheader tem … This is the Application page subheader template. It should be called in the following format: {{Application page subheader|$pageData= (Arrayfunctions export) slotdata of current page|$classData= (Arrayfunctions export) class definition data (if current page and related class definition have a class in ws-base-props)}}finition have a class in ws-base-props) }} +
This is the Class definition form template. It should be called in the following format: {{Class definition form }} Test Please log in first. +