GUF Berichtencatalogus innamewebservice

Dit document beschrijft het aanleveren van gegevens van een grondwatergebruiksysteem (GUF).

De preferente route voor het aanleveren van gegevens voor Grondwatergebruiksysteem en Grondwaterproductiedossier is via het Landelijk Grondwater Register

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 Nederland. 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. Centrale registratie van gegevens voorkomt dat informatie dubbel moet worden ingewonnen.

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).

In het document Handreiking Afname BRO Gegevens wordt beschreven via welke uitgiftekanalen BRO-gegevens geraadpleegd of gedownload kunnen worden en welke functionele en technische mogelijkheden deze kanalen bieden.

In het document Handreiking aanleveren BRO-gegevens heeft men algemene informatie kunnen inwinnen over:

• Hoe kun je een BRO-verzoek als een XML-bestand opstellen?

• Hoe ziet zo'n XML-bestand er uit?

• Hoe moet je te werk gaan als de gegevens in één keer beschikbaar komen dan wel beetje bij beetje in de loop der tijd?

• Hoe kunnen verandering van waarden in de loop der tijd gemeld kunnen worden?

• Hoe kun je een fout in de geregistreerde gegevens corrigeren?

Blijft over de vraag: met welke brondocumenten kunnen gegevens over een Grondwatergebruiksysteem (GUF) aangeleverd of gecorrigeerd worden en welke andere GUF-specifieke informatie is er beschikbaar naast de algemene informatie in de Handreiking aanleveren BRO-gegevens?

1.2. Doelstelling

Dit document bevat GUF- specifieke informatie voor het aanleveren en corrigeren van gegevens over een grondwatergebruiksysteem. Hierbij gaat het met name over:

• Welke GUF-specifieke brondocumenten zijn er als eenheid voor het aanleveren of corrigeren van gegevens?

• Welke combinaties van brondocument en type correctieverzoek zijn toegestaan?

• Welke GUF-specifieke aanvullende regels zijn er, naast de bedrijfsregels in de GUF-gegevenscatalogus en de algemene aanvullende regels in de Handreiking aanleveren BRO-gegevens?

• Welke GUF-specifieke codelijsten zijn er en waar kunnen hun toegestane waarden geraadpleegd worden?

• Is er een tabel waarmee een Engelstalige naam in de XML-bestanden kan worden omgezet naar de Nederlandstalige naam in de gegevenscatalogus?

1.3. Doelgroep

Doelgroep voor dit document zijn organisaties en personen, waaronder bestuursorganen en bedrijven, die opereren als bronhouder, gegevensleverancier of softwareleverancier en die betrokken zijn bij het opstellen van BRO-verzoeken. En die gegevens over een Grondwatergebruiksystem (GUF) moeten aanleveren of hierover geregistreerde gegevens moeten corrigeren.

1.4. Samenhang met andere documentatie

De informatievoorziening over het aanleveren aan de BRO vindt plaats op 3 niveaus. Zie onderstaande figuur.

1. Het startpunt met algemene informatie over de BRO is de website www.basisregistratieondergrond.nl. Een stappenplan voor het verkrijgen van toegang tot het Bronhouderportaal is te vinden op https://basisregistratieondergrond.nl/inhoud-bro/aanleveren-opvragen/tools-tips/bronhouderportaal.

2. Het tweede niveau is het Bronhouderportaal (https://www.bronhouderportaal-bro.nl/login), met rechtsonderaan een link naar de gebruikshandleiding (zie https://doc.bronhouderportaal-bro.nl/).

3. Het derde niveau is de BRO Productomgeving. Hier vindt u onder meer algemene informatie over het aanlever- en afnameproces, wijzigings- en versiebeheer en Q&A voor softwareleveranciers, maar ook specifieke informatie van de beschikbare types registrieobjecten 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 en het document Handreiking aanleveren BRO-gegevens in de BRO productomgeving.

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 innamewebservice.

1.5. Leeswijzer

Hoofdstuk 2 bevat een beschrijving van de Brondocumenten, inclusief een overzicht met welke combinaties van brondocument en type correctieverzoek zijn toegestaan en de bijbehorende aanvullende regels.

Hoofdstuk 3 bevat enkele Scenario's voor het aanleveren van registratieverzoeken en correctieverzoeken.

Hoofdstuk 4 beschrijft enkele integrale Voorbeeldberichten (XML-bestanden).

Hoofdstuk 5 bevat een overzicht van de GUF-specifieke Codelijsten (beheerde waardelijsten) met een link naar de webpagina waar de lijst met toegestane waarden geraadpleegd kan worden.

Hoofdstuk 6 bevat een Vertaaltabel, waarmee de GUF-specifieke Engelstalige namen van onderdelen in de XSD en XML-bestanden kunnen worden omgezet in Nederlandstalige namen in de gegevenscatalogus.

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. Brondocumenten

Dit hoofdstuk definiëert de brondocumenten voor het starten, aanvullen en beëindigen van de registratie van een GUF. Dezelfde brondocumenten kunnen ook gebruikt worden om geregistreerde gegevens te corrigeren.

De entiteiten en attributen in dit document worden aangeduid met de Engelstalige namen, zoals die voorkomen in de XSD-bestanden (de formele berichtdefinities) en de XML-bestanden (met de BRO-verzoeken). Met behulp van de Vertaaltabel kunnen deze worden omgezet in de Nederlandstalige namen in de GUF-gegevenscatalogus.

2.1. Levensloop, materiële geschiedenis en tijdlijn.

Het grondwatergebruiksysteem is een registratieobject met levensloop (waar in de loop van de tijd aanvullingen geregistreerd worden) en het bouwt materiële geschiedenis op voor een aantal attributen. Aanvullingen en veranderingen naar aanleiding van een gebeurtenis in de werkelijkheid worden vastgelegd in een tijdlijn. Zie de Handreiking aanleveren BRO-gegevens voor een beschrijving van deze termen.

De registratie wordt gestart nadat de vergunning voor een grondwatergebruiksysteem is verleend of de melding is afgehandeld. Op dat moment worden de gegevens van het Recht grondwatergebruik (melding / beschikking) geregistreerd in de BRO samen met de gegevens over de ontwerpinstallatie met haar subonderdelen. De gegevens over de ontwerpinstallatie staan in de beschikking/melding.

Eenvoudige tijdlijn van registreren en beëindigen van een GUF.

Nadat de vergunning is verleend of de melding is afgehandeld, wordt de installatie (of installaties) gerealiseerd. Na afloop van de realisatie van deze installatie met haar subonderdelen worden de gegevens hiervan geregistreerd in de BRO. Na verloop van tijd kunnen aanvullingen of veranderingen optreden die in de BRO geregistreerd worden. Aanvullingen zijn bijvoorbeeld dat er een extra put is gerealiseerd met gerealiseerd filter of zelfs een extra installatie met extra putten. Een verandering door de tijd heen is bijvoorbeeld: verandering van de maaiveldhoogte van een Gerealiseerde put.

Tijdlijn van een GUF waarbij gedurende de looptijd een aantal aanvullingen zijn geregistreerd. Op T3 wordt er een wijzigingsvergunning afgegeven waarmee extra ontwerponderdelen zijn toegestaan. Op T4 zijn deze extra onderdelen, als onderdeel van een bestaande installatie, gerealiseerd. Op T5 is de maaiveldhoogte veranderd.

Om complexiteit te verminderen is ervoor gekozen om in de objecten Recht grondwatergebruik en de ontwerpobjecten geen veranderingen te registreren. Deze objecten hebben alleen een begin- en eindtijd (datatype datum). Bij veranderingen krijgen de objecten een einddatum en worden er nieuwe objecten (met een nieuw ID en met een nieuwe begindatum) geregistreerd.

Gedurende de looptijd van een grondwatergebruiksysteem kunnen meerdere rechten (vergunningen of meldingen) geldig zijn. Echter, op ieder moment kan slechts 1 recht actief zijn.

Bij het registreren van een nieuw (toegevoegd of gewijzigd) recht worden ook alle onderliggende ontwerponderdelen opnieuw geregistreerd en worden de tot dan geldende rechten en bijbehorende ontwerponderdelen automatisch beëindigd. Gezien de registratieplicht (van 20 dagen) worden de betreffende gegevens in de BRO geregistreerd naar aanleiding van een melding of een voorlopig besluit tot het verlenen van een vergunning. In het laatste geval kan er bezwaar worden ingediend (gedurende een periode van ca 6 weken) voordat er een definitief/formeel besluit wordt genomen. Gedurende deze periode is het nieuwe recht al geregistreerd, terwijl het oude recht formeel nog geldig/relevant is. Desalniettemin wordt in de BRO het voorgaande recht automatisch beëindigd zodra het nieuwe recht wordt geregistreerd. Indien het besluit over het nieuwe recht positief/toewijzend is (maw: eventuele bezwaren worden ongegrond verklaard), dan is er bij deze automatische actie geen vervolgactie nodig. Indien het besluit over het nieuwe recht negatief/afwijzend is (dit komt in de praktijk weinig voor), dan moet het ten onrechte geregistreerde nieuwe recht worden aangepast met een replaceRequest, of in z'n geheel worden ingetrokken via een deleteRequest waardoor het voorgaande recht opnieuw van kracht wordt. De rationale achter deze automatische beëindiging van voorgaande rechten is dat:

• het risico / de impact dat wordt vergeten een voorgaand recht te beëindigen bij een positief/toewijzend besluit over een nieuw recht (en dat hier verwarring over ontstaat), groter is dan

• het risico / de impact dat een negatief/afwijzend besluit over een nieuw recht wordt vergeten in te trekken via een deleteRequest

• en/of het risico / de impact dat een afnemer van de BRO conclusies heeft verbonden aan het nieuw recht dat uiteindelijk werd ingetrokken/verwijderd.

Bij het registreren van een gewijzigd recht worden altijd de gegevens over de complete ontwerpinstallatie (bijv energiekenmerken) en subonderdelen (bijv putten) aangeboden bij de BRO. De aan te leveren gegevens omvatten zowel de bestaande als de toegevoegde ontwerpinstallaties (en subonderdelen). Alleen de maximale waterverplaatsing (op het niveau van Recht grondwatergebruik) zou in de praktijk kunnen wijzigen, zonder dat de onderliggende onderdelen wijzigen. Echter, ook in dat geval worden met het nieuwe recht tevens de (niet veranderde) ontwerp installatie(s) en subonderdelen geregistreerd en de oude rechten en ontwerpinstallaties afgesloten.

Het kan voorkomen dat er een wijziging plaatsvindt bij de ontwerponderdelen binnen een bestaande vergunning, dus zonder dat de vergunning aangepast wordt. Bijvoorbeeld als de geometrie van een ontwerpput binnen bepaalde marges is opgeschoven. In dat geval wordt er geen nieuw Recht grondwatergebruik geregistreerd ,maar wordt de aanpassing bij het ontwerponderdeel geregistreerd middels een correctiebericht (zie paragraaf Operaties).

2.2. Gebeurtenissen

Naar aanleiding van een in de werkelijkheid opgetreden gebeurtenis worden de relevante gegevens aangeboden aan de BRO in de vorm van een brondocument. Gezien de registratieplicht moet dit gebeuren binnen 20 dagen nadat de betreffende gegevens beschikbaar zijn gekomen (datum besluit, rapportage datum, intrichtingsdatum, etc). Deze berichtencatalogus definieert de verzameling brondocumenten en beschrijft hun inhoud. De gegevens in het brondocument worden gedefinieerd in de gegevenscatalogus.

Bij het verwerken van een brondocument houdt de LV-BRO de ObjectHistory (Objectgeschiedenis), die bestaat uit een lijst van Events (Gebeurtenissen). Per gebeurtenis wordt opgeslagen de datum, naam, identificatie (van Recht grondwatergebruik, Ontwerp installatie en haar onderdelen of Gerealiseerde installatie en haar onderdelen) en het aangeleverde brondocument. Een afnemer van de BRO kan deze ObjectHistory (Objectgeschiedenis) opvragen via de GUF uitgifteservice.

De gebeurtenisdatum wordt niet gedefinieerd in de gegevenscatalogus. De waarde ervan wordt afgeleid van een attribuut in het brondocument, bijvoorbeeld de begintijd van de levensduur van een object of de beginGeldigheid van de geldigheidsduur van een object als er materiële geschiedenis wordt opgebouwd.

De naam van de gebeurtenis wordt niet gedefinieerd in de gegevenscatalogus. De waarde ervan wordt afgeleid van het type brondocument. De lijst met toegestane waarden voor de naam van een gebeurtenis is opgenomen in een codelijst (zie hoofdstuk Codelijsten).

De optionele identifier identificeert een van de ontworpen of gerealiseerde onderdelen.

Het optionele brondocument bevat het naar aanleiding van de gebeurtenis aangeleverde brondocument.

2.3. Overzicht

Voor het aanbieden van (nieuwe of gecorrigeerde) gegevens kent de GUF-innamewebservice de volgende brondocumenten:

Bij veel registratieobjecten is er op een later moment, in samenwerking met het werkveld, een regeling getroffen waarbij reeds bestaande grondwatergebruiksystemen met een levensloop en materiële geschiedenis eenvoudiger en in 1 keer geregistreerd kunnen worden in de BRO. We voorzien dat dit mogelijk ook hier bruikbaar kan zijn. We hebben een dergelijk brondocument (GUF_StartWithHistory aka GUF-StartMetGeschiedenis) hier nog niet beschreven, omdat dit het beste op een later moment in samenwerking met het werkveld (in dit geval waarschijnlijk het LGR) gedaan kan worden.

Onderstaande tabel geeft per type brondocument weer wat de naam in een XML-bestand is, tot welke registratie status de verwerking ervan leidt en wat de naam van de af te leiden gebeurtenis is.

2.4. Operaties

Onderstaande tabel geeft per brondocument weer in welke registratie en correctie operaties het aangeboden kan worden.

2.4.1. Corrigeren van de tijdlijn

Het grondwatergebruiksysteem is een registratieobject met levensloop (waar in de loop van de tijd aanvullingen geregistreerd worden) en materiële geschiedenis (waarbij van bepaalde attributen opeenvolgende waarden in de werkelijkheid worden bijhouden). Deze aanvullingen en veranderingen worden vastgelegd in een tijdlijn. Zie paragraaf Levensloop, materiële geschiedenis en tijdlijn. en de Handreiking aanleveren BRO-gegevens voor nadere informatie.

Als gevolg hiervan moet het corrigeren van fouten in GUF gegevens gebeuren met behulp van 4 verschillende operaties:

• Gebruik een replaceRequest (vervangverzoek) om fouten in een brondocument te corrigeren, zonder gevolgen voor de tijdlijn. Concreet betekent dit dat met deze operatie het niet mogelijk is het gegeven in een brondocument te wijzigen, dat wordt opgeslagen in het attribuut date (datum gebeurtenis) van een Event (Gebeurtenis).

• Gebruik een moveRequest (verplaatsverzoek) om een gebeurtenis te verplaatsen in de tijdlijn. Hierbij kan alleen de datum in het brondocument worden gecorrigeerd, die wordt opgeslagen in het attribuut date (datum gebeurtenis) van een Event (Gebeurtenis).

• Gebruik een insertRequest (invoegverzoek) om een 'vergeten' gebeurtenis in te voegen in de tijdlijn (dus niet toevoegen aan het einde van de tijdlijn).

• Gebruik een deleteRequest (verwijderverzoek) om gebeurtenis te verwijderen uit de tijdlijn.

Ter herinnering: gebruik een registrationRequest (registratieverzoek) om een nieuwe gebeurtenis toe te voegen aan het einde van de tijdlijn.

2.4.2. Onveranderlijkheid van identificerende gegevens

Het is niet mogelijk met een replaceRequest (vervangverzoek) het gegeven in een brondocument te wijzigen, dat werd opgeslagen in het attribuut identifier (identificatie) van een Event (Gebeurtenis).

Bij GUF gaat het om de volgende gegevens:

• De identificationLicence (identificatie beschikking-melding) van een LicenceGroundwaterUsage (Recht grondwatergebruik).

• De designInstallationId (ontwerpinstallatie ID) van een DesignInstallation (Ontwerpinstallatie).

• De designLoopId (ontwerpbodemlus ID) van een DesignLoop (Ontwerpbodemlus).

• De infiltrationBasinId (ontwerpoppervlakteinfiltratie ID) van een DesignSurfaceInfiltration (Ontwerpoppervlakteinfiltratie).

• De designWellId (ontwerpput ID) van een DesignWell (Ontwerpput).

• De realisedInstallationId (gerealiseerde installatie ID) van een RealisedInstallation (Gerealiseerde installatie).

• De realisedLoopId (gerealiseerde bodemlus ID) van een RealisedLoop (Gerealiseerde bodemlus).

• De infiltrationBasinId (gerealiseerde oppervlakteinfiltratie ID) van een RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie).

• De realisedWellId (gerealiseerde put ID) van een RealisedWell (Gerealiseerde put).

• De realisedScreenId (gerealiseerde filter ID) van een RealisedScreen (Gerealiseerde filter).

Gebruik in voorkomende gevallen combinaties van een deleteRequest (verwijderen) en een insertRequest (invoegen) als het FeatureType (objecttype) werd geregistreerd als hoofdobject van een brondocument, dan wel een replaceRequest (vervangen) als het FeatureType (objecttype) werd geregistreerd als onderdeel van het hoofdobject van een brondocument. Het kan nodig zijn om eerst de tijdlijn (opeenvolgende gebeurtenissen) geheel of gedeeltelijk te verwijderen (met een of meerdere deleteRequests) en daarna opnieuw op te bouwen (met een of meerdere registrationRequests en/of insertRequests).

2.5. Inhoud brondocumenten

2.5.1. GUF_StartRegistration

Het brondocument wordt aangeboden wanneer er een nieuw grondwatergebruiksysteem wordt gestart. Het GUF wordt altijd met een LicenceGroundwaterUsage (Recht grondwatergebruik) gestart, inclusief alle bijbehorende designInstallations (ontwerpinstallaties) en subonderdelen, maar zonder gerealiseerde installatie(s). De gerealiseerde installaties worden met een ander brondocument als aanvulling geregistreerd.

Het starten van de registratie is een noodzakelijke eerste gebeurtenis, die per registratieobject maar één keer kan en moet plaatsvinden. Daarom zijn de BRO-verzoeken insertRequest en deleteRequest niet van toepassing. Het verwijderen van een registratieobject kan alleen door het registratieobject uit registratie te nemen. Neem hiervoor contact op met de BRO Servicedesk via een mail naar support@broservicedesk.nl .

2.5.1.1. Inhoud

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument.

De volgende gegevens staan niet in het brondocument

• maar wel aangeleverd in het bericht:

  • De deliveryAccountableParty (bronhouder) als de bronhouder een andere organisatie is dan de dataleverancier.

  • De deliveryResponsibleParty (dataleverancier).

  • Het qualityRegime (kwaliteitsregime).

• niet aangeleverd:

  • Het broId (BRO-ID). Bij een eerste aanlevering van dit brondocument genereert de BRO een waarde voor dit gegeven. Bij de aanlevering van dit brondocument in het kader van een correctie staat het broId (BRO-ID) niet in het brondocument maar wordt het aangeleverd in het bericht.

  • Gerealiseerde installatie en subonderdelen

2.5.1.2. Aanvullende regels

• Het attribuut endTime (eindtijd) mag niet aanwezig zijn in de attributegroup lifespan (levensduur) in het featuretype GUF_StartRegistration (GUF-StartRegistration) van het aangeleverde brondocument.

• Er moet exact 1 featuretype LicenceGroundwaterUsage (Recht grondwatergebruik) aanwezig zijn in het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype LicenceGroundwaterUsage (Recht grondwatergebruik) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype DesignInstallation (Ontwerpinstallatie) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype DesignLoop (Ontwerpbodemlus) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype DesignSurfaceInfiltration (Ontwerpoppervlakteinfiltratie) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype DesignWell (Ontwerpput) van het aangeleverde brondocument.

• Het attribuut geometry (geometrie) moet aanwezig zijn in het featuretype DesignSurfaceInfiltration (Ontwerpoppervlakteinfiltratie) van het aangeleverde brondocument.

• Het attribuut geometry (geometrie) moet aanwezig zijn in het featuretype DesignWell (Ontwerpput) van het aangeleverde brondocument.

2.5.1.3. Af te leiden gegevens

De volgende gegevens worden afgeleid:

• De startValidity (beginGeldigheid) van de validity (geldigheidsduur) van de GroundwaterUsageFacility (het Grondwatergebruiksysteem) wordt afgeleid van de startTime (begintijd) van de lifespan (levensduur) van de GroundwaterUsageFacility (het Grondwatergebruiksysteem).

• De attributen behorend bij de attributegroup StandardizedLocation (Gestandaardiseerde locatie).

• De attributen behorend bij de attributegroup RegistrationHistory (Registratiegeschiedenis).

• Een gegevensgroep objectHistory (objectgeschiedenis) met daarin een gegevensgroep Event (Gebeurtenis).

  • De date (datum) van de event (gebeurtenis) is de startTime (begintijd) van de lifespan (levensduur) van de GroundwaterUsageFacility (het Grondwatergebruiksysteem).

  • De name (naam) van de event (gebeurtenis) is 'StartRegistratie'.

  • De identifier (identificatie) van de event (gebeurtenis) blijft afwezig.

• De startTime (begintijd) van de lifespan (levensduur) van de LicenceGroundwaterUsage (het Recht grondwatergebruik) wordt afgeleid van de startTime (begintijd) van de lifespan (levensduur) van de GroundwaterUsageFacility (het Grondwatergebruiksysteem).

• De startTime (begintijd) van de lifespan (levensduur) van de DesignLoop (Ontwerpbodemlus) van de startTime (begintijd) van de lifespan (levensduur) van de GroundwaterUsageFacility (het Grondwatergebruiksysteem).

• De startTime (begintijd) van de lifespan (levensduur) van de DesignSurfaceInfiltration (Ontwerpoppervlakteinfiltratie) wordt afgeleid van de startTime (begintijd) van de lifespan (levensduur) van de GroundwaterUsageFacility (het Grondwatergebruiksysteem).

• De startTime (begintijd) van de lifespan (levensduur) van de DesignWell (Ontwerpput) wordt afgeleid van de startTime (begintijd) van de lifespan (levensduur) van de GroundwaterUsageFacility (het Grondwatergebruiksysteem).

2.5.2. GUF_NewLicence

Het brondocument wordt aangeboden wanneer er een nieuw LicenceGroundwaterUsage (Recht grondwatergebruik) ontstaat naar aanleiding van een nieuwe beschikking of melding. Het brondocument bevat een nieuw LicenceGroundwaterUsage (Recht grondwatergebruik) met alle bijbehorende ontwerpinstallaties en subonderdelen.

Bij het aanleveren van dit brondocument worden automatisch de voorgaande rechten en bijbehorende ontwerpinstallaties beëindigd (de bestaande voorkomens krijgen een afgeleide einddatum). De GroundwaterUsageFacility (het Grondwatergebruiksysteem) krijgt een nieuw voorkomen (met een afgeleide begindatum geldigheid) en het voorgaande voorkomen wordt afgesloten (krijgt een afgeleide einddatum geldigheid).

Het brondocument GUF_NewLicence (GUF-NieuwRecht) bevat alle designInstallations (ontwerpinstallaties) en subonderdelen die nodig zijn voor uitoefening van het nieuwe LicencesGroundwaterUsage (Rechten grondwatergebruik). Met andere woorden het brondocument bevat niet uitsluitend de toegevoegde of gewijzigde ontwerpinstallatie maar de gehele ontwerpinstallatie.

Zie voor nadere informatie ook de paragraaf Levensloop, materiële geschiedenis en tijdlijn.

2.5.2.1. Inhoud

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument.

De volgende gegevens staan niet in het brondocument maar worden wel aangeleverd in het bericht:

• Het broId (BRO-ID) van het registratieobject waar dit brondocument moet worden aangevuld of gecorrigeerd.

• De deliveryAccountableParty (bronhouder) als de bronhouder een andere organisatie is dan de dataleverancier.

• De deliveryResponsibleParty (dataleverancier).

• Het qualityRegime (kwaliteitsregime).

2.5.2.2. Aanvullende regels

• De actuele waarde van het attribuut registrationStatus (registratiestatus) van de gegevensgroep RegistrationHistory (Registratiegeschiedenis) mag niet gelijk zijn aan 'voltooid' als dit brondocument wordt aangeboden met een registrationRequest (registratieverzoek).

• De startTime (begintijd) in het brondocument moet liggen na de startTime (begintijd) van de lifespan (levensduur) van het tot op dat moment meest recente LicenceGroundwaterUsage (Recht grondwatergebruik).

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype DesignInstallation (Ontwerpinstallatie) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype DesignLoop (Ontwerpbodemlus) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype DesignSurfaceInfiltration (Ontwerpoppervlakteinfiltratie) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype DesignWell (Ontwerpput) van het aangeleverde brondocument.

• Het attribuut geometry (geometrie) moet aanwezig zijn in het featuretype DesignSurfaceInfiltration (Ontwerpoppervlakteinfiltratie) van het aangeleverde brondocument.

• Het attribuut geometry (geometrie) moet aanwezig zijn in het featuretype DesignWell (Ontwerpput) van het aangeleverde brondocument.

2.5.2.3. Af te leiden gegevens

De volgende gegevens worden afgeleid:

• Voorgaande recht en bijbehorende ontwerpinstallatie beëindigen:

  • De endTime (eindtijd) van de lifespan (levensduur) van het voorgaande LicenceGroundwaterUsage (Recht grondwatergebruik) wordt afgeleid van de startTime (begintijd) in het brondocument wanneer de endTime (eindtijd) van de lifespan (levensduur) niet aanwezig is.

  • De endTime (eindtijd) van de lifespan (levensduur) van alle bijbehorende DesignInstallation (Ontwerpinstallatie) wordt afgeleid van de startTime (begintijd) in het brondocument wanneer de betreffende endTime (eindtijd) van de lifespan (levensduur) niet aanwezig is.

  • De endTime (eindtijd) van de lifespan (levensduur) van alle bijbehorende DesignLoop (Ontwerpbodemlus) wordt afgeleid van de startTime (begintijd) in het brondocument wanneer de betreffende endTime (eindtijd) van de lifespan (levensduur) niet aanwezig is.

  • De endTime (eindtijd) van de lifespan (levensduur) van alle bijbehorende DesignSurfaceInfiltration (Ontwerpoppervlakteinfiltratie) wordt afgeleid van de startTime (begintijd) in het brondocument wanneer de betreffende endTime (eindtijd) van de lifespan (levensduur) niet aanwezig is.

  • De endTime (eindtijd) van de lifespan (levensduur) van alle bijbehorende DesignWell (Ontwerpput) wordt afgeleid van de startTime (begintijd) in het brondocument wanneer zo'n DesignWell (Ontwerpput) aanwezig is en de betreffende endTime (eindtijd) van de lifespan (levensduur) niet aanwezig is.

• Nieuw voorkomen voor het GroundwaterUsageFacility (het Grondwatergebruiksysteem):

  • De endValidity (eindGeldigheid) van het vorige voorkomen en de startValidity (beginGeldigheid) van het nieuwe voorkomen worden afgeleid van de startTime (begintijd) in het brondocument.

• Begintijd van nieuw recht en bijbehorende ontwerpinstallatie:

  • De startTime (begintijd) van de lifespan (levensduur) van het nieuwe LicenceGroundwaterUsage (Recht grondwatergebruik) wordt afgeleid van de startTime (begintijd) in het brondocument.

  • De startTime (begintijd) van de lifespan (levensduur) van alle bijbehorende ontwerponderdelen wordt afgeleid van de startTime (begintijd) in het brondocument.

• Een nieuwe gegevensgroep Event (Gebeurtenis):

  • De date (datum) van de event (gebeurtenis) wordt afgeleid van de startTime (begintijd) in het brondocument.

  • De name (naam) van de event (gebeurtenis) is 'NieuwRecht'.

  • De identifier (identificatie) van de event (gebeurtenis) wordt afgeleid van de identificationLicence (identificatie beschikking-melding) in het brondocument.

• De attributen behorend bij de attributegroup StandardizedLocation (Gestandaardiseerde locatie) worden (opnieuw) afgeleid.

2.5.3. GUF_AddRealisedInstallation

Het brondocument wordt aangeboden wanneer één of meer bodemlussen / oppervlakte-infiltraties / putten zijn gerealiseerd die deel uitmaken van een eerste of extra Gerealiseerde installatie. Dit brondocument bevat ook de verschillende gerealiseerde onderdelen (volgend uit de business rules GUF). Dit brondocument bevat, indien het een uitbreiding met een put betreft, ook het gerealiseerde filter. Daarnaast kan het eventueel gerelateerde verkenningen bevatten.

De aangeleverde subonderdelen moeten dezelfde begintijd hebben. Onderdelen met een latere begintijd moeten in een apart brondocument, GUF-UitbreidingGerealiseerdeInstallatie, aangeboden worden.

Afsluiten van installatie(onderdelen) kan niet middels dit brondocument. Daarvoor moet het brondocument GUF-BeeindigingGerealiseerdOnderdeel gebruikt worden.

Uit de catalogus: Levensduur gerealiseerde installatie: Het gegeven staat niet in een brondocument, maar wordt automatisch door de basisregistratie ondergrond afgeleid. De begindatum installatie is de oudste begindatum van de entiteit Gerealiseerde put of de oudste begindatum van de entiteit Gerealiseerde bodemlus of de oudste begindatum van de entiteit Gerealiseerde oppervlakteinfiltratie.

2.5.3.1. Inhoud

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument.

De volgende gegevens staan niet in het brondocument maar worden wel aangeleverd in het bericht:

• Het broId (BRO-ID) van het registratieobject waar dit brondocument moet worden aangevuld of gecorrigeerd.

• De deliveryAccountableParty (bronhouder) als de bronhouder een andere organisatie is dan de dataleverancier.

• De deliveryResponsibleParty (dataleverancier).

• Het qualityRegime (kwaliteitsregime).

2.5.3.2. Aanvullende regels

• De actuele waarde van het attribuut registrationStatus (registratiestatus) van de gegevensgroep RegistrationHistory (Registratiegeschiedenis) mag niet gelijk zijn aan 'voltooid' als dit brondocument wordt aangeboden met een registrationRequest (registratieverzoek).

• Het attribuut geometry (geometrie) moet aanwezig zijn in het featuretype RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) van het aangeleverde brondocument.

• Het attribuut geometry (geometrie) moet aanwezig zijn in het featuretype RealisedWell (Gerealiseerde put) van het aangeleverde brondocument.

• Het attribuut geometry (geometrie) in het featuretype RealisedScreen (Gerealiseerde filter) van het aangeleverde brondocument moet aanwezig zijn als de waarde van het attribuut screenType (filtertype) gelijk is aan nietVerticaal. Het attribuut mag niet aanwezig wanneer de waarde van het attribuut screenType (filtertype) gelijk is aan verticaal.

• De attributegroup validity (geldigheidsduur) mag niet aanwezig zijn in het featuretype RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) van het aangeleverde brondocument.

• De attributegroup validity (geldigheidsduur) mag niet aanwezig zijn in het featuretype RealisedWell (Gerealiseerde put) van het aangeleverde brondocument.

• De attributegroup validity (geldigheidsduur) mag niet aanwezig zijn in het featuretype RealisedScreen (Gerealiseerde filter) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype RealisedLoop (Gerealiseerde bodemlus) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype RealisedWell (Gerealiseerde put) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype RealisedScreen (Gerealiseerde filter) van het aangeleverde brondocument.

• De startTime (begintijd) van de aangeleverde gerealiseerde onderdelen moet liggen na de startTime (begintijd) van de GroundwaterUsageFacility (het Grondwatergebruiksysteem).

2.5.3.3. Af te leiden gegevens

De volgende gegevens worden afgeleid:

• GroundwaterUsageFacility (het Grondwatergebruiksysteem) krijgt een nieuw voorkomen. De endValidity (eindGeldigheid) van het vorige voorkomen en de startValidity (beginGeldigheid) van het nieuwe voorkomen worden afgeleid van het attribuut startTime (begintijd) in het brondocument.

• Voor de aangeleverde RealisedInstallation (Gerealiseerde installatie) wordt een lifespan (levensduur) afgeleid, waarbij de startTime (begintijd) wordt afgeleid van het attribuut startTime (begintijd) in het brondocument.

• Voor de aangeleverde gerealiseerde onderdelen wordt een validity (geldigheidsduur) afgeleid, waarbij de startValidity (beginGeldigheid) wordt afgeleid van het attribuut startTime (begintijd) in het brondocument.

• Voor de aangeleverde gerealiseerde onderdelen wordt een lifespan (levensduur) afgeleid, waarbij de startTime (begintijd) wordt afgeleid van het attribuut startTime (begintijd) in het brondocument.

• Een nieuwe gegevensgroep Event (Gebeurtenis):

  • De date (datum) van de event (gebeurtenis) wordt afgeleid van het attribuut startTime (begintijd) in het brondocument.

  • De name (naam) van de event (gebeurtenis) is 'ToevoegingGerealiseerdeInstallatie'.

  • De identifier (identificatie) van de event (gebeurtenis) wordt afgeleid van de realisedInstallationId (gerealiseerde installatie ID) in het brondocument.

• De attributen behorend bij de attributegroup StandardizedLocation (Gestandaardiseerde locatie).

2.5.4. GUF_ExpandRealisedInstallation

Het brondocument wordt aangeboden wanneer één of meer bodemlussen / oppervlakte-infiltraties / putten zijn gerealiseerd die deel uitmaken van een bestaande Gerealiseerde installatie (volgend uit de business rules GUF). Dit brondocument kan ook het gerealiseerde filter en eventueel gerelateerde verkenningen bevatten. Bij dit brondocument wordt daarnaast de geometrie en eventueel (bij wijziging) de installatiefunctie van de Gerealiseerde installatie aangeleverd. Er ontstaat een nieuw voorkomen van de Gerealiseerde installatie.

Uitgangspunt is dat alle onderdelen die tegelijk aangeboden worden dezelfde beginTijd hebben. Onderdelen met een latere begintijd moeten in een apart brondocument, GUF-UitbreidingGerealiseerdeInstallatie, aangeboden worden.

2.5.4.1. Inhoud

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument.

De volgende gegevens staan niet in het brondocument maar worden wel aangeleverd in het bericht:

• Het broId (BRO-ID) van het registratieobject waar dit brondocument moet worden aangevuld of gecorrigeerd.

• De deliveryAccountableParty (bronhouder) als de bronhouder een andere organisatie is dan de dataleverancier.

• De deliveryResponsibleParty (dataleverancier).

• Het qualityRegime (kwaliteitsregime).

2.5.4.2. Aanvullende regels

• De actuele waarde van het attribuut registrationStatus (registratiestatus) van de gegevensgroep RegistrationHistory (Registratiegeschiedenis) mag niet gelijk zijn aan 'voltooid' als dit brondocument wordt aangeboden met een registrationRequest (registratieverzoek).

• Het attribuut geometry (geometrie) moet aanwezig zijn in het featuretype RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) van het aangeleverde brondocument.

• Het attribuut geometry (geometrie) moet aanwezig zijn in het featuretype RealisedWell (Gerealiseerde put) van het aangeleverde brondocument.

• Het attribuut geometry (geometrie) in het featuretype RealisedScreen (Gerealiseerde filter) van het aangeleverde brondocument moet aanwezig zijn als de waarde van het attribuut screenType (filtertype) gelijk is aan nietVerticaal. Het attribuut mag niet aanwezig wanneer de waarde van het attribuut screenType (filtertype) gelijk is aan verticaal.

• De attributegroup validity (geldigheidsduur) mag niet aanwezig zijn in het featuretype RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) van het aangeleverde brondocument.

• De attributegroup validity (geldigheidsduur) mag niet aanwezig zijn in het featuretype RealisedWell (Gerealiseerde put) van het aangeleverde brondocument.

• De attributegroup validity (geldigheidsduur) mag niet aanwezig zijn in het featuretype RealisedScreen (Gerealiseerde filter) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype RealisedLoop (Gerealiseerde bodemlus) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype RealisedWell (Gerealiseerde put) van het aangeleverde brondocument.

• De attributegroup lifespan (levensduur) mag niet aanwezig zijn in het featuretype RealisedScreen (Gerealiseerde filter) van het aangeleverde brondocument.

• De startValidity ( beginGeldigheid) in het brondocument moet liggen na de startValidity ( beginGeldigheid) van het actuele voorkomen van RealisedInstallation (Gerealiseerde installatie) in de BRO.

2.5.4.3. Af te leiden gegeven

De volgende gegevens worden afgeleid:

• RealisedInstallation (Gerealiseerde installatie) krijgt een nieuw voorkomen. De endValidity (eindGeldigheid) van het vorige voorkomen en de startValidity (beginGeldigheid) van het nieuwe voorkomen worden afgeleid van het attribuut startValidity ( beginGeldigheid) in het brondocument.

• Voor de aangeleverde gerealiseerde onderdelen wordt een validity (geldigheidsduur) afgeleid, waarbij de startValidity ( beginGeldigheid ) wordt afgeleid van het attribuut startValidity (beginGeldigheid) in het brondocument .

• Voor de aangeleverde gerealiseerde onderdelen wordt een lifespan (levensduur) afgeleid, waarbij de startTime (begintijd) wordt afgeleid van het attribuut startValidity (beginGeldigheid) in het brondocument .

• Een nieuwe gegevensgroep Event (Gebeurtenis):

  • De date (datum) van de event (gebeurtenis) wordt afgeleid van het attribuut startValidity (beginGeldigheid) in het brondocument.

  • De name (naam) van de event (gebeurtenis) is 'UitbreidingGerealiseerdeInstallatie'.

  • De identifier (identificatie) van de event (gebeurtenis) wordt afgeleid van de realisedInstallationId (gerealiseerde installatie ID) in het brondocument.

• De attributen behorend bij de attributegroup StandardizedLocation (Gestandaardiseerde locatie).

2.5.5. GUF_GeometryRealisedSurfaceInfiltration

Het brondocument wordt aangeboden wanneer de geometrie van de gerealiseerde oppervlakte-infiltratie in de werkelijkheid wordt aangepast. Bijvoorbeeld wanneer er een nieuwe vergunning is afgegeven waarin er een groter volume geïnfiltreerd mag worden en de infiltratieplas groter is gemaakt. Er ontstaat een nieuw voorkomen van de Gerealiseerde oppervlakteinfiltratie.

2.5.5.1. Inhoud

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument.

De volgende gegevens staan niet in het brondocument maar worden wel aangeleverd in het bericht:

• Het broId (BRO-ID) van het registratieobject waar dit brondocument moet worden aangevuld of gecorrigeerd.

• De deliveryAccountableParty (bronhouder) als de bronhouder een andere organisatie is dan de dataleverancier.

• De deliveryResponsibleParty (dataleverancier).

• Het qualityRegime (kwaliteitsregime).

2.5.5.2. Aanvullende regels

• De actuele waarde van het attribuut registrationStatus (registratiestatus) van de gegevensgroep RegistrationHistory (Registratiegeschiedenis) mag niet gelijk zijn aan 'voltooid' als dit brondocument wordt aangeboden met een registrationRequest (registratieverzoek).

• De startTime (begintijd) in het brondocument moet liggen na de startValidity ( beginGeldigheid) van het vorige voorkomen van RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie).

2.5.5.3. Af te leiden gegevens

De volgende gegevens worden afgeleid:

• RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) krijgt een nieuw voorkomen. De endValidity (eindGeldigheid) van het vorige voorkomen en de startValidity (beginGeldigheid) van het nieuwe voorkomen worden afgeleid van het attribuut startTime (begintijd) in het brondocument.

• Een nieuwe gegevensgroep Event (Gebeurtenis):

  • De date (datum) van de event (gebeurtenis) wordt afgeleid van het attribuut startTime (beginTijd)in het brondocument.

  • De name (naam) van de event (gebeurtenis) is 'GeometrieOppervlakteinfiltratie'.

  • De identifier (identificatie) van de event (gebeurtenis) wordt afgeleid van de infiltrationBasinId (gerealiseerde oppervlakteinfiltratie ID) in het brondocument.

2.5.6. GUF_Height

Het brondocument wordt aangeboden wanneer de maaiveldhoogte verandert door een natuurlijk proces of door ophoging of afgraving van het maaiveld. Hiermee verandert, naast de maaiveldhoogte mogelijk (afhankelijk of de put wel/niet stabiel is) ook de putdiepte en de diepte bovenkant filter (van het Gerealiseerd filter). Er ontstaat een nieuw voorkomen van de Gerealiseerde put en mogelijk ook van het Gerealiseerde filter.

De maaiveldhoogte kan veranderen door een natuurlijk proces of door ophoging of afgraving van het maaiveld. Naast de maaiveldhoogte zelf, kan mogelijk ook de putdiepte en de diepte bovenkant filter (van het Gerealiseerde filter) veranderen maar dit hoeft niet. Het is afhankelijk of de put wel/niet stabiel is. Wanneer de putdiepte en de diepte bovenkant filter niet veranderen, wordt bij dit brondocument alleen gerealiseerd put ID, maaiveldhoogte en beginGeldigheid aangeleverd. Er worden in dit geval geen gegevens van het Gerealiseerde filter aangeleverd. Het ongewijzigde Gerealiseerde filter is dan gerelateerd aan het nieuwe voorkomen van de Gerealiseerde put.

In de gegevenscatalogus heeft het attribuut wellDepth (putdiepte) de eigenschap 'mogelijk geen waarde'. Bij het brondocument GUF_Height heeft het attribuut niet deze eigenschap, omdat het tegenstrijdig is dat de waarde van dit gegeven niet bekend is bij de gebeurtenis dat de maaiveldhoogte is veranderd en tevens bekend is dat de putdiepte en de diepte bovenkant filter zijn veranderd.

2.5.6.1. Inhoud

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument.

De volgende gegevens staan niet in het brondocument maar worden wel aangeleverd in het bericht:

• Het broId (BRO-ID) van het registratieobject waar dit brondocument moet worden aangevuld of gecorrigeerd.

• De deliveryAccountableParty (bronhouder) als de bronhouder een andere organisatie is dan de dataleverancier.

• De deliveryResponsibleParty (dataleverancier).

• Het qualityRegime (kwaliteitsregime).

2.5.6.2. Aanvullende regels

• De actuele waarde van het attribuut registrationStatus (registratiestatus) van de gegevensgroep RegistrationHistory (Registratiegeschiedenis) mag niet gelijk zijn aan 'voltooid' als dit brondocument wordt aangeboden met een registrationRequest (registratieverzoek).

• Een RealisedWell (Gerealiseerde put) met de opgegeven realisedWellId (gerealiseerde put ID) moet voor het registratieobject aanwezig zijn in de BRO.

• Een RealisedScreen (Gerealiseerd filter) met de opgegeven realisedScreenId (gerealiseerde filter ID) moet voor het registratieobject aanwezig zijn in de BRO als er een RealisedScreenChages (Veranderingen gerealiseerde filter) aanwezig is in het brondocument.

• Een RealisedScreen (Gerealiseerd filter) met de opgegeven realisedScreenId (gerealiseerde filter ID) als onderdeel van een RealisedWell (Gerealiseerde put) met de opgegeven realisedWellId (gerealiseerde put ID) moet voor het registratieobject aanwezig zijn in de BRO als er een RealisedScreenChanges (Veranderingen gerealiseerde filter) aanwezig is in het brondocument.

• De startValidity ( beginGeldigheid) van moet liggen na de startValidity ( beginGeldigheid) van het vorige voorkomen van de RealisedWell (Gerealiseerde put).

• De wellDepth (putdiepte) en de (lijst met) RealisedScreenChanges (Veranderingen gerealiseerde filter) mogen niet aanwezig zijn als de waarde van het attribuut wellDepth (putdiepte) en alle waarden van de attributen topScreenDepth (diepte bovenkant filter) in het aangeleverde brondocument dezelfde waarde hebben dan de betreffende actuele waarde. In het andere geval moeten zowel het attribuut wellDepth (putdiepte) als de complete lijst met RealisedScreenChanges (Veranderingen gerealiseerde filter) aanwezig zijn.

2.5.6.3. Af te leiden gegevens

De volgende gegevens worden afgeleid:

• RealisedWell (Gerealiseerde put) krijgt een nieuw voorkomen. De endValidity (eindGeldigheid) van het vorige voorkomen en de startValidity (beginGeldigheid) van het nieuwe voorkomen worden afgeleid van het attribuut startValidity (beginGeldigheid) in het brondocument.

• Indien ook RealisedScreens (Gerealiseerde filters) aangeleverd worden krijgen ook deze een nieuw voorkomen. De endValidity (eindGeldigheid) van het vorige voorkomen en de startValidity (beginGeldigheid) van het nieuwe voorkomen worden afgeleid van het attribuut startValidity (beginGeldigheid) in het brondocument.

• Een nieuwe gegevensgroep Event (Gebeurtenis):

  • De date (datum) van de event (gebeurtenis) wordt afgeleid van het attribuut startValidity (beginGeldigheid) in het brondocument.

  • De name (naam) van de event (gebeurtenis) is 'Maaiveldhoogte'.

  • De identifier (identificatie) van de event (gebeurtenis) wordt afgeleid van de realisedWellId (gerealiseerde put ID) in het brondocument.

2.5.7. GUF_WellFunction

Het brondocument wordt aangeboden wanneer de putfunctie van de gerealiseerde put verandert. Samen met de putfunctie kan ook relatieve temperatuur aangepast worden en kan de installatiefunctie van de gerealiseerde installatie aangepast worden. Er ontstaat een nieuw voorkomen van de Gerealiseerde put en mogelijk ook van de Gerealiseerde installatie.

De Gerealiseerde installatie wordt alleen aangeleverd indien de installatiefunctie verandert bij het veranderen van de putfunctie. Indien de installatiefunctie gelijk blijft, wordt de installatie niet aangeleverd.

De putfunctie bestaat uit een lijstje functies bestaande uit 1 of 2 functies. Het volledige lijstje wordt vervangen door het nieuwe lijstje.

De relatieve temperatuur wordt in alle gevallen opnieuw geregistreerd. Een put kan namelijk veranderen van bijvoorbeeld alleen retourneren (OBES recirculatiesysteem) naar retourneren en onttrekken (OBES WKO-systeem) of andersom. Bij alleen retourneren wordt geen relatieve temperatuur geregistreerd maar bij beide functies wel.

2.5.7.1. Inhoud

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument.

De volgende gegevens staan niet in het brondocument maar worden wel aangeleverd in het bericht:

• Het broId (BRO-ID) van het registratieobject waar dit brondocument moet worden aangevuld of gecorrigeerd.

• De deliveryAccountableParty (bronhouder) als de bronhouder een andere organisatie is dan de dataleverancier.

• De deliveryResponsibleParty (dataleverancier).

• Het qualityRegime (kwaliteitsregime).

2.5.7.2. Aanvullende regels

• De actuele waarde van het attribuut registrationStatus (registratiestatus) van de gegevensgroep RegistrationHistory (Registratiegeschiedenis) mag niet gelijk zijn aan 'voltooid' als dit brondocument wordt aangeboden met een registrationRequest (registratieverzoek).

• Een RealisedWell (Gerealiseerde put) met de opgegeven realisedWellId (gerealiseerde put ID) moet voor het registratieobject aanwezig zijn in de BRO.

• Een RealisedInstallation (Gerealiseerde installatie) met de opgegeven realisedInstallationId (gerealiseerde installatie ID) moet voor het registratieobject aanwezig zijn in de BRO als er een RealisedInstallation (Gerealiseerde installatie) aanwezig is in het brondocument.

• De RealisedWell (Gerealiseerde put) met de opgegeven realisedWellId (gerealiseerde put ID) moet in de BRO geregistreerd zijn als onderdeel van de RealisedInstallation (Gerealiseerde installatie) met de opgegeven realisedInstallationId (gerealiseerde installatie ID) als er een RealisedInstallation (Gerealiseerde installatie) aanwezig is in het brondocument.

• De startValidity ( beginGeldigheid) van moet liggen na de startValidity ( beginGeldigheid) van het vorige voorkomen van de RealisedWell (Gerealiseerde put).

• De RealisedInstallationFunction (Gerealiseerde installatiefunctie) moet aanwezig zijn in het aangeleverde brondocument als de lijst met waarden van de wellFunction (putfunctie) in het brondocument anders is dan de lijst met actuele waarden en de waarde van de installationFunction (installatiefunctie) in het brondocument anders is dan de actuele waarde. In alle andere gevallen mag de RealisedInstallationFunction (Gerealiseerde installatiefunctie) niet aanwezig zijn.

2.5.7.3. Af te leiden gegevens

De volgende gegevens worden afgeleid:

• RealisedWell (Gerealiseerde put) krijgt een nieuw voorkomen. De endValidity (eindGeldigheid) van het vorige voorkomen en de startValidity (beginGeldigheid) van het nieuwe voorkomen worden afgeleid van het attribuut startValidity (beginGeldigheid) in het brondocument.

• Indien ook de RealisedInstallation (Gerealiseerde installatie) wordt aangeleverd, krijgt ook deze een nieuw voorkomen. De endValidity (eindGeldigheid) van het vorige voorkomen en de startValidity (beginGeldigheid) van het nieuwe voorkomen worden afgeleid van het attribuut startValidity (beginGeldigheid) in het brondocument.

• Een nieuwe gegevensgroep Event (Gebeurtenis):

  • De date (datum) van de event (gebeurtenis) wordt afgeleid van het attribuut startValidity (beginGeldigheid) in het brondocument.

  • De name (naam) van de event (gebeurtenis) is 'Putfunctie'.

  • De identifier (identificatie) van de event (gebeurtenis) wordt afgeleid van de realisedWellId (gerealiseerde put ID) in het brondocument.

2.5.8. GUF_ClosureRealisedPart

Het brondocument wordt aangeboden wanneer een of meer van de gerealiseerde onderdelen (gerealiseerde installatie (met subonderdelen), gerealiseerde bodemlus, oppervlakte-infiltratie of put (met filter(s)) is afgesloten, afgedicht of buiten gebruik is gesteld. Het betreffende gerealiseerde onderdeel krijgt een einddatum.

• Bij beëindigen van een gerealiseerde put worden automatisch ook de bijbehorende filters beëindigd. Een gerealiseerd filter kan alleen worden beëindigd door de gerealiseerde put, waarvan hij onderdeel uitmaakt, te beëindigen.

• Bij beëindigen van een gerealiseerde put of oppervlakte-infiltratie is het mogelijk dat de installatiefunctie wijzigt. Daarom kan die bij dit brondocument ook worden aangepast.

Bij beëindigen van een gerealiseerde bodemlus, put of oppervlakte-infiltratie is het mogelijk dat de installatiefunctie en/of de geometrie van de bijbehorende gerealiseerde installatie wordt gewijzigd. Daarom kan die bij dit brondocument ook worden aangeleverd. De betreffende gerealiseerde installatie krijgt een nieuw voorkomen in de materiële geschiedenis.

De levensduur van de gerealiseerde installatie is een afgeleid gegeven. Het wordt afgeleid van de som van systeemonderdelen:

• De begintijd van de gerealiseerde installatie is de oudste begintijd van de som van onderdelen.

• De eindtijd van de gerealiseerde installatie is de meest recente eindtijd van de som van onderdelen indien alle onderdelen een eindtijd hebben. De installatie kan daarom niet zelfstandig worden beëindigd, maar wordt automatisch beëindigd wanneer alle onderdelen zijn beëindigd.

Zie paragraaf realisedInstallation voor details hoe de verwijzing naar de gerealiseerde installatie kan worden opgenomen in een XML-bericht.

2.5.8.1. Inhoud

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument.

De volgende gegevens staan niet in het brondocument maar worden wel aangeleverd in het bericht:

• Het broId (BRO-ID) van het registratieobject waar dit brondocument moet worden aangevuld of gecorrigeerd.

• De deliveryAccountableParty (bronhouder) als de bronhouder een andere organisatie is dan de dataleverancier.

• De deliveryResponsibleParty (dataleverancier).

• Het qualityRegime (kwaliteitsregime).

2.5.8.2. Aanvullende regels

• Het registratieobject mag niet reeds beëindigd zijn:

  • De actuele waarde van het attribuut registrationStatus (registratiestatus) van de gegevensgroep RegistrationHistory (Registratiegeschiedenis) mag niet gelijk zijn aan 'voltooid' als dit brondocument wordt aangeboden met een registrationRequest (registratieverzoek).

  • Het atribuut endTime (eindtijd) van GroundwaterUsageFacility (het Grondwatergebruiksysteem) mag niet aanwezig zijn in de BRO registratie als het brondocument wordt aangeboden in een registrationRequest (registratieverzoek).

• De te beëindigen onderdelen mogen niet reeds beëindigd zijn:

  • Het attribuut endTime (eindtijd) van de entiteit Lifespan (TijdvakLevensduur) van een te beëindigen RealisedLoop (Gerealiseerde bodemlus) mag niet aanwezig zijn in de BRO registratie als dit brondocument wordt aangeboden met een registrationRequest (registratieverzoek).

  • Het attribuut endTime (eindtijd) van de entiteit Lifespan (TijdvakLevensduur) van een te beëindigen RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) mag niet aanwezig zijn in de BRO registratie als dit brondocument wordt aangeboden met een registrationRequest (registratieverzoek).

  • Het attribuut endTime (eindtijd) van de entiteit Lifespan (TijdvakLevensduur) van een te beëindigen RealisedWell (Gerealiseerde put) mag niet aanwezig zijn in de BRO registratie als dit brondocument wordt aangeboden met een registrationRequest (registratieverzoek).

• Alle te beëindigen onderdelen moeten van hetzelfde type zijn:

  • Het brondocument mag niet een RealisedLoop (Gerealiseerde bodemlus) bevatten als het brondocument een RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) of een RealisedWell (Gerealiseerde put) bevat.

  • Het brondocument mag niet een RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) bevatten als het brondocument een RealisedLoop (Gerealiseerde bodemlus) of een RealisedWell (Gerealiseerde put) bevat.

  • Het brondocument mag niet een RealisedWell (Gerealiseerde put) bevatten als het brondocument een RealisedLoop (Gerealiseerde bodemlus) of een RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) bevat.

• Alle te beëindigen onderdelen moeten behoren tot dezelfde gerealiseerde installatie:

  • De realisedInstallationId (gerealiseerde installatie ID) van een RealisedInstallationClosurePart (Gerealiseerde installatie onderdeel beeindigd) moet gelijk zijn aan de realisedInstallationId (gerealiseerde installatie ID) van de eerste RealisedInstallationClosurePart (Gerealiseerde installatie onderdeel beeindigd) van het brondocument als het brondocument meer dan één RealisedInstallationClosurePart (Gerealiseerde installatie onderdeel beeindigd) bevat.

• De te beëindigen onderdelen moeten onderdeel uitmaken van de gerealiseerde installatie:

  • Een RealisedLoop (Gerealiseerde bodemlus) met de opgegeven realisedLoopId (gerealiseerde bodemlus ID) moet in de BRO geregistreerd zijn als onderdeel van een RealisedInstallation (Gerealiseerde installatie) met de opgegeven realisedInstallationId (gerealiseerde installatie ID) als er een RealisedInstallationClosurePart (Gerealiseerde installatie onderdeel beeindigd) en een RealisedLoop (Gerealiseerde bodemlus) aanweizg zijn in het brondocument.

  • Een RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) met de opgegeven infiltrationBasinId (gerealiseerde oppervlakteinfiltratie ID) moet in de BRO geregistreerd zijn als onderdeel van een RealisedInstallation (Gerealiseerde installatie) met de opgegeven realisedInstallationId (gerealiseerde installatie ID) als er een RealisedInstallationClosurePart (Gerealiseerde installatie onderdeel beeindigd) en een RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) aanwezig zijn in het brondocument.

  • Een RealisedWell (Gerealiseerde put) met de opgegeven realisedWellId (gerealiseerde put ID) moet in de BRO geregistreerd zijn als onderdeel van een RealisedInstallation (Gerealiseerde installatie) met de opgegeven realisedInstallationId (gerealiseerde installatie ID) als er een RealisedInstallationClosurePart (Gerealiseerde installatie onderdeel beeindigd) en een RealisedWell (Gerealiseerde put) aanwezig zijn in het brondocument.

• De endTime (eindtijd) moet liggen na de startTime (begintijd) van een te beëindigen RealisedLoop (Gerealiseerde bodemlus).

• De endTime (eindtijd) moet liggen na de startValidity (beginGeldigheid) van een te beëindigen RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie).

• De endTime (eindtijd) moet liggen na de startValidity (beginGeldigheid) van een te beëindigen RealisedWell (Gerealiseerde put).

• De installationFunction (installatiefunctie) van de RealisedInstallationClosurePart (Gerealiseerde installatie onderdeel beeindigd) mag niet aanwezig zijn bij het beëindigen van een RealisedLoop (Gerealiseerde bodemlus).

2.5.8.3. Af te leiden gegevens

De volgende gegevens worden afgeleid:

• De endValidity (eindGeldigheid) van de RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) wordt afgeleid van de endTime (eindtijd) van het betreffende feature als er een RealisedSurfaceInfiltration (Gerealiseerde oppervlakteinfiltratie) aanwezig is in het brondocument.

• De endValidity (eindGeldigheid) van de RealisedWell (Gerealiseerde put) wordt afgeleid van de endTime (eindtijd) van het betreffende feature als er een RealisedWell (Gerealiseerde put) aanwezig is in het brondocument.

• De endTime (eindtijd) en endValidity (eindGeldigheid) van het laatste voorkomen van alle bij de betreffende RealisedWell (Gerealiseerde put) horende RealisedScreens (Gerealiseerde filters) worden afgeleid van de endTime (eindtijd) van de betreffende RealisedWell (Gerealiseerde put) als er een RealisedWell (Gerealiseerde put) aanwezig is in het brondocument.

• De RealisedInstallation (Gerealiseerde installatie) krijgt een nieuw voorkomen wanneer bij dit brondocument ook gegevens van een RealisedInstallationClosurePart (Gerealiseerde installatie onderdeel beeindigd) worden aangeleverd. De endValidity (eindGeldigheid) van het vorige voorkomen en de startValidity (beginGeldigheid) van het nieuwe voorkomen worden afgeleid van de endTime (eindtijd) in het brondocument.

• De endTime (eindtijd) van het laatste voorkomen van de RealisedInstallation (Gerealiseerde installatie) wordt afgeleid van de endTime (eindtijd) in het brondocument als het laatste gerealiseerde onderdeel van de RealisedInstallation (Gerealiseerde installatie) een endTime (eindtijd) krijgt.

• Een nieuwe gegevensgroep Event (Gebeurtenis):

  • De date (datum) van de event (gebeurtenis) wordt afgeleid van het attribuut endTime (eindtijd) in het brondocument.

  • De name (naam) van de event (gebeurtenis) is 'BeeindigingGerealiseerdOnderdeel'.

  • De identifier (identificatie) van de event (gebeurtenis) blijft afwezig.

2.5.9. GUF_Closure

Het brondocument wordt aangeboden wanneer het grondwatergebruiksysteem wordt beëindigd omdat alle Rechten grondwatergebruik zijn beëindigd. Bij de beëindiging van het GUF worden daarom ook alle nog actieve Rechten grondwatergebruik beëindigd en alle gerealiseerde installaties en subonderdelen. De registratie is met dit brondocument voltooid en het registratieobject kan niet meer worden aangevuld.

We sluiten de subonderdelen ook af. Uit de eindtijd en eindgeldigheid is door de gebruiker te achterhalen welke onderdelen van het systeem nog actief waren op het moment van beëindiging.

Uitgangspunt: beëindiging Recht/GUF betekent ook beëindiging gerealiseerde onderdelen.

2.5.9.1. Inhoud

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument.

De volgende gegevens staan niet in het brondocument maar worden wel aangeleverd in het bericht:

• Het broId (BRO-ID) van het registratieobject waar dit brondocument moet worden aangevuld of gecorrigeerd.

• De deliveryAccountableParty (bronhouder) als de bronhouder een andere organisatie is dan de dataleverancier.

• De deliveryResponsibleParty (dataleverancier).

• Het qualityRegime (kwaliteitsregime).

2.5.9.2. Aanvullende regels

• Het te beëindigen registratieobject mag niet reeds beëindigd zijn:

  • De actuele waarde van het attribuut registrationStatus (registratiestatus) van de gegevensgroep RegistrationHistory (Registratiegeschiedenis) mag niet gelijk zijn aan 'voltooid' als dit brondocument wordt aangeboden met een registrationRequest (registratieverzoek).

  • Het atribuut endTime (eindtijd) van GroundwaterUsageFacility (het Grondwatergebruiksysteem) mag niet aanwezig zijn in de BRO registratie als het brondocument wordt aangeboden in een registrationRequest (registratieverzoek).

• De endTime (eindtijd) moet liggen na demeest recente datum voor startTime (begintijd) of startValidity (beginGeldigheid) of endTime (eindtijd) van alle features.

2.5.9.3. Af te leiden gegevens

De volgende gegevens worden afgeleid:

• De endValidity (eindGeldigheid) van GroundwaterUsageFacility (het Grondwatergebruiksysteem) wordt afgeleid van het attribuut endTime (eindtijd) in het brondocument .

• De endTime (eindtijd) en endValidity (eindGeldigheid), indien van toepassing, van alle features die nog geldig zijn (van zowel LicenceGroundwaterUsage (Recht grondwatergebruik) en haar ontwerponderdelen als RealisedInstallation ( Gerealiseerde installatie) en zijn gerealiseerde onderdelen), worden afgeleid van het attribuut endTime (eindtijd) in het brondocument.
  

• Een nieuwe gegevensgroep Event (Gebeurtenis):

  • De date (datum) van de event (gebeurtenis) wordt afgeleid van het attribuut endTime (eindtijd) in het brondocument.

  • De name (naam) van de event (gebeurtenis) is 'Beeindiging'.

  • De identifier (identificatie) van de event (gebeurtenis) blijft afwezig.

3. Scenario's

Onderstaand scenario is gebaseerd op de bijlage 'Voorbeeld materiële historie' in de Gegevenscatalogus.

1. GUF_StartRegistration
   Op 01-01-2021 wordt een vergunning voor grondwaterontrekking verleend met ingangsdatum 01-02-2021. In de vergunning is geen einddatum opgenomen. De grondwaterontrekking bestaat uit een installatie met 1 grondwaterontrekkingsput. In de LV BRO worden de volgende objecten opgevoerd.

2. GUF_NewLicence
   Per 01-03-2021 wordt een wijzigingsvergunning verleend waarbij de maximale putcapaciteit van de ontwerpinstallatie is verhoogd. In de BRO wordt bij het Grondwatergebruiksysteem een nieuw Recht grondwatergebruik geregistreerd, en een nieuwe ontwerpinstallatie en ontwerpput.
   

3. GUF_AddRealisedInstallation
   Per 01-06-2021 is de put gerealiseerd. In de BRO wordt een gerealiseerde installatie en gerealiseerde put opgenomen. 
   

4. GUF_NewLicence
   Per 01-09-2021 wordt een wijzigingsvergunning verleend voor het toevoegen van een extra put aan de installatie. De wijzigingsvergunning wordt toegevoegd aan het grondwatergebruikssysteem. Samen met dit nieuwe Recht Grondwatergebruik wordt een nieuwe ontwerpinstallatie en beide ontwerpputten geregistreerd in de BRO.
   

5. GUF_ExpandRealisedInstallation
   Per 01-10-2021 is de extra ontwerpput gerealiseerd en wordt de gerealiseerde put toegevoegd aan de gerealiseerde installatie in de BRO.
   

6. GUF_ClosureRealisedPart
   Per 01-01-2022 worden de gerealiseerde installatie en putten buiten werking gesteld. De vergunning blijft wel geldig. In de BRO worden de gerealiseerde installatie en putten beëindigd.
   

4. Voorbeeldberichten

4.1. Integrale XML-voorbeeldberichten

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

4.2. XML-code snippets

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

De volgende paragrafen bevatten enkele stukken XML-code die specifiek zijn voor GUF.

4.2.1. realisedInstallation

In het brondocumenttype GUF_ClosureRealisedPart kunnen meerdere gerealiseerde onderdelen worden opgenomen, waarbij deze allen een onderdeel moeten zijn van één en dezelfde gerealiseerde installatie (realisedInstallation). Het is uiteraard toegestaan om bij alle te beëindigen, gerealiseerde onderdelen de betreffende gegevens van de realisedInstallation (gerealiseerde installatie) 'uit te schrijven'.

Een beknoptere opname in een XML-bericht maakt gebruik van een xlink:href, met daarin een 'hash tag' (#-teken) gevolgd door de waarde van de gml:id, die verwijst naar een elders opgenomen uitgeschreven realisedInstallation (gerealiseerde installatie). Zie onderstaande XML-code snippet voor een voorbeeld, waar regel 26 verwijst naar de realisedInstallation (gerealiseerde installatie) in de regels 8 t/m 16.

<realisedWell>
	<RealisedWell gml:id="id_0002">
		<realisedWellId>501</realisedWellId>
		<endTime>
			<brocom:date>2022-01-01</brocom:date>
		</endTime>
		<realisedInstallation>
			<RealisedInstallationClosurePart gml:id="id_0003">
				<realisedInstallationId>401</realisedInstallationId>
				<!-- Optional: only needed if not all parts of the installation are closed and the installationFunction has changed.
				<installationFunction codeSpace="?">?</installationFunction>
				-->
				<!-- Optional: only needed if not all parts of the installation are closed and the geometry has changed.
				<geometry>...</geometry>
				-->
			</RealisedInstallationClosurePart>
		</realisedInstallation>
	</RealisedWell>
</realisedWell>
<realisedWell>
	<RealisedWell gml:id="id_0004">
		<realisedWellId>502</realisedWellId>
		<endTime>
			<brocom:date>2022-01-01</brocom:date>
		</endTime>
		<realisedInstallation xlink:href="#id_0003"/>
	</RealisedWell>
</realisedWell>

5. 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 REST-service, waarmee u de inhoud van een bepaalde codelijst kunt opvragen. Als resultaat ontvangt u dan een JSON-bericht met daarin alle waarden van de codelijst met de beschrijvingen.

6. 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.