Rapport. Data Uitwisseling Specificatie:

Transcriptie

1 Bijlage 30 Rapport Data Uitwisseling Specificatie: Digitale Bereikbaarheidskaart waaronder Digitale Brandkraangegevens Redactie: Wilko Quak (Geonovum) Jaap Smit (Veiligheidsregio IJsselland) Input: DBK-leveranciers Projectleiders DBK veiligheidsregio s Eindredactie: Mark Luijten (NVBR) Status: voorlopig Versienummer: 2.2 Datum: 13 juni 2013

2 Document kenmerken In onderstaande tabel zijn de kenmerken van deze Data Uitwisseling Specificatie opgenomen. Titel Data Uitwisseling Specificatie: Digitale Bereikbaarheidskaart. Auteur Geonovum Datum Onderwerp Data Uitwisseling Specificatie voor Digitale Bereikbaarheidkaart en brandkraangegevens Uitgever Brandweer Nederland Type Tekst Beschrijving Dit document beschrijft de data uitwisseling specificatie voor data van de Digitale Bereikbaarheidskaart + Digitale Brandkraangegevens Bijdragen van Brandweer Nederland, BVIM Formaat Portable Document Format (pdf) Bron Brandweer Nederland, project DBK; BVIM Rechten Vrij van bijzondere belemmeringen op gebruik anders dan copyright. Identificatie DBK2.2.pdf Taal Nederlands Relatie Deze data uitwisseling specificatie is gebaseerd op de NEN 3610 data specificatie template Geldigheidsduur Projectduur en beheerfase Digitale Bereikbaarheidskaart Wijzigingshistorie Hieronder is de historie van dit document opgenomen. Versie Datum Aangepast door Aangepaste secties Omschrijving aanpassing(en) Jaap Smit, Wilko Quak Geheel Aanpassingen adhv commentaarronde Jan-Willem van Aalst Geheel Laatste vragen vanuit Rob Peters, Susan Stegeman Wilko Quak Geheel Aanpassing adv open vragen en telefoonconferentie en vervolgdiscussie Wilko Quak Geheel Aanpassingen adv aanpassingsvoorstellen Robert Kieboom 1.0b Paul Janssen Voorwoord, Vorige 1.0 versie had een verkeerd model scope, H Paul Janssen/Linda van den Brink/ Wilko Quak Geheel Aanpassingen adv commentaar formulier Data uitwisselingspecs_dbk_bk03.doc Opmerking: Op basis van dit document is een XSD gemaakt Paul Janssen Behandeling opm Brandweer Nederland/DBK Paul Janssen/ Linda Geheel Nav review Jan-Willem van Aalst, Eric van Capelleveen van den Brink Paul Janssen/ Linda Geheel van den Brink Paul Janssen Geheel Start op basis van PDOK DPS Template Blad: 2 / 38 Versiedatum: 13 juni 2013

3 Credits Ten minste de volgende personen hebben belangrijke inhoudelijke bijdragen geleverd aan dit document: Naam Wilko Quak Paul Janssen Linda van den Brink Rob Peters Jaap Smit Paul Geurts Robert Kieboom Ruud Awater Dennis Coppens Jan-Willem van Aalst Organisatie Geonovum Geonovum Geonovum CIO, Veiligheidsregio Kennemerland Informatiemanager GEO, Veiligheidsregio IJsselland Geo expert, Gemeente Nijmegen CityGIS Falck AVD Falck AVD Brandweer Nederland / BVIM Blad: 3 / 38 Versiedatum: 13 juni 2013

4 Voorwoord Dit document bevat een Data Uitwisseling Specificatie ten behoeve van de uitwisseling voor de voorziening Digitale Bereikbaarheidskaart. Integraal onderdeel daarvan is ook de uitwisseling van digitale gegevens van brandkranen en de kaartelementen/symbolen van de NEN1414. Het doel van deze data uitwisseling beschrijving is om aanvullend aan de metadata beschrijving van het dataproduct (conform ISO 19115) achtergrondinformatie te verstrekken over een data uitwisseling product. Waar de metadata de informatie op bestandsniveau beschrijft is de Data Uitwisseling Specificatie bedoeld om de gegevensstructuur en object definities te beschrijven. Op basis van de Data Uitwisseling Specificatie en de metadata van het dataproduct kan een eindgebruiker van de Digitale Bereikbaarheidskaart zich een goed beeld vormen van de data die door de dienst worden aangeboden en de data inhoudelijk interpreteren. Daarnaast geldt dat onderdelen van de Data Uitwisseling Specificaties nodig zijn ten behoeve van de inrichting van een regionaal knooppunt. Naast deze versie waarin de werkelijkheid zo goed mogelijk is gemodelleerd, is ook een vereenvoudigde versie beschikbaar waarin geen gekoppelde tabellen worden gebruikt. Blad: 4 / 38 Versiedatum: 13 juni 2013

5 Inhoudsopgave 1 Scope 6 2 Overview Fout! Bladwijzer niet gedefinieerd. 2.1 Naam en Acroniemen Informele beschrijving Definitie Referenties Normatieve referenties Totstandkoming Termen en definities Fout! Bladwijzer niet gedefinieerd. 2.6 Afkortingen Notatie van regels en aanbevelingen 10 3 Data content en structuur Algemene uitgangspunten Applicatie schema Objectcatalogus digitale Bereikbaarheidskaart 21 4 Referentiesystemen 35 5 Levering Leveringsmedium Fout! Bladwijzer niet gedefinieerd. 5.2 Formaten (encodings) WFS Fout! Bladwijzer niet gedefinieerd. 6 Visualisatie 37 7 Bibliografie 38 Blad: 5 / 38 Versiedatum: 13 juni 2013

6 Hoofdstuk 1 Scope Dit document beschrijft de data uitwisseling specificatie ten behoeve van de uitwisseling van de Digitale Bereikbaarheidskaart op het zogenaamde GIS-niveau, GIS-DBK. Integraal onderdeel daarvan is uitwisseling van digitale brandkraangegevens. Deze Data Uitwisseling Specificatie geeft de gedetailleerde beschrijving van structuur, inhoud data-inwinning en datakwaliteit van geo-informatie voor de Digitale bereikbaarheidskaart waaronder brandkraangegevens en dient als basis voor de realisatie van het berichtenverkeer. De data uitwisseling specificaties zijn specifiek gericht op de informatie-uitwisseling tussen de servers van de DBK infrastructuur. Een veiligheidsregio kan zelf bepalen of deze data uitwisseling specificatie ook wordt gebruikt tussen de regionale DBK-server en de aangesloten gebruiksapplicaties. Bij de totstandkoming van deze specificatie zijn de volgende uitgangspunten gehanteerd: De informatie die gemodelleerd wordt is de informatie die de bevelvoerder in de eerste drie minuten nodig heeft. De informatie beschrijft de gegevens die bedoeld zijn voor uitwisseling tussen de regio s. Gegevens die binnen een regio nodig zijn voor beheer worden dus niet opgenomen. Hoe de data uitwisseling is gespecificeerd en wordt gerealiseerd is geen onderwerp van deze specificaties. Uit het model zoals beschreven in dit document kan een automatisch een GML applicatieschema gegenereerd worden. Dit schema voldoet dan aan GML3.2. Voor implementatie in software is echter soms een eenvoudiger formaat nodig dan dit automatisch gegenereerde formaat. Dit vereenvoudigde model maakt geen deel uit van deze specificatie. Met het data- / informatie uitwisseling model is het ook mogelijk om een label te maken met daarin een verwijzing naar een digitale bereikbaarheidskaart als PDF-bestand (PDF-DBK). Dit maakt de transitie naar het nieuwe DBK eenvoudiger doordat na implementatie, de PDF-DBK s gefaseerd kunnen worden geconfereerd naar GIS-DBK. Blad: 6 / 38 Versiedatum: 13 juni 2013

7 Hoofdstuk 2 Overzicht Dit hoofdstuk beschrijft kenmerken van deze Data uitwisseling Specificatie. 2.1 Naam en Acroniemen Data uitwisseling specificatie voor data uitwisseling Digitale Bereikbaarheidskaart waaronder digitale brandkraangegevens. Digitale brandkraangegevens vormen een integraal onderdeel van de Digitale Bereikbaarheidskaart. Omdat in deze versie de brandkraangegevens voor de eerste keer als themagegevens zijn opgenomen wordt er in de titel uitdrukkelijk melding van gemaakt. 2.2 Informele beschrijving Definitie Digitale Bereikbaarheidskaart: Gegevens die onderdeel uitmaken van het berichtenverkeer voor bereikbaarheid van locaties ten behoeve van de brandweer. Digitale brandkraangegevens: Gegevens over brandkranen en waterleidingen voor levering aan de brandweer. Voortkomend uit de Brandweerwet Referenties De Digitale Bereikbaarheidskaart (DBK) omvat de informatie voor bereikbaarheid van locaties ten behoeve van de brandweer. Een twintigtal DBK servers met elk de bereikbaarheidsinformatie voor een afgesproken gebied vormen samen een landsdekkende databank en informatiesysteem. De individuele servers zijn via webservices benaderbaar voor een reeks van DBK applicaties en andere DBK dataservers. Tevens houdt de DBK server contact met de landelijke voorzieningen van relevante basisregistraties waarvan ze thematische informatie integreert. Op dit moment zijn dat de registraties BAG, BRO en BGT/GBKN. Andere bronnen van informatie betreffen de risicokaart (PRK) en de brandkraangegevens (VEWIN). De laatste vormen een speciaal belicht onderdeel in deze versie van de dataspecificaties. Ook de NEN1414 symbolenset maakt onderdeel uit van deze gegevensset. De onderstaande figuur geeft een beeld van de informatiestromen in en rond de Digitale Bereikbaarheidskaart. Blad: 7 / 38 Versiedatum: 13 juni 2013

8 Informatiestromen, berichtenverkeer, van en naar een server van de Digitale Bereikbaarheidskaart De data uitwisseling specificatie omvatten de beschrijving van de informatie zoals dat tussen de regionale servers wordt uitgewisseld. Voor de informatie-uitwisseling tussen de regionale server en de applicaties kan deze specificatie gebruikt worden maar dat is een keuze van de betreffende veiligheidsregio. Deze Data Uitwisseling Specificatie (DUS) is gebaseerd op de volgende documenten die een rol spelen bij de berichtendefinities van de digitale Bereikbaarheidskaart. Eindrapport IM-OOV,versie 1.0 (3 september 2008), Geonovum Specificatie berichtenverkeer DBK, concept 0.5 (4 mei 2009), Brandweer Nederland Programma van Eisen DBK dataserver, concept 0.3 (8 december 2009), Brandweer Nederland Digitale Brandkraangegevens, 0.9 definitief concept (17 december 2009), Brandweer Nederland, BVIM Standaardisatie Kaartsymbolen Operationele Informatievoorziening Veiligheidsregio s, 0.9, Brandweer Nederland, BVIM Conformiteitstoets DBK, conceptversie 2013 Prevap 2009 De in die documenten opgestelde definities worden in dit document geformaliseerd en gebracht in de voor Nederland geldende standaard voor het opstellen van dataspecificaties voor geoinformatie van een bepaald domein of sector. Voor het begrip van het doel dat met deze DUS beoogd wordt is een korte beschrijving van de achtergrond van de genoemde documenten van belang. Blad: 8 / 38 Versiedatum: 13 juni 2013

9 Eindrapport IMOOV Het informatiemodel voor de openbare orde en veiligheid is in 2008 opgesteld voor het uniformeren van geografische informatie binnen de sector Openbare Orde en Veiligheid. Doel daarvan is het verbeteren van de snelheid en kwaliteit van informatie uitwisseling tussen en binnen de OOV disciplines politie, brandweer, GHOR en gemeente. Het betreft daarbij informatie op operationeel niveau voor de bestrijding van incidenten, rampen. Daarbij is het IMOOV in de huidige versie beperkt tot drie ramptypen: brand in grote gebouwen, verkeersongeval op de weg, hoogwater. Het informatiemodel is afgestemd met NEN 3610:2011 en vormt de domeininvulling van de OOV voor het Nederlandse stelsel van geo-informatiemodellen. Het IMOOV is in 2008 opgeleverd met een beperking voor wat betreft het aantal ramptypen en de diepte van detailuitwerking voor specifieke inhoudelijke domeinen. Zo is er een koppelvlak met gegevens voor de Digitale Bereikbaarheidskaart dat nog niet verder ingevuld is. Programma van Eisen DBK dataserver Hierin worden de eisen geformuleerd waaraan de DBK dataservers moeten voldoen. Het programma van eisen geldt als specificatie voor de bouw van DBK dataservers. Het berichtenverkeer is op logisch niveau geformuleerd. De dataspecificaties die in het voorliggende document zijn opgenomen en de implementatie daarvan in XML schema s zijn een nadere uitwerking van het programma van eisen. Digitale Brandkraangegevens. Dit rapport geeft een analyse van de brandkraangegevens die aan de brandweer aangeleverd moet worden. Het rapport is daarmee de invulling van het thema bluswater van de DBK. Achtergrond van de levering van bluswatergegevens is de Brandweerwet die stelt dat de gemeente verantwoordelijk is voor de bluswatervoorziening. In die zin is de gemeente ook verantwoordelijk voor het verstrekken van de informatie over die voorzieningen. Op het terrein van de brandkranen zijn het vaak de drinkwaterbedrijven die in opdracht van gemeenten die voorzieningen onderhouden. Zij realiseren ook de informatievoorziening naar de brandweer. De informatie analyse is een eerste stap in de uitwerking van een formele dataspecificatie. Einddoel is het inrichten van een centrale voorziening, webservice, die functioneert als informatieloket tussen waterbedrijven, bronhouders, en loketten van veiligheidsregio s (operatiën /gebruikers). In het ontwerp van die voorziening wordt uitgegaan van afstemming met IMOOV en het landelijk project Invoering Digitale Bereikbaarheidskaart Normatieve referenties De volgende normen zijn van belang om dit document te kunnen lezen. NEN 3610:2011 Basismodel Geo-informatie IMOOV: 2008 Versie 1.0 NEN 1414:2007 Symbolen voor veiligheidsvoorzieningen op ontruimings- en aanvalsplattegronden Nederlands profiel op GML (in ontwikkeling) IMKL2006 v1.0. Informatiemodel Kabels en Leidingen BGT Gegevenscatalogus 2.1, 1 januari 2013 IMGeo Gegevenscatalogus 1.1, 1 januari 2013 Catalogus basisregistraties adressen en gebouwen, Versie 2009, VROM 1 Zie ook en Blad: 9 / 38 Versiedatum: 13 juni 2013

10 RDF (Resource Description Framework), zie SKOS (Simple Knowledge Organisation System), zie OWL (Ontology Web Language), zie De volgende lijst van normen is van toepassing op een dataproduct / -uitwisseling specificatie die opgesteld is conform NEN 3610 en die vindbaar is in een discovery service en ontsloten wordt middels een web map - en of web feature service. De Digitale Bereikbaarheidskaart conformeert zich waar van toepassing aan deze normen. Raamwerk van geo-standaarden 2.1 Nederlands profiel op ISO voor geografie. Versie 1.2 NEN 3610:2010 Basismodel Geo-informatie Nederlands WMS Profiel 1.1 Nederlands WMS - SLD Profiel 1.0 Nederlands WFS Profiel 1.0 Metadata profiel op ISO voor geografie, versie 1.2 Metadata standaard voor services op ISO 19119, versie Totstandkoming Deze specificatie is opgesteld door Geonovum en is gebaseerd op het NEN 3610 Data Product Specificatie Template. Document titel: Dataproduct specificatie Digitale Bereikbaarheidskaart en Brandkraangegevens Referentiedatum: Auteur: Geonovum Brandweer Nederland Taal: Nederlands 2.5 Afkortingen Lijst van afkortingen en acroniemen die worden gehanteerd in deze data specificatie. IMOOV: Informatiemodel openbare orde en veiligheid DBK: Digitale Bereikbaarheidskaart DB: Digitale Brandkraangegevens DUS: Data Uitwisseling Specificatie GML: Geography Markup Language XML: Extensible Markup Language 2.6 Notatie van regels en aanbevelingen Voor de Data Product / Uitwisseling Specificaties zijn een aantal regels verplicht (bijvoorbeeld gebruik van een bepaald referentiestelsel) en kunnen er ook aanbevelingen zijn. Om beide te duidelijke herkennen worden ze als onderstaand weergegeven in dit document Regel 1 Regels worden in deze stijl weergegeven Blad: 10 / 38 Versiedatum: 13 juni 2013

11 Aanbeveling 1 Aanbevelingen worden in deze stijl weergegeven Blad: 11 / 38 Versiedatum: 13 juni 2013

12 Hoofdstuk 3 Data content en structuur Dit hoofdstuk beschrijft het datamodel van de data uitwisseling. 3.1 Algemene uitgangspunten De volgende stereotypen worden gebruikt als onderdeel van het UML profiel. Stereotype Model element Description applicationschema Package Een applicatie schema volgens ISO en NEN featuretype Class Een geografisch object. datatype Class Een gestructureerd data type zonder identiteit. Enumeration Class Gesloten lijst van domeinwaarden. codelist Class Open lijst van domeinwaarden Blad: 12 / 38 Versiedatum: 13 juni 2013

13 3.2 Applicatie schema UML overzicht en toelichting De kern van het IMDBK bestaat uit brandweervoorzieningen (DBKVoorziening in Figuur 1) en objecten met een bereikbaarheidsplan (DBKFeature in Figuur 1). In volgende figuren worden de onderdelen verder uitgewerkt. DBKFeature +hoortbij 0..1 DBKVoorziening Figuur 1: Basisklasses van DBK Deze representeren verschillende voor de brandweer van belang zijnde voorzieningen en kunnen op de DBK gevisualiseerd worden als puntsymbool (DBKPunt), lijnobject (DBKLijn) of vlak (DBKVlak). Deze voorzieningen kunnen zelfstandig bestaan maar behoren soms ook toe aan een object waarvoor een bereikbaarheidsplan (DBKFeature) beschikbaar is. Wanneer dat het geval is kan het zo zijn dat de voorziening zelf geen geometrie heeft, in dat geval is het de verantwoordelijkheid van de GIS software om de voorziening ergens binnen de geometrie van de Feature te visualiseren. Voorbeeld: een gebouw waarvan bekend is dat er gevaarlijke stoffen liggen, maar waar geen locatie van de gevaarlijke stof bekend is. Blad: 13 / 38 Versiedatum: 13 juni 2013

14 DBKFeature + identificatie :NEN3610ID + BHVAanwezig :Boolean + bijzonderheid :CharacterString [0..*] + informelenaam :CharacterString [0..1] + inzetprocedure :CharacterString [0..1] +hoortbij 0..1 DBKVoorziening DBKObject + adres :Adres [1..*] + aantalbouwlagenbovengronds :Integer + aantalbouwlagenondergronds :Integer + automatischeblusinstallatietype :CharacterString [0..1] + gebouwgevaren :CharacterString [0..1] + gebouwnaam :CharacterString [0..1] + gebruikstype :PrevapCode + aanwezigheid :CharacterString [0..1] + risicoklasse :Risicoklasse [0..1] + bedrijfsnaam :CharacterString [0..*] DBKGebied + geometrie :GM_MultiSurface +pandgeometrie 1..* Pandgeometrie + pandid :CharacterString [0..1] + geometrie :GM_Surface Figuur 2 Overzicht van DBKFeature In Figuur 2 is de klasse DBKFeature verder uitgewerkt. Een aantal attributen is gedefinieerd, deze worden verder uitgewerkt in de objectcatalogus in paragraaf Er zijn twee verschijningsvormen van een DBKFeature: (1) een DBKOBject die altijd is gerelateerd aan 1 of meer BAGpanden en (2) een DBKGebied die niet direct is gerelateerd aan een pand maar wel een bereikbaarheidsplan heeft (bijvoorbeeld een natuurgebied met planvorming voor de bereikbaarheid en de bluswatervoorziening). Blad: 14 / 38 Versiedatum: 13 juni 2013

15 DBKVoorziening + typevoorziening :SymboolCode + label :CharacterString [0..1] DBKPunt + locatie :GM_Point [0..1] + aanvullendeinformatie :CharacterString + hoek :Real [0..1] DBKLijn + geometrie :GM_LineString DBKVlak + geometrie :GM_MultiSurface Bijlage + naam :CharacterString + URL :CharacterString ToegangTerrein + naamroute :CharacterString GevaarlijkeStof + naamstof :CharacterString + gevaarsindicatienummer :CharacterString + VNnummer :CharacterString + ERIC :CharacterString + hoeveelheid :CharacterString GeenBinnendekking + alternatievecomminfrastructuur :CharacterString + dekking :Boolean Figuur 3: Overzicht van DBKVoorziening In Figuur 3 is de klasse DBKVoorziening verder uitgewerkt. Iedere voorziening heef een attribuut typevoorziening waarin vastgelegd is wat voor voorziening het is. In de klassehiërarchie wordt daarna eerst opgesplitst naar de verschijningsvorm van de voorziening op de kaart (als punt, lijn of vlak). In het vervolg van de hiërarchie worden semantische subklasses beschreven met de mogelijkheid om extra attributen op te nemen (zoals het gevaarindicatienummer bij een gevaarlijke stof. Blad: 15 / 38 Versiedatum: 13 juni 2013

16 «datatype» Adres + huisletter: CharacterString + openbareruimtenaam: CharacterString + adresseerbarobjectid: CharacterString [0..1] + huisnummer: Integer + woonplaatsnaam: CharacterString + huisnummertoevoeging: CharacterString + postcode: CharacterString «datatype» NEN3610ID + namespace: CharacterString + lokaalid: CharacterString + versie: CharacterString [0..1] Figuur 4 Datatypes gebruikt in IMDBK In Figuur 4 zijn objectklassen van het stereotype <<datatype>> opgenomen; dit zijn gestructureerde verzamelingen van attributen zonder identiteit. Blad: 16 / 38 Versiedatum: 13 juni 2013

17 «codelist» SymboolCode TB TB TB Deze uitbreidbare lijst wordt beheerd in een codelist register. De inhoud van deze lijst is volgens 'Standaardisatie Kaartsymbolen'. «codelist» Prev apcode «enumeration» Risicoklasse laag middel hoog Deze lijst is onderdeel van het informatiemodel en is dus niet uitbreidbaar deze lijst wordt beheerd in een codelist register. De inhoud van deze lijst is volgens Handleiding PREVAP Figuur 5 Codelijsten gebruikt in IMDBK Voorgedefinieerde lijstjes met waardes zijn te vinden in Figuur 5. In dit figuur zijn twee soorten lijsten weergegeven: lijsten met het stereotype <<enumeration>> en lijsten met het stereotype <<codelist>>. Van een enumeration liggen de toegestane waardes volledig vast in het model en daarvan kan niet worden afgeweken bij uitwisseling. Bij een codelist maken de toegestane waardes geen deel uit van het model maar worden vastgelegd in een register. De exacte invulling van zo n register maakt geen deel uit van deze standaard. Bij uitwisseling zal de waarde van een codelist de vorm van een URL hebben. Blad: 17 / 38 Versiedatum: 13 juni 2013

18 Open issue: Op lange termijn moet over een register worden nagedacht. Op korte termijn kunnen de bekende waardes van de codelist in een annex worden gepubliceerd met daarbij de afspraak dat waardes buiten de lijst worden gecodeerd als: anders: xx. Brandkraan + identificatie: NEN3610ID + locatie: GM_Point + ondergronds: Boolean + capaciteit: Integer + spindeltype: CharacterString +leiding 0..1 Leiding + identificatie: NEN3610ID + geometrie: GM_LineString + diameter: Integer + materiaal: Characterstring [0..1] Figuur 6 Brandkraan- en leidinggegevens Het informatiemodel Brandkraan bevat 2 klasses: Brandkraan en Leiding (zie Figuur 6). Deze klasses beschrijven de informatie voor het uitwisselen van digitale brandkraangegevens zoals beschreven in het document: Digitale Brandkraangegevens. Deze gegevens worden beheerd door de VEWIN. Opmerking: de brandkraan en leiding gegevens worden beheerd door de verschillende Drinkwatermaatschappijen Identifier management Regel 1 In de dataspecificatie Digitale Bereikbaarheidskaart, hebben de objecten Brandkraan, Leiding en DBKFeature een unieke object-identificatie. Deze object-identificatie is conform de regels gedefinieerd in NEN De in deze DUS opgenomen object-identificatie, en identificatie-management is conform NEN 3610: De implementatie van deze regel in de DBK servers is waarschijnlijk niet vanaf stap 1 te realiseren. De regel is wel al opgenomen om daarmee een oplossing te bieden voor een landsdekkend uniform systeem van unieke object-identificatie binnen de DBK. Open issue: Voor deze problematiek is een kort- en een lange termijn oplossing nodig Welke objecten krijgen een unieke identifier Unieke identifiers worden gebruik bij het up-to-date houden van datasets. Ook maken unieke identifiers het mogelijk gegevens aan elkaar te linken; je kunt alleen naar iets verwijzen als het een unieke identifier heeft. Het hebben van unieke identifiers brengt beheerinspanning met zich mee: je moet bijhouden aan welke gegevens je welke identifier hebt gekoppeld en voor langere tijd garanderen dat je de gegevens die bij die identifier horen kunt terugvinden. In het huidige model heeft alleen de klasse DBKFeature een identifier (identificatie). Voor updates betekent dit dat als er één van de Brandweervoorzieningen die bij een DBKObject behoort, verandert het hele Object, dat opnieuw uitgewisseld moet worden. Ook is het lastig om bijvoorbeeld een losse collectie opstelplaatsen te maken, omdat deze alleen geïdentificeerd zijn in de context van de DBKFeature waar ze bij horen. Brandweer Nederland kiest voor een praktische tussenoplossing voor de korte termijn. Hierbij krijgt een aantal belangrijke elementen van een DBKFeature een eigen identifier. De lijst van welke elementen een verplichte identifier krijgen wordt nog vastgesteld. Er zijn een aantal niet- Blad: 18 / 38 Versiedatum: 13 juni 2013

19 verplichte unieke identifiers. Essentieel is dat de software de mogelijkheid biedt om met veel unieke identifiers of met Global Unique Identifier, GUID, te werken. Het onderhoud is dan eigen verantwoordelijkheid. 2 Oplossing op termijn: werken met namespace Hoe krijgen objecten een unieke identifier? De methodologie van NEN3610 houdt in dat er een nationaal namespace register komt waarin iedere organisatie die unieke identifiers uit wil delen een eigen unieke namespace krijgt. De combinatie van de namespace van de organisatie met de lokale identifier binnen die organisatie is dan nationaal uniek. Deze systematiek kan op verschillende manieren worden ingevuld: Er kan voor gekozen worden om één namespace IMDBK te registreren en daarna zelf voor unieke identifiers binnen deze namespace te zorgen. Een ander uiterste is om voor iedere veiligheidsregio en iedere maatschappij van de VEWIN een eigen namespace te registreren. In deze specificatie kiezen we voor het registreren van twee namespaces: nl.imdbk voor de het beheer van DBKObjecten en nl.vewin voor brandkranen en leidingen. Binnen deze twee namespaces worden als volgt unieke identifiers geconstrueerd Unieke identifiers binnen: nl.imdbk De objecten met voor de brandweer relevante gegevens zijn de DBKFeatures. De bereikbaarheidskaarten worden per veiligheidsregio beheerd en hebben binnen de regio een unieke identifer. Deze identifiers zijn uniek te maken door ze vooraf te laten gaan door het nummer van de veiligheidsregio. In totaal levert dit de volgende NEN3610ID op voor een DBKFeature Namespace = nog vast te stellen unieke benaming van de registratie van de DBK. Voorlopig voorstel: ( nl.imdbk ) LokaalID = Identifier binnen de regio voorafgegaan door het nummer van de regio met een.. Voorbeeld: In de brandweerregio Drenthe (dit is veiligheidsregio 03) is een DBKObject met id= xx42xx. Binnen IMDBK krijgt deze de volgende NEN3610ID: {namespace= nl.imdbk,lokaalid= 03.xx42xx. Opmerking: Oorspronkelijk was het plan om het OMSNummer als unieke identificatie te gebruiken, maar OMSNummers zijn afhankelijk van de producent van het meldsysteem en kunnen dus veranderen bij de aanschaf van een nieuw systeem zonder dat er sprake is van een nieuw DBKObject. Unieke identifiers voor Brandkranen en Leidingen Namespace = nog vast te stellen unieke benaming van de registratie van de DBK ( nl.vewin ) LokaalID = Brandkranen en leidingen worden beheerd door de VEWIN. De maatschappijen van de VEWIN geven brandkranen unieke nummers binnen hun maatschappij. Door de nummers vooraf te laten gaan door een afkorting van de maatschappij met een. ontstaan unieke nummers voor brandkranen en leidingen. 2 Voor de NEN1414 symbolen wordt vanuit een DBK werkgroep een voorstel voor unieke identifiers ingebracht in de NEN standaardisatiecommissie. Blad: 19 / 38 Versiedatum: 13 juni 2013

20 Voorbeeld: Voor een brandkraan van maatschappij XX ontstaat zo het volgende lokaalid: XX Opmerking: is voor een volgende versie waarbij de namespace optie wordt gebruikt. Achtergrond NEN3610ID De object-identificatie is voor externe referentie, identificatie van objecten (van buiten naar een object binnen een registratie) in tegenstelling tot de interne object-identificatie (binnen een registratie). Uitgangspunt is dat objecten uniek identificeerbaar zijn. Om dit te bereiken is de object-identificatie opgebouwd uit een landencode (conform ISO Landencodes, uniek op mondiaal niveau), een namespace waarmee de bronhouder/registratie wordt aangeduid (uniek binnen Nederland) en een interne object-identificatie (uniek binnen een registratie/bronhouder). Eventueel kan dit nog aangevuld worden door een uniek versienummer binnen één interne object-identificatie. NEN 3610 hanteert de volgende regels voor een identifier: Een IdentificeerbaarObject heeft een unieke object-object-identificatie binnen het domein van NEN De object-identificatie is voor identificatie van een object (een representatie in een database van een fenomeen in de werkelijkheid). De object-identificatie is niet voor identificatie van het fenomeen zelf. Object-identificatie is voor externe referentie van het object. De NEN 3610 object-identificatie wordt gepubliceerd door de bronhouder/beheerder en mag gebruikt worden voor externe object-identificatie. Binnen een registratie mag een interne objectidentificatie voorkomen die anders luidt en die bedoeld is voor unieke identificatie. Tijdens de hele levensloop (in een database) van een object blijft de object-identificatie gelijk. Objecten kunnen in hun levensloop van eigenschappen veranderen maar de object-identificatie blijft gelijk. De veranderingen worden dan bijvoorbeeld vastgelegd door de begin- en eindtijd. Als een attribuutwaarde verandert dan leidt dat tot een nieuwe versie. Versie object-identificatie is geen onderdeel van de unieke object-identificatie. Indien er verschillende versies van een object bestaan hebben die dezelfde namespace en lokaalid. Versies van een geo-object geven de ontwikkeling van een geo-object in zijn levensloop weer Modellering van object referenties (optioneel) Objecten verwijzen naar elkaar middels de URI van het object. Deze URI kan worden afgeleid van de unieke identifier. In deze versie wordt gekozen voor een praktische tussenoplossing waarbij gebruik wordt gemaakt van de eigen identifier per object. Blad: 20 / 38 Versiedatum: 13 juni 2013

21 Geometrie representatie (optioneel) De geometrie van objecten in het model beperkt zich tot het GML Simple Feature Profile zonder cirkelbogen Representatie van temporele informatie In het huidige model zijn geen temporele kenmerken opgenomen. Het is dus niet bekend sinds wanneer een object de DBK is opgeslagen. Voor het versturen van updates is het wel wenselijk deze gegevens op te nemen, zodat het mogelijk wordt een dataset up-to-date te houden door alleen de gewijzigde objecten te versturen. Omdat IMDBK de informatie beschrijft met de blik van de bevelvoerder (en niet de blik van de informatiebeheerder) zijn geen temporele kenmerken voor updates opgenomen in het model Objectcatalogus digitale Bereikbaarheidskaart Applicatie schema IMDBK Feature catalogus Table 3 - Feature catalogus metadata Naam van feature catalogus Scope Versienummer 0.1 IMDBK IMDBK Versiedatum Herkomst Definities Dataspecificatie IMDBK Table 4 - Types gedefinieerd in de feature catalogus Type Package Stereotypes Section Adres IMDBK «datatype» GeenBinnendekking IMDBK Brandkraan IMDBK Bijlage IMDBK DBKFeature IMDBK DBKGebied IMDBK DBKLijn IMDBK DBKObject IMDBK DBKPunt IMDBK DBKVlak IMDBK DBKVoorziening IMDBK GevaarlijkeStof IMDBK Leiding IMDBK NEN3610ID IMDBK «datatype» Pandgeometrie IMDBK PrevapCode IMDBK «codelist» Blad: 21 / 38 Versiedatum: 13 juni 2013

22 Type Package Stereotypes Section Risicoklasse IMDBK «enumeration» SleutelBuisKluis IMDBK SymboolCode IMDBK «codelist» ToegangTerrein IMDBK Geo object types GeenBinnendekking GeenBinnendekking Subtype van: Stereotypes: Op de DBK wordt aangegeven middels symbolen of er rekening gehouden moet worden met geen C2000 dekking in bijvoorbeeld ondergrondse parkeergarages, danwel alternatieve communicatie-infrastructuur die ter plekke in gebruik is. OPMERKING: Hiervoor is nog geen symbool opgenomen in het document 'Standaardisatie Kaartsymbolen'. Indien dit gebeurt, kan deze klasse wellicht opgenomen worden in Brandweervoorziening. DBKPunt Attribuut: alternatievecomminfrastructuur Attribuut: dekking Type: Boolean Brandkraan Brandkraan Herkomst: Omschrijving: Stereotypes: Digitale Brandkraan Brandweer Nederland Dit is een implementatie van de brandkraangegevens zoals beschreven in het document 'Programma van eisen digitale brandkraangegevens van de BVIM (versie 0.9) Attribuut: identificatie Type: NEN3610ID Unieke identificatie voor de Brandkraan volgens de NEN3610 methodiek Herkomst: Brandweer Nederland: Digitale brandkraangegevens Attribuut: locatie Type: GM_Point Locatie van de brandkraan in het Rijksdriehoeksstelsel Herkomst: Brandweer Nederland: Digitale brandkraangegevens Attribuut: ondergronds Type: Boolean Blad: 22 / 38 Versiedatum: 13 juni 2013

23 Brandkraan Ligging van de brandkraan. Omschrijving: Kan de waarde 'ondergronds' of 'bovengronds' hebben. Herkomst: Brandweer Nederland: Digitale brandkraangegevens Attribuut: capaciteit Type: Integer Capaciteit van de brandkraan in liters per minuut. Herkomst: Brandweer Nederland: Digitale brandkraangegevens Attribuut: spindeltype Spindeltype van de brandkraan. Omschrijving: OPMERKING dit veld is nu een tekstveld. Wanneer er een beperkt aantal toegestane waardes bekend is kan dit nog aangescherpt worden door er een codelist van te maken. Voorkeurswaarde: centraal decentraal Herkomst: Brandweer Nederland Bijlage Bijlage Subtype van: Omschrijving: Stereotypes: DBKPunt Foto s of PDF bestanden worden toegepast om de situatie te verduidelijken middels beelden. Dit beeld geeft een indruk van de aard van het gebouw. Afhankelijk van het type gebouw kunnen detailfoto s worden gebruikt om de aanwezigheid van het brandweerpaneel of inzetbijzonderheden te duiden. Dit wordt middels een symbool op de foto getoond. Attribuut: naam Naam van het fotobestand. Omschrijving: Toegestane bestandtypen zijn: TIFF, GeoTIFF, JPG, PNG, BMP, SVG, EPS Attribuut: URL Pad/link naar het fotobestand. DBKFeature DBKFeature (abstract) Stereotypes: Voor de brandweer relevant object(voor DBK: één of meer gebouwen)met alle gegevens(basis, object, preventief, preparatief en repressief) die op een bereikbaarheidskaart getoond worden. Attribuut: identificatie Blad: 23 / 38 Versiedatum: 13 juni 2013

24 DBKFeature (abstract) Type: NEN3610ID Unieke identificatie van het object binnen de context van NEN3610. Herkomst: NEN3610:2010 Attribuut: BHVAanwezig Type: Boolean Aanduiding of er bij het betreffende object Bedrijfshulpverlening aanwezig is. Attribuut: bijzonderheid Een tekstuele toelichting die informatie bevat die niet elders benoemd is. De betreffende brandweerkorps veiligheidsregio bepaalt in hoeverre er bijzonderheden van toepassing zijn op object dat onderwerp van de DBK is. Multipliciteit: 0..* Attribuut: informelenaam Eventuele informele, in het spraakgebruik bestaande naam van het object of het gebied. Multipliciteit: 0..1 Attribuut: inzetprocedure Het gebruik van een afgesproken werkwijze. De betreffende veiligheidsregio bepaald in hoeverre er bijzonderheden van toepassing zijn op object dat onderwerp van de DBK is Omschrijving: Voorbeelden: Offensieve buitenaanval. Procedure complexe gebouwen. Gevaarlijke stoffen procedure (voor specifieke ruimten) Multipliciteit: 0..1 DBKGebied DBKGebied Subtype van: Omschrijving: Stereotypes: DBKFeature gerelateerd aan een gebied. DBKFeature DBKGebieden zijn DBKFeatures die niet direct gerelateerd zijn aan een pand maar die wel een bereikbaarheidsplan kunnen hebben (met doorganghekken / sleutelkluizen). Een ander voorbeeld is een autosnelweg die voor bereikbaarheid en watervoorziening planvorming heeft. Dit is ook een gebied, zonder dat er planvorming voor specifieke gebouwen aanwezig is. Attribuut: geometrie Type: GM_MultiSurface Geometrie van het betreffende DBKGebied DBKLijn DBKLijn Blad: 24 / 38 Versiedatum: 13 juni 2013

25 DBKLijn Subtype van: Stereotypes: DBKVoorziening Attribuut: geometrie Type: GM_LineString DBKVoorziening met lijnvormige geometrie DBKObject DBKObject Subtype van: Stereotypes: DBKFeature gerelateerd aan 1 of meer panden in de BAG. DBKFeature Attribuut: adres Type: Adres Adressering van het pand volgens de NEN3610 ID. Dus het onderdeel "localid" wordt dan de BAG ID van het adresseerbare object. (indien geen verblijfsobject: BAG ID van het pandobject). Zie ook pagina 32...* Attribuut: aantalbouwlagenbovengronds Type: Integer Aantal bouwlagen bovengronds. Omschrijving: Een gebouw zonder verdieping heeft één bouwlaag. Het grondpeil wordt bepaald door het niveau bij de hoofdingang (Bouwbesluit). Attribuut: aantalbouwlagenondergronds Type: Integer Aantal bouwlagen ondergronds.een gebouw met één kelderverdieping heeft één bouwlaag ondergronds. Het grondpeil wordt bepaald door het niveau bij de hoofdingang (Bouwbesluit). Attribuut: automatischeblusinstallatietype het soort automatische blusinstallatie(s). Een installatie voor het automatisch detecteren en blussen van een brand of explosie. Voorbeelden: aerosolinstallatie, gasblusinstallatie, nevelblusinstallatie, sproeiïnstallatie, schuiminstallatie, sprinkler Multipliciteit: 0..1 Attribuut: gebouwgevaren Extra informatie over de gevaren die verband houden met de gebouwconstructie. Omschrijving: Deze informatie wordt alleen weergegeven indien de constructie potentieel gevaar bij inzet oplevert. Voorbeelden zijn: een rieten kap, houten vakwerk spanten, houten spanten, metalen trekspanten, onvolledige brandcompartimentering. Multipliciteit: 0..1 Attribuut: gebouwnaam Blad: 25 / 38 Versiedatum: 13 juni 2013

26 DBKObject De formele gebouwnaam van het object, afkomstig uit bouwvergunningen die door de gemeenten worden verstrekt. Multipliciteit: 0..1 Attribuut: gebruikstype Type: PrevapCode De aard van het gebruik van het object volgens Prevap codering. Attribuut: aanwezigheid Tekstuele omschrijving van aanwezige personen volgens de verbruiksvergunning, onderverdeeld in bewoners, bezoekers en personeel per pand weer. Indien dit variabel is in de tijd, wordt dit middels tijdvakken vermeld. Indien de zelfredzaamheid van bewoners, bezoekers en personeel beperkt is, wordt dit eveneens via aantallen vermeld. Dit is een tekstuele aanduiding op de DBK (in de tabel naast het kaartbeeld of als tekstlabel in de kaart). Multipliciteit: 0..1 Attribuut: risicoklasse Type: Risicoklasse De risicoklasse op basis van de Leidraad Inventarisatie veiligheidsaspecten bij repressief optreden Object Risico Analyse, versie oktober 2006 van de NVBR Multipliciteit: 0..1 Attribuut: bedrijfsnaam Eventuele informatie, de naam van het bedrijf/de bedrijven dat/die in het object is/zijn gevestigd. Multipliciteit: 0..* DBKPunt DBKPunt Subtype van: Omschrijving: Stereotypes: Attribuut: locatie Type: Verzamelobject voor verschillende voor de brandweer van belang zijnde voorzieningen die als symbool op de kaart worden getoond. DBKVoorziening Voorbeeld: Soort punt: (toegang terrein) vaste paal, verwijderbare paal, beweegbare paal, trappenhuis, BHV-verzamelplaats, brandweerlift, brandmeld-, nevenpaneel, automatische blusinstallatie, rook- en warmteafvoerinstallatie, brandweer- en overige ingangen, sleutelbuis, -kluis, WTS-loxcatie, geboorde put, bluswaterriool, droge stijg-, blusleiding, hoofdschakelaar, -afsluiter elektra, neon, gas, water, geen C2000 binnendekking, opstelpunt eerste en overige brandweervoertuigen, gebouwgevaren, laag- en hoogspanningruimte, bijzonderheden, gevaarlijke stof GM_Point Locatie van deze voorziening op de kaart. Blad: 26 / 38 Versiedatum: 13 juni 2013

27 DBKPunt Omschrijving: Indien er op de kaart geen plaats is op deze locatie om het symbool te tekenen is het de verantwoordelijkheid van het GIS systeem om een alternatieve locatie voor het symbool te vinden. Multipliciteit: 0..1 Attribuut: aanvullendeinformatie Aanvullende informatie voor het symbool Omschrijving: Bijvoorbeeld: 'Onder het luik', 'Bovenaan de trap' en 'Derde verdieping'. Attribuut: hoek Type: Real hoek in graden waaronder het label geplaatst wordt. Eenheid: graden, rechtsom draaiend ten opzichte van het Noorden. rechtsom = positief. Multipliciteit: 0..1 DBKVlak DBKVlak Subtype van: Stereotypes: DBKVoorziening Attribuut: geometrie Type: GM_MultiSurface Geometrie van de scheiding DBKVoorziening DBKVoorziening (abstract) Stereotypes: Attribuut: typevoorziening Type: SymboolCode De aard van de voorziening gebruik makend van een NEN1414 Code uit een register. Hieruit valt een symbool af te leiden. Praktische tussenoplossing: niet voor alle objecten zijn symbolen opgenomen in NEN1414. Regionaal kunnen andere objecten worden weergegeven met een eigen symbool waarbij regionaal een eigen code voor wordt gemaakt die begint met het regionummer. Attribuut: label Eventuele informatie, gebouwnaam, bereikbare ondergrondse en bovengrondse bouwlagen per brandweerlift en per trappenhuis Omschrijving: Voorbeeld: -1 / +4 Multipliciteit: 0..1 Association role: hoortbij Type: DBKFeature Multipliciteit: 0..1 Blad: 27 / 38 Versiedatum: 13 juni 2013

28 GevaarlijkeStof GevaarlijkeStof Subtype van: Omschrijving: Stereotypes: Gevaarlijke stoffen zijn stoffen waarvan gebruik, transport of opslag risico s met zich meebrengen. Deze risico s kunnen zijn explosiegevaar, brand, giftigheid of radioactiviteit. DBKPunt Voorbeelden van gevaarlijke stoffen zijn brandstoffen, grondstoffen voor medicijnen, kunststoffen en kunstmest, of hulpstoffen voor koelen, reinigen of conserveren. Gevaarlijke stoffen worden zowel geografisch als tekstueel weergegeven op de DBK. De locatie van de gevaarlijke stoffen wordt door middel van een puntsymbool op het betreffende object weergegeven. Daarnaast wordt in een tekstuele toelichting aangegeven om welke gevaarlijke stof het gaat en wat de gevaarsindicatienummer (GEVI code) is. Attribuut: naamstof Naam van de gevaarlijke stof. Attribuut: gevaarsindicatienummer GEVI code van de gevaarlijke stof Attribuut: VNnummer Stofidentificatienummer volgens systematiek van de Verenigde Naties. Omschrijving: Het formaat van dit tekstveld wordt afgebakend met een reguliere expressie: [0-9][0-9][0-9][0-9]. Attribuut: ERIC Code volgens Emergency Response Intervention Cards (ERIC). Omschrijving: Informatiesysteem voor de bevelvoerder over de te nemen maatregelen bij gevaarlijke stoffen. Attribuut: hoeveelheid Indicatie van de hoeveelheid aanwezige gevaarlijke stof. Leiding Leiding Stereotypes: Attribuut: identificatie Type: NEN3610ID Unieke identificatie voor de Leiding volgens de NEN3610 methodiek Blad: 28 / 38 Versiedatum: 13 juni 2013

29 Leiding Herkomst: Brandweer Nederland: Digitale brandkraangegevens Attribuut: geometrie Type: GM_LineString Ligging van de leiding Attribuut: diameter Type: Integer Buitendiameter van de leiding in millimeters. Attribuut: materiaal Type: Characterstring Materiaalsoort van de leiding Multipliciteit: 0..1 Pandgeometrie Pandgeometrie Omschrijving: Stereotypes: Object waarin het pandid samen met de geometrie van een BAG Pand wordt opgeslagen. In voorkomende gevallen kan het gebeuren dat in IMDBK een andere geometrie is opgenomen dan in de BAG. Of dit het geval is, en wat er moet gebeuren als in de BAG de geometrie wijzigt, kan worden aangegeven in het veld bagstatus. Attribuut: pandid Id van het gerelateerde BAGPand Omschrijving: De waarde van dit attribuut mag alleen null zijn als het attribuut bagstatus de waarde 'aanvullend' heeft. TODO: Wanneer een pand nog niet bekend is bij de BAG en er toch een geometrie in IMDB zit (met bagstatus 'aanvullend') kan het zijn dat dit object wel een ID heeft in IMDBK. Hoe hiermee om te gaan is nog niet vastgelegd. Multipliciteit: 0..1 Attribuut: geometrie Type: GM_Surface Geometrie van BAGPand met gegeven pandid SleutelBuisKluis SleutelBuisKluis Subtype van: Stereotypes: DBKPunt Attribuut: nummer Type: Number Multipliciteit: 0..1 Blad: 29 / 38 Versiedatum: 13 juni 2013

30 ToegangTerrein ToegangTerrein Subtype van: Stereotypes: Obstakels, zoals toegangspoorten, hekken, muren en slagbomen. DBKLijn Attribuut: naamroute naam van deze route Data types Adres Adres Stereotypes: «datatype» Attribuut: huisletter Een door het bevoegde gemeentelijke orgaan ten aanzien van een adresseerbaar object toegekende toevoeging aan een huisnummer in de vorm van een alfanumeriek teken. Herkomst: BAG Attribuut: openbareruimtenaam Een door het bevoegde gemeentelijke orgaan aan een OPENBARE RUIMTE toegekende benaming. Herkomst: BAG Attribuut: adresseerbarobjectid Multipliciteit: 0..1 Attribuut: huisnummer Type: Integer Een door het bevoegde gemeentelijke orgaan ten aanzien van een adresseerbaar object toegekende nummering. Herkomst: BAG Attribuut: woonplaatsnaam De door het bevoegde gemeentelijke orgaan aan een WOONPLAATS toegekende benaming. Herkomst: BAG Attribuut: huisnummertoevoeging Blad: 30 / 38 Versiedatum: 13 juni 2013

31 Adres Een door het bevoegde gemeentelijke orgaan ten aanzien van een adresseerbaar object toegekende nadere toevoeging aan een huisnummer of een combinatie van huisnummer en huisletter. Herkomst: BAG Attribuut: postcode De door TNT Post vastgestelde code behorende bij een bepaalde combinatie van een naam van een woonplaats, naam van een openbare ruimte en een huisnummer. Omschrijving: Type wordt met een reguliere expressie afgedwongen: '[0-9][0-9][0-9][0-9] [A- Z][A-Z]'. Herkomst: BAG NEN3610ID NEN3610ID Herkomst: Omschrijving: Stereotypes: Identificatiegegevens voor de universeel unieke identificatie van een object. NEN3610:2011 De combinatie van namespace van een registratie, lokale identificatie en versie informatie maken een object uniek identificeerbaar. Met de informatie van deze klasse kun je daardoor met zekerheid verwijzen naar het geïdentificeerde object. «datatype» Attribuut: namespace Unieke verwijzing naar een registratie van objecten. Omschrijving: Het attribuut namespace is een unieke verwijzing naar de registratie die de identificatie uitdeelt. Deze lijst van registraties wordt beheerd door de beheerder van NEN3610. Binnen Nederland zal deze namespace vrijwel altijd met NL. beginnen. De volgende karakters mogen in een namespace aanduiding voorkomen: { A Z, a z, 0 9, _, -,,,. } Herkomst: NEN3610:2011 Attribuut: lokaalid Unieke identificatiecode binnen een registratie. Omschrijving: Locaalid is de identificatiecode die een object heeft binnen een (lokaal) registratie. De volgende karakters mogen in een lokaalid voorkomen: { A Z, a z, 0 9, _, -,,,. } Herkomst: NEN3610:2011 Attribuut: versie Type: CharacterString Versieaanduiding van een object. Blad: 31 / 38 Versiedatum: 13 juni 2013

32 NEN3610ID Omschrijving: Het attribuut versie maakt geen deel uit van de identificatie van het object maar kan gebruikt worden om verschillende versies van hetzelfde object te identificeren. Multipliciteit: 0..1 Herkomst: NEN3610:2011 Enumeraties en codelijsten Risicoklasse Risicoklasse Herkomst: Stereotypes: Mogelijke risicoklasses volgens: 'Leidraad inventarisatie veiligheidsaspecten bij repressief optreden'/ Brandweer Nederland «enumeration» Waarde: laag Waarde: middel Waarde: hoog PrevapCode PrevapCode Lijst van Prevap codes zoals beschreven in: Handleiding PREVAP 2009 Stereotypes: «codelist» Governance: Uitbreidbaar Waarde: 1100 Waarde: 1200 Waarde: 1300 Waarde: 1500 Waarde: 1600 Waarde: 1700 Waarde: 1800 Waarde: 2100 Waarde: 2200 Tehuis Klooster / abdij Woongebouw met inpandige gangen Woning met zorg Woning (bedrijfsm./complex) niet zelfredzaam Bejaardenoord/ verzorgingshuis Kamerverhuur Kinderdagverblijf Peuterspeelzaal Waarde: 2300 Blad: 32 / 38 Versiedatum: 13 juni 2013

33 PrevapCode Theater, schouwburg, bioscoop, aula Waarde: 2400 Museum, bibliotheek Waarde: 2500 Buurtjuis, ontmoetings-, wijkcentrum Waarde: 2600 Gebedshuis Waarde: 2700 Tentoonstellingsgebouw Waarde: 2800 Kantine Waarde: 2900 Café, discotheek, restaurant Waarde: 2999 Overig gebouw met bijeenkomstfunctie Waarde: 3100 Gevangenis Waarde: 4100 Gezondheidsdienst Waarde: 4200 Kliniek (poli-, psychiatr.,...) Waarde: 4300 Ziekenhuis Waarde: 4400 Verpleegtehuis Waarde: 5110 Fabriek Waarde: 6110 Kantoor Waarde: 7100 Hotel Waarde: 7200 Pension / nachtverblijf Waarde: 7300 Dagverblijf (kinderen / gehandicapten) Waarde: 8100 School (leerling < 12 jaar) Waarde: 8200 School (leerling > 12 jaar) Waarde: 9100 Gymzaal, studio (ballet bv.) Waarde: 9200 Blad: 33 / 38 Versiedatum: 13 juni 2013

34 PrevapCode Waarde: 9300 Waarde: Waarde: Waarde: Waarde: Waarde: Waarde: Waarde: Waarde: Waarde: Sporthal, stadion Zwembad Winkel Studio (opname bv. TV) Stationsgebouw Overige gebruiksfunctie Loods, veem, opslagplaats Garage-inrichting (alleen opslag, stalling) Kampeerterrein / jachthaven Markt Tijdelijk bouwsel SymboolCode SymboolCode Omschrijving: Stereotypes: Governance: Lijst van symboolcodes van kaartsymbolen. OPMERKING Deze lijst zal een lijst symboolcodes bevatten zoals beschreven in 'Standaardisatie Kaartsymbolen'. «codelist» Uitbreidbaar Waarde: TB Droge buisleiding afnamepunt Waarde: TB Droge buisleiding voedingspunt Waarde: TB Sleutelkluis / Sleutelbuis Blad: 34 / 38 Versiedatum: 13 juni 2013

35 Hoofdstuk 4 Referentiesystemen RD-NAP-coördinaat-referentiesysteem (binnen de Nederlandse kustlijnen). Hiervoor geldt dat de gebruikte horizontale datum Bessel 1841 is en het coördinaatsysteem de stereografische projectie. Als verticale datum wordt het NAP-vlak gebruikt. Voor RD geldt EPSG code: Voor RD + NAP geldt EPSG code: 7415 Blad: 35 / 38 Versiedatum: 13 juni 2013

36 Hoofdstuk 5 Levering Dit hoofdstuk beschrijft hoe het data uitwisseling wordt uitgeleverd. 5.1 Leveringsmedium Er zijn verschillende leveringstrajecten. Tussen bronhouder en de regionale voorziening en tussen regionale voorziening en eindgebruiker. Voorlopig is er voor beide trajecten een actuele situatie die niet gelijk is aan de gewenste doelsituatie van een webservice gebaseerde infrastructuur. Er is dus sprake van een groeipad. Op dit moment is er een variëteit in media waarop data uitgeleverd kunnen worden. Voor deze DUS wordt alleen de doelsituatie beschreven waarbij een combinatie van SOAP en WFS van toepassing is. Het betreft daarbij het berichtenverkeer voor het operationeel gebruik van de DBK servers. De protocollen en structuur van het berichtenverkeer is niet in de DUS opgenomen. Er wordt daarvoor verwezen naar de specificaties van de verschillende onderdelen zoals opgenomen in het document Programma van Eisen DBK dataserver. Uiteindelijk zijn webservices in zowel WMS als WFS formaat gewenst. Voor de download services van geodata wordt geconformeerd aan het Raamwerk voor geoinformatie standaarden en de daarin gerefereerde normen: Nederlands WFS Profiel 1.0; Metadata profiel op ISO voor geografie, versie 1.2; Metadata standaard voor services op ISO 19119, versie Formaten encoding (WFS) Voor deze dataspecificaties is een GML implementatie gemaakt. Het format van de uitwisselingsdata is GML. Hiermee is de DUS conform het Raamwerk van geostandaarden versie 2.1. Hiervoor zijn voor deze data uitwisselingspecificaties de volgende XML/GML schema s beschikbaar. Applicatie Schema naam: imdbk.xsd Versie: 1.1RC Versie GML: GML Schema s van gml 3.2.1: Blad: 36 / 38 Versiedatum: 13 juni 2013