Op eigenschap zoeken

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

Lijst van resultaten

Deelfracties recyclage park +
Deze types kunnen zijn : +
Deze types kunnen zijn : Beheerder HPLayout +
Dia1 +
Dia2 +
Dia3 +
Digitale meldingen slide 1 +
Digitale meldingen slide 2 +
Digitale meldingen slide 3 +
Digitale meldingen slide 5 +
Digitale meldingen slide 6 +
Digitale meldingen slide 7 +
De Web Feature Service (WFS) vertegenwoord … De Web Feature Service (WFS) vertegenwoordigt een verandering in de manier waarop geografische informatie wordt gecreëerd, gewijzigd en uitgewisseld op het internet. In plaats van het delen van geografische informatie op bestandsniveau met behulp van bijvoorbeeld File Transfer Protocol (FTP), biedt de WFS directe fijnkorrelige toegang tot geografische informatie op het niveau van de functie en de eigenschappen van de functie. Deze internationale standaard specificeert discovery operaties, query operaties, lock operaties, transactie operaties en operaties om opgeslagen, geparametriseerde query expressies te beheren.Met behulp van zoekacties kan de service worden ondervraagd om de mogelijkheden ervan te bepalen en om het applicatieschema op te halen dat de kenmerktypen definieert die de service biedt.Queryoperaties maken het mogelijk om functies of waarden van eigenschappen van functies op te vragen uit de onderliggende dataopslag op basis van beperkingen, gedefinieerd door de klant, op de eigenschappen van de functies.Vergrendelingsoperaties maken exclusieve toegang tot features mogelijk met het oog op het wijzigen of verwijderen van features.Transactie operaties maken het mogelijk om kenmerken te creëren, te wijzigen, te vervangen en te verwijderen uit de onderliggende dataopslag.Opgeslagen query operaties maken het mogelijk voor cliënten om geparametriseerde query expressies te creëren, te laten vallen, te laten opsommen en te beschrijven die door de server zijn opgeslagen en die herhaaldelijk kunnen worden aangeroepen met behulp van verschillende parameterwaarden. Deze internationale standaard definieert elf bewerkingen: GetCapabilities (zoekactie) DescribeFeatureType (ontdekkingsoperatie) GetPropertyValue (zoekactie) GetFeature (query-bewerking) GetFeatureWithLock (query & vergrendeling) LockFeature (vergrendeling) Transaction (transactieverrichting) CreateStoredQuery (opgeslagen query-bewerking) DropStoredQuery (opgeslagen query-bewerking) ListStoredQueries (opgeslagen query-bewerking) DescribeStoredQueries (opgeslagen query-bewerking)pgeslagen query-bewerking) +
De defintie van Open Data vinden we terug … De defintie van Open Data vinden we terug op de website van Smart Flanders : https://smart.flanders.be/open-data-charter/ Daarbij is er ook een open data charter opgesteld. Wanneer er naar open data verwezen wordt, hanteren we de definitie zoals geformuleerd op [1] . Deze stelt dat open wil zeggen dat gegevens vrij toegankelijk zijn, gebruikt, verwerkt en gedeeld mogen worden door eenieder en voor elk doel. Hieronder vallen geen persoonsgegevens of privacy-gevoelige data, noch data waarvan de ontsluiting bestaande regelgeving zou overtreden. Data worden gepubliceerd in open en machine-leesbare formaten zoals bvb JSON, XML, CSV, etc. Op deze [2] zijn enkele voorbeelden te vinden. En hier [3] is het decreet rond hergebruik van overheidsinformatie terug te vinden. Open data vormen de basis van innovatieve smart city oplossingen en wanneer deze opgengesteld worden zodat burgers, kleine en grote bedrijven, het middenveld en andere geinteresseerde partijen ze ook kunnen hergebruiken, wordt dit potentieel gemaximaliseerd.Het Open Data Charter [4] lijst de principes op die van belang zijn bij het voeren van een duurzaam en gemeenschappelijk open data beleid. ↑ https://opendefinition.org ↑ https://www.youtube.com/watch?v=c42QNa-rccw ↑ https://www.google.com/url?q=https://codex.vlaanderen.be/PrintDocument.ashx?id%3D1016299%26datum%3D%26geannoteerd%3Dfalse%26print%3Dfalse&sa=D&ust=1593418655069000&usg=AFQjCNGQmA7zF4ZuKU-l8ikJMatidccrYg ↑ https://www.google.com/url?q=https://drive.google.com/open?id%3D1esUeKOP2BcOzWk3pn4xpJ6MBh9VOQkov&sa=D&ust=1593418655067000&usg=AFQjCNHV9PrREC-Y3Ghd5t_K3R-2G7Rnmwmp;usg=AFQjCNHV9PrREC-Y3Ghd5t_K3R-2G7Rnmw +
De eerste implementaties van slimme steden … De eerste implementaties van slimme steden in India beginnen ter plaatse positieve resultaten op te leveren. Ze werden grotendeels onafhankelijk gecreëerd in verticale silo's, met een beperkte standaardisatie van software Componenten of hun interfaces of de onderliggende datamodellen. De gegevens die door een specifieke applicatie worden gecreëerd, zijn meestal enkel beschikbaar voor die applicatie en kunnen niet breder worden ingezet. Dit beperkt de mogelijkheid om bredere inzichten te verkrijgen uit de enorme gegevens die binnen elk project & afdeling worden gegenereerd, voor gebruik tussen verschillende belanghebbenden binnen de stad en in verschillende steden. Om deze uitdagingen op te lossen, heeft MoHUA het initiatief genomen tot een onderzoeksproject onder leiding van Prof. Bharadwaj Amrutur van het Indian Institute of Science (IISc), Bangalore, getiteld "India Urban Data Exchange (IUDX)" [1] , een open source softwareplatform dat steden in staat moet stellen het volledige potentieel van de enorme data die in onze smart cities worden gegenereerd te benutten. Indian Institute of Science (IISc), Bangalore, werkt samen met een breed scala aan instellingen bestaande uit de industrie, overheidsinstellingen, start-ups, ondernemers, andere academies en onderzoeks Organisaties , om de eerste specificaties en referentie-implementatie van IUDX te ontwikkelen. Overzicht Om de volgende generatie op AI/ML gebaseerde toepassingen te ontwikkelen voor het leveren van nieuwe oplossingen en diensten op schaal, heeft IUDX een referentiearchitectuur [2] en technische specificaties [3] gecreëerd voor het blootleggen van gegevens (met name IoT-gegevens) van IT-systemen van verschillende afdelingen en externe Organisaties , met behulp van gemeenschappelijke API's [4] en gegevensmodellen [5] . De gegevensuitwisseling zal drie belangrijke diensten leveren: Een catalogusdienst die een catalogus met meta-informatie over de verschillende datasets zal hosten, met informatie over de beheerder van de gegevens, het datamodel voor de gegevens, de API-eindpunten, de API-methoden, enz. Een autorisatiedienst die een data custodian (die verantwoordelijk is voor de data) in staat stelt de toegang tot hun datasets te reguleren. Beveiliging en privacy zijn door het ontwerp in deze architectuur opgenomen. Een optionele data-broker, die gestandaardiseerde IUDX-API's zal ondersteunen om toegang te krijgen tot de data. Referentie architectuur Scope De Indiase standaard beschrijft de referentiearchitectuur voor het gegevensuitwisselingskader, de interfaces van de gegevensuitwisselings Componenten en de use cases die in dit ecosysteem worden ingeschakeld. Het beschrijft ook de verantwoordelijkheden van de verschillende belanghebbenden en hun interacties met andere belanghebbenden in het systeem. De norm beschrijft ook de high level architectuur van de volgende drie hoofd Componenten van de gegevensuitwisselingsdiensten: Catalogusdienst die een kader biedt voor het beheer van meta-informatie over bronnen, Autorisatiedienst, die de autorisatie beheert om toegang te krijgen tot de bronnen Resource Access Service, die een gestandaardiseerde manier biedt om toegang te krijgen tot bronnen. Principes De referentiearchitectuur en het ontwerp die in deze norm worden beschreven, is gebaseerd op devolgende principes: Technologie-agnostisch Betrouwbaarheid en schaalbaarheid Privacy-by-design Security-by-design Consumentgericht Consent-driven Open API's voor interoperabiliteit Transparantie door middel van gegevens High Level Architectuur De Data-uitwisseling bestaat uit de volgende interfaces: Resource-interface Autorisatie-interface Discovery-interface Management-interface Authorisatie-interface Identity-interface Middelen, beheerd door een Provider, worden gehost op een of meer Resource Servers, en worden beschikbaar gesteld voor consumptie aan entiteiten via een beschrijving van de meta-informatie (zoals het formaat, de Provider, enz.), via een catalogus in de Data Exchange. De catalogus is zowel menselijk leesbaar als machinaal leesbaar . De aanbieder registreert en beheert de metagegevens van zijn middelen en het bijbehorende toegangscontrolebeleid via de beheersinterface van de gegevensuitwisseling. De Provider kan gebruik maken van een helper-applicatie, zoals de ProviderApp. De meta-data van elke resource moet een app-ontwikkelaar helpen om het gebruik van resources te vergemakkelijken en zo nuttige applicaties voor de consument te creëren. De App kan zich registreren bij de DataExchange om op de hoogte te worden gesteld van eventuele wijzigingen in de meta-data van de bronnen die voor de Consument van belang zijn. De App verkrijgt toestemming om de bronnen te consumeren via de autorisatie-interface door het verkrijgen van een Autorisatie Token. Elk verzoek aan de bron van een aanbieder door een consumentenapplicatie zal worden gecontroleerd aan de hand van het bestaande toegangscontrolebeleid . Als er geen beslissing kan worden genomen, zal de Gegevensuitwisselingde Aanbieder en de Consument te coördineren om een toestemmingstransactie af te ronden en het Autorisatietoken te genereren. Het Autorisatietoken zal worden gebruikt om het toegangscontrolebeleid voor deze middelen bij te werken. Het Autorisatietoken zal door het systeem worden gelogd om de controleerbaarheid van de toestemmingsstromen te garanderen. De coördinatie tussen de aanbieder en de consument gebeurt buiten het kader van deze specificatie en kan worden opgebouwd met behulp van alle beschikbare berichttechnologieën, zoals SMS/OTP/EMAIL, enz. De licentievoorwaarden voor de gegevens vallen ook buiten het toepassingsgebied van deze specificatie. De licentievoorwaarden vallen ook buiten het toepassingsgebied van deze specificatie. In de metagegevens voor de bron kan echter wel naar de licentie worden verwezen. Om te zorgen voor een betere consumentenervaring, kan de App-ontwikkelaar ook het volgende invoeren in een grondstoffenlicentieovereenkomst met de aanbieder. In dit geval kan de consument beschermd tegen het apart verkrijgen van toestemming, zolang de App Developer en de App zich te houden aan de licentievoorwaarden van de aanbieder. Catalog Service Op hoog niveau maakt de DX-catalogusdienst het volgende mogelijk: Discovery of data resources : door het aanbieden van verschillende zoekmechanismen om de interessante bronnen te ontdekken. Bijvoorbeeld, geo-gebaseerd zoeken, tekst zoeken op meta-informatie, attribuut zoeken met een bepaalde waarde, enz. Gemak van de consumptie van gegevens : door het verstrekken van links naar gegevensmodellen die de verschillende attributen van de gegeven bron beschrijven. Dit verbetert de interoperabiliteit van de gegevens en maakt het eenvoudiger om ze te integreren in verschillende toepassingen. Semantische modellering van meta-informatie : Door gebruik te maken van gekoppelde gegevens om semantische contexten te bieden voor de attributen die meta-informatie beschrijven. Dit leidt tot een betere machineleesbaarheid, interpreteerbaarheid, operationele interoperabiliteit en maakt hergebruik van woordenschat uit andere gegevensmodelarchieven en taxonomieën mogelijk. Gemak van toegang tot gegevens uit een bron : door formele beschrijvingen te geven van hoe toegang kan worden verkregen tot de gegevens uit een bron. Bijvoorbeeld, API-objecten om op REST gebaseerde bronnen te beschrijven, enz. Catalog Datamodel De figuur vat het catalogus-informatiemodel samen. De basislaag bestaat uit kern-attribuuttypes. Een attribuut zal in het algemeen een 'type' en 'value' hebben en kan andere meta-eigenschappen hebben om het attribuut aanvullend te beschrijven. Het 'type' identificeert het type kernattribuut en heeft een van de volgende waarden: "Eigenschap", "Relatie", "GeoProperty", "QuantitativeProperty" en "TimeProperty". De 'value' bevat de waarden die aan het attribuut zijn toegekend en kan variëren van eenvoudige objecten, zoals strings of getallen, tot complexe objecten, zoals ' GeoJSON ' objecten, enz. Gemeenschappelijke attributen, die noodzakelijkerwijs een van de kern-attribuuttypen uitbreiden, dienen om een specifieke betekenis en interpretatie te geven aan een attribuutwaarde. Er zijn gemeenschappelijke attributen gedefinieerd om veelgebruikte concepten in DX-catalogus-items vast te leggen. Verder zijn alle verplichte attributen in verschillende catalogusitems noodzakelijkerwijs afkomstig uit de gemeenschappelijke attribuutenset. Een itemType wordt gebruikt om een semantische interpretatie te beschrijven en te geven aan een collectieve set van attributen in een item. Elk itemType specificeert een set verplichte attributen die moet worden opgenomen in een item van dit itemType en deze attributen behoren noodzakelijkerwijs tot de gemeenschappelijke attribuutset. Een gegevensmodel beschrijft meta-informatie-attributen en hun syntactische structuur voor een bepaald toepassingsdomein. Het raamwerk van de catalogus maakt, met behulp van de concepten van gekoppelde gegevens, hergebruik van attributen uit andere domeinspecifieke vocabulaires mogelijk. Merk op dat het definiëren van een specifiek gegevensmodel valt buiten het bestek van de catalogus. Echter, omwille van de consistentie, moeten de in de gegevensmodellen gedefinieerde attributen dezelfde algemene reeks volgen van regels, die later worden gespecificeerd, zoals die worden gevolgd voor DX-metagegevensattributen. De bedoeling is hier een robuust kader te specificeren dat het mogelijk maakt te specificeren, te hergebruiken en een consensus te bereiken voor domeinspecifieke gegevensmodellen. De relaties tussen de objecten in de data catalogus kunnen als volgt worden weergegeven: Referenties ↑ https://www.iudx.org.in/ ↑ https://docs.google.com/document/d/e/2PACX-1vS7TvNSuQrbWGwwKEvVHZpquGg5bWmyvEtKv0I9fFvyBDZFWtm4UdV1e6DLtzkX4IRaGPMhztMButbQ/pub ↑ https://docs.google.com/document/d/e/2PACX-1vQBG5blEcxzm_WUnwaWMFRW3jmfBo2VyG-SgK7Aacbw0YpEhR1i80ZOOMGzQG_PxH5IDNamVkVOu7C4/pub ↑ https://apidocs.iudx.org.in/ ↑ https://github.com/rbccps-iisc/iudx-schemas +
De gefaalde stofzuigers die men nog zou ku … De gefaalde stofzuigers die men nog zou kunnen repareren maar de reparatie niet door kon gaan gezien er wisselstukken, handleidingen en/of beschikbaarheid van een 3D printer,… ontbraken en die nog niet “oud” zijn, zijn gemiste kansen. Door enkele systeemverbeteringen door te voeren, waar een stad in kan helpen (bijvoorbeeld door te investeren in een 3D printer of andere reparatiemiddelen, opleidingen voor vrijwilligers te organiseren,…) zouden deze wel gerepareerd kunnen worden. De data kan de stad tevens helpen bij het evalueren van zo’n investeringsbeslissing. Ze geeft immers inzage in de specifieke barrière. Als men tevens ook weet welke onderdelen geprint zouden kunnen worden, of gemaakt doordat een hulsel, dopje,… zou kunnen geprint worden, weet men dus hoeveel reparaties toch succesvol zouden kunnen doorgaan en dus hoeveel CO2 hiermee zou kunnen uitgespaard worden. +
De ontologie van het Semantisch Sensor Net … De ontologie van het Semantisch Sensor Netwerk (SSN) is een ontologie voor het beschrijven van sensoren en hun waarnemingen, de betrokken procedures, de bestudeerde interessante kenmerken, de gebruikte monsters en de geobserveerde eigenschappen, alsmede de actuatoren. SSN volgt een horizontale en verticale modulariseringsarchitectuur door het opnemen van een lichtgewicht maar op zichzelf staande kernontologie die SOSA (Sensor, Observation, Sample en Actuator) wordt genoemd voor zijn elementaire klassen en eigenschappen. Met hun verschillende reikwijdte en verschillende graden van axiomatisering zijn SSN [1] en SOSA [2] in staat om een breed scala aan toepassingen en use cases te ondersteunen, waaronder satellietbeelden, grootschalige wetenschappelijke monitoring, industriële en huishoudelijke infrastructuren, sociale sensing, burgerkunde, observatiegedreven ontologietechniek, en het Web of Things. The following figure provides an overview of the core classes and properties that are secifically related to modeling Actuations. SOSA axioms are shown in green, while SSN-only axioms are shown in blue. [[Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]] Referenties ↑ http://www.w3.org/ns/ssn/ ↑ http://www.w3.org/ns/sosa//www.w3.org/ns/sosa/ +
De oorspronkelijke Intercommunale Land van … De oorspronkelijke Intercommunale Land van Aalst is naar aanleiding van het nieuwe decreet sinds 23 oktober 2003 opgesplitst in twee intergemeentelijke samenwerkingsverbanden. De milieuactiviteiten zijn ondergebracht in ILvA, het Intergemeentelijk samenwerkingsverband voor milieu. Het neemt de activiteiten op het vlak van afvalpreventie, afvalinzameling en afvalverwerking voor haar rekening. SOLVA is een dienstverlenend samenwerkingsverband dat vooral actief is op het vlak van ruimtelijke ordening en socio-economische expansie. Meer informatie is hier beschikbaar.ie. Meer informatie is hier beschikbaar. +
De primaire focus van de Sensor Model Lang … De primaire focus van de Sensor Model Language (SensorML) is om een robuust en semantisch gekoppeld model te bieden voor het definiëren van processen en verwerkings Componenten in verband met de meting en post-metingstransformatie van waarnemingen. Dit omvat zowel sensoren en actuatoren als rekenkundige processen die voor en na de meting worden toegepast. Het hoofddoel is om interoperabiliteit mogelijk te maken, eerst op syntactisch niveau en later op semantisch niveau (door gebruik te maken van ontologieën en semantische bemiddeling), zodat sensoren en processen beter kunnen worden begrepen door machines, automatisch kunnen worden gebruikt in complexe workflows en gemakkelijk kunnen worden gedeeld tussen intelligente sensor-webknooppunten. Deze standaard is een van de verschillende implementatie Standaarden die onder OGC's Sensor Web Enablement (SWE) activiteit worden geproduceerd. Deze standaard is een herziening van de inhoud die eerder werd geïntegreerd in de SensorML versie 1.0 standaard (OGC 07-000). [[Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]]pen Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]] +
De smart data models is een programma dat … De smart data models is een programma dat geleid wordt door fiware , OASC , TM Forum en Indian Urban Data Exchange (IUDX) . Het doel is om data modellen te verzamelen die gebruikt kunnen worden als shared data models. De organisatie biedt een aantal tools aan om met data models om te gaan zoals: een zoek funcitonaliteit over alle data modellen scripts om vanuit andere bronnen data modellen te genereren scripts om voorbeelden te genereren scirpts om data modellen te valideren De data modellen zijn gebaseerd op NGSI-LD , maar kunnen ook andere standarden supporteren. Referenties [1] Smart Data Models website [2] Smart Data models Githubels website [2] Smart Data models Github +
De tweede thematische werkgroep rond MLaaS … De tweede thematische werkgroep rond MLaaS 'Marktplaats' vond plaats op 15 mei 2024. Context Initiatief De stad Roeselare beschikt reeds over verschillende machine learning algoritmes die data genereren op basis van fotomateriaal en is hiervoor in contact met verschillende partijen. Deze data wordt gebruikt in zowel operationele processen als bij het nemen van beleidsbeslissingen. De opzet van het project is om een platform te bouwen dat toegankelijk is voor steden en gemeenten. Op dit platform wenst Roeselare en aanbod te publiceren van beeldmateriaal en data om beleidsdoelstellingen te ondersteunen zoals inventaris wegmarkeringen op het grondgebied, inventaris vegetatie op het grondgebied en inventaris van wegdekmaterialen en de kwaliteit ervan. Dit biedt een aantal voordelen, nl: Schaalvoordeel Lagere kostprijs Relatief frequente beschikbaarheid van recente data Minder afhankelijk van technische kennis & expertise (beeldresolutie, algoritmes, etc) Laagdrempelige toegang tot deze informatie Met het streven naar het opschalen van bestaande machine learning processen, het uitrollen van nieuwe mogelijkheden en deze via een platform als een service ter beschikking te stellen van alle overheden wensen de initiatiefnemers niet alleen zorgen voor meer data op Vlaams niveau maar ook voor “massa productie” aan een betaalbare prijs. Dit alles kadert een groter geheel rond het City dashboard dat Roeselare enkele jaren geleden opgestart is. Hierbij is men gestart met het verzamelen van mobiele beelden en luchtbeelden. Deze data heeft men verzameld en verwerkt in een City dashboard. Het project bestaat uit 3 pijlers: Beeldmateriaal In de eerste fase ligt de focus op het verzamelen van input. Hierbij worden de noden/mogelijkheden rond het gebruik van luchtbeelden in kaart gebracht op basis van beeldresolutie, prijs en frequentie van beeldbeschikbaarheid. In een volgende fase volt de analyse data verwerking. Hierbij wordt een matrix opgesteld van alle mogelijke soorten luchtbeelden die beschikbaar zijn met telkens de voor-en nadelen per beeldsoort. Machine learning algoritmes In de eerste fase van deze pijler wordt input verzameld. Hierbij worden de noden in kaart gebrecht rond de gevraagde machine learning algoritmes. Het uitgangspunt hierbij is een bestaande lijst binnen stad Roeselare met de volgende onderwerpen: wat zou er mogelijk moeten zijn via machine learning algoritmes, uitbreiden en aftoetsen met andere deelnemende besturen (andere noden), nagaan wat er reeds bestaat op de markt. Daarnaast is het belangrijk om de technische noden per algoritme te bepalen: inputvereisten van het beeldmateriaal en toelaatbare foutenmarge van het algoritme moet vastgelegd worden. Output zoals kaarten, databank voor de inventaris, GEO loket, BI dashboard etc maken hier ook deel van uit. De tweede fase is gericht op de aanbesteding. Hierbij wordt bepaald op welke manier het algoritme kan ontwikkeld of hergebruikt worden. Tijdens de derde en laatste fase gaat men over naar de realisatie van het algoritme en de verwerking van de data. Platform Momenteel hebben de initiatiefnemers een high level concept voor ogen. Het is belangrijk dat dit concept vertaald wordt naar functionele en technische vereisten en dat er vorm gegeven wordt aan de architectuur van het platform. Daarnaast moet er een businessmodel voor het gebruik van het platform gecreëerd worden. Hierbij moet men stilstaan bij de volgende vragen: wie zijn de gebruikers, hoe krijgen ze toegang, wat kunnen ze kopen, wat met het licentiemodel, duidelijkheid rond pay per use, pay per login, pay per area etc. VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. VLOCA-model Momenteel hebben we reeds 2 werkgroepen achter de rug, telkens met een verschillende focus. Bij de eerste werkgroep stonden we stil bij groen inventarisering: En bij inventarisering wegkwaliteit: Vandaag leggen we de focus op het gedeelte rond marktplaats. Hierbij hoort een nieuw VLOCA-model: ID Status Samenvatting Beschrijving UC1 Voorstel UC1: Marktplaats Mgt Marktplaats Management die moet zorgen voor kwaliteitsvolle inhoud, veiligheid en 'fairness' op het platform UC2 Voorstel UC2: Registratie & login Registratie van gebruikers die toegangen (willen) hebben op het platform ifv hun toegekende rechten UC3 Voorstel dr Bouwplatform as a service die gebruikers toelaat om hun modellen zelf te bouwen op het platform UC4 Voorstel UC4: Run aaS Run as a service die gebruikers toelaat om een gekozen model uit de bibliotheek te draaien op hun eigen input data UC5 Voorstel UC5: Bibliotheek Modellen Bibliotheek van modellen die toegang verleent aan machine learning modellen (algoritmen) evt tegen betaling UC6 Voorstel UC6: Model Governance Model Governance die bepaalt wie wat mag aanpassen, wie rechten heeft voor wat, enz. UC7 Voorstel UC7: Helpdesk & Feedback Helpdesk bij issues alsook feedback kunnen geven over de services, kwaliteit modellen of haar documentatie, enz UC8 Voorstel UC8: Betalingen Betalingen kunnen uitvoeren op het platform met facturatie mogelijkheden UC9 Voorstel UC9: CRM Communicatie met bouwers, eigenaars en gebruikers van modellen/algoritmes UC10 Voorstel UC10: Samenvatting UC10: Beschrijving Waarom hebben we nood aan een marktplaats? Uit de vorige 2 werkgroepen kwamen er verschillende valkuilen naar boven waaronder: een gebrek aan lokale expertise en budgetten een complexiteit aan 'generieke' raamovereenkomsten een problematiek van de beeldmaterialen die al dan niet passend zijn voor de aangeboden algoritmes De marktplaats zou potentieel een oplossing kunnen bieden voor deze 3 valkuilen. In de sessie van vandaag reflecteren we over de centrale rol die een marktplaats inneemt tussen leverancier & klant en beeldmateriaal & algoritme: essentieel hierbij is de vraag hoe we de leverancier naar de klant brengen en hoe we diegene die een model gebouwd heeft, naar de stad die er op dat moment nood aan heeft. De tweede focus is de link tussen het beeldmateriaal en het algoritme. Je kan een algoritme hebben maar niet noodzakelijk het juiste beeldmateriaal en omgekeerd. Een slimme marktplaats zou de leveranciers en de klanten bij elkaar kunnen brengen en kan de link tussen een algoritme en beeldmateriaal kunnen optimaliseren. In de huidige situatie gaan leveranciers/producenten en klanten/consumenten rechtstreeks met elkaar in contact. Door een marktplaats te installeren, verloopt dit proces gecentraliseerd. Op deze marktplaats vinden producenten en consumenten alle informatie terug en kunnen ze diensten vergelijken. Het gaat voor alle duidelijkheid niet enkel over private leveranciers maar ook lokale besturen die reeds een model gebouwd hebben, krijgen de mogelijkheid om dit te delen met anderen. Daarnaast is het een misvatting om te veronderstellen dat beeldmateriaal en algoritmes eenvoudig gecombineerd kunnen worden. Het is niet zo simpel als een "drag and drop"-systeem waarbij je een willekeurig algoritme op een willekeurige foto toepast en de verwachte output krijgt. Het idee dat een algoritme altijd accuraat werkt met elk soort beeldmateriaal klopt niet. In werkelijkheid werken bepaalde algoritmes alleen goed met specifieke types van beeldmateriaal. Bijvoorbeeld, een algoritme dat ontworpen is voor satellietbeelden zal mogelijk niet goed functioneren met dronebeelden, en kan dan verkeerde resultaten opleveren. Het is belangrijk om goed geïnformeerd te zijn om te voorkomen dat verkeerde beslissingen worden genomen of verkeerde data wordt gebruikt. Het doel van vandaag is tweeledig : ten eerste is het doel dat de slimme marktplaats kan adviseren welk beeldmateriaal bruikbaar is met welk algoritme, en omgekeerd welk algoritme geschikt is voor een bepaald type beeldmateriaal. Dit voorkomt dat gebruikers, zoals steden, een algoritme aanschaffen dat niet compatibel is met hun beschikbare beeldmateriaal. De marktplaats moet als een makelaar functioneren die compatibele producten koppelt, zodat je weet welke beeldmaterialen werken met welke algoritmes. Het systeem moet intelligent genoeg zijn om verkeerde combinaties te voorkomen. Zodra je een bepaald beeldmateriaal kiest, zouden alleen de compatibele algoritmes beschikbaar moeten zijn. Het doel is om een slimme marktplaats te ontwikkelen die kan adviseren welk beeldmateriaal bruikbaar is met welk algoritme en omgekeerd. Dit voorkomt dat gebruikers, zoals steden, een algoritme aanschaffen dat niet compatibel is met hun beschikbare beeldmateriaal. De marktplaats moet als een makelaar functioneren, compatibele producten koppelen, en ervoor zorgen dat verkeerde combinaties worden vermeden. Zodra je een bepaald beeldmateriaal kiest, zouden alleen de compatibele algoritmes beschikbaar moeten zijn. Daarnaast is het belangrijk te erkennen dat bepaalde algoritmes soms gefinetuned moeten worden om optimaal te werken met nieuw of verschillend beeldmateriaal. Bijvoorbeeld, als er nieuwe versies van foto's binnenkomen of foto's uit een andere regio worden gebruikt, moet het algoritme mogelijk worden aangepast. De marktplaats kan hierbij helpen door aan te geven hoe het beeldmateriaal verwerkt moet worden om geschikt te zijn als input voor een algoritme, zoals het aanpassen van het formaat. Samengevat, de marktplaats heeft twee hoofdtaken: Het koppelen van beeldmateriaal aan de juiste algoritmes op basis van de gewenste output. Het ondersteunen van fine-tuning door aan te geven of er aanvullende dataverwerking nodig is, en deze verwerking ook aan te bieden. Het systeem moet bidirectioneel werken: niet alleen beeldmateriaal aan algoritmes koppelen, maar ook aanbevelingen geven voor welk beeldmateriaal en welke algoritmes geschikt zijn voor specifieke use cases. Hierdoor kunnen gebruikers altijd de meest geschikte combinatie vinden. De focus ligt op de ontwikkeling van een slimme marktplaats die efficiënt kan adviseren welk beeldmateriaal bruikbaar is met welk algoritme en omgekeerd. Hierbij willen we de technische aspecten, zoals hoe data wordt opgeslagen of via API's toegankelijk wordt gemaakt, vandaag grotendeels buiten beschouwing laten. De nadruk ligt op de intelligentie achter de schermen: hoe bepalen we welke data aan welke algoritmes gekoppeld moet worden? Daarnaast zijn er andere belangrijke aspecten van de marktplaats om te overwegen, zoals marketing, klantwerving, het financiële aspect, en juridische kwesties. Het is essentieel om een balans te vinden tussen het aantrekken van klanten en leveranciers. Zonder klanten zijn leveranciers niet geneigd hun producten op de marktplaats te zetten, en zonder producten zijn er geen klanten. Dit kip-of-ei-probleem vereist een strategische aanpak in marketing en sales om exponentiële groei te stimuleren. Het financiële aspect omvat vragen over het kopen of huren van data, en het juridische aspect behandelt de verantwoordelijkheden en geschillen, zoals wat te doen als de gekochte data niet aan de verwachtingen voldoet. Al deze elementen moeten goed beheerd worden om een succesvolle en functionele marktplaats te creëren. Buiten de scope van deze bespreking vallen: De technische details van data-opslag en API-toegang. Specifieke implementaties van het platform. Infrastructuurbeheer en schaalbaarheid van het platform. Technische beveiligingsmaatregelen. Gedetailleerde operationele procedures en onderhoud. Door deze aspecten buiten beschouwing te laten, kunnen we ons volledig richten op het ontwikkelen van de slimme en strategische onderdelen die de kern vormen van een succesvolle marktplaats. Brainstormsessie Doel Het doel van de brainstormsessie is het volgende: Intelligente link leggen tussen beelden en algoritmes Identificatie van de meerwaardecreatie Inzicht in wat je nodig hebt om de meerwaardecreaties te realiseren Beschrijven van mogelijkheden om de oplossing te verduurzamen Opsommen van valkuilen en potentiële principes waaraan de oplossing moet voldoen Oefening 1 Bij deze oefeningen stonden we stil bij de volgende vragen: 1) Geef een paar (concrete) voorbeelden van issues 2) Hoe zouden we dit intelligenter kunnen maken? 3) Geef een paar voorbeelden die dit concept al realiseren Overzicht Issues Acties om het slimmer te doen werken Voorbeelden die dit concept al realiseren dronebeelden zijn niet dezelfde als sattelietbeelden ArcGIS Living Atlas of the World https://livingatlas.arcgis.com/en/browse/?q=deep%20learning#q=deep+learning&d=2 de leverancier van beeldmateriaal van een vorige vlucht is niet meer operationeel in ons gebied en spec's v/d foto's wijzigen een matrix met vergelijkbaar beeldmateriaal voorzien (o.b.v. objectieve kenmerken zoals resolutie, hoogte v/d camera, kleurbanden RGB/Infrarood/...) en zo een alternatief beeldmateriaal voorstellen ArcGIS Marketplace https://www.esri.com/en-us/arcgis-marketplace/overview Leveranciers van beelden die enkel partners toelaten op de beelden te werken verplichten dat leveranciers van algoritmes, algoritmes aanbieden die beeld leverancier agnostisch zijn en enkel rekening houden met belangrijke beeld specs (zoals type beeld materiaal; resolutie) Up42 approach Leveranciers van beelden leveren ook vaak de algorimes. Hoe overtuig je ze om dit te splitsen. afspraken/contracten maken waarbij er een 'fee' per gebruik v/h algoritme/beeld naar de leverancier(s) van gaat https://www.djustconnect.be/nl/ConnectShop verplichten dat beeld leveranciers toelaten dat andere algoritmes op hun beelden worden lostgelaten (ze nemen dan ook geen verantwoordelijkheid voor de verwerking). Hier hangt ook een IP aspect aan vast => wie is eigenaar van de beelden? stel: 3 firma's die beelden aanleveren aan de 'slime marktplaats' bij n firma zijn slechts enkele klanten => werk je dan met op voorhand vastegelegde prijzen? wat als de firma zich terugtrekt uit dit project (wegens gebrek aan klanten) => hebben de klanten dan recht op de beelden die al waren aangeleverd? Tijd van het jaar: Zomer vs Winter algoritmes (groen/bomen) Algoritmes zijn getraind op een set van beelden en werken dus inderdaad alleen hierop. Tenzij ze hertraind worden. zien we dat ook als onderdeel hiervan ? Hoe garanderen dat algoritmes werken op verschillende type beelden (drone, sat, MobileMapping) => een algoritme per type data een must? op een home- of statuspagina van de marktplaats een soort van actuele toestand weergeven van de beschikbare algoritmes en beschikbare beeldmaterialen. Op die manier wordt er weergegeven wat wel en niet mogelijk is qua vragen of output Versionering van de algoritmes : hoe overzichtelijk houden ? opkuis van oude niet meer relevante items Hoe kunnen we vertrouwen cre ren tussen data leveranciers en de marktplaats? Een onafhankelijk clearing house opzetten Athumi - Het Vlaams Datanutsbedrijf verschil in "theoretische" spec's (technisch zoals camera, resolutie, ...) vs de realiteit (ander lichtinval, bewolking, ..) automatische objectieve kwaliteitscontroles / scores op beeldmatriaal voorzien (validatie) analoog zoals bv. "monitoring datakwaliteit" van brondata i.f.v. DWH ontwikkelingen (bv. afdwingen van geldige rijksregisternrs, GRAR-adressen, wanneer dit niet door de brontoepassing gevalideerd wordt) Stockage van resultaten incl. historiek => datamodel van marktplaats moet hierop zijn afgestemd of waar wordt deze stockage verondersteld te gebeuren? Beelden klaarmaken voor verwerking in verschillende algoritmes is niet altijd hetzelfde => integratie pre-processing steps in de marktplaats? Hoe ga je om met verantwoordelijkheden op het einde van het verhaal? Slechte data? Slecht algoritme? Slechte integratie/applicatie/ visualisatie? Data lineage van beslissingen (je neemt een beslissing, van waar, en hoe ben je tot die beslissing gekomen) Wat gaan we doen met de feedback loop (reviews, welke deel van de beslissing was correct, wat niet). Deze kan heel waardevol zijn voor de algoritme leverancier Kunnen ook enkel beelden aangekocht worden. en in eigen toepassingen gebruikt worden Krijgen algoritme bouwers toegang tot grote sets om te trainen Hoe continuiteit garanderen? Zowel blijven supporteren van bestaande als doorontwikkelen of verbeteren van algoritmes hoe organiseer je het wervingsproces voor (nieuwe) beelden en algoritmes? Hoe zorg je er voor dat het platform relevant blijft door een grotere 'menukaart' van algoritmes aan te bieden aan de eindgebruikers? Gebruiksrechten van satellietbeelden zijn beperkt tot welbepaald aantal gebruikers (licentie pricing) => hoe hiermee omgaan? Doelstelling uberhaupt om in deze marktplaats. sat. beelden integreren? 1) Met een intermediaire sat. beeld leverancier werken waarmee offline kan worden ge nterageerd om de beelden te bestellen (in dat geval specifieke data space voor dit soort data voorzien in de marktplaats) 2) Een component voorzien die de bestelllingen met de verschillende sat. leveranciers kan voorzien Kunnen algoritmes koppelen met resultaten van andere algoritmes. bv boom x is al herkend, kan deze al als input gebruikt worden bij start volgende algoritme een bepaalde use case is nog niet uitgewerkt met bestaande algoritmes. Kan dit op aanvraag? Rechtstreeks met leverancier contact opnemen of bij voldoende vragen (requests) door het platform in de markt zetten? Discussie Data Science en Beeldverwerking Intelligente link tussen beelden en algoritmes is essentieel. Problemen zoals incompatibiliteit van beeldmateriaal met algoritmes en noodzaak voor fine-tuning van algoritmes werden besproken. Voorbeelden gevraagd van concrete problemen en oplossingen in beeld- en algoritme-integratie. Belang van een intelligent systeem om ondeskundig gebruik van data en algoritmes te voorkomen. Intelligente Marktplaats Idee van een slimme marktplaats voor koppeling van klanten, leveranciers, data, en algoritmes. Voorbeelden van bestaande intelligente marktplaatsen gezocht ter inspiratie. Praktische Voorbeelden en Uitleg Uitleg over hoe een Miro-bord gebruikt kan worden voor brainstormen en noteren van issues. Verschillende manieren om interactief en visueel te werken met de input van alle deelnemers. Problemen en Oplossingen Voorbeelden van technische problemen: compatibiliteit van algoritmes met verschillend beeldmateriaal, afhankelijkheid van specifieke leveranciers, seizoensgebonden verschillen in beeldmateriaal, versioning van algoritmes. Voorstellen voor oplossingen: goede datacatalogus, automatische detectie van data-algoritme compatibiliteit, versioning overzicht, neutrale clearing house, integratie preprocessing stappen in de marktplaats, feedback loops voor algoritmes, etc. Juridische en Contractuele Zaken Beperkingen in gebruiksrechten van beeldmateriaal en licentieproblemen. Juridische vragen over eigendom en gebruik van beeldmateriaal en algoritmes. Belang van duidelijke afspraken en contracten, inclusief fee-per-gebruik modellen en IP-aspecten. Beheersaspecten en Vertrouwen Vertrouwen tussen data leveranciers en marktplaats. Oplossingen zoals onafhankelijke clearing houses en gedetailleerde metadatabeschrijvingen. Feedback en Continuïteit Belang van een feedback loop voor continue verbetering van algoritmes. Manieren om algoritmes te trainen met gebruikersfeedback en andere gegevensbronnen. Technische Integratie en Ondersteuning Noodzaak voor een geïntegreerde omgeving voor data en algoritmes. Voorbeelden van bestaande platforms zoals de Esri Living Atlas en andere marketplaces die als model kunnen dienen. Discussie over centrale vs. gedeelde marktplaatsen en hoe data en algoritmes over verschillende platforms kunnen worden uitgewisseld. Oefening 2 + 3 In deze oefening gaan we op zoek naar meerwaardecreatie: Wat zijn de specifieke voordelen van dit platform voor potentiële klanten en leveranciers van groen en wegen? Waarom zouden leveranciers en potentiële klanten bereid zijn om bij te dragen aan zo een platform ? Lijst de verschillende redenen op en geef ook aan voor wie dit interessant kan zijn. Voorbeeld: -Steden die zelf geen data scientist hebben, kunnen gebruik maken van dit Marktplaats platform. -Steden kunnen hun eigen oplossingen ook op de marktplaats zetten voor andere steden ervolgens gaan we de waardecreatie toepassen: Wat heb je nodig om de geïdentificeerde meerwaardecreaties uit de voorgaande oefening te realiseren? Lijst de acties op Voorbeeld: -Betrouwbaar en gemakkelijk om terug te vinden wat je zoekt=> voorstelling leveranciers, catalogus van ML met bijbehorende beelden,… -Dankzij de veelvoud van aanbod worden de prijzen normaal gezien naar beneden gedrukt. Overzicht Identificatie meerwaardecreatie Acties stimulatie voor meer uitwisseling naar verschillende gebruikers bron van inspiratie voor het oplossen van specifieke problemen (niet opnieuw warm water uitvinden) laagdrempelige toegang (=met voorbeelden, zoekopdrachten, begeleiding,...) eenvoudige, snelle manier om data en bestaande modellen te kunnen vinden en gebruiken combinatie met open data aangeboden door steden (ganse quadruple helix) kennisdeling tussen lokale besturen bv: recepten: deze dataset met dit algoritme geven een goed resultaat voor het bepalen van de boompopulatie op het grondgebied (hiermee geven we de kwaliteit van de link tussen een algoritme en de dataset) benchmarken met de resultaten van andere gemeenten (zowel data/algoritme, alsook de output zelf) welke output data willen we uberhaupt publiceren (politiek gevoelig,...) Dashboard dat van de output kan worden gebouwd, dan ook op de marktplaats staan. Mogelijkheid bieden om de verwerkte data ook beschikbaar te stellen (delen met) aan andere klanten van het platform om hen zo toe te laten om te benchmarken met hun resultaten koppeling met andere intitiatieven (zoals blauwgroen ?) via datavindplaats ? Hergebruik van data (een keer aankopen en veel mee doen) overzicht van wie in mijn stad reeds die data of algoritme gekocht ? gebruikt ? aanbestedingsproblematiek - klopt dit ? voor grotere bedragen misschien toch via een aanbesteding ? Marktplaats wordt aankoopcentrale ? Algoritme expertise veel breder inzetten (door meer data) Waar nu vaak het een eenmalige grote, dure inspanning is zonder continu teit , de kans om een delta/evolutie te zien historisch. Instapdrempel lager door de prijs die lager zal liggen => motivatie om meer foto's te maken en publiceren Instapdrempel lager door de lagere technische achtergrond die niet meer nodig is. kwaliteitsverbetering data en producten door markt transparantie afstemming aanbod naar vraag door ontwikkeling van algoritmes voor populaire use-cases Marktplace space ? Leveranciers moeten geen eigen marktplaats ontwikkelen; maar kunnen hun MLaaS aanbod makkelijker aanbieden. Alleen is de vraag, hoeveel marktplaatsen gaan er komen? Regels op Vlaams, Belgisch, internationaal niveau? Agentschappen kunnen exclusief hun data of algoritme op de marktplaats zetten. Andere steden kunnen hun ervaringen met trajecten: welke beelden met welke algoritmes en resultaten delen (en eventueel kosten) Als algoritme leverancier is de setup reeds voorzien waarmee je algoritmes dienen te connecteren (input; resultaten) => processingruimte, alsook de resultaat moeten stockeren zullen door de marktplaats op zich genomen worden ipv door de leverancier Mogelijkheid tot groepsaankopen. Naburige steden kopen beelden samen aan. (vliegtuig alleen voor 1 stad laten vliegen is hoge kost). Vlaanderen ? Discussie Stimulatie van kennisuitwisseling: Er is gesproken over het belang van gebruikersrecensies en feedback om kennisuitwisseling tussen steden te bevorderen. Probleemoplossing en inspiratie: Discussie over het gebruik van de marktplaats als bron van inspiratie voor het oplossen van specifieke problemen, zoals boomtellingen. Lagere instapdrempel: Gesprek over het belang van een lage instapdrempel voor het gebruik van de marktplaats, inclusief eenvoudige zoekopdrachten en duidelijke gebruiksvoorwaarden. Open data en samenwerking: Overwegingen over hoe de marktplaats kan worden geïntegreerd met bestaande open data-initiatieven en dashboardfunctionaliteiten voor betere samenwerking. Benchmarking en kwaliteit: Besproken hoe benchmarking met resultaten van andere gemeenten kan bijdragen aan transparantie en kwaliteitsverbetering van de aangeboden data en modellen. Groepsaankopen en kostenbesparing: Discussie over de mogelijkheid van groepsaankopen via het platform om kosten te delen en te besparen. Juridische overwegingen en raamcontracten: Overwegingen over juridische aspecten, zoals de mogelijkheid van raamcontracten om individuele aanbestedingsprocedures te vermijden. Voordelen voor leveranciers: Gesprek over hoe de marktplaats voordelen biedt aan leveranciers door hen te ontheffen van de noodzaak om een eigen marktplaats te ontwikkelen. Gegevens en algoritmen: Besproken hoe leveranciers algoritmen eenvoudig kunnen aanbieden en integreren via de marktplaats, met gebruikmaking van bestaande infrastructuur. Marktplaats als marketingtool: Overwegingen over hoe de marktplaats kan fungeren als een effectieve marketingtool voor steden en bedrijven. Oefening 4 In deze oefening werden potentiële valkuilen geïdentificeerd en, op basis hiervan, formuleerden we principes waaraan de oplossing moet voldoen: Voorbeeld: Self-service zonder goede training kan 'gevaarlijk' zijn Garanties op de kwaliteit ? Interoperabiliteit van de oplossing Betrouwbaarheid, en dus ‘vertrouwen’ in de data en modellen Stabiliteit, en dus ‘continuiteit’ van data en modellen, wordt het continue geupdate Goede helpdesk Overzicht Valkuilen Chaos Verschillende algoritmes, kunnen verschillende resultaten opleveren met een verschillende kwaliteit. Hoe kwaliteits garantie voorzien? doorlooptijd onderschatten (bv. periode "van plannen aankoop tot levering beeldmateriaal" bv. inplannen zomervlucht) Hoe continuiteit garanderen? Zowel blijven supporteren van bestaande als doorontwikkelen of verbeteren van algoritmes Er geen effectieve ontkoppeling komt tussen leverancier en algoritme. Hoe garanderen dat de gebruiker het bos nog ziet doorheen de bomen? Risico op chaos in aanbod ; pricing principes en hieraan gekoppelde platform setup incl. datamodel ontbrekende algoritmes of datasets doen eindgebruikers weggaan van het platform gebrek aan basiskennis bij bepaalde gebruikers => de stap zetten om mee in dit proces te stappen niet nemen of op de lange baan schuiven toch belangrijk dat er voldoende deelnemers zijn: hoe meer deelnemers hoe groter de kans op goede kennisdeling en (hopelijk) hoe lager de prijs eindgebruiker loopt verloren in de marktplaats, of weet niet goed waar te beginnen of wat te vragen/kopen slechte documentatie / metadata dus fouten naar afnemers Principes Goede UI en moderatie bij succes Test & acceptatie proces alvorens men mag aanbieden? - Proof of Concept met gewaardeerde eindgebruikers (vraag van leverancier en/of platform naar afnemer) Betaversies Nieuwe algoritmes hebben nog geen feedback/validatie Early access oproepen tot groepsaankoop tijdig lanceren op het platform onafhankelijke beoordeling door experten in het platform adhv test en acceptatie of Proof of Concept (zie hierboven?) Grondige pré-analyse van wat er zal worden aangeboden en hoe Community Terugkoppeling "request" mogelijkheden in of minstens via het platform basic trainingsmateriaal voor de marktplaats vorozien, en/of een FAQ pagina community van gebruikers om kennis te delen Discussie Training en kennisuitwisseling: Er is gesproken over de noodzaak om trainingen te bieden over het gebruik van de data en modellen op de marktplaats, om fouten te voorkomen en de juridische verantwoordelijkheid te begrijpen. Kwaliteitsgaranties: Discussie over hoe kwaliteitsgaranties kunnen worden geboden voor zowel data als algoritmen, om te voorkomen dat gebruikers betalen voor iets dat niet naar behoren werkt. Gebruiksvriendelijkheid en ondersteuning: Overwegingen over het belang van een goede gebruikersinterface, een helpdesk en documentatie om gebruikers te begeleiden en te ondersteunen. Continuïteit en updates: Gesprek over hoe de marktplaats moet zorgen voor de continuïteit van de aangeboden data en modellen, inclusief ondersteuning voor nieuwe versies en updates. Community en samenwerking: Het belang van een actieve community werd benadrukt, waar gebruikers kennis kunnen delen, feedback kunnen geven en samenwerken aan nieuwe ontwikkelingen. Aanbod en vraag: Discussie over hoe het aanbod op de marktplaats kan worden gestimuleerd, inclusief het faciliteren van verzoeken van gebruikers en het betrekken van leveranciers bij het ontwikkelen van nieuwe oplossingen. Innovatie en toegang: Overwegingen over hoe de marktplaats innovatie kan faciliteren door ook Early Access aan te bieden voor nieuwe algoritmen in ontwikkeling, en hoe dit kan worden gefinancierd, mogelijk via crowdfunding of investeringen van gebruikers. Transparantie en verantwoordelijkheid: Besproken werd hoe transparantie over de ontwikkelingsfase van algoritmen kan helpen bij het nemen van beslissingen en het beperken van risico's voor gebruikers. Promotie en adoptie: Het belang van effectieve promotie van de marktplaats werd benadrukt, samen met strategieën om gebruikers te overtuigen deel te nemen en bij te dragen aan het succes van het platform. Oefening 5 Tot slot keken we naar manieren om de voorgestelde oplossing duurzaam te implementeren: Hoe kunnen we een duurzaam en schaalbaar businessmodel opzetten voor het aanbieden van dit platform aan leveranciers & potentiële klanten bv. andere gemeenten? Marketing & sales: vraag en aanbod stimuleren Future proof maken, zodat het ook oplossingen biedt voor toekomstige problemen (innovatie van data garanderen). Wat zijn potentiële inkomstenstromen en prijsmodellen die we kunnen overwegen voor het aanbieden van dit platform aan externe partijen? Wie betaalt de beheerders van het platform? Welke expertise hebben we juist nodig? Absolute link modellen met databronnen Overzicht Verduurzamen oplossing voorstudie: welke datasets meest gezocht + koppeling met speerpunten eens contact opnemen met de provincie Limburg. Zij hebben een project van inventarisatie van groen (en andere objecten) lopen voor bijna alle Limburgse gemeenten => zij kunnen hoogstwaarschijnlijk nog aandachtspunten aanreiken, dankzij hun ervaring - Initiatief van Nuhma, S-Lim en MyCSN Welke rol kan Athumi hier spelen? Markt analyse => hoeveel klanten worden er realistich verwacht; voor welke use cases; wat is hun bereidheid tot betalen? - Prijs model bepalen en dit afwegen tegen kosten - zowel klanten als leveranciers inzicht in wat ze mogen verwachten - cfr. LODE project transparantie geven aan de gebruikers over het totale kosten plaatje van de marktplaats: kost vd beelden, vd algoritmes, kost van data-opslag, beheer/onderhoud infrastructuur, etc Mogelijke outputkoppeling met met andere Vlaamse, federale projecten zoals LEKP, burgemeestercovenant, helpdesk FAQ Link met verenigingen of zeer 'thematisch' gebonden Sales, business developer Juridisch advies certificaat als data intermediaries https://digital-strategy.ec.europa.eu/en/policies/data-governance-act-explained Discussie Voorstudie en datasets: De noodzaak om een voorstudie uit te voeren om te bepalen welke datasets het meest gezocht zijn, en om deze te koppelen aan speerpunten of focusgebieden, zoals bepaald door Smart Vlaanderen en de Provincie Limburg. Marktanalyse en kostenplaatje: Atomik kan een rol spelen in het uitvoeren van een marktanalyse om realistische verwachtingen te bepalen over het aantal klanten en hun bereidheid om te betalen. Het is ook belangrijk om transparantie te bieden aan gebruikers over het totale kostenplaatje van de marktplaats, inclusief kosten voor beelden, algoritmen, data-opslag, beheer en infrastructuur. Samenwerking en koppelingen: Door samen te werken en te koppelen met andere Vlaamse en federale projecten zoals LKP en het Burgemeestersconvenant, kan de marktplaats worden versterkt en uitgebreid. Er moet een kruisbestuiving plaatsvinden om de marktplaats verder te ontwikkelen en om sales en marketingactiviteiten te ondersteunen. Helpdesk, FAQ en juridisch advies: Het opzetten van een helpdesk en een FAQ-sectie is belangrijk voor gebruikersondersteuning. Juridisch advies moet ook worden overwogen, samen met het verkrijgen van certificering als data-intermediair, om het vertrouwen van zowel dataleveranciers als gebruikers te vergroten. Opname en Miro bord Miro bord Het Miro bord kan je consulteren via deze link . Opname De opname van deze sessie is te bekijken via deze link . Volgende stappen Wat na deze werkgroep? Verwerking van de output van de brainstorm oefening. Desk research Publicatie op de Kennishub Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Thematische werkgroep 1 Data en informatie werkgroep 2024-03-14 9u-12u Teams Thematische werkgroep 2 Technologie werkgroep 2024-04-16 9u-12u Teams Thematische werkgroep 3 Technologie werkgroep 2024-05-15 13u-16u Teams +
De vier hoofdonderdelen van de VLOCA aanpa … De vier hoofdonderdelen van de VLOCA aanpak VLOCA vertrekt vanuit de maatschappelijke context en de ambitie van het lokaal bestuur, over een doordachte aaneenschakeling van architecturale elementen, tot aan de uiteindelijke technologische elementen waaraan de oplossing dient te voldoen. We volgen hier vier stappen, waarvan de eerste twee de basis vormen van de uit te werken architectuur: Context Motivatie Bedrijfsarchitectuur IT-architectuur De strategie, de bedrijfsarchitectuur en de IT-architectuur vormen samen de Open City Architectuur. Context Onder context verstaan we alle instromen die samenkomen en een idee of concept tot resultaat hebben. Open City Ambitie Thematische lokale en bovenlokale open city ambitie Raakvlakken met andere ambities Beleid lokaal bestuur Open City ambitie als antwoord op beleid lokaal bestuur Digitale maturiteit lokaal bestuur Noden en behoeften stakeholders Specifieke noden en behoeften van stakeholders Quadruple helix: overheden, bedrijven, kenniscentra, burgers Omgevingsfactoren Maatschappelijke eisen en beperkingen Beleidsthema’s: milieu, verkeer, economie, … Motivatie De motivatie stelt aan de hand van een aantal vragen de open city ambitie scherp. Deze concretisering zal het trajectambitie kort maar gericht samenvatten. Visie Wat is de bestaansreden van dit project? Missie Wat willen we met dit project bereiken? Doel Wat is het doel van dit project? Successfactor Hoe meten we het succes van dit project? Bedrijfsarchitectuur VLOCA architecten werken volgens een standaard methodiek samen met initiatiefnemende lokale besturen in het tot stand komen van een uitgewerkte bedrijfsarchitectuur. In het VLOCA model worden exploratief alle mogelijk relevante elementen opgesomd. De stad voor wie de use case specifiek uitgewerkt wordt maakt de keuze tussen welke elementen in scope van het project zijn en welke niet. De niet meegenomen elementen worden hier gedocumenteerd als startpunt voor vervolgprojecten al of niet in dezelfde stad of gemeente. Tussen de overgebleven elementen worden prioriteiten gesteld, waaruit uiteindelijk een roadmap kan worden gefilterd, dat de aanzet is van het plan van aanpak van het te realiseren project door de stad. Data en informatie wordt hier eveneens bekeken: de informatienoden worden in kaart gebracht. Een OSLO project kan hieruit volgen, met de totstandkoming van een semantische standaard als doel. Business capabilities Wat moet de oplossing specifiek kunnen waarmaken? Bestaat uit data vereisten, functionaliteiten en techniciteiten Data vereisten Welke data hebben we nodig? Aan welke parameters moet de data voldoen? Functionaliteiten Wat moet een toepassing met informatie kunnen? Wat is de interactie tussen toepassingen? Techniciteiten Wat zijn de technologische vereisten? Welke technologieën moeten onderling verbonden worden? IT architectuur Een specifieke IT architectuur wordt opgesteld voor de stad die het VLOCA traject initieert. Team VLOCA werkt daarbij nauw samen met het lokaal bestuur en haar gekozen IT partner. Tegelijkertijd zorgt team VLOCA ervoor dat een generieke architectuur wordt uitgewerkt, waarop andere steden en gemeenten hun project in een latere fase kunnen baseren. De specifieke context van het eerste project in onze regio zorgt op deze wijze voor een snelle start voor de volgende projecten, waarbij herbruikbaarheid en interoperabiliteit centraal staan. Informatie architectuur Gewenste informatie op dashboards, portaalsite, apps, … Uitgewerkt in een mindmap Data architectuur Voorbereiding voor OSLO traject/ semantische standaard Data governance Applicatie architectuur Rol van relevante toepassingen en hun interactie met informatie Uitgewerkt met een use case diagram Technologische architectuur Hard, soft en hybride infrastructuur voor applicatie architectuur Uitgewerkt met technische tekeningennische tekeningen +
De visie van Open And Agile Smart Cities i … De visie van Open And Agile Smart Cities is om een open smart city markt te creëren gebaseerd op de noden van steden en gemeenschappen. Daarbij verenigen zij meer dan 170 steden over de hele wereld die hun principes gebruiken. Naar architectuur, heeft OASC een aantal MIMs (Minimum Interoperability Mechanisms) gedefinieerd om de open smart city markt te realiseren. Deze zijn terug te vinden onder [1] . Hun MIMs zijn gebaseerd op internationale Standaarden , en een belangrijke inspiratiebron voor VLOCA. Meer over de MIMs is te vinden op de OASC MIM WIKI [2] Meer over OASC is te vinden op [3] ↑ https://oascities.org/wp-content/uploads/2019/03/ OASC -MIMs-1.pdf ↑ https://oasc.atlassian.net/wiki/spaces/ OASC MIM/overview?homepageId=3211482 ↑ https://oascities.org/https://oascities.org/ +
Dear reader, This Open City Architecture … Dear reader, This Open City Architecture program aims to consolidate European and International practices and standards into an open I(C)T architecture to boost the interoperability and openness of data and technology within cities and communities in the Flemish landscape. For that, it is set up in Dutch, but can easily be absorbed in English by using a translation engine like e.g. Google Translate.How to use this can be found : https://support.google.com/chrome/answer/173424?co=GENIE.Platform%3DDesktop&hl=en424?co=GENIE.Platform%3DDesktop&hl=en +
Deelnemers Naam Organisatie … Deelnemers Naam Organisatie Jan Larosse Maakbaar Leuven Rosalie Heens Repair & Share Stephanie Heylands Statik Sten Govaerts Statik Sam Bruyninckx Kringwinkel ViTeS Ward Dumon Servilux Wouter Sterkens KULeuven Niels Kinds Stad Roeselare Lieve Van Espen Stad Leuven Bart Scheenaerts ABB Stefan Lefever imec Yoko Dams VITO Dieter Cuypers VITO Rik Hendrix VITO Verwelkoming Inleiding door Yoko Dams (VITO) Inleiding Bart (VLOCA/ABB) Wat doet VLOCA? Hoe kan dit de deelnemers helpen? Waar willen we met VLOCA naartoe in de toekomst? ORDP (Open Repair Data Platform) Uitleg over het ORDP door Agustin Garcia Pereira (NUI Galway) Gebaseerd op data schema’s Standaard GraphQL ORDS (Open Repair Data Standard) API via GraphQL geeft flexibilieit naar de applicaties toe om querying te customizeren en veranderingen te beheren NUI bouwt interfaces (adaptors, connectors). Offered as a service. Als het project verdergaat, is het plan dat dit model wordt overgedragen aan business. Willen we dit aligneren met bijvoorbeeld een circulaire economie data space, dan zijn mogelijks nog een aantal extra stappen nodig voor onder andere het beheren van semantische interoperabiliteit. Workshop We kozen voor een co-creatie format waarin de organisaties in deze eerste gezamenlijke sessie elkaar en hun standpunten beter leren kennen. Daarbij gebruiken we drie leidende vragen om de open discussie te faciliteren. Vraag 1: Wat is jouw droom rond het thema van datagedreven repair cafés ? Vraag 2: Ben je datagebruiker of producent ? Vraag 3: Wat zijn de gaps, wat zijn mogelijke oplossingen, drempels, prioriteiten ? Vraag 1: DE DROOM: Wat is de ideale wereld ? Hoe stroomt de data ? Wat is het gewenste architectuurmodel? De organisaties aan het woord: Organisatie De droom van de organisatie Maakbaar Leuven Transparante omgeving waar alle info beschikbaar is om de beste oplossing te vinden. Barrières opruimen. Samenwerken. De droom is: méér herstelcultuur. Herstel makkelijker maken Transparante digitale omgeving – lerend netwerk. Digitale tools: laagdrempelig en transparant. Ervaringen delen zodat de herstellers snel weten hoe een faling aan te pakken. Resultaten van de herstellingen beschikbaar maken Interesse vanuit Vanden Borre en BSH (Bosch/Siemens) Repair & Share In een ideale wereld bestaat er 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. De tool maakt automatisch vertalingen en is in staat onbetrouwbare van kwalitatieve informatie te onderscheiden. Statik data model, 1 API Alle interne systemen van professionals zijn anders. Moeilijk om die allemaal te laten samenkomen. Soms ook weerstand. Data bij gebruiker opvragen zonder grote inspanning van de gebruiker Lijsten van merken & modelnummers beschikbaar maken Kwaliteit van de data heel belangrijk Lokale overheden Lokaal beleid wil meten om te weten waarop in te zetten (beleidsperspectief). Men is op zoek naar data om hiermee de bijdrage van reparatie aan klimaatdoelstellingen te meten. Kringwinkel Laagdrempelige informatie waarmee iedereen aan de slag kan Bereid gegevens die ze hebben te delen Medewerkers kunnen goede aanvullende diensten leveren aan commerciële reparateur (bv identificatie) De professioneel hersteller De match making hersteller met het defect toestel is niet evident. Frustratie: “als we willen helpen, zijn we als bedrijf te duur”. Kennis “binnen garantie” inzetten buiten garantie. We willen weten waar handige harry’s opereren en welke kennis ze hebben (zowel problem-owner als problem-solver) om zo te helpen bij match-making. Dus: Identificatie v/h toestel + handige harry vinden die gecertificeerd is voor deze specifieke herstelling. imec Context van een herstelling is belangrijk (risico, wat is nodig, welke kennis is nodig) → wegnemen van zoekkosten, delen moet zeer laagdrempelig en makkelijk zijn. Beschikbaarheid van de data bv. Herstelvideo’s garanderen in de tijd Onderdelen: “veiligheid” wordt soms door fabrikanten gebruikt als afscherming ABB We wensen dat kennis wordt gedeeld met de kleinste gemeentes in VL. Geen uitsluitend grootstedelijk verhaal. Helpend en ontzorgend vanuit centraal team en duidelijk genormeerde data architectuur. KULeuven productpaspoort met materiaalsamenstelling, grondstoffen, transport,… subjectieve obsolescence is barrière (bij de release van een nieuw model van iPhone, switchen mensen vaak vroegtijdig van iPhone) model specifieke identificatie aan de hand van een foto van het label opheffen van de verwarring tussen fabrikantmodel en commercieel model. model specifiek beslissingssysteem op basis van leeftijd en herstelgeschiedenis ((bv. deur vervangen van wasmachine = nuttig voor ganse reeds modellen van Siemens / Bosch, maar daar bestaat geen lijst van) VITO idealiter kunnen heel wat aspecten van repair (kans op succes, leeftijd van eerste faling, veel voorkomende falingen,…) met solide datastromen in kaart brengen om er zo een policy indicator voor het monitoren en meten van circulaire activiteiten in een regio of in EU van te maken. Open discussie Het Europees milieuagentschap (EEA) werk aan nieuwe indicatoren om de circulaire economie in Europe te monitoren. Vanuit dat perspectief zijn zij dus een afnemer van data; Spare parts / verbod op harvesting/mining Nu: druk op de mogelijkheden door wettelijke beperking van gebruik van wisselstukken; Kunnen we reglementering aanpassen via Recupel. Kan de overheid/VLOCA hierop wegen ? → latere fase: betrekken Recupel / bevoegde Vlaamse instanties. Datamodel Op Eurostat vind je hoeveel toestellen er per land verkocht zijn. Een lijst met gelijkaardige vervangmodellen kan helpen bij de zoektocht naar vervangstukken. Vraag2: Ben je datagebruiker of -producent, of beide? Wat is de benchmark? Wat ontbreekt er? Tot welke data wil je graag toegang? Wie gebruikt welke data/welke nog niet? Gebruik je al data die je elders gaat halen? De deelnemende organisaties aan het woord: Organisatie Data aspecten KULeuven Datagebruiker van bv GfK-data (gebruik slechts toegelaten binnen 1 project), kringwinkel, … Producent van data bv. leeftijd Foto van modelnummer om producttype te identificeren. ABB Open data is niet hetzelfde als gratis data. GDPR biedt mogelijkheden aan burgers (niet alleen iets dat extra lasten brengt). Als een wasmachine van jou is, ben je dan ook eigenaar van de data over de reparatie? Als een gebruiker data wil delen, is dat toegelaten? Kan de overheid een rol spelen om data te mogen ontsluiten? Professionele hersteller De productiedata, leeftijd, aankoopbedrag, gebruikte onderdelen, probleemcodering, oplossingscodering incl. foto’s (want een faling kan veroorzaakt worden door verschillende problemen, en per probleem zijn er een aantal oplossingen). Gevalideerde data want men is vaak ter plaatse geweest. Die data worden gedeeld met 46 fabrikanten. Ook verkopers zoals Vanden Borre lezen de data. Maar zelf doet Servilux bijna niets met de data. Dus eigenaar van data met weinig nut voor eigen organisatie. Businessmodel: Servilux krijgt werk in ruil voor data. De wens is er om te kunnen delen en reparaties ook buiten het professionele circuit te vergemakkelijken. Kringwinkel Debruikers van data bv. Youtube. Veel kennis in hoofden van medewerkers maar niet gemakkelijk te delen: persoonlijke barrières (niet willen delen, te trots, wantrouwen tegen app: gaat men dat dan verkopen…) Lokale overheden Data voor monitoring, data verzameling via het city platform (mensen kunnen zelf gegevens i.v.m. herstel ingeven). Aanleveren van data: mapping tool (doorverwijzen naar professionele hersteller of repair café). Ondersteuning aan repair cafés om dataleverancier te worden. Statik foto’s van labels aangevuld door herstellog die door de herstellers wordt ingevuld. Er wordt ook ingevuld of er wisselstukken zijn gebruikt. Een rapport wordt gedeeld met de eigenaar vh toestel. Dit is zichtbaar voor alle andere geregistreerde herstellers. Nu 800 tal toestellen geregistreerd. City platform meer een communicatief verhaal / campagne. Hier worden ook enkele vragen naar leeftijd toestel gevraagd en dus verzameld. Daarnaast een tool voor de professionals, met ongeveer dezelfde velden. Interactieve kaart toont alle cijfers die geregistreerd staan. De guidance tool / beslissingsboom moet nog gebouwd worden. Doel: de burger gidsen naar de mogelijke herstelopties. Nog niet veel testgroepen hiermee bezig. Ongeveer 800 toestellen, waarvan 400 door Maakbaar Leuven. Repair & Share 90% van de Repair Cafés deelt de data niet. We moeten nog meer motiveren/ laagdrempelig maken. Niet makkelijk want je hebt verschillende kanalen: repair monitor, fixometer, Youtube, Ifixit… . Je blijft heel sterk afhankelijk van de medewerking van de vrijwilligers. Hoofdmotivatie is persoonlijke babbel en hulp voor de mensen. Willen zicht krijgen op aantal RC events. We doen dit via websites, facebooksites etc. Maar moeilijk zeker te zijn van het resultaat. Maakbaar Leuven Inschakelen van een ander type van vrijwilliger: hooggeschoold, open voor digitalisatie. Mensen die citizen science data belangrijk vinden, niet enkel de reparateurs. Sensoren in apparaten: er gaat veel servicecapaciteit verloren omdat de data onderbenut zijn. Veel analytische mogelijkheden als we dit aggregeren, vanuit burger gedreven aanpak. imec Er is een manier nodig om traditionele datavergaringsmogelijkheden te omzeilen. Foto’s omzetten naar machine-readable info + foto’s blijven bestaan voor latere herverwerking. Uitdaging: fotodata moet gelinkt worden met metadata. Niet impliciet tenzij iemand dit doet. Zekerheid is niet 100%. Augmented reality als oplossing? Vraag3: Hoe kunnen we data gaps vullen? Wat zijn drempels? Wat zouden mogelijke oplossingen kunnen zijn? Waar moet aan gewerkt worden? Wat is prioritair? Conclusies Geen mogelijkheden als stad om je beleid op te volgen. Stijgt het aantal herstellingen? Waaraan is dat te danken? Impact repair café op afvalreductie? Vrijwilligheid van data-invoer is een drempel Hoe laaggeschoolden en vrijwilligers intrinsiek motiveren om data te in te voeren in een toepassing, terwijl de kerntaak de reparatie en het sociaal contact is. Ze willen het wel, maar ze doen het niet. Uitdaging van het op gang krijgen van de cocreatie; kennis bundelen via standaarden. Samenbrengen van gebruikers op 1 platform reparateurs: hoe repareer ik dit? Meer nuttig maken om de app te openen. consumenten: weggooien of repareren of verkopen Jobcreatie voor laaggeschoolden Gap samenwerking tussen verschillende partijen op snelle & efficiënte manier Match tussen soorten van producten (veel combi’s) en een databank op soort & modelnummer loopt vaak vast (bv. een wasmachine die ook droogt…). Verschillende benamingen voor combinaties van toestellen. Hoe catalogeren? Gap is dat producenten hier niet aan tafel zitten. Sommige merken kunnen bv. product bewust “dichtharsen” om het niet repareerbaar te maken. Testaankoop is een drukkingsmiddel dat werkt (website “terapkapot”). Testaankoop betrekken in traject. Kritische massa. Database moet aantal records bevatten. Pas dan nuttig. Foto’s opslaan goede manier van documenteren (data verandert, foto blijft) Standaardisering: OSLO (data.vlaanderen.be) Wrap up (door imec) nood beschrijving Metadata Managen van metadata is enorm belangrijk rond Ervaringen (risico’s van herstellingen, kennis, materiaal, tijd, MTBF,...) Crowd data (kwaliteits ervaringen, website rond levenstermijn, testaankoop data,...) Product passport Een product passport is key als te managen digitaal data object Met data lineage : van producer over transport tot klant Voorbeeld ondersteuning met toestel foto en OCR (KUL) als digitaliseringsparameter Liability Liability is een belangrijke concern (bijvoorbeeld het herbruiken van onderdelen van recupel). Kunnen we zo mogelijk de reglementering aanpassen ? GDPR GDPR is een belangrijke concern (foto’s, locaties, ...) (kunnen we datakluizen gebruiken ?) Want bv een herstelactiviteit kan metadata bevatten zoals probleem, locatie, label, productie/verkoop data, waarde, gebruikte onderdelen,.. Niet al die data is zomaar te openen (data sovereignty/ownership) Oplossing kan zijn om coderingen toe te voegen (probleem, oplossing) Codelijsten : EICTA (IRIS codering) Weerstand Er is ook een algemene weerstand tot het delen van data en kennis (voorbeeld van de herstellers die moeten documenteren, of vrijwilligers die dan niet willen doen, voorbeeld oplossing via “cake” vrijwilligers). Net hierdoor is er voor 90 % van repair cafés nog geen sprake van data delen. Opportuniteiten voor verderzetting van VLOCA traject Aaangebracht door imec Werken rond data principes zoals privacy, sovereignty Rol van IoT uitwerken (nieuwe manieren zoeken om data captatie te automatiseren, bv RFID tags, OCR/ML op foto’s, ...) Data captatie door vrijwilligers ontzorgen, bijvoorbeeld Augmented Reality Data standaard (ORDS) is niet genoeg, moet verder doorontwikkeld worden tot op EU niveau. Wat ontbreekt er? (cfr OSLO) Data en metadata relateren: welke technieken zijn er (Linked data, asset registries, metadata catalogs,...) Hoe data uit andere data spaces fuzen met Repair data? (lijkt een uitdaging voor hun huidige platform) Hoe komen tot een unified data space voor repair data? Hoe hun GraphQL platform relateren aan toek evoluties van ORDS Heel belangrijk : hoe data repair sources ontdekken (catalogs, federation,...) Kunnen we al komen tot een Vlaamse norm? Hoe omgaan met de complexiteit van de business modellen: veel te veel soorten modellen om prijstransparantie en vergelijking tegen te gaan: eigen interne coderingen nodig op basis van aantal parameters die herstel toelaten => metadata opstellen van uit de repair economie want komt niet van de suppliers (maar is aan het veranderen) +
Deelnemers Jan Larosse Maakbaar L … Deelnemers Jan Larosse Maakbaar Leuven Rosalie Heens Repair & Share Stephanie Heylands Statik Sten Govaerts Statik Wouter Sterkens KULeuven Niels Kinds Stad Roeselare Lieve Van Espen Stad Leuven Jens Rappé Sirus Stefan Lefever imec Yoko Dams VITO Dieter Cuypers VITO Rik Hendrix VITO Fabian de la Meilleure VLOCA Steven Degelaen VLOCA Alain Glickman VLOCA Presentatie 2022-03-09 VLOCA session - Pitch ORDP & Data visualisation Verwelkoming & doelstelling (Yoko) Het voorbereidend traject wordt toegelicht. Aanvankelijk was het idee met verschillende stakeholders uit de sector te bekijken hoe we het huidige Open Repair Data Platform (kortweg ORDP) kunnen verbreden met reparatie data voor reparaties die gebeuren bij professionele herstellers, kringwinkels, retailers, producenten, etc. Immers, uit WS1 bleek dat er op 2 momenten in het reparatieproces moeilijkheden ervaren worden die weggewerkt kunnen worden met behulp van AI, nl. bij identificatie, het stellen van de diagnose en het bepalen van de juiste reparatie optie. In een workshop met Statik, VITO en NUI, werd samen met Alain (VLOCA) beslist om ook te bekijken of we de steden en gemeentes kunnen bedienen met onze data. Samen werden er 5 inzichten geformuleerd die mogelijks uit onze data kunnen afgeleid worden. Aangezien de opkomst voor wat betreft de repair stakeholders mager was (er was wél interesse), werd beslist in een overleg met Bart (VLOCA) om deze workshop deels op te hangen aan het verder uitdiepen van deze alternatieve piste (lokale besturen). Na een eerste analyse kwamen we bij 2 initiatieven die lokale besturen willen voorzien van gegevens/inzichten. Daar gaan we dieper op in: De Gemeente en stadsmonitor wordt toegelicht door Alain; de CE-monitor door Yoko. Nadien bekijken we samen: Hoever het ORDP staat in de ontwikkeling; Welke de 5 inzichten zijn die de data mogelijks kan leveren aan lokale besturen We toetsten deze inzichten af met de data die we hebben (en/of nog niet hebben). We bekijken wat dit opgeleverd heeft. VLOCA en ORDP (Open Data Repair Platform) update stand van zaken Het VLOCA kernteam werd in december 2021 uitgebreid, om een volgende fase van het VLOCA project in te zetten en vanuit de innovatiefase in 2020/'21 stelselmatig effectief en efficiënt te operationaliseren. Momenteel wordt de kennishub als centraal kennisdeelplatform, omgebouwd zodat deze toegankelijker en intuïtiever is. De experten zullen veel makkelijker zelf de informatie kunnen toevoegen. Ook zal er meer ingezet worden op communicatie (via de ABB kanalen). meerwaarde voor ORDP Inhoudelijke aanvulling hoe VLOCA een meerwaarde kan zijn voor het ORDP: Uitdenken van een geschikte data architectuur: Zo bestaat er reeds een “open repair data standard” opgemaakt door The Restart Project. Er is een lijst van productcategorieën vastgelegd maar men is daarbij vertrokken van de lijst met producten die vaak worden binnengebracht bij een repair café. De lijst sluit dus niet aan bij een EU-classificatie (zoals prodcom of CN) en is daarom niet bruikbaar voor reparaties buiten de repair café-sfeer. Stefan (imec): om in te pluggen op green deal data space, moeten de namen voor de productcategorieën aligned zijn (vb met linked data). Huidige data standard is nog te functioneel. Er bestaan mechanismen om confidentialiteit te garanderen, moest dit een belemmering vormen. Wouter (KUL): op Tv's, stofzuigers, lampen, wasmachines en drogers wordt er reeds een verplichte QR-code (sticker) aangebracht met link naar een online EU-productdatabank die het energielabel, en op termijn productpaspoort, bevat. Die QR-code helpt voor het identificeren, niet zozeer bij het diagnosticeren De meerwaarde voor VLOCA ligt dus zeker in het verder verbreden van het ORDP (uitreiken naar professionele herstel, etc.) In een paralleltraject, zal een basisteam worden samengesteld en stakeholders 1 voor 1 benaderd. In dat gesprek wordt dan per stakeholder bekeken wat de noden zijn en welke opties er zijn voor wat betreft de data architectuur. Inzichten vanuit de deelnemende organisaties inzicht Gemeente en stadsmonitor bij ABB (Alain) De data vloeien voort uit een uitgebreide bevraging van +/- 150.000 mensen. Dit is dus een vrij grote sample. Er worden 13 thema’s behandeld. De bevraging wordt om de drie jaar georganiseerd. ABB bereidt momenteel de volgende bevraging voor 2023 voor. Circulaire economie (CE) wordt als nieuw thema’s beschouwd. Maar men richt zich nog niet specifiek op reparatiedata. We zouden dit dus nog kunnen toevoegen. De data moeten wel steeds op gemeenteniveau zijn. Bij ABB zelf is er meer detail. Deze informatie kan opgevraagd worden bij ABB. (Checken of we wijkniveau hebben) Het ORDP kan aanleveren hoeveel/waar repair cafés zijn. De bevraging kan dan bijvoorbeeld uitklaren of dit bekend is. De voorbereiding doet ABB zelf. We zouden eventueel kunnen helpen bij het maken van de vertaalslag van de data naar scores voor CE. (Zo wil Vlaanderen -30% materiaalgebruik realiseren en zouden we kunnen helpen bij het door vertalen van deze doelstelling naar de gemeentes.) CE Monitor (Yoko, zie aparte slide “CE-monitor”) De CE Monitor is opgemaakt bij KUL (Liesbet Gregoir, Luc Alaerts) in het kader van het CE. De “electronics” werden belicht. Voor deze stroom geeft men aan dat men over te weinig data beschikt, zeker op vlak van repair als CE-strategie. Het ORDP kan data leveren op niveau van Vlaanderen of België. Maar aangezien we over locaties beschikken, ook op gebied van steden (indien er een repair café gevestigd is). Het ORDP kan ook bijkomende data zoals afval gerelateerde data zoals geproduceerd door de intercommunales (voor Leuven Ecowerf), opnemen. Echter, de CE-monitor voor Leuven is nog niet operationeel. Het idee is nu om onze pitch te brengen voor het team rond “Leuven circulair” om zo te bekijken of er een samenwerking kan ontstaan. ORDP (Stephanie, zie aparte slideshow “Pitch”, slides 2-12) Stephanie schetst de laatste status van het ORDP incl. De verschillende databronnen en gebruikte software. Ook bekijken we de inzichten die The restart Project uit de eigen repair data haalt, en hoe ze het visualiseren. Pitch: 5 mogelijke inzichten voor lokale besturen en toepassing op ORDP (Yoko, zie aparte slideshow “Pitch”, slides 14-43) We overlopen de 5 inzichten die onze databank mogelijks zou kunnen leveren aan lokale besturen. Dit zijn: Building a data driven scoreboard for policy making Strategic repair cafés deployments Reducing the missed opportunities Impacts of repair cafés on electro waste (as locally collected) Campaign performance marketing mix Voor elk van deze 5 ideeën werd gekeken of we op basis van de huidige data (en eventueel bijkomende data) de gevraagde inzichten kunnen leveren. We overlopen ze dus nogmaals meer mét figuren die we zelf opmaakten. De figuren werden een voor een uitvoerig besproken en mogelijke links naar andere datasets die kunnen worden opgenomen in het ORDP worden gelegd. In een notendop: inzicht inzicht voor lokale besturen en toepassing op ORDP Building a data driven scoreboard for policy making: Is er een aantoonbaar effect van repair cafés op het geluk? Zo organiseert men soms repair cafés in WZC. Oudere mensen genieten daarbij van het sociaal contact en het feit dat ze zich nuttig kunnen maken. Hoewel de impact op “hapiness” en “environmental health” nog moeilijk te kwantificeren is, is er een mogelijkheid om met het ORDP hier een indicator voor op te stellen, mits er meer linken gelegd kunnen worden naar andere databronnen. Bijvoorbeeld naar data die bij de stad aanwezig is rond demografie, vrijwilligerswerk, armoede etc. Maar de relaties en correlaties tussen reparaties en parameters zoals geluk en vrijwilligerswerk zijn nog weinig aantoonbaar. Meer data zouden verzameld moeten worden zoals de demografie van bezoekers van repair cafés en van herstellers. Men kan bevragingen doen. Sowieso is dataverzameling een belangrijk aspect van het repair café. Repair&Share oordeelt dat hier een “nieuw type van” vrijwilliger voor nodig is. Het is immers vaak zo dat er heel wat formulieren ingevuld worden waar nadien niets meer mee gebeurt. Een “circular electronics indicator” zou daarentegen wel aangeleverd kunnen worden. Deelaspecten zouden dan zijn: material demand & stock (waarvoor we Eurostat ‘put on market’ data en Recupel ‘bezitsmeting’ data zullen gebruiken, eventuele aangevuld met stock & flow modellering), repair activities (repair communities status – profesional repairers as registered – fixing rates, common failures,… uit het ORDP), recycling&valorization (door data op te halen bij Recupel, BeWeee, Ecowerf, kringwinkels). We kunnen hiermee nog een stap verder gaan en eveneens CO2 & material impacts (uitgedrukt als carbon footprint of als material footprints) die hiermee gepaard gaan leveren. Eveneens kunnen we leeftijden/ lifespans van electronics monitoren en trendanalyse (time series analysis) hierop toepassen. Strategic repair cafés deployments Het is op heden nog te vroeg om hierop te kunnen focusen. Reducing the missed opportunities: enkele berekenen met huidige data gedaan en we kunnen de missed opportunities zijnde reparaties die niet uitgevoerd konden worden omdat het “systeem” faalde (bv wisselstukken die niet verkrijgbaar of te duur zijn). Er kan zelfs afgeleid worden of de investering in de 3D printer de succesgraad zou kunnen verhogen. Impacts of repair cafés on electro waste (as locally collected): Data werd opgevraagd en verkregen bij Ecowerf (in een goede format en granulariteit) toch weinig correlatie te bespeuren tussen de grote van het netwerk rond het repair café en het aantal electronics binnengebracht op het recyclagepark. Dit is mede te verklaren doordat de locaties van de containerparken (eerder stadsrand) vaak zeer verschillend zijn van locaties waar repair cafés doorgaan (eerder in de kern). Campaign performance marketing mix: analyse gedaan van de promotiecampagnes van stad Leuven en van Maakbaar Leuven. Dit werd vervolgens gefit op het aantal (totaal en het aantal nieuwe) electronics geregistreerd op een repair café in Leuven. Conclusies en mogelijke vervolgacties. Dit korte VLOCA traject heeft reeds een mooie impuls gegeven aan het SHAREPAIR project. We leerden dat er verschillende vervolgstappen te zetten zijn. Enerzijds kunnen we het ORDP verbreden door data van nog meer partijen zoals professionele herstel, kringwinkels, OEMs aan te trekken. Anderzijds kunnen we de inzichten die uit de data kan getrokken worden, verder concretiseren en communiceren. We zijn het verst gevorderd met de CE gerelateerde inzichten voor lokale besturen. Toch zal ook hiervoor verwerking van data van andere partijen nodig zijn. We gaan verder op dit pad en werken in eerste instantie een blauwdruk uit. We kijken welke datanoden er nog zijn, wie ons die data zou kunnen bezorgen en hoe we een brug richting de dataleverancier zouden kunnen bouwen. We werken een structuur voor een dashboard uit, waar de gebruiker (lokale besturen, CE) alle informatie op intuïtieve manier aangeboden krijgt, en zaken verder kan uitdiepen indien gewenst. Concreet (VLOCA acties) TRACK 1: inventariseren van de mogelijke data stromen en mogelijke obstakels definiëren; TRACK 2: architectuur model opmaken: In interactie gaan met de stakeholders (data leveranciers, klanten); uitwerken dashboard (eentje met strategisch oogpunt en een voor ondersteunen operationele werking) Andere acties ikv SHAREPAIR ABB: onderzoek mogelijkheden integratie van het thema binnen GSM / toevoegen CE-indicator – bereidheid tot herstel Pitchen voor Leuven circulair –team (CE monitor) Uitwerken verbreding VLOCA traject Interviews met: BSH / Out of use / kringwinkel / Servilux / Vandenborre +
Deelnemers ABB MOW Stad Kortrijk V … Deelnemers ABB MOW Stad Kortrijk VITO Imec Stad Antwerpen Stad Mechelen MIVB Inleiding Spreker : Fabian de la Meilleure (ABB) Fabian gaf een korte inleiding met verwelkoming en uitleg over de agendapunten van vandaag. Local Digital Twin bevat heel veel onderdelen waarvan o.a. de architecturale component. De focus ligt op 3 centrale thema’s: Verkeer, luchtkwaliteit en geluid. Hieruit komen ook meerdere cases zoals getoond via de demo van Duet uit sessie 1. Recap: Framing Digital Twin Spreker : Koen Triangle (Imec) Maatschappelijke evolutie : De maatschappij waarin wij leven heeft reeds een aantal industriële revoluties gekend om vandaag te komen tot een society 5.0: Super Smart Society met een focus op AI, blockchain en digital twins. Deze technologieën zijn gedreven door data. Concept Digital Twin : Het concept van Digital Twin bestaat al langer maar kan ingezet worden als datagedreven beslissingstool. Deze geeft een virtuele voorstelling van entiteiten en processen. Een Digital Twin maakt gebruik van data op basis van een bepaalde frequentie. Het is niet altijd real-time maar in functie van de dienende case. Data en modellen moeten correct, betrouwbaar en transparant zijn. Cross-domein inzichten, horizontaal over de domeinen zijn mogelijk. What if vragen en scenario’s kunnen worden gebruikt. Dit alles om te komen tot “evidence based” besluitvorming. Data-gedreven overheid & principes : Het concept van de data-gedreven overheid leeft al in steden, waarbij een Digital Twin een rol kan spelen in een aantal beslissingsfasen van het beleidsproces. Het is belangrijk dat je data gebruikt in functie van het beleid, waarbij bepaalde principes in rekening worden gebracht, denk aan toegankelijkheid, vindbaarheid, veiligheid, uitwisselbaarheid etc. Vanuit de DIKW (Data – Information – Knowledge – Wisdom) pyramid voeg je bij elk laag informatie toe om bepaalde beleid mogelijk te maken. Praktisch beginnen : Hoe begin je er daar nu aan? Het kan helpen om eerst over de ambitieniveaus van de open Digital Twin na te denken. In functie van een bepaalde case of van bestaande systemen binnen de organisatie kan je nagaan hoe ver je wenst te gaan. Waar zit je als stad? Tot waar reikt je ambitie? De VLOCA Donut kan uitgebreid worden met de Digital Twin Capability Periodic Table die technologische capaciteiten weergeeft. Dit kan een basis zijn om uit te kiezen. Doelstelling sessie : In deze sessie focussen wij op de onderste componenten van de open Digital Twin. Daarnaast is er ook het analytische gegeven. Een case zien wij als een circulatieplan en een scenario als verschillende opties die een beleid in overweging neemt vooraleer tot een keuze te komen. Luchtkwaliteitsdata van een sensor kan een drift hebben en ook deze variatie kan begrepen worden als eindgebruiker. Vandaag ligt de focus op data maar dit is maar een parameter in de vergelijking van een beslissing. Je moet deze ook kunnen visualiseren en interpreteren. Experten zijn hierbij nodig. Daarnaast is de cultuur ook belangrijk om te komen tot beslissingen. Dit bevat de structuren, de governance en het belang van data in de organisatie. Vragen/opmerkingen : Hendrik Meynen (MIVB) vindt de ambitieniveaus helder om zo weer te geven hoe een Digital Twin stapje per stapje gerealiseerd kan worden. Recap: Conclusies Interviews Spreker : Maxim Chantillon (Imec) Methodologie : Acht centrumsteden zijn geïnterviewd over data-gedreven beslissingsprocessen binnen het beleidsthema “duurzame leefkwaliteit” (omvat verkeer, luchtkwaliteit en geluid). De focus lag daarbij op (1) het huidige beleid en de organisatie, (2) de beleidsprocessen, (3) de huidige noden en (4) de toekomst. Op basis van de geidentificeerde uitdagingen zijn wij gaan nadenken over mogelijke oplossingen voor deze uitdagingen. Uitdagingen : Een aantal uitdagingen werden geïdentificeerd door de deelnemers als zijnde cruciaal. Deze kunnen als volgt samengevat worden: Data: Datakwaliteit en bijhouden data Datastandaardisatie & kennis over standaardisatie versterken bij lokale overheden Datakoppeling & relatie tussen dataleveranciers, zowel binnen de publieke sector als in relatie tot externe niet-overheidsactoren (vb. private sector). Samenwerking: Opbouwen gedeelde infrastructuur tussen lokale overheden, en in relatie naar hogere overheden. Uitbouwen van relatie tussen publieke sector en de private sector Andere: Relevantie Digital Twin aantonen zodat ook andere beleidsactoren toegevoegde waarde zien (vb. politieke niveau). Een aantal moeilijkheden blijven om te evolueren van de theorie naar de praktijk (juridisch / financieel / ...). Oplossingen : Tijdens de workshop werd door de deelnemers nagedacht over hoe deze uitdagingen kunnen omgezet worden in werkbare oplossingen, daarbij was het belangrijk om te denken aan oplossingen die kunnen gelinkt worden en/of uitgewerkt worden in het kader van VLOCA. Voor wat betreft de uitdagingen rond data kwamen de volgende oplossingen naar voren: Datakwaliteit en bijhouden data Datakwaliteit controleren via tooling Gebruik en implementatie van Smart Data Principes & Data Governance Opzetten dataportaal voor dataleveringen en -validatie Datastandaardisatie & kennis over standaardisatie Inzetten op Vlaamse trekkersrol Gebruik standaarden in aanbestedingen (verder) Ontwikkelen van EU/VL bouwblokken Verdere uitbouw VLOCA Kennishub Opzetten domeingebonden data spaces & Central Data APIs Datakoppeling & relatie tussen dataleveranciers Gebruik en implementatie van Smart Data Principes & Data Governance Opzetten Central Data API’s Voor wat betreft de uitdagingen rond samenwerking kwamen de volgende oplossingen naar voren: Samenwerking interne publieke sector & relatie met private sector Opzetten Vlaamse Digital Twin Community Verder bepalen standaarden Stimuleren gebruik authentieke bronnen Opleggen minimale standaarden Opbouwen gedeelde infrastructuur Gebruiken van VLOCA traject(en) om duurzame samenwerkingsverbanden op te zetten Voor wat betreft de uitdagingen rond de relevantie van een Digital Twin en het omzetten van theoretische doelstellingen in de praktijk kwamen de volgende oplossingen naar voren: Relevantie Digital Twin aantonen Begin klein, met praktische use cases Evolutie theorie naar praktijk (juridisch / financieel) Verdere uitbouw van kennis op VLOCA Kennishub Opbouwen lange termijn implementatie via VLOCA traject Gedeelde infrastructuur als middel om kost te drukken Innovatie via samenwerking met industrie Vragen : Martine Van Poppel (VITO): Zijn er plannen om ook de industrie te bevragen over hoe zij het delen van data zien in de context van een Digital Twin? Koen Triangle: In het kader van dit traject is het de bedoeling om ook met de industrie af te toetsen hoe zij de invulling zien van een Digital Twin en toegevoegde waarde kunnen hebben voor de geïdentificeerde noden. Smart Data uitgelegd Spreker : Tom Bergmans (Imec) Opname : De opname van dit onderdeel is beschikbaar via deze link . Eerst focussen op het strategisch element en daarna op data. Er zal ook gewerkt worden met een voorbeeld case. Van Big Data naar Smart Data : Big Data maakt een evolutie door naar Smart Data. Big data wordt aan een hoog tempo gegenereerd en data komt in alle kleuren en geuren binnen. De 4 Big Data V’s geven de problemen mee waar data mee te kampen hebben: Velocity, volume, variety en veracity. De Big Data definities van Volume, Velocity, Variety en Veracity zijn gedefinieerd op deze VLOCA Kennishub. Smart Data: Wat is Smart Data? Hierbij zal aan de Big Data een kwaliteitslaag toegevoegd worden en zullen principes zoals FAIR toegepast worden. Er is een nood aan het feit dat verschillende profielen (denk aan inhoudelijke experten, data experten en beslissers) dezelfde termen rond data gebruiken. Security focust op rechten waar protection de inhoud van de data beschermt. Semantics beoogt een gedeeld begrip van de data. Data als Assets : Het is belangrijk te realiseren dat data als assets een shift in mindset nodig heeft. Data wordt daarbij gezien als een cruciaal element voor beslissingsnemers, en diezelfde data kan leiden tot datagedreven beleid. Data at type level versus data at value level : De eerste categorie bevat data als metadata, de tweede bevat de inhoud van de data zoals de tekst. Dit verschil is expliciet gemaakt omdat deze andere processen ondersteunen en andere componenten bevatten. Deze opsplitsing is cruciaal. Er is geen overkoepelende app. Er is wel een alignering van bedrijfsprocessen en cultuur nodig om het volledig proces te ondersteunen. BPMN Flow uitgelegd : Er wordt voor het voorstellen van de BPMN Flow gebruik gemaakt van de imaginaire stad Brugland die graag de lucht- en geluidskwaliteit wenst te verbeteren om zo de leefbaarheid te verhogen. Dit moet leiden tot een data gedreven beslissing. Hiervoor is een evidence-based systeem nodig. BPMN flow bestaat uit 4 lanen: Business/decision making lane Data governance & management lane Model governance & management lane Application lane Onderaan wordt aangegeven welke componenten overlappen met welk onderdeel. Er is een perfecte mapping op het model dat VLOCA hanteert met dezelfde principes. Het proces begint met de business lane, waarbij er een heldere formulering is van de uitdagingen en de doelen. Aan elk element wordt een beschrijving toegevoegd. Voor luchtkwaliteit is dit bijvoorbeeld het volgende: Welke standaard gebruiken wij (vb. Belaqui)? Willen wij de snelheid of de verkeersintensiteit verbeteren? Voor elk concept in onze probleemstelling moeten wij komen tot een quasi wetenschappelijk begrip van wat er precies beoogd wordt. Als stap 1 en 2 specifiek gedefinieerd worden, dan verloopt het het oplossen van de volgende stappen efficiënter. Deze eerste stappen zijn zeer cruciaal voor het hele proces. Onder de assumptie dat de eerste stappen nauwgezet zijn opgenomen kunnen wij de doorvertaling maken naar de data kant. Dan komen wij tot het data engineering luik. De derde stap, die van het model management, is niet altijd nodig maar wel indien er gebruik wordt gemaakt van modellen om te komen tot predicties maar ook indien er een ‘hertraining’ van modellen is (kan verlopen via een iteratief proces). Het doel is om zo transparant mogelijk te zijn hierover, aangezien dit van cruciaal belang is voor de geloofwaardigheid van het latere beleid. Het is nodig de black box beslissingen zo veel als mogelijk te vermijden, en daarbij o.a. zicht hebben op de data die gebruikt is om het model te trainen en op de modellen zelf. Zo kan bijvoorbeeld een model getraind in de VS mogelijks niet nuttig zijn voor een toepassing In Vlaanderen. Wij moeten weg van hidden feature engineering zodat data stap gevisualiseerd en geïnterpreteerd kan worden door de betrokken actoren. Het is belangrijk om een bepaalde studie niet eenmalig te gaan doen maar om de datasets meermalig te doorlopen en verschillende opties af te wegen. Ideaal is het dus dit geen lineair maar een iteratief proces. Een buikgevoelsbeslissing of waarzeggerij moet evolueren naar een wetenschappelijk verhaal, waarbij het ultieme doel is om tot een zo wetenschappelijk mogelijk onderbouwing te komen. Vragen/opmerkingen : Wim Michiels (Imec): Je moet de mogelijkheden ook duidelijk beschrijven om te verzekeren dat je de nodige data verzameld, en geen overbodige data. Ook van belang is om een statistische basis te hebben en te kunnen gebruiken. Zo kunnen percentielen over een hele periode ook mogelijkheden bieden op vlak van statistiek en model lane (rebranded). FAIR Data Principes: Toelichting Spreker : Martine Delannoy (Imec) Opname : De opname van dit onderdeel is beschikbaar via deze link . Onderzoek : SMIT & Imec, 2022. Evolutie van big data naar smart data : We willen dat de Big Data kan evolueren naar Smart Data. Zo’n evolutie vraagt een aantal aanpassingen, zoals het toepassen van de FAIR Principles. Cruciaal is dat het gebruik van een Digital Twin vertrouwen schept, daarom is het belangrijk dat we de data kunnen vertrouwen. Hoe kunnen we er voor zorgen dat er vertrouwen is in wat uit de Local Digital Twin komt? Er moet vertrouwen zijn in de data, de modellen, de ontwikkeling van een Local Digital Twin etc. Dit onderzoek werd uitgevoerd door SMIT en Imec. Vertrouwen in een Local Digital Twin : Vertrouwen in een Local Digital Twin heeft twee luiken. Er is het vertrouwen in de organisatie (en dus de mensen/individuen) en er is het vertrouwen in het ontwikkelingsproces (en dus de technologie, denk aan data, algoritmes, koppeling van data en weergave van data). Vertrouwen in beide zal leiden tot vertrouwen in de Local Digital Twin. De gebruiker zal op die manier de meerwaarde zien, en een perceptie krijgen van het nut en gebruikersgemak. Vertrouwen in data : Om de Local Digital Twin te vertrouwen is er dus nood aan vertrouwen in de betrokken data. Dit kan versterkt worden door de FAIR Data Principes: Findable, Accessible, Interoperable en Reusable. Findable: De eerste stap bij het (her)gebruiken van data is om ze te vinden. Metadata en data moeten gemakkelijk vindbaar zijn voor zowel mensen als computers. Accessble: Zodra de gebruiker de benodigde gegevens heeft gevonden, moet hij weten hoe deze kunnen worden benaderd aan de hand van authenticatie en autorisatie. Interoperable: De gegevens moeten meestal worden geïntegreerd met andere gegevens. Bovendien moeten de gegevens samenwerken met applicaties of workflows voor analyse, opslag en verwerking. Reusable: Het uiteindelijke doel van FAIR is het optimaliseren van hergebruik van data. Om dit te bereiken moeten metadata en data goed worden beschreven, zodat ze in verschillende settings kunnen worden gerepliceerd en/of gecombineerd. In deze video worden de FAIR principes toegelicht. FAIR checklist : Op basis van onderzoek uitgevoerd door SMIT en Imec werd een vragenlijst opgesteld die toekomstige gebruikers van een dataset kunnen helpen om te begrijpen of deze al dan niet voldoet aan de FAIR principes en wat eventuele tekortkomingen zijn. De vragenlijst bevat de volgende categorieën: Data info: Showstoppers Unrefined data Refined data Smart Data in de praktijk: Workshop Moderatoren : Martine Delannoy (Imec) / Koen Triangle (Imec) / Maxim Chantillon (Imec) Notulisten : Steven Degelaen (ABB) / Fabian de la Meilleure (ABB) Opdracht : Het toepassen van de BPMN Flow in de praktijk, met een focus op de (1) Business/decision making lane en de (2) Data governance & management lane (stap 1 & 2). Daarvoor werd gebruik gemaakt van een beleidsverhaal gekaderd in het cross-domein Duurzame Leefkwaliteit (geluid, luchtkwaliteit en mobiliteit). De groep werd onderverdeelt in twee sub-groepen, groep 1 focuste op luchtkwaliteit en geluid, groep 2 focuste op mobiliteit. Doelstelling : De workshop had een drieledige doelstelling: Deelnemers verder informeren over de BPMN Flow en deze praktisch laten toepassen door de deelnemers. De VLOCA Kennishub verder voeden met relevante concepten, kennis etc. over het domein Duurzame Leefkwaliteit Het verder versterken en verfijnen van de BPMN Flow op basis van feedback verkregen van de deelnemers. Uitkomsten : Beschikbaar via dit Miro bord . Beschikbaar via de volgende links: Groep 1 (focus: Luchtkwaliteit & geluid) Groep 2 (focus: Mobiliteit) Plenaire samenvatting Sprekers : Maxim Chantillon (Imec) & Stefan Levefer (Imec) Groep 1 – Luchtkwaliteit en geluid : Draaiboek : In verband met de luchtkwaliteit is het relevant om te verwijzen naar de door VITO ontwikkelde Blauwdruk voor het opzetten van een gemeentelijk sensornetwerk voor luchtkwaliteit. Deze Blauwdruk is toegankelijk via deze link . Een aantal conclusies kwamen naar voren: Omtrent de BPMN Flow kwam de volgende feedback naar voren: Voor de start van de BPMN Flow is er waarschijnlijk nog een stap (opsomming van bronnen, gebieden en doelgroepen (bron, plaats, tijd, stakeholder, type van impact/effect) op basis van die oplijsting kan de focus gekozen worden). We vertrokken van een eerder vage case, en die werd specifieker gemaakt via Mechelen en hun Schoolstraat project. Voor het bepalen en definiëren van de concepten (B02) is het zeer belangrijk om de concepten en connecties tussen concepten te bepalen. Ook bepalen wat vb. datakwaliteit is voor de use case. Wat betekend de specifieke context voor onze datakwaliteit en wat we moeten meten? Er moeten zowel functionele als niet-functionele concepten bepaald worden. Eveneens belangrijk, en dit is in relatie tot de data providers en data sets (B03), is om te bepalen of data zelf zal gecreëerd worden of zal aangekocht worden, waar zal deze beslissing genomen worden? Suggestie om B04 voor B03 te laten komen, of toch gedeeltelijk. Zo garanderen dat je al een koppeling hebt met de decision takers, dat helpt om beslissingen te nemen. De rollen en verantwoordelijk zijn belangrijk want niet iedereen is overal aanwezig. FAIR checklist: Vragen over het verschil tussen refined en non-refined data. Een use case is een pipeline, dus daarom moet elke dataset in kaart gebracht worden, want er mag geen faling zijn. Er moet een use case zijn om zoveel mogelijk data te mappen. Groep 2 – Mobiliteit: Een aantal conclusies kwamen naar voren : De BPMN flow wordt door de eerste groep als nuttig bevonden. Het geeft inzicht in de realiteit en is een nodige en nuttige oefening om te doorlopen. Toont aan dat een samenwerking tussen domeinexperten en technische experten nodig is om een vraagstuk correct te kunnen behandelen. Tegelijk start het model van een rationale aanpak, maar (beleids)beslissingen worden niet steeds op een rationale manier genomen. Dit zou eventueel kunnen meegenomen worden. Voor domein Mobiliteit kwamen een groot aantal ideeën naar boven, waarbij er een aantal cruciale aandachtpunten zijn: (1) nood aan een duidelijke definitie van beleidsdoelstellingen, niet alleen in concepten maar eveneens in meetbare resultaten, dit maakt het opstellen van de vervolgstappen eenvoudiger, (2) data en datadeling wordt vaak bemoeilijkt omwille van privacy moeilijkheden en (3) gekoppeld hieraan is de nood van het verwerven van externe data, wat niet steeds makkelijk en/of mogelijk is. Voor dit laatste punt is er daarom o.a. nood aan een verdere standaardisatie op vlak van concepten en data. In verband met het delen van data kwam ook naar voren dat organisaties moeten gestimuleerd worden (cultuurverandering) om data graag met elkaar te delen en gezamenlijk naar oplossingen te werken. Tot slot werd de FAIR checklist nuttig bevonden, niet enkel voor externa data maar eveneens voor interne data om te bekijken in welke mate het voldoet aan de FAIR principes en het interne data management op orde staat. Vragen :Hendrick Meynen (MIVB): Hoe wil je use cases mappen? Stefan: Datasets op use cases, want we moeten eens reflecteren over de bruikbaarheid van de use cases. Om zo de herbruikbaarheid van de data set te kennen voor specifieke use cases. Hendrick: probleem is vaak dat use cases toch altijd wat anders zijn en de data dus ook telkens een klein beetje anders zal moeten zijn. Dus we moeten naar een soort van standaard use cases. Next steps Spreker : Steven Degelaen (ABB) Alle verslagen zullen op de VLOCA Kennishub komen. Volgende workshop zal op 26 april (09-12u) doorgaan en zal focussen op de modelering. Alle feedback en suggesties zijn welkom en mogen doorgestuurd worden naar vloca@vlaanderen.be. +
Deelnemers Imec Agentschap Binnenlands … Deelnemers Imec Agentschap Binnenlands Bestuur Agentschap Digitaal Vlaanderen Agentschap Wegen en Verkeer Departement Mobiliteit en Openbare Werken Vlaamse Instelling voor Technologisch Onderzoek (VITO) Brussel Mobiliteit Centrum voor Informatica voor het Brusselse Gewest (CIBG) Maatschappij voor het Intercommunaal Vervoer te Brussel (MIVB) Parking.Brussels Stad Antwerpen Stad Brugge Stad Kortrijk Stad Leuven Stad Mechelen Stad Rotterdam 72 Consulting NorthgateArinso Inleiding Spreker : Fabian De la Meilleure (ABB) Korte inleiding met focus op structuur van de Workshop en de kadering van het VLOCA traject Local Digital Twin en het daarbij gekozen thema Duurzame Leefkwaliteit. Een gemeenschappelijk referentiekader: Wat is een Local Digital Twin? Spreker : Koen Triangle (Imec) Voorstelling van technologische en maatschappelijk evolutiemodel : We zijn doorheen verschillende fasen gegaan, met o.a. industriële revoluties en informatiemaatschappij. Nu evolueren we naar een maatschappij 5.0. Internet of Things, AI, blockchain, Digital Twin etc. staan centraal in dit soort maatschappij. Data zijn daarbij cruciaal : Elke dag creëren we heel wat data en er is een evolutie in deze data. In de komende jaren zal er een enorme toename van de hoeveelheid data zijn en zal de kwaliteit van de beschikbare data toenemen. Relatie tot bedrijven : Een bedrijven zijn zich dit model aan het toe-eigenen, ze functioneren met minder fysieke assets (platform economie) en komen via de data tot een afstemming tussen vraag en aanbod. Koppeling naar de publieke sector : De vraag is hoe we deze data kunnen gaan gebruiken in het beleid, rekening houdend met de beleids- en beheerscyclus. We spreken vaak over de data-gedreven overheid (steden zien als agentschappen) en we willen begrijpen hoe en waar de Digital Twin een rol kan spelen in de beleidscyclus. De Digital Twin heeft al een hele weg afgelegd en de vraag is nu hoe Digital Twin zijn rol kan spelen in verschillende fasen van het beleid. Data-gedreven overheid : Voorstelling van de beleidscyclus en de potentiële relatie van een Digital Twin naar de verschillende fasen van de beleidscyclus. Beleidsvoorbereiding: Focus ligt op monitoring van de omgeving, de identificatie van problematieken en het opstellen van voorstellen. Beleidsdiscussie: Hier kan de Digital Twin ondersteuning gaan geven aan de bredere discussie die dient gevoerd te worden rond het toekomstig beleid. Simulatie: Impactanalyses en bredere simulaties om te beantwoorden aan “wat als” vragen waarbij er de mogelijkheid bestaat om verschillende beleidsscenario’s tegen elkaar af te wegen. Beleidsbeslissing: Het communiceren naar stakeholders om te tonen wat de beslissing kan zijn of om de beslissing te communiceren. Implementatie: Digital Twin kan gebruikt worden om kort op de bal te spelen door data die binnenkomen via de implementatie te gaan gebruiken bij het bijsturen van het beleid. Evaluatie: Samenbrengen van alle data om zo evaluatie te gaan maken voor de relatie tussen de verschillende fasen én de volgende cyclus te gaan voeden. Local Digital Twin : Het is dus een data-gedreven beslissingstool waarbij de volgende kenmerken kunnen onderscheiden worden: Virtuele voorstelling om een stad & processen digitaal voor te stellen. Synchronisatie van de data, waarbij de frequentie zal afhangen van de use case en het gebruik van de Digital Twin – vb. data over gebouwen: minder synchronisatie nodig. Data kwaliteit: Nood aan correcte, actuele, betrouwbare en transparante data. Geeft cross-domein inzichten: samenbrengen en op basis daarvan cross-domein inzichten mogelijk maken. What-if simulaties zijn mogelijk: impact analyses gaan mogelijk worden, vb. door aanpassen van indicatoren. Ondersteunen van evidence-based beslissingen: Via data beslissing onderbouwen. Maar er zijn uitdagingen: Interoperabiliteit, orkestratie van modellen, standaardisatie. Hier loopt onderzoek naar bij Imec en op Europees niveau. Cruciaal om mee te nemen is dat de data centraal staan. Een aantal basisprincipes die daarom moeten gevolgd worden : Toegankelijkheid, vindbaarheid, veiligheid, uitwisselbaarheid, betrouwbaarheid, herbruikbaarheid, privacy, kwaliteit, transparantie (vb. hoe zijn de modellen getraind? Op basis daarvan beslissen voor welke use case het kan gebruikt worden). Via deze principes kan de kwaliteit bewaakt worden. Er is nood aan betrouwbare en kwaliteitsvolle Digital Twins om zo beleid te gaan vormgeven en beslissingen te gaan nemen. Beslissing = data x interpretatie x cultuur Interpretatie: Via applicaties om te presenteren aan gebruikers, ook domeinexpertise, vb. mobiliteitsexpert moet kunnen begrijpen wat het model zegt, datascientist gaat methoden bepalen, dus moet model ook kunnen interpreteren. Cultuur: Zijn er bepaalde processen en rollen aanwezig in organisatie zodat data worden onderhouden en levenscyclus gestructureerd is, maar ook is er de gewoonte om gebruik te maken van data. Digital Twin kan data & interpretatie gaan afdekken, maar cultuur is ook van belang. European Commission Working Model voor Smart and Sustainable Communities: Je begint onderaan de ijsberg en gaat zo content en betekenis toevoegen. Op die manier kan je beslissingen nemen. Het EU systeem gaat uit van éénzelfde logica en er is een alineëring tussen beide. Daardoor kunnen we hier ook op verder bouwen via VLOCA. Een aantal voorbeeldprojecten: DUET / Urbanage / Compair / Brugge DUET (Lieven Raes / Jurgen Silence): Sprekers : Lieven Raes (ADV) / Jurgen Silence (ADV) Opname : De opname van dit onderdeel is beschikbaar via deze link . DUET is een H2020 project, gecoördineerd door de Vlaamse overheid (ADV), met o.a. participatie van Imec, KU Leuven en TNO. Naast de use case focus op Vlaanderen zijn er ook use cases in Athene (Griekenland) en Pilsen (Tsjechië). Doelstelling is om een Digital Twin te bouwen die kan helpen bij het voorspellen en onderbouwen van beleidsbeslissingen. DUET laat toe om heel snel aanpassingen te maken, nieuwe cases te bouwen, visualisaties aan te maken. Voorstelling van use case Gent : Doel is het afsluiten van een weg in de stad en te kijken naar impact op o.a. geluid en verkeer. Demonstratie van het model voor bezoekers: Je kan zien dat de impact van het afsluiten van één brug een grote impact heeft op de gehele omgeving. De bezoeker kan de simulaties gaan inkijken, maar kan niet zelf een simulatie maken. Via de delta-laag kan begrepen worden wat de invloed is van een bepaalde beleidsbeslissing. Demonstratie van het model voor experten: Je kan de view wijzigen, data-lagen toevoegen (o.a. 3D view van Gent, toevoeging van groen). Via “Change” de brug afsluiten. De verkeerssituatie zal wijzigen door het afsluiten van de groep. Via de delta-laag zal het duidelijk worden waar de luchtkwaliteit zal verslechteren en verbeteren. Voor het geluid kan eenzelfde situatie gesimuleerd worden. Tot slot de simulatie van stikstofdioxide via VITO datamodellen, gekoppeld aan het DUET project. De delta laag zal aangeven wat de verschillen zijn. Momenteel focus op de snelheid van de berekeningen en de visualisering. DUET Pilsen : In Pilsen werd een gelijkaardige simulatie gemaakt voor het afsluiten van een brug, ook in de praktijk toegepast en het model bleek zeer correct. Voor luchtkwaliteit werden een aantal simulaties en fictieve berekeningen gemaakt. Met de beleidsmakers en experten gaan we dan ook kijken wat een sterke of beperkte daling en/of stijging is. DUET Athene : Athene focust op verkeerstellingen en air quality sensors. Dit geeft een andere kijk op de Digital Twin en laat toe om burgers meer context te geven. Dat is een belangrijk principe van DUET: Het is ook een communicatie tool naar burgers toe. DUET T-cell architecture : Tool voor beleidsmakers en burgers Realiseren van specifieke cases en scenario’s Ondersteunen van beleidsmakers startende vanuit bestaande componenten. Doelpubliek : DUET is zowel voor burgers als beleidsmakers. Het is een digital twin die bestaande modellen, API’s en een verdere toegevoegde waarde wil creëren. Compair Sprekers : Lieven Raes (ADV) / Jurgen Silence (ADV) Compair werkt o.a. met Telraam, Mobiel 21 en VMM. Lieven Raes demonstreert een dashboard over luchtkwaliteit, gebouwd via het Compair project. Compair gaat de luchtkwaliteit in schoolomgevingen meten en zal nu ook uitgebreid worden met stikstofdioxidesensoren. Een volgende stap is om ook via de burgers informatie te kunnen gaan verzamelen. Urbanage Sprekers : Lieven Raes (ADV) / Jurgen Silence (ADV) Urbanage focust op hoe een Digital Twin kan ingeschakeld worden in de stad voor ouderen, waarbij het comfort wordt weergeven via een aantal parameters. De parameters kunnen door mensen ter plaatse bijgestuurd worden en zo kunnen – via AI – de kaarten verder verduidelijkt worden. Vb. bepalen van de schaduwplekken in de stad. Urbanage geeft ook een visualisatie van picknicktafels en banken. Er is ook een gamificatie aspect aan verbonden, zo de gebruiker toelaten om een bepaalde plek aan te duiden en te voorzien van informatie (vb. gevaarlijke situaties). Digital Twin Brugge Sprekers : Bram De Vreese (Stad Brugge) Proces beschrijving : Beleidsplan 2019-2024 werden acties beschreven om de stad slimmer te maken. SDGs zijn het raamwerk. Begin 2020 werd beslist om in te dienen voor een use case met Imec: Focus op milieu en mobiliteit – wat is de impact van luchtkwaliteit als we een bepaalde verkeersbeslissing gaan nemen. Daarna werd dit verder verfijnd waarbij nieuwe functionaliteiten werden bepaald via workshops. Via innovatie workshops werd ook een planning opgemaakt. Het is een iteratief proces, er werd een bepaald mandaat gegeven aan de stad Brugge – meer dan enkel de use case gaan bepalen. Workshops zorgen voor kennis bij de stad over agile werken, big data en de waarde ervan, betekenis en waarde van een Digital Twin en het belang van een dataplatform (samen in opzet met Leuven & Roeselare). Het dataplatform zorgt voor mogelijkheid tot ownership over de data. Nu gebruiken we het Smart City Platform van Imec. Naast de historische data die we samenbrengen, ook nuttig om meer te focussen op de verfijning. Bij Brugge was er oorspronkelijk weinig kennis, maar samen met Imec versterkt. Twee overheidsopdrachten: eentje voor het rekenmodel mobiliteit en het rekenmodel luchtkwaliteit. Modellen bieden het potentieel om bestaande berekeningen te gaan vervangen en de bevragingsfrequentie te gaan verhogen. Niet zeker of de modelleringen de verwachtingen zullen kunnen inlossen, maar de stad ziet er wel potentieel in als middel om de huidige modellen te gaan wijzigen. Conclusie : Een intensief proces, waarbij veel actoren moeten aligneren. Kennis van Imec is gewaardeerd. Proof of concept is in ontwikkeling, en als stad investeren we in iets duurzaam en puur in iets innovatief investeren is niet makkelijk. Door de industrie te betrekken hebben we het gevoel dat het een product zal zijn om duurzamer te gaan inzetten. Vragen Michael Sibiet (Stad Leuven): DUET – Is het de bedoeling om uit te bouwen naar een Vlaamse toepassing zodat iedereen het kan gebruiken. Jurgen Silence: Nu in ontwerp fase, we bouwen een aantal functionaliteiten, maar iedereen kan het gebruiken. Michael Sibiet: En verzameling van de data, vb. 3D hoogtemodel loopt via Vlaanderen, maar vb. lokale bronnen (bomen). Hoe zien jullie dat? Jurgen Silence: Via de DUET back-office kan je zelf lagen gaan toevoegen en zo combineren met wat in het systeem zit. Michael Sibiet: Is er een bepaalde vastgelegde structuur, zijn er vaste parameters? Of is er uitleg in de metadata? Jurgen Silence: De opbouw van de dataset, we laten het breed open zodat datasets met een breed format toegelaten zijn. De broker centraal moet zoveel mogelijk data toelaten. Eventueel wel wat omzetten. Koen Triangle: Er is nood aan afstemmen van datastructuren en het bepalen van een woordenschat. Dit willen we doen via principes zoals ‘data under governance’ en ‘data under management’. We hebben daar een methodologie voor en die koppelen we vaak aan Smart Data. We moeten kijken hoe we data op elkaar kunnen mappen zonder er een ‘spaghetti’ van te maken, dat bespreken we in het VLOCA traject en willen we delen en afstemmen met de deelnemers. Hendrick Meynen (MIVB Brussel): Brussel als complexe entiteit, er zijn meerdere actoren achter het project DUET. Kan je toelichten hoe DUET is ontstaan? Koen Triangle: Ontstaan door een evolutie, Imec gaf presentatie op Supernova over een Digital Twin en toen hebben we een idee meegegeven. ADV was toen bezig met H2020 PoliVisu project. En die twee sporen vonden elkaar, en zo een H2020 funding project gevonden, met een consortium van internationale spelers – onderzoek & privé. Nu drie jaar onderzoek rond doen, loopt af in dec. 2022. Dus daarom kunnen we dit tonen. Hendrick Meynen: Interessant om dit te horen, het is gradueel gegroeid. Koen Triangle: Data transparantie en governance, dat zijn dingen die gradueel komen. Straks ook nog kijken naar het maturiteitsmodel voor de digital twin. Elke level dient een use case, en ze stijgen in complexiteit maar ze zijn ook complementair, afhankelijk van de use case waarop de focus ligt. Bart De Lathouwer (Stad Rotterdam): Je sprak over smart data, wat bedoel je met smart data? Koen Triangle: Big Data gaan over hoeveel, snelheid etc. Als je die data niet gaat structureren, dan is het een naald in een hooiberg, en dus via smart data proberen we data semantisch te beschrijven, en via ontologie gaan we data structuren, en zo context geven aan de databronnen. Vb. kwaliteit van de data zo gaan begrijpen – definiëren in een breder systeem. Zo de kwaliteit gaan laten begrijpen door de verschillende groepen die de data gaan gebruiken. Bart: Dus semantische verrijkte data? Dat is een prima antwoord. Gert Van Oost (Stad Antwerpen): DUET – Enkel visualisatie van het verkeersmodel in 3 kleuren of zijn er nog andere opties (met identify de verkeersintensiteit bevragen) Jurgen Silence: Je kan elk wegsegment aanduiden en dan zie je de hoeveelheid verloop op ieder stuk wegsegment over een 24u cyclus. Lieve Heyrman (Stad Leuven): DUET – Het is nog een simulatie, wordt er een accuraatheidscore aan toegevoegd om de kwaliteit van de data te bekijken en te weten hoe accuraat de resultaten zijn? Jurgen Silence: Nee dat doen we nu niet, misschien in de toekomst wel als we meer data binnen krijgen. Koen Triangle: Dat is ook voortschrijdend inzicht, het project werd 3 jaar geleden geschreven. De accuraatheid van de data, gaat ook samengaan met de cultuur. We gaan dan ook meten in de stad, en zo gaan afzetten tegen de simulatie en zo dan de loop gaan sluiten. Zo gaan we ook meten in de stad Brugge. Conclusies uit de interviews Sprekers : Martine Delannoy (Imec) / Maxim Chantillon (Imec) Doelstelling/methodologie : Ter voorbereiding van deze workshop werd er een reeks interviews afgenomen. Deze dienen ter stoffering van het workshopgedeelte waarbij elke deelnemer wordt uitgenodigd om de belangrijkste drie conclusies mee te nemen naar de workshop straks. Er zijn 8 interviews uitgevoerd met in totaal een twintigtal personen uit 8 verschillende steden. Het topic hierbij was duurzame leefkwaliteit (luchtkwaliteit, verkeer en geluid). Bevindingen : Onderwerp Bevinding uit de interviews Beleidsproces: Wanneerwe met de steden spraken over het beleid, bleek dat alle steden een algemeen beleidsproces volgen. Sommigen hadden ook nog een voortraject, maar het algemene lineaire proces wordt vrij strikt gevolgd. Naast dit politieke en ambtelijke traject is er een cyclisch, iteratief proces ter ondersteuning van de hele stedelijk werking dat heel wat kansen biedt voor Digital Twin-achtige toepassingen. Huidige praktijken: Er wordt al gewerkt met centrale dataplatformen, of deze zijn in opbouw. Er is wel technisch legacy (een wirwar van systemen) ontstaan door een historiek van decentrale ICT keuzes waarbij elk dienst of departement zelf een eigen toepassing in huis haalde met inefficiënties en overlappende aankopen als gevolg. Dit wordt momenteel aangepast door beslissingen over ICT aankopen te centraliseren. Er is heel wat samenwerking tussen steden in concrete trajecten en netwerken. Dit neemt tijd in beslag maar wordt als waardevol ervaren. Beslissingen worden formeel genomen door de politiek. De administratie is bezig met het voorbereiden van adviezen en met het opvolgen van bepaalde indicatoren, maar beslissen zelf niet en brengen zelf weinig eigen zaken aan. Er is een verschuiving merkbaar van datarollen en bevoegdheden van ICT-diensten naar de zogenaamde ‘business’ of de inhoudelijke domeinen. De waarde en het strategisch belang van data wordt erkend. Steden gaan ook vaak te rade bij externe partners en partijen om data, modellen en studies (bijv. Ruimtelijk of rond specifieke vraagstukken) aan te kopen. Data & modellen: Er wordt gebruik gemaakt van zowel interne als externe data. Men voelt heel hard de noodzaak voor een datawarehouse, maar dit is nog geen gemeengoed. Ook Citizen Science wordt al geregeld eens aangewend. Qua domeinen is mobiliteitsdata al het meest ingeburgerd (data verzameld door stadsorganisatie), terwijl geluid en luchtkwaliteit (data verzameld door hogere overheid) nog eerder projectmatig en dus sporadisch worden aangewend. Externe data wordt wel minder frequent gebruikt in het beleid. Noden: Er is absoluut een nood om de fundamenten rond data en databeheer verder uit te bouwen vooraleer de rol van data in beleid verhoogd kan worden. Standaardisatie is hierbij iets waar vaak tijd en middelen aan verloren worden. Er is vraag naar een gedeelde infrastructuur om overlap te vermijden. Ook ondersteuning rond praktische dataverzameling is gewenst: welke sensor, hoe te gebruiken, kwaliteit,...? Men ziet hier echt heil in samenwerking op Vlaams niveau, zowel met andere steden, besturen, overheden maar ook bedrijven. Drempels: Datakwaliteit is een veelgehoord probleem. De datamaturiteit bij de steden lijkt ook een issue om verdere stappen te kunnen zetten. Gebrek aan middelen, zowel financieel, personeel met de juiste (data-)skills als tijd (te veel ander werk) worden aangehaald als issues om verdere stappen te zetten. Ook de huidige subsidiemechanismen en -benaderingen van steden zijn te vaak gericht op één-op-één relaties en stimuleren concurrentie. Zoals gezegd lijkt een samenwerking hier de juiste aanpak volgens steden. Er waren ook vragen rond de openbaarheid van bestuur en de ‘causaliteit’, waardoor het gebruik van datamodellen en het inzetten van decision support tools soms als een boemerang zou kunnen werken voor beleidsmakers. Hier dient dus zeker aandacht aan besteed worden. Workshop: Digital Twin in de beleidscyclus van duurzame leefkwaliteit Moderatoren : Martine Delannoy (Imec) / Maxim Chantillon (Imec) / Dimitri Schuurman (Imec) Notulisten : Steven Degelaen (ABB) / Fabian de la Meilleure (ABB) / Koen Triangle (Imec) Doelstelling : Op basis van de belangrijkste uitdagingen voor de deelnemers, geïdentificeerd via de presentatie van de interviewresultaten, in groep nadenken over mogelijke oplossingen die kunnen geboden worden in het VLOCA kader. Nadruk lag daarbij op de volgende onderdelen: Standaardisatie / Technische componenten / Infrastructuur / Kennis / Principes / Andere. De groep werd ingedeeld in 3 groepen. Uitkomsten : Beschikbaar via dit Miro Bord . Beschikbaar, per groep, via de volgende linken: Groep 1 Groep 2 Groep 3 Plenaire samenvatting van het interactieve deel Groep 1 : Heel wat interessante noden, vooral op het vlak van complexiteit van oplossingen, datakwaliteit, nodige gezamenlijke investeringen, samenwerking privé-publiek, standaardisatie, interactie en relevantie. Oplossingen binnen VLOCA focussen op technologische componenten en standaardisering. Zoals het instellen van kwaliteitschecks, centrale API’s voor data, integratie tussen verschillende simulatiepakketten en het aanleveren van data voor validatie en controle om betrouwbaarheid te bekijken. Voor standaardisatie heel wat voorbeelden en discussie over hoe aanbesteding kan zorgen voor navolging van standaarden (afdwingbaar, verhoogde criteria etc.). Rond kennisprincipes en andere ook heel wat punten zoals het vermijden van herhaling door lokale overheden en belang van herbruikbaarheid door ontwikkelende overheidsniveau (lokaal – regionaal) juist te kiezen. Groep 2 : Uitdagingen die aan bod kwamen zijn o.a. standaardisatie, afstemming tussen overheden, verantwoording rond data (o.a. data accountability) en rol van algoritmes. Mogelijke oplossingen die aan bod kwamen: een Architecture of Standards, datakwaliteit en checken van datakwaliteit via tooling en toetsen aan realiteit (via aannemers op terrein), voor sensoren zou een catalogus nuttig zijn (wie gebruikt wat en voor welke doelstelling), innovatie is belangrijk maar niet steeds voldoende middelen en datakwaliteit kan versterkt worden via een scoring systeem (nood: data worden steeds gebruikt in een bepaalde context dus rekening houden met de gebruikte context). Groep 3 : Uitdagingen waren o.a. het koppelen van gegevens (veel gegevens, vaak in silo’s, vaak ook datakwaliteit, formaten (2D-3D), up-to-date houden van data) en de weg van theorie naar praktijk (nog vele tussenstappen, soms zit wetgeving in de weg en dus ook praktisch mee omgaan). Ook gebrek aan standaarden en de nood aan interoperabiliteit kwam aan bod. Oplossingsrichtingen die aangehaald werden zijn o.a. smart principes en data governance, het semantisch annoteren om zo de interoperabiliteit te kunnen borgen en de nood aan actieve samenwerking met anderen om kennis op te pikken en te delen. VLOCA Architectuur kaderen in relatie tot een Digital Twin Spreker : Stefan Lefever (Imec) Opname : De opname van dit onderdeel is beschikbaar via deze link . Binnen VLOCA speelt zich heel veel af, met veel verschillende deelnemers en achtergronden. Het Local Digital Twin traject is één van de trajecten binnen VLOCA. VLOCA is een innovatieprogramma, en stelt zich als doel om kennisdeling naar een hoger niveau te brengen. De volgende thema’s werden besproken: VLOCA architectuur: Waarom? VLOCA architectuur: Hoe? Architectuur van Local Digital Twins en data-gedreven beleid en waarom smart data essentieel zijn Een holistische visie op (smart) data, informatie en IT Terug naar de VLOCA architectuur Digital Twin ambitions levels : stap voor stap aanpak Korte vooruitblik op de volgende workshops Wat betekent Local (in Local Digital Twin)? : Vroeger was het Urban, nu is het Local. We haken in op het Europese verhaal en terminologie. Op Vlaams niveau kunnen we de Local Digital Twin bekijken op het gemeentelijke niveau en de relatie naar Vlaanderen. Dus Digital Twins zijn nog steeds tamelijk innovatief en de uitdaging om deze uit te bouwen is wel stap voor stap aan te pakken. Agile is hot, maar kan in de praktijk ook wel werken. Het organiseren is de grote uitdaging. VLOCA Architectuur: Waarom? : Via VLOCA worden referentie digitale vraagstukken bekeken, waarbij de vraagkant cruciaal is en de vraag en aanbod op elkaar gaan worden gelegd via de referentiearchitectuur zodat ze bruikbaar zijn voor de vraagzijde (tot op niveau van de componenten, standaarden, etc.). Zo komen tot een gemeenschappelijke taal, om zo onze informatie te delen en met elkaar te communiceren. Ambitie moet zijn om met VLOCA definities te gaan brengen, via VLOCA Compliance Scores, om zo een Kennishub te hebben die bruikbaar materiaal is voor de gebruiker. VLOCA architectuur: Hoe? : Hoe kunnen we de referentiearchitectuur gaan zien? Via een onderverdeling in het business niveau, het functioneel niveau en het technisch niveau. Business niveau: Er zijn problemen en we moeten daar een oplossing voor zoeken – waar willen we naartoe? Wat willen we bereiken? Dat is de focus voor de VLOCA trajecten en het waarom. Capteren van problemen en opportuniteiten. Moet aan de principes gekoppeld worden – zoeken naar vertalen van de FAIR+ principes en CAIRE principes. Functioneel niveau: Wat moeten we gaan doen om het probleem te kunnen oplossen? Wat is de capability, wat zijn de capaciteiten om de problemen op te lossen? Belangrijk om de gemeenschappelijke vragen op te schrijven/te capteren en zo mee te nemen naar aanbestedingen wanneer we naar de markt gaan. Hoe kunnen we functionele vragen gaan omzetten. Welke capabilities zijn er nodig? Welke standaarden? Sinds start van VLOCA zijn er andere initiatieven ontstaan, zoals GAIA-X, de Smart Region Office, de Vlaamse Dataspace. VLOCA kan hier een deeltje bij gaan helpen om dit te vertalen naar de realiteit. Heel veel aspecten zitten ook vervat in what-if-scenario’s: Hoe moeten we hier mee omgaan (vb. stress in de stad, COVID beheersing, verouderde bevolking aan de kust)? Hoe de maatschappij beter gaan ondersteunen? Vb. er zijn te veel auto’s, dus mobiliteitsplannen gaan evalueren, maar wat is de impact? Vb. stress in de stad, hoe gaan meten en mee omgaan? Er zijn verschillende tijdshorizonten mee verbonden, dus zorgt voor erg veel complexiteit. Technisch niveau: Welke techniciteit heb ik vandaag nodig om aan de noden van de hogere niveaus (business / functioneel) te voldoen? Architectuur van local digital twin en data gedreven beeld : Een digital twin ambieert een sneller beleid gedreven door data (bij een data-gedreven beleid dient steeds opgepast te worden voor statistisch foute correlaties en causaliteit). Tegelijk zijn data erg divers, dus moeilijk te valideren en erg variabel. Dit maakt dat data-gedreven beleid een continu leerproces is. Data passen in een piramide: Als je geen data hebt, dan ook geen informatie, kennis of wijsheid. Daarbij moet je rekening houden met het feit dat je moet weten hoe je data gewijzigd zijn. Als je data anders zijn dan tevoren, dan kan dit ook de inhoud gaan wijzigen en kan het je wijsheid over een bepaalde situatie gaan veranderen. Dus als je data anders zijn, dan moet je de datapipeline goed in orde krijgen om te weten wat er precies gewijzigd is in de data om zo met de data te kunnen omgaan. ML lifecycle: In een data-gedreven beleid worden beslissingen een continue proces en die kunnen dus niet begrepen worden door enkel op één moment te gaan beslissen. Smart data: de som van big data + semantiek + data kwaliteit + security + data protection + utility (= de mate waarin de data bruikbaar zijn voor datagedreven beleid en sturing). Utility: Is er een fit for purpose (want de data moeten hun doel kunnen dienen)? Een holistische visie op (smart) data, informatie en IT : De stedelijke use cases zijn cross-domein, hier moeten we meer zicht op krijgen. Om te zorgen dat Vlaanderen een koploper kan worden, moet er een duidelijk link zijn naar de operationalisering. Maar wat is een Digital Twin dan? Heel veel onder de ijsberg, en we moeten trachten vanuit VLOCA om het te gaan “ontmisten”. Digital Twin Consortium: Zij hebben een digital twin periodic capability opgebouwd. Het is nuttig om het werk van VLOCA hier op te mappen en te begrijpen hoe de overeenkomsten zijn tussen beide. Ze hebben een periodieke tabel opgebouwd die agnostisch is, ze starten in de fysische omgeving om zo de simulaties te kunnen doen. 6 categorieën bestaan hierbij, zijnde data services, integration, intelligence, UX, management en trustworthiness. Dit consortium is gericht op de private industriële Digital Twin. Binnen VLOCA gaan kijken wat deze mapping betekend voor een publieke Digital Twin, want een publieke omgeving is veel complexer. Het biedt de mogelijkheid om te gaan kijken vanuit de industrie welke functionele capaciteiten beschikbaar zijn want ook voor een publieke Digital Twin moet je begrijpen wat het digitale aanbod kan zijn naar de markt toe. Terug naar VLOCA architectuur : De VLOCA architectuur start vanuit een macro visie op Local Digital Twins, waarbij er een opbouw is via Data Spaces en Data Platforms. De dataplatformen kunnen zowel high als low velocity data vergaren, semantische context toevoegen etc. EU zet zeer sterk in op data spaces. De ecosystemen van actoren die al heel sterk met elkaar gaan communiceren is een data space, en EU wil een level playing field om niet enkel data te delen, maar ook contracten, gebruikersprofielen, enz. Hoe kan de data ontdekt worden? De data spaces zijn in volle ontwikkeling alsook hun governance, door Gaia-X o.a. Dus data delen en transparantie daarrond moet tegen 2025 een feit zijn – hopelijk – en we zouden dit ook vanuit Vlaanderen mee moeten krijgen en mee co-creëren. Data spaces zouden de moeilijkheden rond data althans gedeeltelijk moeten oplossen. Maar: nog niet voldoende. De use case moet gerealiseerd worden, en de koppeling en semantiek daarvan moeten nog steeds uit verschillende data spaces komen. Aangezien data spaces verschillende semantische achtergronden gebruiken, vraagt dat nog steeds management. Hoe kunnen we omgaan met heterogene data? Private sector heeft veel oplossingen, dat kan ook gebruikt worden in de publieke sector. De VLOCA donut mapt quasi volledig op de tabel van het Digital Twin Consortium en er werden nog een aantal zaken aan toegevoegd. De donut helpt om het VLOCA te vertalen naar de gebruiker, het werkt beter dan een gelaagd model. Next steps : Welke standaarden horen er bij? Welke vereisten en capaciteiten zijn er nodig? We moeten patronen vinden in de business vragen (WAAROM) en in de functionele vereisten en capaciteiten (WAT). Maar: belangrijke vraag – waar moeten we nu aan beginnen? We starten met kleine stappen en we moeten het besef creëren over wat er op ons afkomt en hoe er nu al iets mee te doen. Een Digital Twin kan verschillende ambitieniveaus hebben en dat helpt om elkaar te begrijpen. Er zijn 6 verschillende niveau’s, maar het één is niet beter dan het ander. Welk niveau je ambieert hangt af van wat je wil bereiken. Level 1: Minder capabilities dan vb. Een niveau 6. Een 2D/3D map/system. Een klassiek GIS systeem, gaat de data visualiseren. Wat hebben we nodig? Externe data sources – vb. GRB, economische data, interne data sources – logistiek, mobiliteit. Via integratie een aantal zaken gaan doen. Level 2: Connected to static data and metadata. Time series moeten opgeslagen worden, er is een historiek om de Digital Twin te gaan realiseren en om de data zo te kunnen gaan gebruiken. Er is een data capture en een vorm van data management. Hoe gaan we data bijhouden? Hoe gaan we ze analyseren? Level 3: Link naar real-time. Vb. Sensoren, maar niet steeds real-time. Er zijn metingen in een bepaalde context, en die context factoren moeten meegenomen worden. Level 4: Jump naar what-if scenario’s via het toevoegen van simulaties. Er is training via een bepaalde dataset, dus het kennen van de simulation assets is cruciaal. Er is nood aan een semantische onderbouwing en annotatie van de simulation assets. Smart Applications zijn de front end, vb. DUET. Hoe kan een verifiable data organisation gecreëerd worden om te zorgen voor een duidelijke connectie naar de eigen use cases? Level 5: Niet besproken. Level 6: Niet besproken. Smart City Map of enabling (functional) capabilities: VLOCA moet een taal creëren waarbij we allemaal dezelfde inzichten en taal gebruiken. Korte vooruitblik op volgende workshops : Basis boodschap: stap voor stap digitalisering/dataficering is mogelijk en afhankelijk van de business ambities. In de volgende workshops willen we focussen op specifieke klemtonen/patronen voor een data-gedreven beleid. Vragen : Bart De Lathouwer (Stad Rotterdam): Hoe vermijden we dat Data Spaces de nieuwe silo's worden? Koen Triangle: Dat is nog in flux, en data spaces hebben tot doel om af te spreken binnen één domein en dus zo vermijden dat het silo’s worden, maar dit is nog iets voor de komende 5 jaar, o.a. via Gaia-X. Bart De Lathouwer: in welke mate is Gaia-X dan normatief? Koen Triangle: We volgen op en trachten dit kritisch toe te passen en te bekijken wat nuttig is. Geeft lessen en mogelijkheden om van te starten. Gert Vervaet: Goed om alles kritische te bekijken, we moeten er rekening mee houden dat iets misschien 80% goed is en past bij de bredere context. Soms beter om het niet ideale te kiezen en verder te gaan met de groep i.p.v. weer te ontwikkelen. Gert Vervaet (ADV): Modellen gebruiken intern een databank (spatial of andere), en die modellen sturen dan ook informatie uit via een bepaalde weg. Maar die weg kan anders zijn in Waze, bij Google etc. Dat zijn allemaal andere definities. En bij Open LR en AGORA-C opgelost, maar niet allemaal bruikbaar bij de Digital Twin. En we moeten daar over nadenken. Stefan Lefever (Imec): Zeker meenemen in dataspaces. Als iemand een weg deelt, iemand die een scenario deelt, dan moet dat via één van de standaarden die daar aanwezig is, dan maakt het dat mogelijk om data te delen. Ge kunt niet verwachten om met alles rekening te houden. Gert Vervaet: Open LR wordt ondertussen door een grote groep gebruikt, en dat is nu al succesvol. Bart De Lathouwer (Stad Rotterdam): NGSI staat mee in je donut - wordt dit door VLOCA omarmt? Stefan Lefever (Imec): De donut bevat een aantal voorbeelden, we kijken naar de Europese standaarden maar als er andere dingen moeten bijkomen, dan mag je het altijd laten weten. Afsluiten & Next steps Spreker : Steven Degelaen (ABB) Workshop informatie is vanaf week 21/02 beschikbaar. Volgende workshops vinden plaats op: Donderdag 17/03/2022 – 13-17u – structuur en beheer van data Donderdag 21/04/2022– 13-17u – simulaties op basis van modellering Dit zijn meer technische sessies, en je moet over een technische bagage beschikken. Vragen/opmerkingen mogen steeds doorgestuurd worden naar vloca@vlaanderen.be. +
Deelnemers Imec Agentschap Binnenlands … Deelnemers Imec Agentschap Binnenlands Bestuur (ABB) Departement Mobiliteit & Openbare Werken (DMOW) Vlaamse Instelling voor Technologisch Onderzoek (VITO) Stad Antwerpen Stad Brugge Stad Gent Stad Leuven Gemeente Kampenhout Centrum voor Informatica voor het Brusselse Gewest (CIBG) Maatschappij voor het Intercommunaal Vervoer te Brussel (MIVB) Inleiding Spreker : Fabian de la Meilleure (ABB) Overlopen van de agenda en het introduceren van de werking tijdens de sessie, via chat en Slido. Een aantal verwachtingen kwamen naar boven bij de deelnemers: Kaderen van concept Digital Twin & bredere landschap Informatie over modellen voor Digital Twins & hoe er mee om te gaan Informatie over 3D modellering Co-creëren van een visie over steden heen voor Digital Twins. Recap: Framing Digital Twin Spreker : Koen Triangle (Imec) Opname : De opname van dit onderdeel is beschikbaar via deze link . Digital Twin / Data-driven decision support system : Een manier op data in te zetten voor het creëren van publieke waarde, en dus een systeem om data-gedreven beslissingen te ondersteunen. De data zal daarbij dus gebruikt worden voor het creëren van publieke waarde en zal ingezet worden in de beleidscyclus. Kenmerken van een Local Digital Twin: Virtuele voorstelling van entiteiten en processen Gebruik van gesynchroniseerde data Correcte, betrouwbare en transparante data is cruciaal: Belangrijk om bijvoorbeeld te weten hoe de data is ingewonnen, of hoe een vragenlijst is opgemaakt. Als gebruiker moet je de metadata kennen. Qua data kan het zowel gaan over gestructureerde als ongestructureerde data. Cross-domein inzichten: combinatie over verschillende domeinen heen. What-if simulaties zijn mogelijk Ondersteuning van “evidence-based” beslissingen op basis van data Een Digital Twin kan dus gezien worden als een tool om data in te zetten voor het beleid. Data-gedreven overheid : Een local digital twin kunnen we koppelen aan de fasen van de beleidscyclus. Principes : Bij een Digital Twin moeten er steeds een aantal principes nageleefd worden, die belangrijk zijn in het hele proces, zijnde van de data tot de applicatie: Toegankelijkheid Vindbaar Veiligheid Uitwisselbaar Efficiëntie Betrouwbaarheid Herbruikbaarheid Kwaliteit Transparantie Privacy Maar: waar te beginnen? : Er zijn een aantal ambitiesniveaus van een data-gedreven beslissingssysteem gedefinieerd. Heel wat actoren hebben een Digital Twin, maar er zitten veel verschillen op. Bijvoorbeeld GIS systemen, ontwikkeling van cross-domein systemen etc. Afhankelijk van de noden kan een overheid kiezen voor een bepaald Digital Twin systeem/ambitieniveau. Stellingen : Aan het onderdeel “Recap: Framing Digital Twin” waren de volgende stellingen gekoppeld: Stelling 1: Waar ziet jouw organisatie de rol van een data-driven decision support system in het beleidsproces? Stelling 2: In welke beleidsdomeinen heeft de data-driven decision support system de grootste meerwaarde? De resultaten van deze stelling zijn hier beschikbaar. Recap: Smart Data Spreker : Koen Triangle (Imec) Opname : De opname van dit onderdeel is beschikbaar via deze link . Van Big Data naar Smart Data : Er is nood aan een evolutie van Big Data naar Smart Data, om de data bruikbaar te maken. Daarom laten voldoen aan o.a. de FAIR principes, alsook verder werken aan kwaliteit, aan veiligheid, aan semantiek etc. Er is nood aan een goed beheer van de data, Smart Data zorgt hiervoor waardoor de data kan ingezet worden in beslissingsprocessen, en zo kan er ook vertrouwen gecreëerd worden. Daarom is er nood aan een oplossing die voldoet aan systeem principes: Data-gedreven Verschillende tijdsdimensies incorporeren Cross-domein simulaties Betrouwbaar & transparant Verschillende expertisen combineren Open zijn, om zo vendor lock in te vermijden (daarom nood aan o.a. standaarden). BPMN Flow : Deze flow detailleert het volledige proces doorheen het platform en hoe een beslissingsproces kan ondersteund worden via zo’n platform. De flow is opgebouwd via 4 stroken: Business: gaat over het beleid Data: gaat over de data en de kwaliteit ervan Modellen: gaat over de modellen, de specificaties, de accuraatheid, de training, de beschikbare modellen etc. Applicaties: gebruik van de data via modellen om zo te komen tot een business situatie Meer informatie over de BPMN Flow is beschikbaar in dit draaiboek . Conclusie : Tot slot dient aangehaald te worden dat een beslissing een relatie is tussen data, de interpretatie ervan en de cultuur waarin de beslissing zal genomen worden. Interpretatie: de data moet geïnterpreteerd worden, maar er is ook nood aan domeinexpertise (vb. hoe is een model opgebouwd). Cultuur: de processen, de rollen, die nodig zijn voor het onderhouden van de data – (denk aan data stewards, data scientists). Het combineren van deze drie concepten is nodig om te zorgen voor een waardevol gebruik van de data. Stellingen : Aan het onderdeel “Recap: Smart Data” waren de volgende stellingen gekoppeld: Stelling 1: Het koppelen van beschikbare data aan het beleidsproces is iets wat mijn organisatie altijd doet / soms doet / zelden doet / nooit doet. Stelling 2: De grootste uitdaging voor mijn organisatie om te komen tot Smart Data is financieel / interne rollen & processen / juridische uitdagingen / beschikbaarheid van basisdata / beschikbaarheid van basis IT infrastructuur / verzekeren van politieke steun / aanwezigheid van blokkerende bestaande/oude IT infrastructuur. De resultaten van deze stelling zijn hier beschikbaar. Recap: Conclusies Interviews Spreker : Maxim Chantillon (imec) Opname : De opname van dit onderdeel is beschikbaar via deze link . De resultaten van de interviews afgenomen met de centrumsteden werden kort overlopen, alsook hoe de geïdentificeerde uitdagingen gekoppeld werden aan mogelijke oplossingen door de deelnemers tijdens Workshop 1 . Uitdagingen : De volgende uitdagingen kwamen naar voren: Data: Datakwaliteit en bijhouden data Datastandaardisatie & kennis over standaardisatie Datakoppeling en relatie tussen dataleveranciers Samenwerking: Opbouwen gedeelde infrastructuur Relatie interne publieke sector & private sector Andere: Relevantie Digital Twin Evolutie theorie naar praktijk (juridisch / financieel /...) Oplossingen : De volgende oplossingen werden gekoppeld aan de bovenstaande uitdagingen: Data: Datakwaliteit en bijhouden data Datakwaliteit controleren via tooling Gebruik en implementatie van Smart Data Principes & Data Governance Opzetten dataportaal voor dataleveringen en -validatie Datastandaardisatie & kennis over standaardisatie Inzetten op Vlaamse trekkersrol Gebruik standaarden in aanbestedingen Datakoppeling & relatie tussen dataleveranciers Opzetten Central Data API’s Samenwerking: Samenwerking interne publieke sector & relatie met private sector Opzetten Vlaamse Digital Twin Community Verder bepalen standaarden Stimuleren gebruik authentieke bronnen Opleggen minimale standaarden Opbouwen gedeelde infrastructuur Opzetten samenwerkingsverbanden via VLOCA traject(en) Relevantie Digital Twin Begin klein, met praktische use cases Evolutie theorie naar praktijk (juridisch / financieel / ...) Opbouwen lange termijn implementatie via VLOCA traject Gedeelde infrastructuur als middel om kost te drukken Innovatie via samenwerking met industrie Stellingen : Aan het onderdeel “Recap: Conclusies Interviews” waren de volgende stellingen gekoppeld: Stelling 1: Ik kan me herkennen in deze uitdagingen. Stelling 2: De belangrijkste uitdaging om op te focussen is [één antwoord mogelijkheid]: Datakwaliteit en bijhouden data / Datastandaardisatie & kennis over standaardisatie / Datakoppeling & relatie tussen dataleveranciers / Samenwerking in de publieke sector en met private sector / Verder aantonen van de relevantie van een data-driven decision support system / Evolutie van theorie naar praktijk / Niet besproken. Bijkomende vraag bij Stelling 2: Wat wordt met data standaardisatie bedoeld? Bram De Vreese (Stad Brugge): Er wordt veel in deze context over data standaardisatie gesproken, maar kennis is niet steeds aanwezig bij leveranciers. Vragen om het op te nemen in bestekken is goed, maar voor een stad moeilijk om te bepalen welke standaarden ze moeten opnemen en welke referenties er zijn. Het is een snel veranderend landschap en inzichten wijzigen. Het is niet eenvoudig voor een stad om daarin de tussenpersoon te gaan vormen. Dit komt er allemaal bij, naast de dagdagelijkse werking. De resultaten van deze stellingen zijn hier beschikbaar. Basics over modellen Verkeer, Luchtkwaliteit en Geluid Tijdens dit onderdeel werden de basics over modellen voor verkeer, luchtkwaliteit en geluid naar voren gebracht door drie experten. Opname : De opname van dit onderdeel is beschikbaar via deze link . Verkeer Spreker : Wim Michiels (Imec) Verkeersmodellen hebben een lange traditie : Een aantal factoren kunnen hierbij gebruikt worden om een onderscheid te maken tussen de verschillende verkeersmodellen: Grootte van het gebied: micro (zeer klein gebied, vb. kruispunt) – meso (een iets groter gebied, vb. een kleine wijk) – macro (een groot gebied, vb. een dorp/stad) Statisch model (stabiele omstandigheden) – dynamisch model (continue wijzigende omstandigheden) Unimodaal (één vervoersmodus) – multimodaal (meerdere vervoersmodi) Activity based (het idee om te proberen een digitale kopie te maken van de mens en zijn activiteiten, waarbij de inzet vooral focust op het begrijpen van menselijk gedrag en zo modellen te gaan ontwikkelen). Er is zeer veel academisch onderzoek beschikbaar, maar niet noodzakelijk veel commerciële toepassingen. Deze blijven eerder beperkt tot nog toe. Typische toepassing: De klassieke 4-staps modellen : Algemeen genomen zijn er binnen de verkeersmodellering 4 klassieke modellen in gebruik: Trip generation: Een nieuwe activiteit in een bepaalde zone zal leiden tot een bepaalde hoeveelheid verplaatsing – vb. woonontwikkeling, een nieuwe supermarkt. Trip distribution: Inzicht in het aantal verplaatsingen en waar deze naartoe gaan – vb. supermarkt en het effect van de supermarkt op de verplaatsingen in de regio. Modal choice: Zeer uitdagend, waarbij het gaat over het bekijken van vervoersopties en berekeningen daarrond. Trip assignment: Heeft nood aan sterke cartografie, gaat op straatniveau focussen om te begrijpen hoe verkeer zal evolueren. Voorbeeld dynamisch toepassing : De VISSIM simulatie, dat is een microscopisch en dynamisch model, gebaseerd op wetenschappelijk onderzoek. De vraag voor het model is wat de impact is van een nieuwe ontwikkeling in het terrein. Cruciaal : Algemeen kan gesteld worden dat de gebruiksdoelen van een verkeersmodel afhankelijk zijn van de gemodelleerde, meetbare parameters en de data die daarvoor ter beschikking is. Klassiek onderzoek – de Greenshields measurement: Onderzoeker gebruikte een timer en foto’s om te bekijken of er een verband was tussen dichtheid van voertuigen per lengte weg. Zo kan je gaan bepalen of de verkeersintensiteit niet te hoog is voor de capaciteit van de weg. Als de intensiteit toeneemt, moet er dan actie genomen worden om de capaciteit uit te breiden? Dit passen we nog steeds toe op de simulaties – vb. VISSIM simulaties. Het is daarbij nodig om het afwegingskader op een objectieve manier vast te stellen. Conclusies: Een aantal conclusies kunnen getrokken worden: Doelstelling van het gebruik van een model: Inzicht verwerven in de impact van het ene (X) op het andere (Y). Indien we niet kunnen meten, dan kan er weinig mee gedaan worden in een model. Daarbij zijn scenario’s van veranderende toestand nodig: Er is nood aan iets dat moet veranderen, iets dat we als maatschappij wensen of dat een bepaalde actor wilt wijzigen in een bepaalde situatie (vb. bouw van een nieuwe winkel). Maar: er moet opgelet worden met modelpessimisme: het model zal niet altijd vanzelf werken, en je zal dus bepaalde conclusies kunnen trekken en als je niet de nodige conclusies kan trekken, dan moet je het model verder ontwikkelen. Er is niet één verkeersmodel dat alle praktische en beleidsvragen kan oplossen. Maak gebruik van de grote variatie aan modellen voor verschillende vraagstukken. Een model kan ook eenvoudig zijn, en gebaseerd op een beperkte dataset. Je kan een totaalbeslissing over een project en alle bijhorende maatregelen dan onderbouwd nemen op basis van de analyse van de uitkomst van verschillende modellen en bijhorende datasets, elk met zijn eigen sterkte. Het bouwen en bedienen van het verkeersmodel geeft je zeer veel inzicht in de werking van je verkeerssysteem, in de de toepassingsmogelijkheden maar ook de beperkingen. Een interesse in de fundamentele werking van het verkeersmodel is een voorwaarde om de resultaten van het model goed te kunnen interpreteren. Stellingen : De volgende stellingen werden voorgelegd aan de deelnemers: Stelling 1: Welke van jullie beleidsdoelstellingen zouden kunnen worden vertaald in meetbare grootheden, en zijn ze meetbaar? Feedback Spreker: De modal shift is perfect meetbaar, denk daarbij aan het aantal voetgangers, fietsers, vrachtwagens, mensen in bus etc. Deze data kan de basis zijn, en indien je dit regelmatig herhaald kan je de verschuivingen zien. Het moeilijke is de oorzaak van de keuze voor een bepaalde vervoerswijze te achterhalen. Meten is één zaak, maar het verder parametriseren is iets anders. Daarnaast dient er ook rekening gehouden te worden met moeilijkheden tussen domeinexperten en meer technische profielen/ Stelling 2: Voor welke verkeersproblemen zou je graag modellen willen/kunnen inzetten? Feedback Spreker: De modal split is een hot topic. Ook de focus op kruispunten en overdreven snelheid krijgt een hoge score. Overdreven snelheid is makkelijk om mee van start te gaan. Zie in dit kader ook bijvoorbeeld initiatieven zoals telramen en professionele installaties. Verkeersveiligheid scoort erg laag, hoewel het een van de belangrijkste verkeersdoelstellingen is. Stelling 3: Hoe zou je de betrokkenheid van het beleid en de administratie bij modellen kunnen verhogen? Feedback Spreker: De interactieve tool en visuele input scoren zeer hoog. Zelf modellen maken scoort veel minder en ook uitgebreide rapportage scoort veel minder. Met interactieve tools zijn er grote mogelijkheden. Ook het visuele scoort hoog, dat is logisch gezien de wereld waarin we leven, waarin filmpjes heel belangrijk geworden zijn. De resultaten van deze stellingen zijn hier beschikbaar. Luchtkwaliteit Spreker : Stijn Vranckx (VITO) Extra info : meer informatie over luchtkwaliteitsmodellen kan hier gevonden worden. Concept Luchtverontreiniging : Een breed concept dat verschillende aspecten bevat, denk daarbij aan: Deeltjes: fijn stof, roet, metalen, ultrafijn stof Gassen: CO, SO², NO² etc. Er zijn veel vormen van luchtverontreiniging waarmee er rekening kan gehouden worden, dit vraagt dus een keuze of eventueel een focus op meerdere tegelijk. Bronnen die luchtkwaliteit beïnvloeden : Een aantal veelvoorkomende bronnen die de luchtkwaliteit beïnvloeden zijn de volgende: Industrie Huishoudens Luchtvaart Scheepvaart Wegverkeer Landbouw Naast de verschillende bronnen is ook de afstand tot de bronnen belangrijk, het type omgeving, en het weer. Modelleren van luchtkwaliteit : Op het vlak van luchtkwaliteitsmodellen zijn er, net zoals bij verkeersmodellen, een aantal verschillende mogelijkheden: Er zijn real-time toepassingen Daarnaast zijn er ook modellen die forecasting gaan toelaten, het is in dit kader dat weersvoorspellingen belangrijk zijn. Weersvoorspellingen kunnen de luchtkwaliteit namelijk gaan beïnvloeden en forecasting dient dus gebruik te maken van weersvoorspellingen. Een derde mogelijkheid is de historiek: De historiek kan, via modellen, inzicht geven in de langetermijnsevolutie. Tot slot is er een vierde mogelijkheid, waarbij modellen kunnen gebruikt worden als link naar andere beleidsdomeinen. Hierbij kan bijvoorbeeld gedacht worden aan luchtkwaliteit en de link naar verkeersstromen. Luchtkwaliteitsmodellen & parametrisatie : Luchtkwaliteitsmodellen hebben nood aan parametrisatie om te begrijpen hoe de fysische en chemische processen gaan verlopen. Dit dient opgenomen te worden in de modellering. Hierbij kan bijvoorbeeld gedacht worden aan het effect van secundair fijn stof, dat zich vormt door chemische processen in de luchtlagen. Een ander voorbeeld is de street canyon in steden/dorpen: daar is de luchtstroom anders, dus dat dient ook meegenomen te worden als een fysisch proces. Dus afhankelijk van de omgeving en de doelstelling(en) zullen fysische en chemische processen dienen meegenomen te worden. Welke data heeft een AQ model nodig? : Hier werd het voorbeeld van de ATMO-Street modelketen gegeven. Binnen dit model zal een interpolatie zijn met metingen, die kan gecombineerd worden met de gekende uitstoot van wegverkeer/industrie/scheepvaart. De street canyon aspecten zitten nog niet opgenomen in het model, dus dat kan dan nog extra toegevoegd worden. Naast het ATMO-Street modelketen werd ook het voorbeeld van de QUARK voor Duet Digital Twin meegegeven. Dit model gebruikt mobiliteitsdata om te komen tot een luchtkwaliteitskaart, via een koppeling met data uit de vloot en weersvoorspellingen. Conclusies : Er zijn verschillende modellen voor verschillende toepassingen, en hier dient rekening mee gehouden te worden bij de selectie van modellen. Algemeen kunnen de volgende vragen gesteld worden: Wat is de toepassing? Real-time, forecast, historisch of toekomstgericht? Op welke schaal willen we het toepassen? Voor een brede regio of voor een stadsniveau? Welke afweging maken we tussen accuraatheid en snelheid? Welke data heeft zo’n model nodig? Nood aan een uitgebreide en goed beheerde hoeveelheid basisdata. Stellingen : De volgende stellingen werden voorgelegd aan de deelnemers: Hoe ziet jouw organisatie de evolutie/rol van modellen in het beleidsproces evolueren? Feedback Spreker: Er zijn 3D modellen van steden die continu evolueren. Data kwaliteit verbetert ook. In interactieve modelketen ga je ook koppelen met 3D data en de data continue updaten. Dat is verschillend van klassieke modellering en statische data. Met recente evoluties wordt het mogelijk om continu met de meest up-to-date data te werken. Welke vragen wil je kunnen beantwoorden met luchtkwaliteitsmodellen? Feedback Spreker: Duidelijk dat “hoe wijzigt de luchtkwaliteit bij maatregelen” bovenaan staat. “Realtime luchtkwaliteit” staat minder hoog op agenda maar dat heeft eveneens te maken met de doelgroep Wat is voor jou prioritair bij modeloefeningen: responsiviteit of accuraatheid? Feedback Spreker: Accuraatheid zeer dominant, dit is enigszins verrassend. De resultaten van deze stellingen zijn hier beschikbaar. Stedelijk geluiden Spreker : Julien Verplanken (Imec) Waarom geluid? : Onder meer opgenomen in de Sustainable Development Goals, daarnaast ook door de Europese Commissie. Het is dus belangrijk om op in te zetten. Geluidsoverlast is een belangrijk punt in een stedelijke omgeving. Het is meetbaar, net zoals luchtkwaliteit en verkeer, dus daarom ook relevant. Geluidhinder in Vlaamse context : Er zijn bepaalde richtlijnen over het geluid dat mag afgespeeld worden op bijvoorbeeld concerten, maar voornamelijk ligt de nadruk op geluidshinder door verkeer (spoorwegen, wegen, luchthavens). Daarbij zal ook een verschil gemaakt worden voor de tijd: dag, avond, nacht etc. Klankentappers : Zelf een sensor bouwen om klanken te capteren, wat toelaat om aan citizen science te gaan doen. Laat toe om veel data te verzamelen, en via de input ook output. Potentieel van geluid in een Open Local Digital Twin : Urban Sounds Tagging: Reeds in New York getest, je kan geluid gaan verzamelen en koppelen en zo geluidsprofielen gaan opmaken, Buurtprofiel opmaken Sensor/data fusion om de leefbaarheid en levenskwaliteit te verhogen Cross-domein simulaties rond verkeer, geluid en lucht. Wat is Machine Learning? : Traditioneel programmeren zal nood hebben aan manuele invoer van regels via een programma, en de data is gevoed via een verwacht input. Bij Machine Learning ga je output en input geven, via een training, en de output daarvan is het getrainde algorithme – het zogenaamde programma. Buurtgeluidsprofiel : Je kan een heatmap gaan opbouwen om zo een geluidsprofiel te maken. Meer dan anders wordt het hier mogelijk gemaakt om het ruimtelijke en tijdsaspect in kaart te brengen. Op basis van sensordata, uit verschillende bronnen kan je dan een “leefbaarheidsscore” gaan opmaken. Stellingen : De volgende stellingen werden voorgelegd aan de deelnemers: Welke contextuele informatie zou een impact kunnen hebben op hoe geluid als hinder kan worden ervaren? Feedback Spreker: De resultaten zijn in lijn met verwachtingen. Wat zijn volgens jou de meest typische (Europese) bronnen van geluidsoverlast? Feedback Spreker: Minder in lijn met verwachtingen: studies in NY tonen aan dat men daar vaak last heeft van sirenes. Ook zeer veel overlast door werken allerhande en ook airconditioning. Er zijn wat meer oorzaken. In België ligt de focus meer op verkeer, niet onverwacht. Wordt in uw gemeente bij de ruimtelijke ontwikkeling bewust omgegaan met geluid en potentieel geluidshinder? Feedback Spreker: De resultaten geven een zeer verdeeld beeld. De resultaten van deze stellingen zijn hier beschikbaar. Stad aan het woord rond modellen Spreker : Bram De Vreese (Stad Brugge) Opname : De opname van dit onderdeel is beschikbaar via deze link . Waarom werken rond modellen? : De doelstelling om voorspellingen te gaan maken en inzichten te verwerven zorgde voor een nood aan modellen. Stad Brugge had hier dan ook een klassieke use case gebruikt: Wat is de impact van aanpassingen aan de weginfrastructuur? Imec zou de integratie doen van de rekenmodellen voor onze beleidsdomeinen verkeer en luchtkwaliteit, vanuit de use case werd het dan ook nodig om in te zetten om modellen. Kennis? : Er is sterke nood aan kennis over modellen en hoe om te gaan met modellen vooraleer je er zelf mee kan starten voor het maken van beleid. Wat is een model? Welke leveranciers zijn er? Nationaal? Internationaal? Is een combinatie tussen lucht en mobiliteit mogelijk? Wat zijn parameters? Hebben we die als stad zelf voorhanden? Welke verkeerstypes zijn aanwezig? Welke standaarden? Waar moeten we rekening mee houden? Zijn er internationale standaarden? Er was hier ook geen eenduidig antwoord, wat het niet makkelijk maakte. Verschil tussen simuleren (situaties ten opzichte van elkaar) en weergeven (visualiseren). Welke prijzen gelden? Welke databronnen zijn er? Is er integratie mogelijk? Welke API’s zijn beschikbaar? Hoe worden modellen gevalideerd & geoptimaliseerd? Netwerk : Over een netwerk beschikken is cruciaal om om te gaan met modellering. Vanuit Brugge werd er gesproken met de volgende partijen, alsook over het/de model(len) die zij aanbieden/ter beschikking hebben: Aimsun (Siemens Business) PTV-Group TML (KULeuven) AnyWays Departement Mobiliteit en Openbare Werken Vlaanderen De Lijn (Mint) Cegeka Hierbij dient opgemerkt te worden dat het model waar De Lijn mee werkt hetzelfde is als dat van het Department Mobiliteit en Openbare Werken. Luchtkwaliteit : Brugge gaf aan dat VITO is hier toch wel de benchmark is, althans voor Brugge. Internationaal zijn er nog wel wat spelers, maar die modellen moeten dan toch gebenchmarked worden met de data vanuit VITO. Stellingen : Aan het onderdeel “Stad aan het woord rond modellen” waren de volgende stellingen gekoppeld: Stelling 1: Het integreren van modellen en de uitkomsten van deze modellen in het beleidsproces vraagt sterke aanpassingen van het huidige beleidsproces. Stelling 2: De ervaringen van de stad Brugge rond modellen zijn gelijkaardig aan de ervaringen die mijn administratie heeft. De resultaten van deze stelling zijn hier beschikbaar. Bijkomende vragen : Joris Liebens (DMOW): Is er ook ooit overwogen om een stadsmodel Brugge te bouwen dat is afgeleid uit de regionale verkeersmodellen? Bram De Vreese: Ja, maar de vraag is op welke schaal we het willen (macro-meso-micro) en daar is dan ook de vraag van de kostprijs naar boven gekomen. Daarom hebben we beslist om niet op één van de drie modellen verder te werken. Voor ons was de oplossing een model dat werkt met AI en heel wat datasets samenbrengt en een eigen model creërt. Dat was het meest haalbare voor ons, en voor ons ook goede resultaten bracht. Voor onze use case was het niet nodig om een specifiek Brugge model te hebben. Maar misschien voor anderen wel het geval. Joris Liebens: Belangrijk is dat het nodig is om te bepalen wat precies nodig is voor de stad. Koen Triangle: Daarom is het ook belangrijk om transparantie te hebben over model & data, zodat je als modelgebruik kan begrijpen/zien hoe het model is opgebouwd. We moeten daar transparantie in creëren Uitdagingen rond modellen Spreker : Stefan Lefever (Imec) Opname : De opname van dit onderdeel (samen met het volgende onderdeel) is beschikbaar via deze link . Introductie : Modellen en algoritmes maken een integraal en essentieel deel uit van een Digital Twin / Data-driven decision support system ambitie, dewelke zal trachten om een evidence-based decision taking te ondersteunen bij overheden. In Workshop 1 & 2 hebben we heel wat informatie doorlopen over de concepten en de data, deze sessie focuste op modellen. Wat zijn de “hoog niveau” uitdagingen voor Digital Twins? : Hier zijn de Gemini Principles cruciaal, deze bepalen aan principes die kunnen gevat worden in drie categorieën: “purpose”, “trust” en “function”. Op twee punten werd dieper ingegaan: Er dient een duidelijk doel te zijn. De Digital Twin dient betrouw en vertrouwbaar te zijn. VVSG verwijst hier bijvoorbeeld naar het “algoritmeregister” van Rotterdam. Voor bijvoorbeeld parkeercontrole is het dan duidelijk op welke algoritmes dit gebaseerd is, welke databronnen er zijn, welke privacy regels van toepassing zijn, hoe het menselijk toezicht zal gebeuren etc. Er is daarom nood aan een back-end om dit op te zetten, eentje die kan zorgen voor automatisering zonder steeds nood te hebben aan een menselijke interventie. Dit kan dus gezien worden als een standaard geconnecteerde omgeving, en het opzetten van die back-end vraagt een standaard geconnecteerde omgeving. Uitdagingen : Het willen voldoen aan de Gemini Principles levert ook een aantal uitdagingen op: Modellen kunnen data bevatten/gebruiken/creëren Data kan erg complex zijn; denk aan netwerken, variabelen, parameters etc. Modellen mogen niet functioneren in isolatie want dan zullen deze weinig waarde hebben. Modellen hebben eveneens nood aan documentatie om ze verstaanbaar te maken, en zo tot inzichten te komen. De metadata dient machine-readable te zijn, om zo bijvoorbeeld te gebruiken in het asset governance draaiboek. Conclusies : Een aantal conclusie werden getrokken: Modellen zijn essentiële "assets" bij het gebruik van digital twins om tot inzichten te komen over maatschappelijke uitdagingen. Een digital twin moet daarbij de fysische realiteit "virtueel" voorstellen met een niveau van nauwkeurigheid of kwaliteit die "fit-for-purpose" is. Het realisme (en dus de bruikbaarheid daarvan) hangt voornamelijk af van : data : de kwaliteit van de data model : betrouwbaarheid van de algoritmes, validiteit van de "assumpties" en de competentie van de implementatie representatie en visualisatie: Kwaliteit van de presentatie van de output Het vertrouwen in het gebruik van algoritmes dient mee opgenomen worden, zowel door als voor de beslissingsnemers en de andere stakeholders. Aan de hand van VLOCA draaiboeken willen we de lokale overheden ondersteunen bij het bereiken van de principes en het omgaan met de uitdagingen. Stellingen : Aan het onderdeel “Uitdagingen rond modellen” waren de volgende stellingen gekoppeld: Stelling 1: Wat zijn de belangrijkste uitdagingen die jou organisatie ziet rond modellering? Stelling 2: In welke mate weegt de factor “betrouwbaarheid” van modellen door bij het aankopen/ontwikkelen van modellen (naast factoren zoals kostprijs, algemene doelstelling/gebruik, snelheid van aankoop/ontwikkeling, politieke invloed etc.)? De resultaten van deze stelling zijn hier beschikbaar. Hints naar oplossingen Sprekers : Stefan Lefever (Imec) en Stijn Vranckx (VITO) Opname : De opname van dit onderdeel (samen met het vorige onderdeel) is beschikbaar via deze link . Terugblik op standaardistatie : In het verleden is er standaardisatie geweest voor inter-model communicatie (het koppelen van modellen), denk bijvoorbeeld aan OpenMI. Het doel van een OpenMI standaard is het standaardiseren van het ontwerp van de “engine” interface, want dan kan die gelinkt worden met andere modellen, door middel van verdere specificatie: Model definitie, Configuratie en Run-time gedrag. De OpenMI standaard ontwikkelde een standaard voor het koppelen van modellen, en het is net die koppeling die zal zorgen voor een verhoging van de waarde. De standaarden zorgen voor een lokale koppeling van de modellen. Maar nu is er nood aan standaarden die ontwikkeld worden voor de modellen van vandaag. De modellen daarbij niet in isolatie gaan inschakelen maar als een deel van een marketplace. Toekomst : Het verkennen van standaarden en modellen verloopt en zal verder moeten verlopen via onderzoeksprojecten. Vb. DUET, PRECINT, Urbange, Living-in.EU, nationale en internationale initiatieven. Wij hebben voor deze sessie gekozen voor DUET, om zo de interacties wat te kaderen. De focus ligt nu op modelinteracties, hoe de data teruggegeven kan worden, en hoe daar door verschillende deelnemers mee omgegaan kan worden. Voorbeeld DUET : Hoe is dit nu door VITO gebruikt in een setting? In het kader van DUET heeft VITO dit gebruik in het kader van een model agent API: Core 2D model Message broker = gaat iedere 10 seconden kijken of er een bericht binnen komt – geeft een scenario ID van traffic. Traffic model Quark model = voor de luchtkwaliteitsberekening. Via het model kan je verschillende stappen doorlopen om te komen tot een luchtkwaliteitsberekening, op basis van de wijzigende mobiliteit. De kaarten uit het model worden beschikbaar gesteld als een Geotiff, en via een bericht naar de visualisatie gestuurd om het via de DUET interface te gaan visualiseren. Er is ook een proces voor de standaarden voor het koppelen van modellen. Via DUET kunnen we bottom-up een aantal standaardisaties mee gaan vormgeven, en dat is het belang van deze onderzoeksprojecten, en dat laat toe om zaken te versnellen, en zo te komen tot een Digital Twin marketplace. Vanuit DUET leggen we ook de link naar de VLOCA projecten. Maar er zijn meer capaciteiten nodig dan de DUET interactie bijvoorbeeld. Denk aan ontologieën, vocabularium definitie, data schema management, model brokering, workflow/process orchestration. Niet allemaal via VLOCA in behandeling, maar mogelijk wel ondersteunen vanuit VLOCA. Een voorbeeld van standaardisatie is de CityGML3.0, deze voorziet meer integratie van modellen met een digital twin ecosysteem. Hoe kunnen BIM en GIS modellen gekoppeld worden. DT zijn complexe ecosystemen dus hebben nood aan extra koppeling. Oplossingen & waar VLOCA kan helpen : Stap voor stap & delen van kennis uit diverse projecten Realiseren van de uitdagingen aan de hand van projecten Smart assets vereisen een proces Technologie is beschikbaar, maar nog niet in een proces / aanpak gedefinieerd Standaardisatie is nodig om schaalbaar te maken Aligneren met bestaande en nieuwe initiatieven en technologieën Vooruitblik : Er zijn heel wat nationale initiatieven, denk bijvoorbeeld aan het Zweedse Digital Twin Cities Centre, waarbij zij focussen op standaardisatie van metadata en andere vragen zoals: Hoe kunnen we automation gaan ondersteunen (vb. een algortimeregister), hoe kunnen we schaalbaar omgaan met dataflows, hoe kunnen we omgaan met data integratie, hoe kunnen we omgaan met schema matching en het linken van data, hoe kunnen we de motivatie en incentives verder gaan verhogen, hoe kunnen we de input, entiteiten, systemen, processen verder gaan versterken? Stellingen : Aan het onderdeel “Hints naar oplossingen” waren de volgende stellingen gekoppeld: Stelling 1: De uitdagingen rond modellering, voor een data-gedreven overheid, moeten aangepakt worden door: Lokale overheden / Vlaamse overheid / Europese Commissie/ Onderzoeksinstellingen / Private sector / Een samenwerking van de voorgaande. Feedback Spreker: Uitdagingen rond modellering: samenwerking – ook duidelijk een rol voor de Vlaamse overheid. Stelling 2: Wat verwacht jouw organisatie van VLOCA voor de evolutie naar een data-gedreven overheid? De resultaten van deze stelling zijn hier beschikbaar. Next steps Spreker : Fabian de la Meilleure (ABB) Alle verslagen en bijhorende presentaties worden beschikbaar gesteld op deze Kennishub. Feedback en suggesties zijn welkom op vloca@vlaanderen.be. +
Delen Delen via ... Share by Twitter X +
Denemarken heeft een Deens Standaarden Co … Denemarken heeft een Deens Standaarden Commitee voor Smart Cities opgericht (S-491) met als doel om een Smart City Guide te creëren. Meer informatie is via de volgende linken terug te vinden (beide enkel beschikbaar in het Deens): https://www.ds.dk/da/udvalg/kategorier/samfund/baeredygtige-samfund https://www.ds.dk/da/nyhedsarkiv/2020/6/dansk-guide-til-smart-cities-skal-sikre-omstilling-til-et-baeredygtigt-samfundmstilling-til-et-baeredygtigt-samfund +
Denemarken heeft zich ook recent geëngageerd vanuit het Deense instituut voor Standaarden om een nationale vertaling te maken van internationale open city Standaarden . Meer info is via deze link beschikbaar. +
Deze VLOCA kennishub is gebaseerd op een S … Deze VLOCA kennishub is gebaseerd op een Semantisch MediaWiki platform. Hier bekijken we hoe het co-creatieproces in de praktijk wordt uitgerold. Een goed review proces is essentieel om de VLOCA kwaliteitsdoelstellingen te bereiken. VLOCA heeft immers als doel een kwalitatieve kennishub uit te bouwen. Het VLOCA coördinatieteam van ABB , IMEC en VITO heeft sterke aandacht voor ongewenst digitaal vandalisme of pseudo-kennis, zodat de pure co-creatie tussen steden en gemeenten, bedrijven, burgers en kennisinstellingen steeds centraal blijft staan. Tevens wordt VLOCA het neutrale referentiekader in Vlaanderen, los van commerciële belangenvermenging. We nodigen leveranciers van Smart City oplossingen uit om een architectuur of Standaarden voorstellen die aligneren met de basiprincipes zoals interoperabiliteit en open Standaarden en de geest van VLOCA volgt. Op deze Mediawiki pagina wordt het VLOCA review process geduid. Registratie als deelnemer of stakeholder Heb je interesse om op de hoogte te blijven van VLOCA ? Graag houden we je op de hoogte. Wil je actief deelnemen ? Nog beter ! Vul dan als eerste stap op het VLOCA portaal het contactformulier in. Een lid van het VLOCA kernteam neemt dan contact op met je om elkaars verwachtingen te bespreken. Na dit eerste contact creëren we samen je account op de VLOCA kennishub en kan je mee starten in het co-creatie traject. Een aanvraag indienen Een aanvraag tot co-creatie rond een initiatief kan worden ingediend via het daartoe voorziene formulier . Er wordt gevraagd enkele specifieke velden in te vullen over het initiatief en aan te geven of het gaat om een idee, een project, een proof of concept of een voorstel tot architecturale standaardisatie. Eens je aanvraag geregistreerd is, kan je de status opvolgen : Geregistreerd : de aanvraag is geregistreerd, maar nog niet behandeld door een reviewer. In behandeling : de aanvraag is in behandeling. Co-creatie : het co-creatieproces voor dit initiatief is gestart. Aan de hand van het formulier wordt een pagina aangemaakt waarbij een aantal semantische eigenschappen voorgedefinieerd zijn waarmee we de VLOCA kennishub verder zullen vormgeven. Je kan via de wiki "edit" functionaliteit dan gemakkelijk verder de inhoud bewerken of schema's of figuren opladen. Review process Op de kennishub onderscheiden we 2 verschillende rollen voor geregistreerde gebruikers. Anonieme gebruikers hebben enkel leesrechten op de kennishub. Geregistreerder gebruikers zijn ofwel reviewer, of contributor : contributor : Contributors leveren een bijdrage aan het platform door het registreren van aanvragen, het editeren en toevoegen van pagina's en het deelnemen aan de discussies. Contributors verkrijgen een account en toegang tot de kennishub door via het VLOCA portaal te registreren. reviewer : Reviewers zijn verantwoordelijk voor het nakijken en goedkeuren van page edits en het begeleiden van contributors in het aanleveren van kwalitatieve content. Reviewers worden geselecteerd op basis van neutraliteit en bevestigde expertise. Bijdragen aan de kennishub werkt via het systeem van approved revisions . Bij het registreren van een aanvraag tot co-creatie rond een initiatief via het aanvraag formulier , wordt op basis van de ingevulde velden en secties een Mediawiki pagina aangemaakt. Contributors zorgen voor de content, die na een goedkeuring door een reviewer als "approved revision" geldt. De revisies die gemarkeerd zijn als "approved revision" zijn voor iedereen leesbaar. Consensus m.b.t. welke pagina geldt als goedgekeurde versie, wordt verkregen op de discussiepagina, waaraan contributors en reviewer kunnen bijdragen. In essentie is deze discussie vrij. Discussion pagina's Als contributor is het mogelijk om deel te nemen aan de discussies voor elke pagina. Klik hiervoor op de Overleg tab. Op de discussie pagina's kan je jouw input toevoegen door de relevante topic te editeren of een topic toe te voegen. Hiervoor is een "Kopje toevoegen" tab voorzien. We vragen hierbij wel een zekere etikette aan de dag te leggen : Onderteken altijd je posts met een signature, hiervoor is een knop voorzien in de toolbar bovenaan het editeerveld, of je kan volgende tag invoegen : --~~~~ Editeer nooit iemand anders z'n post, maar reageer via aparte posts en gebruik indentatie indentatie Meer informatie over het gebruik van Overleg Pagina's is te vinden bij wikipedia [1] en [2] Co-creatie proces Hier wordt een verdere beschrijving opgenomen van het co-creatie traject. OSLO methodiek: OSLO staat voor Open Standaarden voor Linkende Organisaties De Vlaamse overheid zet in op een eenduidige standaard voor de uitwisseling van informatie. Het is de bedoeling om te zorgen voor meer samenhang en een betere vindbaarheid van data. Op die manier kan iedereen de gegevens makkelijker gebruiken. OSLO staat voor Open Standaarden voor Linkende Overheden ( OSLO ), een initiatief uit 2012 opgestart door de Vlaamse ICT-organisatie (V-ICT-OR). Hier werd de basis gelegd voor een open semantische informatiestandaard. Met OSLO zet informatie Vlaanderen samen met haar partners versterkt in op semantische interoperabiliteit. Het standaardiseren van de betekenis van informatie is essentieel om het Vlaanderen Radicaal Digitaal principe ‘vraag niet wat je al weet’ te realiseren. Daarnaast zijn semantische Standaarden een belangrijke hefboom voor de interbestuurlijke dialoog en hergebruik van informatie door de private sector. Op 31 maart 2017 werden de resultaten van het project OSLO opgeleverd op een publieke informatiedag. De vocabularia en applicatieprofielen die in dit project werden ontwikkeld in co-creatie met Vlaamse administraties, lokale besturen, federale partners, de Europese Commissie en private partners (88 auteurs) werden er aan een breed publiek voorgesteld. Meer informatie over OLSO vind je op de website van de Vlaamse overheid Het VLOCA proces Alignering: Trajecten (initiatieven) geven input op de kennishub via een registratie. Deze input wordt door [[ IMEC ]]/ VITO / ABB gereviewed met input op VLOCA principes en concepten. Projectidentificatie: Aan de hand van o.m. live workshops analyseert het consortium [[ IMEC ]]/ VITO / ABB samen met initiatiefnemers het thema en verschillende principes binnen het project/initiatief. Deze projectidentificatie verloopt via bestaande netwerken zoals Smart Flanders, VVSG, … Daarbij worden andere belanghebbenden/stakeholders verder geïnventariseerd en wordt een procesplan samen met de initiatefnemers opgemaakt. Consolidatie, goedkeuring en finalisering: Het VLOCA proces wordt afgerond in afstemming met OSLO waarbij Standaarden en draaiboeken met bijhorende rollen en verantwoordelijkheden worden vastgelegd. ↑ https://nl.wikipedia.org/wiki/Wikipedia:Overlegpagina ↑ https://nl.wikipedia.org/wiki/Wikipedia:Wikiquette +
Deze eigenschap duidt de child componenten aan, het property type is Page . +
Deze eigenschap geeft de status van een co … Deze eigenschap geeft de status van een co-creatie aanvraag weer. De mogelijke waarden hiervoor zijn : Geregistreerd : de aanvraag is geregistreerd, maar nog niet behandeld door een reviewer In behandeling : de aanvraag wordt behandeld. Co-creatie : het cocreatie proces voor dit initiatief is gestart. Textief is gestart. Text +
Deze klasse definieert het type van een Hoppin punt. Deze types kunnen zijn : +
Deze pagina beschrijft welke stappen je do … Deze pagina beschrijft welke stappen je doorloopt om een mobiliteitsdienst (deelfietsen, parkeerplaatsen, een pakjesautomaat, een bushalte, ..) toe te voegen aan een Hoppinpunt. Ga op zoek naar de verantwoordelijke uitbater Neem contact op met de verantwoordelijke wegbeheerder / gemeente om de verantwoordelijke uitbater te weten te komen. Dit kan bijvoorbeeld Agentschap Wegen en Verkeer zijn voor gewestwegen of de gemeente voor lokale wegen, maar ook de Werkvennootschap of Lantis. Volgens de nota van de Vlaamse regering: "De aanleg van Hoppinpunten wordt in het artikel 42 van het Decreet Basisbereikbaarheid toegewezen aan de wegbeheerder. Het is daarom van belang dat de beleidsvisie verspreid wordt en zijn doorwerking krijgt in het regionale en lokale mobiliteitsbeleid." Neem contact op met de verantwoordelijke uitbater Contacteer de uitbater van het Hoppinpunt en vraag de aansluitingsvoorwaarden en timings na om te weten te komen of er nog ruimte is voor de dienst die je wil toevoegen, aan welke voorwaarden die moet voldoen en op welke momenten extra diensten toegevoegd kunnen worden. Zorg voor een digitale beschrijving van de mobilitetisdienst Hou er ook rekening mee dat er specifieke voorwaarden zijn rond data-uitwisseling (met de mobiliteitscentrale). Het is belangrijk dat het aanbod goed digitaal beschreven is en de beschikbaarheid van de diensten ook digitaal raadpleegbaar is. Zo komt je dienst op de overzichten met Hoppingpunten, eventueel ook in routeplanners en kunnen weggebruikers op voorhand weten welke diensten er aanwezig zijn en wat de beschikbaarheid is.anwezig zijn en wat de beschikbaarheid is. +
Deze pagina beschrijft welke stappen je do … Deze pagina beschrijft welke stappen je doorloopt om een nieuw Hoppin' punt te creëren. Hoe kun je hier digitaal aan meewerken ? Daar vind je hier meer uitleg over. Raadpleeg het stappenplan Het Departement Mobiliteit & Openbare Werken van de Vlaamse overheid maakte een draaiboek aan waar je de verschillende stappen terugvindt die je doorloopt bij het inplanten van een nieuwe Hoppin' punt. Je vindt het stappenplan hier . Het omvat onder andere: Wat is een Hoppinpunt Waaraan moet het Hoppinpunt voldoen? Hoe pas je de huisstijl voor Hoppinpunten toe Waar en wanneer is de huisstijl afdwingbaar (gewestwegen vs. gemeentewegen) (dit stappenplan moet verder nog vorm krijgen) Contacteer de verantwoordelijk van je vervoerregio De concrete uitrol van Hoppinpunten wordt vooral gecoördineerd op niveau van de vervoerregio's. Contacteer de verantwoordelijk van je vervoerregio om te kijken welke ervaringen er al zijn in andere gemeenten en of je ondersteuning kunt krijgen vanuit de vervoerregio zelf. De lijst met vervoerregio's vind je op deze webpagina , als je doorklikt vind je de contactgegevens van het aanspreekpunt van de vervoerregio. Contacteer een (buur)gemeente met ervaring Tal van gemeenten hebben reeds een Mobipunt of Hoppinpunt gerealiseerd. Hierbij hebben ze waardevolle kennis opgedaan en informatie verzameld of documentatie aangemaakt die eventueel hergebruikt kan worden door jouw gemeente. Ga na bij de verantwoordelijke van de vervoerregio welke goeie voorbeelden zijn. (Momenteel is er nog geen centraal overzicht beschikbaar met bestaande Hoppin' punten) Registreer het Hoppinpunt Registreer het Hoppinpunt op het digitale platform van de Vlaamse Overheid (dit is een verplichting om een vergunning / subsidies) te kunnen verkrijgen. Er wordt een Hoppin’ ID aangemaakt voor jouw Hoppinpunt. Op deze manier kunnen mobiliteitsaanbieders op termijn automatisch de data (zoals de beschikbaarheid, prijzen, ..) van hun diensten linken aan je Hoppin’ punt, en deze digitaal beschikbaar maken. beschikbaar maken. +
Deze pagina beschrijft welke stappen je do … Deze pagina beschrijft welke stappen je doorloopt om subsidies aan te vragen voor een Hoppinpunt Hoe kun je hier digitaal aan meewerken ? Daar vind je hier meer uitleg over. Bepaal wie de verantwoordelijke wegbeheerder is De subsidies hangen onder andere af van wie de wegbeheerder is van het Hoppinpunt. Dit kan bijvoorbeeld Agentschap Wegen en Verkeer zijn voor gewestwegen of de gemeente voor lokale wegen. Als u zelf niet de wegbeheerder bent, neem contact op met de verantwoordelijke wegbeheerder om af te stemmen. Lees het besluit van de Vlaamse regering De Vlaamse Regering keurde een besluit goed rond het subisidiëren van Hoppinpunten, daarin vind je de nodige achtergrondinformatie. Het besluit kun je hier raadplegen. Bekijk de voorwaarden Op deze pagina kun je een overzicht vinden van de voorwaarden waaraan je moet voldoen om subisdies te ontvangen. Het gaat ondermeer over de visuele identiteit van het Hoppinpunt, de toegankelijkheid en nodige vergunningen zoals een omgevingsvergunning. Hou er ook rekening mee dat er specifieke voorwaarden zijn rond data-uitwisseling (met de mobiliteitscentrale). Het is belangrijk dat het aanbod goed digitaal beschreven is en de beschikbaarheid van de diensten ook digitaal raadpleegbaar is. Zo komt je Hoppinpunt op de overzichten, routeplanners en kunnen weggebruikers op voorhand weten welke vervoersmiddelen, parkeerplaatsen, dienst etc. er beschikbaar zijn. Contacteer de verantwoordelijk van de vervoerregio De concrete uitrol van Hoppinpunten wordt vooral gecoördineerd op niveau van de vervoerregio's. Contacteer de verantwoordelijk van je vervoerregio om te kijken welke subsidies van toepassing zijn. De lijst met vervoerregio's vind je op deze webpagina , als je doorklikt vind je de contactgegevens van het aanspreekpunt van de vervoerregio.ekpunt van de vervoerregio. +
Deze pagina is momenteel in opmaak door VL … Deze pagina is momenteel in opmaak door VLOCA en mogelijks nog geen reflectie werkelijke toestand organisatie. Korte Beschrijving Klimaatadaptatie: zeer lage waterpeilen en langdurige droogteperiodes, enerzijds, en verhoogde afvoeren en overstromingsrisico’s als gevolg van extreme neerslag anderzijds. - Eenvoudiger en real-time kunnen raadplegen van data zorgt er voor dat tijdig kan worden geanticipeerd op droogte en wateroverlast. - Waterbeheerders zullen beroep kunnen doen op continue en betrouwbare metingen in plaats van te moeten vertrouwen op handmatige, sporadische metingen. - Op de langere termijn kan dit meetnet opportuniteiten en pijnpunten in en rond onze waterlopen aan het licht brengen. - Het openbaar stellen van de metingen moet leiden tot een betere coördinatie en samenwerking met andere waterbeheerders (bv. landbouw of natuursector). Beschrijving Architectuur De architectuur is nog in opbouw en is nog onderhevig zijn aan veranderingen. Onderstaande afbeelding toont dan ook een schets van hoe de architectuur zal worden opgezet. Schets van architectuur. Sensor Toepassingen Toepassingen Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? 1 Onbevaarbare waterlopen Uitvoering Peilsensoren 15m 15m LoRa/GPRS 30 (doel = 80) Real-time + veel locaties Sensor evaluatie Provincie Antwerpen Parameters Type Sensor Fabrikant Troeven Beperkingen Tips en Tricks 1 Waterniveau Akoestisch Fluves, Decentlab en Multiflexmeter Makkelijk te plaatsen, real-time Temperatuur correctie nodig, vegetatie e.d. onder sensor verstoren signaal Hang de sensor zo dat het signaal niet kan weerkaatsen op constructies, zoals de kopmuur. 2 Waterniveau Radar VMM Geen temperatuur correctie nodig, real-time Vegetatie e.d. onder sensor verstoren signaal Hang de sensor zo dat het signaal niet kan weerkaatsen op constructies, zoals de kopmuur. 3 Waterniveau Druk Keller Geen problemen met vegetatie e.d., kan real-time Aan duurdere kant, niet vandalisme-proof Handig voor locaties zonder constructies of constructies die af en toe onder water komen te staan. Weliswaar eerder aan te raden op afgelegen locaties. Lessons learned - Het is echt nodig het beheer van de sensoren op voorhand mee in te calculeren om een realistisch zicht te krijgen op timing en workload. - Beperkte datavalidatie valt te automatiseren (extreme outliers, foutmeldingen), maar de fijnere dingen blijven vooral handwerk.dingen blijven vooral handwerk. +
Deze piramide biedt een visuele weergave van de verschillende lagen waarop de Vlaamse Virtuele Gemeente gebaseerd is. +
Deze property bevat het Smart City Domein … Deze property bevat het Smart City Domein voor het Initiatief, het property type is Page . De toegestane waarden voor de Smart City Domeinen zijn : Smart Governance Smart Economy Smart Mobility Smart Environment Smart People Smart Living Other Smart People Smart Living Other +
Deze richtlijnen worden momenteel opgemaak … Deze richtlijnen worden momenteel opgemaakt in een co-creatie proces. Aanbeveling dus onder voorbehoud. Deze worden momenteel geregeld geüpdatet. Naar het einde van 2021 toe worden deze richtlijnen gefinaliseerd. Hoe houden we gestructureerd data bij? In het VLOCA traject zijn organisaties uit de verschillende domeinen van de watersector betrokken. Iedere organisatie houdt data bij in één of andere vorm. Om data te gaan delen en breder beschikbaar te maken binnen de watersector, is het de eerste stap ervoor zorgen dat deze data op een gestructureerde manier worden bijgehouden door de verschillende organisaties. Zodra dit gebeurt, kan er verder nagedacht worden over het delen van data. Van 5 star open linked data naar VLOCA open data Een manier om data meer gestructureerd bij te houden is de 5 star linked open data . Hierbij worden de data stap voor stap omgevormd zodat deze beter deelbaar worden. Dit gaat van aanbevelingen zoals “zorg dat de data online staan” en “in een gestructureerd formaat” tot “zorg ervoor dat de data gelinkt worden aan andere data”. In VLOCA zien we een gelijkaardig proces. We onderscheiden hier de minimale vereisten en de VLOCA-aanbevelingen: Minimale vereisten Excel of google sheet etiquette Een excel tabblad, google sheet, of gelijkwaardig, is op zo gestructureerd dat elke kolom slechts één type data behandelt, en elke rij een nieuwe observatie is. De inhoud van de kolommen, die bovenaan worden beschreven door een header, verandert niet. Machine-readable Zie ook het VLOCA principe " machine-readable ". VLOCA aanbevelingen Kies een duurzaam systeem voor data opslag en beheer • Database en database model : Om grote hoeveelheden data op te slaan, waar diverse parameters, observaties en context aan gekoppeld zijn, kan het nuttig zijn om de data in een database op te slaan waarbij een database model duidelijk de relaties tussen alle tabellen beschrijft. Voor de keuze van de geschikte database en het geschikte database model verwijzen we door naar de VLOCA richtlijn " Keuze van database ". • Data-bewerkingen en versiebeheer Indien er bewerkingen gebeuren op data is het belangrijk om dit proces zo transparant mogelijk te maken. De ruwe data, waar er van vertrokken wordt, moeten altijd ongewijzigd blijven (zie ook richtlijnen rond " machine-readable "). De bewerkingen gebeuren scriptmatig en de output wordt afzonderlijk opgeslagen. Bij voorkeur, wordt dit proces ook bijgehouden in een metadata file, die beschrijft welke veranderingen de data ondergingen, en wordt er een nieuw versienummer gegeven aan de data. • Kies het juiste data format We onderscheiden ruwweg 3 types van data format: 1) Tabulaire data (Excel, google sheet, csv, SQL databases, etc.): Data wordt bijgehouden in tabel formaat met rijen en kolommen. Toevoegen van data en het nadien verwijderen is relatief eenvoudig, maar eens de structuur van de tabellen en de relaties ertussen zijn vastgelegd, vergt het enige moeite om deze aan te passen. 2) Tree data (xml, json): Een verzameling van “key-value pairs”, waarbij elke value ook een nieuwe key kan zijn of een lijst van keys. Data wordt inherent gestructureerd bij de aanmaak van de boom, maar het toevoegen of wijzigen van de structuur vergt weer enige moeite. 3) Graph data (RDF: Resource Description Framework): Een graaf is een lijst van relaties tussen objecten. Typisch worden 3 elementen onderscheiden (“tripplets”): het onderwerp, de relatie, en het object. Het onderwerp is gelinkt aan het object o.b.v. een relatie. Een graaf opstellen kost meer moeite dan bovenstaande 2 formaten, maar data toevoegen of samenvoegen is veel gemakkelijker. In een RDF wordt elk “ding” voorzien van een URI , die het “ding” uniek identificeert. Verwijzen naar data op het web kan zo ondubbelzinnig gebeuren. Houd de OSLO data standaarden in het oog Gezien de grote verscheidenheid aan data in de Vlaamse watersector, is het onbegonnen werk om tot een uniform datastandaard te komen. Het volgen van de VLOCA richtlijnen kan al een deel van deze zorg ontlasten. Vereiste water gerelateerde metadata (aan te vullen in co-creatie process) Ondanks de grote verscheidenheid aan use cases wordt toch aangeraden om bepaalde meta data altijd bij te houden. Volgende metadata worden aanbevolen: Sensor Type sensor Leverancier Metingen Parameter naam Parameter eenheid Observatie Ruwe meting Gekalibreerde meting Locatie X,y,z Locatie naam Coordinate system Producteigenaar Installatie Tijdstip installatie Gevoeligheid Onderhoud Onderhoud start Onderhoud stop Onderhoud type Data transfer Batterij Wat verder? Data delen en API ’s Eens data op een gestructureerde manier wordt bijgehouden, is het makkelijker om de data ook uit te wisselen. Een overzicht van de VLOCA richtlijnen hierover vind u op volgende pagina: #todo +
Deze richtlijnen worden momenteel opgemaak … Deze richtlijnen worden momenteel opgemaakt in een co-creatie proces. Aanbeveling dus onder voorbehoud. Deze worden momenteel geregeld geüpdatet. Naar het einde van 2021 toe worden deze richtlijnen gefinaliseerd. Minimale vereisten Er zijn verschillende manieren om data te delen. Een belangrijke minimale vereiste is dat de data structuur niet verandert in de tijd. Een voorbeeld: een excel sheet blijft bestaan met altijd dezelfde kolommen. Er worden terloops geen kolommen tussen bestaande kolommen toegevoegd. Uiteraard kunnen rijen aangevuld worden als er nieuwe observaties binnen komen. Indien er toch een aanpassing gebeurd van de data, dan moet dit op één of andere manier duidelijk gemaakt worden: Er wordt een uitleg voorzien welke veranderingen er gedaan zijn (bv: een modelsimulatie werd opnieuw gerund met andere input parameters/ meta-data) Er wordt meegedeeld waar deze nieuwe data te vinden zijn (naam bestand, versioneringsnummer,...) Naargelang de manier waarop data opslag gebeurd, kunnen deze 2 vuistregels een andere vorm aannemen. We illustreren dit: Excel, csv, ... Een excel, csv bestand, ... blijft hetzelfde doorheen de tijd. Elke kolom specifieert een parameter, elke rij een observatie. Definities van kolomnamen kunnen bijgehouden worden in een afzonderlijke sheet met elke rij een kolomnaam, met een uitleg in de cellen ernaast. Een bijkomende sheet zou gebruikt kunnen worden om de meta-data van de data sheet te benoemen: locatie staalname, apparatuur gebruikt, calibratie parameters, etc.Indien er zaken zouden veranderen, kan deze meta-data sheet aangepast worden. Kolommen die eventueel toegevoegd worden, hebben zo ook meer context: bv. er werd een andere sensor gebruikt, die nu meer parameters kan registreren. Indien er nu een copy (met andere naam, versienummer,...) gemaakt wordt van een excel bestand waar er een kolom bij kwam, dan kan er makkelijk nagegaan worden wat deze excel net inhoudt of hoe deze verschilt tov de vorige versie obv de extra gegevens in de kolom-definitie en of meta-data sheet. Onderstaande figuren illustreren dit. Voorbeeld data tabbladen opdeling Voorbeeld excel data Voorbeeld kolom definitie excel Voorbeeld meta-data in excel json, xml, ... Onderstaande figuur illustreert hoe dezelfde data kan bijgehouden worden in json formaat (of gelijkwaardig). De bijgevoegde metadata laat toe om aan te tonen indien er een verandering gebeurde in de data dit toe te wijzen aan bv een verandering van sensor, of locatie. Indien de data nu gedeeld wordt, kan er achterhaald worden waarom bepaalde data veranderd zijn, objectief gezien, zonder dit manueel gevraagd moet worden aan de verdeler van de data. Voorbeeld json metadata en data opslag voor transparantere data deling Eens dit principe voldaan is, kan de data veilig gedeeld worden zonder dat er verwarring onstaat over welke data net gedeeld wordt.In de VLOCA aanbevelingen worden suggesties gedaan hoe dit best kan gebeuren. VLOCA aanbevelingen Maak je linked data vindbaar met een URI In een notendop zijn er 3 vuistregels mbt linked data [1] : Gebruik URI als unieke identifiers Sla je data als triplets op (onderwerp, eigenschap, waarde) Publiceer je data op het web Waarom een URI? een ID (bv:54112), zoals we die kennen in een database bv, is enkel uniek in de context van die specifieke database.Een URI (vaak URL's) zijn per definitie al uniek, gezien het ze voorkomt dat er dubbele adressen zijn. Ontsluit je database met een API Een database kan een grote hoeveelheid data bijhouden, en een API maakt het gemakkelijk om deze data te consulteren. Via een web request kan data opgevraagd worden obv enkele simpele zoektermen. Deze worden dan door de API vertaald naar een database query, die de opgevraagde data teruggeeft in een bepaald vooraf afgesproken formaat. Het voordeel hier is dat je je eigen database kan structureren zoals je wenst, maar toch data kan aanbieden naar buiten toe op een gecontroleerde en overzichtelijke manier: gecontroleerd: je beslists zelf welke delen van de database opgevraagd kunnen worden overzichtelijk: de gebruiker vraagt met enkele eenvoudige key-value pairs de data op zonder heel de database structuur te moeten kennen of bekijken Ontsluit je data via een broker Indien het request-response paradigma minder geschikt is voor de toepassing, kan de data ontsloten worden via een broker. Voor de pro's en con's van het broker (pub-sub) en request-response paradigma, zie volgende pagina . In de meeste gevallen wordt een broker (pub-sub) systeem verkozen in IoT toepassingen. Gebruik yyyy-mm-dd (ISO8601) in je datum voorbeelden Kwestie van de verwarring tussen month-first versus day-first niet te hebben is het mss goed in de voorbeelden datums als yyyy-mm-dd voor te stellen. Wat is de effectieve use case van huidige json/xml voorbeeld? In het geval van het json/xml voorbeeld is de structuur wss in de praktijk gelinkt aan een api/dbase/xsd... met een bepaalde versie (v1,...) al dan niet op basis van het data model van een (open) standaard. Veranderingen in het data model zouden dan versionering hebben? Gaat het hier over een illustratie van een wijziging in data model of van de meta data van een sensor volgens het voorbeeld data model? > Indien de data nu gedeeld wordt, kan er achterhaald worden waarom bepaalde data veranderd zijn, objectief gezien ahv het achterliggende schema of de data zelf? Hoe precies? Verder is het mss nuttig te adviseren om bestaande data modellen te gebruiken om data te delen? Reactie: Wat is de effectieve use case van huidige json/xml voorbeeld? Goede opmerking, ik begrijp waar je naartoe wil. Het voorbeeld was een zeer low level voorbeeld om de reflex te hebben om meta-data op een of andere manier bij te houden.We spreken hier nog niet over koppeling aan bestaan data model, wat uiteraard wel goed zou zijn om te doen. ↑ https://www.w3.org/egov/wiki/Tutorial/Linked_Data/Tutorial/Linked_Data +
Deze richtlijnen worden momenteel opgemaak … Deze richtlijnen worden momenteel opgemaakt in een co-creatie proces. Aanbeveling dus onder voorbehoud. Deze worden momenteel geregeld geüpdatet. Naar het einde van 2021 toe worden deze richtlijnen gefinaliseerd. Binnen VLOCA Water in de stad wordt een belangrijk onderscheid gemaakt tussen historische data en real-time data. Historische data In de meeste gevallen volstaat voor historische data een postgres database of gelijkwaardig. Indien er veel gebruikt gemaakt wordt van GIS data, kan het nuttig zijn om gebruik te maken van een PostGIS extentie. GIS data is ook data, en ergens heeft het geen speciale behandeling nodig. Doch, ervaring leert dat bepaalde queries of berekeningen veel efficiënter gebeuren door gespecialiseerde database structuren. Vandaar deze aanbeveling.Voor een geschikt database model kan er in eerste instantie gekeken worden naar de vereiste VLOCA metadata die aangeraden worden, om een eerste lijst te hebben van belangrijke velden om bij te houden. Real-time data Als er over real-time data gesproken wordt, zijn databases die efficiënt om kunnen met tijdsreeksen een pluspunt. Databases zoals InfluxDB , Timescale Postgres of Apache Druid of gelijkwaardig kunnen dienst doen.waardig kunnen dienst doen. +
Deze richtlijnen worden momenteel opgemaak … Deze richtlijnen worden momenteel opgemaakt in een co-creatie proces. Aanbeveling dus onder voorbehoud. Deze worden momenteel geregeld geüpdatet. Naar het einde van 2021 toe worden deze richtlijnen gefinaliseerd. In onderstaande tabellen wordt een evaluatie van diverse sensoren gegeven: Provincie Antwerpen Provincie Antwerpen parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 Waterniveau Akoestisch Fluves, Decentlab en Multiflexmeter Makkelijk te plaatsen, real-time Temperatuur correctie nodig, vegetatie e.d. onder sensor verstoren signaal Hang de sensor zo dat het signaal niet kan weerkaatsen op constructies, zoals de kopmuur Voorbeeld 2 Waterniveau Radar VMM Geen temperatuur correctie nodig, real-time Vegetatie e.d. onder sensor verstoren signaal Hang de sensor zo dat het signaal niet kan weerkaatsen op constructies, zoals de kopmuur Voorbeeld 3 Waterniveau Druk Keller Geen problemen met vegetatie e.d., kan real-time Aan duurdere kant, niet vandalisme-proof Handig voor locaties zonder constructies of constructies die af en toe onder water komen te staan. Weliswaar eerder aan te raden op afgelegen locaties Voorbeeld VMM VMM parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 Oppervlaktewaterkwaliteit Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 2 Waterpeil Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 3 Grondwater Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 4 Drinkwater Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 5 Neerslag pluviometer Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 6 Neerslag radar Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 7 Bodemvocht Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 8 Debieten waterlopen Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Crodeon Crodeon parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 Grondwaterniveau Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 2 Debietsmeting pompen Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Stad Brugge Stad Brugge parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 pH Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 2 EC Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 3 O2 Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld VITO VITO parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 grondwater Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 2 overstorten Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Stad Roeselare Stad Roeselare parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 waterpeil Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 1 neerslag pluviometer Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Stad Antwerpen Stad Antwerpen parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 waterpeil Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 2 neerslag pluviometer Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 3 grondwaterpeil Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 4 debieten riolen Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Hydroko Hydroko parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 Debietsmeting drinkwater Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 2 Drukmeting drinkwater Druksensor Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Aliaxis Aliaxis parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 Waterkwaliteit afvalwater Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 2 Waterkwaliteit drinkwater Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld VERA VERA parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 Waterkwaliteit Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Aquafin Aquafin parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 Toestand rioolstelsels Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 2 Procesvoering RWZI Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Fluves Fluves parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 Waterpeil Peilsensor Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 2 Waterkwaliteit Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld De Watergroep De Watergroep parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 Debieten waterlopen Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 2 Grondwaterpeil Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 3 Waterkwaliteitparameters Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Provincie West-Vlaanderen Provincie West-Vlaanderen parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 Waterpeil Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 2 Debieten waterlopen Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 3 Verzilting Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Stad Gent Stad Gent parameters type sensor fabrikant troeven beperkingen tips&tricks Link naar projectfiche 1 Grondwaterpeil Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeelde 1 Grondwaterpeil Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld +
Deze richtlijnen worden momenteel opgemaak … Deze richtlijnen worden momenteel opgemaakt in een co-creatie proces. Aanbeveling dus onder voorbehoud. Deze worden momenteel geregeld geüpdatet. Naar het einde van 2021 toe worden deze richtlijnen gefinaliseerd. In onderstaande tabellen wordt een overzicht gegeven van de toepassing van sensoren: Toepassing waterkwantiteit Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Waterpeil Provincie Antwerpen Onbevaarbare waterlopen Uitvoering Peilsensoren 15m 15m LoRa/GPRS 30 (doel = 80) Real-time + veel locaties Waterpeil VMM Onbevaarbare waterlopen Uitvoering Peilsensoren Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Waterpeil Stad Roeselare Voorbeeld Uitvoering Peilsensoren Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Waterpeil Stad Antwerpen Voorbeeld Uitvoering Peilsensoren Voorbeeld Voorbeeld Voorbeeld Voorbeeld Real-time + veel locaties Waterpeil Fluves Voorbeeld Uitvoering Peilsensoren Voorbeeld Voorbeeld Voorbeeld Voorbeeld Veel locaties Waterpeil West-Vlaanderen Voorbeeld Voorbereiding Peilsensoren Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Grondwaterpeil VMM Grondwater Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Grondwaterpeil Crodeon Grondwater Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Real-time (bv. voor sturing pomp) Grondwaterpeil VITO Grondwater Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Grondwaterpeil Stad Gent Grondwater Voorbereiding Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Real-time + veel locaties Grondwaterpeil De Watergroep Grondwater Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Toepassing debieten Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Debietsmeting pompen Crodeon Grondwater Uitvoering Voorbeeld 1min 1min Voorbeeld Voorbeeld Real-time (bv. voor sturing pomp) Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Debietsmeting riolen Stad Antwerpen Riolen Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Debietsmeting waterlopen VMM Onbevaarbare waterlopen Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Real-time + veel locaties Debietsmeting waterlopen Provincie West-Vlaanderen Voorbeeld Voorbereiding Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Real-time + veel locaties Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Debietsmeting drinkwater Hydroko Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Toepassing waterkwaliteit Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? pH Provincie Antwerpen Onbevaarbare waterlopen Uitvoering Peilsensoren 15m 15m LoRa/GPRS 30 (doel = 80) Real-time + veel locaties pH VMM Onbevaarbare waterlopen Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld pH Stad Brugge Oppervlaktewater Uitvoering Voorbeeld Voorbeeld Meer dan 1x/dag Voorbeeld Voorbeeld Real-time + veel locaties + snel reageren (bv zwemzones) Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? EC VMM Onbevaarbare waterlopen Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld EC Stad Brugge Oppervlaktewater Uitvoering Voorbeeld Voorbeeld Meer dan 1x/dag Voorbeeld Voorbeeld Real-time + veel locaties + snel reageren (bv zwemzones) EC Provincie West-Vlaanderen Voorbeeld Voorbereiding Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Real-time + veel locaties + snel reageren (bv zwemzones) Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? O2 VMM Onbevaarbare waterlopen Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld O2 Stad Brugge Oppervlaktewater Uitvoering Voorbeeld Voorbeeld Meer dan 1x/dag Voorbeeld Voorbeeld Real-time + veel locaties + snel reageren (bv zwemzones) opmerking: waterkwaliteit opsplitsen per parameter (zie hierboven o.a. EC, pH, O2) Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Drinkwaterkwaliteit VMM Drinkwater Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Drinkwaterkwaliteit Aliaxis Drinkwater Voorbereiding Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Veel parameters + real-time + veel locaties (afh. van case) Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Waterkwaliteit VERA Voorbeeld In voorbereiding Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Waterkwaliteit Fluves Voorbeeld Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Veel locaties Waterkwaliteit De Watergroep Voorbeeld Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Waterkwaliteit VMM Onbevaarbare waterlopen Voorbereiding Multiparameter Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Multiparameter waterkwaliteit VMM Onbevaarbare waterlopen In voorbereiding Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Toepassing drukmeting Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Drukmeting drinkwater Hydroko Drinkwater Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Real-time + veel locaties Toepassing overstorten Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Overstorten VMM Oppervlaktewater Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Overstorten VITO Oppervlaktewater Uitvoering CTD 5min Voorbeeld Voorbeeld Voorbeeld Voorbeeld Toepassing neerslag Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Neerslag VMM Pluviometer Uitvoering minuut 5 minuten Voorbeeld Voorbeeld Voorbeeld Voorbeeld Neerslag VMM Radar Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Neerslag Stad Roeselare Pluviometer Uitvoering dynamisch instelbaar Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Neerslag Stad Antwerpen Pluviometer Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Toepassing bodemvocht Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Bodemvocht VMM Voorbeeld Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Real-time + veel locaties Toepassing riolering Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Toestand rioolstelsel Aquafin Riolering Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Real-time + veel locaties Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Netwerk keuze Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? Procesvoering RWZI Aquafin Riolering Uitvoering Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Veel parameters + real-time + veel locaties Template nieuwe toepassingen Toepassing Organisatie Type toepassing Fase project (uitvoering, voorbereiding) Type sensor Meetfrequentie Zendfrequentie Keuze netwerk Aantal sensoren Belangrijkste meerwaarde sensor voor deze usecase? 1 Voorbeeld Drinkwaterkwaliteit Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 2 Voorbeeld Peilmeting Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld 3 Voorbeeld Pluviometer Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeld Voorbeeldd Voorbeeld Voorbeeld Voorbeeld +
Deze richtlijnen worden momenteel opgemaak … Deze richtlijnen worden momenteel opgemaakt in een co-creatie proces. Aanbeveling dus onder voorbehoud. Deze worden momenteel geregeld geüpdatet. Naar het einde van 2021 toe worden deze richtlijnen gefinaliseerd. In onderstaande tabellen wordt een overzicht gegeven van standaarden die gekozen werden voor opslag en overdracht van wel bepaalde databronnen. Gezien de grote hoeveelheid aan standaarden, kan het zijn dat er voor wel bepaalde cases andere standaarden nodig zijn. Dit overzicht dient als eerste referentie welke opties er zijn, en sluit deze die niet vermeld worden niet noodzakelijk uit. GIS Toepassing Standaard Voordelen Nadelen Opmerking Delen GIS data OGC WFS bv: OGC WFS, WMS en WMTS Natuurlijke waterlopen Toepassing Standaard Voordelen Nadelen Opmerking periodische grab sample FIWARE-WaterQualityObserved Bodem Rioleringsstelsel Modelering Neerslag Andere Toepassing Standaard Voordelen Nadelen Opmerking Excel, csv of google sheets etiquette Een excel tabblad, google sheet, of gelijkwaardig, is op zo'n manier gestructureerd dat elke kolom slechts één type data behandelt, en elke rij een nieuwe observatie is. De inhoud van de kolommen, die bovenaan worden beschreven door een header, verandert niet. Opslag time-series data InfluxDB Opslag time-series data Timescale Postgres Opslag time-series data Apache Druid Apache Druid +
Digitale meldingen Context Gent, Shift … Digitale meldingen Context Gent, Shift, Izegem en Geraardsbergen werken samen met VLOCA (Vlaamse Open City Architectuur) aan een Gemeente-Zonder-Gemeentehuis-Boost initiatief, een samenwerking tussen GZG en het programma Lokaal Digitaal genaamd “ Digitale meldingen ”. ‘Digitale Meldingen' is een initiatief gericht op het verbeteren en transparanter maken van de communicatie tussen burgers, lokale besturen en de Vlaamse overheid. Via een centraal meldingsplatform willen we burgers in staat stellen om hun zorgen te delen met de juiste instanties, zodat problemen met de dienstverlening efficiënt en gestructureerd kunnen worden aangepakt. VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. Business werkgroep Opzet Tijdens de werkgroep werden de volgende topics behandeld: Scoping aan de hand van use-cases: we leggen de nadruk op de context en wat we willen bereiken met een digitaal meldingen platform. Hierbij staat het verbeteren van de efficiëntie, transparantie en effectiviteit van meldingenbeheer tussen verschillende publieke en niet-publieke organisaties centraal. We focussen tijdens deze werkgroep dus niet op de specifieke functionaliteiten van een centraal meldingen platform, of wat het meldingen platform moet kunnen. SWOT-analyse rond het Centraal meldingen platform Consolidatie van de SWOT-analyse in een aantal doelstellingen Scoping Wat verstaan we onder 'meldingen'? Melding: de burger signaleert een tekortkoming in het functioneren van de stad. Meldingen zijn vragen om herstel, aandacht of onderzoek. Wat valt hier niet onder? Klacht: een manifeste uiting (zowel mondeling, schriftelijk als elektronisch) waarbij een ontevreden burger bij het stadsbestuur klaagt over een door de stad (al dan niet) verrichte handeling of prestatie. Suggestie: een voorstel voor verbetering van de werking Vraag: de burger is op zoek naar inlichtingen over wie, wat, waar, wanneer, waarom, welk en hoe. Reactie: een repliek of antwoord op iets geven. De onderstaande figuur beschrijft de flow en de verschillende onderdelen van een centraal meldingen platform. Het ontvangen van de meldingen is bij dit project niet de primaire scope. Het lokaal bestuur in kwestie beslist zelf hoe de meldingen in ontvangst genomen worden bv. via een loket, telefonisch, lokale applicatie,.. De belangrijkste focus vandaag is het verzenden van de melding overheen de verschillende besturen. Dit brengt complexiteit met zich mee. Het gedeelte 'dispatching' gaat specifiek over de overgang van een melding van de verantwoordelijkheid van een lokaal bestuur naar een andere partij. 'Verwerking' betreft de afspraken rond het afhandelen van de melding. Het blauwe gedeelte is waar we ons momenteel op richten: het zorgen voor duidelijke communicatie rondom een melding. Bij een melding van bijvoorbeeld een defecte lantaarnpaal willen we zeker weten binnen welke tijd deze moet worden afgehandeld, welke risico's eraan verbonden zijn, en dat alles binnen een systeem kan worden gevolgd. We specificeren niet wie ter plaatse moet komen of welke stappen deze persoon moet ondernemen om het probleem op te lossen. Vraag Fluvius: is het de bedoeling dat dit systeem de bestaande kanalen vervangt? Op onze website bestaat er reeds de mogelijkheid om een defecte straatlamp te melden door een burger. Of blijven deze naast elkaar bestaan? Wordt er een link gelegd? VLOCA: we hebben de ambitie om deze maximaal met elkaar te gaan integreren. In een latere fase zullen we een analyse moeten doen om te bekijken welke systemen er reeds bestaan. Vandaag ligt de nadruk op wat de meerwaarde van een centraal meldingen platform is en waarom we erop zouden moeten inzetten. In de onderstaande afbeelding worden de use cases toegelicht die al dan niet binnen scope zitten: Oefening 1: SWOT-analyse Toelichting Een SWOT-analyse is een strategische planningstechniek die wordt gebruikt om de Sterktes (Strengths), Zwaktes (Weaknesses), Kansen (Opportunities), en Bedreigingen (Threats) van een project of organisatie te identificeren en te evalueren. Sterktes: Interne kenmerken die bijdragen aan het succes. Zwaktes: Interne kenmerken die de prestaties belemmeren. Kansen: Externe factoren die benut kunnen worden voor voordeel. Bedreigingen: Externe factoren die risico’s vormen voor succes. Waarom belangrijk? Een SWOT-analyse biedt strategisch inzicht, ondersteunt besluitvorming en helpt bij risicobeheer voor het centraal meldingen platform. Toepassing op: Centraal Meldingen Platform Efficiëntie: Biedt inzicht in interne processen die verbeterd kunnen worden. Transparantie: Identificeert externe factoren die kansen bieden voor verbeterde communicatie met burgers. Effectiviteit: Helpt bij het bepalen van bedreigingen die de succesvolle implementatie van het platform kunnen belemmeren. Opdracht: Identificeer de sterktes, zwaktes, kansen en bedreigingen rond het digitaal meldingen platform. Besluit Een gestandaardiseerd, digitaal meldingssysteem verbetert efficiëntie en dienstverlening, maar vereist effectieve aanpak rond bewustwording, transparantie en integratieproblemen. Sterktes: Efficiëntie en Uniformiteit: Verhoogde efficiëntie en standaardisatie van processen. Digitale meldingen: Volledig digitale en locatie-onafhankelijke meldingen. Gebruikersgericht: Diensten op maat, sneller en gerichter. Werklastbesparing: Verminderde werklast door directe dispatching. Synergie en samenwerking: Herbruikbare bouwblokken en innovatieve publiek-private samenwerking. Keuzevrijheid: Lokale overheden kiezen eigen inputkanalen. Zwaktes: Gebruikersdeelname: Mogelijke weerstand tegen verandering of samenwerking Meldingenbeheer: Verhoogde instroom meldingen, dubbele meldingen en niet-digitale meldingen. Complexiteit en integratie: Standaardisatie van termen, complexiteit opzet en integratieproblemen met bestaande systemen. Transparantie: Gebrek aan zicht op afhandeling door andere instanties. Opschaling: Moeilijkheden voor kleinere besturen om op te schalen. Een uniforme infrastructuur en technologische verbeteringen verhogen de efficiëntie en innovatie, maar hou rekening met privacy, operationele uitdagingen en mogelijks hogere kosten. Kansen: Generieke infrastructuur: Uniform en eenvoudig meldingsproces. Technologische verbeteringen: Proactieve meldingen en ondersteuning via AI. Standaardisatie en open source: Gebruik van internationale standaarden (bvb LDES) en open source oplossingen zoals QGIS. Efficiëntie en innovatie: Minder doorsturen tussen beheerders, beter gebruik van meldingsdata, en versterking van het innovatieve imago doormiddel van proactieve dienstverlening. Bedreigingen: Privacy en datakwaliteit: GDPR-risico's en de noodzaak voor hoogwaardige data. Technologische en operationele uitdagingen: Bijhouden van nieuwe technologieën, authenticatieproblemen, en prestatie- en schaalbaarheidsproblemen. Operationele kosten en ondersteuning: Hoge koppelingskosten door fragmentatie en risico op onvoldoende ondersteuning door leveranciers. Oefening 2: consolidatie SWOT-analyse in doelstellingen Toelichting In deze oefening staan we stil bij de vraag welke projectdoelen we kunnen identificeren. Oefening 3: groepering en prioritisering doelstellingen Besluit Door maximaal in te zetten op een eenvoudig en gestandaardiseerd end-to-end process verhogen we de toegankelijkheid en zorgen we voor een verbeterde en kosten-efficiente dienstverlening richting de burger. Prioriteiten: Een snel, transparant en eenvoudig meldingenproces overheen verschillende bestuursvormen Maximaal inzetten op een end-to-end process voor meldingen. Maximale toegankelijkheid van het meldingssysteem. Maximale integratie van bestaande bouwstenen. Vermindering van complexiteit door standaardisatie. Duidelijke en heldere afspraken tussen verschillende partijen. Inzichten halen uit meldingen voor verbeterde en proactieve dienstverlening. Kostenbesparing door minder werklast voor verwerkende diensten. Om deze doelstellingen te behalen moeten we ons behoeden voor de risico’s die hiermee gepaard gaan: Niet kwalitatieve of privacy conforme informatie Zorg voor standaardisatie en betrek DPO bij informatiedeling Niet alle lokale besturen zijn klaar om deze stap te nemen Hou rekening met bestaande maturiteitsverschillen bij lokale besturen Te veel focus op technologische oplossing Zoek de juiste balans tussen tools en procesoptimalisatie Authenticatie tussen verschillende partijen Zorg voor robuuste authenticatie en autorisatie, ook voor anonieme meldingen Meer werklast door toename in systemen Vind een goede balans tussen integratie en schaalbaarheid Continue veranderende technologie Voorzie budget voor innovatie of kies voor een commercial ‘off the shelf’ oplossing Hogere TCO door wildgroei aan systemen Zorg voor kosten-baten analyse rekening houdend met operationele kosten Beperkt draagvlak bij de leveranciers Maak duidelijke en gedragen overeenkomsten met leveranciers Opname en Miro bord Miro bord Het Miro bord kan je consulteren via deze link . Opname De opname van deze sessie is te bekijken via deze link . Volgende stappen Wat na deze werkgroep? Verwerking van de input van de brainstorm oefening. Verder onderzoek en voorbereiding van de volgende thematische werkgroep. Publicatie op de Kennishub. Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Kick-off Business werkgroep 2024-04-26 13u-14u30 Teams Business werkgroep Business werkgroep 2024-05-27 13u30-16u00 Teams +
Digitale meldingen Context Gent, Shift … Digitale meldingen Context Gent, Shift, Izegem en Geraardsbergen werken samen met VLOCA (Vlaamse Open City Architectuur) aan een Gemeente-Zonder-Gemeentehuis-Boost initiatief, een samenwerking tussen GZG en het programma Lokaal Digitaal genaamd “ Digitale meldingen ”. ‘Digitale Meldingen' is een initiatief gericht op het verbeteren en transparanter maken van de communicatie tussen burgers, lokale besturen en de Vlaamse overheid. Via een centraal meldingsplatform willen we burgers in staat stellen om hun zorgen te delen met de juiste instanties, zodat problemen met de dienstverlening efficiënt en gestructureerd kunnen worden aangepakt. VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. Functionaliteiten werkgroep Waar willen we met een centraal meldingen platform naartoe? Het centraal meldingssysteem biedt een snel, transparant en eenvoudig meldingenproces voor burgers en overheidsinstanties. Het maximaliseert toegankelijkheid en integratie, vermindert complexiteit door standaardisatie, en zorgt voor duidelijke afspraken tussen de verschillende partijen. Belangrijkste kenmerken: End-to-end proces en toegankelijkheid: Naadloos van melding tot afsluiting, gebruiksvriendelijk voor iedereen. Integratie en standaardisatie: Efficiënt gebruik van bestaande systemen en met uniforme processen. Proactieve en kostenbesparende dienstverlening: Data-inzichten en AI voor betere service en lagere kosten. Consolidatie SWOT analyse in doelstellingen Door maximaal in te zetten op een eenvoudig en gestandaardiseerd end-to-end proces verhogen we de toegankelijkheid en zorgen we voor een verbeterde en kosten-efficiënte dienstverlening voor de burger Maximaal inzetten op een end-to-end proces voor meldingen Maximale toegankelijkheid van het meldingssysteem Maximale integratie van bestaande bouwstenen Vermindering van complexiteit door standaardisatie Duidelijke en heldere afspraken tussen verschillende partijen Inzichten halen uit meldingen ter bevordering van proactieve en verbeterde dienstverlening Kostenbesparing door minder werklast voor verwerkende diensten Een snel, transparant en eenvoudig meldingenproces over verschillende bestuursniveaus heen Consolidatie SWOT analyse in risico's Om deze doelstellingen te behalen moeten we ons bewust zijn van de risico’s die hiermee gepaard gaan: Niet kwalitatieve of privacy conforme informatie Zorg voor standaardisatie en betrek DPO bij informatiedeling Niet alle lokale besturen zijn klaar om de stap te nemen Hou rekening met bestaande maturiteitsverschillen bij lokale besturen Te veel focus op technologische oplossing Zoek de juiste balans tussen tools en procesoptimalisatie Authenticatie tussen verschillende partijen Zorg voor robuuste authenticatie en autorisatie, ook voor anonieme meldingen Verhoogde werklast door toename in systemen Vind een goede balans tussen integratie en schaalbaarheid Continue veranderende technologie Voorzie budget voor innovatie of kies voor een commerciële ‘off the shelf’ oplossing Hogere TCO door wildgroei aan systemen Zorg voor kosten-baten analyse rekening houdend met operationele kosten Beperkt draagvlak bij de leveranciers Maak duidelijke en gedragen overeenkomsten met leveranciers Consolidatie MOSCOW analyse Bevraging toont behoefte aan een centraal meldingssysteem met focus op essentiële functies, maximale toegankelijkheid, integratie en standaardisatie. Must have Gebruikersgericht meldingssysteem: Moet gericht zijn op de burger en niet op de overheid; met mogelijkheden voor anonieme, geregistreerde en geauthentiseerde meldingen. Statusvolging en notificaties: Status van meldingen moet door alle betrokken partijen gevolgd kunnen worden en burgers moeten geïnformeerd blijven. Basisfunctionaliteiten: Meldingen op basis van minimaal nodigde informatie; digitale meldingen met locatiegegevens. Automatisering en procesbeheer: Categorisatie en prioritering van meldingen; automatische doorverwijzing; teamtoewijzing, en procesopvolging binnen het systeem. Integratie en samenwerking: Eén centraal kanaal voor meldingen; eenvoudige statusuitwisseling, duidelijke rollen en verantwoordelijkheden, en opvolging vanuit één systeem. Data en privacy: Minimale informatie-uitwisseling: naleving van Europese en lokale regelgeving; opslag van data op Belgische servers. Rapportage en inzichten: Mogelijkheden om knelpunten in de afhandeling van meldingen in kaart te brengen en behandelen (cfr. ITIL processen). Should have Specifieke objecten en standaardisatie: Digitale meldingen op specifieke objecten in de publieke ruimte; identieke meldingstypes over alle gemeenten, producten op basis van afgesproken standaarden. Could have Extra functionaliteiten en innovatie: toewijzen op basis van capaciteit van de behandelende teams, overzicht van meldingen in de buurt, gebruik van AI bij toewijzing en detectie knelpunten in de afhandeling. Rapportage op maat: Rapporten op maat van het gebruikersprofiel met realtime data rapportages en inzichten rond trends. Won’t have Gratis basisplatform: Gratis basisplatform voor kleine besturen. Automatische detectie: Automatische detectie van problemen en opmaak van meldingen. Gedetailleerd overzicht kan je terugvinden in het VLOCA model Organisatie: processen, rollen en verantwoordelijkheden Om het centraal beheer van de meldingen te organiseren, is er nood aan een samenwerkingsmodel met afspraken rond processen, rollen en verantwoordelijkheden. Samenwerkingsmodel Het samenwerkingsmodel voor centraal beheer van meldingen omvat duidelijke afspraken rond communicatie, gezamenlijke doelstellingen, geïntegreerde processen en voortdurende feedback voor verbetering. Hieronder de belangrijkste aspecten voor succes: •Duidelijke doelstellingen: Zet concrete doelen voor het wegwerken van pijnpunten met betrekking tot meldingen. •Communicatie en coördinatie: Voorzie de nodige communicatiekanalen en vind de juiste balans voor vergaderingen. •Geïntegreerde processen: Zorg voor gestandaardiseerde procedures en geïntegreerde systemen. •Feedback en verbetering: Innoveer en verbeter op basis van regelmatige evaluatie en continue feedback. Duidelijke processen zorgen voor een efficiënte, veilige en toegankelijke manier om meldingen te beheren. Meldingenbeheer & workflow en opvolging Wat doen de processen: Beheren het volledige traject van meldingen, inclusief ontvangst, toewijzing, statusopvolging en leggen mogelijke integraties met bestaande tools. Belangrijke functies: •Ontvangst en toewijzing van meldingen aan de juiste teams •Statusopvolging van meldingen •Clustering van gerelateerde meldingen voor efficiëntie •Integratie met planningshulpmiddelen voor effectieve taakuitvoering Authenticatie & toegang en compliance & beveiliging Wat doen de processen: Zorgen voor veilige toegang tot het systeem en naleving van regelgeving om data privacy te waarborgen. Belangrijke functies: •Verificatie van gebruikers en behandelaars •Beveiligde toegang tot het systeem •Naleving van regels en wetgeving •Beveiliging van data-uitwisseling Ondersteuning & samenwerking en asset-en dienstbeheer Wat doen de processen: Bieden ondersteuning aan gebruikers, bevorderen samenwerking tussen partijen en beheren assets en diensten. Belangrijke functies: •Gebruikersondersteuning •Regelmatige communicatie en overleg •Integratie van nieuwe organisaties •Beheer van betrokken assets en diensten •Integratie van assets met authentieke bronnen Een doelgerichte aanpak rond meldingen vergt de juiste rollen. Business partner (SPOC) De contactpersoon voor zakelijke partners Service level manager Beheert service levels en processen Meldingcoördinator Coördineert meldingen en houdt overzicht Behandelaar Verwerkt en handelt meldingen af Data Protection Officer Beschermt persoonsgegevens en zorgt voor naleving van privacywetgeving Beheerder Verantwoordelijk voor het beheer en onderhoud van het systeem Projectteam Ontwikkelt en verbetert het meldingssysteem Ondersteund door effectieve samenwerking met duidelijke verantwoordelijkheden tussen de verschillende partijen. Zie onderstaande RACI-tabel: Roadmap fases In 4 fases richting een centraal meldingenplatform Om dit te kunnen realiseren zullen we gefaseerd moeten werken. Opzetten van basisfunctionaliteiten Focus op implementeerbare oplossingen en leg de fundamenten voor een gebruiksvriendelijk meldingssysteem. Automatisering en centraal procesbeheer Zet in op een end-to-end proces en start hierbij met de belangrijkste knelpunten. Zorg ervoor dat de meldingen bij de juiste teams terechtkomen. Integratie en data privacy Ga voor diepere integratie richting één systeem voor opvolging, met duidelijke afspraken en rekening houdend met privacy van de burger. Optimalisatie, innovatie en rapportage Zet in op innovatieve technologiën, rapportage en uitgebreide functionaliteiten voor het end-to-end proces 1. Opzetten van basisfunctionaliteiten Een doelgerichte aanpak rond meldingen vergt introspectie van alle betrokken partijen om tot een sterk fundament te komen. Onze eerste stap is het creëren van een sterke basis om op terug te vallen. Binnen deze fase moet in kaart gebracht worden welke thema’s prioritair behandeld moeten worden in het kader van een centraal beheer van meldingen. Voor deze thema’s afspraken gemaakt worden over de minimale vereisten voor een gemeenschappelijke aanpak. Het is belangrijk om hierbij rekening te houden met de maturiteit van de verschillende organisaties. Een sterk fundament vertrekkende vanuit de concrete pijnpunten Identificeer de belangrijkste bottlenecks rond meldingen en focus op het verhelpen hiervan. Voer een duidelijke impactanalyse uit op de betrokken organisatie en leg de basis voor een constructieve samenwerking. Hieronder de belangrijkste taken binnen deze fase: Focus op de belangrijkste pijnpunten rond meldingen met negatieve impact op de burger Breng de verschillende betrokken partijen in kaart die nodig zijn om de melding af te ronden Breng de verschillende mogelijke kanalen in kaart waarlangs meldingen ontvangen worden Ontwikkel en valideer een standaardaanpak en methode om meldingen tussen verschillende partijen te delen en te behandelen Ontwikkel basisfunctionaliteiten zoals opvolging, statuswijzigingen en notificaties met minimale informatie 2. Automatisering en centraal procesbeheer Dit fundament dient als basis voor verdere automatisering en duidelijke afspraken rond centrale behandeling van de meldingen. In deze fase richten we ons op het automatiseren en centraliseren van het meldingsproces om de efficiëntie en effectiviteit te verhogen. Dit omvat de categorisatie en prioritering van meldingen, het toewijzen van meldingen aan de juiste teams, en het opzetten van een centraal beheer. Overheden en nutsbedrijven moeten zelf beslissingen kunnen nemen over hun eigen organisatie en de kanalen voor meldingen. Het doel is om een robuust systeem te creëren dat meldingen automatisch naar de juiste kanalen doorverwijst en de opvolging binnen het systeem maximaliseert. Automatiseer en centraliseer voor een efficiënt procesbeheer Ontwikkel de categorisatie en prioritering van meldingen, en zorg voor een effectieve toewijzing en doorverwijzing. Geef overheden en nutsbedrijven de mogelijkheid om hun eigen instellingen te beheren en zorg voor een naadloze opvolging binnen het systeem. Hieronder alvast belangrijkste taken binnen deze fase: Implementeer de categorisatie en prioritering van meldingen om de meest urgente zaken eerst af te handelen. Zorg voor teamtoewijzing en doorverwijzing van meldingen naar de juiste afdelingen of teams. Stel overheden en nutsbedrijven in staat om zelf beslissingen te nemen over hun eigen organisatie en de meldingskanalen. Maximaliseer de opvolging van meldingen binnen het systeem om overzicht en controle te behouden. Ontwikkel geautomatiseerde workflows om dubbele en onterechte meldingen te vermijden. 3. Integratie en data privacy Duidelijke rollen en verantwoordelijkheden en veilige data-uitwisseling zijn cruciaal voor een robuuste integratie. In deze fase ligt de focus op het integreren van systemen en het waarborgen van data privacy om een naadloze samenwerking te realiseren. Het is essentieel om verschillende systemen te integreren, duidelijke rollen en verantwoordelijkheden te definiëren en te zorgen voor veilige data-uitwisseling. Dit garandeert dat alle betrokken partijen efficiënt kunnen samenwerken en dat de gegevens van burgers beschermd zijn volgens de geldende regelgeving. Integreer en beveilig data voor naadloze samenwerking Integreer verschillende systemen, definieer duidelijke rollen en verantwoordelijkheden, en zorg voor een veilige data-uitwisseling. Dit bevordert een efficiënte samenwerking en waarborgt de privacy van gebruikers. Hieronder alvast belangrijkste taken binnen deze fase: Integreer bestaande systemen om een naadloze gegevensoverdracht tussen verschillende partijen te waarborgen. Definieer en documenteer duidelijke rollen en verantwoordelijkheden voor alle betrokken partijen. Zorg voor veilige data-uitwisseling die voldoet aan Europese en lokale regelgeving om de privacy van gebruikers te beschermen. Implementeer beveiligingsmaatregelen om data-inbreuken te voorkomen en de integriteit van gegevens te waarborgen. 4. Optimalisatie, innovatie en rapportage Artificiële intelligentie, data-analyse en standaardisering bieden verdere optimalisatiemogelijkheden In deze fase richten we ons op het optimaliseren van processen, het implementeren van innovatieve oplossingen en het verbeteren van rapportagemogelijkheden. Door gebruik te maken van AI en data-analyse kunnen we meldingen groeperen, trends identificeren en capaciteiten beheren. Dit stelt ons in staat om proactief te reageren op problemen en voortdurend de dienstverlening te verbeteren. Optimaliseer, innoveer en rapporteer met inzichten uit data Optimaliseer bestaande processen, implementeer AI-gedreven oplossingen, en ontwikkel uitgebreide rapportage- en analysemogelijkheden om proactieve en efficiënte dienstverlening te bevorderen. Hieronder alvast belangrijkste taken binnen deze fase: Verbeter en standaardiseer meldingsprocessen door rekening te houden met beschikbare capaciteit van behandelende teams. Gebruik AI om meldingen aan de juiste dienst en prioriteit toe te wijzen en om meldingen rond hetzelfde probleem te groeperen. Bied gebruikers een overzicht van meldingen in hun buurt en ontwikkel rapportagesystemen die real-time inzichten bieden Gebruik data-analyse om trends te voorspellen en preventieve maatregelen te nemen om toekomstige problemen te voorkomen. Opname en Miro bord Opname Wegens technische problemen is een opname helaas niet beschikbaar. Miro bord Het Miro bord kan je consulteren via deze link . Volgende stappen Wat na deze werkgroep? Verwerking van de input van de brainstorm oefening. Verder onderzoek en voorbereiding van de volgende thematische werkgroep. Publicatie op de Kennishub. Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Kick-off Business werkgroep 2024-04-26 13u-14u30 Teams Business werkgroep Business werkgroep 2024-05-27 13u30-16u00 Teams Functionaliteiten werkgroep Functionele werkgroep 2024-06-20 9u00-12u00 Teams Applicatie componenten werkgroep Functionele werkgroep 2024-08-08 13u00-16u00 Herman Teirlinck - 01.16 - Rik Wouters Aanpak en risico's werkgroep Functionele werkgroep 2024-09-11 9u00-12u00 Herman Teirlinck - 01.71 - Frans Breziers +