Showing 20 pages using this property.
C
Pagina's die alle gebruikers kunnen aanpassen Op de kennishub vind je verschillende types pagina's terug. Volgende type pagina's zijn open voor bijdrage voor alle ingelogde gebruikers: Initiatieven : alle (smart city) initiatieven die inspireren, informeren of aanzetten tot actie Organisaties : (lokale) overheden, private spelers, burgerparticipaties, ... Standaarden : architectuurstandaarden Termen en concepten : Termen,, concepten en andere begrippen Page discussions Naast pagina's actief aanpassen, is het ook mogelijk aan de hand van page discussions vragen te stellen en feedback te geven over de inhoud van pagina's. Actieve oproep: pagina's in review Deze functie is in uitwerking. Een overzicht van pagina's die actief aangevuld en gereviewed worden door de community zal hier verschijnen. Governance De governance rond pagina's bewerken en regels rond de discussion pages vind je hier terug.  +
Class CoCreatieAanvraag with pagetitle format title Allowed namespaces: CoCreatieAanvraag Has version history: false Layout Areas : 'sub-header sidebar' 'main sidebar' Columns : 3fr 1fr Rows : auto 1fr Storage templates Base properties: Template:Base properties Page properties: Template:CoCreatieAanvraag properties Component templates Sidebar template: Template:CoCreatieAanvraag sidebar Defined parameters Name Property Slot Formfield type Allowed values Required Multiple Automatically generated template code Info Page properties template Sidebar template Open one of the tabs to view automatically generated template code. This is meant to be used when creating new templates. If you are modifying an existing template, it might still be useful to update the parameter definitions and use parts of the generated code, but be careful not to completely overwrite existing templates. Existing templates will likely have had other modifications that are not included in the automatically generated code. Template:CoCreatieAanvraag properties <noinclude> This is the '''CoCreatieAanvraag properties''' template. It should be called in the following format: <pre> {{CoCreatieAanvraag properties }} </pre> </noinclude><includeonly>{{#set: }}</includeonly> Template:CoCreatieAanvraag sidebar <noinclude> This is the '''CoCreatieAanvraag sidebar''' template. It should be called in the following format: <pre> {{CoCreatieAanvraag sidebar}} </pre> </noinclude><includeonly><!-- -->{{#vardefine:@allow sidebar edit |{{#ifingroup:user |{{#if:{{#urlget:veaction}}{{#urlget:action}}||yes}} }} }}<!-- --><div class="tab-content"><!-- -->{{#tag:_input||type=radio|id=sidebar-view|name=toggle-sidebar|checked=checked|class=d-none sidebar-view}}<!-- --><div class="card sidebar-view-tab"> <div class="card-header">{{#ifeq:{{#var:@allow sidebar edit}} |yes |<span style="float:right">{{#tag:label|Edit|for=sidebar-edit|class=btn btn-secondary}}</span>}} <b class="d-block">{{#caprint:$base[Base properties][Class]}}</b> {{#caprint:$base[Base properties][Title]}} </div><!-- end of .card-header --> <div class="card-body"> </div><!-- end of .card-body --> </div><!-- end of .card -->{{#ifeq:{{#var:@allow sidebar edit}} |yes |<!-- -->{{#tag:_input||type=radio|id=sidebar-edit|name=toggle-sidebar|class=d-none sidebar-edit}}<!-- --><div class="card sidebar-edit-tab"><!-- --><form action="addToWiki"><!-- // _edits for base properties --><!-- // _create or _edits for page properties // use casize to check if the slot already exists. Then _edit, else _create. -->{{#if:{{#casize:$class}} | |<_create mwwrite="{{FULLPAGENAME}}" mwtemplate="CoCreatieAanvraag properties" mwslot="ws-class-props" mwfields="" /> }}<!-- end of #if --> <div class="card-header"><span style="float:right">{{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}}</span> <b class="d-block">{{#caprint:$base[Base properties][Class]}}</b> {{#caprint:$base[Base properties][Title]}} </div><!-- end of .card-header --> <div class="card-body"> <div class="text-right"> {{#tag:label|Close|for=sidebar-view|class=btn btn-secondary}} <input type="submit" value="Save" class="btn btn-primary" /> </div> </div><!-- end of .card-body --> </form> </div><!-- end of .card --> |}}<!-- end of #ifeq @allow sidebar edit == yes --> </div><!-- end of .tab-content --></includeonly>  
Combimobiliteit is het gecombineerd gebruik van diverse vervoersmogelijkheden (openbaar vervoer, fiets, auto, deelmobiliteit) om de reiziger van punt A naar punt B te brengen.  +
Introductie (Waarom?) VLOCA verenigt iedereen die betrokken is bij slimme en open steden, om samen een ‘open city architectuur’ te co-creëren. Zo’n architectuur zorgt ervoor dat een toepassing die in de ene gemeente ontwikkeld wordt, ook in een andere bruikbaar is. En dat al die sensoren, platformen en applicaties probleemloos informatie kunnen uitwisselen. VLOCA wordt tastbaar gemaakt via thematische trajecten, waarvan één rond Hoppinpunten . Dit zijn fysieke plekken waar je vlot kunt overschakelen van het ene vervoersmiddel op het andere. Zo’n punt kan bijvoorbeeld aan een station of bushalte liggen en ook ruimte bieden voor deelfietsen of deelwagens. Op deze plaatsen stappen veel mensen over, daarom kunnen het goede plaatsen zijn om ook andere diensten aan te bieden zoals pakjesautomaten of laadinfrastructuur. Hoppinpunten zijn een uitstekende case voor VLOCA, omdat ze overal in Vlaanderen gerealiseerd worden, over de gemeentegrenzen heen. Bovendien moet er informatie uitgewisseld worden over welke (mobiliteits)diensten aanwezig zijn in welk punt, en wat de beschikbaarheid ervan is (bijv.: aantal vrije deelfietsen,  parkeerplekken, of de doorkomst van bussen). Enkel zo kan reizigers een naadloze overstap gegarandeerd worden. Werkwijze (Hoe?) Workshops In het kader van het Hoppin’ traject werden er een aantal workshops georganiseerd. De verslagen met bijhorende presentatie kan je vinden op de volgende pagina’s: Werkgroep Type werkgroep Datum Tijd Locatie Hoppinpunten Workshop 1: Behoeftes & doelstellingen Data en informatie werkgroep 2021-02-11 Hoppinpunten Workshop 2: Data Data en informatie werkgroep 2021-03-11 Hoppinpunten Workshop 3: Details Data en informatie werkgroep 2021-05-06 Leidende use cases Daarnaast werd tijdens het Hoppin' traject gebruik gemaakt van drie leidende use cases : Use Case 1: Evaluatie van een mobipunt ​: De UC beschrijft de actie waarbij (een medewerker van) een lokaal bestuur de werking en gebruik van een huidig mobipunt wil evalueren. Deze medewerker heeft nood aan data om, aan de hand van statistische analyses, nieuwe diensten en verbeteracties te formuleren. Mogelijke gegevens zijn:​ Gebruik van blue bikes en deelfietsen op bepaalde tijdstippen​ Aantal zoekopdrachten of financiele verrichtingen aan het mobipunt voor adhoc verplaatsingen​ Use case 2: Operator wil diensten aanbieden : Een operator wil in de buurt/aan een hoppinpunt een nieuwe dienst aanbieden voor reizigers. Om de marktanalyse grondig te kunnen uitvoeren, heeft de operator data nodig over:​ Aantal passanten​ Huidig aanbod van andere operators en substituten​ Timeseries openbaar vervoer​ Aanwezige infratstructuur en huidig aanbod​ Use case 3: Reiziger die onderweg is : Deze UC beschrijft een bewegende reiziger die onderweg is tijdens een verplaatsingstraject van punt a naar punt b.​ De reiziger heeft de volgende noden: De reiziger wil realtime inzicht over de beschikbaarheid van vervoersmodi op het hoppinpunt​ De reiziger wil proactief de reis plannen en indien mogelijk vervoersmiddel reserveren​ De reiziger wil gebruik maken van het scherm aan de hoppinzuil​ De reiziger wil onmiddellijk de betaling volbrengen ​ Resultaten (Wat?) Het beleid Hoppinpunten worden met een reden geplaatst: achter de realisatie zit de visie rond basisbereikbaarheid van de Vlaamse Overheid. Het is belangrijk om te weten wat de doelstellingen zijn, zodat zowel de realiteit als het digitale model de doelstellingen kunnen ondersteunen en helpen realiseren. Vragen zijn onder meer: Welke doelstellingen wil de overheid realiseren Wat is de beoogde doelgroep? Wat zijn beoogde (mobiliteits)diensten op zo’n Hoppinpunt? Wat is het minimumaanbod op zo’n Hoppinpunt? Wanneer is zo’n Hoppinpunt geslaagd en hoe zal het succes opgevolgd worden? Aan welke voorwaarden moeten diensten voldoen? Hoe zal het aanbod en gebruik gestimuleerd worden: bijv. subsidies of andere voordelen? Hoe kan ervoor gezorgd worden dat het aanbod over aanbieders heen consistent en vlot is? De visie en het beleid rond basisbereikbaarheid liggen vast. De visietekst is beschikbaar via deze link , en is decretaal verankerd in het Decreet Basisbereikbaarheid . De concrete materialisatie in het concept van de Hoppinpunten is nog in ontwikkeling, waardoor nog niet op al deze vragen een antwoord geformuleerd kan worden. Het is echter wel belangrijk dit scherp te hebben voor het concept uitgerold wordt (op straat en in de digitale werkelijkheid), zodat de uitvoering zo nauw mogelijk kan aansluiten bij de beleidsvisie. Draaiboek: Ik wil subsidies aanvragen voor een Hoppinpunt De werkelijkheid De Hoppinpunten zijn eerst en vooral een fysiek gegeven: infrastructuur op straat waar verschillende vervoersmiddelen gecombineerd kunnen worden. Om dit concept digitaal te beschrijven binnen VLOCA, is het noodzakelijk om een goed zicht te hebben op hoe een Hoppinpunt er in de realiteit uitziet, zodat het digitale informatiemodel de situatie in de realiteit – en alle mogelijke situaties op alle locaties – goed kan beschrijven. Die werkelijkheid wordt zichtbaar in: de infrastructuur op straat, de locatie, de aanwezige diensten, nutsvoorzieningen, de relatie met de omgeving van het punt. De infrastructuur dient zo vormgegeven te worden dat ze maximaal in staat is om de beleidsdoelstellingen te realiseren. Belangrijk hier is ook: wie zal de Hoppinpunten beheren: zowel de infrastructuur als de aanwezige diensten. Wie doet het onderhoud, maar ook: wie beslist welke diensten er aanwezig zijn, wanneer die voldoen aan de (kwaliteits)voorwaarden, wie behandelt vragen en klachten, wie zorgt voor de nodige aansluitingen etc. Draaiboek: Ik wil een nieuw Hoppinpunt aanleggen Draaiboek: Ik wil een mobiliteitsdienst toevoegen aan een Hoppinpunt Het informatiemodel en de digitale werkelijkheid De infrastructuur op straat staat niet op zichzelf. Doordat er diensten aan gekoppeld worden (doorkomsten bussen, laadpalen, deelwagens, parkeerplaatsen, ..) en er interoperabiliteit moet zijn met andere Hoppinpunten en diensten, moet er informatie uitgewisseld worden. We onderscheiden hierbij ruwweg drie niveaus.   De digitale beschrijving van de infrastructuur / statische werkelijkheid Eerst en vooral wordt er een informatiemodel gebouwd dat de infrastructuur op straat digitaal beschikbaar maakt. Het gaat dan over: de locatie van het Hoppinpunt, de afmetingen, de toegankelijkheid, de aanwezige diensten, .. Deze digitale beschrijving is nodig om een bijvoorbeeld de Hoppinpunten op te nemen in digitale kaarten of routeplanners. Daarnaast is een digitale beschrijving ook nodig om een inventaris te maken van alle Hoppinpunten en het overzicht te bewaren om zo de uitrol bijvoorbeeld te kunnen opvolgen. Hoppinpunten, of onderdelen ervan die nog gerealiseerd moeten worden, kunnen digitaal ook al omschreven worden, om de realisatie op te volgen of toekomstige mogelijkheden te communiceren aan gebruikers. Informatiemodel: Statische informatie over Hoppinpunten Artikel over Hoppinpunten & data-uitwisseling De digitale weergave van het real-time aanbod en gebruik In tweede instantie wordt best ook real-time informatie beschikbaar gemaakt: wanneer komt er een bus, hoeveel vertraging heeft die, hoeveel parkeerplaatsen zijn er vrij, is er een laadpaal beschikbaar, .. Zo kunnen gebruikers efficiënt hun reis of overstap plannen en kunnen de verschillende diensten op elkaar afgestemd worden. Deze informatie wordt typisch gebruikt door real-time multimodale routeplanners die een routekeuze geven aan de gebruiker, afhankelijk van de beschikbaarheid van vervoersmiddelen op een bepaald moment. Aan sommige Hoppinpunten is een digitale zuil geplaatst. Hier zou deze dynamische informatie bijvoorbeeld geraadpleegd kunnen worden, dit dient nog nader gedefinieerd worden binnen het Hoppin-project. Informatiemodel: Dynamische informatie Hoppinpunten Reservatie en financiële transacties van diensten Ten derde kunnen betalingen gebeuren van diensten (bus ticket, laadpalen, verzenden postpakket, gebruik deelfiets, ..) door integraties tussen verschillende partijen. Dit is bij uitstek het werkgebied van Mobility-as-a-Service oplossingen. Ook bieden sommige bankapplicaties al de mogelijkheid aan om te betalen voor diensten. Bijkomend kan ook reservatie-informatie uitgewisseld worden tussen gebruikers en mobiliteitsdiensten aan een Hoppinpunt. Zo zouden gebruikers een laadsessie of deelwagen kunnen reserveren. Dit aspect is niet behandeld in het VLOCA traject. Deelaspecten I (statische informatie) en II (dynamische info) zijn nog onvoldoende matuur en dienen eerst verduidelijkt te worden, voor er een referentie-architectuur uitgewerkt kan worden voor reservatie & betaling. Het Hoppin’ VLOCA traject als fundering van verschillende vervolgtrajecten Het co-creatietraject, de Kennishub, de use cases, de draaiboeken en referentie-architectuur hebben een solide basis gelegd voor de digitale uitwerking van Hoppinpunten. Deze zaken worden verder uitgewerkt in de volgende trajecten: OSLO traject Hoppinpunten OSLO Applicatieprofiel Hoppinpunten OSLO Vocabularium Hoppinpunten Het Hoppinproject van de Vlaamse Overheid binnen het programma Basisbereikbaarheid, inclusief een subsidietraject voor steden en gemeenten De Mobiliteitscentrale De Data Integratie diensten voor Mobiliteit traject van Digitaal Vlaanderen Het Greenmov project van Digitaal Vlaanderen en imec Het AWV OTL project  
This is the image belonging to page Combimobiliteit- Hoppin punten  +
Summary 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. Scope 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: Increase ANSPs efficiency Lower charges Increase technology uptake Decrease fragmentation (for some options) Domains In order to assess their potential contribution to the European Single European Sky objectives. The project had the following goals: Propose a set of new institutional market designs for the introduction of competition in the European ATM sector; Define a framework allowing a comprehensive assessment of the impact of different institutional market designs; Develop a variety of economic and network simulation models allowing the assessment of the proposed approaches; Assess the feasibility and acceptability of proposed institutional changes for various market actors; Propose a vision for the implementation of the most desirable institutional structures. To achieve the overall objectives, the project focused on four potential ways to introduce competitive elements in the ATM sector: Performance regulation with variations in ownership and governance models Unbundling Tender of licenses for en-route air traffic services Flight centric, sector-less operations Partners 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. 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. 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 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.  
Componenten   ArchitectuurComponent API gateway Asset Registry Context Broker Data Analytics Data Catalog Data Lake(house) Data broker Firewall IAM service InfluxDB IoT agent Message buffer Postgres Semi structured data Sensor Solid Timescale Postgres  +
Manier om data analyse processen te structureren  +
Voorbeeld 2 configuratie file data analyse  +
How to connect sensors today  +
Consolidatie MOSCOW ANALYSE  +
De Context Broker is de centrale softwarecomponent van FIWARE en een verplicht onderdeel van elk" Powered by FIWARE "-platform of -oplossing. Het is ook een van de Componenten van de CEF (Connecting Europe Facility) [1] De Context Broker bewaart en beheert context informatie op een gedecentraliseerde en grootschalige manier. De informatie is gecodeerd met NGSI , ofwel de V2-versie van de huidige gestandaardiseerde NGSI-LD . De context broker gebruikt het HTTPS protocol voor de verzending van NGSI-berichten. Een aantal implementaties wordt door FIWARE beschouwd als FIWARE Generic Enablers . Dit zijn: Orion Context Broker [1] (NGSI-v2) Orion-LD Context Broker [2] (NGSI-LD) Scorpio Broker [3] (NGSI-LD) Stellio Context Broker [4] (NGSI-LD) Naast de FIWARE-enablers zijn er ook andere implementaties (zie github ). ↑ https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Context+Broker  +
Een door FIWARE geïntroduceerd sleutelbegrip is het begrip context informatie. In het algemeen is context de informatie rond de informatie. Zonder context is de informatie moeilijk, zo niet onmogelijk te begrijpen. Voor slimme steden zijn veel voorkomende voorbeelden van context de informatie aangaande: tijd ; wanneer is de informatie gemaakt; plaats ; waar is de informatie gecreëerd. Deze context maakt het mogelijk metingen te relateren aan echte gebeurtenissen en aan andere metingen. Een voorbeeld hiervan is verkeersinformatie: de tijd en locatie van b.v. een file, maakt het mogelijk om dit te relateren aan een evenement (bijv. voetbalwedstrijd). Context Management is een Minimum Interop Mechanism geworden binnen de aanbevelingen van Open_And_Agile_Smart_Cities Functionaliteit voor de opslag van context informatie in een Context Broker is daarom de basis van OASC compliant implemenaties.  +
Database en context broker naast elkaar  +