- Beschreven welke stukken uit BAGdocumentatie relevant zijn in 4.1. - Locatie TNO test informatieverzoekdienst is opgenomen in paragraaf 4.3.4 - De eerste informatie over de specificaties over brandkranen is opgenomen in paragraaf 4.4 Berichtspecificaties opgenomen voor terugmelden aan de TMF onder paragraaf 3.3
De gehele BAG-documentatie is als bijlage toegevoegd.
0.5
Albert van Duijn Eric van Capelleveen Amersfoort, 5 mei 2009 515372/ADN/AKQ
Inhoudsopgave
1 1.1 1.2 1.3 1.4 1.5
Inleiding Soort bericht Specificatie per bericht Bronhouders Status berichtspecificatie Leeswijzer
3 3 5 6 7 9
2 2.1 2.2
Notificatieberichten Notificatieverzoek BAG Notificatieverzoek BGT/GBKN
11 11 11
3 3.1 3.2 3.3 3.3 3.3 3.3 3.3 3.3 3.4
Terugmeldberichten Terugmelden via de TMF Terugmelding BAG Terugmelding BRO Service proces Security SOAP Interface Functies Data typen Terugmelding PRK
Verzoekberichten Verzoek BAG Documentatie koppelvlak LVO BAG Geo verzoek aan BAG Publiceren vergunningsgegevens Vergunningen metadata Opbouw van het vergunningzaak bericht Verzoek BRO (ondergrond) Autorisatie SOAP Interface Voorbeeld Locatie test informatie verzoekdienst Verzoek VEWIN (bluswater) Verzoek PRK (risicokaart) Verzoekbericht BGT/GBKN Incidentverzoekberichten
19 19 19 20 21 21 22 33 33 34 36 37 37 38 40 40
5 5.1 5.1 5.1 5.2 5.3 5.4
Berichten tussen de DBK-applicatie en andere applicaties Melding incident Minimale inhoud incidentinformatiebericht Globale beschrijving Melding ter plaatse Wijziging symbool Wijziging gegevens
44 44 44 45 46 46 47
1
Inleiding
Voor u ligt het berichtenboek Digitale Bereikbaarheidskaart (DBK). In dit berichtenboek worden in het kader van de POC1 DBK de berichten, waar in het PvE DBK een eerste aanzet is gedaan, verder uitgewerkt. In de inleiding wordt het soort berichten omschreven welke worden gespecificeerd. Daarnaast wordt per bericht aangegeven welke elementen van het bericht gespecificeerd dienen te worden. 1.1
Soort bericht
Er wordt onderscheid gemaakt naar een drietal berichten; een notificatiebericht, een verzoekbericht en een terugmeldbericht. Notificatieverzoek Notificatieverzoeken (is een vorm van verzoekbericht) zijn berichten van de bronhouders aan de afnemers waarin relevant wijzigingen in de registratie, doorgevoerd door de bronhouder, als was/wordt-informatie worden aangeduid. De afnemer stuurt een verzoek naar de bronhouder met daarin aangegeven de gevraagde gegevens, de gewenste periode en het object of het gebied waarover deze gegevens worden gevraagd. Na ontvangst wordt de gevraagde gegevensset naar de aanvrager gestuurd. Informatieverzoek Informatieverzoeken omvatten verzoeken vanuit de DBK-applicatie aan de bronhouders om voor een bepaald geografisch gebied (venster X1,Y1 – X2, Y2) of objectinformatie aan te leveren. Het object wordt in het verzoek aangeduid als een pand-ID, adres, 6PPC Postcode met huisnummeraanduiding of een X,Y die binnen de pandgeometrie valt. Terugmeldberichten Terugmeldberichten zijn berichten waarin de DBK-applicatie aan de bronhouder terugmeldt dat een afwijkende situatie is aangetroffen en waarin die afwijkende situatie tevens als was/wordt-bericht wordt gespecificeerd. Van alle drie de berichttypen komen varianten voor omdat de status van het bericht anders is. We onderscheiden statussen als Melding, Geweigerd en Begrepen. Deze status wordt aan het bericht toegevoegd.
1
Proof of Concept (POC) = proef die de werking van het concept/visie aantoont
3
Incidentverzoekberichten (haal-principe) zijn berichten die tussen twee DBK-servers worden uitgewisseld op het moment dat er grensoverschrijdende inzet plaatsvindt. De brandweerspecifieke DBK-gegevens worden dan op vensterniveau opgevraagd en geleverd door de DBK-server die de gegevens van de incidentlocatie bezit. In de onderstaande figuur is de gebiedsproblematiek die daarbij wordt overbrugd weergegeven.
Gebiedsproblematiek
bronhouders
Gemeente Y Regio B
Gemeente X Regio A
Incident verzoek
bijstand
bronhouders
Gemeente Y
Regio B Gemeente X Regio A
bijstand
Figuur 1. Gebiedsproblematiek Elke DBK-server heeft verbindingen met de bronhouders en tussen de DBKservers bestaat eveneens berichtenverkeer. Hiertoe dient een landelijke catalogus van verzorgingsgebieden te worden onderhouden. Daarop is raadpleegbaar welke DBK-servers welke verzorgingsgebieden afdekken. Voor de duur van de proef mag dit gesimuleerd worden. De verzorgingsproblematiek speelt ook bij de VEWIN-leden, die elk hun verzorgingsgebied kennen. Omdat dit niet aan grote wijzigingen onderhevig is, kan dit binnen de proef gesimuleerd worden. In figuur 2 zijn de berichtsoorten schematisch weergegeven.
4
A ijdT / um ta D
Notificatieverzoek Server Ondergrond
Omgeving BRONHOUDER bron data was / wordt
TMF TerugMeld Faciliteit
tijdvak
XY Venster
B ijdT / um ta D Xmax Ymax
Xmin Ymin
W/W data binnen venster Informatieverzoek
Xmin Ymin
Data binnen XY Venster Incidentverzoek
Xmin Ymin
Data binnen XY Venster
XY Venster
XY Venster
Xmax Ymax
Xmax Ymax
Brandweerserver 24 x 7 Lage uitval
Omgeving BRANDWEER GEMEENTE kopie data
Terugmelding
W/W Data
Bevestiging verwerking
Was / wordt
Figuur 2. Berichtsoorten per bronhouder Onderstaande tabel geeft aan in welk proces welke berichten gebruikt zullen worden: Tabel 1. Berichtsoorten per werkproces Info Notificatie verzoek Maken x Gebruiken x Beheren x
Terugmelding
Incidentverzoek bericht
x x x
Tenslotte zijn er nog berichten van de DBK-applicatie naar andere applicaties. Deze worden apart in hoofdstuk 5 beschreven 1.2
Specificatie per bericht
Bij het ontvangen en versturen van berichten tussen verschillende partijen via internet dienen de verzender en ontvanger dezelfde taal te praten. Ze moeten elkaar ook op het web zien te vinden. Om die redenen dienen de berichten die verstuurd worden aan beide kanten op dezelfde manier opgesteld te worden. Op deze manier weet een bericht waar het moet zijn, kan het bericht verstuurd worden en kan het bericht door de ontvangende partij gelezen worden en kan er een antwoord worden teruggestuurd. Berichten worden in deze proef veelal technisch afgehandeld via webservices. Om dit mogelijk te maken dienen de systemen van beide partijen op een aantal wijzen op elkaar afgestemd te worden.
5
Locatie van berichten Locatie is het eerste wat van belang is. Om een webservice van een andere partij aan te kunnen roepen dien je te weten waar deze zich bevindt. Dit gebeurt op dezelfde manier als met normale webpagina’s. Ze worden aangeduid met URI’s (Uniform Resource Identifiers). Dit is praktisch hetzelfde als URL’s (Uniform Resource Locators). (www.enzovoort.land) Protocollering van berichten Communicatie is een tweede belangrijk element. Er dient een manier van praten afgesproken te worden tussen de verzender en de ontvanger zodat de ontvanger begrijpt wat de verzender van hem vraagt. Hier zijn protocollen voor ontwikkeld. Er zijn protocollen die zijn geschikt om puur informatie te versturen, daarnaast zijn ook protocollen ontwikkeld om geo-informatie uit te wisselen. Onderlinge afstemming informatiemodellen Nu men weet hoe men met elkaar kan praten, moet men elkaar ook nog kunnen verstaan. Het kan voorkomen dat een benaming van een bepaald informatie element bij beide partijen net iets anders is gedefinieerd. Er dient iets te worden georganiseerd om ervoor te zorgen dat partijen van elkaar weten wat ze bedoelen als partij X het heeft over een object en partij Y het heeft over een gebouw. De informatie-elementen waar men informatie over wil uitwisselen dienen onderling op elkaar aangesloten te worden. Deze elementen dienen voor elk type bericht gespecificeerd te worden voordat men de berichten kan gaan maken en deze in gebruik gaan nemen. 1.3
Bronhouders
In het kader van de POC zijn een aantal bronhouders geïdentificeerd waarmee de brandweer in het kader van de DBK-gegevens wenst uit te wisselen. Het gaat om de volgende partijen: - gemeenten, Dataland en Kadaster (LV BAG) voor Basisregistratie Adressen Gebouwen (BAG) - gemeenten en VROM LVO Omgevingsloket voor WABO/Omgevingsvergunning - IPO/PRK Risicokaart voor Risicogegevens en ondergronden (luchtfoto’s, GBKN, TOP10 en open water geometrie (idem provincies) - TNO Bouw en Ondergrond (BRO) Basisregistraties Ondergrond voor Geboorde putten (onder andere brandputten) - drinkwaterbedrijven (VEWIN leden) voor brandkranen - brandweerkorpsen voor brandweerspecifieke gegevens (worden in DBKapplicatie vastgelegd).
6
1.4
Status berichtspecificatie
Het DBK-project is vrij vernieuwd bij de overheid in het gebruik maken van basisregistraties en andere bronnen via berichtuitwisseling. Om die reden blijken bronhouders niet altijd kant en klare oplossingen te hebben waar een DBK-applicatie op kan aansluiten. Wij streven er naar zoveel mogelijk bronberichten in de POC mee te nemen, waaronder van elke soort bericht tenminste één. In deze eerste versie van het berichtenboek ontbreken nog een groot aantal berichtspecificaties. Zodra er nieuwe specificaties opgesteld of vrijgegeven zijn dan worden deze zo snel mogelijk in het berichtenboek verwerkt en wordt een nieuwe versie, met daarin aangegeven wat de toevoegingen zijn, rondgestuurd. Voor het goed specificeren van de berichten om aan te sluiten op de diverse bronhouders is echter samenwerking en kennisuitwisseling met de bronhouders vereist. De projectorganisatie zal de verbindingen tussen de partijen leggen en waar nodig acties coördineren en kennis bundelen om het berichtenverkeer gespecificeerd te krijgen. De stand van zaken welke berichten in dit berichtenboek worden behandeld is weergegeven in figuur 3. Dit betekent niet altijd dat de berichtenspecificatie al gereed is. De voortgang en verwachte opleverdatum van de verschillende berichten wordt in het begeleidend schrijven toegelicht.
Welke berichten in de POC DBK incidentverzoek
informatieverzoek
terugmelding
BAG WABO BRO VEWIN PRK BGT incident
Gemeente X Regio A DBK applicatie
G AB
N O I K T BA O ? W R EV R B P G B W
BAG WABO BRO VEWIN PRK BGT ? Status 21.04.2009
notificatieverzoek
Figuur 3. Berichten in de POC
7
Hier volgen de trajecten met de verschillende bronhouders: BAG - Met VROM/Kadaster Landelijke Voorziening BAG wordt kennis uitgewisseld om de berichtspecificaties te verkrijgen rondom reguliere BAGberichten. Hiervan is een vertrouwelijke conceptversie ter beschikking gesteld ten behoeve van de POC. Hierin zijn de berichten uitgewerkt. De LVO BAG zal vanaf 22 juni benaderbaar zijn. - met ICTU/ODP en Geonovum wordt gewerkt om voor de POC ook geoterug meldingen voor de BAG te realiseren. Hiervoor zal de TMF/BAG worden gebruikt. Hiervoor is nu een tijdelijke oplossing gerealiseerd. Contactpersoon: Albert van Duijn WABO - Met VROM loopt een traject om in kaart te brengen hoe het WABO-proces, het gemeentelijk proces en het brandweerproces in elkaar vallen om vanuit daar de berichten en systemen te identificeren. De WABOberichtenspecificaties zijn op dit moment onvoldoende concreet om tijdens de proef gebruik van te maken. Applicaties dienen deze berichtuitwisseling op termijn wel te ondersteunen maar dit valt buiten de POC - er loopt een traject met VNG om na te gaan hoe aan te sluiten op gemeentelijke systemen als een vergunning is verleend en verdwijnt uit de landelijke voorziening - vergunningen kunnen rechtstreeks gepubliceerd worden op overheid.nl uit de gemeentelijke systemen of de OLO. Aangezien de berichtspecificaties van de WABO niet beschikbaar zijn hier de specificaties opgenomen waar volgens een gemeente zijn vergunningsgegevens aan overheid.nl dient te publiceren. Deze gegevens zijn vrij beschikbaar, een gedeelte uit deze documentatie2 is opgenomen in dit document. Contactpersoon: Eric van Capelleveen Waterleidingmaatschappijen - Er worden specificaties gemaakt voor alle drie type berichten. Dit wordt één centraal loket. Functionele en technische specificaties worden door de projectgroep DBK opgesteld in samenspraak met Vewin. Een eerste aanzet tot de specificaties is inmiddels vrijgegeven. Er wordt nog gekeken of de waterleidingbedrijven op alle locaties mee kunnen doen of dat de data voor alle drie de locaties vanaf één centrale plek geserveerd zal worden.
2
Zie website: http://www.overheidheeftantwoord.nl/producten,vergunningen/Documentatie. html voor gedetailleerde informatie over het IPM 4.0 model
8
Contactpersoon: Jaap Smit BRO/DINO/Geboorde putten - De informatieberichten voor de BRO zijn gespecificeerd en in dit document opgenomen. TNO heeft aangegeven aan de berichtspecificaties voor terugmelden aan de TMF te werken. Deze volgen zo spoedig mogelijk. Contactpersoon: Albert van Duijn Risicokaart - De risicokaart heeft een WFS beschikbaar. Hiervan zijn de benodigde specificaties ter beschikking gesteld. Voor nu wordt één gevaarlijke stof in de POC uitgevraagd. Alleen deze gevaarlijke stof, LPG wordt in de POC getest. BGT/GBKN Op dit moment wordt nagegaan in welke mate de landelijke voorziening GBKN benut kan worden binnen de proef voor informatieverzoeken en notificatieverzoeken. Contactpersoon: Eric van Capelleveen Incidentverzoekberichten Incidentverzoekberichten zijn berichten tussen servers die nodig zijn bij grensoverschrijdend gebruik. Deze zijn nodig om gegevens bij de lokale server op te halen als de bronnen niet beschikbaar zijn. Deze zijn nu op logisch niveau beschreven. Een technische beschrijving zal later toegevoegd worden. Contactpersoon: Albert van Duijn 1.5
Leeswijzer
De volgende berichten zullen in dit document gespecificeerd worden. Tabel 2. Totaaloverzicht berichtenverkeer Berichtenverkeer derden Berichtenverkeer binnen brandweerdomein Terugmelding BRO Melding incident Terugmelding Melding ter plaatse (AVLS) Terugmelding RRGS/PRK Wijziging symbool Terugmelding BGT Wijziging gegevens Verzoek BAG Verzoek WABO Verzoek BRO Verzoek Bluswater Verzoek RRGS/PRK
9
Berichtenverkeer derden
Berichtenverkeer binnen brandweerdomein
Verzoek BGT Notificatie BAG Notificatie WABO Notificatie Ondergrond Notificatie Bluswater Notificatie RRGS/PRK Notificatie BGT Incidentverzoek berichten In hoofdstuk 2 worden alle terugmeldingen uitgewerkt. Hoofdstuk 3 bevat de verzoeken om informatie. Hoofdstuk 4 gaat in op de notificatieberichten. Hoofdstuk 5 beschrijft de berichtenten tussen de brandweer en derden. Van elk bericht wordt aangegeven wie de bronhouder is, wat de locatie is, wat de communicatieprotocollen zijn, welke gegevens uitgewisseld worden en hoe deze tussen de organisaties onderling op elkaar aansluiten.
10
2
Notificatieberichten
Er is berichtenverkeer met derden en er is berichtenverkeer binnen het brandweerdomein. De berichten weergegeven in onderstaande tabel dienen ondersteund te worden. 2.1
Notificatieverzoek BAG
Notificatieberichten worden op dit moment nog niet ondersteund. Het wordt vanaf halverwege 2009 mogelijk om een abonnement op de BAG-gegegevens te nemen. Men krijgt dan een voorlopig landelijk bestand (wat later ook op gemeentelijk niveau wordt aangeboden). Met een abonnement krijgt men periodiek een uittreksel toegestuurd op basis waarvan men zelf de relevante mutaties uit kan filteren. ODP is bezig met een voorstel om een generieke abonnementvoorziening te realiseren. De launching customer hiervoor is het handelsregister. Als dit succesvol is dan komt deze dienst ook beschikbaar voor de BAG. Als alles conform planning verloopt is deze dienst voor de BAG per 01-01-10 beschikbaar. Mocht de generieke voorziening niet doorgaan dan zal de projectgroep BAG zelf een abonnementsvoorziening ter beschikking stellen. 2.2
Notificatieverzoek BGT/GBKN
Locatie: Communicatieprotocol: Inhoud en mapping bericht
11
3
Terugmeldberichten
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. 3.1
Terugmelden via de TMF
Terugmelden via de TMF Er is een landelijk portaal, de TerugMeldFaciliteit (TMF) in het leven geroepen. Dit portaal dient om alle terugmeldingen te routeren naar de juiste bronhouder. Iedereen is vrij om hier gebruik van te maken. Naast het terugmelden zelf kunnen terugmeldingen ook worden teruggetrokken en wordt statusinformatie gestuurd over de terugmelding naar de bronhouder.
Figuur 4. Werking van de TMF Tijdens de proef zullen een aantal typen terugmeldingen via de TMF verlopen. Het gaat om terugmeldingen van de BRO en eventueel die van de PKR. Het datatransport vindt plaats via http. SOAP of WUS wordt gebruikt als communicatieprotocol. Een terugmeld bericht dient de volgende elementen te bevatten. Tabel 3. Informatie elementen van het terugmeldbericht aan de TMF Groep/element objecttype object sleutel attribuuttype
Groep / element contact-naam contact-telefoon contact-email bijlage
3.2
XSD Group / element contactInfo.naam contactInfo.telefoon contactInfo.email attachment.filename attachment.base64attachment
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. Terugmelding aan de BAG geschiedt via omschrijving zoals boven staat geformuleerd. Indien het een bestaand BAG-object is volgt het volgende bericht: - pand-ID - pandgeometrie - aard van de wijziging (in tekst) - verzender van de terugmelding - datum/tijd terugmelding - 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 BAG-specificaties. Tijdelijk oplossing voor geo-terugmeldingen BAG: - bij een terugmelding moet een actuele check worden gedaan op de BAG - bij het terugmelden moet gebruik gemaakt worden van de TMF-portal (ODPproduct). De applicatie-applicatie interface kan in deze pilot nog niet onder steund worden. - de pandgeometrie moet worden teruggemeld als PDF-attachement. Dit bestand kan worden bijgevoegd in de TMF-portaal. Dit kan doormiddel van een PDF-bestand, maar de applicatie dient ook een GML-bestand te kunnen genereren waarmee wijzigingen in geometrie toegestuurd kunnen worden. De bijlagen mogen niet groter zijn dan 2MB.
13
3.3
Terugmelding BRO
Het betreft terugmeldingen aan de BRO over bij de BRO niet bekende brandputten danwel wijzigingen van gegevens van bestaande brandputten die door de brandweer ter plekke zijn geconstateerd. Het bericht bevat de volgende gegevens: - (on)bekende 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 - datum/tijd terugmelding. Terugmeldingen BRO zullen via de TMF verlopen. De berichtspecificatie Deze beveiligde service moet informatie kunnen verwerken die aangeleverd wordt via de TMF van de overheidsservicebus (OSB). Externe partijen zijn daarmee in staat om gegevens te corrigeren. 3.3.1
Service proces Het proces dat gevolgd wordt is hieronder schematisch weergegeven.
14
Zoekopdracht
Geautoriseerd?
Ja
Uitvoeren zoekopdracht
Nee
Gevonden?
Ja
Nee
Gegevens retourneren
Foutmelding retourneren
Einde
15
3.3.2
Security Voor de beveiliging van de webservices zal gebruik worden gemaakt van standaarden die aan de OSB-richtlijnen voldoen. Daarbij wordt gebruik gemaakt van PKI-certificaten met asymmetrische encryptie over SSL volgens RFC 4346. Een beschrijving hiervan is te vinden op: http://tools.ietf.org/html/rfc4346
3.3.3
SOAP Interface 3.3.4
Functies
Functie registerWell Verzoek tot registratie van een nieuwe put die voor de brandweer bruikbaar is. Input (registerWellRequest) Omschrijving Put gegevens
Output (registerWellResponse) Omschrijving Confirmatie van de aanname van het verzoek.
Datatype Well
Veldnaam WELL
Datatype Boolean
Veldnaam ACCEPTED
Functie mutateWell Verzoek tot het muteren van de gegevens van een specifieke put. Input (mutateWellRequest) Omschrijving Nieuwe put gegevens. Alle informatie uit de entiteit wordt als geheel aangemeld voor mutatie.
Datatype Well
Veldnaam WELL
Output (mutateWellResponse) Omschrijving Confirmatie van de aanname van het verzoek.
Datatype Boolean
Veldnaam ACCEPTED
16
Functie unregisterWell Geeft de brandputt van het opgegeven id. Input (unregisterWellRequest) Omschrijving Well id
Output (unregisterWellResponse) Omschrijving Confirmatie van de aanname van het verzoek. 3.3.5
Datatype Character string
Veldnaam WELL_ID
Datatype Boolean
Veldnaam ACCEPTED
Data typen
Data typen Well Omschrijving Brandput id Positie X-coordinaat (rijksdriehoekstelsel) Positie Y-coordinaat (rijksdriehoekstelsel) Laatst bekende capaciteit (m3/s) Laatste controledatum Status (bruikbaar of onbruikbaar)
3.4
Datatype Character string Double
Veldnaam WELL_ID
Double
WELL_Y
Double
WELL_CAPACITY
Date Character string
WELL_INSPECTION_DATE WELL_STATUS
WELL_X
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
17
-
gebruikstype Prevapcode aard van de wijziging (in tekst) verzender van de terugmelding datum/tijd terugmelding.
18
4
Verzoekberichten
Verzoeken om informatie zijn bedoeld om gegevens met één klik bij de bron te halen. 4.1
Verzoek BAG
Inmiddels zijn meer details van de specificaties van het koppelvlak met de LVO BAG bekend. De beschrijving van het koppelvlak wordt ten behoeve van de POC DBK aan ons ter beschikking gesteld met de volgende kanttekeningen: - het betreft hier een conceptversie. Er kunnen naar aanleiding van de laatste testen nog kleine wijzigingen worden aangebracht in de xsd- en wsdlbestanden ( nu 99,5% stabiel) - het koppelvlakdocument is nog niet gereed en bevat op bepaalde plekken dan ook nog weinig toelichting - deze documentatie is nog in concept en hiervan is om die reden ook nog niets terug te vinden op Kadaster.nl. Daarnaast heeft het Kadaster aangegeven dat de LVO BAG op dit moment nog niet via internet bereikbaar is. Zij geven aan dat de LVO BAG live gaat op 22 juni 2009. De daadwerkelijke test van het koppelvlak BAG vanuit de DBKapplicaties kan dus pas vanaf dat moment plaatsvinden. 4.1.1
Documentatie koppelvlak LVO BAG Het Kadaster heeft een heleboel bestanden ter beschikking gesteld. Het gaat om het document Koppelvlak BAG – Dienst bevragingen Schema’s en services en bijbehorende xsd- en wsdl-bestanden. Deze beschrijven het complete koppelvlak met LVO BAG. Voor de POC DBK hoeft niet het gehele koppelvlak koppelvlak gemaakt te worden. Hier kunnen we ons beperken tot een subset. Omdat het hier uitgebreide documentatie betreft met veel toegevoegde xsd- en wsdl-bestanden worden deze als geheel in de bijlage als separate bestanden toegevoegd. In dit document wordt dus niet de gehele documentatie opgenomen maar zal worden aangeven welke delen ons inziens relevant zijn voor de POC, en welke delen niet. Wat wij vragen van de BAG De DBK-applicatie moet het volgende verzoek tot opvragen van BAG gegevens kunnen uitvoeren.
19
Dit verzoek moet kunnen worden uitgevoerd op basis van de volgende input: - X,Y, - adres, - postcode + huisnummer - pand-ID. De pand-ID is dezelfde als die in de BAG; de X,Y kan afwijken van de exacte X,Y die in de BAG is opgeslagen bij het pand, maar zou redelijkerwijs binnen de pandgeometrie vallen. Het adres kan afwijken van de exacte schrijfwijze die in de BAG is gehanteerd. Verwacht antwoord: - pand-ID - pand-geometrie - adres - postcode - huisnummer compleet - woonplaats. Wat is hiervoor uit de documentatie relevant? Het betreft hier alleen gegevensuitwisseling van actuele gegevens, niet van was-/wordt-bestanden. Dit houdt in dat (voor nu) uit de documentatie alleen informatie van peildatum actueel/relevant is. Gegevensuitwisseling rondom de levenscyclus valt dus buiten beschouwing. Van de gespecificeerde berichten zijn de berichten onder paragraaf 4.1 (bevragen adresseerbare objecten) en paragraaf 4.2 (bevragen pand) noodzakelijk om bovenstaand verzoek te kunnen uitvoeren. Mochten er nog aanvullende berichten uit de meegeleverde documentatie nodig zijn, voel u dan vrij om deze te gebruiken.
4.1.2
Geo verzoek aan BAG De pandgeometrie is al onderdeel van het BAG-bericht. Een voorbeeld hiervan is bijgevoegd. Er zijn geen aanvullende requirements nodig dan de viewer/editor de GML uit het BAG-bericht kan visualiseren.
20
Figuur 5. Voorbeeld pandgeometrie van BAG-bericht 4.2
Publiceren vergunningsgegevens
Betreft een verzoek tot opvragen van WABO-omgevingsvergunningsloket gegevens op basis van X,Y, adres, postcode + huisnummer, pand-ID danwel zaak-ID. Verwacht antwoord: - pand-ID - zaak-ID - aanvullen met WABO-gegevens. Vergunning kan worden gepubliceerd via het omgevingsloket of via Informatie Publicatie Model vergunning 4.0 (IPM 4.0). Informatie over ontsluiting via het omgevingsloket is nog niet beschikbaar. Wél zijn er al gemeenten die vergunningsinformatie ontsluiten volgens IPM 4.0. Vergunning worden op deze wijze rechtstreeks ontsluiten uit de gemeentelijke systemen via XML-berichtverkeer. Hieronder volgt een uitwerking van IPM 4.0. 4.2.1
Vergunningen metadata Een vergunningenbericht beschrijft òf de vergunning (de zaak), òf bijbehorende documenten. Allebei de berichten worden voorafgegaan door algemene stuurinformatie. De vergunning waar in de voorbeelden naar wordt verwezen is overigens fictief.
21
Stuurinformatie Veld vergunningzaak en vergunningdocument Omschrijving Wordt gebruikt om aan te geven waar het XML-schema zich bevindt. XML Veld transactietype Omschrijving Geeft het type bericht aan. Mogelijke waarden zijn C (create), U (update) en D (delete). XML<message>C Veld transactieID Omschrijving Uniek kenmerk van het bericht. XML<message>1 Veld volgnummer Omschrijving Indien een bericht uit meerdere opeenvolgende berichten bestaat, wordt met dit veld het volgnummer aangegeven. XML<message>1 Veld aanmaakdatum Omschrijving Datum waarop het XML-bericht wordt aangemaakt, volgens syntax jjjj-mm-dd. XML<message>2008-08-08 4.2.2
Opbouw van het vergunningzaak bericht De vergunningzaak is opgebouwd uit drie blokken, conform de overheidsbrede Web Metadata Standaard (OWMS 3.5). De blokken zijn OWMS-kern, OWMS-mantel en vergunningenmeta.
22
In de OWMS-kern is een minimale set van eigenschappen opgenomen, met een aantal toegevoegde elementen in owmsmantel. In vergunningenmeta zijn elementen opgenomen die specifiek voor Vergunningen zijn. OWMS-kern In de OWMS kern is een set van acht eigenschappen opgenomen, namelijk dcterms:identifier, dcterms:title, dcterms:type, dcterms:language, dcterms:creator, dcterms:modified, dcterms:spatial en dcterms:temporal. Door het invullen van deze eigenschappen is de metadata conform OWMS.
Eigenschap Identificatie Status Verplicht. Komt voor Eén keer. Omschrijving Unieke verwijzing naar de zaakpagina op de website van de publicerende overheid waarop de vergunningeninformatie staat. Waardebereik dcterms:URI XMLhttp://www.vlist.nl/vergunningen/vergunning.vg?id=1234 Eigenschap Titel Status Verplicht. Komt voor Eén keer. Omschrijving: De titel van de vergunning is een combinatie van Type (met eventueel bijbehorende Activiteit) en de locatieaanduiding. Waardebereik Tekst: veld Product + veld Activiteit (repeterend) + Locatie XMLOmgevingsvergunning Slopen, bouwen 2821 XS, 21 Stolwijk Veld Informatietype Status Verplicht. Komt voor Eén keer.
23
Omschrijving Kenmerk waarmee aangegeven wordt dat dit bericht vergunningeninformatie bevat. Waardebereik Vaste tekst “vergunning”. Let op: de aanduiding is case sensitive, dus vergunning met een kleine v. XMLvergunning Eigenschap Taal Status Verplicht. Komt voor Eén keer. Omschrijving Taal van het document. Notatiewijze conform RFC4646 van de Internet Engineering Task Force (IETF). Concreet bestaat de code uit een language tag (ISO 639-2) aangevuld met een country code (ISO 3166). Voorbeeld: nlNL (Nederlands), of fy-NL (Fries). Waardebereik
dcterms:RFC4646
XMLnl-NL Eigenschap Maker Status Verplicht. Komt voor Eén keer. Omschrijving Geeft het soort en de naam van de organisatie aan die verantwoordelijk is voor het verlenen van de vergunning. Waardebereik Vaste waarde uit waardelijst (zie hieronder). Waardelijsten http://standaarden.overheid.nl/owms/3.5/doc/eigenschappen/dcterms.creator.ht ml (zie wijze van coderen). XMLVlist Eigenschap Datum laatste wijziging Status Verplicht. Komt voor Eén keer. Omschrijving Aanvankelijk de datum waarop de zaak is aangemaakt, en na een wijziging de datum van laatste wijziging. Waardebereik dcterms:W3CDTF XML2008-08-31 Eigenschap Locatie Status Niet Verplicht Komt voor Eén keer Omschrijving Aanduiding van de locatie die bij het document hoort. Dit veld hoeft alleen ingevuld te worden als deze locatie relevant voor het document is. U dient de meest specifiek mogelijke locatieaanduiding in te vullen Waardebereik Vaste waarde uit de waardelijsten (zie hieronder)
24
Waardelijsten http://standaarden.overheid.nl/owms/3.5/xml/waardelijsten/overheid.Gemee nte.xml http://standaarden.overheid.nl/owms/3.5/xml/waardelijsten/overheid.Provinc ie.xml http://standaarden.overheid.nl/owms/3.5/xml/waardelijsten/overheid.Waters chap.xml http://standaarden.overheid.nl/owms/3.5/doc/syntax-codeerschemas/overheid.postcodehuisnummer.html XML Vlist Eigenschap Geldigheid Status Invullen indien de vergunning onherroepelijk is. Komt voor Eén keer. Omschrijving Geeft de periode van geldigheid voor de verleende vergunning aan. Indien de vergunning nog niet is verleend, dan is dit veld niet aanwezig. Voor het aangeven van een onbeperkte geldigheidsduur kan het veld end worden leeg gelaten. Indien een vergunning één dag geldig is, wordt bij start en end dezelfde datum ingevuld. Waardebereik
dcterms:Period
XML <start xmlns=””>2008-09-01<end xmlns=””>2008-09-01 OWMS-mantel In de OWMS-mantel is een groot aantal extra elementen opgenomen, waarvan er binnen Vergunningen op Internet drie worden gebruikt. Het zijn respectievelijk dcterms:description, dcterms:hasPart en dcterms:references. Eigenschap
Omschrijving
Status Verplicht. Komt voor Eén keer. Omschrijving Korte beschrijving van het onderwerp van de vergunning. Waardebereik Vrij tekstveld.
25
XMLSlopen en bouwen van een woning aan de Bovenkerkseweg 21 te Stolwijk
Eigenschap Heeft onderdeel Status Opnemen indien er documenten zijn die onderdeel uitmaken van de zaak. De resourceIdentifier is verplicht, de waarde niet. Komt voor Nul, één of meerdere keren. Omschrijving
Koppeling met de bovenliggende zaak, verwijst naar de Identifier van het vergunningenzaak bericht (de URL van de zaakpagina). De verwijzing vult u in bij resourceIdentifier. Vervolgens kunt u de verwijzing nader omschrijven (bijvoorbeeld Beschikking).
Waardebereik
dcterms:URI
XMLBeschikking< /dcterms:hasPart> Eigenschap zaaknummer Status verplicht Komt voor een keer Omschrijving Kenmerk waarmee de vergunning teruggevonden kan worden. Het nummer dient voor interne systemen van de deelnemende overheid herkenbaar te zijn. Waardebereik dcterms:URI XML1234
Vergunningenmeta In het derde blok zijn specifieke elementen opgenomen die niet binnen OWMS vallen, en de vergunning verder beschrijven. Ze zijn per blok gegroepeerd, namelijk product, termijn, actor en object
Informatie over product Aanduiding van het soort vergunning. Als er sprake is van een omgevingsvergunning, dan wordt eveneens het type activiteit waarover de vergunning gaat, toegevoegd.
26
Eigenschap Producttype Status Verplicht. Komt voor Eén keer. Omschrijving Type vergunning. Deze wordt geselecteerd uit een lijst met voorgedefinieerde vergunningtypen. Waardebereik overheidvg:Product Waardelijst http://standaarden.overheid.nl/owms/3.5/xml/waardelijsten/overheidvg.Product .xml XML<product><producttype>Omgevingsvergunning Eigenschap Activiteit Status Als het product omgevingsvergunning is, dan is dit veld verplicht. Komt voor Nul, één of meerdere keren. Nul indien er geen sprake is van een omgevingsvergunning. Omschrijving Activiteit die behoort bij de omgevingsvergunning. Dit veld kan meerdere keren voorkomen, al naar gelang het aantal activiteiten. Waardebereik overheidvg:Activiteit Waardelijst http://standaarden.overheid.nl/owms/3.5/xml/waardelijsten/overheidvg.Activiteit.xml
XML<product>Slopenbouwenvergunning onherroepelijk
27
Eigenschap Termijnsoort Status Niet verplicht. Komt voor Nul of één keer. Omschrijving Wordt gebruikt om verschillende termijnen in proces van vergunningverlening en handhaving aan te duiden. Waardebereik overheidvg:Termijnsoort Waardelijst http://standaarden.overheid.nl/owms/3.5/xml/waardelijsten/overheidvg.Term ijnsoort.xml XMLvergunningsduur Eigenschap Startdatumtermijn Status Invullen indien termijnsoort is gevuld. Komt voor Nul of één keer. Omschrijving Datum waarop de termijn ingaat. Notatie: jjjj-mm-dd. Waardebereik dcterms:W3CDTF XML<startdatumTermijn>2008-0923 Eigenschap Einddatumtermijn Status Invullen indien termijnsoort is gevuld. Komt voor Nul of één keer. Omschrijving Datum waarop de termijn eindigt. Notatie: jjjj-mm-dd. Als de startdatum gevuld is en de einddatum leeg, dan is de vergunningsduur onbeperkt. Waardebereik dcterms:W3CDTF XML<einddatumTermijn>2008-0923 Informatie over de betrokkene De overheidsbrede zoekdienst mag vanwege privacy-overwegingen alleen gegevens van niet natuurlijke personen doorzoekbaar maken. Dat betekent dat indien metadata over een betrokkene wordt meegestuurd, deze alleen bedrijfsinformatie mag bevatten. Van een bedrijf wordt de statutaire naam (de naam zoals opgenomen in het Handelsregister van de Kamer van Koophandel) opgenomen. Om het mogelijk te maken meer informatie over dat bedrijf te vinden, is het veld bedrijfsnummer toegevoegd. Hierin kan een unieke sleutel worden opgeslagen waarmee het bedrijf identificeerbaar is, bijvoorbeeld het KVK- of BTW-nummer Eigenschap bedrijfsnaam Status invullen indien betrokkene een bedrijf is Komt voor nul of één keer.
28
Omschrijving tatutaire bedrijfsnaam afgeleid uit het Nieuw Handelsregister. Volgens de Wet Bescherming Persoonsgegevens is het niet toegestaan in dit veld informatie op te nemen die verwijst naar een zelfstandige zonder personeel (ZZP’er). Waardebereik Vrij tekstveld. XML actor>bedrijf bv Eigenschap Bedrijfsnummer Status Niet verplicht. Komt voor Nul of één keer. Omschrijving Mogelijkheid tot het opslaan van een sleutel voor het koppelen van een bedrijfsnaam met een externe databank als het Nieuw Handelsregister. Hier zou bijvoorbeeld het KvK-nummer of het BTW-nummer van een bedrijf in opgeslagen kunnen worden. Waardebereik Vrij tekstveld XML 10000000 Eigenschap Bedrijfsadres Status Invullen indien bedrijfsnaam ingevuld is. Komt voor Nul of één keer. Omschrijving Geeft het vestigingsadres van de aanvrager van een vergunning aan. Waardebereik overheid:PostcodeHuisnummer Waardelijst http://standaarden.overheid.nl/owms/3.5/doc/syntax-codeerschemas/overheid.postcodehuisnummer.html Notatiewijze Uitgebreid: Vier cijfers, twee hoofdletters, een reeks cijfers van het huisnummer, toevoeging. Minimaal: vier cijfers. XML2821XS21
Informatie over het object van de vergunning Een vergunning wordt in veel gevallen afgegeven over een bepaalde locatie. Die locatie kan op veel verschillende manieren worden aangeduid, afhankelijk van het type vergunning. Een kapvergunning kan bijvoorbeeld op een adres worden afgegeven, maar daarmee is nog niet automatisch duidelijk om welke boom het gaat. Een nieuw te bouwen huis heeft vaak nog geen officieel adres, of wellicht is alleen de straatnaam bekend. En een milieuvergunning kan voor een specifiek onderdeel van een groot bedrijventerrein gelden, waarvan de exacte locatie niet bekend is omdat de vergunning op naam van het bedrijf dat het terrein beheert, wordt afgegeven. Met een X- en een coördinaat is het niet mogelijk de contouren van een dergelijk terrein of een object op dat terrein exact aan te geven. Het IPM biedt in ieder geval drie manieren om een locatie aan te duiden. U wordt verzocht zoveel mogelijk informatie in te vullen.
29
De manieren zijn adresaanduiding (postcode, huisnummer, huisletter, huisnummertoevoeging, woonplaats, straat, gemeente en provincie), perceelaanduiding (perceel, sectie en gemeente) en coördinaten. Daarnaast is een veld beschikbaar voor het opnemen van een nummer dat verwijst naar externe systemen: het referentienummer. Eigenschap referentienummer Status Invullen indien beschikbaar. Komt voor Nul of één keer. Omschrijving Sleutel waarmee objectgegevens uit externe systemen (bijvoorbeeld de BAG) gehaald kunnen worden. Waardebereik Vrij tekstveld. XML
1. Adresaanduiding In OWMS-kern vulde u bij dcterms:spatial al een locatie aanduiding in. Misschien was deze aanduiding voor een bepaalde vergunning niet gedetailleerd genoeg. Daarom wordt u binnen het blok vergunningenmeta de mogelijkheid geboden meer gegevens over de locatie op te nemen. U kunt kiezen tussen vier mogelijkheden: een opsomming van postcode en huisnummer, een opsomming van straatnaam met woonplaats, een gemeente of een provincie. U vult in wat u minimaal heeft. Is dat bijvoorbeeld alleen de naam van de gemeente (in het geval van een APV), dan vult u dat veld in. Uw keuze ligt tussen meest gedetailleerd (optie 1a) en minst gedetailleerd (optie 1d). Het achterliggende idee is dat het detailniveau achteraf, eventueel geautomatiseerd, aangevuld kan worden. Een voorbeeld: heeft u de beschikking over postcode en huisnummer, dan hoeft u straatnaam en woonplaats niet in te vullen. Die kunnen immers afgeleid worden. 1a. Adresaanduiding: postcode en huisnummer Eigenschap huisnummer, postcode Status Invullen indien beschikbaar. Komt voor Nul of meerdere keren. Omschrijving Adresgegevens van de locatie waarop de vergunning betrekking heeft. Waardebereik overheid:PostcodeHuisnummer Waardelijst http://standaarden.overheid.nl/owms/3.5/doc/syntax-codeerschemas/overheid.postcodehuisnummer.html Notatiewijze Uitgebreid: Vier cijfers, twee hoofdletters, een reeks cijfers van het huisnummer, toevoeging. Minimaal: vier cijfers. XML Eigenschap huisletter, toevoeging HuisNummer Status Invullen indien beschikbaar.
30
Komt voor Nul of meerdere keren. Omschrijving toevoegingen aan huisnummer. Waardebereik Vrij tekstveld. XML 1b. Adresaanduiding: woonplaats en adres Eigenschap woonplaats Status Invullen indien beschikbaar. Komt voor Nul of meerdere keren. Omschrijving Naam van woonplaats die binnen een bepaalde gemeente valt Waardebereik Vrij tekstveld. XML Eigenschap straatnaam en huisnummer Status Invullen indien beschikbaar. Komt voor Nul of meerdere keren. Omschrijving Naam van de straat. Waardebereik Vrij tekstveld. XML 1c. Adresaanduiding: gemeente Eigenschap gemeente Status Invullen indien beschikbaar. Komt voor Nul of meerdere keren. Omschrijving Naam van de gemeente. Waardebereik overheid:Gemeente Waardelijst http://standaarden.overheid.nl/owms/3.5/xml/waardelijsten/overheid.Gemeen te.xml XML 1d. Adresaanduiding: provincie Eigenschap provincie Status Invullen indien beschikbaar. Komt voor Nul of meerdere keren. Omschrijving Naam van de provincie.
31
Waardebereik overheid:Provincie Waardelijst http://standaarden.overheid.nl/owms/3.5/xml/waardelijsten/overheid.Provinc ie.xml XML Perceelaanduiding Aanduiden van een perceel geschiedt conform de notatie van het Kadaster. Eigenschap kadastrale gemeente, sectie en nummer Status Niet verplicht. Komt voor Nul of meerdere keren. Omschrijving Kadastrale aanduidingen van objecten. Afhankelijk van de opbouw van de locatie is het mogelijk dat er meerdere perceelaanduidingen zijn: dit veld kan dus meerdere keren voorkomen. Waardebereik overheid:KadastraleGemeente Waardelijst http://standaarden.overheid.nl/owms/3.5/doc/waardelijsten/overheid.Kadastr aleGemeente.xml. XMLStolwijk<sectie> A12Stolwijk<sectie>A13 3. Coördinaataanduiding Bij aanduiding van een object in coördinaten kunt u volgens het Rijksdriehoekstelsel punten op een kaart aanduiden. De z-waarde is facultatief. Eigenschap coördinaten Status Invullen indien beschikbaar. Komt voor Nul of meerdere keren. Omschrijving Coördinaten van de locatie waarop de vergunning betrekking heeft. Waardebereik Vrij tekstveld. XML
32
Wat is hiervan waardevol voor de DBK? 4.3
Verzoek BRO (ondergrond)
Het betreft hier het 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). Het proces dat gevolgd wordt is hieronder schematisch weergegeven.
Figuur 6. Proces informatieverzoeken BRO 4.3.1
Autorisatie Voor de beveiliging van de webservices zal gebruik worden gemaakt van de Webservices Security standaard. Daarbij wordt gebruik gemaakt van PKI certificaten met asymmetrische encryptie. Een beschrijving van de WSSecurity standaard is te vinden op:
SOAP Interface Functies Functie findLocation(findLocationRequest) Geeft de brandputten in het aangegeven geografisch gebied. Input (findLocationRequest) Omschrijving Minimale X-coördinaat (rijksdriehoekstelsel) Minimake Y-coördinaat (rijksdriehoekstelsel) Maximale X-coördinaat (rijksdriehoekstelsel) Maximale Y-coördinaat (rijksdriehoekstelsel) Output (findLocationResponse) Omschrijving Lijst van Brandputten
Datatype Double
Veldnaam MINX
Double
MAXX
Double
MINY
Double
MAXY
Datatype Well
Veldnaam WELLS
Functie findAddress(findAddressRequest) Geeft de brandputten op het aangegeven adres. Input (findAddressRequest) Omschrijving Adres Verplicht zijn: 1. postcode en huisnummer of, 2. straatnaam, huisnummer en plaatsnaam Output (findAddressResponse) Omschrijving Lijst van Brandputten
Datatype Address
Veldnaam ADDRESS
Datatype Well
Veldnaam WELLS
Functie findWell(findWellRequest)
34
Geeft de brandputt van het opgegeven id. Input (findWellRequest) Omschrijving Well id
Output (findWellResponse) Omschrijving Well
Datatype Character string
Veldnaam WELL_ID
Datatype Well
Veldnaam WELL
Functie findWellIds(findWellIdsRequest) Geeft de brandputten op het aangegeven adres. Input (findWellIdsRequest) Omschrijving (geen) Output (findWellIdsResponse) Omschrijving Lijst met identificatie nummers
Datatype
Veldnaam
Datatype Well
Veldnaam WELLS_IDS
Data typen Data typen Well Omschrijving Brandput id Positie x coordinaat (rijksdriehoekstelsel) Positie y coordinaat (rijksdriehoekstelsel) Laatst bekende capaciteit (m3/s) Laatste controledatum Status (bruikbaar of onbruikbaar) Address Omschrijving Straatnaam Huisnummer
Locatie test informatie verzoekdienst Inmiddels is er locatie beschikbaar gesteld vanuit TNO waar de test informatieverzoekdienst te benaderen is. De locatie van de dienst is: http://dinolab52.nitg.tno.nl/odp/BrandweerImpl?wsdl 4.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 - status (nader te specificeren). De eerste informatie over de specificaties is nu beschikbaar. Gegevens per brandkraan Dit betreft het eerste concept zoals dat gebruikt wordt bij de POC Geografisch 1. FID (Object ID) 2. Shape: Point (Geometry) Administratief 3. brkr_id 4. leveranc 5. gembrkr_nr 6. gem 7. capaciteit 8. cap_type 9. contr-dat 10. controleur 11. contr.org 12. status
13. begin_datum 14. eind_datum
uniek brandkraannummer per leverancier (Double) naam van de leverancier/bronhouder (Text) uniek brandkraannummer per gemeente (Double) gemeentenaam (Text) in m3/sec (Double) capaciteit_type ‘gemeten’ of ‘berekend’ (Text) controledatum (Date) naam (Text) naam organisatie controleur (Text) brandkraan op controle datum(Text): ‘goed’ (vindbaar en bruikbaar), ‘matig’ (vindbaar, buikbaar maar heeft onderhoud nodig), ‘slecht’ (vindbaar maar niet bruikbaar of onvindbaar) (Date) (Date)
37
Deze gegevens zijn voor het proefgebied Zwolle tijdelijk beschikbaar in de volgende formaten: WFS – T (Web Feature Service Transactions: webservice voor dedata op basis van open GIS standaard) SOAP (Simple Object Access Protocol: IT standaard voor berichtenuitwisseling) REST (Representational state transfer: ‘modernere’ en eenvoudiger versie van SOAP) 4.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. In het kader van de proef beperken we ons tot één bepaald risico: een lpg tankstation. De risicokaart heeft een WFS-dienst beschikbaar. Deze WFS-service biedt de bovenstaande gegevenselementen aan behalve de maximumhoeveelheid van een gevaarlijke stof.
- 77479.36 390083.058Gemeente BERGEN OP ZOOMTankstation Ozcan b.v.Van Konijnenburgweg814612PLBERGEN OP ZOOMBERGEN OP ZOOMBE2V8594 - - J 4.6
Verzoekbericht BGT/GBKN
Locatie: Communicatieprotocol: Inhoud en mapping bericht: 4.7
Incidentverzoekberichten
Incidentverzoekberichten zijn een speciaal soort informatieverzoeken.Wij gaan er in eerste instantie vanuit dat informatie zoveel mogelijk bij de bron betrokken zal worden. Mocht echter de verbinding naar de bronhouder(s) om wat voor reden dan ook niet beschikbaar zijn dan zijn deze berichten bedoeld om gegevensuitwisseling tussen servers onderling mogelijk te maken en daarmee grensoverschrijdend gebruik van informatie.
40
Dit type functionaliteit is nog niet opgenomen in het PvE. Daarom wordt hier kort stil gestaan hoe dit dient te werken in de praktijk en wanneer welke berichten gebruikt dienen te worden. Gebruik in de praktijk Als een incident wordt ingeschoten of ingevoerd, dat buiten de eigen regio ligt en deze niet direct bij de bron te halen zijn, dient eerst geconstateerd te worden dat de specifieke data niet onderdeel is in de eigen regio. Er wordt in een ‘tabel’gekeken in welke regio het object zich bevindt. In het kader van de proef wordt de regio waar het object zich in bevind bekend verondersteld. Dit deel van de functionaliteit wordt gesimuleerd. In de desbetreffende regio wordt naar het object gezocht. Zodra het object is gevonden wordt de objectinformatie van het object en van alle objecten die zich in een box van 50 meter in het vierkant om het object bevinden opgehaald. Daarnaast wordt van het object waar in eerste instantie op is gezocht de bijbehorende preventieve, preperatieve en repressieve informatie opgehaald en getoond op het scherm. Ook dient de informatie die niet gekoppeld is aan het object maar zich in een straal van 5 (of 10? of meer of niet?) meter van het object bevindt getoond. Op deze wijze wordt ook informatie getoond die wel betrekking heeft op het object maar niet direct aan het object is gekoppeld. Ook dient de bevelvoerder preventieve, preperatieve en repressieve informatie op te kunnen halen van omringende objecten. Dit is mogelijk door objecten in de omgeving aan te klikken. Deze informatieverzoeken worden niet bij het eerste verzoek meegestuurd omdat dit kan leiden tot nodeloze vertraging door het opvragen van veel gegevens die wellicht niet noodzakelijk zijn. Als een bevelvoerder inzoomt dan wordt het te bekijken gebied verkleint. Dit leidt niet tot nieuwe informatieverzoeken. Als een bevelvoerder uitzoomt dan dient alle objectinformatie opgevraagd te worden van de objecten die zich in de nieuwe box bevinden. Dit leidt niet tot opvagen van nieuwe preventieve, preperatieve en repressieve informatie. Om dit mogelijk te maken zijn er 2 berichten noodzakelijk: - een verzoekbericht waarin alle objectgegevens worden uitgevraagd in een bepaalde box - een verzoekbericht waarin de preventieve, preperatieve en repressieve gegevens die aan het object gekoppeld zijn of die zich in de directe nabijheid van het object bevinden maar die niet direct aan het direct gekoppeld zijn wordt uitgevraagd. Deze gegevens dienen via standaard WFS beschikbaar gesteld te worden. De WFS wordt aangeroepen door middel van de hierboven benoemde verzoekberichten.
41
Locatie: nader te bepalen, hangt af van waar de servers komen te staan. Verzoekbericht objectgegevens Request: getfeature Service=WFS Version=zie standaard BBOX=min x, max x, min y, max y feature is object - pand-ID - pand-geometrie - adres - postcode - huisnummer compleet - woonplaats. - gebruikstype - verblijf aantal - verblijf tijdvakken - zelfredzaamheid - toegang terrein - gevel- en eventueel detailfoto. (deze komen volgens mij grotendeels uit de BAG). Verzoekbericht brandweerspecifieke gegevens Preventieve gegevens - BHV (ja/nee)(verzamelpunt) Vergunning? - brandcompartimentering (waar; welke) Vergunning / bouwtekening? - brandmeldpaneel (waar) - automatische blusinstallatie Ja/Nee - rook en warmte-afvoerinstallatie Ja/Nee - overdruk-, stuwdrukinstallatie (parkeergarage, tunnel). Preparatieve gegevens (blauw) - ingang brandweer, overige (waar) ZELF - sleutelbuis/-kluis (waar; sleutelhouder ) ZELF - brandkranen (capaciteit)(waar)VITENS / ZELF - open water (capaciteit)(waar) GBKN oid - geboorde put (capaciteit, open en gesloten)(waar) BRO - bluswaterriool (waar, capaciteit)ZELF? - droge stijgleiding, blusleiding (waar) ZELF? - hoofdafsluiters (waar)(welke) ZELF - C2000 binnendekking (andere communicatiesystemen). Repressieve gegevens - gebouwconstructie (welke) Vergunning - gevaarlijke stoffen (waar, welke, maximale hoeveelheid)PRK
42
- kabels en leidingen (groot)(waar; aard)? - inzetprocedure (bijzondere)ZELF - bijzonderheden (overig)ZELF - opstelpunt (waar). ZELF
43
5
Berichten tussen de DBK-applicatie en andere applicaties
We zien de volgende berichten tussen de DBK en andere applicaties ontstaan. 5.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: - 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). 5.1.1
Minimale inhoud incidentinformatiebericht
De incidentinformatie bestaat uit: Meldergegevens: - naam, adres, woonplaats, telefoonnummer Incidentlocatie: - adres, plaats, postcode, gemeente, coördinaten - type locatie (object, kruispunt) met object-naam, objectfunctie, kruispuntnaam en/of naam van de kruisende straat Incidentgegevens: - incidentnummer - meldingsclassificatie - karakteristieken - prioriteit
44
Inzetgegevens: - roepnamen van alle overig gekoppelde eenheden (van alle disciplines) - roepnamen van alle geïnformeerde eenheden Overige gegevens die voor de eenheid van belang kunnen zijn: - AOL’s (voor de discipline Politie en geldend voor meldingsclassificatie en incidentlocatie van het incident) - kladblokregels (die zijn vastgelegd door een centralist behorende tot de betreffende discipline (POL of BRW)) - alléén bij de BRW worden verder nog de volgende gegevens meegestuurd: Vaknummer, Rampenplan, Aanvalsplan en Bereikbaarheidskaart 5.1.2
Globale beschrijving Architectuur
GMS server
Mobiele Data Terminals Politie GMS database
MDT Host Politie
overige GMSservices
MDT-koppelserver MDT Host CPA
GMS clients
Mobiele Data Terminals CPA
Schematisch kan de MDT-koppeling als volgt worden voorgesteld: - de MDT-koppelserver zal het initiatief nemen tot het opzetten van de datacommunicatie-verbindingen. Deze verbindingen blijven in principe intact - indien de verbinding tussentijds uitvalt zal de MDT-koppelserver periodiek trachten de verbinding weer te op te zetten - GMS zal een mogelijkheid bieden waarmee de MDT-koppeling kan worden geconfigureerd - de MDT-koppelserver zal, in opdracht van de centralist of automatisch, informatie naar de MDT-host versturen. Deze informatie wordt middels berichten, zoals gespecificeerd in deze koppelingspecificaties verstuurd - de MDT-koppelserver zal berichten die binnenkomen vanuit de MDT-host verwerken en daarna andere GMS subsystemen, zoals werkstations of andere GMS-services informeren.
45
Globale werking van de koppeling. Een levenscyclus van een logische verbinding tussen het GMS-koppelproces en een extern systeem bestaat uit 2 fasen. De eerste fase, de initialisatiefase, bestaat uit het opbouwen van de (tcp/ip-) verbinding tussen het koppelproces en het externe systeem Wanneer het GMS MDT-koppelproces wordt gestart zal verbinding worden gezocht met de externe MDT-systemen3. Wanneer het opbouwen van de verbinding niet lukt volgt een retry-strategie om te trachten de verbinding alsnog tot stand te brengen (zie [1]). De tweede fase is de operationele fase. Tijdens de operationele fasen vinden alle berichtencycli plaats (behalve de initialisatiecyclus). Ook wordt tijdens de operationele fase de verbinding middels echo-berichten bewaakt (zie [1]). De operationele fase eindigt wanneer de verbinding wordt verbroken of wegvalt, of wanneer het MDT-koppelproces wordt gestopt. Globale beschrijving van de functionaliteit. De functionaliteit van de GMS-MDT-koppeling bestaat uit: versturen incidentinformatie naar politie-eenheden Voor gedetailleerde omschrijving specificatie MDT-koppeling zie: #515372 v2 - (NBRA042) Specificatie berichtenverkeer DBK 5.2
Melding ter plaatse
Dit is feitelijk een AVLS-functionaliteit. 5.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.
3
Versie 2 van de koppeling is geschikt voor het versturen van incident- en ritinformate naar MDTsystemen van de disciplines Politie en CPA
46
5.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 (e-mails). 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 (??) - bijgevoegd pdf-bericht - bijgevoegd url/link naar DBK-applicatie. De wijzigingen van één object worden samengevoegd in één bericht.
