Thematische werkgroep 3

Technologie werkgroep

Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur. In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix.

De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen.

De Technologie werkgroep vond plaats op .

Deelnemers

Organisatie	Deelnemer
Agentschap Binnenlands Bestuur (VLOCA)	Laurien Renders
	Alain Glickman
Intercommunale Leiedal	Lucas Verbanck
	Inge Wydhooge
	David Lingier
	Thomas Goemaere
Stad Gent	Jan Godderis
	Dieter Nieuwborg
District09	Ann Bernaert
Provincie West-Vlaanderen	Wim Beerten
GIM	An Heirman
Departement Omgeving	Stijn Vanderheiden

Context

Initiatief

De uitdaging waar we voor staan, is de aanzienlijke druk op de bebouwde en open ruimte in Vlaanderen. Het vraagt om een slimme benadering van de nog beschikbare ruimte. We streven ernaar om data te integreren in ons beleid en onze dienstverlening, met als uiteindelijk doel het creëren van leefbare buurten en bruisende centra.

De vraag is: hoe bereiken we dit? Het antwoord ligt in het verkrijgen van inzicht in wanneer een buurt behoefte heeft aan zaken zoals bijvoorbeeld extra voorzieningen, groenvoorzieningen en handelsmogelijkheden. Dit inzicht stelt ons in staat om bij bouwprojecten op een slimme manier te beslissen waarop we moeten inzetten.

In dit streven zijn we op zoek naar een aantal essentiële elementen:

1. Een permanente monitoring van de kenmerken van een buurt, zodat we op de hoogte blijven van de veranderende behoeften en trends.

2. Het vermogen om de impact van specifieke bouwprojecten op deze kenmerken te beoordelen. We willen begrijpen hoe nieuwe ontwikkelingen de leefbaarheid van een buurt beïnvloeden.

3. Het ontwikkelen van visuele tools die deze informatie kunnen presenteren op een manier die relevant en begrijpelijk is voor verschillende belanghebbenden, waaronder burgers en medewerkers die vergunningen verlenen.

VLOCA

VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. Meer informatie over VLOCA en onze werking kan je terugvinden op https://www.vlaanderen.be/lokaal-bestuur/digitale-transformatie/vloca/vloca-trajectbegeleiding-waarom.

Samenvatting vorige werkgroep

Het verslag van de functionaliteiten werkgroep kan je hier terugvinden.

Doel huidige werkgroep

1. Introductie geven over het project
2. Toelichting geven over VLOCA
3. Brainstormen over technologie

Brainstormsessie

Theorie

Om de bedrijfsarchitectuur te analyseren (en het geheel van taken/acties in kaart te brengen) moeten we door een cascade. Werkgroep per werkgroep wordt een nieuwe laag gevormd op basis van de output.

Als we naar de hoofdtaken kijken, kunnen we een aantal acties identificeren met betrekking tot de databronnen (locatiegegevens en ruimtelijke relaties) om waardecreatie te genereren. Concreet kunnen we bewerkingen doen op de databronnen zoals afstandsmetingen, het berekenen van aantallen en het meten van oppervlaktes. De uitkomst van deze bewerkingen heeft als uiteindelijk doel het beleid te informeren bij het plannen van voorzieningen op strategische locaties. De waardecreatie bestaat uit het voorzien van voldoende parken, scholen, openbaar vervoer etc.

Door enkel de hoofdtaken te identificeren is onze analyse nog niet compleet. De input-en outputtaken bevatten nog een (niet exhaustieve) lijst van andere acties die nodig zijn om van databronnen naar waardecreatie te gaan. Vooraleer bewerkingen mogelijk zijn met de databronnen moeten eerst de inputtaken uitgevoerd worden. Na het bewerken van de databronnen zijn er nog een aantal outputtaken te onderscheiden.

Tijdens de oefening van vandaag gaan we om te beginnen op zoek naar de applicatiecomponenten bij elk van de taken. De applicatiecomponenten zijn de modulaire bouwstenen van software die specifieke functies uitvoeren zoals gebruikersinterfaces, databases en services.

Vervolgens maken we de cascade compleet door na te denken over de randvoorwaarden. Dit zijn de overkoepelende applicatiecomponenten.

Tot slot wensen we elke mogelijke oplossing te toetsen aan een aantal principes. Deze principes kunnen geformuleerd worden op basis van de valkuilen die we identificeren tijdens de werkgroepen.

Bijvoorbeeld:

Een oplossing wordt gebouwd door een leverancier met een bepaalde technologie. Dit werkt aanvankelijk perfect maar na een paar jaar blijkt deze technologie achterhaald en het platform waarop het gebouwd is, niet meer ondersteund wordt.

=> om te vermijden dat de oplossing na x jaar in de vuilbak gaat omdat de technologie niet meer voldoet, willen we een veiligheid inbouwen door een voorwaarde/principe op te stellen bij aanvang van de ontwikkeling

=> principe: de oplossing moet technologie-agnostisch zijn

We kunnen hiervoor inspiratie halen uit de VLOCA-principes.

Oefeningen

Link naar het Miro bord

De link naar het Miro bord kan je hier terugvinden.

Oefening 1: applicatiecomponenten identificeren

Voor elk van de input-, hoofd-en outputtaken gaan we op zoek naar de applicatiecomponenten. Deze hebben we nodig om over te gaan naar realisatie van de oplossing.

Reminder: applicatiecomponenten zijn modulaire bouwstenen van software die specifieke functies uitvoeren, zoals gebruikersinterfaces, databases en services. Dit zijn  gedetailleerde, specifieke bouwstenen of modules binnen een applicatie.

Voorbeeld:

- Om aan data transformatie te doen heb je een ETL applicatie component nodig

- Om resultaten zelf te visualiseren heb je een self service rapporterings applicatie component nodig

- Om een oppervlakte te meten/berekenen heb je een location intelligence 'surface calculator' (?) nodig

Oefening 2: overkoepelende applicatiecomponenten identificeren

Naast de ‘gewone’ applicatiecomponenten moeten we ook op zoek naar de overkoepelende applicatiecomponenten.

Overkoepelende applicatiecomponenten zijn de grote, samenhangende delen van een softwaretoepassing die verschillende functionaliteiten en taken coördineren om het beoogde doel van de applicatie te bereiken. Deze componenten werken vaak samen en vormen de ruggengraat van de applicatie. Het zijn bredere, meer strategische componenten die de algemene structuur en functionaliteit van een applicatie bepalen.

Voorbeeld:

- GDPR

- Algemene gebruiksvoorwaarden

- Kwaliteitscheck van de bronnen

- Voorzien van een helpdesk

- Organiseren van opleidingen

Oefening 3: Identificatie valkuilen en principes

Welke zijn de valkuilen waarmee we rekening moeten houden bij de keuze van een oplossing?

Formuleer enkele basisprincipes waaraan de oplossing moet voldoen (VLOCA principes kunnen inspiratie bieden)

Voorbeeld:

-Self-service zonder goede training kan 'gevaarlijk' zijn.

-PowerBI rapport in een gemeente die geen PowerBI licentie heeft maar enkel MS Office

Oefening 4: bijkomende vragen van de initiatiefnemers

Hoe zetten we het beheer van dataverwerking op voor verschillende lokale besturen? Rekening houden dat zowel stad Gent als (verschillende besturen binnen het werkgebied) Intercommunale Leiedal zullen gebruikers zijn.

Outcome

Oefening 1

Input taken		Hoofdtaken		Output taken		Valkuilen		Principes
Belmap API voor geocoderen		Realtime sensordata: verkeersmetingen (bv telraam) , zonlicht, geluid, luchtkwaliteit,		(3D) Simulatieplatform met geïntegreerde algoritmes/modellen cross-use case (vb Zanadoo/Tygron) oa voor impactanalyse, predictive modelling		Garantie van datakwaliteit (bewaken na verloop van tijd)		interface op maat van gebruikers/profielen
geocoderen via GIS-software - API Vlaanderen - ...		Netwerkanalyse in ArcMap/FME voor berekenen bereikbaarheids-zones		simuleren > voorspellen: nood aan rekenmodel - model afhankelijk van thema		kennis / ervaring gebruik Python best practices (niet iedereen is op zelfde niveau)		eenvoudig starten, geleidelijk aan uitbreiden
FME Data Integratie Platform voor aggregren, clusteren, verrijken, automatisch updaten, transformeren, ...		Analyse straat- en luchtbeelden		'Statische' info visualiseren op geoloket		tool voor het brede publiek: moet helder en gemakkelijk zijn in gebruik - moet de eerste lijns-ambtenaar ontzorgen… maar mag de werkelijkheid niet simplifiëren - juistheid van de gedeelde data		doelpubliek in rekening brengen bij output
API om data Netwerk en voorzieningen binnen te halen		Feature extraction, image classification, Object detection		Statistische info op Stad/Provincie in Cijfers				Hergebruik waar mogelijk
ETL om ruwe data te verwerken tot afgeleide data (klaar voor berekening)		geografische analyses		publiceren op (open) dataportaal ifv doorgedreven GIS-analyses				gedurende de (continue) ontwikkeling steeds terugkeren naar de gebruiker voor snelle bijsturing waar nodig
		GIS-software (ArcGIS, QGIS), FME, SQL, Python, R		Geo-webtoepassing voor eenvoudige visualisatie van resultaten				voorbeeldstudies bij wijze van introductie van de tool ifv communicatie ? laagdrempelig
Geolocation		Python		Samenwerkingsplatform (communicatie met externe partijen ontwikkelaars, burgers, wijk,...) voor scenariotesting en bijsturing				standaard werkmethode
API Vlaanderen		GIS libraries		Python Pandas  (Dataframe) naar DB				Gevaarlijk om dynamische (continue updates) grafieken te delen !
clusteren - verrijken - ..		FME Data Integratie Platform (server component)		Bijhouden, visualiseren, informeren, planologisch (ruimtelijk) beleid (RUP, GWP)				Ijkpunten vastleggen, op data van welke moment analyse is gebeurd.
		Netwerkanalyse - bereikbaarheidzones --> ESRI, FME, openrouteservice		GOAT tool
Python		meten oppervlaktes: ESRI, FME, QGIS, GDAL?,		Training : Videos/Youtube kanaal, opname doen, camera's
DB/API Integraties		afstand tot groen		Scheduler om analytische rapporten regelmatig te draaien ifv triggers/events
DSI : Digitale Stedenbouwkundige informatie		analyse van data - creëren van berekende data /... via GIS/FME/SQL/Python/R		visualiseren in GIS programma (ook in powerpoint)
Realtime updating: Message broker				ESRI :story map, dynamic powerpoint (pdf)
				ArcGIS for Power BI
				Clevermaps, Qlick
updaten > analyses herhalen - scheduler  (FME, server - scripts, ..)				visualiseren: VertiGIS
geomapping				monitoring / vergelijken
				GIS-software
link bestaande data verzameling bijv. provincies in cijfers e.a.				BI-rapportage
				AI training / Machine learning aan de hand van historische datasets
update: versioning
monitoring / vergelijken
Verrijking: linked data (dataspace ?)

Oefening 2+3

Input taken		Hoofdtaken		Output taken		Valkuilen		Principes
marktplaats > (open) dataplatform > welke data zet je voor wie open: intern, overheid, burgers, bedrijven		Documentatie metadata		Hosting omgeving (vb AWS)		Vertrouwen in data door beleids-medewerkers: hoe aanpakken?		Traceerbaarheid van de data
marktplaats: github (afgewerkte toepassing vrij laten gebruiken) of kostendelend model		data catalog		FAQ
		Security: Pseudo- of anonimiseren van data of aggregeren		HPC : HighPerformance Computing (Vlaamse Super Computer)
wie laat je toe om met de data aan de slag te gaan: overheden, studiebureau's, burgers.....expertise over de data is vaak essentieel.		Security: Multi-Factor-Authentication		Opvolging wetgeving/beleidsdoelstelling: GDPR, AI, en veranderende wetgeving/beleid
Rollen en verantwoordelijkheden		Vlaanderen: ACM / IDM componenten		duidelijke doucumentatie + opleiding voor verschillende profielen
Competenties (bevraging)/rol		SLA & Data Governance : Afspraken rond updates en aanleveren van nieuwe data met aandacht voor de kwaliteit van de data
dataintegratie van verschillende bronnen: intern, open, privaat
verantwoordelijkheid: databeheer, databronnen, onderhoud
samenwerkingsovereenkomst / afsprakenkader
toegankelijkheid: steeds meer applicaties ? centraal vertrekpunt? ? herkenbaarheid vanuit Vlaamse overheid
overzicht van gebruik/gebruikers (monitoren)
Anonimiseren en pseudonimiseren

Oefening 4

"Hoe zetten we het beheer van dataverwerking op voor verschillende lokale besturen? Rekening houden dat zowel stad Gent als (verschillende besturen binnen het werkgebied) Intercommunale Leiedal zullen gebruikers zijn"

Leiedal: "we wensen iets te ontwikkelen voor Stad Gent en andere lokale besturen die hiervan gebruik willen maken. We zijn op zoek naar good practices, tips en tricks etc."

• Het blijft altijd een pijnpunt wanneer de correctheid van de data niet gegarandeerd kan worden. Het is daarom belangrijk om goede afspraken te maken over de manier waarop data verzameld wordt. Bepaalde kwalitatieve data kan enkel lokaal verzameld worden maar het beheer moet op grotere schaal (idealiter op Vlaams niveau) gebeuren. Hoe wordt dit het beste georganiseerd? VLAIO neemt de lead maar heeft onvoldoende terreinkennis mbt de verzameling van de data waardoor een mismatch ontstaat tussen de aanpak van VLAIO en de nood op het terrein. Er is een goed overlegmodel nodig om de manier te kunnen finetunen waarop data verzameld wordt.
• De vraag gaat een stuk over data. De bouwblokken zijn een goed voorbeeld waarvoor we op Vlaams niveau een oplossing zoeken. Het gaat echter ook over de ETL verwerkingsprocessen naar informatie. Deze processen worden opgezet en uitgerold in verschillende besturen. Draait dit bij iedereen best apart of toch beter gezamenlijk opzetten?
• De toeristische infrastructuur wordt beheerd door verschillende provincies bvb de knooppunten (bordjes) voor de wandel-en fietsroutes. Elke provincie beheert deze infrastructuur, weliswaar met ambassadeurs op het terrein. Zij verzamelen en actualiseren de data in hun eigen systemen. Toerisme Vlaanderen, als overkoepelende entiteit, gaat dan ervoor zorgen dat de data samen komt, er kwaliteitscontroles gebeuren en dat er op de grenzen van de provincies de netwerken mooi op elkaar aansluiten etc. De overkoepelende netwerkinformatie kan zo gebruikt worden in verschillende applicaties om je wandel-of fietsroute te plannen. Dit is een proces dat gestuurd wordt via de cloud, waarbij er rapporteringen kunnen gebeuren en waarbij de provincies instaan voor de kwaliteit van hun data. Zij bieden deze aan en er wordt automatisch een controle gedaan op een aantal kwaliteitspunten die afgesproken worden (bvb wat verstaan wij onder kwaliteit voor dataset x of y, aan welke vormvereisten moeten deze voldoen). Indien er iets niet in orde zou zijn, wordt dit in een rapport gegoten en koppelt men hierover terug zodat dit kan verbeterd worden en de data opnieuw kan aangeboden worden. Dit is een voorbeeld van decentraal beheer dat centraal aangeboden wordt.
• Voor Slim Ruimtelijk Plannen is het moeilijk om te zeggen aangezien er verschillende beleidsdomeinen bij elkaar komen. Je bent hier niet zeker van de dekking van de gebieden die door de lokale besturen aangeboden worden.

Leiedal: enerzijds proberen we zoveel mogelijk open data te gebruiken. Soms heeft een lokaal bestuur een betere dataset rond bvb groen die we graag willen integreren in de tool. Als je open data gebruikt, ga je er vanuit dat het een volledig gebied dekt. Hier tegenover staat de interne data die bij de grenzen stopt. Ruimtelijke plannen gaat net over deze grenzen heen en hierbij wil je ook effecten van een buurgemeente kunnen mee in kaart nemen wanneer je SLIM ruimtelijk wil plannen. Alle informatie van de gemeentegrenzen willen we meenemen.

• Het komt erop neer dat je moet bepalen welke datasets je wil opbouwen en ter beschikking stellen en hierrond duidelijke afspraken te maken met de kwaliteitseisen in het achterhoofd
• Indien lokale data niet helemaal accuraat is, moet bekeken worden hoe ze aan te passen of aangevuld worden aan de hand van een extrapolatie
• Het belangrijkste is dat bij het gebruik van datasets die door verschillende partijen gebruikt worden, duidelijke afspraken gemaakt worden. Hiervoor zit je eerder in het OSLO-traject: zowel rond semantiek als structuur van aanvoer van gegevens.

Rond de verwerking van de data: wie beheert de centrale ruimtelijke planning? Of blijft dit lokaal? Heeft het zin om deze te centraliseren

• Dit heeft enkel zin wanneer ze herbruikbaar zijn door verschillende partijen.
• Er moet voldoende kennis zijn
• De data moet kunnen gelezen/gebruikt worden met verschillende software
• Het is belangrijk om dit goed in de interface te verwerken om wanorde te vermijden => standaardisatie is nodig om scripten op te laden

Discussiepunten

Het is gevaarlijk om dynamische (realtime) grafieken te delen - er kan een grote impact zijn op het beleid. Men moet deskundig omgaan met data

• Dit is ook de vraag altijd: willen we met actuele data werken? Je zit altijd met een stedenbouwkundig of een verordening tempo. Je wil wel dat de data een actueel beeld geeft van de toestand. Een goed ritme vinden daarin is belangrijk.
• Daarom is het belangrijk om hierover op voorhand te communiceren naar beleid; een ijkpunt is nodig voor analyse. Het probleem komt vaak terug bvb bij verkeerstellingen kan er een snelle evolutie plaatsvinden. Bij discussies bij de Raad van State kan geargumenteerd worden dat data niet meer actueel is. Dit kan verregaande gevolgen hebben.

Specialisten zullen gemakkelijk hun weg vinden naar courant gebruikte applicaties van de Vlaamse Overheid maar indien het de bedoeling is om een breed publiek aan te spreken (bvb in het kader van participatie), zal het belangrijk dat we niet vanuit verschillende applicaties apart werken maar dat er een soort herkenbaarheid is. Dit schept mogelijks meer vertrouwen bij burgers. Dit kan belangrijk zijn om mee te nemen zodat iedereen nog de bomen door het bos ziet.

Het is belangrijk om een concreet voorbeeld te kunnen geven ipv veel theorie bij een nieuwe applicatie voor bvb ambtenaren. Het kan interessant zijn om een case te onderbouwen met deze tool dan.

• dit kan het bewustzijn verhogen rond de kracht van data en wat ermee mogelijk is
• dit kan ook dienen als een spiegel om te bekijken hoe bruikbaar een tool is en of bepaalde zaken nog aangepast moeten worden

Vragen en opname

Vragen

• Vraag voor Ann: zit bvb de impact van een bouwproject voor +1000 inwoners en daaraan gelinkte druk op parken ook in het platform? De front-end van het platform is volledig gebouwd op API's. Hier zitten verschillende simulaties in maar het is open en uitbreiding is mogelijk waardoor je nieuwe use cases of simulaties en modellen aan kan toevoegen bvb biodiversiteit, leefbaarheid etc. Eens je een licentie hebt voor het gebruik van het platform kan je aan de modellen aan maar het is niet gratis.

• Vraag voor Ann: is het eenvoudig om analyses over te zetten naar een presentatie voor het beleid? - het is allemaal voorzien om mooie kaarten te produceren die je kan opnemen in een rapportering.

Opname

De opname van deze sessie is te bekijken via deze link.

Volgende stappen

De volgende stappen zijn:

1. Verwerking van de input van de brainstorm oefening
2. Rondsturen van een link naar dit verslag en presentatie
3. Resultaten verzamelen en verwerken in een referentiedocument

   Andere werkgroepen

   Hieronder het overzicht van alle VLOCA-werkgroepen die hebben plaatsgevonden binnen het kader van het traject Slim Ruimtelijk Plannen.

Werkgroep	Type werkgroep	Datum	Tijd	Locatie
Business werkgroep	Business werkgroep	2023-09-27		Stadskantoor Gent
Thematische werkgroep 1	Data en informatie werkgroep	2023-11-14		Teams
Thematische werkgroep 2	Functionele werkgroep	2023-12-19		Teams
Thematische werkgroep 3	Technologie werkgroep	2024-01-23		Teams