GUF Berichtencatalogus uitgiftewebservice

1. Inleiding

1.1. Voorwoord

Betrouwbare en toegankelijke informatie over de samenstelling en opbouw van de ondergrond is van groot belang voor een dichtbevolkt land als het onze. Het helpt overheden, bedrijven en burgers om op feiten gebaseerde beslissingen te nemen over het gebruik van de ondergrond, bijvoorbeeld in verband met bereikbaarheid, waterveiligheid, warmte- en koudeopslag, aardgasproductie en de winning van aardwarmte. Ook voorkomen we zo dat informatie dubbel moet worden ingewonnen omdat het niet centraal is geregistreerd.

Het verzamelen, beschikbaar stellen, en gebruiken van al deze informatie is sinds september 2015 wettelijk vastgelegd in de Basisregistratie Ondergrond (BRO). Op 1 januari 2018 is het eerste deel van de Wet BRO in werking getreden, op 1 januari 2020 het tweede deel en op 1 januari c.q. 1 juli 2021 het derde deel.

Omdat de BRO een onderdeel is van het Stelsel van Basisregistraties, zijn verplichtingen met betrekking tot aanlevering, gebruik, terugmelding en onderzoek in de werkprocessen van overheidsorganisaties opgenomen in de Wet BRO. De BRO-gegevens worden centraal geregistreerd in de Landelijke Voorziening BRO (LV-BRO).

1.2. Doelstelling

Het document Handreiking Afname BRO Gegevens beschrijft via welke uitgiftekanalen BRO-gegevens geraadpleegd of gedownload kunnen worden en welke functionele en technische mogelijkheden deze kanalen bieden. Onder de noemer 'BRO uitgifte API' vallen dan in het bijzonder de 'REST uitgifteservice' en de 'SOAP webservice'.  Functioneel gezien lijken deze twee uitgifteservices veel op elkaar.

• De REST service is met name handig om als software ontwikkelaar 'incidenteel even snel en alleen publieke gegevens' op te halen uit de LV-BRO, zonder dat je je eerst moet aanmelden en zonder dat een PKIoverheid certificaat nodig is.

• De SOAP webservice is met name geschikt om frequent en volledig geautomatiseerd in een machine-to-machine omgeving toegang te hebben tot alle beschikbare gegevens. Hiervoor moet je je aanmelden en heb je een PKIoverheid certificaat nodig.

Blijft over de vraag: hoe zien de uitgifteverzoeken en hun antwoorden er uit en wat is de structuur van de diverse uitgiftedocumenten?

1.3. Doelgroepen

Doelgroepen voor dit document zijn organisaties en personen die aan de afnamekant van de BRO opereren, waaronder bestuursorganen (bestuurders, beleidsmakers, BRO-coördinatoren) en bedrijven (ingenieurs, software-leveranciers).

1.4. Samenhang met andere documentatie

De informatievoorziening over de afname van BRO-gegevens vindt plaats op 3 niveaus.

1. Het startpunt met algemene informatie over de diverse uitgiftekanalen is het document Handreiking Afname BRO Gegevens. Dit document verwijst door naar het volgende niveau.

2. Het tweede niveau bevat algemene informatie per uitgiftekanaal (zie https://basisregistratieondergrond.nl/inhoud-bro/aanleveren-opvragen/gegevens-opvragen/):

   1. De handleiding van de REST uitgifteservice is te vinden op https://www.bro-productomgeving.nl/bpo/latest/informatie-voor-softwareleveranciers/url-s-publieke-rest-services

   2. Algemene informatie over de SOAP webservice is te vinden op https://basisregistratieondergrond.nl/inhoud-bro/aanleveren-opvragen/instructies/gegevens-opvragen-via-soap-webservices/
      De handleiding voor het inrichten van SoapUI in het bijzonder is te vinden op https://basisregistratieondergrond.nl/inhoud-bro/aanleveren-opvragen/instructies/gegevens-opvragen-via-soap-webservices/aansluiten-demo-omgeving-soapui/

3. Het derde niveau is de BRO Productomgeving. Hier vindt u specifieke informatie per domein/registratieobjecttype zoals scopedocument, gegevenscatalogus en werkafspraken, storymap, berichtencatalogi voor inname en uitgifte, voorbeeldberichten voor inname en uitgifte.

Het verdient aanbeveling dat u zich eerst bekend maakt met de aangeven informatie uit de eerste 2 niveau's.

Daarna kunt u zich verdiepen in de GUF-specifieke informatie in de BRO productomgeving, waaronder de GUF gegevenscatalogus en eventuele werkafspraken en in het bijzonder dit document, de GUF berichtencatalogus uitgiftewebserevice.

1.5. Leeswijzer

Hoofdstuk 2 beschrijft de algemene werking van de GUF uitgiftewebservice.

Hoofdstuk 3 beschrijft de structuur van de diverse uitgiftedocumenten.

Hoofdstuk 4  bevat een toelichting op enkele voorbeeldberichten.

Hoofdstuk 5 bevat de toegestane waarden van de enumeraties (niet-beheerde lijsten met toegestane waarden).

Hoofdstuk 6 bevat verwijzingen (URN's en URL's) naar de codelijsten (beheerde lijsten met toegestane waarden).

Hoofdstuk 7 bevat een vertaaltabel, aan de hand waarvan, gegeven de Engelstalige naam van een entiteit of een attribuut, de Nederlandse naam in de catalogus kan worden opgezocht.

1.6. Versiehistorie

1.7. Contactinformatie

Algemene informatie en documentatie over de BRO kunt u vinden op  https://basisregistratieondergrond.nl/.

Heeft u een vraag over de BRO? Wij staan voor u klaar om u te helpen.  Voor vragen, suggesties of opmerkingen kunt contact opnemen met de BRO Servicedesk via een mail naar support@broservicedesk.nl.

Of bel ons op telefoonnummer 088 - 8664 999. Wij zijn bereikbaar op werkdagen van 8.00 tot 17.00 uur.

2. Algemene werking van de GUF uitgiftewebservice

Dit hoofdstuk beschrijft de algemene werking van de GUF uitgiftewebservice.

Paragraaf 2.1  beschrijft de operaties die de GUF uitgiftewebservice ondersteunt.

Paragraaf 2.2 beschrijft de BRO-berichten (request en response) die een rol spelen bij die operaties.

2.1. Operaties

De GUF uitgiftewebservice wordt gerealiseerd als een SOAP-webservice.

De wsdl kan worden gedowload van  https://schema.broservices.nl/dsguf-v1.0.wsdl

De GUF uitgiftewebservice ondersteunt twee soap operaties:

• dispatchCharacteristics (uitgifte van kengegevens).

• dispatchData (uitgifte van objectgegevens).

Een soap operatie heeft een request en een response:

• Het DispatchCharacteristicsRequest   (Verzoek tot uitgifte van kengegevens) en de DispatchCharacteristics Response  (Bericht van verzending van kengegevens).

• Het DispatchDataRequest   (Verzoek tot uitgifte van objectgegevens) en de DispatchDataResponse  (Bericht van verzending van objectgegevens).

Naast een functioneel antwoord (een bericht van verzending) kan ieder verzoek ook leiden tot een foutmelding:

• SOAP:Fault  (Systeemfout): als er tijdens de verwerking van het uitgifteverzoek een onverwachte fout optreedt in het BRO-systeem, dan leidt dit tot een  SOAP:Fault.

• ParseFault  (Validatiefout): als de uitgiftewebservice constateert dat een uitgifteverzoek niet een welgevormd XML-bericht is of dat het niet voldoet aan de XSD-schemavalidatie, dan leidt dit tot een ParseFault.

2.2. BRO-berichten

Deze paragraaf beschrijft de vier verschillende BRO-berichten (requests en responses) die een rol spelen in de GUF uitgiftewebservice.

2.3. DispatchCharacteristicsRequest

Het BRO-bericht DispatchCharacteristicsRequest  bevat het uitgifteverzoek tot het leveren van de in het BRO-register opgenomen kengegevens van de GUF registratieobjecten die voldoen aan bepaalde kenmerken.  Het DispatchCharacteristicsRequest (Verzoek tot uitgifte van kengegevens) van de GUF uitgiftewebservice is een specialisatie van  AbstractDispatchCharacteristicsRequest in de package brocommon, waaraan het het attribuut  criteria  (kenmerken) toevoegt met de GUF specifieke kenmerken.

De definities van de  transactiegegevens  staan in onderstaande tabel:

De  criteria  (kenmerken) worden gedefinieerd door het type  GUF_CriteriaSet van de GUF uitgiftewebservice. De GUF_CriteriaSet (kenmerkenverzameling) is een specialisatie van  CriteriaSet  uit package brommon,  waaraan het een aantal optionele attributen toevoegt .

De definities van de attributen  van de CriteriaSet uit brocommon  staan in onderstaande tabel:

De definities van de attributen, die  GUF_CriteriaSet uit dsguf-messages.xsd toevoegt aan CriteriaSet uit brocommon,  staan in onderstaande tabel:

2.4. DispatchDataRequest

Het BRO-bericht DispatchDataRequest  bevat het uitgifteverzoek tot het leveren van de in het BRO-register opgenomen gegevens van een bepaald registratieobject. Daarbij wordt het registratieobject geïdentificeerd door zijn BRO-ID.  Het DispatchDataRequest (Verzoek tot uitgifte van objectgegevens) van de GUF uitgiftewebservice is een specialisatie van  DispatchDataRequest in de package brocommon, waaraan het het attribuut  dataToBeDelivered  (te leveren gegevens) toevoegt.

De definities van de drie  transactiegegevens (uit brocommon en uit dsguf)  staan in onderstaande tabel:

Het gegeven  dataToBeDelivered   (te leveren gegevens) geeft aan welke gegevens over het registratieobject worden opgevraagd. Zie onderstaande tabel voor de lijst met toegestane waarden en hun betekenis:

2.5. SOAP:Fault

Tijdens de uitvoering van een operatie kan er een onverwachte fout optreden in het BRO-systeem. Hiervoor kunnen verschillende oorzaken zijn, zoals het falen van bepaalde software of hardware. Deze onverwachte fouten worden beschouwd als een technische fout veroorzaakt door het BRO-systeem. De BRO stuurt dan een bericht in de vorm van een generieke  SOAP:Fault (Systeemfout).

Een SOAP:Fault (Systeemfout) bestaat uit twee verplichte gegevens en één optioneel gegeven.  De definities van deze gegevens staan in onderstaande tabel:

2.6. ParseFault

Als er fouten in het uitgifteverzoek worden gevonden tijdens de technische controle van een uitgifteverzoek, bijvoorbeeld het uitgifteverzoek is niet een welgevormd XML-bericht of het uitgifteverzoek voldoet niet aan de schemavalidatie, dan worden deze beschouwd als een softwarefout in het systeem van de data-afnemer. Het BRO-systeem stuurt dan een bericht in de vorm van een  ParseFault  (Validatiefout).

Het BRO-bericht  ParseFault (Validatiefout) is in feite een gemodelleerde vorm van de algemene  SOAP:Fault (Systeemfout), waarbij op de plek van het  detail de gegevens van de ParseFault (Validatiefout) worden opgenomen. In de  ParseFault (Validatiefout) zit een lijst met  abortReasons  (Redenen afbreken).

Dit BRO-bericht begint met een SOAP:Fault (Systeemfout), bestaande uit drie gegevens, waarin het attribuut detail het specifieke type ParseFault (Validatiefout) heeft.  De definities van deze  gegevens  staan in onderstaande tabel:

De  ParseFault  (Validatiefout) bestaat uit drie gegevens en een lijst met abortReasons.  De definities van de  gegevens van ParseFault (Validatiefout)  staan in onderstaande tabel:

Iedere AbortReason  (Reden afbreken) bestaat uit twee gegevens. De definities staan in onderstaande tabel:

2.7. DispatchCharacteristicsResponse

Onder normale omstandigheden bestaat het antwoord op een DispatchCharacteristicsRequest (Verzoek tot uitgifte van kengegevens) uit een  DispatchCharacteriscticsResponse (Bericht van verzending van kengegevens).  Het antwoord  dispatchCharacteristicsResponse   is gedefinieerd in het XSD-bestand dsguf-messages.xsd. Het is een specialisatie van DispatchResponse zoals gedefinieerd in brocommon.xsd. Het voegt daaraan toe het attribuut  numberOfDocuments (aantal documenten) en een lijst met  dispatchDocuments  (uitgiftedocumenten).

Het BRO-bericht dispatchCharacteristicsResponse   kan twee betekenissen hebben:

• Een bericht van afwijzing.

• Een bericht van verzending van kengegevens.

Onderstaande tabel geeft weer welke gegevens onder welke omstandigheden in het BRO-bericht opgenomen zullen worden. De lijst met criterionErrors (kenmerkfouten) speelt alleen een rol bij de uitgifte van kenmerken.

Onderstaande tabel bevat de  definities van de  gegevens van  de  DispatchResponse :

Onderstaande tabel bevat de  definities van de  gegevens die  DispatchCharacteristicsResponse  uit dsguf-messages.xsd  toevoegt aan DispatchResponse uit brocommon:

De lijst met  dispatchDocument s (uitgiftedocumenten) is leeg als er geen registratieobjecten zijn gevonden die voldoen aan de criteria (kenmerken) in het dispatchCharacteristicsRequest (verzoek tot levering kengegevens).

Als er geen registratieobjecten zijn gevonden die voldoen aan de kenmerken, dan heeft het attribuut numberOfDocuments de waarde 0 en is de lijst met dispatchDocuments leeg.

Als er meer dan 2000 registratieobjecten zijn gevonden die voldoen aan de kenmerken, dan heeft het attribuut numberOfDocuments de waarde 2000 en is de lijst met dispatchDocuments beperkt tot dat aantal.

Ieder dispatchDocument (uitgiftedocument) is:

• óf van het type dsguf:GUF_C, met daarin de kengegevens van grondwatergebruiksysteem dat niet uit registratie is genomen,

• óf van het type brocom:BRO_DO, met daarin de kengegevens van een registratieobject dat uit registratie is genomen.

Het type  uitgiftedocument  BRO_DO is een specialisatie van AbstractRegistrationObject in de package brocommon. Dit type uitgiftedocument bestaat uit de gegevens:

• broId (BRO-ID).

• deregistered   (uit registratie genomen).

• deregistrationTime  (tijdstip uit registratie genomen)

Het type  uitgiftedocument  SFR_C is een specialisatie van AbstractCharacteristics in de package brocommon, wat op zijn beurt een specialisatie is van AbstractRegistrationObject. Dit type uitgiftedocument bestaat uit de gegevens:

• GroundwaterUsageFacility (Grondwatergebruiksysteem):

  • broId (BRO-ID).

  • deregistered   (uit registratie genomen).

  • deliveryAccountableParty  (bronhouder)

  • qualityRegime  (kwaliteitsregime)

  • objectRegistrationTime  (tijdstip registratie object)

  • latestCorrectionTime  (tijdstip laatste correctie)

  • underReview  (in onderzoek)

  • standardizedLocation  (gestandaardiseerde locatie)

  • deliveredLocation  (aangeleverde locatie)

• LicenceGroundwaterUsage (Recht grondwatergebruik):

  • identificationLicence (identificatie beschikking-melding)

  • legalType (rechtstype)

  • usageTypeFacility (gebruiksdoel systeem)

    • primaryUsageType (primair gebruiksdoel)

    • humanConsumption (menselijke consumptie)

  • licensedQuantity (maximale waterverplaatsing)

    • licensedInOut  ( verplaatsingsrichting)

    • maximumPerYear  ( maximaal per jaar)

• DesignInstallation (Ontwerpinstallatie):

  • installationFunction (installatiefunctie)

  • geometry (geometrie)

  • energyCharacteristics (energiekenmerken)

    • energyCold (energie koude per jaar)

    • energyWarm (energie warmte per jaar)

• DesignLoop (Ontwerpbodemlus):

  • geometry (geometrie)

• DesignSurfaceInfiltration (Ontwerpoppervlakteinflitratie):

  • geometry (geometrie), indien geometryPubliclyAvailable (openbaar raadpleegbaar) gelijk is aan 'Ja'.

• DesignWell (Ontwerpput):

  • geometry (geometrie), indien geometryP ubliclyAvailable (openbaar raadpleegbaar) gelijk is aan 'Ja'.

• RealisedInstallation (Gerealiseerde installatie):

  • installationFunction (installatiefunctie)

  • geometry (geometrie)

•  RealisedLoop (Gerealiseerde bodemlus):

  • geometry (geometrie)

• RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinflitratie):

  • geometry (geometrie), indien geometryP ubliclyAvailable (geometrie openbaar raadpleegbaar) gelijk is aan 'Ja'.

• RealisedWell (Gerealiseerde put):

  • geometry (geometrie), indien geometryP ubliclyAvailable (geometrie openbaar raadpleegbaar) gelijk is aan 'Ja'.

• RealisedScreen (Gerealiseerde filter):

• • geometry (geometrie), indien geometryP ubliclyAvailable (geometrie openbaar raadpleegbaar) gelijk is aan 'Ja'.

  • topScreenDepth (diepte bovenkant filter), indien topScreenDepthPubliclyAvailable (diepte bovenkant filter openbaar raadpleegbaar) gelijk is aan 'Ja'

2.8. DispatchDataResponse

Onder normale omstandigheden bestaat het antwoord op een dispatchDataRequest (verzoek tot uitgifte van objectgegevens) uit een  dispatchDataResponse (bericht van verzending van objectgegevens).  Het antwoord  DispatchDataResponse   is gedefinieerd in het XSD-bestand dsguf-messages.xsd. Het is een specialisatie van DispatchResponse zoals gedefinieerd in brocommon.xsd. Het voegt daaraan toe één optionele lijst met dispatchDocuments.

Het BRO-bericht dispatchDataResponse  kan twee betekenissen hebben:

• Een bericht van afwijzing.

• Een bericht van verzending van objectgegevens.

Onderstaande tabel geeft weer welke gegevens onder welke omstandigheden in het BRO-bericht opgenomen zullen worden. De lijst met criterionErrors (kenmerkfouten) speelt alleen een rol bij de uitgifte van kenmerken en dus niet bij de uitgifte van objectgegevens.

Zie de voorgaande paragraaf voor de  definities van de  gegevens van  de  DispatchResponse uit brocommon.

Onderstaande tabel bevat de  definities van de  gegevens die  DispatchDataResponse  uit dsguf-messages.xsd  toevoegt aan DispatchResponse uit brocommon:

3. Uitgiftedocumenten

Een uitgiftedocument bevat de gegevens van het opgevraagde registratieobject, die in het BRO-systeem geregistreerd zijn. De beschikbare gegevens zijn gedefinieerd in de catalogus.

De GUF uitgiftewebservice kent vijf types uitgiftedocumenten; zie onderstaande tabel. Welke type wordt uitgeleverd hangt af van de opgevraagde gegevens (zie het gegeven  dataToBeDelivered  (te leveren gegevens) in het  DispatchDataRequest), de identiteit van de afnemer en de registratiestatus van het registratieobject.

Onderstaande figuur geeft de uitgiftedocumenten (blauwe achtergrond) weer inclusief de mogelijke inhoud:

De featuretypes (objecttypes) LicenceGroundwaterUsage (Recht grondwatergebruik) en RealisedInstallation (Gerealiseerde installatie) en hun gerelateerde featuretypes zijn volledig gedefinieerd in de GUF gegevenscatalogus.

De attributen/gegevensgroepen met een schuine streep voor hun naam worden afgeleid door de GUF innamewebservice; deze gegevens worden niet aangeleverd via een brondocument.

De attributen met een min-teken voor hun naam worden alleen uitgeleverd in de GUF_PO_DP en GUF_PPO_DP varianten van de uitgiftedocumenten.

Een aantal geometry (geometrie) attributen wordt alleen uitgeleverd in de GUF_PO en GUF_PPO varianten als de waarde van het bijbehorende attribuut publiclyAvailable (openbaar raadpleegbaar) gelijk is aan 'ja'. Deze geometriën worden altijd uitgeleverd in de GUF_PO_DP en GUF_PPO_DP varianten.

3.1. Inhoud GUF_PO_DP

Uitgiftedocument GUF_PO_DP bevat:

• De actuele gegevens van een grondwatergebruiksysteem conform de GUF gegevenscatalogus,

  • aangevuld met de ObjectHistory (Objectgeschiedenis), die is afgeleid van de aangeleverde brondocumenten,

  • met daarin de lijst met Events (Gebeurtenissen), 

    • waarvan de date (gebeurtenisdatum) is afgeleid van een aangeleverde datum in het brondocument (begintijd, eindtijd of beginGeldigheid, afhankelijk van het betreffende brondocument)

    • en de name (gebeurtenisnaam) is afgeleid van de naam van het brondocument,

    • maar niet het sourceDocument (brondocument) bij een  Event (Gebeurtenis) .

In de LV-BRO kunnen features (objecten) zitten met een endValidity (eindGeldigheid) en/of een endTime (eindtijd). Het GUF_PO_DP uitgiftedocument bevat alleen de actuele gegevens, met ander woorden:

• een feature, anders dan het feature  GroundwaterUsageFacility (Grondwatergebruiksysteem), wordt alleen uitgegeven als het attribuut endValidity (eindGeldigheid) en het attribuut  endTime (eindtijd) beiden afwezig zijn in het feature .

• een feature LicenceGroundwaterUsage (Recht grondwatergebruik) met al zijn gerelateerde ontwerp installaties en onderdelen wordt alleen uitgegeven  als bij het feature  GroundwaterUsageFacility (Grondwatergebruiksysteem) het attribuut endTime (eindtijd) afwezig is.

• een feature  RealisedInstallation (Gerealiseerde installaties) met al zijn gerelateerde gerealiseerde installaties en onderdelen wordt alleen uitgegeven als bij het feature  GroundwaterUsageFacility (Grondwatergebruiksysteem) het attribuut endTime (eindtijd) afwezig is.

3.2. Inhoud GUF_PO

Uitgiftedocument GUF_PO bevat dezelfde gegevens als uitgiftedocument GUF_PO_DP, met uitzondering van de volgende gegevens (die ontbreken in GUF_PO):

• de attributen met een min-teken voor hun naam:

  • objectIdAccountableParty (object-ID bronhouder).

  • deliveryResponsibleParty (dataleverancier).

• de geometrie attributen als de waarde van het bijbehorende attribuut maximumWellDepthPubliclyAvailable (openbaar raadpleegbaar) gelijk is aan 'nee':

  • geometry (geometrie) van DesignSurfaceInfiltration (Ontwerpoppervalkteinfiltratie).

  • geometry (geometrie) van DesignWell (Ontwerpput).

  • geometry (geometrie) van RealisedSurfaceInfiltration (Gerealiseerde oppervalkteinfiltratie).

  • geometry (geometrie) van RealisedWell (Gerealiseerde put).

  • geometry (geometrie) van RealisedScreen (Gerealiseerd filter).

• de maximumWellDepth (Maximale putdiepte) van DesignWell ( Ontwerpput) als de waarde van het bijbehorende attribuut geometryPubliclyAvailable (maximale putdiepte openbaar raadpleegbaar   ) gelijk is aan 'nee'

• designScreen (Filtertraject) van DesignWell ( Ontwerpput) als de waarde van het bijbehorende attribuut designScreenPubliclyAvailable   (filtertraject openbaar raadpleegbaar) gelijk is aan 'nee'

• wellDepth (Putdiepte) van RealisedWell (Gerealiseerde put) als de waarde van het bijbehorende attribuut wellDepthPubliclyAvailable  (putdiepte openbaar raadpleegbaar) gelijk is aan 'nee'

• topScreenDepthPubliclyAvailable  (Diepte bovenkant Filter) van RealisedScreen ( Gerealiseerde filter) als de waarde van het bijbehorende attribuut topScreenDepthPubliclyAvailable (diepte bovenkant filter openbaar raadpleegbaar ) gelijk is aan 'nee'

3.3. Inhoud GUF_PPO_DP

Uitgiftedocument GUF_PPO_DP bevat:

• De gegevens van een grondwatergebruiksysteem conform de GUF gegevenscatalogus, zoals aangeleverd in een GUF_StartRegistration brondocument en aangepast conform eventuele verwerkte correctieverzoeken voor het dit brondocument,

  • aangevuld met de ObjectHistory (Objectgeschiedenis), die is afgeleid van de aangeleverde brondocumenten,

  • met daarin de lijst met Events (Gebeurtenissen), 

    • waarvan de date (gebeurtenisdatum) is afgeleid van een aangeleverde datum in het brondocument (begintijd, eindtijd of beginGeldigheid, afhankelijk van het betreffende brondocument)

    • en de name (gebeurtenisnaam) is afgeleid van de naam van het brondocument

    • en het sourceDocument (brondocument) met daarin het bij deze gebeurtenis aangeleverde brondocument .

3.4. Inhoud GUF_PPO

Uitgiftedocument GUF_PPO bevat dezelfde gegevens als uitgiftedocument GUF_PPO_DP, met uitzondering van de volgende gegevens (die ontbreken in GUF_PPO):

• de attributen met een min-teken voor hun naam:

  • objectIdAccountableParty (object-ID bronhouder).

  • deliveryResponsibleParty (dataleverancier).

• de geometrie attributen als de waarde van het bijbehorende attribuut publiclyAvailable (openbaar raadpleegbaar) gelijk is aan 'nee':

  • geometry (geometrie) van DesignSurfaceInfiltration (Ontwerpoppervalkteinfiltratie).

  • geometry (geometrie) van DesignWell (Ontwerpput).

  • geometry (geometrie) van RealisedSurfaceInfiltration (Gerealiseerde oppervalkteinfiltratie).

  • geometry (geometrie) van RealisedWell (Gerealiseerde put).

  • geometry (geometrie) van RealisedScreen (Gerealiseerd filter).

• de maximumWellDepth (Maximale putdiepte) van DesignWell ( Ontwerpput) als de waarde van het bijbehorende attribuut geometryPubliclyAvailable (maximale putdiepte openbaar raadpleegbaar   ) gelijk is aan 'nee'

• designScreen (Filtertraject) van DesignWell ( Ontwerpput) als de waarde van het bijbehorende attribuut designScreenPubliclyAvailable   (filtertraject openbaar raadpleegbaar) gelijk is aan 'nee'

• wellDepth (Putdiepte) van RealisedWell (Gerealiseerde put) als de waarde van het bijbehorende attribuut wellDepthPubliclyAvailable  (putdiepte openbaar raadpleegbaar) gelijk is aan 'nee'

• topScreenDepthPubliclyAvailable  (Diepte bovenkant Filter) van RealisedScreen ( Gerealiseerde filter) als de waarde van het bijbehorende attribuut topScreenDepthPubliclyAvailable (diepte bovenkant filter openbaar raadpleegbaar ) gelijk is aan 'nee'

4. Voorbeeldberichten

4.1. Integrale XML-voorbeeldberichten

Integrale voorbeeldberichten zijn te vinden via deze link: GUF Voorbeeldberichten uitgiftewebservice.

4.2. XML-code snippets

Voorbeelden van een aantal algemene stukken XML-code (code snippets) zijn te vinden in de  Handreiking Afname BRO Gegevens.

5. Enumeraties

In de BRO wordt een onderscheid gemaakt tussen  beheerde waardenlijsten  en  niet-beheerde waardenlijsten.

In de gegevenscatalogus en de XSD-bestanden noemen we een niet-beheerde waardenlijst een enumeratie. Bij een enumeratie staat de lijst met toegestane waarden vast en kan de lijst met toegestane waarden niet veranderd worden zonder aanpassingen in de gegevenscatalogus, de berichtdefinities (XSD-bestanden) en de software (voor het maken of verwerken van een bericht).

De onderstaande tabel geeft een overzicht van de GUF-specifieke enumeraties.

• De eerste kolom bevat de Engelstalige naam van de enumeratie, zoals deze voorkomt in de XSD-bestanden.

• De tweede kolom bevat de Nederlandstalige naam, zoals die voorkomt in de gegevenscatalogus.

• De derde kolom bevat de toegestane waarden, die gebruikt mogen worden in een BRO-verzoek.

• De vierde kolom bevat een omschrijving van de toegestane waarde.

6. Codelijsten

In de BRO wordt een onderscheid gemaakt tussen  beheerde waardenlijsten  en  niet-beheerde waardenlijsten.

In de gegevenscatalogus en de XSD-bestanden noemen we een  beheerde waardenlijst  een codelijst. Het domein van een  codelijst  is een uitbreidbare opsomming van toegestane waarden.

De onderstaande tabel geeft een overzicht van de GUF-specifieke codelijsten.

• De eerste kolom bevat de Engelstalige naam van de codelijst, zoals deze voorkomt in de XSD-bestanden.

• De tweede kolom bevat de Nederlandstalige naam, zoals die voorkomt in de gegevenscatalogus.

• De derde kolom bevat de URN, die in een BRO-verzoek gebruikt moet worden bij het XML-attribuut codeSpace . Zie Codelist (Codelijst) en de voorbeeldberichten voor nadere informatie.

• De vierde kolom bevat een link naar de website waar de actuele lijst met de toegestane waarden is te raadplegen, die in een BRO-verzoek gebruikt mogen worden als waarde voor een XML-element.

7. Vertaaltabel

Dit hoofdstuk bevat een vertaaltabel, aan de hand waarvan, gegeven de Engelstalige naam van een complexType of element of een attribuut in de XSD-bestanden, de Nederlandse naam in de gegevenscatalogus kan worden opgezocht.

De onderstaande tabel is gesorteerd op alfabetische volgorde van de Engelstalige naam van het complexType/element. Tussen haakjes staat het type modelelement van de entiteit. Binnen een entiteit zijn de attributen gesorteerd op Engelstalige naam.