Op eigenschap zoeken

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

Lijst van resultaten

Consolidatie MOSCOW ANALYSE +
Coock open stad +
Create-IoT +
DM fct wg sl 10 +
DM fct wg sl 11 +
DM fct wg sl 12 +
DM fct wg sl 13 +
DM fct wg sl 14 +
DM fct wg sl 3 +
DM fct wg sl 4 +
DM fct wg sl 5 +
DM fct wg sl 6 +
DM fct wg sl 7 +
DM fct wg sl 8 +
DM fct wg sl 9 +
DM overzicht +
DOORVERWIJZING Eigenschap:SpecsInfoArchi +
Data eigenschap. +
Class VlocaTraject with pagetitle format … Class VlocaTraject with pagetitle format title Allowed namespaces: VlocaTraject Has version history: false Layout Areas : 'sub-header sidebar' 'main sidebar' Columns : 3fr 1fr Rows : auto 1fr Storage templates Base properties: Template:Base properties Page properties: Template:VlocaTraject properties Component templates Sidebar template: Template:VlocaTraject sidebar Defined parameters Name Property Slot Formfield type Allowed values Required Multiple Automatically generated template code Info Page properties template Sidebar template Open one of the tabs to view automatically generated template code. This is meant to be used when creating new templates. If you are modifying an existing template, it might still be useful to update the parameter definitions and use parts of the generated code, but be careful not to completely overwrite existing templates. Existing templates will likely have had other modifications that are not included in the automatically generated code. Template:VlocaTraject properties <noinclude>This is the '''Csp class properties''' template. It should be called in the following format:<pre>{{Csp class properties}}</pre></noinclude><includeonly>{{#set:}}</includeonly> Template:VlocaTraject sidebar <noinclude>This is the '''Vloca default sidebar''' template. It should be called in the following format:<pre>{{Vloca default sidebar}}</pre></noinclude><includeonly>{{#vardefine:@allow sidebar edit |{{#ifingroup:user |{{#if:{{#urlget:veaction}}{{#urlget:action}}||yes}} }} }}<div class="tab-content">{{#tag:_input||type=radio|id=sidebar-view|name=toggle-sidebar|checked=checked|class=d-none sidebar-view}}<div class="card sidebar-view-tab"><div class="card-header">{{#ifeq:{{#var:@allow sidebar edit}} |yes |{{#tag:label|Edit|for=sidebar-edit|class=btn btn-secondary}}}}{{#caprint:$base[Base properties][Class]}}{{#caprint:$base[Base properties][Title]}}</div><div class="card-body"></div></div>{{#ifeq:{{#var:@allow sidebar edit}} |yes |{{#tag:_input||type=radio|id=sidebar-edit|name=toggle-sidebar|class=d-none sidebar-edit}}<div class="card sidebar-edit-tab"><form action="addToWiki">{{#if:{{#casize:$class}}||<_create mwwrite="{{FULLPAGENAME}}" mwtemplate="Csp class properties" mwslot="ws-class-props" mwfields="" />}}<div class="card-header">{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}{{#caprint:$base[Base properties][Class]}}{{#caprint:$base[Base properties][Title]}}</div><div class="card-body"><div class="text-right">{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}<input type="submit" value="Save" class="btn btn-primary" /></div></div></form></div>|}}</div></includeonly>ht"> {{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}} <input type="submit" value="Save" class="btn btn-primary" /> </div> </div> </form> </div> |}} </div></includeonly> +
Class Wiki with pagetitle format next_av … Class Wiki with pagetitle format next_available Has version history: false Layout Areas : 'main' Columns : Rows : Storage templates Base properties: Template:Base properties Page properties: Template:Wiki properties Component templates Sidebar template: Template:Wiki sidebar Defined parameters Name Property Slot Formfield type Allowed values Required Multiple Automatically generated template code Info Page properties template Sidebar template Open one of the tabs to view automatically generated template code. This is meant to be used when creating new templates. If you are modifying an existing template, it might still be useful to update the parameter definitions and use parts of the generated code, but be careful not to completely overwrite existing templates. Existing templates will likely have had other modifications that are not included in the automatically generated code. Template:Wiki properties <noinclude>This is the '''Wiki properties''' template. It should be called in the following format:<pre>{{Wiki properties}}</pre></noinclude><includeonly>{{#set:}}</includeonly> Template:Wiki sidebar <noinclude>This is the '''Wiki sidebar''' template. It should be called in the following format:<pre>{{Wiki sidebar}}</pre></noinclude><includeonly>{{#vardefine:@allow sidebar edit |{{#ifingroup:user |{{#if:{{#urlget:veaction}}{{#urlget:action}}||yes}} }} }}<div class="tab-content">{{#tag:_input||type=radio|id=sidebar-view|name=toggle-sidebar|checked=checked|class=d-none sidebar-view}}<div class="card sidebar-view-tab"><div class="card-header">{{#ifeq:{{#var:@allow sidebar edit}} |yes |{{#tag:label|Edit|for=sidebar-edit|class=btn btn-secondary}}}}{{#caprint:$base[Base properties][Class]}}{{#caprint:$base[Base properties][Title]}}</div><div class="card-body"></div></div>{{#ifeq:{{#var:@allow sidebar edit}} |yes |{{#tag:_input||type=radio|id=sidebar-edit|name=toggle-sidebar|class=d-none sidebar-edit}}<div class="card sidebar-edit-tab"><form action="addToWiki">{{#if:{{#casize:$class}}||<_create mwwrite="{{FULLPAGENAME}}" mwtemplate="Wiki properties" mwslot="ws-class-props" mwfields="" />}}<div class="card-header">{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}{{#caprint:$base[Base properties][Class]}}{{#caprint:$base[Base properties][Title]}}</div><div class="card-body"><div class="text-right">{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}<input type="submit" value="Save" class="btn btn-primary" /></div></div></form></div>|}}</div></includeonly>ht"> {{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}} <input type="submit" value="Save" class="btn btn-primary" /> </div> </div> </form> </div> |}} </div></includeonly> +
Class definitions aanpassen In CSP Basis … Class definitions aanpassen In CSP Basis 1.8.0 the default sidebar was added, this allows you to have sidebars without having to create custom sidebar templates for each class definition. There are some customization options built into the default sidebar as well. It is recommended to use these customization options when possible and to only create fully custom sidebar templates when absolutely necessary, as the fully custom sidebar templates require a lot more maintenance work when for example some parserfunctions get deprecated. This document describes the various customization options. Inhoud 1 Class definitions aanpassen 1.1 Parameters and formfield/display templates 1.2 Custom formfield/display templates 1.3 Custom sidebar template where you are adding to the default sidebar 1.4 Fully custom sidebar template Parameters and formfield/display templates Edit parameters on a class definition page, to configure what will show up on your sidebar. Note that the parameter configuration is also used for setting properties, but you can use "(none)" as property name value if you don't want to set a property. Only the "parameter name" field is required. When you only fill this, you will get default text fields in the sidebars. Choose a displayTemplate to configure how a parameter is displayed in the view tab of the default sidebar. Choose a formfieldTemplate to coinfigure what type of form field is used in the edit tab of the default sidebar. DisplayTemplate and formfieldTemplate can both be set to "(none)" to not have a parameter show up in respectively the view and edit tabs of the default sidebar. Custom formfield/display templates It is possible to add custom template names in the displayTemplate and formfieldTemplate fields. All fields that are filled for a parameter will be passed to the templates so they can be accessed through template parameters there. For example you can use {{{allowedValues|}}} in a formfieldTemplate. It might be useful to look at the ws-data slot of the class definition to see all of the parameters. The values of parameters on a content page are also passed to the display/formfield templates as the "value" parameter. In a display/formfield templates you cannot access values of other parameters directly, but you can do this by using {{#invoke:CspFunctions|getParentArgs|$pageData}}, which will return the $pageData parameter that is used in Template:Csp default sidebar (and contains an ArrayFunctions export with slotdata of the page). It is possible to add fields to the json data in the ws-data slot that cannot be filled through the parameters form. For example CSP 1.8.0 does not yet include the option to specify a placeholder for your formfields, but you can add placeholder to the json data and then use {{{placeholder|}}} in a custom formfieldTemplate. Custom sidebar template where you are adding to the default sidebar In many cases you won't necessarily want to replace the default sidebar, but you may want to add another card above or below it with additional functionality. It is possible to use the default sidebar within a custom sidebar template. For example like the following code snippet: {{Csp default sidebar|$pageData={{{$pageData|}}}|$classData={{{$classData|}}}}}{{Csp sidebar tabs|id=another-card|canEdit=yes|closeButton=|title=Another card|subTitle=Below the default sidebar|view=<div class="card-body">viewtab content</div>|edit=<div class="card-body">edittab content</div>}} Fully custom sidebar template In a fully custom sidebar template you can do anything you want. You will still get the $pageData and $classData parameters passed to this template so you can use those. The following is an example of custom sidebar code that will produce a sidebar similar to the default one, perhaps this will give you some ideas for what's possible: <div class="tab-content"><input type="radio" id="sidebar-view" name="toggle-sidebar" checked="checked" class="d-none sidebar-view" /><div class="card sidebar-view-tab"><div class="card-header">{{#ifeq:{{#ifingroup:user |{{#if:{{#urlget:veaction}}{{#urlget:action}}||yes}} }}|yes |<label for="sidebar-edit" class="btn btn-secondary">Edit</label>}}{{#af_get:{{{$pageData}}}|ws-base-props|Base properties|1|Class|_text}}{{#af_get:{{{$pageData}}}|ws-base-props|Base properties|1|Title|_text}}</div><div class="card-body">{{Sidebar item|Label=Title|Value={{#af_get:{{{$pageData}}}|ws-base-props|Base properties|1|Title |_text}}}}{{Sidebar item|Label=TextInput|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TextInput |_text}}}}{{Sidebar item|Label=TokenInput|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TokenInput |_text}}}}{{Sidebar item|Label=AskTokenInput|Value={{#af_join:{{#af_map:{{#af_split:{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|AskTokenInput |_text}}|,}}|@@|[[{{{@@}}}|{{#show:{{{@@}}}|?Title}}]]}}| }}}}{{Test date display|Name=DateInput|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|DateInput |_text}}}}{{Sidebar item|Label=DateInputTwo|Value={{#if:{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|DateInputTwo |_text}} |{{#time: j M Y H:i |{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|DateInputTwo |_text}} }} }}}}{{Sidebar item|Label=TextInputTwo|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TextInputTwo |_text}}}}{{Sidebar item|Label=CheckboxInput|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|CheckboxInput |_text}}}}{{Sidebar item|Label=TextAreaInput|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TextAreaInput |_text}}}}{{Sidebar item|Label=NumberInput|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|NumberInput |_text}}}}{{Sidebar item|Label=SelectInput|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|SelectInput |_text}}}}{{Sidebar item|Label=TokenMultipleInput|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TokenMultipleInput |_text}}}}{{Sidebar item|Label=Rob parameter|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|Rob parameter |_text}}}}</div></div>{{#ifeq:{{#ifingroup:user |{{#if:{{#urlget:veaction}}{{#urlget:action}}||yes}} }}|yes |<input type="radio" id="sidebar-edit" name="toggle-sidebar" class="d-none sidebar-edit" /><div class="card sidebar-edit-tab"><div class="card-header"><label for="sidebar-view" class="btn btn-secondary" >Close</label>{{#af_get:{{{$pageData}}}|ws-base-props|Base properties|1|Class|_text}}{{#af_get:{{{$pageData}}}|ws-base-props|Base properties|1|Title|_text}}</div><div class="card-body"><form action="addToWiki"><_edit target="{{PAGEID}}" template="Base properties" formfield="Title" mwslot="ws-base-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="TextInput" mwslot="ws-class-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="TokenInput" mwslot="ws-class-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="AskTokenInput" mwslot="ws-class-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="DateInput" mwslot="ws-class-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="DateInputTwo" mwslot="ws-class-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="TextInputTwo" mwslot="ws-class-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="CheckboxInput" mwslot="ws-class-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="TextAreaInput" mwslot="ws-class-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="NumberInput" mwslot="ws-class-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="SelectInput" mwslot="ws-class-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="TokenMultipleInput" mwslot="ws-class-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="TestNoDisplay" mwslot="ws-class-props" /><_edit target="{{PAGEID}}" template="Csp class properties" formfield="Rob parameter" mwslot="ws-class-props" />{{Sidebar item|Label=Title|Value=<input type="text" name="Title" class="form-control" required="required" value="{{#af_get:{{{$pageData}}}|ws-base-props|Base properties|1|Title|_text}}" />}}{{Sidebar item|Label=TextInput|Value=<input type="text" name="TextInput" class="form-control" required="required" value="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TextInput|_text}}" />}}{{Sidebar item|Label=TokenInput|Value=<_token id="token-{{lc:{{anchorencode:TokenInput}} }}" name="TokenInput[]" class="form-control" allowclear selected="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TokenInput|_text}}" options="Ay,Bee,Cee" />}}{{Sidebar item|Label=AskTokenInput|Value=<_token id="token-{{lc:{{anchorencode:AskTokenInput}} }}" name="AskTokenInput[]" class="form-control" required="required" multiple="multiple" input-length-trigger="1" query="[[Class::+]][[Title::!!!]](limit=999)(returntext=Title)" >{{#af_join:{{#af_map:{{#af_split:{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|AskTokenInput|_text}} }} |$value|<option value="{{{$value}}}" selected="selected">{{#show:{{{$value}}}|?Title}}</option>}}|\n}}</_token>}}{{Test date formfield|Name=DateInput|Value={{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|DateInput|_text}} }}{{Sidebar item|Label=DateInputTwo|Value=<input type="datetime-local" name="DateInputTwo" class="form-control" value="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|DateInputTwo|_text}}" />}}<div class='alert alert-danger'>No template defined in parameter definitions</div>{{Sidebar item|Label=<label for="checkbox-{{lc:{{anchorencode:CheckboxInput}} }}" >CheckboxInput</label>|Value=<input type="hidden" name="CheckboxInput" value="" /><input type="checkbox" id="checkbox-{{lc:{{anchorencode:CheckboxInput}} }}" name="CheckboxInput" value="Yes" checked="{{#ifeq:{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|CheckboxInput|_text}} |Yes|checked}}" />}}{{Sidebar item|Label=TextAreaInput|Value=<input type="textarea" name="TextAreaInput" class="form-control" >{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TextAreaInput|_text}}</input>}}{{Sidebar item|Label=NumberInput|Value=<input type="number" name="NumberInput" class="form-control" value="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|NumberInput|_text}}" />}}{{Sidebar item|Label=SelectInput|Value=<select name="SelectInput" class="form-control" allowclear selected="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|SelectInput|_text}}" options="Alpha,Bravo,Charlie" />}}{{Sidebar item|Label=TokenMultipleInput|Value=<_token id="token-{{lc:{{anchorencode:TokenMultipleInput}} }}" name="TokenMultipleInput[]" class="form-control" multiple="multiple" selected="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TokenMultipleInput|_text}}" options="Alpha,Bravo,Charlie" />}}{{Sidebar item|Label=TestNoDisplay|Value=<input type="text" name="TestNoDisplay" class="form-control" value="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|TestNoDisplay|_text}}" />}}{{Sidebar item|Label=Rob parameter|Value=<input type="number" name="Rob parameter" class="form-control" value="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|Rob parameter|_text}}" />}}<div class="text-right"><label for="sidebar-view" class="btn btn-secondary">Close</label><input type="submit" value="Save" class="btn btn-primary" /></div></form></div></div>|}}</div>} {{Sidebar item |Label=Rob parameter |Value=<input type="number" name="Rob parameter" class="form-control" value="{{#af_get:{{{$pageData}}}|ws-class-props|Csp class properties|1|Rob parameter|_text}}" /> }} <div class="text-right"> <label for="sidebar-view" class="btn btn-secondary">Close</label> <input type="submit" value="Save" class="btn btn-primary" /> </div> </form> </div> </div> |}} </div> +
Co-creatie aanvragen Co-Creatie aanv … Co-creatie aanvragen Co-Creatie aanvraag Gelinkt VLOCA-Traject Smart City Domeinen Smart City Componenten WerfWater Vertellende vlotten Velopark Urban digital twin (Brugge) Tipping Points Stiemerlab Smart Waterland Rainbrain Proactive Flooding Detection PROBE Online Reserveren en Betalen: type locatie in de stad Monitoring van de Laak (VLAIO CoT) Koppeling IoT-peilsensordata naar andere IoT- stacks Iot-gestuurde mobipunten Internet of Water Hydrologisch meetnet provincie Antwerpen Flood4Cast DenCITY B-WaterSmart Antwerp Living Labs: levendige en leefbare (universiteits)buurt API-ledre (universiteits)buurt API-led +
Combimobiliteit is het gecombineerd gebruik van diverse vervoersmogelijkheden (openbaar vervoer, fiets, auto, deelmobiliteit) om de reiziger van punt A naar punt B te brengen. +
Communicatie sensor data De keuze van ee … Communicatie sensor data De keuze van een geschikte datatransmissie techniek is essentieel om hoog frequente sensor data te ontsluiten: zie hierover volgende pagina . Ontlsluiten voorspellingen Eens een bepaalde detectie / datapunt gemaakt is, is het belangrijk om de info die nodig was om tot deze informatie te komen goed te documenteren.Voor aanbevelingen hierover, raadpleeg de pagina: Hoe houden we gestructureerd data bij? De volgende stap is deze gestructureerde en goed gedocumenteerde data te ontsluiten. Voor de aanbeveling hierrond, kan de volgende pagina geraadpleegd worden: Hoe deel ik mijn data? Data dashboarding en visualisatie Voor een aantal tips bij het opzetten van een online dashboard zie volgende pagina VLOCA Projecten gerelateerd aan het draaiboek VLOCA project Organisatie(s) Stiemerlab Stad Genk , VITO , UHasselt , VMM , LUCA school of Arts Hydrologisch meetnet provincie Antwerpen Provincie Antwerpenrovincie Antwerpen Provincie Antwerpen +
Componenten ArchitectuurComponent A … Componenten ArchitectuurComponent API gateway Asset Registry Context Broker Data Analytics Data Catalog Data Lake(house) Data broker Firewall IAM service InfluxDB IoT agent Message buffer Postgres Semi structured data Sensor Solid Timescale PostgresSensor Solid Timescale Postgres +
Concept & definition A Data-driven D … Concept & definition 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”. A DDDS can consequently be understood as a class of computerized information system that support decision-making activities via the access to and manipulation of internal company data and sometimes external data. The concept was originally defined from a private sector point of view, and not from a public administration perspective. Public administration perspective on DDSS In a public administration context, specific reference can be made to internal public administration data and external data. Public administration data can refer to data originating from within the public administration that will take a particular decision, but can also refer to data originating from other public administration actors. External data would, in the context of public administrations, refer to non-public administration data (e.g. data from private sources or other stakeholders). For example, a local Digital Twin can include data of various sources: Data originating from the administration itself (local police, environmental department etc.) Data originating from other public administrations, think of neighbouring local administrations, the Flemish public administrations, the federal public administration etc. Data originating from non-public administration actors, such as private companies or citizens. Other types of decision support systems As Power (2002, 2008) and Kozielski et al. (2021) indicate, a DDSS is only one type of decision support system. Other types of decision support systems are the following: Communication driven Data driven Document driven Knowledge driven Model driven. Relevant in this regard is specifically the Knowledge-driven decision support system , which “is a blanket term for systems built using artificial intelligence technologies. Equipped with specialized problem-solving expertise, they are used to suggest or recommend actions to managers, using tasks that would otherwise require a human expert. Knowledge-driven [decision support system] are often paired with data mining to sift through large amounts of data to identify the content relationships within.” (Lee, 2021; Power, 2002, 2008).02, 2008). +
Concept van een repair café Een Repair C … Concept van een repair café Een Repair Café is een bijeenkomst die draait om repareren, georganiseerd op buurtniveau. Men kan er meegebrachte kapotte spullen repareren met hulp van vrijwilligers. Doelstellingen zijn het verkleinen van de afvalberg, het behouden van kennis over repareren en het versterken van de sociale cohesie. (bron: Wikipedia) Repair cafés worden meestal gehouden op gemeenschapslocaties, waaronder kerken, bibliotheken en campussen waar gereedschap beschikbaar is en waar eigenaren hun kapotte goederen kunnen repareren met de hulp van vrijwilligers, of waar ervaren vrijwilligers complexere reparaties uitvoeren terwijl ze worden bijgestaan door de eigenaren. (bron: SHAREPAIR) Er zijn over de hele wereld veel reparatiegroepen. Onderstaande afbeelding geeft een indruk van de verspreiding van de 2447 reparatiegroepen die aangesloten zijn bij Repair Café International, een stichting die reparatie weer onderdeel wil maken van de lokale gemeenschap[1]. Naast dit netwerk bestaan er nog vele andere netwerken zoals het wereldwijde Restarters-netwerk[2], of dichter bij huis het Repair&Share-netwerk[3] in Vlaanderen of het Repair Together-netwerk[4] in Brussel en Wallonië. Figuur 1 Wereldwijd netwerk van Repair Café international (bron: https://www.repaircafe.org/bezoeken/) Iedereen kan een nieuwe reparatiegroep starten of een reparatie-evenement organiseren. Bestaande reparatiegroepen en netwerken staan bij met kennis en middelen zoals een startup kit dat je kan bestellen bij Repair Café International[5]) of via lokale overheden en organisaties (bijvoorbeeld een training van Avansa Limburg[6]). Er zijn een aantal huisregels waar een repair café aan moet voldoen[7]. Zo bieden de vrijwilligers hun expertise vrijwillig (dus onbezoldigd) aan. De eigenaar mag een (financiële) vergoeding geven of doneren, maar steeds op vrijwillige basis. In principe is het de product eigenaar die zelf aan de slag gaat onder begeleiding van de reparatiedeskundige. Samen leren ze hoe een reparatie uit te voeren. Op deze manier kunnen noch de organisatoren van het Repair Café, noch de reparatiedeskundigen aansprakelijk worden gesteld voor enige directe of indirecte schade die zou kunnen voortvloeien uit adviezen of aanwijzingen betreffende reparaties. Allerhande communicatie kanalen, zoals posters in een openbare ruimte, sociale media of een lokale evenementenkalender, kunnen gebruikt worden om burgers op de hoogte te brengen van het evenement. Ze worden uitgenodigd om een kapot product (afhankelijk van de focus: elektrisch apparaat, elektronica, textiel, fiets, meubels,…) naar het evenement te brengen, melden het product aan bij aankomst aan een receptietafel en beginnen vervolgens met repareren, samen met een vrijwilliger. [1] Repair Café International. “Starten”. https://www.repaircafe.org/meedoen/starten/ bezocht 09/09/2022 [2] Avansa Limburg “Ondersteuning Repair Cafés”. https://avansa-limburg.be/projecten/ondersteuning-repair-cafes, bezocht 09/09/2022 [3] https://www.repaircafe.org/en/house-rules/[4] Repair Café International, https://www.repaircafe.org/, bezocht 09/09/2022 [5] Restarters network: https://restarters.net/ [6] Repair&Share network: https://repairshare.be/kaart/ [7] Repair Together network: https://repairtogether.be/en/ +
Contactpersonen voor ORDP[1] De “Open Re … Contactpersonen voor ORDP[1] De “Open Repair Alliance” is een bottom-up en open-source data-initiatief dat het aantal reparaties van elektrische en elektronische producten meet, de defecte onderdelen en of het product repareerbaar was. Er werd een gezamenlijke aanpak ontwikkeld om successen en uitdagingen te documenteren bij het repareren van artikelen die hun garantieperiode hebben overschreden. Alle reparatie-initiatieven kunnen de standaard vrij toepassen en hun gegevens delen. De EU kan meer reparatie-initiatieven aanmoedigen om deel te nemen aan de Open Repair Alliance of om een aparte verplichte regeling te ontwikkelen. De standaard is open en online te raadplegen: https://standard.openrepair.org/ De standaard bestaat uit een aantal modules die verplicht moeten worden ingevuld, zoals: Product gerelateerd: Productcategorie (vooraf gedefinieerd), merk, model, bouwjaar Reparatiegerelateerd: probleem, reparatiestatus (vast; herstelbaar; einde levensduur; onbekend), reparatiebarrière (reserveonderdelen niet beschikbaar, reserveonderdelen te duur, geen manier om het product te openen, reparatie-informatie niet beschikbaar, gebrek aan apparatuur, product ook versleten). Sessiegerelateerd: via welke community-reparatiegroep (groeps-ID), gebeurtenisdatum, land en ID (unieke record-ID) Aanbieder gerelateerd: gegevensprovider, registratiedatum. De reparatiegemeenschap kan er verder voor kiezen om de aanvullende gegevens in te vullen, waaronder: Impactgerelateerd: de gevolgen van reparatie als afval, gewicht omgeleid, uren vrijwillig. Reparateur gerelateerd: Over de persoon die de reparatie heeft uitgevoerd Deelnemer gerelateerd: Over de persoon die eigenaar is van het apparaat Feedback gerelateerd: Ervaring van de deelnemers met de reparatie. De data zijn nuttig voor het identificeren van veel voorkomende falingen (doorheen de levensfase) of als graadmeter van hoe “repareerbaar” de toestellen in onze samenleving zijn. Men kan er ook uit afleiden voor welke toestellen en/of faling de eigenaar de moeite doet ermee naar een repair café te gaan. Er zijn zeker ook beperkingen bij het gebruik: Aanvaarding: Fabrikanten zijn over het algemeen terughoudend om gegevens over storingen, reparatiefuncties etc. te delen, waar de Open Repair Alliance inzicht in kan geven. Geloofwaardigheid: de data geeft niet weer hoe moeilijk het was om de reparatie uit te voeren. Het enkele resultaat van een reparatie is niet overdraagbaar naar andere contexten (bijvoorbeeld zelfreparatie). Representativiteit: De gegevens, aangezien het onwaarschijnlijk is dat mensen die een café bezoeken representatief zijn voor de bredere bevolking, en de producten die ze naar het café brengen, ook mogelijk niet representatief zijn voor de bredere markt. Robuustheid: Er wordt geen gebruik gemaakt van een door de EU ondersteunde productclassificatie [1]De SHAREPAIR coordinator: Lieve.VanEspen@leuven.be +
Context Er zijn geen initiatieven gelink … Context Er zijn geen initiatieven gelinkt aan dit traject. Overzicht deliverables Deliverable Versie Actoren VLOCA-model V0.1 Slimme stadsdistributie – Hasselt VLOCA-Model V0.1 Overheden Stakeholderanalyse Stakeholderanalyse V0 Kennisinstellingen Overheden Voorbeeld architectuurtekening TA-Tekening V0 VLOCA-model V0.2 Slimme stadsdistributie – Hasselt VLOCA-Model V0.2 Overheden Overzicht werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2023-01-11 13u30-16u30 Digitaal Thematische werkgroep 1 Data en informatie werkgroep 2023-02-28 09u00-12u00 Digitaal2-28 09u00-12u00 Digitaal +
Context Er zijn geen initiatieven gelink … Context Er zijn geen initiatieven gelinkt aan dit traject. Overzicht werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2023-01-12 13u00-16u00 VAC Gent Thematische werkgroep 2 Functionele werkgroep 2023-04-04 13u00-16u00 Digitaal Thematische werkgroep 3 Technologie werkgroep 2023-05-09 13u00-16u00 Digitaal Overzicht deliverables Deliverable Versie Actoren VLOCA-model V0.2 Het potentieel van urban mining voor de bouwsector VLOCA-Model V0.2 Overheden VLOCA-model V0.1 Het potentieel van urban mining voor de bouwsector VLOCA-Model V0.1 Overhedenouwsector VLOCA-Model V0.1 Overheden +
Context Er zijn geen initiatieven gelinkt aan dit traject. Overzicht werkgroepen Geen werkgroepen gevonden Some use of " " in your query was not closed by a matching " ". Overzicht deliverables +
Data Enrichment Onder data enrichment ve … Data Enrichment Onder data enrichment verstaan we een bepaalde databron verrijken met andere data die gelinkt of gerelateerd is aan deze data. Bijvoorbeeld, een straatsegment kan verrijkt worden door: op te gaan zoeken hoeveel winkels er langs deze straat liggen welke buslijnen er actief zijn wat het hoogteverschil is tussen het start en eind punt van het segment etc...tart en eind punt van het segment etc... +
Data Kwaliteit beschrijft of data geschikt … Data Kwaliteit beschrijft of data geschikt is voor het doel in de specifieke context (bijvoorbeeld data analyse). Hoe bepaal je of de data voldoet aan de kwaliteitseisen ?Er worden (niet exhaustief) een 5-tal subparameters gebruikt : Accuraatheid : is de informatie correct in zijn details. Heeft de data calibratie/validatie nodig en is dit al gebeurd ? Compleetheid : Hoe compleet is de data, hoe uitgebreid of is er nog aggregatie/verfijning nodig om tot het doel te komen? Betrouwbaarheid : Is de data tegenstrijdig met andere betrouwbare bronnen. Relevantie : Heb je de data echt nodig ? Timeliness : Hoe up-to-date is de informatie ? Kan deze gebruikt worden voor real-time rapportering ? +
Data Lineage is metadata die aangeeft waar data vandaan komt en hoe deze werd berekend. Ook waar de data naartoe gaat kadert daar onder. +
Data Ownership (eigenaarschap) refereert z … Data Ownership (eigenaarschap) refereert zowel naar het bezit van de data als de verantwoordelijkheid voor de informatie die de data levert. Het gaat over het wettelijk recht hebben over de data. Daarbij gepaard moet dus ook geregeld worden hoe de data kan verkregen worden (onder welke voorwaarden), gebruikt worden, verrijkt worden, en opnieuw verdeeld worden. Dit kan geregeld worden in licenties of andere overeenkomsten. Open Data is data die onder een open licentie gedeeld wordt. Data Sovereignty is een term die ook een legaal karakter heeft, maar gaat eerder over het concept dat de data die iemand verzamelt, opslaat en verwerkt onderworpen is aan de wetten van de regio (land) waar de data fysisch gelokaliseerd is.nd) waar de data fysisch gelokaliseerd is. +
Data Portability is een concept om gebruik … Data Portability is een concept om gebruikers te beschermen tegen het opslaan van hun data in silo's. Daarbij moet het mogelijk zijn om via standaard formaten de data uit te lezen en over te dragen naar een andere plaats. Dit recht op data porteerbaarheid werd ingeschreven in de GDPR wetgeving. Dit gaat voornamelijk ook persoonlijke data. De persoonsdata moet in een machine-leesbaar formaat worden aangeleverd door de organisaties die dit in gebruik hebben. Dit machine-leesbaar formaat kan bijvoorbeeld XML, JSON, CSV, ... zijn. De doelstelling hiervan is dat het hergebruik van de data gemakkelijk is.het hergebruik van de data gemakkelijk is. +
Data Security verwijst naar de veiligheid … Data Security verwijst naar de veiligheid van data. Hoe veilig wordt de data beheerd en opgeslagen ? Dit slaat niet enkel op de fysische veiligheid (bijvoorbeeld fysische toegangscontrole tot servers), maar ook naar de virtuele veiligheid (bijvoorbeeld IAM). Security speelt een belangrijke rol in het vermijden dat systemen gehacked worden en data lekt of gestolen wordt.orden en data lekt of gestolen wordt. +
Data Space in Flanders – how to support th … Data Space in Flanders – how to support the Flemish data economy Data spaces are not a new concept. The idea that data can be shared across organisations, that this has high societal potential, and that it is not easy to achieve, has been around for at least 25 years. It was already the underlying tenet of the Electronic Data Interchange (EDI) efforts at the end of the 90's and beginning of the 00's and was also the prime motivation for developing a semantic web. Even though the issue may have been in part solved for rather business data that does not change a lot (which we'll call "slow moving" in this paper), the emergence of fast moving data that emanated from e.g. Internet of Things sensors has introduced new challenges to the sharing of data. Data spaces We define a data space as "a set of data coming from a variety of data sources". A data space is an essential concept in allowing the sharing of data between various actors in a data ecosystem, by which we refer to "a loose set of interacting actors that directly or indirectly consume, produce, or provide data and other related resources." [1] There is therefore an inherent relation between a data ecosystem and a data space: the data space is composed of a data which is exchanged between the members of the data ecosystem. Data spaces are defined by the applications that use them. An application will need a number of data sources to function and it is this set of data sources to which we refer as a data space. There is therefore not one data space, but an almost unlimited number of data spaces, represented by all the combinations of existing data sources. In a data ecosystem, we count 3 types of participants: Data consumers Developers End-users Data providers Open data providers Closed data providers Data space federators When we refer to organisations in a data spaces, we aim to denote government organisations, not for profit organisations or private companies. Data consumers are the actors that define the data space through their data needs. Among the data consumers, we count both the developers that build applications and the end-users that use the applications that are built by the developers. In terms of data providers, we mainly see organisation or private entities that provide open data or closed data. Principles FAIR Data SMART data Data Sovereignity Federation vs centralisation How can data spaces benefit the economy? From a macro-economic point of view, there are costs to a lack of interoperability. A lack of interoperability will lead to fewer competitors and a winner-takes all logic. As entry barriers are introduced, a few winners will develop market power and keep competitors from entering in a market. Fewer competitors mean that dominating companies can controle prices, which leads to inflation and a general higher cost for society and especially for consumers. High market power has been calculated to be as high as 9% of GDP. Making sure that interoperability exists between organisations in terms of data sharing can lower entry barriers to new companies and thus allow a beneficial effect on prices. The market has a very limited incentive to making sure that such interoperability exists, which means that governmental actors has a substantial role to play. Related initiatives GAIA-X IDSA BDVA FIWare CEF EIF Sensor data platform Datanutsbedrijf Vlaams actieplan Artificiële Intelligentie SolidLab Living-in.eu NxtPort ETP Alice Cases Environment Logistics Mobility Health How can data spaces be implemented in Flanders? ↑ https://www.gaia-x.eu/pdf/Gaia-X_Architecture_Document_2103.pdfitecture_Document_2103.pdf +
Data Variety is de verscheidenheid aan dat … Data Variety is de verscheidenheid aan data in een data verzameling, of in een probleem domein. Een grote verscheidenheid maakt het heel moeilijk om de data te uniformiseren, en dus qua IT systemen te optimaliseren. Het is 1 van de grootste uitdagingen in cross-domein applicaties. Verscheidenheid kan bijvoorbeeld uitgedrukt worden in data formaten of structuren, die het meer of minder mogelijk maken om data binnen te lezen in machines. Er bestaan 3 types data : gestructureerde data : verwijst naar data die voorgedefineerd and geformatteerd is (heeft dus een data formaat ), meestel in een structuur due gemakkelijk kan weggeschreven worden in een opslag medium. Een mooi voorbeeld hier is een relationele database. De data wordt zo in tabellen geformatteerd dat deze gemakkelijk kunnen opgeslagen en bevraagd worden (bv via SQL). Gestructureerde data is dus vrij rigide in zijn data formaat en hangt af van de creatie van een data model dat definieert welke data types moeten gebruikt worden en hoe die moeten opgeslagen en verwerkt worden. Voorbeelden zijn RDF, Parquet, Avro. Deze data wordt vaak opgeslagen in data warehouses. semi-gestructureerde data : dit is gestructureerde data die niet echt past in een formele structuur van een relationele database, maar wel nog tagging of andere markering gebruikt om elementen te scheiden van elkaar. Het is data met een "zelf-beschrijvend formaat". Een typisch voorbeeld zijn smartphone foto's die ongestructureerde beeld data bevatten, maar met metadata met de opnamentijd, locatie en andere geindentificeerde informatie. Typische data formaten zijn JSON, CSV, XML,... IoT data bijvoorbeeld die in het formaat JSON-LD is, kan beschouwd worden als semi-gestructureerd. ongestructureerde data : dit is data die opgeslagen wordt als een "blob", zonder formaat en structuur en die dus onbehandeld blijft to deze gebruikt wordt. Voorbeelden zijn CSV, TSV, Excel, email, text blobs, sociale media posts, IoT sensor data, satelietbeelden, ... Deze data wordt vaak opgeslagen in data lakes.eslagen in data lakes. +
Data Velocity (snelheid) refereert naar de … Data Velocity (snelheid) refereert naar de snelheid waarop data wordt gegenereerd, verdeeld, verzameld en aangeboden. Hoe snel komt data binnen ? Een voorbeeld is Facebook waar elke dag een tsunami van foto's binnen komt om te verwerken, opslaan, terug ophalen,... Ook aggregatie van datastromen (zoals bijvoorbeeld verkeerslichten) kan voor heel wat data zorgen op een korte tijd. Hoge snelheids data vereist specifieke verwerkingstechnieken en systemen (zoals streaming technologie). Tegenwoordig is het ook mogelijk om "on-the-fly" analyze uit te voeren op hoge snelheids data.uit te voeren op hoge snelheids data. +
Data Veracity gaat over de (on)zekerheidsf … Data Veracity gaat over de (on)zekerheidsfactor, waarheidsgetrouwheid van de data. Is de data die aangeleverd wordt accuraat genoeg, is ze betrouwbaar, is de kwaliteit hoog genoeg voor mijn doeleinden ? Veel big data wordt niet gebruikt, omdat de informatie die uit de data komt niet als betrouwbaar gezien wordt. Het beheren van data veracity, door bijvoorbeeld context toe te voegen aan de data of de data semantisch te linken met bestaande definities, ... is een grote uitdaging. Data governance kan hier ook een grote rol in spelen. Of aangeleverde data een bepaald doel dient (om bv. in AI gebruikt te worden) is een enorme uitdaging, maar fundamenteel voor het succes van data intelligence.Dit gaat ook over de informatie over de herkomst en betrouwbaarheid van de databron : is de databron gekend, de context van de data productie, werd de data door iemand anders aangepast, ... enkele voorbeelden van oorzaken van Data Veracity : Bugs : data wordt verkeerd getransformeerd door een bug Abnormaliteiten : 2 naast elkaar liggende weerstations vertonen totaal verschillende waarden Fake Data : valse berichten verspreid in sociale media Data Lineage : een organizatie krijgt data van verschillende bronnen en ontdekt dat 1 van de bronnen zeer onnauwkeurig is, maar beschikt niet over de Data Lineage informatie om te weten waar die bron is verwerkt op verschillende plaatsen.aatsen. +
Data aggregatie is een proces waarin infor … Data aggregatie is een proces waarin informatie wordt verzameld en uitgedrukt in een beknopte vorm, voor doeleinden zoals statistisch analyseren. Een bekend aggregatie doel is om meer informatie over bepaalde groepen, gebasseerd op specifieke variablen, zoals leeftijd, beroep of inkomen, te verkrijgen.eeftijd, beroep of inkomen, te verkrijgen. +
Data en informatie werkgroep De eerste th … Data en informatie werkgroep De eerste thematische werkgroep is erop gericht de data en informatienoden van de use cases, die tijdens de vorige werkgroep werden geïdentificeerd, in kaart te brengen. Een aantal vragen die aan bod kunnen komen tijdens deze werkgroep zijn: Welke data hebben wij nodig? Aan welke eigenschappen moet de data voldoen? Welke data en informatie brengen we samen om de use cases te kunnen uitwerken? De Werkgroep Data & Informatie staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen de data- en informatienoden in kaart brengen. Specifiek zijn we voor deze werkgroep op zoek naar data analisten, functionele analisten, DPO's, business analisten, eindgebruikers,... De verzamelde inzichten worden vervolgens verwerkt om de data- en informatiearchitectuur verder aan te vullen.Heb jij interesse, specifieke noden, expertise of andere belangen bij dit traject? Klik hier om je in te schrijven. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Thematische werkgroep 1 Data en informatie werkgroep 2024-06-11 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-06-11 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-07-09 13u-16u Teamsologie werkgroep 2024-07-09 13u-16u Teams +
Data en informatie werkgroep: Het potentie … Data en informatie werkgroep: Het potentieel van urban mining voor de bouwsector Tijdens de eerste thematische werkgroep worden de data en informatienoden van de reeds geïdentificeerde use cases in kaart gebracht. De Werkgroep Data en Informatie staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen de data- en informatienoden in kaart brengen. De verzamelde inzichten worden vervolgens verwerkt om de data- en informatiearchitectuur verder aan te vullen. De Data en informatie werkgroep vond plaats op 29 juni 2023. Deelnemers Organisatie Deelnemer Agentschap Binnenlands Bestuur (VLOCA) Fabian de la Meilleure Paul De Wilde Alain Glickman Stad Mechelen/VLOCA Mieke Van Cauwenberghe MyCSN (Data platform/integrator) Niels Kelchtermans OVAM - Vlaanderen Circulair Elmar Willems VVSG Elke de Taeye Buildwise Linde Maes Tracimat Mark Bergmans Starring Jane Jan Boudrez Kevin Braem Kenny Van Wassenhove Esri Belux Tommy De Windt Frank Desmet VITO Steven Claes VITO/VLOCA Yoko Dams Aanleiding en Context Initiatief Met het Urban mining project willen de initiatiefnemers onderzoeken hoe BIM als meerwaarde §kan ingezet worden op de korte keten van de bouwmaterialen in het teken van klimaat neutraal bouwen vandaag maar zeker in de toekomst. We zien dat de bouw nog steeds een overgroot aandeel heeft in de productie van schadelijke stoffen voor het milieu en er heel veel milieu-Impact is op de recuperatie van oudere materialen moet er drastisch ingegrepen worden. En dit kan door: Bij de bestaande bebouwing maximaal in te zetten op het recupereren van bouwonderdelen en bouwdelen en bouwgrondstoffen. Dit met hoogste prioriteit op de meest belastende bouwmaterialen zoals aluminium, staal en beton en baksteen... Bij de nieuw op te richten gebouwen maximaal in te zetten op gebruik van CO2 neutrale of positieve bouwmaterialen die naast het snel plaatsen ook op een gemakkelijke manier hergebruikt kunnen worden en uitgevoerd worden op klimaat neutrale bouwplaatsen We onderzoeken aan de hand van de inspiratiekaart renovatiebeleid welke bestaande type gebouwen het meest CO2 reductie opleveren na een grondige energetische renovatie. We bekijken ook de hoeveelheid aan gebouwen die via een minimale inbreng een langer en/ of nieuw leven kunnen krijgen. We willen door de stad kunnen gaan (Digital Twin light versie) waarbij we gebouwen kunnen vastnemen om daarna hun paspoort te kunnen raadplegen. Vb Utrecht https://3d.amsterdam.nl/index.html#122050.63,486038.88,1143.55,56.00,344.51,0.00 We vinden via het (woning)paspoort bouwmaterialen terug die hergebruikt kunnen worden maar ook alle andere bouwonderdelen met een aanduiding waarvoor ze terug ingezet kunnen worden (10R) sloopopvolgingsplan SOP en herbruikbaarheidsplan Omgekeerd kan de eigenaar zelf ook de bouwmaterialen op het open platform te koop aanbieden nog voor ze uitgebroken of afgebroken worden. We willen daar boven op alles nog realiseren met het minste hinder op de openbare ruimte en voor de bewoners. We willen tenslotte inzetten op een gezond leefklimaat binnen maar ook buiten in het stedelijk weefsel waar het leefbaar moet zijn. Presentatie slide 7 Presentatie slide 8 VLOCA Vloca-principes Om te beginnen werden de VLOCA-principes toegelicht: VLOCA staat voor:- Transparantie: alle ontwikkelingen en verworven kennis wordt transparant op de kennishub geplaatst, voor iedereen bereikbaar met zelfs de mogelijkheid om zaken aan te vullen- Schaalbaarheid: de use cases vormen steeds het startpunt van de analyse waarbij er steeds rekening gehouden wordt hoe men los van een bepaalde technologie een oplossing kan uitgewerkt worden- Technologisch agnostisch: VLOCA houdt niet vast aan één bepaalde technologie. De use cases vormen het startpunt en hierbij wordt nagedacht hoe er los van een bepaalde technologie een oplossing kan uitgewerkt worden. - Gebruikersgericht: oplossingen worden uitgedacht in functie van het standpunt van de eindgebruiker - Interoperabel: de oplossingen kaderen nooit in slechts één project maar zijn bruikbaar voor huidige en toekomstige trajecten. - Duurzaamheid: de oplossingen die gegenereerd worden zijn niet enkel bruikbaar op korte termijn, maar ook voor de toekomst Proces Binnen VLOCA vertrekt men steeds vanuit de use cases die in de vorige sessies geïdentificeerd en gevalideerd werden. Daarnaast konden ook een aantal datanoden gedistilleerd worden. De opzet van de eerste thematische werkgroep is om de datanoden en informatiestromen verder in kaart te brengen en te capteren wat de metagegevens zijn. Daarnaast worden ook de andere gegevens die gekoppeld zijn aan data en informatiestromen-en bronnen geïdentificeerd. De volgende stap in het proces is de verwerking van deze informatie in de architectuur. Hierbij maken we effectief de brug van de business naar de IT zijde. Werkgroepen Tot nu toe hebben we de opstartvergadering en de business werkgroep tezamen met OSLO georganiseerd. Vanaf nu gaan we elk onze eigen weg (maar tegelijk ook weer niet). Hoewel de komende werkgroepen los van elkaar plaatsvinden, is er een constante uitwisseling van informatie tussen OSLO en VLOCA om een complementaire uitkomst te garanderen. Samenvatting vorige werkgroep Het verslag van de vorige werkgroep met een overzicht van alle use cases en concepten kan je hier terugvinden. Oefeningen werkgroep Toelichting use-cases Vooraleer we in de oefeningen konden duiken werd een overzicht gegeven van alle geïdentificeerde use cases: Samenvatting Beschrijving UC1: Aanbod deel Een data register systeem (databank) van alle (al dan niet) geplande af te breken gebouwen met hun gebruikte materiaal ter beschikking stellen. Eigenlijk uiteindelijk is het de bedoeling van alle gebouwen een BIM bestand te hebben. UC2: Vraag deel Een mogelijkheid om een 'vraag' in te dienen van een nieuwbouw of renovatie project met de beoogde materiaal dimensies en specificaties. Kan 'open' of via 'login' UC3: Makelaars deel De mogelijkheid om de vraag en aanbod te 'match maken' door een 'intelligente' algoritme te berekenen voor wie welke materiaal zou kunnen dienen UC4: Offerte aanbod Het kunnen aanbieden van materiaal voor specifieke aanvragers met een concrete offerte UC5: Bestelling uitvoeren Het kunnen aanvaarden van een 'offerte' van de aanbieder van herbruikbare bouw materiaal UC6: Inzichten & Dashboarding Het verkrijgen van inzichten die het beleid kan beinvloeden en/of bijsturen UC7: Principes Schaalbaarheid (voor extra steden en regio's) en interoperabiliteit (voor extra toepassingen) van de toepassing is cruciaal UC8 : Afbraakwaarde Berekening kunnen doen om verkoopswaarde vs rennovatie vs afbraak van eender welk leegstand gebouw UC9 : Woningspaspoort Berekening van 'kwaliteit' van een gebouw, vooral ifv duurzaam (CO2) en Levensduur (wanneer moet iets evt vervangen worden)+ hergebruiksinventaris= Woningspaspoort UC10 : CRM, Helpdesk,... Een CRM en Helpdesk om gebruikers aan te trekken, te stimuleren om te gebruiken en retentie bij een 'mindere' ervaring. UC11: Aanbod deel Een data register systeem (databank) van alle (al dan niet) geplande af te breken gebouwen met hun gebruikte materiaal ter beschikking stellen. Eigenlijk uiteindelijk is het de bedoeling van alle gebouwen een BIM bestand te hebben. Uit deze lijst werden er 3 use cases geselecteerd: UC1, UC2 en UC9. Binnen UC1 kan men de volgende business capabilities onderscheiden: Beschrijving UC1 Via allerlei data over de gebouwen een estimatie kunnen geven van de BIM en die na evaluatie al dan niet op te laden in de BIM databank met vermelding van methode, verwachte kwaliteit van de model ed meer. BC1.2 Alle eigenaars van gebouwen moeten een standaard BIM model kunnen invoeren en aanpassen BC1.3 Bestaande andere standaarden moeten kunnen automatisch vertaald worden naar de standaard BIM model (eigenaars die een soortgelijke maar geen identieke BIM formaten gebruiken moeten de mogelijkheden hebben om die alsnog op te laden en te 'vertalen' naar de BIM formaten) BC1.4 Bestaande ingevulde databases van BIM's (of vertaalbare) modelen moeten met 'druk op een knop' kunnen opgeladen worden in het systeem BC1.5 Herbruikbaarheidsgraad (kwaliteit van het materiaal) kunnen invoeren met objectieve en subjectieve criteria met ook foto's of andere ongestructureerde data bronnen BC1.6 Via allerlei data over de gebouwen een estimatie kunnen geven van de BIM en die na evaluatie al dan niet op te laden in de BIM databank met vermelding van methode, verwachte kwaliteit van de model ed meer. BC1.7 Overzicht van opvulling van de BIM databank incl % tov volledige universum Vervolgens werd ingezoomd op UC2. Hierbij horen de volgende business capabilities: Beschrijving UC2 Een mogelijkheid om een 'vraag' in te dienen van een nieuwbouw of renovatie project met de beoogde materiaal dimensies en specificaties. Kan 'open' of via 'login' BC2.1 Bij nieuwe project kunnen opladen van de 'beoogde' BIM van het nieuwe gebouw/project met laatste datum van aanvraag BC2.2 Het kunnen aanvragen van specifieke materiaal met laatste datum waarop nog kan geboden worden BC2.3 Overzicht van opvulling van de aanvraag databank BC2.4 Indien niet herbruikbaar, dan wordt de kans gegeven om door recyclage 'klanten' ook een aanvraag kan gemaakt worden. Tot slot, de laatste use case met bijhorende business capabilities: Beschrijving UC9 Berekening van 'kwaliteit' van een gebouw, vooral ifv duurzaam (CO2) en Levensduur (wanneer moet iets evt vervangen worden)+ hergebruiksinventaris= Woningpaspoort BC9.1 Met een 'subjectieve' gradatie van CO2 producerende materialen kan een gebouw of delen ervan berekend worden om te zien hoe die scoort op duurzaamheid. BC9.2 Via bepaalde vooropgestelde lijst de levensduur (voor een controle) berekening van een gebouw. BC2.3 Na controle kan een gebouw een nieuwe levensduur estimatie krijgen (manueel aanpassen, en niet automatisch laten overschrijven via business rules) Aanpak Het verloop van de oefening is als volgt: Deelnemers worden doorverwezen naar een miro bord (de link naar dit bord kan je hier terugvinden), selecteren een blauwe post-it en schrijven databronnen op De facilitator van de werkgroep clustert deze databronnen samen onder één gemeenschappelijke noemer Per databron worden eerst de metadata samen gecapteerd, vervolgens de kenmerken van de data Use case 1 Om te beginnen werd er bekeken welke databronnen men kon onderscheiden. Deze databronnen werden vervolgens door de facilitator en in onderling overleg geclusterd. Hierbij een overzicht van de vernoemde databronnen: Cluster Databronnen Cluster 1 Inventarisatie huishoudelijk afval, per gemeente alle hoeveelheden en soorten: OVAM MATIS ondersteunt tracering en registratie van afvalcijfers: OVAM Let op: verschil huishoudelijk en bedrijfsmatig afval! sector gegevens rol IVOO Jaarlijkse, publieke gegevensopvraging, xlxs bestanden publiek beschikbaar Cluster 2 EPC woning --> verplichte renovatie naar niveau Cluster 3 Jaarlijks geproduceerde wegendata (beschikbaar in de markt) kan ook dienen om toestand gebouwen initieel vast te stellen. Gebouwen zijn opervlakkig 'inspecteerbaar'. (Regelmatige vsiuele controle door burgers/gevolmachtigde via Smart Phone google streetview 3d pointcloud Cluster 3 Metadataportaal datavindplaats bruikbaar? https://metadata.vlaanderen.be/srv/dut/catalog.search#/home Cluster 4 Diverse (ERP / inventaris / ...) externe systemen (van leveranciers) met reeds aanwezige producten (goederen & diensten) en hun cycli (nieuw / gewijzigd / product-fit / ...) alsook Billing Of Material (BoM). Zodat we nadien kunnen zorgen, na de data captatie, dat de kwaliteit van de producten voldoet aan de verwachtingen van het aanbod Cluster 5 EPC en gekoppeld Renovatiebudget Cluster 6 Volledig 3D, Point Cloud model Vlaanderen met CAD BIM GIS integratie (impact gebouw omgeving, AI bouwmaterialen detectie, potentieel indoors beelden en (real-time) asset detetie, afbraakbeheer, (real-time) tracking en tracing bouwmaterialen, afbraakmaterialen, etc.) Schaalbaar/reproduceerbaar Mobile friendly Portaal/Loket met gestandaardiseerde wizard en combinatie databronnen via api's, webhooks en potentieel logica op verzamelde data voor productie eindgegevens en inzichten Datavindplaats Vlaanderen In de volgende oefening werden een aantal vragen gesteld over de metadata: Wat is de naam van de databron Wie is de eigenaar van de data Welke gegevens zijn in de data verwerkt/beschikbaar In welke formaten worden de data opgeslagen en opgehaald Om de hoeveel tijd is er nieuwe data beschikbaar (data frequentie en data recentheid) Wat is de dekkingsgraad van de data Hoe wordt de data opgehaald (bv API – push/pull, webhook,..) De deelnemers konden vervolgens per databron (blauwe post-its) die tijdens de vorige oefening gedefinieerd werden in het Miro bord de vragen te beantwoorden. Dit leverde de onderstaande tabel op: Metadata Conditie Datastandaardisatie Kadaster Vergunningen en verplichtingen Beschikbaarheid materialen Naam van de databron Plaatsbeschrijving (incl. foto's) SFB Kadaster Historische waarde/monument Inventaris Onroerend Erfgoed (?) Prijzen (en stock?) van de herbruikbare materialen zie ook databank van OPALIS Conditiemeting Nen standaarden omgevingsvergunningen Leveranciers/producenten materialen hergebruikinventaris Aansluiten op OSLO en initiatieven AWV voor OTL standaardisatie en aanleveren BIM data? https://wegenenverkeer.be/zakelijk/bim/otl Databank Tracimat - sloopopvolgingsplannen (ovb) Eigenaar van de data gebouweigenaar Openbare instantie GIS Openbare instantie GIS tracimat Leveranciers Welke gegevens zijn allemaal in de data verwerkt/ beschikbaar? (beelden van) materialen/bouwelementen en hun conditie bouwjaar, bouwvolume, gebouwtype, materialen ikv sloop,...; voor residentieel>1000m en niet-residentieel >5000m In welk formaten worden de data opgeslagen en opgehaald? Industry Foundation Classes (IFC), Autodesk Revit (. rvt), ArcGIS BIM file Om de hoeveel tijd is er nieuwe data beschikbaar? (data frequentie en data recentheid) bij "sleutelmomenten" zoals verkoop, verhuur,...? bij verplichting sloopopvolging, vrijwillig; continu Dagelijks Wat is de dekkingsgraad van de data? Moet duidelijk leeftijd, samenstelling, behandeling en toestand opnemen Beschrijven van 'bestemming' materialen (bv een binnendeur) Vlaanderen Hoe wordt de data opgehaald? (bv API - push/pull, webhook, ...) Kenmerken van de data Conditie Datastandaardisatie Kadaster Vergunningen en verplichtingen Beschikbaarheid materialen Is GDPR van toepassing (zijn er persoonlijke gegevens aanwezig in de data) en waarom? foto's interieur zijn confidentieel Nee omdat er geen persoonsgegevens zijn Ja Neen Is de data betrouwbaar? (bv. zijn de sensoren betrouwbaar bij regenweer)? Hangt af van de 'objectiviteit' van de meting en expertise ja Ja, en zal meer betrouwbaar worden met de tijd (ervaring deskundigen, feedback door verplichte tracering sinds juli 2022,...) 1: goed 1: goed 1: goed NVT In welke mate is de data interoperabel? Fair principe 3: Metadata zijn zo beschreven dat machines ze kunnen interpreteren en het is duidelijk hoe die (meta)data zich tot andere (meta)data verhouden 1: goed In welke mate is de data beschikbaar voor (her)gebruik? Het is duidelijk hoe data gebruikt en hergebruikt mogen worden en ze zijn rijkelijk voorzien van kenmerken 1: goed Use case 2 Voor de tweede use case ging men op dezelfde manier te werk als voor de eerste: databronnen werden geïdentificeerd, door de facilitator geclusterd en vervolgens werden de vragen met betrekking tot de metadata en de kenmerken van de data beantwoord. Dit leverde de volgende twee tabellen op: Cluster Databronnen Opmerkingen Cluster 1 P & G score (overstroming) Zonnestudie Mobiliteitsscore (bv immoweb) Cluster 2 Informatie van notarissen Cluster 3 Ik neem aan dat dit document gekend is ;-): chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/ https://globalabc.org/sites/default/files/2021-09/GABC_The-Building-Passport_FINAL.pdf asbest inventaris Alles blijft binnen het woningpaspoort en blijft privé pas als de eigenaar wil delen kan de link gemaakt worden naar het open platform? Cluster 3 Zie afsprakenkader over Woningpas en data Protocol OVAM – VEKA - Fluvius: van (fluvius.be) Cluster 4 Materiaaldata koppelen aan BIM model en andere bestaande toepassingen zoals de EPB-software en TOTEM. Daarnaast onderzoeken of we de data kunnen integreren in de Woningpas. Het ontwikkelde paspoort genereert naast de asbestinventaris ook een sloopopvolgingsplan met informatie over de materialen (hoeveelheid, samenstelling, historiek ...) die vrijkomen bij ontmanteling en sloop. TOTEM = (Tool to Optimise the Total Environmental impact of Materials) is een transparante, eenvoudige, digitale interface waarmee de Belgische bouwsector aan de slag kan om de milieu-impact van gebouwen te objectiveren en te verminderen. TOTEM (vlaanderen.be) > M-peil Cluster 5 PID Metadata Inventaris technieken Inventaris materialen Infrastructuur Waardebepaling materialen Naam van de databron uitgevoerde herstellingen bv aan ketel, pomp,...? Asbest Aansluitingen Situatieschets en advies onder voorbehoud onderhoud verslagen ketels/sww product/materiaal specificaties bouwelementen Impact en advies duurzaamheid pand Zonnepanelen, laadpaal, warmtepomp, … Lijst van vermarktbare bouwonderdelen, bouwmaterialen is vrij toegankelijk voor iedereen? Levensduur bouwmaterialen, mogelijkheid tot notificaties in woningpaspoort als levensduur overschreden wordt De bouwcatalogus gaat uit van referentielevensduurdata om te bepalen hoe lang bepaalde materialen gemiddeld kunnen gebruikt worden. Zie rapport: Bouwcatalogus veranderingsgericht bouwen (vlaanderen.be) Eigenaar van de data in gemeenschappelijk nut te delen voor iedereen toegankelijk indicatie welke materialen aan een marktconforme prijs aangeboden kunnen worden Welke gegevens zijn allemaal in de data verwerkt/ beschikbaar? merk, datum, serie nummer, onderdelen, prijs?, manual, datum onderhoud en indien nodig herstelgegevens (datum, vervangonderdeel,...) hergebruikinventaris Buildwise met selectie businessmodel RotorDC, materiaalbank,… In welk formaten worden de data opgeslagen en opgehaald? Om de hoeveel tijd is er nieuwe data beschikbaar? (data frequentie en data recentheid) plaatsing, herstelling, onderhoud,… Wat is de dekkingsgraad van de data? Hoe wordt de data opgehaald? (bv API - push/pull, webhook, ...) Kenmerken van de data Inventaris technieken Inventaris materialen Infrastructuur Waardebepaling materialen Is GDPR van toepassing (zijn er persoonlijke gegevens aanwezig in de data) en waarom? Ja? In welke mate is de data vindbaar? Fair principe 1: Goed beschreven en geïndexeerd en metadata kunnen doorzocht worden niet voor bestaande gebouwen via Madaster wel een estimatie via info architecten, studiebureau meer gedetaileerde info In welke mate is de data toegankelijk? Fair principe 2: Het is duidelijk of en hoe je toegang kunt krijgen tot de (meta)data en op te halen via standaardprotocollen uc1: een deel van de digital twin van Oostende, waarvan de data gerepliceerd worden naar Vlaams Overheid. Waarvan sommige informatie met de burger gedeeld kan worden en andere informatie afgeschermd wordt In welke mate is de data interoperabel? Fair principe 3: Metadata zijn zo beschreven dat machines ze kunnen interpreteren en het is duidelijk hoe die (meta)data zich tot andere (meta)data verhouden In welke mate is de data beschikbaar voor (her)gebruik? Het is duidelijk hoe data gebruikt en hergebruikt mogen worden en ze zijn rijkelijk voorzien van kenmerken Vraag & antwoord en volgende stappen Vragen Nvt Volgende werkgroepen Indien je graag zou willen deelnemen aan een toekomstige werkgroep kan je via de onderstaande link een overzicht van de workshops terugvinden en zich hier inschrijven. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2023-01-12 13u00-16u00 VAC Gent Thematische werkgroep 2 Functionele werkgroep 2023-04-04 13u00-16u00 Digitaal Thematische werkgroep 3 Technologie werkgroep 2023-05-09 13u00-16u00 Digitaal +
Data en informatie werkgroep: Machine Lear … Data en informatie werkgroep: Machine Learning as a Service (MLaaS) Tijdens de eerste thematische werkgroep worden de data en informatienoden van de reeds geïdentificeerde use cases in kaart gebracht. De Werkgroep Data en Informatie staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen de data- en informatienoden in kaart brengen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen. De eerste thematische werkgroep rond 'Groen' vond plaats op 14 maart 2024. Context Initiatief De stad Roeselare beschikt reeds over verschillende machine learning algoritmes die data genereren op basis van fotomateriaal en is hiervoor in contact met verschillende partijen. Deze data wordt gebruikt in zowel operationele processen als bij het nemen van beleidsbeslissingen. Naast het voeden van eerder traditionele databanken stellen ze die intern ook ter beschikking via GEO loketten, en dit op een automatische manier. Deze kennis en ervaring willen ze verder uitbouwen en de algoritmes en processen tegelijkertijd ter beschikking stellen voor ieder bestuur, gaande van het kleinste lokaal bestuur tot bovenlokale overheden als Vlaanderen. Het concept van “machine learning as a service” laat de gebruiker om gebruik te maken van de data en de algoritmes zonder kennis te moeten uitbouwen van de technische achtergrond. Het moet als het ware een “dummy proof” platform worden waarbij men op een éénvoudige manier kan kiezen uit een overzichtelijke catalogus en kunnen “inpluggen” voor de processen die men nuttig acht. Door deze ontzorging kunnen meer besturen stappen zetten richting een sterker data gestuurde beleidsvorming en –voering. Met het streven naar het opschalen van bestaande machine learning processen, het uitrollen van nieuwe mogelijkheden en deze via een platform als een service ter beschikking te stellen van alle overheden willen ze niet alleen zorgen voor meer data op Vlaams niveau maar ook voor “massa productie” aan een betaalbare prijs. Groen inventarisering is een van de toepassingen binnen het MLaaS-project. In het bestuursakkoord van Roeselare werd de doelstelling opgenomen om 100.000 extra bomen te planten tegen 2025. Hiervoor was het nodig om zicht te krijgen op het bestaande aantal bomen. Om dit zo efficiënt mogelijk aan te pakken, wenste men in te zetten op datacaptatie via beeldherkenning. De eerste stap van de datacaptatie was het capteren van beelden en data. Een aantal methoden werden gebruikt: Luchtfoto’s 15cm/pixel (augustus 2020, EuroSense) RGB beelden InfraRood beelden Digital Surface Model (DSM) o.b.v. stereobeelden Digital Terrain Model (DTM) (LiDAR 40cm/pixel, 2014) Gebouwen vectormodel (shapefile, GRB) De tweede stap was de herkenning via machine learning. Hiervoor werd een proefzone van 2x2km (40cm/pixel beelden Vlaanderen) bepaald waarbij er zowel een manuele (door jobstudenten) als een machine learning inventarisering gebeurde. Tot slot werden de resultaten geanalyseerd: Er werd gekeken naar attributen zoals locatie, diameter van de boomkruin en hoogte van de bomen Verder werd de detectie van de bomen vergeleken vrijstaande bomen werden zeer goed geïdentificeerd (resultaat: 98.000 vrijstaande bomen) de identificatie van bosrijk gebied was moeilijk (oa door overlap van boomkruinen) Er werden slechts 1.145 bomen geïdentificeerd in het Sterrenbos (27 ha) vs een stadnaard bomendichtheid: 13.500 à 54.000 bomen (500 à 2.000 bomen/ha) De vervolgstappen bestaan uit de machine learning-data als basis te gebruiken voor een boominventaris binnen het kader van groenbeheer dit kan dan verder verrijkt worden met extra attributen (bvb boomsoort, leeftijd, beheer, snoei etc.) Hoe? op het terrein door middel van ESRI-apps door boomexperten StadLandSchap (provincie West-Vlaanderen) VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. Brainstormsessie Doel Het doel van de brainstormsessie is het volgende: Identificatie van de meerwaardecreatie Inzicht in wat je nodig hebt om de meerwaardecreaties te realiseren Beschrijven van mogelijkheden om de oplossing te verduurzamen Opsommen van valkuilen en potentiële principes waaraan de oplossing moet voldoen Oefening 1+2 Bij deze oefeningen stonden we stil bij de volgende vragen: 1) Waarom is groen inventarisering belangrijk? Laat ons uitgaan van ‘the worst case’: we doen het niet.. Wat zijn de gevolgen? Voorbeeld: We kunnen geen rapportering doen naar Vlaamse overheid/EU (subsidies?) 2) Wat heb je nodig om de geïdentificeerde meerwaardecreaties uit oefening 1 te realiseren? Lijst de acties op Voorbeeld: -Doel: we willen kunnen rapporteren naar Vlaanderen. Wat heb je hiervoor precies nodig? -Ik wil het aantal bomen in een bepaalde regio gedurende een bepaalde tijd visueel weergeven, deze vergelijken met een ijkpunt/objectief en een actieplan opmaken Overzicht Identificatie meerwaardecreatie Toegepast Zicht op evolutie kruinprojectie (in tijd, privaat/publiek, per wijk) -> evaluatie beleid + te nemen acties Foto's identificatie van boomkruinen van 2 periodes met elkaar vergelijken (zorgen dat die idd vergelijkbaar zijn) en de 'delta' te capteren tov een objectief/target. En de verschillen te rapporteren op geografische voor actiebeleid (vanuit Europa mag het niet negatief evolueren) implementeren en monitoring van 3-30-300 regel (= 30% kruinoppervlakte) = Natuurherstelwet (in oct 2023 goedgekeurd in EU) Infraroodbeelden (zomer beelden) en LIDAR data geen objectief zicht op werkvolume / kostprijs voor onderhoud (eigen beheer / uitbesteed) foto's analyseren op basis van AI om type beplanting en oppervlaktes/ lopende meters automatisch te genereren bestekken controleren voor onderhoud openbaar groen Klimaat adaptatie gebeurt via bomen => daarom focus op bomentellingen groenonderhoud ifv type bomen, struiken (snoeien ikv van kwetsbare zones broedseizoen vogels) zicht op wijzigingen in het bomenbestand (uitval (extra bomen te planten), conditie (medisch ingrijpen..) - ifv beheer ) herkenning en signaliseren van wijzigingen in de detectie van bomenbestand ineffici nt groenonderhoud (geen zicht op welke bomen waar staan)=> verkeerde plaatsen gestuurd (ook verkeerde prioritisatie) De periodes waar onderhoud niet mag gebeuren (bvb wegens broedseizoen vogels) met waar heeft dit vooral impact op. Beter inschatting van de kosten van groenonderhoud Verschillende types vegetatie ; health status, ... karteren en op basis hiervan cijfers berekenen m.b.t. - status groen;- welke fractie heeft onderhoud nodig en wanneer (meerjarenplan opmaken) Burgerparticipatie: Waar staan bomen in mijn buurt, welke boom kan ik helpen verzorgen Welke bomen zijn kwetsbaar, waar staan ze orthofoto's en infrarood van meerdere periodes. Hoeveel groen is er in mijn gemeente/wijk om zo CO2 sequestratie in te schatten + rapportage eu De gezondheid van het bomenbestand inkaart brengen (via orthofoto en infrarood) via vliegtuig of drone orthofoto's en infrarood van meerdere periodes van zomer tot zomer (winter beelden zijn hierbij niet echt relevant) trends kunnen uithalen (uniformiseren van inventarisatie en analyses) In sommige gevallen ook Mobile mapping data nodig de natuurherstelwet eist tegen 2030 geen achteruitgang van groen in de stad Infraroodbeelden (zomer beelden) NDVI index = proxy voor gezondheid van de bomen effici nte handhaving gerooide bomen zonder vergunning detectie wijziging bomenbestand op privaat domein, gekoppeld aan kapvergunningen Correlaties detecteren (bijv impact op luchtkwaliteit) data standaardiseren om data te kunnen linken (obv locatie?) en vergelijken. Toegankelijk maken van de data een boom/struik op een bepaalde locatie blijkt telkens opnieuw dood te gaan (ongeschikte locatie / soort boom) monitoring evolutie gezondheid (conditie) van bomen/struiken o.b.v. soort boom / locatie v/d boom via jaarlijkse foto analyses Sociale discrepantie in een stad (sommigen hebben meer bomen/groen dan andere) => hoe kunnen we dit 'nivelleren' Detectie van groene longen in verstedelijkt gebied en hun spreiding (tegen hittestress, verbetering leefkwaliteit) Lokaliseren van bomen en groen op luchtfoto's Open data (voor burgers te informeren): waar zijn de groene zones in de stad, al dan niet met speeltoestellen, hoe is deze ingericht... uitzetten tov andere basiskaarten (vb GRB - gebouwen en wegen voor verharding) uitzetten tov eigen interne databronnen (vb speelpleinen) Correlatie van evolutie bomenbestand met andere omgevingsfactoren vaststellen (bebouwing, verharding, luchtvervuiling, wateroverlast, al dan niet vergunde kap=>handhaving) Detectie van bomen en volume/kruinen van de bomen met daarbij het opbouwen van tijdreeksen om evoluties in de tijd kunnen vaststellen + vergelijken met centrale of eigen databronnen verrijken met andere databronnen, bebouwing, lunchtkwaliteit, wateroverlast,... invasieve (woeker)planten verdringen bomen/struiken pro-actieve detectie van invasieve planten o.b.v. luchtbeelden dronebeelden (=hyperspectrale camera's, want normale 3 kleuren camera's zijn niet voldoende om dit te kunnen capteren) Geen zicht op de verhardingsgraad binnen een AOI (Area of Interest) Kost van graafwerken (in een verharde plaats is kostelijker dan berm bvb) Land cover classificatie kan helpen om de verhardingsgraad te inventariseren + monitoren en de impact van acties te begroten Kan eventueel gebruikt worden voor taxatie (=beloning bij ontharding) ontharding ikv van vergunningsvoorwaarden analyseren -> handhaving 2 luchtfoto's analyseren voor en na handhaving van voortuinen die 'verhard' werden in het verleden => binnen het jaar ook 'winter' foto's mogelijk (zijn zelfs gemakkelijker omdat de bomen niet in de weg staan) => GIM : Belmap/perceel's kenmerken/verharding vanuit winterfoto's gedaan doorlaatbare beton vs niet doorlaatbare beton kunstgras vs echt gras <= via IR foto's Discussie De evolutie van kruin projectie: as is situatie vergelijken met een objectief Is de meest objectieve methode om het groen bestand in een stad te gaan monitoren Indien je een trend wil analyseren is het belangrijk om in acht te nemen dat machine learning ook evolueert doorheen de tijd en dat deze sterker wordt in het herkennen van bomen. Wanneer je deze dan op een ouder luchtbeeld toepast, kan het zijn dat de resultaten verschillend zijn met een ouder machine learning versie. Dankzij de nieuwe Europese wetgeving, nl de natuurherstelwet, is het verplicht om aan monitoring te doen en mag de evolutie uiteraard niet negatief zijn. Het bomenbestand of de kruinprojectie mag er met andere woorden niet op achteruit gaan. Het is belangrijk dat dit op zowel privaat als publiek domein gemonitord wordt. Daarnaast is er nood aan een trend te identificeren zodat er een aangepast beleid kan uitgestippeld worden. Voor het toepassen van de natuurherstelwet heb je een uitstekend monitoringsysteem nodig Groenonderhoud: gericht preventief onderhoud (al dan niet) gaan doen (ifv snoeiperiodes, broedseizoen, staat van groen etc) Signaalfunctie: signalisatie wijzigingen en detectie boombestand In een foto van 2023 wordt een boom geïdentificeerd die er niet meer is op een foto van 2024, dan wordt een signaal gegeven Normaliter wordt bij de groendienst bijgehouden welke bomen vervangen (moeten) worden maar bij bvb stormschade is het niet altijd duidelijk welke bomen afgezaagd werden en waar Dit zou een soort van fail safe kunnen zijn voor de groendienst om na te kijken of ze op alle locaties waar bomen verdwenen zijn, er ook effectief nieuwe bomen aangeplant worden in het volgende plantseizoen. Dit is vooral nuttig in het geval van conditiebepaling van een boom dat dit kan gesignaleerd worden zodat een boomverzorger op pad gestuurd kan worden pm een visual tree assessment uit te voeren. Het is eenvoudiger om met machine learning een bomenbestand te gaan inventariseren dan een volledige groen inventarisatie omdat het groen zich net onder de kruinen bevindt en dus heel wat groen niet zichtbaar is door middel van luchtbeelden. Is een valkuil voor het automatisch automatiseren van groen. De bomen hebben daarnaast de grootste impact op de groene stedelijke infrastructuur wat ervoor zorgt dat je klimaatbestendiger wordt. Klimaat adaptatie gebeurt met andere woorden voornamelijk via bomen. Dit verklaart de focus. Mobile mapping data = camera op auto gemonteerd waardoor je niet alleen informatie van bovenaf maar ook in 3-D kan opmeten Soms kan de kruin van een boom gezond lijken maar is er schade aan de stam. Dit kan je niet zien op luchtfoto's. Het beste signaal is een infrarood signaal dat pixels gaat tellen, of er minder blad is etc: dit is de holy grail van machine learning voor bomen. De NDVI-index (=Landsat Normalized Difference Vegetation Index) geeft een inzicht in de gezondheidstoestand van een boom. Geeft chlorofyl gehalte in groen vegetatie aan. Kan je enkel in de zomer doen wanneer vegetatie in bloei staat Essentieel om trendanalyse te kunnen doen Je hebt infrarood beelden nodig om vegetatie van niet-vegetatie te onderscheiden. Alles boven de 3m van vegetatie = een boom. Zo worden de algoritmes opgemaakt. In de zomer hebben de bomen geen bladeren waardoor identificatie moeilijker wordt. Identificatie van invasieve planen: is dit gemakkelijker te detecteren in de winter dan? GIM: De sensoren en resolutie die momenteel ter beschikking zijn, zijn momenteel onvoldoende om aan dergelijke identificatie te gaan doen bij GIM. Dit is eerder iets voor in de toekomst. Dit is puur een algoritme dat draait, hier komt geen AI aan te pas. Benny: langs de front zijde zou het wel mogelijk zijn. Als je ervoor zorgt dat je je data op een goede manier ontvangt, dan kan je daarmee trendanalyse gaan doen zonder dat het het in een AI moet gaan gieten. Je kan machine learning gebruiken om je data op een gestructureerde manier binnen te halen en indien je dit regelmatig doet, volgens vaste afspraken met beeldmateriaal volgens vaste algoritmes, dan kan je deze nog verder optimaliseren. GIM: Machine learning kan helpen om op voorhand in te schatten of een boom er al dan niet gezond uit ziet. Vervolgens kan je VI of andere berekeningen toepassen op je kanalen. Dit is de eerste stap. Vervolgens heb je een stap waarbij je een machine learning gaat toepassen. Tot slot heb je nog je BI en analytics waarmee je statistische of geografische verschillen mee kan identificeren. Dit is dan meer een data engineering vraagstuk. Benny: het project heeft an sich geen AI. De focus ligt op machine learning. Dit is de technische scope. Terecht dat er aangegeven wordt dat het draait om een script maar het is wel een script met een detectie. Het is dus een machine learning die dat script gegenereerd heeft. GIM: je kan automatische verwerkingsketen opzetten in 3 stappen: 1) je krijgt beelden binnen van een bapaald type waarvoor je indexen maakt 2) je kan een AI algoritme aanmaken (wat niet nodig is voor alle use cases) 3) je berekent de verschillen, regio's, statistieken. Op die manier heb je een volledige procesketen die je in je maintenance tool, rapportage tool voor Europa of management review kan inpluggen. Mogelijkheid om drone aan te kopen om lage luchtfoto's te nemen om exoten in kaart te brengen in duinen en repen. alles hangt af van de camera die in drone steekt: indien dit een hyperspectrale camera bevat (= weerkaatsing licht kan in groot aantal kanalen geregistreerd worden), dan kan die een gedetailleerde beschrijving maken van de objecten die hij inventariseert. Indien je echter een camera gebruikt die enkel in het groot groen en blauw informatie capteert, dan zal dit niet mogelijk zijn. Indien je moet graven door een verhard oppervlak of in een verharde berm: verschillende kost Kan mogelijk bijdragen aan betere inschatting kosten bij bvb Fiber roll-out Linken taxatie/beloning aan ontharding Handhaving: bomen die onrechtmatig gerooid worden zonder vergunning voornamelijk in voortuinen problematiek verharding vaak keuze van lokale besturen om niet meer te gaan handhaven indien je kort op de bal kan spelen ne binnen het jaar kan handhaven dan kan dit de zaak veranderen bvb kunstgras en al dan niet doorlaatbare beton: te detecteren met infrarood maar anders niet te onderscheiden => indien wijziging en signaalfunctie = controleren ter plaatse en handhaven Oefening 3 Bij deze oefening keken we naar manieren om de voorgestelde oplossing duurzaam te implementeren: Hoe kunnen we groen inventarisering duurzaam implementeren? -Welke frequentie en accuraatheid zijn hiervoor nodig? -Hoe kunnen AI en ML bijdragen tot het verduurzamen van de oplossing? -Welke expertise hebben we nodig? -Hoe kunnen we de kosten delen? -Zijn er applicaties die noodzakelijk zijn om de oplossing draaiende te houden? => zorgen dat de groen inventaris up to date gehouden wordt? Overzicht Verduurzamen oplossing Expertise: - Groenbeleid/groenbeheer Datascience GIS, ML/AI => Frequentie is afhankelijk van welke monitoring frequentie nodig heeft Beter 1 type opname dat voor vele toepassingen kan worden gebruikt dan meerdere opnames/beelden (kiostprijs drukken) Frequentie: max. 1 x jaar, min 1x per legislatuur (6 jaar) Kosten : Drone >> vliegtuig >> satelliet beelden Datascience expertise pro-actief om bij 'crisis' situatie te kunnen handelen Data engineering (ETL + GIS) expertise Kosten: groepsaankoop organiseren. Bv 1 vlucht voor hele regio/provincie (bvb Leiedal, Limburg met drone excl. Voeren, 2euros per inwoner per jaar) foto's gezamenlijk aankopen (volume kortingen) foto's hergebruiken voor verschillende algoritmes --> centraal overzicht op een "marktplaats" met samples en kostprijs "hergebruik" licentie aankopen met intercommunales Niet elk soort beeld is bruikbaar voor alle use cases Kost delen: foto's zoveel mogelijk hergebruiken intern, algorithme zoveel mogelijk extern delen financiering - uniformiseren van modellen zodat Vlaanderen/ provincie een pakket kan aanbieden waar lokale besturen kunnen op intekenen Private spelers zijn misschien ook geinteresseerd zoals infrabel ed meer Kosten delen: aanbieden als een service (voor de runningcost) (pay for use) ML-algoritmes delen (documentatie rond welke output het algoritme levert: inhoudelijk + nauwkeurigheid (+ scores per algoritme x beeldmateriaal door afnemers) AWV Federaal niveau ? zeer kritisch evalueren welk type foto's (resolutie / type camera's) nodig zijn voor welk type analyse Matrix usecase vs frequentie en accuraatheid Exploitatie kosten: - hosting; - ML running cost; - support of ML expert; - onderhoud algoritmes Samenwerking tussen instanties voor dezelfde use case => build once apply frequently van de algoritmes Samenwerking over verschillende use case zodat kan voortgebouwd worden op basis code ML algoritme een algoritme voor resolutie / beeld x kan niet zonder meer toegepast worden op resolutie / beeld y Data storage delen (local/cloud): Storage as a Service => brondata (foto's, lidar etc van verschillende jaargangen), opgeleverde ruwe data (bomenbestand, groeninventaris...), afgeleide data(?) beelden ook interessant voor manuele analyses bij besturen indien voldoende hoge kwaliteit/resolutie Kosten voor Desktop GIS of Cloud applicatie delen (open source alternativen) Ondersteuning/support delen voor Desktop GIS/Cloud applicaties Discussie De grootste bezorgdheid bij lokale besturen is de kostprijs van de vluchten voor luchtfoto's. Wanneer het al niet evident is voor een centrumstad als Kortrijk, dan zal dit zeker het geval is voor kleinere besturen. Er moet gekeken worden om zo kostenefficiënt mogelijk een groot aanbod te genereren. Het is belangrijk om beeldtypes en opnames te gaan identificeren die zo ruim mogelijk gebruikt kunnen worden. Ook de frequentie bepalen in functie van het beschikbare budget is primair. Een groepsaankoop organiseren zou ook interessant kunnen zijn waarbij voor bijvoorbeeld een hele regio een vlucht uitgevoerd wordt ipv op het niveau van een lokaal bestuur. In Limburg hebben ze de volledige provincie in beeld gebracht. Hiervoor was een prijsvoorstel op voorwaarde dat voldoende lokale besturen zouden deelnemen. Deze kost kwam op 2 euro per inwoner per jaar. Voor een stad als Hasselt met 80.000 inwoners kom je dan aan een bedrag van 1.160.000 euro per jaar. De kostprijs zal doorslaggevend zijn indien je geen groepsaankopen doet. Zeer interessante beelden die heel gedetailleerd zijn: kroonvolume, stamomtrek etc. Enkel verschillende soorten waren niet haalbaar. Op luchtfoto's kan je tot op 5-7 cm. Dit geeft enorme meerwaarde. De verwerking is natuurlijk dan wel duurder Een drone is interessant voor kleinere oppervlaktes maar eens je volledige steden in beeld wil brengen is dit niet meer kostenefficiënt. Alternatief: in begin, midden en einde legislatuur gaan monitoren ifv natuurherstelwet. Hier kan je al heel wat informatie uit halen. Is beter dan niets. Het moet betaalbaar blijven. Dit is grote valkuil vandaag. De kostprijs zou kunnen dalen bij ontwikkeling van technologie en veranderingen op de markt. Dit kan de frequentie dan verhogen. In functie van de vorige oefening voor elke use cases bekijken welke frequentie we nodig hebben voor welke data. Sommige data zijn beschikbaar op jaarbasis. Bekijken wat haalbaar is. Dronebeelden, luchtbeelden, satellietbeelden: hier zien wij potentieel in. Indien je in een groot volume kan aankopen voor een grotere regio, dan kan dat frequenter gebeuren. Nederland heeft strategie ontwikkeld waarbij ze zich niet enkel baseren op foto's maar deze ook aanvullen met satellietbeelden. Dit hebben we momenteel nog niet in België of Vlaanderen. Kan interessant zijn. Satellietbeelden en crisisomstandigheden: belangrijk om te anticiperen want soms is het te laat om nog een aanvraag te doen. Belangrijk om er bij de tasking rekening mee te houden. Foto's kunnen op 'marktplaats' geplaatst worden waar je ze kan verhuren en waarmee je je kosten kan dekken? Kan je door middel van handhaving aan financiering doen? Waarschijnlijk niet. De inkomsten uit handhaving zullen de kosten niet dekken. Misschien zijn er wel andere spelers buiten de lokale besturen geïnteresseerd in dergelijke foto's bvb Infrabel of nutsmaatschappijen. Indien er geen privacygevoelige zaken op staan of private domeinen te blurren, kan dit de kostprijs drukken. Kost splitsen tussen aankopen of verzamelen van foto's en de operationele kosten Oefening 4 Tot slot werden potentiële valkuilen geïdentificeerd en, op basis hiervan, formuleerden we principes waaraan de oplossing moet voldoen: Voorbeeld: •Self-service zonder goede training kan een risico vormen •Afhankelijkheid van leverancier •Interoperabiliteit van de oplossing •Betrouwbaarheid, en dus ‘vertrouwen’ in de output en dashboard cijfers •Stabiliteit, en dus ‘continuiteit’ van de metrieken in de rapporten en dashboards Overzicht Valkuilen Principes Kostprijs via externe partij de analyse uitvoeren (ze moeten die zelf niet uitvoeren) kleinere gemeentes hebben een beperkte kennis en weten ook niet altijd waar ze terecht kunnen (+hoge kostprijs) Expectation Management : Scope van het MLaaS-platform deint uit richting BI/Analytics i.p.v. afleveren datasets, waardoor verwachtingen te hoog worden gesteld en er teveel debat gevoerd moet worden over hoe je de data wil inzetten en wat je ermee wil gaan doen.Inpsiratie via het platform kan wel, kant en klare analytics is heel at moeilijker gezien linken met andere (interne) bronnen. Limieten van ML : niet alles kan, maar kan ook om bvb 'gaten' of 'anomalien' Te breed gaan in functionaliteit In eerste instantie enkel MUST HAVES uitwerken = 'noden' van lokale besturen (direct toepasbaar lokaal met budget, capaciteit, direct resultaat kunnen opleveren) VB : Invasieve Exoten : sommige lokale besturen zijn daar nog niet mee bezig, dus ze gaan daar niet direct iets mee gaan doen. BAK Bodem AfdekkingsKaart (3/30/300 ?) = bomenbestand brengt niet in kaart, gewoon groen, bebouwd, => niet voldoende of we op vlak van groen gaan we vooruit of niet) de marktplaats (community) valt stil - te weinig bekendheid / potentieel te laag = Marketing (via partner zoals Leiedal, ABB, bvb.) kwaliteit van beelden (bijv bij bewolkt weer) verwachtingen ML-algoritmes technisch tgo inhoudelijke experten niet op dezelfde lijn (bvb vertrouwen in de resultaten, documentatie en co-creatie) transparantie over kwaliteit van de resultaten, ML-algoritme otwikkelingsstatus..., ondersteuning (interne) data scientist of duidelijke documentatie), standaardisatie van beelden en algoritmes Om correct vergelijk mogelijk te maken in de tijd: - Zelfde type beelden - Zelfde periode - Zelfde Ai/ML toepassing zelfs lentebeelden zijn niet vergelijkbaar met zomerbeelden (sommige bomen bloeien later of vroeger) Standaardisatie van beeldmateriaal vanuit 'Vlaanderen' om vergelijking mogelijk te maken Bij wie zit IP van ontwikkeld algorithme Niet het juiste beeld met de juiste kwaliteit voor de use case Security vereisten proces IT security standaarden / principes toepassen ML/AI blijft een model benadering => Geen 100% correctheid / volledigheid continu teit van leveranciers te garanderen (stopzetten deelactiviteiten zoals opname beelden, ontwikkeling algoritmes, support...) Transparantie, bedrijfsvoering (om bvb faillissementen of veranderende werkmethodes op tijd te capteren), gebruikte technieken, documentatie, kennisopbouw intern houden, centraliseren Elk model is use case / beeld specifiek => verwachtingsbeheer Ook input/validatie nodig om het model te trainen false negatives en false postiives) Nauwkeurigheid voor handhaving => eerder een signaalfuncties om ter plaatse te controleren Eerder een 'reactieve' bomenbeleid => is dat wel een direct toepasbaar use case ? aantallen is moeilijker, eerder via oppervlakte van kruinen Discussie Het zou interessant kunnen zijn om voor de data-analyse te kunnen rekenen op een externe partij. Bijvoorbeeld, onlangs werd de stadsmonitor gelanceerd waarbij er data over kruinprojectie moest geanalyseerd worden. Voor kleinere gemeentes kan het interessant zijn om de analyse uit te besteden wanneer ze niet over de nodige expertise beschikken. Benny: Het afleveren van machine learning datasets lijkt haalbaar maar je kan niet verwachten dat je een kant en klaar BI analytics zal hebben rond verschillende thema's. Oppassen voor verkeerde verwachtingen. De analyses voor de stadsmonitor zijn analyses tot op wijkniveau, niet meer. Voor een kleinere gemeente kan dit weliswaar voldoende zijn. In de diepte analyses gaan uitwerken is een ander verhaal. De scope is hier eerder beperkt tot het afleveren van datasets op basis van machine learning. Die kan je binnentrekken op je eigen platform of Power BI en zorgt ervoor dat deze zelfde kwaliteit en kenmerken hebben waardoor je er analyses op kan doen. Je hebt er zelf nog wel werk aan. Machine learning kan niet kant en klaar afgeleverd worden. De machine learning zien wij iets als ondersteunend in databeheer. Je hebt heel wat extra attributen nodig. Het is belangrijk om te werken op de noden van de lokale besturen en een product afleveren dat direct toepasbaar is in de werking. Er zijn heel wat zaken al benoemd die nice to have/know zijn maar wat ga je daar dan mee doen en heb je capaciteit of budget om er iets mee te doen, dat is nog onduidelijk. Best focussen we eerst op de zaken die direct implementeerbaar zijn en die ook direct resultaat geven. Dit geeft ook de garantie dat het zal gebruikt worden en doorheen de tijd geüpdatet worden. Het bestrijden van invasieve exoten: lijkt interessant om te weten waar deze haarden zich bevinden bestrijding staat momenteel nog in zijn kinderschoenen. Er moet budget en capaciteit voorzien worden om hiermee aan de slag te gaan. Is enkel op lange termijn interessant. Marktplaats leeft enkel als er veel vraag & aanbod is Marketing van marktplaats zou kunnen opgenomen worden door partner die regionale context goed kent bvb regionale landschappen zoals in West-Vlaanderen gebeurt door Leiedal. Zij organiseren groepsaankopen voor opnames van luchtbeelden en hebben contacten binnen alle besturen in hun regio. Duidelijk communiceren over potentiële output van machine learning Documentatie wordt cruciaal: moet voor eindgebruiker en afnemer duidelijk zijn zonder dat je technisch profiel bent. Ook mbt creatie: iedereen van in het begin erbij betrekken zodat de verwachtingen duidelijk zijn en ze kunnen input geven over de manier van berekenen etc. Je kan AI of machine learning toepassen op beelden die in het verleden genomen worden en hierop analyses doen belangrijk is om zoveel mogelijk parameters constant te houden om een correcte vergelijking te kunnen doen Als je beelden neemt met een drone of met een sattelier en daarop AI of machine learning loslaat, dan zal je tot verschillende resultaten komen wat voor vergelijkingen maken moeilijk wordt. Er kan al een verschil zitten tussen beelden in verschillende seizoenen. De opnames van de beelden moeten zo gelijkaardig mogelijk zijn. Hierbij kan een draaiboek helpen. Standaardisatie is belangrijk, een soort OSLO voor beeldmateriaal. Wanneer je met een externe leverancier werkt moet je ervoor zorgen dat er transparantie is over hoe dat bedrijf werkt om bvb bij een faillissement vast te zitten. Nauwkeurigheid bij handhaving moet voldoende zijn Eerder signaalfunctie die op terrein moet gecontroleerd worden. Enkel obv detectie van machine learning of AI kan geen handhaving gebeuren. Trendanalyses zijn mogelijk op voorwaarde van dat je goede data hebt Benny: doel van dit project is trendanalyse kunnen doen op hoge resolutie beelden Tot op vandaag is er geen objectieve manier om op een grootschalig niveau bomen te gaan monitoren op vlak van gezondheid. Dit gebeurt momenteel op basis van visuele controles en ervaring maar er is geen systematische benadering. Vele lokale besturen hebben momenteel nog een reactief bomenbeleid, met andere woorden, als er een boom omwaait dan zal men ter plaatse gaan om te remediëren dus de vraag is ook of deze use case direct toepasbaar zal zijn. Op termijn hopelijk wel. Aantal zaken zal de lokale besturen echter dwingen om actief data te gaan verzamelen: Natuurherstelwet Hemelwater verordering Objectief weergeven van sociale ongelijkheid (rijke buurt = meer groen) Wat is de visie omtrent het gebruik van de JaarBAK (Jaarlijkse bodemafdekkingskaart Vlaanderen) van Digitaal Vlaanderen versus de noden die we vandaag bespreken? Bomen zijn het belangrijkste aspect voor inzichten in het groen in de stad omdat zij alle ecosystemen leveren die wij interessant vinden voor klimaatadaptatie van de stad: captatie van CO2, fijnstof afname, verfrissing, verluchting etc. Dit kan je berekenen op basis van het kruin volume en kruin projectie. De JaarBAK bevat een algemene laag groen maar het zegt niets over de waarde van het groen. Het brengt de locatie van de bomen van een stad niet in kaart maar geeft enkel algemeen zicht op de bodemafdekking. Ht gaat niet op detailniveau, wat wel nodig is om een trend te detecteren. Op basis van deze trend kunnen bijvoorbeeld stedelijke verordeningen/richtlijnen uitgevaardigd worden die bepalen dat waardevol groen maximaal moet behouden worden. Deze analyse willen we doen op stads-en wijkniveau, maar ook op private en publieke grond. Problemen kunnen worden geïdentificeerd en acties geformuleerd. De kroonbedekking is een nieuwe GIS-laag die gebruikt wordt voor ecosysteemdiensten die berekeningen kunnen doen en monitoring. Vroeger had je manuele inventarisatie = asset management. Nu zijn het twee aparte werelden die idealiter bij elkaar komen door bijvoorbeeld monitoring via quickscan en terwijl zoeken in de GIS-punten file. Het algoritme zou automatisch de link moeten leggen tussen de twee datasets. Het probleem is dat tegen een inventaris klaar is (met manuele inventarisatie), deze al verouderd is. Ik geloof niet meer in dit systeem. Beter is een quickscan en dan gericht aan bomen met een problematiek werken. Benny: ik zie het als een en-en verhaal. Een manuele inventarisering blijft nodig maar je kan hulpmiddelen inzetten om die zo goed mogelijk up to date te houden. Hierbij kan machine learning een ondersteunende rol spelen. Daarnaast kunnen, door middel van machine learning, trends gedetecteerd worden op een meer geaggregeerd niveau die je kan analyseren. Voor de detail analyse kan je een bijkomende visuele analyse doen. Er zal nooit een exacte technische link kunnen gelegd worden tussen machine learning detectie en een inventarisatie die rijker zou moeten zijn. Machine learning algoritmes testen op accouraatheid op basis van manuele inventarisatie Is gebeurd in Roeselare. Veel velden zijn statisch bvb boomsoort, fruitbomen of niet etc. Enkel controles tijdens beheersingrepen. Databeheer zo licht mogelijk houden: enkel wat echt mogelijk bijhouden - wijzigingen bvb Opname en Miro bord Miro bord Het Miro bord kan je consulteren via deze link . Opname De opname van deze sessie is te bekijken via deze link . Volgende stappen Wat na deze werkgroep? Verwerking van de input van de brainstorm oefening. Verder onderzoek en voorbereiding van de volgende thematische werkgroep. Publicatie op de Kennishub Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Thematische werkgroep 1 Data en informatie werkgroep 2024-03-14 9u-12u Teams Thematische werkgroep 2 Functionele werkgroep 2024-04-16 9u-12u Teams Thematische werkgroep 3 Technologie werkgroep 2024-05-15 13u-16u Teams Thematische werkgroep 4 Technologie werkgroep 2024-06-21 9u-12u Teams +
Data en informatie werkgroep: Slimme Markt … Data en informatie werkgroep: Slimme Markten Tijdens de eerste thematische werkgroep worden de data en informatienoden van de reeds geïdentificeerde use cases in kaart gebracht. De Werkgroep Data en Informatie staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen de data- en informatienoden in kaart brengen. De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen.Heb jij interesse, specifieke noden, expertise of andere belangen bij dit traject? Klik hier om je in te schrijven. Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-09-26 13u-16u VAC Leuven Thematische werkgroep 1 Data en informatie werkgroep 2024-10-21 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-11-21 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-12-19 13u-16u Teamsie werkgroep 2024-12-19 13u-16u Teams +
Data en informatie werkgroep: Slimme stads … Data en informatie werkgroep: Slimme stadsdistributie Tijdens de eerste thematische werkgroep worden de data en informatienoden van de reeds geïdentificeerde use cases in kaart gebracht. De Werkgroep Data en Informatie staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen de data- en informatienoden in kaart brengen. De verzamelde inzichten worden vervolgens verwerkt om de data- en informatiearchitectuur verder aan te vullen. De Data en informatie werkgroep vond plaats op Fout: ongeldige tijd. . Deelnemers Organisatie Deelnemer Agentschap Binnenlands bestuur (VLOCA) Fabian de la Meilleure Laurien Renders Paul De Wilde Alain Glickman Stad Hasselt Kim Bos Michèle Martens Stad Leuven Marij Lambert Bpost Wim Rosseel Buki Owa Alain Van Daele FEBETRA Isabelle De Maegt VIL Domien Stubbe VOKA Wim Pannecoucke TLV Frederic Keymeulen KU Leuven Instituut voor Mobiliteit Carolien Lavigne MyCSN NV Jan Geukens Aanleiding en Context Initiatief Het City of Things project Slimme stadsdistributie vanuit stad Hasselt gaat over de transitie naar een leefbare en veilige binnenstad. Hierbij moet enerzijds rekening gehouden worden met autovrije/autoluwe delen, maar anderzijds zijn er ook grote behoeften naar steeds meer logistieke stromen in de binnenstad. Dit laatste is een effect van snelle leveringen die men tegenwoordig als maar liever ziet gebeuren alsook de sterke groei in e-commerce welke geboost is door COVID-19. Het resultaat van deze groei in logistieke stromen zorgt dat de leefbaarheid in de stad onder druk komt te staan. Om gerichte acties te kunnen nemen, moet men zicht krijgen op leveringen die in de binnenstad gebeuren, dit geeft ruimte om te kijken naar een data gedreven innovatie.Er zijn heel wat globale mobiliteitsdoelstellingen die ook van toepassing zijn voor stadsdistributie. Zo kijkt men enerzijds naar het verminderen van negatieve effecten zoals emissies en overlast. Anderzijds kijkt men dan naar het versterken van positieve effecten, zoals het verhogen van verkeersveiligheid, stimuleren van duurzaam ondernemerschap. Om dit te kunnen bereiken wordt gekeken naar slimme oplossingen. VLOCA Vloca-principes Om te beginnen werden de VLOCA-principes toegelicht: VLOCA staat voor: Transparantie: alle ontwikkelingen en verworven kennis wordt transparant op de kennishub geplaatst, voor iedereen bereikbaar met zelfs de mogelijkheid om zaken aan te vullen; Schaalbaarheid: de use cases vormen steeds het startpunt van de analyse waarbij er steeds rekening gehouden wordt hoe men los van een bepaalde technologie een oplossing kan uitgewerkt worden; Technologisch agnostisch: VLOCA houdt niet vast aan één bepaalde technologie. De use cases vormen het startpunt en hierbij wordt nagedacht hoe er los van een bepaalde technologie een oplossing kan uitgewerkt worden; Gebruikersgericht: oplossingen worden uitgedacht in functie van het standpunt van de eindgebruiker; Interoperabel: de oplossingen kaderen nooit in slechts één project maar zijn bruikbaar voor huidige en toekomstige trajecten; Duurzaamheid: de oplossingen die gegenereerd worden zijn niet enkel bruikbaar op korte termijn, maar ook voor de toekomst. Proces Binnen VLOCA vertrekt men steeds vanuit de use cases die in de vorige sessies geïdentificeerd en gevalideerd werden. Daarnaast konden ook een aantal datanoden gedistilleerd worden. De opzet van de eerste thematische werkgroep is om de datanoden en informatiestromen verder in kaart te brengen en te capteren wat de metagegevens zijn. Daarnaast worden ook de andere gegevens die gekoppeld zijn aan data en informatiestromen-en bronnen geïdentificeerd. De volgende stap in het proces is de verwerking van deze informatie in de architectuur. Hierbij maken we effectief de brug van de business naar de IT zijde. Werkgroepen Tot nu toe hebben we de opstartvergadering en de business werkgroep tezamen met OSLO georganiseerd. Vanaf nu gaan we elk onze eigen weg (maar tegelijk ook weer niet). Hoewel de komende werkgroepen los van elkaar plaatsvinden, is er een constante uitwisseling van informatie tussen OSLO en VLOCA om een complementaire uitkomst te garanderen. Samenvatting vorige werkgroep Het verslag van de vorige werkgroep met een overzicht van alle use cases en concepten kan je hier terugvinden. Oefeningen werkgroep Toelichting use-cases Vooraleer we in de oefeningen konden duiken, werden de twee use cases waarop we zouden werken, toegelicht. De eerste use case was gericht op 'registratie, toegang, monitoring en reservatie'. Deze werd geselecteerd uit de volgende lijst: Samenvatting Beschrijving UC1: Registratie Bedrijf Aanmaken van een nieuwe registratie als organisatie/onderneming om vanaf nu via login/paswoord alle gegevens niet meer opnieuw te moeten invoeren, alsook de kentekens, vrachtwagens en chauffeurs te kunnen registreren en linken aan mijn organisatie. UC2: Aanvraag Levering Een visuele applicatie (='Dashboard') waar de vervoerder een reservatie/registratie, om de binnenstad binnen te rijden, kan aanvragen en ifv het flankerend beleid al dan niet toestemming krijgt om de gevraagde route te kunnen gebruiken. Alternatieve 'routes' (welke wagen, tijdstip, geografische route, enz) worden ook voorgesteld. UC3: Beleids Cockpit uitvoering Het flankerend beleid moet kunnen ingevoerd worden in de 'cockpit' zodat elke aanvraag (= registratie) ifv de gevraagde routes, maar ook de type wagen, ed meer de toegestane routes kan beslist en gevisualiseerd worden via een algoritme die een 'nudging' mogelijk maakt om bvb naar een levering te streven die conform het beleid is en/of geoptimaliseerd kan worden. UC4: Toegang Binnenstad De binnenstad kan toegankelijk gemaakt worden (via paaltjes of via een ANPR camera) voor degenen die een registratie conform het beleid hebben gedaan van de levering. UC5: Monitoring Dashboard De steden krijgen een 'monitoring dashboard' die het volledige vrachtverkeer (registraties, sensoren, camera's data, ANPR, Toegangscontrole,...) grafisch en in cijfers weergeeft om zo een beter beleid te kunnen vormen, evalueren, simuleren en aanpassen. UC6: Reservatie domeinen De vervoerder/handelaar/leverancier moet een laad- en losplaats kunnen 'reserveren' , gelinkt met bestaande software die reeds eventueel bestaat, om zeker te zijn dat de levering zo optimaal zou kunnen verlopen. (Betaling ? : misschien ifv EURO normen van de (vracht)wagen) UC7: Matchmaking Door alle verzamelde data, , zoals beladingsgraad, afmetingen, drops, enz.,alsook de 'registratie' aanvragen, kan de 'waste' in de transport worden weggewerkt door de 'lege'/'beschikbare' volumes te benutten door andere vervoerders, handelaars en leveranciers. UC8: Open Data Alle data die uiteindelijk gecapteerd worden moet kunnen opengesteld worden om zo de ganse quadruple helix de mogelijkheid te bieden om 'Value Added Services' te kunnen bouwen op die data. UC9 : CRM Database Alle contact gegevens om de gebruikers van de tool te kunnen contacteren met 'informatie' of 'customized' berichten met alle optin en optouts alsook 'voorkeuren' van informatie. UC10 : Helpdesk Een helpdesk (live, FAQ, chatbot,...) De tweede use case betrof 'beleidscockpit uitvoering en matchmaking'. Deze werden geselecteerd uit de volgende lijst: Samenvatting Beschrijving UC1: Registratie Bedrijf Aanmaken van een nieuwe registratie als organisatie/onderneming om vanaf nu via login/paswoord alle gegevens niet meer opnieuw te moeten invoeren, alsook de kentekens, vrachtwagens en chauffeurs te kunnen registreren en linken aan mijn organisatie. UC2: Aanvraag Levering Een visuele applicatie (='Dashboard') waar de vervoerder een reservatie/registratie, om de binnenstad binnen te rijden, kan aanvragen en ifv het flankerend beleid al dan niet toestemming krijgt om de gevraagde route te kunnen gebruiken. Alternatieve 'routes' (welke wagen, tijdstip, geografische route, enz) worden ook voorgesteld. UC3: Beleids Cockpit uitvoering Het flankerend beleid moet kunnen ingevoerd worden in de 'cockpit' zodat elke aanvraag (= registratie) ifv de gevraagde routes, maar ook de type wagen, ed meer de toegestane routes kan beslist en gevisualiseerd worden via een algoritme die een 'nudging' mogelijk maakt om bvb naar een levering te streven die conform het beleid is en/of geoptimaliseerd kan worden. UC4: Toegang Binnenstad De binnenstad kan toegankelijk gemaakt worden (via paaltjes of via een ANPR camera) voor degenen die een registratie conform het beleid hebben gedaan van de levering. UC5: Monitoring Dashboard De steden krijgen een 'monitoring dashboard' die het volledige vrachtverkeer (registraties, sensoren, camera's data, ANPR, Toegangscontrole,...) grafisch en in cijfers weergeeft om zo een beter beleid te kunnen vormen, evalueren, simuleren en aanpassen. UC6: Reservatie domeinen De vervoerder/handelaar/leverancier moet een laad- en losplaats kunnen 'reserveren' , gelinkt met bestaande software die reeds eventueel bestaat, om zeker te zijn dat de levering zo optimaal zou kunnen verlopen. (Betaling ? : misschien ifv EURO normen van de (vracht)wagen) UC7: Matchmaking Door alle verzamelde data, , zoals beladingsgraad, afmetingen, drops, enz.,alsook de 'registratie' aanvragen, kan de 'waste' in de transport worden weggewerkt door de 'lege'/'beschikbare' volumes te benutten door andere vervoerders, handelaars en leveranciers. UC8: Open Data Alle data die uiteindelijk gecapteerd worden moet kunnen opengesteld worden om zo de ganse quadruple helix de mogelijkheid te bieden om 'Value Added Services' te kunnen bouwen op die data. UC9 : CRM Database Alle contact gegevens om de gebruikers van de tool te kunnen contacteren met 'informatie' of 'customized' berichten met alle optin en optouts alsook 'voorkeuren' van informatie. UC10 : Helpdesk Een helpdesk (live, FAQ, chatbot,...) Aanpak Het verloop van de oefening is als volgt: Deelnemers worden doorverwezen naar een miro bord (de link naar dit bord kan je hier terugvinden), selecteren een blauwe post-it en schrijven databronnen op De facilitator van de werkgroep clustert deze databronnen samen onder één gemeenschappelijke noemer Per databron worden eerst de metadata samen gecapteerd, vervolgens de kenmerken van de data Use case 1 Om te beginnen werd er bekeken welke databronnen men kon onderscheiden. Deze databronnen werden vervolgens door de facilitator en in onderling overleg geclusterd. Hierbij een overzicht van de vernoemde databronnen: Cluster Databronnen Opmerkingen Cluster 1 Voertuiggegevens DIV Cluster 2 OVAM voor afvalstoffen Cluster 3 Sensoren bij parkeerplaatsen IOT-sensoren in de stad (luchtkwaliteit, parkeersensoren,...) Cluster 4 ANPR data - politie Vergunningen zitten bij de gemeente maar controle nummerplaat bij politie voor ANPR data Cluster 5 Inname openbaar domein (databanken zoals Spotbooking) GiPOD (IoD) Wanneer zijn welke delen van de stad niet toegankelijk? Parkeer-rechtendatabank Reservatie van parkeerplaatsen voor verhuis bv Cluster 6 traffic management systemen van de stad Parkeergeleidingssystemen van de stad (bv. Yunex) Cluster 7 GIS Parkeerzones in de stad Cluster 8 telecombedrijven (proximus bvb) floating car data voor druktemeting/routegeleiding Cluster 9 KBO Cluster 10 data (identificatie) voor authenticatie organisatie/ondernemig Boeking (agenda) voorkeurroutes vrachtwagens en bestelwagens leverzones en levertijdstippen Vergunning (autorisatie) ANPR whitelist (vergunningen) Cluster 11 (voorkeurs)data van handelaren/burgers (manuele ingave?) Type goederen, voorkeuren, etc Levervoorkeuren klanten (groen transport/in hubs/tijdsvensters) Cluster 12 CRM-databank Voor registratie van bedrijven In de volgende oefening werden een aantal vragen gesteld over de metadata: Wat is de naam van de databron Wie is de eigenaar van de data Welke gegevens zijn in de data verwerkt/beschikbaar In welke formaten worden de data opgeslagen en opgehaald Om de hoeveel tijd is er nieuwe data beschikbaar (data frequentie en data recentheid) Wat is de dekkingsgraad van de data Hoe wordt de data opgehaald (bv API – push/pull, webhook,. De deelnemers konden vervolgens alle databronnen, (blauwe post-its) die tijdens de vorige oefening gedefinieerd werden, in het Miro bord plakken om de vragen te beantwoorden. Dit leverde de onderstaande tabel op: Metadata Cluster 1 Cluster 2 Cluster 3 Cluster 4 Cluster 5 Cluster 6 Cluster 7 Cluster 8 Cluster 9 Cluster 10 Cluster 11 Cluster 12 Naam van de databron Voertuig-gegevens DIV Voertuig gegevens OBU Sensordata Data transporteurs GIS/ parkeerzones KBO Levervoorkeuren handelaars burgers Inname openbaar domein vergunningen Voorkeursroutes Floating car Eigenaar van de data FOD Mobiliteit Gewesten/ Viapass Stad of gemeente zelf transporteurs, leveranciers, klanten (mix) Stad of gemeente zelf FOD Economie Handels(wijk)verenigingen Stad of gemeente zelf Stad of gemeente zelf Stad of gemeente zelf (IoD, zwaar vrachtvervoer) Dataprovider of dataset aangekocht door gemeente Politie Stad of gemeente (via enquêtes of stadsbreed CRM) of via burgerprofiel Transporteurs - route optimalisatiesystemen TomTom, Waze, Google Welke gegevens zijn allemaal in de data verwerkt/ beschikbaar? nummerplaat gewichten euronorm … Eigenaar voertuig nummerplaat Euronorm voertuig Totaal toegelaten gewicht voertuig Type sensor, actuele status, context van de sensor, data observations bedrijfsafhankelijk, maar: leveradressen, type goederen, e-cmr's, laadlijsten, chauffeur, type voertuig, transportplanning,… Ondernemingsnummer Adres Naam … verzendings- en leveringsplan van laad & los plaatsen. Of hoe de inventaris zal worden getransporteerd, welke en hoeveel transportmiddelen men wenst te gebruiken, welke route verplicht te nemen, … adres, aantal IoD's, reden inname, Lijst van categorieën die vergunning mogen aanvragen (recht op toegang = juridisch kader/reglement) type zone (30, 50, 70), doorrij hoogte van trajecten, obstakels, LEZ, Schoolomgevingen Gemiddelde doorreis tijden van bepaalde tracé's, actuele congestie op verkeersassen Nummerplaat Tijdstip registratie zone Zie ook Telraam (type voertuig dat voorbij rijdt) geldigheidsduur (specifieke datum of voor 1 jaar of meer), aantal vergunningen per bedrijf Maatstaven voor optimalisatie zoals volledige en tijdige leveringen, transport afstanden en tijden, aantal zones te doorkruisen, … parkeerdata: tijdstip IN/OUT (+ overstay), geolocatie (bij sensoren met SIM-kaart) nummerplaat Sensor & IoT inzichten, historische financiële, operationele, ... data inzichten, ... Voor welke zone In welk formaten worden de data opgeslagen en opgehaald? JSON bedrijfsafhankelijk: CSV, excel, op papier (cmr),… geopackage pdf en jpg Excel geoJSON, polygon Om de hoeveel tijd is er nieuwe data beschikbaar? (data frequentie en data recentheid) Bij inschrijving van het voertuig of wissel nummerplaat Bij registratie van nieuwe voertuigen bij tolinner (bv. Satellic) Real time constante veranderingen, maar belangrijkste is op het punt dat de planning gemaakt wordt (dagelijks, mogelijks méér dan eens) Real time Stad of gemeente is verantwoordelijk om gegevens op te laden in IoD - GiPOD Realtime gegevens worden ingeput bij registratie voertuig voor kmheffing bij een serviceprovider historische data Wat is de dekkingsgraad van de data? alle BE voertuigen (quid buitenlandse voertuigen?) alle voertuigen onderhevig aan de kmheffing > 3,5 t zowel Belgische als buitenlandse alle info van het bedrijf Alle ondernemingen in BE Op stedelijk niveau Bij Waze kunnen specifieke area's geselecteerd worden Hoe wordt de data opgehaald? (bv API - push/pull, webhook, ...) Streaming protocol intern gebruik nu. API mogelijk (must have voor grote bedrijven), maar ook manuele ingave nodig voor kleine bedrijven Webhook? Wellicht API based - pull Kenmerken van de data Cluster 1 Cluster 2 Cluster 3 Cluster 4 Cluster 5 Cluster 6 Cluster 7 Cluster 8 Cluster 9 Cluster 10 Cluster 11 Cluster 12 Is GDPR van toepassing (zijn er persoonlijke gegevens aanwezig in de data) en waarom? De link voertuig-eigenaar is beschermd door GDPR. Mogelijk is de bruiikbare data erg beperkt Afhankelijk van type sensor (Camera, geluid, ANPR, ... zijn GDPR gevoelig) ja: adressen en namen van klanten, chauffeur Is de data betrouwbaar? (bv. zijn de sensoren betrouwbaar bij regenweer)? Afhankelijk van type sensor ja, als in: dit is de data die het transportbedrijf aangeeft voor zijn ladingen. Intern kan een planner natuurlijk 'sjoemelen' In welke mate is de data vindbaar? Fair principe 1: Goed beschreven en geïndexeerd en metadata kunnen doorzocht worden afhankelijk van bedrijf tot bedrijf, welk programma ze hebben In welke mate is de data toegankelijk? Fair principe 2: Het is duidelijk of en hoe je toegang kunt krijgen tot de (meta)data en op te halen via standaardprotocollen niet echt toegankelijk: bedrijven willen niet zomaar hun data afgeven. Daarnaast ook duur om dit te regelen (API inbouwen, extra tijd voor planner in registratie,...) In welke mate is de data interoperabel? Fair principe 3: Metadata zijn zo beschreven dat machines ze kunnen interpreteren en het is duidelijk hoe die (meta)data zich tot andere (meta)data verhouden bedrijfsafhankelijk In welke mate is de data beschikbaar voor (her)gebruik? Het is duidelijk hoe data gebruikt en hergebruikt mogen worden en ze zijn rijkelijk voorzien van kenmerken zeer onduidelijk: geen toestemming van bedrijf, in conflict met GDPR (?), klantgegevens zijn ook eigendom van de klant (en mogen niet zomaar gedeeld worden),… Use case 2 Voor de tweede use case ging men op dezelfde manier te werk als voor de eerste: databronnen werden geïdentificeerd, door de facilitator geclusterd en vervolgens werden de vragen met betrekking tot de metadata en de kenmerken van de data beantwoord. Dit leverde de volgende twee tabellen op: Cluster Databronnen Opmerkingen Cluster 1 Voertuig specificaties i.f.v. vrachten Vrachtgoed + verpakking Radioactiviteits detectie (ook bij vorige use case) RA afval ziekenhuizen bv beladingsgraad bij vertrek (of vrije ruimte) Cluster 2 (Simulatie)modellen voor bv. emissies/type voertuig Cluster 3 Voorkeurs routes Bestemming (leverpunt) Transport schedules / timeframes Cluster 4 Transportvergunning Eigen goederen vervoeren of derden / Europese regelgeving Vergunningen: juridisch kader (reglement) vanuit LB Tijdsvensters voor leveringen opgelegd door de stad Vergunningen: zones met restricties Cluster 5 Evenementenkalender (IoD) Cluster 6 Reistijd Transport kosten Transport berekeningen op real-time transport data Cluster 7 Dataset business rules / beslissingsboom "Slimme Stadsdistributie" (te ontwikkelen) CRM Slimme Stadsdistributie: wie krijgt beloning? Cluster 8 Scholen: schooluren GIS: schoolstraten Cluster 9 Outbound transport naar klant Externe orders en zendingen Inbound transport naar (tijdelijke) opslagplaats Cluster 10 Zelfde databronnen als use case 1? voorkeuren handelaars/burgers Metadata Cluster 1 Cluster 2 Cluster 3 Cluster 4 Cluster 5 Cluster 6 Cluster 7 Naam van de databron Voertuigen en ladingen Leveringsvoorwaarden Evenenemten IOD CRM/ beslissingsboom/ algorithme Simulatie data Voorkeursroute/ levering Real time data leveringen Eigenaar van de data Transport firmas Stad of gemeente zelf Stad of gemeente zelf open data? Handelsverenigingen Stad of gemeente zelf Stad of gemeente zelf LSP's Welke gegevens zijn allemaal in de data verwerkt/ beschikbaar? Ladingskarakteristieken: aard en gewicht lading, volume vrachtgoed Weersverwachtingen? (Sneeuw) duur (start en einde) zones/tijdstippen/voertuigen met restricties (tijdelijk of permanent) emissie per km per voertuigtype SLA Ophalen van (externe) transport data zoals bestellingen uit (externe) CRM systemen, zendingen, routes, locaties, picked en picking lijsten, afspraken, soort laad werk, ... uit (externe) transport systemen, diverse inzichten uit BI en AI systemen, enz. Voertuig karakteristieken: voertuigtype, euronorm, laadvermogen Locatie: Adres? Straatsegment? Parkeerplaats? gegevens scholen typische beleveringsprofielen per soort handelszaak Vervoerder afspraken Reden inname vracht(goed) met restricties Klanten afspraken In welk formaten worden de data opgeslagen en opgehaald? json Om de hoeveel tijd is er nieuwe data beschikbaar? (data frequentie en data recentheid) Bij wijzigingen van voertuigen / verschillende types ladingen Wat de transportvergunningen betreft, elke dag Stad of gemeente is verantwoordelijk om gegevens op te laden in IoD - GiPOD Realtime (near) Real-time (near) Real-time Wat is de dekkingsgraad van de data? België Hoe wordt de data opgehaald? (bv API - push/pull, webhook, ...) Streaming protocol Kenmerken van de data Cluster 1 Cluster 2 Cluster 3 Cluster 4 Cluster 5 Cluster 6 Cluster 7 Is GDPR van toepassing (zijn er persoonlijke gegevens aanwezig in de data) en waarom? Is de data betrouwbaar? (bv. zijn de sensoren betrouwbaar bij regenweer)? In welke mate is de data vindbaar? Fair principe 1: Goed beschreven en geïndexeerd en metadata kunnen doorzocht worden In welke mate is de data toegankelijk? Fair principe 2: Het is duidelijk of en hoe je toegang kunt krijgen tot de (meta)data en op te halen via standaardprotocollen In welke mate is de data interoperabel? Fair principe 3: Metadata zijn zo beschreven dat machines ze kunnen interpreteren en het is duidelijk hoe die (meta)data zich tot andere (meta)data verhouden In welke mate is de data beschikbaar voor (her)gebruik? Het is duidelijk hoe data gebruikt en hergebruikt mogen worden en ze zijn rijkelijk voorzien van kenmerken Vraag & antwoord en volgende stappen Vragen De opname van deze sessie is te bekijken via de onderstaande link. Volgende werkgroepen Indien u graag zou willen deelnemen aan één van de aankomende werkgroepen, kan u hieronder een overzicht van de workshops terugvinden en u ook zo inschrijven. De datum van de tweede thematische werkgroep zal binnenkort gecommuniceerd worden en vindt plaats via Microsoft Teams. Inschrijvingslink volgt. Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2023-01-11 13u30-16u30 Digitaal Thematische werkgroep 1 Data en informatie werkgroep 2023-02-28 09u00-12u00 Digitaal +
Data en informatie werkgroep: Veelzijdige … Data en informatie werkgroep: Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) Tijdens de eerste thematische werkgroep worden de data en informatienoden van de reeds geïdentificeerde use cases in kaart gebracht. De Werkgroep Data en Informatie staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen de data- en informatienoden in kaart brengen. De verzamelde inzichten worden vervolgens verwerkt om de data- en informatiearchitectuur verder aan te vullen. De Data en informatie werkgroep vond plaats op Fout: ongeldige tijd. . Deelnemers Organisatie Deelnemer Agentschap Binnenlands Bestuur (VLOCA) Fabian de la Meilleure Laurien Renders Alain Glickman Provincie Oost-Vlaanderen Pieter-Jan Fieremans Provincie Vlaams-Brabant Alexander Leysen VERA Hans Hubin Kenny Stevens Jan Potemans Erika Van Essche Stad Dendermonde Jan De Backer Stad Halle Kasper Vanbeginne Aanleiding en Context Initiatief Met het Visualo-project willen de initiatiefnemers, waaronder stad Halle, een gezond en aantrekkelijk stadscentrum creëren waar lokale verkopers, horeca, organisaties en de mensen die er wonen samen kunnen komen en de stad op een andere manier kunnen beleven. Aan de hand van verschillende technologieën en gerichte communicatie zal het aanbod van lokale handelaren gepromoot worden om zo interactie met de inwoners te verhogen. Men wil dus specifiek inzetten op lokale handelszaken die een grote impact gevoeld hebben door corona. Daarnaast is hun aanbod weinig bekend bij inwoners en nog minder bij bezoekers. Digitale infoschermen in het straatbeeld zouden een oplossing kunnen zijn maar tonen vooral advertenties voor multinationals en webshops. Daarnaast stelt men vast dat lokale besturen zich vaak beperkingen tot aankondigingen voor evenementen. Het doel van het project is de creatie van een gebruiksvriendelijke app voor handelaars, een performant platform voor de centrum manager en het weergeven van advertenties op slimme infoborden. Hieronder een opsomming van de vereisten per doelgroep: Presentatie Slide 9 VLOCA Vloca-principes Presentatie Slide 9 Om te beginnen werden de VLOCA-principes toegelicht: VLOCA staat voor:- Transparantie: alle ontwikkelingen en verworven kennis wordt transparant op de kennishub geplaatst, voor iedereen bereikbaar met zelfs de mogelijkheid om zaken aan te vullen- Schaalbaarheid: de use cases vormen steeds het startpunt van de analyse waarbij er steeds rekening gehouden wordt hoe men los van een bepaalde technologie een oplossing kan uitgewerkt worden- Technologisch agnostisch: VLOCA houdt niet vast aan één bepaalde technologie. De use cases vormen het startpunt en hierbij wordt nagedacht hoe er los van een bepaalde technologie een oplossing kan uitgewerkt worden. - Gebruikersgericht: oplossingen worden uitgedacht in functie van het standpunt van de eindgebruiker - Interoperabel: de oplossingen kaderen nooit in slechts één project maar zijn bruikbaar voor huidige en toekomstige trajecten. - Duurzaamheid: de oplossingen die gegenereerd worden zijn niet enkel bruikbaar op korte termijn, maar ook voor de toekomst Proces Binnen VLOCA vertrekt men steeds vanuit de use cases die in de vorige sessies geïdentificeerd en gevalideerd werden. Daarnaast konden ook een aantal datanoden gedistilleerd worden. De opzet van de eerste thematische werkgroep is om de datanoden en informatiestromen verder in kaart te brengen en te capteren wat de metagegevens zijn. Daarnaast worden ook de andere gegevens die gekoppeld zijn aan data en informatiestromen-en bronnen geïdentificeerd. De volgende stap in het proces is de verwerking van deze informatie in de architectuur. Hierbij maken we effectief de brug van de business naar de IT zijde. Werkgroepen Tot nu toe hebben we de opstartvergadering en de business werkgroep tezamen met OSLO georganiseerd. Vanaf nu gaan we elk onze eigen weg (maar tegelijk ook weer niet). Hoewel de komende werkgroepen los van elkaar plaatsvinden, is er een constante uitwisseling van informatie tussen OSLO en VLOCA om een complementaire uitkomst te garanderen. Architectuurschema's Samenvatting vorige werkgroep Het verslag van de vorige werkgroep met een overzicht van alle use cases en concepten kan je hier terugvinden. Oefeningen werkgroep Toelichting use-cases Vooraleer we in de oefeningen konden duiken, werden de twee use cases waarop we zouden werken, toegelicht. De eerste use case was gericht op interacties: Samenvatting Beschrijving UC1: Digitale Scherm Digitale Scherm die al dan niet interactief' een advertentie van de lokale winkels laat zien UC2: Media Centrale Een pseudo media centrale die de advertenties controleert, toekent en 'factureert' ifv regels en GRP (Reach, frequentie, enz.) UC3: App Een app die gemakkelijk door de lokale adverteerder toelaat om zijn eigen advertentie te kunnen inplannen en projecteren. UC4: Inzichten Rapportage van performantie van campagnes met inzichten van wat heeft gewerkt en wat niet (Tips en Tricks), incl beleidsrapportering. UC5: Schaalbaarheid Oplossing is uitbreidbaar (en interoperabel) naar andere steden en gemeenten zonder veel aanpassingen UC6:CRM Marketing Communicatie tool om gerichte of informatieve contacten met de klanten of prospecten te kunnen doen UC7:Helpdesk Meldingen en klachten alsook vragen en opmerkingen (FAQ, reviews, ...) Er werd gekozen voor UC1: Digitale scherm. Binnen deze use case kan men de volgende business capabilities onderscheiden: Beschrijving UC1 Digitale Scherm die al dan niet 'interactief' een advertentie van de lokale winkels laat zien BC1.2 Als beheerder wil ik de burger interactieve opzoek mogelijkheden (via touchscreen of via handgebaren...) kunnen aanbieden BC1.3 Als beheerder wil ik aan de bezoeker een snelle begeleiding, kortingen of reservering bvb via touchscreen of QR codes kunnen aanbieden BC1.4 Als beleid wil ik de burgers kunnen bevragen om hun mening op bepaalde vragen te stellen BC1.7 Als wandelaar wil ik het scherm ook kunnen terugvinden op een stadsapp bvb op mijn gsm of zelfs thuis via een website BC1.8 Als wandelaar wil ik de info/korting/enz kunnen delen met derden (vrienden, familie,...) BC1.10 Als wandelaar wil ik via een QR code kunnen gebruiken om tot een 'website' te komen waar ik de advertenties kan 'swipen' om de 'net verdwenen' advertentie te kunnen terugvinden, of de handelaar te kunnen contacteren direct via gsm, enz. BC4.9 Als stad wil ik de digitale schermen ook kunnen gebruiken om mijn beleid en andere info te verspreiden aan de wandelaars in de binnenstad De tweede use case was gericht op inzichten: Samenvatting Beschrijving UC1: Digitale Scherm Digitale Scherm die al dan niet interactief' een advertentie van de lokale winkels laat zien UC2: Media Centrale Een pseudo media centrale die de advertenties controleert, toekent en 'factureert' ifv regels en GRP (Reach, frequentie, enz.) UC3: App Een app die gemakkelijk door de lokale adverteerder toelaat om zijn eigen advertentie te kunnen inplannen en projecteren. UC4: Inzichten Rapportage van performantie van campagnes met inzichten van wat heeft gewerkt en wat niet (Tips en Tricks), incl beleidsrapportering. UC5: Schaalbaarheid Oplossing is uitbreidbaar (en interoperabel) naar andere steden en gemeenten zonder veel aanpassingen UC6:CRM Marketing Communicatie tool om gerichte of informatieve contacten met de klanten of prospecten te kunnen doen UC7:Helpdesk Meldingen en klachten alsook vragen en opmerkingen (FAQ, reviews, ...) Binnen deze tweede use case konden opnieuw een aantal business capabilities geïdentificeerd worden: ID Beschrijving UC4 Rapportage van performantie van campagnes met inzichten van wat heeft gewerkt en wat niet (Tips en Tricks), incl beleidsrapportering. BC4.1 Als beleid wil ik het aantal passanten kunnen meten en ook rapporteren aan de adverteerders BC4.2 Als beleid wil ik het aantal 'viewers' kunnen capteren en tellen en ook rapporteren aan de (potentiele) adverteerders BC4.3 Als beleid wil ik de gezichtsuitdrukkingen van de 'viewers' kunnen meten en ook rapporteren aan de (potentiele) adverteerders BC4.4 Als adverteerders wil de ROI van een campagne kunnen meten en berekenen door de binnenstappers en besteders te bepalen van de 'viewers' BC4.5 Als adverteerder (en medewerker) wil ik de mogelijkheid hebben om (experimentele) AB testen te kunnen doen (vergelijken van verschillende advertenties op de commerciële resultaten van de adverteerder) BC4.6 Als adverteerder wil ik weten welke segmenten ik kan bereiken op welk moment in welke straat segment die evt in mijn doelgroep zitten BC4.7 Als beleid wil ik de schermtijd (in piek momenten bvb) kunnen rapporteren ifv lokale business, overheid, instellingen, corporates, global brands, enz BC4.8 Als beleid wil ik dat de winkels in de zijstraten ook visibiliteit kunnen krijgen dankzij de digitale schermen in de hoofdstraten Aanpak Het verloop van de oefening is als volgt: Deelnemers worden doorverwezen naar een miro bord (de link naar dit bord kan je hier terugvinden), selecteren een blauwe post-it en schrijven databronnen op De facilitator van de werkgroep clustert deze databronnen samen onder één gemeenschappelijke noemer Per databron worden eerst de metadata samen gecapteerd, vervolgens de kenmerken van de data Use case 1 Om te beginnen werd er bekeken welke databronnen men kon onderscheiden. Deze databronnen werden vervolgens door de facilitator en in onderling overleg geclusterd. Hierbij een overzicht van de vernoemde databronnen: Cluster Databronnen Cluster 1 Lijst van handelszaken KBO Ambulante handelaars (food trucks, markten) Overzicht van ondernemers Cluster 2 Bron van wie publiceert: handelaar/overheid Cluster 3 ANPR gegevens voor bv druktemeting Handhaving/ Campagnes adhv GAS-boetes inzichten: bv aantal sluikstorten Politie gegevens Cluster 4 Kaart van de stad GIS Lijst/kaart van musea en andere toeristische bezienswaardigheden Cluster 5 Camera en AI: type gebruiker gekoppeld aan opzoekingen Camera data uit scherm Data voor koppelingen volgens type gebruiker (gebruikersprofiel) Cluster 6 Indien informatie van bv openbaar vervoer, deze specifiek databron Info De Lijn (uurtabellen) Info NMBS (uurtabellen) Cluster 7 Uit databank Sportkalender Agenda met events in de stad Aanbod, recreatieve plaatsen en publieke voorzieningen op kaart Cluster 8 In een use case waar we bv de weersvoorspelling voor de komende 3 uur willen weergeven: databron kmi KMI weersvoorspelling Cluster 9 info over lokale overheid Voor beleidsinformatie koppeling met deze databron Childfocus Cluster 10 Stadsapp Cluster 11 RFID Cluster 12 Databron: digitale weergave van het scherm op bv app Data bron input informatie van de handelaar (product, prijs, korting etc) Databron: afspeellijst advertenties, wat moet wanneer getoond worden? advertentie met nodige info (hyperlinks, telefoon, adres, ...) Cluster 13 Voor reservering, koppeling met specifieke databank/reservatie tool van aanbieder Cluster 14 Afvalkalender Cluster 15 Hoogtepunten nieuws RSS feeds Nieuws van hogere overheden Cluster 16 IOT/ Real time dashboard (luchtkwaliteit, ...) Cluster 17 Indien bv parkeergelegenheid dient weer gegeven te worden, koppeling met de API van parkeermonitoring parkeerdrukte vrije parkeerplaatsen In de volgende oefening werden een aantal vragen gesteld over de metadata: Wat is de naam van de databron Wie is de eigenaar van de data Welke gegevens zijn in de data verwerkt/beschikbaar In welke formaten worden de data opgeslagen en opgehaald Om de hoeveel tijd is er nieuwe data beschikbaar (data frequentie en data recentheid) Wat is de dekkingsgraad van de data Hoe wordt de data opgehaald (bv API – push/pull, webhook,..) De deelnemers konden vervolgens per databron (blauwe post-its) die tijdens de vorige oefening gedefinieerd werden in het Miro bord de vragen te beantwoorden. Dit leverde de onderstaande tabel op: Clusters 1 tot 5 Metadata Cluster 1 Cluster 2 Cluster 3 Cluster 4 Cluster 5 Naam van de databron KBO/handelaars overzicht evenementen/sportkalender/.. Weer Overheidinfo Parkeerdata en/of mobiliteitsgegevens UIT databank Luchtkwaliteit LBLOD kompas databank omgevingsinformatie (weer, luchtkwaliteit,...) Hoeveelheid opgewekte electriciteit door lokale zonnepanelen Eigenaar van de data Kruispuntbank en locatus Lokaal bestuur en verenigingen Open source of stad Lokaal bestuur Lokaal bestuur Alternatief via eigen platform of CRM Parkeerbeheerder Welke gegevens zijn allemaal in de data verwerkt/ beschikbaar? Adres Oplijsting events Pluviometers, wind, temperatuur, vochtigheid openingsuren, aanvraag documenten Parkeertickets per parkeerautomaat BTW-nummer PM 2/10, Co2, No2, Etc Actuele bezetting parkeertoren/parking Activiteit Zaakvoerders In welk formaten worden de data opgeslagen en opgehaald? excell CSV-JSON CSV-JSON LBLOD CSV-JSON pdf CSV-JSON Om de hoeveel tijd is er nieuwe data beschikbaar? (data frequentie en data recentheid) Bij opstart of faillissement handelszaak vaste evenementen = jaarlijkse niet-vast = maandelijks? Kan real time maar niet altijd nodig gemengd = statisch en dynamisch Wat is de dekkingsgraad van de data? Heel Vlaanderen voor VKBO grondgebied stad/gemeente Meestal beperkt, zeer locatie gevoelig lokaal en regionaal Locatie-gebonden (parking, parkeerzone,...) Hoe wordt de data opgehaald? (bv API - push/pull, webhook, ...) MAGDA (manuele excel tabel met mutaties) API, MQTT, SQL-query API API Kenmerken van de data Cluster 1 Cluster 2 Cluster 3 Cluster 4 Cluster 5 Is GDPR van toepassing (zijn er persoonlijke gegevens aanwezig in de data) en waarom? Beperkt. Naam zaakvoerders en adresgegevens nee, overzicht als "doorverwijzing" naar eventpagina ed. Neen Neen Is de data betrouwbaar? (bv. zijn de sensoren betrouwbaar bij regenweer)? Hoge betrouwbaarheidsgraad (maar niet perfect) ja Is overheidsinformatie dus normaal betrouwbaar Problemen met type activiteit (NACE) Problemen met niet doorgegeven faillissementen In welke mate is de data vindbaar? Fair principe 1: Goed beschreven en geïndexeerd en metadata kunnen doorzocht worden 1: goed 1: goed Ja 2 Naam in KBO is niet per se naam van winkel … In welke mate is de data toegankelijk? Fair principe 2: Het is duidelijk of en hoe je toegang kunt krijgen tot de (meta)data en op te halen via standaardprotocollen 2: gemiddeld bestuur heeft de toegang 1: goed Vrije data vanuit bestuur 2 Geen API voor mutaties dacht ik … In welke mate is de data interoperabel? Fair principe 3: Metadata zijn zo beschreven dat machines ze kunnen interpreteren en het is duidelijk hoe die (meta)data zich tot andere (meta)data verhouden 1: goed 1: goed 1: goed In welke mate is de data beschikbaar voor (her)gebruik? Het is duidelijk hoe data gebruikt en hergebruikt mogen worden en ze zijn rijkelijk voorzien van kenmerken Ja Clusters 6 tot 10 Metadata Cluster 6 Cluster 7 Cluster 8 Cluster 9 Cluster 10 Naam van de databron Stadsapp Handhaving Camera's in schermen Kaarten KMI Eigenaar van de data Lokaal bestuur Stad of politie Scherm beheerder Stad Geopunt - digitaal vlaanderen Open street map Welke gegevens zijn allemaal in de data verwerkt/ beschikbaar? Evenementen, handelaren, dienst uren, afval kalender #overtredingen #boetes Zeer divers, tellingen, emoties, AI mogelijkheden Puntlocaties en polygonen (individueel pand tot weergave sportaccommodatie) Toeristische trekpleisters Openbare toiletten Parken, parkings, haltes openbaar vervoer, fietsstallingen, AEDs/EHBO, apotheken In welk formaten worden de data opgeslagen en opgehaald? Excel CSV-JSON JSON Om de hoeveel tijd is er nieuwe data beschikbaar? (data frequentie en data recentheid) Wat is de dekkingsgraad van de data? Hoe wordt de data opgehaald? (bv API - push/pull, webhook, ...) Manueel API API Kenmerken van de data Cluster 6 Cluster 7 Cluster 8 Cluster 9 Cluster 10 Is GDPR van toepassing (zijn er persoonlijke gegevens aanwezig in de data) en waarom? Ja maar politie is verantwoordelijk (opsporingsberichten) Ja, camerabeelden zijn altijd een verwerking van persoonsgegevens Nee Is de data betrouwbaar? (bv. zijn de sensoren betrouwbaar bij regenweer)? Ja 2: hangt af van lokaal bestuur In welke mate is de data vindbaar? Fair principe 1: Goed beschreven en geïndexeerd en metadata kunnen doorzocht worden 1: goed In welke mate is de data toegankelijk? Fair principe 2: Het is duidelijk of en hoe je toegang kunt krijgen tot de (meta)data en op te halen via standaardprotocollen 1: goed In welke mate is de data interoperabel? Fair principe 3: Metadata zijn zo beschreven dat machines ze kunnen interpreteren en het is duidelijk hoe die (meta)data zich tot andere (meta)data verhouden 1: goed In welke mate is de data beschikbaar voor (her)gebruik? Het is duidelijk hoe data gebruikt en hergebruikt mogen worden en ze zijn rijkelijk voorzien van kenmerken 1: goed Use case 2 Voor de tweede use case ging men op dezelfde manier te werk als voor de eerste: databronnen werden geïdentificeerd, door de facilitator geclusterd en vervolgens werden de vragen met betrekking tot de metadata en de kenmerken van de data beantwoord. Dit leverde de volgende twee tabellen op: Cluster Databronnen Opmerkingen Cluster 1 Ingebouwde camera Cluster 2 Tevredenheidsenquête via scherm percentage verdeelde schermtijd, handelaar vs stad, bron platform Cluster 3 QR-codes met doorverwijzingen Cluster 4 Geluidssensor (straatlawaai, incident) Cluster 5 Weersinformatie linkken aan drukte voor context aan handelaar Cluster 6 Betaal terminal data Omzet in aantallen en waarde handelaars Cluster 7 Marktcijfers/ trends (GfK, AC Nielsen, Agoria, ... ) Historische cijfers (situatie voor scherm) Cluster 8 Demografische gegevens Clearchannel gebruik telecom data om te bepalen wie bereikt wordt met schermen Cluster 9 Proximus/ google betaalverkeer drukte (passanten) monitoring gsm-gebruik Inzicht naar handelaar drukte uit wifi data inzicht naar handelaar drukte uit nobiliteitsdata Wifi cijfers drukte in de stad databron fluvius/RTF/Proximus lijst inwoners --> van waar komen passanten? Cluster 10 Bluetooth meting voor druktemeting WiFi/Bluetooth-scanner in scherm Cluster 11 Verkoop bij ondernemers die gelinkt kan worden aan promo via scherm "Actiecodes" handelaars --> hoeveel uit het scherm? Cluster 12 Toestand bezette schermtijd algemeen Touchinput van scherm Eventuele drukknoppen onder of naast het scherm Cluster 13 Aantal navigaties -> goede indicatie of het scherm naar een actie geleid heeft (naar de winkel te stappen) Cluster 14 gemiddelde tijd gebruik scherm verschil advertentie openbare info aantal clicks per advertentie aantal opzoekingen passantentelling Aantal gebruikers van het scherm (aantal keren aangeklikt) Aantal gepost advertenties Meest bekeken pagina's bron platform Aantal QR Code scans Toestand bezette schermtijd per gebruiker Hoeveel airtime is er over? Metadata Cluster 1 Cluster 2 Cluster 3 Cluster 4 Cluster 5 Cluster 6 Naam van de databron Passantentellingen externe data Passantentellingen via sensoren aan scherm Passanten tellingen via sensoren andere locatie Verkoop data handelaars Marktcijfers (trends) Geïnde acties bij handelaars Eigenaar van de data Open source, stad of 3de partij of on site Open source, stad Open source, stad of 3de partij handelaars Lokaal bestuur of derde partij Rol van de boekhouder Welke gegevens zijn allemaal in de data verwerkt/ beschikbaar? Aantallen, modaliteiten aantal passanten vraag wat wil de handelaar ter beschikking stellen, aantal kopers , gemiddelde aankoopsom ? #bezoeker #marktkramers leeftijdscategorie (camera) geslacht (camera) mood (bv. happy) (camera) aantal vrachtwagens (camera) aantal fietsers (camera) returning visitor (WiFi of Bluetooth) aantal auto's (camera) In welk formaten worden de data opgeslagen en opgehaald? CSV, JSON Via platform? Om de hoeveel tijd is er nieuwe data beschikbaar? (data frequentie en data recentheid) Real time of bepaalde intervallen Real time of bepaalde intervallen Real time of bepaalde intervallen kwartaal Sporadisch wanneer de metingen worden uitgevoerd Wat is de dekkingsgraad van de data? Lokaal - stad/gemeente Beperkt maar wel zeer lokaal (waar het scherm staat) Meestal groter maar niet altijd relevant Digitale maturiteit handelaar Hoe wordt de data opgehaald? (bv API - push/pull, webhook, ...) API API, MQTT API, MQTT Manuale uploads? API? Metadata Cluster 1 Cluster 2 Cluster 3 Cluster 4 Cluster 5 Cluster 6 Kenmerken van de data Is GDPR van toepassing (zijn er persoonlijke gegevens aanwezig in de data) en waarom? Ja maar dit wordt zogoed als altijd geanonimiseerd dus ok Ja maar dit wordt zogoed als altijd geanonimiseerd dus ok Ja maar dit wordt zogoed als altijd geanonimiseerd dus ok Ja, persoonsgegevens bv marktkramers Ja, indien terugkoppeling op klantnaam Is de data betrouwbaar? (bv. zijn de sensoren betrouwbaar bij regenweer)? Dient bewaakt te worden - niet onze data Gezien het hier over 1 sensor op een specifiek locatie gaat zou dit vrij betrouwbaar moeten zijn Invraag te stellen naar gelang systeem Tellingen kunnen afwijken, aantal marktkramers niet 2. kortingscodes kunnen gedeeld worden In welke mate is de data vindbaar? Fair principe 1: Goed beschreven en geïndexeerd en metadata kunnen doorzocht worden 1 In welke mate is de data toegankelijk? Fair principe 2: Het is duidelijk of en hoe je toegang kunt krijgen tot de (meta)data en op te halen via standaardprotocollen 1 In welke mate is de data interoperabel? Fair principe 3: Metadata zijn zo beschreven dat machines ze kunnen interpreteren en het is duidelijk hoe die (meta)data zich tot andere (meta)data verhouden 1 In welke mate is de data beschikbaar voor (her)gebruik? Het is duidelijk hoe data gebruikt en hergebruikt mogen worden en ze zijn rijkelijk voorzien van kenmerken Hoge mate aangezien externe data Vraag & antwoord en volgende stappen Vragen De opname van deze sessie is te bekijken via deze link . Volgende werkgroepen Indien u graag zou willen deelnemen aan één van de aankomende werkgroepen, kan u via de onderstaande link een overzicht van de workshops terugvinden en u ook zo inschrijven. De tweede thematische werkgroep zal plaatsvinden op 30 maart om 13u00 via Microsoft Teams. Inschrijvingslink: VLOCA-Visualo . Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2022-11-07 09u00-12u00 Vlaamse Overheid Herman Teirlinckgebouw (Brussel) Thematische werkgroep 1 Data en informatie werkgroep 2023-03-02 13u00-16u00 Digitaal Thematische werkgroep 2 Functionele werkgroep 2023-03-30 13u00-16u00 Digitaal Thematische werkgroep 3 Technologie werkgroep 2023-04-25 13u00-16u00 Digitaal +
Data en informatie werkgroep: VlocaTraject … Data en informatie werkgroep: VlocaTraject/DAKS 2.0/ Lokale economie,VlocaTraject/SInCR - Lokale economie Tijdens de eerste thematische werkgroep worden de data en informatienoden van de reeds geïdentificeerde use cases in kaart gebracht. De Werkgroep Data en Informatie staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen de data- en informatienoden in kaart brengen. De verzamelde inzichten worden vervolgens verwerkt om de data- en informatiearchitectuur verder aan te vullen. De Data en informatie werkgroep vond plaats op Fout: ongeldige tijd. . Deelnemers Organisatie Deelnemer Agentschap Binnenlands Bestuur (VLOCA) Laurien Renders Fabian De la Meilleure Alain Glickman VLAIO Nils Walravens DAKS 2.0 Liederik Cordonni Stad Mechelen Sandrine Raskin The Retail Factory Luc Van Rompaey Stad Leuven Bo Peeters Proximus Joshua Moerman Jasper Botterman Luc Cogneau KERNpunt Justine Vanneste POM West-Vlaanderen Frederik Sack Geo Solutions Sven Vanderhaegen CROPLAND Vincent Thielman Provincie Oost-Vlaanderen Fieremans Pieter-Jan Provincie Antwerpen Kristof Schroons Senne Van Hoof Economisch Huis Oostende Joke Van Gheluwe CrowdScan Ben Bellekens Locatus Gerard Zandbergen Thomas More Marijke Brants Eveline Smolders ViNotion Egbert Jaspers Provincie Vlaams-Brabant Ruben Van de Voorde Citymesh Pim Wittesaele Bart Couvreur Mobiliteit en openbare werken (VO) Klaas Van Cauwenberg Aanleiding en Context Initiatief Er zijn momenteel twee projecten met vergelijkbare opzet: SInCR, gericht op grotere steden, en DAKS 2.0, bedoeld voor kleinere steden. Beide projecten hebben als hoofddoel om data in te zetten ter ondersteuning van zowel handelaars en ondernemers als beleidsmakers, waarbij deze twee doelgroepen verschillende behoeften hebben. De onderzoeksvragen die deze projecten proberen te beantwoorden, zijn gevarieerd. Ten eerste, hoe kunnen we het effect van beleidsmaatregelen en georganiseerde evenementen op het winkelgebied meten? Dit omvat onderwerpen zoals acquisitiebeleid, de evaluatie van acties en evenementen, en mobiliteits- en parkeerbeleid. Een andere belangrijke vraag is hoe we data breder en slimmer kunnen inzetten ter ondersteuning van beleid en ondernemers. Hierbij gaat het om het benutten van data op een meer strategische en effectieve manier. Daarnaast streven deze projecten ernaar om een duurzame samenwerking op te zetten waarbij alle betrokken partijen meerwaarde ervaren. SInCR en DAKS 2.0 zijn voortzettingen van het project 'Datagestuurde Winkelgebieden', waarbij prototypes zijn ontwikkeld, zoals een handelaarsdashboard en een generiek beleidsdashboard op basis van gegevens over drukte, bestedingen, evenementen en weer. Dit heeft enkele uitdagingen en kansen aan het licht gebracht die in SInCR en DAKS 2.0 zullen worden aangepakt: Momentum rond retail data behouden na afloop lopende projecten Kapitaliseren opgebouwde kennis & beperkte datamaturiteit bij handelaars en steden verder opbouwen Beperkte scope en doorlooptijd subsidieprojecten 🡪 scope verbreden Afhankelijkheid van de leveranciers beperken 🡪 datadeling & standaardisering (OSLO & VLOCA) Wildgroei aan platformen 🡪 generiek overkoepelende oplossing: standaardisatie & deelbaarheid maximaal hergebruik en interoperabiliteit Draagvlak handelaars vergroten 🡪 bevragen, leerlessen valideren en coachen Opmaak business- & governance model Binnen DAKS 2.0 zijn er drie belangrijke focusgebieden: acquisitie & passantenmetingen, de impact van parkeer- en mobiliteitsbeleid, en acties en evenementen. Deze drie onderwerpen zullen worden meegenomen in de ontwikkeling van de OSLO Lokale Economie-standaard en de VLOCA architectuurstandaarden. Andere onderwerpen zoals leegstand, e-commerce, duurzaamheid en energie, kunnen afhankelijk van hun belang voor de verschillende doelgroepen eveneens meegenomen worden in dit traject. Hoewel het wellicht niet haalbaar is om op alle thema’s grondig in te gaan in dit traject. VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. Samenvatting vorige werkgroep Het verslag van de business werkgroep kan je hier terugvinden. Doel van huidige werkgroep Introductie geven over het project Toelichting geven over VLOCA Brainstormen over data-en informatiebronnen Brainstormsessie Aanpak Het verloop van de oefening is als volgt: Er worden een aantal vragen overlopen waarop een antwoord gezocht wordt. Deze zijn respectievelijk gelinkt aan beleid, bezoekers en retail. Om te beginnen konden de deelnemers hun 3 prioriteiten aanduiden met betrekking tot de bovenstaande vragen. Vervolgens gingen we over naar het formuleren van assumpties. Deze assumpties dienen telkens een meerwaardecreatie in te houden. Voorbeeld: - vraag: Hoe effectief en efficiënt zijn onze aantrekkings- en retentie campagnes met betrekking tot bezoekers? - assumptie: door het organiseren van een braderie, noteren we een stijging van de omzet van 20% in de binnenstad Na het formuleren van de assumpties gingen we na wat we nodig hebben om ze te bewijzen. Hoe maken we de assumpties haalbaar en meetbaar? Voorbeeld: - omzetcijfers met een vergelijkbare periode te gaan vergelijken Tot slot identificeerden we de databronnen. Welke data hebben we nodig en waarom? Voorbeeld: - omzetcijfers van periode tov andere 'gelijkaardige' periode - data KMI - events kalender -... Uitkomst De input van de deelnemers werd gecapteerd in dit Miro bord . Hypotheses Data- en informatienoden: hoe maken we de assumpties haalbaar en meetbaar? Databronnen: welke databronnen hebben we nodig en waarom? 1 straatparkeren excl. voor bewoners maken zorgt voor X % minder bezoekers aan de binnenstad Data rond straatparkeren Bezoekersdata LEZ data Data rond bezetting parkeergarages Aantal boetes uitgedeeld hierrond 2 Welke vergelijking gaat op: X% meer bezoekers is hoeveel meer bestedingen? Omzetcijfers bezoekersprofiel (herkomst) Invloed van andere factoren: events? 3 X % meer passanten leidt altijd tot X % meer bestedingen 4 niet-lokale bezoekers genereren X % meer omzet dan lokale bezoekers 5 we zijn er als stad in geslaagd om jongeren en jonge gezinnen meer lokaal te doen winkelen Nulmeting nodig sociaal-demografische profielen Bezoekersprofielen, incl leeftijd en gezinssamenstelling meting profielen voor - tijdens -na campagne omzetcijfers Meer als wanneer ... wat is het event dat gemeten wordt? festival? Campagne? 6 Een festival leidt tot x% meer uitgaven in de horeca Bestedingsdata van Worldline voor horeca vergelijken voor dezelfde dagen van de week, enkele weken voor en na het evenement, om te zien of er meer bezoekers zijn voor die weekdag Bestedingsdata Omzetcijfers inkomstendata van horeca nodig Uitwisselingsmatrix tussen festivalzone en horeca in centnrum Passantendata (specifiek bezoeken gegenereerd door festival) Festival bandje (NFC) scannen bij het binnenkomen in de winkel. Dit koppelen aan de uitgaven Weerdata Evenementenkalender 7 Bezoekers in het weekend spenderen x% meer dan buiten het weekend Data van wordonline vergelijken tussen verschillende maanden Bestedingsdata volgens type dag Bestedingen en besteders (volume, aantal unieke) uitzetten tov passanten/bezoekers. Passantendata volgens type dag 8 lokale markt leidt tot meer bezoekers in de binnenstad en meer omzet voor handelaars Omzetcijfers handelaars nodig (voor - tijdens - na markt) Bezoekerstellingen - zeer specifiek gebied + afgebakend in tijd Passantentellingen - zeer specifiek gebied + afgebakend in tijd Bestedingsdata - zeer specifiek gebied + afgebakend in tijd --> opletten ook bestedingsdata van de marktkramers (betaalterminals gekoppeld aan postcode handelaar - ipv locatie markt) passanten data voor - tijdens - na markt Vergelijkingsbasis met andere meetgebieden of momenten (zonder markt) Kaderen in groter gebied obv van contextuele cijfers (bestedingen/bezoekers) 9 Een invoeren van een autovrije binnenstad/kernwinkelgebied zorgt voor 10% meer bestedingen op MLT (> 6m) straatparkeren excl. voor bewoners maken zorgt voor X % minder bezoekers aan de binnenstad Bestedings & bezoekersdata op straatniveau passanten data tijdens lunch + structureel profiel + vermoedelijke werkplaats + vernoedelijke herkomst externe factoren Relatieve evolutie en vergelijking met straten die niet autovrij gemaakt zijn in dezelfde stad / kern data andere steden vergelijken 10 X aantal nieuwe wooneenheden leidt tot X euro meer bestedingen in het nabije winkelgebied 11 Wat is de algemene trend mbt passanten en welke verhouding is er met betrekking tot bestedingen? niet-lokale bezoekers genereren X % meer omzet dan lokale bezoekers Lange termijn data van bezoekersprofielen lange termijn drukte data verhouding van lokale vs niet-lokale herkomsten uit passanten data relateren aan de evolutie van bestedingsdata tijdens dezelfde periode Omcetcijfers van specifieke sectoren en gebieden Omgevingsfactoren 12 inzetten op toerisme zorgt voor minstens X % meer omzet voor alle handelaars X aantal nieuwe wooneenheden leidt tot X euro meer bestedingen in het nabije winkelgebied Bezoekersprofiel kijken of lokale toename in data en/of andere bron (kadaster) ook gekoppeld kan worden aan toename in passanten / bestedingen in de buurt Bestedingsdata Overzicht toerisme campagnes 13 daalt het aantal lokale shoppers (%) als het aantal nationale/internationale shoppers stijgt bezoekers aantallen met lokale en niet-lokale bezoekers omzetcijfers voor lokale bezoekers bestedingsdata met opsplitsing tussen lokale en niet-lokale besteders omzetcijfers voor niet-lokale bezoekers bezoekersaantalen niet-lokale bezoekers (bezoekersprofiel) liefst veel historiek voor bovenstaande databronnen evenementenkalender 14 Besteders hebben een voorkeur voor vlotst bereikbare aanbod 15 2 uur gratis centrum parking laat het aantal bezoekers stijgen met 10% 16 Bezoekers van de kust zorgen voor 10% meer omzet in de horeca en x% in de retail identificatie van bezoeker als profiel profiel bezoeker tellen meten van aantallen bestedingen/transacties per sector weerdata bezoekersprofiel of herkomstprofiel bestedingscijfers of aantal transacties naar sector Weerdata cijfers diverse modi (trein, tram, ...) data per transportmodi 17 Culturele of sportieve events hebben een beperkte impact op de omzet van handelaars 18 Mensen die werken rond de binnenstad zorgen voor % van lunchbezoeken in de binnenstad Analyse van de herkomst van het aantal bezoekers in functie van lunchtijd. Type bezoekersprofielen Bestedingen (sector: reca) Werkgebieden rond de binnenstad Kruisbezoeken 19 Een autovrije winkelstraat, leidt tot 15% meer bestedingen Bestedingsdata van 1j voor het autovrij maken en dan vergelijken met data van 1j na autovrij maken (minstens 1j zodat seizoenseffecten mee onderzocht kunnen worden) omzetcijfers aanleg van de straat/type karakter van straten aantal m2 zacht verkeer, invloed van groen in de straat internationale studies alles op hetzelfde niveau aangelegd (pleingevoel) of verzonken weg tov voetpaden beeldkwaliteitsplan stad/gemeente (indien beschikbaar) 20 Een sportevenement zorgt voor minder bestedingen in de handel Bestedingsdata voor - tijdens - na sportevenement in handel en horeca vergelijken Bezoekersdata Bestedingsdata handel/horeca Evenementenkalender openingsuren handel vs tijdstip sportevenement socio demografisch profiel sportevenement bezoeker retail aanbod parkeerdata (drukte) traject van sportevenement 21 wat is de impact (%) van een toeristische activiteit (tijdelijk) op de handelaren in de buurt bestedingen en passantendata voor - tijdens - na toeristische activiteit bezoekersdata voor, tijdens en na bestedingsdata rond het evenement herkomstprofiel van toeristen activiteitenkalender om externe invloeden in kaart te brengen socio demogragisch profiel van de activiteitsbezoekers retailaanbod omgeving openingsuren toeristische activiteit openingsuren retail in de buurt 22 Een concentratie van het aanbod trekt meer bezoekers aan en genereert meer bestedingen Bestedingsdata (type worldline) Locatus data leegstand en sectoren, o.a. op kaart Locatus data sectoren en leegstand op kaart Bestedingsdata Verschillende zones / steden kunnen vergelijken Bezoekersdata Vergelijkingsbasis tussen verschillende zones of steden 23 als stad kunnen we samen met onze ondernemers meer gericht campagnes opzetten 24 Campagnes op grote mediakanalen (nationale media) hebben een grotere impact op het aantal bezoekers. 25 Communicatiecampage op sociale media heeft meer impact dan op klassieke printmedia Vergelijking bezoekers en bestedingsen voor een na de sociale media campagne campagne-planning bezoekersdata + herkomsten bestedingscijfers Vergelijking bezoekers en bestedingsen voor een na de geprinte media campagne evenementenkalender data rond zichtbaarheid van de campagne (wie heeft het gezien, hoeveel mensen hebben het gezien, ...) profielen data uitstrooigebied geprinte media 26 Een festival leidt toch minder uitgaven in handel maar tot een verbetering van het imago / reputatie van de stad 27 Ideale mix van sectoren handel & horeca aanbieden om meer besteders/bezoekers naar de stad te halen 28 Minder leegstand - meer aantrekking van het winkelgebied 29 Koopzondagen leiden tot een verlaagde besteding (>-20%) op voorafgaande zaterdag Bestedingcijfers (zoals Wordline data) - weekends vergelijken met en zonder koopzondag bestedingen/transacties per dag bestedingen per weekend (vergelijking met en zonder koopzondag) Relatieve analyse tov bezoekers bezoekers per weekend (vergelijking met en zonder koopzondag) evenementen Wat was de verhouding van de drukte in de binnenstad tov afgelopen zaterdag en de trend van de x zaterdagen ervoor. impact weerdata ijking met andere steden/gemeenten die koopzondag toepassen 30 Voldoende keuze (winkels met gelijkaardig aanbod) zorgt voor meer bestedingen. 31 Investeringen in vergroening en rustruimte zorgen voor meer bezoekers die langer in de stad blijven. Kwalitatief onderzoek kwantificering groen in de stad Vergelijking omzet voor en na inplanting kwalitatief onderzoek duurtijd verblijf bezoekers bomenplan stad/gemeente meetstaat/plannen omgevingvergunning heraanleg/herinrichting overzicht omgevingsvergunning ivm heraanleg openbaar domein vergroening vs parkeergelegenheid evenementen kalender Weerdata verkeersdata (drukte in de buurt) 32 met onze campagnes verhogen we het gebruik van randparkings met 30% 33 Door parkeren in de kern gratis te maken zorgen we voor een extra omzet van xx% in de binnenstad 34 Door het organiseren van de wekelijkse markt trekken we x% extra bezoekers aan tussen xh en xh en deze zorgen voor een extra omzet van x% in de binnenstad 35 Koopzondagen leiden tot meer beleving in de stad en hogere bestedingen 36 een verlaging van de leegstand zal tot 10% meer passage zorgen en een verhoging van de winkelbeleving bij consumenten huidige leegstand in gebied Locatus leegstands data historische reeks van leegstand in gebied passantentelling aantal passanten in gebied kwalitatief beleving meten (bevraging) bevraging van passant rond beleving voor en na ingreep leegstand consument meten bezoekersprofiel andere factoren om impact te isoleren 37 Voor kleine steden zijn promocampagnes minder relevant indien ze gevoerd worden op grote afstand van de stad in kwestie. In kaart brengen potentieel doelpubliek / verplaatsingsbereidheid per gemeente bereik van een kleine stad ligt lager dan bij grootstad waar ligt het wingebied van een kleine stad bezoekersprofielen herkomst bezoeker indien niet de woonplaats, ligt de werkplaats dan in de buurt van de stad 38 Er is een directe correlatie tussen nabijheid parking met bestedingen. Benchmark tussen gelijkaardige lokale besturen met verschillend parkeeraanbod Bestedingsdata Parkeermogelijkheden Perceptie - bevragingen sector waarvoor aankoop gebeurt Hoe verhoud de vullingsgraad van de parkeergarages zich tov de drukte. profiel van de stad/bezoeker Shopping gewoontes van de bezoekers Mobiliteit Imago van de parking Kwaliteit van de parking 39 Het imago / de reputatie van de stad heeft een impact op het aantal bezoekers en besteders Kwalitatief onderzoek bij de bezoekers - vergelijken in verschillende steden Definitie imago / reputatie Bezoekerstellingen Hoe 'imago / reputatie' definieren? Bestedingsdata Bezoekersprofielen tijdsgebonden analyse criminaliteit cijfers vs bezoekerscijfers Kwalitatief onderzoek - perceptie Kwalitatieve bevraging omtrent buurtgevoel aantal bezoekers voor en na een negatief bericht in de media Vergelijking met andere steden/gemeenten 40 De ondernemer die samen met de stad een campagne voert zal x% meer netto omzet genereren dan campagnes alleen te voeren omzetcijfers budget impact type campagne: print, social media Vraag & antwoord en volgende stappen Vragen Wordt er binnen de scope van dit project ook gekeken naar een mogelijke negatieve impact op de rest van de stad? Is er ook een luik in het onderzoek dat kijkt naar preventie? - Dit is een heel relevante vraag en de ondersteuning van retail is een belangrijke focus maar niet ten koste van alles. We werken in een bredere context dan enkel wat wij willen bereiken. Opname De opname van deze sessie is te bekijken via deze link . Volgende werkgroepen Indien u graag zou willen deelnemen aan één van de aankomende werkgroepen, kan u via de onderstaande link een overzicht van de workshops terugvinden en u ook zo inschrijven. De tweede thematische werkgroep zal plaatsvinden op 8 november om 9.30 in het Herman Teirlinck gebouw (Brussel). Inschrijvingslink: VLOCA-Lokale economie . Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2023-09-19 VAC Gent Thematische werkgroep 1 Data en informatie werkgroep 2023-10-10 09:00-12:00 Teams Thematische werkgroep 2 Functionele werkgroep 2023-11-08 Teams Thematische werkgroep 3 Technologie werkgroep 2023-12-07 13u-16u Teams +
Data en informatie werkgroep: VlocaTraject … Data en informatie werkgroep: VlocaTraject/Slim Ruimtelijk Plannen Tijdens de eerste thematische werkgroep worden de data en informatienoden van de reeds geïdentificeerde use cases in kaart gebracht. De Werkgroep Data en Informatie staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen de data- en informatienoden in kaart brengen. De verzamelde inzichten worden vervolgens verwerkt om de data- en informatiearchitectuur verder aan te vullen. De Data en informatie werkgroep vond plaats op 14 november 2023. Deelnemers Organisatie Deelnemer Agentschap Binnenlands Bestuur (VLOCA) Laurien Renders Alain Glickman Intercommunale Leiedal Lucas Verbanck David Lingier Inge Wydhooge Thomas Goemaere Stad Gent Jan Godderis Dieter Nieuwborg District09 Ann Bernaert Departement Omgeving VPO Wouter Brems Stijn Vanderheiden Hans van den Berg Project SHIFT Filip Hellyn Provincie West-Vlaanderen Wim Beerten Digitaal Vlaanderen Martine Delannoy Geo-IT Wouter De Wilde Avineon Rob GIM An Heirman ESRI Belux Frank Desmet VITO Karolien Vermeiren Context Initiatief De uitdaging waar we voor staan, is de aanzienlijke druk op de bebouwde en open ruimte in Vlaanderen. Het vraagt om een slimme benadering van de nog beschikbare ruimte. We streven ernaar om data te integreren in ons beleid en onze dienstverlening, met als uiteindelijk doel het creëren van leefbare buurten en bruisende centra. De vraag is: hoe bereiken we dit? Het antwoord ligt in het verkrijgen van inzicht in wanneer een buurt behoefte heeft aan zaken zoals bijvoorbeeld extra voorzieningen, groenvoorzieningen en handelsmogelijkheden. Dit inzicht stelt ons in staat om bij bouwprojecten op een slimme manier te beslissen waarop we moeten inzetten. In dit streven zijn we op zoek naar een aantal essentiële elementen: 1. Een permanente monitoring van de kenmerken van een buurt, zodat we op de hoogte blijven van de veranderende behoeften en trends. 2. Het vermogen om de impact van specifieke bouwprojecten op deze kenmerken te beoordelen. We willen begrijpen hoe nieuwe ontwikkelingen de leefbaarheid van een buurt beïnvloeden. 3. Het ontwikkelen van visuele tools die deze informatie kunnen presenteren op een manier die relevant en begrijpelijk is voor verschillende belanghebbenden, waaronder burgers en medewerkers die vergunningen verlenen. VLOCA VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders. Samenvatting vorige werkgroep Het verslag van de business werkgroep kan je hier terugvinden. Doel huidige werkgroep Introductie geven over het project Toelichting geven over VLOCA Brainstormen over data-en informatiebronnen Brainstormsessie Aanpak De focus van de oefeningen van vandaag ligt op de voorzieningen. Men kan een bepaalde wijk analyseren op 2 manieren: Een gebied analyse “In deze buurt zijn er 1200 gezinnen met 3 parken, 2 scholen en een ziekenhuis en bebouwingsgraad van 0.3” Meestal in termen van Indexen of Graden, zoals : •Aantallen •Bebouwingsgraad, verhardingsgraad, bewoningsdichtheid… •VT-index… Een netwerk analyse “Het nieuwe Woonblok A37 is 250 meter van een park" Meestal in termen van Afstand en tijd, zoals : •In m/km in vogelvlucht of via de straten per fiets/te voet/wagen/… •In minuten per fiets/te voet/openbaar vervoer/wagen… Een van de elementen waar we naar op zoek gaan zijn de "attributen": In de context van business architectuur verwijzen attributen naar kenmerken of eigenschappen van entiteiten binnen een organisatie die belangrijk zijn voor het begrijpen, ontwerpen en beheren van de bedrijfsprocessen. Een entiteit kan van alles zijn, zoals een product, dienst, bedrijfsproces, actor (bijvoorbeeld een medewerker of klant), of een ander element dat relevant is voor de bedrijfsvoering. Voorbeelden: •Resolutie: Hoe fijn de details zijn in de weergave van de geografische gegevens. •Actualiteit: Hoe recent en up-to-date de geografische informatie is. Oefeningen Oefening 1 Waar denk je dat het meeste potentieel zit op vlak van digitalisering bij ruimtelijke planning? Formuleer de uitdagingen waar je momenteel mee geconfronteerd wordt. De focus ligt hierbij op de voorzieningen. Oefening 2 Formuleer de bijhorende attributen bij de geïdentificeerde problemen. Oefening 3 Databronnen identificeren: we gaan na welke databronnen kunnen gebruikt worden (ifv elke attribuut) om per entiteit de GPS waarden, afstanden, attributen te kunnen opvullen (ook bvb gebruik makend van pragmatisch berekeningen zoals intra- of extrapollaties). Geef aan welke valkuilen er kunnen zijn bij het gebruik van deze databronnen. Outcome Uitdagingen Attributen Databronnen Valkuilen Voorbeeld: Iedere bewoner heeft een park binnen 150 meter van woning Wat zijn de coördinaten van het park/woonblok Kenmerken van het park (opp, capaciteit,..) 150m = te voet/fiets/auto? Gemeentelijke bronnen Info bewoner Databank parken Open street maps databank parken stopt aan de grens iedere buurt heeft nood aan Xm² schaduwrijk groen (tegen hittestress) 3 bomen = puntlocaties, 30 = kruin - oppervlakte 300 = afstand landgebruikskaart VITO wat is luwteoase? hoe selecteren vanuit andere datasets? een buurt bevat voldoende groen en schaduw of zicht op groen (3 30 300 regel) voor goeie analyse van schaduw heb je 3D nodig - kan minimaal de kruinen zijn groenkaart vlaanderen, OSM = landuse park veranderende standaarden een bewoner moet toegang hebben tot een park (recreatief), zichtbaar groen, natuurgebied, bos Locatie toegang park studie dOMG - zicht op groen (nog lopende) - output = dataset Laatste lidar coverage VL verouderd iedere bewoner heeft een 'luwteoase' binnen X meter van de woning copernicus EU luwteoase inclusief minimale licht, geluid, geurhinder Belmap (3D DT Benelux- GIM) LiDAR vlaanderen (2013-2015) -> Aan vernieuwing toe (alternatief stereobeelden) parken in Vlaanderen 2022 (Dugernier et al) Dep Omgeving obv OSM en Sport Vlaanderen nieuwe LiDAR data of actuele voldoende gedetailleerde stereobelden inwonersaantallen per adrespunt zijn er voldoende sportvoorzieningen binnen bereikbare afstand Doelgroep sport-voorziening POI-service Vlaanderen inventaris van de locaties (centroide), geen info over bv capaciteit, toegang,.. Locatie toegang sport-voorziening capaciteit, toegang, bij 1 voorziening kan middelpunt genomen worden, bij grotere sportinfrastruur meerdere ingangen Iedere bewoner hoort te wonen die niet overstroomd geraakt - moet in een groter kader gezien worden: systeemdenken, hangt ook af van genoeg ruimte voor water: infiltratie --> minder verharding risicokaarten VMM Belmap (3D DT Benelux- GIM) > overstomingsrisico bewoners moeten toegang hebben tot kwaliteitsvolle (lokale) voedingsproducten (concept van voedingsmoerassen) frequentie openingsuren, capaciteit winkel, specialiteit (typologie) naar analogie van POI updatefrequentie studie steunpunt gezondheid (of gezond leven vzw) - voedselmoeras/voedselwoestijn/… hoe lokale bio boer en buurtinitiatieven capteren? VKBO iedere bewoner heeft een kwalitatieve fietsstalling nodig binnen x m van de (voordeur) van de woning Lokale inventaris (in vorm van databank)? - oslo openbaar domein Afhankelijk van lokale bijhouden = Niet gebiedsdekkend voor Vlaanderen Open street map zijn er mogelijkheden om duurzaam energie te gaan uitwisselen? - opleggen van pv's - warmtenetten (pas rendabel vanaf bepaalde dichtheid) - beo-velden - wijkrenovaties wat is de energievraag(dichtheid) warmtekaart (veka) conflict tussen individueel belang & timing versus gemeentelijke visie & acties wat is het energie-aanbod : reeds geïnstalleerde PV, mogelijke bronnen voor restwarmte, … HE potentieelkaarten (Geopunt) toegankelijkheid & beschikbaarheid & up to date zijn van de data wat is het potentieel (theoretisch) HE aanbod (m² dakopp., mogelijkheden uit de ondergrond) EPC labels? Fluvius Belmap (3D DT Benelux GIM) iedere bewoner heeft een halte OV nodig binnen X meter afstand - Voor bewoners in den gemeenten rond de grote steden en centrumsteden: een halte voor openbaar vervoer naar die steden op wandelafstand bij voorkeur bij tram locaties haltes uurregeling capaciteit Data Delijn, NMBS, TEC/MIVB Granulariteit Mobiscore Grenszones ieder gezin heeft binnen redelijke afstand van de woning toegang tot deelauto's/deelautolocatie https://www.vlaanderen.be/basisbereikbaarheid/combimobiliteit/hoppinpunten/locaties-hoppinpunten autodelen.net hoppinpunten iedere bewoner heeft een deelfietslocatie binnen X meter afstand welk type fietsen, aantal beschikbaar (real time?) Mobit , Donkey republic, blue bike, … Deelsteps, Bird? Hoppinpunten iedere bewoner heeft op x meter toegang tot een laadpunt - wandelafstand - link privaat/publiek vraagstuk Mechelen? private laadpalen - privacyregeling doet moeilijk - oplossing mechelen? https://mow.vlaanderen.be/laadpalen toegang tot sociale voorzieningen binnen x meter: bibliotheek, school, sportaccomodatie, kinderopvang, dokter, apotheek, zwembad,.. up-to-date inventaris van verschillende types voorzieningen (met geometry) Zorgvoorzieningen erkend door het Agentschap Zorg en Gezondheid via POI-service verschil in administratieve zetels en vestigingsplaatsen per voorziening definiëren binnen welke afstand voorziening aanwezig moet zijn > 10min wandel/ auto / ?? Here maps - tomtom Capaciteit van een voorziening VKBO bibliotheek.be Belmap - POI's Iedere bewoner heeft een eerstelijns gezondheidszorg nodig - Iedere bewoner zou toegang op wandelafstand moeten hebben tot een groepspraktijk/artsenpraktijk die 24/24 7/7 open is, idem apotheek (in het weekend is dat een uitdaging) Zorgvoorzieningen erkend door het Agentschap Zorg en Gezondheid via POI-service WFS Interessante Plaatsen Ratio van het aantal inwoners per erkende huisarts eerstelijnszones Cyclomedia / Xenomatix Iedere bewoner dient op wandelafstand van een afvalcontainer/vuilbak/containerpark te wonen in de toekomst coördinaten containerpark - hoe omgaan met tijdelijke containerparken? OSM Grenszones Lokale databanken (?) via afval-intercommunales of VKBO? glasbollen, kledingcontainers? gemeentelijke data - vuilnisbakken openbaar domein (out of scope) iedere bewoner heeft een 'luwteoase' binnen X meter van de woning. Inclusief minimale licht, geluid, geurhinder - link met stiltegebieden? inventaris parken & groen + onderverdeling in typologie / opp / capaciteit /... Geluidbelastingskaart https://omgeving.vlaanderen.be/geluidsbelastingskaarten wat is luwteoase? hoe selecteren vanuit andere datasets? Emissies (luchtkwaliteit etc) geluidsbelasting + andere > niet gebiedsdekkend Geur? Enkel voor belangrijke spoorwegen & grote steden Licht? Telramen en citizens science projecten? hinderdata niet gebiedsdekkend beschikbaar, enkel obv 5 jaarlijks schriftelijk leefomgevingsonderzoek veilige fietsinfrastructuur binnen (school)buurt, Iedere voetganger/fietser heeft nood aan veilige verkeersinfrastructuur gegevens over fiets- en voetgangersinfrastructuur: kwaliteitskenmerken, afmetingen, kwantiteit, gebruik Fluvius (verlichtingspunten) typologie verlichting is niet altijd gekend (Fluvius) typologie van fietsinfrastructuur : fietsstraat / vrijliggend fietspad /... + kwaliteit Verkeersbordendatabank Up to date? Volledig? aanwezigheid veilige verlichting Cyclomedia / Xenomatix provincie - vlaanderen Een buurt wordt geen verkeersknelpunt of niet gebruikt als sluipweg tijdens de ochtend- of avondspits, als gevolg van wegenwerken, ... (Historische of voorspelde) traffic flow per tijdstip - Locatie openbare werken GIPOD - Telraam - GPS datasets Betrouwbaarheid traffic flow voorspelling in buurt of gebied met minder data Typologie buurt iedere buurt heeft X aantal plekken die aanzetten tot ontmoeten: zitbanken, speelzones Cultureelcentrum bvb VKBO hoe definiëren? plaats voor een school ouders moeten een kinderopvangplaats op minder dan x minuten van hun woning/werk hebben locatie, capaciteit Department Omgeving : locatie Geen capaciteit Departement onderwijs? parameters om een jeugdvriendelijke gemeente te worden - is hetzelfde vraagstuk als voor ouderen (jongeren/ouderenzorg) - 8-80 cities model - jongeren kunnen in de buurt van een school hun boterhammen opeten op een gezellige plek (jeugdvriendelijke gemeente) - Voor jongeren dienen er (veilige) 'hangplekken' te zijn in de buurt inventarisatie ontmoetingsplaatsen > parken, sport, buurthuis, speelpleintjes, ... POI, KBO iedere buurt ligt op X afstand (of X fietstijd) tot een BFF (bovenlokaal functioneel fietsroutenetwerk) - analogie fietssnelwegen - fix the mix het BFF en de fietssnelwegen de geactualiseerde shape-files van het BFF en gerealiseerde en geplande fietssnelwegen afbakening van buurt. Meetpunt (rand of centrum), cfr. voor andere uitdagingen Verschillende buurten afbakening van buurten. aparte oefening of bestaande oefening bijv. typering bouwblokken (oefening plattelandsatlas voor provincie West-Vlaanderen (atelier romain) ook op bouwblok typering bouwblokken - segmentaties buurten Belmap, NIS kernen provincies - woonlinten-kernen dOMG Vragen & opname Vragen Opname De opname van deze sessie is te bekijken via deze link . Volgende stappen De volgende stappen zijn: Verwerking van de input van de brainstorm oefening Rondsturen van een link naar dit verslag en powerpoint Verder onderzoek en voorbereiding van de tweede thematische werkgroep waarvoor u zich hieronder kan inschrijven Andere werkgroepen Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2023-09-27 Stadskantoor Gent Thematische werkgroep 1 Data en informatie werkgroep 2023-11-14 Teams Thematische werkgroep 2 Functionele werkgroep 2023-12-19 Teams Thematische werkgroep 3 Technologie werkgroep 2024-01-23 Teams +