Definitiestudie. Crisiscommunicatie. Versie 1.0. Datum 2 december 2010

Definitiestudie Crisiscommunicatie

Versie 1.0

Datum Status

2 december 2010 Definitief

Colofon

IVENT A&A CDC Madame Curielaan 4-6 Postbus 20703 2289 CA Rijswijk Contactpersoon

Patrick Brooijmans Teamleider functionele integratie i-Bridge2.0 M +31 6 51313575 [email protected]

Versie Opdrachtgever Auteur(s) Projecten

1.0 R. van Bladel P. Brooijmans i-Bridge2.0

Pagina 2 van 21

Inhoud Colofon .............................................................................................................2 1. Inleiding ......................................................................................................4 2. Procesbeschrijving .......................................................................................5 2.1 Huidige gang van zaken ................................................................................ 5 2.2 Huidige informatie vorm ................................................................................ 5 2.3 Doelgroep van de informatie ........................................................................... 6 3. Functionele wensen en eisen ...........................................................................8 3.1 Functionele eisen ........................................................................................ 8 3.2 Toelichting op de functionele eisen ................................................................... 8 4. Globaal functioneel ontwerp ............................................................................9 4.1 Uitgangspunten .......................................................................................... 9 4.2 Functioneel ontwerp ..................................................................................... 9 5. Globaal technisch ontwerp............................................................................14 5.1 Randvoorwaarden.................................................................................. 14 5.2 Architectuur ......................................................................................... 15 5.3 Software versies .................................................................................... 16 5.4 Gebruikersportaal .................................................................................. 16 5.5 Beheerdersportaal ................................................................................. 17 6. Relaties met andere projecten ........................................................................21 6.1 NCC ...................................................................................................... 21 6.2 Burgernet................................................................................................ 21 6.3 CivilNEC................................................................................................. 21

Pagina 3 van 21

1.

Inleiding

Crisiscommunicatie is een aspect dat steeds belangrijker wordt. Voorbeelden zijn de website www.crisis.nl of de studies naar cell broadcasting als vervanger van het bestaande Waarschuwings- en Alarmering Systeem (WAS). Burgers zijn gewend om in hun dagelijks leven geografische informatie te gebruiken (denk aan het gebruik van navigatiesystemen of Google Earth). Tijdens de rampenbestrijdingsoefening Eagle One (maart 2008) is gekeken of het gebruik van Virtual Earth in combinatie met Cyclorama's (360 graden foto's) een toegevoegde waarde kon bieden in crisiscommunicatie. In i-Bridge 2.0 timebox 3 wordt nader onderzocht wat de mogelijkheden zijn op functioneel en technisch vlak om sleutelfunctionarissen betrokken bij de rampenbestrijding, burgers en media te informeren ondersteund door geografie. In dit onderzoek wordt ook gekeken naar de mogelijkheden tot integratie met bestaande websites (o.a. www.crisis.nl). In deze definitiestudie wordt de basis gelegd voor de functionaliteit crisiscommunicatie. In gesprekken met betrokken functionarissen van Hulpverlening Gelderland-Midden zijn de onderliggende werkprocessen en de functionele wensen en eisen voor de functionaliteit vastgelegd. In deze definitiestudie wordt tevens een globaal functioneel ontwerp gepresenteerd.

Pagina 4 van 21

2. 2.1

Procesbeschrijving

Huidige gang van zaken

Grip 1 situatie Bij een klein incident is de informatiemanager van het COPI verantwoordelijk voor de communicatie naar buiten toe. De informatiemanager staat de pers te woord, maar schrijft geen persberichten en plaatst geen berichten op websites. De informatie die naar buiten wordt gebracht is niet geverifieerd door een bestuurlijke functionaris. Grip 2 situatie Bij opschaling wordt de verantwoordelijkheid voor communicatie van de Informatiemanager in het CoPI overgedragen aan het actiecentrum voorlichting in het ROT. De informatievoorziening wordt vanuit het actiecentrum gecoördineerd. De gemeente is nu verantwoordelijk voor het proces voorlichting. Dit betekent onder andere dat informatie altijd op bestuurlijk niveau geverifieerd moet worden. Het actiecentrum voorlichting zorgt voor de informatievoorziening aan pers en burger. Bij verdere escalatie heeft de gemeente de mogelijkheid om situationele informatie voor het grote publiek te plaatsen op de website www.crisis.nl van de overheid. Daarnaast kan de gemeente de lokale rampenzender op radio en televisie inschakelen. Ook hier ligt de verantwoordelijkheid van informatievoorziening bij de gemeente. De burgemeester is verantwoordelijk voor de informatie die naar buiten gebracht wordt. De webredacteur van de gemeente die informatie aan www.crisis.nl gaat toevoegen zit fysiek in het gemeentehuis en niet in het actiecentrum voorlichting van het ROT. Bij verdere opschaling naar regionaal niveau zou de webredacteur plaats moeten nemen in het Regionaal actiecentrum. Daar zijn echter op dit moment nog geen afspraken over gemaakt. In de huidige situatie blijft de webredacteur fysiek op het gemeentehuis. 2.2

Huidige informatie vorm

Geschreven tekst en telefoon De sectie voorlichting van de regio houdt zich voornamelijk bezig met het beantwoorden van telefonische vragen en het schrijven van persberichten. Deze telefonische voorlichting is voor zowel burger als pers. Wanneer het erg druk wordt ontstaat er een onderscheid in informatie bestemd voor de burger en informatie voor de pers. Deze scheiding zal in dit document in stand gehouden worden. In geen geval wordt in de huidige situatie gebruik gemaakt van een kaartbeeld bij de tekstuele of mondeling overgedragen informatie. Web In het geval dat er een website wordt gebruikt voor het plaatsen van crisisinformatie, wordt deze voorzien van tekstuele informatie met evt. een plaatje. Deze informatie is door de burgemeester geverifieerd. De berichten hebben als doel de burger van informatie te voorzien over hoe te handelen. Zelden wordt er een kaartje bij gegeven waaruit bijvoorbeeld de locatie van opvang of evacuatieroutes blijkt. Radio en televisie Via de regionale rampenzender op de radio wordt vanzelfsprekend alleen tekstuele informatie verstrekt. Dit medium zal daarom in deze POC buiten beschouwing worden gelaten

Pagina 5 van 21

Ook de informatievoorziening via de televisie wordt in deze POC buiten beschouwing gelaten, aangezien de televisie geen andere informatie ter beschikking heeft dan al via telefoon, pers en web verspreid is. Er is in Gelderland Midden in het verleden wel een ruimte opgezet in het gemeentehuis van waaruit de burgemeester direct informatie kon verspreiden via de televisie. Deze ruimte is echter niet meer in gebruik. In de POC wordt vooral gefocust op de wijze waarop de informatie het publiek zal bereiken en welke tools de hulpverleners ter beschikking moeten hebben om dit te bewerkstelligen. Daarnaast zal gekeken worden hoe de juiste informatie vervolgens bij de juiste doelgroep terecht zal komen. Hoe deze informatie na publicatie verder gebruikt wordt is geen onderdeel van de POC. Om die reden zal radio en televisie buiten beschouwing worden gelaten. Dat betekent niet dat deze media niet belangrijk is voor de crisiscommunicatie. Radio en TV zullen altijd beschikbaar moeten blijven voor de mensen die geen beschikking hebben over een internet verbinding, die geen kennis hebben van het medium internet of bij uitval van het internet. 2.3

Doelgroep van de informatie

Momenteel voorziet het actiecentrum voorlichting zowel de burger als pers van informatie. Het ligt dan ook voor de hand dat het actiecentrum de scheiding in de verschillende informatiestromen gaat maken. In deze POC worden een 3-tal informatiestromen onderscheiden: 1. Informatie voor deelnemers aan het incident 2. Informatie voor professionals die geen operationele informatie behoeven 3. Informatie voor publiek en pers 1.

De deelnemers aan het incident willen alle mogelijke informatie krijgen. In de meeste gevallen zullen deze deelnemers de beschikking hebben over i-Bridge CMS en hebben dus de beschikking over de meest recente incident informatie. Wanneer er echter geen beschikking is over i-Bridge CMS moet toch alle incident informatie beschikbaar zijn. Hierbij kan worden gedacht aan een kaartbeeld met alle incident informatie in de kaart en het meest recente totaalbeeld.

2.

Bij betrokken professionals die geen operationele informatie behoeven kan gedacht worden aan instanties die wel te maken hebben met de incident bestrijding, maar geen behoefte, noodzaak of rechten hebben te weten waar bijvoorbeeld iedereen exact met de voertuigen staat. Bij dergelijke instanties wordt gedacht aan waterschappen, nutsbedrijven, netwerkbeheerders, vervoerders etc. Incident informatie is belangrijk, maar niet in te groot detail.

3.

De informatie voor het publiek dient te bestaan uit informatie over wat te doen of waar naartoe te gaan. Gedetailleerde incident informatie is niet nodig en/of toegestaan. Wel moeten de volgende zaken duidelijk naar voren komen in de publieksinformatie: (a) Welk gebied zal worden ontruimd (b) Waar zijn de opvangplaatsen te vinden (c) Wat zijn de te nemen vluchtroutes om het getroffen gebied uit te komen (d) Wat zijn de omleidingsroutes om het getroffen gebied te omzeilen De genoemde informatie moet zowel uit het tekstbeeld en uit het kaartbeeld naar voren komen.

De publieksinformatie staat vaak al in grote lijnen vast in rampen- en ontruimingsplannen. Zodra het te ontruimen gebied bekend is kan zonder verificatieslag de vluchtroutes of omleidingsroutes door een daartoe bevoegd(e) perso(o)n(en) geplaatst worden. De bevoegde personen moeten met een beperkt aantal tussenstappen gegevens uit i-Bridge CMS kunnen halen en deze naar de webomgeving kunnen publiceren.

Pagina 6 van 21

Een idee voor de POC is om foto beelden te koppelen aan de locaties in de kaart zodat het publiek ook een beeld krijgt bij datgene wat in de kaart en in tekst staat weergegeven

Pagina 7 van 21

3.

Functionele wensen en eisen

3.1

Functionele eisen

-

3.2

Makkelijke selectie van te publiceren objecten en informatie items Publieksvoorlichting portaal bestaat uit een tekst en een geografisch deel De informatie komt zoveel mogelijk uit dezelfde bron Publicatie van informatie op verschillende toegankelijkheidsniveaus: o Informatie direct uit i-Bridge CMS o Crisisinformatie relevant voor betrokken professionals en instanties o Publieksvoorlichting Beveiliging mogelijk voor de hoogste niveaus van informatie Unieke beveiliging per incident Op verschillende plaatsen de informatie uit de bron naar het web kunnen overzetten Koppeling behouden tussen tekst en locatie(s) in het kaartbeeld Koppelen van afbeeldingen aan een locatie in de kaart Toelichting op de functionele eisen

Het moet mogelijk zijn om op eenvoudig wijze de informatie op de website te plaatsen. Daarmee moet het plaatsen van informatie zoveel mogelijk geautomatiseerd verlopen. Het ligt voor de hand dat het actiecentrum voorlichting de mogelijkheid krijgt de informatie te publiceren voor de verschillende doelgroepen. Het moet overigens wel mogelijk zijn van meerdere werkplekken/clients informatie aan de webpagina toe te voegen. Vanaf één werkplek de teksten publiceren lijkt niet werkbaar. Gescheiden informatiestromen Er moeten verschillende niveaus van toegang tot de informatie komen voor de te configureren gebruikersgroepen. Dit houdt in dat het mogelijk moet zijn dat iedere doelgroep de informatie ontvangt die voor hem/haar bestemd is. Een burger moet zonder inloggen meteen de informatie krijgen die voor het grote publiek relevant is. Een hulpverlener of betrokken instantie bij de rampenbestrijding moet meer gedetailleerde informatie ontvangen, maar deze informatie moet afgeschermd zijn voor het publiek. Koppeling tussen tekst en kaartbeeld Het is wenselijk om de koppeling tussen tekst en kaartbeeld te behouden. Wanneer een gebruiker op de tekst klikt of met de muis er overheen gaat, licht het bijbehorende kaart ico(o)n(en) op. De werking hiervan wordt uitgewerkt in de “POC integratie tekst plot” die parallel aan deze POC crisiscommunicatie loopt. Alle gegevens in een bron Het uitgangspunt is dat alle incident informatie vanuit dezelfde bron ontsloten wordt. Om de informatie voor verschillende doelgroepen te scheiden wordt slechts een categorisering aan de bestaande gegevens toegevoegd. Op die manier wordt het proces zoveel mogelijk geautomatiseerd. Verificatie Sommige informatie mag meteen worden gepubliceerd, maar informatie bestemd voor het publiek moet veelal geverifieerd worden door de burgermeester. Er moet een workflow zijn waarin het mogelijk is informatie klaar te zetten voor verificatie zodat deze met een druk op de knop gepubliceerd kan worden na goedkeuring.

Pagina 8 van 21

4.

4.1

Globaal functioneel ontwerp

Uitgangspunten

Voor het globaal functioneel ontwerp wordt uitgegaan van de huidige suite aan applicaties die al ontwikkeld zijn binnen het project i-Bridge 2.0 timebox 1 en timebox 2. De te ontwikkelen functionaliteit moet technisch samensmelten met de aanwezige componenten of er een integraal onderdeel van vormen. 4.2 Functioneel ontwerp Op UML gebaseerd Use Case diagram

Pagina 9 van 21

Use Case Code Use Case Naam Doel c.q. korte omschrijving Preconditie

0 Systeem om crisisinformatie te publiceren Het systeem moet informatie uit een bron kunnen publiceren voor verschillende gebruikersgroepen naar een webomgeving. Incident informatie op een bronlocatie Beschikking tot een webserver waarop informatie geplaatst kan worden Informatie voor 3 verschillende gebruikersgroepen gepubliceerd via het web in tekst en kaartbeeld. Voor 2 van de gebruikersgroepen is de informatie beschermd achter een wachtwoord of dergelijk mechanisme Informatie beheerder (vanuit het actiecentrum voorlichting)

Eindconditie

Primary actors Secondary actors Basic Flow of Events (stappen)

1. 2. 3. 4. 5. 6. 7. 8.

Alternative flows Opmerkingen

Toegang tot beheer omgeving Configureren van gebruikersgroepen en rechten Plot informatie uit de bron selecteren Publiceren van de tekstuele informatie Verifiëren van geselecteerde informatie Publiek bereikbare webinterface Beschermde webinterface Attendering voor geplaatste informatie

Zie MoSCoW lijst voor prioritering

Usecase 1: Toegang tot beheer omgeving Use Case Code 1 Use Case Naam Toegang tot beheer omgeving Doel c.q. korte omschrijving Preconditie Eindconditie Primary actors Secondary actors Basic Flow of Events (stappen) Alternative flows

De beheerder moet toegang hebben tot de beheeromgeving waarin teksten en kaartobjecten geselecteerd en gepubliceerd kunnen worden. Een beheer omgeving en een beheerder (of meerdere beheerders) die kunnende beheer omgeving kunnen bereiken. Een ingelogde beheerder 1.1 Een beheerder opent de beheer omgeving 1.2 De beheerder logt in om toegang te krjjgen tot de beheeromgeving 1.3 De beheerder geeft aan met welk incident er gewerkt gaat worden en dus welk incident voor de gebruikersgroepen toegankelijk moet zijn. 1.2 De beheerder krijgt automatisch toegang op basis van zijn locatie of gebruikte pc (gebruik van Active Directory of LDAP).

Opmerkingen Usecase 2: Configureren van gebruikersgroepen en rechten Use Case Code 2 Use Case Naam Configureren van gebruikersgroepen en rechten Doel c.q. korte De beheerder kan per incident gebruikersgroepen aanmaken en aangeven welke omschrijving rechten deze gebruikersgroepen hebben Preconditie Beheeromgeving en gedefinieerde gebruikersgroepen. Eindconditie Gedefinieerde gebruikersgroepen Primary actors Beheerder Secondary actors 2.1 De beheerder definieert hoeveel gebruikersgroepen er zijn en hoe ze heten Basic Flow of 2.2 De beheerder geeft aan welke veiligheidsniveaus gelden per gebruikersgroep Events (stappen) Pagina 10 van 21

2.3 De beheerder geeft aan welke tekstbeelden door welke gebruikersgroep gezien mogen worden 2.4 De beheerder geeft aan welke gebruikersgroepen geattendeerd moeten worden wanneer nieuwe informatie beschikbaar wordt gesteld 2.5 De beheerder geeft aan welke gebruikersgroepen het logboek mogen inzien Alternative flows Opmerkingen Usecase 3: Plot informatie uit de bron selecteren Use Case Code 3 Use Case Naam Plot informatie uit de bron selecteren Doel c.q. korte De beheerder geeft van de te publiceren plot features met welk beveiligingsniveau ze omschrijving gepubliceerd moeten worden. Daarbij is het hoogste beveiligingsniveau de standaard welke vervolgens voor de lager geldende niveaus gewijzigd kan worden Preconditie Plot features in een database. Gedefinieerde beveiligingsniveaus in de beheeromgeving Eindconditie Features met aangepaste beveiligingsniveaus klaar voor publicatie Primary actors Beheerder Secondary actors 3.1 De beheerder bekijkt de meest recent geplaatste items in de kaart Basic Flow of 3.2 De beheerder selecteert een aan te passen item in de kaart Events (stappen) 3.3 De beheerder selecteert het gewenste beveiligingsniveau voor het geselecteerde item 3.4 Het aangepaste item wordt opgeslagen Alternative flows 3.4 Het aangepaste item wordt klaargezet voor verificatie Opmerkingen De plot items voor het hoogste beveiligingsniveau kunnen direct gepubliceerd worden zonder verificatie Usecase 4: Publiceren van tekstuele informatie Use Case Code 4 Use Case Naam Publiceren van tekstuele informatie Doel c.q. korte De huidige beelden uit i-Bridge tekst en nieuwe tekstbeelden voor de voorgedefinieerde omschrijving gebruikersgroepen worden geschreven en gepubliceerd via de webomgeving Preconditie Gedefinieerde tesktbeelden. Bekende gebruikersniveaus voor de verschillende tekstbeelden Eindconditie Verschillende tekstbeelden klaar voor publicatie voor de verschillende gebruikersgroepen Primary actors Beheerder Secondary actors 4.1 Behalve de standaard tekstbeelden (meldkamerbeeld, CoPI beeld, Totaalbeeld) Basic Flow of worden er nu ook gebruikersgroep specifieke beelden aangeleverd Events (stappen) 4.2 De aangeleverde tekstbeelden worden klaargezet voor verificatie Alternative flows 4.2 De aangeleverde tekstbeelden worden direct gepubliceerd Opmerkingen De teksten voor het hoogste beveiligingsniveau kunnen direct gepubliceerd worden zonder verificatie Usecase 5: Verifiëren van geselecteerde informatie Use Case Code 5 Use Case Naam Verifiëren van geselecteerde informatie Doel c.q. korte De klaargezette tekstuele en plot informatie op de lagere beveiligingsniveaus worden omschrijving klaargezet ter verificatie. Een beheerder of burgemeester kan deze informatie verifiëren en publiceren. Preconditie Klaarstaande tekstbeelden en plot items. Eindconditie Gepubliceerde informatie voor de verschillende doelgroepen Primary actors Burgermeester of ander gemachtigd persoon (Beheerdersfunctie) Secondary actors Pagina 11 van 21

Basic Flow of Events (stappen) Alternative flows Opmerkingen

5.1 De klaargezette informatie kan gelezen en aangepast worden 5.2 De geverifieerde informatie wordt gepubliceerd Eventuele koppelingen tussen tekst en plotbeeld worden behouden.

Usecase 6: Publiek bereikbare web-interface Use Case Code 6 Use Case Naam Publiek bereikbare web-interface Doel c.q. korte Op de publiek bereikbare webpagina staat een geverifieerd tekstbeeld en kaartbeeld omschrijving klaar. Preconditie Gepubliceerde tekst en kaart informatie voor het grote publiek Eindconditie Een webpagina met publieke tekst en kaart informatie Primary actors Gebruiker Secondary actors Basic Flow of 6.1 Een publieke gebruiker typt het url adres in zijn internetbrowser om naar de Events (stappen) publiekelijk bereikbare website te komen 6.2 De publieke gebruiker kan een incident selecteren waarvan vervolgens de publiek toegankelijke tekst en plot gegevens getoond worden 6.3 De gebruiker kan een help functie openen om hulp te krijgen bij het gebruik van het publieke portaal Alternative flows Opmerkingen Het tekst en kaartbeeld moeten corresponderen en informatie weergeven die op elkaar afgestemd is. Dus geen ouder kaartbeeld bij een nieuw tekstbeeld Usecase 7: Beschermde web-interface Use Case Code 7 Use Case Naam Beschermde web-interface Doel c.q. korte Op de beschermde webinterface kunnen alle niet publieke gebruikersgroepen de omschrijving informatie raadplegen. Per gebruikersgroep is een aparte login vereist. Preconditie Geverifieerde en niet-geverifieerde informatie (alleen voor het hoogste beveiligingsniveau) gepubliceerd vanuit de beheeromgeving Eindconditie Een of meerdere webpagina’s beschermd achter een login procedure. Per gebruikersgroep is een aparte login vereist Primary actors Niet publieke gebruiker Secondary actors 7.1 De gebruiker krijgt een url en login waarmee de website bereikt kan worden Basic Flow of aangeleverde tekstbeelden worden klaargezet voor verificatie Events (stappen) 7.2 De gebruiker logt in en krijgt alle voor hem bestemde informatie te zien Alternative flows Opmerkingen Deze login moet per incident wijzigen om te voorkomen dat iedereen die ooit een login heeft ontvangen altijd kan inloggen. Usecase 8: Attendering voor geplaatste informatie Use Case Code 8 Use Case Naam Attendering voor geplaatste informatie Doel c.q. korte Wanneer nieuwe tekstbeelden gepubliceerd zijn krijgen de leden van de omschrijving gebruikersgroepen een sms bericht om ze te wijzen op de aanwezigheid van nieuwe informatie Preconditie Telefoonnummers en beveiligingsniveau per gebruiker bekend Eindconditie Geattendeerde gebruiker Primary actors Beheerder / Systeem Secondary actors 8.1 De beheerder configureert de attenderingsservice per SMS. Wie krijgt wanneer een Basic Flow of SMS. Events (stappen) 8.2 Wanneer er een nieuw tekst of kaartbeeld voor een bepaalde of meerdere Pagina 12 van 21

doelgroepen wordt gepubliceerd krijgt deze gebruiker of gebruikersgroep een SMS bericht ter attendering. Alternative flows Opmerkingen

De attendering is per type gedeeld beeld.

Pagina 13 van 21

5.

Globaal technisch ontwerp

Het globaal technisch Ontwerp bevat de technische beschrijving voor de implementatie van functionele eisen zoals beschreven in hoofdstuk 3. De technische beschrijving vindt slechts plaats op globaal niveau. Tijdens het ontwikkel traject worden de details ingevuld. De ontwikkelwerkzaamheden bestaan uit de volgende hoofdonderdelen:

1. Het bouwen van een gebruikers portaal 2. Het bouwen van een beheerders portaal Deze hoofdonderdelen worden in meer detail beschreven in resp. par. 5.4 en 5.5. 5.1

Randvoorwaarden

Bij het technisch ontwerp is er vanuit gegaan dat het gebruikersportaal en evt. beheerdersportaal gevuld wordt met bestaande incident informatie gegenereerd door het I-bridge CMS systeem. De bestaande I-Bridge CMS componenten zorgen voor de aanvoer van incident en gebruikers informatie. Het technisch ontwerp beschrijft de componenten die ontwikkeld moeten worden om deze bestaande incident informatie op de juiste wijze te presenteren aan de gebruikers, zoals beschreven in de functionele eisen in paragraaf 3.1. De Layout van het gebruikersportaal en beheerdersportaal is nog niet vastgelegd. Wel staat ongeveer vast welke componenten op de web-pagina’s voor moeten komen. De schermindelingen die later in dit hoofstuk worden weergegeven worden zijn slechts een indicatie van hoe de uiteindelijke portalen er uit komen te zien. Kleur, lettertype, en indeling zullen nog wijzingen tijdens het ontwikkel proces.

Pagina 14 van 21

5.2

Architectuur Beschrijving architectuur (van onder naar boven in het diagram):

6

5

4

3

2

1

Browser - Silverlight

ArcGIS Server - MapService

ArcMap - QueryLayers

SQLServer - Arcgis views - Eagle tabellen

Ping

Groove

1. In Groove wordt alle I-Bridge CMS incident informatie opgeslagen 2. De Ping converter vangt de wijzigingen binnen een incident vanuit Groove en stuurt de updates naar een SQLServer database. 3. In de database zijn 2 schema’s: o Het I-Bridge schema bevat de CMS objecten die door Ping worden bijgewerkt. Het I-Bridge schema bevat een historie mechanisme waardoor het mogelijk is om wijzigingen door de tijd heen te bevragen. o Het Arcgis schema bevat alleen views op de I-Bridge tabellen. In de views worden attribuutwaarden uit het genormaliseerde I-Bridge schema “plat” gemaakt in het ArcGIS schema. 4. Een ArcMap map document verwijst naar de database via zgn. Query Layers (nieuw in ArcGIS10). o Een Query Layer heft een directe verbinding naar het ArcGIS schema in de database middels query definities. o Het voordeel van deze aanpak is dat de tussenlaag ArcSDE, een database interface laag zoals in eerdere versies van ArcGIS noodzakelijk was, nu kan worden weg gelaten. Dit maakt de architectuur een heel stuk lichter en eenvoudiger te beheren. 5. In ArcGIS Server wordt een mapservice gemaakt op basis van het mapdocument. o Later wordt uitgelegd dat er in feite meerdere mapservices (op basis van ieder hun eigen mapdocument) worden gepubliceerd. 6. De mapservice wordt in een Silverlight client-applicatie gebruikt middels de ArcGIS Web API voor Silverlight. o De Silverlight applicatie is het onderdeel van het systeem waarvoor de meeste ontwikkelinspanning nodig is. o De overige onderdelen behoeven geen ontwikkelinginspanning maar moeten worden geconfigureerd. o In vergelijking met de Silverlight applicatie zoals die in de eerdere versie van de I-BridgeLiveViewer werd gebruikt, zijn de volgende verschillen te melden:  Graphics rendering (symbologie, kleur, etc.) van incodent objecten vindt plaats in de client applicatie en niet in ArcMap. De incident objecten moeten per incident sowieso van de server naar de client worden getransporteerd t.b.v. maptips, attributen raadplegen, linken met tekst elementen in rtf beelden, etc.  Omdat de incident objecten toch al op de client aanwezig zijn, voegt het renderen op de client geen noemenswaardig performance verlies op.  De render details zijn opgenomen in een configuratie bestand op de server dat door de client bij het opstarten van de applicatie wordt uitgelezen.  De eigenlijke rendering vindt plaats m.b.v. UniqueValue renderers uit de ArcGIS API voor Silverlight.  Alle render logica wordt opgenomen in de XAML declaraties op de client en niet in C# code.

Pagina 15 van 21

5.3 Software versies Voor de ontwikkeling worden de volgende versies van software pakketten gebruikt:

-

-

-

-

ArcGIS10 Beta (Desktop en Server) o De nieuwste versie van ArcGIS is vereist om gebruik te kunnen maken van zgn Query Layers in ArcGIS Desktop en Feature Layers in ArcGIS Server. ArcGIS Web API voor Silverlight 2.0 o De laatste versie van de SIlverlight API ondersteunt de nieuwe functionaliteiten in SIlverlight 4. Visual Studio 2010, Silverlight 4 o Silverlight 4 heeft standaard voorzieningen voor:  RIA services (authentication, eenvoudig data beheer in SQL Server)  Richt Text Format control o In Silverlight 3 moest veel extra worden geprogrammeerd voor de gewenste functionaliteit voor autenticeren en databeheer. Microsoft SQLServer 2008 SP1 o Nodig voor de ondersteuning van Geometry en Geography in de database.

5.4 Gebruikersportaal Het gebruikersportaal zal gebouwd worden in Silverlight van Microsoft. Bij het openen van de web pagina wordt in de silverlight client op de pagina het volgende beeld getoond. Het gaat slechts om een heel grove weergave. Indeling, kleur, font, etc. zal nog wijzigen.

De weergegeven elementen in de afbeelding hebben de volgende betekenissen en functies: Pagina 16 van 21

Publieke Modus

-

-

Initieel start de viewer op in “publiek” mode De pagina bevat een titel balk met logo en algemene help voor het gebruik van het portaal In de keuze lijst met incidenten kan de gebruiker een keus maken. Alleen de incidenten waartoe de rol publiek toegang heeft worden getoond in de keuzelijst. Na een incident te hebben gekozen worden de bijbehorende incident objecten in de kaart getoond. Let op: alleen die objecten waartoe de rol publiek toegang heeft. Eventuele bijbehorende tekstbeelden (ook alleen die waartoe de rol publiek toegang heeft) zijn in te zien via tabbladen met tekstbeelden. De incident objecten worden niet alleen in de kaart getoond maar ook in een treeview aan de rechterkant van de kaart. Door op een incident object te klikken verplaatst/zoomt de kaart naar het betreffende object.

Niet publieke modus - Via de login knop wordt het login scherm getoond. Een gebruiker met naam en wachtwoord kan zich aanmelden. Afhankelijk van de rol(len) van de gebruiker krijgt de gebruiker meer rechten dan de publieksrol. M.a.w. bij het verversen van de kaart of het kiezen van een ander incident kunnen meer objecten op de kaart worden getoond dan in de publieksrol. - Een bijzonder rol is “beheerders”. Indien een gebruiker lid is van die rol dan verandert het scherm drastisch. Een nieuwe pagina (beheerders pagina) wordt getoond met de mogelijkheid om toegangsrechten op incidenten en incident objecten te beheren. Deze beheerderspagina wordt in de volgende paragraaf in meer detail beschreven. Samengevat bestaan de functies in het gebruikers portaal uit de volgende onderdelen:

1. Initieel inloggen als publieks groep zonder dat de gebruiker expliciet moet inloggen (use case 6.1) 2. De gebruiker kan een incident kiezen (Use case 6.2) 3. De incident objecten worden opgehaald uit de database en vervolgens op de kaart getekend (use case 3) 4. In de database wordt gebruik gemaakt van zgn. Row Level Security. Dit mechanisme zorgt ervoor dat een database gebruiker alleen die objecten terug krijgt waar hij genoeg toegangsrechten toe heeft. Ieder incident object in de database heeft een extra kenmerk met dat toegangsrecht. (use case 3.3) 5. Toegangsrechten voor incident objecten worden beheerd in een beheerpagina die onderdeel is van deze applicatie. (use case 7) 6. De kaart objecten tonen een maptip wanneer de muis cursor er over heen beweegt 7. Van bepaalde objecten kunnen attribuutwaarden als label in de kaart worden afgebeeld. In te stellen via configuratie. 8. De rendering informatie voor de incident objecten komt uit een config bestand op de server. De objecten worden in de client applicatie gerenderd. 9. Nadat een incident is geselecteerd en de kaart is gevuld met incident objecten wordt na een te configureren interval de kaart ververst. Alle incident objecten van het geselecteerde incident worden dan weer vande server opgehaald. 10. Het ophalen van incident objecten gebeurt alleen bij het selecteren van een incident en bij het automatisch verversen van de kaart. Tijdens pannen/zoomen worden geen incident objecten opgehaald. 5.5 Beheerdersportaal Het beheerdersportaal is bedoeld voor de rol beheerder, die de mogelijkheid moet hebben te bepalen welke gebruikersgroepen er zijn en welke informatie zij mogen zien. Het beheerdersportaal is bereikbaar via de login op het publieksportaal.

Pagina 17 van 21

Ook voor het beheerdersportaal geldt dat de hier weergegeven afbeelding slechts een indicatie is van hoe het portaal er uiteindelijk uit komt te zien. De afbeelding is slechts een weergave van de aanwezige componenten in het beheerdersportaal.

Het Ping proces zorgt voor het updaten van de database vanuit de Groove synchronisatie. Als een incident object initieel wordt toegevoegd in de database dan krijgt het object de “beheerder” toegangsrechten. Een gebruiker met publieksrol kan zo’n object dus niet bekijken. Een gebruiker uit de rol “beheerders” moet eerst inloggen en via de functie “beheren toegangsrechten” de objecten uit een incident voorzien van de juiste toegangsrechten. Pas daarna kan een gebruiker met voldoende rechten de objecten zien in de kaart. Inloggen gebeurt middels autenticatie op een user store die door de beheerder kan worden bijgehouden. Als user store kan worden gekozen voor Windows Authentication (active directory, ldap, etc.) of Forms Authentication (user store in een aparte SQLServer Express database als onderdeel van de website). Voor gebruik via internet heeft de Forms Authentication de voorkeur. Voor gebruik via intranet kan ook Windows Authentication worden gebruikt. In eerste instantie worden de volgende rollen onderscheiden:

-

Beheerders Deelnemers Hulpverleners Publiek.

Het beheren van de user store met namen, wachtwoorden en rollen valt buiten de scope van deze applicatie. Beheer van de user store vindt plaats met de standaard daarvoor beschikbare applicaties.

Pagina 18 van 21

De weergegeven elementen in de afbeelding hebben de volgende betekenissen en functies: - De beheerder is ingelogd in de rol Beheerders - De beheerder kan uit alle aanwezige Incidenten kiezen - Na het kiezen van een incident worden alle incident objecten in de kaart getoond. Tevens worden de objecten getoond in de treeview aan de rechterkant van de kaart. - Het scherm “Beheer toegangsrechten” is zichtbaar Aangeven van plot feature rechten - Met de Select knop kan de beheerder objecten selecteren in de kaart. Geselecteerde objecten zijn te herkennen een aparte selectie kleur. - Alternatief is om objecten in de treeview aan de rechterkant te selecteren. De lijst zal hiertoe worden uitgebreid met checkboxes. Bij het aanvinken van de checkbox voor een object zal bijbehorend object in de kaart de selectiekleur krijgen. - In de lijst met toegangsrechten (publiek, deelnemers, hulpverleners) kunnen een of meerdere rechten worden gekozen. - Door op de Save knop te drukken worden de geselecteerde rechten doorgevoerd naar de geselecteerde objecten in de database.

Pagina 19 van 21

Aangeven van tekstrechten - Voor het toekennen van rechten tot tekstbeelden geldt dezelfde procedure als voor plot rechten zoals hierboven beschreven. - Selecteer een tekst beeld met gewenst toegangsrechten en druk op Save. -

Het is mogelijk om een Select All uit te voeren. In de kaart of in de lijst. Benodigde interface (knop of ctrl-A) wordt uitgewerkt. Een aparte knop “Select UnAuthorized” selecteert alle objecten (in kaart en in lijst) die nog geen toegangsrechten toegewezen hebben gekregen.

Pagina 20 van 21

6.

6.1

Relaties met andere projecten

NCC

Het NCC beheert de website www.crisis.nl als medium om het publiek in de crisiscommunicatie naar de burger. Inzet van de website wordt bepaald door de gemeente. De website kan niet worden ingezet bij grip 2 en hoger. De onderdelen die in i-Bridge ontwikkeld worden zouden dan ook moeten werken met de techniek van de websites van de gemeenten. In een later stadium, als de het deel crisiscommunicatie in iBridge werkt en goedgekeurd is door gebruikers van de gemeente zou wellicht opnieuw contact gelegd moeten worden met het NCC, cluster Risico- en Crisiscommunicatie (JanBart van Oppenraaij). 6.2

Burgernet

Burgernet (www.burgernet.nl) is een uniek samenwerkingsverband tussen burgers, gemeente en politie om de veiligheid in de woon- en werkomgeving te bevorderen. Hierbij wordt gebruik gemaakt van een telefonisch netwerk van inwoners en medewerkers van bedrijven uit de gemeente. De centralist van de meldkamer van de politie start, na een melding van bijvoorbeeld een inbraak of een vermist kind, een Burgernetactie op. Dit gebeurt op basis van een goed signalement. Burgernet en Profinet maakt op dit moment alleen gebruik van proven technology. Men is van mening dat Burgernet goed toegankelijk moet zijn voor de gemiddelde burger. Het is mogelijk om een koppelvlak te genereren tussen i-Bridge en Burgernet op basis van uitwisseling van XML-protocollen. Binnen Burgernet is men druk bezig om koppelingen te leggen tussen de verschillende GMS (Sherpa, CityGIS en Tensing). Per 1 september 2010 zouden 13 korpsen in Nederland aangesloten moeten zijn op Burgernet. Er is een beweging bij BZK om de verschillende initiatieven op het gebied van alertering te consolideren en te komen tot een omgeving. Burgernet en i-Bridge bewegen zich nog op gescheiden paden, maar die zouden in de toekomst wel eens bij elkaar kunnen gaan komen. Er wordt dan ook de intentie uitgesproken om contact te houden en op regelmatige basis informatie uit te wisselen. De functionalitie die i-Bridge op dit moment ontwikkelt t.b.v. crisiscommunicatie zou ook voor alertering van burgers kunnen worden ingezet. Als korpsen veelvuldig gebruik gaan maken van Burgernet zou een presentatie op geografische ondergrond wellicht makkelijker zijn dan een lijst met incidenten. 6.3

CivilNEC

Volgt.

Pagina 21 van 21