NVBR. Programma van Eisen Digitale bereikbaarheidskaart 8 januari Concept 0.4

Transcriptie

1 NVBR Programma van Eisen Digitale bereikbaarheidskaart 8 januari 2009 Concept 0.4

2 NVBR Stationsplein 1 Postbus AX Amersfoort Telefoon Programma van Eisen Digitale bereikbaarheidskaart Albert van Duijn Eric van Capelleveen Amersfoort, 8 januari /ADN/AKQ

3 Voorwoord Dit Programma van Eisen is ontwikkeld als onderdeel van het NVBR-project Digitale Bereikbaarheidskaart (DBK) wat nauw samenwerkt met de in oprichting zijnde vraagorganisatie Brandweer (VO Brandweer). Het Programma van Eisen is bedoeld om de minimale eisen die brandweerkorpsen en gemeenten stellen aan DBK-applicaties te verwoorden. Daartoe bevat het PvE een aantal principes die de interoperabiliteit tussen DBK-applicaties van verschillende makelij kan garanderen. Tevens zijn minimale werkingsprincipes opgenomen om de harmonisatie tussen de brandweerkorpsen in Nederland te bewerkstelligen zonder afbreuk te doen aan de geografische verschillen.

4 Inhoudsopgave Voorwoord 1 Inleiding Aanleiding Positionering Programma van Eisen Leeswijzer Procedure met betrekking tot wijzigingen 2 2 Afbakening Architectuur Gegevenselementen Objectgegevens (groen) Preventieve gegevens (geel) Preparatieve gegevens (blauw) Repressieve gegevens (rood) Basisprincipes DBK 5 3 Algemene schermen en functionaliteit Opbouw hoofdscherm en achterliggende schermen Algemene functies 8 4 Werkproces maken en specifieke functionaliteit Proces maken DBK-kaarten Kiezen van een ondergrond Zoeken van object(locatie) Aanmaken van een object en toevoegen bijbehorende gegevens Object bewerken en onderling koppelen Tijdelijke gegevenselementen Symbolen plaatsen en verbinden Publiceren en distribueren Publiceren kaart Digitaal distribueren objectinformatie Case 22 5 Werkproces Gebruiken en specifieke functionaliteit Proces Gebruiken van de DBK Overkoepelende functionaliteit Navigatiefunctionaliteit Raadpleegfunctionaliteit Case 28

5 6 Werkproces Beheren en specifieke functionaliteit Proces Beheren van de DBK Signaleringslijst Aangeven wijzigingen in het veld Terugmelden aan bronhouders en repressie/inspectie Meta-informatie en versiebeheer Beheer in relatie tot BAG Beheer in relatie tot WABO Cases 34 7 Aanvullende eisen Aanvullende eisen voor conversie naar DBK vanuit huidige dataformaten Eisen aan infrastructuur 36 8 Berichtenverkeer Verzoeken om informatie Verzoek BAG Verzoek WABO Omgevingsloket Verzoek BRO (ondergrond) Verzoek VEWIN (bluswater) Verzoek PRK (risicokaart) Terugmeldingen Terugmelding BAG Terugmelding WABO Terugmelding BRO Terugmelding VEWIN Terugmelding PRK Berichten tussen de DBK-applicatie en andere applicaties Melding incident Melding ter plaatse Wijziging symbool Wijziging gegevens Bijlage 1: Gegevensset DBK en bronhouders

6 1 Inleiding Voor u ligt het Programma van Eisen (PvE) voor de Digitale bereikbaarheids- Kaart (DBK). Dit PvE is tot stand gekomen met hulp van de expertgroep DBK en met de kennis en ervaring van alle professionals uit zowel de gemeentelijke als brandweerpraktijk die bij de acht PvE-reflectiesessies deze hebben ingebracht. 1.1 Aanleiding Het project DBK is een harmonisatieproject van de Programmaraad Informatiemanagement (PRIM) van de NVBR waarin de lokale en regionale brandweerkorpsen verenigd zijn. Het project DBK is bedoeld om én het verplichte gebruik van basisregistraties door brandweerkorpsen én het gebruik van bereikbaarheidskaarten in het digitale tijdperk onderling te verbinden. Dit was de aanleiding om het project DBK uit te voeren. In fase 1 van dit project is bepaald wat de DBK is en hoe de DBK vormgegeven dient te worden 1. Het rapport dat dit beschrijft is inmiddels eind december 2008 door de Raad van Regionale Commandanten vastgesteld. Het PvE markeert het einde van fase 2: het bepalen van de minimale (functionele) eisen aan een DBK-applicatie. Dit document is het resultaat van deze fase. 1.2 Positionering Programma van Eisen De eisen die in dit document zijn aangegeven zijn de minimale eisen die de brandweer en gemeenten, verzameld binnen de NVBR, stellen aan een DBKapplicatie. Als een leverancier zich kan en wil onderscheiden met functionaliteit waarvan deze denkt dat Brandweer Nederland mee geholpen is, dan is de leverancier uiteraard vrij om die functionaliteit aan te bieden. Ook als u slechts een gedeelte van de functionaliteit wilt of kunt aanbieden vanuit uw expertisegebied dan staat het de leverancier vrij dat te doen. Brandweerkorpsen en gemeenten worden evenwel aangemoedigd deze set eisen te zien als de minimale eisen waaraan DBK-applicaties moeten (gaan) voldoen. In dit PvE zijn een aantal cases uitgewerkt. In het beschrijven van de cases is getracht zoveel mogelijk de verwachte problematiek en werkwijze inzichtelijk te maken die bij het opstellen en beheren van DBK s zich voor zal doen. 1 Zie NVBR-site voor rapport DBK eerste fase 1/1

7 Deze cases zijn de basis, naast nog een aantal andere elementen, voor de POC 2 - acceptatietoetsen en te zijner tijd de conformiteittoetsen. Als uw versie van een DBK-applicatie aan deze conformiteittoetsen voldoet, dan krijgt uw applicatie het predicaat DBK proof. U krijgt een vermelding op de website van de NVBR en u kunt de applicatie(s) aanbieden aan de brandweerkorpsen, de veiligheidsregio s en de gemeenten. Dit in analogie met wat bij VROM met BAG 3 -applicaties gebeurd is. 1.3 Leeswijzer In hoofdstuk 2 wordt de DBK-applicatie afgebakend. Welke systemen en informatie maken allemaal gebruik van dezelfde basiskaarten en thema s en hoe hangen deze weer samen met de DBK-applicatie. Vervolgens wordt in hoofdstuk 3 de algemene functionaliteit beschreven die gewenst is bij een dergelijke GIS-/CAD-applicatie. Hoofdstuk 4 gaat gedetailleerd in op de functionaliteit die nodig is bij de drie hoofdprocessen van de DBK: maken, gebruiken en beheren. Verder wordt in dit hoofdstuk ingegaan op de relatie tussen BAG, de WABO (omgevingsvergunning) en de DBK, specificatie van het berichtenverkeer met alle bronhouders en de benodigde infrastructurele voorzieningen om de DBK in gebruik te kunnen nemen. 1.4 Procedure met betrekking tot wijzigingen Een PvE als dit is in principe een levend document. Het zal na definitieve vaststelling door de PRIM en RvRC van de NVBR in beheer worden genomen. Wijzigingen die met de jaren ontstaan zullen in het PvE worden verwerkt. Het beheer is vooralsnog in handen gelegd van de portefeuillehouder ICT bij de NVBR. U wordt verzocht gedurende de projectfase wijzigingsvoorstellen, onvolledigheden en onjuistheden te melden aan adn@tg.nl en vanaf 1juli 2009 aan dbk@nvbr.nl. 2 POC: Proof of Concept; er wordt in 2009 een POC gehouden 3 BAG: Basisregistratie Adressen en Gebouwen 2/2

8 2 Afbakening 2.1 Architectuur Hoewel er geen expliciete architectuur is ontwikkeld voor de DBKapplicatie/systeemomgeving is gaandeweg het specificatietraject wel duidelijk geworden dat een DBK-applicatie waarschijnlijk draait op een MDTomgeving. MDT staat voor een Mobiele Data Terminal en is zoiets als een mobiele computer die in extreme omstandigheden gebruikt kan worden en die verbonden is met een centrale dataserver. Op deze dataserver is basiskaartdata en themakaartdata aanwezig. Deze gegevens worden niet alleen door de DBKapplicatie gebruikt maar ook voor allerhande andere mobiele toepassingen zoals navigatie, locatietracering (AVLS), maar ook voor informatiemanagement tijdens crisis (CMIS) op COPI-niveau en/of Motorkapoverleg. Daarnaast wordt deze ruimtelijke gegevens ook gebruikt in de meldkamersystemen (GMS) en het bijpassende meldkamer GIS. Gegevens over verkeersbelemmeringen die vanuit de systemen van de weg-, spoor-, vaarweg-, en luchtwegbeheerders afkomstig is worden eveneens aan deze gegevensomgeving toegevoegd. Zo gebruiken deze systemen dezelfde gegevens en leveren onderling een consistent beeld op ondanks het feit dat ze voor verschillende doeleinden gebouwd zijn. VLN Prorail TIC? GMS IVS Vervoers belemmeringen MK GIS Basis/themakaartdata DBK CMIS Navigatie AVLS Figuur 1. DBK en aanpalende systemen De DBK-applicatie maakt onderdeel uit van deze omgeving, maar is tevens afgebakend tot haar eigen functionaliteitsgebied. 3/3

9 Zo vindt u in dit PvE geen uitgebreide eisen aan AVLS- en navigatiesystemen, terwijl deze systemen vaak wel in samenhang met de DBK-applicatie aangeboden worden. Reden hiervoor is dat vanuit de Raad MIV op dit gebied reeds specificatietrajecten lopen, waarop de DBK zich heeft gebaseerd. Dat is ook de reden waarom in dit PvE geen nadere eisen zijn opgenomen die het RSGB 4 en de Basisregsitraties omvatten. Daarvoor wordt verwezen naar de daartoe bestaande documenten vindbaar op en en hun specifieke websites. De architectuurprincipes uit de NORA en haar gemeentelijke evenknie GEMMA zijn gevolgd en toegepast. Evenzo is uitgegaan van internationale standaarden zoals de GML-specificaties van de Open GIS-organisatie waarmee geo-webservices zijn gespecificeerd. 2.2 Gegevenselementen In het eerste document over de DBK zijn de gegevenselementen reeds benoemd. We geven ze hieronder nogmaals weer. De DBK is opgebouwd uit vijf lagen, te beginnen met de kaartondergrond die naar keuze moet kunnen worden ingesteld. Dan bestaat het DBK informatievierkant uit vier vlakken. Het groene kwart geeft de objectgegevens voor zoals die in veel basisregistraties worden bijgehouden. Het gele kwart stelt de preventieve gegevens voor zoals die in de WABO-voorzieningen worden verzameld. Het blauwe kwart stelt de veelal door de brandweer zelf geregistreerde/geinitiëerde preventieve voorzieningen voor. Tenslotte worden in het rode kwart de inzetbijzonderheden en onderkende gevaren getoond. Deze zijn op maat door de brandweer bepaald, veelal na het raadplegen van het risicoregister/-kaart Objectgegevens (groen) De standaard objectgegevens (gebouw/terrein gericht) zijn: - object-id (diverse) (gebouw-id, OMS-nummer en PR- nummer) - naam object, pand(en), secties (plaatselijk bekend als) - adres (volgens BAG en afgekort) - gebruikstype (prevap) - bouwlagen (laagste, hoogste)(eventueel gebouwhoogte) - controledatum - verblijf aantal (maximale GV. Bewoners, bezoekers, personeel/pand) - verblijf tijdvakken - zelfredzaamheid (bewoner, bezoeker/pand) 4 RSGB: Referentie Stelsel Gemeentelijk Basisregistraties 4/4

10 - toegang terrein (inrit en obstakels) - gevel- en eventueel detailfoto Preventieve gegevens (geel) In de preventieve (vergunnings-) fase worden onderstaande gegevens reeds vastgelegd: - BHV (ja/nee)(verzamelpunt) - brandcompartimentering (waar; welke) - brandmeldpaneel (waar) - automatische blusinstallatie Ja/Nee - rook en warmte-afvoerinstallatie Ja/Nee - overdruk-, stuwdrukinstallatie (parkeergarage, tunnel) Preparatieve gegevens (blauw) In de planvormingsfase worden gegevens over de volgende zaken vastgelegd: - ingang brandweer, overige (waar) - sleutelbuis/-kluis (waar; sleutelhouder) - brandkranen (capaciteit)(waar) - open water (capaciteit)(waar) - geboorde put (capaciteit, open en gesloten)(waar) - bluswaterriool (waar, capaciteit) - droge stijgleiding, blusleiding (waar) - hoofdafsluiters (waar)(welke) - C2000 binnendekking (andere communicatiesystemen) Repressieve gegevens (rood) Direct bij de inzet houdt men rekening met onderstaande gegevens: - gebouwconstructie (welke) - gevaarlijke stoffen (waar, welke, maximale hoeveelheid) - kabels en leidingen (groot)(waar; aard) - inzetprocedure (bijzondere) - bijzonderheden (overig) - opstelpunt (waar). 2.3 Basisprincipes DBK Maken, beheren en gebruiken zijn de hoofdprocessen van de DBK. Bij het maken wordt de werkelijkheid vastgelegd in een aantal gegevensbestanden. De ondergrond wordt door de beheerder van de kaart (TOP10, GBKN enzovoort) vastgelegd en aangeboden. We benutten die ondergrond om ons brandweerobject te kiezen en daar specifieke DBK-informatie aan te koppelen. Daarna worden achtereenvolgens gegevens over het object, de preventieve, preparatieve en gevaarzetting en inzetbijzonderheden vastgelegd. 5/5

11 Waar mogelijk betrekken we deze gegevens met één klik van de bronbeheerders. De gegevens worden in principe niet opnieuw vastgelegd anders dan dat omwille van veiligheid en voortdurende beschikbaarheid een werkkopie wordt vastgelegd. Telkenmale dat de gegevens opgevraagd worden zullen deze indien mogelijk bij de bron worden opgehaald. Alleen bij uitblijvende beschikbaarheid wordt teruggegrepen op de laatst vastgelegde werkkopie. Dit leidt tot een bereikbaarheidskaart die opgebouwd is uit diverse subverzamelingen en voortdurend via het proces van beheer wordt bijgehouden en beheerd. De werkkopie wordt (indien mogelijk) bij elke raadpleging ververst. Wanneer in de bronverzamelingen iets verandert, wordt van deze wijziging een aankondiging gedaan en kan er besloten worden of deze wijziging relevant is voor de subverzamelingen van de DBK. Indien dat het geval is kunnen deze veranderingen worden doorgevoerd en wordt het DBK-product dus ook ververst. Wijzigingen kunnen ontstaan door veranderingen in de buitenwereld zoals veranderingen in de weginfrastructuur, gebeurtenissen zoals aanvragen van een vergunning ten behoeve van een verbouwing en/of bij het signaleren van wijzigingen door inspectie of bij oefeningen respectievelijk inzet. Bij een inzet worden de gegevens snel onttrokken aan de DBK-verzamelingen en worden deze trapsgewijs ontsloten voor de brandweerlieden die bij de inzet betrokken zijn en aanrijdend/varend zijn. Ook daar geldt dat de actuele data wordt opgevraagd bij de bron. Een bron die regelmatig wordt ververst om actueel te blijven, ook bij uitval van directe online verbindingen. 6/6

12 3 Algemene schermen en functionaliteit Dit hoofdstuk beschrijft de algemene functionaliteit die bij een DBK- GIS-/CAD-applicatie noodzakelijk is. Dit hoofdstuk heeft niet de bedoeling voor te schrijven hoe exact een scherm- en menuopbouw vormgegeven dient te worden, dit hoofdstuk geeft alleen aan welke algemene GIS-/CADfunctionaliteit en welke schermelementen de DBK-applicatie dient te bevatten. 3.1 Opbouw hoofdscherm en achterliggende schermen Het hoofdscherm dient in ieder geval de elementen zoals hieronder weergegeven te bevatten. Kaartsegmentvenster met daarin detailweergave Dit scherm toont alle detailgegevens van de kaartlagen. Dit scherm moet horizontaal en verticaal schuifbaar (te scrollen) zijn. Kaartoriëntatievenster Dit is een klein schermpje waarin het detailvenster (view) van het kaartsegmentvenster in een groter geheel, de regio of de gemeente of de provincie wordt getoond. Gegevensboom De gegevensboom bevat alle kaartelementen/datasets die in het hoofdvenster kunnen worden getoond. Het moet mogelijk zijn om (gedeeltes) van een kaartelement aan of uit te vinken. OS kopbalk DBK Kopbalk Scherm Kaart segment venster met verplaatsbalken kaart orientatie venster Gege vens toon boom Invoer A Invoer B Invoer C Invoer D TOETS 1 TOETS 2 DBK Bodembalk OS stuurbalk Figuur 2. Elementen algemene scherm 7/7

13 Eigenschappenscherm Het eigenschappenscherm bevat informatie over de eigenschappen van het geselecteerde object of andersoortige kaartelement. Hieronder valt ook metainformatie. DBK-kopbalk Dit menu bevat alle aan te roepen functies, schermen en instellingsmogelijkheden. DBK-bodembalk In de bodembalk wordt informatie getoond over de positie in het hoofdscherm. Zoals x,y-coördinaat, actieve kaartlaag enzovoort. Aanvullende schermen Er dienen in ieder geval de volgende schermen aangeroepen kunnen worden. Deze worden verder uitgewerkt in de specifieke functionaliteit bij de werkprocessen: - zoekmenu - tekenmenu - beheerlijst - signaleringslijst. Elk scherm heeft een schermidentificatie zodat bij problemen aan het bewuste scherm gerefereerd kan worden. 3.2 Algemene functies Er wordt hier een opsomming gegeven van korte beschrijvingen van functies die minimaal in de applicatie een plek moeten hebben. In- en uitzoomen op kaartlagen Vergroten en verkleinen van het beeld in het kaartsegmentvenster. Verplaatsen Hiermee wordt het hoofdscherm verplaatst naar een ander gedeelte van de kaart. Selecteren Een element op de kaart of een gedeelte van de ondergrond moet geselecteerd kunnen worden. Afdrukken De applicatie dient kaarten af te kunnen drukken. 8/8

14 Informatie tonen De applicatie dient in het eigenschappenscherm informatie te tonen over het object of een andere geselecteerd element. Metadata tonen De applicatie dient de metadata over de gebruikte datasets te kunnen tonen. Naar standaard gebied De applicatie dient met één druk op de knop terug te keren naar de view op het standaardgebied. Volgende in de lijst In de beheerlijst of werklijst of dient men naar het volgende item te kunnen gaan. Vorige in de lijst In de beheerlijst of werklijst dient men naar het vorige item te kunnen gaan. Terug naar begin In de beheerlijst of werklijst dient men in één keer terug naar het begin te kunnen gaan. Foto/Beeld/Tekening toevoegen Aan een object moet een foto/beeld/tekening toegevoegd kunnen worden. Link toevoegen Aan een object dient een link toegevoegd te kunnen worden. Zoeken (object-id, x,y, adres/naam) Doorzoeken van de database volgens bovenstaande manieren. Ongedaan maken Ongedaan maken van de laatste x acties. Laatste mutatie terugdraaien Laatst gemaakte mutatie onthouden en terug kunnen draaien wanneer nodig. GPS Hiermee kan snel gepositioneerd worden en laat de applicatie op basis van de GPS bepaalde x,y,z-locatie de omgeving zien. 9/9

15 Tabel 1. Algemene functionaliteit Nummer Functionele eis van eisen ALG-1 Hoofdscherm dient de volgende elementen te bevatten: - kaartsegmentvenster met detailweergave - kaartoriëntatievenster - gegevensboom - eigenschappenscherm - DBK-kopbalk - DBK-bodembalk ALG-2 In ieder geval dienen de volgende schermen/ functies dienen vanuit het hoofdscherm aan te roepen zijn: - zoekmenu - tekenmenu - beheerlijst - signaleringslijst ALG-3 De applicatie dient in ieder geval de algemene functies die staan omschreven in paragraaf 4.2 te bevatten Hardheid eis 10/10

16 4 Werkproces maken en specifieke functionaliteit We onderscheiden drie hoofdprocessen in het werken met de DBK. Het maken, beheren en gebruiken van digitale bereikbaarheidskaarten. Daarnaast zijn er eisen aan de applicatie die korpsen helpen om de transitie te maken van hun oude situatie. Hier wordt geschetst hoe en welke import, export en conversie mogelijkheden de applicatie dient te bevatten. Als laatste staan de eisen aan de infrastructuur beschreven waarop de DBK-applicatie dient te draaien. 4.1 Proces maken DBK-kaarten Het maken van een DBK is gecentreerd rond een object. Zodra er voor een object planvorming gemaakt dient te worden, dan zal voor dit object een bereikbaarheidskaart opgesteld worden. Het werkproces staat in onderstaande figuur uitgewerkt. Figuur 3. Procesbeschrijving produceren kaart (1) 11/11

17 Figuur 4. Procesbeschrijving produceren kaart (2) 4.2 Kiezen van een ondergrond Het maken van een DBK begint met het kiezen van een ondergrond. Deze ondergrond moet in de gegevensboom (gedeeltelijk) aan of uit kunnen worden gezet. Ook moet de ondergrond transparant kunnen worden gemaakt (transparantie is traploos instelbaar). Tenslotte moet de volgorde van de geactiveerde kaartlagen ingesteld en gewijzigd kunnen worden. De DBK-applicatie dient minimaal de volgende ondergronden weer te kunnen geven: - luchtfoto s - GBKN (BGT) - Top10 - wegenkaart (welke naar keuze) - pandenkaart (BAG). Indien er geen, één of meerdere ondergronden actief zijn; deze laden in volgorde van boven naar beneden zoals weergegeven; ze vormen altijd de onderste laag van de gelaagde weergave van de kaart. De kaartlagen worden getoond als beelden, maar zijn afhankelijk van hun beschikbare structuur, bereikbaar als beeldpunten, vectoren, vlakken, objecten enzovoort, zodat kaartelementen geselecteerd en benut kunnen worden. 12/12

18 Tabel 2. Eisen bij gebruik ondergrond Nummer van eisen OND-1 OND-2 OND-3 OND-4 Functionele eis - Applicatie dient deze ondergronden te ondersteunen: - luchtfoto s - GBKN - Top10 - wegenkaart - pandenkaart (Elementen) van de ondergrond moeten aan- en uitgezet kunnen worden De ondergrond dient via een schuifbalk trapsgewijs transparant te kunnen worden gemaakt De ondergronden dienen in volgorde instelbaar te zijn. Ze vormen altijd de onderste lagen van het kaartbeeld Hardheid eis 4.3 Zoeken van object(locatie) Wanneer er planvorming van een object dient plaats te vinden zal eerst de juiste locatie gevonden dienen te worden. Via de zoekfunctie wordt een object gelokaliseerd. Er kan op de volgende wijzen worden gezocht: - adres (postcode (6PPC) en huisnummer)(automatisch lijst met keuzemogelijkheden tijdens intypen genereren) - objectidentificatie (dit kunnen verschillende objectidentificaties zijn, minimaal de verplichte BAG gebouwidentificator, brandweergebouw identificatie, PRK-identificator en OMS-nummer) - X,Y (intypen of met navigatie aanwijzen) - GPS genereert X,Y. Wanneer de zoeksleutel slechts een deel van de identificator omvat worden alle resultaten die aan het zoekcriterium voldoen getoond. Wanneer meerdere gegevens worden ingetoetst wordt naar keuze de vereniging (OR) of de combinatie (AND) van beide zoekvelden getoond. Als resultaat van de zoekactie wordt een lijst getoond met resultaten die voldoen aan de zoekcriteria. Vanuit deze lijst kan een zoekresultaat geselecteerd worden. Wanneer er slechts één resultaat is dan worden de weergave van het zoekresultaat overgeslagen. Het beeld van het hoofdscherm verplaatst zich dan naar het geselecteerde object. 13/13

19 Tabel 3. Eisen bij zoeken object Nummer van eisen OBJ-1 OBJ-2 OBJ-3 OBJ-4 OBJ-5 Functionele eis De zoekfunctie dient in de database op de volgende elementen te kunnen zoeken: - adres - objectnummer - X,Y-coördinaat - GPS-locatie Bij het intikken van het adres in het zoekscherm dient het systeem het adres af te maken met mogelijke passende adressen Het systeem dient een lijst te geven met resultaten die voldoen aan de zoekcriteria Vanuit deze lijst dient een zoekresultaat aangeklikt kunnen worden, het hoofdscherm verspringt dan automatisch naar de juiste locatie Naar keuze wordt de vereniging (OR) of de combinatie (AND) van beide zoekvelden getoond Hardheid eis 4.4 Aanmaken van een object en toevoegen bijbehorende gegevens Om een object in te tekenen dient de contour van het object geselecteerd te kunnen worden. De contour van het geselecteerde object wordt vervolgens als het ware uit de onderliggende laag geknipt en horizontaal (beeldvullend) op het scherm getoond. Deze kopiecontour moet automatisch geroteerd worden om eenvoudig te kunnen werken. pikmeer pikmeer meerstraat kerkstraat Figuur 5. Uitlichten objectcontour Nu de contour uit het scherm is gelicht moet men het object, dat door de kopiecontour wordt voorgesteld, kunnen bewerken. Binnen een contour of een terrein dient een nadere detaillering van de contour te kunnen worden gemaakt. 14/14

20 21-a 21-b 21-c d 21-e 21-f 21-g 21-h 21-j 21-a b 21-c 21-d 21-e 21-f 21-g 21-h 21-j 21 pikmeer pikmeer 25 meerstraat kerkstraat meerstraat kerkstraat 21 Silo Silo Silo Silo Silo Silo Figuur 6. Bewerken en terugplaatsen objectcontour Er dienen ook symbolen voor brandweerspecifieke informatie aan het object toegevoegd te kunnen worden. Bovenstaande bewerkingen en handelingen staan in de pagina s verder toegelicht. 4.5 Object bewerken en onderling koppelen Er dienen in het object of aan de objectcontour andere objecten aangemaakt te kunnen worden ofwel een nadere onderverdeling gemaakt te worden. Bijvoorbeeld door meerdere gebouwen op een groot terrein te tekenen (complexen) of door binnenruimtes (dan wel gebouwdelen) in een (groot) gebouw te tekenen. Deze objecten dienen onderling gekoppeld te kunnen worden en zijn. Aan het object dienen ook willekeurige bestanden gekoppeld te kunnen worden. Te denken valt aan bouwtekeningen of foto s van het pand. Alle aan de kopiecontour verbonden deelobjecten en bestanden zijn in principe in een lokaal referentiestelsel vastgelegd. De positionering van de gebouwcontour op onze aardbol (X,Y) geschiedt in de BAG en wordt daaruit onttrokken. Alleen bij tijdelijke objecten die men zelf aanmaakt en die (nog) niet in de BAG voorkomen legt met eveneens de X,Y in RD-stelsel vast. 15/15

21 Objecten onderling koppelen X,Y 21-a b 21-c 21-d 21-e 21-g 21-f Bouwlagen onderscheiden en koppelen in één geografisch geprojecteerd object 21-h JPG 21-j Figuur 7. Aanmaken en koppelen objecten en toevoegen bestanden 4.6 Tijdelijke gegevenselementen De mogelijkheid bestaat dat voor een object (gebouw) planvorming (preparatie) gemaakt dient te worden, maar die nog niet in de bronregistratie (BAG) staat vermeld. Om die reden dient de applicatie met tijdelijke gegevenselementen te kunnen werken. De applicatie dient tevens de mogelijkheid te bevatten dat een contour niet overgenomen maar zelf ingetekend wordt. Bij elk tijdelijk gegevenselement wordt een einddatum opgegeven en wordt automatisch op een signaleringslijst geplaatst ten behoeve van beheer. Als er van de bronhouders geen vervanging te verwachten is (valt buiten de bronhouder specificaties) voor het tijdelijke gegevenselementen, dient deze ook voor onbeperkte tijd geldig gemaakt te kunnen worden. Een tijdelijk gegevenselement moet in verband kunnen worden gebracht met een corresponderend (vervanging) bericht van de bronhouder. Hiertoe doorzoekt de DBK-applicatie de databank van tijdelijke elementen en toont voor een contour-plusgebied de tijdelijke gegevens, elementen en vervangingselement van de bronhouder. Ook dient bij de tijdelijke contour een objectidentificator opgegeven te kunnen worden. Mutaties/berichten met hetzelfde object-id, contour of in contour-plusgebied van een tijdelijk gegevenselement worden opgenomen in een werklijst voor beheer. De beheerder dient de mogelijkheid te hebben het tijdelijke gegevenselementen te vervangen door de nieuwe contour. Hiermee wordt het tijdelijke object verwijderd. 16/16

22 De werklijst laat alle objecten zien die via meldingen vanuit de bronhouders om behandeling vragen. De signaleringslijst bevat de tijdelijke objecten die tegen hun vervaldatum aan zitten. Deze vragen immers ook om behandeling. 4.7 Symbolen plaatsen en verbinden Op het hoofdmenu kan je het tekenmenu aanklikken. In het tekenmenu worden vier hoofdcategorieën getoond: - objectkarakteristieken - preperatieve voorzieningen - preventieve voorzieningen - onderkende gevaren en inzetbijzonderheden. Bovenstaande gegevens worden met de symbolen uit de NEN1414-norm op het scherm weergegeven. Intekenen van bepaalde elementen, evenals het toevoegen van symbolen, gebeurt volgens de functionaliteit die is beschreven in het algemene gedeelte. Bovenstaande gegevens worden met de symbolen uit de NEN1414-norm op het scherm weergegeven. Intekenen van bepaalde elementen, evenals het toevoegen van symbolen gebeurt volgens de functionaliteit die is beschreven in het algemene gedeelte. Er dient tevens een mogelijkheid te zijn nieuwe symbolen toe te voegen op bestaande symbolen te vervangen. Wanneer een nieuw symbool wordt aangemaakt/gewijzigd wordt daarvan in principe een bericht gezonden aan dbk@nvbr.nl om de harmonisatie van symbolen te bewerkstelligen. De symbolen worden bij plaatsing gekoppeld aan het object. Deze koppeling is relatief aan het object, dus niet met vaste X,Y RD 5 -coördinaten. Dit betekent dat als het object wordt verplaatst, de ingetekende symbolen automatisch mee verplaatst dienen te worden. Het moet echter ook mogelijk zijn om informatie absoluut (wel in RD) vast te leggen. Ook moet het mogelijk zijn om gegevenselementen te koppelen aan andere objecten dan de contour. Een toevoeging op de symbolenlijst zijn de blauwe opstelpunten. Deze kennen hetzelfde symbool als de rode opstelplaats uit de NEN 1414, maar dat blauw van kleur. Dit zijn opstelpunten die worden geplaatst bij open water dat geschikt is als bluswater. De contour van de wateroppervlakte wordt overgenomen. Aan de contour wordt over de volledige breedte waar water gewonnen kan worden een band aangegeven, met in het midden het bijbehorende symbool. 5 RD-stelsel Rijksdriehoekmeting standaard coördinatenstelsel waarbij de OLV kerk in Amersfoort op X=155, Y=463 ligt 17/17

23 Bij een blauw opstelpunt dient men verschillende WTS 6 -lengtes als een licht blauw gearceerde transparante cirkel om het opstelpunt aan te kunnen geven. De slanglengtes moeten met een lengte van 1000 meter, 2500 meter en 3500 meter aangegeven om de bluswaterwinpunten aangegeven kunnen worden. De kleur intensiteit van de WTS-cirkel neemt af met de afstand ergo de WTS cirkel is dieper van kleur dan de WTS 2500-cirkel. Voor het gemak moet het tevens mogelijk zijn contouren van dergelijke watervlaktes/-lopen te importeren. Symbolen plaatsen/verbinden Opstelpunt BHV Controledatum Communicatiebinnendekking Ingang Brandweer, overige Bluswaterriool Brandcompartimentering Droge stijgleiding, blusleiding Zelfredzaamheid Bouwlagen (hoogste laagste) Brandmeldpaneel Sleutelbuis/-kluis Inzetprocedure Veld Bijzonderheden (overig) Sym bool X,Y parkeerstrook 21-a 21-b 21-c 21-e 21-g 21-h d 21-f 21-j Tekst/veldinformatie metadata X,Y Gebouwcontour is drager symbolen en andere informatie Als deze verschuift, verschuift alles mee Figuur 8. Plaatsen en verbinden van symbolen aan object Na het bewerken van het object wordt het object in de oorspronkelijke positie geroteerd en weer teruggeplaatst op de oorspronkelijke locatie. Aanpassingen aan het object worden opgeslagen. Bij het plaatsen van een symbool dienen altijd de volgende informatievelden gevuld te worden: - veldnaam (wordt automatisch door DBK-applicatie ingevuld bij symboolkeuze) - gebruikte symbool (is feitelijk een verwijzing naar een symbolenbibliotheek) - tekst/veldinformatie (de bij het symbool behorende velden en teksten) - X,Y-coördinaat in principe lokaal (soms absoluut) - metadata (wanneer door wie aangemaakt, verandert, aard verandering). 6 WTS: Water Transport Systeem 18/18

24 Tabel 4. Eisen aan aanmaken en verrijken object Nummer van eisen OBJ-6 OBJ-7 OBJ-8 OBJ-9 OBJ-10 OBJ-11 OBJ-12 OBJ-13 OBJ-14 OBJ-15 OBJ-16 OBJ-17 OBJ-18 OBJ-19 Functionele eis Selecteren van contouren uit één van de basislagen Knippen van een contour uit de ondergrond en deze horizontaal beeldvullend tonen op het tekenscherm Bewerken van de contour met algemene tekenfunctionaliteit Koppelen van objecten aan elkaar en aan contour Koppelen van digitale bestanden aan contour (foto, tekening, pdf-bestand) Toevoegen van objectinformatie, preperatieve voorzieningen, preventieve voorzieningen en gevaren en inzetbijzonderheden aan de hand van symbolen volgens NEN1414-norm Symbolen relatief aan contour koppelen Symbolen absoluut vastleggen Mogelijkheid om symbolen aan andere kaartelementen te koppelen Toevoegen van blauwe opstelpunten en bijbehorende slanglengtes Importeren van contour uit andere bron Opslaan van bewerkte contour in eigen DBKdatabase Voor elk symbool worden de volgende informatievelden gevuld: - veldnaam - gebruikte symbool - tekst/veldinformatie - x,y-coördinaat - metadata Terugmelden symboolwijzigingen NVBR Hardheid eis 4.8 Publiceren en distribueren Nadat het object is bewerkt en teruggeplaatst, dient het object vrijgegeven te worden voor publicatie. Nadat het object is vrijgegeven dient het gepubliceerd of digitaal gedistribueerd worden. Met beide acties wordt het object ter beschikking gesteld aan de gebruikers. 19/19

25 4.8.1 Publiceren kaart Bij het publiceren van een kaart wordt een object opgemaakt tot een bruikbare kaart en dient daarna op verschillende wijzen gepubliceerd te kunnen worden. Opmaken kaart Bij het publiceren kan men bepaalde elementen aan de kaart toevoegen. Er dient een kader om het te publiceren gebied/object te worden geplaatst. Alles binnen dit kader zal dan gepubliceerd worden. In dit kader wordt automatisch een legenda opgenomen waarin alle elementen die binnen het kader aanwezig zijn getoond worden. Daarnaast wordt ook een noordpijl en een schaal toegevoegd aan de kaartlaag. Er wordt op schaal getekend. De kaart wordt bladvullend gepubliceerd op de meest gangbare tekenschalen. De applicatie dient de meest gangbare standaard schaalmaten ondersteunen: - 1:5-1:10-1:20-1:25-1: 100. NEN/ISO 5455 Technische tekeningen Schalen Als een object bij een volledig blad geen standaardschaal heeft, dient de applicatie de meest passende standaardschaal te gebruiken. Bij complexe tekeningen waarin meerdere bouwdelen of bouwlagen moeten worden weergegeven, dient vooraf een preview gemaakt te kunnen worden. Het moet mogelijk zijn één of meerdere delen van het totale object op verschillende afdrukbladen te plaatsen. Een kaart dient naar keuze noordgericht of gebouwgericht opgemaakt te kunnen worden. Publiceren kaart De volgende manieren dient de applicatie te bevatten: - maken van een papieren afdruk - maken van een pdf-bestand - maken van een met als attachment een pdf-bestand - maken van een met een link naar het object Digitaal distribueren objectinformatie Bij het distribueren van objectinformatie dient de gehele dataset vervangen te kunnen worden. Echter het moet ook mogelijk zijn dat alleen gewijzigde gegevenselementen vervangen worden. Daarbij dient altijd de laatste synchronisatie datum te worden vastgelegd. 20/20

26 Tabel 5. Eisen aan publiceren en distribueren kaart Nummer van eisen OBJ-20 OBJ-21 OBJ-22 OBJ-23 OBJ-24 OBJ-25 OBJ-26 OBJ-27 OBJ-28 Functionele eis Vrijgeef functie, hiermee wordt het object vrijgegeven voor digitale distributie of publicatie Bij publiceren van een kaart dienen de volgende elementen aan een kaart toegevoegd te worden: - kader (afdrukbereik) - legenda met alle voorkomende elementen binnen kader - noordpijl - schaal Bij het opmaken van een kaart dient de kaart volgens een van de norm x schalen getoond te worden Een kaart dient bladvullende gepubliceerd te worden. Wanneer een kaart bladvullend niet één van de standaardschalen heeft dient de dichtstbijzijnde standaardschaal geselecteerd te worden Applicatie dient een previewmogelijkheid te bevatten Applicatie dient mogelijkheid te hebben afdruk over meerdere schermen te verdelen Applicatie dient kaart noordgericht of gebouwgericht af te kunnen drukken Publicatie dient op volgende wijzen te kunnen: - maken van een papieren afdruk - maken van een pdf-bestand - maken van een met als bijlage een pdfbestand - maken van een met een link naar het object Bij digitaal distribueren dient de gehele dataset of gewijzigde elementen vervangen kunnen worden Hardheid eis 21/21

27 4.9 Case Case 1: Het maken van een bereikbaarheidskaart Een lintdorp waarin een waterrijke natuur en recreatiegebied grenst aan nieuwe bedrijvigheid. Bedrijvigheid die zich manifesteert in de vorm van een bedrijfsverzamelgebouw met meerdere verdiepingen dat verrijst binnen de gebouwcontouren van een bestaande leegstaande opslagloods en waar een provisorische parkeerruimte (parkeerstrook) bij gecreëerd wordt. Direct nabijgelegen in de andere gemeente wordt een voormalige herenboerderij verder verbouwd voor kantoorgebruik. Er komt een parkeerkelder onder en tevens worden daarna een open parkeerdek (2 lagen gebouwd tegen het pand aan). Hierdoor wordt het bestaande pand qua eigendom gesplitst. De kelder en aanbouw kennen een andere iegenaar dan de oorspronkleijke boerderij. Tenslotte vindt op het achterliggende terrein tussenopslag van bulk(vloei)stoffen plaats en zijn er opstelplaatsen voor de transporterende tankwagens. Hier zal een extra toegang gemaakt worden aan de nieuw aan te leggen Waddenweg die als nieuwe weg wordt toegevoegd. 22/22

28 5 Werkproces Gebruiken en specifieke functionaliteit 5.1 Proces Gebruiken van de DBK In de volgende twee afbeeldingen is het gebruik van de DBK weergegeven in combinatie met de standaard eenheden bevelvoeringprocedure zoals deze bij de brandweer wordt gebruikt. Naast de ondersteuning van de bevelvoerder in zijn werkproces krijgt de chauffeur ook ondersteuning om zo snel mogelijk ter plaatse te kunnen zijn. Figuur 9. Procesbeschrijving gebruiken DBK (1) Figuur 10. Procesbeschrijving gebruiken DBK (2) 23/23

29 5.2 Overkoepelende functionaliteit De gebruikapplicatie kent een navigatiegedeelte en een raadpleeg (view) gedeelte. Er dienen meerdere sessies van het raadpleeggedeelte actief te kunnen zijn zodat meerdere mensen tegelijkertijd objectgegevens kunnen bekijken. Het is namelijk goed denkbaar dat er naast het navigatie- en bevelvoerderscherm ook een bemanningscherm actief is. Er dient ook informatie-uitwisseling mogelijk te zijn tussen het raadpleeg- en het navigatiegedeelte. Als de bevelvoerder een bericht krijgt over een obstakel of wijziging van het inprikpunt 7 of opstelpunt en deze aangeeft in de applicatie dan dient het navigatiegedeelte dit te verwerken en op basis hiervan een nieuwe beste route te berekenen. Deze blokkade dient mondeling ook aan de meldkamer doorgegeven te worden en daarna regulier verspreid te worden naar de andere eenheden (die aanrijdend zijn). De applicatie dient de volgende stelsels te ondersteunen om een incidentlocatie te identificeren en in te voeren die vanuit de meldkamer of andere bron via spraak wordt ontvangen: - adres: X,Y BAG (via BAG-raadpleging wordt adres omgezet naar x,y) - RD-stelsel (X,Y) - UTC-stelsel (X,Y) - Duits/Belgische coordinatiestelselsystemen 8. Tabel 6. Eisen aan overkoepelende functionaliteit gebruiken Nummer van eisen GEBR-1 Functionele eis Applicatie dient berichtenverkeer met GMS 9 te ondersteunen. De inhoud van dit berichtverkeer bestaat onder andere uit het doorgeven van: - icidentlocatie - incidentgegevens - actuele belemmeringen Hardheid eis 7 Het inprikpunt is het punt van waaruit op de DBK de route naar het opstelpunt is ingetekend. Dat ligt in de regel bij de ingang van het terrein aan de openbare weg 8 Dit vindt plaats op basis van de volgende protocollen: (komt van Jan Sander RED is tot 5/1 met verlof) 9 Specificatie van functionaliteit en berichtenverkeer is beschreven in PvE MDT-koppeling voor de brandweer 24/24

30 Nummer van eisen GEBR-2 GEBR-3 GEBR-4 GEBR-5 Functionele eis Applicatie dient de volgende stelsels te ondersteunen om een incidentlocatie te kunnen identificeren: - adres: X,Y BAG - RD-stelsel - UTC-stelsel - Duits/Belgische systemen (wordt nader ingevuld) Applicatie bevat navigatie- en viewgedeelte Er dienen meerdere sessies van het viewgedeelte tegelijkertijd actief te kunnen zijn Het moet mogelijk zijn informatie tussen het navigatie- en viewgedeelte uit te wisselen en te gebruiken Hardheid eis Navigatiefunctionaliteit Een melding wordt ingeschoten vanuit de meldkamer in de DBK gebruikapplicatie. De bevelvoerder gebruikt deze informatie om het juiste object te bekijken en de chauffeur navigeert naar de opgegeven incidentlocatie toe met behulp van de DBK -navigatiefunctionaliteit. De applicatie ontvangt en gebruikt actuele belemmeringeninformatie om de snelste route naar het object te bepalen. Tabel 7. Eisen aan navigatiefunctionaliteit Nummer van eisen GEBR-6 Functionele eis Opstellen en wijzigen van navigatie naar incidentlocatie volgens de snelste route Hardheid eis Raadpleegfunctionaliteit Met het inschieten van de incidentgegevens wordt de bevelvoerder geholpen doordat automatisch het juiste object geselecteerd is en het bijbehorende kaartbeeld te zien is. Er wordt genavigeerd naar het inprikpunt dat gekoppeld is aan het object. Wanneer er meerdere inprikpunten zijn die naar de verschillende opstelplaatsen leiden (bijvoorbeeld bij evenementen en grote complexe gebouwen en terreinen) moet de meldkamer feitelijk al aangeven naar welk inprikpunt de eerste uitruk geleid wordt. Dit veronderstelt dat de meldkamer inzage heeft in de digitale bereikbaarheidskaart en de daarin gedefinieerde inprikpunten en opstelplaatsen. 25/25

31 Als er meerdere inprikpunten zijn dient de bevelvoerder het gekozen inprikpunt voor de incidentbestrijding van zijn voertuig te kunnen wijzigen. Bij het wijzigen van het inprikpunt dient de navigatie automatisch naar het nieuwe inprikpunt te navigeren. Ook dient de bevelvoerder op de kaart aan te kunnen geven waar opstoppingen oid zijn (daarmee voert deze de belemmeringen zelf in anders dan dat deze vanuit de meldkamer aan het navigatiesysteem worden aangedragen). Daarmee ontstaat tevens een retourstroom van het veld naar de meldkamer aangaande belemmeringen informatie. Het object dient in het hoofdscherm getoond te worden met een gebied van de hoogste waarde van 50 meter om de buitencontour heen of 2/3 van de hoogte van hoge gebouwen. Deze waarde wordt herleid uit het aantal verdiepingen dan wel uit de apart invoer bij de objectgegevens. De applicatie moet de mogelijk hebben om in of uit te zoomen en het scherm te verplaatsen. Ook moet er doorgeklikt kunnen worden om aanvullende informatie over bepaalde gegevenselementen op te kunnen halen. De vormgeving en opmaak moet simpel zijn, bedieningsgemak en bedieningssnelheid zijn erg belangrijk. De applicatie bevat daarnaast minimaal vijf knoppen. Deze knoppen dienen om de getoonde gegevens op het scherm te kunnen wijzigen. Er zijn drie knoppen gemarkeerd als 1, 2 en 3. Elke van deze knoppen correspondeert met een aantal gegevens uit de DBK-gegevensset (zie tabel 3). Als knop 1 wordt ingedrukt verschijnen de gegevens onder knop 1. Als knop 2 wordt ingedrukt worden de gegevens onder knop 1 zachter gemaakt en meer op de achtergrond weergegeven. De gegevens onder knop 2 staan meer op de voorgrond en zijn duidelijk zichtbaar. Zodra knop 3 wordt ingedrukt verdwijnen de gegevensets die horen bij knop 1 en 2 naar de achtergrond en worden de gegevens onder knop 3 op de voorgrond weergegeven. Tabel 8. Informatie onder de knoppen Gegevens onder knop 1 Gegevens onder knop 2 Gegevens onder knop 3 Objectgegevens BMP Brandmeldpaneel Grote kabels en leidingen Basisomgeving BHV Bedrijfshulpverlening Bijzonderheden Toegang terrein Sleutel buis/kluis Inzetprocedure Gebruikstype Brandcompartimenten Opstelpunt Verblijf Bluswatervoorzieningen Hoofdafsluiter Bouwlagen Ingangen Gevelfoto/360 -foto Stijg-/blusleidingen Communicatie binnendekking Installaties Bouwconstructie 26/26

32 Gegevens onder knop 1 Gegevens onder knop 2 Gegevens onder knop 3 Gevaarlijke stoffen Daarnaast dient de applicatie een brandweerknop te bevatten. Deze knop dient een de standaard NVBR-dataset van de DBK te tonen. Dit zorgt ervoor dat er grensoverschrijdende inzet snel geharmoniseerd kan worden. In dit geval worden alle gegevens in eens weergegeven. Tenslotte dient de applicatie een schuifknop te bevatten. De schuifknop biedt de mogelijkheid om zelf, afwijkend van de standaardknoppen, te bepalen hoeveel gegevens op het scherm getoond zullen worden. Als de schuif helemaal links staat worden er geen gegevens getoond. Als de schuif naar rechts wordt geschoven worden trapsgewijs steeds meer gegevens getoond. Wanneer de schuif geheel rechts staat worden alle gegevens van de DBK-set op het scherm getoond (zie figuur 11). De schuifknop is gebonden aan een object. Digitale bereikbaarheidskaart: getrapte detailinhoud Verstrijken van tijd Grote kabels en 1 leidingen Gebouwconstructie 2 Inzetprocedure Bijzonderheden Brand Gevaarlijke Gebruikstype BMP compartimenten stoffen Basis omgeving Toegang terrein Verblijf Bouw lagen BHV Sleutel buis / kluis Aanrijdend eerste minuten 2 Object gegevens Bluswater voorzieningen Ingangen Installaties DBK + Stijg, blus leidingen Opstelpunt Gevelfoto / 360 foto 3 Hoofafsluiter C2000 binnendekking Optioneel aanvullende informatie binnen eerste minuten NVBR set Aanvalsplan 1 3 Figuur 11. Verdeling knoppen Bij aankomst op locatie wordt aan de meldkamer doorgegeven dat het voertuig ter plaatse is. Dit gebeurt via AVLS, niet via de DBK-applicatie. Echter de DBK dient wel de AVLS-berichten te kunnen ontvangen en verwerken. Het is gewenst dat op het raadpleegscherm ook het navigatiescherm getoond kan worden. 27/27

33 Tabel 9. Eisen aan viewfunctionaliteit Nummer van eisen GEBR-7 GEBR-8 GEBR-9 GEBR-10 GEBR-11 GEBR-12 GEBR-13 GEBR Case Functionele eis Het inprikpunt dient gewijzigd te kunnen worden als bij een object meerdere inprikpunten beschikbaar zijn Obstakels en andere routebelemmerende informatie dient op de kaart ingetekend, verwerkt en verstuurd te kunnen worden Het object dient bij invoeren/opvragen in het hoofdscherm getoond te worden met 50 meter om de buitencontour heen of met omtrek van 2/3 van hoge gebouwen De applicatie dient zoom en scroll functionaliteit te bevatten De gegevens in de kaart dienen klikbaar te zijn zodat aanvullende informatie opgevraagd kan worden De applicatie bevat verder tenminste de 5 volgende knoppen: brandweerknop - schuifknop Applicatie dient AVLS-berichten te kunnen ontvangen en verwerken Tonen van navigatiescherm in raadpleegdeel van applicatie Hardheid eis Er wordt een incident gemeld net over de grens van het eigen gemeentelijke/regionale inzetgebied. Allereerst wordt een uitrukeenheid vanuit GMS vanuit het verzorgingsgebied van de aangrenzende korps gestuurd. Deze krijgt onderweg pech en GMS stuurt een nieuwe uitrukeenheid uit het aangrenzende gebied naar de incidentlocatie. Op de aanrijdroute is tevens een verkeersbelemmering geconstateerd door een bekend incident. De belemmering zorgt ervoor dat de aanrijdroute van de uitruklocatie naar de incidentlocatie wordt aangepast om de belemmering te ontwijken. Weg/Aanrijdend worden de incidentgegevens ingeschoten en geraadpleegd. Dan volgt een handmatige correctie van de incidentgegevens op basis van mondelinge communicatie vanuit de meldkamer. Het inprikpunt wordt daarbij veranderd. 28/28

34 Aansluitende worden opnieuw de DBK-gegevens geraadpleegd volgend het 1,2,3-principe en de NVBR-totaal en schuifknop. Er worden meerdere detailgegevens geraadpleegd. We gaan uit van een complexgebouw met meerdere verblijfobjecten en/of een complex met meerdere panden. 29/29

35 6 Werkproces Beheren en specifieke functionaliteit 6.1 Proces Beheren van de DBK Onder beheren wordt verstaan het doorvoeren van wijzigingen in het brandweerdeel van de DBK-registratie als gevolg van veranderingen op basis van een van de volgende elementen: - infrastructuur en omgeving - adressen en gebouwencontouren en andere objectgegevens - preventieve voorzieningen - preparatieve voorzieningen - gevaarzetting en inzetbijzonderheden. De veranderingen worden aangedragen op basis van berichtenverkeer uit de basisregistraties en/of waarneming met terugmelding vanuit het veld. Deze verschijnen op de werklijst van de beheerders. Bijhouden vanuit meldingen en mutaties (1) Uit basisreg Wijz. GBKN Hoofd infra wijz. K&L Wijz bluswaterv Boorput wijz Top 10 Vergunningswijziging BRW Gebruikswijziging Ontvangen mutatie Inspectie datum Adreswijziging / melding B&W bijz proc Controle op volledigheid, betrouwbaarheid en verwerkbaarheid Automatisch Filteren melding op relevantie Beoordelen relevenatie melding of mutatie voor DBK of inzetprocedure Figuur 12. Bijhouden vanuit meldingen en mutaties (1) 30/30

36 Bijhouden vanuit meldingen en mutaties (2) Kaart en / of inzetprocedure aanpassen (evt wanneer relevant) Terugmelden aan bronhouder (evt wanneer relevant) Relevante wijzigingen melden aan repressie Kaart en of procedure opslaan en vrijgeven voor publicatie Figuur 13. Bijhouden vanuit meldingen en mutaties (2) Signaleringslijst De beheerders hebben een signaleringslijst waarop alle meldingen verschijnen die mogelijk een nieuwe kaart of wijzigingen op een bestaande kaart tot gevolg kunnen hebben. Deze beheer lijst dient een filter te bevatten waarmee de beheerders zelf kunnen instellen welke meldingen wel en welke niet op de beheerlijst zullen verschijnen. De beheerlijst dient per element te tonen waar het bericht vandaan komt, wat de inhoud van de mutatie is en welk object het betreft. Het is een wens dat element met verschillende prioriteiten op de beheerlijst weergegeven moeten kunnen worden. Dit helpt om belangrijke wijzigingen met voorrang op te pakken. Een beheerder dient een element uit de beheerlijst aan te kunnen klikken en te bekijken of deze relevant is voor het brandweerdomein. Als een element niet interessant is kan hij de status van het bericht wijzigen in niet relevant. Hiermee verdwijnt het element van de beheerlijst. Een element kan ook gevolgen hebben voor de planvorming, als dit het geval is dient een beheerder een element te bewerken zoals staat omschreven in het maakproces. Zodra een element bewerkt is dient de status van het item op de beheerlijst op gereed gezet te kunnen worden. Hiermee verdwijnt het element van de beheerlijst Aangeven wijzigingen in het veld Een gedeelte van het beheer plaats in het veld. Inspectieteams en mensen van de uitruk (repressie), die aan het oefenen zijn, kunnen afwijkingen in het veld constateren. Deze dienen ter plekke digitaal ingetekend en naar de beheerafdeling doorgestuurd te kunnen worden. 31/31

37 6.1.3 Terugmelden aan bronhouders en repressie/inspectie Wanneer het melding of constatering betreft vanuit de eigen inspectie of repressie waarvan duidelijk is dat de data van de bronhouders niet correct is dan dit teruggemeld te worden aan de bronhouder. Er dient een mogelijkheid te zijn om door middel van een screenshotfunctie en/of een stukje van een kaartlaag of iets dergelijks dat wat niet correct is goed aan te kunnen geven. Dit bestand dient als bericht vergezeld met tekst en uitleg aan de bronhouder terug te kunnen gestuurd. Daarnaast is het voor repressie ook van belang om te horen wat er met de wijzigingen zijn gedaan die zijn ingebracht. Nadat de wijziging is beoordeeld en gekozen is wat ermee gedaan gaat worden dient dit (via ) teruggekoppeld te worden aan de inbrenger en andere belanghebbenden. Hiervoor is een beheerbare deels op geografie ingedeelde instellingentabel aanwezig. Het gaat hier om verzorgingsgebieden en bijbehorende adressen Meta-informatie en versiebeheer Meta-informatie over de berichten en versiegeschiedenis dient bijgehouden te worden. Het gaat dan om wie heeft berichten verwerkt en wat is er verder mee gebeurd en naar wie berichten zijn verstuurd en of er terugmelding is gedaan et cetera. De geschiedenis van voorgaande wijzigingen (maximaal vijf stappen) dient ook vastgehouden te worden. Metadata wordt overeenkomstig de geldende metadatastandaarden NEN/ISO / vastgelegd. Tabel 10. Eisen aan beheren Nummer van eisen BEH-1 BEH-2 BEH-3 BEH-4 BEH-5 BEH-6 Functionele eis Beheerlijst voor inkomende berichten uit bronhouders en repressie/inspectie Instelbaar filter in beheerlijst om alleen relevante berichten op de beheerlijst te laten verschijnen In beheerlijst of werklijst gedetailleerde berichtinformatie bekijken of visueel op kaart kunnen tonen door op een item te klikken Er dient prioritering in de items in de beheerlijst aangebracht te kunnen worden Bericht dient in persoonlijke werklijst ingeladen te kunnen worden. Hierin dient aangegeven te worden wat er met het bericht is gedaan. Als bericht in persoonlijke werklijst geladen verdwijnt deze uit de beheerlijst Applicatie dienen items bij objecten digitaal in te tekenen en in te sturen Hardheid eis 32/32