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

• Introductie Linked open data  +
• Introduction to AI  +
• IoT and Air quality in cities part 2  +
• Is component van relatie.  +
• Isa2 is interoperable europe-1024x512px4  +
• LDES  +
• Learnings from VLAIO city of things (ANPR, Databroker, Modi)  +
• Learnings from the Antwerp smart zone  +
• Linked Data Event Streams, NGSI-LDF, Comunica  +
• Introductie Met dit project zoeken de in … Introductie </br> Met dit project zoeken de initiatiefnemers rond penhouder Deerlijk naar de optimale hybride vorm van dienstverlening waarbij de kwaliteiten van fysiek en digitaal helemaal tot hun recht komen en elkaar versterken. Het project wil in concreto de fysieke organisatie en inrichting van het gemeentehuis efficiënt en logisch aanpassen aan wat digitaal kan. </br> De output is een blauwdruk die de opzet van de werkplek van de toekomst duidelijk maakt.</br> </br> Pitch </br> Voor burgers, ondernemers, verenigingen en medewerkers van het lokaal bestuur </br> biedt deze loketvrije aanpak </br> een burgernabije, warme, toegankelijke, outreachende en efficiënte dienstverlening op maat , </br> door een draagvlak voor digitale transformatie te creëren via participatie wat resulteert in een fysieke integratie van verschillende contactpunten . </br> In tegenstelling tot de huidige manier van werken gericht op interne en externe kruisbestuiving, creëert ruimte voor kwalitatieve contacten, ondersteunt maximaal digitale toepassingen, werkt drempelverlagend, én is inclusief de ecologische en HR uitdagingen van de toekomst. .</br> </br> Impactmap </br> </br></br> </br> Doel</br> </br> Doelgroep</br> </br> Impact</br> </br> Deliverable</br> </br> </br> Door het aanpassen van de omgeving aan de digitale transformatie en</br> daarbij alle stakeholders van gemeente en OCMW centraal te stellen bieden we met deze vernieuwende aanpak een warme en toegankelijke dienstverlening op maat.</br> </br> </br> Burger</br> </br> *De wijze van dienstverlening wordt afgestemd op de specifieke noden en behoeftes van de burger. *De burger weet waar, wanneer en hoe hij contact kan nemen met de gemeente volgens zijn behoefte en vraag --> tijdswinst voor de burger + de burger wordt niet van het kastje naar de muur gestuurd en heeft een positieve ervaring met de gemeentelijke dienstverlening. De burger komt in contact met de gemeente voor de produkten waarvoor hij dit nog nodig acht. *Door de vrijgekomen tijd in te zetten op het outreachend karakter van onze dienstverlening krijgen medewerkers sneller een (completer) beeld van de (hulp)vraag van de burger en wordt deze in het algemeen beter geholpen. Het optimaliseren van de omgeving speelt hierbij ook een grote rol. Impactmeting: tevredenheidsmeting bij burgers installeren</br> </br> </br> </br> </br> Burger met (algemene) vraag</br> </br> *De nieuwe omgeving is ingebed in een ruimere structuur --> werkt drempel verlagend. Er worden meer mensen geholpen en dit op een effici ntere manier. Hulpverlening (OCMW, thuiszorg) loopt niet achter op de feiten. *De nieuwe omgeving maakt outreachend werken mogelijk --> signalen worden sneller opgepikt en de burger wordt tijdig doorverwezen. *De gemeente functioneert als netwerkorganisatie --> de burger doet meteen bij de juiste medewerker zijn verhaal en wordt correct geholpen *Bij verplaatsing naar het nieuwe huis van de gemeente komt de burger in contact met cultuur en vrijetijdsdiensten --> de burger leert het aanbod kennen en effectieve deelname wordt makkelijker *Inzetten op e-inclusie wordt verankerd en door het aanpassen van de omgeving bereiken acties met betrekking tot e-inclusie hun doel. Impactmeting: kwalitatieve data ifv contactmomenten OCMW cli nteel evalueren en het aantal huisbezoeken dient te stijgen, stijging in het aantal leden van de bib en bij de ticketverkoop vrije tijd en ticketverkoop inclusieve vrijetijd (vb EDC, MIA uitpas)</br> </br> </br> </br> </br> Burger met specifieke vraag tot dienstverlening</br> </br> *De burger kan plaats- en tijdsonafhankelijk gebruik maken van de dienstverlening. Als het niet lukt via de digitale balie krijgt de burger hulp op maat in een vertrouwelijke en nabije omgeving. De burger heeft hierin de keuze en blijft bijgevolg 'eigenaar' van het hulpverleningsproces. *Daar de digitale transformatie de medewerkers op een zeker niveau ontlast van sommige taken is er ruimte voor meer kwalitatieve dienstverlening. Wat impliceert dat een loket hier niet voor volstaat. Impactmeting: daling van aantal contactmomenten, gekoppeld aan een stijging van contacttijd per moment, in kaart brengen waar en wanneer de burger wenst geholpen te worden en meten of we hieraan tegemoet komen</br> </br> </br> </br> </br> Bezoeker van vrijetijdspunt/bib</br> </br> *Het vrijetijdspunt en de bib zijn ingebed in de ruimere structuur --> ook deze bezoekers worden ondergedompeld in het geheel --> werkt drempelverlagend. Een bezoeker die initieel kwam voor het vrijetijdspunt kan toch even iets navragen aan de sociale dienst. Opnieuw worden problematieken sneller behandeld. *De nieuwe omgeving werkt taboedoorbrekend. Het stigmatiseren van OCMW cli nteel is verleden tijd. Het 'huis van de gemeente' wordt een doorsnede van de maatschappij. Impactmeting: stijgend aantal vragen/contacten bij de sociale dienst en thuiszorgdienst, stijgend aantal deelnemers aan activiteiten voor kwetsbare personen</br> </br> </br> </br> </br> Verenigingen</br> </br> *Alle vrijetijdsdiensten worden samengebracht tot n vrijetijdspunt --> n duidelijk aansprekingspunt voor verenigingen. *Door het aanpassen van de omgeving aan de digitale transformatie en het afbouwen van loketten ontstaan er voldoende en vernieuwde ruimtes voor ontmoeting en beleving. De ruimtes worden afgesteld op de hedendaagse digitale samenleving zodat verenigingen zich toekomsgericht kunnen ontwikkelen.</br> </br> </br> </br> </br> Ondernemingen</br> </br> *Door de digitale transformatie van ondermeer het ondernemingsloket dient de ondernemer niet altijd tot in het gemeentehuis te komen met zijn vragen. Bijgevolg kan hij/zij tijds- en plaatsonafhankelijk gebruik maken van de dienstverlening. Voor ondernemers met een drukke agenda is dit een grote meerwaarde. *Door de vrijgekomen personeelstijd kan de ondernemer met specifieke vragen rekenen op meer kwalitatieve dienstverlening op maat. Dit impliceert opnieuw dat een loket hier niet voor volstaat. Impactmeting: contacttijd met ondernemers en via tevredenheidsmeting bij ondernemers</br> </br> </br> </br> </br> Het lokaal bestuur als organisatie</br> </br> *Het 'dienstenorganogram' wordt losgelaten --> de focus verschuift naar een netwerkorganisatie. Door het installeren van een netwerkorganisatie krijgen de medewerkers meer zicht op de totale organisatie en worden de banden met collega's over de ganse organisatie sterker. Enerzijds versterkt dit de identiteit van de organisatie en anderzijds stelt dit alle medewerkers in staat om de zaken waar nodig organisatie- en dus ook maatschappij breed te bekijken. Dit resulteert in een snellere maar ook kwalitatievere dienstverlening. *De digitale tranformatie en de (fysieke) verschuiving naar een netwerkorganisatie zal medewerkers inspireren om hun eigen werk creatiever aan te pakken. Ook zal dit hen stimuleren om initiatief te nemen, idee n te brengen en zorgt dit voor een betere bottom up doorstroom. Impactmeting: instrument voor organisatiebeheersing</br> </br> </br> </br> </br> Medewerker gemeente</br> </br> *Repetitieve taken vallen weg --> inhoudelijke meerwaarde wordt toegevoegd aan het werk --> een grotere arbeidsvreugde tot gevolg. *Aangezien de vrijgekomen personele en fysieke ruimte ingezet wordt om nabijheid, ontmoeting en dienstverlening op maat mogelijk te maken kan een medewerker beter inschatten wat er leeft bij de burger en hier gericht op inspelen --> zorgt voor minder frustratiepunten bij medewerkers en bevordert het welzijn op het werk. *back-office en front-office worden gescheiden --> medewerker kan dossiers voorbereiden en nabehandeling voorzien zonder gestoord te worden Impactmeting: tevredenheidsenquete medewerkers</br> </br> </br> </br> </br> Medewerker sociale dienst</br> </br> *Administratieve ontlasting + maximaal voorzien van nodige hardware --> inzetten op outreachende hulpverlening. Men kan teruggaan naar de basis van het sociaal werk en preventief gaan werken, wat een meerwaarde is voor zowel maatschappelijk werker als hulpvrager. *De omgeving voorzien van vertrouwelijke gespreksruimtes in plaats van loketten --> hulpverlening an sich krijgt meer ruimte. *De digitale en fysieke transformatie cre ert ook mogelijkheden en verscheidene manieren om met partners samen te werken. Dit zorgt voor een betere aanpak van multiproblem problematieken. Impactmeting: aantal huisbezoeken stijgen, aantal uithuiszettingen dalen, aantal schorsingen leefloon dalen, tevredenheidsenquete medewerkers</br> </br> </br> </br> </br> Management</br> </br> *Digitale transformatie --> meer data ter beschikking --> management faciliteren in beleidsvoorbereidende opdracht + optimalisering traject werkplek van de toekomst *De (fysieke) netwerkorganisatie --> stimuleert het management (en elk lid ervan) om de ganse organisatie te zien en clusteroverschrijdend te denken en te handelen.</br> </br> </br> </br> </br> Beleid</br> </br> *De digitale en infrastructurele transformatie cre ert ruimte voor verdieping en verbreding van de dienstverlening. Het stelt het beleid in staat om hier verder op door te gaan en accenten te leggen. *Beslissingen worden meer gebaseerd op cijfers en evoluties. *Doorheen het project wordt gewerkt met 'peterschap' dit zorgt voor een politiek draagvlak.</br> </br> </br> </br> </br> Regio</br> </br> *Er is regionaal een eenduidige visie omtrent de digitale transformatie. Door experten uit de regio te betrekken via een klankbordgroep krijgt deze visie vorm in de praktijk. *Lokale besturen uit de regio (en daarbuiten) kunnen het onderzoek, de uitgekomen blauwdruk en de testcases implementeren in de eigen werking --> kosten- en tijdsbesparend</br> </br> </br> </br> </br> </br> Blauwdruk </br> </br></br> </br> Pagina</br> </br> Blauwdruk:</br> </br> Naar een open, nabij en loketvrij gemeentehuis van de toekomst</br> </br> </br> Fase</br> </br> De inwoner wil een straatfeest organiseren.</br> </br> Inwoner komt terecht bij het 'centraal punt' van de gemeente. Omdat hij dit wil of omdat de vraag te complex is om meteen digitaal op te lossen</br> </br> Inwoner wordt door de host ontvangen op het centraal punt van de gemeente</br> </br> Inwoner wordt geholpen door allround onthaalmedewerker</br> </br> Inwoner heeft een vervolgafspraak met de backoffice specialist</br> </br> Pro-actieve en automatische verwerking van de productaanvraag</br> </br> Verrijken van informatie door de medewerker(s) van het gemeentehuis</br> </br> Opvolging van het antwoord via de 'Mijn Burgerprofiel' app en toepassing</br> </br> </br> Interactiepunt</br> </br> De inwoner zoekt wat hij hiervoor in orde moet brengen via de zoekfunctie op de website van de gemeente, stelt de vraag aan een chatbot, mailt of telefoneert naar het contactpunt van de gemeente</br> </br> Centrale dienstverleningsplek in de gemeente (principe 'centraal punt')</br> </br> De 'host' (persoonlijke of digitale) zorgt voor een gastvrij contact met de gemeente en prikkelt ook digitaal (principe 'Hostmanship)</br> </br> De inwoner stelt z'n vraag aan de medewerker. Tijdens het contact wordt de vraag gelinkt aan het juiste product, de juiste contactpersoon, de juiste locatie, en wordt de juiste volgende stap uitgevoerd of een vervolgafspraak gepland.</br> </br> De inwoner heeft een vervolgafspraak met de medewerker van de uitleendienst omdat er een aantal specifieke vragen zijn, op een voor hem/haar meest geschikte locatie of tijdstip. (principe 'buiten de muren)</br> </br> Geen interactiepun tussen burger en medewerker</br> </br> Geen interactiepunt tussen burger en medewerker</br> </br> Mijn Burgerprofiel</br> </br> </br> Medium</br> </br> Verschillende kanalen en contactpunten (op afstand)</br> </br> Het gemeentehuis van de toekomst</br> </br> Het gemeentehuis van de toekomst met open deur, een host als welkomstpunt, een interactieve wachtruimte, een digipunt en intu tieve wayfinding (fysiek en digitaal)</br> </br> Gesprek tussen burger en medewerker in het centraal punt</br> </br> Fysieke interactie: centraal punt, via videobellen, aan decentraal servicepunt, mobiel, aan huis</br> </br> Data en automatische processen</br> </br> Interactie tussen medewerkers verrijkt de dienstverlening aan de burger (principe filterende en inspirerende werkplek)</br> </br> Het voorkeurportaal van de inwoner (app, website, statusupdate via mail of op te vragen via rechtstreeks contact) (principe: technologisch ondersteunend)</br> </br> </br> Ervaring</br> </br> </br> </br> </br> Frontoffice</br> </br> Contactteam en digitale portalen van de gemeente</br> </br> Logische, vlot bereikbare en toegankelijke locatie in de gemeente</br> </br> Contact verloopt via een menselijke host en gesprek van mens-mens of via een menscomputer contact (bijv. digitaal scherm, bevestigingsmail op de smartphone, smart device, )</br> </br> Voor interacties <5 min is er een rechtopstaand contact (bijv. aan een balie), voor interacties > dan 5 minuten een zittend contact (bijv. in een doorschijnend maar afgesloten ruimte, met water/koffie en ondersteunende digitale tools).</br> </br> Voor interacties <5 min is er een rechtopstaand contact (bijv. aan een balie), voor interacties > dan 5 minuten een zittend contact (bijv. in een doorschijnend maar afgesloten ruimte, met water/koffie en ondersteunende digitale tools).</br> </br> De aanvragen gebeuren volledig digitaal door dataverwerking en automatische processen. Burger krijgt automatische statusupdates via 'Mijn Burgerprofiel'</br> </br> Automatische statusupdates laten weten wanneer het inname openbaar domein werd goedgekeurd zodat het materiaal van de uitleendienst effectief kan/mag geleverd worden. De medewerkers van de uitleendienst krijgen hiervan bericht op hun device. De premie voor het straatfeest wordt door automatische toevoeging van deze informatie aan het dossier automatisch uitbetaald aan de aanvrager.</br> </br> Bundeling van 'Mijn vragen' (meldingen, producten, ) via digitaal portaal naar keuze</br> </br> </br> Backoffice</br> </br> Centraal contactteam en centraal digitaal intern platform</br> </br> Digitaal toegankelijke en gedeelde back-office (documenten, processen, systemen, )</br> </br> Digitaal toegankelijke en gedeelde back-office (documenten, processen, systemen, )</br> </br> De allround onthaalspecialist krijgt de tijd en ruimte om de vraag van de burger te beantwoorden. Er moet weinig geregistreerd/gegevens opgezocht worden (snel 360 zicht op de burger) maar de hulp van een 'virtuele assistent' kan ingeroepen worden. Automatisch worden een aantal zaken in gang gezet (aanvraag premie, inname openbaar domein, aanvraag uitleendienst,...)</br> </br> Digitaal toegankelijke en gedeelde back-office (documenten, processen, systemen, )</br> </br> Contactpersoon/dossierverantwoordelijke volgt dossiers en interacties globaal op en intervenieert op vraag en indien nodig.</br> </br> De co rdinator van de uitleendienst werkt op de flexplek waar ook iemand van de omgevingsdienst aan het werken is. Ze krijgen beiden bevestiging van de aanvraag van het straatfeest en komen er door hun gesprek achter dat er door de aanwezigheid van een distributiebedrijf achterin de straat extra signalisatie noodzakelijk is. De info wordt aangevuld aan het dossier en de burger krijgt hiervan meteen een update.</br> </br> Mijn burgerprofiel' wordt gevoed door lokale interacties en antwoorden.</br> </br> </br> Verschil huidige aanpak (wanneer van toepassing)</br> </br> Het centrale digitale platform van de toekomst zal via AI vlotter doorzoekbaar zijn, automatischer gevoed en getraind kunnen worden zodat er minder tijd van het centraal contactteam besteed moet worden aan het actueel houden van een digitale toepassing. Die tijd kan ge nvesteerd worden in de rechtstreekse dienstverlening en het rechtstreeks contact.</br> </br> No wrong door' in het gemeentehuis. Hier is iemand die alle dienstverlening kan doorverwijzen naar de juiste vervolgafspraak of het juiste digitale product. Indien het gemeentehuis gesloten is, worden alternatieven aangeboden of duidelijk gecommuniceerd wanneer je er wel terecht kan.</br> </br> Open deur, gastvrij onthaal (fysiek of digitaal), iemand komt naar je toe voor de balie, er zijn digitale alternatieven wanneer niemand beschikbaar is.</br> </br> Het contact met de onthaalmedewerker kan langer duren, er kan doorgevraagd worden, de vraag kan integraler benaderd worden, de virtuele assistent (AI chatbot voor de medewerker) helpt de medewerker een juist antwoord te formuleren. Zo kan er nog beter doorverwezen worden naar een oplossing. Die oplossing kan zowel digitale vervolgstappen omvatten, een afspraak met een specialist,...</br> </br> De gemeente komt meer naar de burger toe in plaats van omgekeerd. De medewerker wordt dus mobieler maar kan door nieuwe technologie n (afspraken- en planningssystemen) locaties en momenten bepalen waarop dit kan. Het uitgangspunt is dat de burger uit minstens 2 locaties en tijdsblokken kan kiezen.</br> </br> Meer automatische en proactieve verwerking en informatie. 'De burger kan de status van z'n vraag, melding of product volgen via 'Mijn burgerportaal' (in de app, op de website, via andere toekomstige tools, )</br> </br> Meer kennisuitwisseling en contact tussen medewerkers, ook van andere diensten en thema's. Samenwerking wordt gestimuleerd via flexibele werkplekken en interactieplekken waar kennisdeling en brainstorming wordt gestimuleerd.</br> </br> Mijn Burgerprofiel' als overheidsoverschrijdend portaal van en voor de burger. Gevoed door meerdere overheden, kanaalonafhankelijk raadpleegbaar door de burger via nzelfde portaal</br> </br> </br> </br> Succes-meting </br> </br></br> </br> Impact (6 thema's uit conceptstudie)</br> </br> Meetpunt</br> </br> SMART specificatie</br> </br> Huidige waarde</br> </br> Doel waarde</br> </br> </br> Inzetten op centraal punt van/voor de gemeente</br> </br> aantal gecentraliseerde contactpunten</br> </br> Het aantal contactpunten waar de burger voor dienstoverschrijdende vragen terecht kan tov het aantal inwoners.</br> </br> Afwijkend bij elke stad/gemeente</br> </br> 1-10 Afhankelijk van het aantal inwoners in de stad of gemeente.</br> </br> </br> eductie aantal loketten</br> </br> Het aantal loketten gekoppeld aan 1 dienst.</br> </br> Afwijkend bij elke stad/gemeente</br> </br> 0</br> </br> </br> Tevredenheid van de burger</br> </br> Algemene tevredenheid van de burger over het centrale contactpunt inzake snel en correct een antwoord krijgen op diens vraag op een schaal van 1 -5</br> </br> Tot op heden wordt er hier geen data over bijgehouden.</br> </br> 3,5</br> </br> </br> Eerstelijnsmedewerker kan direct antwoord bieden</br> </br> De tijd die een medewerker spendeert aan het zoeken naar de juiste informatie (documenten, processen, premies, producten en diensten)</br> </br> Tot op heden wordt er hier geen data over bijgehouden.</br> </br> 3 minuten</br> </br> </br> aantal contactkanalen</br> </br> Het aantal contactkanalen voor de burger dat op 1 punt samenkomt voor de medewerker</br> </br> Afwijkend bij elke stad/gemeente</br> </br> Stijging voor de burger, daling voor de medewerker door koppelingen</br> </br> </br> Profiel onthaalmedewerker</br> </br> Het eerste aansprekingspunt van de gemeente is niet meer louter een administratieve job en wordt ingeschaald.</br> </br> c- niveau</br> </br> minimum b- niveau</br> </br> </br> Hostmanship - van klant naar gast</br> </br> tevredenheidsmeting burger</br> </br> Algemene tevredenheid van de burger over het onthaal in het gemeentehuis op een schaal van 1 -5</br> </br> verschillend bij elke stad/gemeente: zie gemeente- en stadsmonitor</br> </br> 3,5</br> </br> </br> sneller bij de juiste persoon</br> </br> De tijd die een burger doorloopt van het onthaal in het gemeentehuis tot het antwoord bij de effectieve dienst als het centraal onthaal geen antwoord kan bieden</br> </br> Tot op heden wordt er hier geen data over bijgehouden.</br> </br> Afhankelijk van de soort vraag en of er een afspraak bij de dienst noodzakelijk is</br> </br> </br> Buiten de muren - mobiel contactpunt</br> </br> aantal decentrale dienstverleningslocaties</br> </br> Het aantal contactpunten waar de burger voor dienstoverschrijdende vragen terecht kan buiten het gemeentehuis tov het aantal inwoners.</br> </br> Afwijkend bij elke stad/gemeente</br> </br> minimum 1 (indien mobiel zijn dit er meteen meerdere)</br> </br> </br> aantal contacturen op decentrale lokaties</br> </br> De tijd die een medewerker spendeert aan dienstverlening op een decentrale locatie</br> </br> Afwijkend bij elke stad/gemeente</br> </br> In stijgende lijn</br> </br> </br> Inspirerende en filterende werkplaats</br> </br> aantal contactmomenten over de diensten heen</br> </br> De tijd die een medewerker spendeert aan formeel of informeel overleg met medewerkers van de eigen organisatie, maar van een andere dienst per week</br> </br> Tot op heden wordt er hier geen data over bijgehouden.</br> </br> 0,5 uur per week</br> </br> </br> aantal flexibele werkplekken</br> </br> Het aantal werkplekken in het gemeentehuis en op decentrale locaties die niet toegewezen zijn aan 1 persoon of dienst.</br> </br> Afwijkend bij elke stad/gemeente</br> </br> 10% van het aantal beeldschermwerkers (zonder de scholen) (met een maximum van 25 indien de huidige infrastructuur niet meer toelaat)</br> </br> </br> aantal activity based werkplekken</br> </br> Het aantal ruimtes in functie van de specifieke activiteit (vb concentratie, hybride vergaderen, informeel overleg, ontspanning, )</br> </br> Afwijkend bij elke stad/gemeente</br> </br> Voor elke specifieke activiteit min 1 plek</br> </br> </br> tevredenheidsmeting medewerker</br> </br> Algemene tevredenheid van de medewerker over de werkplekken op een schaal van 1 -5</br> </br> Tot op heden wordt er hier geen data over bijgehouden.</br> </br> 3</br> </br> </br> Duurzame partnerschappen</br> </br> aantal organisaties die gebruik maken van de ruimtes van het gemeentehuis</br> </br> Het aantal externe organisaties die over de periode van 1 jaar gebruik maken van de ruimtes van het gemeentehuis</br> </br> Afwijkend bij elke stad/gemeente</br> </br> afhankelijk van de grootte van de stad/gemeente: 3 -</br> </br> </br> aantal uren waarop het gemeentehuis door andere gebruikers gebruikt wordt</br> </br> Het aantal uren per week waarop een locatie van het gemeentehuis door andere (externe) gebruikers ingenomen wordt.</br> </br> Tot op heden wordt er hier geen data over bijgehouden.</br> </br> minimum 1 uur per week</br> </br> </br> aantal externe diensten die werken op flexibele werkplek / frontoffice</br> </br> Het aantal externe diensten die gebruik maken van de frontoffice in het gemeentehuis om de burger te woord te staan over de eigen dienstverlening per jaar.</br> </br> Afwijkend bij elke stad/gemeente</br> </br> afhankelijk van de grootte van de stad/gemeente: 3 -</br> </br> </br> Technologsich ondersteunend</br> </br> Eerstelijnsmedewerker weet waar info te vinden is en kan met de technologie werken.</br> </br> De tijd die een medewerker spendeert aan het zoeken naar de juiste informatie (documenten, processen, premies, producten en diensten)</br> </br> Tot op heden wordt er hier geen data over bijgehouden.</br> </br> 3 minuten</br> </br> </br> De mate waarin informatie doorstroomt naar de juiste dienst en software met elkaar gekoppeld is.</br> </br> Het aantal keer waarop de burger zijn vraag moet stellen.</br> </br> Tot op heden wordt er hier geen data over bijgehouden.</br> </br> 1</br> </br> </br> Lokale besturen uit de regio (en daarbuiten) kunnen het onderzoek, de uitgekomen blauwdruk en de testcases implementeren in de eigen werking</br> </br> aantal besturen die rapport raadplegen</br> </br> Het aantal keer dat de website (gemeentehuisvandetoekomst.be ) door een uniek ip adres geconsulteerd wordt per jaar.</br> </br> 0</br> </br> 20</br> </br> </br> </br> Andere projectdocumenten </br> Geen documenten beschikbaar via de VLOCA kennishub.</br> </br> Interesse in dit project? </br> Gelieve contact op te nemen via gzg@vlaanderen.be . Interesse in dit project? Gelieve contact op te nemen via gzg@vlaanderen.be .  +
• Introductie (Waarom?) Steeds meer steden … Introductie (Waarom?) </br> Steeds meer steden ontwikkelen hun eigen Local Digital Twin. Een data gedreven overheid gebruikt data ter ondersteuning van beleidsbeslissingen. Een Local Digital Twin, of Lokale Digitale Tweeling, biedt in een virtuele omgeving een actueel overzicht van de toestand van een gemeente of stad, en laat toe om beleidsmaatregelen en andere geplande ingrepen te simuleren en testen. Deze simulaties gebeuren op basis van data en slimme (artificiële intelligentie) algoritmes. Het is dus een instrument om beleidsmakers en experten te helpen bij het nemen van complexe, domeinoverschrijdende beslissingen die het leven van de inwoners verbeteren.</br> De implementatie van Local Digital Twins vereist evenwel een gedeeld referentiekader. De kennis en uitgangspunten over Local Digital Twins lopen vandaag nog niet altijd gelijk bij alle partijen die ze moeten bouwen en gebruiken, en VLOCA is dan ook de ideale partner om dit kader in co-creatie uit te tekenen.</br> In dit co-creatietraject bespreken we concepten en technische principes over Local Digital Twins door te brainstormen met data-architecten en domeinexperten van Vlaamse steden en gemeenten. Imec deelt inzichten over het concept van Local Digital Twins, datagedreven beleid en digitaliseren van beslissingsprocessen, en schetst de huidige stand van zaken in Vlaanderen en Europa.</br> Tijdens dit traject ligt de focus op het beleidsdomein duurzame leefkwaliteit, met specifieke aandacht voor geluid, verkeer en luchtkwaliteit. </br> </br> Bijdragen aan dit VLOCA Traject </br> Je kan bijdragen aan dit traject door deel te nemen aan de workshops of door actief bij te dragen aan de uitbouw van de Kennishub. </br> </br> Workshops (Hoe?) </br> Werkgroep Type werkgroep Datum Tijd Locatie Local Digital Twin Workshop 1: Gedeeld referentiekader Business werkgroep 2022-02-17 Local Digital Twin Workshop 2: Structuur en beheer van data Data en informatie werkgroep 2022-03-17 Local Digital Twin Workshop 3: Simulaties op basis van modelering Functionele werkgroep 2022-04-21 </br> Resultaten (Wat?) </br> Concept: Data-gedreven beslissingsondersteuningssysteem </br> Een Digital Twin kan beschouwd worden als een " data driven decision support system " of " data-gedreven beslissingsondersteuningssysteem ", kortweg DDSS . A Data-driven Decision Support System (DDSS) refers to “a category or type of decision support system that emphasizes access to and manipulation of a time-series of internal company data and sometimes external data” (Power, 2002, 2008). A decision support system “[is] a class of computerized information system that supports decision-making activities”. </br> </br> Draaiboeken </br> Ik wil begrijpen of de data waar ik mee aan de slag ben/zal gaan voldoet aan de FAIR principes. </br> Evidence-based decision making </br> Overzicht relevante Termen & Concepten </br> De thematische focus van dit traject ligt op duurzame leefkwaliteit, waarbij we aandacht hebben voor geluid, verkeer en luchtkwaliteit. Wat betreft geluid, zijn de volgende termen & concepten zijn daarbij onder meer relevant: </br> </br> Microfoon </br> Geluidsvervuiling </br> Sound event detection </br> Urban sound tagging </br> Voor wat betreft luchtkwaliteit en modellering, kan verwezen worden naar luchtkwaliteitmodellen . </br> </br> Overzicht relevante Europese programma's & projecten </br> Living-in EU </br> Destination Earth </br> Digital Europe Programme </br> H2020 </br> GAIA-X </br> DUET </br> URBANAGE </br> PRECINCT </br> PILL </br> Digital Twin Consortium </br> International Data Spaces Association </br> Open Data Institute </br> CompAir </br> Digital Twin Brugge </br> Overzicht internationale voorbeeldcases </br> LIST - Luxembourg Institute of Science and Technology </br> CDBB - Center for Digital Twin Britain </br> GeoNovum - Nederland </br> Gothenburg - Digital Tvilling </br> Finland - Digital Twin </br> Wellington - Digital TwinWellington - Digital Twin  +
• Introductie (Waarom?) VLOCA verenigt ied … Introductie (Waarom?) </br> VLOCA verenigt iedereen die betrokken is bij slimme en open steden, om samen een ‘open city architectuur’ te co-creëren. Zo’n architectuur zorgt ervoor dat een toepassing die in de ene gemeente ontwikkeld wordt, ook in een andere bruikbaar is. En dat al die sensoren, platformen en applicaties probleemloos informatie kunnen uitwisselen. </br> VLOCA wordt tastbaar gemaakt via thematische trajecten, waarvan één rond Hoppinpunten . Dit zijn fysieke plekken waar je vlot kunt overschakelen van het ene vervoersmiddel op het andere. Zo’n punt kan bijvoorbeeld aan een station of bushalte liggen en ook ruimte bieden voor deelfietsen of deelwagens. Op deze plaatsen stappen veel mensen over, daarom kunnen het goede plaatsen zijn om ook andere diensten aan te bieden zoals pakjesautomaten of laadinfrastructuur. </br> Hoppinpunten zijn een uitstekende case voor VLOCA, omdat ze overal in Vlaanderen gerealiseerd worden, over de gemeentegrenzen heen. Bovendien moet er informatie uitgewisseld worden over welke (mobiliteits)diensten aanwezig zijn in welk punt, en wat de beschikbaarheid ervan is (bijv.: aantal vrije deelfietsen,  parkeerplekken, of de doorkomst van bussen). Enkel zo kan reizigers een naadloze overstap gegarandeerd worden. </br> </br> Werkwijze (Hoe?) </br> Workshops </br> In het kader van het Hoppin’ traject werden er een aantal workshops georganiseerd. De verslagen met bijhorende presentatie kan je vinden op de volgende pagina’s:</br> </br> </br> Werkgroep Type werkgroep Datum Tijd Locatie Hoppinpunten Workshop 1: Behoeftes & doelstellingen Data en informatie werkgroep 2021-02-11 Hoppinpunten Workshop 2: Data Data en informatie werkgroep 2021-03-11 Hoppinpunten Workshop 3: Details Data en informatie werkgroep 2021-05-06 </br> Leidende use cases </br> Daarnaast werd tijdens het Hoppin' traject gebruik gemaakt van drie leidende use cases : </br> Use Case 1: Evaluatie van een mobipunt ​: De UC beschrijft de actie waarbij (een medewerker van) een lokaal bestuur de werking en gebruik van een huidig mobipunt wil evalueren. Deze medewerker heeft nood aan data om, aan de hand van statistische analyses, nieuwe diensten en verbeteracties te formuleren. Mogelijke gegevens zijn:​</br> </br> Gebruik van blue bikes en deelfietsen op bepaalde tijdstippen​ </br> Aantal zoekopdrachten of financiele verrichtingen aan het mobipunt voor adhoc verplaatsingen​ </br> </br> Use case 2: Operator wil diensten aanbieden : Een operator wil in de buurt/aan een hoppinpunt een nieuwe dienst aanbieden voor reizigers. Om de marktanalyse grondig te kunnen uitvoeren, heeft de operator data nodig over:​</br> </br> Aantal passanten​ </br> Huidig aanbod van andere operators en substituten​ </br> Timeseries openbaar vervoer​ </br> Aanwezige infratstructuur en huidig aanbod​ </br> </br> Use case 3: Reiziger die onderweg is : Deze UC beschrijft een bewegende reiziger die onderweg is tijdens een verplaatsingstraject van punt a naar punt b.​ De reiziger heeft de volgende noden: </br> </br> De reiziger wil realtime inzicht over de beschikbaarheid van vervoersmodi op het hoppinpunt​ </br> De reiziger wil proactief de reis plannen en indien mogelijk vervoersmiddel reserveren​ </br> De reiziger wil gebruik maken van het scherm aan de hoppinzuil​ </br> De reiziger wil onmiddellijk de betaling volbrengen ​ </br> Resultaten (Wat?) </br> Het beleid </br> Hoppinpunten worden met een reden geplaatst: achter de realisatie zit de visie rond basisbereikbaarheid van de Vlaamse Overheid. Het is belangrijk om te weten wat de doelstellingen zijn, zodat zowel de realiteit als het digitale model de doelstellingen kunnen ondersteunen en helpen realiseren. Vragen zijn onder meer: </br> </br> Welke doelstellingen wil de overheid realiseren </br> Wat is de beoogde doelgroep? </br> Wat zijn beoogde (mobiliteits)diensten op zo’n Hoppinpunt? </br> Wat is het minimumaanbod op zo’n Hoppinpunt? </br> Wanneer is zo’n Hoppinpunt geslaagd en hoe zal het succes opgevolgd worden? </br> Aan welke voorwaarden moeten diensten voldoen? </br> Hoe zal het aanbod en gebruik gestimuleerd worden: bijv. subsidies of andere voordelen? </br> Hoe kan ervoor gezorgd worden dat het aanbod over aanbieders heen consistent en vlot is? </br> De visie en het beleid rond basisbereikbaarheid liggen vast. De visietekst is beschikbaar via deze link , en is decretaal verankerd in het Decreet Basisbereikbaarheid . </br> De concrete materialisatie in het concept van de Hoppinpunten is nog in ontwikkeling, waardoor nog niet op al deze vragen een antwoord geformuleerd kan worden. Het is echter wel belangrijk dit scherp te hebben voor het concept uitgerold wordt (op straat en in de digitale werkelijkheid), zodat de uitvoering zo nauw mogelijk kan aansluiten bij de beleidsvisie. </br> Draaiboek: Ik wil subsidies aanvragen voor een Hoppinpunt </br> </br> De werkelijkheid </br> De Hoppinpunten zijn eerst en vooral een fysiek gegeven: infrastructuur op straat waar verschillende vervoersmiddelen gecombineerd kunnen worden. Om dit concept digitaal te beschrijven binnen VLOCA, is het noodzakelijk om een goed zicht te hebben op hoe een Hoppinpunt er in de realiteit uitziet, zodat het digitale informatiemodel de situatie in de realiteit – en alle mogelijke situaties op alle locaties – goed kan beschrijven. Die werkelijkheid wordt zichtbaar in: de infrastructuur op straat, de locatie, de aanwezige diensten, nutsvoorzieningen, de relatie met de omgeving van het punt. De infrastructuur dient zo vormgegeven te worden dat ze maximaal in staat is om de beleidsdoelstellingen te realiseren. </br> Belangrijk hier is ook: wie zal de Hoppinpunten beheren: zowel de infrastructuur als de aanwezige diensten. Wie doet het onderhoud, maar ook: wie beslist welke diensten er aanwezig zijn, wanneer die voldoen aan de (kwaliteits)voorwaarden, wie behandelt vragen en klachten, wie zorgt voor de nodige aansluitingen etc.</br> Draaiboek: Ik wil een nieuw Hoppinpunt aanleggen </br> Draaiboek: Ik wil een mobiliteitsdienst toevoegen aan een Hoppinpunt </br> </br> Het informatiemodel en de digitale werkelijkheid </br> De infrastructuur op straat staat niet op zichzelf. Doordat er diensten aan gekoppeld worden (doorkomsten bussen, laadpalen, deelwagens, parkeerplaatsen, ..) en er interoperabiliteit moet zijn met andere Hoppinpunten en diensten, moet er informatie uitgewisseld worden. We onderscheiden hierbij ruwweg drie niveaus.  </br> </br> De digitale beschrijving van de infrastructuur / statische werkelijkheid </br> Eerst en vooral wordt er een informatiemodel gebouwd dat de infrastructuur op straat digitaal beschikbaar maakt. Het gaat dan over: de locatie van het Hoppinpunt, de afmetingen, de toegankelijkheid, de aanwezige diensten, .. Deze digitale beschrijving is nodig om een bijvoorbeeld de Hoppinpunten op te nemen in digitale kaarten of routeplanners. Daarnaast is een digitale beschrijving ook nodig om een inventaris te maken van alle Hoppinpunten en het overzicht te bewaren om zo de uitrol bijvoorbeeld te kunnen opvolgen. Hoppinpunten, of onderdelen ervan die nog gerealiseerd moeten worden, kunnen digitaal ook al omschreven worden, om de realisatie op te volgen of toekomstige mogelijkheden te communiceren aan gebruikers. </br> Informatiemodel: Statische informatie over Hoppinpunten </br> Artikel over Hoppinpunten & data-uitwisseling </br> </br> De digitale weergave van het real-time aanbod en gebruik </br> In tweede instantie wordt best ook real-time informatie beschikbaar gemaakt: wanneer komt er een bus, hoeveel vertraging heeft die, hoeveel parkeerplaatsen zijn er vrij, is er een laadpaal beschikbaar, .. Zo kunnen gebruikers efficiënt hun reis of overstap plannen en kunnen de verschillende diensten op elkaar afgestemd worden. Deze informatie wordt typisch gebruikt door real-time multimodale routeplanners die een routekeuze geven aan de gebruiker, afhankelijk van de beschikbaarheid van vervoersmiddelen op een bepaald moment. </br> Aan sommige Hoppinpunten is een digitale zuil geplaatst. Hier zou deze dynamische informatie bijvoorbeeld geraadpleegd kunnen worden, dit dient nog nader gedefinieerd worden binnen het Hoppin-project. </br> Informatiemodel: Dynamische informatie Hoppinpunten </br> </br> Reservatie en financiële transacties van diensten </br> Ten derde kunnen betalingen gebeuren van diensten (bus ticket, laadpalen, verzenden postpakket, gebruik deelfiets, ..) door integraties tussen verschillende partijen. Dit is bij uitstek het werkgebied van Mobility-as-a-Service oplossingen. Ook bieden sommige bankapplicaties al de mogelijkheid aan om te betalen voor diensten. Bijkomend kan ook reservatie-informatie uitgewisseld worden tussen gebruikers en mobiliteitsdiensten aan een Hoppinpunt. Zo zouden gebruikers een laadsessie of deelwagen kunnen reserveren. </br> Dit aspect is niet behandeld in het VLOCA traject. Deelaspecten I (statische informatie) en II (dynamische info) zijn nog onvoldoende matuur en dienen eerst verduidelijkt te worden, voor er een referentie-architectuur uitgewerkt kan worden voor reservatie & betaling. </br> </br> Het Hoppin’ VLOCA traject als fundering van verschillende vervolgtrajecten </br> Het co-creatietraject, de Kennishub, de use cases, de draaiboeken en referentie-architectuur hebben een solide basis gelegd voor de digitale uitwerking van Hoppinpunten. Deze zaken worden verder uitgewerkt in de volgende trajecten: </br> </br> OSLO traject Hoppinpunten</br> OSLO Applicatieprofiel Hoppinpunten </br> OSLO Vocabularium Hoppinpunten </br> Het Hoppinproject van de Vlaamse Overheid binnen het programma Basisbereikbaarheid, inclusief een subsidietraject voor steden en gemeenten </br> De Mobiliteitscentrale </br> De Data Integratie diensten voor Mobiliteit traject van Digitaal Vlaanderen </br> Het Greenmov project van Digitaal Vlaanderen en imec </br> Het AWV OTL project  +
• Introductie (Waarom?) Via het VLAIO City … Introductie (Waarom?) </br> Via het VLAIO CityOfThings project Databroker werd het belang van het organiseren van data delen aangetoond, met de stad Gent als project leider. Op https://vimeo.com/399147417 werd door KCVS een introductiefilmpje geplaatst die het concept en het belang van een databroker beter beschrijft, met onderstaande context :</br> "Steden en gemeenten staan momenteel voor tal van grote uitdagingen, waaronder klimaatverandering, een vergrijzende bevolking, mobiliteit, globalisering en digitalisering. Slimme steden of ‘smart cities’ zoeken naar technologieën zoals IoT, die hen kunnen helpen het leven duurzamer en aangenamer te maken. Daarbij worden data als sleutel gezien om relevante toepassingen voor de maatschappij van de toekomst te voorzien. De nood om de waarde van historische en real-time (stads)data ten volle te exploiteren, voedt de nood aan een databroker die deze data toegankelijk maakt. Stad Gent leverde, samen met Digipolis Gent, de steden Antwerpen, Brugge, Genk en Roeselare, IMEC en het Kenniscentrum Vlaamse Steden, een project op dat zowel praktisch als juridisch een gids vormt voor alle Vlaamse steden en gemeenten. Deze gids zorgt ervoor dat de steden en gemeenten in staat zijn om zo’n databroker te implementeren en te exploiteren. "</br> Een open databroker vormt de basis van een open stad architectuur. Vandaar dat we in dit VLOCA traject willen verder gaan op de resultaten van dit traject en zien hoe dit kan gekaderd worden binnen een continue evolutie van de open stad architectuur binnen een VLOCA context, en dus ook gekoppeld worden aan andere trajecten.</br> </br> Werkwijze (Hoe?) </br> Er werd beslist om in dit traject 2 workshops te organizeren. In de eerste workshop is het de bedoeling om een aantal actoren in het landschap die actueel bezig zijn met open databroker (en city) platformen aan het woord te laten en informatie te delen. Daarbij natuurlijk de steden die meegewerkt hebben aan het VLAIO CoT databroker project, de steden Brugge/Roeselare/Leuven die hier een aanbesteding voor een open smart city data platform voor lopen hebben, en Antwerpen die met ACPAAS een draaiend open smart city platform heeft. </br> </br> Workshops </br> Werkgroep Type werkgroep Datum Tijd Locatie Data Broker Workshop 1 Business werkgroep 2021-02-03 Data Broker Workshop 2 Functionele werkgroep 2021-03-03 </br> Op basis van de informatie en feedback uit de eerste workshop werd een eerste versie gemaakt van de open smart city referentie architectuur. Deze werd dan besproken in de tweede workshop met dezelfde stakeholders.</br> </br> Resultaat (Wat?) </br> Bijdragen aan dit VLOCA traject VLOCA traject  +
• IoT and Air Quality in Cities part 1: Air … IoT and Air Quality in Cities part 1: Air Quality Sensing </br> In the last years, many air quality sensors and data solutions have emerged in response to the need for a higher air pollution monitoring resolution in cities. However, caution is needed as low-cost sensors are generally less accurate, show drift over time and are cross-sensitive to other pollutants or meteorological conditions. Moreover, a dedicated hardware setup is needed meeting the demands of your specific use case. This workshop will guide you in a stepwise approach towards a sensor-based solution, including choosing the right sensor for the specific application, and required data calibration and validation.</br> Date: Tuesday March 09 rd 2021, 09:00 - 11:00</br> Registration: https://share.hsforms.com/11l49Ol22R7-3AG3VlZO2Ow42q9f </br> Registered participants will receive the MS Teams-link a few days before the</br>meeting.</br> </br> </br> Speakers: </br> Valerio Panzica La Manna and Jelle Hofman (IMEC-NL), Martine Van Poppel and Jan Peters (VITO)</br> </br> Slides </br> </br> </br> Agenda (2h online event) </br> 09:00 - 09:15 </br> Introduction: Air Quality and IoT </br> </br> 09:15 - 10:00 </br> Data quality & calibration </br> </br> 10:00- 10:45 </br> Choosing the right sensor and set-up for your application </br> </br> 11:45 - 12:00 </br> Wrap-up and Q&Alication 11:45 - 12:00 Wrap-up and Q&A  +
• IoT and Air Quality in Cities part 2: Air … IoT and Air Quality in Cities part 2: Air Quality Modelling </br> Over the past years, interest in air quality has increased resulting in many smart city solutions. This workshop will present an overview of air quality modelling for smart city applications, including refining air pollution maps by incorporating data from emerging sensor networks. Besides improving the real-time information, models can be applied to predict future air quality, predict scenarios, anddetermine sources of air pollution, linking to smart ventilation in smart buildings. </br> Date: Tuesday March 23 rd 2021, 10:00 - 12:00</br> Registration: https://share.hsforms.com/1ka2R54OuTwOZ-oTlKj9HlA42q9f </br> Registered participants will receive the MS Teams-link a few days before the</br>meeting.</br> </br> </br> Speakers: </br> Stijn Vranckx and Jorge Sousa (VITO), Jelle Hofman (IMEC-NL)</br> </br> Slides </br> </br> You can watch the video of the workshop on Vimeo</br> </br> </br> </br> </br> Agenda (2h online event) </br> 10:00 - 10:15 </br> Introduction: Air Quality Modelling and Smart city applications </br> </br> 10:15 - 11:00 </br> Improved air quality information through coupling of sensors and models </br> </br> 11:00- 11:20 </br> Modelling the indoor & outdoor environment of smart buildings </br> </br> 11:20- 11:40 </br> Identification of air pollution sources and screening of air quality solutions</br> </br> 11:40 - 12:00 </br> Q&Aair quality solutions 11:40 - 12:00 Q&A  +
• JSON-LD, of JavaScript Object Notation for … JSON-LD, of JavaScript Object Notation for Linked Data, is een methode om Linked data over te dragen via JSON.</br> Het streven was om zo eenvoudig mogelijk het bestaande JSON formaat om te zetten naar een semantisch formaat: JSON-LD. Zo kunnen gegevens op vergelijkbare wijze met de traditionele JSON worden geserialiseerd. [1] Het is een W3C standaard die is ontwikkeld door de JSON for Linking Data Community Group.</br> https://json-ld.org/ta Community Group. https://json-ld.org/  +
• Japan (Cross-ministerial Strategic Innovat … Japan (Cross-ministerial Strategic Innovation Promotion Program) werkt ook aan een horizontale benadering voor Smart Cities, en heeft recent een white paper gepubliceerd rond hun voorstel voor een Smart City Reference Architecture, tesamen met een user guide. Dit materiaal is terug te vinden via deze link (enkel beschikbaar in het Japans).ze link (enkel beschikbaar in het Japans).  +
• Kandidaatstandaarden VLOCA zal vanaf 2023 open city architectuurstandaarden opleveren. Deze pagina wordt verder aangevuld.  +
• Kennishub Page types Inhoud 1 … Kennishub Page types </br> </br> Inhoud </br> </br> 1 Page types pagina </br> 2 Settings page instellingen </br> 3 Page properties template </br> 4 Sidebar template </br> 5 Overzicht van de classes en properties </br> 6 Sidebars aanpassen via de Javagen tool </br> </br> </br></br> Page types pagina </br> De page types pagina geeft een overzicht van alle page types op de kennishub.</br>Op deze pagina kan je nieuwe page types aanmaken en aanpassen.</br> </br> </br></br> </br> Veld </br> </br> Beschrijving </br> </br> </br> New page type</br> </br> Voeg een nieuwe page type toe, settings page, Page properties en Sidebar template worden aangemaakt</br> </br> </br> Settings page</br> </br> Op deze pagina vind je de algemene instellingen terug voor de nieuwe template</br> </br> </br> Defines class</br> </br> Elke page type is gelinkt aan een class. Een class zorgt voor de categorising van de pagina's. Zo kan informatie gequieried worden</br> </br> </br> Base properties template</br> </br> De algemene properties voor alle classes</br> </br> </br> Page properties template</br> </br> Op deze pagina wordt ingesteld welke properties opgeslagen worden en op welke manier</br> </br> </br> Sidebar template</br> </br> De sidebar template bepaalt alle velden aan de rechterkant van het scherm (=de sidebar)</br> </br> Settings page instellingen </br> Deze tabel geeft een overzicht van de mogelijke instellingen voor een settings page. Deze vullen we manueel aan.</br> </br> </br></br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> De class waar naar vernoemd wordt, deze class halen we op om properties te laden</br> </br> Defines class=</br> </br> </br> Bij aanmaak van een nieuwe pagina wordt een titel gekozen. Deze resulteert in een pagina titel en een URL. Opties zijn: Pagetitle format=next_available --> Wanneer er een nieuwe pagina, wordt de volgende beschikbare nummer gekozen in de URL Pagetitle format=title --> De gekozen titel verschijnt in de URL, kan niet meer worden aangepast! </br> </br> Pagetitle format=</br> </br> </br> Namespace gebruiken voor een uniforme structuur in URL's: Geen namespace: Allowed namespaces=(Main) --> vloca-kennishub.vlaanderen.be/Pagina NamespaceX: Allowed namespaces=NamespaceX --> vloca-kennishub.vlaanderen.be/NamespaceX/Pagina</br> </br> Allowed namespaces=</br> </br> </br> Bepaalt de display naam (voor de leesbaarheid, bijvoorbeeld de lijst met classes uit te kiezen bij aanmaak nieuwe pagina)</br> </br> Displays as=</br> </br> </br> Bepaalt de structuur van de pagina: willen we een sidebar zien?</br> </br> Layout areas='sub-header sidebar' 'main sidebar'</br> </br> </br> Verhouding van de body en de sidebar</br> </br> Layout columns=3fr 1fr</br> </br> </br> Verhouding van de body en de sidebar</br> </br> Layout rows=auto 1fr</br> </br> Voorbeeld </br> </br> {{Class definition</br> |showonselect=1</br> |Defines class=VlocaSessie</br> |Pagetitle format=next_available</br> |Allowed namespaces=VlocaSessie</br> |Displays as=VLOCA-Sessie</br> |Layout areas='sub-header sidebar' 'main sidebar'</br> |Layout columns=3fr 1fr</br> |Layout rows=auto 1fr</br>}} </br> Page properties template </br> De page properties worden manueel aangevuld.</br>De sleutelwoorden (csv) en +sep=, worden gebruikt wanneer verschillende properties in de sidebar gekozen mogen worden op pagina niveau.</br> Voorbeeld </br> </br> <noinclude></br>{{Managed</br> |Version=1.0</br> |Version notes=1.0 - First managed version</br> |Short description=</br>}}</br></br><pre></br>{{VlocaSessie properties</br> |Actoren= <text> (csv)</br>}}</br></pre></br></br></noinclude></br></br><includeonly></br>{{#set: </br> |Actoren={{{Actoren|}}}|+sep=,</br>}}</br>{{DISPLAYTITLE:{{{Title|}}}|noreplace}}</br></includeonly> </br> Sidebar template </br> De code in de sidebar template is complexer en langer dan de page properties template.</br>Om de leesbaarheid van de pagina te bewaken en omdat er een geautomatiseerd proces is voor het opstellen van deze sidebar templates, wordt de sidebar template niet volledig beschreven.</br> </br> Overzicht van de classes en properties </br> De onderstaande matrix geeft een overzicht van alle page types/ classes die op de kennishub zijn aangemaakt en welke properties eraan gekoppeld zijn.</br> </br> Class-props en Base-props </br>Class props omvat alle props welke in de class definition zijn vastgelegd. De base props gaan om de inherente props van een pagina, zoals de titel en de class waar deze toe behoort, welke dus - in turn - de class props bepaald.</br>Base props zijn zodoende props welke voor iedere pagina bestaan en class props niet.</br> </br> Sidebars aanpassen via de Javagen tool </br> Om sidebars eenvoudig te kunnen aanpassen, werd de Sidebar generator ontwikkeld.</br>De Sidebar generator is een matrix met instellingen. Die instellingen worden samengebracht in een code die in een bronbestand samenkomen.</br>Dit bronbestand kan integraal worden gekopiëerd in de respectievelijke Sidebar templates.</br> Een meer gedetailleerd overzicht is terug te vinden op de VLOCA SharePoint (vloca@vlaanderen.be voor toegang).erd overzicht is terug te vinden op de VLOCA SharePoint (vloca@vlaanderen.be voor toegang).  +
• Kennishub paginas aanpassen Inhoud … Kennishub paginas aanpassen </br> </br> Inhoud </br> </br> 1 Voeg een pagina toe </br> 2 Aanpassen van de essentiële metadata/ parameters </br> 3 Structuur van de pagina’s </br> 4 Opmaak van de pagina’s </br> </br> 4.1 Kies je opmaakstijl </br> 4.2 Verfijn je opmaak </br> 4.3 Voeg een koppeling toe </br> </br> 4.3.1 Voeg een VLOCA kennishub koppeling toe </br> 4.3.2 Voeg een koppeling toe als uitwendige pagina </br> </br> </br> 4.4 Voeg een referentie toe </br> 4.5 Voeg andere gegevens of media toe </br> 4.6 Voeg speciale tekens in </br> </br> </br> 5 Wijzigingen opslaan </br> </br> </br></br> Voeg een pagina toe </br> 1)       Druk op: Nieuwe pagina </br>2)       Geef een titel mee ( pas op, deze wordt gebruikt in de hyperlink! ) </br>3)       Kies je type pagina ( goed kiezen! ) en geef het de juiste naam </br>4)       Bevestigen</br> </br> </br></br> </br> Pagina type </br> </br> Titel (zonder komma's) </br> </br> </br> Termen en Concepten</br> </br> Vrij te bepalen</br> </br> </br> Organisatie</br> </br> Vrij te bepalen</br> </br> </br> Standaard</br> </br> Officiële benaming</br> </br> </br> Externe initiatieven</br> </br> Officiële benaming</br> </br> </br> </br> Aanpassen van de essentiële metadata/ parameters </br> Eens de nieuwe pagina aangemaakt, kan je rechts de knop bewerken terugvinden. Daar kan je de velden met metadata aanvullen. Elke type pagina heeft andere metadata dat aan te vullen is. Een aantal voorbeelden van velden:</br> </br> Onder je type pagina (bv organisatie) kan je de paginatitel aanpassen (niet de hyperlink) </br> Checkbox ‘is tag’: kan je vanuit andere pagina’s navigeren naar deze pagina en kan ik de naam van deze pagina gebruiken als tag in de metadata van andere pagina’s? </br> Tags: welke andere pagina’s wil ik in deze pagina ‘taggen’? </br> Files (upload): wil ik bestanden op deze pagina (naast afbeeldingen) opladen? </br> Structuur van de pagina’s </br> Trajecten </br>Volgende regels zorgen ervoor dat alle trajectpagina’s uniform worden opgesteld:</br> </br> Content op de pagina: Algemene intro, maximum 2 paragrafen </br> Links naar de workshops (voor benaming: kijk bij aanmaken nieuwe pagina) </br> Links naar de draaiboeken (voor benaming: kijk bij aanmaken nieuwe pagina) </br> Link naar de trajectpagina (parameter: website) op de sidebar rechts </br> Aanvullen van alle andere parameters indien gekend </br> Opmaak van de pagina’s </br> De titel van de pagina wordt aangeduid met de opmaalstijl “Titelpagina”.</br> De headers (van kop (h1) tot onderkop 4 (h5) wordt gebruikt om structuur in de pagina’s te geven en verschijnt automatisch in de inhoudsopgave (die tevoorschijn komt bij gebruik van minstens 2 koppen).</br> Andere opmaakregels worden hieronder toegelicht.</br> </br> Je kan heel eenvoudig tekst, opmaak, links en afbeeldingen toevoegen eens je op de knop bewerken hebt gedrukt (let op, je kan niet zomaar elke pagina bewerken).</br> </br> Kies je opmaakstijl </br> </br> </br> Verfijn je opmaak </br> </br> </br> Voeg een koppeling toe </br> </br> </br> Voeg een VLOCA kennishub koppeling toe </br> Deze link verwijst naar een andere pagina op de kennishub. Koppelingen of links kunnen zowel blauw als rood kleuren:</br> </br> De link kleurt blauw: de pagina bestaat al als tag </br> De link kleurt rood: de pagina bestaat nog niet op de kennishub, deze kan worden toegevoegd. </br> Voeg een koppeling toe als uitwendige pagina </br> Je kan een koppeling toevoegen die verwijst naar een externe pagina.</br> </br> Voeg een referentie toe </br> Je kan referenties toevoegen. Opgepast, je zal ook een referentielijst moeten toevoegen (onder de knop invoegen/ referentielijst).</br> </br> </br> Voeg andere gegevens of media toe </br> </br> </br> </br> </br> Afbeelding en media </br> Een reeds opgeladen mediabestand invoegen of een nieuw mediabestand opladen en invoegen, opmaak kan aangepast worden na selectie van afbeelding</br> </br> </br> Sjabloon </br> Een sjabloon kan een stuk herbruikbare tekst zijn of extra informatie weergeven (zoals een Youtube video) {{Video|Url=https://www.youtube.com/embed/yZTfyZCaSLY}} </br> </br> </br> Opmerking </br> Een visuele opmerking invoegen aan je tekst</br> </br> </br> Tabel </br> Voeg een tabel in</br> </br> </br> Snippet </br> Voeg een stukje code toe om extra functionaliteiten toe te voegen</br> </br> </br> Galerij </br> Voeg een afbeelding of verschillende afbeeldingen in met opmaak en afspeelmogelijkheden</br> </br> </br> Codeblok </br> Voeg een blok code in (bijvoorbeeld embedding van een video)</br> </br> </br> Uw handtekening </br> Voeg automatisch je naam en datum en uur in</br> </br> </br> Referentielijst </br> Voeg een automatische referentielijst in</br> </br> Voeg speciale tekens in </br> </br> </br> Wijzigingen opslaan </br> Door twee keer op wijzigingen opslaan te drukken, kan je je pagina opslaan en visualiseren.</br> Om je wijzigingen te controleren (als je dus een bestaande pagina bewerkt), kan je op wijzigingen controleren drukken voor je de tweede keer op wijzigingen opslaan drukt.  +
• Kennishub paginas opbouw Inhoud … Kennishub paginas opbouw </br> </br> Inhoud </br> </br> 1 Visueel overzicht van de kennishub </br> 2 Overzicht van de velden </br> 3 Source editing </br> 4 Linken gebruiken </br> 5 Templates gebruiken </br> 6 Properties </br> 7 Inline queries/ parser functions </br> </br> 7.1 Parser function #ask </br> </br> 7.1.1 Voorbeelden van de #ask functie </br> 7.1.2 Opbouw en instellingen van de #ask functie </br> 7.1.3 Resultaten van de #ask functie opmaken </br> </br> </br> 7.2 Parser function #show </br> 7.3 Extension:ParserFunctions </br> 7.4 RSS feeds schrijven </br> </br> </br> 8 Variabelen </br> 9 Iconen gebruiken </br> 10 Tabellen aanmaken </br> 11 Velden open- en toeklappen </br> 12 Magic words </br> 13 Meer opmaakregels </br> 14 Informatie volgens inlogstatus en gebruikersprofiel </br> </br> </br></br> Visueel overzicht van de kennishub </br> </br></br> </br> Ws-header </br> </br> Vlaanderen\ VLOCA Kennishub </br> </br> </br> </br> Account/ Log in & out</br> </br> Hulp nodig?</br> </br> </br> Ws-navmenu </br> </br> </br> </br> NAV1 </br> </br> NAV2 </br> </br> NAV3 </br> </br> NAV4 </br> </br> NAV5 </br> </br> NAV6 </br> </br> NAV7 </br> </br> Conditionele nav </br> </br> </br> </br> Zoeken</br> </br> </br> Ws-sub-header </br> </br> Titel </br> </br> </br> </br> </br> Wiki buttons </br> </br> Knop 1</br> </br> Knop 2</br> </br> Knop 3</br> </br> Knop 4</br> </br> Knop 5</br> </br> Sidebar </br> </br> </br> Body </br> </br> Body </br> </br> </br> </br> </br> Files </br> </br> </br> </br> </br> </br> Gegevens over de pagina </br> </br> </br> </br> </br> </br> Ws-footer </br> </br> Tools</br> </br> Footer 1</br> </br> Footer 2</br> </br> Footer 3</br> </br> Footer 4</br> </br> Footer 5</br> </br> </br> </br> </br> </br> De verhouding Body vs sidebar/ panel zit in de settings page , meer informatie op deze pagina . </br> Alle andere instellingen zitten in de stylesheet </br> </br> Overzicht van de velden </br> </br></br> </br> Wat aanpassen? </br> </br> Op welk niveau aanpassen? </br> </br> Wat wordt er aangepast? </br> </br> </br> Ws-header </br> </br> Kennishub</br> </br> De gehele bovense lijn</br> </br> </br> Ws-navmenu </br> </br> Kennishub</br> </br> De gehele navigatiebalk met knoppen exclusief zoekknop</br> </br> </br> Ws-sub-header </br> </br> Pagina</br> </br> De titel volgens de page template van de pagina (bepaald volgens de settings page )</br> </br> </br> Wiki buttons</br> </br> Kennishub</br> </br> De knoppen boven elke body, beheerd door WikiBase</br> </br> </br> Body</br> </br> Pagina</br> </br> Per pagina aan te vullen via visual editor en of source editing</br> </br> </br> Ws-footer </br> </br> Kennishub</br> </br> De gehele onderste lijn met uitzondering van 'tools'</br> </br> </br> Sidebar </br> </br> Page Template</br> </br> De sidebar volgens de gekozen page template )</br> </br> </br> Files</br> </br> Kennishub</br> </br> In beheer van WikiBase</br> </br> </br> Gegevens over de pagina </br> </br> Kennishub</br> </br> De gegevens over de pagina's volgens de page template (bepaald volgens de settings page )</br> </br> </br> settings page </br> </br> Kennishub</br> </br> De instellingen van de page templates</br> </br> </br> stylesheet </br> </br> Kennishub</br> </br> De stylesheet: de algemene opmaak van de kennishub</br> </br> </br> page templates </br> </br> Kennishub</br> </br> Type pagina's (page templates)</br> </br> </br> Namespaces*</br> </br> Kennishub</br> </br> Voorzetsel voor een pagina (bv: Template:)</br> </br> * Namespaces zijn in beheer van WikiBase </br> </br> Source editing </br> Elke pagina kan bewerkt worden aan de hand van de visual editor. Dit is een intuitieve en eenvoudige manier om inhoud aan pagina's toe te voegen.</br>Wanneer meer complexe inhoud ingevoerd moet worden, kan gebruik worden gemaakt van source editing.</br>Hoe pagina's opmaken en aanvullen vind je op deze pagina terug.</br> Source editing kan worden geselecteerd door:</br>Via de visual editor (in modus bewerken) naast de save changes knop, de source editor te selecteren of;</br>Achter elke url ?action=edit toe te voegen.</br> </br> Linken gebruiken </br> Links kunnen vanuit de visual editor en de source editing toegevoegd worden. Onderstaande voorbeelden zijn opgesteld om voor de source editing.</br> </br> </br></br> </br> Links </br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> Link naar interne pagina</br> </br> Wanneer de interne URL* en weer tegeven tekst dezelfde zijn</br> </br> [[InterneURL]] </br> </br> </br> Link naar interne pagina met andere naam</br> </br> Wanneer de URL en de pagina naamverschillend zijn</br> </br> [[InterneURL|tekst weer te geven]] </br> </br> </br> Link naar intern bestand</br> </br> Linken naar een intern bestand</br> </br> [[File:InterneURL|tekst weer te geven]] </br> </br> </br> Linken naar een interne afbeelding met preview</br> </br> Een foto linken zonder tekst, met afmetingen</br> </br> [[File:InterneURLimage.jpg|1000x1000px]] </br> </br> </br> Link naar externe pagina of bestand</br> </br> Linken naar Externe URL of bestand Opgelet: één spatie tussen de URL en tekst weer te geven </br> </br> [ExterneURL SPATIE tekst weer te geven] </br> </br> </br> Mailto</br> </br> Gestructureerde e-mail draften</br> </br> {{#widget:link|type=a|href=mailto:e-mail adres?subject=Onderwerp&body=Body e-mail|text=tekst weer te geven}} </br> </br> </br> Templates en widgets</br> </br> Sjablonen met tekst gebruiken op pagina's</br> </br> {{InterneUrlTemplate}} </br> </br> *Interne URL (geen https://vloca-kennishub.vlaanderen.be/ ) </br> URL's zijn hoofdletter- en spatie gevoelig </br> </br> Templates gebruiken </br> Een overzicht van alle beheerde templates vind je hier terug.</br> </br> Properties </br> De velden die we in de sidebar rechts aanpassen noemen we properties. Deze properties (of attributen) geven ons de mogelijkheid pagina's verder te beschrijven en te categoriseren.</br>Deze properties kunnen gebruikt worden in parser functions.</br>Om deze properties goed te kunnen gebruiken, is het soms nodig deze anders in te stellen.</br>Een aantal voorbeelden:</br> </br> </br></br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> Property 'datum veld'</br> </br> [[Has type::Date]] </br> </br> Inline queries/ parser functions </br> Een inline query gaat informatie ophalen uit de properties van de pagina's. Dit is de metadata gekoppeld aan een pagina: informatie ingegeven in de sidebar maar ook datum van aanmaak, wijziging, auteurs en meer.</br> </br> Parser function #ask </br> Deze query laat toe een gerichte zoekopdracht uit te voeren en deze zoekopdracht gestructureerd weer te geven.</br> </br> Voorbeelden van de #ask functie </br> Ter illustratie geven we een aantal voorbeelden.</br> Tabelformaat </br> </br> Naam deliverable Traject Deliverable Versie Aankondiging start publieke review Andere Beschrijving Aanmaak co-creatie pagina op de kennishub Andere Beschrijving Architectuurstandaard Andere Beschrijving Meer resultaten ... </br> </br> Tekstformaat </br> 3D referentie architectuur E-LSP , ANPR , API Meer resultaten ... </br> </br> Opbouw en instellingen van de #ask functie </br> De opbouw en instellingen van een #ask functie zijn hier opgelijst:</br> </br> </br></br> </br> Voorbeeld syntax </br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> #ask:xxx</br> </br> Opzoeken op één class (page type)</br> </br> #ask:[[Class::xxx]] </br> </br> </br> #ask:xxxxxx</br> </br> Opzoeken op meerdere class (page type)</br> </br> #ask:[[Class::xxx]][[Class::xxx]] </br> </br> </br> #ask:!xxx</br> </br> Een class uit de zoekopdracht filteren</br> </br> #ask:[[Class::!xxx]] </br> </br> </br> #ask:</br> </br> Opzoeken op alle classes (page type)</br> </br> #ask: </br> </br> </br> Property:xxx </br> </br> Filteren op één specifieke property</br> </br> [[Property:xxx]] </br> </br> </br> Property:xxx Property:xxx </br> </br> Filteren op verschillende properties (en)</br> </br> [[Property:xxx]][[Property:xxx]] </br> </br> </br> Property:xxx OR Property:xxx </br> </br> Filteren op verschillende properties (of)</br> </br> [[Property:xxx]]OR[[Property:xxx]] </br> </br> </br> Property:+ </br> </br> Filteren op alle geldige waarden van een property</br> </br> [[Property:+]] </br> </br> </br> Property:!xxx </br> </br> Specifieke property uitsluiten</br> </br> [[Property:!xxx]] </br> </br> </br> Property:!+ </br> </br> Filteren op lege waarden</br> </br> [[Property:!+]] </br> </br> </br> Property:~*xxx </br> </br> Filteren op geldeeltelijke waarden van een property</br> </br> [[Property:~*xxx]] </br> </br> </br> mainlabel=xxx</br> </br> De titel van de kolom met resultaten aanpassen</br> </br> |mainlabel=xxx </br> </br> </br> mainlabel=-</br> </br> De titel van de kolom met resultaten verbergen met gebruik van het minteken</br> </br> |mainlabel=- </br> </br> </br> ?=Weer te geven titel</br> </br> De hoofwaarde op een andere plaats weergeven</br> </br> |?=Weer te geven titel </br> </br> </br> ?Property</br> </br> Een property weergeven in de resultaten</br> </br> |?Property </br> </br> </br> ?Property=Weer te geven titel</br> </br> De titel van een property aanpassen</br> </br> |?Property=Weer te geven titel </br> </br> </br> ?Property # -</br> </br> De link naar een property afzetten in de zoekresultaten</br> </br> |?Property # - </br> </br> </br> ?Property # - =Weer te geven titel</br> </br> De titel van een property aanpassen en de link naar een property afzetten in de zoekresultaten</br> </br> |?Property # - =Weer te geven titel </br> </br> </br> sort=Property</br> </br> Sorteren op een property</br> </br> |sort=Property </br> </br> </br> order=xxxx</br> </br> Sorteervolgorde: asc of desc</br> </br> |order=xxxx </br> </br> </br> limit=xx</br> </br> Aantal weer te geven resultaten</br> </br> |limit=xx </br> </br> </br> headers=plain</br> </br> De links in de titelbalk afzetten</br> </br> |headers=plain </br> </br> </br> searchlabel=Meer resultaten ...</br> </br> Tekst weer te geven als er te veel zoekresultaten zijn</br> </br> |searchlabel=Meer resultaten ... </br> </br> </br> default=Geen resultaten</br> </br> Tekst weer te geven als er geen zoekresultaten zijn</br> </br> |default=Geen resultaten </br> </br> </br> class=table</br> </br> Type weergave van de zoekresultaten, zie ook hier </br> </br> |class=table </br> </br> </br> Werkgroep Datum Thematische werkgroep 3 2024-12-19 Thematische werkgroep 3 2024-12-10 Thematische werkgroep 3 2024-12-03 Thematische werkgroep 2 2024-11-21 Thematische werkgroep 2 2024-11-12 Meer resultaten ... </br> </br> Voorbeeld van een volledige inline query</br> </br> {{#ask:[[Class::VlocaSessie]]</br>[[SessieType::~*werkgroep]][[Datum::+]]</br>|mainlabel=Werkgroep</br>|?Datum # -</br>|sort=Datum</br>|order=desc</br>|limit=5</br>|headers=plain</br>|searchlabel=<br>Meer resultaten ...</br>|default=Geen resultaten</br>|class=sortable smwtable}} </br> </br> Voor meer voorbeelden, zie MediaWiki Website . </br> </br> Resultaten van de #ask functie opmaken </br> Resultaten van de #ask functie kunnen worden opgemaakt in verschillende formaten. Dit zijn een aantal voorbeelden die we op de kennishub gebruiken:</br> </br> </br></br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> Tabel: wikitable smwtable </br> </br> |class=wikitable smwtable </br> </br> </br> Tabel: datatable </br> </br> |class=datatable </br> </br> </br> Tabel: datatable compact </br> </br> |class=datatable compact </br> </br> </br> Tabel: sortable smwtable-clean </br> </br> |class=sortable smwtable-clean </br> </br> </br> Tabel: sortable wikitable smwtable </br> </br> |class=sortable wikitable smwtable </br> </br> </br> Tabel: sortable table </br> </br> |class=sortable table </br> </br> </br> Tabel: datatable compact cell-border </br> </br> |class=datatable compact cell-border </br> </br> </br> Tabel: table table-hover table-condensed </br> </br> |class=table table-hover table-condensed </br> </br> </br> Andere: tagcloud , enkel pagina naam zonder properties</br> </br> |class=tagcloud </br> </br> </br> Lijst met komma's , enkel pagina naam zonder properties</br> </br> |class=list </br> </br> </br> Genummerde lijst , enkel pagina naam zonder properties</br> </br> |class=ol </br> </br> </br> Bullet points lijst , enkel pagina naam zonder properties</br> </br> |class=ul </br> </br> </br> Category (per beginletter) , enkel pagina naam zonder properties</br> </br> |class=Category </br> </br> </br> Tekst, enkel pagina naam zonder properties</br> </br> Leeg</br> </br> Meer voorbeelden zijn terug te vinden op de MediaWiki Website . </br> </br> Parser function #show </br> De #show functie laat toe om informatie uit pagina's op te halen, zoals bijvoorbeeld de titel van een pagina.</br> </br> </br></br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> Properties ophalen uit een pagina. In dit specifieke voorbeeld willen we voor de huidige pagina de versie nummer weergeven als niet klikbare tekst.</br> </br> {{#show:{{FULLPAGENAME}}|?Versie # -|default=0}} </br> </br> Voor meer voorbeelden, zie MediaWiki Website . </br> </br> Extension:ParserFunctions </br> De Extensie ParserFunctions geeft de mogelijkheid om naast magic words, de #ask en #show functie gegevens op te halen en te vergelijken.</br>Een aantal voorbeelden:</br> </br> </br></br> </br> Voorbeeld </br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> ja</br> </br> Als criteria niet leeg is</br> </br> {{#if:testwaarde|ja|nee}} </br> </br> </br> ja</br> </br> Als criteria's gelijk zijn</br> </br> {{#ifeq:testwaarde|testwaarde|ja|nee}} </br> </br> </br> 2024-05-03</br> </br> De datum ophalen en weergeven</br> </br> {{#time:Y-m-d}} </br> </br> </br> Andere versie </br> </br> Aan de hand van een template bepalen wat de versienummer is</br> </br> {{#switch: {{LoadVersie}}<BR>| V0 = <BR>Dit is versie 0<BR>| V0.1 =<BR>Dit is versie 0.1<BR>| Andere versie<BR>}} </br> </br> Meer voorbeelden op de MediaWiki ParserFunctions pagina . </br> </br> RSS feeds schrijven </br> De extensie om RSS en atom feeds te genereren is geinstalleerd.</br>Een feed URL ziet er als volgt uit:</br> https://vloca-kennishub.vlaanderen.be/Special:Ask/-5B-5BClass::!Wiki-5D-5D-20/mainlabel%3D/limit%3D25/order%3Ddescending/sort%3Dmodification-20date/format%3Dfeed/searchlabel%3D-20Geen-20resultaten/type%3Drss/title%3DKennishub/description%3DKennishub-20feed </br> Dezelfde keywords als inline queries worden gebruikt bij het schrijven van de feed URL.</br>De RSS URL verschijnt enkel automatisch voor recente wijzigingen (op tools klikken, vervolgens op atom, in de URL kan atom vervangen worden door rss).</br>Voor elke pagina kan de rss feed link manueel worden geschreven en getweaked.</br> </br> Variabelen </br> Variabelen laten toe om een waarde te bewaren en later op de pagina op te roepen.</br>Een aantal voorbeelden:</br> </br> </br></br> </br> Voorbeeld </br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> </br> </br> Een variable waarde opslaan</br> </br> {{#vardefine:testvar|Testwaarde}} </br> </br> </br> Test</br> </br> Gebruik maken van een variabele waarde</br> </br> {{#var:testvar}} </br> </br> Iconen gebruiken </br> De FontAwesome extensie is geinstalleerd zodat het gebruik van iconen mogelijk is.</br>Een template werd opgesteld om deze nog eenvoudiger te gebruiker op de kennishub.</br>Hieronder een aantal voorbeelden en hoe deze op de kennishub kunnen toegegvoegd worden met de source editing.</br> </br> </br></br> </br> Icoon </br> </br> ID </br> </br> Syntax </br> </br> </br> </br> </br> plus</br> </br> {{Fa|plus}} </br> </br> </br> </br> </br> lock</br> </br> {{Fa|lock}} </br> </br> </br> </br> </br> envelope</br> </br> {{Fa|envelope}} </br> </br> </br> </br> </br> user</br> </br> {{Fa|user}} </br> </br> </br> </br> </br> arrow-right</br> </br> {{Fa|arrow-right}} </br> </br> Een uitgebreid overzicht van alle iconen vind je op de FontAwesome website terug. </br> </br> Tabellen aanmaken </br> Eenvoudige tabellen toevoegen kan met de visual editor. Deze tabellen zijn verder niet op te maken met de visual editor.</br>Source editing biedt heel wat mogelijkheden in opmaak. Hoe tabellen geprogrammeerd worden, zie je op de MediaWiki hulppagina .</br> De praktijk leert ons dat gebruikers tabellen vaak in Excel voorbereiden om die achteraf over te zetten op de kennishub.</br>De tabel kopiëren en plakken is helaas geen mogelijkheid. Om die reden hebben wij OSWALD ontwikkeld, een tool die tabellen in Excel exact nabouwt in het juiste voormaat voor de kennishub of andere MediaWiki instanties.</br> </br> Velden open- en toeklappen </br> </br></br> </br> Voorbeeld </br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> Klik hier </br> Veld dat open en toegeklapt kan worden</br> Extra open en toeklap knop </br> </br> </br> Velden open- en toeklappen</br> </br> <div class="mw-customtoggle-xxx"><b>Klik hier</b></div></br><div class="mw-collapsible mw-collapsible-content mw-collapsed mw-xxx" id="mw-customcollapsible-xxx"></br>Veld dat open en toegeklapt kan worden</br><div class="mw-customtoggle-xxx"><u>Extra open en toeklap knop</u></div></br></div> </br> </br> </br> .mw-collvl2 { </br> border-width: 2px; </br>border-style: solid; </br>border-color: rgb(255, 237, 0); </br>padding: 0.5em; </br>margin-bottom: 3px; </br>}</br> </br> </br> Opmaak herhaalde toeklapbare velden in [MediaWiki:Common.css]</br> </br> .mw-collvl2 {</br> border-width: 2px;</br> border-style: solid;</br> border-color: rgb(255, 237, 0);</br> padding: 0.5em;</br> margin-bottom: 3px;</br>} </br> </br> </br> Open- en toeklappen </br> </br> Actieknoppen herhaalde open- en toeklapbare velden</br> </br> <div class="mw-customtoggle-2">Open- en toeklappen {{Fa|hand-pointer}}</div> </br> </br> </br> </br>Veld dat open- en toegeklapt kan worden </br> </br> Inhoud open- en toeklapbare velden</br> </br> <div class="mw-collapsible mw-collapsible-content mw-collapsed mw-collvl2" id="mw-customcollapsible-2"></br>Veld dat open- en toegeklapt kan worden</br></div> </br> </br> </br> NiveauSelecteren </br> </br> Template met actieknoppen 3 herhaalde niveaus</br> </br> {{NiveauSelecteren}} </br> </br> Magic words </br> Magic words zijn heel korte stukken tekst in de source editing die ons toelaten korte informatie weer te geven of pagina instellingen te beheren.</br> We onderscheiden 3 verschillende types:</br> Behavior switches </br>Deze zijn als het ware pagina instellingen die bepalen hoe er met informatie op de pagina wordt omgegaan. De syntax bevat altijd een dubbel laag liggende streep voor en na het sleutelwoord.</br>Een aantal voorbeelden:</br> </br> </br></br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> Geen inhoudsopgave weergeven</br> </br> __NOTOC__ </br> </br> </br> Inoudsopgave op deze plaats weergeven</br> </br> __TOC__ </br> </br> </br> Vanaf dit punt de pagina niet indexeren voor zoekopdrachten</br> </br> __NOINDEX__ </br> </br> Variables </br>Dit zijn syntaxen die gebruikt worden om informatie en properties weer te geven van de algemene kennishub of de huidige pagina. Ze zijn op dezelfde manier opgemaakt als templates.</br>Een aantal voorbeelden:</br> </br> </br></br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> Huidige jaar weergeven</br> </br> {{CURRENTYEAR}} </br> </br> </br> Pagina ID weergeven</br> </br> {{PAGEID}} </br> </br> </br> Volledige naam van de pagina weergeven</br> </br> {{FULLPAGENAME}} </br> </br> </br> Titel(tabnaam) van de pagina anders weergeven</br> </br> {{DISPLAYTITLE:title}} </br> </br> Parser functions </br>Deze laten toe om properties uit andere pagina’s af te lezen en om opgehaalde informatie anders te formatteren (alternatief op parser function #show).</br>Een aantal voorbeelden:</br> </br> </br></br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> Pagina naam van een andere pagina weergeven</br> </br> {{PAGEID: page name }} </br> </br> </br> Een url in een ander formaat weergeven</br> </br> {{urlencode:string|QUERY}} </br> </br> Meer voorbeelden op de MediaWiki Magic words pagina . </br> </br> Meer opmaakregels </br> Naast al het bovenstaande, is het soms nodig om een aantal opmaakregels te coderen om de inhoud beter weer te geven. </br>De extra opmaakregels zijn voornamelijk geschreven in HTML. Deze zijn niet hoofdletter gevoelig.</br> Hieronder een aantal vaak gebruikte regels:</br> </br> </br></br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> Tussentitels, van h1 tot en met h6</br> </br> <h1>xxx</h1> </br> </br> </br> Tekst in het vet</br> </br> <b>xxx</b> </br> </br> </br> Tekst in het cursief</br> </br> <i>xxx</i> </br> </br> </br> Tekst onderstreept</br> </br> <u>xxx</u> </br> </br> </br> No breaking space</br> </br>   </br> </br> </br> Break (nieuwe lijn)</br> </br> <br> </br> </br> Meer opmaakregels vind je op HTML tutorials . </br> </br> Informatie volgens inlogstatus en gebruikersprofiel </br> Informatie kan volgens de inlogstatus, gebruiker of gebruikersprofiel gefilterd of weergegeven worden.</br>Een aantal voorbeelden:</br> </br> </br></br> </br> Voorbeeld </br> </br> Beschrijving </br> </br> Syntax </br> </br> </br> Huidige bezoeker is niet ingelogd</br> </br> Tekst weergeven volgens ingelogd of niet ingelogd</br> </br> {{#ifanon:Huidige bezoeker is niet ingelogd|Huidige bezoeker is ingelogd}} </br> </br> </br> Huidige bezoeker is geen admin</br> </br> Tekst weergeven volgens admin of niet admin</br> </br> {{#ifingroup:sysop|Huidige bezoeker is admin|Huidige bezoeker is geen admin}} </br> </br> Meer voorbeelden op de MediaWiki Extension:UserFunctions pagina .admin of niet admin {{#ifingroup:sysop|Huidige bezoeker is admin|Huidige bezoeker is geen admin}} Meer voorbeelden op de MediaWiki Extension:UserFunctions pagina .  +
• Kennishubgovernance Op de kennishub onde … Kennishubgovernance </br> Op de kennishub onderscheiden we 2 verschillende rollen voor geregistreerde gebruikers. Anonieme gebruikers hebben enkel leesrechten op de kennishub. Geregistreerder gebruikers zijn ofwel reviewer, of contributor :</br> </br> contributor: Contributors leveren een bijdrage aan het platform door het registreren van aanvragen, het editeren en toevoegen van pagina's en het deelnemen aan de discussies. Contributors verkrijgen een account en toegang tot de kennishub door via het VLOCA portaal te registreren. </br> reviewer: Reviewers zijn verantwoordelijk voor het nakijken en goedkeuren van page edits en het begeleiden van contributors in het aanleveren van kwalitatieve content. Reviewers worden geselecteerd op basis van neutraliteit en bevestigde expertise. </br> </br>Bijdragen aan de kennishub werkt via het systeem van approved revisions. Bij het registreren van een aanvraag tot co-creatie rond een initiatief via het aanvraag formulier, wordt op basis van de ingevulde velden en secties een Mediawiki pagina aangemaakt.</br></br>Contributors zorgen voor de content, die na een goedkeuring door een reviewer als "approved revision" geldt. De revisies die gemarkeerd zijn als "approved revision" zijn voor iedereen leesbaar.</br></br>Consensus m.b.t. welke pagina geldt als goedgekeurde versie, wordt verkregen op de discussiepagina, waaraan contributors en reviewer kunnen bijdragen. In essentie is deze discussie vrij.</br></br> </br> Deze pagina wordt herzien en verder aangevuld.na wordt herzien en verder aangevuld.  +
• Korte Beschrijving Door klimaatverand … Korte Beschrijving </br> </br> Door klimaatverandering nemen extreme zomerse onweersbuien toe in frequentie en intensiteit. Met name in stedelijke omgeving leidt dit in toenemende mate tot wateroverlast: het rioleringssysteem is immers niet berekend op buien van dergelijke omvang. Om op voorhand actie te nemen (het inschakelen van pompen, de lediging van bufferbekkens om de buipiek op te vangen, voortijdige dispatching van hulpdiensten, etc.) neemt de concrete vraag voor real-time overstromingsvoorspellingssystemen toe. HydroScan biedt met Flood4Cast® een volledig operationeel voorspellingsalgoritme dat in deze behoefte voorziet. De werking en meerwaarde is reeds aangetoond in een POC in Antwerpen. Het product is klaar om toegepast te worden in andere gemeentes en regio's in Vlaanderen, en daarbuiten.</br> </br> Belangrijke eigenschappen Flood4Cast® </br> Voorspelt stedelijke overstromingen in real time tot 3 uur op voorhand en met grote nauwkeurigheid </br> Actualiseert elke 5 minuten </br> Lokaliseert nakende overstromingen met een precisie tot op straatniveau </br> Wordt visueel in kaart gebracht binnen een decision support system </br> Genereert alarmsignalen naar de beslissingsnemers </br> Doelgroep </br> Gemeentes en provincies </br> Hulverleningsdiensten </br> Nutsbedrijven </br> Burgers </br> Beschrijving Architectuur </br> </br> Het Flood4Cast®-voorspellingsalgoritme wordt bij het opzetten van het systeem gevoed met gegevens voor overstromingsgevoeligheid (1):</br> </br> </br> Overstromingskaarten voor buien met verschillende kansen van optreden (wanneer beschikbaar). Voor Vlaanderen beschikt VMM over gedetailleerde pluviale overstromingskaarten opgemaakt door HydroScan en JBA (UK). </br> Administratieve gebieden waarvoor overstromingsrisico’s worden bepaald op basis van gebiedsspecifieke overstromingsgevoeligheidsparameters. </br> </br> Nadat het algoritme in werking is gesteld, wordt het opwaarts via een API gevoed met real-time radarbeelden (2).</br> Binnen het Flood4Cast®-voorspellingsalgoritme (3) vindt een statistische analyse plaats van de buikarakteristieken. Op basis van deze analyse wordt een neerslagvoorspelling ( nowcasting ) gedaan voor de volgende 3 uur en wordt deze voorspelling omgezet naar overstromingsrisico’s. Indien beschikbaar, worden overstromingskaarten samengesteld o.b.v. de overstromingsrisico’s per deelgebied.</br> Afwaarts wordt de volgende output gegenereerd:</br> </br> Real-time overstromingsrisico’s / overstromingskaarten (4). Deze worden via een API doorgegeven aan:</br> het speciaal ontwikkelde Flood4Cast® dashboard </br> een gebruikersinterface / platform dat in beheer staat van de eindgebruiker </br> Alarmen (5) </br> Optioneel kunnen strategisch geplaatste sensoren worden gekoppeld om de nauwkeurigheid verder te verhogen.</br> </br> API </br> De data-uitwisseling via API is geïmplementeerd conform de REST -architectuur. Hierbij wordt het aantal endpoints naar de gebruiker en de informatie in de bestanden beperkt tot de strikt noodzakelijke data. Gedetailleerde documentatie van de API is beschikbaar voor de gebruiker. Het primair gehanteerde data-uitwisselingsformaat is JSON. Het gehanteerde bestandformaat door de open API van VMM voor de neerslagrasterdata is het HDF5 Opera bestandformaat.</br> </br> Data </br> Radar </br> Voor de overstromingsvoorspellingen wordt gebruik gemaakt van real-time neerslagradarbeelden. Deze zijn voor heel Vlaanderen beschikbaar.</br> </br> Overstromingsrisico’s </br> Overstromingsrisico’s worden per administratief gebied bepaald op basis van diverse overstromingsgevoeligheidsparameters, onder meer de verhardingsgraad in het gebied. Hiermee kunnen overstromingsrisico’s toch worden ingeschat, ook indien er geen overstromingskaarten beschikbaar zijn.</br> </br> Overstromingskaarten </br> Indien overstromingskaarten beschikbaar zijn zullen deze ook worden gepreprocest en gevoed aan het algoritme. Voor Vlaanderen beschikt VMM over gedetailleerde pluviale overstromingskaarten. </br> De overstromingskaarten worden opgeknipt voor verschillende deelgebieden. Hierdoor kunnen de overstromingskaarten worden getoond in functie van de optredende neerslag in de deelgebieden.</br> </br> Dashboard </br> Een (optioneel) dashboard werd ontwikkeld voor de eindgebruikers. Hierin wordt, afhankelijk van de gebruiker, het volgende getoond:</br> </br> Neerslag(voorspelling): historische data en voorspelling ( nowcasting ) voor de komende 3 uur </br> Overstromingsrisicovoorspelling: overstromingsrisico’s per administratief gebied </br> Overstromingsvoorspelling: indien overstromingskaarten beschikbaar zijn, op verschillende schaalniveaus, waarvan het fijnste tot op straatniveau </br> Het dashboard toont live beelden en voorspellingen. Afhankelijk van de gebruiker kan het dashboard ook specifieke historische neerslaggebeurtenissen oproepen. Hiertoe is een event selector beschikbaar waarin de geregistreerde buien gemakkelijk zijn aan te roepen en af te spelen alsof ze in real time gebeuren.</br> Het dashboard toont getriggerde alarmen bij voorspelde wateroverlast.</br> </br> Alarmering </br> Gebruikers kunnen worden gewaarschuwd via:</br> </br> Dashboard </br> SMS </br> E-mail </br> Verdere informatie </br> </br></br> </br> Website: </br> https://www.hydroscan.eu/nl/flood4cast/ </br> </br> </br> E-mail: </br> flood4cast@hydroscan.be  +
• Korte Beschrijving Door klimaat … Korte Beschrijving </br> </br> Door klimaatverandering nemen extreme zomerse onweersbuien toe in frequentie en intensiteit. Met name in stedelijke omgeving leidt dit in toenemende mate tot wateroverlast: het rioleringssysteem is immers niet berekend op buien van dergelijke omvang. Om op voorhand actie te nemen (het inschakelen van pompen, de lediging van bufferbekkens om de buipiek op te vangen, voortijdige dispatching van hulpdiensten, etc.) neemt de concrete vraag voor real-time overstromingsvoorspellingssystemen toe. HydroScan biedt met Flood4Cast® een volledig operationeel voorspellingsalgoritme dat in deze behoefte voorziet. De werking en meerwaarde is reeds aangetoond in een POC in Antwerpen. Het product is klaar om toegepast te worden in andere gemeentes en regio's in Vlaanderen, en daarbuiten.</br> </br> Belangrijke eigenschappen Flood4Cast® </br> Voorspelt stedelijke overstromingen in real time tot 3 uur op voorhand en met grote nauwkeurigheid </br> Actualiseert elke 5 minuten </br> Lokaliseert nakende overstromingen met een precisie tot op straatniveau </br> Wordt visueel in kaart gebracht binnen een decision support system </br> Genereert alarmsignalen naar de beslissingsnemers </br> Doelgroep </br> Gemeentes en provincies </br> Hulverleningsdiensten </br> Nutsbedrijven </br> Burgers </br> Beschrijving Architectuur </br> </br> Het Flood4Cast®-voorspellingsalgoritme wordt bij het opzetten van het systeem gevoed met gegevens voor overstromingsgevoeligheid (1):</br> </br> </br> Overstromingskaarten voor buien met verschillende kansen van optreden (wanneer beschikbaar). Voor Vlaanderen beschikt VMM over gedetailleerde pluviale overstromingskaarten opgemaakt door HydroScan en JBA (UK). </br> Administratieve gebieden waarvoor overstromingsrisico’s worden bepaald op basis van gebiedsspecifieke overstromingsgevoeligheidsparameters. </br> </br> Nadat het algoritme in werking is gesteld, wordt het opwaarts via een API gevoed met real-time radarbeelden (2).</br> Binnen het Flood4Cast®-voorspellingsalgoritme (3) vindt een statistische analyse plaats van de buikarakteristieken. Op basis van deze analyse wordt een neerslagvoorspelling ( nowcasting ) gedaan voor de volgende 3 uur en wordt deze voorspelling omgezet naar overstromingsrisico’s. Indien beschikbaar, worden overstromingskaarten samengesteld o.b.v. de overstromingsrisico’s per deelgebied.</br> Afwaarts wordt de volgende output gegenereerd:</br> </br> Real-time overstromingsrisico’s / overstromingskaarten (4). Deze worden via een API doorgegeven aan:</br> het speciaal ontwikkelde Flood4Cast® dashboard </br> een gebruikersinterface / platform dat in beheer staat van de eindgebruiker </br> Alarmen (5) </br> Optioneel kunnen strategisch geplaatste sensoren worden gekoppeld om de nauwkeurigheid verder te verhogen.</br> </br> API </br> De data-uitwisseling via API is geïmplementeerd conform de REST -architectuur. Hierbij wordt het aantal endpoints naar de gebruiker en de informatie in de bestanden beperkt tot de strikt noodzakelijke data. Gedetailleerde documentatie van de API is beschikbaar voor de gebruiker. Het primair gehanteerde data-uitwisselingsformaat is JSON. Het gehanteerde bestandformaat door de open API van VMM voor de neerslagrasterdata is het HDF5 Opera bestandformaat.</br> </br> Data </br> Radar </br> Voor de overstromingsvoorspellingen wordt gebruik gemaakt van real-time neerslagradarbeelden. Deze zijn voor heel Vlaanderen beschikbaar.</br> </br> Overstromingsrisico’s </br> Overstromingsrisico’s worden per administratief gebied bepaald op basis van diverse overstromingsgevoeligheidsparameters, onder meer de verhardingsgraad in het gebied. Hiermee kunnen overstromingsrisico’s toch worden ingeschat, ook indien er geen overstromingskaarten beschikbaar zijn.</br> </br> Overstromingskaarten </br> Indien overstromingskaarten beschikbaar zijn zullen deze ook worden gepreprocest en gevoed aan het algoritme. Voor Vlaanderen beschikt VMM over gedetailleerde pluviale overstromingskaarten. </br> De overstromingskaarten worden opgeknipt voor verschillende deelgebieden. Hierdoor kunnen de overstromingskaarten worden getoond in functie van de optredende neerslag in de deelgebieden.</br> </br> Dashboard </br> Een (optioneel) dashboard werd ontwikkeld voor de eindgebruikers. Hierin wordt, afhankelijk van de gebruiker, het volgende getoond:</br> </br> Neerslag(voorspelling): historische data en voorspelling ( nowcasting ) voor de komende 3 uur </br> Overstromingsrisicovoorspelling: overstromingsrisico’s per administratief gebied </br> Overstromingsvoorspelling: indien overstromingskaarten beschikbaar zijn, op verschillende schaalniveaus, waarvan het fijnste tot op straatniveau </br> Het dashboard toont live beelden en voorspellingen. Afhankelijk van de gebruiker kan het dashboard ook specifieke historische neerslaggebeurtenissen oproepen. Hiertoe is een event selector beschikbaar waarin de geregistreerde buien gemakkelijk zijn aan te roepen en af te spelen alsof ze in real time gebeuren.</br> Het dashboard toont getriggerde alarmen bij voorspelde wateroverlast.</br> </br> Alarmering </br> Gebruikers kunnen worden gewaarschuwd via:</br> </br> Dashboard </br> SMS </br> E-mail </br> Verdere informatie </br> </br></br> </br> Website: </br> https://www.hydroscan.eu/nl/flood4cast/ </br> </br> </br> E-mail: </br> flood4cast@hydroscan.be  +
• Korte Beschrijving Overzicht van de … Korte Beschrijving </br> Overzicht van de DenCITY locaties in de smart Zone in Antwerpen </br> DenCITY is een real time luchtkwaliteitsmonitoring project in Antwerpen, waarbij luchtkwaliteitssensoren voor PM 10 , PM 2.5 , NO 2 en O 3 getest werden in labocondities en vervolgens geinstalleerd op 35 locaties in de Smart Zone in Antwerpen. Daarnaast werd een real-time versie van het ATMO-Street model opgezet en een data assimilatie keten die de real time sensor informatie verwerkte tot een verbeterde, ruimtelijk explicite, real time inschatting van de locale luchtkwaliteit in Antwerpen.</br> </br> Beschrijving Architectuur </br> Onderstaand diagram geeft een schematisch overzicht weer van de opgezette architectuur binnen DenCITY. </br> </br> </br> Databronnen </br> In DenCITY wordt data gegenereerd door low cost luchtkwaliteitssensoren , die sturen hun data via LoRa verbinding naar een IoT agent die de datastroom omzet naar NGSI-v2 om die vervolgens te posten op de DYAMAND Context broker . </br> Daarnaast werd ook gebruik gemaakt van de VMM luchtkwaliteitsmeetposten. De data hiervan wordt door IRCEL ontsloten via een OGC Sensor Observation Service waarlangs de real time luchtkwaliteitsmetingen van het telemetrisch netwerk als Open Data worden beschikbaargesteld. </br> Verkeerstellingen uit het telraam initiatief werden gebruikt om tot een verbeterde inschatting van verkeersemissies te bekomen in het luchtkwaliteitsmodel. Deze data worden via een REST-API [1] ter beschikking gesteld. </br> Informatie omtrent de gebouwhoogtes en de ligging van de straatsegementen om de street canyon bijdrage te kunnen berekenen in het luchtkwaliteitsmodel werden gedownload onder de vorm van shapefiles uit het 3D GRB , ter beschikking gesteld door AIV en van het Openstreetmap initiatief respectivelijk. </br> Real-time data flow </br> Toegevoegd</br> De real time sensor data wordt ter beschikking gesteld via een NGSI-v2 compliant context broker . Deze wordt gevoed vanuit de luchtkwaliteitssensoren via een NGSI Agent die de data vertaald in NGSI entities volgens het FIWARE AirQualityObserved data model. Meteo data afkomstig van het Europees Centrum voor Medium Range Weather Forecasts (ECMWF) wordt via REST-API binnengehaald en vertaald door een NGSI agent in een WeatherObserved entitie en zo op de context broker aangeboden. </br> Gezien de kwaliteit van de low cost sensor data niet altijd gegarandeerd is, werden uitgebreide labo tests uitgevoerd, op basis hiervan werden algoritmes opgesteld en een cloud gebaseerd real time calibratie systeem opgezet. Deze component maakt handig gebruik van de beschikbare meteo gegevens in de context broker (WeaterObserved entities). En pusht verrijkte AirQualityCalibrated entities terug op de broker. Deze component in de architectuur is geïmplementeerd als subscriber op de FIWARE AirQualityObserved en WeatherObserved entities in de context broker .</br> De data die op de context broker verschijnt wordt via een QuantumLeap REST service naar een tijdsreeks databank gestuurd op de [1] .</br> Naast de real time sensor gegevens is in deze proof of concept ook een real-time luchtkwaliteitmodel keten opgezet, waarbij de gecalibreerde luchtkwaliteits sensordata vanaf de context broker door een data assimilation agent worden geconverteerd naar CSV bestanden om te voldoen aan input vereisten van het luchtkwaliteitsmodel. Naast de real time low cost sensor metingen maakt het luchtkwaliteitsmodel ook gebruik van de VMM luchtkwaliteit referentiemetingen, die via Sensor Observation Service worden aangeboden. Het luchtkwaliteitsmodel haalt z'n meteo data uit de meteo service binnen via een specifieke API die toelaat om NetCDF bestanden te downloaden met 4D meteo model data. </br> De ruimtelijk expliciete modelkaarten die het resultaat zijn van de geassimileerde real time luchtkwaliteitsmodellering worden in een GIS databank bijgehouden en via een Geoserver als OGC Web Map Service ontsloten. Op die manier kon heel makkelijk een app gebouwd worden die een ruimtelijk expliciet beeld geeft van de actuele luchtkwaliteit.</br> </br> Referenties </br> </br> ↑ https://telraam-api.net/ </br> </br> </br> Lessons learned </br> Tegen volgende zaken zijn we aangebotst : </br> </br> eenvoudige beschrijving van geografische data in NGSI data model is onvoldoende, ontbreken van geospatiale functionaliteiten m.b.t. locaties </br> linken van meta data in geospatiale databanken aan real time dataflows : welk process opzetten om real time geospatiale meta data (e.g. opgeslagen in een PostgresSQL/PostGIS databank in sync te houden met real time IoT dataflows bij vervanging van sensoren & updates </br> sensor data postproductie nodig bij offline calibratie algoritmes, hoe omgaan met versiebeheer voor historische sensor data. </br> </br> </br> </br> </br> Deze pagina beschrijft een fictief initiatief dat als illustratie kan dienen voor de informatie die we wensen te capteren op de kennishub. Deze beschijving is gebaseerd op het oorspronkelijke DenCITY project, waarin de bedoeling was om een dicht stedelijk luchtkwaliteit sensornetwerk op te zetten en zo luchtkwaliteitsmodellen te verrijken met real time informatie. Deze illustratieve case werd verder verrijkt met enkele architecturale elementen, semantische links etc... om het ingeven van informatie op de kennishub te illustreren. Onderstaande beschrijving wijkt m.a.w. af van de originele opzet van het project.ele opzet van het project.  +
• Korte Beschrijving Overzicht van de … Korte Beschrijving </br> Overzicht van de DenCITY locaties in de smart Zone in Antwerpen </br> DenCITY is een real time luchtkwaliteitsmonitoring project in Antwerpen, waarbij luchtkwaliteitssensoren voor PM 10 , PM 2.5 , NO 2 en O 3 getest werden in labocondities en vervolgens geinstalleerd op 35 locaties in de Smart Zone in Antwerpen. Daarnaast werd een real-time versie van het ATMO-Street model opgezet en een data assimilatie keten die de real time sensor informatie verwerkte tot een verbeterde, ruimtelijk explicite, real time inschatting van de locale luchtkwaliteit in Antwerpen.</br> </br> Beschrijving Architectuur </br> Onderstaand diagram geeft een schematisch overzicht weer van de opgezette architectuur binnen DenCITY. </br> </br> </br> Databronnen </br> In DenCITY wordt data gegenereerd door low cost luchtkwaliteitssensoren , die sturen hun data via LoRa verbinding naar een IoT agent die de datastroom omzet naar NGSI-v2 om die vervolgens te posten op de DYAMAND Context broker . </br> Daarnaast werd ook gebruik gemaakt van de VMM luchtkwaliteitsmeetposten. De data hiervan wordt door IRCEL ontsloten via een OGC Sensor Observation Service waarlangs de real time luchtkwaliteitsmetingen van het telemetrisch netwerk als Open Data worden beschikbaargesteld. </br> Verkeerstellingen uit het telraam initiatief werden gebruikt om tot een verbeterde inschatting van verkeersemissies te bekomen in het luchtkwaliteitsmodel. Deze data worden via een REST-API [1] ter beschikking gesteld. </br> Informatie omtrent de gebouwhoogtes en de ligging van de straatsegementen om de street canyon bijdrage te kunnen berekenen in het luchtkwaliteitsmodel werden gedownload onder de vorm van shapefiles uit het 3D GRB , ter beschikking gesteld door AIV en van het Openstreetmap initiatief respectivelijk. </br> Real-time data flow </br> Toegevoegd</br> De real time sensor data wordt ter beschikking gesteld via een NGSI-v2 compliant context broker . Deze wordt gevoed vanuit de luchtkwaliteitssensoren via een NGSI Agent die de data vertaald in NGSI entities volgens het FIWARE AirQualityObserved data model. Meteo data afkomstig van het Europees Centrum voor Medium Range Weather Forecasts (ECMWF) wordt via REST-API binnengehaald en vertaald door een NGSI agent in een WeatherObserved entitie en zo op de context broker aangeboden. </br> Gezien de kwaliteit van de low cost sensor data niet altijd gegarandeerd is, werden uitgebreide labo tests uitgevoerd, op basis hiervan werden algoritmes opgesteld en een cloud gebaseerd real time calibratie systeem opgezet. Deze component maakt handig gebruik van de beschikbare meteo gegevens in de context broker (WeaterObserved entities). En pusht verrijkte AirQualityCalibrated entities terug op de broker. Deze component in de architectuur is geïmplementeerd als subscriber op de FIWARE AirQualityObserved en WeatherObserved entities in de context broker .</br> De data die op de context broker verschijnt wordt via een QuantumLeap REST service naar een tijdsreeks databank gestuurd op de [1] .</br> Naast de real time sensor gegevens is in deze proof of concept ook een real-time luchtkwaliteitmodel keten opgezet, waarbij de gecalibreerde luchtkwaliteits sensordata vanaf de context broker door een data assimilation agent worden geconverteerd naar CSV bestanden om te voldoen aan input vereisten van het luchtkwaliteitsmodel. Naast de real time low cost sensor metingen maakt het luchtkwaliteitsmodel ook gebruik van de VMM luchtkwaliteit referentiemetingen, die via Sensor Observation Service worden aangeboden. Het luchtkwaliteitsmodel haalt z'n meteo data uit de meteo service binnen via een specifieke API die toelaat om NetCDF bestanden te downloaden met 4D meteo model data. </br> De ruimtelijk expliciete modelkaarten die het resultaat zijn van de geassimileerde real time luchtkwaliteitsmodellering worden in een GIS databank bijgehouden en via een Geoserver als OGC Web Map Service ontsloten. Op die manier kon heel makkelijk een app gebouwd worden die een ruimtelijk expliciet beeld geeft van de actuele luchtkwaliteit.</br> </br> Referenties </br> </br> ↑ https://telraam-api.net/ </br> </br> </br> Lessons learned </br> Tegen volgende zaken zijn we aangebotst : </br> </br> eenvoudige beschrijving van geografische data in NGSI data model is onvoldoende, ontbreken van geospatiale functionaliteiten m.b.t. locaties </br> linken van meta data in geospatiale databanken aan real time dataflows : welk process opzetten om real time geospatiale meta data (e.g. opgeslagen in een PostgresSQL/PostGIS databank in sync te houden met real time IoT dataflows bij vervanging van sensoren & updates </br> sensor data postproductie nodig bij offline calibratie algoritmes, hoe omgaan met versiebeheer voor historische sensor data. </br> </br> </br> Deze pagina beschrijft een fictief initiatief dat als illustratie kan dienen voor de informatie die we wensen te capteren op de kennishub. Deze beschijving is gebaseerd op het oorspronkelijke DenCITY project, waarin de bedoeling was om een dicht stedelijk luchtkwaliteit sensornetwerk op te zetten en zo luchtkwaliteitsmodellen te verrijken met real time informatie. Deze illustratieve case werd verder verrijkt met enkele architecturale elementen, semantische links etc... om het ingeven van informatie op de kennishub te illustreren. Onderstaande beschrijving wijkt m.a.w. af van de originele opzet van het project.ele opzet van het project.  +
• Korte Beschrijving Achtergrond Door kl … Korte Beschrijving </br> Achtergrond </br> Door klimaatverandering nemen extreme zomerse onweersbuien toe in frequentie en intensiteit. Daarmee komen ook stedelijke overstromingen als gevolg van dergelijke regenbuien en als gevolg van toenemende urbanisatie steeds vaker voor. Dit is niet alleen vervelend, maar heeft ook een economische impact. Tegenwoordig treedt elke zomer wel ergens in Vlaanderen zware wateroverlast op als gevolg van hevige neerslag.</br> </br> Doelstelling </br> Het hoofddoel van dit project is aantonen dat we brandweer, nutsmaatschappijen, en burgers beter en proactief kunnen wapenen tegen overstromingsgevaar. We doen dit door verschillende facetten met elkaar te combineren: enerzijds maken we data meer granulair en dus nauwkeuriger door bestaande data met elkaar te koppelen en gepaste sensoren in te schakelen. Daarnaast willen we de verruimde data aan de hand van een voorspellingsmodel omzetten in informatie om overlast makkelijker te kunnen indiceren bij de brandweer en de diensten- en nutsmaatschappijen. Door de ontwikkeling van een end-to-end systeem dat deze voorspellingen duidt aan de hand van gevisualiseerde scenario's op een dashboard, proberen we de proactiviteitsvraag van de betrokken partijen te beantwoorden.</br> </br> Concrete meerwaarde voor de eindgebruiker </br> De primaire meerwaarde van dit project is de oplevering van een POC decision support system . Het betreft een tool die:</br> </br> de brandweer en nutsmaatschappijen waarschuwt bij naderende hevige neerslag. </br> ondersteunt in het nemen van proactieve beslissingen over hoe op de hevige neerslag wordt gereageerd (bijv. dispatching van de hulpdiensten naar specifieke locaties, inschakelen van pompen, etc.). Deze beslissingen werden tot nu toe vaak genomen tijdens of na de feiten. De verantwoordelijkheden voor de beslissingen liggen bij de eindgebruiker. </br> Concreet zijn binnen het project verschillende types sensoren geïnstalleerd in waterlopen en riolering, zijn diverse pluviometers geïnstalleerd ter ondersteuning van de neerslagradardata, heeft een gedetailleerde overstromingsmodellering plaatsgevonden, is een software-omgeving opgezet die neerslagdata omzet naar neerslagvoorspellingen en bijbehorende overstromingsverwachtingen tot op straatniveau, en is een viewer ontwikkeld waarbinnen de verzamelde real-time data en de voorspellingen worden getoond.</br> </br> Studiegebied </br> Het project werd uitgevoerd in een gebied in het noorden van Antwerpen dat ruwweg de deelgemeentes Ekeren en Merksem omvat.</br> </br> Beschrijving Architectuur </br> </br> Centraal in het dataflowschema bevinden zich de volgende Componenten :</br> </br> Dataplatform sensoren (met de gekoppelde LoRaWan-sensoren) </br> Flood4Cast® -voorspellingsalgoritme voor neerslagrisico’s en overstromingen. </br> Afwaarts werden deze Componenten via een API gekoppeld aan de gebruikersinterface.</br> In bovenstaande figuur worden alle interacties grafisch weergegeven.</br> </br> Data </br> Sensoren </br> In het kader van dit project werden in de regio Ekeren-Merksem in totaal 13 sensoren geïnstalleerd:</br> </br> 4 Decentlab pluviometers (type tipping bucket Young Model 52203) </br> 6 Decentlab ultrasone level sensoren Maxbotix </br> 3 Decentlab druksensoren voor rioolwaterhoogte </br> Radar </br> Daarnaast werd gebruik gemaakt van de neerslagradarbeelden die in real-time via een webdienst beschikbaar worden gesteld door de VMM . VMM combineert hiertoe de ruwe radarbeelden van drie radars tot een composietbeeld:</br> </br> Jabbeke (KMI) </br> Helchteren ( VMM ) </br> Herwijnen (KNMI, NL) </br> De radarbeelden zijn opnames op 1 km hoogte, en met een resolutie van 5 minuten. </br> </br> Overstromingskaarten </br> Een integraal model werd opgesteld voor het studiegebied in InfoWorks ICM (Innovyze). De volgende Componenten werden aangeleverd:</br> </br> Rioleringsmodel (Water-link) </br> Waterloopmodel ( VMM ) </br> Deze modellen werden gekoppeld en uitgebreid met een 2D hydrodynamische modellering van de oppervlakkige afstroming buiten de waterlopen tot een gebiedsdekkend integraal model.</br> Met behulp van het resulterende integrale model werden statische overstromingskaarten gegenereerd op basis van composietbuien met verschillende terugkeerperiodes. Deze overstromingskaarten werden opgeknipt voor verschillende deelgebieden. Hierdoor kunnen de overstromingskaarten worden getoond in functie van de optredende neerslag in de deelgebieden.</br> </br> Datatransmissie </br> Voor datatransmissie van de sensoren werd in dit project gebruik gemaakt van het LoRaWan-systeem. Waar mogelijk werden ook de sensoren in de riolering via een kabel verbonden met een bovengronds antennepaaltje. De sensoren hebben over het algemeen gedurende de hele periode zonder problemen hun metingen naar het dataplatform gestuurd. Het dataplatform werd via een API gekoppeld aan de gebruikersinterface.</br> In potentie kan het dataplatform via de API ook worden gekoppeld aan het Flood4Cast® -systeem en gebruikt worden om ook hydraulische randvoorwaarden in en buiten het gebied mee te nemen in de wateroverlastvoorspellingen: deze koppeling is gedurende het project uiteindelijk niet uitgevoerd.</br> Voor de radarbeelden bevraagt het Flood4Cast® -systeem de webdienst van VMM via een API .</br> </br> API </br> Alle voornoemde API -diensten zijn geïmplementeerd conform de REST -architectuur. Hierbij wordt het aantal endpoints naar de gebruiker en de informatie in de bestanden beperkt tot de strikt noodzakelijke data. Gedetailleerde documentatie van de API is beschikbaar voor de gebruiker. Het primair gehanteerde data-uitwisselingsformaat is JSON. Het gehanteerde bestandformaat door de open API van VMM voor de neerslagrasterdata is het HDF5 Opera bestandformaat. </br> </br> Gebruikersinterface (dashboard) </br> Een gebruikersinterface werd ontwikkeld voor de eindgebruikers. Hierin werd getoond:</br> </br> Neerslag(voorspelling): historische data en voorspelling ( nowcasting ) voor de komende 3 uur: deze nowcasting wordt uitgevoerd binnen Flood4Cast® en via een API in real time doorgegeven </br> Overstromingsvoorspelling: overstromingskaarten gekoppeld aan de gevallen neerslag (incl. voorspelling voor de komende 3 uur): deze overstromingskaarten worden vanuit Flood4Cast® via een API in real time doorgegeven </br> Sensor-data: locatie van de sensoren incl. type, status (connectiviteit, batterij) </br> De gebruikersinterface toont live beelden en voorspellingen. De gebruikersinterface bevatte tijdens het project tevens een switch om een specifieke historische neerslaggebeurtenis op te roepen (5 september 2018) waarbij effectief overstromingen optraden in het studiegebied. Hierdoor kan de tool ook worden gedemonstreerd wanneer het weinig of niet regent.</br> De gebruikersinterface toont getriggerde alarmen bij voorspelde wateroverlast.</br> </br> Alarmering </br> In het ontwikkelde systeem is het mogelijk de gebruiker te waarschuwen via:</br> </br> Dashboard </br> SMS </br> E-mail </br> Lessons learned </br> De prescreening van meettoestellen en locaties en stapsgewijze opschaling is essentieel bij de uitrol van grotere IoT monitoring netwerken. </br> Het opzetten van dergelijke meetsystemen vraagt:</br> brede applicatiekennis (locatieselectie in functie van datanood, dekking wireless communicatie, constructie en montage sensordrager); </br> onderhoud en opvolging tijdens de operationele fase. </br> Het analyseren van de neerslagradar is een essentieel onderdeel om de risico’s te kunnen inschatten in ruimte en tijd en om een forecasting te kunnen doen. </br> Op verschillende beslissingsniveaus wordt overstromingsinformatie op een andere schaal gebruikt. Primair is het belangrijker om over een groter gebied minder gedetailleerde overstromingsinformatie te hebben dan direct effectief tot op woningniveau het risico te gaan inschatten. </br> Verdere projectinformatie </br> </br></br> </br> Betrokken partijen: </br> IMEC , VITO , HydroScan, Brandweer Zone Antwerpen, water-link</br> </br> </br> Looptijd: </br> 2017 - 2019</br> </br> </br> Locatie: </br> Antwerpen</br> </br> </br> Financiering: </br> VLAIO </br> </br> </br> Meer informatie: </br> https://www . IMECcityofthings .be/en/projects/flooding-predicting-flood-levels  +
• Korte Beschrijving Achtergrond Door kl … Korte Beschrijving </br> Achtergrond </br> Door klimaatverandering nemen extreme zomerse onweersbuien toe in frequentie en intensiteit. Daarmee komen ook stedelijke overstromingen als gevolg van dergelijke regenbuien en als gevolg van toenemende urbanisatie steeds vaker voor. Dit is niet alleen vervelend, maar heeft ook een economische impact. Tegenwoordig treedt elke zomer wel ergens in Vlaanderen zware wateroverlast op als gevolg van hevige neerslag.</br> </br> Doelstelling </br> Het hoofddoel van dit project is aantonen dat we brandweer, nutsmaatschappijen, en burgers beter en proactief kunnen wapenen tegen overstromingsgevaar. We doen dit door verschillende facetten met elkaar te combineren: enerzijds maken we data meer granulair en dus nauwkeuriger door bestaande data met elkaar te koppelen en gepaste sensoren in te schakelen. Daarnaast willen we de verruimde data aan de hand van een voorspellingsmodel omzetten in informatie om overlast makkelijker te kunnen indiceren bij de brandweer en de diensten- en nutsmaatschappijen. Door de ontwikkeling van een end-to-end systeem dat deze voorspellingen duidt aan de hand van gevisualiseerde scenario's op een dashboard, proberen we de proactiviteitsvraag van de betrokken partijen te beantwoorden.</br> </br> Concrete meerwaarde voor de eindgebruiker </br> De primaire meerwaarde van dit project is de oplevering van een POC decision support system . Het betreft een tool die:</br> </br> de brandweer en nutsmaatschappijen waarschuwt bij naderende hevige neerslag. </br> ondersteunt in het nemen van proactieve beslissingen over hoe op de hevige neerslag wordt gereageerd (bijv. dispatching van de hulpdiensten naar specifieke locaties, inschakelen van pompen, etc.). Deze beslissingen werden tot nu toe vaak genomen tijdens of na de feiten. De verantwoordelijkheden voor de beslissingen liggen bij de eindgebruiker. </br> Concreet zijn binnen het project verschillende types sensoren geïnstalleerd in waterlopen en riolering, zijn diverse pluviometers geïnstalleerd ter ondersteuning van de neerslagradardata, heeft een gedetailleerde overstromingsmodellering plaatsgevonden, is een software-omgeving opgezet die neerslagdata omzet naar neerslagvoorspellingen en bijbehorende overstromingsverwachtingen tot op straatniveau, en is een viewer ontwikkeld waarbinnen de verzamelde real-time data en de voorspellingen worden getoond.</br> </br> Studiegebied </br> Het project werd uitgevoerd in een gebied in het noorden van Antwerpen dat ruwweg de deelgemeentes Ekeren en Merksem omvat.</br> </br> Beschrijving Architectuur </br> </br> Centraal in het dataflowschema bevinden zich de volgende Componenten :</br> </br> Dataplatform sensoren (met de gekoppelde LoRaWan-sensoren) </br> Flood4Cast® -voorspellingsalgoritme voor neerslagrisico’s en overstromingen. </br> Afwaarts werden deze Componenten via een API gekoppeld aan de gebruikersinterface.</br> In bovenstaande figuur worden alle interacties grafisch weergegeven.</br> </br> Data </br> Sensoren </br> In het kader van dit project werden in de regio Ekeren-Merksem in totaal 13 sensoren geïnstalleerd:</br> </br> 4 Decentlab pluviometers (type tipping bucket Young Model 52203) </br> 6 Decentlab ultrasone level sensoren Maxbotix </br> 3 Decentlab druksensoren voor rioolwaterhoogte </br> Radar </br> Daarnaast werd gebruik gemaakt van de neerslagradarbeelden die in real-time via een webdienst beschikbaar worden gesteld door de VMM . VMM combineert hiertoe de ruwe radarbeelden van drie radars tot een composietbeeld:</br> </br> Jabbeke (KMI) </br> Helchteren ( VMM ) </br> Herwijnen (KNMI, NL) </br> De radarbeelden zijn opnames op 1 km hoogte, en met een resolutie van 5 minuten. </br> </br> Overstromingskaarten </br> Een integraal model werd opgesteld voor het studiegebied in InfoWorks ICM (Innovyze). De volgende Componenten werden aangeleverd:</br> </br> Rioleringsmodel (Water-link) </br> Waterloopmodel ( VMM ) </br> Deze modellen werden gekoppeld en uitgebreid met een 2D hydrodynamische modellering van de oppervlakkige afstroming buiten de waterlopen tot een gebiedsdekkend integraal model.</br> Met behulp van het resulterende integrale model werden statische overstromingskaarten gegenereerd op basis van composietbuien met verschillende terugkeerperiodes. Deze overstromingskaarten werden opgeknipt voor verschillende deelgebieden. Hierdoor kunnen de overstromingskaarten worden getoond in functie van de optredende neerslag in de deelgebieden.</br> </br> Datatransmissie </br> Voor datatransmissie van de sensoren werd in dit project gebruik gemaakt van het LoRaWan-systeem. Waar mogelijk werden ook de sensoren in de riolering via een kabel verbonden met een bovengronds antennepaaltje. De sensoren hebben over het algemeen gedurende de hele periode zonder problemen hun metingen naar het dataplatform gestuurd. Het dataplatform werd via een API gekoppeld aan de gebruikersinterface.</br> In potentie kan het dataplatform via de API ook worden gekoppeld aan het Flood4Cast® -systeem en gebruikt worden om ook hydraulische randvoorwaarden in en buiten het gebied mee te nemen in de wateroverlastvoorspellingen: deze koppeling is gedurende het project uiteindelijk niet uitgevoerd.</br> Voor de radarbeelden bevraagt het Flood4Cast® -systeem de webdienst van VMM via een API .</br> </br> API </br> Alle voornoemde API -diensten zijn geïmplementeerd conform de REST -architectuur. Hierbij wordt het aantal endpoints naar de gebruiker en de informatie in de bestanden beperkt tot de strikt noodzakelijke data. Gedetailleerde documentatie van de API is beschikbaar voor de gebruiker. Het primair gehanteerde data-uitwisselingsformaat is JSON. Het gehanteerde bestandformaat door de open API van VMM voor de neerslagrasterdata is het HDF5 Opera bestandformaat. </br> </br> Gebruikersinterface (dashboard) </br> Een gebruikersinterface werd ontwikkeld voor de eindgebruikers. Hierin werd getoond:</br> </br> Neerslag(voorspelling): historische data en voorspelling ( nowcasting ) voor de komende 3 uur: deze nowcasting wordt uitgevoerd binnen Flood4Cast® en via een API in real time doorgegeven </br> Overstromingsvoorspelling: overstromingskaarten gekoppeld aan de gevallen neerslag (incl. voorspelling voor de komende 3 uur): deze overstromingskaarten worden vanuit Flood4Cast® via een API in real time doorgegeven </br> Sensor-data: locatie van de sensoren incl. type, status (connectiviteit, batterij) </br> De gebruikersinterface toont live beelden en voorspellingen. De gebruikersinterface bevatte tijdens het project tevens een switch om een specifieke historische neerslaggebeurtenis op te roepen (5 september 2018) waarbij effectief overstromingen optraden in het studiegebied. Hierdoor kan de tool ook worden gedemonstreerd wanneer het weinig of niet regent.</br> De gebruikersinterface toont getriggerde alarmen bij voorspelde wateroverlast.</br> </br> Alarmering </br> In het ontwikkelde systeem is het mogelijk de gebruiker te waarschuwen via:</br> </br> Dashboard </br> SMS </br> E-mail </br> Lessons learned </br> De prescreening van meettoestellen en locaties en stapsgewijze opschaling is essentieel bij de uitrol van grotere IoT monitoring netwerken. </br> Het opzetten van dergelijke meetsystemen vraagt:</br> brede applicatiekennis (locatieselectie in functie van datanood, dekking wireless communicatie, constructie en montage sensordrager); </br> onderhoud en opvolging tijdens de operationele fase. </br> Het analyseren van de neerslagradar is een essentieel onderdeel om de risico’s te kunnen inschatten in ruimte en tijd en om een forecasting te kunnen doen. </br> Op verschillende beslissingsniveaus wordt overstromingsinformatie op een andere schaal gebruikt. Primair is het belangrijker om over een groter gebied minder gedetailleerde overstromingsinformatie te hebben dan direct effectief tot op woningniveau het risico te gaan inschatten. </br> Verdere projectinformatie </br> </br></br> </br> Betrokken partijen: </br> IMEC , VITO , HydroScan, Brandweer Zone Antwerpen, water-link</br> </br> </br> Looptijd: </br> 2017 - 2019</br> </br> </br> Locatie: </br> Antwerpen</br> </br> </br> Financiering: </br> VLAIO </br> </br> </br> Meer informatie: </br> https://www . IMECcityofthings .be/en/projects/flooding-predicting-flood-levels  +
• Korte Beschrijving B-WaterSmart [1] is e … Korte Beschrijving </br> B-WaterSmart [1] is een Europees Horizon 2020 project, binnen dit project zal een pilot plaatsvinden in Mechelen. </br>In het kader van het rioleringsproject Bankstraat – Zepstraat – Gijsbeekstraat werd riolering (DWA en RWA) vernieuwd. Om te voldoen aan de bufferingseis dient nog een bufferbekken aangelegd te worden met een buffercapaciteit van 270 m³/ha en een lozingsnorm van 10 l/s/ha. </br>Dit bufferbekken was enkel voorzien als een reservoir om het verzamelde hemelwater van de verharde oppervlakte tijdelijk te bergen en vertraagd te lozen naar waterloop Dorpsloop 1.05 (3e categorie), in beheer van Provincie Antwerpen.</br>Het project B-WaterSmart is een opportuniteit om het hemelwater uit het bufferbekken te hergebruiken voor irrigatie van landbouwpercelen. Daarvoor moeten volgende aanpassingen gebeuren:</br> </br> Het bufferbekken wordt voorzien van een regelbare schuif die de doorvoer kan tegenhouden; </br> Er wordt een zuiveringsinstallatie voorzien om het hemelwater te zuiveren tot een kwaliteit voldoende om gewassen te irrigeren, </br> Er worden sensoren voorzien om de neerslag opwaarts te meten, de waterkwaliteit van het water in het bufferbekken, bodemvochtigheid in de landbouwpercelen, het grondwaterpeil in de landbouwpercelen en het waterpeil in het bufferbekken, </br> Er wordt (mobiele) infrastructuur voorzien om het gezuiverde water uit het bekken te transporteren naar de landbouwpercelen. </br> Stad Mechelen wil deze use-case binnen het traject i.k.v. een centrale (IoT) data-infrastructuur waardoor het versnipperd gebruik van data-bronnen binnen de organisatie wordt tegengaan en smart city oplossingen in de stad sneller kunnen opschalen, alsook middelen en expertise worden samengebracht.</br> Het project loopt van 1/9/2020 – 31/8/2024. </br> </br> Beschrijving Architectuur </br> Lessons learnedr Lessons learned  +
• Korte Beschrijving Bestuursdocumenten (r … Korte Beschrijving </br> Bestuursdocumenten (reglementen, verslagen, vergunningen, vragen en antwoorden) zijn de basis van de besluitvorming en geven heel goed weer hoe het bestuur en de administratie werken. De digitale ontsluiting georganiseerd rond informatie over het document is goed georganiseerd. Er zijn nog noden binnen en buiten de organisatie rond toegankelijkheid, doorzoekbaarheid en bruikbaarheid van de rijkdom aan informatie besloten in de documenten zelf. </br> Met dit project, Proactieve Openbaarheid van Bestuur als Linked open data (POBLOD) willen we kapitaliseren op de resultaten van een aantal innovatieve deeltrajecten uit het verleden, en een schaalbare oplossing voorstellen en implementeren met impact binnen en buiten de organisatie. </br> Het vertrekpunt is dat we tastbare assets van het besluitvormingsproces, incl de video- en geluidsopnamen van de zittingen, willen indexeren en mappen op bestaande en te ontwikkelen semantische modellen. Deze worden gekoppeld aan bestaande en te ontwikkelen Linked open data definities (bvb de set gehanteerd in het Lokale Besluiten als Linked open data van de Administratie Binnenlands Bestuur en de set rond geografische afbakeningen op het Gents grondgebied). </br> De (her)bruikbaarheid wordt onderzocht en gevalideerd door:</br> een intern traject binnen de administratie, gefocust op dossiervoorbereiding </br>een traject rond externe bruikbaarheid door de doorzoekbaarheid van de documenten o.a. via een chatbot mogelijk te maken </br>de haalbaarheid van een dashboard te onderzoeken waar ook het audiovisueel materiaal ontsloten wordt </br>de machine-readability bewezen wordt door algoritmes te ontwerpen die op basis van semantische concepten geagendeerde en goedgekeurde stukken op wijksites kan plaatsen, of volgens aangegeven interesses aan individuele burgers kan bezorgd worden </br>Concreet verhoogt dit voorstel de transparantie van beleidsbeslissingen aanzienlijk, en kan de burger niet alleen gemakkelijker maar zelfs quasi-moeiteloos informatie over beleidsbeslissingen verkrijgen. Om dit te illustreren met enkele voorbeelden maakt dit project het mogelijk om interesse in een bepaald thema (bvb. sport) aan te geven, en vervolgens een e-mail te ontvangen als dit thema op de agenda van de gemeenteraad komt. Eenmaal er een besluit genomen is op de gemeenteraad kan ook dit besluit in de mailbox belanden. Als tweede voorbeeld maakt dit project het ook mogelijk om informatie relevant voor een bepaalde wijk rechtstreeks op de wijksite te plaatsen. Als derde voorbeeld wordt het aanzienlijk eenvoudiger om reglementeringen of besluiten op te zoeken, gezien zoeken nu gebaseerd is op semantische linken. Het niet ingeven van een correcte term zorgt er dan niet langer voor dat bepaalde info niet teruggevonden kan worden.</br> </br> Beschrijving Architectuur </br> Lessons learnedeschrijving Architectuur Lessons learned  +
• Korte Beschrijving Binnen ORB (project O … Korte Beschrijving </br> Binnen ORB (project Online Reserveren en Betalen) bestaat een nood aan een gestandaardiseerd vocabularium en applicatieprofiel voor de uitwisseling van data tussen verschillende toepassingen. Dit kan gaan om het makkelijk overstappen van 1 software pakket op het andere, maar vooral om integratie tussen verschillende systemen zoals voor beheer van het aanbod (sporttereinen in een planningstool voor jaarwerking clubs vs online verhuur aan particulieren) en facturatie decentraal beheerd door de verschillende diensten van de Stad Gent van verschillende types locaties.</br> Er is daarom een nood om aanbod, beschikbaarheid en consumptie van locaties en diensten eenduidig te beschrijven in een werkgroep met zoveel mogelijk betrokken actoren. Het primaire doel van de werkgroep is zeer duidelijke afspraken te definiëren over wat er wordt uitgewisseld. Een secundair doel is het creëren van een draagvlak voor het</br>applicatieprofiel door zoveel mogelijk spelers van in het begin te betrekken.</br> Er zijn redelijk wat vocabularia die kunnen hergebruikt worden ( OSLO gebouwenregister, OSLO Dienst, OSLO Organisatie, Good relations, schema.org, IoT-lite) en ook een aantal basisregisters (wegwijs, vkbo, gebouwenregister) die interessant zijn voor ORB. Echter zonder verduidelijking welke termen uit bovenstaande vocabularia gebruikt worden en hoe deze zich met elkaar verhouden (overlap, relaties tussen de verschillende vocabularia) zou het voor een software ontwikkelaar zeer moeilijk worden om deze vocabularia correct toe te passen.</br> Use case: sportterrein in de stad (in sporthal of buiten)</br> </br> Beschrijving Architectuur </br> Lessons learnedg Architectuur Lessons learned  +
• Korte Beschrijving Dat droogte een prang … Korte Beschrijving </br> Dat droogte een prangend probleem is in Vlaanderen, België en wereldwijd, staat als een</br>paal boven water. </br>Uit die problematiek is WerfWater ontstaan. Met een platform dat de</br>vraag en het aanbod van water samenbrengt, geeft deze startup bemalingswater een tweede leven.</br> </br>Waarom bemalingswater?</br> Bij bouwprojecten waar diepe fundering en/of kelder geplaatst wordt is het noodzakelijk dat er bemaald wordt. Dit wil zeggen dat er water onttrokken wordt uit de bodem. In eerste instantie wordt er gekozen om terug te gaan infiltreren in de bodem. </br> Maar in de praktijk gebeurt dit slechts in ongeveer 15% van alle bemalingen. In de andere 85% van de gevallen wordt dit water geloosd in waterlopen en in de riolering.</br> Dit water wil WerfWater op nationaal (en in de toekomst ook internationaal) gratis aanbieden voor lokaal gebruik door bijvoorbeeld particulieren, landbouwers, groendiensten, brandweer en sportterreinen.</br>Hierdoor worden waterverspilling en droogte tegengegaan.</br>WerfWater verbindt dit aanbod met vragende partijen.</br> </br>Momenteel wordt de eerste versie van het platform getest aan de hand van pilot cases.</br> WerfWater wil in dit verhaal nog een stapje verder gaan. Dit willen ze doen door de</br>ontwikkeling van een container met geïntegreerde IoT sensoren. Deze sensoren meten de</br>kwaliteit, het opgepompte volume en het hergebruikte volume.</br>Via het platform kunnen steden en gemeenten, bemalers en bouwbedrijven dan het</br>opgepompte volume opvolgen.</br> De container zelf zal voorzien worden van een beluchtingssysteem en verschillende</br>aansluitflenzen zodat er altijd een passende aansluiting is voor de verschillende afnemers.</br>Het container design is af en de specifieke sensoren die gaan getest worden momenteel onderzocht.</br> </br> Beschrijving Architectuur </br> Lessons learnedg Architectuur Lessons learned  +
• Korte Beschrijving Data die gegenereerd … Korte Beschrijving </br> Data die gegenereerd wordt rond de fysieke locaties van mobipunten via API ontsluiten naar het bredere palet aan mobiliteitsplatformen in Vlaanderen.</br> Projectkader:</br> De mobipunten vormen een belangrijke sleutel in het Vlaamse mobiliteitsbeleid. Ook in het brede netwerk van open informatie in Vlaanderen is een rol voor deze mobipunten weggelegd. Naast het feit dat de mobipunten een ruimtelijke referentie hebben, kunnen zij ook dienen als ankerpunt voor aanvullende data. Realtime vervoersinformatie, de aanwezigheid van mobiliteitsopties en -diensten alsmede automatisch gegenereerde data vanuit sensoren kunnen worden gerelateerd aan de fysieke locaties van mobipunten. Dit creëert tal van mogelijkheden tot integraties met algemene reisplanner-toepassingen, planmakers bij lokale overheden, et cetera. Concreet wordt er gewerkt aan een API om de volgende mobipunt-gerelateerde data te ontsluiten:</br> </br> Regel in ongenummerde lijst (Anonieme) Gebruikersdata: Lokale algemene gebruikersstatistieken, beoordelingen, resultaten van bevragingen, … </br> Regel in ongenummerde lijst Lokale data: Lokaal verkregen data betreffende vervoersaanbod, aanwezige diensten, toeristische informatie, lokale bijzonderheden, ... </br> Regel in ongenummerde lijst Sensordata: Optionele aanwezigheid van verschillende typen sensoren die kunnen ondersteunen bij het directe gebruik (cf parkeergelegenheid) alsmede input kunnen vormen voor lokaal onderzoek of specifieke problematieken (luchtkwaliteit, …). </br> Bestand:VLOKA-Traject-Mobipunten.pdf </br> </br> Beschrijving Architectuur </br> Lessons learnedctuur Lessons learned  +
• Korte Beschrijving De ‘urban digital twi … Korte Beschrijving </br> De ‘urban digital twin’ van Brugge maakt het mogelijk om maatregelen op voorhand te simuleren, waaronder luchtkwaliteit, verkeerstromen en geluidshinder. De digitale kopie wordt gevoed met real-time data om een accuraat resultaat te verkrijgen. Onderzoekscentrum imec bundelt de publieke en private spelers tot een breedgedragen standaard.</br> Het innovatieproject verloopt in drie fasen. Tegen het einde van 2020 worden diverse databronnen in Brugge gebundeld in één dashboard. Hiermee krijgen beleidmakers een duidelijk beeld van onder andere de luchtkwaliteit en verkeerstromen.</br> De tweede fase biedt de mogelijkheid om voorspellingen te maken binnen een specifiek domein. Denk bijvoorbeeld aan een verkeerssituatie voor en na en bepaalde interventie. In een derde en laatste fase moet het mogelijk zijn om beslissingen over verschillende beleidsdomeinen te testen.</br> </br> Scope </br> This open innovation project will run in three phases.</br> </br> In phase one and by the end of this year, various data sources in Bruges will be made available and combined into a single dashboard that immediately gives policymakers a clear insight into issues such as air quality and traffic flows in the city. </br> Phase two will enable predictions to be made in individual areas, such as by comparing the traffic situation before and after a specific action has been taken. </br> The ultimate aim of this digital ‘control room’ is to be able to thoroughly test decisions taken on a range of policy issues. Imec will be involved as a research center, working with public and private players (smart city platforms, data and modeling providers, IoT sensor suppliers, cloud providers, etc.) to arrive at widely supported standards. Imec and the City of Bruges are looking to collaborate with manufacturers, estate experts and other cities in order to speed up the development of urban digital twins in Flanders by drawing on open data. </br> Domains </br> Traffic Management </br> Air Quality </br> Partners </br> Stad Brugge </br> Imec </br> Cegekageka  +
• Korte Beschrijving De Naamsestraat in Le … Korte Beschrijving </br> De Naamsestraat in Leuven is één van de 5 zogenaamde “doortrekkersstraten” waarlangs mensen uit het uitgaanscentrum van Leuven terugkeren naar huis. ’s Nachts levert dit regelmatig problemen op zoals rondslingerend afval, vandalisme, storend gedrag en ook nachtlawaai.</br> Met dit project wil de stad Leuven , op een niet-repressieve manier, in een deel van de Naamsestraat storend straatnachtlawaai capteren om zicht en greep te krijgen op het probleem en deze data tegelijkertijd gebruiken om real time nudging technieken aan te sturen om het nachtlawaai wanneer het zich voor doet te verminderen.</br> Met deze aanpak kunnen we a) actiegedreven nudging technieken uittesten in een living lab opstelling, b) storend straatnachtlawaai geautomatiseerd definiëren wat ons kan helpen in de aanpak van deze problematiek in de rest van Leuven , c) storend straatnachtlawaai in kaart brengen en zo het probleem objectiveren zonder dat er manuele melding moeten worden gemaakt bij of moet worden ingegrepen door de politie, d) analyseren op welke momenten en door welke externe parameters storend nachtlawaai wordt geïntensifieerd en zo predictieve modellen opzetten die politie, stewards of nachtwachten kunnen helpen in betere planning van de interventies en ingrepen.</br> De doelstelling binnen dit traject is om te zien hoe een specifieke aanbesteding binnen het VLAIO CoT Nachtlawaai project al kan aligneren op interop niveau met VLOCA principes. Daarvoor werd een interop compliance matrix opgeverd die er als volgt uit ziet :</br> </br> </br> De belangrijke doelstelling hier is om binnen een beperkt aanbestedingsbudget toch al aandacht te voorzien om meer functionele oplossings gerichte aanbieders (vertikaal) toch al in de richting te bewegen van een meer horizontale benadering, om bijvoorbeeld beter te integreren met het toekomstige Smart City Data Platform van Brugge/Roeselare/Leuven.</br> Meer context hieromtrent werd verwerkt in de Coock Open Stad workshop die hier te vinden in : https://vloca-kennishub.vlaanderen.be/vloca-kennishub/File:Coock_workshop_feb_Stefan.pdf , waar een geleidelijke benadering van meer functioneel vertikaal gerichte aanbestedingen stapsgewijs kan ge"horizontaliseerd" worden door dit type interop compliancy scores.</br> </br> </br> Beschrijving Architectuur </br> Nog niet bekend</br> </br> Lessons learned  +
• Korte Beschrijving Hoe ziet de huidige s … Korte Beschrijving </br> Hoe ziet de huidige situatie eruit</br> (Samen)Leefbaarheid in de stad</br>Als stad krijgen we dagelijks meldingen en klachtenbrieven rond de onmiddellijke leefomgeving van de burger. De top vijf van de meldingen van de stad gaan over: sluikstort, het straatbeeld (focus op interventies in het openbaar domein), stadsloketten, mobiliteit (focus op parkeren) en overlast.</br> Onze ambities om én een veilige en leefbare stad te zijn én om een levendige, aantrekkelijke stad te zijn waar jongeren en bezoekers graag vertoeven, zijn niet makkelijk te verzoenen. Dit brengt spanningen en soms zelfs onvrede met zich mee.</br> Stad Antwerpen wil technologie inzetten om tot proactieve, gedragen oplossingen te komen waarbij er sturing en verbinding is richting consensus en waar we minder repressief moeten optreden. Met andere woorden hoe kan technologie bijdragen tot een beter evenwicht tussen een levendige en leefbare studentenbuurt.</br> Focus op de universiteitsbuurt in het historisch centrum</br> Rond de stadscampus in het historisch centrum van de stad Antwerpen doen zich overlastproblemen voor. Het buurtcomité signaleerde een aantal problemen zoals de lawaaioverlast, wildplassen, braken, peuken, sluikstorten, ...</br> In de universiteitsbuurt moeten de verschillende betrokkenen zoals bewoners, bedrijven, verschillende onderwijsinstellingen en studenten samen een prettige leefomgeving creëren.</br> De bedrijfseenheid maatschappelijke veiligheid wil, samen met alle andere betrokken diensten, op een gecoördineerde manier de overlastfenomenen in kaart brengen en op de verschillende problemen en uitdagingen een gepast antwoord bieden, ook met de inzet van innovatieve, technologische oplossingen die in overeenstemming rijn met de GDPR-wetgeving.</br> Wat willen we verbeteren?</br>Technologie moet ons helpen overlast van asociaal (feest)gedrag te beperken en/of sociaal gedrag te stimuleren (nudgen).</br> Onder asociaal (feest)gedrag verstaan we:</br>- afval (sluikstort, zwerfvuil, bijzetgedrag, hondenpoep, peuken, …)</br>- wildplassen</br>- vandalisme</br>- braken</br>- (nacht)lawaai</br>- …</br> De innovatieve en technologische oplossing draagt bij tot het aanpakken van minstens 1 van de hierboven vernoemde overlastfenomenen en minstens 1 van onderstaande doelen:</br>- het stimuleren van sociaal (feest)gedrag;</br>- het voorkomen of ontraden van asociaal (feest)gedrag;</br>- het efficiënt oplossen van de negatieve gevolgen van (a)sociaal (feest)gedrag.</br> Er is ruimte om naar alle types oplossingen te kijken waarbij nieuwe technologieën kansen bieden om het probleem nog beter te adresseren. We zoeken een mature oplossingen en ‘ready-to-market’ is. </br> </br> Beschrijving Architectuur </br> Technische en architecturale verwachtingen (cfr. ACPaaS, SA2020 en DaaS Standaarden )</br>Digipolis heeft een centraal platform, het Antwerp City Platform (ACPaaS). We verwachten van onze partners en leveranciers dat ze maximaal verder bouwen aan en op dit platform. Het platform bevat bouwblokken, waaronder ACPaaS engines, Centrale referentiesystemen (CRS) voor data, Standaarden in technologie, architecturale principes, UI-building blocks enzovoort. </br>Voor meer informatie over ACPaaS kan je terecht op https://acpaas.digipolis.be/ . </br> We verwachten </br>- dat offertes in lijn zijn met de principes van dit platform: huisstijl, , DAAS Standaarden , Software Architectuur 2020, API requirements, privacy by design, security by design, event requirements, testing,... zijn te vinden op https://acpaas.digipolis.be/nl/docs/resources </br>- dat de building blocks van ACPaaS maximaal gebruikt worden (ACPaaS engines, ACPaaS UI- Componenten , starterkits,...);</br>- dat de offertes waar mogelijk herbruikbare Componenten toevoegen aan het platform.</br> Daarnaast verwachten we uiteraard een professionele manier van werken met testing, documentatie, gebruik van development-, acceptatie- en productieomgeving, oplevering van een systeem met monitoring en logging, en dergelijke meer. </br> Alle info op https://acpaas.digipolis.be/ . </br> Tevens past dit project in een ruimer kader van Vlaamse Open City Architectuur (VLOCA).</br> We verwachten in deze context dat:</br>- de offertes in lijn zijn met de principes van deze architectuur;</br>- de oplossingsarchitectuur waar mogelijk beschreven wordt dmv de semantische annotaties binnen VLOCA ( https://vloca-kennishub.vlaanderen.be/vloca-kennishub/Semantische_annotaties )</br> </br> </br> Lessons learned  +
• Korte Beschrijving In samenwerking met s … Korte Beschrijving </br> In samenwerking met scholen wordt een IoT netwerk van pluviometers uitgebouwd om een beter zicht te krijgen op de ruimtelijke verdeling van neerslag over het grondgebied. De verzamelde data wordt in real time ter beschikking gesteld via een API, zodat een beter zicht kan bekomen worden op de effectieve neerslagverdeling. Dit stelt de lokale waterbeheerders in staat om sneller actie te ondernemen om overstromingen te voorkomen.</br>Dit project wordt gekoppeld aan een educatief traject waarbij leerlingen via een 3D printer een pluviometer maken, de elektronica monteren en de resultaten testen en analyseren. Hierbij worden ze uitgedaagd om na te denken over nieuwe technieken zoals IoT en 3D printen. Op basis van de meetresultaten gaan ze aan de slag met weer en klimaat(verandering) maar ook wiskundige zaken zoals nauwkeurigheid en statistiek.</br> </br> Beschrijving Architectuur </br> Datanodes op basis van WIFI, Sigfox of LoRa</br>Cloudplatvorm met MQTT broker, database en visualisatie.</br> De architectuur is nog onder ontwikkeling.</br> </br> Lessons learnednog onder ontwikkeling. Lessons learned  +
• Korte Beschrijving Met het project IoT- … Korte Beschrijving </br> Met het project IoT- peilsensoren zet de VMM samen met de 5 provinciale waterloopbeheerders in op het ontsluiten van een fijnmaziger netwerk aan waterpeilgegevens. In een eerste fase worden 50 sensoren op onbevaarbare waterlopen in Vlaanderen online gebracht.</br>Een dichter netwerk van low cost IoT- peilsensoren levert real time data die via een webservice-platform open ontsloten worden. De data dient maximaal te kunnen doorstromen naar andere IoT-stacks.</br> De koppeling naar andere dataplatformen moet de uitwisselbaarheid van de data verhogen en data-combineerbaarheid stimuleren.</br>Het beschikbaar stellen van een gestandaardiseerde workflow kan andere lokale waterloopbeheerders (steden, gemeenten, ..) stimuleren hierop aan te sluiten.</br> </br> Beschrijving Architectuur </br> Onderstaand schema geeft het overzicht van de in opbouw zijnde architectuur en de dataflow ( use case: VMM project Machine Learning toepassing voor laagwatervoorspellingen op onbevaarbare waterlopen adhv open data) .</br> </br> </br> </br> Databronnen </br> In opdracht van de VMM wordt een ‘Machine Learning- toepassing voor laagwatervoorspellingen op onbevaarbare waterlopen adhv open data’ uitgetest en wordt gebruikt als use case (binnen het VMM project). De inzetbaarheid van de fijnmazige IoT-sensordata in learning-toepassing voor laagwater debietvoorspellingen obv. open datasets maakt deel uit van de opdracht.</br> De webdiensten van waterinfo.be ontsluiten waterkwantiteitsgegevens voor zowel meetdata op punt locaties (puntdata) via de REST-API service naar waterinfo.be als voor ruimtelijk-temporele data over Vlaanderen (rasterdata) via REST-API service naar hydro.vmm.be.</br> Daarnaast wordt gebruikt gemaakt van de ECMWF (Europees Centrum voor Medium Range Weather Forecasts) datasets (via het KMI) mbt de voorspelde neerslag, verdamping en temperatuur (in NetCDF ) voor de medium (15 daagse voorspelling) en extended range (46 daagse voorspelling).</br> Verder zal gebruik gemaakt worden van geodata (Geoserver WMS/WFS) voor de gegevens van de stroomgebiedseigenschappen alsook is het de bedoeling om andere externe datasets voor hydro-meteo data (ERA5, COPERNICUS data) in te zetten.</br> </br> Real-time dataflow </br> Real time hydro-meteorologische sensordata waaronder voor IoT- sensoren (puntdata) en hun metadata worden doorgestuurd via een GPRS- verbinding en als open data via de webdienst waterinfo.be ontsloten.</br>Hierbij wordt gebruik gemaakt van een REST-API service.</br> De data wordt ‘geautomatiseerd’ gevalideerd in het waterinfo backend-databeheersysteem en krijgt per tijdstap een quality flag.</br>De service ondersteunt een aantal formaten zoals html , Waterml2 , json , kml , csv , …</br> De data kan van hieruit gekoppeld worden met andere context brokers en IoT stacks.</br>De service kan anoniem aangeroepen worden met restrictie op aantal gegevens en aantal requests via een dedicated token voor geautomatiseerde data-bevraging.</br> </br>In het project kan de inzet van een ‘kortere dataketen’ naar de context broker verkend worden. De opmaak van een maximaal efficiënte architectuur en de dataflow maakt deel uit van de VMM doelstellingen binnen dit VLOCA initiatief.</br> </br> Lessons learned  +
• Korte Beschrijving Mobipunten bieden de … Korte Beschrijving </br> Mobipunten bieden de kans om (voor)stedelijke mobiliteit minder auto-afhankelijk te maken door duurzame en combimobiele oplossingen te faciliteren. Deze mobipunten vormen essentiële schakelpunten in het mobiliteitsnetwerk van de toekomst. De investering in mobipunten gebeurt in belangrijke mate door lokale besturen. De inpassing binnen het netwerk gebeurt bij voorkeur op een doordachte en datagestuurde manier.</br> Parallel aan de tendens naar combimobiliteit is er een revolutie aan de gang binnen de mobiliteit waarbij steeds meer nieuwe mobiliteitsvormen hun ingang vinden. De nieuwe mobiliteitsvormen zijn (1) veelal elektrisch aangedreven, (2) veelal gedeelde systemen via lidmaatschap en (3) veelal te gebruiken via een app op de smartphone. Beide tendensen versterken elkaar. De nieuwe mobiliteitsvormen verhogen de mogelijkheden om combimobiele oplossingen aan de reizigers aan te bieden, terwijl mobipunten het gebruik van de nieuwe mobiliteitsvormen kunnen ondersteunen.</br> Binnen dit project gaat de stad Stad Aalst samen met de omliggende steden en gemeenten Denderleeuw, Erpe-Mere, Haaltert, Lede en Ninove en met ondersteuning van de intergemeentelijke samenwerkingsverbanden SOLVA en Leiedal op zoek hoe de kennis van vandaag gebruikt kan worden voor de mobipunten van de toekomst. Met data die (deel)fietsen, (deel)wagens, e-steps, parkeersensoren… vandaag verzamelen wordt een analysemodel ontwikkeld om de inpassing van mobipunten in het mobiliteitsnetwerk te sturen, te objectiveren en te evalueren.</br> Het project kan rekenen op de ondersteuning van Mobipunt VZW , een consortium van mPact, Autodelen.net en Infopunt Publieke Ruimte dat het concept mobipunten lanceerde in Vlaanderen en de Vlaamse klankbordgroep mobipunten aanstuurt. </br> Het project wordt gefinancierd door VLAIO in het kader van de oproep City of Things .</br> Voor de uitvoering van het project wordt samengewerkt met een consortium van inhoudelijke en technische partners: Anyways , BDO Crossroad en Geosparc .</br> </br> Beschrijving project </br> Fase 1: bepalen wensen beleidsanalyse </br> </br> De doelstelling van de eerste fase van het project is het scherpstellen van de uitdaging vanuit het werkveld. Waarom willen steden en gemeenten investeren in hoppinpunten (of mobipunten)? Dat is het uitgangspunt van een online bevraging die in 2020 werd gelanceerd bij beleidsmakers in Vlaanderen.</br> De overtuiging is dat mobipunten zullen bijdragen aan combimobiliteit. Mobipunten worden als essentiële schakels gezien om het mobiliteitssysteem te verduurzamen. Ze moeten helpen om nieuwe mobiliteitsvormen zoals deelmobiliteit mainstream maken, het openbaar vervoer faciliteren en bovenal minder autokilometers en meer duurzame verplaatsingen bevorderen. Zo dragen mobipunten meteen ook rechtstreeks bij tot de klimaatdoelstellingen, leefbare kernen en hebben ze een positieve impact op verkeersveiligheid en luchtkwaliteit.</br> Raadpleeg hier het rapport over fase 1 </br> </br> Fase 2: data-ontsluiting </br> Vertrekkende van de analyse gedaan in fase 1, wordt een lijst gemaakt van de te verzamelen noodzakelijke datasets. Vervolgens wordt voor elke nood een lijst gemaakt van kandidaat datasets. Deze datasets worden vergeleken op basis van kwaliteit in al zijn aspecten, beschikbaarheid, technische factoren zoals beschikbaarheid van een API en kost. Op basis van deze analyse zal de uiteindelijke keuze van datasets worden bepaald.</br> Raadpleeg hier het rapport over fase 2 </br> </br> Fase 3: opmaken beleidsanalysetool </br> De doelstelling van het project is om een proof of concept te ontwikkelen van een tool/dashboard dat geschikt is voor beleidsanalyse rond mobipunten. Hierbij worden verschillende analyses gecombineerd op basis van IoT-data uit de mobiliteitswereld.</br> De tool moet geschikt zijn voor beleidsanalyse: </br> </br> Bij investeringen in nieuwe mobipunten. De aanleg van nieuwe mobipunten in het publieke domein vraagt een sterke financiële inspanning van de wegbeheerder. Bovendien is er vaak een grote concurrentie tussen verschillende ruimtevragers in een beperkte ruimte. In deze fase van beleidsanalyse moet de tool dus voornamelijk geschikt zijn om verschillende locaties tegenover elkaar af te wegen en te bepalen wat de meest zinvolle investeringen zijn. </br> Bij evaluatie van bestaande mobipunten. Een (voor)stedelijke mobiliteitsnetwerk is steeds in ontwikkeling. Gezien mobipunten de cruciale schakels vormen binnen het multimodaal netwerk, zullen ook deze mobipunten steeds in ontwikkeling zijn. In deze fase moet beleidsanalyse zich daarom richten op een periodieke evaluatie van de effecten van een mobipunt. Ervaringen van wat goed of minder goed werkt op een mobipunt kunnen hierbij leiden tot inzichten om tot betere mobipunten op gelijkaardige plaatsen te komen. </br> Raadpleeg hier het rapport over fase 3 rapport over fase 3  +
• Korte Beschrijving Mobipunten bieden de … Korte Beschrijving </br> Mobipunten bieden de kans om (voor)stedelijke mobiliteit minder auto-afhankelijk te maken door duurzame en combimobiele oplossingen te faciliteren. Deze mobipunten vormen essentiële schakelpunten in het mobiliteitsnetwerk van de toekomst. De investering in mobipunten gebeurt in belangrijke mate door lokale besturen. De inpassing binnen het netwerk gebeurt bij voorkeur op een doordachte en datagestuurde manier.</br> Parallel aan de tendens naar combimobiliteit is er een revolutie aan de gang binnen de mobiliteit waarbij steeds meer nieuwe mobiliteitsvormen hun ingang vinden. De nieuwe mobiliteitsvormen zijn (1) veelal elektrisch aangedreven, (2) veelal gedeelde systemen via lidmaatschap en (3) veelal te gebruiken via een app op de smartphone. Beide tendensen versterken elkaar. De nieuwe mobiliteitsvormen verhogen de mogelijkheden om combimobiele oplossingen aan de reizigers aan te bieden, terwijl mobipunten het gebruik van de nieuwe mobiliteitsvormen kunnen ondersteunen.</br> Binnen dit project gaat de stad Stad Aalst samen met de omliggende steden en gemeenten Denderleeuw, Erpe-Mere, Haaltert, Lede en Ninove en met ondersteuning van de intergemeentelijke samenwerkingsverbanden SOLVA en Leiedal op zoek hoe de kennis van vandaag gebruikt kan worden voor de mobipunten van de toekomst. Met data die (deel)fietsen, (deel)wagens, e-steps, parkeersensoren… vandaag verzamelen wordt een analysemodel ontwikkeld om de inpassing van mobipunten in het mobiliteitsnetwerk te sturen, te objectiveren en te evalueren.</br> Het project kan rekenen op de ondersteuning van Mobipunt VZW , een consortium van mPact, Autodelen.net en Infopunt Publieke Ruimte dat het concept mobipunten lanceerde in Vlaanderen en de Vlaamse klankbordgroep mobipunten aanstuurt. </br> Het project wordt gefinancierd door VLAIO in het kader van de oproep City of Things .</br> Voor de uitvoering van het project wordt samengewerkt met een consortium van inhoudelijke en technische partners: Anyways , BDO Crossroad en Geosparc .</br> </br> Beschrijving project </br> Fase 1: bepalen wensen beleidsanalyse </br> Resultaten van bevraging over de doelstellingen die beleidsmakers koppelen aan mobipunten </br> De doelstelling van de eerste fase van het project is het scherpstellen van de uitdaging vanuit het werkveld. Waarom willen steden en gemeenten investeren in hoppinpunten (of mobipunten)? Dat is het uitgangspunt van een online bevraging die in 2020 werd gelanceerd bij beleidsmakers in Vlaanderen.</br> De overtuiging is dat mobipunten zullen bijdragen aan combimobiliteit. Mobipunten worden als essentiële schakels gezien om het mobiliteitssysteem te verduurzamen. Ze moeten helpen om nieuwe mobiliteitsvormen zoals deelmobiliteit mainstream maken, het openbaar vervoer faciliteren en bovenal minder autokilometers en meer duurzame verplaatsingen bevorderen. Zo dragen mobipunten meteen ook rechtstreeks bij tot de klimaatdoelstellingen, leefbare kernen en hebben ze een positieve impact op verkeersveiligheid en luchtkwaliteit.</br> Raadpleeg hier het rapport over fase 1 </br> </br> Fase 2: data-ontsluiting </br> Vertrekkende van de analyse gedaan in fase 1, wordt een lijst gemaakt van de te verzamelen noodzakelijke datasets. Vervolgens wordt voor elke nood een lijst gemaakt van kandidaat datasets. Deze datasets worden vergeleken op basis van kwaliteit in al zijn aspecten, beschikbaarheid, technische factoren zoals beschikbaarheid van een API en kost. Op basis van deze analyse zal de uiteindelijke keuze van datasets worden bepaald.</br> Raadpleeg hier het rapport over fase 2 </br> </br> Fase 3: opmaken beleidsanalysetool </br> De doelstelling van het project is om een proof of concept te ontwikkelen van een tool/dashboard dat geschikt is voor beleidsanalyse rond mobipunten. Hierbij worden verschillende analyses gecombineerd op basis van IoT-data uit de mobiliteitswereld.</br> De tool moet geschikt zijn voor beleidsanalyse: </br> </br> Bij investeringen in nieuwe mobipunten. De aanleg van nieuwe mobipunten in het publieke domein vraagt een sterke financiële inspanning van de wegbeheerder. Bovendien is er vaak een grote concurrentie tussen verschillende ruimtevragers in een beperkte ruimte. In deze fase van beleidsanalyse moet de tool dus voornamelijk geschikt zijn om verschillende locaties tegenover elkaar af te wegen en te bepalen wat de meest zinvolle investeringen zijn. </br> Bij evaluatie van bestaande mobipunten. Een (voor)stedelijke mobiliteitsnetwerk is steeds in ontwikkeling. Gezien mobipunten de cruciale schakels vormen binnen het multimodaal netwerk, zullen ook deze mobipunten steeds in ontwikkeling zijn. In deze fase moet beleidsanalyse zich daarom richten op een periodieke evaluatie van de effecten van een mobipunt. Ervaringen van wat goed of minder goed werkt op een mobipunt kunnen hierbij leiden tot inzichten om tot betere mobipunten op gelijkaardige plaatsen te komen. </br> Raadpleeg hier het rapport over fase 3 rapport over fase 3  +
• Korte Beschrijving Ontwikkeling van een sensornetwerk voor het meten van de elektrische geleidbaarheid (EC), zuurtegraad (pH) en temperatuur in oppervlakte-, grond-en afvalwater in Vlaanderen. Beschrijving Architectuur Lessons learned  +
• Korte Beschrijving RAINBRAIN focust op d … Korte Beschrijving </br> RAINBRAIN focust op de ontwikkeling van een datagedreven beslissingsondersteunend instrument op maat van steden en gemeenten. RAINBRAIN omvat technologie om diverse grote datastromen te beheren en analyseren in combinatie met simulatiemodellen, zelflerende en sturingsalgoritmes.</br>RAINBRAIN is opgezet om beter te kunnen anticiperen op periodes van wateroverlast en watertekorten.</br>Looptijd: 13/12/2019 -28/02/2023</br> </br> Beschrijving Architectuur </br> Ontwikkeling en het testen van een Big Data en IoT geconnecteerd waterplatform slim stedelijk waterbeheer , datagedreven beslissingsondersteunend instrument strategische planning, bij de ontwikkeling van waterbeheersings- en andere stedelijke infrastructuur realtime monitoring en sturing van het watersysteem , sturing en beheer van uiteenlopende publieke en private waterassets te faciliteren, op elkaar af te stemmen en op een intelligent manier te automatiseren. RAINBRAIN helpt om de gevolgen van klimaatverandering op te vangen en verhoogt de efficiëntie van de bestaande waterinfrastructuur.</br> </br> Lessons learnedterinfrastructuur. Lessons learned  +
• Korte Beschrijving Slimme monitoring van … Korte Beschrijving </br> Slimme monitoring van waterlopen</br> Dit VLAIO -project is erop gericht om, met de inzet van technologische innovatie onder de vorm van sensoren of andere slimme meetinstrumenten, de waterkwaliteit en -niveau van de Laak, een bijrivier van de Demer, permanent te monitoren.</br> Wat? </br> Begin december 2019 keurde het Agentschap Innoveren & Ondernemen ( VLAIO ) 13 nieuwe City of Things-projecten goed. Hierdoor krijgen lokale besturen een subsidie om te onderzoeken hoe slimme technologie (sensoren, camera’s, open data, artificiële intelligentie …) ingezet kan worden om een oplossing te bieden aan concrete problemen of noden binnen een gemeente. Gemeente Tremelo diende samen met buurgemeente Begijnendijk een project in om de waterkwaliteit en -niveau van de Laak permanent op te volgen.</br> </br> Wat willen we bereiken? </br> Momenteel worden er om de twee jaar handmatige stalen genomen, die dan worden geanalyseerd in een labo. Op deze manier kunnen lozingen of pieken van vervuiling niet waargenomen worden en kunnen er bijgevolg geen gerichte acties rond genomen worden.</br> Daarnaast is het nodig dat waterstanden actueler opgevolgd kunnen worden om kort op de bal te spelen bij droogte of wateroverlast. Op dit moment is er al een permanente monitoring op één plaats om de waterstand op te volgen. In dit project willen we echter onderzoeken of het een meerwaarde is om meerdere peilmeters te plaatsen over het gehele traject.</br> </br> Beoogd resultaat </br> Een belangrijk element waar in dit project rekening mee gehouden zal worden, is de betaalbaarheid en haalbaarheid van de gekozen technologische oplossing zodat ook kleinere lokale besturen er mee aan de slag kunnen. Er zal bijgevolg in dit project gefocust worden op de visualisatie van de informatie (in de vorm van een dashboard) waarmee lokale ambtenaren en beleidsverantwoordelijken aan de slag kunnen vanuit hun bevoegdheden en beleidsdoelstellingen.</br> Met ‘De monitoring van de Laak’ willen we een piloot uitwerken, een end-to-end verhaal, waarbij de markt onderzocht wordt naar bruikbare sensoren die gericht data kunnen verzamelen en de data exporteren naar een centraal IoT-platform. Via dit platform wordt er doelgerichte interpreteerbare informatie beschikbaar gesteld voor de lokale beleidsverantwoordelijken.</br> Net zoals bij andere VLAIO -projecten is het ook onze bedoeling om na afronding van dit project de resultaten toe te passen voor andere waterlopen in andere gemeenten.</br> </br> Beschrijving Architectuur </br> Lessons learneded  +
• Korte Beschrijving Stiemerlab [1] is een … Korte Beschrijving </br> Stiemerlab [1] is een citizen science of burgerwetenschappelijk project dat de waterkwaliteit van de Stiemerbeek in kaart wil brengen.</br> Het rioleringsstelsel en de toenemende stadsuitbreiding in Genk hebben een negatieve invloed op de waterkwaliteit (vervuiling, algenvorming) en biodiversiteit van de Stiemerbeek en Stiemerbeekvallei. Het citizen science (of burgerwetenschappelijk) project ‘Stiemerlab’ vertrekt vanuit het startpunt dat Genkse burgers, omwonenden en lokale organisaties actief kunnen bijdragen om de problematiek van de waterkwaliteit in kaart te brengen, en aan te pakken. Het project wil burgers actief betrekken, onder meer door hen te trainen als burgerwetenschappers om met behulp van sensoren data te verzamelen over de waterkwaliteit in de Stiemerbeek. Daarnaast kunnen burgers ook participeren in het in kaart brengen van de biologische waterkwaliteit via het nemen van waterstalen op verschillende locaties in de Stiemervallei.</br> De bekomen resultaten worden vervolgens gevisualiseerd op een toegankelijke manier naar een breed publiek in de publieke ruimte en op een open online platform Het doel van dit project is enerzijds om de waterkwaliteit van de Stiemerbeek over een lange periode op te volgen en anderzijds inzicht te krijgen in het herstellende karakter van de beek na overstorten uit de riolen.</br> Looptijd project: 2021-2021</br> </br> Beschrijving Architectuur </br> Lessons learnedArchitectuur Lessons learned  +
• Korte Beschrijving Waarom Roeselare he … Korte Beschrijving </br> Waarom </br> Roeselare heeft in het verleden al vaker te kampen gehad met wateroverlast. Maar ook lage waterbeschikbaarheid en periodes van droogte komen steeds vaker voor. Om hier een oplossing voor te vinden diende de stad een project in voor de ‘Slim in de stad’ prijs. SmartWaterland kreeg een subsidie van €290.000 toegekend om het project verder uit te werken.</br> </br> Wat </br> Binnen dit project wordt een fijnmazig netwerk van pluviometers opgezet die via real-time data regenval beter in kaart brengt. Ook de waterstanden in rivieren, riolen en waterputten worden via sensoren gemeten.</br>Stad Roeselare werkt hiervoor samen met WVI, Vives & Quicksand.</br> </br> Hoe </br> Om voor een goede geografische spreiding te zorgen wordt er samengewerkt met scholen. De pluviometers worden in de scholen geprint met een 3D printer. De leerlingen zullen ze in de klas in elkaar steken en meenemen naar huis om daar data te verzamelen. De binnenkomende data kan direct geanalyseerd worden en geeft de stad een beter zicht op de plaatsen waar het hard regent. Hierdoor krijgen waterbeheerders de mogelijkheid om veel sneller en nauwkeuriger te handelen in geval van wateroverlast of droogte.</br> </br> Looptijd </br> 01/03/2020 –31/08/2022</br> </br> Beschrijving Architectuur </br> Lessons learnedctuur Lessons learned  +
• Korte Beschrijving Waterland vzw [1] is … Korte Beschrijving </br> Waterland vzw [1] is een nieuwe vzw die als verbinder optreedt tussen burger en politiek.</br> Met het project 'Vertellende vlotten' worden groene eilanden op binnenwateren voorzien van online sensoren (temperatuur, geleidbaarheid, peil, maar ook hopelijk zuurstof) waarbij de burger real-time informatie krijgt over de waterkwaliteit en dit op een speelse wijze, met een belevingswaarde [cf. Zwerm-gamification project van IMinds].</br>Door meten en vergroenen (drijvende groeneilanden) aan elkaar te koppelen kan het verfraaien van de waterloop een directe positieve impact hebben op de (be)leefbaarheid van de omgeving.</br> </br> Beschrijving Architectuur </br> Lessons learnedeschrijving Architectuur Lessons learned  +
• Korte Beschrijving in Vlaanderen wordt d … Korte Beschrijving </br> in Vlaanderen wordt de combinatie fiets + openbaar vervoer maar half zoveel gebruikt als in Nederland. Om duurzame combimobiliteit te bevorderen is er nood aan meer kwalitatieve, comfortabele en veilige fietsentallingen, bijvoorbeeld aan STATIONS of aan mobi- of HOPPIN' punten.</br> Een basis om op verder te werken is een levende en open inventaris van alle fietsenstallingen in het land, inclusief hun locatie, een foto, openingsuren, maximum stallingsduur, beschrijving van de ingang en van de aanwezige faciliteiten (oplaadpunten, fietspomp, fietsherstelpunt, lockers, ..) en - indien een telsysteem aanwezig is - in real-time het aantal vrije plaatsen.</br> Daarom werd het platform www.velopark.be opgericht</br> </br> Beschrijving Architectuur </br> Velopark werkt op basis van decentrale Linked open data bestanden met een centrale catalogus.</br> De databestanden kunnen door eigenaars / beheerders van fietstenstallingen op een </br>intuïtieve manier aangemaakt worden via een wizard op http://admin.velopark.be </br> De catalogus en databestanden zijn volledig als open data beschikbaar en kunnen ook via een eenvoudige API geraadpleegd worden. Alle specificaties zijn te vinden op https://www.transportdata.be/dataset/velopark </br> Een front-end haalt alle informatie op en geeft deze op een aantrekkelijke en gemakkelijke manier weer via een kaart. Via de front-end kunnen bezoekers ook feedback geven. De aparte fiches van fietsenstallingen kunnen ingesloten worden in andere webpagina's of CRM systemen van bijvoorbeeld gemeentes.</br> </br> Lessons learned </br> - de ontologie en vocabulary van Velopark zijn volledig compatible met VLOCA</br>- gemeenten in Vlaanderen zijn nog niet klaar voor decentrale opslag van databestanden op hun eigen servers. Daarom worden alle bestanden momenteel centraal op Velopark gehost.</br>- studiebureaus en hergebruikers zijn nog niet klaar voor het (her)gebruiken van Linked open data , daarom werd een eenvoudige API opgezet.arom werd een eenvoudige API opgezet.  +
• LDES (Linked Data Event Streams) is een re … LDES (Linked Data Event Streams) is een recente "living standard" binnen SEMIC. Deze laat toe om data als event streams te publiceren, maar ook schaalbaar en gefedereerd te gebruiken.</br> </br> </br> De specificatie van de standaard is terug te vinden op https://semiceu.github.io/LinkedDataEventStreams/eventstreams.html en meer info op github : https://github.com/SEMICeu/LinkedDataEventStreamsub.com/SEMICeu/LinkedDataEventStreams  +
• LUCA School of Arts is een multidisciplina … LUCA School of Arts is een multidisciplinaire onderwijs- en onderzoeksomgeving waar creatief talent zich artistiek, uitvoerend en technisch kan ontplooien en ontwikkelen. In vier steden (Brussel, Genk , Gent en Leuven ) bundelt LUCA de onderwijsexpertise van vijf instituten (Sint-Lukas, Narafi, C-mine, Sint-Lucas en Lemmens).</br> LUCA  biedt meer dan vijftig studietrajecten aan in Audiovisuele Kunsten en Technieken, Beeldende Kunsten en Vormgeving, Interieur & Productdesign, Bouwkunde, Muziek en Drama. Met die waaier aan professionele en academische opleidingen is ze een referentie in het hoger kunstonderwijs.</br> Het artistiek onderzoek van LUCA is ingebed in de geassocieerde Faculteit Kunsten van de KU Leuven. Met meer dan 700 personeelsleden en 3.800 studenten is LUCA een creatieve hub voor meer dan 4.500 kunstenaars, theater- en filmmakers, designers, musici, fotografen, leraren, onderzoekers…fotografen, leraren, onderzoekers…  +
• Lemon en Switchrs slaan de handen in elkaa … Lemon en Switchrs slaan de handen in elkaar om water te besparen. Switchrs is een strategisch innovatiebureau voor sociale impact en circulaire economie. Lemon specialiseert zich dan weer in het bouwen van webplatformen en mobiele applicaties. WerfWater combineert de kwaliteiten van Switchrs en Lemon Companies. Via deze digitale weg proberen Lemin en Switchrs één van de meest levensnoodzakelijke producten, water, te recuperen en opnieuw in omloop te brengen.pnieuw in omloop te brengen.  +