NVBR. Specificatie berichtenverkeer DBK 5 mei Concept 0.5

Transcriptie

1 NVBR Specificatie berichtenverkeer DBK 5 mei 2009 Concept 0.5

2 NVBR Stationsplein 1 Postbus AX Amersfoort Telefoon Specificatie berichtenverkeer DBK Versie Toevoeging Opmerking Beschreven welke stukken uit BAGdocumentatie relevant zijn in Locatie TNO test informatieverzoekdienst is opgenomen in paragraaf De eerste informatie over de specificaties over brandkranen is opgenomen in paragraaf Berichtspecificaties opgenomen voor terugmelden aan de TMF onder paragraaf 3.3 De gehele BAG-documentatie is als bijlage toegevoegd. Albert van Duijn Eric van Capelleveen Amersfoort, 5 mei /ADN/AKQ

3 Inhoudsopgave 1 Inleiding Soort bericht Specificatie per bericht Bronhouders Status berichtspecificatie Leeswijzer 9 2 Notificatieberichten Notificatieverzoek BAG Notificatieverzoek BGT/GBKN 11 3 Terugmeldberichten Terugmelden via de TMF Terugmelding BAG Terugmelding BRO Service proces Security SOAP Interface Functies Data typen Terugmelding PRK 17 4 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 40

4 5 Berichten tussen de DBK-applicatie en andere applicaties Melding incident Minimale inhoud incidentinformatiebericht Globale beschrijving Melding ter plaatse Wijziging symbool Wijziging gegevens 47

5 1 Inleiding Voor u ligt het berichtenboek Digitale Bereikbaarheidskaart (DBK). In dit berichtenboek worden in het kader van de POC 1 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

6 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. Gemeente Y Regio B bronhouders Gebiedsproblematiek Regio A Gemeente bijstand X Gemeente Y Regio B Incident verzoek bijstand Gemeente X Regio A bronhouders 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

7 BRONHOUDER Omgeving Ondergrond Server bron data TerugMeld Faciliteit TMF wordt was / Data XY Venster binnen Xmin XY Venster binnen W/W venster data Notificatieverzoek XminXY Datum/Tijd A tijdvak VensterDatum/Tijd B InformatieverzoekYmin Xmax Ymax Xmax Ymax Data XY Venster binnen Incidentverzoek XY Venster Bevestiging verwerking TerugmeldingXmin Ymin Xmax Ymax W/W Data Brandweerserver BRANDWEER GEMEENTE Omgeving Lage 24 x uitval 7 Was wordt kopie data/ Figuur 2. Berichtsoorten per bronhouder Onderstaande tabel geeft aan in welk proces welke berichten gebruikt zullen worden: Tabel 1. Berichtsoorten per werkproces Info verzoek Notificatie Terugmelding Incidentverzoek bericht Maken x x Gebruiken x x Beheren 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

8 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). ( 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 WA- BO/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

9 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 informatieverzoek incidentverzoek wordt in het begeleidend schrijven toegelicht. Welke WABO BRO BAG terugmelding berichten POC DBK Gemeente DBK applicatie X Regio A incident VEWIN PRK BGT VEWIN WABO BRO BAG PRK BAGWABOBROVEWINPRKBGT?Status BGT? notificatieverzoek Figuur 3. Berichten in de POC 7

10 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 documentatie 2 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: html voor gedetailleerde informatie over het IPM 4.0 model 8

11 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

12 Berichtenverkeer derden Verzoek BGT Notificatie BAG Notificatie WABO Notificatie Ondergrond Notificatie Bluswater Notificatie RRGS/PRK Notificatie BGT Incidentverzoek berichten Berichtenverkeer binnen brandweerdomein 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

13 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 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

14 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 XSD Group/element Objecttag objectidentificatie attribuutidentificatie 12

15 Groep / element contact-naam contact-telefoon contact- bijlage XSD Group / element contactinfo.naam contactinfo.telefoon contactinfo. attachment.filename attachment.base64attachment 3.2 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

16 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 Service proces Het proces dat gevolgd wordt is hieronder schematisch weergegeven. 14

17 Zoekopdracht Geautoriseerd? Ja Uitvoeren zoekopdracht Nee Gevonden? Ja Nee Gegevens retourneren Foutmelding retourneren Einde 15

18 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 Een beschrijving hiervan is te vinden op: SOAP Interface Functies Functie registerwell Verzoek tot registratie van een nieuwe put die voor de brandweer bruikbaar is. Input (registerwellrequest) Omschrijving Datatype Veldnaam Put gegevens Well WELL Output (registerwellresponse) Omschrijving Datatype Veldnaam Confirmatie van de aanname van het verzoek. Boolean ACCEPTED Functie mutatewell Verzoek tot het muteren van de gegevens van een specifieke put. Input (mutatewellrequest) Omschrijving Datatype Veldnaam Nieuwe put gegevens. Alle informatie uit de entiteit wordt als geheel aangemeld voor mutatie. Well WELL Output (mutatewellresponse) Omschrijving Datatype Veldnaam Confirmatie van de aanname van het verzoek. Boolean ACCEPTED 16

19 Functie unregisterwell Geeft de brandputt van het opgegeven id. Input (unregisterwellrequest) Omschrijving Datatype Veldnaam Well id Character string WELL_ID Output (unregisterwellresponse) Omschrijving Datatype Veldnaam Confirmatie van de aanname van het verzoek. Boolean ACCEPTED Data typen Data typen Well Omschrijving Datatype Veldnaam Brandput id Character WELL_ID string Positie X-coordinaat Double WELL_X (rijksdriehoekstelsel) Positie Y-coordinaat Double WELL_Y (rijksdriehoekstelsel) Laatst bekende capaciteit Double WELL_CAPACITY (m3/s) Laatste controledatum Date WELL_INSPECTION_DATE Status (bruikbaar of onbruikbaar) Character string WELL_STATUS 3.4 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

20 - gebruikstype Prevapcode - aard van de wijziging (in tekst) - verzender van de terugmelding - datum/tijd terugmelding. 18

21 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 De daadwerkelijke test van het koppelvlak BAG vanuit de DBKapplicaties kan dus pas vanaf dat moment plaatsvinden 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

22 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 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

23 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 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

24 Stuurinformatie Veld vergunningzaak en vergunningdocument Omschrijving Wordt gebruikt om aan te geven waar het XML-schema zich bevindt. XML <vergunningzaak xsi:schemalocation= vergunningzaak ></vergunningzaak> <vergunningdocument xsi:schemalocation= ngen/4.0/ vergunningdocument ></vergunningdocument> Veld transactietype Omschrijving Geeft het type bericht aan. Mogelijke waarden zijn C (create), U (update) en D (delete). XML <message><transactietype>c</transactietype></message> Veld transactieid Omschrijving Uniek kenmerk van het bericht. XML <message><transactieid>1</transactieid></message> Veld volgnummer Omschrijving Indien een bericht uit meerdere opeenvolgende berichten bestaat, wordt met dit veld het volgnummer aangegeven. XML <message><volgnummer>1</volgnummer></message> Veld aanmaakdatum Omschrijving Datum waarop het XML-bericht wordt aangemaakt, volgens syntax jjjj-mm-dd. XML <message><aanmaakdatum> </aanmaakdatum></message> 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, OW- MS-mantel en vergunningenmeta. 22

25 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 XML <dcterms:identifier > > 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 XML <dcterms:title>omgevingsvergunning Slopen, bouwen 2821 XS, 21 Stolwijk</dcterms:title> Veld Informatietype Status Verplicht. Komt voor Eén keer. 23

26 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. XML <dcterms:type scheme= overheid:informatietype >vergunning</dcterms:type> 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: nl- NL (Nederlands), of fy-nl (Fries). Waardebereik dcterms:rfc4646 XML <dcterms:language>nl-nl</dcterms:language> 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 ml (zie wijze van coderen). XML <dcterms:creator scheme= overheid:gemeente >Vlist</dcterms:creator> 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 XML <dcterms:modified> </dcterms:modified> 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

27 Waardelijsten nte.xml ie.xml chap.xml XML <dcterms:spatial scheme= overheid:gemeente >Vlist</dcterms:spatial> 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 <dcterms:temporal><start xmlns= > </start><end xmlns= > </end></dcterms:temporal> 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

28 XML <dcterms:description>slopen en bouwen van een woning aan de Bovenkerkseweg 21 te Stolwijk</dcterms:description> 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 Waardebereik 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). dcterms:uri XML <dcterms:haspart resourceidentifier= >Beschikking< /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 XML <dcterms:references >1234</dcterms:references> 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

29 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 XML <product><producttype>omgevingsvergunning</producttype></product> 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 XML <product><activiteit>slopen</activiteit><activiteit>bouwen</activiteit></product Informatie over termijnsoort en fase Een vergunning bevindt zich altijd in een bepaalde fase. Indien een overgang plaatsvindt van de ene naar de andere fase, wordt een nieuw XML-bericht naar de overheidsbrede zoekdienst gestuurd. Het nieuwe bericht bevat een update van de oude met een wijziging op in ieder geval de onderstaande twee velden. De ingangsdatum is de datum waarop de nieuwe fase ingaat (of ingegaan is). De mogelijke fasen zijn omschreven in het hieronder vermelde XML schema. Eigenschap Fase Status Verplicht. Komt voor Eén keer. Omschrijving D fase waarin de afhandeling van de vergunning zich bevindt. Waardebereik overheidvg:fase Waardelijst xml XML <termijn><fase>vergunning onherroepelijk</fase></termijn> 27

30 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 ijnsoort.xml XML <termijn><termijnsoortperiode><termijnsoort>vergunningsduur</termijnsoort></t ermijnsoortperiode></termijn> 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 <termijn><termijnsoortperiode><startdatumtermijn> </startdatumTermijn></termijnsoortPeriode></termijn> 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 <termijn><termijnsoortperiode><einddatumtermijn> </einddatumTermijn></termijnsoortPeriode></termijn> 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

31 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><bedrijfsnaam>bedrijf bv</bedrijfsnaam></actor> 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 <actor><bedrijfsnummer> </bedrijfsnummer></actor> 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 Notatiewijze Uitgebreid: Vier cijfers, twee hoofdletters, een reeks cijfers van het huisnummer, toevoeging. Minimaal: vier cijfers. XML <actor><bedrijfsadres>2821xs21</bedrijfsadres></actor> 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

32 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 <object><referentienummer> </referentienummer></object> 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 Notatiewijze Uitgebreid: Vier cijfers, twee hoofdletters, een reeks cijfers van het huisnummer, toevoeging. Minimaal: vier cijfers. XML <object><adres><postcodehuisnummer><huisnummer>13</huisnummer><postco de>1000ab</postcode></adres></postcodehuisnummer></object> Eigenschap huisletter, toevoeging HuisNummer Status Invullen indien beschikbaar. 30

33 Komt voor Nul of meerdere keren. Omschrijving toevoegingen aan huisnummer. Waardebereik Vrij tekstveld. XML <object><adres><postcodehuisnummer><huisnummer>21</huisnumject><adres><postcodehuisnummer><huisnummer>21</huis nummer><huisletter>b</huisletter><huisnummertoevoeging>bis< / huisnummertoevoeging> </postcodehuisnummer></adres></object> 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 <object> <adres><woonplaatsadres><woonplaats>stolwijk</woonplaats></woonplaats Adres></adres></object> Eigenschap straatnaam en huisnummer Status Invullen indien beschikbaar. Komt voor Nul of meerdere keren. Omschrijving Naam van de straat. Waardebereik Vrij tekstveld. XML <object><adres><woonplaatsadres><straat>bovenkerkseweg</straat><huisnumm er>21</huisnummer></woonplaatsadres></adres></object> 1c. Adresaanduiding: gemeente Eigenschap gemeente Status Invullen indien beschikbaar. Komt voor Nul of meerdere keren. Omschrijving Naam van de gemeente. Waardebereik overheid:gemeente Waardelijst te.xml XML <object> <adres><gemeente>vlist</gemeente></adres></object> 1d. Adresaanduiding: provincie Eigenschap provincie Status Invullen indien beschikbaar. Komt voor Nul of meerdere keren. Omschrijving Naam van de provincie. 31

34 Waardebereik overheid:provincie Waardelijst ie.xml XML <object> <adres><provincie>zuid- Holland</provincie></adres></object> 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 alegemeente.xml. XML <adres><perceel> <kadastralegemeente scheme= overheid:kadastralegemeente >Stolwijk</kadastraleGemeente><sectie> A</sectie><nummer>12</nummer> </perceel></adres> <adres><perceel> <Kadastralegemeente scheme= overheid:kadastralegemeente >Stolwijk</kadastraleGe meente><sectie>a</sectie><nummer>13</nummer> </perceel></adres> 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 <object><coordinaten><x-waarde>10000</x-waarde><ywaarde>10000</y-waarde></coordinaten></object> 32

35 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 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 WS- Security standaard is te vinden op: 33

36 pdf SOAP Interface Functies Functie findlocation(findlocationrequest) Geeft de brandputten in het aangegeven geografisch gebied. Input (findlocationrequest) Omschrijving Datatype Veldnaam Minimale X-coördinaat (rijksdriehoekstelsel) Double MINX Minimake Y-coördinaat Double MAXX (rijksdriehoekstelsel) Maximale X-coördinaat Double MINY (rijksdriehoekstelsel) Maximale Y-coördinaat (rijksdriehoekstelsel) Double MAXY Output (findlocationresponse) Omschrijving Datatype Veldnaam Lijst van Brandputten Well WELLS Functie findaddress(findaddressrequest) Geeft de brandputten op het aangegeven adres. Input (findaddressrequest) Omschrijving Datatype Veldnaam Adres Verplicht zijn: 1. postcode en huisnummer of, 2. straatnaam, huisnummer en plaatsnaam Address ADDRESS Output (findaddressresponse) Omschrijving Datatype Veldnaam Lijst van Brandputten Well WELLS Functie findwell(findwellrequest) 34

37 Geeft de brandputt van het opgegeven id. Input (findwellrequest) Omschrijving Datatype Veldnaam Well id Character string WELL_ID Output (findwellresponse) Omschrijving Datatype Veldnaam Well Well WELL Functie findwellids(findwellidsrequest) Geeft de brandputten op het aangegeven adres. Input (findwellidsrequest) Omschrijving Datatype Veldnaam (geen) Output (findwellidsresponse) Omschrijving Datatype Veldnaam Lijst met identificatie nummers Well WELLS_IDS Data typen Data typen Well Omschrijving Datatype Veldnaam Brandput id Character WELL_ID string Positie x coordinaat Double WELL_X (rijksdriehoekstelsel) Positie y coordinaat Double WELL_Y (rijksdriehoekstelsel) Laatst bekende Double WELL_CAPACITY capaciteit (m3/s) Laatste controledatum Date WELL_INSPECTION_DATE Status (bruikbaar of onbruikbaar) Character string WELL_STATUS Address Omschrijving Datatype Veldnaam Straatnaam Character STREET_NAME string Huisnummer Integer HOUSE_NR 35

38 Huisnummer toevoeging (optioneel) Postcode Plaatsnaam Character string Character string Character string HOUSE_NR_ADD POSTAL_CODE CITY Voorbeeld SOAP request <?xml version="1.0"?> <S:Envelope xmlns:s=" <S:Body> <ns2:findlocation xmlns:ns2=" <MINX>0.0</MINX> <MAXX>0.0</MAXX> <MINY>0.0</MINY> <MAXY>0.0</MAXY> </ns2:findlocation> </S:Body> </S:Envelope> SOAP response <?xml version="1.0"?> <S:Envelope xmlns:s=" <S:Body> <ns2:findlocationresponse xmlns:ns2=" <WELLS> <WELL_INSPECTION_DATE></WELL_INSPECTION_DATE> <WELL_STATUS>!!TEST!!</WELL_STATUS> <WELL_CAPACITY>0.0</WELL_CAPACITY> <WELL_ID>B11B0001</WELL_ID> <WELL_X>0.0</WELL_X> <WELL_Y>0.0</WELL_Y> </WELLS> <WELLS> <WELL_INSPECTION_DATE></WELL_INSPECTION_DATE> <WELL_STATUS>!!TEST!!</WELL_STATUS> <WELL_CAPACITY>0.0</WELL_CAPACITY> <WELL_ID>B11B0002</WELL_ID> <WELL_X>0.0</WELL_X> <WELL_Y>0.0</WELL_Y> </WELLS> <WELLS> <WELL_INSPECTION_DATE></WELL_INSPECTION_DATE> <WELL_STATUS>!!TEST!!</WELL_STATUS> <WELL_CAPACITY>0.0</WELL_CAPACITY> <WELL_ID>B11B0003</WELL_ID> <WELL_X>0.0</WELL_X> <WELL_Y>0.0</WELL_Y> </WELLS> </ns2:findlocationresponse> </S:Body> </S:Envelope> 36

39 4.3.4 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: 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 uniek brandkraannummer per leverancier (Double) 4. leveranc naam van de leverancier/bronhouder (Text) 5. gembrkr_nr uniek brandkraannummer per gemeente (Double) 6. gem gemeentenaam (Text) 7. capaciteit in m 3 /sec (Double) 8. cap_type capaciteit_type gemeten of berekend (Text) 9. contr-dat controledatum (Date) 10. controleur naam (Text) 11. contr.org naam organisatie controleur (Text) 12. status brandkraan op controle datum(text): goed (vindbaar en bruikbaar), matig (vindbaar, buikbaar maar heeft onderhoud nodig), slecht (vindbaar maar niet bruikbaar of onvindbaar) 13. begin_datum (Date) 14. eind_datum (Date) 37