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

• Organisatie 3  +
• Organisatie2  +
• Page  +
• Pagina is in aanmaak  +
• Parkeerarchitectuur  +
• Pitch ORDP and Data visualisation  +
• PostGIS [1] ↑ https://en.wikipedia.org/wiki/PostGIS  +
• Postgres [1] ↑ https://en.wikipedia.org/wiki/PostgreSQL  +
• Presentatie VLOCA mobiliteit WS3  +
• Processen  +
• Processen2  +
• Prototype  +
• Pub sub vs request response  +
• RACI  +
• RACI 2  +
• Registreer  +
• Registreer Registreer  +
• Relational database https://en.wikipedia.org/wiki/Relational_database  +
• Repair pogingen per product categorie  +
• Repair problemen  +
• Revolt slide 1Revolt slide 1 wg 1  +
• Organisaties A ABB ADV AQUAFIN A … Organisaties </br> A ABB ADV AQUAFIN AWV Agoria Alliance for Internet of Things Innovation Anyways G Gemeente Boechout Gemeente Edegem Gemeente Geetbets Gemeente Herent Gemeente Ingelmunster Gemeente Kampenhout Gemeente Lubbeek Gemeente Oostkamp Gemeente Pelt Gemeente Pepingen Gemeente Puurs-Sint-Amands Gemeente Tremelo Gemeente Zaventem GeoNovum Gothenburg - Digital Tvilling Geraardsbergen C CEN/TC465 Canada-OpenNorth Center for Digital Twin Britain Coock Open Stad D DS- Deense standaarden De Lijn Denmark IoT and Smart Cities Destination Earth Digital Europe Programme Digital Twin Consortium E E-Hubs Economisch Huis Oostende Europa - Digital Single Market European Committee for Standardization (CEN) E meer European Interoperability Framework (EIF) Europees Telecommunicatie en Standaardisatie Instituut (ETSI) F FIWARE Finland - Digital Twin H Hydroscan I IDSA IGEMO IMEC INSPIRE IOK (Intercommunale Ontwikkelingsmaatschappij voor de Kempen) Indian Urban Data Exchange (IUDX) J Japan Cross-Ministerial IPP K Kenniscentrum Vlaamse Steden (KCVS) L LUCA school of Arts Leiedal Luxembourg Institute of Science and Technology M MOW MaaS Afsprakenkader MaaS Alliance Mobiliteit en Parkeren Antwerpen Mobiliteitscentrale Mobipunt VZW S Stad Mechelen SKR- Zweedse Vereniging van Lokale Overheden en Regios SOLVA Slimme Regio Vlaanderen Stad Aalst Stad Antwerpen Stad Bonheiden Stad Brugge Stad Dendermonde Stad Geel Stad Genk Stad Gent Stad Halle Stad Harelbeke Stad Hasselt S meer Stad Kortrijk Stad Leuven Stad Mortsel Stad Oostende Stad Peer Stad Roeselare Stad Sint-Niklaas Stad Tongeren Stad Turnhout Stad Vilvoorde Synchronicity N NMBS O OASC OSLO Open Geospatial Consortium (OGC) Open Smart Cities of India (OSCI) P PROVANT PWC Proefstation voor Groententeelt Provincie Antwerpen Provincie Oost-Vlaanderen Provincie Vlaams-Brabant Provincie West-Vlaanderen T TM Forum U UHasselt V V-ICT-OR VERA VITO VLAIO VLAKWA VMM Velopark.be VlaVirGem W Waterland Wellington - Digital Twin Werfwater World Economic Forumal Twin Werfwater World Economic Forum  +
• Overzicht VLOCA-werkgroepen Werkgroepen … Overzicht VLOCA-werkgroepen </br> Werkgroepen VLOCA Traject Type werkgroep Circulaire Economie: Repair cafés - Workshop 1 Circulaire economie: Repair cafés Business werkgroep Circulaire Economie: Repair cafés - Workshop 2 Circulaire economie: Repair cafés Data en informatie werkgroep Data Broker Workshop 1 Data Broker Business werkgroep Data Broker Workshop 2 Data Broker Functionele werkgroep Hoppinpunten Workshop 1: Behoeftes & doelstellingen Combimobiliteit: Hoppin punten Data en informatie werkgroep Hoppinpunten Workshop 2: Data Combimobiliteit: Hoppin punten Data en informatie werkgroep Hoppinpunten Workshop 3: Details Combimobiliteit: Hoppin punten Data en informatie werkgroep Local Digital Twin Workshop 1: Gedeeld referentiekader Local Digital Twin Business werkgroep Local Digital Twin Workshop 2: Structuur en beheer van data Local Digital Twin Data en informatie werkgroep Local Digital Twin Workshop 3: Simulaties op basis van modelering Local Digital Twin Functionele werkgroep Business werkgroep Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) Business werkgroep Thematische werkgroep 3 Mobiliteitsbudget voor burgers Technologie werkgroep Thematische werkgroep 1 Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) Data en informatie werkgroep Thematische werkgroep 2 Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) Functionele werkgroep Thematische werkgroep 3 Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) Technologie werkgroep Thematische werkgroep 1 Het potentieel van urban mining & BIM voor de bouwsector Data en informatie werkgroep Thematische werkgroep 2 Het potentieel van urban mining & BIM voor de bouwsector Functionele werkgroep Thematische werkgroep 3 Het potentieel van urban mining & BIM voor de bouwsector Technologie werkgroep Business werkgroep Het potentieel van urban mining & BIM voor de bouwsector Business werkgroep Business werkgroep Regionaal plugable incentiveringsplatform Business werkgroep Thematische werkgroep 1 VlocaTraject/DAKS 2.0/ Lokale economie,VlocaTraject/SInCR - Lokale economie Data en informatie werkgroep Thematische werkgroep 1 Slim Ruimtelijk Plannen Data en informatie werkgroep Thematische werkgroep 1 Vrachtwagenparkeren Data en informatie werkgroep Thematische werkgroep 2 VlocaTraject/DAKS 2.0/ Lokale economie,VlocaTraject/SInCR - Lokale economie Functionele werkgroep Business werkgroep Slimme stadsdistributie Business werkgroep Thematische werkgroep 2 Slim Ruimtelijk Plannen Functionele werkgroep Thematische werkgroep 2 Vrachtwagenparkeren Functionele werkgroep Thematische werkgroep 3 VlocaTraject/DAKS 2.0/ Lokale economie,VlocaTraject/SInCR - Lokale economie Technologie werkgroep Thematische werkgroep 3 Slim Ruimtelijk Plannen Technologie werkgroep Business werkgroep Vrachtwagenparkeren Business werkgroep Business werkgroep Slim Ruimtelijk Plannen Business werkgroep Business werkgroep VlocaTraject/DAKS 2.0/ Lokale economie,VlocaTraject/SInCR - Lokale economie Business werkgroep Thematische werkgroep 3 Vrachtwagenparkeren Technologie werkgroep Thematische werkgroep 1 Welkomapp voor nieuwkomers Data en informatie werkgroep Business werkgroep Citerra Business werkgroep Thematische werkgroep 1 Citerra Data en informatie werkgroep Thematische werkgroep 2 Citerra Functionele werkgroep Thematische werkgroep 3 Citerra Technologie werkgroep Thematische werkgroep 1 Machine Learning as a Service (MLaaS) Data en informatie werkgroep Thematische werkgroep 2 Machine Learning as a Service (MLaaS) Technologie werkgroep Thematische werkgroep 3 Machine Learning as a Service (MLaaS) Technologie werkgroep Thematische werkgroep 1 Slimme stadsdistributie Data en informatie werkgroep Business werkgroep REVOLT Business werkgroep Business werkgroep ThermAi Business werkgroep Business werkgroep Slimme Markten Business werkgroep Business werkgroep SHOK Business werkgroep Thematische werkgroep 1 SHOK Data en informatie werkgroep Thematische werkgroep 1 Slimme Markten Data en informatie werkgroep Thematische werkgroep 1 ThermAi Data en informatie werkgroep Thematische werkgroep 1 REVOLT Data en informatie werkgroep Thematische werkgroep 2 REVOLT Functionele werkgroep Thematische werkgroep 2 SHOK Functionele werkgroep Thematische werkgroep 2 Slimme stadsdistributie Functionele werkgroep Thematische werkgroep 2 Slimme Markten Functionele werkgroep Thematische werkgroep 2 ThermAi Functionele werkgroep Thematische werkgroep 3 SHOK Technologie werkgroep Thematische werkgroep 3 Slimme Markten Technologie werkgroep Thematische werkgroep 3 ThermAi Technologie werkgroep Thematische werkgroep 3 REVOLT Technologie werkgroep Business werkgroep Modderstroom Monitoring Business werkgroep Thematische werkgroep 1 Modderstroom Monitoring Data en informatie werkgroep Thematische werkgroep 2 Modderstroom Monitoring Functionele werkgroep Thematische werkgroep 3 Modderstroom Monitoring Technologie werkgroep Thematische werkgroep 3 Slimme stadsdistributie Technologie werkgroep Thematische werkgroep 1 Mobiliteitsbudget voor burgers Data en informatie werkgroep Thematische werkgroep 2 Mobiliteitsbudget voor burgers Functionele werkgroep Kick-off Digitale meldingen Business werkgroep Thematische werkgroep 3 Mobiliteitsbudget voor burgers Technologie werkgroep Business werkgroep Digitale meldingen Business werkgroep Functionele werkgroep Digitale meldingen Functionele werkgroep Applicatie componenten werkgroep Functionele werkgroep Aanpak en risico's werkgroep Digitale meldingen Data en informatie werkgroep Thematische werkgroep 1 Mobiliteitsbudget voor burgers Data en informatie werkgroep Functionaliteiten werkgroep Digitale meldingen Functionele werkgroep Applicatie componenten werkgroep Digitale meldingen Functionele werkgroep Aanpak en risico's werkgroep Digitale meldingen Functionele werkgroep Thematische werkgroep 2 Mobiliteitsbudget voor burgers Functionele werkgroep Water in de stad Workshop 1 Leefomgeving: Water in de Stad Business werkgroep Water in de stad Workshop 2 Leefomgeving: Water in de Stad Data en informatie werkgroep Water in de stad Workshop 3 Leefomgeving: Water in de Stad Technologie werkgroep </br> Werkgroepen VlocaSessie API-led Antwerp Living Labs: levendige en leefbare (universiteits)buurt B-WaterSmart Burgerloket Circulaire economie: Repair cafés Combimobiliteit: Hoppin punten DINA: Dienstverlening via integratie naadloos aanbieden Data Broker Datagestuurde handelskern DenCITY Digitalisering volledige customer journey parkeren en GAS4 en GAS5 Flood4Cast Het potentieel van urban mining & BIM voor de bouwsector Hydrologisch meetnet provincie Antwerpen Internet of Water Iot-gestuurde mobipunten Koppeling IoT-peilsensordata naar andere IoT- stacks Leefomgeving: Water in de Stad Local Digital Twin Lokaal digitaal ondernemingsloket Lokale Open Data Economie (LODE) Maatgerichte implementatie van een document management systeem Machine Learning as a Service (MLaaS) Mobiele Sensor Units Mobiliteitsbudget voor burgers Monitoring van de Laak Nachtlawaai verminderen d.m.v. technologie en nudging Online Reserveren en Betalen: type locatie in de stad PROBE Preventieve gezondheid Preventieve gezondheidszorg: persoonlijke gezondheidsdata en lokale overheden Proactive Flooding Detection Rainbrain Regionaal plugable incentiveringsplatform Sensorhotels Slimme Markten Slimme stadsdistributie Smart Innovation Factory Smart Waterland Sociaal Dossier Platform Stiemerlab Tijd- en plaatsonafhankelijke klantencontacten Tipping Points Transparante efficiënte en klantvriendelijke dienstverlening voor onze burgers verenigingen en ondernemingen Urban digital twin Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) Velopark Vertellende vlotten Citerra DAKS 2.0/ Lokale economie Data gedreven beleidsondersteuning Digitale meldingen EMS DOE - Energie Management Systeem Modderstroom Monitoring REVOLT SHOK SInCR - Lokale economie Slim Ruimtelijk Plannen ThermAi Vrachtwagenparkeren Welkomapp voor nieuwkomers WerfWaterr nieuwkomers WerfWater  +
• Overzicht van alle standaarden   Behere … Overzicht van alle standaarden </br>   Beherende organisaties Volgende organisaties Smart City Domeinen Smart City Componenten 3D tiles Augmented Reality Markup Language 2.0 (ARML20.0) CityGML Datex GeoJSON GeoRSS Geography Markup Language (GML) IMKL INSPIRE-data-standaard Smart Environment Water LDES NEN Open Urban Platform NGSI (LD) NGSI-v2 OGC API - Features OGC Catalogue Service OGC Coordinate Transformation Service OGC Publish/Subscribe Interface Standard OGC SensorThings API OGC WaterML 2 SWE Common Data Model Encoding Standard SWE Service Model Implementation Standard Semantic Sensor Network (SSN) Ontology Sensor Model Language (SensorML) Sensor Observation Service Sensor Planning Service (SPS) Simple Features (SFS) Smart Data Models Thematische werkgroep 4 Smart Government TOMP-API Time Series Model Language (TSML) W3C Web of Things Web Coverage Service (WCS) Web Feature Service (WFS) Web Map Service (WMS) Web Map Tile Service (WMTS)MS) Web Map Tile Service (WMTS)  +
• Page ID Page title Page hits 36 … Page ID</br> </br> Page title</br> </br> Page hits</br> </br> </br> 3677</br> </br> Welkom bij de Vlaamse Open City Architectuur (VLOCA) Kennishub</br> </br> 19291</br> </br></br> </br> 1653</br> </br> Bestand:2021-03-23-COOCK-AQ-Workshop-II.pdf</br> </br> 3802</br> </br></br> </br> 1652</br> </br> Bestand:2021-03-09-COOCK-AQ-Workshop-SlideDeck FINAL.pdf</br> </br> 2867</br> </br></br> </br> 1701</br> </br> Bestand:Circulaire Economie Workshop 2 0.pdf</br> </br> 2814</br> </br></br> </br> 1697</br> </br> Bestand:COOCK SMIT BuildingTrustandValue(60089).pdf</br> </br> 2525</br> </br></br> </br> 1657</br> </br> Bestand:2021-04-27-Coock-Learnings.pdf</br> </br> 2508</br> </br></br> </br> 1658</br> </br> Bestand:2021-05-04 VITO airQmap final.pdf</br> </br> 1970</br> </br></br> </br> 1654</br> </br> Bestand:2021-04-20-COOCK-IAQ-Workshop-IMEC-NL.pdf</br> </br> 1965-20-COOCK-IAQ-Workshop-IMEC-NL.pdf 1965  +
• Pagediscussions Op de kennishub is het m … Pagediscussions </br> Op de kennishub is het mogelijk om voor (bijna) elke pagina een discussion page te gebruiken.</br>Een discussion page laat ingelogde gebruikers toe om vragen te stellen en feedback te geven over de inhoud van de pagina.</br> </br> </br> Deze functionaliteit is nog niet actief. Bij activatie van deze pagina's zal de toelichting op deze pagina worden aangevuld.elichting op deze pagina worden aangevuld.  +
• Pagina's die alle gebruikers kunnen aanpas … Pagina's die alle gebruikers kunnen aanpassen </br> Op de kennishub vind je verschillende types pagina's terug.</br>Volgende type pagina's zijn open voor bijdrage voor alle ingelogde gebruikers:</br> </br> Initiatieven : alle (smart city) initiatieven die inspireren, informeren of aanzetten tot actie </br> Organisaties : (lokale) overheden, private spelers, burgerparticipaties, ... </br> Standaarden : architectuurstandaarden </br> Termen en concepten : Termen,, concepten en andere begrippen </br> Page discussions </br> Naast pagina's actief aanpassen, is het ook mogelijk aan de hand van page discussions vragen te stellen en feedback te geven over de inhoud van pagina's.</br> </br> Actieve oproep: pagina's in review </br> Deze functie is in uitwerking.</br>Een overzicht van pagina's die actief aangevuld en gereviewed worden door de community zal hier verschijnen.</br> </br> Governance </br> De governance rond pagina's bewerken en regels rond de discussion pages vind je hier terug.nd de discussion pages vind je hier terug.  +
• Parameters {{Modal |Targetid= <id> … Parameters </br> {{Modal</br>|Targetid= <id> of the modal div, also used for the button that links to it. e.g. "myModal", "myModal1", "myModal2"</br>|ButtonText= <text> text for button that links to modal </br>|ButtonClass= <class> class for button that links to modal. defaults to btn btn-success btn-sm</br>|TargetClass=defaults to modal fade</br>|Show modal header= <optional: "No"> to hide the modal header (default Yes)</br>|ModalHeading=</br>|BodyClass=defaults to modal-body</br>|BodyText=</br>|FooterText=</br>|VisitPage=</br>|contentstyle=add class and/or style (default: class="modal-content")</br>|width=</br>|Hide link=<optional: "Yes"> if you do not want this template to generate a link to your modal</br>}}</br> </br> test </br> This is a sick modal m8 </br> </br> </br> </br> </br> You've clicked me </br> </br> </br> Thanks for doing so!</br> </br> </br> Some button </br> </br> </br> </br> Example modal with custom Link : </br> </br> </br> </br> </br> </br> My modal header </br> </br> </br> text fdfsafs afsfas sdfsd</br> </br> </br> Footertext with close button! X </br> </br> </br> </br> {{#widget:Button link |href=#test-modal |datatoggle=modal |class=btn btn-primary |buttontext=Link}}</br></br>{{Modal</br>|Targetid=test-modal</br>|ModalHeading=My modal header</br>|BodyText=text fdfsafs</br>afsfas</br>sdfsd</br>|FooterText=Footertext with close button! {{#widget:Button link |type=a |href=#test-modal |datatoggle=modal |class=btn btn-default |buttontext=X}}</br>|Hide link=Yes</br>}}atatoggle=modal |class=btn btn-default |buttontext=X}} |Hide link=Yes }}  +
• Please pass a url parameter 'page' to this page to display the slots for that page. eg. /Wiki:Slots?page=Main Page  +
• Presentatie Presentatie VLOCA traject m … Presentatie </br> Presentatie VLOCA traject mobiliteit Workshop 2: Data </br> Resultaten Mentimeter Stemmingen </br> Attendance List </br> Nils Walravens (imec) </br> Stefan Lefever (imec) </br> Erwin Hermans (MOW) </br> Pieter Morlion (Fietsberaad) </br> Eli Nomes (Leuven) </br> Bart Scheenaerts (ABB) </br> Tjalle Groen (Taxistop) </br> Wouter Luyckx (Arcadis) </br> Ziggy Vanlishout (AIV) </br> Guido Vaganee (VVSG) </br> Paul Theyskens (MOW) </br> Dimitri Schepers (AIV) </br> Bruno Herman (imec) </br> Pieter Dresselaers (Igemo) </br> Gert Vervaet (Geosparc) </br> Ewout Depauw (SOLVA) </br> Philippe Michiels (imec) </br> Mathias Van Compernolle (imec) </br> Anne-Marie Van Asbroeck (imec) </br> Koen Triangle (imec) </br> Bart Verbeeck (Cegeka) </br> Wim Michiels (ANYWAYS) </br> Annelies De Craene (AIV) </br> Emilie Couwenberg (Stad Antwerpen) </br> Rik Hendrix (VITO) </br> Rob Van den Berg (imec) </br> Gert De Tant (Sirus) </br> Natasha Blommaert (AWV) </br> Introductie </br> Herhaling van de VLOCA-doelstellingen & Hoe bij te dragen .</br> </br> Toelichting AIV Relanceplan: Relanceproject MAAS </br> Door Annelies De Craene (AIV).</br>Doelstellingen:</br> </br> Realiseren we open & interoperabele mobiliteitsdatastromen voor multiple hergebruik: routes, haltes, real-time locatie voertuigen, dienstregeling via het sensor data platform --> datastromen aanbodzijde maas voor multiple hergebruik door Mobiliteitscentrale, Hoppin/Mobipunten, Lokale besturen, etc. </br> Een nieuwe mobiliteitstroom van cameragegevens op (ANPR – Automatic Number Plate Recognition) aangesloten op het sensor data platform. Op deze manier komen ANPR-data geanonimiseerd ter beschikking voor de ontwikkeling van toepassingen. </br> Gepersonaliseerde mobiliteitsdata door een referentie implementatie voor de use case 'mymobility profile' op te zetten. </br> Momenteel nota in opmaak voor de Vlaamse Regering.</br> </br> Toelichting OSLO en VLOCA </br> Door Dimitri Schepers (AIV)</br> Raakvlakken tussen OSLO en VLOCA-traject mobiliteit:</br> </br> Betrokkenheid OSLO in VLOCA-traject vanwege synergie, </br> maar ook teneinde dubbel werk te voorkomen</br> </br> Raakvlakken met reeds bestaande OSLO-trajecten:</br> OSLO Mobiliteit</br> Trips en Aanbod </br> Dienstregeling (in ontwikkeling) </br> Fietsinfrastructuur (nog op te starten) </br> Mobipunten (wordt bekeken) </br> OSLO Openbaar Domein </br> Agentschap Wegen & Verkeer Object Type Library (OTL) </br> Synergie tussen OSLO en VLOCA</br> </br> Van OSLO naar VLOCA</br> Aanreiken van bestaande datastandaarden die ondergebracht kunnen worden in VLOCA </br> Van VLOCA naar OSLO</br> Identificeren van noden voor het ontwikkelen van data standaarden </br> Toelichting data-attributen </br> Door Stefan Lefever (imec-edit).</br> De verschillende relevante data-attributes die in de workshop gebruikt werden, zijn toegelicht en op de bijgevoegde slides terug te vinden.</br> </br> Breakouts </br> Doel van de breakouts:</br> </br> Beter begrijpen wanneer welk type data belangrijk is. </br> Beter begrijpen welke data-attributen belangrijk zijn. </br> De uitdagingen hierrond goed capteren. </br> Lessen trekken naar wat dit betekent voor architectuur en infrastructuur. </br> (de volgende workshop) </br> Input uit de vorige workshop:</br> </br> Alle ideaalbeelden en gekoppelde data werden bij elkaar gebracht om tot drie algemene use cases te komen die tijdens de breakouts verder uitgediept werden: </br> Als (medewerker van) een lokaal bestuur, heb ik relevante data nodig om het gebruik van een hoppinpunt te evalueren. </br> Als dienstverlener/operator, wil ik aan de hand van data in de buurt/aan een hoppinpunt een nieuwe dienst aanbieden voor reizigers. </br> Als reiziger, wil ik de hoppinzuil gebruiker om een vervoersmiddel te boeken en te betalen voor mijn reis. </br> Voor elke use case werden volgende stappen doorlopen:</br> </br> Prioriteren welke soorten van data meest belangrijk zijn </br> Welke data-attributen meest belangrijk zijn </br> Bespreken waarom dit zo is en wat dat betekent voor architectuur en infrastructuur </br> Dit in 2 rondes van 30min en gebruik makend van mentimeter als ondersteunende tool.</br>De resultaten van de mentimeter stemmingen kan je | hier raadplegen.</br> </br>Onderstaande geeft per use case weer welke de belangrijkste datasets bleken en hoe belangrijk bepaalde data-attributen zijn. Er wordt een samenvatting gegeven van het gesprek, per data-attribuut dat besproken werd in de sessie.</br> </br> Use case 1: Evaluatie van een hoppinpunt </br> Als (medewerker van) een lokaal bestuur, heb ik relevante data nodig om het gebruik van een hoppinpunt te evalueren.</br> In deze breakout werden in eerste instantie de datatypes “Aantal passanten”; “Gebruikersprofielen” en “Afgelegde trajecten en overstappen” besproken.</br> </br> Aantal passanten </br> Volume:</br> Big data is belangrijk voor fit-for-purpose oplossingen. </br> Open data is een vereiste. </br> Ownership:</br> Verantwoordelijkheid voor aanleveren data </br> Semantics:</br> Geen standaardisatie beschikbaar </br> Quality:</br> Nauwkeurigheid tellingen passanten is vandaag niet voldoende </br> Hoe kan de data relevant gemaakt worden? </br> Gebruikersprofielen </br> Protection:</br> Bv. Medische gegevens </br> Beschermen privacygegevens </br> Moet op hoger niveau behandeld worden (maas) </br> Security:</br> Impliciet gezien vertrouwelijke data </br> Ownership:</br> Gevoelig informatie </br> Maas afsprakenkader in ict </br> Middle man om ownership te regelen </br> Afgelegde trajecten en overstappen </br> Volume:</br> Trusted party nodig voor opslag? </br> Variety:</br> Veel verschillende formaten en diverse bronnen </br> Connecties tussen mobi-punten </br> Goed catalogiseren </br> Densiteit </br> Semantics:</br> Densiteit moet beter gedefinieerd worden. </br> Attractiepolen </br> Ownership: </br> Google heeft hier bepaalde data over die aangekocht kunnen worden. </br> Semantics: </br> Uniform formaat </br> Prioriteren </br> Sociale mix </br> Protection:</br> Moet voldoende geaggregeerd zijn </br> Quality:</br> Relevantie van de informatie? </br> Use case 2: Operator wil nieuwe dienst aanbieden </br> Als dienstverlener/operator, wil ik aan de hand van data in de buurt/aan een hoppinpunt een nieuwe dienst aanbieden voor reizigers. </br> In deze break out werden 2 datatypes besproken: “wachttijden” en “trajecten en overstappen”.</br> </br> Wachttijden </br> Protection: 100% zou geanonimiseerd moeten zijn </br> Quality:</br> Data moet up to date zijn en betrouwbaar (belangrijkste) </br> Volledigheid/context:</br> Reden waarom wachttijden lang zijn </br> Kadering van de data </br> Redenering van de reiziger: stuctureel versus incidenteel </br> Metadata rond kwaliteit</br> Betrouwbaarheid </br> Juistheid </br> Meetmethode </br> Resolutie </br> … </br> Belangrijke bedenkingen:</br> Vanaf wanneer verandert het gedrag en stopt men met wachten </br> Wachtverzachters: welk effect? </br> </br> Semantiek:</br> Betekenis van data moet worden vastgelegd. Wat willen we meten?</br> De tijd dat iemand wacht </br> De tijd voor het volgende beschikbaar vervoersmiddel </br> Rekenen we iemand die onmiddellijk een fiets neemt mee? </br> Volume:</br> Risico: Datavolume moeilijk in te schatten </br> Hoeveel data moeten we bijhouden en hoe lang?</br> Retentie en archiveringsbeleid </br> Voor simulatie en predictie: voldoende data nodig (cycli van 1 jaar) </br> Eigenaarschap:</br> Belangrijk om te weten van wie de data komt (onafhankelijk?) </br> Trajecten en overstappen </br> Bemerking rond trajecten en overstappen: </br> Het meet de status quo en levert opportuniteiten op binnen het bestaande kader. </br>Het meet echter niet de trajecten van autogebruikers. </br>Die trajecten en de motivering van automobilisten zijn een verborgen bron van ov-optimalisatie.</br> </br> Protection:</br> Zaak van privacy by design / deontologische code / GDPR </br> Uiteraard wel belangrijkste en een aandachtspunt, anonimiseren moet juist gebeuren </br> Volume:</br> Grote volumes </br> Zinvolle data destilleren kan een uitdaging zijn </br> Datavolume groot en moeilijk te voorspellen</br> Retentie en archiveringsbeleid nodig </br> Voor simulatie en predictie: voldoende data nodig </br> Semantiek:</br> Wat is overstappen? Ook het laatste stuk te voet is een deel van het traject. </br> Overstappen tussen twee stations op grotere afstand? </br> Use case 3: Reiziger wil een reis boeken en betalen </br> Als reiziger, wil ik de hoppinzuil gebruiker om een vervoersmiddel te boeken en te betalen voor mijn reis. </br>In deze break out werden 2 datatypes besproken: </br> </br> Tijdstip en frequentie van modi </br> Reservatiedata </br> Tijdstip en frequentie van modi </br> Velocity:</br> Een vertraging wil je onmiddellijk weten </br> Snelheid van data is afhankelijk van de issues op het net </br> Dit is enorm gelinkt aan kwaliteit </br> Wat werkt de snelheid tegen?</br> Ondergronds niet het signaal kunnen capteren </br> Onvoldoende devices en niet alle bussen/deelsystemen geven locatie aan -> als je het niet weet, kan je de data niet genereren </br> Je moet weten waar de verschillende modi zijn </br> Infra / architectuur aandachtpunten voor velocity:</br> Detecteren van posities via gps apparaten -> kan makkelijk worden gebruikt om uit te rusten </br> Fietsen hebben geen accu aan boord - wordt het moeilijker </br> Hoeveelheid data die wordt gegenereerd valt mee dus voor architectuur valt dat dan mee, het is belangrijker om een goede dekkingsgraad te hebben om voldoende te weten en te kunnen plannen </br> Ownership:</br> Ownership van de data is gekoppeld aan kwaliteit - omdat er dan ook SLA's aan kunnen worden geboden </br> Semantics:</br> Is semantiek een probleem?</br> Voor de trein kan je 3 verschillende momenten krijgen wanneer dat die aankomt (op perron, op de app, op het bord). Probleem is dat dit een voorspelling is en dat dit in de toekomst is, maar je weet wel waar hij is voorbij gereden (timestamps) weet je wel of waar de data is verloren en dit dan ook aangeven. Het blijft een voorspelling en dus aangeven op welke manier de voorspelling wordt gemaakt </br> Metadata is hier ook wel belangrijke context mee te geven aan de voorspellingen waarom er bepaalde voorspellingen zijn gedaan. </br> Metadata = de bijsluiter van data en er moet zeker opstaan wat de oorsprong is van de data (officiële instanties,...) </br> Citymapper voorspelt aan de hand van modellen de reistijd als je geen connectie hebt en dat maakt de ervaring beter is </br> Semantics definieert duidelijk wat de inhoud van de data is en wat je ermee kan doen en dus als reiziger waar je op kan rekenen </br> Via linked data heb je op zijn minst al de attributen die erin staan, maar we zijn er vandaag nog niet helemaal </br> Wordt vaak ook beschreven als de ijsberg - maar alles wat onder ijsberg zit rond semantics en die onderlaag is niet te onderschatten </br> Quality:</br> Belangrijk dat als je op een mobipunt staat en je een dienst wil gebruiken dat de data correct is om gebruik te maken van de modi. Weten waar de bus naartoe rijdt en in welke richting,... </br> Bij werken/evenementen/afwijkingen -> dit moet ook perfect worden door gegeven </br> Beste app: CityMapper doet het uitstekend, maar de app werkt maar zo goed als de data die wordt ontvangen van de voertuigen </br> Correctheid van de data heeft een ongelofelijke impact op de reiservaring en op de snelheid van jouw reis </br> Wat is een oorzaak van foute data? Trackingdevices moeten worden geïnstalleerd op het voertuig en heel de keten moet worden afgedekt en constant live is in real time (=full stack approach) En hierdoor hangen snelheid en quality wel sterk samen </br> De connectie valt soms weg in de metro -> hiervoor verlies je tracking en dus verlies je de input </br> Ook gegevens van de fietsen zijn belangrijk - real time aangeven hoeveel fietsen er zijn - zodat de verschillende modi beschikbaar zijn / ook de taxi’s hun gegevens real time beschikbaar hebben </br> Antwerpen haalt de data op van Poppy en de laatste 2 weken lag de data plat -> er wordt gekeken naar een SLA afspraak + Transformatie van de data wordt door Antwerpen gedaan zodat de data kan worden mee genomen intern op hun data broker </br> In het vergunningsregelement voor deelvoertuigen worden formaten opgelegd op welke manier ze de data moeten aanleveren, maar dit wel in dialoog met de aanbieders zodat ze op de hoogte zijn van wat er gebeurt </br> Architectuuroplossingen:</br> Gebruik maken van de mensen zelf -> via smartphone eigenlijk weet je waar de mens is en waar het voertuig is -> proberen beter in te schatten waar de bus is dan de vervoersmaatschappij zelf </br> Zelf als stad sensoren voorzien op de voertuigen die in jouw stad rijden en op die manier een eigen netwerk opzetten en end 2 end oplossing voorzien </br> Dataformaten verplichten via aanbestedingen en vermijden dat providers op de data blijven zitten omdat ze daar eigenaar van zijn - dit moet worden doorbroken -> Via standaard apis en applicaties aanbieden, en ook op Europees niveau standaardisatie </br> De stap van big data naar smart data -> voorspellende modellen en AI om te weten hoe je jouw reis kan plannen (eg tijdstip dat er geen fietsen zijn op vrijdag omdat een AI systeem dat voorspelt - cfr drukte van google). In hoeverre smart data slim houden en hoe dat verder onderhouden en blijven up to date houden -> Zullen zelf lerende systemen moeten zijn. </br> Bouwblokken laten inbouwen in de eigen applicaties die interopdata uitspuwt -> decentrale gedachten die ervoor zorgt dat data kan worden ontsloten </br> Reservatiedata </br> Security:</br> Er zijn 2 dingen betrokken: persoonsgegevens en het financiële/rekening dat gekoppeld is aan de reserveren -> dit zijn belangrijke items waardoor security belangrijk is </br> Er is een internationale context -> als je naar Helsinki gaat wil ik daar ook kunnen reserveren en door aparte standaarden en lokale standaarden is het moelijk om jouw identiteit kunnen mee nemen op een veilige manier. (quid a-kaart vs de lijn kaart) </br> Hoe kan je dit tackelen?</br> Mydata.org/solid/itsme/kbc </br> Componenten die aligneren met internationale betalings/privacystandaarden (eg. Ik ga naar Londen en ik neem enkel mijn betaalkaart mee -> ik vertrouw mijn bank om dit te regelen) </br> Hoe kan ik mijn identiteit vrijwaren? Personal data management -> pseudonimisering / hashing </br> Ook belangrijk dat je uw eigen data kan beheren en dat je zelf eigenaar bent van uw data (=solid) </br> Ook als je een kind / valies mee hebt wil je dat mee nemen in jouw betaling -> je moet uw profiel kunnen beheren zodat het planningssysteem hiermee rekening houdt - solid bepaalt wie mag welke data zien en dus vermijdt dat de data real time wordt verkocht </br> Hoe kan je dit tacklen - de juiste standaarden gebruiken om forward compatible te zijn </br> Toch nodig om zo veel mogelijk data te hebben, omdat je altijd wel veel zaken wilt weten en dat je bij meta data of afgeleide van data moet weten </br> Architectuur aanpassen aan privacy by design - de dataproducent geeft akkoord om data te gebruiken (eg je moet ervoor betalen als je de data wilt doorverkopen) </br> Goed weten wat je wilt analyseren om te weten welke data je nodig hebt (eg edge computing) </br> Duidelijk bepalen wat er kan gebruikt worden (wettelijk) en dus ook kunnen aangeven tot hoe ver de data kan worden gebruikt. </br> Volgende Workshop </br> De volgende workshop zal focussen op infrastructuur. </br> Datum volgende workshop: 8/4 -> In de paasvakantie – nieuw voorstel is 6/5 tussen 13.30 – 16.00 en 4/6 tussen 13.30 – 16.00 </br> In de tussentijd nodigen we alle deelnemers uit om op de Kennishub bij te dragen aan de inhoud van VLOCA op basis van jullie expertise.  +
• Presentatie Presentatie VLOCA Hoppinpunt … Presentatie </br> Presentatie VLOCA Hoppinpunten workshop 3 </br> </br> Attendance List </br> Bart De Proost (MOW) </br> Axel Verstrael (Streetwaves) </br> Kenny Stevens (VERA) </br> Gert Vervaet (Geosparc) </br> Emilie Couwenberg (Stad Antwerpen) </br> Philippe Michiels (imec) </br> Tjalle Groen (Taxistop) </br> Frederik Schodts (Vlaanderen) </br> Tim Coninx (De Lijn) </br> Ziggy Vanlishout (Digitaal Vlaanderen) </br> Annie Pinxten (Cronos) </br> Pieter Dresselaers (Igemo) </br> Koen Dereu (Haviland) </br> Koen Triangle (imec) </br> Tijl Dendal (MOW) </br> Wouter Luyckx (Arcadis) </br> Guido Vaganée (VVSG) </br> Ewout Depauw (SOLVA) </br> Bram Roelant (Mobipunt) </br> Natasha Blommaert (MOW) </br> Rik Hendrix (VITO) </br> Bart Scheenaerts (ABB) </br> Wim Michiels (ANYWAYS) </br> Annelies De Craene (Digitaal Vlaanderen) </br> Stephen T'Siobbel (MOBLT) </br> Rob Van Den Berg (imec) </br> Anne-Marie Van Asbroeck (imec) </br> Pieter Morlion (imec) </br> Nils Walravens (imec) </br> Mathias Van Compernolle (imec) </br> Stefan Lefever (imec) </br> Introductie </br> Herhaling van de VLOCA-doelstellingen & Hoe bij te dragen .</br> VLOCA gaat over richtlijnen, standaarden en afspraken rond City Digitale architectuur.</br>Het wil zo veel mogelijk openheid creëren in de digitalisering.</br>Binnen een stad zijn er silo’s en domeinen (eg. Mobiliteit / Verlichting) en deze systemen zijn gelaagd en zijn onderhevig aan verschillende lock ins (eg. use case, domain lock in, vendor, cloud,...).</br>VLOCA gaat over het management van deze lock ins om op die manier de samenwerkingen tussen deze systemen te faciliteren.</br>We aligneren ook met andere initiateven (zoals GAIA X). VLOCA bestaat uit een aantal trajecten (zie slides). Deze trajecten hebben als doel te capteren en te inspireren. </br>En het doel is dat deze trajecten aan elkaar worden verbonden via de Kennishub. Daar worden de onderleggende principes samen gebracht. </br> Wat zijn de concrete deliverables van VLOCA: </br> </br> Digitaal informatie model op te zetten en dit kan worden gemakt met Linked data en OSLO trajecten </br> Hopping Traject consolidatie op de Kennishub -> leidt tot een hoppincompliant template </br> Co-creatie is hiervoor nodig op de Kennishub. </br> Heel veel activiteit van VLOCA gaat zich nu verplaatsen naar deze Kennishub </br> In het najaar zouden we graag deze elementen uit Hoppinpunten combineren met de andere trajecten in een Vlaamse Open City Architectuur </br> Samen naar kwaliteitsvolle hoppinpunten </br> Er wordt eerst ingegaan op de visie vorming en de beleid. </br>Daarna wordt er ingegaan op de subsidiëring en regelgeving. </br>Daarna meer over de huidige situatie. </br> Evolutie van een aanbod-gedreven aanpak naar een vraag-gestuurde aanpak </br>Mobipunten beginnen hun plaats te krijgen in het landschap </br>Er is ook een nieuwe governance structuur in leven gelopen in proefregio’s </br>In 2020 is MOW dan gekomen tot een besluit van de Vlaamse Regering. </br> </br>Evolutie van basismobiliteit naar basis bereikbaarheid. </br>Daar zit ook het STOP Principe in, en dus ook combimobiliteit </br>Het hoppinpunt moet alles met elkaar gaan verbinden. </br>En daardoor kan vervoer op maat worden aangeboden. </br>Er moet dus goed worden gecommuniceerd tussen de spelers en het landschap. </br> Er was visievorming in 2019 die zich heeft verankerd in een Besluit van de Vlaamse Regio. </br>In de mededeling aan de Vlaamse Regering zijn 2 dingen belangrijk: </br>Er moeten genoeg punten zijn & het moet bottom up gebeuren en iedereen moet er zijn schouders onder zetten.</br> Het visie werk is dan vertaald in regelgeving -> Besluit van de Vlaamse overheid (11/11/2020) </br>Dit bevat een categorisering van de mobipunten – er zijn 5 types. </br>4 van de 5 types moeten worden geïntegreerd in het regionaal mobiliteitsplan </br> BVR bevat ook de definitie van de zuilen en de stijl van de zuilen </br>Er zijn ook een aantal eisen gedefinieerd: </br> </br> Toegankelijkheid (inclusief naar iedereen) </br> Minimale uitrusting voorzien </br> Parkeerplaatsen </br> Fietsenstallingen </br> Er moeten informatiedragers zijn </br> Informatiestructuur om data uitwisseling mogelijk maken </br> Uitzondering, want normaal worden nutslevering niet gesubsidieerd (eg glasvezel en 5G) </br>Er is een subsidiemechanisme gekoppeld aan de BVR voor de (her-) aanleg voor de mobipunten. (zie slides voor meer uitleg) </br>Andere spelers als AWV zijn ook belangrijke spelers in dit landschap </br>Er zijn ook talrijke partijen actief op de hoppinpunten. </br>En daarboven ook de regionale spelers die het beheer op zich nemen. </br>Er zijn dus verschillende stakeholders betrokken. </br> Huidige Situatie: </br> </br> Er zijn tal van initiatieven en MOW zou graag in dialoog gaan met deze initiatieven. </br> Hoppinpunten bestaat sinds 2020 en dit zal verder worden uitgerold. </br> Wat zijn de volgende stappen: </br> </br> Hoppinpunten (her) inrichting in samenwerking met de stakeholders </br> Kwaliteit bewaken van de hoppinpunten </br> Basis leggen voor uitwisselen van data en integratie vergroten aan de hand van standaarden (OSLO) en digitalisering VLOCA. </br> Vraag Pieter Dresselaers: </br>Hoe wordt er gekeken naar de timing van het invoeren van de hoppinpunten </br>De Timing moet worden bekeken in functie van de rest van de nota basis bereikbaarheid. </br>Tijl is ook nog maar een maand bezig en gaat er proberen een lijn in te brengen en gaat proberen om dit te laten samen sporen met basisbereikbaarheid. </br> Vraag Pieter Morlion: </br>Op welke manier kan er worden samen gewerkt om bestaande en digitale punten te integreren – vraag is eerder aan Bram (Mobipunten vzw) </br>Er is op dit moment een databank met de diensten (eg eten, toilet,...), maar ook met mobiliteitsdiensten </br>Zij zijn ook vragende partij om de data correct te houden en bekijken op welke manier ze kunnen aligneren met de Mobiliteitscentrale. </br>In aanvulling op het antwoord van Bram, geeft Tijl ook aan dat er heel wat verschillende spelers zijn en dat die verder in kaart moeten worden gebracht zodat er goede afspraken mee kunnen worden gemaakt. Er is een heel landschap aan spelers -> bekijken hoe we ermee verder gaan en definiëren hoe dit kwaliteitsvol kan worden verder gezet. Tijl treedt graag in dialoog met de verschillende partners om samen verder te bouwen en te leren over initiatieven.</br> </br> Hoppin Informatie </br> Op basis van de voorgaande workshops heeft imec al zelf nagedacht over een informatie architectuur. We hebben zelf voorstel gedaan op basis van de informatie die we hebben verzamelt. </br>Een hoppinpunt bestaat niet op zich. Het linkt aan een MaaS afsprakenkader (=financiële regeling), maar ook met het technisch (APIs) en semantisch kader (= OSLO, data moet duidelijk zijn beschreven) </br>En wat betekent dit voor de hoppinpunten. Dit kan diensten en informatie aanbieden. </br> Daarom zijn er verschillende zaken: </br> </br> Informatie architectuur</br> Welke diensten krijgen we op het punt </br> Trein / Bus / deel auto / Taxi </br> Historische informatie – op welke manier wordt het gebruikt </br> Connectiviteit met andere wegen </br> Data modellen</br> Hoe gaan we om met de data – Link met OSLO en zorgen dat we OSLO compliant zijn </br> Service provider – zijn onafhankelijk van het hoppinpunt</br> Deze geven leven aan het hoppinpunt </br> De lijn / NMBS / Pakket dienst of een betaalservice die voor een hoppinpunt geldt. </br> Als we spreken over de busdienst willen we weten welke lijnen het zijn en time tables </br> Het is belangrijk dat deze zaken duidelijk gedefinieerd zijn omdat dit combineren van data faciliteert. </br> Peer als voorbeeld </br> Ze wouden 2 zaken voorkomen: </br> </br> Dat een hoppinpunt geen rommeltje zou worden, geeft onduidelijkheid voor de gebruiker </br> Digitale rommel en dat je 28 apps moet hebben en 4 abonnementen om die diensten te combineren </br> Concreet onderzocht waar ze dit mobipunt willen plaatsen in Peer. </br>Er zijn verschillende groottes en verschillende plaatsen, dus nood aan flexibiliteit bij het inplanten. </br> Mobipunt is zoals een supermarkt, of zoals een publieke markt. </br> </br> Deze analogie met de verschillende marktypes geeft ook aan dat de rol van de overheid duidelijk moet worden bepaald. </br> Wat wel duidelijk was is dat er een samenwerking nodig was met private spelen. </br> Deze zouden graag schaal zien om te vermijden dat ze op verschillende aanbestedingen moeten intekenen. </br> Alle aanbieders hebben hun manier om de data aan te bieden en dat was complex. </br> Een zuil is belangrijk en die kan zowel digitaal als fysiek bestaan. </br>Er zal dus sowieso veel data digitaal moeten beschikbaar zijn voor de gebruikers en voor de verschillende applicaties. </br>Ook rekening houden met burgerinclusiviteit (geen gsm / 4G) dus op de zuil ook digitale zaken aanbieden. </br> Eye opener voor het project was om het gesprek aan te gaan met de burgers. </br> Het eerste begrip was dat dit meer was voor bezoekers van Peer. </br>Daarna werd de vraag gesteld of dit nodig is voor de inwoners van Peer? </br> De voornaamste vragen van de burgers gingen over welke services en hoe kan ik die services gebruiken. </br>Daarnaast kwam het telkenmale terug dat er een routeplanner nodig was waarin je de verschillende diensten kan combineren en kan betalen. </br>Kunnen betalen en hoe je betaalt en hoe je de route van A -> B aflegt zonder eigen voertuig was voor de burgers cruciaal. </br> De volgende vraag was dan: wat kunnen we doen en wat moeten we doen als overheid? </br> </br> Fysiek mobipunt inrichting kan de overheid doen </br> Zuil en elektriciteit voorzien kan ook </br> Deelfiets kan worden aanbesteed </br> Geïntegreerde dienst was nog niet duidelijk. </br> In het project werd er dan wel een voorstel gedaan tot welk niveau een overheid zou kunnen gaan op gebied van architectuur (fysiek en digitaal): </br> Voor de hardcore mobiliteit (NMBS / De lijn) daar is informatie beschikbaar. </br>deelfietsen en deelauto’s daar was toen nog veel werk – er was toen nog geen digitale back bone / infrastructuur </br>Postvakjes – hoe integreren we dit? </br>Een tip: open street maps gebruiken om de diensten te definiëren. </br>er is een datamodel dat je kan gebruiken als stad / gemeente en dan heb je ook een cmmunity die daarmee iets kan doen. </br>Op basis daarvan kan je open data publiceren. </br> Conclusie: </br>Om koterij te vermijden is het nodig dat je een goed bouwplan nodig hebt </br>Hetzelfde geldt digitaal -> bouwplan nodig om structuur te voorzien waaraan de verschillende partijen moeten voldoen. </br> Vraag van Guido: </br>Is er nog een vervolgtraject van S-Lim? </br>Op dit moment is het bij S-Lim geen prio en zit het niet in hun opdracht. </br>We moeten vooral vermijden dat iedereen eigen lastenboeken begint te schrijven </br> vraag Pieter: </br>Apart op OSM publiceren of samen als hoppinpunten </br>Hoppin is een Vlaams merk en het is niet de bedoeling om op OSM merken te plaatsen </br>OSM heeft al een uitgebreid model om Hoppinpunten te definiëren </br>Nadeel is wel dat het allemaal statische informatie is </br>Hoe gaan we Hoppinpunten afbakenen op een kaart (op OSM)? </br>De mogelijkheid om iets te publiceren kan op OSM </br>Een aanbieder zelf kan dit ook aanmaken</br> </br> Workshops </br> Meer details te vinden op |Miro .</br> Groep 1: </br>Welke informatie ontbreekt in het luik hoppin-informatie architectuur? </br> </br> Data rond beheer</br> Info over beheerder: er is niet 1 bron over verantwoordelijkheden, belangrijk om referentie te hebben wie punt beheert </br> Beheer van het punt zelf: maintenance informatie voor technische dienst </br> Toegankelijkheid dienst zelf </br> POI’s </br> Drukte </br> Locatie </br> Weer data </br> Data rond gebruik / gebruikers</br> Score gebruikers beperkingen </br> Usage data </br> Andere diensten </br> Specifiek voor de service provider:</br> Info dienstverlening </br> Real time beschikbaarheid diensten </br> Bezettingsgraad </br> Hoe je kan plannen, booken </br> Welke beschrijvingen ontbreken in het luikt service provider? </br> </br> Naast de diensten die worden beschreven: Hoppin-punten kunnen ook andere impulsen geven – meer dan mobiliteit!</br> Markkramen </br> Uitleendienst </br> Boxen: Concert geven op hoppin-punten via een box (app). </br> Link naar 15 min stad </br> Gamification hoppin punten (Azie). </br> Lokale economie, leefbaarheid boosten. </br> Moet je dit willen beschrijven? Hoe ver wil je gaan? Wel optie aanbieden om dit te kunnen beschrijven: type diensten wel opnemen. En zo modulair verder uitbouwen. </br> Ook andere mob diensten:</br> Deelsteps </br> Disruptieve aanbieders: uber ... </br> Waterbus </br> Carpool </br> Hoe zou je deze informatie en beschrijvingen gebruiken in je toekomstig werk rond hoppinpunten? Welke richtlijnen zijn wenselijk? </br> </br> Vertaling naar leesbare omgeving voor de gebruiker: hoe in praktijk de leesbaarheid voor gebruiker realiseren? Herkenbaarheid, user experience van hoppin punt moet ook aandacht krijgen! </br> Opschaling hoppin-punten: moet gemakkelijk gaan – niet ten kost van experience. </br> Gebruikersinfo: sturend zijn voor beleid. </br> Richtlijnen rond accuraatheid van de data:- standaarden </br> Duidelijk kader, afspraken rond gebruik data (data sharing commerciele partijen!) </br> Uitbreidbaarheid van informatiemodel </br> Metadata over gebruikte databronnen </br> Semantiek: data moet zichzelf beschrijven </br> Specifiek: Koppeling met mobiliteitscentrale (vervoer op maat) (ook info over de muziekboxen!): specifiek voor MOW als soort van MaaS speler. </br> Welke andere initiatieven moeten in rekening worden gebracht om dit informatiemodel zo volledig mogelijk te maken zoals MaaS afsprakenkader, OSLO mobility, ITS-BE?</br> </br> Belgisch kader! Internationaal kader! -> OSLO houdt er rekning mee, ook ITS.be. </br> Vorige learnings: Peer, Mobipunt vzw, ... </br> CDS-M: Nederlandse standaard – data dit naar steden terug moet gaan en verwerkt worden. </br> States: grote aanbieders ja, maar lokaal – kleine aanbieders, zij hebben het niet gemakkelijk -> hoppinpunten kan soort tussenoplossing bieden, in te pluggen in grotere oplossingen. Hier in Vlaanderen is er ook al moeheid bij de Limes van deze wereld -> Vlaanderen moet hier rol spelen om initiatieven over de steden te standaardiseren!!! </br> Kleine aanbieders begeleiden! Kleine initiatieven zijn vaak heel duurzaam, geworteld, dicht bij mensen. </br> Groep 2: </br>Uit intro Koen De Reu (Haviland): Belangrijke rol intercommunales om om te gaan met uitdagingen lokale besturen, zeer weinig lokale kennis aanwezig, ondersteunen met de in planning en linken naar Vlaanderen. </br> Welke informatie ontbreekt in het luik informatie architectuur? </br> </br> Welke (toekomstige) voorzieningen </br> Ruimtelijke situering (punt en/of polygoon) </br> Beschrijvingen aanwezige sensoren </br> Nood aan info die zich bij andere bestuursniveaus bevindt, diensten die inwerken op het lokaal hoppinpunt. Daarvoor bvb een identificator nodig per hoppinpunt om zo ook naburige hoppuinpunten in kaart te brengen. </br> Mogelijkheid tot feedback: basic contactinformatie van de beheerder, bvb kapotte ruit van een wachthokje. Info kan ook in 2 richtingen gaan, bvb sterbeoordeling geven aan en hoppinpunt, of vragen stellen over een hoppinpunt aan de gebruiker, mogelijkheid om klachten of feedback te geven. Zeker voor lokale besturen kan dat belangrijk zijn als ze beheerder zijn van een hoppinpunt. </br> Feedback zou ook via sensoriek kunnen gebeuren, bvb geluidsmetingen, druktemetingen. </br> Naar wie sturen ze die boodschap dan is de vraag natuurlijk, link naar governance en beheersvraagstuk. Haltebeheer is ook een uitdaging en iets om mee te nemen in het geheel. Dat zijn specifieke spelers die verantwoordelijkheden hebben, wordt vaak uitbesteed naar JC Decaux etc. Meestal zijn de gemeenten wel beheerder. Zou eventueel wel samen aanbesteed kunnen worden, omdat bvb door de sociale economie te doen. </br> Overlast: gemeentes willen soms geen extra diensten aanbieden omdat ze extra verkeer zouden kunnen aantrekken (bvb extra verkeer voor pakjesautomaten). </br> Compliance andere punten: is nu toegespitst op IoT gebeuren, maar voor kwaliteitscriteria kan compliance belangrijk zijn, voor de ruimtelijke aspecten en dienstverlening. </br> Welke beschrijvingen ontbreken in het luikt service provider? </br> </br> Mobcentrale: boeken via de mobiliteitscentrale. Welke diensten? Moeten nog aanbesteed worden, deelmobiliteit in het algemeen. Gaat een landschap zijn waar een aantal vervoer op maat deelfietsen en auto’s worden aangeboden, naast anderen. Zullen dus expliciet vermeld moeten worden. Zuilen geven nu aan wat er op een punt beschikbaar is, meer niet, maar idee mobiliteitscentrale is daar ook een boekingsplatform van te maken. In de beschrijving van de dienst moet dus een link voorzien worden naar de dienst waar je kan boeken. </br> Verplichting tot reserveren of niet, maximale gebruiksduur etc. </br> Metadata over betaling: betaalmiddelen, wanneer betalen, currency,… </br> Nood aan abo of niet? </br> 1 betaalsysteem: eerder een wensdroom, gebruiksgemak vooropstellen en via 1 systeem alles betalen, maar zal mogelijk moeilijk zijn. </br> Back to many of back to one: waar kan je je deeltransport achterlaten? </br> Hoe zou je deze informatie en beschrijvingen gebruiken in je toekomstig werk rond hoppinpunten? Welke richtlijnen zijn wenselijk? </br> Welke andere initiatieven moeten in rekening worden gebracht om dit informatiemodel zo volledig mogelijk te maken zoals MaaS afsprakenkader, OSLO mobility, ITS-BE?</br>Wie zijn mogelijke hergebruikers van dit model? </br>Belang lokale initiatieven en hiermee afstemming vinden</br>Kernwoord: afstemming</br> Groep 3: </br>Welke informatie ontbreekt in het luik informatie architectuur? </br> </br> TYPE mobipunt : regionaal, lokaal, buurt, ... als deel van de identificatie </br> VERANTWOORDELIJKE / BEHEERDER / AANPSREEKPUNT. Contact informatie, bijvoorbeeld voor klachten of suggesties ter verbetering (bv netheid, onderhoud,...). Relatie tot HOPPIN label ? </br> SERVICE INFO: naast de services, bijvoorbeeld ook momentele verstoringen van services op HOPPIN impact niveau vertaald (“Hoppin verstoord” symboolke groen-rood-oranje) </br> RUIMTELIJKE info : link naar authentieke gegevensbronnen (bv adres, gebouw, wegsegment), uniek ID van een hoppinpunt, toegankelijkheidsinfo, ... </br> GEBRUIKERS info : mogelijke gebruikers perspectief data (dynamisch) dus ook voor service suppliers en niet alleen voor de reiziger. LINK met TYPE mobipunt. </br> Vraag: hoe kunnen we data over gebruikers van de service suppliers hierover integreren. </br> TOETREDINGSMODALITEITEN : waar moeten vragen neergelegd worden ? Rol van gemeente, mobiliteitscentrale, ... </br> CONNECTIVITEIT : (huidige) beleving van het HoppinPunt => ge-aggregeerde informatie. Luchtsensoren, wachttijden, ... </br> UITBREIDBAARHEID is belangrijk, levenscyclus van het model. </br> Welke beschrijvingen ontbreken in het luik service provider? </br> </br> Lockers, lokale handelaars, fietsherstelzuilen, wachtaccomodatie, toiletten, AEDs, foodtrucks, slimme sloten/micro mobiliteit, ... </br> Bijvoorbeeld deelauto-‘s : via digitaal slot, of via sleutel in de Delhaize ? Zo breed mogelijk houden op niveau van kleine gemeenten en grote steden. </br> Hoe types van services omschrijven ? </br> Waar stopt het Hoppin punt en zijn services ? Fysieke afstand ? </br> Beheer/governance van het Hoppin punt kan ook een service worden op een Hoppin punt.</br> </br> Governance van de services zelf ? De lat hiervoor op de relevante hoogte leggen voor de service en het belang. </br> CONCLUSIE : types services beschrijven en hun common elementen capteren => best af te werken via de KH. </br> Cfr. Groep 1 : Hoppin als ontmoetings- en belevings plaats </br> Welke andere initiatieven moeten in rekening worden gebracht om dit informatiemodel zo volledig mogelijk te maken zoals MaaS afsprakenkader, OSLO mobility, ITS-BE?</br>Wie zijn mogelijke hergebruikers van dit model? </br> </br> PAYMENTaaS : Compliance rond betalingsmogelijkheden ? Uniforme betaling als service. </br> Voorbeelden : Londen, Yelbi Berlijn </br> Pitch : parkeerrechtendatabank => mobiliteitsrechtendatabank ? </br> Harmonisering van licentiemodellen ivm toelaten toegang tot Hoppin Punt. Overbrengen van data uniformiseren naar nieuwe services. </br> Relance plannen : Sensor Data Platform en Mobiliteit van Digitaal Vlaanderen. </br> Vooruitblik naar volgende workshop </br> Volgende workshop zal in het najaar plaats vinden. Dit is een consolidatie workshop. </br>In de tussentijd verwerken we de informatie die we hebben ontvangen uit de workshops en delen we die op de Kennishub. </br>Dit dient als basis voor de verdere cocreatie en daarnaast zal er worden bilateraal afgestemd om de deliverables verder inhoudelijk te verfijnen.  +
• Presentatie Workshop 1 presentatie A … Presentatie </br> Workshop 1 presentatie </br> </br> Attendance List </br> Anne-Marie Van Asbroeck </br> Bram Roelant </br> Ann Verhecken </br> Dieter Cuypers </br> Nele D’haese </br> Annelies Decraene </br> Bart Deproost </br> Annelien Dierick </br> Eli Nomes </br> Ewout Depauw </br> Gert De Tant </br> Rik Hendrix </br> Erwin Hermans </br> Koen Triangle </br> Natasha Blommaert </br> Nils Walravens </br> Philippe Michiels </br> Pieter Dresselaers </br> Pieter Morlion </br> Stijn Piette </br> rob van den berg </br> Bart Scheenaerts </br> Dimitri Schepers </br> Stefan Lefever </br> Stijn Michiels </br> Paul Theyskens </br> Tim Coninx </br> Tjalle Groen </br> Guido Vaganée </br> Maarten Van Loo </br> Gilles Van Onacker </br> Ziggy Vanlishout </br> Gert Vervaet </br> Vincent Van der Linden </br> Terugblik: het VLOCA Project & mobiliteitstraject </br> VLOCA Project </br> Vloca heeft als doel om een Open City Architectuur uit te werken in Vlaanderen. Dit kan gezien worden als een gezamenlijk digitaal bouwplan voor de toekomst. Aan de hand van thematische, technische en projectmatige use cases worden gestandaardiseerde architectuur Componenten vast gelegd die de groei richting slimme steden en gemeenten moet ondersteunen.</br>Co-creatie en inspraak van de vele betrokken partijen (besturen, bovenlokale en regionale overheden, het middenveld, technologiespelers en smart city bedrijven) staat hierbij centraal. Op die manier willen we komen tot gedeelde principes, kennisdeling en Componenten . Dit vertaalt zich in afspraken rond smart city toepassingen, de API ’s voor gegevensstromen, data Componenten en afspraken rond technische architectuur . </br>Participatie wordt erg gewaardeerd. Dit kan gebeuren door deel te nemen aan de discussies in de werksessies en op de kennishub.</br>Op dit moment lopen verschillende VLOCA trajecten:</br> </br> Thematisch:</br> Water in de Stad </br> Mobiliteit: Hoppinpunten </br> Technisch:</br> Databroker </br> Local Digital Twin </br> Topic en project gebonden</br> Lawaai </br> Linken van ongestructureerde data uit besluiten van lokale besturen (PROBE) </br> Mobiliteitstraject </br> Deze Workshop 1 bouwt verder op de kennismakingssessie van 10 december 2020 waarbij vele initiatieven rond slimme mobiliteit en in het bijzonder rond hoppinpunten werden gepresenteerd.</br>Het verslag en de verdere verwerking is terug te vinden op de kennishub.</br> </br> Doelstelling van de workshop vandaag </br> De doelstelling van de workshop vandaag is om inzicht te krijgen in de informatienoden (behoeftes) en achterliggende waarde van gegevens (doelstelling) ten aan zien van hoppinpunten .</br>Achterliggend idee is dat wanneer we tot efficiënte en effectieve IoT -systemen willen komen; er een context nodig is waarbij data tussen partijen in ver vertrouwen kan uitgewisseld worden. Hiervoor zijn spelregels of governance nodig die verduidelijken waarbinnen data worden gebruikt. Zo is het mogelijk om gericht innovaties te gaan ontwerpen met een maatschappelijke meerwaarde. Hierbij vertrekken we in eerste instantie van uit wensen van gebruikers (in dit geval gedefinieerd als de ‘reiziger’) en de noden vanuit innovatiestandpunt.</br>Om dit te bekomen werd in de werksessie gewerkt in twee opeenvolgende break-out sessies. Tijdens de eerste break-out sessie werd gefocust op het perspectief van professionals en organisaties betrokken in het mobiliteitsveld en hoppinpunten . Dit gebeurde in 4 kleinere groepen. Hierbij stonden telkens volgende vragen centraal: Wat is de ideale toepassing vanuit het perspectief van de professional? Wat ontbreekt er op dit moment om hier toe te komen? Wat zijn specifieke condities om data te delen. Deze vragen werden door verschillende deelnemers en organisaties voorafgaand aan de workshop voorbereid en in de break out sessie toegelicht en gaven de overige deelnemers hier feedback op. Vervolgens, in een tweede sessie werd deze bovenstaande vragen herhaald maar vanuit het standpunt van de reiziger, die gebruik kan/wil maken van de diensten in de context van een hoppinpunt.</br> </br> Inventarisatie van gewenste applicaties </br> Lokale Overheden – Intercommunales - Vervoersregio </br> De output van een IoT -systeem moet hapklare informatie aanleveren, zoals hoeveel passanten er zijn bij een bepaald hoppinpunten , welke vervoersmodi er het meest worden gebruikt, op welke manier reizigers hun vervoer reserveren, etc. Steden en gemeenten zullen die informatie dan wel zelf linken aan cijfers over criminaliteit, verkeersongevallen, en dergelijke meer; om in te zetten dus bij de beleidsplanning </br> Vanuit het oogpunt van intercommunales is het belangrijk de vervoersvraag te kunnen opvolgen en linken door gebruik te maken geaggregeerde lokale gegevens en zo beleidsevaluatie toe te laten. </br> Ideale toepassing laat toe om regiospecifieke diensten uit te werken. Hiertegenover staat wel de nuancering dat top-down en op een grotere schaal zaken aanpakken wel nut kan hebben; de ideale oplossing ligt in het midden van deze twee perspectieven. </br> Toepassingen maken monitoren gemakkelijk: Hoeveel reizigers? Hoe vaak worden deelauto’s gebruikt? Wanneer precies? Etc. Met dergelijke informatie kunnen doordachte investeringskeuzes worden gemaakt. Tegelijkertijd kan ook gepeild worden naar de maturiteit van een hoppinpunten . </br> Ideale toepassing denkt vanuit reizigerstrajecten en doorstroming ipv grondgebied of punt in de gemeente </br> Oude haltes als Vervoer_Op_Maat hotspot via derdebetalerssyteem door lokaal bestuur gedragen? </br> Regionale overheid ( AWV ) </br> Het Agentschap staat in voor de organsiatie van raamcontracten om hoppin zuilen te plaatsen en ze kenbaar te maken aan gebruikers. Raamcontract dient voor AWV zelf als voor lokale besturen. </br> Dit betreffen analoge zuilen ( OTL -standaard) en Digitale zuilen. </br> Sensoren (lees ook het artikel Hoe kies ik een geschikte sensor? ) om data te capteren en real time ter beschikking te stellen </br> Data & ICT Integrator (Digitaal Vlaanderen - gov) </br> In een ideale toepassing faciliteert het agentschap de publicatie van de data en datastromen; geënt op het ecosysteem van de smart city data space: een publicatieketen om realtime data met statische data te koppelen; hoppinpunten zijn hier een onderdeel van, maar de Smart City Data Space of SCDS gaat nog verder </br> Via de Smart City Data Space zullen inplugbare software componenten aangeleverd worden die bedrijven kunnen inpluggen in eigen software. Zodat data niet meer "gelocked" is in één toepassing, maar ook door andere kan aangesproken worden </br> Ambitie is om individuele databrokers met elkaar te doen communiceren </br> Bouwblokken voor managed services tov Open Data </br> Data & ICT Integrator (privé) </br> Platform voor het samenbrengen van vele databronnen </br> Technologieën en applicaties die op zichzelf data kunnen zoeken en eenmaal geïntegreerd moet die data terug kunnen stromen naar de gebruiker die bepaalde vragen en queries kan stellen. Applicaties zelf moeten de diensten kunnen gaan zoeken. Dus gebruik maken van een gefedereerd platform en data discoverable maken (lees ook het artikel Hoe deel ik mijn data? ) </br> Niet alleen data-integratie maar ook nieuwe data generen </br> Middenveld ((Fietsberaad; Taxistop; Mobipunten vzw) = </br> Sterke visuele weergave van beschikbaarheid van fietsparkeermogeliljkheden en overdekte fietsenstallingen inclusief beschikbaarheid van extra fysieke diensten zoals fietspompen, lockers, herstelautomaat </br> Verdere uitbouw Velopark </br> Eén abonnement voor alle hoppinpunten </br> Gestandaardiseerde verwerking van gegevens van alle vervoersaanbieders adhv TOMP-API </br> Reizigers </br> Gebruikers zullen waarschijnlijk een aantal verschillende apps ter beschikking hebben, multimodale routeplanners, die hem/haar zullen adviseren. Dergelijke apps zouden volgende functionaliteiten moeten hebben: </br> Zouden alle informatie moeten aanreiken m.b.t. de kortste/snelste/etc. manier om van A naar B te gaan, en dit gebaseerd op (een selectie uit) verschillende vervoersmodi. </br> Zou statische zowel als dynamische info moeten geven. Waar overstappen? Welke faciliteiten zijn er op dit punt allemaal aanwezig? Hoe druk is het op tram of bus? Als ik even wacht, hoe druk is het dan nog op tram of bus? </br> Reserveren van deelauto, deelfiets, etc. </br> Gemakkelijk betalen, en dit voor verschillende formules (abonnement, betalen per rit, maandelijks betalen van vervoerskosten, betalen via facturatie, betalen via palen waarlangs geswiped wordt met een kaart, etc.) of volledige traject in 1 profiel en 1 ticket. </br> Ingeven van bepaalde specificaties moet mogelijk zijn, bv. personen met een motorische of visuele beperking moeten dit kunnen aangeven, personen die een deelauto aanbieden moeten kunnen aangeven dat ze hun eigen auto wensen te gebruiken, etc. </br> Adviseren reizigers op basis van gegevens over trajecten die vaak worden afgelegd, mobiliteitsonkosten die worden gemaakt, etc. in de richting van trajecten die sneller zijn, milieuvriendelijker zijn, gezonder zijn, etc. Ook zou advies kunnen worden gegeven over betalingsformules: Reizigers attent maken op het feit dat ze te veel betalen, bv., en dat het zinvol zou zijn om over te stappen naar een andere betalingsformule. </br> Rekening houden met bestaande digitale kloven: bv interactieve interfaces waarop zoekopdrachten kunnen ingegeven worden op de kiosken </br> Integratie met parkeren en parkeergeleidingssystemen </br> Mogelijkheid tot afweging maken tussen prijs vs tijd </br> Bushaltes die een uniek nummer krijgen om overstap te vergemakkelijken </br> Privacy van de reiziger/burger moet bewaakt worden (lees ook AVG of GDPR ) </br> Benodigdheden om dit te overbruggen </br> Lokale Overheden – Intercommunales - Vervoersregio </br> Databronnen en ontbrekende data </br> </br> Methode van reservering van een flexbus (online vs telefonisch) </br> Data up-to-date houden </br> Specifieke data van deelmobiliteit aangeleverd door spelers: bv gebruikersprofielen, trafieken, wachttijden, afgelegde trajecten </br> Voorafgaand voor lokale besturen zijn er gegevens nodig over het potentieel en het toekomstig gebruik van hoppinpunten om de meerwaarde te kunnen berekenen tov andere geografische punten (bv bushalte) en andere infrastructuur en uitrusting (ikv ruimtelijke planning); zoals data over de omgeving van de punten (locatie, densiteit van de buurt, bereikbaarheid, sociale mix, attractiepolen, ..) als ook data over actuele reizigers. Er wordt gewerkt aan een maturiteitsmodel om hoppinpunten te managen, op te volgen en te verbeteren </br> Inzicht en beter begrip over het concept ‘overstappen’ en data van gebruikers hierover </br> Data over de ervaring van de reiziger en de gebruikers van hoppinpunten </br> Data over het gebruik van deelfietsen </br> Datastromen </br> </br> Eenvoudige visualisaties/dashboarden voor lokale ambtenaren, gezien beperkte capaciteit, kennis en tijd </br> Belang van databrokers om de data te delen, vooral gezien dit data over personen gaat en dus gevoelig zijn </br> Data moeten toegankelijk zijn voor lokale besturen om er hun beleid mee af te stemmen </br> Rol Mobiliteitscentrale is vaag, maar idealiter ondersteunt ze de verschillende stromen in de vorm van een Vlaams Datacenter </br> Bovenlokale inspanningen zijn nodig om datastromen te faciliteren en dus ook vertrouwen tussen partijen </br> Interoperabiliteit </br> </br> Lokale datastromen, ook die van buiten de gemeentegrenzen integreren </br> Advertenties in applicaties geven de voorkeur aan lokale handelaars </br> Inzetten van de TOMP-API en data standaarden </br> Businessmodel </br> </br> BM gebaseerd op een eerlijke kost die de klant betaald </br> Kwalitatieve data als basis voor de uitbouw van een business model </br> Samenbrengen van verschillende subsidiebronnen (lokale, toegankelijke infrastructuur;…) openliggend vraagstuk is de plicht/wens/mogelijkheid van lokale besturen om zelf ook mee een deel van de kost te dragen. </br> Onduidelijkheid over bijdrage van lokale spelers en hun bijdrage ( Mobiliteitscentrale ) </br> Governance model nodig over de te verzamelen data, de correctheid, de verzekering van de dienstverlening,… </br> Nieuwe overheidsdiensten (bv publieke taxi) mogen niet marktverstorend zijn </br> Price-setting mag geen reden zijn om geen data te willen delen </br> Niet alleen samenwerking en openheid nodig tussen providers, maar ook tussen naburige gemeenten vanuit het idee van trajecten. </br> Regelgevend kader </br> </br> Onduidelijk en ontbrekend regelgevend kader om gegevens uit te wisselen tussen aanbieders en lokaal bestuur en afdwingbaarheid; huidig kader is een gentlemen agreement en afdwingbaarheid onduidelijk (bv samenwerking als toetredingsvoorwaarden) </br> Aanbestedingen door lokale besturen worden beïnvloed door MobCent maar ook van lokale besturen (is nog onduidelijk) </br> Wie kan gebruik maken van de hoppinpunten ? </br> Hoe ook info krijgen van niet-aangeslotenen via Mobiliteitscentrale ? </br> Modelclausules om inzicht te krijgen hoe data stroomt (lijkt taak voor hogere overheid; ook voor de uitbating op technisch vlak) </br> Huidige contracten tussen overheid en aanbieders zijn vaak niet voorzien voor het visionaire concept </br> Regionale overheid ( AWV ) </br> Databronnen en -stromen </br> </br> Er ontbreekt ‘data’ over welke ‘data’ de gebruiker wenst digitaal te raadplegen via hoppinzuilen en wat dan de nodige databronnen zijn. De use cases zijn nog niet gedefinieerd. </br> Data mbt betalingen tussen verschillende aanbieders onderling: bv De Lijn vs MaaS providers </br> Interoperabiliteit </br> </br> OTL standaard lijkt aangewezen evt via OSLO MaaS applicatieprofiel </br> Standaarden </br> </br> Data Standaarden : OSLO MAAS + OSLO Wegen en Verkeer (OTL), </br> Datauitwisselingens Standaarden : Datex II ?, NSGI-LD ?, JSON-LD (is eerder afspraak)?, … andere waarschijnlijk nog ??? </br> Geo Standaarden : streaming data binnen geo toepassingen (Cityflows ed), 3D-gewijs. </br> Op EU vlak: ETSI (JSON-LD, maar geospatial niet toereiken </br> Architecturale specs (breed) </br> </br> Keuzes moeten gemaakt worden ovv Hardware specs, Software specs, keuze databronnen, keuze data Standaarden en keuze data-uitwisselingss Standaarden </br> Data & ICT Integrator (Digitaal Vlaanderen - gov) </br> Businessmodel </br> </br> De incentive voor leveranciers om diensten te creëren op de data ontbreekt nog, maar ook het inzicht wat een werkbaar model voor deze partijen zou kunnen zijn. Andere manier dan contractuele bepalingen zoeken is nodig omdat die vaak niet doeltreffend genoeg zijn. </br> Data & ICT Integrator (privé) </br> Datastromen </br> </br> Om nieuwe data te genereren zijn meer sensoren nodig maar ook niet typische partijen die inzicht geven over drukte of passage, zoals naburige koffiebars </br> Nood aan ‘data’ over waar de hoppinpunten ingepland zijn/zullen worden </br> Interoperabiliteit </br> </br> De keuze voor een platform houdt risico in van vendor-lock in en de facto intra-operabiliteit (link met governance) </br> Standaarden </br> </br> Afspraken rond het formaat dat beschrijft hoe data ontsloten worden</br> Duidelijkheid over verplichte karakter van de Standaarden </br> Businessmodellen </br> </br> Duidelijkheid nodig over gewenste en (niet-)toegelaten verdienmodellen </br> Governance </br> </br> In verlengde hiervan is communicatie (korte tot midellange termijn) over locaties en timing van nieuwe hoppinpunten en hoe deze beslissingen lopen </br> Wie mag data gebruiken en/of inzien en/of verwerken? </br> Veel Standaarden opleggen vraagt ook veel technische implementaties voor bedrijven </br> Middenveld (Fietsberaad, taxistop en Mobipunten vzw) </br> Databronnen en ontbrekende data </br> </br> Overzicht fietsenstallingen aan hoppinpunten </br> Realtime bezetting van de fietsenstallingen en fietskluizen </br> Datastromen </br> </br> Écht kwaliteitsvolle real time data van de beschikbaarheid van fietsen </br> Onderscheid voor- of natrajectgemeente, functie van profiel vd gemeente: eigen fietsen en/of deelfietsen </br> Uitdaging om alle mogelijke data samen te brengen (rol voor MobC en Maas-operatoren </br> Data van micromobiliteit: bv deelsteps </br> Interoperabiliteit </br> </br> IOP met de LODstandaard van Velopark </br> Standaarden </br> </br> Linked open data standaard van Velopark JSON Structure & Vocabulary + standaard voor real-time bezettingsdata </br> gbfs gtfs </br> Semantische definiering van het concept ‘Fietsenstalling’ </br> Architectuur </br> </br> Is er nood aan een geïntegreerde back-end, en gediversifieerde frontends; om zo te vermijden dat de reiziger overspoeld wordt met verschillende applicaties en aanbieders </br> Businessmodellen </br> </br> Kunnen beinvloed worden door de overheid die Standaarden oplegt in aanbestedingen door overheden; op die manier is de overheid niet marktverstorend maar eerder sturend </br> Governance </br> </br> Afspraken nodig over eigenaarschap van data en het uitwisselen als open data (al dan niet in een gesloten circuit) </br> VLOCA principes kunnen meerwaarde zijn om dit concept van hoppinpunten te ondersteunen, gezien er gestart is maar ook nog veel ontwikkeld moet worden en nog nieuwe inzichten te wachten staan en vandaaruit verdere keuzes zullen gemaakt worden </br> Reiziger </br> Databronnen en ontbrekende data </br> </br> Inzicht in real-time aanbod moet in het aanbod verwerkt zitten, wat betekent dat data uit de silo’s van applicaties, software en Organisaties gehaald wordt </br> Er moet een verzekering naar de reiziger komen dat het geplande traject effectief afgewerkt kan worden. </br> Datastromen </br> </br> Gezien de meeste gebruikers beroep doen op de diensten van Google (Maps) zouden de hoppinpunten geintegreerd moeten kunnen worden hierin.  +
• Presentatie datum : 10/12/2020 Kennism … Presentatie </br> datum : 10/12/2020 </br> Kennismaking presentatie </br> </br> Voorstelling agenda en afspraken </br> Slides 1-3</br> </br> Inleiding VLOCA trajecten (Annelien Dierick, ABB ) </br> Slides 4-18</br> </br> Combimobilititeit: waarom? (Anne-Marie Van Asbroeck ( IMEC )) </br> Intro </br> Slides 19-28</br> Er is een enorme shift op komst in mobiliteit en om ervoor te zorgen dat dit veilig, vlot en duurzaam kan gebeuren dient er goed afgestemd te worden. Hoppin- of mobipunten zijn daarbij een belangrijke schakel in het geheel: ze zijn herkenbaar, laten een vlotte overstap toe en diensten kunnen hierrond optimaal georganiseerd worden.</br>We gaan vermijden dat we eindigen met allerlei aangebouwde koterij door samen te werken aan een eengemaakte visie van die VLOCA en haar Standaarden . Waar zal in dit project aan gewerkt worden? </br>• Op het vlak van het Ecosysteem: mapping van de initiatieven in de markt - ook voor de EU, het in kaart brengen van data van steden en gemeenten, mobiliteit en service providers door kennisdeling. </br>• Onderzoeken: naar tools en services voor interoperabiliteit tussen spelers zoals steden en gemeenten, MOW , AWV , MaaS spelers, in samenwerking met OASC (Minimum interoperability mechanisms, etc); naar het instellen van een level playing field : de overheid faciliteert marktspelers met Standaarden , implementatie, business cases, afsprakenkader; naar verwachtingen ten aanzien van de digitale zuilen, verwachtingen ten aanzien van de data-infrastructuur. </br>• Rekening houden met OSLO mobiliteit door te participeren in de OSLO oefening om raakpunten met VLOCA te onderzoeken en te ontdekken ( NeTEx , Datex , ANPR ,..)</br>Er wordt rekening gehouden met de verschillende stakeholders in het landschap. </br> </br> Overzicht initiatieven (gemodereerd door Anne-Marie van Asbroeck ( IMEC )) </br> De basisinfo over deze projecten bevindt zich in de slides 29-45.</br> </br> Mobiliteitscentrale (Paul Theyskens, MOW ) </br> Dit project heeft een sterke reizigersfocus en is gericht op het plannen, boeken en betalen van ritten. Hiervoor worden statische (locatie) en real-time data van verschillende partners geïntegreerd en in Hoppin-/mobipunten ontsloten. Interoperabiliteit is van groot belang. </br> </br> National access point transportdata.be (Paul Theyskens, MOW ) </br> Transportdata.be is een website om mobiliteitsdata te delen en moet dienen als centraal punt om die data ter beschikking te stellen voor hergebruikers in binnen- en buitenland.</br> </br> Europese Standaarden en regelgeving (Paul Theyskens, MOW ) </br> Dit project draait om de uitwerking van de EU richtlijn MultiModal Travel Information Services (MMTIS) en de Gedelegeerde Verordening van de EC waarbij in lijn met EU Standaarden mobiliteitsdata ter beschikking gesteld moeten worden van derden voor hergebruik. De implementatie gebeurt gefaseerd en gaat alsmaar meer details omvatten, zoals bv ook disruptie van bijvoorbeeld busvervoer etc.</br> </br> Hoppin punten (Natascha Blommaert, AWV ) </br> Het Agentschap voor Wegen en Verkeer ( AWV ) is verantwoordelijk voor het opzetten van de infrastructuur en de aanbestedingen voor de installatie van de Hoppin punten. Hiervoor worden raamcontracten uitgewerkt voor het opzetten van de zuilen als dienstverlening voor de gemeenten en om erover te waken dat de herkenbaarheid en uniformiteit van die punten verzekerd is doorheen heel Vlaanderen. Een deel van die punten zal geïnstalleerd worden op gewestwegen door AWV zelf, een 750-tal punten door de gemeenten; in totaal zo’n 1.000. Er is een analoge en digitale component. De data die gebruikt worden zijn die van de Mobiliteitscentrale.</br> </br> IoT gestuurde mobi-punten (Ewout De Pauw, stad Stad Aalst ) </br> Dit project dat gecoördineerd wordt door de intercommunale SOLVA (21 gemeenten in arrondissement Aals -Oudenaarde) is erop gericht om in de streek de inpassing van de Hoppin-punten te optimaliseren. Er is reeds vanalles gaande, maar een evaluatie dringt zich op. Hoe kan de kennis van vandaag gebruikt worden voor de Hoppin-punten van de toekomst. Een Proof-of-Concept evaluatiekader wordt uitgewerkt.</br> </br> eHUBS - Smart Shared Green Mobility Hubs (Eli Nomes, stad Leuven ) </br> De Vlaamse/ Leuvense component van dit EU project geleid door de stad Amsterdam en met deelname van 7 EU steden is erop gericht 50 mobipunten met geïntegreerde e-mobiliteit uit te rollen in het Leuvense . Er is een specifieke taak binnen het project rond data. Harmoniseren van datastromen is een belangrijke doelstelling en er wordt een bijdrage geleverd aan TOMP-API .</br> </br> Slimme mobiliteit als hoeksteen van een levendige dorpskern (Kenny Stevens, Geetbets ) </br> Om een veiligere en aangename dorpskern te realiseren worden allerlei sensoren toegepast, ANPR camera’s etc. Maar een deel gaat om politionele data die niet zomaar overal voor gebruikt kunnen worden. In dit project wordt gekeken naar welke technologieën ingezet kunnen worden tegen sluipverkeer in kleine gemeenten en tegelijkertijd wordt gekeken hoe ook met het zelfde doel de dorspkern heringericht kan worden waarbij toch een vlotte mobiliteit gevrijwaard blijft. Beslissingen hierover zullen gebaseerd zijn op mobiliteitsdata. Tegelijkertijd wordt gewerkt aan een raamovereenkomsten voor andere kleine gemeenten en dorpskernen zodat ook zij perkeerproblemen en sluipverkeer kunnen aanpakken..</br> </br> Slimme mobipunten (Veerle Aerts, Peer ) </br> Dit project is reeds afgelopen, maar heeft geleid tot een standaardisatie en modulariteit van de elementen die samen een mobipunt maken om ruimtelijke verrommeling te voorkomen en de prijzen te drukken en daarbij IoT ingebouwd zien op "Plug & Play" wijze. Welke data zijn bv nodig opm een mobipunt optimaal in te planten? Veel inspiratie voor het traject kan hier gevonden worden en hier wordt weer richting raamovereenkomsten gewerkt.</br> </br> Mobipunt VZW API (Bram Roelant, Mobipunt VZW ) </br> In dit project wordt data die gegenereerd wordt rond de fysieke locaties van mobipunten via API ontsloten naar het bredere palet aan mobiliteitsplatformen in Vlaanderen. Centralisatie van data is noodzakelijk. API en software in ontwikkeling met een sterke focus op gebruiksvriendelijkheid.</br> </br> Velopark (Pieter Morlion, fiestberaad) </br> Velopark.be is een digitaal platform dat informatie over fietsenstallingen voor iedereen beschikbaar maakt. Door te koppelen met andere data zoals openbaar vervoer en data van steden en gemeenten, kan zo de velomobiliteit aangezwengeld worden. Deze afstemming is in nederland bijvoorbeeld al veel beter uitgebouwd. Er wordt statische data verstrekt en real-time waar mogelijk/ de applicatie is volledig gebaseerd op open data en is nu al volledig OSLO -compatibel.</br> </br> OSLO mobiliteit: dienstregeling, uitvoering en planning (Dimitri Schepers, PWC Tim Coninx, De Lijn ) </br> Dit OSLO -traject is erop gericht reizigersinformatie semantisch te verrijken en te structureren in samenspraak met de belanghebbenden (gemeenschappelijk begrippenkader). De eerste generieke standaard is reeds gemaakt en nu wordt er verder concreet gewerkt bv voor de dienstregeling. .</br> </br> OSLO mobiliteit: trips en aanbod (Dimitri Schepers, PWC ) </br> Dit OSLO traject draait om de ontwikkeling van een OSLO -standaard die erop gericht is vraag en aanbod van mobiliteit door data-analyse beter op elkaar af te stemmen.</br> </br> OSLO mobipunten/hoppin-punten (Joshua Declercq, MOW ) </br> Hier worden de Standaarden geconsolideerd tot 1 model met focus op de infrastructuur, i.e. de Hoppin/mobipunten.</br> </br> OSLO fietsnetwerk/fietsinfrastructuur (Joshua Declercq, MOW ) </br> Dit OSLO -traject loopt al langer en heeft dezelfde doeltellingen als bovenstaande OSLO -trajecten maar met een focu op velomobiliteit. Het bovenlokaal fietsnetwerk is een belangrijk deel van de modellen. Er wordt ook gekeken naar standaardisering van velomobiliteitsmetingen die hier en daar lokaal gebeuren, om ervoor te zorgen dat ze breder gebruikt kunnen worden. Men wil ook de verschillende projecten die zich enten op die fietsinfrastructuur beter linken.</br> </br> Cityflows (Anne-Marie Van Asbroeck, IMEC ) </br> CityFlows brengt multimodale stromen in een stad in één real-time zicht door mobiliteitsgerelateerde datastromen ( Slimme Verkeerslichten , Telecom , WiFi scanning , Floating Car Data , Slimme Camera ’s, open data …) te bundelen via datafusie . Dit project richt zich echt op alle stromen en behelst een grote verscheidenheid aan data. Focusgebied is de Antwerp Smart Zone .</br> </br> Samen naar een gedeelde architecturale visie ​(Stefan Lefever, IMEC ) </br> Slides 46-57</br> Op basis van de net voorgestelde projecten is het duidelijk dat er al veel in beweging is zowel in-the field als conceptueel, de OSLO -trajecten en dit alles zal ooit samen moeten komen. VLOCA zal niet alles oplossen en heeft ook die ambitie niet, maar wil daaraan bijdragen. </br>Er is ook veel aan de gang in de slimme steden zelf, waar het thema mobiliteit sowieso zal samenkomen met andere thema’s en daarbij moet die Open City Architectuur helpen. Zo is de EU bezig met standaardisering (CEN/TC 684), waarbij ook Agoria -ICT voor Vlaanderen de spiegelcommissie is. Het Wereld Economisch Forum erkent de nood aan zogenaamde Infratech, infrastrustuurtechnologie en daarin speelt de overheid een cruciale rol. Een voorbeeld daarvan zijn de hoppin/mobipunten. Interoperabiliteit en datakwaliteit staan centraal en data-uitwisseling is cruciaal. </br>In dit project zijn we begin dit jaar gestart met een blauwdruk als uitgangsbasis die een visie beschrijft en waaruit dan principes komen om die architectuur vorm te geven. Daarnaast komen daar ook, gebaseerd op de verschillende marketplaces modulaire Componenten die herbruikbaar zijn, digitaal connecteerbaar en deze kunnen gaan van sensoren tot een bruikbare applicatie voor de burger of overheid. We zullen in VLOCA rond deze principes werken en die gestandaardiseerde Componenten . </br>Aggregatie uit invulformulieren die door de deelnemers ingevuld werden:</br>Hieruit kwamen 3 domeinen naar voor die belangrijk zijn om mee te nemen in VLOCA (niet-exhaustief): </br>1. Gebruik: voor wie, wat zijn de noden?: multimodlaiteit, gebruikerssegmentatie, efficiente betaling en bruikbaarheid van real-time data. </br>2. Sturing: hoe willen we de data gebruiken om te kunnen sturen? : hoe kan de dienst geoptimaliseerd worden vanuit de data?, cross-domain koppelingen (luchtkwaliteit, veiligheid, parkeerbeleid), data voor multimodale stromen, optimalisering voor beleid, financieel etc. </br>3. Future-proof elementen: verdere elektrificatie van de mobiliteit (mobiele media als energie-opslag), combinatie met pakketdiensten etc. </br>Hoe nu een uniforme digitale architecturale aanpak realiseren om uiteindelijk te komen tot een cross-domain open urban platform? </br>Daarnaast werden ook de volgende meerwaarden die VLOCA kan leveren, geïdentificeerd: betaalbaarheid, herbruikbaarheid, versnelde implementatie, innovatie en adoptie, meer open beschikbare data als hefboom om sneller oplevering mogelijk te maken, betere datakwaliteit zodat er snelle en actionable data zijn, datafusie mogelijk maken, security, data-ownership ( IDSA ) en privacy, betere beleidsinschattingen en meer gerichte financiering. Voor al deze meerwaarden is data een bruikbare grondstof en voor deze data zijn er een aantal belangrijke aandachtspunten. Wat naar voor kwam uit deze bevraging blijkt net hetzelfde te zijn voor het thema water. Door te werken op deze aandachtspunten voor data wil VLOCA meehelpen om sneller, gerichter en dynamischer uit te rollen. </br>Om dit te doen is een werkwijze nodig, een structuur. Er bestaan al veel referentie-architecturen die dit toelaten. Het OpenDei project wil uit al die verschillende referentie-architecturen een model genereren dat applicatiedomeinen overstijgt en interoperabiliteit vooropstelt. Hierrond werden ook een aantal OpenDei principes gedefinieerd en het model is het 6C model (customization, community, content/context, computing, cyber en connection). Dit model willen we gebruiken als referentie om ons te gidsen; bovendien willen we deze pyramide top-down aanpakken waarbij we starten met customization. Zo hebben we ook de workshops georganiseerd, de eerste WS zal gaan om de value-proposition, welke applicaties, services en beleidsnoden? Deze Ws is eerder voor business en policy profielen. De tweede WS zal eerder gaan over het connect/context en compute gedeelte, eerder data gelinkt en voor data-profielen. De derde workshop over de infrastructuur, de digitale infrastructuur die nodig is om dit te doen ( ANPR , 5G , Tellus , andere sensoren) voor infra-ICT profielen. De laatste werkshop zoomt dan uit en gaat dan over de transversale thema’s zoals security, interoperabiliteit, cross-domain etc. </br>Semantische onderbouw als leidraad om babylonische spraakverwarring te voorkomen, een gezamenlijke taal. Alles staat op de kennishub, een online webplatform gebaseerd op mediawiki, goed geschikt om co-creatie te doen. Binnen die gemeenschappelijke taal van VLOCA zijn er een aantal belangrijke centrale termen. VLOCA adresseert cross-cutting concerns (bv security), heeft een aantal systeemeigenschappen (bv interoperabiliteit en schaalbaarheid) en bevat [[::Category:Bouwlagen| Bouwlagen]]. Principes zijn belangrijk om openheid te realiseren, het zijn essentiële termen en Componenten , er zijn Standaarden die die Termen & Concepten specifiëren, Organisaties en projecten die die Standaarden beheren en Componenten die Standaarden , Termen & Concepten implementeren. </br>Het project van Peer is een goed voorbeeld van dit alles. Hier werd gekeken naar wat de uitdagingen zijn van het realiseren van een mobipunt. Wat zijn de ruimtelijke en digitale uitdagingen? Wat is er nodig om er een digitaal knooppunt van te maken? Dit als voorbeeld, maar uiteindelijk moeten al die initiatieven samengebracht worden en moet binnen die gemeenschappelijke taal gebouwd worden aan die architectuur om een VLOCA schema te realiseren met aandacht voor wat nog kan komen in de toekomst.</br> </br> Discussie en werkplan workshops (Nils Walravens/Mathias Vancompernolle ( IMEC )) </br> Slides 58-66</br> De timing van het traject met de verschillende workshops wordt overlopen. Naast de workshops zal een groot deel van het werk ook moeten gebeuren tussen de workshops in en daarvoor is de kennishub het platform om dat te doen. </br>De globale doelstelling van het traject wordt nog even geschetst. Doel is die VLOCA, maar we gaan niet in detail cases uitwerken.</br>Uit de input werden een aantal mogelijke vragen/topics gedistilleerd en voor elk van die topics met hun subtopics zullen 3 vragen gesteld worden: </br>1. Is dit het juiste topic? (werd dit correct gedistilleerd uit de geleverde input in de invulformulieren. </br>2. Zijn het de juiste / Ontbreken er subvragen? </br>3. Welke andere topics zijn er nog? </br> </br> Klantrelatie </br> Wie heeft/wil de klantrelatie? </br>Issues hier zijn bv. veelheid aan toepassingen, combimobiliteit, een andere login voor elke toepassing... </br>Hoe organiseren we dat zonder dat de gebruiker daar last van heeft? </br>MaaS en betalen? </br>En die klantrelatie heeft natuurlijk zijn implicaties voor betalingen, want naast data zullen ook deze uitgewisseld moeten worden. </br>bv. derdebetalerssyteem mogelijk maken: alle bezoekers aan een event mogen gratis met de bus komen. --> de architectuur moet aandacht hebben voor verschillende types transacties. </br>Opmerking: MOW heeft een MaaS project ( Vlaams MaaS afsprakenkader ) waarin dit aan bod komt, dus best daarmee aligneren. Breng wat uit dat project komt ook hier in. Het is wel niet juridisch afdwingbaar, maar hier wordt overeengekomen tussen alle spelers in het ecosysteem. </br>A: Dit zal zeker gebeuren door VLOCA. </br>Worden er al architecturale aspecten meegenomen in dit Vlaams MaaS afsprakenkader? </br>A: Er is een werkgroep rond data en technologie waarin tech mapping ( OSLO , TOMP-API, …) bezig is, maar niet specifiek voor dit topic, doch aansluiting is zeker nodig.</br>Opmerking: In Vlaanderen wil men SOLID principes gebruiken om hiermee om te gaan (bestuurscomité kruispuntbank Vlaanderen) zodat personen zelf de regie hebben over hun gegevens.</br>Opmerking: Hou ook rekening met niet-Belgen en dat die mogelijk niet dezelfde mogelijkheden hebben. </br>welke visie is er voor die 1.000 Hoppin zuilen in Vlaanderen? We mogen de realiteit niet uit het oog verliezen en ook die visie mee te nemen. Theorie en praktijk dienen goed op elkaar afgestemd te worden. </br>A: Jazeker! </br>Opmerking: Opgepast voor het “techie” standpunt in SOLID , graag ook aandacht voor het gebruikersstandpunt, anders is het risico groot dat gebruikers afhaken. </br>A: Het identiteitsconcept en zelfbeheerconcept is belangrijk. Opmerking: Vanuit praktijk beginnen! MaaS en betalingsproblematiek is niet oplosbaar in de mobipunten. Er zijn al andere initiatieven mee bezig. Derdebetalerssytemen kunnen wel behandeld worden, maar dat is eerder een administratieve formaliteit. Wat vooral ontbreekt is dat bestaande user-journeys nog onvoldoende gebruikt worden. Dat gebeurt nu wel, maar we moeten vermijden dat elk mobipunt dat apart gaat doen met data van de Lijn, NMBS etc. Zet de mobiliteitscentrale als eerste gebruiker voorop en genereer iets generiek dat dan verder gebruikt kan worden en aan derden aangeboden kan worden. Anders wordt er dubbel werk gedaan. Bv. voetgangersstromen in Brussel om overstappunten af te stemmen op die stromen. Heb niet enkel aandacht voor de eindgebruiker maar ook voor de noden van de tussengebruikers. Laten we werken aan een continuous improvement, en start met prioriteits-use-cases. Kijk hoe AGILE improvements daarin ingebracht kunnen worden. </br>A: We vermijden techie-standpunten door co-creatief te werk te gaan in de trajecten. </br> </br> Toegang tot data </br> Hoe organiseren we toegang tot data? </br>Belangrijke termen hier zijn: vindbaarheid, beschikbaarheid, toegankelijkheid (bv. ruwe data, visualisatie, dashboards…), bruikbaarheid (bv. detailniveau, real-time…) en openheid.</br>Bijvoorbeeld: de mogelijkheid om mobiliteitsdata te verkennen tot op straatniveau en aanpassingen te doen aan het netwerk om het effect ervan te kunnen inschatten.</br>We aligneren met OSLO . </br>Opmerking: De apetijt om data aan te leveren is kleiner bij bedrijven dan verwacht wordt op beleids- en tech-niveau. We moeten rekening houden met de economische realiteit en vraagstukken in deze voor die bedrijven in plaats van ons over te geven aan wishful thinking. </br>Opmerking: Een groot deel van wat hier op tafel ligt is al uitgewerkt door Mobipunt VZW , taxistop en E-Hubs project. Hou hier aub rekening mee want er wordt niet van nul gestart. </br>A: zeer waardevol, nemen we zeker mee. </br>Opmerking: Veel data zit vast in silo’s en achter betaalmuren. </br>Er zal een lijstje van potentiële topics voor de workshops gemaakt worden op de kennishub zodat deelnemers daar suggesties kunnen doen. </br> </br> Data-Uitwisseling </br> Hoe organiseren we het uitwisselen van data?</br>Hoe kunnen mobiliteitsaanbieders bepaalde data delen/moeten delen zonder dat dit essentiële informatie vrijgeeft voor concurrenten in een moeilijke markt (deelfietsen, deelauto's, etc.)? </br>Kan een databroker dit mogelijk maken? </br>Data zit in silo’s en in verschillende (verouderde) vormen. Het is belangrijk om te komen tot hedendaagse databrokers, bruikbaar voor alle spelers, ook de kleine KMO. </br>A: toegankelijkheid en bruikbaarheid zijn belangrijke topics. </br>Wie beheert de data van de mobipunten? Hier is al aan gewerkt door allerlei organisaties , ook dashboards voor lokale besturen. </br>A: Dit gaat over het governance-vraagstuk. We zullen hiervoor aandacht hebben. </br> </br> Meerwaarde voor (lokale) besturen </br> Vertaling naar de praktijk van het (lokaal) bestuur?</br>Mapping van digitale en fysieke inplanting van de benodigde overstap-infrastructuur (gemeentelijke/stedelijke planning). </br>Hoe kan data ontsluiting continu bijdragen tot een betere rollout van de combimobi infrastructuur? </br>Opmerking: Deze vertaling is zeer belangrijk voor lokale besturen, is een goede eerste stap. Maar ook voor bovenlokale overheden. </br>Opmerking: een goed overzicht van bewegingen is al zeer interessant voor lokale stakeholders (ook KMO’s), snel leren over lokale mobiliteit (bv over files en luchtvervuiling door verkeerde instelling van verkeerslichten). Hoe kan de lokale mobiliteitsambtenaar deze info overdragen naar lokale stakeholders? </br>Q: Kunnen we de koppeling maken met wat er gebeurt in de vervoersregio’s? Kunnen de mobipunten geëvalueerd worden over de regio’s heen? </br>Q: Hoe zit het met de governance van dit project zelf? Is er voldoende afstemming met MOW ? Hoe vermijden we dubbel werk en zorgen we ervoor dat dit alles versterkend werkt. </br>A: daarvoor is de kennishub opgezet en er zal zeker met MOW samengewerkt worden, ze zijn hier cvandaag ook aanwezig. Al wat impact heeft op het architecturale plaatje zal afgestemd worden. </br>A: er is sinds begin januari een nieuwe Hoppin medewerker bij MOW , dus maak daar gebruik van. </br>A: er is een ambtelijke stuurgroep in dit project met brede vertegenwoordiging van Vlaamse administratie ( MOW , AIV , VLAIO , ABB , VMM ). </br>Q: Zal ook de visie van de burgers meegenomen worden? </br>A: Er is een deelproject in het programma basisbereikbaarheid specifiek over mobipunten. Er is een manager op businessniveau die de stakeholders samenbrengen en het zou goed zijn dat deze oefening daarop kan aansluiten (via programmamanager Eric Sempels). </br>Voor MOW , mobiliteitscentrale is herbruikbaarheid van service belangrijk zodat anderen daarmee zelf aan de slag kunnen voor hun eigen lokale initiatieven.</br> </br> Slotvraag : wat willen jullie concreet gerealiseerd zien op het einde van het traject ? </br> Vb. Gedeelde informatiemodellen, gedeelde semantiek, afspraken rond communicatie Standaarden en uitwisselings Standaarden , protocollen, voorbeeldclausules voor bestekken, gebruik bestaande bouwblokken, ... </br>Opmerking: Bezorgdheid mbt de timing van de workshops en alignering met allerlei projecten van MOW die pas opleveren in 2021 en 2022. </br>A: Timing is een belangrijke parameter in dit verhaal, we houden hiermee rekening; er zal een traject gemaakt worden rond data-brokers etc. VLOCA gaat net bijdragen aan alignering tussen de verschillende lopende initiatieven. VLOCA is geen eindpunt. </br>Opmerking: MOW kent zeer harde deadlines tov kabinet en timings zijn gebetonneerd. Ook de inzet van MOW in VLOCA wordt hier deels door gehypothekeerd. Er zijn reeds heel wat vertragingen. Het gaat niet alleen om timing, maar ook om capaciteit om hieraan te werken. Toch een beetje de indruk dat er dubbel werk gedaan zal worden, dus kijk goed wat al gebeurd is zodat MOW -ers niet extra belast worden. </br>A: We zullen waar mogelijk zaken ter hergebruiken en geen dubbel werk te genereren. </br>Q: Wordt het resultaat van dit traject overgedragen aan een operationele organisatie? </br>A: Dit is werk voor het governance werkpakket. Hiervoor worden een aantal realistische scenario’s opgesteld en voorgelegd en besproken in verkennende gesprekken. </br>Opmerking: Er is veel in beweging, breng zaken samen en kijk waar de missing links zitten in wat er al bezig is, misschien wordt daar best op gefocust en zo kunnen win-wins gerealiseerd worden. , </br>Opmerking: Er zijn al vele harde deadlines van projecten die gehaald moeten worden en die deadlines veroorzaken/linken met silo’s. En toch is alles in constante evolutie. Zorg ervoor dat silo’s ge-elimineerd kunnen worden en duplicaties vermeden. Werk naar een toegankelijke service toe, eenvoudig op in te loggen. We moeten ons organiseren naar constante verandering. </br> Dank voor de waardevolle input!</br> </br> </br> Verdere feedback en voorbereiding workshop 1 (Piet Seuntjens ( VITO ) en Stefan Lefever ( IMEC )) </br> Slides 67-77</br> Piet schetst het belang van de kennishub als centraal gegeven in de trajecten. </br> Stefan legt uit hoe er praktisch gewerkt kan worden met de kennishub (aanmaken account, content toevoegen, taggen etc.). </br> </br> Afsluitend woordje (Annelien Dierick, ABB )  +
• Presentatie https://vloca.vlaanderen.be/ … Presentatie </br> https://vloca.vlaanderen.be//KennishubDownloads/WS4_presentatie_finaal.pdf </br> </br> Onderwerp Van De Workshop </br> In deze workshop werd:</br> </br> er een overzicht gegeven al het geleverde werk sinds de start van het traject in 2020 </br> er een snelcursus tot de kennishub en de draaiboeken gegeven </br> er een showcase gedaan van 2 lopende projecten </br> er de kans gegeven voor vragen en opmerkingen </br> Verslag </br> Een stand van zaken </br> Water in de stad in cijfers, en een overzicht van het gelopen traject:</br> </br> </br> </br> Volgende workshops werden gehouden: </br> </br> Kennismaking </br> Governance </br> Data en data beschikbaarheid </br> Sensoren </br> </br>O.b.v. deze workshops heeft VLOCA een aantal draaiboeken gemaakt die stakeholders in het Vlaamse waterlandschap kunnen consulteren om een stappenplan voorhanden te hebben bij hun slimme “water in de stad” vraagstukken. Een selectie van enkele voorbeelden:</br> </br> Ik wil wateroverlast kunnen voorspellen </br> Hoe deel ik mijn data </br> Hoe kies ik een geschikte sensor </br> </br>We hebben getracht om deze draaiboeken zo goed mogelijk te enten op concrete vragen uit de workshops. </br> Zijn er echter hier nog vragen of opmerkingen over, laat het ons gerust weten via de discussiepagina’s op de Kennishub!</br> </br> De Kennishub en draaiboeken </br> Er werd een kort overzicht gegeven van hoe iedereen kan bijdragen aan de Kennishub. Vervolgens gaf Goedele Verreydt van Iflux haar ervaring bij het gebruik van de Kennishub. Ze haalde volgende 4 bedenkingen aan:</br> </br> Hoe gedetailleerd moeten de techniciteiten zijn voor steden en gemeentes in zo'n draaiboeken?​ </br> Hoe match je de data op de vraagstelling van steden en gemeenten?​ </br> Link maken tussen draaiboeken en bestek => automatische uitrol van lijst?​ </br> Momenteel niet opgenomen hoe voorspellingen gemaakt kunnen worden (bv. wateroverlast, droogte, …) </br> Showcases lopende projecten: Provincie Antwerpen – Bart Aubroeck </br> Bart Aubroeck van provincie Antwerpen, dienst Integraal Waterbeleid lichte hun hydrologische monitoring toe. Er is een duidelijke behoefte aan het meten van grond en oppervlaktewater daar er verschillende problemen/noden rond gemeld werden:</br> </br> droogvallen waterlopen </br> te hoge afvoer </br> up-to-date houden oppervlaktewatermodellen </br> Opvangen tijdelijk meetnetwerk grondwater </br> Er werd gekeken naar de noden aan software en hardware om dit meetnetwerk op te zetten en te onderhouden. Verschillende behoeftes werden al eerder aangehaald in de behoeftes van andere projecten (zie ook overzicht projecten Workshop 0 ):</br> </br> Hardware</br> Betaalbaar </br> Real time </br> Software</br> Gekoppelde ruimtelijke database </br> Beheer én verwerking van data </br> Signaalfunctionaliteit </br> Verder werd er ook een evaluatie gegeven van het huidige geïmplementeerde netwerk. Deze vonden ook hun neerslag op volgende kennishub pagina: Evaluatie van sensoren - Provincie Antwerpen. </br> Er werd ook een mededeling gedaan van de opdracht voor ontwikkeling van het dataplatform die net in de markt werd gezet:  +
• Presentatie & slides gebruikt tijdens de tweede sessie van het VLOCA Traject omtrent de Data Broker  +
• Presentation Kennismaking presentatie … Presentation </br> Kennismaking presentatie </br> </br> Voorstelling agenda en afspraken </br> Slides 1-3</br> </br> Inleiding VLOCA trajecten (Ken Daems, ABB ) </br> Slides 3-11 </br> </br> Water in de Stad (Nele D’Haese ( VITO ) en deelnemers) </br> Intro </br> Slides 12-18 </br> </br> Projecten </br> De basisinfo over deze projecten bevindt zich in de slides. Slides 19-29 </br> </br> B-Watersmart (Isabelle Neyskens, stad Mechelen) </br> Accelerating Water Smartness in Coastal Europe </br> Dit project draait om de inzet van een bufferbekken om de afvoer van rioolwater te bufferen, maar vanuit de droogteproblematiek wil men bekijken hoe dit water ingezet kan worden voor subirrigatie in de landbouw. Hiervoor worden verschillende sensoren ingezet. </br> Kwantiteit en kwaliteit </br> </br> Hydrologisch meetnet provincie Antwerpen (Frie Van Bauwel, provincie Antwerpen) </br> Het hydrologisch meetnet van de provincie Antwerpen is gericht op een realtime opvolging van het waterpeil in de Antwerpse waterlopen. Zowel droogteproblematiek als wateroverlast kunnen gedetecteerd worden. Er wordt gewerkt met ultrasone sensoren met een periodiciteit van 15min. De overschrijding van waak- en alarmpeilen wordt gedetecteerd. </br> Kwantiteit </br> </br> Internet of Water (Koen Triangle, IMEC ) </br> Internet of Water Flanders </br> Dit project beslaat het volledige onderzoek voor het opzetten van het IoW, van sensor tot finale applicatie, van het IT-gedeelte t/m de finale operationalisering. Er wordt bekeken hoe de verkregen dat ingezet kunnen worden voor het beleid. </br> Kwaliteit </br> </br> Q: Wordt er met andere projecten afgestemd voor de locaties van de sensoren, Dit kan omwille van allerlei redenen, zoals onderhoud, nuttig zijn. </br> A: Onderhoud wordt toch eerder apart bekeken, het gaat om andere expertise. [antwoord beperkt tot concreet antwoord op onderhoud, issue is breder] </br> Q: Heeft IoT nog nood aan use-cases? </br> A: Nu staan er een 40-tal locaties op de shortlist, maar input voor de long-list is steeds welkom. </br> Koppeling IoT peilsensordata (Willem Defloor, VMM ) </br> Dit project kent veel paralellen met het project hydrologisch meet,et van de provincie Antwerpen. Op onbevaarbare waterlopen wordt een fijnmazig netwerk van sensoren uitgerold dat men wil testen voor laangwatervoorspellingen, maar ook hoogwater. Daarnaast wordt gewerkt aan een efficënt IoT platform. </br> Kwantiteit </br> </br> Q: Hoeveel sensoren worden er geplaatst? </br> A : In de pilootfase (eerste 5 maanden) 50. Er wordt een tweetrapsstrategie toegepast en 2021 worden er nog meer bijgeplaatst. Het is fijnmazig, zowel geografisch als in tijd (periodiciteit 15min). </br> Monitoring van de Laak (Tine Cahy, VERA) </br> De laak kampt met veel illegale lozingen en de huidige detectie is te fragmentarisch; waterkwaliteitsmetingen gebeuren slechts on de 2 jaar en dan is het kalf al vergiftigd. VERA wil kort op de bal spelen, dus snel detecteren zodat snel gehandeld kan worden. </br> Kwaliteit, in 2de instantie ook kwantiteit </br> </br> Q: Welke kwaliteitsaspecten worden gemonitord? </br> A: liefst zo’n breed mogelijk spectrum, maar focus in eerste instantie op zuurstofgehalte want rapporten wijzen uit dat daar het grootste probleem zit, maar graag dus ook pH en temperatuur. </br> Pro-active flood-detection (Koen Hilgersom, Hydroscan) </br> De klimaatsverandering zorgt voor meer extremen: meer wateroverlast in bepaalde seizoenen en dan weer watertekort in andere. Dit project moet ervoor zorgen dat pro-actief gehandeld kan worden door een end-to-end systeem en een algoritme voor neerslagvoorspellingen. Dit moet toelaten te komen tot wateroverlastvoorspellingen. </br> Kwantiteit </br> </br> Opmerking: Er is hier toch scope om ook kwaliteitsmetingen mee te nemen, immers overflows kunnen zeer vervuilend zijn. </br> Rainbrain (Hans Vercammen, stad Roeselare) </br> Roeselare bevindt zich hydrografisch in een trechterpositie, aan de flessenhals van de Mandel. Er zijn zowel droogte-effecten, mee aangedreven door het hitte-eiland effect, als wateroverlast. Dit heeft ook zijn effecten op de biodiversiteit. In dit project zoekt men naar software die metingen van pluviometers kan koppelen aan niveaumeters zodat op basis van de neerslag het peil kan voorspeld worden. Zowel voor droogte- als wateroverlastproblematiek is eenzelfde architectuur nodig. </br> Kwantiteit </br> </br> Q: Waarop doelt u als u het heeft over biodiversiteitseffecten? </br> A: Dat we veel preciezer kunnen bepalen of het echt nodig is om bepaalde waterlopen af te blokken of niet. </br> Q: Wat wordt er net door Aquafin gemeten in dit project? </br> A: Dat is zeer divers en afhankelijk van de lokale omstandigehden en het project. </br> Smart Waterland (Gino Dehullu, stad Roeselare) </br> In samenwerking met het lokale onderwijsnet wordt een zeer fijnmazig netwerk van pluviometers geïnstalleerd om een beter zicht te krijgen op de spreiding van de neerslag. Het is de bedoeling om dit dan weer te koppelen met Rainbrain. Het project koppelt zo sensibilisering van leerlingen en gezinnen aan de monitoring. </br> Kwantiteit </br> </br> Q: Wordt er een eigen model van pluviometer ontwikkeld? </br> A: De pluviometers worden door WVI ontwikkeld en zullen 3- printbaar zijn en deel uitmaken van een educatief pakket in ontwikkeling. </br> Q: Wordt er een dashboard ontwikkeld? </br> A: Dit gebeurt door WVI. </br> Stiemerlab (Peter Vos, stad Genk) </br> Stiemerlab kadert in een breder programma rond waterproblematiek van de Stiemervallei. Door overflow van de omliggende wijken wordt de Stiemerbeek vervuild. De monitoring van de waterkwaliteit met slimme sensoren in samenwerking met de burger moet leiden tot sensibilisering en hopelijk meer infiltratie in de niet verharde oppervlakken in de wijk. </br> Kwaliteit </br> </br> Vertellende vlotten (Lieven Symons, waterland vzw) </br> Waterland is een nieuwe vzw die als verbinder optreedt tussen burger en politiek. In die optiek worden groene eilanden op binnenwateren voorzien van sensoren (temperatuur, geleidbaarheid, peil, maar ook hopelijk zuurstof) waarbij de burger real-time informatie krijgt en dit op een speelse wijze, met een belevingswaarde [cf. Zwerm-gamification project van IMinds]. </br> Kwaliteit en kwantiteit (finaliteit sterk sensibiliserend) </br> </br> Werfwater (Arne Van Baelen, Werfwater) </br> De doelstelling van Werfwater is de verspilling van bemalingswater tegen te gaan. Hiervoor is het belangrijk debieten in real-time te kunnen volgen. Aangezien dat ook bemalingswaterkwaliteit variable is, moet dit ook gemonitord worden. Grootschalige oplossingen zijn nodig. </br> Kwantiteit (en kwaliteit) </br> </br> Q: Is er contact met de verschillende burgerinitiatieven in Gent en Leuven die dit op de kaart gezet hebben? </br> A: Ja, met Gents MilieuFront en Leuven , maar ook elders. </br> </br> Bijkomend was er nog sprake van een Initiatief van DIGIPOLIS Gent dat te laat ingediend werd. Die informatie zal ook op het platform gezet worden. </br> Reminder: graag aanmelden op kennishub </br> Opmerking: er zijn veel gedeelde themata en technologieën tussen de projecten</br> </br> Samen naar een gedeelde architecturale visie van VLOCA mbt water ​(Stefan Lefever, IMEC ) </br> Slides 30-42 </br> </br> Doelstelling </br> Doelstelling van VLOCA is om uit relecvante en actuele domeinen zoals waterbeheer (water in de stad, zonder te hard te focussen op stad, want Vlaanderen is een nevelstad), de gemeenschappelijke digitale noden te halen met andere domeinen en daar via Standaarden een antwoord op bieden. De doelstelling van VLOCA is niet om het water domein as such te digitaliseren, maar om te aligneren met Componenten en Standaarden uit andere domeinen en zo ook cross-domain digitalisering mogelijk te maken. </br> Welke minimale bouwstenen zijn nodig om het maximum te halen uit alle initiatieven? Hoe kunnen data uit verschillende domeinen gekoppeld worden? Wat zijn de interoperabiliteitsproblemen? Welke principes zijn nodig?</br> </br> Overlopen input </br> Overlopen input vanuit vragenlijsten die voorafgaand aan de workshop door de deelnemers ingevuld werden. </br> Thematische input: verschillende verwachtingen voor datagebruik kunnen door ze te verenigen in een uniforme aanpak leiden tot een netwerk met meer potentieel dan de afzonderlijke delen. </br> Meerwaarde van het Smart Water Network </br> Data als bruikbare grondstof om sneller SWN applicaties uit te rollen. </br> </br> Voorstel </br> Voorstel: aanpak van OpenDei voor het architectuurmodel, het 6C-model dat toegepast wordt in verschillende domeinen (gezondheidszorg, agri-food etc.). We starten top-down omdat de WAARDE vanboven zit: Customization (applicaties), Community (samenwerking), Content/Context (data wordt info, krijgt betekenis), Computing (bewerking van data om info te verkrijgen), Cyber (van ruwe data naar eerste vorm van info), Connection (sensoren en netwerk). </br> De focus voor de verschillende workshops volgt dezelfde structuur, workshop 4/5 is laagoverschrijdend. We kunnen via IMEC ook contact leggen met OpenDei . Er wordt niet enkel gewerkt tijdens de workshops, maar vooral ook tussen de workshops in en dit gebeurt via de kennishub. </br> Semantische onderbouw als leidraad (mediawiki). Architectuur en technische vertalingen op een schaal als VLOCA heeft nood aan een semantisch houvast. Wat zijn principes, hoe verschillen die van concepten, wat is een architectuur en hoe kunnen we daar zeker zijn dat we genoeg elementen verzamelen die leiden tot een eerste interpretatie ? De MediaWiki laat toe om verwijzingen te leggen naar jargon binnen de kennishub, en dus informatie dynamisch (zoals het Web) te organiseren ipv hierarchisch. Deze semantische onderbouw moet toelaten om steeds de focus te behouden bij de doelstellingen van het uittekenen van een VLOCA architectuur. </br> De bedoeling is om tegen eind 2021 draaiboeken te hebben binnen de VLOCA architectuur die toelaten om cross-domain digitale oplossingen uit te tekenen. </br> Welke principes? </br> Termen en concepten dienen eenduidig verklaard te worden (bv voor aanbestedingen), Standaarden worden geformuleerd en een voorzet gegeven voor welke goed zijn. </br> Intermezzo: voorbeeld van output voor een typische water architectuur (SWAN) </br> De organisatoren linken VLOCA met grotere trajecten in het buitenland (meerwaarde voor deelnemers). </br> </br> Q: Ondervangt OpenDei structuur het feit dat men lokaal strenger kan optreden, een strengere invulling kan geven? </br> A: OpenDei is een inspiratiebron. Doorvertaling naar Vlaamse contex zal nodig zijn; we laten ons niet beperken door OpenDei ; we gaan het niet klakkeloos volgen. Dus we laten ons niet beperken moesten er door OpenDei bepaalde grenzen worden opgelegd. (cfr. OSLO waar Europese Standaarden als basis dienen voor een lokale vertaling) </br> Opmerking: Ik zie een zekere alignering van projecten </br> Q: Bestaande projecten: zijn hun datamodellen gekend? Werken die al samen? Zijn die projecten gealigneerd? </br> A: OSLO wordt meegepakt in VLOCA trajecten. We moeten samenbrengen wat al bestaat. Wij stimuleren dat voor datastandaardisatie de OSLO - Standaarden worden gevolgd. Het is niet de bedoeling om OSLO -trajecten binnen VLOCA te draaien, dat is ook onmogelijk. Wel om zoveel mogelijk te aligneren met wat er in OSLO gebeurt. (PS: zie de kennishub voor de links naar geplande OSLO trajecten rond water) </br> Q: We gaan bestaande Standaarden bij elkaar brengen, en in een standaard architectuur bij elkaar brengen, heb ik dit goed verstaan? </br> A: Ja. </br> Q: Hoe is VLOCA afgelijnd, waar begint het en waar eindigt het? </br> A: het concrete traject zal bepalen wat de uitkomst is, maar het minimum minimorum moet een brede verspreiding van de draaiboeken zijn, de diepte wordt bepaalde door de trajecten zelf. Het is een co-creatie traject. Wat we doen is complementair aan bestaande initiatieven (V-ICT-OR, ACPAAS etc.). </br> A: De prioriteiten worden in co-creatie afgebakend. We zouden in het co-creatietraject prioriteiten willen afbakenen in samenwerking met projectleiders. Wat we doen moet een doel dienen. We moeten kennis kunnen uitwisselen, in praktijk brengen, verspreiden, De scope gaan we voor een deel gezamenlijk bepalen startend vanuit de projecten. </br> Discussie en werkplan workshops (moderator Piet Seuntjens, VITO ) </br> Slides 43-56 </br> Voorstelling werkwijze, overzicht van de flow van de workshops </br> Gezamenlijke agenda-setting, transparant, op basis van gelijkwaardigheid</br> </br> Startvraag: Wat vinden jullie van het voorgestelde proces? </br> Q: is het niet beter om vanuit de data te starten? Ik kan wel de dienst al benoemen, maar nog niet de applicaties. Waarschijnlijk ligt het daaraan. </br> A: We redeneren vanuit applicaties omdat we moeten weten welke service/dienst er moet geleverd worden, en welke waarde er dan gecreëerd wordt. Uiteraard is die onderverdeling wat artificieel. Als zou blijken dat het dataverhaal ook relevant is voor de eerste workshop, dan nemen we zeker ook datavragen mee. (bv. databroker) </br> Q: Kunnen we niet beter spreken van use-cases ipv applicaties? </br> A: OK, het gaat nog steeds om de waarde. </br> Q: Moeten we geen onderscheid maken tussen pro-actief en reactief (real-time)? Hemelwaterplannen, droogteplannen zijn pro-actief. Het is moeilijk om applicaties en diensten te benoemen. De kennisopbouw vind ik wel gemakkelijk te benoemen. Het is niet altijd al mogelijk om de applicatie te benoemen. </br> A: benoemen van use-case en daaruit volgen dan de applicaties die dat invullen. </br> Q: is er geen differentiatie nodig tussen de deelnemers op basis van de verschillende lagen in de architectuur? Er worden heel veel termen gebruikt die IT-gerelateerd zijn. Daardoor is het niet altijd gemakkelijk te volgen. Wat wij willen weten als waterloopbeheerders, rioolbeheerders, … is iets anders dan wat de IT-mensen willen weten. Hoe kunnen we zorgen dat de overlap mogelijk is, dat iedereen mekaar begrijpt? Hoe kunnen we een goede overgang maken? Is dit al voldoende meegenomen in het werkproces? </br> A: valabele opmerking, een aandachtspunt dat we zeker zullen bekijken. Eerste workshops: inderdaad meer business en operationele profielen. Wanneer we verder discussiëren over bouwplaten, referentiearchitecturen,… hebben we ook IT-profielen nodig. </br> Q): Hoe worden die Standaarden en de architectuur dan verder gebruikt? Hoe zien jullie het traject na VLOCA? Is er niet alleen maar meerwaarde in een proces als er daarna ook echt iets mee gedaan wordt? Kunnen die ideeën al gedeeld worden? </br> A: Wanneer die matuurder zijn zullen we daar met de stakeholders wel samen rond werken. </br> A: Er is een apart werkpakket in het project voor het governance gedeelte [moeten we aangeven of/hoe zij hierin betrokken worden?] </br> Opmerking: 2 bedenkingen: 1) top-down aanpak is OK, maar vertrekken vanuit data is even valabel; 2) gemengde workshops kunnen ook nieuwe waarde creëren. </br> Opmerking: Het tijdspad is toch moeilijk. </br> Q: Wat als je een workshop mist? Hoe kan je op de hoogte blijven? </br> A: Er wordt gedocumenteerd op de kennishub en het VLOCA-portaal. Daar zal alles worden gedocumenteerd. Wat is haalbaar? Wat is niet haalbaar? Dat bepalen we samen. We proberen om de voorgestelde momenten wel aan te houden. Wat er behandeld wordt tijdens deze momenten zal worden bepaald, enerzijds, op basis van de voortgang, en anderzijds op basis van wat haalbaar is voor de deelnemers. </br> Startvraag 2: Wat willen jullie concreet gerealiseerd ​zien op het einde van het traject? Wanneer is voor jullie VLOCA een succes? </br> A: Draaiboeken, raamovereenkomsten waar lokale besturen gemakkelijk van kunnen afnemen met jaarlijkse of 2-jaarlijkse update. De meeste lokale besturen hebben geen tijd om dit zelf aan te pakken, ook niet met voorbeeldclausules. Een variant op het standaardbestek van de wegenbouw. </br> </br> Q: Waar zitten de gaps, welke Standaarden ontbreken nog op dit moment? </br> Opmerking: Een OSLO -traject duurt verschillende maanden. Informatie delen lukt wel, misschien tot overeenstemming komen, maar meer lijkt me heel ambitieus. Nu is er maar 1 workshop… </br> Q: Hoe zal info gedeeld worden? </br> Subvraag: visulalisatie/dashboards? </br> Opmerking: Graag terughoudendheid met beschikbaar maken van data via dashboards, want kan iedereen dit wel even juist interpreteren? Er zijn mogelijk verschillende platforms of niveaus nodig: burger, operatoren en IT-architecten. </br> Opmerking: opgelet, in sommige projecten gaat het net om citizen-science, dus misschien moet er met personae gewerkt worden? </br> Opmerking: Vlaamse overheid wil waterdashboard bouwen: nieuw platform gefocust op doelen en beleid. </br> Subvraag: alarmen en monitoring? </br> Opmerking: Dit is een belangrijk aspect. </br> Opmerking: Triggers zijn nodig om het onderscheid te maken tussen data en data die tot actie nopen. </br> Opmerking: Data uitwisselen kan, maar als dit leidt tot iets wat risico inhoudt, dan leidt dit tot een no-go zone. Voorbeeld : alle aansturingen die bijvoorbeeld vanuit een SCADA systeem getriggerd worden (bijvoorbeeld drukkleppen,…) zijn “afgesloten” en leven in een beveiligde silo, om veiligheids- of andere redenen. </br> Opmerking: Artificial Intelligence zal de triggers bepalen, daar moeten we op kunnen vertrouwen. </br> Opmerking: Gebruik maken van bestaande kanalen zoals Geopunt. </br> Voorstel workshop 1, 2, 3 en 4. </br> De inhoud van de verschillende geplande workshops wordt summier geschetst.</br> </br> Verdere feedback en voorbereiding workshop 1 (Piet Seuntjens ( VITO ) en Stefan Lefever ( IMEC )) </br> Slides 57-67 </br> Piet schetst het belang van de kennishub als centraal gegeven in de trajecten. </br> Stefan legt uit hoe er praktisch gewerkt kan worden met de kennishub (aanmaken account, content toevoegen, taggen etc.). De kennishub werkt volgens de wiki-principes.</br> </br> Afsluitend woordje (Ken Daems, ABB )  +
• Presentation Water workshop 1 Powerpoint … Presentation </br> Water workshop 1 Powerpoint </br> </br> Onderwerp Van De Workshop </br> Watersystemen volgen niet de contouren van steden, gemeenten, provincies, polders, waterbedrijven,</br>of een van de andere actoren uit de waterwereld. Rivieren, beken en rioleringen lopen doorheen de</br>bevoegdheidsverdelingen die doorheen de jaren ontstonden. Technologische vernieuwing laat toe om</br>een nieuwe, IoT-laag aan het watersysteem toe te voegen. Dit creëert enorme mogelijkheden voor de</br>optimalisatie van ons waterbeheer, zoals de vele initiatieven tijdens de kennismaking toonden. Maar dit</br>stelt tevens grote uitdagingen om de governance van deze IoT-laag op een duurzame en verantwoorde</br>manier te organiseren. En dit met een open blik op de toekomst, en de governanceuitdagingen die deze</br>met zich meebrengt.</br>De werkshop was voor beleidsmedewerkers en andere professionals met een</br>strategisch profiel en het doel was om enigszins zicht te krijgen op de principes die leidend zouden</br>kunnen worden voor de governance van IoT-systemen in de watersector. Deze leidende principes</br>bepalen immers de randvoorwaarden waaronder technische architecturen en infrastructuur worden</br>gerealiseerd.</br> </br> Waarden op basis waarvan het creatiemodel wordt gebruikt. </br> Wederkerigheid van data delen, quid pro quo, return van de data na toevoegen van waarde als wederdienst voor verkrijgen van data. </br> Opgelet voor discriminatie van stakeholders (de grote vs de kleintjes): Is er een level-playing field? Uiteenlopende gezichtspunten over vermarktbaarheid van data door derden (overheid vs. bedrijf). </br> Standaard afspraken rond data delen (cfr. one size fits all afspraken i.p.v. huidige custom afspraken). Wordt er gestreefd naar eenzelfde set voorwaarden waaronder bepaalde datasets worden ter beschikking gesteld? (Nu: ad-hoc afspraken per overeenkomst.) </br> Licenties en hoe die werken (data die gefinancierd worden met publieke middelen moeten gedeeld worden, maar op een democratische manier, waarbij kosten en baten gedeeld zijn. Als bedrijf wil ik ook de mogelijkheid hebben om de licentie van data te hebben en deze aan derden te geven, maar ik wil ook de mogelijkheid hebben om deze licentie te revoken). </br> Effectiviteitsprincipes (Erik Laes, VITO ) </br> Effectiviteitsprincipes of leidende principes zijn principes die individuen, organisaties of de samenleving in haar geheel richting geven in het omgaan met innovaties in een snel veranderende omgeving.</br> </br> Effectiviteitsprincipes onderscheiden zich van ethische principes. Ethische of morele principes sturen ons handelen op basis van waarden die we intrinsiek waardevol vinden (los van het feit of we het realiseren van die waarde in een concrete situatie al dan niet haalbaar achten). </br> Effectiviteitsprincipes kunnen weliswaar gebaseerd zijn op ethische principes, maar ze zijn evenzeer gebaseerd op overwegingen omtrent de meeste geschikte manier om een bepaalde waarde te realiseren, gebaseerd op kennis, ervaring, of overleg. </br> Goede effectiviteitsprincipes zijn richtinggevend, bruikbaar, inspirerend, ontwikkelingsgericht, toetsbaar</br> </br> Transparantie </br> Transparantie betekent dat VLOCA zoveel mogelijk informatie wil vrijgeven over de</br>data, de processen, de standaarden en de acties die genomen worden binnen het smart city initiatief. Kernconcepten hierbij zijn:</br> </br> Open data ‘by default’ (d.w.z. data die niet gevoelig van aard zijn worden in principe opengesteld) </br> Maximaal stimuleren van hergebruik van data (commercieel en niet-commercieel) </br> Data worden gepubliceerd volgens open en machine-leesbare standaarden </br> Duurzaamheid in het onderhouden van datasets </br> Samenwerken over meerdere bestuurslagen </br> Open en transparante communicatie in een leesbare taal over het initiatief </br> Respect </br> Dit betekent dat VLOCA respect voor de burger centraal stelt, door in te zetten op bescherming en empowerment. Kernconcepten hierbij zijn:</br> </br> Autonome keuzes over delen van data mogelijk maken </br> Actiemogelijkheden van burgers op basis van gedeelde inzichten vergroten </br> Bescherming van privacy garanderen </br> Versterken van digitale competenties </br> Bijzondere aandacht voor kwetsbare groepen </br> Actief zoeken naar realiseren van maatschappelijke meerwaarde </br> Verantwoordelijkheid </br> Verantwoordelijkheid betekent dat de nodige processen, standaarden en interacties</br>voorzien worden om vertrouwen te creëren bij de gebruikers van de smart city</br>diensten, door o.a. een effectief toezicht op de projectuitvoering te organiseren. Kernconcepten hierbij zijn:</br> </br> Kwaliteitscontrole van data </br> Alleen die data verzamelen die voor de dienstverlening nodig zijn </br> Cybersecurity </br> Samenwerking met partners die vertrouwd worden door burgers </br> Peer review door onafhankelijke experts </br> Data niet zonder toestemming delen met derden </br> Activering </br> VLOCA wil innovatie en ondernemerschap door burgerinitiatieven, publieke overheden en commerciële partijen stimuleren. Kernconcepten hierbij zijn:</br> </br> Vermijden van vendor lock-in </br> Interoperabiliteit </br> Design met het oog op innovatie </br> Actief de dialoog aangaan met mogelijke hergebruikers van data(platformen) </br> Democratie </br> VLOCA voert democratische waarden hoog in het vaandel. Kernconcepten hierbij zijn:</br> </br> Eigenaarschap van data van burgers ligt bij de burgers zelf </br> Burgerparticipatie </br> Democratisch toezicht </br> Vermijden van machtsconcentraties </br> Faire verdeling van de uitkomsten van het initiatief </br> Breakouts (Nele D’Haese, VITO ) </br> Open data leiden niet automatisch tot efficiënte en effectieve</br>IoT-systemen? Het creëren van een context waarin de transfer van data in alle vertrouwen kan doorgaan is belangrijk. Spelregels afspreken die het kader verduidelijken waarbinnen data worden gebruikt, is daarom belangrijk. Deze regels moeten eerst worden bepaald:</br>Principes gevolgd bij de ontwikkeling van de VLOCA:</br> </br> Ontwerp voor innovatie </br> Streven naar maatschappelijke meerwaarde</br> Wat zijn de behoeften en wensen van de gebruikers van een IoT-systeem? </br> Wat zijn de behoeften vanuit het oogpunt van innovatie? </br> Duurzaam (Regen) Waterbeheer in een stedelijke context wateroverlast en droogte bestrijedn </br> Stap 1 </br> De eerste stap is het bepalen van de acteur die u vertegenwoordigt. Vertegenwoordig je een provincie? Een stad of gemeente? Een bedrijf? Enz. </br> </br> Stap 2 </br> Durf de toekomst in te kijken! Beantwoord de vraag:</br>Wat zouden je informatienoden binnen 5 jaar, binnen 10 jaar, … kunnen zijn?</br> </br> Stap 3 </br> Probeer al eens in te schatten wat de gemakkelijkste manier zou zijn om deze informatie te krijgen. Een app op je telefoon? Een dashboard? Een gewone website?</br> </br> Stap 4 </br> Van welke data ben je nu al de eigenaar?</br>Over welke data kan je nu al beslissen of je ze al dan niet deelt met anderen?</br> </br> Stap 5 </br> Als je antwoord hier niet hetzelfde is voor alle data die je in Stap 4 opsomde, kan je</br>dan duidelijk differentiëren naargelang het type data?</br>Onder welke condities wil je data delen? Wat betekent dit op het vlak van eigenaarschap, identificatie van de 'vragende partij', authorisatie van derden om data door te geven.</br> </br> Stap 6 </br> welke data heb ik nodig?</br>Als je kijkt naar de informatiebehoefte die je eerste beschreef, en de data die je al hebt (of waar je al toegang toe hebt), welke data denk je dan nog nodig te hebben?</br> </br> Stap 7 </br> Waneer zijn deze data bruikbaar voor jou? Welke eisen stel je op het vlak van kwalitijtscontrole, broncontrol, etc.</br> </br> Stap 8 </br> Ga naar het prioriteiten bord, en geef aan wat voor jou prioriteit moet krijgen. We kunnen vanuit VLOCA niet alles tegelijkertijd uitwerken. Wat zou er volgens jou voorrang moeten krijgen?</br> </br> Plenaire terugkoppeling (Nele D’Haese, VITO ) </br> Terugkoppeling uit breakout sessie 1 (Maarten van Loo) </br> Terugkoppeling uit breakout sessie 2 (Koen Triangle) </br> Terugkoppeling uit breakout sessie 3 (Astrid Philippron) </br> Terugkoppeling uit breakout sessie 4 (Erik Laes) </br> Vooruitblik naar volgende workshop (Mathias Van Compernolle, IMEC ) </br> De inhoud van de verschillende geplande workshop wordt summier geschetst.  +
• Presentation Water workshop 2 Powerpoint … Presentation </br> Water workshop 2 Powerpoint </br> </br> Onderwerp Van De Workshop </br> In deze workshop werd dieper ingegaan op de databeschikbaarheid. Door te werken naar standaarden</br>en/of principes kan een vlottere uitwisseling van data mogelijk gemaakt worden. De workshop draaide</br>volledig rond deze standaarden en principes. </br> </br> Welke bestaan er? </br> Welke zijn er te verkiezen waar en wanneer en voor welk type data? </br> Hoe worden data best bijgehouden en met welke systemen best uitgewisseld? </br> Of bekeken vanuit de Open Dei referentiearchitectuur ging deze workshop over de</br>interfaces van Community (delen en samenwerken), Content/Context (datastandaarden) en Computing</br>(opslag en gebruik). </br>Tegelijkertijd werden ook twee andere gerelateerde initiatieven nader toegelicht bij het begin van de</br>workshop:</br> </br> OSLO en meerbepaald het OSLO traject AIR & WATER </br> Data broker van AIV. </br> Introductie OSLO (Kevin Haleydt) </br> Het belang van semantische interoperabiliteit </br> In het kader van dienstverlening dienen overheden van verschillende niveau (lokaal, regionaal, federaal, Europees) met elkaar samen te werken </br> Dit gaat vaak gepaard met allerhande gegevensuitwisselingen van informatie uit verschillende:</br> Systemen </br> Administraties </br> Technische formaten… </br> Nood aan gemeenschappelijk semantische verstandhouding </br> Open Standaarden voor Linkende Organisaties </br> OSLO = Open Standaarden voor Linkende Organisaties </br> Robuuste en gedocumenteerde methodologie </br> Co-creatie als vertrekpunt voor gedragenheid </br> Online publicatie van de semantische (maar ook technische) standaarden in het Standaardenregister </br> Eindproduct van een OSLO traject </br> Semantisch</br> Applicatieprofiel </br> Vocabularium </br> Implementaties</br> LBLOD </br> AWV </br> CRAB </br> Besluitvorming </br> Vlaamse Codex </br> Raakvlakken OSLO & VLOCA Water in de stad </br> Betrokkenheid OSLO in VLOCA traject vanwege synergie, maar ook teneinde dubbel werk te voorkomen </br> Raakvlakken met reeds bestaande OSLO trajecten:</br> OSLO Openbaar Domein</br> Waterdeel </br> Watervoorkomen </br> OSLO Air & Water (focus op observaties & qualiteit) </br> Agentschap Wegen & Verkeer Object Type Library (OTL), namelijk deelimplementaties:</br> Rioleringen </br> Waterlopen (to be) </br> Dijken (to be) </br> Constructie-elementen (to be) </br> Kortom, duidelijke synergie tussen OSLO & VLOCA </br> Data Broker AIV (Annelies De Craene, Ziggy Vanlishout) </br> Sensor Data Platform </br> Onze Probleem is: Hoe maken we van real time sensordata een belangrijke hefboom voor duurzame groei van de Vlaamse data-economie?</br> </br> huidige platformen zijn niet altijd geschikt om grote volumes sensordata aan te bieden op een </br> kostenefficiënte manier</br> </br> smart city toepassingen zijn vandaag nog te veel maatwerk en onvoldoende schaalbaar </br> sensordata ontstaan in silo’s en bieden op zichzelf onvoldoende meerwaarde voor nieuwe </br> business modellen, niet gestandaardiseerd</br> </br> een dreigende vendor lock-in op sensordata en geconsolideerde smart city markt vormt een </br> sterke rem op de innovatie</br> Sensordata zijn een groeimarkt voor de data-economie van morgen.</br>De effect die we beogen:</br> Doelstellingen</br> </br> Herbruikbare open source componenten aanbieden aan de markt die kostenefficiënte publicatie van grote volumes sensordata in real time toelaat - interoperabiliteit </br> Inzetten op open standaarden zodat sensor data sensor-agnostisch wordt en ‘loskomt’ van de leverancier vd sensor en vlot gerelateerd kan worden aan slow moving data (vb. basisregisters) </br> Ecosysteemvan ‘samenwerkende’ sensor dataplatformen tot stand brengen </br> Business voordelen</br> </br> Innovatiesnelheid en time to market van Vlaamse bedrijven gevoelig verhogen. Dit is een voorwaarde voor de veerkracht van onze Vlaamse bedrijven </br> Realtime en gepersonaliseerde data zijn een vereiste voor digitale transformatie geworden </br> Self Service by design en betaalbaar te gebruiken door de gehele markt </br> BREAK-OUTS </br> De deelnemers werden verdeeld over 3 break-outs. Elke break-out kreeg een aanzet tot beslissingsboom</br>voorgeschoteld op een MIRO-board als een eerste probeersel van een stappenplan om te komen tot de</br>beste oplossing om data beschikbaar te maken. Deze beslissingsboom werd overlopen aan de hand van</br>een aantal vragen over de gewenste datastandaarden, eventuele voorkeuren van dataopslagtypes en</br>pub/sub type. Om ergens te starten werden op basis van het ingediende huiswerk van de deelnemers</br>een genudgde classificatie gemaakt tussen 4 types data om de discussie te stimuleren: </br> </br> sensor data </br> GIS data </br> modelresultaten </br> staalname data. </br> Datatypes </br> Het is duidelijk dat nog meer types data gezien worden door de deelnemers en dit afhankelijk van hun</br>uitgangspunt. De voorgestelde opsplitsing is een goed begin, maar niet altijd even relevant. Tevens ging het over semantiek. Een opdeling kan nuttig zijn, maar mag ons niet vastzetten. In vele gevallen zijn de</br>issues dezelfde voor de verschillende types. Het belangrijkste bijkomende onderscheid dat aangehaald werd is real-time versus niet-real-time of historische data. </br>Op die basis zouden bv. al sensordata onderscheiden kunnen worden van de andere 3 voorgestelde types. Ook alle eerder contextdata zijn niet-real-time. Een andere onderscheidingsfactor zou dan contextdata of back-end data van overheden versus andere, door data-bedrijven en sensoren geleverde data (ook wel ‘industriële data’ genoemd) kunnen zijn. En wat met data-enrichment ? </br>Ontologische opdelingen zoals bij WaterML zijn ook mogelijk. Voor OSLO zijn de volgende 3 parameters</br> </br> primordiaal: de plaats (locatie, context,...) </br> de observatie data </br> de context van het device. </br> Die 3 moeten samen blijven. Dit relateert ook aan het belang van unieke Ids.</br> </br> Datastandaarden </br> Algemeen is er een vraag naar standaardisatie; de standaard zelf doet er op zich niet toe, want</br>theoretisch kan je mappen tussen de verschillende datastandaarden, maar dat heeft dan natuurlijk zijn</br>economische plaatje. De realiteit nu is dat er vanalles en nog wat gemaakt wordt en dat bovendien</br>de leveranciers zelf nog een transformatie moeten doorgaan en daadwerkelijk de standaard moeten</br>leveren.</br>Daar staat tegenover dat flexibiliteit nodig is, want standaarden evolueren vandaag trager dan</br>technologische evoluties in sensoren en data-opslag. Tussen beide moet een evenwicht zijn en backward compatibility is daarin zeer belangrijk.</br> </br> Eigen data-opslag </br> Eigen data-opslag is bijvoorbeeld niet interessant voor satellietdata, waar het verplaatsen van de</br>gigantische hoeveelheid data niet aan te raden is. Bovendien moet eigen data-opslag een duidelijk doel</br>hebben zoals het trainen van modellen, archivering, calibratie etc.</br>De IT infra moet flexibel genoeg zijn om de uitwisselbaarheid en opslag te ontkoppelen (cf. REST API ).</br>Wat men intern gebruikt, kan al sterk bepaald zijn door historische keuzes en de bestaande use case(s):</br>uitwisseling, monitoring, presentatie, exploratie, onderzoek etc. Sensor data is ook meestal niet bedoeld</br>voor 1 use case. Idealiter kan een database om met verschillende data-types. Hoe kan je flexibel omgaan</br>met multi-gebruik met andere noden, bijvoorbeeld cross-domain. Smart data wordt belangrijk!</br>Databases waarbij time-series verwerkt worden verschillen van databases waarbij dit niet nodig is.</br>Zeker indien deze data snel achter elkaar (~seconde) binnenstromen.</br>Zij die nog keuzes moeten maken, weten dan toch graag wat een goede keuze is voor data-opslag met</br>een blik op de toekomst.</br> </br> Quality control </br> De kwaliteit van sensordata zijn een heikel punt. Hoe kan die nagegaan worden? Speelt dit enkel maar bij sensordata of is dit even relevant -maar mogelijk minder heikel- voor de andere datatypes?</br>Kan kwaliteitscontrole en validatie ook gestandaardiseerd worden en uitwisselbaar worden (bv.</br>scripts)?</br> </br> Data-ontsluiting (pub/sub, API) </br> Pub/sub system: hoewel sommigen al aangeven de AIV data-broker te willen gebruiken, dient</br>genuanceerd te worden dat het nog een theoretisch concept is. Wat is beter? : self-hosted (Edge) versus</br>Cloud. FIWARE kan in beide gevallen gebruikt worden, want bestaat uit standaarcomponenten.</br>Pre-processing scripts staan best dichtbij de edge. Als de sensor/edge smart genoeg is kan daar al </br>voorverwerking gebeuren. Daar staat tegenover dat bepaalde klanten graag raw data hebben en andere</br>reeds verwerkte. Kunnen beide opties in bepaalde gevallen open blijven?</br>Wat met message brokers/buffers (cf. Kafka)? In functie van de concrete toepassing, kan het nodig zijn</br>dat informatie gebufferd wordt, omdat het verwerken ervan trager is dan de snelheid waarmee data</br>binnen stroomt.</br> API : Er moet naar een interoperabel systeem van API gegaan worden (cf. OSLO verhaal). Standaardisatie</br>is hierin belangrijk en een directe vraag aan OSLO. REST-API aub.</br>Versiebeheer is ook een belangrijk aandachtspunt.  +
• Presentation Water workshop 3 Powerpoint … Presentation </br> Water workshop 3 Powerpoint </br> </br> Onderwerp Van De Workshop </br> Gezien het doel van de Vlaamse overheid bouwt onze regio verder uit tot een Europese koploper op vlak van</br>Slimme Regio’s. Vlaanderen zal lokale besturen maximaal ondersteunen om het beleid en</br>implementaties rond slimme steden efficiënt en breed te verspreiden.</br>Er is behoefte aan een gemeenschappelijk digitaal bouwplan met</br> </br> Gestandaardiseerde architectuur componenten voor slimme steden en gemeenten </br> Lokale overheden ondersteunen bij de digitale transformatie </br> This workshop aims to: Improve the understanding and knowledge of water sensors for every use, with nuanced information</br> </br> </br> Ervaringen </br> VLOCA workshop: partners voor water (PvW) case (Dr. Niels Wardenier, VITO) </br> Selectie sensorlocaties </br> 9 locaties werden geselecteerd:</br> </br> 7 locaties rond “de Ganzepoot” </br> 2 locaties in het havengebied </br> Installatie sensoren </br> Voorafgaand locatiebezoek: maart 2020 Installatie van de sensorbuizen: april – mei 2020 CTD sensoren operationeel: juli – augustus 2020 Alle locaties uitgerust met 9 CTD sensoren (Keller)</br> </br> Geleidbaarheid (EC) </br> Temperatuur </br> Drukmeting </br> Installatie sensorbuizen </br> Sensoren geïnstalleerd in PVC buizen</br>Buizen langs onderzijde afgesloten → sensor niet verliezen</br> </br> Onderhoud sensoren </br> Tweewekelijks onderhoud van alle sensoren:</br> </br> Visuele inspectie </br> Reinigen sensoren </br> Uitvoeren van controlemetingen mbv draagbaar toestel </br> HYDROKO </br> Use-case Hydroko : Digitale Watermeter + Afsluitbare kraan</br>Nieuwe ontwikkeling van sensor</br>vertrekkend van technische vereisten.</br> </br> Nauwe samenwerking tussen Hydroko & Water-link </br> Hardware + data-platform </br> Bijzondere aandacht voor:</br> Eenvoud Installatie </br> Cyber-security (Encryptie) </br> Betrouwbaarheid/levensduur </br> Testen </br> Data-uitwisseling via API </br> Andere sensoren voor water-toepassingen</br> Druk monitor </br> Level sensor </br> Slimme standpijp </br> Hydrant monitor (under development) </br> Automatic pipe flush valve (under development) </br> And more to come … </br> Plenaire terugkoppeling breakouts (Nele Desmet) </br> Breakout sessie </br> Breakout interacties</br> </br> Meerkeuze vragen → Mentimeter </br> Stellingen (akkoord/niet akkoord) → Mentimeter </br> Open vragen </br> Breakout Topics</br> </br> Sensoren voor monitoring water </br> Prijs van sensoren en inspanningen/kosten voor onderhoud </br> Sensornetwerk opzetten </br> Datacommunicatie en logging </br> Plenaire terugkoppeling</br> </br> Samenvatting antwoorden op meerkeuzevragen (selectie) </br> Topic 1+2 ➔ Hoe kies ik een geschikt sensor? </br> Topic 3 ➔ Hoeveel en waar sensoren plaatsen? </br> Topic 4 ➔ Hoe kies ik de geschikte datacommunicatie en logging device? </br> Hoe kies ik een geschikte sensor? </br> Geschikt voor meten van parameter X en geschikt voor de beoogde toepassing</br> Hoe kies ik een geschikte sensor?</br>Input uit breakouts: topic 1+2 Waarmee hou je rekening om te beoordelen/evalueren of een sensor “kwalitatief” of “geschikt” is?</br> </br> Robuustheid (beperkt onderhoud/kalibratie) </br> Vereiste onderhoudsfrequentie </br> Drift bestendigheid </br> Accuraatheid/nauwkeurigheid </br> Betrouwbaarheid </br> Precisie </br> Meetbereik (range) </br> Waterdichtheid bij hogere waterdruk (diepte in waterkolom) </br> Modulair, uitbreiding (bv. extra parameters) </br> Prijs / kosten - TCO </br> Testen, ervaring, review/feedback </br> Geschikt voor beoogde toepassing en condities </br> Geschikt voor type water waarin je meet (vb. Afvalwater ↔drinkwater) </br> Stroomverbruik </br> Afmetingen </br> Vandalisme bestendigheid </br> Beschikbaarheid van reserve onderdelen </br> Hoeveel en waar sensoren plaatsen? </br> Praktische & technische aspecten m.b.t. sensornetwerk, keuze locatie en installatie. Waar denk je aan? Waar hou je rekening mee?</br> </br> Energievoorziening (elektriciteit, batterij, zonnepaneel) </br> Toegankelijkheid, bereikbaarheid </br> Vegetatie (hinder/onderhoud) </br> Vergunningen en toelatingen </br> Risico op diefstal/vandalisme – Mogelijkheid tot beveiliging </br> Connectiviteit voor datacommunicatie </br> In functie van de beoogde toepassing / doelstelling </br> Daar waar je een verandering/verstoring verwacht voor de meetparameter(s) </br> Toepassingen waar ruimtelijk component belangrijk is → hoe meer, hoe beter </br> Complex proces om geschikte locaties te kiezen → diverse aspecten </br> Kleine netwerken (enkele locaties) van zelfde type samenbrengen → meerwaarde </br> Hoe kies ik de geschikte datacommunicatie en logging? </br> Wat zijn de vereisten voor datatransmissie en logging? Wat zijn de vereisten voor remote interactie/communicatie met de sensoren?</br> </br> Realtime voor bepaalde toepassingen bv. overstroming, procescontrole, RWZI, overstort </br> Voor andere toepassingen data uurlijksof dagelijks doorsturen voldoende vb. droogte monitoring </br> Optimalisatie door dynamische aanpassing van meetfrequentie/zendfrequentie bv. bij overschrijding grenswaarde, bij event, bij alarm,… </br> Remote access is voor de meeste toepassingen belangrijk </br> Two-way interactie biedt mogelijkheden voor </br> variabel/dynamisch aansturing </br> Software updates </br> Afweging noden en wensen mbt transmissie & logging tov kosten en nodige energie  +
• Previous discussion was archived at [[{{{archive}}}]] on Fout: ongeldige tijd. .  +
• Previous page history was archived for backup purposes at [[{{{archive}}}]] on Fout: ongeldige tijd. .  +
• Principes Onderstaande principes werden … Principes </br> Onderstaande principes werden gedefinieerd tijdens de VLOCA exploratiefase tot 2022. De principes worden herzien en aangevuld.</br> </br> </br> Deze ontwerp principes zijn een samenvatting van bevindingen van verschillende organisaties zoals OpenNorth, OpenDei, Gaia-X, IDSA, OASC, AIOTI, ... in 2 categorieen : de meer operationele principes rond data en infrastructuur, en de effectiviteits principes om het doel om het leven van de burger in de stad/gemeente te verbeteren zo gedragen mogelijk te realiseren.</br> </br> VLOCA operationele principes (DATA/SYSTEM driven) </br> (zie https://vloca-kennishub.vlaanderen.be/vloca-kennishub/Categorie:Technische_principes )</br> </br> Hier breiden we de term FAIR graag uit naar FAIRed+ </br> OP.1 FAIR – Findable</br> </br> Voorbeelden : IDS metadata registry, data catalogues, ...</br> </br> OP.2 FAIR – Accessible </br> </br> Voorbeelden : Open API’s, LDES, ...</br> </br> OP.3 FAIR – Interoperable</br> </br> Voorbeelden : ISA2, MIMs, ...</br> </br> OP.4 FAIR – Reusable</br> </br> Voorbeelden : data governance, ...</br> </br> OP.4 FAIR e d- Efficient</br> </br> Voorbeelden : Total Cost of Ownership, Federation, Decentralization, open source, open protocols, modularity, data lakehouses, scalability, reliability, cost, customization, protocols management, cloud & vendor lock-in management, support & maintenance, technology complexity management, hardware agnostic management, ...</br> </br> OP.6 FAIRe d – Decisionable</br> </br> Voorbeelden : data quality, data provenance tracking, GDPR compliant handling, ...</br> </br> OP.7 Data marketplace enabled</br> OP.8 Openness</br> </br> Voorbeelden : open data charter, open source software, ...</br> </br> OP.9 Privacy & sovereingty</br> </br> Voorbeelden : personal data management, data projection, ...</br> </br> OP.10 Security</br> </br> </br> VLOCA effectiviteits princpes (PEOPLE driven) </br> (zie Effectiviteitsprincipes )</br>Deze principes worden in de literatuur ook de CARE principes genoemd. (Collective Benefit – Authority to Control – Responsible – Ethical)</br> EFF.1 Transparant</br> EFF.2 Respectvol</br> EFF.3 Verantwoordelijk</br> EFF.4 Activerend</br> EFF.5 Democratisch</br> EFF.6 Ethisch</br> </br> Opgenomen onder technische principes </br> API-first </br> Context Information </br> Data kwaliteit </br> Data Portability </br> DATA-first </br> Data-soevereiniteit </br> Governance </br> Interoperabiliteit </br> Machine readable </br> OASC MIMs </br> Open Data </br> Open DEI Principles </br> Semantische Interoperabiliteit  +
• Privacy by design of Gegevensbescherming d … Privacy by design of Gegevensbescherming door ontwerp: Ondernemingen/organisaties worden aangemoedigd om in het vroegste stadium van het ontwerp van de verwerkingsactiviteiten de technische en organisatorische maatregelen te treffen die nodig zijn om de beginselen inzake privacy en gegevensbescherming vanaf het begin te waarborgen („gegevensbescherming door ontwerp”). </br> Standaard moeten ondernemingen/organisaties ervoor zorgen dat persoonsgegevens worden verwerkt met het hoogste niveau van privacybescherming(bijvoorbeeld alleen de noodzakelijke gegevens worden verwerkt, korte opslagperiode, beperkte toegankelijkheid) zodat persoonsgegevens standaard niet toegankelijk zijn voor een onbeperkt aantal personen („gegevensbescherming door standaardinstellingen”).</br> Lees meer: https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/obligations/what-does-data-protection-design-and-default-mean_nlnd-default-mean_nl  +
• Privacyverklaring Toegankelijkheid Recente wijzigingen Sitemap English Over VLOCA  +
• Pub/sub Pub/sub (of ook Publish/Subscrib … Pub/sub </br> Pub/sub (of ook Publish/Subscribe) verschilt van het request/response paradigma.</br> </br> Request/response </br> Bij een request/response wordt een request gedaan voor data. Deze vraag komt aan bij de data owner, die op zoek gaat naar de data die gevraagd werd.</br>Dit zou in praktijk kunnen betekenen dat de data owner een vraag van een gebruiker die door middel van een API tot bij hem kwam, via een query opvraagt in zijn database.</br> Eens de data owner zijn data gevonden heeft, stuurt hij deze terug. Dit is de response .</br> </br> Publish/subscribe </br> In een pub/sub systeem, stuurt de data owner continu zijn meest recente data door naar een broker, waar de data verdeeld wordt naar iedereen die gesubscribed is op deze data. Dit verdeel process gebeurt automatisch.</br> Zie ook een analogie met een vrachtwagen en magazijn onderaan [1] :</br> </br> </br> Wanneer kiezen we welk paradigma? </br> Doorgaans wordt in grotere IoT systemen het pub-sub (broker) paradisgma verkozen. Waarom is dit?</br> Bij het Request-Response systeem, moet de client (zie voorbeeld hierboven) telkens vragen indien er een aanpassing was van de data [2] :</br> </br>1: Client request: wat is de sensorwaarde? - Response: 2</br> 2: Client request: wat is de sensorwaarde? - Response: 2</br> 3: Client request: wat is de sensorwaarde? - Response: 2</br> 4: Client request: wat is de sensorwaarde? - Response: 2</br> 5: Client request: wat is de sensorwaarde? - Response: 5.5</br> </br> In bovenstaand voorbeeld, moeten er bij de eerste 4 request telkens "lege ladingen" teruggestuurd worden naar de client: de data bleef ongewijzigd.</br>Indien men wenst om op zeer hoge frequentie data te monitoren, kan er een probleem onstaan als veel clients dit tegelijkertijd doen: het systeem geraakt overbelast.</br> In het pub-sub systeem, wordt er enkel data-traffic uitgevoerd indien er effectief een verandering optrad in de data: dan pas sturen de clients hun "vrachtwagen" naar de broker om de nieuwe data binnen te trekken.</br> </br> </br> ↑ https://blog.opto22.com/optoblog/request-response-vs-pub-sub-part-1 </br> </br> ↑ https://blog.opto22.com/optoblog/request-response-vs-pub-sub-part-2quest-response-vs-pub-sub-part-2  +
• Publish/Subscribe 1.0 is een interfacespec … Publish/Subscribe 1.0 is een interfacespecificatie die de kern Componenten en -concepten van het Publish/Subscribe-berichtenuitwisselingspatroon met OGC Web Services ondersteunt. Het Publish/Subscribe-patroon is een aanvulling op het Request/Reply-patroon dat door veel bestaande OGC Web Services wordt gespecificeerd. Deze specificatie kan worden gebruikt in overleg met, of onafhankelijk van, bestaande OGC Web Services om gegevens te publiceren die interessant zijn voor geïnteresseerde Abonnees.</br> Publish/Subscribe 1.0 richt zich voornamelijk op mogelijkheden voor abonnementenbeheer, zoals het aanmaken van een abonnement, het verlengen van een abonnement en het uitschrijven van een abonnement. Deze standaard stelt echter ook Publish/Subscribe services in staat om de ondersteunde protocollen voor het afleveren van berichten, zoals SOAP-berichten, ATOM en AMQP, te adverteren en te beschrijven. Berichtafleveringsprotocollen moeten worden beschouwd als onafhankelijk van de Publish/Subscribe 1.0-standaard. Daarom bevat OGC Publish/Subscribe alleen metagegevens met betrekking tot berichtafleveringsprotocollen in voldoende detail om verschillende implementaties van Publish/Subscribe 1.0 interoperabel te maken.</br> Deze specificatie definieert de Publish/Subscribe-functionaliteit onafhankelijk van de bindende technologie (bijv. KVP, SOAP, REST). Uitbreidingen van deze specificatie kunnen deze kernconcepten met specifieke bindingstechnologieën realiseren.</br> [[Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]]Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]]  +
• QUARK – “Quick Urban AiR quality using Ker … QUARK – “Quick Urban AiR quality using Kernels” - is een screeningsmethodiek ontwikkeld door VITO om op een snelle manier jaargemiddelde hoge resolutie luchtkwaliteitskaarten te berekenen voor stedelijke omgevingen. De methodiek voldoet aan volgende voorwaarden:</br> </br>•             Snel zijn (rekentijd)</br> •             Relatief gelijkende resultaten geven als ATMO-Streetsimulaties van dezelfde scenario’s.</br> </br>De methodiek maakt gebruik van een kernel aanpak. Dit zijn de jaargemiddelde bijdrages tot polluentconcentraties voor een wegsegment met standaard-emissies. Voor verschillende mogelijke oriëntaties van een wegsegment wordt de bijdrage tot de jaargemiddelde in de configuratiestap berekend. De methodiek wordt toegepast om de verschillen in de polluentconcentraties ten opzichte van een referentiesituatie te berekenen.</br> De resultaten voor de referentiesituatie worden ook tijdens de configuratiestap berekend. Wanneer een nieuw scenario dient te worden geananlyseerd, dient enkel voor wegsegementen met wijzigingen in de verkeerssituatie de luchtkwaliteitsimpact te worden berekend.  </br> In de modellering worden de wijzigingen in de verkeerssituatie als eerste stap omgezet tot wijzigingen in wegverkeersemissies. Voor deze wegverkeersemissies wordt vervolgens op basis van de voorberekende kernel-bibliotheek de luchtkwaliteitsverschilkaart samengesteld. Hiervoor wordt voor elke bron (wegsegment) de juiste kernel geselecteerd en opgeschaald met de emissies.</br> Door combinatie van de verschilkaart en de referentie kunnen ook de totale polluentconcentraties berekend worden.</br> </br>De methodiek is opgezet en toepasbaar voor stikstofdioxide (NO 2 ) en fijn stof (PM 10 en PM 2.5 ). Voor de DUET Digital Twin is QUARK gekoppeld aan een verkeersmodel van KU Leuven.</br> Meer informatie via https://vito.be/nl/product/atmosys-luchtkwaliteitsmanagement-systeem  +
• RESTful API's voldoen aan een aantal eigenschappen die meer in detail beschreven worden in [1] ↑ https://en.wikipedia.org/wiki/Representational_state_transfer  +
• Recente wijzigingen Thematische werkgr … Recente wijzigingen </br> Thematische werkgroep 1 ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 3 mei 2024 08:41:32 ) CityTRAQ ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 2 mei 2024 13:08:40 ) Kick-off ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 30 april 2024 14:17:46 ) Digitale meldingen ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 30 april 2024 13:54:20 ) Stad Harelbeke ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 30 april 2024 13:53:49 ) VlocaTraject ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 26 april 2024 12:20:31 ) VlocaSessie ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 26 april 2024 12:19:46 ) Standaard ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 26 april 2024 12:19:01 ) Deliverable ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 26 april 2024 12:12:54 ) ArchitectuurComponent ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 26 april 2024 12:06:32 ) Geraardsbergen ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 24 april 2024 10:03:09 ) Thematische werkgroep 3 ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 22 april 2024 14:13:36 ) Thematische werkgroep 2 ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 22 april 2024 14:13:07 ) Thematische werkgroep 1 ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 22 april 2024 14:12:47 ) Thematische werkgroep 1 ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 22 april 2024 13:55:17 ) Template:Base properties ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 19 april 2024 12:09:33 ) Slimme Markten ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 14:54:37 ) Aankondiging start publieke review ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:14 ) Aanmaak co-creatie pagina op de kennishub ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:13 ) Architectuurstandaard ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:13 ) Bestekteksten ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:12 ) Data Governance Model ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:11 ) Conformiteitsmodel ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:11 ) Informatienoden ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:10 ) Marktanalyse ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:09 ) Oproep tot deelname ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:08 ) Opstart werkgroep beheer architectuur van de use case ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:08 ) Stakeholder interview ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:07 ) Stakeholderanalyse ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:06 ) Testimonial ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:05 ) Traject charter ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:05 ) Use case prioritering ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:04 ) Use case roadmap ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:03 ) VLOCA Draaiboeken ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:02 ) VLOCA Talk ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:01 ) Vereistenmodel ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:00 ) VLOCA-Model ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:23:00 ) Technische Architectuur tekeningen ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:59 ) VLOCA assessment ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:58 ) VLOCA donut ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:58 ) Bouwlagen OpenDei ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:22 ) Data Capture ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:22 ) Segment Broker ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:21 ) Segment Capture ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:21 ) Personal Data ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:21 ) Segment Compute ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:20 ) Segment Federation ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:20 ) Segment IAM ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:20 ) Segment Personal Data ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:19 ) Segment Process&Transform ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:19 ) Meer wijzigingen ...t and is provided by Semantic MediaWiki . : 18 april 2024 13:22:19 ) Segment Process&Transform ( Laatste wijziging "Wijzigingsdatum <span style="font-size:small;">(Modification date)</span>" is a predefined property that corresponds to the date of the last modification of a subject and is provided by Semantic MediaWiki . : 18 april 2024 13:22:19 ) Meer wijzigingen ...  +
• Repair cafés worden al recurrent  georgani … Repair cafés worden al recurrent  georganiseerd op verschillende plaatsen in Vlaanderen en daarbuiten. De verwachtingen en wensen van deelnemende partijen tonen aan welke zaken belangrijk zijn bij het organiseren van repair cafés:</br> </br> </br> </br> Stakeholder </br> </br> De droom van de organisatie </br> </br> </br> Repairgroep</br> </br> </br> Een transparante omgeving waar alle informatie die nodig is  om de beste oplossing te vinden, beschikbaar is; </br> Ervaringen en resultaten worden maximaal gedeeld binnen een lerend netwerk; </br> Huidige belemmeringen van herstel weggewerkt, zodat herstellen bijvoorbeeld makkelijk wordt; </br> Wisselstukken kunnen en mogen geoogst worden uit kapotte toestellen. </br> méér herstelcultuur. </br> </br> </br> Repair netwerk</br> </br> </br> Er bestaat een Google voor herstel waar je het type, merk en model ingeeft. Deze search levert je handleidingen, video’s (met index) en andere vormen van hulp op; </br> De tool maakt tevens automatisch vertalingen en is in staat onbetrouwbare van kwalitatieve informatie te onderscheiden. </br> </br> </br> IT</br> </br> </br> Alle hersteldata worden geborgen in 1 overkoepelend data model, met 1 API;Het platform vraagt data op, op zo’n manier dat het weinig extra inspanningen vraagt van de gebruiker;Lijsten van merken, model- en serienummers worden publiek beschikbaar gemaakt. </br> </br> </br> Lokale overheden</br> </br> </br> Beleidsvoorbereidend: Lokale beleidsmakers kunnende benchmark goed in kaart brengen (“nulmeting”) mbv solide data en weten zo beterwaarop in te zetten (beleidsperspectief). </br> Beleidsopvolgend: men heeft real time data beschikbaar waarmee de effectiviteit van een beleidsmaatregel continu wordt opgevolgd; </br> Link met klimaat: hiermee de bijdrage van reparatie aan klimaatdoelstellingen te meten. </br> </br> </br> De Kringwinkel</br> </br> </br> Laagdrempelige informatie waarmee iedereen aan de slag kan; </br> Gegevens worden maximaal gedeeld; </br> Kringwinkel medewerkers leveren goede aanvullende diensten aan commerciële herstellers (bv identificatie). </br> </br> </br> De professionele hersteller</br> </br> </br> Vlotte match making hersteller met het defect toestel; Doordat we weten welke herstellers/vrijwilligers welke vaardigheden hebben en zo gericht kunnen doorverwijzen; Herstel is betaalbaar eveneens geholpen door een goede matchmaking waarbij de buiten garantie herstellingen gericht doorverwezen kunnen worden. Opdeze manier wordt de identificatie door ons gedaan, wat een hulp is voor de vrijwillige hersteller of de burger (DIY repair); </br> </br> </br> Onderzoek – data technisch</br> </br> </br> Data delen is zeer laagdrempelig en makkelijk; </br> Beschikbaarheid van de data bv. Herstelvideo’s is gegarandeerd in de tijd. </br> </br> </br> ABB</br> </br> </br> Kennis wordt gedeeld met de kleinste gemeentes in VL. Geen uitsluitend grootstedelijk verhaal; </br> gebruik van een VLOCA genormeerde data architectuur. </br> </br> </br> Onderzoek  - CE</br> </br> </br> Er bestaan productpaspoorten die uitgebreide informatie-uitwisseling zoals materiaalsamenstelling, reparatie tips & logboeken toelaten. </br> De data kan ook gebruikt worden om voor een gebied (stad, regio, land, continent) beleidsindicatoren voor de circulaire economie te voeden. </br> Er bestaan algoritmes die model specifieke identificatie kunnen doen aan de hand van een foto van het label (in ontwikkeling). </br> productpaspoort </br> </br> Er is een model specifiek beslissingssysteem opgesteld dat op basis van leeftijd en herstelgeschiedenis correcte indicatie geeft van te verwachten faling, wisselstukken, kost, etc.    +