NVBR Programma van Eisen Digitale bereikbaarheidskaart 8 januari 2009 Concept 0.4
NVBR Stationsplein 1 Postbus 907 3800 AX Amersfoort Telefoon 033 4677777 www.twynstragudde.nl
Programma van Eisen Digitale bereikbaarheidskaart
Albert van Duijn Eric van Capelleveen Amersfoort, 8 januari 2009 504225/ADN/AKQ
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.
Inhoudsopgave
Voorwoord 1 1.1 1.2 1.3 1.4
Inleiding Aanleiding Positionering Programma van Eisen Leeswijzer Procedure met betrekking tot wijzigingen
1 1 1 2 2
2 2.1 2.2 2.2 2.2 2.2 2.2 2.3
Afbakening Architectuur Gegevenselementen Objectgegevens (groen) Preventieve gegevens (geel) Preparatieve gegevens (blauw) Repressieve gegevens (rood) Basisprincipes DBK
3 3 4 4 5 5 5 5
3 3.1 3.2
Algemene schermen en functionaliteit Opbouw hoofdscherm en achterliggende schermen Algemene functies
7 7 8
4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.8 4.8 4.9
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
11 11 12 13 14 15 16 17 19 20 20 22
5 5.1 5.2 5.2 5.2 5.3
Werkproces ‘Gebruiken’ en specifieke functionaliteit Proces ‘Gebruiken’ van de DBK Overkoepelende functionaliteit Navigatiefunctionaliteit Raadpleegfunctionaliteit Case
23 23 24 25 25 28
6 6.1 6.1 6.1 6.1 6.1 6.1 6.1 6.2
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
30 30 31 31 32 32 33 34 34
7 7.1 7.2
Aanvullende eisen Aanvullende eisen voor conversie naar DBK vanuit huidige dataformaten Eisen aan infrastructuur
36 36 36
8 8.1 8.1 8.1 8.1 8.1 8.1 8.2 8.2 8.2 8.2 8.2 8.2 8.3 8.3 8.3 8.3 8.3
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
39 39 39 40 40 40 41 41 41 42 42 43 43 43 43 44 44 44
1.
Bijlage 1: Gegevensset DBK en bronhouders
1
Inleiding
Voor u ligt het Programma van Eisen (PvE) voor de Digitale bereikbaarheidsKaart (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 worden1. 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
Deze cases zijn de basis, naast nog een aantal andere elementen, voor de POC2acceptatietoetsen 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 BAG3-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
[email protected] en vanaf 1juli 2009 aan
[email protected].
2
POC: Proof of Concept; er wordt in 2009 een POC gehouden
3
BAG: Basisregistratie Adressen en Gebouwen
2/2
2
2.1
Afbakening
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
IVS
?
GMS
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
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 RSGB4 en de Basisregsitraties omvatten. Daarvoor wordt verwezen naar de daartoe bestaande documenten vindbaar op www.ictu.nl, www.minbzk.nl en www.minvrom.nl 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.
2.2.1
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
- toegang terrein (inrit en obstakels) - gevel- en eventueel detailfoto. 2.2.2
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).
2.2.3
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).
2.2.4
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
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
3
Algemene schermen en functionaliteit
Dit hoofdstuk beschrijft de algemene functionaliteit die bij een DBKGIS-/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 Scherm
DBK Kopbalk
Kaart segment venster met verplaatsbalken
kaart orientatie venster Invoer A
Gege vens toon boom
Invoer B Invoer C Invoer D
TOETS 1
TOETS 2
DBK Bodembalk OS stuurbalk
Figuur 2. Elementen algemene scherm
7/7
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
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
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
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
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
Tabel 2. Eisen bij gebruik ondergrond Nummer van eisen OND-1
OND-2 OND-3 OND-4
4.3
Functionele eis
Hardheid 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
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
Tabel 3. Eisen bij zoeken object Nummer van eisen OBJ-1
OBJ-2
OBJ-3 OBJ-4
OBJ-5
4.4
Functionele eis
Hardheid 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
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 e rs me
tra
tra rks ke
at
at
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
21 -a 21 -b 21
-d 21
-c 21 -e 21 -g 21 -h 21
-f 21
-j 21
21-a 21-b
21
21-c
21-d
21-e 21-g
21-f
21-h
21-j
pikmeer pikmeer e me
rst
t raa
21
at tra o rks Sil ke o Sil 25
o Sil
21
23 25
23 25
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
Objecten onderling koppelen X,Y
21
21-a 21-b 21-c
21-d
21-e 21-f
21-g
Bouwlagen onderscheiden en koppelen in één geografisch geprojecteerd object
21-h 21-j JPG
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
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
[email protected] 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 RD5-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
Bij een blauw opstelpunt dient men verschillende WTS6-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 1000- 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 parkeerstrook
–
Opstelpunt
–
BHV
–
Controledatum
–
Communicatiebinnendekking
–
Ingang Brandweer, overige
–
Bluswaterriool
–
Brandcompartimentering
–
Droge stijgleiding, blusleiding
–
Zelfredzaamheid
21-g
–
Bouwlagen (hoogste laagste)
21-h
–
Brandmeldpaneel
–
Sleutelbuis/-kluis
–
Inzetprocedure
–
Bijzonderheden (overig)
21-a
Veld
X,Y 21
21-b 21-c
21-e
Sym bool X,Y
21-d
Gebouwcontour is drager symbolen en andere informatie Als deze verschuift, verschuift alles mee
21-f
21-j
Tekst/veldinformatie metadata
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
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 4.8
Functionele eis
Hardheid 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
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
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 email met als attachment een pdf-bestand - maken van een email met een link naar het object.
4.8.2
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
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
Hardheid 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 email met als bijlage een pdfbestand - maken van een email met een link naar het object Bij digitaal distribueren dient de gehele dataset of gewijzigde elementen vervangen kunnen worden
21/21
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
5
5.1
Werkproces ‘Gebruiken’ en specifieke functionaliteit
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
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 inprikpunt7 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 coordinatiestelselsystemen8. Tabel 6. Eisen aan overkoepelende functionaliteit gebruiken Nummer van eisen GEBR-1
Functionele eis
Hardheid eis
Applicatie dient berichtenverkeer met GMS9 te ondersteunen. De inhoud van dit berichtverkeer bestaat onder andere uit het doorgeven van: - icidentlocatie - incidentgegevens - actuele belemmeringen
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
Nummer van eisen GEBR-2
GEBR-3 GEBR-4 GEBR-5
5.2.1
Functionele eis
Hardheid 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
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
5.2.2
Functionele eis
Hardheid eis
Opstellen en wijzigen van navigatie naar incidentlocatie volgens de snelste route
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
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 Objectgegevens BMP Brandmeldpaneel Basisomgeving BHV Bedrijfshulpverlening Toegang terrein Sleutel buis/kluis Gebruikstype Brandcompartimenten Verblijf Bluswatervoorzieningen Bouwlagen Ingangen Stijg-/blusleidingen
Gegevens onder knop 3 Grote kabels en leidingen Bijzonderheden Inzetprocedure Opstelpunt Hoofdafsluiter Gevelfoto/360°-foto Communicatie binnendekking
Installaties Bouwconstructie
26/26
Gegevens onder knop 1 Gegevens onder knop 2 Gevaarlijke stoffen
Gegevens onder knop 3
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
3
1
2 1
Gebouwconstructie
Gebruikstype
Basis omgeving Toegang terrein
Verblijf
Bouw lagen
BMP
Brand compartimenten
BHV
Sleutel buis / kluis
Bijzonderheden
Gevaarlijke stoffen
Object gegevens Bluswater voorzieningen
Grote kabels en leidingen
DBK +
Opstelpunt
Aanvalsplan
Installaties
Stijg, blus leidingen Ingangen
2
Inzetprocedure
3
Hoofafsluiter Gevelfoto / 360° foto C2000 binnendekking
Aanrijdend eerste minuten Optioneel aanvullende informatie binnen eerste minuten
NVBR set
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
Tabel 9. Eisen aan viewfunctionaliteit Nummer van eisen GEBR-7
GEBR-8
GEBR-9
GEBR-10 GEBR-11
GEBR-12
GEBR-13 GEBR-14
5.3
Functionele eis
Hardheid 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: - 1 - 2 - 3 - brandweerknop - schuifknop Applicatie dient AVLS-berichten te kunnen ontvangen en verwerken Tonen van navigatiescherm in raadpleegdeel van applicatie
Case 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
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
6
6.1
Werkproces ‘Beheren’ en specifieke functionaliteit
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 Wijz bluswaterv
Hoofd infra wijz. K&L Boorput wijz Top 10
Vergunningswijziging Gebruikswijziging Adreswijziging
BRW Ontvangen mutatie
/ melding
Inspectie datum 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
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) 6.1.1
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.
6.1.2
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
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 email) 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 emailadressen.
6.1.4
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 19115 / 82045 vastgelegd.
Tabel 10. Eisen aan beheren Nummer van eisen BEH-1 BEH-2 BEH-3
BEH-4 BEH-5
BEH-6
Functionele eis
Hardheid 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
32/32
Nummer van eisen BEH-7 BEH-8
6.1.5
Functionele eis
Hardheid eis
Applicatie dient terugmeldfunctie naar bronhouders te bevatten Moet meta-informatie en geschiedenis van wijzigingen kunnen bijhouden: versiebeheer, mutatiegeschiedenis per persoon. Metadata volgens kerndataset
Beheer in relatie tot BAG De onderstaande BAG-gegevens worden bij de BAG betrokken en indien onjuist bevonden teruggemeld naar de BAG-beheerder. - Pand (ligplaats, standplaats): . pandidentificatie (gebouw–ID) . pandgeometrie (gebouwcontour) . datum begin geldigheid pandgegevens . pandstatus (zie onderstaande tabel) - Verblijfsobject: . verblijfsobject identificatie . verblijfsobject geometrie . gebruiksdoel verblijfsobject (uit bouwvergunning) . pandrelatering (hoort bij pand-ID) - Nummeraanduiding: . huisnummer . huisletter . huisnummertoevoeging . postcode . ID woonplaats . ID openbare ruimte - Openbare ruimte: . identificatie openbare ruimte . naam openbare ruimte . type openbare ruimte - Woonplaats: . woonplaatsidentificatie . woonplaatsnaam . woonplaatsgeometrie. Pand statussen: - bouwvergunning (VBN) - afzien van bouw (MAB) - start bouw (MSB) - bouw gereed (MGB) - ingemeten geometrie (BIG) - sloopvergunning (VSL)
33/33
6.1.6
sloop gereed (MGS) verbouw (WGV) samenvoegen/splitsen (SSV) onbewoonbaarheid (ONB) constatering nieuw (COG) calamiteit (VOC) terugmelding (TEG).
Beheer in relatie tot WABO De onderstaande WABO Omgevingsvergunningsgegevens worden bij de Omgevingsloket LVO betrokken en indien onjuist bevonden teruggemeld naar de Vergunningsbeheerder. Na gesprekken met WABO in januari 2009 toevoegen
6.2
Cases Case 3: Wijzigingen in infrastructuur Wijzigingen in de infrastructuur zoals een nieuwe 10KV-leiding, een nieuwe weg, een nieuwe parkeerstrook, zijn vaak wel snel waarneembaar, maar het kan even duren voordat deze elementen ook in de registraties K&L,Wegen en dergelijke en ondergronden verwerkt zijn. Tot die tijd worden ze als tijdelijke elementen opgenomen. Deze opname wordt teruggemeld aan de bronbeheerder van de K&L, Wegen en ondergrondregistraties. Tevens worden de tijdelijke elementen op een signaal lijst gezet die periodiek doorlopen wordt op het verwijderen van tijdelijke elementen. Automatische koppeling op basis van plek, vorm en identificerende gegevens is eveneens mogelijk.
Case 4: Wijzigingen in de WABO Wanneer in de WABO-gegevens bij de gemeente, of de milieu/omgevingsdienst) die namens de gemeente deze taken uitvoert, iets verandert aan de vergunningsvoorwaarden en de geëiste preventieve of preparatieve voorzieningen dan moeten die wijzigingen kenbaar worden en verwerkt worden. De brandweer ontvangt bericht van dergelijke veranderingen (hoe dat gaat verschilt nu nog per gemeente). In de DBK-applicatie moeten deze berichten van verandering kunnen worden ontvangen en verwerkt.
34/34
Case 5: Wijzigingen in de BAG Wijzigingen in de gebouwcontour worden als wijziging gemeld door de BAGbeheerder. De effecten daarvan moeten door de DBK-beheerder doorgrond worden door de DBK-gegevens naast/over de gewijzigde BAG-gegevens te leggen/projecteren.
Case 6: Wijzigingen brandweergegevens Wijzigingen in de brandweergegevens kunnen ontstaan door wijzigingen in regelgeving die nieuwe voorzieningen veroorzaken dan wel doordat de situatie is gewijzigd en feitelijk het maakproces van de DBK opnieuw wordt uitgevoerd, zij het oip een bestaande DBK.
Case 7: Wijzigingen vanuit de inspectie/constatering Tijdens inspecties en oefeningen door repressief personeel kunnen verschillen geconstateerd worden tussen wat op de DBK staat en wat men in werkelijkheid aantreft. Dat kunnen onjuist geplaatste symbolen (verkeerd geplaatst, verdwenen, wel aangetroffen niet op de kaart vermeld) zijn. In die gevallen moet men die symbolen kunnen toevoegen, verplaatsen, verwijderen, waarbij deze actie gelogd wordt (wie, wanneer). De vergunningsinformatie wordt NIET gewijzigd naar aanleiding van deze verschillen. In die gevallen waarin geconstateerd wordt dat de situatie niet meer correspondeert met wat op de kaart staat moet nagegaan worden of dit de omgeving betreft of het pand. Wanneer de omgeving niet juist is (verouderde ondergrond) zal een tijdelijk object moeten worden toegevoegd die de wijziging van de ondergrond representeert. Deze wijziging moet als terugmelding kunnen worden toegestuurd aan de beheerder van de ondergrond (veelal TOP10, GBKN enzovoort) De wijziging omvat een geometrische weergave die tevens gegeorefereerd (van x,y voorzien) is. Deze wordt als een tijdelijk object boven op de ondergrond geplaatst. Het object komt in de lijst van tijdelijke objecten, die na wijziging van de ondergrond weer verdwijnen.
35/35
7
7.1
Aanvullende eisen
Aanvullende eisen voor conversie naar DBK vanuit huidige dataformaten Voordat een korps kaarten maakt, beheert en gebruikt volgens de nieuwe werkprocessen met nieuwe applicaties dienen oude kaarten en oude datasets geconverteerd te worden om in de nieuwe applicaties gebruikt te worden. Om dit proces te ondersteunen is ervoor gekozen om de nieuwe applicatie ook functionaliteit mee te geven Tabel 11. Eisen aan conversie mogelijkheden Nummer van eisen AANV-1 AANV-2 AANV-3
7.2
Functionele eis
Hardheid eis
Batchgewijs verwerken van gegevens (import/export) Meest gangbare bestandsformaten (DWG, DGN, SID, DXF, SHAPE, CSV) Data moet geo-gerefereerd kunnen worden (RDstelsel)
Eisen aan infrastructuur De DBK-applicaties werken op een communicatienetwerk dat redundant en beveiligd is en dat de applicatie ook op mobiele platforms beschikbaar maakt. Dit kan op dit moment per brandweerkorps verschillen. De verwachting is dat hierin de komende jaren meer eenheid en connectiviteit tot stand gebracht zal worden. We specificeren hier alleen functionele eisen.
36/36
Infrastructurele voorzieningen brandweerdomein
Brandweer DBK in voertuig
bericht Uitval Kopie Server Ondergrond
synchronisatie bericht
bericht
bericht
Server Basisregistraties
Brandweerserver 24 x 7 Lage uitval
bericht
bericht
Server(s) Derden
bericht
bericht
Brandweer Tablet pc
bericht Brandweer DBK beheerder
Figuur 14. Infrastructurele voorzieningen Binnen het brandweerdomein (dat heel goed tevens een multi-domein kan zijn) dient een centrale server beschikbaar te zijn die de voor de DBK-applicatie benodigde gegevens (kaartlagen) die normaliter online opgevraagd worden bij de bronhouders, ook bij uitval van de systemen van deze bronhouders kan blijven serveren. Dit mogen enigszins verouderde data zijn. Er dient wel functionaliteit te zijn om partieel deze data te synchroniseren, door deze data vanaf een mediadrager (CD/DVD/USB stick) te laden of via een synchronisatieproces bij de verstrekkende bronhouder te betrekken. Dit synchronisatieproces mag niet ten koste gaan van de prestatie van de operationaliteit van de gebruikende DBK-applicaties. De DBK-gegevens worden vanaf de operationele brandweerserver voor beheer gekopieerd en bewerkt en na bewerking weer teruggeplaatst. De in bewerking zijnde gegevens blijven tijdens beheeractiviteiten voor gebruik beschikbaar. De brandweerserver kan tevens berichten van server van derden, van basisregistratiehouders en de (kaart)ondergrond houder ontvangen en in een wachtrij voor verwerking plaatsen. Tevens kan deze server de in de wachtrij voor verzending geplaatste berichten naar de bronhouders/derden verzenden. Voor deze verzending wordt van standaard emailprogrammatuur en de terugmeldingsprocedures van basisregistratiehouders gebruik gemaakt. Gegarandeerde verbindingtypen: - WIFI - GPRP - P2000/C2000.
37/37
Tabel 12. Eisen aan infrastructuur Nummer van eisen INFRA-1 INFRA-2 INFRA-3
INFRA-4 INFRA-5
INFRA-6
INFRA-7
INFRA-8
Functionele eis
Hardheid eis
Netwerk dient redundant, beveiligd en beschikbaar te zijn voor mobiele applicaties Centrale beschikbaar die in eerste instantie realtime bevraging doet bij de bronhouders Centrale server dient bij ontbreken toegang tot gegevens bronhouders gegevens te versturen op basis van de meest recente lokaal opgeslagen kopie Er dient (dagelijks) een lokale kopie gemaakt te worden en beschikbaar te zijn Het moet mogelijk zijn partieel data te synchroniseren op de server, door deze data vanaf een mediadrager (CD/DVD/USB-stick) te laden of via een synchronisatieproces bij de verstrekkende bronhouder te betrekken. Dit proces mag niet te koste gaan van de prestatie van de operationaliteit van de gebruikende DBK-applicaties De DBK-gegevens worden vanaf de operationele brandweerserver voor beheer gekopieerd en bewerkt en na bewerking weer teruggeplaatst. De in bewerking zijnde gegevens blijven tijdens beheeractiviteiten voor gebruik beschikbaar De brandweerserver kan tevens berichten van server van derden, van basisregistratiehouders en de (kaart)ondergrond houder ontvangen en in een wachtrij voor verwerking plaatsen. Tevens kan deze server de in de wachtrij voor verzending geplaatste berichten naar de bronhouders/derden verzenden. Voor deze verzending wordt van standaard emailprogrammatuur en de terugmeldingsprocedures van basisregistratiehouders gebruik gemaakt Het netwerk dient de volgende verbindingtypen te ondersteunen: - WIFI - GPRP - P2000/C2000
38/38
8
Berichtenverkeer
Er is berichtenverkeer met derden en er is berichtenverkeer binnen het brandweerdomein. De berichten weergegeven in onderstaande tabel dienen ondersteund te worden. Tabel 13. Overzicht berichtenverkeer Berichtenverkeer derden Terugmelding BAG Terugmelding WABO Terugmelding Ondergrond Terugmelding Bluswater Terugmelding RRGS/PRK Verzoek BAG Verzoek WABO Verzoek Ondergrond Verzoek Bluswater Verzoek RRGS/PRK
Berichtenverkeer binnen brandweerdomein Melding incident Melding ter plaatse (AVLS) Wijziging symbool Wijziging gegevens
Deze berichten worden tijdens de POC in 2009 nader gespecificeerd. We geven een eerste opzet. 8.1
Verzoeken om informatie Verzoeken om informatie zijn bedoeld om gegevens met één klik bij de bron te halen.
8.1.1
Verzoek BAG Betreft een verzoek tot opvragen van BAG-gegevens op basis van X,Y, adres, postcode + huisnummer of pand-ID. de pand-ID is dezelfde als die in de BAG; De X,Y kan afwijken van exacte X,Y die in de BAG is opgeslagen bij het pand maar zou redelijkerwijs binnen de pand geometrie vallen. Het adres kan afwijken van de exacte schrijfwijze die in de BAG is gehanteerd. Verwacht antwoord: - pand-ID - pand-geometrie - adres
39/39
- postcode - huisnummer compleet - woonplaats. 8.1.2
Verzoek WABO Omgevingsloket Betreft een verzoek tot opvragen van WABO-omgevingsvergunningsloket gegevens op basis van X,Y, adres, postcode+ huisnummer, pand-ID dan wel zaak-ID. Verwacht antwoord: - Pand-ID - Zaak-ID - aanvullen met WABO-gegevens. Na gesprekken met WABO in januari 2009 toevoegen
8.1.3
Verzoek BRO (ondergrond) Het betreft hier opvragen van gegevens uit de basisregistratie BRO over brandputten. De brandweer zal initieel ook veel gegevens gaan toeleveren die nog niet in de BRO zijn opgenomen. De aanvraag wordt gedaan op basis van een gebiedsaanduiding circa drie slanglengtes (60 meter) weg van de buitencontouren van het pand. (de pandgeometrie). Verwacht antwoord: - bekende brandput-ID - positie brandput X,Y in RD - laatst bekende capaciteit in m3/sec - laatste controledatum - status (nader te specificeren).
8.1.4
Verzoek VEWIN (bluswater) Het betreft het opvragen van bluswaterwinpunten (brandkranen) bij de waterdistributiebedrijven en particuliere beheerders. Er wordt een zoekvenster gedefinieerd 60 meter (3 slanglengtes) om de pandcontour heen. Verwacht antwoord: - bekende brandkraan-ID (brandkraannummer) - positie brandkraan X,Y in RD - laatst bekende maximumcapaciteit in m3/sec - laatste controledatum - atatus (nader te specificeren).
40/40
8.1.5
Verzoek PRK (risicokaart) Het betreft het opvragen van risico-informatie die vastgelegd is in het risicoregister en risicokaart ten behoeve van de gevaarzetting. In die situaties waarin de actuele hoeveelheden gevaarlijke stoffen en de aard daarvan sterk fluctueren wordt overeenkomstig het systeem in Rotterdam Rijnmond de actuele hoeveelheden opgevraagd. In de andere situaties wordt het PRK en RRGS bevraagd. Deze bestanden worden bijgehouden door het bevoegd gezag. Betreft een verzoek tot opvragen van BAG-gegevens op basis van X,Y, adres, postcode + huisnummer of pand-ID. De pand-ID is dezelfde als die in de BAG; De X,Y kan afwijken van exacte X,Y die in de BAG is opgeslagen bij het pand maar zou redelijkerwijs binnen de pand geometrie vallen. Het adres kan afwijken van de exacte schrijfwijze die in de BAG gehanteerd is. Verwacht antwoord: - object-ID PRK - pand-ID - adres - postcode - huisnummer compleet - woonplaats - gebruikstype Prevapcode - stof - maximumhoeveelheid. Nader afstemmen met PRK
8.2
Terugmeldingen Terugmeldingen zijn bedoeld om de kwaliteit van de registraties te kunnen borgen en te voorkomen dat aparte registraties van afwijkingen ontstaan die voortdurende herziening vragen.
8.2.1
Terugmelding BAG Doelstelling van dit bericht is de bronhouder BAG op de hoogte te stellen van geconstateerde verschillen ten opzichte van de BAG-registratie. Dit kan gaan om tijdelijke objecten die al door de brandweer zijn ingevuld en waarvoor later een BAG-object wordt uitgegeven. Het zal in de meeste gevallen gaan om een bestaand BAG-object waarvan in de praktijk afwijkende informatie is vastgesteld. Indien het een bestaand BAG-object is volgt het volgende bericht: - pand-ID - pandgeometrie
41/41
-
aard van de wijziging (in tekst) verzender van de terugmelding datum/tijd terugmelding link naar tijdelijk object DBK (??) aanvullen conform BAG-specificaties.
Indien het een tijdelijk object is waarvan geen BAG is bekend is (dat is dus eerst uitgevraagd via een verzoek BAG-bericht) volgt het volgende bericht - pand-ID - pandgeometrie - aard van de wijziging (in tekst) - verzender van de terugmelding - datum/tijd terugmelding - link naar tijdelijk object DBK (??) - aanvullen conform BAGspecificaties. Nader in te vullen in overleg met BAG 8.2.2
Terugmelding WABO Het betreft vaststelling van onjuiste gegevens die niet corresponderen met de gegevens verkregen uit de WABO/omgevingsloketdatabank. Het bericht bevat de volgende inhoud: - zaak-ID - pand-ID - aard van de wijziging (in tekst) - verzender van de terugmelding - datum/tijd terugmelding - link naar tijdelijk object DBK - aanvullen conform WABO-specificaties Na gesprekken met WABO in januari 2009 toevoegen
8.2.3
Terugmelding BRO Het betreft terugmeldingen aan de BRO over binnen de BRO niet bekende brandputten dan wel wijzigingen van gegevens van bestaande brandputten die door de brandweer ter plekke zijn geconstateerd. Het bericht bevat de volgende gegevens: - (on)ekende brandput-ID - positie brandput X,Y in RD - laatst bekende capaciteit in m3/sec - laatste controledatum - status (nader te specificeren) (nieuw of gewijzigd?) - aard van de wijziging (in tekst) - verzender van de terugmelding
42/42
- datum/tijd terugmelding. 8.2.4
Terugmelding VEWIN Het betreft terugmeldingen aan de VEWIN-partners (waterdistributiebedrijven) (en particuliere brandkraanhouders) over niet bij de VEWIN-partner bekende brandkranen dan wel wijzigingen van gegevens van bestaande brandkranen die door de brandweer ter plekke zijn geconstateerd. Het bericht bevat de volgende gegevens: - bekende brandkraan-ID (brandkraannummer) - positie brandkraan X,Y in RD - laatst bekende maximumcapaciteit in m3/sec - laatste controledatum - status (nader te specificeren) ) (nieuw of gewijzigd?) - aard van de wijziging (in tekst) - verzender van de terugmelding - datum/tijd terugmelding.
8.2.5
Terugmelding PRK Het betreft terugmeldingen aan de PRK-registratie over bij de PRK niet als juist geconstateerde informatie dan wel wijzigingen van gegevens van bestaande risico- en kwetsbare objecten die door de brandweer ter plekke zijn geconstateerd. Het bericht aan de PRK-beheerder bevat de volgende gegevens: - object-ID PRK - pand-ID - adres - postcode - huisnummer compleet - woonplaats - gebruikstype Prevapcode - aard van de wijziging (in tekst) - verzender van de terugmelding - datum/tijd terugmelding.
8.3
Berichten tussen de DBK-applicatie en andere applicaties We zien de volgende berichten tussen de DBK en andere applicaties ontstaan.
8.3.1
Melding incident Dit bericht wordt vanuit het meldkamersysteem GMS verzonden naar de DBKapplicatie en geladen in de DBK-applicatie op het aanrijdende voertuig, voor vertrek of tijdens het aanrijden. Wanneer het bericht niet aankomt kan de bevelvoeder handmatig dit bericht inbrengen in de DBK-applicatie. Het bericht bevat de volgende informatie:
43/43
8.3.2
incident-ID X,Y object-ID GMS OMS-ID pand-ID adres huisnummer (compleet) woonplaats aard van het incident datum/ijd melding meldkamer opschalingscode GRIP (nader afstemmen met bestaande GMS-koppeling).
Melding ter plaatse Dit is feitelijk een AVLS-functionaliteit.
8.3.3
Wijziging symbool In dit geval is een bestaand symbool uit de symbolenbibliotheek vervangen waardoor de DBK er anders uit zal gaan zien dan voorheen; het kan gaan om een nieuw symbool of vervanging van een symbool. Dit bericht wordt toegestuurd aan
[email protected] en bevat de onderstaande gegevens: - gebruiker-ID - brandweerkorps-ID - woonplaats - veiligheidsregio - oud symbool - nieuw symbool - reden wijziging - datum/tijd wijziging.
8.3.4
Wijziging gegevens Dit bericht wordt aangemaakt bij een wijziging ten behoeve van de wijzigingenlog. Indien het aard van bericht voldoet aan de doorstuurparameters (een door de beheerder in te stellen filter) wordt het bericht doorgestuurd naar de in de doorstuurtabel betrokken functionarissen (emails). Dit kunnen naar keuze collegapreventisten, -preparatisten, -centralisten en/of uitrukpersoneel zijn. De inhoud van het bericht luidt: - pand-ID - pandgeometrie - aard van de wijziging(en) (in tekst) - verzender van de kennisgeving - datum/tijd kennisgeving - link naar tijdelijk object DBK (??)
44/44
- bijgevoegd pdf-bericht - bijgevoegd url/link naar DBK-applicatie. De wijzigingen van één object worden samengevoegd in één bericht.
45/45
Bijlage 1: Gegevensset DBK en bronhouders
DBK-gegevens Objectkarakteristiek (gebruikscontour)(pand) (terrein) 6. Object-ID 8. Adres (+ X,Y) 9. Gebruikstype (prefab) 10. Bouwlagen (laagste, hoogste) 12. Verblijf aantal (max.GV. Bewoners, bezoekers, personeel/pand) 14. Zelfredzaamheid (bewoner, bezoeker/pand) 16. Gevel- en eventueel detailfoto Preventieve voorzieningen 18. Brandcompartimentering 19. Brandmeldpaneel 20. Automatische blusinstallatie 21. Rook en wamteafvoerinstallate 22. Overdruk-, stuwdrukinstallatie (parkeergarage, tunnel)
Bronhouder
Bron
Gemeente Gemeente Gemeente Gemeente
BAG BAG WOZ?/WABO? WABO WABO
Gemeente WABO Gemeente Brandweer/Comm.partij Gemeente
WABO WABO WABO WABO
Gemeente Gemeente Gemeente Gemeente
WABO Gemeente
Preperatieve voorzieningen 25. Brandkranen (capaciteit) 26. Open water (capaciteit) 27. Geboorde put (capaciteit, open en gesloten) 28. Bluswaterriool 29. Droge stijgleiding, blusleiding 30. Hoofdafsluiter
Drinkwatermaatschappij GBKN, waterschap TNO, externe leveranciers Gemeente Gemeente Gemeente
VEWIN BGT/GBKN BRO
Onderkende gevaren en inzetbijzonderheden 32. Gebouwconstructie 33. Gevaarlijke stoffen 34. Kabels en leidingen (groot)
Gemeente Rijk LV Kadaster
WABO? RRGS/ARK/zelf Kadaster KLIC
WABO WABO WABO
Bijlage 1
Luchtfoto’s Er loopt nu een offertetraject voor de uitvoering van een kosten-/batenanalyse (KBA) voor de jaarlijkse opdracht voor het maken van luchtfoto's voor de overheid. De verwachting is dat in het voorjaar van 2009 door het GI-beraad op basis van deze KBA-resultaten wordt besloten hoe met de landelijke verstrekking van luchtfoto’s omgegaan zal gaan worden. NB. de luchtfoto's van 2006 (niet de beste kwaliteit) zijn beschikbaar voor heel Nederland.
Bijlage 1
blad 2
