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
- Summary Test by Wikibase Solutions +
- Summary Testbestand Architectuur +
- Summary The four layers of interoperability. +
- Summary Twitter icon +
- Summary Twitter icon NEW +
- Summary WhatsApp icon +
- Synchronicity architectuur +
- TH WG SRP 38 +
- TH WG SRP 39 +
- TH WG SRP 40 +
- TH WG SRP 41 +
- TH WG SRP 43 +
- Summary The Digital Europe Programme (DI … Summary </br> The Digital Europe Programme (DIGITAL) is a new EU funding programme focused on bringing digital technology to businesses, citizens, and public administrations. How to make Europe greener and more digital are the twin challenges for our generation, and our success in meeting them will define our future.</br> The European Commission has begun to look at a greener Europe through the lens of the European Green Deal. At the same time, it is opening up discussions about the move to a more digital world: the digital transition.</br> Digital technology and infrastructure have a critical role in our private lives and business environments. We rely on them to communicate, work, advance science and answer current environmental problems. At the same time, the COVID-19 pandemic highlighted not only how much we rely on our technology to be available to us, but also how important it is for Europe not to be dependent on systems and solutions coming from other regions of the world. Paving the way for achieving this goal is DIGITAL programme.</br> The Digital Europe Programme will provide strategic funding to answer these challenges, supporting projects in five key capacity areas: in supercomputing, artificial intelligence, cybersecurity, advanced digital skills, and ensuring a wide use of digital technologies across the economy and society, including through Digital Innovation Hubs. With a planned overall budget of €7.5 billion (in current prices), it aims to accelerate the economic recovery and shape the digital transformation of Europe’s society and economy, bringing benefits to everyone, but in particular to small and medium-sized enterprises.</br> The Digital Europe Programme will not address these challenges in isolation, but rather complement the funding available through other EU programmes, such as the Horizon Europe programme for research and innovation and the Connecting Europe Facility for digital infrastructure, the Recovery and Resilience Facility and the Structural funds, to name a few. It is a part of the next long-term EU budget, the Multiannual Financial Framework 2021-2027.</br> </br> Scope </br> The first four work programmes implementing DIGITAL are:</br> </br> DIGITAL Europe - Work Programme (excluding the topics below) </br> DIGITAL Europe - EDIH European Digital Innovation Hubs </br> DIGITAL Europe - Cybersecurity </br> DIGITAL Europe - High Performance Computing </br> Domains </br> Still tbd after calls</br> </br> Partners </br> The first three work programmes were adopted by the European Commission and follow extensive consultations with the Member States </br> The European High Performance Computing Joint Undertaking (EuroHPC JU) is a joint initiative between the EU, European countries and private partners to develop a World Class Supercomputing Ecosystem in Europe.rcomputing Ecosystem in Europe. +
- Summary The ODI is a non-profit with a m … Summary </br> The ODI is a non-profit with a mission to work with companies and governments to build an open, trustworthy data ecosystem. They work with a range of organisations, governments, public bodies and civil society to create a world where data works for everyone.</br> </br> Scope </br> Consultancy & advice: Talk to us about ways we can help you with your data strategy, data policy or new opportunities </br> Courses & training: Learn more about data with our in-house courses and e-learning offer </br> Membership & networking: Join our ODI Members network, with organisations, startups, charities and more </br> Research and development: We're constantly researching and developing new ideas. Join our exploration </br> Public policy: Our public policy team provides thought leadership on emerging issues in data policy and digital technologies </br> Tools & resources: Use our free tools and resources to help with your everyday work </br> Startups & fostering innovation: Work with startups or help us develop your startup idea </br> Data as Culture: Our world-class art programme that aims to expand the public understanding of data </br> Domains </br> The ODI aims to enable the development of data infrastructure in ways that benefit people, companies, governments and civil society. They focus on increasing data flows around the data ecosystem , improving skills and capabilities, and encouraging innovation. They support data flows, focusing our efforts in three broad areas:</br> </br> Improving the data practices of organisations so that they can build and manage adequate data infrastructure and data use . The work on data literacy and data assurance is part of these efforts. </br> Tackling challenges so that the data ecosystem works better . The data institutions work and the work on data ecosystems and innovation are part of this. </br> Gathering and creating research, evidence and knowledge about data and the benefits of open, trustworthy data access, to inform companies and policymakers as they create data infrastructure, assets, practices and policies. This is their evidence and foresight work. </br> Partners </br> Full list available via this link .resight work. Partners Full list available via this link . +
- Summary The project Physical Internet Li … Summary </br> The project Physical Internet Living Lab (“PILL”) started at the beginning of 2021. The Physical Internet (“PI”) is an innovative concept, a next-generation vision on efficient, resilient and sustainable logistics. The PI aims to interconnect transport networks, looking to move freight in the most optimal way ⎯ from origin to destination. But before going into detail, let’s start with some terminology.</br> </br> Scope </br> Firstly, we want to increase the efficiency and effectiveness of node processes by utilizing assets and spare capacities in order to accommodate transport demand and facilitate the complex physical reality of logistics. In this regard, optimization of human resources, equipment, infrastructure etc. will be taken into account. </br> Secondly, we want to create transparent real-time services to be used by companies operating within nodes connectable to long-distance flows by rail, road, or inland waterways. </br> Furthermore, we will devise collaborative and proactive strategies for companies enabling them to use their assets to the maximum. The latter, proactive, refers to proactive solution-seeking of IoT objects when receiving different ETAs of transport means approaching the nodes. This will result in the development of new operational models as well as business models that support autonomous interaction between PI nodes and their network(s). </br> And last, but not least: we want the Digital Twins to create a symbiosis between the virtual risk-free environment and the real physical system. Such a symbiosis will contribute to reducing infrastructure investments and expansion as a result of enhanced and improved operations within nodes. </br> Domains </br> Transport & Mobility </br> Physical Internet </br> Partners </br> VUB (Vrije Universiteit Brussel) </br> Imec </br> VIL </br> VLAIO </br> </br>Advisory Board</br> </br> Air Cargo Belgium </br> Alice </br> Vlaamse Waterwegen </br> Delca Logistics </br> Dockflow </br> DP World </br> ECS </br> FOD Financien </br> GS1 </br> Lanark </br> Lineas </br> Microsoft </br> Vlaanderen mobiliteit & openbare werken </br> NxtPort </br> P&G </br> POM </br> Port of Antwerp </br> Port of Zeebrugge </br> PSA </br> Rombit </br> RX Seaport </br> Sensolus </br> T-mining </br> The Beacon </br> Trivizor </br> UbidataTrivizor Ubidata +
- Summary The provision of air traffic man … Summary </br> The provision of air traffic management (ATM) services has for a long time been a national monopoly. In addition, it has traditionally been considered a natural monopoly due to the need for large infrastructure investments. Both of these elements are now changing. Air traffic management has been under increased scrutiny of the European Union since the start of the Single European Sky program. In addition, technological revolutions have reduced the need for large-scale ground-based infrastructure and expensive equipment, questioning the natural monopoly character of the industry.</br> </br> Scope </br> The overall goal of the COMPAIR project was to study various institutional and market design options for introducing competition for en-route services. Our results suggests that introducing some form of competitive elements would:</br> </br> Increase ANSPs efficiency </br> Lower charges </br> Increase technology uptake </br> Decrease fragmentation (for some options) </br> Domains </br> In order to assess their potential contribution to the European Single European Sky objectives. The project had the following goals:</br> </br> Propose a set of new institutional market designs for the introduction of competition in the European ATM sector; </br> Define a framework allowing a comprehensive assessment of the impact of different institutional market designs; </br> Develop a variety of economic and network simulation models allowing the assessment of the proposed approaches; </br> Assess the feasibility and acceptability of proposed institutional changes for various market actors; </br> Propose a vision for the implementation of the most desirable institutional structures. </br> To achieve the overall objectives, the project focused on four potential ways to introduce competitive elements in the ATM sector:</br> </br> Performance regulation with variations in ownership and governance models </br> Unbundling </br> Tender of licenses for en-route air traffic services </br> Flight centric, sector-less operations </br> Partners </br> Transport & Mobility Leuven NV (TML) conducts fundamental and applied research to support policy decisions. It is our mission to help society by offering scientifically sound analyses. To this end, we rely on quantitative research: modelling, statistical analyses, simulations, and prognoses. Our research fields are traffic, passenger and freight transport and the related economic impact and environmental problems. Transport & Mobility Leuven is a private research company founded in 2002 by the KU Leuven. Our focus is both scientific as practical: we are the bridge between the university and society. TML works for governments and businesses and supports their policies by research. In this way, new research needs are discovered and TML can adequately develop new research initiatives. </br> Nommon is a research-intensive technology company that provides decision support tools and consulting services for organisational intelligence and policy assessment. For this purpose, Nommon integrates supporting databases with analytical and simulation models that make use of a variety of mathematical tools, from data mining or operations research, to the most recent and innovative methods from complex systems science. Nommon works in sectors whose performance emerges from the complex interaction of interdependent policies, technologies, and socio-economic trends, including transport systems, logistics and supply chain, energy and environment, and urban and regional planning. Nommon is particularly active in the field of transport research. </br> The Hebrew University of Jerusalem , Israel’s first university, is a multidisciplinary institution of higher learning and research, where intellectual pioneering, cutting-edge scientific discovery, and a passion for learning flourish. Research and creativity have always been the cornerstone of the Hebrew University of Jerusalem since its inception in 1928. For over 80 years, Hebrew University researchers have not only carried out outstanding basic research, but have also responded to the needs of society. The University is justly proud of its position at the cutting edge of world science. Its researchers publish widely in leading international scientific and scholarly journals, conduct collaborative research projects with noted scholars from other countries and compete successfully for research grants from international and national funding sources (NIH, DFG, EU, Human Frontier, ERC, Howard Hughes, ISF).The Hebrew University of Jerusalem has been ranked among the top universities in the world in two comprehensive surveys conducted by The Times Higher Education Supplement of London and Shanghai University. In The Times listings of the world’s 100 top universities in specific academic fields, the Hebrew University was ranked 43 rd place in the arts and humanities; 44th in social sciences, 52nd in science, and 63rd in biomedicine. Funding of more than $107 million supports 4,500 research projects in progress. Within the framework of these projects, 45% of all the student body (24,000) are graduate students and are working towards advanced degrees, gaining invaluable experience as the project leaders of tomorrow. The University has educated and trained thousands of students - 28% of all doctoral candidates in Israel are enrolled at the Hebrew University- providing the skilled manpower needed for many aspects of Israel's development </br> Slot Consulting is a consulting company focusing on research and innovations. The company has a rich aviation reference portfolio and provides services to other innovative industries as well. Slot Consulting was founded in 2001 in Budapest, Hungary. The term “slot” indicates partly the strong airport relation but also the fact that we are keen to find the slots, niche areas both for our clients or for our own developments. Slot Consulting is involved in European research programmes from the beginning. We have an outstanding reference portfolio in European aviation research projects and so Slot Consulting is one of the leading European SME in this field. Performing research in consortium with leading European players is an opportunity to learn the directions of the European air transport and aeronautics research trends, the general research and development principles and to improve our expertise in the focus areas. This helps us to be more innovation focused. Slot Consulting has done ATM market assessment for application of new technologies and service provision. The researched area has covered mainly Central Europe and the focus was on technological, economical, and political environment for service provision. Slot Consulting has participated in the National Aeronautical Strategy development - Slot Consulting regularly participates in development of the National Aeronautical Strategy building providing expertise in ATM and airport related regulations. Slot Consulting has done Hungarian Aeronautical potential research - A study was done by Slot Consulting on Hungarian Aeronautical industry potential on request of Canadian Embassy to establish the industry potential and possible areas of Hungarian - Canadian cooperation.an - Canadian cooperation. +
- Summary There are two next generation 3D … Summary </br> There are two next generation 3D city models of Helsinki available: a semantic city information model and a visually high-quality reality mesh model. </br> The city information model allows users to perform a variety of analyses focusing on energy consumption, greenhouse gases or the environmental impacts of traffic, for example. The reality mesh model can be utilised in various online services or as the basis for all kinds of design projects, such as planning the exit routes and the locations of performance stages and sales stalls for city events, for example. </br> The models are available as open data.</br> </br> Domains </br> 3D Rendering & Gaming engine </br> Urban Planning </br> Meer informatie </br> Extra info is beschikbaar via deze link . info is beschikbaar via deze link . +
- Summary URBANAGE is a European initiativ … Summary </br> URBANAGE is a European initiative focused on helping urban planners and policymakers harness the power of new technologies for more inclusive, evidence-based decisions. As Europe faces an oncoming demographic shift where its urban populations will consist of a higher proportion of older adults, the need for cities to offer better services for happy and healthy aging is crucial.</br> URBANAGE supports the development of age-friendly cities through the roll-out of a new decision-support ecosystem, co-created by relevant stakeholders (public servants) and users (older adults). The innovative ecosystem will bring together people’s needs and city data with new technologies including Big Data analysis, and Artificial Intelligence modeling and simulation algorithms, all accessed via Local Digital Twins with online Gamification features for enhanced engagement purposes. </br> Based on a thorough understanding of users’ needs, the ecosystem (tools, and co-creation) will be validated by piloting use-cases in three local planning systems in Europe (Helsinki, Santander, and Flanders).</br> </br> Scope </br> Urban Test Beds</br> </br> Helsinki </br> Santander </br> Flanders </br> Main Objective </br> To assess the potential benefits, risks and impact of implementing a long-term sustainable framework for data-driven decision-making in the field of urban planning for aging well in cities, by means of an engagement strategy with relevant stakeholders and users, supported by disruptive technologies such as urban digital twins, big data analytics, artificial intelligence, and gamification.</br> </br> Objective 1: To understand the implications (including potential benefits, risks, social impact, and acceptance) and requirements from the end-user’s perspectives (public servants and senior citizens) of using disruptive technologies for evidence-based decision-making and enhanced governance in urban planning for age-friendly environments, including their ethical and legal consequences. </br> Objective 2: To integrate disruptive technologies such as urban digital twins, big data analysis, and artificial intelligence in an Ecosystem of tools designed to support public decision-making and services provided in urban planning for age-friendly environments. </br> Objective 3: To validate the URBANAGE Ecosystem in 3 use cases (Helsinki, Santander and Flanders region), and evaluate its implementation with end-users to extract lessons for replication. </br> Objective 4: To develop a viable business model to ensure the long-term sustainability of the URBANAGE Ecosystem and tools and pave the way for market uptake. </br> Domains </br> Age Friendly Cities The URBANAGE project aims at providing a long-term sustainable framework for data-driven decision-making in the field of urban planning for age-friendly cities. URBANAGE will develop and validate a decision-support Ecosystem that integrates urban digital twins, big data analytics, predictive algorithms profiting from artificial intelligence, and gamification for enhanced engagement purposes. Based on a thorough understanding of users’ needs, it will be validated by piloting use-cases in the context of three local planning systems in Europe (Helsinki in Finland, Santander, in Spain, and the Flanders region, in Belgium). These technologies will support the analysis, modeling, and simulation of physical conditions for aging well in cities: accessibility and safety in all areas of the physical environment, including public spaces, streets, public transport, and housing, as well as the location of public equipment and services or the access to community services. </br> Digital Twins The URBANAGE Digital Twin is an extensible platform that allows modelling the city and its processes through a virtual replica. The implementation of the Digital Twin will be done by developing components to facilitate data modelling and mapping, geospatial analysis and data retrieval through web services (API and advanced visualization services). The modelling of the city elements will be achieved through the City Information Model (CIM) that represents the four layers that allow connecting the different elements which define the city and its processes. These four layers are citizen, urban planning, physical infrastructure and technical infrastructure. Functionality 1: Short-term decision-making support for city management (DSS) Universal accessibility is a key issue to ensure older people´s active and healthy living. It is important to guarantee day-to-day accessibility to services and amenities that older people use most frequently, such as health care centers, cultural and social equipment, public spaces, etc. URBANAGE DSS will facilitate the prior evaluation of the impact of different events and unexpected situations in the older population of an area, and to propose alternatives. Moreover, it will provide information and alternative routes and services to older people based on analysis of the physical urban conditions (topography, density, climate), services use and their usual routes, in the event of: works, breakdowns, special events, special weather conditions, and so on. Functionality 2: Long-term decision-making support for city planning (PSS) Planning for age-friendly cities will benefit from the creation of an age-friendliness index for neighbourhoods which, through a combination of different data sources analysis, will assess, with an integral approach, the readiness of an urban area to ensure an active and healthy living for an older population. Based on this index, and with inputs from historical data (also from the projects' Functionality 1) URBANAGE Planning Support System will allow for the creation and evaluation of different scenarios and alternatives for making long-term planning decisions geared at improving an area´s age-friendliness index. </br> Partners </br> Engineering Ingegneria Informatica </br> Tecnalia </br> Imec </br> ATC </br> University of Helsinki </br> 21C </br> Consulting Informatico </br> AGE Platform Europe </br> Forum Virium Helsinki </br> AAL </br> Informatie Vlaanderen </br> Santandertander +
- Summary Virtual Gothenburg is mainly bei … Summary </br> Virtual Gothenburg is mainly being developed so that urban planning can be carried out in a smarter and more efficient way, helping us to build a better city for its inhabitants. The Digital twin will enable detailed studies of the city from three perspectives:</br> </br> We can understand what the existing city looks like and how it works at the moment </br> We can control different functions in the city on the basis of what is happening now in real time </br> We can predict and plan simulated future functions or events in the city. </br> “Today’s society is so complex and has so many interacting factors that we need to develop new tools for urban planning. In a digital twin, we can create scenarios for new planned areas complete with traffic simulations for those areas. For example, how are autonomous vehicles perceived and how do they work? It is easy to carry out sun and shadow studies as well as noise/sound and air quality analyses. We also need to address the challenges of downpours and segregation,” says Eric Jeansson.</br> “With a digital version of Gothenburg, not only will we be able to work with urban and regional planning and transport issues in a smarter and more efficient way, but we can also have a better dialogue with the city's inhabitants about future changes to the city."</br> </br> Domains </br> City & Urban Planning </br> 3D Rendering & Game engine </br> Meer informatie </br> Meer info kan je vinden via de onderstaande video en via deze link .e video en via deze link . +
- Summary With Gaia-X, representatives fro … Summary </br> With Gaia-X, representatives from business, science and politics on an international level create a proposal for the next generation of data infrastructure: an open, transparent and secure digital ecosystem, where data and services can be made available, collated and shared in an environment of trust.</br> Gaia-X is a project initiated by Europe for Europe and beyond. Representatives from business, politics, and science from Europe and around the globe are working together, hand in hand, to create a federated and secure data infrastructure. Companies and citizens will collate and share data – in such a way that they keep control over them. They should decide what happens to their data, where it is stored, and always retain data sovereignty.</br> The architecture of Gaia-X is based on the principle of decentralization. Gaia-X is the result of a multitude of individual platforms that all follow a common standard – the Gaia-X standard. Together, we are developing a data infrastructure based on the values of openness, transparency, and trust. So, what emerges is not a cloud, but a networked system that links many cloud services providers together.</br> </br> Scope </br> A Federated and Secure Data Infrastructure</br> Innovation through digital sovereignty – that’s the goal of Gaia-X. We achieve this by establishing an ecosystem in which data is made available, collated and shared in a trustworthy environment. The users always retain sovereignty over their data. So, what emerges is not a cloud, but a federated system that links many cloud services providers and users together.</br> Gaia-X promotes federations, a new model of cloud data exchange that is orthogonal to the existing dominant model of hyper-concentration of data. Data are acquired in all sectors across the globe. They shall no more be concentrated in single places. The new way of computing is a continuum from the edge, i.e., from devices and data sources in the field directly to the cloud. This minimizes the need for data bandwidth, bringing the computing processes to the data and adapting to the phenomenon of data-gravity.</br> Through Gaia-X federations and federated services, several data owners can exchange data amongst each other minimizing data transfers and leveraging services for data that are guaranteed in terms of identity, description, service characteristic, service controllability and, more in general, can be trusted.</br> Through Gaia-X federations, several technology providers can create and offer a network of services with common identity, common self-description, common controllability, and interoperability across their nodes. This creates the necessary trust, the quality of services and the critical mass necessary to create value out of data and to deal with data-gravity and data distribution.</br> Through a federated model, Gaia-X providers offer a value that is not possible to obtain from highly centralized, proprietary, closed, non-federated and non-interoperable technologies that currently dominate the market and, as a matter of fact, do not provide for the level of trust requested by users.</br> </br> Domains </br> Federation Services </br> Standards </br> Data Spaces </br> Services </br> Partners </br> Huge list, available at the GAIA-X Websitethe GAIA-X Website +
- Swagger is een open-source raamwerk dat toelaat om RESTful APIs te bouwen, documenteren en consumeren [1] ↑ https://en.wikipedia.org/wiki/Swagger_(software) +
- SynchroniCity is een van de vijf grootscha … SynchroniCity is een van de vijf grootschalige proefprojecten (LSP) onder de vlag van het Horizon 2020 programma van de Europese Commissie.</br> Het belangrijkste doel van SynchroniCity is het bereiken van:</br> </br> een markt voor op IoT gebaseerde stedelijke diensten voor Europa en daarbuiten; </br> een robuust, op Standaarden gebaseerd model voor innovatie en inkoop van op IoT gebaseerde diensten op verschillende gebieden. </br> Hiervoor is een consortium opgericht bestaande uit acht deelnemende steden (Antwerpen, Carouge, Helsinki, Manchester, Milaan, Porto, Santander en Eindhoven), kennisinstellingen en bedrijven. In totaal maken 34 partners uit 11 landen deel uit van SynchroniCity. Het project eindigde eind 2019 na een looptijd van 36 maanden.</br> Gedetailleerde informatie over het project is te vinden op de SynchoniCity website SynchroniCity .</br> SynchroniCity richt zich op twee hoofdonderwerpen</br> </br> demonstreren van IoT- en AI-ondersteunde diensten om het leven van burgers te verbeteren en om lokale economieën te laten groeien; </br> Wat is de minimale gemeenschappelijke technische basis die nodig is in een wereldwijde markt voor IoT-ondersteunde diensten voor steden en gemeenschappen? </br> SynchroniCity Technologie </br> SynchroniCity is gebouwd rond een eenvoudig idee: wat is de minimale gemeenschappelijke technische basis die nodig is in een wereldwijde markt voor IoT-compatibele services voor steden en gemeenschappen?</br>Het is gebaseerd op bestaand werk van andere projecten:</br> </br> ITU-T FG-SCC [1] , </br> ITU-T Y.2060 [2] , </br> ISO / IEC JTC 1 [3] , </br> oneM2M [4] , </br> BIG-IoT [5] , </br> OrganiCity [6] , </br> Espresso [7] , </br> FIWARE , </br> AIOTI , </br> EIP-SCC [8] </br> Referentiearchitectuur </br> De Synchronicity referentiearchitectuur is gebaseerd op de volgende concepten, zoals gespecificeerd in [1] en schema.</br> </br> </br> Contextgegevensbeheer: het beheert de context informatie afkomstig van IoT-apparaten en andere openbare en privégegevensbronnen, en biedt contexttoegang via een uniforme interface. Contextinformatie bevat statusinformatie over real-world entiteiten die op een gestructureerde manier zijn gedefinieerd. CDM biedt functionaliteiten om toegang tot verschillende gegevensbronnen mogelijk te maken en context informatie te analyseren, b.v. voor het detecteren van gebeurtenissen. </br> IoT Management is de module die verantwoordelijk is om via specifieke IoT Agents te communiceren met de apparaten die verschillende Standaarden of protocollen gebruiken, waardoor ze compatibel en beschikbaar zijn voor het SynchroniCity-framework; </br> Data Storage Management biedt functionaliteiten met betrekking tot dataopslag en toegang in de specifieke context van IoT-systemen en smart city-platform, in interactie met heterogene bronnen. </br> IoT Data Marketplace ondersteunt zakelijke interacties tussen dataleveranciers die deel uitmaken van het SynchroniCity-ecosysteem en consumenten. Het implementeert een hub om digitale gegevensuitwisseling voor stedelijke gegevens en IoT-mogelijkheden mogelijk te maken, met functies voor het beheren van activa, bestellingen en inkomstenbeheer. Deze functies ondersteunen het creëren van innovatieve bedrijfsmodellen. </br> Beveiliging, privacy en bestuur: deze module behandelt alle beveiligingsaspecten die verband houden met drie hoofdpijlers: gegevens, IoT-infrastructuur en de platformdiensten, die de toepassingen en diensten van de steden ondersteunen. Rond deze pijlers bieden beveiligingsfunctionaliteiten cruciale beveiligingseigenschappen zoals vertrouwelijkheid, authenticatie, autorisatie, integriteit, niet-afwijzing, toegangscontrole, enz. </br> Monitoring en platformbeheerservices: het biedt functionaliteiten om de platformconfiguratie te beheren en de activiteiten van de platformdiensten te monitoren. Het ondersteunt specifieke KPI-definitie om de status van het platform te evalueren in relatie tot verschillende aspecten (bijv. Prestaties, gebruik, betrouwbaarheid, servicekwaliteit enz.) </br> Referentie API </br> Om de interoperabiliteit te garanderen, is de SynchroniCity API gebaseerd op een HTTP RESTful-benadering en veelgebruikte Standaarden . De implementatie van de SynchroniCity API is een basisvereiste voor de Reference Zones die compatibel met SynchroniCity willen zijn. De basisconcepten van deze API zijn:</br> </br> Context Management API de manier om te communiceren met de Context Management module om de context entiteiten te beheren. De API is gebaseerd op NGSIv2 </br> Data Storage API geeft toegang tot historische data en Open Data. De definitie van deze API is geïnspireerd op de NGSI-LD Temporal Query-taal </br> IoT data marketplace API maakt het mogelijk inkomsten te genereren met digitale activa gedurende de hele levensduur van de dienst. Het is een uitbreiding van het Business API-ecosysteem </br> Security API biedt autorisatiefuncties voor toegang tot de SynchroniCity-services. De API is gebaseerd op het OAUTH2 protocol </br> Gedetailleerde specificatie in sectie 4 van [2] </br> </br> Antwerpen </br> Als lid van het SynchroniCity programma heeft Antwerpen ook hieraan bijgedragen. Het heeft met name de volgende problemen aangepakt:</br> </br> Mobiliteit: hoe kan tegen 2030 een modal split van 50/50 in de regio Antwerpen tot stand worden gebracht. De stad Antwerpen zoekt naar oplossingen die helpen om:</br> een modale verschuiving van auto's of vrachtwagens naar duurzamere en minder congestiegevoelige modi. </br> een tijdsverschuiving voor reizen en transporten. </br> een mentale verschuiving over de behoefte aan mobiliteit Zowel fiets- als multimodale reizen zouden kunnen helpen om een modale verschuiving met forenzen en logistieke bedrijven te bewerkstelligen, terwijl ze een zeer positief effect hebben op de luchtkwaliteit en het geluidsniveau. </br> Energie en materialen / milieubeheer: de stad Antwerpen wil een voorbeeldige ‘ecocity’ zijn en wil in 2050 klimaatneutraal zijn. De stad Antwerpen zoekt naar oplossingen die helpen om te komen tot: </br> Klimaatverandering / CO2-neutraliteit tegen 2050.</br> Klimaatadaptatie. </br> Milieukwaliteit (luchtkwaliteit / geluidshinder). </br> Circulaire economie. </br> Afvalbeheer </br> Als onderdeel van het programma heeft de stad Antwerpen ontwikkeld:</br> </br> de slimme wegen naar Antwerpen om mobiliteit met de stad te ondersteunen https://www.slimnaarantwerpen.be/en/home </br> het Antwerp City Platform as a Service (ACPaaS) https://antwerpen.digipolis.be/nl/blog/12323b66-039e-4e87-86e4-8593ead99a6e </br> Het heeft samen met de steden Kopenhagen en Helsinki bijgedragen aan het grootschalige Internet of Everything Lab. </br> More information can be found here </br> </br> </br> </br> ↑ https://www.itu.int/en/ITU-T/focusgroups/ssc/Pages/default.aspx </br> </br> ↑ https://www.itu.int/rec/T-REC-Y.2060-201206-I </br> </br> ↑ https://en.wikipedia.org/wiki/ISO/IEC_JTC_1 </br> </br> ↑ https://en.wikipedia.org/wiki/OneM2M </br> </br> ↑ http://big-iot.eu/ </br> </br> ↑ https://organicity.eu/ </br> </br> ↑ https://espresso.espresso-project.eu/project-2/ </br> </br> ↑ https://www.polisnetwork.eu/project/eip-scc/ +
- Syntax {{#widget: Button link |class= |id= |href= |title= |buttontext= |target= |style= |datatarget= |datatoggle= |datadismiss= }} Example click here +
- Syntax {{#widget: Link |type=a, li, butt … Syntax </br> {{#widget: Link</br>|type=a, li, button, img</br>|typeattribute=</br>|id=</br>|class=</br>|style=</br>|href=</br>|src=</br>|datasrc=</br>|title=</br>|ariacontrols=</br>|text=</br>|target=</br>|role=</br>|height=</br>|width=</br>|for=</br>|datatoggle=</br>|datatarget=</br>|dataplacement=</br>|dataslide=</br>|datadismiss=</br>|hrefsurround=Used for images that should be surrounded by an ''a'' link</br>|targetsurround=</br>}}</br> </br> example </br> edit this page </br> </br> does not work </br> Tooltip on lefts page does not work Tooltip on left +
- Syntax van een taal (ook een programmeerta … Syntax van een taal (ook een programmeertaal of een markeertaal) is de verzameling regels due de combinaties van symbolen definieren on correcte gestructureerde uitdrukkingen op te stellen.</br>Het gaat hierbij over de vorm van de taal, niet over de betekenis.</br> Meer uitleg is te vinden op https://en.wikipedia.org/wiki/Syntax_(programming_languages)ia.org/wiki/Syntax_(programming_languages) +
- TODO De SWE Service Model Implementation … TODO</br> De SWE Service Model Implementation Standard definieert momenteel acht pakketten met gegevenstypes voor gemeenschappelijk gebruik in OGC-sensorwebenotivatiediensten (SWE). Vijf van deze pakketten definiëren de operationele vraag- en antwoordtypen. De pakketten zijn: </br> </br> Inhoud - Definieert gegevenstypen die kunnen worden gebruikt in specifieke diensten die (toegang tot) sensoren bieden; </br> Melding - Definieert de gegevenstypen die de verstrekking van metagegevens over de meldingsmogelijkheden van een dienst en de definitie en codering van SWES-gebeurtenissen ondersteunen; </br> Gemeenschappelijk - Definieert gegevenstypen die gemeenschappelijk zijn voor andere pakketten; </br> Gemeenschappelijke codes - Definieert gemeenschappelijk gebruikte lijsten van codes met speciale semantiek; </br> BeschrijfSensor - Definieert de vraag- en antwoordtypen van een bewerking die worden gebruikt om metagegevens over een bepaalde sensor op te vragen; </br> UpdateSensorDescription (beschrijving van de sensor) - Definieert de vraag- en antwoordtypen van een handeling die worden gebruikt om de beschrijving van een bepaalde sensor te wijzigen; </br> InsertSensor - Definieert de vraag- en antwoordtypen van een handeling die worden gebruikt om een nieuwe sensorinstantie in een dienst in te voegen; </br> DeleteSensor - Definieert de vraag- en antwoordtypen van een handeling die worden gebruikt om een sensor uit een dienst te verwijderen. </br> Deze pakketten maken gebruik van datatypes die in andere Standaarden zijn gespecificeerd. Deze datatypen worden in deze norm norm normatief gerefereerd, in plaats van dat ze in deze norm worden herhaald.</br> [[Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]][Open Geospatial Consortium (OGC) | Overzicht van OGC Standaarden ›]] +
- Taxonomieën bieden machine-geordende repre … Taxonomieën bieden machine-geordende representaties in een formele structuur. Ze worden vaak gebruikt om de ontwikkeling van modellen voor machine learning te sturen, bijvoorbeeld door een reeks labels te verstrekken waarvoor geclassificeerd moet worden.</br> Een taxonomie vertegenwoordigt de formele structuur van klassen of soorten objecten binnen een domein. Taxonomieën: </br> </br> volgen een hiërarchische indeling en geven namen voor elk object in relatie tot andere objecten. </br> kunnen ook de lidmaatschapseigenschappen van elk object in relatie tot andere objecten vastleggen. </br> hebben specifieke regels die gebruikt worden om elk object in een domein te classificeren of te categoriseren. Deze regels moeten volledig, consistent en ondubbelzinnig zijn. </br> moeten streng zijn in de specificatie, zodat elk nieuw ontdekt object in één en slechts één categorie of object past </br> erven alle eigenschappen van de klasse erboven, maar kunnen ook extra eigenschappen hebben. </br> </br>Meer informatie over de term taxonomie kan hier gevonden worden. +
- Technologie werkgroep Deze thematische w … Technologie werkgroep </br> Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix .</br> De derde thematische werkgroep vond plaats op 25 juni 2024.</br> </br> Context </br> Initiatief </br> In samenwerking met Mobiliteit en Parkeren Antwerpen en de Stad Antwerpen werkt VLOCA (Vlaamse Open City Architectuur) samen met OSLO (Open Standaarden voor Linkende Organisaties) aan een City of Things project genaamd "Citerra". Citerra staat voor 'City Environmental Regulations and Rights for Access' voor steden, gemeenten, bedrijven, burgers, verenigingen en overheden , en heeft als doel de link te leggen tussen de genoemde stakeholders en de lokale regelgeving.</br> Het doel van Citerra is om alle regelgevingen te centraliseren en te uniformeren, waarbij de aanvragen voor vergunningen kunnen worden ingediend. De focus van dit City of Things traject ligt op vergunningen voor autoluwe zones of gebieden met cameratoezicht. Hoewel de Stad Antwerpen het project leidt, is het de bedoeling om dit initiatief breder te zien richting alle lokale besturen.</br> Op dit moment is de informatie over verschillende gereglementeerde zones in de stad niet goed georganiseerd, wat het voor burgers en bedrijven moeilijk maakt om te begrijpen welke regels waar van toepassing zijn. Het handmatig invullen van persoonlijke gegevens bij herhaalde aanvragen leidt ook tot frustratie. Om dit te verbeteren, streeft het project ernaar gebruikers zelf hun profiel te laten beheren, inclusief het toevoegen van extra nummerplaten, en om gegevens automatisch in te vullen bij nieuwe aanvragen. Bovendien voldoet het project aan de Europese Commissie Directive over "Intelligent Transport Systems" door steden te verplichten Urban Vehicle Access Rights (UVAR) data naar het Europese Platform te uploaden, wat geautomatiseerd zal verlopen.</br> </br> VLOCA </br> 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.</br> </br> VLOCA-model </br> De start van elk VLOCA-traject begint bij een VLOCA-model:</br> </br> </br></br> </br> ID</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC1</br> </br> UC1: Registratie</br> </br> Registratie</br> </br> </br> UC2</br> </br> UC2: Informatieplatform</br> </br> informatie platform en zoek opdrachten</br> </br> </br> UC3</br> </br> UC3: Profiel & Formulier aanvullen</br> </br> Profiel aan- en formulier invullen</br> </br> </br> UC4</br> </br> UC4: Indiening</br> </br> Indienen aanvraag</br> </br> </br> UC5</br> </br> UC5: Opvolging dossier</br> </br> opvolging dossier</br> </br> </br> UC6</br> </br> UC6: toekenningsproces</br> </br> toekenning, weigering, betwisting, advies aanvraag</br> </br> </br> UC7</br> </br> UC7: dossierbeheer</br> </br> beheer dossier (overzicht, toevoegingen, verlengingen, aanpassingen, herinneringen, …)</br> </br> </br> UC8</br> </br> UC8: Message Center</br> </br> CRM voor communicatie (uitgaande/inkomende, contact strategie en historiek)</br> </br> </br> UC9</br> </br> UC9: Helpdesk</br> </br> helpdesk & FAQ & Reviews</br> </br> </br> UC10</br> </br> UC10: betaalmodule</br> </br> betaalmodule en business model vinden en bouwen</br> </br> </br> UC11</br> </br> UC11: Monitoring</br> </br> Monitoring en analytische rapportering incl fraudedetectie</br> </br> </br> UC12</br> </br> UC12: Inzichten</br> </br> Rapporting BI Dashboards en Inzichten</br> </br> </br> UC13</br> </br> UC13: Duurzaamheid</br> </br> Van een piloot tot een 'operationeel' draaiende applicatie en platform</br> </br> Tijdens de eerste werkgroep bespraken we de onderstaande figuur die het proces weergeeft van het aanvraagformulier: </br> </br> </br> </br>Bij de tweede werkgroep stonden we stil bij het informatieplatform: </br> </br> </br> Vandaag </br> </br> Brainstormsessie </br> Het doel en de aanpak van de brainstormsessie worden hieronder beschreven. Tevens wordt de uitkomst van de brainstorm hierin samengevat.</br> </br> Doel </br> Het doel van de brainstormsessie is het volgende</br> Zicht krijgen op hoe het overkoepelde platform </br> - het toekenningsproces kan verbeteren</br> - de communicatie kan verbeteren voor alle partijen</br> Identificatie van de valkuilen</br> </br> </br> Oefening 1: Hoe kan het overkoepelde platform het toekenningsproces verbeteren? </br> Instructies </br> Bij deze oefeningen stonden we stil bij de volgende vragen:</br> </br> Hoe kan de gebruikerservaring van de toekenningsproces verbeterd worden voor zowel de ambtenaar en burger? </br> Wat heb je hiervoor nodig? </br> Welke stappen in het toekenningsproces kunnen geautomatiseerd worden? </br> Welke stappen zijn essentieel? </br> Voorbeeld:</br> -Je aanvraag is niet volledig correct ingevuld en kan nog niet verwerkt worden</br> -Verhuis van bedrijf naar andere stad, vergunning komt niet automatisch mee.</br> -Aanvraag is toegekend, hierna ontvang je je vergunning</br> </br> Output </br> Discussie </br> </br> Oefening 2: Hoe kan het overkoepelende platform de communicatie verbeteren voor alle partijen? </br> Instructies </br> Hoe kan de gebruikservaring verbeterd worden via communicatie? Hoe kan het systeem aangepast worden aan de verschillen communicatiebehoeftes van de gebruiker. Wat is belangrijk voor operationele communicatie, marketing communicatie.</br> Voorbeeld: </br> -Je brengt de wetgeving van de verschillende lokale besturen samen </br> </br> Output </br> Discussie </br> </br> Oefening 3: identificatie valkuilen </br> Instructies </br> Hoe gaan we om met de verschuiving van aanvragen die rechtstreeks verlopen via de website van de lokale besturen naar een overkoepelend medium? Wat zijn mogelijke valkuilen?</br> Voorbeeld:</br> - Integratie van verschillende systemen en databronnen kan technisch uitdagend zijn</br> - Financiering verdeling over de verschillende lokale besturen</br> </br> Output </br> Discussie </br> </br> Opname en Miro bord </br> Miro bord </br> Het Miro bord kan je consulteren via deze link . </br> </br> Opname </br>De opname van deze sessie is te bekijken via deze link . </br> Volgende stappen </br> Wat na deze werkgroep?</br> </br> Verwerking van de input van de brainstorm oefening. </br> Verder onderzoek en voorbereiding van de volgende thematische werkgroep. </br> Publicatie op de Kennishub </br>Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be Andere werkgroepen </br> Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-02-27 13u-16u VAC Antwerpen Thematische werkgroep 1 Data en informatie werkgroep 2024-03-28 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-05-16 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-06-25 13u-16u Teams024-06-25 13u-16u Teams +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. </br> De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen.</br> De Technologie werkgroep vond plaats op 07 december 2023.</br> </br> Deelnemers </br> </br></br> </br> Organisatie</br> </br> Deelnemer</br> </br> </br> Agentschap Binnenlands Bestuur (VLOCA)</br> </br> Steven Degelaen</br> </br> </br> Alain Glickman</br> </br> </br> Stad Mechelen</br> </br> Sandrine Raskin</br> </br> </br> The Retail Factory</br> </br> Luc Van Rompaey</br> </br> </br> Stad Leuven</br> </br> Bo Peeters</br> </br> </br> Proximus</br> </br> Jasper Botterman</br> </br> </br> Joshua Moerman</br> </br> </br> Gerdy Seynaeve</br> </br> </br> POM West-Vlaanderen</br> </br> Frederik Sack</br> </br> </br> Economisch Huis Oostende</br> </br> Joke Van Gheluwe</br> </br> </br> Bjorn Pintelon</br> </br> </br> ViNotion</br> </br> Egbert Jaspers</br> </br> </br> Kernpunt</br> </br> Liederik Cordonni</br> </br> </br> Justine Vanneste</br> </br> </br> Thomas Moore</br> </br> Marijke Brants</br> </br> </br> Crowdscan</br> </br> Ben Bellekens</br> </br> </br> </br> 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.</br> 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.</br> 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.</br> Daarnaast streven deze projecten ernaar om een duurzame samenwerking op te zetten waarbij alle betrokken partijen meerwaarde ervaren.</br> 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:</br> </br> Momentum rond retail data behouden na afloop lopende projecten </br> Kapitaliseren opgebouwde kennis & beperkte datamaturiteit bij handelaars en steden verder opbouwen </br> Beperkte scope en doorlooptijd subsidieprojecten 🡪 scope verbreden </br> Afhankelijkheid van de leveranciers beperken 🡪 datadeling & standaardisering (OSLO & VLOCA) </br> Wildgroei aan platformen 🡪 generiek overkoepelende oplossing: standaardisatie & deelbaarheid maximaal hergebruik en interoperabiliteit </br> Draagvlak handelaars vergroten 🡪 bevragen, leerlessen valideren en coachen </br> Opmaak business- & governance model </br>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.</br> Samenvatting vorige werkgroep </br> Het verslag van de business werkgroep kan je hier terugvinden. </br> </br> Doel van huidige werkgroep </br> Introductie geven over het project </br> Toelichting geven over VLOCA </br> Brainstormen over principes mbt technologie </br> Brainstormsessie </br> Aanpak </br> Om te beginnen gaan we kijken of we nog aanvullingen kunnen doen bij de valkuilen die we tijdens de vorige werkgroep geïdentificeerd hebben. </br> Vervolgens gaan we op basis van elke valkuil een principe formuleren en dit telkens met een verschillende bouwsteen in het achterhoofd: leveranciers, databronnen, data opslag, data integratie, data hub en BI omgeving. </br> Uitkomst </br> De input van de deelnemers werd gecapteerd in dit Miro bord .</br> </br> Oefening 1: identificatie valkuilen </br> </br></br> </br> Valkuilen</br> </br> </br> Te brede scope - must have vs nice to have</br> </br> </br> Financiële impact op budget</br> </br> </br> Geen targets definiëren</br> </br> </br> Andere prioriteiten</br> </br> </br> Dataverhaal is soms 'on top' en niet ingebed</br> </br> </br> Business model</br> </br> </br> Verantwoordelijkheid (gedeelde verantwoordelijk, wie is eindverantwoordelijk voor platform, enz.)</br> </br> </br> Negeren van bestaande Vlaamse Bouwstenen (en data)</br> </br> Oefening 2: aanvullen van schema </br> </br></br> </br> </br> </br> Geïdentificeerde valkuil</br> </br> Situatieschets valkuil</br> </br> Potentiële oplossing</br> </br> Vorm een principe</br> </br> </br> Leveranciers</br> </br> Plots faillissement</br> </br> Datalevering valt stil</br> </br> Plan B: andere leverancier</br> </br> Goed beheer van calamiteiten</br> </br> </br> </br> </br> </br> </br> Solvabiliteitscheck elk jaar</br> </br> Continuiteitsgaranties van leveranciers => Open data structuur</br> </br> </br> Security lek</br> </br> Securitylek bij leverancier</br> </br> Aanlevering van security rapporten door leveranciers</br> </br> Security labels voor leveranciers</br> </br> </br> Afhankelijkheid van leveranciers</br> </br> inhoud en beschikbaarheid van databron hangt teveel af van leverancier</br> </br> standaardisatie van de databron en nauwere samenwerking met leveranciers omtrent gebruik</br> </br> data standaarden en samenwerkingsmodel</br> </br> </br> Continuiteit van de data afhankelijk van de leverancier</br> </br> Leveranciers kunnen niet 1 op 1 dezelfde data voorzien - dus bij wijziging van leverancier gaat de continuiteit van je data verloren. Vb. Proximus telecomdata vs Telenetdata Vb. passantentellingdata - net niet dezelfde technologie of meetgebied</br> </br> Samenwerking leveranciers?</br> </br> Breng micro en macro data samen</br> </br> </br> Geen proactieve communicatie over fouten of uitvallen van sensoren</br> </br> </br> </br> </br> </br> </br> </br> </br> Kleine lokale besturen vinden dit te complex</br> </br> Kleine lokale besturen vinden dit te complex</br> </br> Leveranciers kunnen bruikbare informatie aanbieden (niet enkel ruwe data)</br> </br> Kant en klare dashboards</br> </br> </br> </br> </br> </br> </br> Leveranciers bieden opleidingen</br> </br> </br> </br> </br> Weinig informatie over verwerking, marktaandeel en extarpolatie</br> </br> Data moeilijk te interpreteren en naar waarde te schatten</br> </br> Standaard voorwaarden over transparantie</br> </br> </br> </br> </br> te weinig datadocumentatie aangeleverd</br> </br> </br> </br> </br> </br> </br> </br> </br> Databronnen</br> </br> Kostprijs</br> </br> Te grote kost tov budget</br> </br> zoveel mogelijk standardisatie (bij de steden dezelfde vraag formuleren om de kosten van ontwikkeling te drukken)</br> </br> Betaalbaar houden ook voor kleinere spelers door standaardoplossing 1x te ontwikkelen en te dupliceren</br> </br> </br> Kleine lokale besturen kunnen zich bepaalde data niet veroorloven</br> </br> Bepaalde data zijn op LT niet haalbaar / betaalbaar / relevant voor kleine steden en gemeenten.</br> </br> schaalvoordelen zoeken om prijs te drukken</br> </br> </br> </br> </br> </br> </br> </br> </br> keuzes bij lokale besturen op basis van neutrale en correcte info/advies</br> </br> </br> </br> </br> Niet genoeg gedacht over toekomstige noden en technologiën</br> </br> Platform & content evolueren te traag</br> </br> Innovatie & ProofOfConcepts track definieren</br> </br> Continue evolutie van de mogelijkheden aan de hand van een continue (test) stroom van nieuwe toepassingen</br> </br> </br> verschillende bronnen spreken elkaar tegen</br> </br> neutrale analyse en duiding van databronnen</br> </br> </br> </br> </br> </br> </br> </br> </br> neutraal of onafhankelijk ?</br> </br> </br> </br> </br> </br> </br> </br> </br> neutraliteit moet gedefinieerd worden</br> </br> </br> </br> </br> </br> </br> </br> </br> Model met duidelijke standaarden en richtlijnen</br> </br> </br> </br> </br> </br> </br> Te veel data - bomen door het bos niet meer zien</br> </br> Ontbreken van standaardisering op vlak van data</br> </br> samenwerking en uitwisseling tussen lokale besturen + opteren voor dezelfde databronnen door gelijkaardige besturen om benchmark mogelijk te maken</br> </br> belang van co-creation en standaardisatie</br> </br> </br> bestuurlijke dekking niet verkrijgen of tegenstand burger (om sensoren te plaatsen)</br> </br> Data kan niet verkregen worden</br> </br> Duidelijke communicatie (ook van de resultaten)</br> </br> Verhogen van de betrokkenheid bij burger door betere communcatie & betrekken van burger</br> </br> </br> Cijfers naar je hand zetten</br> </br> Bias wordt geïntroduceerd in databron op basis van noden</br> </br> gezamenlijk validatie-traject bij opstart van nieuwe databron -> met generieke standaard als resultaat</br> </br> belang van co-creation en standaardisatie</br> </br> </br> Verandering in de datadefinitie</br> </br> plotse verandering in cijfers</br> </br> duidelijke definities + adhankelijkheden & mogelijke impact</br> </br> continuiteit van data verbeteren door proactief externe afhankelijkheden te kennen</br> </br> </br> Duurzaamheid van databron op de LT</br> </br> Data is niet langer beschikbaar, toegankelijk of betaalbaar</br> </br> alternatieve bronnen indien mogelijk</br> </br> </br> </br> </br> </br> </br> </br> </br> LT overeenkomsten met garanties</br> </br> </br> </br> </br> Te weinig gebruik maken van beschikbare open bronnen en eigen bronnen reeds beschikbaar</br> </br> </br> </br> </br> </br> </br> </br> </br> Lokale besturen gebruiken reeds andere Cloudsolutions</br> </br> Cloudsystemen leven naast elkaar en brengen hierdoor geen toegevoegde waarde.</br> </br> Directe koppeling tussen de verschillende cloud systemen</br> </br> Centraal platform waarop verschillende clouddiensten kunnen aansluiten en communiceren</br> </br> </br> Bij anomaliën geen plan B (data issues, offline,...)</br> </br> wanneer een databron afwijkende cijfes produceert dan is er niets om op terug te vallen</br> </br> anomalien detectie : tijdseries</br> </br> </br> </br> </br> </br> </br> </br> </br> een databron zou indien mogelijk reële cijfers en geschatte cijfers kunnen bevatten om op terug te vallen (interpolatie / predicite)</br> </br> extra robustheid inbouwen door statistische modelering</br> </br> </br> </br> </br> afwijken van de standaardisatie</br> </br> </br> </br> </br> </br> </br> Dataopslag</br> </br> Kostprijs</br> </br> geen kostendeling tss deelnemers</br> </br> 1 gedeelde infrastructuur met verschillende toegangen</br> </br> kost beheersbaar houden door kosten voor infastructuur te delen</br> </br> </br> Data opslag en integratie gebeurt vaak manueel</br> </br> </br> </br> </br> </br> </br> </br> </br> Data integratie</br> </br> Andere notievormen tussen leveranciers (bv. date)</br> </br> Meer tijd nodig voor preprocessing</br> </br> Standaardnotitie voor vaak voorkomende variabelen</br> </br> Interoperabiliteit</br> </br> </br> Datacultuur</br> </br> veel lokale besturen hebben weinig tot geen ervaring / geloof in data</br> </br> Delen van laagdrempelige goede praktijken en voordelen</br> </br> </br> </br> </br> </br> </br> </br> </br> durven / kunnen / mogen pionieren</br> </br> </br> </br> </br> </br> </br> </br> </br> domeinoverschrijdende meerwaarde aantonen</br> </br> </br> </br> </br> Kleine lokale besturen vinden dit te complex</br> </br> </br> </br> </br> </br> </br> </br> </br> Data delen tussen publieke en private actoren</br> </br> open data stimuleren en ontsluiten</br> </br> </br> </br> </br> </br> </br> Integratie van realtime databronnen (bv van sensoren)</br> </br> Architectuur moet ook device management, realtime stromen ondersteunen</br> </br> Aandacht voor realtime flows vs statische of 'slow moving' databronnen</br> </br> Integratie van lange termijn inzichten met korte/realtime inzichten</br> </br> </br> Data hub</br> </br> Andere projecten geraken niet gemakkelijk op ons platform</br> </br> Data wordt niet voldoende gebruikt (monetisatie)</br> </br> Publiceren op een data catalogus met documentatie van hoe, wat en wanneer</br> </br> Schaalbaar door goede documentatie</br> </br> </br> Complexiteit</br> </br> Onduidelijkheid van content van databronnen</br> </br> Uniform datamodel met bijhorende uitleg / training / documentatie</br> </br> </br> </br> </br> </br> </br> </br> </br> Documentatie van praktische use cases bij andere 'klanten'</br> </br> Betere inzichten over wat bestaat en hoe het in de praktijk gebruikt kan worden</br> </br> </br> onvoldoende kennis van ontwikkelde architecturen en gestandaardiseerde ontologieën (SSN/SOSA, OSLO)</br> </br> meerwaarde en het gebruik is onduidelijk voor afnemers - wie gebruikt het nu? waarom zou ik de eerste zijn ?</br> </br> Opleidingen van data architecturen meer in de kijker zetten zowel vanuit commercieel als technisch standpunt</br> </br> Gencentraliseerde onboarding door Digitaal vlaanderen veel meer benutten binnen de verschillende trajecten OSLO.</br> </br> </br> BI omgeving</br> </br> Lokale besturen gebruiken reeds andere BI hardware</br> </br> </br> </br> </br> </br> </br> </br> </br> Geen voldoende input van thematische experten</br> </br> foute analyses, verkeerde interpretatie van anomalien,…</br> </br> alle stakeholders betrekken vanaf de beginfase (voor de selectie van bronnen,...)</br> </br> overkoepelend projectmanagement om vooraf alle stakeholders in kaart te brengen en op de nodige tijdstippen doorheen het proces te betrekken</br> </br> </br> </br> </br> </br> </br> user testing in iedere fase om te zien of de datakwaliteit voldoet aan de vraag/nood</br> </br> </br> Geen duiding/begeleiding bij gebruik dashboard</br> </br> verkeerde interpreatatie</br> </br> training & documentatie</br> </br> vermijden van foute interpretaties door opleiding & documentatie te voorzien door specialiste van de databron</br> </br> </br> verkeerde data uitvraag (verkeerde sql query)</br> </br> </br> </br> </br> </br> </br> Verkeerde interpretatie van het beleid op data</br> </br> De gevisualiseerde data komt niet correct binnen bij de eindgebruiker</br> </br> Simpele en eenduidige visualisaties. Visualisaties afgestemd op doelpubliek. toegang tot de achterliggende definities . Een duidelijke handleiding</br> </br> </br> </br> </br> Datamaturiteit van het beleid, de gebruikers</br> </br> Geen of zeer beperkte ervaring met data</br> </br> Inhuren van expertise</br> </br> </br> </br> </br> </br> </br> </br> </br> Kant en klare dashboards die duidelijk zijn met lage instap</br> </br> </br> </br> </br> </br> </br> </br> </br> decentralisatie van experten in bvb de steden (center of excellence in bepaalde databronnen) expertise centrum opstellen per databron (kan ook in de verschillende steden zijn bvb)</br> </br> </br> </br> </br> </br> </br> </br> </br> Kant en klare rapporten</br> </br> </br> </br> </br> </br> </br> </br> </br> voorbeeldrapporten, alsook de 'correcte' noden en behoefte en verwachtingen</br> </br> </br> </br> </br> Dashboard niet voldoende afgestemd met lokale besturen</br> </br> Data is niet afgestemd op de 'use case'</br> </br> Initieel ontwikkelngstraject als co-creatie</br> </br> Betere inzicht aan de hand van databronnen door co-creatie van dashboards / inzichten. Leverancier + klant</br> </br> </br> publiek maken van data zonder een juiste kadering van de definities</br> </br> foute interpretaties van inhoud, misleidende informatie, fake data (=context en verhaal klopt niet meer door meervoudig gebruik door verschillende instanties)</br> </br> steeds een informatie pagina/sheet voorzien bij het publiek maken van data</br> </br> duidelijke verantwoordelijkheden voor een juiste data interpretatie</br> </br> </br> Te veel verschillendei interpretaties</br> </br> clausule opstellen die de verantwoordelijkheid van het kaderen van de data legt bij de instatie die ze publiceert</br> </br> </br> </br> </br> </br> </br> open data charter met duidelijke richtlijnen (met engagementen)</br> </br> </br> Lokale besturen gebruiken reeds andere BI software</br> </br> Verschillende dashboards moeten worden geraadpleegd</br> </br> Data openstellen via bv. API Integratie mogelijk maken in bestaande dashboard</br> </br> </br> </br> </br> </br> Vraag & antwoord en volgende stappen </br> Vragen </br> Opname </br> De opname van deze sessie is te bekijken via deze link . </br> </br> </br> </br> </br> Volgende werkgroepen </br>Alle thematische werkgroepen zijn afgerond. VLOCA gaat nu aan de slag met de verzamelde informatie om een generieke bedrijfsarchitectuur op te bouwen. Andere werkgroepen </br> 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 +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix .</br> De tweede thematische werkgroep vond plaats op 23 mei 2024.</br> </br> Context </br> Initiatief </br> VERA werkt samen met verschillende lokale besturen en de provincie Vlaams-Brabant om het probleem van modderstromen als gevolg van bodemerosie aan te pakken. Meer dan 100 gemeenten in Vlaanderen ondervinden bodemerosie, wat aanzienlijke schade kan veroorzaken aan zowel private eigendommen als publieke infrastructuur. Door klimaatverandering, trends in de landbouw en verharding zal dit probleem naar verwachting in de toekomst verder versterkt worden.</br>Op dit moment worden erosiepoelen gebruikt als oplossing. Deze poelen worden onderaan de helling aangelegd om modderstromen op te vangen en te voorkomen dat ze schade veroorzaken. Deze erosiepoelen zijn uitgerust met sensoren en overlopen, waardoor het water op een gecontroleerde en langzame manier kan wegstromen. De vraag die zich stelt, is of deze erosiepoelen effectief zijn. Er bestaat onzekerheid over hun capaciteit en functionaliteit, vooral in noodsituaties. Het is essentieel om dit op een kostenefficiënte manier te monitoren, met als doel zowel acute waarschuwingen bij rampen als proactieve oplossingen voor het probleem.</br>Er wordt nagedacht over het gebruik van peilmeters of debietsensoren om de erosiepoelen te monitoren. Hiermee kan worden bijgehouden hoeveel water door de overlopen gaat. Hoewel dit geen exacte voorspellingen oplevert, biedt het wel inzicht in de hoeveelheid neerslag.</br> Het overkoepelende doel van het project is om een gecentraliseerd dataplatform op te zetten en een raamcontract te ontwikkelen voor de sensoren. De verzamelde data kunnen gedeeld worden met rioolbeheerders, landbouwers en verzekeringsmaatschappijen, omdat deze informatie waardevol kan zijn voor alle betrokken partijen.</br> </br> VLOCA </br> 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.</br> </br> VLOCA-model </br> De start van elk VLOCA-traject begint bij een VLOCA-model:</br> </br> </br></br> </br> ID</br> </br> Samenvatting</br> </br> Beschrijving</br> </br> </br> UC1</br> </br> UC1: Sensoren</br> </br> Verschillende actoren willen verschillende types sensoren kunnen plaatsen en beheren (bv. onderhoudsplan).</br> </br> </br> UC2</br> </br> UC2: Data Captatie</br> </br> Ik wil als gebruiker alle informatie correct binnenkrijgen (context, data, goede transmissie)</br> </br> </br> UC3</br> </br> UC3: Dataplatform</br> </br> Ik wil als gebruiker een visualisatie zien van alle data zodat ik deze kan analyseren.Ik wil als gebruiker data kunnen toevoegen, aanpassen, delen en opslaan.</br> </br> </br> UC4</br> </br> UC4: Dashboarding</br> </br> Ik wil als gebruiker een dashboard kunnen hanteren met KPI's (bv kleurencodes) die ik zelf kan beheren in functie van de data.</br> </br> </br> UC5</br> </br> UC5: Message Center</br> </br> Ik wil als gebruiker via mijn tool contacten kunnen aanspreken, toevoegen, wijzigen en behandelen (messaging systeem).</br> </br> </br> UC6</br> </br> UC6: Predictie</br> </br> Op basis van de verworven data wil ik modellen kunnen gebruiken om predicties uit te voeren zodat er tactisch advies gegeven kan worden.</br> </br> </br> UC7</br> </br> UC7: Mitigatie</br> </br> Op basis van real time data en advies wil ik als lokaal bestuur kunnen reageren om de schade te minimaliseren (crisis management).</br> </br> </br> UC8</br> </br> UC8: Preventie</br> </br> Als lokaal bestuur wil ik een overzicht krijgen van adviezen, acties en aanbevelingen om modderstromen te vermijden.</br> </br> </br> UC9</br> </br> UC9: Advies</br> </br> Op basis van data van modderstromen wil ik dit kunnen analyseren, correlaties zien en advies verlenen.</br> </br> </br> UC10</br> </br> UC10: Marktplaats</br> </br> ik wil als gebruiker data en datasciencemodellen kunnen aanbieden en verkrijgen.</br> </br> </br> UC11</br> </br> UC11: ROI</br> </br> Business Modelling</br> </br> </br> UC12</br> </br> UC12: Helpdesk</br> </br> Helpdesk - FAQ - Reviews</br> </br> Tijdens deze werkgroep staan we stil bij use cases 2-5. </br> In de onderstaande figuur zie je een visuele voorstelling van dit VLOCA-model: </br> </br> </br> Brainstormsessie </br> Het doel en de aanpak van de brainstormsessie worden hieronder beschreven. Tevens wordt de uitkomst van de brainstorm hierin samengevat.</br> </br> Doel </br> Het doel van de brainstormsessie is het volgende:</br> </br> Zicht krijgen op de wensen mbt het dashboard </br> Zicht krijgen op de wensen mbt het message center </br> Inzicht krijgen in het data management </br> Valkuilen en principes identificeren </br> Nadenken over verduurzaming ifv de keuze voor een bepaalde databron </br> In de onderstaande figuur wordt het proces weergegeven dat zich afspeelt binnen het dataplatform: </br> </br> </br> Oefening 1 </br> Instructies </br> Bij deze oefeningen stonden we stil bij de volgende vragen: </br> Welke soort dashboards zijn interessant voor de verschillende doelgroepen? Welke parameters wil je kunnen monitoren? Hoe wil je dat je data gevisualiseerd wordt? Welke inzichten wil je krijgen? Wie heeft toegang tot het dashboard? Wie heeft welke rechten om wat te kunnen? </br> Voorbeeld: </br> -Als rampen coördinator wil ik toegang tot het regionaal dashboard</br> -Ik wil de waterstand van een bepaalde stroom kunnen zien</br> -Een rapport trekken over temperatuur</br> -Een visualisatie over luchtvochtigheid over een bepaalde periode</br> -Ik wil een melding zien wanneer een bepaalde waarde overschreden is</br> </br> Output </br> </br></br> </br> Parameters</br> </br> </br> Hoeveelheid (voorspelde) neerslag in grafiek</br> </br> </br> Check of alle sensoren nog werken</br> </br> </br> Werking sensoren/ status batterij/GPS...</br> </br> </br> Iets zoals bij waterinfo VMM : https://www.waterinfo.be/Themas#item=overstroming/actueel </br> </br> </br> Vullingsgraad van de poel (in kader van technisch onderhoud)</br> </br> </br> Zelfs over historische data moeten snelle queries mogelijk zijn</br> </br> </br> Performantie Queries</br> </br> </br> Alerts moeten op verschillende applicaties/devices mogelijk zijn en configureerbaar wie welke alerts krijgt. Elke stad kan zijn eigen configuratie hierin doen. Scheiding op tenant=stadsniveau? (je kunt niet in de data van een andere stad kunnen zien)</br> </br> </br> Scheidingslijnen : data governance => is dit relevant voor modderstromen ?</br> </br> </br> Rechtstreekse koppeling naar brondata met dashboardapplicaties zodat eigen dashboards met bijv. PowerBi makkelijk gemaakt kunnen worden en automatisch geupdated worden (read only). Dit wel met al de security vereisten: alleen eigen data kunnen zien, binnen een stad een hierarchie wie wat mag zien.</br> </br> </br> vaste dashboard, vs dynamische/self service dashboard, integratie in bestaande lokale dashboard</br> </br> </br> Stakeholder : Academici : Inzicht: vul- en ledigingscurves</br> </br> </br> Stakeholder : Academici : Inzicht: historische data</br> </br> </br> Stakeholder : Academici : Inzicht: makkelijk data kunnen downloaden voor verder onderzoek</br> </br> </br> Stakeholder : Academici : Maximale vulpeilen van buffers (of andere %) in grafiek</br> </br> </br> Rampcoördinatie: predictie van tijdstip van overlopen (+ aftelklok)</br> </br> </br> Rampcoördinatie: op kaart groen/geel/oranje/rood </br> </br> </br> Technische teams : Onderhoud: datum laatste onderhoud (poelen & sensoren)</br> </br> </br> Technische teams : Onderhoud: percentage van oorspronkelijke buffercapaciteit die er nog is</br> </br> </br> Technische teams : Onderhoud: bijhouden wie onderhoud heeft uitgevoerd</br> </br> </br> Lokale input interface van alle informatie bij het ruimen bvb. (feedback loop)</br> </br> </br> Landbouwers goed bij betrekken </br> </br> </br> Bodemvocht</br> </br> </br> Stakeholder</br> </br> </br> Jonge vs oudere generaties</br> </br> </br> Neerslag gegevens</br> </br> </br> Stakeholders: omwonenden goed bij betrekken</br> </br> </br> Als landbouwer toegang tot de volgende data: hoeveelheid grond die afgestroomd is, bodemvocht (via de sensoren), hoeveelheid neerslag die gevallen is, ... en dit allemaal overzichtelijk gepresenteerd in de tijd. Ook eventuele alerts (van het vollopen) gaan handig zijn voor hem</br> </br> </br> Overzicht van de statussen van de buffers op kaart (gekleurde puntjes bvb)</br> </br> </br> Mobiel toegankelijke website</br> </br> </br> Bedenking: mogelijkheid aansluiting met andere toepassingen (vb Sirio van sumaque of flood4cast van hyrdroportal) - deze tool moet niet allés zelf kunnen, focus op poelen</br> </br> </br> Data space ?</br> </br> </br> Dashboard dient te kunnen linken met datalake in de cloud, real time gevoed kunnen worden door IoT standaard technologie om metingen van de sensoren via fabrikant en globale protocollen tot in de omgeving te krijgen die het dashboard kan gebruiken, een service die OSLO compliant data publiceert van dezelfde bron is beter te gebruiken vanaf de service of de store. Dashboard dient geo selecties mogelijk te maken en kan native integreren met MS PowerBI, MS Excel en heeft open API. Parameters moeten niet beperkt zijn in type</br> </br> Discussie </br> Neerslagdata en Sensoren:</br> Een dashboard moet de hoeveelheid neerslag (verleden, heden, voorspellingen) tonen, met data van bijvoorbeeld het KMI. </br> Er moet een alarmsysteem zijn om te controleren of sensoren nog werken, inclusief batterijstatus en GPS-locatie. </br> Directe koppeling naar brondata is belangrijk, zodat de data eenvoudig te downloaden en te analyseren is, bijvoorbeeld via CSV-bestanden. </br> Operationeel Gebruik en Onderhoud:</br> Het dashboard moet operationele rapporten kunnen genereren om de werking van sensoren te bewaken. </br> Onderhoudsinformatie moet bijgehouden worden, inclusief de datum van het laatste onderhoud van zowel de sensoren als de poelen. </br> Er moet een onderscheid zijn tussen dashboards voor operationele inzichten, technisch onderhoud en rampenbestrijding. </br> Configuratie en Toegang:</br> Alerts moeten configureerbaar zijn per stad, zodat elke stad eigen instellingen kan beheren. </br> Er moet een duidelijke scheiding zijn tussen data van verschillende steden (multi-tenant omgeving). </br> Landbouwers moeten toegang krijgen tot relevante data (neerslag, bodemvocht, status van de buffers) en eventueel alerts voor overstroomrisico’s. </br> Gebruiksgemak en Toegankelijkheid:</br> Het dashboard moet mobiel toegankelijk zijn, zodat gebruikers ter plaatse snel informatie kunnen inzien. </br> Er moet rekening gehouden worden met de mogelijkheid om het dashboard te integreren met andere bestaande systemen en applicaties. </br> Predictiemodellen en Visualisatie:</br> Het systeem moet rampcoördinatie ondersteunen door voorspellingen te doen over wanneer buffers zullen overlopen en visueel alarmeren (groen, oranje, rood). </br> Het is belangrijk om visueel overzicht te hebben van de vul- en ledigingsfrequentie van de buffers, inclusief een aftelklok voor voorspelde overstromingen. </br> Data Governance en Technische Overwegingen:</br> Er moet een flexibele data-architectuur zijn waarin data uit verschillende bronnen real-time kan worden geïntegreerd en geanalyseerd. </br> De data moet Oslo-compliant worden gepubliceerd waar mogelijk, maar de ruwe data moet ook behouden blijven voor flexibiliteit en toekomstige integraties. </br> Samenwerking en Feedback:</br> Het systeem moet het mogelijk maken om feedback van technische teams direct in te voeren, zodat onderhoud en andere acties goed gedocumenteerd worden. </br> Academici en andere geïnteresseerden moeten ook toegang hebben tot de data voor verder onderzoek en inzicht. </br> Oefening 2 </br> Instructies </br> Wie wanneer contacteren? Welke type van communicatie gaan we hebben met de gebruikers en in welke scenario? Hoe verzamel je de contactpersonen? Hoe kan je een goede opvolging implementeren?</br> Voorbeeld: </br> ·Contact persoon x moet gecontacteerd worden in geval een erosiepoel is overstroomd om efficiënte en snelle ontruiming te voorzien?</br> </br> Output </br> </br></br> </br> Notificaties, communicatie en procesflow</br> </br> </br> Eerste melding: 75% vulling en neerslag voorspeld</br> </br> </br> Melding als poel overstort</br> </br> </br> Melding als poel aan schoonmaak toe is</br> </br> </br> Afhankelijk van voorspelde impact - voorbeeld poel in buurt van veel kritische infrastructuur </br> </br></br></br> </br> Een opt-in voor verschillende soorten meldingen (inschrijven wie wil)</br> </br> </br> GDPR</br> </br> </br> Status van afhandeling van alerts. Als er actie moet ondernomen worden, moet er kunnen aangeduid worden dat het ontvangen is en in verwerking door die persoon of dat team. Dus alerts leven ook op een desk waar status aanpassingen, comments en doorverwijzingen mogelijk zijn.</br> </br> </br> Burgemeester</br> </br> </br> Brandweer</br> </br> </br> De Lijn (als er bus passeert)</br> </br> </br> Omwonenden</br> </br> </br> Riool-beheerder</br> </br> </br> Valkuil: hoe spamming/te veel aan berichtjes vermijden.</br> </br> </br> bvb "be alert"</br> </br> </br> Proces ?</br> </br> </br> bvb "bin" (buurt informatie netwerken) via de politie</br> </br> </br> Ramp- coördinator</br> </br> </br> Technische dienst</br> </br> </br> Politie</br> </br> </br> Provincie</br> </br> </br> Ploeg van wacht als eerste contact bvb ?</br> </br> </br> Zou hiervoor standaard technologie gebruiken zodat je ontwikkeling en onderhoud minimaliseert. Je hoeft dan enkel configuratie te doen en je kan zowel emails, SMS, ... sturen als ook pompen aansturen of andere acties automatiseren. Bijvoorbeeld GeoEvent Server </br> </br> </br> Alert voor stroomafwaarts liggende buurtbewoners indien kans op overlopen poel (en indien relevant natuurlijk)</br> </br> </br> Koppeling met BE-Alert</br> </br> </br> Afhankelijk van urgentie een ander kanaal. Niets is zo storend/ineffectief als een kanaal met overbodige alerts waar geen acties aan gekoppeld moeten worden.</br> </br> </br> Hoogdringend: gsm</br> </br> </br> Belangrijk maar geen onmiddellijke actie: email</br> </br> </br> Om in de achtergrond in de gaten te houden: dashboard specifiek voor monitoring</br> </br> </br> proces uittekenen wie krijgt wat wanneer en hoe (welke kanaal)?</br> </br> </br> Opsplitsing wie men op de hoogte brengt in functie van evolutie situatie metingen in poel.</br> </br> Discussie </br> Proactieve Meldingen:</br> Het systeem moet niet alleen reactief zijn maar ook proactief meldingen sturen bij gevaren, zoals modderstromen. </br> Burgemeester en andere relevante personen moeten notificaties ontvangen via WhatsApp of SMS. </br> Contactinformatie en GDPR:</br> Bepaal wie wanneer gecontacteerd moet worden. </br> Overweeg hoe contactinformatie wordt bijgehouden en voldoe aan GDPR-regelgeving. </br> Meldingscriteria:</br> Meldingen moeten gestuurd worden bij overschrijding van bepaalde drempelwaarden (bijvoorbeeld hoeveelheid neerslag). </br> Verschillende soorten meldingen vereisen specifieke responsen, zoals schoonmaak van een overstortende poel. </br> Betrokkenen en Communicatiekanalen:</br> Naast de burgemeester moeten ook noodplanningsambtenaren via mail of WhatsApp op de hoogte worden gesteld. </br> Betrokkenen kunnen onder andere de technische dienst, brandweer, politie, en omwonenden zijn. </br> Gebruik van bestaande systemen zoals BE-Alert en buurtinformatienetwerken. </br> Overdaad aan Informatie Vermijden:</br> Voorkom dat er te veel informatie wordt gestuurd naar betrokkenen, wat kan leiden tot informatie-overload. </br> Zorg voor duidelijke afspraken over wie wanneer verantwoordelijk is voor welke acties. </br> Opvolging en Statusbeheer:</br> Het systeem moet de status van meldingen kunnen bijhouden (ontvangen, in verwerking, etc.). </br> Gebruik een dashboard voor statusaanpassing, opmerkingen en doorverwijzingen. </br> Procesuitwerking:</br> Werk een duidelijk proces uit voor wie wanneer welke melding ontvangt via welk kanaal (GSM voor dringende zaken, e-mail voor minder dringende zaken, dashboard voor monitoring). </br> Gebruik van Bestaande Technologie:</br> Gebruik bestaande technologieën en platforms om meldingen te versturen en acties te automatiseren. </br> Zorg voor koppelingen met databanken voor contactinformatie (bijv. burgemeesters) om configuratie te vergemakkelijken. </br> Oefening 3 </br> Instructies </br> Hoe ga je data beheren/gebruiken eens dat je deze gecapteerd hebt via de verschillende databronnen? Hoe lang wil je de data bijhouden? Hoe vaak moet de data verzameld worden (frequentie)? Wie neemt de verantwoordelijkheid voor data? Hoe er voor zorgen dat data juist geïnterpreteerd wordt? Welke profielen/rollen zullen met de data werken? Hoe zorgen we voor continuïteit bij ingebruikname van bvb nieuwe sensoren?</br> Voorbeeld: </br> -De milieu ambtenaar die voorheen geen data had, wilt nu kunnen inloggen op het dashboard om de ruwe data te downloaden voor analyses te kunnen doen</br> -Je hebt een data ingenieur nodig van data captatie tot ontsluiten van de data</br> </br> Output </br> </br></br> </br> Databeheer en gebruik</br> </br> </br> Bestaande IoT platformen</br> </br> </br> Zelf een dataplatform bouwen is overkill. Er zijn voldoende bestaande dataplatformen waar oa integratie met sensoren al aanwezig is alsook de storage koppelingen en de ontsluiting naar dashboards, LDES-server, etc...</br> </br> </br> opkuisen/validatie van de data is belangrijk (zowel door iemand met technische achtergrond in sensoren als lokale terreinkennis)</br> </br> </br> data altijd bijhouden (belangrijk academisch maar ook om te leren uit operationeel beheer)</br> </br> </br> Bestaande real time batch processing tools? </br> </br> </br> gevalideerde data mee ontsluiten via bestaande platformen ? bv waterinfo waar info over GOG's staat ? DOV met info over erosiepoelen en sedimentvangen, .... ? Zo kan je onderscheid maken tussen een operationaal platform dat real-time wordt gebruikt en archief met gevalideerde metingen via andere platform</br> </br> </br> Databeheer moet door één partij gebeuren dewelke enkel de relevante behoudt die voor toekomstige simulaties/gebeurtenissen bruikbaar zijn (goede data governance afspraken)</br> </br> </br> Kosten vs snelheid vs volume</br> </br> </br> Data verwijderen is niet nodig. Blobstorage is goedkoop. Enkel mss een strategie over snel toegankelijke data en historische offloading naar blob storage voor minder snel toegankelijke data</br> </br> </br> operationeel : realtime (snelheid belangrijk)</br> </br> </br> inzichten : belangrijk dat de data gevalideerd is (om zo tijdsreeksen te kunnen opmaken bvb)</br> </br> </br> Ruwe data van sensoren is wss onbruikbaar voor ambtenaar, meer nood aan al licht verwerkte en leesbare data. Bijv. al de sensoren die waterstand meten naar 1 datamodel mappen -> deze data beschikbaar stellen aan ambtenaar (aggregatie van de data, of standaardmodel, leesbare KPIs)</br> </br> </br> Bestaande scalable</br> </br> </br> Cloud gebaseerde data storage oplossingen? ? </br> </br> </br> De meest relevante en éénduidige data bijhouden, zoals KMI bvb doet. => bundelen in front office</br> </br> </br> Gert Verstraeten</br> </br> </br> context data en metadata (bvb locatie)</br> </br> </br> modderpoel met zijn eigen 'id' krijgen die met de sensoren data meegestuurd worden</br> </br> </br> datastandaarden - afspraken, bijvoorbeeld tijdsnotatie, Mogelijkheid aanduiden kwaliteit van data (in plaats van gewoon verwijderen), </br> </br> </br> niet gemakkelijk om door de techniekers te laten aanpassen</br> </br> </br> Historische semi-ruwe data (na een eerste verwerking naar standaard model) is belangrijk voor AI dus mag niet gedelete worden.</br> </br> </br> Erosiepoelen zijn in de DOV gestockeerd (of alvast zeer veel)</br> </br> </br> GIS platformen gebruiken voor spatiale analyse , integratie met spatiale databases</br> </br> </br> Termen als Datawarehouses and Datalakes worden vernoemd. Ook Lakehouse bekijken? (best of breed ?) </br> </br> </br> Denken dat een 'platform' een oplossing is. Kwestie van semantiek misschien eerder 'Data componenten oplossing'? </br> </br> </br></br> </br> Functieprofielen/rollen</br> </br> </br> Data eigenaar</br> </br> </br> Data engineer</br> </br> </br> Data analist</br> </br> </br> Data scientist</br> </br> </br> Dashboard/ visualisatie expert</br> </br> </br> tegen hackers die alarmen uisturen of pompen laten starten</br> </br> </br> Cybersecurity expert</br> </br> </br> Dataplatform beheerder</br> </br> </br> DPO (enkel voor GDPR data natuurlijk)</br> </br> </br> Toegangs- en rollen-beheerder</br> </br> </br> Financieel verantwoordelijke</br> </br> </br> Technische architect</br> </br> </br> Product Owner, Implementatie ProjectManager, Data Scientist, </br> </br> </br> Datamodel expert</br> </br> </br> Data strategist ?</br> </br> Discussie </br> Data management: De discussie concentreerde zich op het belang van data management, inclusief data input, beheer, verwerking, en ontsluiting. </br> Data governance: De verantwoordelijkheid voor data, inclusief de vraag wie de eigenaar is, en het belang van goede data governance-afspraken. </br> Dataopslag en -beheer: Er werd gesproken over het bijhouden van historische data, het beheren van verschillende soorten data, en het gebruik van blob storage voor minder snel toegankelijke data. </br> Dataplatformen: Discussies omvatten het overwegen van bestaande dataplatformen versus het bouwen van een eigen platform, integratie met andere platforms, en de functionele en technische vereisten van een dataplatform. </br> Rollen en verantwoordelijkheden: Verschillende rollen werden besproken, waaronder data engineers, data scientists, data-analisten, en de rollen van een DPO (Data Protection Officer) en financieel verantwoordelijke. </br> Technische aspecten: De technische architectuur van het dataplatform, inclusief data warehouses, data lakes, en het concept van een 'lakehouse', werd behandeld. </br> Oefening 4 </br> Instructies </br> Welke zijn de valkuilen waar we volgens jou rekening mee moeten houden?</br> Formuleer enkele basisprincipes waaraan de oplossing moet voldoen</br> Voorbeeld:</br> •Te veel dashboarden waardoor je geen overzicht meer hebt</br> •Complexe dashboard</br> •Verantwoordelijkheid van data</br> </br> Output </br> </br></br> </br> Valkuilen</br> </br> Principes</br> </br> </br> Geen spaghetti integraties</br> </br> </br> </br> </br> Goede afspraken duurzame databeheer (verantwoordelijkheid)</br> </br> </br> </br> </br> teveel informatie die niet meteen begrijpbaar zijn voor de gebruiker: goede selectie maken van wat relevant is om te tonen aan elk doelpubliek + goede metadata beschrijving. </br> </br> </br> </br> </br> Zorg voor opleiding van eindgebruikers</br> </br> </br> </br> </br> onderhoud van het materiaal - te lange periodes met 'no data' of met onrealistische data wegens problemen met de sensoren kunnen vertrouwen ondermijnen </br> </br> goede opvolging noodzakelijk - feedback van lokale terreinbeheerders cruciaal - niet louter een data/IT project</br> </br> </br> Niet opvolgen kosten/baten lange termijn. TCO zicht. Ook kijken naar waar kan waarde gegenereerd worden, en welke schadekosten zijn vermeden. Bijvoorbeeld zeggen we dat goede grond wegspoelt, nu vangen we die (deels) op maar wat doen we ermee? </br> </br> </br> Afhankelijkheid van schaarse technische profielen op de markt </br> </br> </br> </br> </br> Inkomende data op platform moet een eerste validatie krijgen,zodat fouten al in begin van de pipeline opgemerkt worden - Data quality checks : eerste lijn... </br> </br> </br> </br> </br> Mogelijke principe: reeds ontwikkelde bouwstenen hergebruiken+ configuratie off the shelf functionaliteit bestaande technologiën, low code no code configuratie (reeds zelf ontwikkeld-bestaande + technologiën,), configueren en developen enkel als 'bijkomende' capability</br> </br> </br> </br> </br> Budgetten ifv retour hele systeem. Als door monitoring grote schade kan worden voorkomen dan zullen de budgetten te verantwoorden zijn.</br> </br> </br> </br> </br> Dashboards kunnen een tree hebben, dus van overzicht naar detail via enkele klikken. (drill downs, slice/dice) </br> </br> </br> Na kantooruren geen service van dataplatform </br> </br> helpdesk 24/7 ? </br> </br> Discussie </br> Complexiteit van Dashboards: Te veel informatie op dashboards kan leiden tot verwarring en gebrek aan overzicht, waardoor gebruikers de gegevens niet goed begrijpen. </br> Verantwoordelijkheid van Data: Juridische aspecten rondom verantwoordelijkheid voor data in het geval van problemen moeten duidelijk zijn om mogelijke problemen te voorkomen. </br> Budgetten en Leveranciersafhankelijkheid: Het beheer van budgetten en de afhankelijkheid van externe leveranciers zijn cruciale factoren die het succes van het project kunnen beïnvloeden. </br> Datakwaliteit en Validatie: Het belang van datakwaliteit en het instellen van datavalidatieprocessen om fouten in de gegevens te voorkomen. </br> Gebruikersacceptatie en Change Management: Het anticiperen op weerstand tegen verandering en het implementeren van effectief change management om ervoor te zorgen dat gebruikers het nieuwe systeem omarmen. </br> Technische Capaciteiten en Talent: De beschikbaarheid van technisch talent en de afhankelijkheid van schaarse technische profielen op de markt kunnen uitdagingen vormen voor het project. </br> Duurzaamheid en Onderhoud: Het plannen van duurzame databeheerpraktijken en het garanderen van continuïteit en onderhoud van het systeem, inclusief het opzetten van serviceovereenkomsten en een helpdesk. </br> Opname en Miro bord </br> Miro bord </br> Het Miro bord kan je consulteren via deze link . </br> </br> Opname </br> De opname van deze sessie is te bekijken via deze link .</br> </br> </br> </br> </br> Volgende stappen </br> Wat na deze werkgroep?</br> </br> Verwerking van de input van de brainstorm oefening. </br> Verder onderzoek en voorbereiding van de analyse. </br> Publicatie op de Kennishub. </br>Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be Andere werkgroepen </br> Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-02-29 13u30-16u30 Provinciehuis Leuven Thematische werkgroep 1 Data en informatie werkgroep 2024-03-19 9u-12u Teams Thematische werkgroep 2 Functionele werkgroep 2024-04-18 9u-12u Teams Thematische werkgroep 3 Technologie werkgroep 2024-05-23 9u-12u Teams +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix .</br> De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen.</br> De Technologie werkgroep vond plaats op Fout: ongeldige tijd. .</br> </br> Deelnemers </br> </br></br> </br> Organisatie</br> </br> Deelnemer</br> </br> </br> Agentschap Binnenlands Bestuur (VLOCA)</br> </br> Laurien Renders</br> </br> </br> Alain Glickman</br> </br> </br> IGEMO</br> </br> Felipe Garcia Del Pino</br> </br> </br> Sander Bulens</br> </br> </br> Pieter Dresselaers</br> </br> </br> Macq</br> </br> Geert Vanstraelen</br> </br> </br> Kenneth Villaroman</br> </br> </br> ESRI</br> </br> Frank Desmet</br> </br> </br> Geosparc</br> </br> Kris De pril</br> </br> </br> TLV</br> </br> Frederic Keymeulen</br> </br> </br> Be-Mobile</br> </br> Evert Gellynck</br> </br> </br> Stad Mechelen</br> </br> Benjamin Vermeulen</br> </br> </br> Steven Moens</br> </br> </br> Nemeon</br> </br> Mark Verheyden</br> </br> </br> Cronos</br> </br> Peter Buytaert</br> </br> </br> Travis</br> </br> Bas Vissers</br> </br> </br> Max Monkel</br> </br> Context </br> Initiatief </br> Het onderwerp van discussie is vrachtwagenparkeren in het Rivierenland. Er heerst een dringende behoefte aan parkeerplaatsen voor vrachtwagens, aangezien dit probleem al enkele jaren bestaat. Er is bovendien een duidelijke stijging in het aantal inschrijvingen van vrachtvoertuigen in het</br> Rivierenland de laatste jaren. De regio is tevreden met de economische bedrijvigheid achter deze evolutie, maar maakt zich ook zorgen over de externaliteiten verbonden aan de stijging. Er zijn vrachtwagens die rust nemen op verschillende (onveilige) plaatsen, maar er is geen georganiseerde en veilige parkeergelegenheid. Momenteel zijn er ongeveer 180 publieke vrachtwagenparkeerplaatsen beschikbaar in de regio. Dit leidt tot problemen. Bovendien ontbreekt het aan basisvoorzieningen voor chauffeurs, wat resulteert in klachten van burgers en vervuiling langs de wegen. Er wordt gezocht naar oplossingen voor zowel lokale overheden als transportbedrijven, maar dit wordt als een complex en gelaagd probleem beschouwd. Lokale besturen vragen daarom een oplossing voor het kanaliseren van het ‘wildparkeren’ van vrachtwagens.</br> Er zijn drie initiatieven in ontwikkeling om dit probleem aan te pakken.</br> Het eerste initiatief is het creëren van een vrachtwagenparking in de omgeving van Mechelen. Dit is bedoeld om de huidige problemen met openbaar parkeren aan te pakken.</br> Het tweede initiatief richt zich op het ontwikkelen van een applicatie om vrachtwagenparkeren te vergemakkelijken, hoewel nog moet worden beslist of bestaande applicaties zullen worden gebruikt of een nieuwe zal worden gemaakt.</br> Het derde initiatief gaat over het opzetten van een online overlegplatform om verschillende initiatieven en expertise op elkaar af te stemmen.</br> De discussie is hier gericht op het creëren van een oplossing omtrent vrachtwagenparkeerplaatsen in samenwerking met gemeenten en bedrijven, waarbij wordt geprobeerd om de expertise van verschillende belanghebbenden samen te brengen. Daarnaast wordt gezocht naar financieringsmogelijkheden en publiek-private samenwerkingen om het project te ondersteunen. Ook wordt gewerkt aan de standaardisatie en toegankelijkheid van gegevens met betrekking tot vrachtwagenparkeren in Vlaanderen, waarbij externe ondersteuning wordt geboden voor de ontwikkeling van een applicatie.</br> </br> VLOCA </br> 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.</br> </br> Verslag vorige werkgroep </br> Het verslag van de functionaliteiten werkgroep kan je hier terugvinden.</br> </br> Doel huidige werkgroep </br> Introductie geven over het project </br> Toelichting geven over VLOCA </br> Brainstormen over technologie </br> Brainstormsessie </br> Theorie </br> </br>De bovenstaande afbeelding geeft weer wat we in essentie willen bereiken met dit project, namelijk een een wijziging in het aanbod van beschikbare parkings. </br> </br> Om de bedrijfsarchitectuur te analyseren (en het geheel van taken/acties in kaart te brengen) moeten we door een cascade. Werkgroep per werkgroep wordt een nieuwe laag gevormd op basis van de output.</br> </br> Als we naar de hoofdtaken kijken, kunnen we een aantal acties identificeren met betrekking tot de databronnen om waardecreatie te genereren. De uitkomst van deze bewerkingen heeft als uiteindelijk doel het het wildparkeren en de overlast te verminderen, zo wordt waarde gecreëerd. </br> Door enkel de hoofdtaken te identificeren is onze analyse nog niet compleet. De input-en outputtaken bevatten nog een (niet exhaustieve) lijst van andere acties die nodig zijn om van databronnen naar waardecreatie te gaan. Vooraleer bewerkingen mogelijk zijn met de databronnen moeten eerst de inputtaken uitgevoerd worden. Na het bewerken van de databronnen zijn er nog een aantal outputtaken te onderscheiden. </br> Om de analyse compleet te maken hebben we ook nog de applicatiecomponenten (de modulaire bouwstenen van software die specifieke functies uitvoeren zoals gebruikersinterfaces, databases en services) en de overkoepelende applicatiecomponenten (de randvoorwaarden) nodig. </br> </br> Tot slot wensen we elke mogelijke oplossing te toetsen aan een aantal principes. Deze principes kunnen geformuleerd worden op basis van de valkuilen die we identificeren tijdens de werkgroepen. </br> Bijvoorbeeld:</br> Een oplossing wordt gebouwd door een leverancier met een bepaalde technologie. Dit werkt aanvankelijk perfect maar na een paar jaar blijkt deze technologie achterhaald en het platform waarop het gebouwd is, niet meer ondersteund wordt.</br> => om te vermijden dat de oplossing na x jaar in de vuilbak gaat omdat de technologie niet meer voldoet, willen we een veiligheid inbouwen door een voorwaarde/principe op te stellen bij aanvang van de ontwikkeling</br> => principe: de oplossing moet technologie-agnostisch zijn</br> We kunnen hiervoor inspiratie halen uit de VLOCA-principes.</br> </br> </br> </br> Outcome </br> Volgend zijn 4 stellingen waarop de deelnemers argumenten voor en tegen konden formuleren: </br> </br> Stelling 1: Pure matchmaking (Immoweb-model) vs reservatiesysteem (Airbnb-model) </br> </br> </br> Matchmaking model </br> </br></br> </br> Pro</br> </br> Contra</br> </br> </br> Weinig risico op conflicten</br> </br> Je lost het probleem niet op</br> </br> </br> Makkelijk</br> </br> Er is geen zekerheid dat er ook een plek beschikbaar zal zijn</br> </br> </br> Onderling af te stemmen tussen eigenaar/trucker</br> </br> Hoe krijgt de eigenaar van de parkeerplaats zijn inkomsten?</br> </br> </br> Er bestaan al veel platformen</br> </br> </br> Wie is verantwoordelijk voor het up to date houden van de data? Vaak is het door verouderde data dat de chauffeur op de weg moet parkeren</br> </br> </br> Gebrek aan zekerheid van de plaats</br> </br> </br> Controle/inzicht op service & kwaliteit?</br> </br> </br> Stats?</br> </br> </br> Data?</br> </br> Reservatie systeem </br> </br></br> </br> Pro</br> </br> Contra</br> </br> </br> Zekerheid</br> </br> Wat als er geen aanbod is?</br> </br> </br> Juiste communicatie met chauffers die boeking hebben in verschillende talen. Duidelijke uitleg</br> </br> Vergunning nieuwe plaatsen: toelichting aan bevolking (igv stallen gevaarlijke stoffen)</br> </br> </br> Ondersteuning vanuit platform om alles goed te regelen voor de parkeerplaats</br> </br> Data vrachtwagenverkeer: eigendom data blijft bij overheid voor verdere analyse</br> </br> </br> Zekerheid van plaats voor</br> </br> App adaptaties</br> </br> </br> Betrouwbaarheid</br> </br> Zoveelste nieuwe app</br> </br> </br> Opvolging bij 3de partij en niet bij logistieke partijen en chauffeurs</br> </br> </br> All-in 1 solution</br> </br> Stelling 2: Vrijblijvend delen van data (+ zelf een app bouwen vs data naar bestaande leverancier sturen (bvb Travis)) vs Trivago model (met verschillende databases) </br> </br> Pro: </br> </br> weinig risico en kleinere investering </br> Integratie mogelijk met andere navigatie/booking software </br> Stelling 3: Dataspace vs gecentraliseerd model </br> </br> </br> Stelling 4: Volledige samenwerking vs scraping (metasearch) </br> </br> </br> Debat </br> Travis: het eenvoudige van de zaak is een netwerk bouwen van beschikbare parkeerplaatsen (supply). Het moeilijke is de chauffeurs bereiken. Alles wordt beslist door planners etc. De vraag is hoe je de gebruikers (in dit, de planners in het hoofdkantoor) bereikt. Dit is waar je een oplossing kan vinden voor deze problematiek. Je moet uiteindelijk in de planningssystemen geraken, hier worden de beslissingen gemaakt. </br> - VLOCA: Dit is het CRM gedeelte van het project en behoort vandaag niet tot de scope van de discussie</br> - Er is wel een soort dataset die aan planners en systemen ter beschikking kan gesteld worden. </br> Geosparc: Het bouwen van apps moet geen verantwoordelijkheid zijn van een overheid maar eerder datauitwisseling stimuleren. Partijen zouden moeten verplicht worden om datasets ter beschikking te stellen wanneer zij daarop willen aansluiten. </br> Gaan we genoeg effect creëeren met een opportunistisch model? Data is wel wat waard. Gaat er iemand interesse voor tonen? Als lokale organisatie kunnen we een rol spelen in het zoeken naar bedrijven die hun parking willen delen. Kan deze informatie voor iets of iemand dienen?</br> - De taak van de overheid kan voorwaarden bepalen om parkings ter beschikking te stellen. Het kader schetsen. </br> Het Trivago model kan enkel werken wanneer anderen hun data open stellen. Booking stelt zijn data open hiervoor. Dit kan je bereiken met het dataspace model waarbij iedereen eigenaar blijft van zijn eigen data maar stelt ze wel ter beschikking. Je hebt samenwerkingsovereenkomsten tussen de verschillende spelers nodig. De overheid kan dan standaarden opleggen waarbij iedereen in de markt vrij is om met een leverancier naar keuze in zee te gaan. </br> - Dit zou eerder dan op Vlaams niveau opgezet moeten worden aangezien een voldoende grote schaal nodig is. Het overstijgt dan de gemeentelijke grenzen</br> </br> Vragen </br> Hoeveel parkeerplaatsen zijn er naar schatting beschikbaar in de verschillende gemeenten? </br> - een 180-tal parkeerplaatsen voor vrachtwagens. Dit is een ruwe inschatting op basis van luchtfoto's. Een exacte telling is nog niet gebeurd. Er is al wel een ruimtelijke analyse gedaan om in kaart te brengen welke parkeerplaatsen in aanmerking zouden kunnen komen (ifv aanrijafstand, locaties etc). Ook hebben er al gesprekken plaatsgevonden met partijen die grond ter beschikking zouden willen/kunnen ter beschikking stellen. </br> Vraag voor Travis: hoe wordt er omgegaan met bedrijven die eventueel wel interesse zouden hebben om hun terreinen ter beschikking te stellen voor lokale vrachtwagens maar niet voor internationaal, doorrijdend verkeer? </br> - Travis vraagt aan de chauffeurs om een aantal gegevens: bedrijfsnaam, kentekennummer, naam chauffeur en de periode van parkeren. De eigenaar van het terrein weet zo perfect wie er wanneer op zijn parking staat. Er wordt echter geen onderscheid gemaakt in herkomst van chauffeur of waar het bedrijf vandaan komt. Travis begeleidt de eigenaars van de parkings om ervoor te zorgen dat de chauffeur perfect wordt ingelicht met betrekking tot de regels. </br> Hoe zit de aanpak qua beleid? Data is nodig om te prioriteren. </br> - Momenteel lopen er gesprekken met Quares. Zij hebben een gelijkaardige studie gedaan in o.a. Gent. Zij stellen dat een combinatie van een vrachtwagenparking met het opladen van iets essentieel is om bedrijven ervan te overtuigen om vrachtwagens te laten parkeren op hun terreinen. Ze denken dan voornamelijk aan een afroepsysteem, gekoppeld aan het laden en lossen, maar op een centrale plek. Er wordt dus ingezet op zowel infrastructuur als het digitale aspect.</br> Kan de overheid een verplichting opleggen aan de markt om data te delen?</br> - De bedoeling van dit platform kan net zijn om een rol te leggen bij Vlaanderen die standaarden en een dataspace ondersteunt. Zo leg je niets op maar creëer je de ruimte om iedereen in het systeem te laten instappen. Er wordt dus een standaard ter beschikking gesteld wat deuren opent. Dit is een model waarbij je via open standaarden communiceert en waarbij iedereen zich kan enten op deze standaarden. Zo is het mogelijk dat bvb IGEMO haar parkeerplaatsen aanbieden via een open model zodat dat het interessant wordt voor andere spelers om dat model aan te nemen. IGEMO kan zo een katalysator zijn zonder enige verplichting op te leggen. Dit is de essentie van de open data spaces in Vlaanderen. </br> Valt er iets te leren over studies rond parkings van personenwagens? Regionaal of stedelijk werden zones vastgelegd waarbinnen je mag parkeren. Er zijn daarnaast ook private aanbieders van apps voor parkings. Op termijn zijn het de gebruikers zelf die beslissen welke applicaties die het nuttigste waren. Ze werden wel ondersteund door (lokale) overheden. Je krijgt dan een rimpeleffect zoals bij applicaties als 4411. Worden de learnings uit deze ervaringen mee genomen in dit project? Voor vrachtwagenparkings kunnen lokale besturen, net zoals voor personenwagens, bepaalde zones inkleuren (die dan gestandaardiseerd zijn)? </br> - IGEMO: Nog niet. Voor de ons zijn dit gescheiden werelden. Voor vrachtwagens is de ruimte zeer belangrijk, net zoals bvb de beveiliging. Dit maakt het volgens ons niet mogelijk om het organisch zijn gang te laten gaan. Gemeenten zullen zeer terughoudend zijn rond vrachtwagenparkings. Dit wordt liever stil gehouden. Ze willen niet dat iedereen daar kan parkeren. Daarnaast kan de plaats die je als gemeente aanduidt als parkeerplaats kan aanleiding geven tot klachten van bewoners. Tot nu toe hebben we dit nog niet meegemaakt. Onze focus ligt op de lokale problematiek en bedrijven. De app moet meer naar een afgesloten systeem gaan. Daarnaast kan ook een open systeem opgezet worden waar Travis bvb kan inspelen. Het idee van de open space lijkt interessant maar dit is niet echt van toepassing op onze lokale problematiek. </br> - Bij een open dataspace is het model open maar hierbij moet je niet al je data open te stellen voor iedereen. Hier kan je rechten en beperkingen op zetten. Je kan lokale en bovenlokale parkeerplaatsen ter beschikking stellen waarbij je lokale parkeerplaatsen enkel ter beschikking stelt van chauffeurs uit de eigen regio. Dit is perfect definieerbaar. De reservatie kan dan bvb enkel gebeuren door regiogebonden organisaties. Indien er echter een terreineigenaar is voor wie het niet uitmaakt wie er op zijn parking staat, dan zit je in een ander niveau. Een dataspace wil niet impliceren dat alles open is voor iedereen. </br> - IGEMO: we moeten op de internationale stromen meeliften. Voor een parkeerplaats op de snelweg wordt een vergoeding gevraagd per nacht. Indien er een vergoeding voor de lokale parkeerplaatsen naar de lokale overheden kan vloeien, kan hiermee iets anders gerealiseerd worden. Zo creëer je een synergie. Er is geen commerciële drijfveer, we zoeken naar een oplossing voor een probleem. Onze eerste opdracht is om data te verzamelen. </br> Indien er een nieuwe commerciële speler komt die zich op dit probleem wil richten en hiervan een business model wil maken, staat de deur hiervoor open?</br> - IGEMO: absoluut! Wij hebben geen enkele baat bij het bouwen en exploiteren van een applicatie. Idealiter faciliteren we dit en komt het beheer in handen van een partner. Wij hebben de opdracht gekregen om een oplossing te vinden voor vrachtwagens die zich op het openbaar domein bevinden. Voor hen moet plaats gevonden worden zodat ze zich op een toegewezen plek kunnen parkeren. We willen echter wel inzicht in de data die gegenereerd worden. De problematiek is een gedeelde verantwoordelijkheid onder o.a. de sector en lokale besturen.</br> </br> Volgende stappen </br> De volgende stappen zijn:</br> </br> Verwerking van de input van de brainstorm oefening </br> Rondsturen van een link naar dit verslag en presentatie </br> Resultaten verzamelen en verwerken in een referentiedocument </br> Andere werkgroepen </br> Hieronder het overzicht van alle VLOCA-werkgroepen die hebben plaatsgevonden binnen het kader van het traject Vrachtwagenparkeren .</br> </br> Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2023-09-26 IGEMO Thematische werkgroep 1 Data en informatie werkgroep 2023-10-24 IGEMO Thematische werkgroep 2 Functionele werkgroep 2023-11-21 IGEMO Thematische werkgroep 3 Technologie werkgroep 2024-01-30 9u00-12u00 IGEMO +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix .</br> De verzamelde inzichten worden vervolgens verwerkt om de IT-architectuur verder aan te vullen.</br> De Technologie werkgroep vond plaats op Fout: ongeldige tijd. .</br> </br> Deelnemers </br> </br></br> </br> Organisatie</br> </br> Deelnemer</br> </br> </br> Agentschap Binnenlands Bestuur (VLOCA)</br> </br> Laurien Renders</br> </br> </br> Alain Glickman</br> </br> </br> Intercommunale Leiedal</br> </br> Lucas Verbanck</br> </br> </br> Inge Wydhooge</br> </br> </br> David Lingier</br> </br> </br> Thomas Goemaere</br> </br> </br> Stad Gent</br> </br> Jan Godderis</br> </br> </br> Dieter Nieuwborg</br> </br> </br> District09</br> </br> Ann Bernaert</br> </br> </br> Provincie West-Vlaanderen</br> </br> Wim Beerten</br> </br> </br> GIM</br> </br> An Heirman</br> </br> </br> Departement Omgeving</br> </br> Stijn Vanderheiden</br> </br> Context </br> Initiatief </br> 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.</br> 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.</br> In dit streven zijn we op zoek naar een aantal essentiële elementen:</br> 1. Een permanente monitoring van de kenmerken van een buurt, zodat we op de hoogte blijven van de veranderende behoeften en trends.</br> 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.</br> 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.</br> </br> VLOCA </br> 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.</br> </br> Samenvatting vorige werkgroep </br> Het verslag van de functionaliteiten werkgroep kan je hier terugvinden.</br> </br> Doel huidige werkgroep </br> Introductie geven over het project </br> Toelichting geven over VLOCA </br> Brainstormen over technologie </br> Brainstormsessie </br> Theorie </br> Om de bedrijfsarchitectuur te analyseren (en het geheel van taken/acties in kaart te brengen) moeten we door een cascade. Werkgroep per werkgroep wordt een nieuwe laag gevormd op basis van de output. </br> </br> Als we naar de hoofdtaken kijken, kunnen we een aantal acties identificeren met betrekking tot de databronnen (locatiegegevens en ruimtelijke relaties) om waardecreatie te genereren. Concreet kunnen we bewerkingen doen op de databronnen zoals afstandsmetingen, het berekenen van aantallen en het meten van oppervlaktes. De uitkomst van deze bewerkingen heeft als uiteindelijk doel het beleid te informeren bij het plannen van voorzieningen op strategische locaties. De waardecreatie bestaat uit het voorzien van voldoende parken, scholen, openbaar vervoer etc. </br> </br> Door enkel de hoofdtaken te identificeren is onze analyse nog niet compleet. De input-en outputtaken bevatten nog een (niet exhaustieve) lijst van andere acties die nodig zijn om van databronnen naar waardecreatie te gaan. Vooraleer bewerkingen mogelijk zijn met de databronnen moeten eerst de inputtaken uitgevoerd worden. Na het bewerken van de databronnen zijn er nog een aantal outputtaken te onderscheiden.</br> </br> Tijdens de oefening van vandaag gaan we om te beginnen op zoek naar de applicatiecomponenten bij elk van de taken. De applicatiecomponenten zijn de modulaire bouwstenen van software die specifieke functies uitvoeren zoals gebruikersinterfaces, databases en services. </br> </br> Vervolgens maken we de cascade compleet door na te denken over de randvoorwaarden. Dit zijn de overkoepelende applicatiecomponenten. </br> </br> Tot slot wensen we elke mogelijke oplossing te toetsen aan een aantal principes. Deze principes kunnen geformuleerd worden op basis van de valkuilen die we identificeren tijdens de werkgroepen. </br> Bijvoorbeeld:</br> Een oplossing wordt gebouwd door een leverancier met een bepaalde technologie. Dit werkt aanvankelijk perfect maar na een paar jaar blijkt deze technologie achterhaald en het platform waarop het gebouwd is, niet meer ondersteund wordt.</br> => om te vermijden dat de oplossing na x jaar in de vuilbak gaat omdat de technologie niet meer voldoet, willen we een veiligheid inbouwen door een voorwaarde/principe op te stellen bij aanvang van de ontwikkeling</br> => principe: de oplossing moet technologie-agnostisch zijn</br> We kunnen hiervoor inspiratie halen uit de VLOCA-principes.</br> </br> </br> </br> Oefeningen </br> Link naar het Miro bord </br> De link naar het Miro bord kan je hier terugvinden. </br> </br> Oefening 1: applicatiecomponenten identificeren </br> Voor elk van de input-, hoofd-en outputtaken gaan we op zoek naar de applicatiecomponenten. Deze hebben we nodig om over te gaan naar realisatie van de oplossing.</br> Reminder: applicatiecomponenten zijn modulaire bouwstenen van software die specifieke functies uitvoeren, zoals gebruikersinterfaces, databases en services. Dit zijn gedetailleerde, specifieke bouwstenen of modules binnen een applicatie.</br> Voorbeeld: </br> - Om aan data transformatie te doen heb je een ETL applicatie component nodig</br> - Om resultaten zelf te visualiseren heb je een self service rapporterings applicatie component nodig</br> - Om een oppervlakte te meten/berekenen heb je een location intelligence 'surface calculator' (?) nodig</br> </br> Oefening 2: overkoepelende applicatiecomponenten identificeren </br> Naast de ‘gewone’ applicatiecomponenten moeten we ook op zoek naar de overkoepelende applicatiecomponenten.</br> Overkoepelende applicatiecomponenten zijn de grote, samenhangende delen van een softwaretoepassing die verschillende functionaliteiten en taken coördineren om het beoogde doel van de applicatie te bereiken. Deze componenten werken vaak samen en vormen de ruggengraat van de applicatie. Het zijn bredere, meer strategische componenten die de algemene structuur en functionaliteit van een applicatie bepalen.</br> Voorbeeld: </br> - GDPR</br> - Algemene gebruiksvoorwaarden</br> - Kwaliteitscheck van de bronnen</br> - Voorzien van een helpdesk</br> - Organiseren van opleidingen</br> </br> Oefening 3: Identificatie valkuilen en principes </br> Welke zijn de valkuilen waarmee we rekening moeten houden bij de keuze van een oplossing?</br> Formuleer enkele basisprincipes waaraan de oplossing moet voldoen (VLOCA principes kunnen inspiratie bieden)</br> Voorbeeld:</br> -Self-service zonder goede training kan 'gevaarlijk' zijn.</br> -PowerBI rapport in een gemeente die geen PowerBI licentie heeft maar enkel MS Office</br> </br> Oefening 4: bijkomende vragen van de initiatiefnemers </br> Hoe zetten we het beheer van dataverwerking op voor verschillende lokale besturen? Rekening houden dat zowel stad Gent als (verschillende besturen binnen het werkgebied) Intercommunale Leiedal zullen gebruikers zijn. </br> </br> Outcome </br> Oefening 1 </br> </br></br> </br> Input taken</br> </br> </br> </br> Hoofdtaken</br> </br> </br> </br> Output taken</br> </br> </br> </br> Valkuilen</br> </br> </br> </br> Principes</br> </br> </br> Belmap API voor geocoderen</br> </br> </br> </br> Realtime sensordata: verkeersmetingen (bv telraam) , zonlicht, geluid, luchtkwaliteit,</br> </br> </br> </br> (3D) Simulatieplatform met geïntegreerde algoritmes/modellen cross-use case (vb Zanadoo/Tygron) oa voor impactanalyse, predictive modelling</br> </br> </br> </br> Garantie van datakwaliteit (bewaken na verloop van tijd)</br> </br> </br> </br> interface op maat van gebruikers/profielen</br> </br> </br> geocoderen via GIS-software - API Vlaanderen - ...</br> </br> Netwerkanalyse in ArcMap/FME voor berekenen bereikbaarheids-zones</br> </br> simuleren > voorspellen: nood aan rekenmodel - model afhankelijk van thema</br> </br> kennis / ervaring gebruik Python best practices (niet iedereen is op zelfde niveau)</br> </br> eenvoudig starten, geleidelijk aan uitbreiden</br> </br> </br> FME Data Integratie Platform voor aggregren, clusteren, verrijken, automatisch updaten, transformeren, ...</br> </br> Analyse straat- en luchtbeelden</br> </br> 'Statische' info visualiseren op geoloket</br> </br> tool voor het brede publiek: moet helder en gemakkelijk zijn in gebruik - moet de eerste lijns-ambtenaar ontzorgen… maar mag de werkelijkheid niet simplifiëren - juistheid van de gedeelde data</br> </br> doelpubliek in rekening brengen bij output</br> </br> </br> API om data Netwerk en voorzieningen binnen te halen</br> </br> Feature extraction, image classification, Object detection</br> </br> Statistische info op Stad/Provincie in Cijfers</br> </br> Hergebruik waar mogelijk</br> </br> </br> ETL om ruwe data te verwerken tot afgeleide data (klaar voor berekening)</br> </br> geografische analyses</br> </br> publiceren op (open) dataportaal ifv doorgedreven GIS-analyses</br> </br> gedurende de (continue) ontwikkeling steeds terugkeren naar de gebruiker voor snelle bijsturing waar nodig</br> </br> </br> GIS-software (ArcGIS, QGIS), FME, SQL, Python, R</br> </br> Geo-webtoepassing voor eenvoudige visualisatie van resultaten</br> </br> voorbeeldstudies bij wijze van introductie van de tool ifv communicatie ? laagdrempelig</br> </br> </br> Geolocation</br> </br> Python</br> </br> Samenwerkingsplatform (communicatie met externe partijen ontwikkelaars, burgers, wijk,...) voor scenariotesting en bijsturing</br> </br> standaard werkmethode</br> </br> </br> API Vlaanderen</br> </br> GIS libraries</br> </br> Python Pandas (Dataframe) naar DB</br> </br> Gevaarlijk om dynamische (continue updates) grafieken te delen !</br> </br> </br> clusteren - verrijken - ..</br> </br> FME Data Integratie Platform (server component)</br> </br> Bijhouden, visualiseren, informeren, planologisch (ruimtelijk) beleid (RUP, GWP)</br> </br> Ijkpunten vastleggen, op data van welke moment analyse is gebeurd.</br> </br> </br> Netwerkanalyse - bereikbaarheidzones --> ESRI, FME, openrouteservice</br> </br> GOAT tool</br> </br> </br> Python</br> </br> meten oppervlaktes: ESRI, FME, QGIS, GDAL?,</br> </br> Training : Videos/Youtube kanaal, opname doen, camera's</br> </br> </br> DB/API Integraties</br> </br> afstand tot groen</br> </br> Scheduler om analytische rapporten regelmatig te draaien ifv triggers/events</br> </br> </br> DSI : Digitale Stedenbouwkundige informatie</br> </br> analyse van data - creëren van berekende data /... via GIS/FME/SQL/Python/R</br> </br> visualiseren in GIS programma (ook in powerpoint)</br> </br> </br> Realtime updating: Message broker</br> </br> ESRI :story map, dynamic powerpoint (pdf)</br> </br> </br> ArcGIS for Power BI</br> </br> </br> Clevermaps, Qlick</br> </br> </br> updaten > analyses herhalen - scheduler (FME, server - scripts, ..)</br> </br> visualiseren: VertiGIS</br> </br> </br> geomapping</br> </br> monitoring / vergelijken</br> </br> </br> GIS-software </br> </br> </br> link bestaande data verzameling bijv. provincies in cijfers e.a.</br> </br> BI-rapportage</br> </br> </br> AI training / Machine learning aan de hand van historische datasets</br> </br> </br> update: versioning</br> </br> </br> monitoring / vergelijken</br> </br> </br> Verrijking: linked data (dataspace ?)</br> </br></br></br> </br> Oefening 2+3 </br> </br></br> </br> Input taken</br> </br> </br> </br> Hoofdtaken</br> </br> </br> </br> Output taken</br> </br> </br> </br> Valkuilen</br> </br> </br> </br> Principes</br> </br> </br> marktplaats > (open) dataplatform > welke data zet je voor wie open: intern, overheid, burgers, bedrijven</br> </br> </br> </br> Documentatie metadata</br> </br> </br> </br> Hosting omgeving (vb AWS)</br> </br> </br> </br> Vertrouwen in data door beleids-medewerkers: hoe aanpakken?</br> </br> </br> </br> Traceerbaarheid van de data</br> </br> </br> marktplaats: github (afgewerkte toepassing vrij laten gebruiken) of kostendelend model</br> </br> data catalog</br> </br> FAQ</br> </br> </br> </br> </br> </br> </br> Security: Pseudo- of anonimiseren van data of aggregeren</br> </br> HPC : HighPerformance Computing (Vlaamse Super Computer)</br> </br> </br> wie laat je toe om met de data aan de slag te gaan: overheden, studiebureau's, burgers.....expertise over de data is vaak essentieel.</br> </br> Security: Multi-Factor-Authentication</br> </br> Opvolging wetgeving/beleidsdoelstelling: GDPR, AI, en veranderende wetgeving/beleid</br> </br> </br> Rollen en verantwoordelijkheden</br> </br> Vlaanderen: ACM / IDM componenten</br> </br> duidelijke doucumentatie + opleiding voor verschillende profielen</br> </br> </br> Competenties (bevraging)/rol</br> </br> SLA & Data Governance : Afspraken rond updates en aanleveren van nieuwe data met aandacht voor de kwaliteit van de data</br> </br> </br> dataintegratie van verschillende bronnen: intern, open, privaat</br> </br> </br> verantwoordelijkheid: databeheer, databronnen, onderhoud</br> </br> </br> samenwerkingsovereenkomst / afsprakenkader</br> </br> </br> toegankelijkheid: steeds meer applicaties ? centraal vertrekpunt? ? herkenbaarheid vanuit Vlaamse overheid</br> </br> </br> overzicht van gebruik/gebruikers (monitoren)</br> </br> </br> Anonimiseren en pseudonimiseren</br> </br> Oefening 4 </br> "Hoe zetten we het beheer van dataverwerking op voor verschillende lokale besturen? Rekening houden dat zowel stad Gent als (verschillende besturen binnen het werkgebied) Intercommunale Leiedal zullen gebruikers zijn"</br> Leiedal: "we wensen iets te ontwikkelen voor Stad Gent en andere lokale besturen die hiervan gebruik willen maken. We zijn op zoek naar good practices, tips en tricks etc."</br> </br> Het blijft altijd een pijnpunt wanneer de correctheid van de data niet gegarandeerd kan worden. Het is daarom belangrijk om goede afspraken te maken over de manier waarop data verzameld wordt. Bepaalde kwalitatieve data kan enkel lokaal verzameld worden maar het beheer moet op grotere schaal (idealiter op Vlaams niveau) gebeuren. Hoe wordt dit het beste georganiseerd? VLAIO neemt de lead maar heeft onvoldoende terreinkennis mbt de verzameling van de data waardoor een mismatch ontstaat tussen de aanpak van VLAIO en de nood op het terrein. Er is een goed overlegmodel nodig om de manier te kunnen finetunen waarop data verzameld wordt. </br> De vraag gaat een stuk over data. De bouwblokken zijn een goed voorbeeld waarvoor we op Vlaams niveau een oplossing zoeken. Het gaat echter ook over de ETL verwerkingsprocessen naar informatie. Deze processen worden opgezet en uitgerold in verschillende besturen. Draait dit bij iedereen best apart of toch beter gezamenlijk opzetten? </br> De toeristische infrastructuur wordt beheerd door verschillende provincies bvb de knooppunten (bordjes) voor de wandel-en fietsroutes. Elke provincie beheert deze infrastructuur, weliswaar met ambassadeurs op het terrein. Zij verzamelen en actualiseren de data in hun eigen systemen. Toerisme Vlaanderen, als overkoepelende entiteit, gaat dan ervoor zorgen dat de data samen komt, er kwaliteitscontroles gebeuren en dat er op de grenzen van de provincies de netwerken mooi op elkaar aansluiten etc. De overkoepelende netwerkinformatie kan zo gebruikt worden in verschillende applicaties om je wandel-of fietsroute te plannen. Dit is een proces dat gestuurd wordt via de cloud, waarbij er rapporteringen kunnen gebeuren en waarbij de provincies instaan voor de kwaliteit van hun data. Zij bieden deze aan en er wordt automatisch een controle gedaan op een aantal kwaliteitspunten die afgesproken worden (bvb wat verstaan wij onder kwaliteit voor dataset x of y, aan welke vormvereisten moeten deze voldoen). Indien er iets niet in orde zou zijn, wordt dit in een rapport gegoten en koppelt men hierover terug zodat dit kan verbeterd worden en de data opnieuw kan aangeboden worden. Dit is een voorbeeld van decentraal beheer dat centraal aangeboden wordt. </br> Voor Slim Ruimtelijk Plannen is het moeilijk om te zeggen aangezien er verschillende beleidsdomeinen bij elkaar komen. Je bent hier niet zeker van de dekking van de gebieden die door de lokale besturen aangeboden worden. </br> </br>Leiedal: enerzijds proberen we zoveel mogelijk open data te gebruiken. Soms heeft een lokaal bestuur een betere dataset rond bvb groen die we graag willen integreren in de tool. Als je open data gebruikt, ga je er vanuit dat het een volledig gebied dekt. Hier tegenover staat de interne data die bij de grenzen stopt. Ruimtelijke plannen gaat net over deze grenzen heen en hierbij wil je ook effecten van een buurgemeente kunnen mee in kaart nemen wanneer je SLIM ruimtelijk wil plannen. Alle informatie van de gemeentegrenzen willen we meenemen. </br> </br> Het komt erop neer dat je moet bepalen welke datasets je wil opbouwen en ter beschikking stellen en hierrond duidelijke afspraken te maken met de kwaliteitseisen in het achterhoofd </br> Indien lokale data niet helemaal accuraat is, moet bekeken worden hoe ze aan te passen of aangevuld worden aan de hand van een extrapolatie </br> Het belangrijkste is dat bij het gebruik van datasets die door verschillende partijen gebruikt worden, duidelijke afspraken gemaakt worden. Hiervoor zit je eerder in het OSLO-traject: zowel rond semantiek als structuur van aanvoer van gegevens. </br> Rond de verwerking van de data: wie beheert de centrale ruimtelijke planning? Of blijft dit lokaal? Heeft het zin om deze te centraliseren</br> </br> Dit heeft enkel zin wanneer ze herbruikbaar zijn door verschillende partijen. </br> Er moet voldoende kennis zijn </br> De data moet kunnen gelezen/gebruikt worden met verschillende software </br> Het is belangrijk om dit goed in de interface te verwerken om wanorde te vermijden => standaardisatie is nodig om scripten op te laden </br> Discussiepunten </br> Het is gevaarlijk om dynamische (realtime) grafieken te delen - er kan een grote impact zijn op het beleid. Men moet deskundig omgaan met data</br> </br> Dit is ook de vraag altijd: willen we met actuele data werken? Je zit altijd met een stedenbouwkundig of een verordening tempo. Je wil wel dat de data een actueel beeld geeft van de toestand. Een goed ritme vinden daarin is belangrijk. </br> Daarom is het belangrijk om hierover op voorhand te communiceren naar beleid; een ijkpunt is nodig voor analyse. Het probleem komt vaak terug bvb bij verkeerstellingen kan er een snelle evolutie plaatsvinden. Bij discussies bij de Raad van State kan geargumenteerd worden dat data niet meer actueel is. Dit kan verregaande gevolgen hebben. </br> </br> Specialisten zullen gemakkelijk hun weg vinden naar courant gebruikte applicaties van de Vlaamse Overheid maar indien het de bedoeling is om een breed publiek aan te spreken (bvb in het kader van participatie), zal het belangrijk dat we niet vanuit verschillende applicaties apart werken maar dat er een soort herkenbaarheid is. Dit schept mogelijks meer vertrouwen bij burgers. Dit kan belangrijk zijn om mee te nemen zodat iedereen nog de bomen door het bos ziet.</br> Het is belangrijk om een concreet voorbeeld te kunnen geven ipv veel theorie bij een nieuwe applicatie voor bvb ambtenaren. Het kan interessant zijn om een case te onderbouwen met deze tool dan.</br> </br> dit kan het bewustzijn verhogen rond de kracht van data en wat ermee mogelijk is </br> dit kan ook dienen als een spiegel om te bekijken hoe bruikbaar een tool is en of bepaalde zaken nog aangepast moeten worden </br> Vragen en opname </br> Vragen </br> Vraag voor Ann: zit bvb de impact van een bouwproject voor +1000 inwoners en daaraan gelinkte druk op parken ook in het platform? De front-end van het platform is volledig gebouwd op API's. Hier zitten verschillende simulaties in maar het is open en uitbreiding is mogelijk waardoor je nieuwe use cases of simulaties en modellen aan kan toevoegen bvb biodiversiteit, leefbaarheid etc. Eens je een licentie hebt voor het gebruik van het platform kan je aan de modellen aan maar het is niet gratis. </br> Vraag voor Ann: is het eenvoudig om analyses over te zetten naar een presentatie voor het beleid? - het is allemaal voorzien om mooie kaarten te produceren die je kan opnemen in een rapportering. </br> Opname </br> De opname van deze sessie is te bekijken via deze link .</br> </br> </br> </br> </br> Volgende stappen </br> De volgende stappen zijn:</br> </br> Verwerking van de input van de brainstorm oefening </br> Rondsturen van een link naar dit verslag en presentatie </br> Resultaten verzamelen en verwerken in een referentiedocument Andere werkgroepen Hieronder het overzicht van alle VLOCA-werkgroepen die hebben plaatsgevonden binnen het kader van het traject Slim Ruimtelijk Plannen . </br> 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 +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix .</br> Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen deze noden in kaart brengen. Specifiek zijn we voor deze werkgroep op zoek naar meer technische profielen zoals IT-architecten, solutions architecten, IT managers, personen die actief zijn binnen de industrie,..</br> 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?</br> </br> Klik hier om je in te schrijven. Andere werkgroepen </br> 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 werkgroep 2023-02-28 09u00-12u00 Digitaal +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix .</br> Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen deze noden in kaart brengen. Specifiek zijn we voor deze werkgroep op zoek naar meer technische profielen zoals IT-architecten, solutions architecten, IT managers, personen die actief zijn binnen de industrie,..</br> 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?</br> </br> Klik hier om je in te schrijven. Andere werkgroepen </br> Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2023-01-12 13u00-16u00 VAC Gent Thematische werkgroep 2 Functionele werkgroep 2023-04-04 13u00-16u00 Digitaal Thematische werkgroep 3 Technologie werkgroep 2023-05-09 13u00-16u00 Digitaal werkgroep 2023-05-09 13u00-16u00 Digitaal +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix .</br> Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen deze noden in kaart brengen. Specifiek zijn we voor deze werkgroep op zoek naar meer technische profielen zoals IT-architecten, solutions architecten, IT managers, personen die actief zijn binnen de industrie,..</br> 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?</br> </br> Klik hier om je in te schrijven. Andere werkgroepen </br> 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 Teamsnologie werkgroep 2024-07-09 13u-16u Teams +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix .</br> Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen deze noden in kaart brengen. Specifiek zijn we voor deze werkgroep op zoek naar meer technische profielen zoals IT-architecten, solutions architecten, IT managers, personen die actief zijn binnen de industrie,..</br>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?</br> </br> Klik hier om je in te schrijven. Andere werkgroepen </br> Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-03-21 10u-13u VAC Brugge Thematische werkgroep 1 Data en informatie werkgroep 2024-05-21 9u-12u Teams Thematische werkgroep 2 Functionele werkgroep 2024-06-18 9u-12u Teamsctionele werkgroep 2024-06-18 9u-12u Teams +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix .</br> Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen deze noden in kaart brengen. Specifiek zijn we voor deze werkgroep op zoek naar meer technische profielen zoals IT-architecten, solutions architecten, IT managers, personen die actief zijn binnen de industrie,..</br>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?</br> </br> Klik hier om je in te schrijven. Andere werkgroepen </br> Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-09-10 9u-12u VAC Brugge Thematische werkgroep 1 Data en informatie werkgroep 2024-10-10 9u-12u Teams Thematische werkgroep 2 Functionele werkgroep 2024-11-05 9u-12u Teams Thematische werkgroep 3 Technologie werkgroep 2024-12-03 9u-12u Teamshnologie werkgroep 2024-12-03 9u-12u Teams +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix .</br> Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen deze noden in kaart brengen. Specifiek zijn we voor deze werkgroep op zoek naar meer technische profielen zoals IT-architecten, solutions architecten, IT managers, personen die actief zijn binnen de industrie,..</br>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?</br> </br> Klik hier om je in te schrijven. Andere werkgroepen </br> Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-09-12 13u-16u VAC Antwerpen Thematische werkgroep 1 Data en informatie werkgroep 2024-10-15 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-11-12 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-12-10 9u-12u Teamshnologie werkgroep 2024-12-10 9u-12u Teams +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix .</br> Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen deze noden in kaart brengen. Specifiek zijn we voor deze werkgroep op zoek naar meer technische profielen zoals IT-architecten, solutions architecten, IT managers, personen die actief zijn binnen de industrie,..</br>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?</br> </br> Klik hier om je in te schrijven. Andere werkgroepen </br> Werkgroep Type werkgroep Datum Tijd Locatie Business werkgroep Business werkgroep 2024-09-26 13u-16u VAC Leuven Thematische werkgroep 1 Data en informatie werkgroep 2024-10-21 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-11-21 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-12-19 13u-16u Teamsnologie werkgroep 2024-12-19 13u-16u Teams +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix .</br> Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen deze noden in kaart brengen. Specifiek zijn we voor deze werkgroep op zoek naar meer technische profielen zoals IT-architecten, solutions architecten, IT managers, personen die actief zijn binnen de industrie,..</br>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?</br> </br> Klik hier om je in te schrijven. Andere werkgroepen </br> Werkgroep Type werkgroep Datum Tijd Locatie Thematische werkgroep 1 Data en informatie werkgroep 2024-06-11 13u-16u Teams Thematische werkgroep 3 Technologie werkgroep 2024-07-09 13u-16u Teams Thematische werkgroep 2 Functionele werkgroep 2024-07-09 13u-16u Teamstionele werkgroep 2024-07-09 13u-16u Teams +
- Technologie werkgroep Deze thematische we … Technologie werkgroep Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur . In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix . Vaste deelnemers zijn de leden van het VLOCA-trajectconsortium en stakeholders, die samen deze noden in kaart brengen.</br> 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?</br> </br> Klik hier om je in te schrijven. Andere werkgroepen </br> 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 werkgroep 2023-04-25 13u00-16u00 Digitaal +
- Template:Documentation subpage Template:High-use Template:Caution This is a generic template for handling the horizontal alignment of elements on a page. Use the template like this: Template:Tlx +
- Template:Managed {{Draaiboek propertie … Template:Managed </br> </br> {{Draaiboek properties</br>|Abstract= <text></br>|CoCreatieAanvraag= <text> (csv)</br>|VlocaSessie= <text> (csv)</br>|Draaiboek= <text> (csv)</br>|Actoren= <text> (csv)</br>|Organisatie= <text> (csv)</br>|Organisaties= <text> (csv)</br>|Standaard= <text> (csv)</br>|Maturiteitstype= <text></br>|Status= <text></br>|SmartCityDomein= <text> (csv)</br>|SmartCityComponent= <text> (csv)</br>|Website= <text></br>|VlocaTraject= <text> (csv)</br>|SessieType= <text></br>|ArchitectuurComponent= <text> (csv)</br>|ArchitectuurBouwlaag= <text> (csv)</br>|Status= <text></br>}}text> (csv) |SessieType= <text> |ArchitectuurComponent= <text> (csv) |ArchitectuurBouwlaag= <text> (csv) |Status= <text> }} +
- Template:Managed {{Draaiboek sidebar }} $base array is defined in MediaWiki:Ws-sub-header $page array is defined in MediaWiki:Ws-sub-header +
- Template:Managed {{Initiatief sidebar }} $base array is defined in MediaWiki:Ws-sub-header $page array is defined in MediaWiki:Ws-sub-header +
- Template:Managed {{Nieuws properties |Abstract= <text> |Actoren= <text> (csv) |Website= <text> |VlocaTraject= <text> (csv) |Datum= <text> |Tijd= <text> |TypeNieuws= <text> (csv)}} +
- Template:Managed {{Nieuws sidebar }} $base array is defined in MediaWiki:Ws-sub-header $page array is defined in MediaWiki:Ws-sub-header +
- Template:Managed {{Organisatie sidebar }} $base array is defined in MediaWiki:Ws-sub-header $page array is defined in MediaWiki:Ws-sub-header +
- Template:Managed {{Project properties |Abstract= <text> |Organisatie= <text> |Organisaties= <text> (csv) |Technieken= <text> (csv) |Tags= <text> (csv) |Status= <actief, niet actief> whether or not the organization is active }} +
- Template:Managed {{Standaard propertie … Template:Managed </br> </br> {{Standaard properties</br>|Abstract= <text></br>|CoCreatieAanvraag= <text> (csv)</br>|VlocaSessie= <text> (csv)</br>|Draaiboek= <text> (csv)</br>|Actoren= <text> (csv)</br>|Organisatie= <text> (csv)</br>|Organisaties= <text> (csv)</br>|Standaard= <text> (csv)</br>|Maturiteitstype= <text></br>|Status= <text></br>|SmartCityDomein= <text> (csv)</br>|SmartCityComponent= <text> (csv)</br>|Website= <text></br>|VlocaTraject= <text> (csv)</br>|SessieType= <text></br>|ArchitectuurComponent= <text> (csv)</br>|ArchitectuurBouwlaag= <text> (csv)</br>}}ocaTraject= <text> (csv) |SessieType= <text> |ArchitectuurComponent= <text> (csv) |ArchitectuurBouwlaag= <text> (csv) }} +