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

Evidence based decision making Business Process (zonder componenten) +
Flood4Cast logo +
Focus centr disp +
Focus fys afhaalpunt +
From OpenDei +
Gaia-X concept +
Geen deliverables gevonden +
Een algemene flow voor het implementeren v … Een algemene flow voor het implementeren van een watersensornetwerk Keuze sensor en sensorlocaties Bij het opzetten van een watersensornetwerk komt veel bij kijken. Welke sensor kiezen we? Hoeveel, en waar plaatsen we die net? Op de volgende pagina's gaan we in op zulke vragen: Hoe kies ik een geschikte sensor Hoeveel en waar sensoren plaatsen Hoe kies ik de geschikte datatransmissie en logging device Bijkomende data verzamelen / data verrijken Eens het sensornetwerk in plaats is kan er gekeken worden of deze data aangevuld kan worden met bijkomende (open) data. Dit wordt ook wel Data enrichment genoemd. Een eerste aanzet van open data bronnen in de waterwereld vindt u hier, al is deze zeker niet exhaustief! Neerslag Waterhoogtes waterkwaliteit bodemvocht Op waterinfo is al een netwerk van neerslag en waterhoogte data publiek beschikbaar. Data opslag Data kan best van in het begin op een gestructureerde manier bijgehouden worden. Voor de VLOCA aanbevelingen, zie volgende pagina: Ik wil de data bewaren (keuze databank, backups, toegangscontrole,…) Data delen Het openstellen van data vraag enige aandacht, zodat andere partijen hiermee makkelijk aan de slag kunnen. Lees hier de VLOCA aanbevelingen hierover. Data analyse Best practices voor data analyse vindt u hier . Draaiboeken per thema Er zijn verschillende draaiboeken uitgewerkt per concrete case, deze kunnen hier teruggevonden worden: Ik wil wateroverlast kunnen voorspellen Ik wil een bufferbekken optimaal inzetten voor de droogteproblematiek Ik wil waak- en alarmpeilen detecteren Ik wil een netwerk van pluviometers implementeren Ik wil bemalingswaterdebieten in real time volgen Ik wil illegale lozingen detecteren Ik wil real-time waterkwaliteitsparameters communicerenerkwaliteitsparameters communiceren +
Een authentieke gegevensbron is de meest v … Een authentieke gegevensbron is de meest volledige, kwalitatief hoogstaande verzameling van gegevens die op elektronische wijze worden bijgehouden. Authentieke gegevensbronnen zijn nuttig of noodzakelijk bij de uitvoering van de taken van algemeen belang waarmee Vlaamse en lokale overheden belast zijn of bij de uitvoering van de verplichtingen die op hen rusten. Het programma Authentieke Gegevensbronnen [1] streeft daarbij naar de harmonisering van informatie en stelt informatie bronnen ter beschikking met deze kenmerken: AuthenticiteitInteroperabiliteitKwaliteitOpenheidHerbruikbaarheid (vraag niet wat je al weet) Deze bronnen worden niet alleen ontwikkeld of onderhouden door Informatie Vlaanderen zelf, zoals de basisregisters en de basiskaart Vlaanderen (GRB). Ook het bijhouden en beschikbaar stellen van relevante bronnen van andere overheden behoort tot de doelstelling. Speciale aandacht gaat naar sterke koppelvlakken tussen basisobjecten in lijn met de geldende datastandaarden. Dankzij deze koppelvlakken kan data vlot met elkaar in verband worden gebracht voor de afnemers en toepassingen van de digitale overheid. Lees meer: https://github.com/Informatievlaanderen/werkgroep-authentieke-gegevensbronnen ↑ https://overheid.vlaanderen.be/informatie-vlaanderen/ontdek-onze-producten-en-diensten/authentieke-gegevensbronnen-diensten/authentieke-gegevensbronnen +
Een basisregister wordt gedefinieerd als " … Een basisregister wordt gedefinieerd als "een betrouwbare authentieke bron van informatie die onder de controle staat van een hiervoor aangestelde publieke administratie of organisatie door de overheid". Om een basisregister maximaal te kunnen inzetten worden er een aantal eisen vooropgesteld, zoals het voldoen aan de OSLO-standaarden, de levenscyclus en de historiek. Dienstverleningsregister past binnen een stelsel van onderling verbonden basisregisters. Dit stelsel vormt het fundament voor een vlotte gegevensuitwisseling- en integratie binnen en buiten de overheid die hergebruik van data stimuleren en dubbele opvraging en registratie vermijden. Zes referentieobjecten treden hierbij steeds op de voorgrond: personen, ondernemingen, percelen, gebouwen, adressen en de kaart. https://overheid.vlaanderen.be/dienstverleningsregistereid.vlaanderen.be/dienstverleningsregister +
Een classificatie is een van de twee meest … Een classificatie is een van de twee meest primordiale taken bij machine learning (samen met regressie). Het doel van classificatie is een waarde te voorspellen uit een beperkte reeks van klassen, op basis van een gegeven input. De soorten invoer kunnen zijn: univariate of multivariate gegevens (numerieke, of categorische datapunten) beeldgegevens (een matrix van breedte*hoogte*kanaaldimensie) sequentiegegevens (een lijst, al dan niet met vaste breedte, van gebeurtenissen of logisch geordende items) audiosignaal (dat vaak met behulp van een spectrogram in een beeldvormig formaat wordt omgezet) Soorten classificaties zijn: Binaire classificatie : 2 mogelijke uitkomsten Multiklas classificatie : >2 mogelijke uitkomsten, 1 voorspelde waarde Multi-label classificatie : >=2 mogelijke uitkomsten, toepasbaarheid van elk aantal labels voorspeldd van elk aantal labels voorspeld +
Een data formaat is de organizatie van inf … Een data formaat is de organizatie van informatie volgens een aantal ge-predefinieerde specificaties. Voorbeelden van data formaten zijn tekst bestanden, binaire bestanden, AVRO data bestanden, Parquet bestandsformaten, ...Een data formaat is dus een fysische representatie (serialisatie) van data (waarden) die meestal geoptimaliseerd is voor efficientie van data opslag of data uitwisseling. De specificatie kan impliciet of expliciet (bv. volgens een officiele standaard) zijn. Data kan op die manier aangeboden worden als : gestructeerde data. Deze data heeft een gepredefinieerd data formaat meestal als de structuur van een verzameling alvorens die opgeslagen wordt. Het beste voorbeeld hier is de relationele database, waar de data geformatteerd is in precies gedefinieerde velden, om gemakkelijk opgevraagd te kunnen worden, bijvoorbeeld door SQL. Voorbeelden can zulke data formaten zijn RDF, Parquet, Avro. Deze data worden vaak opgeslagen in data warehouses. semi-gestrucutureerde data. Is gestructureerde data die niet voldoet aan de formele structuur van een relationele database, maar wel tagging of andere markers gebruikt om verschillende elementen van elkaar te scheiden. De data heeft een zelf-beschrijvend formaat. Voorbeelden van zule data formaten zijn JSON, CSV, XML, NGSI-LD, ... ongestructureerde data. Dit is data die wordt opgeslagen zonder data formaat. Voorbeelden zijn text en binaire blobs, video, email, ... Deze data wordt vaak opgeslagen in data lakes. wordt vaak opgeslagen in data lakes. +
Een data platform kan ook toelaten om bepa … Een data platform kan ook toelaten om bepaalde algoritmes op de data te faciliteren. Meer en meer heeft ruwe data te weinig business waarde, en is het data fusion of het toepassen van algoritmes op de data die de waarde toevoegen. Video stromen op ANPR camera's bijvoorbeeld hebben weinig waarde, het is het algoritme die de nummerplaten detecteert die waarde toevoegt. We zien ook meer en meer dat 1 data stroom tot meerdere afgeleide datastromen kan leiden (zoals die video stroom die nummerplaten kan detecteren, maar ook bijvoorbeeld calamiteiten of bewakingsdoeleinden kan hebben). Al die bewerkingen op de data hebben op hun beurt nood aan transformaties, opslag, ... en dus vormen die een belangrijk deel van technische capaciteiten die een data platform kan aanbieden. Een aantal voorbeelden : interoperabele en/of portabele modellen die kunnen ingezet worden voor simulatiedoeleinden artificiele intelligentie algoritmes (bijvoorbeeld machine learning met training en test datasets, en inference functions) streaming analysis, bijvoorbeeld kalibreren van sensoren op basis van andere data en hun historiek data science Business Intelligence & reportinge Business Intelligence & reporting +
Een data platform moet data aanbieden aan … Een data platform moet data aanbieden aan zijn gebruikers. Data moet gepubliceerd kunnen worden met verschillende protocols en in verschillende formaten, afhankelijk van de vereisten van de toepassingen. Dit sgement bevat technische capaciteiten om dit mogelijk te maken. Idealiter worden hier standaard APIs aangeboden (voorbeeld : Linked Data Event Streams, Fiware APIs, OGC API's, ...), met open formaten voor de data (bv Parquet formaat voor big data, maar dit kunnen evengoed JSON bestanden zijn). Het service segment kan data ook aanbieden via schaalbare infrastructuur, zoals Kafka of MQTT brokers of HTTP services. Het identificeren van de noden van de gebruikers (bijvoorbeeld rond het bevragen van de data en welke indices zoals tijd of plaats) is daarbij heel belangrijk om een schaalbare en ge-unificeerde service aan te bieden. Deze service laag is heel belangrijk binnen het virtueel smart data platform, ook wel data space genoemd. De Vlaamse Smart Data Space biedt componenten aan om data schaalbaar en interoperable te delen en bevragen.n interoperable te delen en bevragen. +
Een data schema beschrijft de structuur va … Een data schema beschrijft de structuur van een data model. Dat kan bijvoorbeeld de structuur zijn van een database, waar het schema (in tekst en grafisch) de tabellen, velden, relaties, indezes, ... beschrijft. Een voorbeeld van een data schema taal is SHACL. SHACL kan gebruikt worden om de structuur van data (opgeslagen in RDF of JSON of gelijkaardige formaten) te beschrijven. SHACL bevat een RDF vocabularium van klassen, eigenschappen en mogelijkheden om de integriteit van data elementen te beschrijven. Dit draagt sterk bij tot het verhogen van de Data Kwaliteit.Andere voorbeelden zijn XML schema's of RDFS.ere voorbeelden zijn XML schema's of RDFS. +
Een door FIWARE geïntroduceerd sleutelbegr … Een door FIWARE geïntroduceerd sleutelbegrip is het begrip context informatie.In het algemeen is context de informatie rond de informatie. Zonder context is de informatie moeilijk, zo niet onmogelijk te begrijpen.Voor slimme steden zijn veel voorkomende voorbeelden van context de informatie aangaande: tijd ; wanneer is de informatie gemaakt; plaats ; waar is de informatie gecreëerd. Deze context maakt het mogelijk metingen te relateren aan echte gebeurtenissen en aan andere metingen. Een voorbeeld hiervan is verkeersinformatie: de tijd en locatie van b.v. een file, maakt het mogelijk om dit te relateren aan een evenement (bijv. voetbalwedstrijd). Context Management is een Minimum Interop Mechanism geworden binnen de aanbevelingen van Open_And_Agile_Smart_Cities Functionaliteit voor de opslag van context informatie in een Context Broker is daarom de basis van OASC compliant implemenaties.an OASC compliant implemenaties. +
Een eerste aanzet voor een definitie wordt hier gegeven. eigenlijk hier: https://vloca-kennishub.vlaanderen.be/vloca-kennishub/Data_broker +
Een geschematiseerde voorstelling van IDA datastromen tussen Organisaties . +
Een informatie-architectuur beschrijft de inhoudelijke relaties en samenhang tussen toepassingen en gegevens onderling. Een informatie-architectuur maakt de relaties tussen informatie van een organisatie inzichtelijk. +
Een ontologie beschrijft concepten en hun … Een ontologie beschrijft concepten en hun relaties binnen een specifiek domein. Een ontologie kan beschreven worden met computer beschrijvende talen zoals RDF (Resource Description Framework), RDFS (Resource Description Framework Schema), OWL (Ontology Web Language). Deze talen kunnen geserialiseerd worden in verschillende formaten zoals XML of JSON.Een ontologie is dus een formele beschrijving die de organizatie van kennis definieert, bedoeld als een verzameling concepten binnen een domein met hun onderlinge relaties. Deze ontologieeen werken zoals het menselijk brein, die "werken en redeneren met" concepten en hun relaties via links.Om zo een ontologische beschrijving mogelijk te maken, moeten componenten zoals objecten, klassen, attributen en relaties, maar ook beperkingen, regels en axiomas formeel gespecifieerd worden. Een ontologie brengt dus een taal mee om relaties uit te drukken op een flexibele manier, en gaan op die manier ook verder dan andere voorstellingen van kennis zoalswoordenschat, taxonomy, logisch model ,... Ontologieen zijn noodzakelijk voor semantische interoperabiliteit. In de literatuur wordt er een onderscheid gemaakt tussen informele en formele ontologieeen, zoals hieronder weergegeven. ( https://www.researchgate.net/publication/239443286_Ontology_Learning_from_Text_A_Look_Back_and_into_the_Future/figures?lo=1 )ok_Back_and_into_the_Future/figures?lo=1 ) +
Een referentie architectuur is een beschri … Een referentie architectuur is een beschrijving ter illustratie van hoe een systeem kan gebouwd worden met andere partijen. Op deze pagina starten we met een beschrijving op hoog niveau van hoe zo'n architectuur eruit zou kunnen zien. De bedoeling is dat VLOCA een Open City architectuur kan co-creëren die toepasbaar is op het Vlaamse landschap van steden en gemeenten en vooral toelaat om toepassingen gemakkelijk en duurzaam uit te rollen, met respect voor principes die het systeem kan instantieren tot platformen die met elkaar kunnen communiceren en voldoen aan de VLOCA praktijken. Om te starten, hebben we een eenvoudige architectuur blauwdruk samengesteld, waar we reeds een aantal mogelijke aandachtspunten samenvatten. Deze zijn onder andere het economisch kader (adhv markplaatsen) en de mogelijke interacties die een platform dat voortvloeit uit de architectuur vorm kunnen geven. Bovendien wil VLOCA gaan voor de architectuur die nodig is voor een Open slimme stad . Dit is een initieel startpunt om de VLOCA co-creatie te inspireren, en waar verder kan op geïtereerd worden in de volgende fazen van VLOCA. Zoals te zien is in onderstaande figuur, worden een aantal lagen onderscheiden samen met de marktplaats die de Componenten en elementen uit deze lagen kan aanbieden. Om dit te realiseren, moeten de Componenten tussen lagen onderling ten minsten compatibel en interoperabel zijn, zodat verschillende elementen uit de diverse markplaatsen met elkaar kunnen gekoppeld worden. Deze architectuur moet toelaten om snel applicaties te creëren via API's ( API-first principe) op verhandelbare of open data ( DATA-first principe), afhankelijk van de toepassing en de nood aan business intelligentie. We hebben op de applicatie laag ook een ondersteuning voorzien voor het bouwen van applicaties, en delen van code onderling zodat bouwers van toepassingen heel snel nieuwe oplossingen kunnen uitrollen, wat in de steeds sneller veranderende wereld en uitdagingen binnen een slimme stad een belangrijke uitdaging is. De architectuur voorziet ook verschillende toegangspoorten tot de functionaliteit, zodat de toepassing voor verschillende doelgroepen de gepaste functionaliteit kan opleveren. Een marktplaats van aanbestedingen kan tenslotte zorgen dat (deel)aanbestedingen kunnen hergebruikt worden tussen steden en gemeenten om verschillende reeds succesvolle combinaties van de onderdelen en platform varianten te hergebruiken en zo toepassingen sneller over steden en gemeenten uit te rollen. blauwdruk referentie architectuur Binnen de definitie van een architectuur , en met de specifieke uitdagingen van een "open city" architectuur, zijn de basisprincipes natuurlijk van groot belang om onder andere de kost van verandering en evolutie tot een minimum te beperken. Belangrijke principes en kenmerken die we binnen VLOCA verder gaan verkennen worden hieronder opgelijst, maar zijn niet exhaustief. open, geconnecteerd, performant, herbruikbaar, modulair, ... open source en open data strategie gebruik van open Standaarden op de juiste plaatsen aandacht voor belangrijke eigenschappen van data : kwaliteit, snelheid, privacy, veiligheid, elasticiteit, integriteit, eigenaarschap en soevereigniteit, ... welke processen zijn nodig (bv. DataOps) ? wat zijn de minimaal nodige beheersprincipes ? documentatie en bruikbaarheid business en economisch model ? ...? ... +
Een service-level agreement of SLA is een … Een service-level agreement of SLA is een overeenkomst waarin afspraken staan tussen aanbieder en afnemer van een dienst of product. Er wordt afgesproken wat de prestatie-indicatoren en kwaliteitseisen zijn van de te leveren dienst of product, om deze later te kunnen toetsen. In een SLA worden de rechten en plichten van beide partijen omschreven. Een SLA kan als afspraak bestaan tussen zowel externe (leverancier) als interne (klant) partijen binnen een organisatie. Lees ook: https://nl.wikipedia.org/wiki/Service_level_agreementwikipedia.org/wiki/Service_level_agreement +
Een slimme stad is een soort 'super toepas … Een slimme stad is een soort 'super toepassing' op het domein van Internet Of Things . Op het vlak van IoT zijn er binnen Europa verschillende piloten uitgevoerd ("large scale pilots") die geleid hebben tot een inspirerende 3D-referentie architectuur, hieronder weergegeven en terug te vinden op [[ OpenDei | OpenDei ]]. We zien op de Z-as de verschillende lagen van een mogelijke smart city stack, met hun respectievelijke verantwoordelijkheden. Op de X-as zien we dan belangrijke " cross-cutting " functies waar een professioneel platform moet aan voldoen, zoals veiligheid, privacy, connectiviteit en betrouwbaarheid. En tenslotte worden de belangrijkste architecturale "systeemeigenschappen" op de Y-as meegenomen, zoals interoperabiliteit, schaalbaarheid, beheersmogelijkheden, ... Dit is een mooi model om verder tijdens VLOCA te gebruiken als inspiratiebron, aangezien het de lessen uit verschillende grote EU projecten combineert. De principes en kenmerken die hier vermeld worden, kunnen we ook gaandeweg beter gaan identificeren en beschrijven. 3D referentie architectuur E-LSP ( https://european-iot-pilots.eu/wp-content/uploads/2019/06/IoT-_European-_Large-Scale_Pilots_Programme_eBook_CREATE-IoT_V02.pdf )ilots_Programme_eBook_CREATE-IoT_V02.pdf ) +
Een typische IT architectuur wordt meestal … Een typische IT architectuur wordt meestal opgebouwd uit lagen die een bepaalde cohesie tussen hun geleverde functionaliteiten vertoont. Zo zijn in de referentie architectuur reeds een aantal lagen gedefinieerd. De Open Smart City architectuur bestaat uit subarchitecturen (bv. voor een IoT stack) die ook uit lagen bestaat. Deze categorie gaat deze lagen beschrijven en links leggen met de andere Smart City elementen. OpenDei gebruikt de 6C Bouwlagen in zijn kennismodel : De OpenDei RAF (Referentie Architectuur Framework) ziet er als volgt uit :amework) ziet er als volgt uit : +
Eigenschappen die specifiek zijn voor een … Eigenschappen die specifiek zijn voor een systeem. Voorbeelden hiervan zijn schaalbaarheid; Een systeem met deze eigenschap kan bijvoorbeeld vrij eenvoudig grotere hoeveelheden data aan. Oplijsting vanuit E-LSP architectuur: intelligentie beschikbaarheid afhankelijkheid beheerbaarheid integreerbaarheid schaalbaarheid interoperabilityarheid schaalbaarheid interoperability +
Embed a video on the page, use an embed link, example: https://www.youtube.com/embed/ScMzIvxBSi4 Template parameters Parameter Description Type Status Url Url no description Example https://www.youtube.com/embed/ScMzIvxBSi4 URL required +
Er is geen duidelijke verdeling tussen een … Er is geen duidelijke verdeling tussen een vocbularium en een ontologie . Ontologie wordt meer gebruikt voor complexe en formele verzameling van termen. In de stricte zin van het woord is een vocabularium een context-loze lijst van termen met geen gedefinieerde relaties. Een ontologie daarentegen impliceert wel de aanwezigheid van relaties tussen de termen, axiomas, klassen, ...es tussen de termen, axiomas, klassen, ... +
European Committee for Standardisation of … European Committee for Standardisation of CEN is een vereniging die de nationale normalisatie-instellingen van 34 Europese landen verenigt. CEN is een van de drie Europese normalisatie-instellingen (samen met CENELEC en ETSI) die officieel zijn erkend door de Europese Unie en door de Europese Vrijhandelsassociatie (EFTA) als verantwoordelijk voor het ontwikkelen en definiëren van vrijwillige normen op Europees niveau. CEN biedt een platform voor de ontwikkeling van Europese normen en andere technische documenten met betrekking tot verschillende soorten producten, materialen, diensten en processen. CEN ondersteunt normalisatie-activiteiten met betrekking tot een breed scala aan gebieden en sectoren, waaronder: lucht en ruimte, chemie, bouw, consumentenproducten, defensie en veiligheid, energie, milieu, voedsel en diervoeder, gezondheid en veiligheid, gezondheidszorg, ICT, machines, materialen, drukapparatuur, diensten, smart living, transport en verpakking. Meer informatie kan hier gevonden worden. informatie kan hier gevonden worden. +
FAIR checklist – Nieuwe dataset Wanneer … FAIR checklist – Nieuwe dataset Wanneer je als organisatie wil omgaan met data, dan is het belangrijk dat deze voldoet aan de FAIR Principes . Dit draaiboek beschrijft welke stappen je kan doorlopen om een nieuwe dataset conform de FAIR (F: Vindbaar, A:Toegankelijk, I:Interoperable en R:Herbruikbaar) principes in gebruik te nemen. SMIT-VUB maakte een checklist op die kan worden doorgenomen om een nieuwe dataset te evalueren in functie van deze FAIR principes . Stap 1: Identificeer de dataset Op basis van de onderstaande eigenschappen kan je de cruciale informatie over een dataset identificeren/verzamelen. Verzeker dat de infofiche zorgvuldig wordt ingevuld voor elke dataset. Eigenschap Antwoord Dataset naam Dataset afkorting Dataset aanbieder Dataset eigenaar Dataset domein Dataset beschrijving Dataset locatie Frequentie van data Kalibratie van data Gebruikslicentie DPO instructies Stap 2: Bepaal de gebruiksgeschiktheid Voldoet de dataset aan de doelen van de use case? Indien ja, ga ook na of er blokkerende elementen zijn waardoor de data niet zou mogen gebruikt worden. Raadpleeg in functie van de geldende GDPR wetgeving de Data Protection Officer van jouw organisatie of de organisatie vanwaar de data afkomstig is. Duid aan, bij de dataset identificatie, indien er aanbevelingen zijn op het vlak van privacy . Stap 3: Evalueer de ruwe dataset Vooraleer enig datagebruik of dataverwerking te gaan doen, is het belangrijk na te gaan of de ruwe dataset beantwoordt aan de FAIR principes . Voor de verschillende FAIR Principes werden vragen opgesteld die je als potentieel gebruiker van een dataset kan gaan beantwoorden. Deze vragen kunnen je helpen om te begrijpen of de ruwe dataset voldoet aan de FAIR Principes. FAIR principe Categorie Vraag Antwoord Opmerking Toegankelijk Data Context Werd de ruwe dataset samen met een dataschema geleverd? Herbruikbaar Data Context Bevat de dataset extra data die de doelen kunnen aanvullen? Toegankelijk Data Context Werd de ruwe dataset samen met een datavocabulaire geleverd? Toegankelijk Data Context Is de dataset voldoende actueel in de context van de use case? Toegankelijk Data Context Is de geschiedenis van de dataset beschikbaar? Kunnen we eerdere data van de huidige dataset controleren? Privacy Data Context Weten we met welke reden de data werd verzameld? Vindbaar Data Kwaliteit Weten we hoe de data is verzameld? Toegankelijk Data Kwaliteit Is de data in een toegankelijk formaat ? (Een formaat dat snelle verwerking mogelijk maakt?) Herbruikbaar Data Kwaliteit Is er een datastandaard toegepast? Vindbaar Data Kwaliteit Weet ik hoe de gegevens zijn verwerkt door de gegevensverzamelaar? Veiligheid Data Kwaliteit Zijn de gegevens beschermd tegen mogelijke risico’s? Veiligheid Data Kwaliteit Kan ik alleen de delen van de dataset zien die ik mag zien? Toegankelijk Data Kwaliteit Staat het protocol een authenticatie- en autorisatieprocedure toe waar nodig? Herbruikbaar Data Kwaliteit Wordt de data vrijgegeven met een duidelijke en toegankelijke datagebruikslicentie ? Toegankelijk Data Traceerbaarheid Is de metadata toegankelijk, ook als de data niet meer beschikbaar is? Vindbaar Data Traceerbaarheid Ken ik de herkomst van de data? Efficiency Data Traceerbaarheid Weet ik het doel van de uitgever van de data? Vindbaar Data Traceerbaarheid Wordt de data beschreven met rijke metadata ? Herbruikbaar Data Traceerbaarheid Is de databron onveranderlijk? Vindbaar Data Traceerbaarheid Is de verzamellocatie van elk datapunt gekend? (Link naar geodata) Toegankelijk Data Kwaliteit Is het protocol open, gratis en universeel toepasbaar? Herbruikbaar Data Kwaliteit Is er een mogelijkheid om de data fundamenteel te herzien via samenwerking met de producent? Uitwisselbaar Data Kwaliteit Heeft de data betrekking op een gemeenschappelijk gestandardiseerd glossarium? Privacy Data Kwaliteit Bevat de data gevoelige informatie (persoonlijke, financiële, intellectuele eigendomsgegeven)? Stap 4: Beslis of de kwaliteit voldoet Na deze evaluatie moet er een beslissing worden genomen of de dataset voldoende bruikbaar is. Enkel indien je van oordeel bent, op basis van de bovenstaande evaluatiestappen dat jij (of je team, organisatie) akkoord bent/is ga je door naar de volgende stap. Stap 5: Verwerk de data of laat de data verwerken Op basis van de uitkomst van de voorgaande stap en de doelstellingen die jij of je organisatie heeft, kan je de dataset verwerken of laten verwerken tot een voor jou/jouw organisatie bruikbare dataset. Stap 6: Evalueer de resulterende dataset Eens de dataset verwerkt werd, kan je ook nog een FAIR Principes evaluatie maken van de dataset die resulteerd uit deze verwerking. De vragen hieronder, opgesteld voor de verschillende FAIR Principes kunnen hierbij helpen. Op basis van deze evaluatie kan je beslissen of er nog verdere actie nodig zijn of niet voor het gebruik van de data. FAIR Principe Categorie Vraag Antwoord Opmerking Uitwisselbaar Data Context Ondersteunt de dataset meerdere gebruiksscenario’s? Toegankelijk Data Context Komt de dataset overeen met een gedeeld glossarium / gepubliceerde ontologie ? Efficiëntie Data Context Ziet de data er geloofwaardig uit? Efficiëntie Data Context Ondersteunt de dataset de organisatiedoelen en/of een gekozen toepassing ikv een use case. Efficiëntie Data Context Ondersteunt de dataset de aannames/vereisten van het model? Vindbaar Data Context Zijn de metadata toegelicht? Vindbaar Data Traceerbaarheid Krijgen de gegevens een wereldwijd unieke en persistente ID toegewezen? Vindbaar Data Traceerbaarheid Is de data technisch geïndexeerd en machinedoorzoekbaar? Vindbaar Data Traceerbaarheid Wordt de data beschreven met rijke metadata? Toegankelijk Data Kwaliteit Is de data voldoende volledig (ontbrekende waarden) voor het doel van het project? Herbruikbaar Data Kwaliteit Is de data te koppelen aan andere gebruikte datasets? Toegankelijk Data Kwaliteit Voldoet de data aan het formaat van het datalakehouse? Herbruikbaar Data Kwaliteit Wordt de data vrijgegeven met een duidelijke en toegankelijke datagebruikslicentie? Veiligheid Data Kwaliteit Is de data beschermd tegen risico? Herbruikbaar Data Kwaliteit Kan de dataset worden gevalideerd met real-life metingen? Is de data reeds gevalideerd door de data eigenaar? Uitwisselbaar Data Kwaliteit (Als het antwoord ja was in de ruwe lijst - stap 3): Komt de dataset overeen met de gemeenschapsnormen? Privacy Data Kwaliteit (Als het antwoord ja was in de ruwe lijst - stap 3): Voldoet de dataset aan de AVG (Algemeen Verordening Gegevensbescherming)-normen? Toegankelijk Data Kwaliteit (Als het antwoord ja was in de ruwe dataset lijst - stap 3): Is het voor het doel van dit project belangrijk om het protocol open, gratis en universeel aan te bieden? Stap 7: Stel een periodieke herevaluatie van de dataset in functie van de gekozen toepassing. Het is belangrijk om de datakwaliteit te blijven monitoren, en dus ook om bij te houden of de dataset nog steeds zal voldoen aan de FAIR Principes . Daarom is het aangeraden om een periodieke herevaluatie van de dataset te houden, in functie van de gekozen toepassing. +
FAIR principles DATA principes data wi … FAIR principles DATA principes data wiki Findable The first step in (re)using data is to find them. Metadata and data should be easy to find for both humans and computers. Machine-readable metadata are essential for automatic discovery of datasets and services, so this is an essential component of the FAIRification process. F1. (Meta)data are assigned a globally unique and persistent identifier F2. Data are described with rich metadata (defined by R1 below) F3. Metadata clearly and explicitly include the identifier of the data they describe F4. (Meta)data are registered or indexed in a searchable resource Accessible Once the user finds the required data, they need to know how they can be accessed, possibly including authentication and authorisation . A1. (Meta)data are retrievable by their identifier using a standardised communications protocol A1.1 The protocol is open, free, and universally implementable A1.2 The protocol allows for an authentication and authorisation procedure, where necessary A2. Metadata are accessible, even when the data are no longer available Interoperable The data usually need to be integrated with other data. In addition, the data need to interoperate with applications or workflows for analysis , storage , and processing . I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation. I2. (Meta)data use vocabularies that follow FAIR principles I3. (Meta)data include qualified references to other (meta)data Reusable The ultimate goal of FAIR is to optimise the reuse of data. To achieve this, metadata and data should be well-described so that they can be replicated and/or combined in different settings. R1. Meta(data) are richly described with a plurality of accurate and relevant attributes R1.1. (Meta)data are released with a clear and accessible data usage license R1.2. (Meta)data are associated with detailed provenance R1.3. (Meta)data meet domain-relevant community standards The principles refer to three types of entities: data (or any digital object), metadata (information about that digital object), and infrastructure. For instance, principle F4 defines that both metadata and data are registered or indexed in a searchable resource (the infrastructure component).e resource (the infrastructure component). +
Figuur 1 Wereldwijd netwerk van Repair Café international (bron: https://www.repaircafe.org/bezoeken/ ) +
Forum VLOCA zal vanaf 2023 een discussieforum implementeren op de kennishub. Deze pagina wordt verder aangevuld. +
Functionele werkgroep Deze thematische w … Functionele werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties . Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie- uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen. Een aantal vragen die hier naar voor komen zijn: Hoe zien de data- en informatiestromen eruit? Welke interacties voeren welke stakeholders uit en tot welk doel? Welke beslissingspunten komen we bij uitwisselingsmomenten en acties tegen? De Werkgroep staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen deze noden in kaart brengen. Specifiek zijn we voor deze werkgroep op zoek naar data & functionele analisten, eindgebruikers (voor e2e testing user journeys,), proces analisten, IT managers, solutions analisten/ architecten,.. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen. Heb jij interesse, specifieke noden, expertise of andere belangen bij dit traject? Klik hier om je in te schrijven. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2023-01-11 13u30-16u30 Digitaal Thematische werkgroep 1 Data en informatie werkgroep 2023-02-28 09u00-12u00 Digitaalatie werkgroep 2023-02-28 09u00-12u00 Digitaal +
Functionele werkgroep Deze thematische w … Functionele werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties . Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie- uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen.De tweede thematische werkgroep vond plaats op 18 april 2024. Context Initiatief VERA werkt samen met verschillende lokale besturen en de provincie Vlaams-Brabant om het probleem van modderstromen als gevolg van bodemerosie aan te pakken. Meer dan 100 gemeenten in Vlaanderen ondervinden bodemerosie, wat aanzienlijke schade kan veroorzaken aan zowel private eigendommen als publieke infrastructuur. Door klimaatverandering, trends in de landbouw en verharding zal dit probleem naar verwachting in de toekomst verder versterkt worden.Op dit moment worden erosiepoelen gebruikt als oplossing. Deze poelen worden onderaan de helling aangelegd om modderstromen op te vangen en te voorkomen dat ze schade veroorzaken. Deze erosiepoelen zijn uitgerust met sensoren en overlopen, waardoor het water op een gecontroleerde en langzame manier kan wegstromen. De vraag die zich stelt, is of deze erosiepoelen effectief zijn. Er bestaat onzekerheid over hun capaciteit en functionaliteit, vooral in noodsituaties. Het is essentieel om dit op een kostenefficiënte manier te monitoren, met als doel zowel acute waarschuwingen bij rampen als proactieve oplossingen voor het probleem.Er wordt nagedacht over het gebruik van peilmeters of debietsensoren om de erosiepoelen te monitoren. Hiermee kan worden bijgehouden hoeveel water door de overlopen gaat. Hoewel dit geen exacte voorspellingen oplevert, biedt het wel inzicht in de hoeveelheid neerslag. Het overkoepelende doel van het project is om een gecentraliseerd dataplatform op te zetten en een raamcontract te ontwikkelen voor de sensoren. De verzamelde data kunnen gedeeld worden met rioolbeheerders, landbouwers en verzekeringsmaatschappijen, omdat deze informatie waardevol kan zijn voor alle betrokken partijen. VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. VLOCA-model De start van elk VLOCA-traject begint bij een VLOCA-model: ID Samenvatting Beschrijving UC1 UC1: Sensoren Verschillende actoren willen verschillende types sensoren kunnen plaatsen en beheren (bv. onderhoudsplan). UC2 UC2: Data Captatie Ik wil als gebruiker alle informatie correct binnenkrijgen (context, data, goede transmissie) UC3 UC3: Dataplatform Ik wil als gebruiker een visualisatie zien van alle data zodat ik deze kan analyseren.Ik wil als gebruiker data kunnen toevoegen, aanpassen, delen en opslaan. UC4 UC4: Dashboarding Ik wil als gebruiker een dashboard kunnen hanteren met KPI's (bv kleurencodes) die ik zelf kan beheren in functie van de data. UC5 UC5: Message Center Ik wil als gebruiker via mijn tool contacten kunnen aanspreken, toevoegen, wijzigen en behandelen (messaging systeem). UC6 UC6: Predictie Op basis van de verworven data wil ik modellen kunnen gebruiken om predicties uit te voeren zodat er tactisch advies gegeven kan worden. UC7 UC7: Mitigatie Op basis van real time data en advies wil ik als lokaal bestuur kunnen reageren om de schade te minimaliseren (crisis management). UC8 UC8: Preventie Als lokaal bestuur wil ik een overzicht krijgen van adviezen, acties en aanbevelingen om modderstromen te vermijden. UC9 UC9: Advies Op basis van data van modderstromen wil ik dit kunnen analyseren, correlaties zien en advies verlenen. UC10 UC10: Marktplaats ik wil als gebruiker data en datasciencemodellen kunnen aanbieden en verkrijgen. UC11 UC11: ROI Business Modelling UC12 UC12: Helpdesk Helpdesk - FAQ - Reviews Tijdens deze werkgroep staan we stil bij UC1: sensoren. In de onderstaande figuur zie je een visuele voorstelling van dit VLOCA-model: Brainstormsessie Het doel en de aanpak van de brainstormsessie worden hieronder beschreven. Tevens wordt de uitkomst van de brainstorm hierin samengevat. Doel Het doel van de brainstormsessie is het volgende: Zicht krijgen op welke databronnen (bvb sensoren, KMI-data,..) we nodig hebben om een antwoord te bieden aan onze probleemstelling/voor de realisatie van de meerwaardecreatie Bekijken welke data reeds beschikbaar is (gratis of betalend), welke we zelf moeten verzamelen Indien we data zelf gaan verzamelen, hoe doen we dit? Waarmee moeten we rekening houden? Zicht krijgen op welke contextuele data/geodata we nodig hebben Stilstaan bij duurzaamheid bij de keuze voor bepaalde databronnen (bvb geografische coverage van sensoren, budget, uitrol, al dan niet uitbesteden beheer van sensoren etc.) Valkuilen identificeren bij gebruik van bepaalde databronnen Principes formuleren voor het gebruik van deze databronnen Oefening 1+2 Instructies Bij deze oefeningen stonden we stil bij de volgende vragen: Welke data/variabelen hebben we nodig om een antwoord te bieden aan de nood voor advies, preventie en efficiëntieverhoging? Voorbeeld: - Neerslag voorspelling + actuele meting 2. Uit welke databronnen haal je deze informatie? Hoe onderscheidt deze databron zich van een andere? Welke data is reeds beschikbaar (gratis of betalend)? Welke moeten we zelf gaan verzamelen? Hoe doen we dit? Welke applicaties (tools die je gaat gebruiken) heb je nodig om de databronnen te sturen/ondersteunen? Welke functieprofielen heb je hiervoor nodig? Voorbeeld: -KMI data -Data uit pluviometers Output Data Type ondergrond landgebruik / vegetatie / ... Temperatuur (verdamping,...) Neerslag-intensiteit? Kracht van het vallen van water (bvb hagelbui tov normale regen) => liter/mm2/uur verzadiging bodem door eerdere neerslag temperatuur, luchtvochtigheid, ... -> evapotranspiratie Hellingsgraad omliggend gebied + ploegrichting, bewerkingsrichting vochtgehalte bodem neerslag verleden, heden, toekomst verwachte neerslag Bodemdata: Bodemvocht, C-gehalte bodem (Organische Koolstof => hoe meer hoe beter infiltratie) =>adhv bodemstaal, samenstelling bodem (Zand, klei, leem, ...)... Welk gewas (gras, ...) op het veld/akker en welk stadium van het gewas (pas gezaaid of pas geoogst of al gewas met gesloten bladerdek en goed ontwikkelde wortels bodemtype (leemlaagdikte, kalklaagdikte,...) bvb in VLBR vind je ijzerzandsteen die veel minder doorlatend is... Weging slibtransport bij ruiming = hoe zwaar was de slib bij de ruiming => validatie van de modellen. Meestal komt slib niet terug op de landbouwgrond (?!), maar de gemeente gaat die 'modderbrij/pap' ruimen, gedragen door de gemeente, ze krijgen 75% subsidie, gemeente en stad staat in voor de onderhoud van de erosiepoel, ook al staan die op de grond van de landbouwer Over bronnen heen: stroom, dekking, datacommunicatie... Hoeveelheid sediment in poel Preventieve maatregelen die landbouwers al nemen (bv drempeltjes in de ruggen) ADCP (voor kennis opbouw niet operationeel) => Accoustic Doppler Current Profiler Zwevende stof (turbiditeit is een proxy hiervan, kan ook ultrasoon => vraagt minder onderhoud van de sensor) Goedkopere proxy voor turbiditeit Waterniveau in de toevoer naar de poel peilmetingen volume sediment (3D-scanning) Waterniveau in de poel Metingen van de sensoren in de poel Volume en oppervlakte van de erosiepoel Mogelijke vervuiling in toevoer =>zware metalen in sediment, hoge nitratenwaardes, enz. Lengte van de helling dimensionering en ontwerp van erosiepoel Hoogte sediment erosiepoel onverharde oppervlakte die afwatert naar de poel (hoeveel hectare land is er af naar die poel) Naast dimensionering ook overstortpeil (=wanneer gaat die overlopen) vd poel (geen meting uiteraard) Snelheid modderstromen (meet)signaal dat ruiming triggert Samenstelling sediment Discussie Neerslag (Huidig en Historisch): Bespreking van de variabele neerslag: huidige en verwachte neerslag, evenals historische neerslaggegevens. Impact van hevige buien, zoals hagel, en de meetbaarheid van neerslagintensiteit. Bodemverzadiging: Hoe eerdere neerslag de huidige bodemverzadiging beïnvloedt. Methoden om de verzadigingsniveaus van de bodem te meten en te beoordelen. Bodemkwaliteit en -samenstelling: Relatie tussen bodemvochtigheid, organisch koolstofgehalte, en waterinfiltratie. De invloed van bodemtype (zand, klei, leem) en de dikte van de bodemlagen op waterdoorlatendheid. Gewassoorten en stadia: Verschillende gewassoorten en hun stadia van groei en hun impact op erosie. Vergelijking van pas gezaaide gewassen versus goed ontwikkelde gewassen met betrekking tot erosiegevoeligheid. Akkerstructuur en Hellingsgraad: De rol van de bewerkingsrichting van akkers en hoe deze samenwerkt met de hellingsgraad. Specifieke regionale kenmerken zoals ijzerzandsteenlagen en hun invloed op erosie. Temperatuur en Luchtvochtigheid: De invloed van temperatuur op verdamping en bodemdoorlatendheid, vooral bij bevroren bodem. De rol van luchtvochtigheid Metingen in de poel: Discussie over sedimentmetingen en waterniveau in de poel, en het gebruik van verschillende sensortechnologieën. Het voordeel van ultrasonische sensoren voor minder onderhoud. Preventieve Maatregelen en Landgebruik: Overzicht van de preventieve maatregelen die landbouwers nemen tegen erosie. Impact van het type landgebruik en vegetatie op waterafvoer en sedimentvorming. Infrastructuur voor Sensoren: Overwegingen met betrekking tot stroomvoorziening (batterijen, zonne-energie) en datacommunicatie voor sensoren. Het bepalen van de benodigde sensorendekking en locaties voor optimale monitoring. Vervuiling en Samenstelling van Sedimenten: Mogelijke vervuiling van sedimenten met zware metalen en nitraatwaarden. Analyse van de samenstelling van sedimenten voor beter inzicht in erosie en sedimenttransport. Databronnen De landbouwer (type gewas, wanneer oogsten/zaaien/maaien) landgebruiksdata: Landbouw en visserij (jaarlijkse perceelsdata =iedere landbouwer verplicht om zijn percelen met gewassen te publiceren) = Europese verplichting (deel via Geopunt, Agentschap landbouw en zeevisserij) Satellietbeelden/ luchtfoto's voor bv. bodembedekkingsgraad => platformen zoals "watchitgrow" Thermometer Weerstations VMM (waterinfo.be) KMI (voorspelde neerslag, historiek inclusief) WoW - weather underground PWS (personal weather station) weather ... (open data weer platform van de KMI) Klimaatportaal VMM Pluviometer Pluviometers VMM (waterinfo.be) OVAM voor bodemattesten Vochtmeter Citizen science projecten (kleinschalige pluviometer netwerken, bodemvocht...) Meetlat 3D scanning Peilmeter Turbiditeits-meter Sensor om debiet te meten opvulling erosiepoel (op de erosiepoelen = snelheid van de modderstroom) Sensor om debiet te meten afvoer erosie poel Vlaamse Water Dataspace (toekomst) Watermeters Bodemonderzoek, terreinbezoek (metingen), bouwplannen Bodemdeskundige dienst Belgi https://www.vlaanderen.be/inbo/datasets/ (instituut voor natuur en bosonderzoek) Kaarten => geopunt www.dov.vlaanderen.be (databank ondergrond vlaanderen) Bodemanalyse Bodemstaal (C-gehalte) Digital twin van de poel voor modellering en onderhoud Aantal vrachtwagens afgevoerd sediment Sattelietbeelden, dronebeelden Discussie Landbouwer als Data-Bron: Landbouwers zijn belangrijke bronnen van gegevens over hun percelen, zoals welke gewassen worden geteeld en eerdere preventieve maatregelen tegen erosie. Landgebruiksdata: Jaarlijkse gegevens over landgebruik en gewassen worden verzameld door het Agentschap Landbouw en Visserij (voorheen ILVO), beschikbaar op Geopunt. Satelliet- en Luchtbeelden: Gebruik van satellietbeelden en luchtfoto's voor het monitoren van bodemvochtigheid en vegetatie, met platforms zoals Watch It Grow. Weersgegevens: Weerdata van KMI en andere bronnen zoals Weather Underground, inclusief historische neerslag en voorspellingsgegevens. Lokale weerstations, waaronder personal weather stations (PWS), kunnen ook bijdragen. Erosiepoelen en Sedimentmetingen: Metingen van sedimentopbouw in erosiepoelen door middel van volume-inschattingen na ruiming en met sensoren voor debietmetingen. Gemeentes zijn verantwoordelijk voor het beheer en de ruiming van deze poelen. Bodem- en Vegetatieanalyse: Bodemstalen worden gebruikt voor het bepalen van bodemkwaliteit en organisch koolstofgehalte. Bodemtype en -verzadiging worden ook gemonitord via OVAM en andere bodemkundige diensten. Data-infrastructuur en Sensoren: Infrastructuur voor sensoren, zoals batterijen en datacommunicatie, om diverse metingen te ondersteunen, waaronder debiet, bodemvochtigheid, en sedimenthoeveelheid. Citizen Science: Gebruik van data van Citizen Science-projecten, waar vrijwilligers bodemvocht en andere gegevens verzamelen met behulp van kleine meetnetwerken en persoonlijke weerstations. Erosiemetingen en -preventie: Monitoring van preventieve maatregelen door landbouwers en het effect op erosie. Dit kan ook door luchtfoto’s of via directe input van de landbouwers zelf. Technologische Innovaties: Gebruik van 3D-scanning en LIDAR-technologie voor nauwkeurige terreinmetingen en volumebepalingen van sedimentophoping in erosiepoelen. Applicaties nodig Sirio control, predict --> verdere verwerking van metingen, datacombinatie de slimme analyses, het maken van voorspellingsmodellen (sumaqua in Leuven) Callibratiesoftware GPS (niet noodzakelijk) eerder via erosiepoelen posities Batterij-status Lokale opslag Sensorstatus Communicatiestatus Discussie Sirio Control en Predict Software: Deze bestaande software combineert diverse databronnen, zoals KMI-informatie en pijsensoren, om analyses te maken en voorspellingen te doen over waterhoogtes. Het kan ook batterijstatus lezen en alerts genereren. Uitbreiding naar Modderstromen: Hoewel Sirio oorspronkelijk voor waterhoogtes en overstromingen is ontwikkeld, is het potentieel uit te breiden voor gebruik bij modderstromen en sedimentbeheer. Kalibratie van Sensorgegevens: Kalibratie gebeurt meestal op de sensoren zelf, niet na het versturen van de gegevens. Applicaties voor kalibratiesoftware zijn belangrijk om ervoor te zorgen dat de metingen nauwkeurig blijven. Communicatie en Lokale Opslag: Communicatiesoftware zorgt ervoor dat de gegevens van sensoren efficiënt worden verzonden. Lokale opslag is belangrijk voor buffering en het bijhouden van data in geval van communicatiestoringen. GPS en Locatiebepaling: Hoewel GPS niet nauwkeurig genoeg is voor exacte puntmetingen binnen een erosiepoel, is het wel nuttig voor het lokaliseren van pluviometers en andere sensoren in het veld. GPS-coördinaten helpen bij het traceren van de posities van meetapparatuur. Kaartweergave en Sensorlocatie: Sirio biedt ook een kaartweergave waarin de locaties van sensoren kunnen worden weergegeven, wat helpt bij het beheren en visualiseren van meetpunten. Erosiepoelen Monitoring: De focus ligt op het monitoren van erosiepoelen, waarbij sensoren op strategische locaties worden geplaatst om data te verzamelen over water- en sedimentniveaus. Alerts en Beveiliging: Applicaties kunnen ook alarmsignalen genereren, bijvoorbeeld wanneer een sensor wordt gestolen of wanneer de batterijstatus laag is. GPS kan helpen bij het traceren van verloren of gestolen apparatuur. Integratie van Diverse Data Bronnen: Door verschillende databronnen, zoals weerinformatie, waterpeilgegevens, en lokale sensoren te combineren, kunnen applicaties zoals Sirio uitgebreide analyses en voorspellingen maken. Manuele Input van Landbouwers: Het is belangrijk dat landbouwers zelf informatie kunnen opladen of invoeren, wat een waardevolle aanvulling kan zijn op de automatische data die wordt verzameld. Functieprofielen Landbouwers Burgers? Vrijwilligers? Sensor specialist Erosie coördinator Erosie specialist Data engineer Data scientist Data specialist Landbouwadviseur Technieker installatie Onderhouds-technieker (sensor) Schepen landbouw/milieu.. Milieuambtenaar Omgevingsambtenaar Discussie Geen discussiepunten Oefening 3 Instructies Welke zijn de valkuilen waar we volgens jou rekening mee moeten houden? Formuleer enkele basisprincipes waaraan de oplossing moet voldoen Voorbeeld: - Bij het gebruik van sensor x moet je rekening houden met y. Alle sensoren die we voor deze problematiek willen gebruiken, moeten voldoen aan principe z Output Valkuilen Achtergebleven sediment moeilijk te meten Hoogte/peil meting verkeerd door plantengroei in de poel Kostprijs? Wie gaat betalen? Metingen stilstaand sediment vs sediment dat nog in suspensie is(?) Wie gaat onderhoud doen? Wie is verantwoordelijk? Turbiditeitssensor komt droog te staan (kan de sensor beschadigen) Wat als, ondanks erosiepoel, toch een modderstroom ontstaat? ondanks al die maatregelen komt er toch een modderstroom : credibliteit traject Verkeerde interpretatie gepubliceerde data door beleid en/of burgers Stroomvoorziening onvoldoende Risico vandalisme/ diefstal? Geen of slechte dataconnectie 'Doorbreken' Poel Overzichtelijkheid en leesbaarheid platform/ dashboard Te duur Discussie Hier zijn de samenvattende punten van de besproken valkuilen en uitdagingen: Hoogtemeting door Plantengroei: Plantengroei in de poel kan de hoogtemeting verstoren. Het systeem kan onterecht denken dat het waterpeil te hoog is door de begroeiing, wat tot onnodige alarmen kan leiden. Droogvallen van de Turbiditeitsensor: Als de turbiditeitsensor droog komt te staan, kan dit leiden tot defecten of beschadiging van de sensor. Moeilijkheid bij het Meten van Sediment: Het onderscheid maken tussen stilstaand sediment op de bodem en sediment dat nog in suspensie is, vormt een uitdaging. Kostprijs en Verantwoordelijkheid: De kosten kunnen hoog zijn, en het is cruciaal om duidelijk te definiëren wie verantwoordelijk is voor de financiering en het onderhoud van het systeem. Stroomvoorziening: Onvoldoende stroomvoorziening, bijvoorbeeld door een lege batterij of als iemand per ongeluk de stekker eruit trekt, kan problemen veroorzaken. Slechte Dataconnectie: Gebrek aan of slechte dataconnectie kan de betrouwbaarheid van het systeem beïnvloeden. Doorbreken van de Poel: De poel zelf kan doorbreken, wat niet gerelateerd is aan sediment maar aan de integriteit van de poelstructuur. Risico van Vandalisme en Diefstal: De sensoren kunnen beschadigd raken door vandalisme of per ongeluk door boeren die met hun tractor de sensoren raken. Verkeerde Interpretatie van Gepubliceerde Data: Gepubliceerde data kan verkeerd geïnterpreteerd worden door beleidsmakers en burgers, wat tot misverstanden kan leiden. Overzichtelijkheid en Leesbaarheid van het Platform: Het platform of dashboard moet overzichtelijk en leesbaar zijn om effectief gebruikt te kunnen worden. Ondanks Monitoring Toch Modderstroom: Als er ondanks monitoring toch een modderstroom ontstaat, kan dit de credibiliteit van het project schaden en toekomstige ondersteuning ondermijnen. Oefening 4 Instructies Hoe kunnen we de oplossing verduurzamen, rekening houdend dat we voor een bepaalde databron zouden kiezen? We doen een ‘realitycheck’. -Hoe houden we het budget onder controle? -Wat met ‘coverage’? Hoeveel sensoren heb ik nodig om een representatief beeld te krijgen? Is dit haalbaar en beheersbaar? -Uitbesteden vs zelf data capteren -Uitrol project in grotere regio -Hoe bouwen we een business model op hiermee? Output Verduurzaming 'Groepsaankoop' van de sensoren Raamovereenkomst => juridisch niet evident, want de steden of gemeenten moeten vermeld worden met inschatting van afneming : sta je er niet in met 'optin', dan kun je niet gebruik maken van die raamovereenkomst Hoe robuust zijn de sensoren? (zowel tegen schade alsook continuiteit van de 'kwaliteit') Jeroen Ampe : 'Vlaanderen', 'Antwerpen' zou voldoende zijn, of 'alle lokale besturen kunnen afnemen met die overeenkomst', maar inschatting van volumes moet er wel instaan Communicatieplan (templates) voor info aan burgers van betrokken gemeenten ==> Als onderdeel van dit project Burgerbetrekking: 'adopteer een poel', sensibilisering ownership moet heel duidelijk zijn + wie zijn afnemers Berekenen schade modderstromen vs preventiebudget (ROI en Payback) betrekken landbouwers (en belangen organisaties), verzekeringsmaatschappijen, burgers Data doorverkopen aan landbouwers Data doorverkopen aan verzekerings-maatschappijen (of korting op premie) Totaaloplossing (sensoren +platform + alarmering + onderhoud + ...) vs sensors only & integratie in reeds bestaande platformen van bv steden/gemeenten Discussie Duurzaamheid van het project Het doel is om het project te verduurzamen en te voorkomen dat het slechts een Proof of Concept blijft. Belangrijk om te leren van eerdere ervaringen en deze te integreren in een langetermijnproject. Financiering en budgettering Noodzaak om alternatieve sponsors te zoeken, zoals verzekeringsmaatschappijen. Manieren vinden om het budget onder controle te houden. Overweging of proxies van variabelen kunnen worden gebruikt in plaats van dure sensoren. Technische aspecten De noodzaak om te bepalen hoe uitgebreid sensoren moeten worden geplaatst. Overweging van groepsaankopen van sensoren om kosten te verlagen en kleine gemeenten te helpen. Raamovereenkomsten De juridische complexiteit van raamovereenkomsten, inclusief wie verantwoordelijk is voor aankopen (lokale besturen, provincies of Vlaanderen). De noodzaak om alle gemeenten en hun geschatte volume van afname op te nemen in de raamovereenkomst. Het verschil tussen het implementeren en benutten van een raamovereenkomst. Robuustheid van sensoren Sensoren moeten bestand zijn tegen fysieke schade en continuïteit van datakwaliteit behouden. Burgerbetrokkenheid Initiatieven zoals "Adopteer een Poel" om kosten te delen en burgers bij het project te betrekken. Het opstellen van een communicatieplan voor gemeenten om burgers te informeren en te sensibiliseren. Eigenaarsschap en databeheer Duidelijkheid over wie de afnemers van de data zijn. Berekening van de Return on Investment (ROI) en payback van het project. Betrokkenheid van belanghebbenden zoals landbouwers, verzekeringsmaatschappijen en burgers. Totale oplossing vs. modulaire aanpak Overweging om een totale oplossing te bieden van sensoren tot platform, versus het aanbieden van losse onderdelen die gemeenten zelf kunnen integreren in bestaande systemen. 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 Business werkgroep Business werkgroep 2024-02-29 13u30-16u30 Provinciehuis Leuven Thematische werkgroep 1 Data en informatie werkgroep 2024-03-19 9u-12u Teams Thematische werkgroep 2 Functionele werkgroep 2024-04-18 9u-12u Teams Thematische werkgroep 3 Technologie werkgroep 2024-05-23 9u-12u Teams +
Functionele werkgroep Deze thematische w … Functionele werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties . Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie- uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen. De tweede thematische werkgroep vond plaats op 16 mei 2024. Context Initiatief In samenwerking met Mobiliteit en Parkeren Antwerpen en de Stad Antwerpen werkt VLOCA (Vlaamse Open City Architectuur) samen met OSLO (Open Standaarden voor Linkende Organisaties) aan een City of Things project genaamd "Citerra". Citerra staat voor 'City Environmental Regulations and Rights for Access' voor steden, gemeenten, bedrijven, burgers, verenigingen en overheden , en heeft als doel de link te leggen tussen de genoemde stakeholders en de lokale regelgeving. Het doel van Citerra is om alle regelgevingen te centraliseren en te uniformeren, waarbij de aanvragen voor vergunningen kunnen worden ingediend. De focus van dit City of Things traject ligt op vergunningen voor autoluwe zones of gebieden met cameratoezicht. Hoewel de Stad Antwerpen het project leidt, is het de bedoeling om dit initiatief breder te zien richting alle lokale besturen. Op dit moment is de informatie over verschillende gereglementeerde zones in de stad niet goed georganiseerd, wat het voor burgers en bedrijven moeilijk maakt om te begrijpen welke regels waar van toepassing zijn. Het handmatig invullen van persoonlijke gegevens bij herhaalde aanvragen leidt ook tot frustratie. Om dit te verbeteren, streeft het project ernaar gebruikers zelf hun profiel te laten beheren, inclusief het toevoegen van extra nummerplaten, en om gegevens automatisch in te vullen bij nieuwe aanvragen. Bovendien voldoet het project aan de Europese Commissie Directive over "Intelligent Transport Systems" door steden te verplichten Urban Vehicle Access Rights (UVAR) data naar het Europese Platform te uploaden, wat geautomatiseerd zal verlopen. 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 De start van elk VLOCA-traject begint bij een VLOCA-model: ID Samenvatting Beschrijving UC1 UC1: Registratie Registratie UC2 UC2: Informatieplatform informatie platform en zoek opdrachten UC3 UC3: Profiel & Formulier aanvullen Profiel aan- en formulier invullen UC4 UC4: Indiening Indienen aanvraag UC5 UC5: Opvolging dossier opvolging dossier UC6 UC6: toekenningsproces toekenning, weigering, betwisting, advies aanvraag UC7 UC7: dossierbeheer beheer dossier (overzicht, toevoegingen, verlengingen, aanpassingen, herinneringen, …) UC8 UC8: Message Center CRM voor communicatie (uitgaande/inkomende, contact strategie en historiek) UC9 UC9: Helpdesk helpdesk & FAQ & Reviews UC10 UC10: betaalmodule betaalmodule en business model vinden en bouwen UC11 UC11: Monitoring Monitoring en analytische rapportering incl fraudedetectie UC12 UC12: Inzichten Rapporting BI Dashboards en Inzichten UC13 UC13: Duurzaamheid Van een piloot tot een 'operationeel' draaiende applicatie en platform Tijdens de vorige sessie bespraken we de onderstaande figuur die het proces weergeeft van het aanvraagformulier: Vandaag staan we stil bij het informatieplatform: Hierbij willen we scherp stellen wat de verwachtingen zijn over een platform. Brainstormsessie Het doel en de aanpak van de brainstormsessie worden hieronder beschreven. Tevens wordt de uitkomst van de brainstorm hierin samengevat. Doel Het doel van de brainstormsessie is het volgende: Zicht krijgen op welke data/informatie we nodig hebben om een antwoord te bieden aan de nood aan efficiëntie/tijdwinst en effectiviteit/optimalisering door middel van een centraal informatieplatform Oplijsten van databronnen waaruit je de informatie kan halen, welke applicaties en functieprofielen je nodig hebt Inzicht krijgen in wat je moet kunnen doen met de data Valkuilen identificeren Oefening 1+2 Instructies Bij deze oefeningen stonden we stil bij de volgende vragen: Welke data/informatie hebben we nodig om een antwoord te bieden aan de nood aan efficiëntie/tijdwinst en effectiviteit/optimalisering door middel van een centraal informatieplatform? Voorbeeld: - Wetgeving van lokale besturen 2. Uit welke databronnen haal je deze informatie? Welke data is reeds beschikbaar (gratis of betalend)? Welke moeten we zelf gaan verzamelen? Hoe doen we dit? Welke applicaties (tools die je gaat gebruiken) heb je nodig om de databronnen te sturen/ondersteunen? Welke functieprofielen heb je hiervoor nodig? Voorbeeld: - Wetgeving van een lokaal bestuur bevindt zich in een lokaal intern systeem Output Data Databronnen Applicaties/tools Functieprofielen Bestaande vergunningen Standardisatie model/Uitbreidingen huidig model: voorwaarde van een goeie databron OSLO vendors/applicaties van de gemeenten: veel vendors van de gemeentes hebben deze info al gepubliceerd (assumptie) data hoe wordt omgegaan met oa. hulp diensten / stad gemeenten (zit in de reglementen) publicaties gemeentes (www) loket.lokaalbestur modelleerder met kennis besluiten / reglementen / OSLO welke steden hebben welke vergunningen vergunningenlijst per lok. bestuur centrale vindplaats: applicaties die info en besluiten van de verschillende gemeentes centralisseerd ( lopend traject) - lokale gemeentes zouden dit ook kunnen gebruiken en minder zwaar ipv API individueel maar er blijven beperkte API's juridische dienst - LB-en Contact gegevens van steden en gemeenten Besluiten/Regelgeving LDES: data ter beschikking stellen, op verchillende manieren query end point. Zorgt data data kan doorstromen Mobiliteits dienst - LB-en welke steden hebben welke systemen voor handhaving: steden hebben verdwijnpalen, andere gebruiken polities enzo - Kan ook zijn dat je badge nodig hebt naast vergunning LPDC: Vlaanderen (catalagus def per gemeente) agile team: po, pm, analist, dev,...) regels/voorwaarden voor vergunning/stad CRAB: adrespunt bepalen binnen polygoon Bouwblokken waarmee oslo data worden gestuurd - door digitaal vlaanderen ontwikkeld business user (lokaal bestuur) GIS informatie autoluwe zones GIS databronnen: polygonen, sommigen straten vallen er net in of uit -> validatie OSLO team standaard government venstertijden: ter info als je geen vergunning nodig hebt want je kan uw houden aan de venstertijden eGOV? - Wallet Vrijer manier om data te consumeren Leveranciers aanvraagsystemen: integraties en koppeling voorzien welke steden hebben autoluwe zones DIV (voertuigen) via MAGDA Beheerder/stad waar liggen de autoluwe zones Adressenregister /CRAB Database gaat reproduceren bij wijzigingen automatisch. bv adressen enkel de wijzigen krijg je door zonder API call IT verantwoordelijke voor support EID/ITSme MAGDA Beheerder overkoepelend Ondernemersloket RRN via Magda IT20/IT19 (rijksregister op basis hiervan krijg je de domicile en huis) testusergroup Burgerprofiel KBO via Magda Kostprijs om vergunning aan te vragen soc. nr en geldigheid zorgverstrekker VIA MAGDA (automatische vergunningen) Burgerprofiel op header/notificatie / document niveau: aanvraag moet door goedkeuringproces ze een notificatie krijgen voor status en vergunning wordt opgeladen bij akkoord wat kost een vergunning? Vlaamse codex SOLID? Persoonlijke data kluis -> gdpr -> Aligneren met die vlaamse bouwblok Alternatieve Routes: visuele tip LBLOD gepubliceerde reglementen en besluiten (lokale belsuiten - machine leesbare kijken naar standaard - per bestuur gepubliceerd en Vlaanderen gaat dit ook verzamelen ) Simulatie tool Informatie in verschillende talen RIZIV standaardisering Overzicht regelgeving over gans Vlaanderen van de verschillende steden , europese, vlaamse, ... (Vlaamse codex) DIV (via magda) Citerra simulatie van wat wel of niet mag na invoering van tijd en plaats - op basis van aangegeven tijstip en locatie de relevante info krijgen signalisatie plan: voetgangersgebied - borden laten besluiten in gemeenteraad. Eersta stap om tot besluit komen waar komen de borden -> automatisch besluit Machine readable policy: beleidsmatig best vertaald worden naar regels die door computer vertaald kunnen worden Doorlooptijd aanvrager + VTEs (volgorde van belangrijkheid voor process automatisatie te bepalen - werkkracht die achter een bepaald proces moeten worden gezet => om zo makkelijk te zien waar je tijdswinst kan halen door optimaliseren of automatiseren) overheid Visualiseren op basis van signalisatieplan (impact autoluwe zone) - maar vergunning pas toegekend als werken zijn uitgevoerd Toegang voor derde partijen zoals navigatie applicaties lokale vergunningen Abstracties database (voor kleinere steden/gemeentes niet makkelijk om API te voorzien) federaal? -> binnen ABB bezig om dit bechikbaar te maken voor lokale besturen . Lokale bron voor kleinere steden & geconnecteerde delen (bv bewonersparkeren aantal vergunning is dynamsich - afhankelijk van de bewoners moet er parking voorzien worden en kan er geen vrije bewonerskaarten meer voorzien worden voor de bewoners van het app, bouwheer moet parking voorzien vooe gebouw ) identificeren -> automatisatie FOD FAS dummy aanvraagmodule: veel mensen willen oefenen voor ze een aanvraag officieel indienen. Kan ook via video's authenticatie / authorisatie heb ik eigenlijk wel een vergunning nodig? of ben ik vrijgesteld? data space soorten vergunningen mobiliteit Aanvraag via nummerplaat of op aanvrager opvolgen? regel Wat is kost retributie bij handhaving Bulkaanvragen op basis van Asterix nummerplaten ( vaste serie van nummerplaten zoals politie bv) voertuiggegevens Discussie Besluitvorming over Vergunningen: Vaststellen van criteria voor vergunningsverlening en hoe deze criteria toe te passen om eerlijke en consistente beslissingen te waarborgen. Handhaving van Autoluwe Zones: Effectieve methoden voor handhaving, inclusief technologische systemen en menselijke handhaving, en hoe deze het beste kunnen worden geïmplementeerd en gecoördineerd. Automatisering van Aanvraagprocessen: Verminderen van administratieve lasten door het automatiseren van aanvraagprocessen en het verkennen van mogelijkheden voor efficiënte en gebruikersvriendelijke systemen. Toegang voor Derde Partijen: Overwegingen omvatten hoe informatie over autoluwe zones beschikbaar kan worden gesteld aan derde partijen zoals navigatie-apps, met aandacht voor privacy en veiligheid. Gebruiksvriendelijkheid van Aanvraagprocessen: Discussie focust op het verbeteren van de gebruiksvriendelijkheid van aanvraagprocessen om de drempel voor aanvragers te verlagen, mogelijk door middel van begeleiding en ondersteuning. Automatische Goedkeuring en Weigering van Vergunningen: Overwegingen betreffen de criteria en procedures voor automatische goedkeuring of weigering van vergunningen, en hoe dit kan bijdragen aan een efficiënter proces. Uniformiteit en Standaardisatie: Bespreking van de voordelen en uitdagingen van het standaardiseren van processen en informatie over autoluwe zones voor alle steden en gemeenten in Vlaanderen. Uitzonderingen en Flexibiliteit: Behandelen van uitzonderingen op het vergunningsbeleid en het integreren van flexibiliteit om maatwerk mogelijk te maken voor specifieke situaties. Noodzakelijke Databronnen: Er werd gesproken over het identificeren van databronnen die nodig zijn voor het vergunningenaanvraagproces, zoals gemeentewebsites, LBD (Lokale Producten Catalogus), Gis (Geografisch Informatiesysteem), e-government, Rijksregister, KBO (Kruispuntbank van Ondernemingen), CP (Contactpunt), etc. Automatisering van Vergunningsaanvragen: Er was discussie over het automatiseren van vergunningsaanvragen en hoe dit kan worden ondersteund door relevante databronnen, zoals het gebruik van machineleesbare besluiten en standaardisatie van processen. Signalisatieplannen en Besluitvorming: Er werd opgemerkt dat signalisatieplannen belangrijk zijn voor het bepalen van autoluwe zones en dat deze informatie moet worden gekoppeld aan besluitvormingsprocessen voor vergunningen. Lokale versus Federaal Databeheer: Er was discussie over het verschil in benadering tussen grote steden en kleinere gemeenten wat betreft het beheer van lokale vergunningendatabases en de mogelijke rol van federale instanties in het faciliteren van toegang tot deze data. Datamodellen en Lokale Centrales: Er werd gesproken over het ontwikkelen van datamodellen en lokale centrales om kleinere gemeenten toegang te geven tot relevante informatie, met een focus op het delen van gegevens tussen verschillende niveaus van bestuur. Applicaties en tools voor gegevensbeheer: Er wordt gesproken over verschillende tools en applicaties die worden gebruikt om gegevens te ondersteunen en te sturen, zoals Eldes voor linked data event streams. Centrale vindplaats voor informatie: Deze applicatie is bedoeld om informatie over besluiten van verschillende gemeenten te centraliseren en beschikbaar te stellen voor machines, mogelijk met behulp van gestandaardiseerde protocollen. Vendors en gemeentelijke applicaties: Er wordt verwezen naar de applicaties van zowel externe leveranciers als de gemeenten zelf, die mogelijk al informatie publiceren op gestandaardiseerde wijze. Gebruik van API's en centrale vindplaats: Er wordt besproken hoe een centrale vindplaats het gebruik van API's kan verminderen, maar toch mogelijk nog beperkte API-functionaliteit vereist voor specifieke taken. Burgerprofiel en notificaties: Er wordt gesproken over het gebruik van burgerprofielen en notificaties voor statusupdates van aanvragen of dossiers. Solid en persoonlijke datakluis: Er wordt overwogen hoe Solid en persoonlijke datakluisconcepten kunnen worden toegepast op de behandeling van persoonsgegevens, met inachtneming van GDPR-vereisten. Simulatietool en standaardisering: Er wordt gesproken over het gebruik van simulatietools en het belang van standaardisering in het proces. Oefening 3 Instructies Wat moet je kunnen doen met de data? Welke acties kan je identificeren qua databeheer? Voorbeeld: -Je brengt de wetgeving van de verschillende lokale besturen samen Output Databeheer & integratie overschrijven van unieke bron gegevens (met label aangepast): bv domicile manueel overschrijven en aangeven dat dit niet een authentieke bron maar nieuwe info is leesbare_txt generieke info_txt Voorwaarden_txt_xml Couleurlocal_parameters_txt_xml Attesten.pdf_xml types data die beschikbaar moeten zijn en samengevoegd moeten worden in een formulier samenvoegen van data in formulier en dan alles samen doorsturen. 1 API met alle mogelijke velden maar niet alles noodzakelijk ingevuld afh van vereisten stad ( 1 API met alle mogelijke velden (moet niet allemaal ingevuld zijn) en niet per leverancier) beheren van aanvragen en vergunningen (hergebruiken/editeren en deleten of archive) verlengen van aanvraag/vergunning oslo datamodel bestaande data capteren: 3 elementen door slimme lokaal bron te genereren bestaande data gestandaardiseerd herbruikbaar delen een omgeving waar lokale data aangemeld kan worden ifv citerra: verschillende toepassingen waar de vergunningen zitten ter beschikking stellen aan citerra (data vindplaats) besluitdata vertalen in machineleesbare data (verdere detaillering Voertuigen, 200 numemrplaat aanvragen leveranciers registreren in Citerra of op vind plaats zelf? Mogelijkheden * Behouden in applicaties en opvragen * Centraal behouden Citerra * uploaden wallet, solid * Ondernemersloket * Rechstreeks in eigen erp van leveranciers Bulk aanvragen in XML Bulkoplading moet mogelijk zijn bewaren van data voor meerdere aanvragen/opnieuw aanvragen van vergunning gemeente moet business rules kunnen updaten tijdelijk bewaren van data/onafgewerkte aanvraag payment gateway: centraal systeem betalingen - hoe 1 keer afrekening en juist doorbetale,n naar de verschillende steden, diensten QA (quality assurance) Data ownership ( bewerkingen die gebeuren moeten gelinkt worden aan de bewerker -> welke stad dienst heeft vergunning geweigerd: transparentie & opvolging) CMS met sync naar dependent & dependencies: vanuit centrale platform vergunning aangevraagd worden, zal er iets van database aan dit platform en sync moeten zitten/ BV leverancier en je moet door de 2 zones rijden, eerste goedkeuring en tweede weigering -> relevante info moet terug komen van 1 van de vragen. Dus er moet een link zijn - om de link te houden => Duidelijk vermelden aan aanvrager om dit mee te delen valideren volgens het data model (SHACL): als gemeente iets pubiceerd dans moet je nakijken of data correct is. tergukoppeling indieen validatie faalt Discussie Definiëren van benodigde data en acties: De discussie richtte zich op het identificeren van alle relevante data en acties die nodig zijn voor het informatieplatform. Beheren en hergebruiken van aanvragen en vergunningen: Gesprek over de benodigde functionaliteit voor het beheren van aanvragen en vergunningen, inclusief opties zoals aanpassen, verwijderen en archiveren. Integreren van verschillende soorten data: Overwegingen bij het integreren van diverse data in formulieren en het gebruik van een centrale API voor gegevensverzending. Valideren van data volgens een bekend datamodel: De discussie betrof het valideren van data volgens een vastgesteld datamodel dat consistent is voor lokale besturen. Vaststellen van data-eigenaarschap: Gesprek over wie verantwoordelijk is voor de data die op het platform staat om duidelijkheid te scheppen over verantwoordelijkheden. Opzetten van een payment gateway: Overwegingen bij het implementeren van een payment gateway voor efficiënte betalingen bij vergunningsaanvragen. Thematische vergunningsconcept van de Vlaamse overheid: Bespreking van het concept van thematische vergunningen en hoe dit kan worden toegepast voor automatische identificatie van vereiste vergunningen bij verschillende verplaatsingen. Overwegen van verschillende benaderingen voor authenticatie: Discussie over de mogelijke benaderingen voor authenticatie, met de nadruk op HTTP-technologie als een mogelijke optie met externe systemen. Oefening 4 Instructies Hoe gaan we om met de verschuiving van aanvragen die rechtstreeks verlopen via de website van de lokale besturen naar een overkoepelend medium? Wat zijn mogelijke valkuilen? Voorbeeld: - Integratie van verschillende systemen en databronnen kan technisch uitdagend zijn - Financiering verdeling over de verschillende lokale besturen Output Valkuilen teveel couleur locale, te weinig standaardisatie LLM (language model - machine leesbaar) is geen oplossing, kan als hulpmiddel gebruikt maar niet als tool, validator zelf AI voor reglementen kan een mw zijn , nog onderzoeken wat de mogelikheden zijn 'lokale invulling' vs automatisatie en kost: hoe meer vrijheid dat je toelaat hoe minder kans tot automatisatie waar trek je de lijn Scope Vlaanderen is beperkt (subsidie), generiek maken door bv aanvrager geeft aan of hij/zij al dan niet Vlaams is gesloten platform?: nog niet duidelijk of er 1 platform wordt gebouwd voor heel Vlaanderen of worden alle blouwblokken ter beschikking gesteld. Open platform waar iedreen kan integreren. Scope nog niet duidelijk Toeliching: scope autoluwe zone, nog open of het 1 platform wordt, platform waat alle vergunningen naast elkaar staan en 1 specifieke kunt aanvragen voor autoluwezone. Breder maken nog geen zicht maar mogelijkheden niet starten met een duidelijke scope en timing voor poc uptime platform moet maximaal zijn: moet kunnen voldoen aan piekdagen/uren als zondag bv integriteit van de databronnen niet-schaalbaarheid naar andere use-cases aanpassingen LPDC ivm parametrisatie door Vlaanderen nodig: hoeveel nummerplaten aanvragen per burger bv in een generieke formulier ztten dat kan ingevuld zijn per stad/gemeentes. Nu zijn het enkel tekstvelden nu niet beschikbaar Governance voor duurzaamheid van platform te vaak dynamische aanpassingen nodig nadien / stabiliteit : niet te veel wijzigingen in regels van steden te moeilijk dus eigen websites blijven: formulier te complex -> dan gaan ze toch naar de algemene stad site en gaat het niet gebruikt worden ( vraag komt van ondernemingen) stad/gemeente of leverancier van aanvraagsysteem die niet wil meedoen niet alle steden en gemeentes hebben een aanvraagsysteem Uitsluiting van bepaalde steden geeft minder waarde aan dit project cyber security financiering bouw of business model Uitdagingen: Datamodel, intelligentie van data iedereen meekrijgen commerci le belangen vs open data: veel bronnen aangehaald en deel ervan zijn open data of worden open data -> commerciele spelers meekrijgen. bv Parking die in autoluwe zone ligt lokale specificiteit vs generieke regelgeving opsec: operational security. End points voorzien voor handhaving voor ophalen en syncen van vergunningen gaan bepaalde zaken publiek zijn. bv qr code waar persoon makkelijk kan nagaan - OPSEC is deel waar wordt gekeken dat er info ook niet ge-expoded kan zijn. Info die je niet met concurrentie wilt delen onderhoudskost Discussie Lokale invulling versus automatisatie: Hoe lokale aanpassingen de automatisatie kunnen belemmeren omdat standaardisatie moeilijker wordt. Dit kan leiden tot hogere kosten voor automatisering. Scope van het platform: Er is onduidelijkheid over de reikwijdte van het platform. Moet het een centraal platform zijn voor alle vergunningsaanvragen in Vlaanderen, of eerder een open platform waar verschillende integratoren en oplossingen kunnen worden gebruikt? Financiering en businessmodel: Hoe wordt de financiering verdeeld en wat is het businessmodel voor de verschillende spelers? Dit omvat ook de vraag of het platform commerciële belangen moet dienen of juist moet focussen op open data. Integratie en schaalbaarheid: Het platform moet niet alleen voor autoluwe zones werken, maar ook schaalbaar zijn voor andere vergunningsaanvragen en gebruiksscenario's. Operationele veiligheid: Zorgen over de beveiliging van endpoints en het voorkomen van onbedoelde blootstelling van gevoelige informatie, zoals wie welke vergunningen aanvraagt. Governance en duurzaamheid: Het creëren van een duurzaam governancemodel voor het platform en ervoor zorgen dat het platform dynamische aanpassingen kan doorvoeren zonder de stabiliteit in gevaar te brengen. Inclusiviteit en acceptatie: Het belang van het betrekken van alle belanghebbenden om de waarde van het platform te maximaliseren en ervoor te zorgen dat het breed wordt geaccepteerd en gebruikt. 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 Business werkgroep Business werkgroep 2024-02-27 13u-16u VAC Antwerpen Thematische werkgroep 1 Data en informatie werkgroep 2024-03-28 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-05-16 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-06-25 13u-16u Teams +
Functionele werkgroep Deze thematische we … Functionele werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties . Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie- uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen. De Werkgroep Data en Informatie staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen de data- en informatienoden in kaart brengen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen.Heb jij interesse, specifieke noden, expertise of andere belangen bij dit traject? Klik hier om je in te schrijven. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-03-21 10u-13u VAC Brugge Thematische werkgroep 1 Data en informatie werkgroep 2024-05-21 9u-12u Teams Thematische werkgroep 2 Functionele werkgroep 2024-06-18 9u-12u Teamsctionele werkgroep 2024-06-18 9u-12u Teams +
Functionele werkgroep Deze thematische we … Functionele werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties . Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie- uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen. De Werkgroep Data en Informatie staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen de data- en informatienoden in kaart brengen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen.Heb jij interesse, specifieke noden, expertise of andere belangen bij dit traject? Klik hier om je in te schrijven. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-09-10 9u-12u VAC Brugge Thematische werkgroep 1 Data en informatie werkgroep 2024-10-10 9u-12u Teams Thematische werkgroep 2 Functionele werkgroep 2024-11-05 9u-12u Teams Thematische werkgroep 3 Technologie werkgroep 2024-12-03 9u-12u Teamshnologie werkgroep 2024-12-03 9u-12u Teams +
Functionele werkgroep Deze thematische we … Functionele werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties . Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie- uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen. De Werkgroep Data en Informatie staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen de data- en informatienoden in kaart brengen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen.Heb jij interesse, specifieke noden, expertise of andere belangen bij dit traject? Klik hier om je in te schrijven. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-09-26 13u-16u VAC Leuven Thematische werkgroep 1 Data en informatie werkgroep 2024-10-21 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-11-21 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-12-19 13u-16u Teamsnologie werkgroep 2024-12-19 13u-16u Teams +
Functionele werkgroep Deze thematische we … Functionele werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties . Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie- uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen. De Functionele werkgroep vond plaats op 08 november 2023. Deelnemers Organisatie Deelnemer Agentschap Binnenlands Bestuur (VLOCA) Laurien Renders Alain Glickman Stad Mechelen Sandrine Raskin Jos Van Loock The Retail Factory Luc Van Rompaey Stad Leuven Bo Peeters Proximus Jasper Botterman POM West-Vlaanderen Frederik Sack Provincie Oost-Vlaanderen Fieremans Pieter-Jan Economisch Huis Oostende Joke Van Gheluwe Bjorn Pintelon ViNotion Azem Kariman Provincie Vlaams-Brabant Ruben Van de Voorde Visit Leuven Stijn Anthoons Aanleiding en Context Initiatief Er zijn momenteel twee projecten met vergelijkbare opzet: SInCR, gericht op grotere steden, en DAKS 2.0, bedoeld voor kleinere steden. Beide projecten hebben als hoofddoel om data in te zetten ter ondersteuning van zowel handelaars en ondernemers als beleidsmakers, waarbij deze twee doelgroepen verschillende behoeften hebben. De onderzoeksvragen die deze projecten proberen te beantwoorden, zijn gevarieerd. Ten eerste, hoe kunnen we het effect van beleidsmaatregelen en georganiseerde evenementen op het winkelgebied meten? Dit omvat onderwerpen zoals acquisitiebeleid, de evaluatie van acties en evenementen, en mobiliteits- en parkeerbeleid. Een andere belangrijke vraag is hoe we data breder en slimmer kunnen inzetten ter ondersteuning van beleid en ondernemers. Hierbij gaat het om het benutten van data op een meer strategische en effectieve manier. Daarnaast streven deze projecten ernaar om een duurzame samenwerking op te zetten waarbij alle betrokken partijen meerwaarde ervaren. SInCR en DAKS 2.0 zijn voortzettingen van het project 'Datagestuurde Winkelgebieden', waarbij prototypes zijn ontwikkeld, zoals een handelaarsdashboard en een generiek beleidsdashboard op basis van gegevens over drukte, bestedingen, evenementen en weer. Dit heeft enkele uitdagingen en kansen aan het licht gebracht die in SInCR en DAKS 2.0 zullen worden aangepakt: Momentum rond retail data behouden na afloop lopende projecten Kapitaliseren opgebouwde kennis & beperkte datamaturiteit bij handelaars en steden verder opbouwen Beperkte scope en doorlooptijd subsidieprojecten 🡪 scope verbreden Afhankelijkheid van de leveranciers beperken 🡪 datadeling & standaardisering (OSLO & VLOCA) Wildgroei aan platformen 🡪 generiek overkoepelende oplossing: standaardisatie & deelbaarheid maximaal hergebruik en interoperabiliteit Draagvlak handelaars vergroten 🡪 bevragen, leerlessen valideren en coachen Opmaak business- & governance model Binnen DAKS 2.0 zijn er drie belangrijke focusgebieden: acquisitie & passantenmetingen, de impact van parkeer- en mobiliteitsbeleid, en acties en evenementen. Deze drie onderwerpen zullen worden meegenomen in de ontwikkeling van de OSLO Lokale Economie-standaard en de VLOCA architectuurstandaarden. Andere onderwerpen zoals leegstand, e-commerce, duurzaamheid en energie, kunnen afhankelijk van hun belang voor de verschillende doelgroepen eveneens meegenomen worden in dit traject. Hoewel het wellicht niet haalbaar is om op alle thema’s grondig in te gaan in dit traject. 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. Samenvatting vorige werkgroep Het verslag van de business werkgroep kan je hier terugvinden. Doel van huidige werkgroep Introductie geven over het project Toelichting geven over VLOCA Brainstormen over functionaliteiten Brainstormsessie Aanpak Op basis van de vorige werkgroep hebben we een aantal thema's kunnen identificeren die belangrijk geacht worden voor dit project: Mobiliteit Parkeren Profiel passanten Verzorgingsgebied Imago Autoluw maken van bepaalde zones Voor deze projecten (SINCR en DAKS 2.0) kunnen we 3 soorten afnemers onderscheiden: Beleidsmakers (het beleid) Retail De initiatiefnemers zelf Voor deze werkgroep focussen we op de impact op het beleid. Wat wordt er precies verwacht van de deelnemers aan deze werkgroep? Functionaliteiten oplijsten Functieprofielen oplijsten Valkuilen en successen identificeren Oefening 1 Wat zijn de voorwaarden om iets goed af te leveren aan ‘het beleid’? Hierbij kunnen we 3 fasen onderscheiden: Data management (verzamelen, verwerken, ontsluiten) Integratie (data bij elkaar brengen) en analyse Inzichten leveren aan beleid - data kiezen - data kopen - data verwerken - toegang geven tot rapporten => dit zijn allemaal acties Voorbeeld: - Om aan data te geraken moet ik ze kopen bij een kwaliteitsvolle leverancier of zelf gaan verzamelen - We moeten het beleid kunnen overtuigen met data om de evenementenkalender te optimaliseren Oefening 2 Welke functieprofielen/rollen heb ik nodig? Voorbeeld: - om te kunnen overtuigen heb je een business analist nodig om te motiveren waarom de kalender moet aangepast worden en welke positieve resultaten dit zal hebben - om aan de slag te gaan met de data heb je een data analist nodig Oefening 3 Welke valkuilen kunnen opduiken? Voorbeeld: - data analisten vinden is moeilijk - software is duur en valt niet binnen budget Oefening 4 Wat zal tot een succes leiden? Welke prioriteiten leggen we? Voorbeeld: - overtuigen van beleid om evenementenkalender aan te passen - overtuigen van beleid om al dan niet autoluwe zone in te voeren Uitkomst De input van de deelnemers werd gecapteerd in dit Miro bord . Functieprofielen/rollen Data management Integratie en analyse Inzichten leveren aan beleid Valkuilen Successen Startpunt vertrekt vanuit de diensten zelf en hun noden - pas daarna worden de data teams betrokken Verkeerde interpretatie van het beleid op data Datagedreven evenementen kalender dankzij dit traject datamanager Data koppeling met andere systemen Push mail met analyse/overzichten naar beleid publiek maken van data zonder een juiste kadering van de definities het beleid kan leegstand terugdringen door aantoonbare passage van klanten Platform : om het rapport die we wensen op te vragen Presentatie via powerpoint verschillende bronnen spreken elkaar tegen Kan bijdragen tot RUP (Ruimtelijk UitvoeringsPlan) E n login voor alle data via n platform selectie grafieken/visualisaties Dynamische/Automatische rapportering Security lek Afstemming tussen (beleid)departementen doormiddel van data monitoringshub, (meldingen bij gemiste data instanties via een set van regels), keep alive functie keuze van welke resultaten we willen tonen gebruiks- vriendelijke dashboarden Kostprijs Publiek beschikbaar maken van data (mits goede omkadering) Data analist Data Opkuisen Voor en Na Analyse vertalen van inzichten op basis van kernvragen financi le impact op budget Niet meer blind varen databron toegangsauthorisatie toekomstprojecties (prognoses, forecasting) ruwe data pushen voor post analyse Duurzaamheid van databron op de LT Objectieve evaluaties Update historiek gepaste aggregatie niveaus aanmaken geautomatiseerde rapportage Verandering in de datadefinitie activiteiten logging in database nulmeting/baseline keuze; gaan we 1 sensor inzetten voor multimodaal verkeersbeeld? voordeel is vergelijkwaardigheid vanuit 1 bron of meerdere sensorieken aansluiten op dashboard Cijfers naar je hand zetten - datamanipulatie Lineage Bepalen van de data YoY, MoM maatwerk mogelijkheden in de vorm van aanvullende analyses zoals trigger based drempelwaarden rapportage, paniekdetectie, gedrag, etc bezettingsgraad Datamaturiteit van het beleid, de gebruikers data anonimisaie (metadatatering en beveiliging) Brute force bijv. data platform aanbieden met extra fuctionaliteiten (AI, predictie, ...) Sensoren en leveranciers die aantoonbaar gegevensbescherming op orde hebben (ISO 27001) Te veel data - bomen door het bos niet meer zien Databronnen verkennen en zoeken naar de linken Keuze hoe bevragen we meerdere sensoren in het veld? (representativiteit, analytisch) Correct begrip van de data en wat ze lezen in het rapport of presentatie Te brede scope - must have vs nice to have Data relaties datamodel opbouwen beheren van toegangen tot platform Afhankelijkheid van leveranciers Data scientist Data structureren trends detecteren automatische rapporten op verschillende detailniveaus Geen targets defini ren Data fusie voorspellingen data newsflash bestuurlijke dekking niet verkrijgen of tegenstand burger (om sensoren te plaatsen) Data transformeren Nieuwe databonne detecteren, nieuwe verbanden of nulmeting Eenvoudige dsahboards verkeerde data uitvraag (verkeerde sql query) Data verrijken (verschillende bronnen, of extra attributen) oorzaak - gevolg Rapport of dashboard complexiteit API-vriendelijk/open structuur meest kwaliteitsvolle bron weerhouden voor de use case validatie van data (periodiek) business model afspraken maken rond definities en data structuur (communiceren) verantwoordelijkheid (gedeelde verantwoordelijk, wie is eindverantwoordelijk voor platform, enz.) scalable data storage afwijken van de standaardisatie access management Geen duiding/begeleiding bij gebruik dashboard BI expert Data standardisering Keuze maken tussen maatwerk dashboard of bestaand back end systeem. Verzorgen van Integratie en API standaarden Te veel verschillendei interpretaties Data engineer keuze locatie processing, fysieke geografische data opslag, (afhankelijk van aanwezige infrastructuur, beveiligingsnormen) Andere prioriteiten Legal counsel Verschillende datastromen aan elkaar koppelen binnen n omgeving Dataverhaal is soms 'on top' en niet ingebed DWH specialist Data methodologie (definities, begrippen,...) Definities en omschrijving van de data Data architect Benchmarking Dienst economie : eerste contactpunt met linken mobiliteit en toerisme en smart city,...) linken tussen de data op time / day Privacy Officer / GDPR dossier Data connecteren vergunnings ambtenaar (toestemming om sensoren te plaatsen) uitvoeringsambtenaar (die de sensoren plaatsen of gebruiken bvb) Vraag & antwoord en volgende stappen Vragen Opname De opname van deze sessie is te bekijken via deze link . Volgende werkgroepen Indien u graag zou willen deelnemen aan één van de aankomende werkgroepen, kan u via de onderstaande link een overzicht van de workshops terugvinden. Inschrijven kan door te klikken op een van de werkgroepen. De derde en laatste thematische werkgroep zal plaatsvinden op 7 december om 13u via Teams. Inschrijvingslink: VLOCA-Lokale economie . Heb jij interesse, specifieke noden, expertise of andere belangen bij dit traject? Klik hier om je in te schrijven. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2023-09-19 VAC Gent Thematische werkgroep 1 Data en informatie werkgroep 2023-10-10 09:00-12:00 Teams Thematische werkgroep 2 Functionele werkgroep 2023-11-08 Teams Thematische werkgroep 3 Technologie werkgroep 2023-12-07 13u-16u Teams +
Functionele werkgroep Deze thematische we … Functionele werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties . Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie- uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen. De Functionele werkgroep vond plaats op 19 december 2023. Deelnemers Organisatie Deelnemer Agentschap Binnenlands Bestuur (VLOCA) Laurien Renders Alain Glickman Intercommunale Leiedal Lucas Verbanck Inge Wydhooge Thomas Goemaere Stad Gent Jan Godderis Kim Paduwat Dieter Nieuwborg District09 Ann Bernaert Provincie West-Vlaanderen Wim Beerten GIM An Heirman ESRI Belux Gert Bergers Departement Omgeving Stijn Vanderheiden Kenniscentrum Vlaamse steden Joris Voets 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. 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. Samenvatting vorige werkgroep Het verslag van de data en informatie werkgroep kan je hier terugvinden. Doel huidige werkgroep Introductie geven over het project Toelichting geven over VLOCA Brainstormen over functionaliteiten Brainstormsessie Theorie Bovenstaand schema is een visualisatie van de oplossing met alle bouwstenen en bedrijfsprocessen. Om te beginnen werd toegelicht wat een bedrijfsproces precies inhoudt: Wat? Een bedrijfsproces is een serie stappen, taken of acties die een organisatie doet om een specifiek doel te bereiken. Het is als een georganiseerde to-do lijst voor de hele organisatie. Deze processen helpen bedrijven om dingen op een efficiënte en effectieve manier te doen, waardoor ze hun doelen kunnen bereiken. Bijvoorbeeld, het proces van het maken van een product, het afhandelen van bestellingen, of het regelen van financiële zaken zijn allemaal voorbeelden van bedrijfsprocessen. Het idee is om dingen op een gestructureerde manier te doen om het werk soepeler te laten verlopen. Waarom? Een business proces beschrijven gaat helpen om de juiste software/hardware (bvb sensor) te kiezen om digitalisering en/of automatisering van het werk dat een omgevingsambtenaar doet, mogelijk te maken. Dan werd het schema toegelicht met een visualisatie van de acties binnen de business processen. De linkerkant betreft de databronnen die tijdens de vorige werkgroep behandeld werden. In het midden zien we de verschillende indicatoren en wat we hiermee precies kunnen doen: Per indicator (bvb voorzieningen, verharding, bebouwing) voor het beoordelen en plannen van ruimtelijke ordening gebeuren er berekeningen, ontsluiten van data, beschermen etc. •Enkele voorbeelden: Voorzieningen Verharding V/T index Bebouwing Groencapaciteit Bevolkingsaantal => op elk van deze indicatoren kan een analyse/bewerking gebeuren bvb De afstand bepalen van punt x tot voorziening y Een evolutie vaststellen doorheen de tijd mbt verharding Een visualisatie maken van de groencapaciteit Aan de rechterkant van het schema worden de verschillende gebruikers weergegeven met een aantal acties die zij kunnen doen met de data. Aanpak Tijdens de brainstorm gaan we: De werkwoorden/acties oplijsten en beschrijven Bekijken wat nodig is om de acties te automatiseren en/of digitaliseren Valkuilen identificeren Oefeningen Oefening 1: werkwoorden/acties oplijsten Identificeer en beschrijf de acties nodig om het business process te beschrijven. Voorbeeld: Meten Evalueren Vergelijken Analyseren => dit zijn allemaal acties die we zouden kunnen digitaliseren Voorbeeld: Om zicht te krijgen op tekorten aan basisscholen/parken/kinderopvang op een bepaalde locatie moeten we de ligging/capaciteit/... van deze voorzieningen verzamelen, de bereikbaarheid en bezettingsgraad berekenen en vergelijken met andere buurten zodat we kunnen analyseren welke last we bij een bouwproject opleggen. Oefening 2: wat hebben we nodig om de acties te automatiseren en/of digitaliseren Zijn de voorgestelde acties digitaliseerbaar? Automatiseerbaar? Hoe denk je dat dit realiseerbaar is? Voorbeeld: •Ligging/capaciteit/... van scholen/parken/kinderopvang ophalen via API's •Afstand berekenen tussen een woonwijk en omliggende parken aan de hand van ligging en wegennetwerk Oefening 3: valkuilen identificeren Met de input die we ontvangen hebben kunnen we business processen en bijhorende applicatiecomponenten beschrijven. Welke zijn de valkuilen waar we volgens jou rekening mee moeten houden? Voorbeeld: Privacy-gevoelige data inwoners Capaciteit scholen niet beschikbaar Scholen waarbij leerjaren gespreid zijn over verschillende vestingen Outcome Werkwoorden/acties Beschrijving acties Hoe digitaliseren/automatiseren Valkuilen Meten Ik wil het aantal publieke voorzieningen tellen in mijn buurt Via API's van Digitaal Vlaanderen of bevragen gemeentelijke databronnen. Informatie soms onvolledig of niet actueel. Vergelijken Ik wil de verhardingsgraad van mijn stad vergelijken met die van een andere stad Op basis van de Jaarlijkse bodemafdekkingskaart (Departement Omgeving) de verhardingsgraad uitrekenen door de oppervlakte van waarschijnlijke verharde grond te delen door de ganse oppervlakte Foutenmarge: fouten in kaarten bij schaduwen, grote vlakken,... waardoor verschil soms binnen een foutenmarge valt. Voorspellen Ik wil weten hoeveel peuters er in deze buurt/woonwijk binnen 10 jaar zullen zijn Door het combineren van studies en huidige cijfers kan ik een estimatie geven van het huidig aantal peuters en door studies ivm groei van de bevolking kan ik een estimatie laten doen jaar per jaar. De studies zijn niet 'waterdicht' mbt hun kwaliteit en hun scope valt niet samen met die van Ruimtelijke Planners. Door demografische shiften kan het verleden soms niet meer gebruikt worden voor de toekomst. Monitoren' van een 'evolutie' Ik wil de jaarlijkse evolutie van oppervlakte aan parken in een bepaalde wijk visualiseren Jaarlijkse update, Automatisatie via digitalisatie opportuniteit update frequentie afhankelijk van brondata verschil in datafrequentie/beschikbaarheid stabiliteit van brondata (niet duurzaam, stopt plotseling,...) andere berekeningswijzen onder verschillende instanties (inter en intra) nood standaarden meten/vergelijken Ik wil weten waar er verharding is bijgekomen in een gemeente en waar er verharding is verdwenen doorheen verschillende jaren verschilbestand (delta bestand) en cre ren van de dataset jaarlijksebodemafdekkingskaart (matrix maar ook in de tijd en ruimtelijk bekijken) AI moet getraind worden op lokale data, niet blindelings geloven ML op satelliet, drone beelden AI in de linkse deel eerder dan in de rechter deel apriori in dit traject Geo functies op oppervlaktes (ruimtelijke statistiek). Aggregeren Ik wil granulaire informatie aggregeren om te voldoen aan privancy-regels Drempelwaarde van aantal inwoners per 'gebied' (wordt meegegeven en gebruikt als filter) verlies van informatie door aggregatie dataset als dataeigenaar anonimeseren voor privacy redenen Data clusteren Detail data zo groeperen dat ermee zinnig gewerkt kan en mag worden Standaard platformtools gebruiken zodat je kan focussen op modellen en zonder complexe ontwikkeling meerder type bronnen van verschillende oorsprong te kunnen combineren. Automatische datapipeline implementeren. brondata is echt detail data per huis, maar GDPR beschermd is in Vlaanderen niet vrij toegankelijk,. Relatie met "private data is nodig voor verrijking. Burger/registraitie is niet een correcte weergave van de realiteit (echte verblijf is niet altijd de officiele adressen) => via GSM Simkaarten. Registratie van veel data is op administratieve indeling en niet op ruimtelijke indeling (gepubliceerde data is op postcode en niet op straatsegment bvb). Proportioneel verdelen van een 'postcode' bvb tot een straatsegment bvb kan grote fouten genereren (denk maar aan inwoners in de havandokken van Antwerpen) om data proportioneel te verdelen moeten we aannames doen om zo dicht mogelijk bij realiteit te blijven Evalueren Ik wil het aantal voorzieningen vergelijken met drempelwaarde/beleidsdoelstelling dat voor het gebied werd opgesteld drempelwaarden/KPI's defini ren voor verschillende type gebeiden > de berekende waarde vergelijken met drempelwaarde rekening houden met eigenheid van buurten/gemeenten (drempelwaarde moet goed gekozen worden, die kunnen lokaal verschillen) Beoordelen Voorbarige conclusies trekken uit onvolledige data/simplistisch model ROI berekening/estimatie is subjectief (wat is de waarde van een boom) Veel beoordelingen en analyses blijven nog altijd subjectief(methodiek is niet gedocumenteerd extern) converteren converteren van verschillende datatypes (raster tov vector) zonder verlies van data Komt meestal voor converteren van co rdinaat-systemen verlies van data - verlies nauwkeurigheid verrijken, geocoding / geomapping (straatnaam tot punt op kaart) interne data verrijken met open data (datavindplaats met of zonder ruimtelijk component) implementeren van automatische data-verrijkings- processen structuur, schaalniveau, ... van de verschillende datasets te verschillend bvb dienst toerisme, erfgoed ... of met andere (vb commerci le) databronnen (belmap, tomtom, locatus,... - Open Street Map) updaten ik wil steeds de meest actuele gegevens ter beschikking hebben implementeren van automatische data-update processen API vs Datadump gewijzigde datastructuur vergelijken ik wil objectieve data kunnen vergelijken met subjectieve data (van bevragingen/enqu te) GSM voor beleidsadvies en beleidsevaluatie Objectieve vs Declaratieve data Iedereen heeft toegang volgens onze berekeningen tot een park, maar in een bevraging blijkt dat het niet gepercipieerd wordt buurtbevraging, en soms sporadische signalen vanuit de buurt van een tekort aan een bepaalde voorziening, terwijl dat we dat niet zouden gemeten hebben => aanzet voor een diepgaande analyse transformeren mappen van dataset op OSLO datamodel implementeren van automatische datatransformatie processen BIM naar GIS, CAD naar GIS monitoren ik wil heel wat ruimtelijke data (verhardingen, ruimtebeslag, oppervlakte tuinen, ... ruimte voor infrastuctuur, ...) doorheen de tijd opvolgen ik wil, bij elke update van deze data, eenvoudig een nieuwe meting krijgen en dit toevoegen aan de tijdsreeksen (data via DV, dOMG, VITO, andere 'definitie' (bvb ruimtebeslag) =>europese definities komen eraan, lange tijdsreeksen worden moeilijker (retroactief terug rekenen op historische data, mits goed communiceren van de veranderingen) Subscription zodat bij een update een berichtje gestuurd wordt. andere basisdata/bron indien ze niet meer bestaan, bij keuze van nieuwe = nieuwe definities Visualiseren ik wil de resultaten kunnen visualiseren op een interactieve kaart in combinatie met andere relevante gegevens Implementatie van interactieve kaart Te veel toepassingen zodat ze niet meer de weg vinden tot de juiste visualiseren van de verschillende componenten: brondata - analyse -simulatie Storymap (= product) ze vinden hun weg niet altijd tot de goede toepassing 3D juiste captatie van de user/functionele requirements Ze willen soms ook de brondata zelf zien Geoloket geopunt bvb. Tool is er, maar ze doen het toch manueel over of via specialisten. Veel 'leken' op vlak van werken met data => gebruiksvriendelijkheid automatiseren van processen die gemakkelijk te onderhouden zijn, en flexiebel aan te passen zijn segmentatie van architectuur (=modulair...) vertrouwen Kan ik de data voldoende vertrouwen om de gebruiken voor mijn analyses - beoordelingen AI? Chatgtp : bij het opstellen van een conclusie document kan goed werken - Vooral bij data-acquisitie - Hoe meer naar rechts hoe meer wantrouwen (suggestief ? adviserend ?) bevolkingsprognoses (niet bij de planners), hoge specialisatiegraad nodig, meer door gespecialiseerde bureaus Verhardingskaarten (consultants, VITO,...) => gewoon als een bron => credibiliteit ?? Geen exacte wetenschappen, vertrouwen zal wel groeien, maar de marges moeten gekend leer (learning) dataset niet voldoende groot. Vragen & opname Vragen Opname De opname van deze sessie is te bekijken via deze link . Volgende stappen De volgende stappen zijn: Verwerking van de input van de brainstorm oefening Rondsturen van een link naar dit verslag en powerpoint Verder onderzoek en voorbereiding van de eerste thematische werkgroep waarvoor u zich hieronder kan inschrijven Werkgroepen Hieronder het overzicht van alle werkgroepen voor het traject Slim Ruimtelijk Plannen . Andere werkgroepen 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 +
Functionele werkgroep Deze thematische we … Functionele werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties . Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie- uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen. De Functionele werkgroep vond plaats op 21 november 2023. Deelnemers Organisatie Deelnemer Agentschap Binnenlands Bestuur (VLOCA) Laurien Renders Alain Glickman IGEMO Felipe Garcia Del Pino Pieter Dresselaers GKS Machines Gerrit Verbeeck Geosolutions Kurt Vanderbiesen TLV Frederic Keymeulen Quares Robben Diependaele Gemeente Willebroek Thierry Serrien Gemeente Sint-Katelijne-Waver Veerle Bosmans MOW Steven Devloo Intrabel Gert Bellekens VVSG Guido Vaganée Febetra Isabelle De Maegt Context Initiatief Het onderwerp van discussie is vrachtwagenparkeren in het Rivierenland. Er heerst een dringende behoefte aan parkeerplaatsen voor vrachtwagens, aangezien dit probleem al enkele jaren bestaat. Er is bovendien een duidelijke stijging in het aantal inschrijvingen van vrachtvoertuigen in het Rivierenland de laatste jaren. De regio is tevreden met de economische bedrijvigheid achter deze evolutie, maar maakt zich ook zorgen over de externaliteiten verbonden aan de stijging. Er zijn vrachtwagens die rust nemen op verschillende (onveilige) plaatsen, maar er is geen georganiseerde en veilige parkeergelegenheid. Momenteel zijn er ongeveer 180 publieke vrachtwagenparkeerplaatsen beschikbaar in de regio. Dit leidt tot problemen. Bovendien ontbreekt het aan basisvoorzieningen voor chauffeurs, wat resulteert in klachten van burgers en vervuiling langs de wegen. Er wordt gezocht naar oplossingen voor zowel lokale overheden als transportbedrijven, maar dit wordt als een complex en gelaagd probleem beschouwd. Lokale besturen vragen daarom een oplossing voor het kanaliseren van het ‘wildparkeren’ van vrachtwagens. Er zijn drie initiatieven in ontwikkeling om dit probleem aan te pakken. Het eerste initiatief is het creëren van een vrachtwagenparking in de omgeving van Mechelen. Dit is bedoeld om de huidige problemen met openbaar parkeren aan te pakken. Het tweede initiatief richt zich op het ontwikkelen van een applicatie om vrachtwagenparkeren te vergemakkelijken, hoewel nog moet worden beslist of bestaande applicaties zullen worden gebruikt of een nieuwe zal worden gemaakt. Het derde initiatief gaat over het opzetten van een online overlegplatform om verschillende initiatieven en expertise op elkaar af te stemmen. De discussie is hier gericht op het creëren van een oplossing omtrent vrachtwagenparkeerplaatsen in samenwerking met gemeenten en bedrijven, waarbij wordt geprobeerd om de expertise van verschillende belanghebbenden samen te brengen. Daarnaast wordt gezocht naar financieringsmogelijkheden en publiek-private samenwerkingen om het project te ondersteunen. Ook wordt gewerkt aan de standaardisatie en toegankelijkheid van gegevens met betrekking tot vrachtwagenparkeren in Vlaanderen, waarbij externe ondersteuning wordt geboden voor de ontwikkeling van een applicatie. 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. Vorige werkgroep Het verslag van de vorige werkgroep kan je hier terugvinden. Brainstormsessie Doel Waar we tijdens de vorige werkgroep gefocust hebben op het identificeren, kwalificeren en kwantificeren van overlast en parkeeropportuniteiten, gaan we tijdens deze werkgroep zoeken naar een manier om opportuniteiten te verzilveren. Met andere woorden, om potentiële locaties om te zetten naar effectieve parkeerplaatsen. De opportuniteiten hebben we reeds geïdentificeerd, nl: - Herbestemming privé domeinen - Meervoudig gebruik privé en semi publieke domeinen - Openbare domeinen Om over te gaan tot implementatie moeten we de volgende acties ondernemen: Contacteren (Hoe ? Wie ?) Overtuigen (Win-Win ?) = ‘Business Modellering’ Ondersteunen (Onboarding, Helpdesk, ‘draaiboek’,…) Specifiek rond ondersteuning komen mogelijk de volgende vraagstukken aan bod: Juridische Ondersteuning (contracten, geschillen, …) Operationele Ondersteuning (Upgraden, Onderhouden,…) Financiële Ondersteuning (factureren, subsidieren, verzekeren,…) Output Acties Stappen Meervoudig gebruik Herbestemming 1. Identificatie Kadaster Wat is er mogelijk, welke ruimte is er? (RUP, GRUP,..) Kijken ifv bereikbaarheid bvb snelweg Luchtfoto's, google earth Lokale parkings van bvb warenhuizen Bedrijventerreinen en vastgoedbedrijven Gemeenen (admin/schepenen) Vervoerregio UNIZO, VOKA, comeos Onverharde terreinen zoeken Netwerk event 2. Contacteren Eigenaars bedrijventerreinen Gemeentes, POM Filiaalverantwoordelijke warenhuizen ODTH Logistics Netwerk event Provincies, gewesten Site manager Kadaster Lokale ondernemers Lokale besturen UNIZO, VOKA, comeos Consessiehouder 3. Overtuigen Concrete inhoud Wie, wat, wanneer, hoe Overtuigen door te ontzorgen Terrein beschikbaar stellen mag geen tijd/moeite/geld kosten Win-win Incentives opzetten Meetbare resultaten kenbaar maken Huuropbrengsten? Simulatiespel - bezoek plannen waar het al bestaat Best practices delen Steun bij administratie en investeringen Vermijden van conflicten Ontzorgen bij administratie Business case Positief voor bedrijfsimago Lokale verankering partnerschap opzetten Hoe hou je iets in orde, proper? Camerabewaking? Voorzieningen? Juridisch kader aanbieden Bepaalde investeringen mee ondersteunen (bvb beveiliging of laadinfrastructuur) Bepaalde voordelen op lokaal niveau toekennen Business opportuniteiten kwantificeren Kaderakkoord als template aanbieden waarin de voorwaarden duidelijk worden gestipuleerd Nadruk leggen op lokaal engagement Maatwerk is nodig! - goede segmentatie - ontzorging - incentivering - regionale verantwoordelijkheid - imago 4. Onboarden Intentieverklaring ondertekenen (plechtig) Opstaren van project stuurgroep Wegwijzering en aanduiding Voorzieningen in orde brengen Vraagstukken rond ondersteuning 1. Juridische ondersteuning Samenwerkingsovereenkomst publiek domein (rechten, risico's, handhaving voor lokaal bestuur) Gebruikersovereenkomst - opmaak standaarddocument dat verder nog kan gepersonaliseerd worden Wetgeving rond openbare verlichting Hulp bij aanvragen vergunningen Opmaak convenant Omgevingsvergunning? Milieuvergunning? Aansprakelijkheid? 2. Operationele ondersteuning Helpdesk 24/7 Faciliteiten op maat Handhaving Afvalsortering-en ophaling Toegangscontrole Onderhoud en herstellingen Verzekeringen 3. Financiële ondersteuning Voor installatie van infrastructuur laadpalen Fiscale voordelen? Subsidies vanuit Vlaamse Overheid? Valkuilen Lange termijn voor vergunningen Geschil exploitant en eigenaars Moet ingebed zijn in totaalvisie rond (vrachtwagen)parkeren (rekening houden met bvb aanrijroutes maar ook risico verschuiving probleem naar omliggende gemeentes) Business case geen vetpot Wie is de owner van het probleem? Nood aan een duidelijke taakverdeling Technische beperkingen Lokale buurtcomités kunnen plannen blokkeren - invloed op politiek Welke profielen hebben we nodig? Architect Studiebureau Project manager Financiële analist Business developer Account manager Persoon die zich bezighoudt met sales Jurist Volgende stappen De volgende stappen zijn: Verwerking van de input van de brainstorm oefening Rondsturen van een link naar dit verslag en powerpoint Verder onderzoek en voorbereiding van de eerste thematische werkgroep waarvoor u zich hieronder kan inschrijven Werkgroepen Hieronder het overzicht van alle werkgroepen voor het traject Vrachtwagenparkeren . Inschrijven kan door op de link te klikken van de betreffende werkgroep. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2023-09-26 IGEMO Thematische werkgroep 1 Data en informatie werkgroep 2023-10-24 IGEMO Thematische werkgroep 2 Functionele werkgroep 2023-11-21 IGEMO Thematische werkgroep 3 Technologie werkgroep 2024-01-30 9u00-12u00 IGEMO +
Functionele werkgroep Deze thematische we … Functionele werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties . Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie- uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen. De Functionele werkgroep vond plaats op Fout: ongeldige tijd. . Deelnemers Organisatie Deelnemer Agentschap Binnenlands Bestuur (VLOCA) Fabian de la Meilleure Laurien Renders Alain Glickman Provincie Oost-Vlaanderen Joachim Van den Bergh Pieter-Jan Fieremans Provincie Vlaams-Brabant Alexander Leysen VERA Kenny Stevens Jan Potemans Stad Halle Kasper Vanbeginne AE Steven De Block Aanleiding en Context Initiatief Met het Visualo-project willen de initiatiefnemers, waaronder stad Halle, een gezond en aantrekkelijk stadscentrum creëren waar lokale verkopers, horeca, organisaties en de mensen die er wonen samen kunnen komen en de stad op een andere manier kunnen beleven. Aan de hand van verschillende technologieën en gerichte communicatie zal het aanbod van lokale handelaren gepromoot worden om zo interactie met de inwoners te verhogen. Men wil dus specifiek inzetten op lokale handelszaken die een grote impact gevoeld hebben door corona. Daarnaast is hun aanbod weinig bekend bij inwoners en nog minder bij bezoekers. Digitale infoschermen in het straatbeeld zouden een oplossing kunnen zijn maar tonen vooral advertenties voor multinationals en webshops. Daarnaast stelt men vast dat lokale besturen zich vaak beperkingen tot aankondigingen voor evenementen. Het doel van het project is de creatie van een gebruiksvriendelijke app voor handelaars, een performant platform voor de centrum manager en het weergeven van advertenties op slimme infoborden. Hieronder een opsomming van de vereisten per doelgroep: Presentatie Slide 9 VLOCA Vloca-principes Presentatie Slide 9 Om te beginnen werden de VLOCA-principes toegelicht: VLOCA staat voor:- Transparantie: alle ontwikkelingen en verworven kennis wordt transparant op de kennishub geplaatst, voor iedereen bereikbaar met zelfs de mogelijkheid om zaken aan te vullen- Schaalbaarheid: de use cases vormen steeds het startpunt van de analyse waarbij er steeds rekening gehouden wordt hoe men los van een bepaalde technologie een oplossing kan uitgewerkt worden- Technologisch agnostisch: VLOCA houdt niet vast aan één bepaalde technologie. De use cases vormen het startpunt en hierbij wordt nagedacht hoe er los van een bepaalde technologie een oplossing kan uitgewerkt worden. - Gebruikersgericht: oplossingen worden uitgedacht in functie van het standpunt van de eindgebruiker - Interoperabel: de oplossingen kaderen nooit in slechts één project maar zijn bruikbaar voor huidige en toekomstige trajecten. - Duurzaamheid: de oplossingen die gegenereerd worden zijn niet enkel bruikbaar op korte termijn, maar ook voor de toekomst Proces Binnen VLOCA vertrekt men steeds vanuit de use cases die in de vorige sessies geïdentificeerd en gevalideerd werden. Daarnaast konden ook een aantal datanoden gedistilleerd worden. De opzet van de tweede thematische werkgroep is het identificeren en in kaart brengen van de functionele noden en interacties . Dit gebeurt aan de hand van een functionele oefening van data- en informatie volgens use cases, stakeholders, beslissingspunten en applicatie componenten. Deze fase bevindt zich in het luik van de bedrijfs- en IT architectuur. Werkgroepen In het bovenstaande schema kan je zien dat we ons ongeveer in het midden van het traject bevinden. Na deze werkgroep volgt nog een technologie werkgroep waarna een publieke review plaatsvindt om de architectuurstandaard te valideren. Samenvatting vorige werkgroep Het verslag van de vorige werkgroep met een overzicht van alle use cases en concepten kan je hier terugvinden. Archimate Wat: Visuele architectuur taal. Om mensen en systemen te laten samenwerken, hebben we een gedeelde architectuur omgeving nodig die beter communiceert. Doel: Om die gesprekken te ondersteunen en om te helpen bij het nemen van beslissingen, maken we verschillende modellen voor verschillende belanghebbenden en trajecten, zodat we complexe systemen, processen en oplossingen begrijpen en kunnen communiceren met elkaar. Hoe: Gestandaardiseerde aanpak en woordenschat om de verschillende aspecten van de architectuur te beschrijven. Binnen archimate kunnen we 4 lagen onderscheiden, gemapt op Open City Architectuur: Motivatie Beschrijft de uitdaging / probleem waarmee de sponsor, business en ICT afdelingen worden geconfronteerd. Dit is de reden waarom het traject is opgesteld. Bedrijf De bedrijfsarchitectuur is bedoeld om de gewenste processen in kaart te brengen. Het is tevens belangrijk om de betrokken actoren te identificeren, die de inhoud & volgorde van de processen valideren. Applicatie De applicatie architectuur ondersteunt de bedrijfsarchitectuur en beschrijft de relaties tussen applicatie componenten, functies, services, .. in een multimodaal model. Technologie De technologie architectuur ondersteunt de applicatie architectuur. Het beschrijft de relaties tussen platform- en infrastructuur omgevingen voor de technologische services die ze aanbieden aan de applicaties. Oefeningen werkgroep Aanpak Het verloop van de oefening is als volgt: Deelnemers worden doorverwezen naar een miro bord (de link naar dit bord kan je hier terugvinden) Om te beginnen worden de use cases overlopen Vervolgens overlopen we de bijbehorende schema's Tot slot krijgen de deelnemers de mogelijkheid om feedback te geven op de schema's aan de hand van groene en rode post-its met als doel extra noden te capteren en indien nodig aanpassingen te doen. Presentatie use cases Feedback en discussie m.b.t architectuurschema's Om te beginnen werden alle architectuurschema's toegelicht. Hierop werden de volgende opmerkingen en feedback gegeven: Kasper : Bij realtime monitoring heb je meerdere facetten: bepaalde informatie ingeven via het scherm informatie registreren op basis van de camera en zo de weergegeven informatie aanpassen aan het doelpubliek - adaptieve interactie monitoren van data Jan : Voor alle informatie die niet afkomstig is van klanten: evenementen bijvoorbeeld, nieuws van de stad, crisiscommunicatie etc., zit dit in het schema vervat? - Paul: jazeker, dit zit hierin opgenomen Steven : Voor mij is het duidelijk gezien mijn achtergrond (aanbieder van software). De dingen die ik hier zie zijn helemaal niet nieuw. Dit zijn zaken die voor ons heel relevant zijn. Vervolgens kregen de deelnemers de tijd om per architectuurschema rode en groene post-it's toe te voegen met vragen en opmerkingen. Schema 1: Performance platform voor centrum manager Steven : aangezien we over een performance platform spreken, gaat het niet enkel over het beheer maar ook over hoe goed de advertenties het doen. We zullen de handelaars moeten kunnen overtuigen met de succes rate van de advertenties. Adverteren zijn grote budgetten voor hun en zij willen weten wat ze hiervoor in de plaats zullen krijgen. Dit is data die je heel goed zal moeten beheren en die een city marketeer ter beschikking moet hebben. - Paul: absoluut! Dit zit volgens mij bij de onderzoeksresultaten. Bij databeheer zit ook een link naar intelligentie beheer. Joachim : valt hieronder het aansturen van verschillende locaties (in geval van meerdere schermen met andere inhoud)? Ik had begrepen dat er een optie zou zijn voor meerdere schermen per gemeente en dat deze dynamisch zouden kunnen aangestuurd worden. Indien een adverteerder een voorkeur heeft voor een bepaalde locatie, hoe en waar wordt dit aangestuurd? De definitie die hier gebruikt wordt, wijst eerder op de content creator terwijl een deel van de activiteit bij de beheerder ligt; het spreiden van content over verschillende assets. De rollen en verantwoordelijkheden horen ergens anders thuis volgens mij. - Paul: ik denk dat dit de bedoeling is vanuit de data centrale. Dit wordt beschreven in de definities. - Kasper: de functionaliteit ook. In het kader van de adaptieve advertenties waarbij het kan voorkomen dat het systeem/beheerder moet weten op welke locatie een advertentie te lanceren. Slimme technologie moet tevens in staat zijn om in te schatten waar en wanneer een advertentie best gepubliceerd wordt. - Joachim: het is gelinkt aan context: tijd, plaats en eventueel ook doelgroep. - Paul: dit zit zowel bij de app als bij de mediacentrale. Dit gaan we nog herbekijken. Joachim : bevat data governance gebruikersmanagement? - Paul: data governance gaat eerder zeggen hoe we zaken gaan accepteren en capteren, rollenbeschrijving,.. Puur user management zit niet in data governance Joachim: slaagt de consent op de handelaar of op de burger of beide? Ik veronderstel op de handelaar. - Paul: voor allebei - Joachim: ik zie dit niet werken voor allebei aangezien het in de publieke ruimte gebeurt. - Kasper: het systeem zal zo ontworpen moeten worden dat een concent niet nodig is. Moeten we bekijken. Alexander : van bij de start van dit project werd gezegd dat we wat betreft consent en privacy er nog niet aan uit zijn wat kan en niet. - Paul: absoluut, hiervoor moet bekeken worden met juristen en DPO wat de mogelijkheden zijn. Vraag & antwoord en volgende stappen Opname De opname van deze sessie is te bekijken via de onderstaande link: Volgende werkgroepen Indien u graag zou willen deelnemen aan één van de aankomende werkgroepen, kan u via de onderstaande link een overzicht van de workshops terugvinden en u ook zo inschrijven. De derde thematische werkgroep zal plaatsvinden op 25 april om 13u00 via Microsoft Teams. Inschrijvingslink: VLOCA-Visualo . Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2022-11-07 09u00-12u00 Vlaamse Overheid Herman Teirlinckgebouw (Brussel) Thematische werkgroep 1 Data en informatie werkgroep 2023-03-02 13u00-16u00 Digitaal Thematische werkgroep 2 Functionele werkgroep 2023-03-30 13u00-16u00 Digitaal Thematische werkgroep 3 Technologie werkgroep 2023-04-25 13u00-16u00 Digitaal +
Functionele werkgroep Deze thematische we … Functionele werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties . Na de data- en informatiewerkgroep zijn deze respectievelijke noden helder geworden. Deze functionele werkgroep bouwt hierop verder om de data- en informatie- uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling te schetsen. Een aantal vragen die aan bod kunnen komen tijdens deze werkgroep zijn: Hoe zien de data- en informatiestromen eruit? Welke interacties voeren welke stakeholders uit en tot welk doel? Welke beslissingspunten komen we bij uitwisselingsmomenten en acties tegen? De Werkgroep staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen deze noden in kaart brengen. Specifiek zijn we voor deze werkgroep op zoek naar data & functionele analisten, eindgebruikers (voor e2e testing user journeys,), proces analisten, IT managers, solutions analisten/ architecten,.. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen.Heb jij interesse, specifieke noden, expertise of andere belangen bij dit traject? Klik hier om je in te schrijven. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Thematische werkgroep 1 Data en informatie werkgroep 2024-06-11 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-06-11 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-07-09 13u-16u TeamsTechnologie werkgroep 2024-07-09 13u-16u Teams +
Functionele werkgroep Deze thematische we … Functionele werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de functionele noden en interacties, waar data- en informatie-uitwisseling tussen mensen en systemen, mensen onderling en systemen onderling centraal staat. De Werkgroep staat open voor deelname door de gehele quadruple helix. Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen deze noden in kaart brengen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen.Heb jij interesse, specifieke noden, expertise of andere belangen bij dit traject? Klik hier om je in te schrijven. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2023-01-12 13u00-16u00 VAC Gent Thematische werkgroep 2 Functionele werkgroep 2023-04-04 13u00-16u00 Digitaal Thematische werkgroep 3 Technologie werkgroep 2023-05-09 13u00-16u00 Digitaal werkgroep 2023-05-09 13u00-16u00 Digitaal +
GAIA-X is een belangrijk programma binnen … GAIA-X is een belangrijk programma binnen Europa samen met industriele spelers om de interop binnen cloud omgevingen te stimuleren, en zo het gebruik van cloud in Europe meer compatibel te maken met applicaties, tussen platformen en voor een betere data sharing. De technische architectuur focust vooral op federation en wordt hier beschreven : [1] Het conceptuele model ziet er als volgt uit : enterer als volgt uit : enter +
Geanonimiseerde gegevens zijn gegevens waa … Geanonimiseerde gegevens zijn gegevens waarvan de natuurlijke persoon niet of niet langer kan worden geïdentificeerd. Ze worden niet langer als persoonsgegevens beschouwd. Gegevens zijn pas echt geanonimiseerd als de anonimisering onomkeerbaar is. Lees meer: https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-personal-data_nl#antwoordreform/what-personal-data_nl#antwoord +
Gebruik van sjablonen Op de kennishub vi … Gebruik van sjablonen Op de kennishub via de tekst editor kunnen sjablonen worden toegevoegd. Deze laten toe blokken tekst of content automatisch te laten genereren. Hoe sjablonen gebruiken? Aan de hand van de visual editor Ga naar insert en kies een template Aan de hand van de source editor {{Naam Template}} Bestaande sjablonen De bestaande sjablonen zijn hier terug te vinden en aan te passen. Kies Template in de lijst. Waar te gebruiken Link naar de template Beschrijving Code te kopiëren City of Things initiatiefpagina's CityOfThingsIntro Template met algemene info over City of Things Initiatieven {{CityOfThingsIntro}} Deliverable DeliverableBestekteksten Template met algemene info over bestekteksten {{DeliverableBestekteksten}} Deliverable DeliverableConformiteitmodel Template met algemene info over conformiteitmodel {{DeliverableConformiteitmodel}} Deliverable DeliverableDraaiboeken Template met algemene info over draaiboeken {{DeliverableDraaiboeken}} Deliverable DeliverableKennishub Template met algemene info over kennishub {{DeliverableKennishub}} Deliverable DeliverableMarktAnalyse Template met algemene info over marktanalyse {{DeliverableMarktAnalyse}} Deliverable DeliverableOproepDeelname Template met algemene info over oproepdeelname {{DeliverableOproepDeelname}} Deliverable DeliverableStakeholderAnalyse Template met algemene info over stakeholderanalyse {{DeliverableStakeholderAnalyse}} Deliverable DeliverableTechnischeTekening Template met algemene info over technischetekening {{DeliverableTechnischeTekening}} Deliverable DeliverableTrajectCharter Template met algemene info over trajectcharter {{DeliverableTrajectCharter}} Deliverable DeliverableUseCasePrioritering Template met algemene info over use caseprioritering {{DeliverableUseCasePrioritering}} Deliverable DeliverableUseCaseRoadmap Template met algemene info over use case roadmap {{DeliverableUseCaseRoadmap}} Deliverable DeliverableVereistenModel Template met algemene info over vereistenmodel {{DeliverableVereistenModel}} Deliverable DeliverableVlocaAssessment Template met algemene info over VLOCA assessment {{DeliverableVlocaAssessment}} Deliverable DeliverableVlocaDataGovernanceModel Template met algemene info over data governance model {{DeliverableVlocaDataGovernanceModel}} Deliverable DeliverableVlocaDonut Template met algemene info over VLOCA donut {{DeliverableVlocaDonut}} Deliverable DeliverableVlocaInformatiemodel Template met algemene info over informatiemodel {{DeliverableVlocaInformatiemodel}} Deliverable DeliverableVlocaModel Template met algemene info over VLOCA-model {{DeliverableVlocaModel}} Deliverable DeliverableVlocaTalk Template met algemene info over VLOCA Talk {{DeliverableVlocaTalk}} Deliverable OverzichtDeliverableVersies Overzicht van alle versienummers van deze deliverable {{OverzichtDeliverableVersies}} Inline queries SortOnVlocaTrajectTypeDeliverableVersie Sorteren op verschillende properties (VlocaTraject, TypeDeliverable, Versie) {{SortOnVlocaTrajectTypeDeliverableVersie}} Nieuwe_pagina OverzichtTypePaginas Tabel overzicht "OverzichtTypePaginas" {{OverzichtTypePaginas}} Pagina beschrijving Deliverable OverzichtTypeDeliverables Overzicht van alle deliverables van dit type {{OverzichtTypeDeliverables}} Pagina nieuwsoverzicht OverzichtNieuwsberichten Overzicht van alle nieuwsberichten {{OverzichtNieuwsberichten}} Pagina Smart City Domein SmartCityComponenten Overzicht van alle smart city componenten {{SmartCityComponenten}} Pagina's met niveaus NiveauSelecteren Keuzeknoppen om de juiste niveaus te selecteren {{NiveauSelecteren}} Sjablonen InschrijvingWorkshop Laden van property "InschrijvingWorkshop" {{InschrijvingWorkshop}} Sjablonen LoadVersie Laden van property "LoadVersie" {{LoadVersie}} Trajectpagina OverzichtDeliverables Overzicht van deliverables gelinkt aan traject {{OverzichtDeliverables}} Trajectpagina OverzichtDraaiboeken Overzicht van draaiboeken gelinkt aan traject {{OverzichtDraaiboeken}} Trajectpagina en Sessie OverzichtWorkshops Overzicht van workshops gelinkt aan traject {{OverzichtWorkshops}} VLOCA Trajectpagina's TrajectInitiatieven Template met gelinkte initiatieven in VLOCA Traject {{TrajectInitiatieven}}A Traject {{TrajectInitiatieven}} +
Gebruikersrechten Gebruikersgroepen De … Gebruikersrechten Gebruikersgroepen De gebruikersgroepen die toegewezen kunnen worden op de kennishub zijn devolgende: Group naam Group id Admin (beheer) Admin (IT) Moderator/ Steward Content creator/ Recensent Gebruikers/ Bijdragers Bots (all) X Autoconfirmed users X Bots bot X Bureaucrats bureaucrat X Interface administrators interface-admin X moderator moderator X Administrators (SMW) smwadministrator X Curators smwcurator X Editors smweditor X spacemaster spacemaster X Suppressors suppress X Administrators sysop X Users * X Widget editors widgeteditor X Onder Special:ListGroupRights vind je welke rechten zijn toegewezen aan welke gebruikersgroep. Gebruikersgroepen toewijzen https://vloca-kennishub.vlaanderen.be/Special:UserRights Alle gebruikers https://vloca-kennishub.vlaanderen.be/Special:ListUsers Gebruikers samenvoegen https://vloca-kennishub.vlaanderen.be/Special:UserMerge Paswoorden herstellen https://vloca-kennishub.vlaanderen.be/Special:PasswordReset Andere gebruikers instellingen https://vloca-kennishub.vlaanderen.be/Special:SpecialPagesnnishub.vlaanderen.be/Special:SpecialPages +
Gebruikersrollen en groepen Group n … Gebruikersrollen en groepen Group naam Group id Admin (beheer) Admin (IT) Moderator/ Steward Content creator/ Rece nsent Gebruikers/ Bijdragers Bots (all) X Autoconfirmed users X Bots bot X Bureaucrats bureaucrat X Interface administrators interface-admin X moderator moderator X Administrators (SMW) smwadministrator X Curators smwcurator X Editors smweditor X spacemaster spacemaster X Suppressors suppress X Administrators sysop X Users * X Widget editors widgeteditor X * Voor ingelogde gebruikers, gebruik de parser function #ifanon https://vloca-kennishub.vlaanderen.be/Special:ListGrants Alle gebruikers https://vloca-kennishub.vlaanderen.be/Special:ListUsers Rollen per gebruiker https://vloca-kennishub.vlaanderen.be/Special:UserRights Andere zaken Special pages: Users and rights https://vloca-kennishub.vlaanderen.be/Special:SpecialPagesnnishub.vlaanderen.be/Special:SpecialPages +
Geen werkgroepen gevonden Some use of " " in your query was not closed by a matching " ". +