GMN Berichtencatalogus innamewebservice

Inleiding

Dit document beschrijft hoe een bronhouder en/of dataleverancier de gegevens over een grondwatermonitoringnet (GMN) kan opnemen in een verzoek voor de Basisregistratie Ondergrond (BRO).

Het document veronderstelt dat de lezer bekend is met de GMN gegevenscatalogus en het Bronhouderportaal. Nadere informatie is te vinden op www.basisregistratieondergrond.nl.

Het document veronderstelt dat de lezer beschikt over de kennis en vaardigheid om een XML-bestand te lezen en te schrijven.

De focus van het document ligt op het beschrijven van de structuur van de mogelijke berichten aan de hand van enkele voorbeelden. Andere zaken zoals definitie, kardinaliteit, domein en bedrijfsregels met betrekking tot de gegevensinhoud van de berichten staan in de gegevenscatalogus. Vervolgstappen, zoals het valideren (testen), aanbieden en verwerken van een BRO-verzoek, staan beschreven in het Bronhouderportaal (zie www.basisregistratieondergrond.nl).

De correctieverzoeken replaceRequest, insertRequest, moveRequest en deleteRequest zijn op dit moment buiten scope.

Leeswijzer

Hoofdstuk 2 beschrijft de algemene opbouw van een BRO-verzoek.

Hoofdstuk 3 beschrijft een aantal voorbeeld scenario's, waarin met behulp van een verschillende reeksen van opeenvolgende BRO-verzoeken de tijdlijnen van diverse gegevens worden opgebouwd.

Hoofdstuk 4 bevat een toelichting op enkele voorbeeldberichten.

Hoofdstuk 5 bevat de toegestane waarden van de gebruikte enumeraties (niet-beheerde waardenlijsten).

Hoofdstuk 6 bevat verwijzingen (URL's) naar de websites met toegestane waarden van de codelijsten (beheerde waardenlijsten).

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

Versiehistorie

Contactinformatie

Algemene informatie, documentatie en voorbeeld XML-berichten kunt u vinden op www.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 .

Als u toegang heeft tot de BRO Selfservicedesk (alleen via desktop of laptop), kunt u daar inloggen en uw vraag stellen voor een extra snelle afhandeling.

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

BRO-Verzoek

Om gegevens te registreren in de Landelijke Voorziening BRO (LV BRO) moet u deze aanleveren bij het Bronhouderportaal in de vorm van een BRO-verzoek (zie basisregistratieondergrond.nl).

Vervolgens is het BRO-verzoek het bestand in IMBRO/XML-formaat dat het BRO-brondocument bevat en als verzoek wordt aangeboden in het Bronhouderportaal.

Dit hoofdstuk beschrijft de algemene opbouw van een BRO-verzoek.

Paragraaf 2.1 beschrijft het interactiepatroon voor een object met een levensloop, inclusief het opbouwen van materiële geschiedenis zoals gebruikt bij GMN en het corrigeren van onjuist geregistreerde gegevens (formele geschiedenis).

Paragraaf 2.2 geeft de definities van de verschillende requests (verzoeken) die worden ondersteund door de GMN inname webservice.

Paragraaf 2.3 beschrijft de verschillende brondocumenten die in een request (verzoek) opgenomen kunnen worden.

Object met levensloop

Het grondwatermonitoringnet is een object met een levensloop. De levensloop van een grondwatermonitoringnet heeft een begin en een eind, en loopt gelijk met de periode waarin de kwaliteit en/of de kwantiteit van het grondwater wordt gemonitord. Een grondwatermonitoringnet bestaat voor langere tijd, en tijdens zijn bestaan kunnen veranderingen optreden die geregistreerd moeten worden in de BRO. Registratie van gegevens van een grondwatermonitoringnet is dus geen eenmalige gebeurtenis, maar een proces dat zo lang duurt als het grondwatermonitoringnet bestaat. 

Een dataleverancier moet gegevens tijdig registreren. Het uitgangspunt is dat gegevens worden aangeleverd zo kort mogelijk nadat zij zijn geproduceerd. Bij objecten met een levensloop betekent tijdig ook in de juiste chronologische volgorde. Dat veronderstelt dat de processen bij de dataleverancier zo zijn ingericht dat ze aansluiten op de productie van gegevens.

Gebeurtenissen

De chronologie van het proces van registreren van gegevens over een grondwatermonitoringnet begint met het starten van de registratie, gevolgd door het aanvullen en uiteindelijk het beëindigen van de registratie.

Bij het starten van de registratie geeft de bronhouder de startDateMonitoring (begindatum monitoring) op. Deze begindatum ligt in het verleden. De BRO legt dit gegeven vast in de MonitoringNetHistory (Monitoringnetgeschiedenis). Tot het moment van beëindigen van de registratie blijft een grondwatermonitoringnet vanuit het oogpunt van de BRO actief. Ook als er gedurende enige of langere tijd geen grondwatersamenstellingsonderzoeken of grondwaterstandonderzoeken aan gekoppeld zijn of worden.

Wanneer zich gedurende de levensloop van een grondwatermonitoringnet een relevante verandering voordoet, worden de nieuwe gegevens aangeboden aan de BRO. Op dat moment wordt de registratie aangevuld. De aanvullingen moeten in chronologische volgorde worden aangeboden (oplopende waarde voor eventDate (datum gebeurtenis). De aard van de gebeurtenis, die in de werkelijkheid optreedt, kan verschillen. Voor ieder onderkend type gebeurtenis bestaat een apart type brondocument. Het verwerken van een brondocument leidt ertoe dat er een IntermediateEvent (Tussentijdse gebeurtenis) wordt vastgelegd, waarin de eventName (naam gebeurtenis), de eventDate (datum gebeurtenis) en de measuringPointCode (meetpuntcode) zijn opgenomen. Eenzelfde type gebeurtenis kan gedurende de levensloop van het grondwatermonitoringnet meerdere keren optreden. Een verzoek tot aanvullen kan dan ook zo vaak als nodig worden aangeboden. In de werkelijkheid kunnen op een bepaalde datum meerdere gebeurtenissen optreden. In de BRO moet de combinatie van eventName (naam gebeurtenis), eventDate (datum gebeurtenis) en measuringPointCode (meetpuntcode) uniek zijn. Voor een bepaalde eventDate (datum gebeurtenis) kunnen meerdere IntermediateEvents (Tussentijdse gebeurtenissen) worden vastgelegd mits deze verschillende waarden voor eventName (naam gebeurtenis) en/of measuringPointCode (meetpuntcode) hebben.

Bij het beëindigen van de registratie van gegevens over een grondwatermonitoringnet geeft de bronhouder de endDateMonitoring (einddatum monitoring) op. De BRO legt dit gegeven vast in de MonitoringNetHistory (Monitoringnetgeschiedenis). Hierna is het aanvullen van de registratie niet meer mogelijk. De gegevens van het grondwatermonitoringnet, en de onderzoeken die eraan gekoppeld zijn, blijven na die einddatum opvraagbaar voor gebruikers.

Tijdens het verwerken van een registratieverzoek voert het BRO systeem diverse controles uit. Zo wordt de inhoud van het brondocument gevalideerd tegen de gegevensdefinities in de GMN gegevenscatalogus, inclusief de regels en indien van toepassing de IMBRO/A regels. Het verwerken van een aanvulling op de registratie of de beëindiging van een registratie verloopt anders dan het starten van de registratie in de zin dat er extra controles zijn ingebouwd. Die controles zijn nodig omdat beoordeeld moet worden of de datum gebeurtenis past in de chronologische volgorde van de reeds geregistreerde gebeurtenissen en of de inhoud van het aangeboden brondocument past bij de in de BRO geregistreerde gegevens.

Materiële geschiedenis

Bij het opbouwen van materiële geschiedenis kan een onderscheid gemaakt worden in de aard van de aanvulling:

• Er worden nieuwe gegevens toegevoegd aan het in de BRO geregistreerde object.

• Er worden nieuwe waarden voor reeds in de BRO geregistreerde gegevens toegevoegd.

In het eerste geval is, naast de juiste chronologische volgorde, ook van belang dat de aangeboden gegevens nieuw zijn, dat wil zeggen hetzelfde gegeven is niet reeds aanwezig in de registratie.

In het tweede geval speelt, naast de juiste chronologische volgorde, ook een rol dat ieder tweetal van opeenvolgende waarden verschillend moet zijn.

Een nieuw gegeven, of een nieuwe waarde voor een gegeven, is geldig vanaf de datum van de gebeurtenis (datum begin geldigheid). Een eerder geregistreerde waarde blijft behouden, maar verliest op de datum van de gebeurtenis zijn geldigheid (datum einde geldigheid).

• Een gegeven zonder een datum einde geldigheid noemen we een actueel gegeven.

• Een gegeven met een datum einde geldigheid noemen we een historisch gegeven.

• De waarde van een gegeven zonder een datum einde geldigheid noemen we de actuele waarde van het gegeven.

• Een waarde van een gegeven met een datum einde geldigheid noemen we een historische waarde voor het gegeven.

Bij een grondwatermonitoringnet wordt er materiële geschiedenis opgebouwd voor:

• De lijst met meetpunten waaruit een grondwatermonitoringnet bestaat. Daarbij moet een grondwatermonitoringnet altijd bestaan uit ten minste één (actueel of historisch) meetpunt.

• De buisverwijzing van een meetpunt. Daarbij heeft een meetpunt altijd één actuele buisverwijzing. De actuele buisverwijzing van een meetpunt kan vervangen worden. Daarmee wordt de voorgaande buisverwijzing een historische buisverwijzing van dat meetpunt.

Voor de overige gegevens van een grondwatermonitoringnet wordt er geen materiële geschiedenis opgebouwd. Als bijvoorbeeld het grondwateraspect verandert van kwaliteitsmonitoring in kwantiteitsmonitoring, dan is dit aanleiding voor het beëindigen van het huidige grondwatermonitoringnet en het starten van een nieuw grondwatermonitoringnet.

Concreet houdt dit in dat er, naast gebeurtenissen voor het starten en beëindigen van de registratie, er tussentijdse gebeurtenissen worden onderkend voor:

• het toevoegen van een meetpunt.

• het vervangen van de (actuele) buisverwijzing van een meetpunt.

• het beëindigen van een meetpunt.

Stel dat er volgens onderstaande figuur 5 gebeurtenissen worden aangeboden.

Dan leidt dit tot onderstaande structuur voor een grondwatermonitoringnet.

In termen van materiële geschiedenis hebben het grondwatermonitoringnet, ieder van de meetpunten en ieder van de buisverwijzingen ieder een eigen tijdlijn. Ze ontstaan op een bepaald moment, bestaan gedurende een periode en houden mogelijkerwijs op een bepaald moment op met bestaan. Vanwege de existentiële afhankelijkheden van deze drie objecttypes zijn er bepaalde regels voor deze tijdlijnen.

• De tijdlijn van een meetpunt mag niet liggen buiten de tijdlijn van het grondwatermonitoringnet waarvan het een onderdeel is.

• De tijdlijn van een buisverwijzing mag niet liggen buiten de tijdlijn van het meetpunt waarvoor het wordt gebruikt.

• Een buis mag niet tegelijkertijd gebruikt worden in meerdere meetpunten binnen één grondwatermonitoringnet.

De eerste twee regels zijn triviaal. De derde regel wordt toegelicht in onderstaande figuur. De buisverwijzingen naar buis A1 in het tweede meetpunt zijn niet valide, omdat achtereenvolgens de periode valt binnen een andere period, de begindatum ligt binnen een andere periode en de einddatum ligt binnen een andere periode.

Aanvullende regels.

Zoals in paragraaf 2.1.1 is aangegeven, voert het BRO systeem diverse controles uit tijdens het verwerken van een registratieverzoek. De aanvullende controles bij het verwerken van het aanvullen of beëindigen van de registratie kunnen nu nader geduid worden:

• Bij het aanvullen of beëindigen van de registratie moeten de gebeurtenissen in chronologische volgorde van eventDate (datum gebeurtenis) worden aangeleverd.

• De combinatie van eventName (naam gebeurtenis), eventDate (datum gebeurtenis) en measuringPointCode (meetpuntcode) moet uniek zijn.

• Met betrekking tot elk MeasuringPoint (Meetpunt):

  • De measuringPointCode (meetpuntcode), als identificerend gegeven van een meetpunt, moet uniek zijn binnen een grondwatermonitoringnet.

  • De periode van een meetpunt moet samenvallen of liggen binnen de periode van het grondwatermonitoringnet. Met andere woorden:

    • De startDate (startdatum meetpunt) mag niet liggen voor de startDateMonitoring (begindatum monitoring).

    • De startDate (startdatum meetpunt) moet liggen voor de endDateMonitoring (einddatum monitoring).

    • De endDate (einddatum meetpunt) moet liggen na de startDate (startdatum meetpunt), als het gegeven endDate (einddatum meetpunt) aanwezig is.

    • De endDate (einddatum meetpunt) moet liggen voor de endDateMonitoring (einddatum monitoring) van de entiteit MonitoringNetHistory (Monitoringnetgeschiedenis), als beide gegevens aanwezig zijn.

• Met betrekking tot iedere GroundwaterMonitoringTube (GMW-monitoringbuis) in de keten van buisverwijzingen van een meetpunt:

  • De keten van buisverwijzingen wordt gesorteerd naar oplopende waarde voor startDate (startdatum buisverwijzing).

  • De combinatie van broId (BRO-ID), tubeNumber (buisnummer) en startDate (startdatum buisverwijzing), als identificerend gegeven van een buisverwijzing, moet uniek zijn binnen een meetpunt van een grondwatermonitoringnet.

  • De combinatie van broId (BRO-ID) en tubeNumber (buisnummer) van een buisverwijzing moet verschillen van de combinatie van broId (BRO-ID) en tubeNumber (buisnummer) van de voorafgaande buisverwijzing.

  • De startDate (startdatum buisverwijzing) van de eerste buisverwijzing van een meetpunt moet gelijk zijn aan de startDate (startdatum meetpunt) van het meetpunt.

  • Het gegeven endDate (einddatum buisverwijzing) mag niet aanwezig zijn bij de laatste (actuele) buisverwijzing in de keten van buisverwijzingen van een meetpunt.

  • Het gegeven endDate (einddatum buisverwijzing) moet aanwezig zijn als een buisverwijzing niet de laatste (actuele) buisverwijzing van een meetpunt is.

  • De endDate (einddatum buisverwijzing) moet liggen na de startDate (startdatum buisverwijzing), als het gegeven endDate (einddatum buisverwijzing) aanwezig is.

  • De startDate (startdatum buisverwijzing) van een opvolgende buisverwijzing moet gelijk zijn aan de endDate (einddatum buisverwijzing) van de voorafgaande buisverwijzing.

  • De periode van een buisverwijzing moet samenvallen of liggen binnen de periode van het meetpunt. Met andere woorden:

    • De startDate (startdatum buisverwijzing) van de buisverwijzing mag niet liggen voor de startDate (startdatum meetpunt) van het meetpunt.

    • De startDate (startdatum buisverwijzing) van de buisverwijzing moet liggen voor de endDate (einddatum meetpunt) van het meetpunt.

    • De endDate (einddatum buisverwijzing) van de buisverwijzing moet liggen na de startDate (startdatum buisverwijzing) van de buisverwijzing, als het gegeven endDate (einddatum buisverwijzing) aanwezig is.

    • De endDate (einddatum buisverwijzing) van de buisverwijzing moet liggen voor de endDate (einddatum meetpunt) van het meetpunt als beide gegevens aanwezig zijn.

  • De periode van een buisverwijzing mag niet overlappen met de periode van dezelfde buisverwijzing bij een ander meetpunt binnen hetzelfde grondwatermonitoringnet.

• De registratie kan niet meer aangevuld of beëindigd worden zodra de registratie is beëindigd (registrationStatus = voltooid).

Als een registratieverzoek (starten, aanvullen of beëindigen) wordt afgewezen, moet de reden van afwijzing zo duidelijk verwoord zijn dat de dataleverancier begrijpt wat er precies is fout gegaan.

Formele geschiedenis

Formele geschiedenis is iets anders dan materiële geschiedenis. Bij het opbouwen van materiële geschiedenis is er sprake van een verandering in de werkelijkheid. Bij formele geschiedenis gaat het om wijzigingen in (de waarde van) een gegeven zoals dat in de BRO is geregistreerd. Het corrigeren van bijvoorbeeld een onjuiste waarde door een typefout is niet een verandering in de werkelijkheid (materiële geschiedenis) maar een verandering van de geregistreerde waarde (formele geschiedenis).

Een dataleverancier kan zich op allerlei manieren vergissen bij het aanbieden van nieuwe gegevens of een nieuwe waarde. De dataleverancier kan bijvoorbeeld onjuiste gegevens aanleveren, een fout maken in de datum van een gebeurtenis of vergeten een verzoek op tijd aan te bieden. Het corrigeren van een onjuiste waarde leidt tot het opbouwen van formele geschiedenis. Zie voor nadere toelichting paragraaf 2.1.2 van de gegevenscatalogus.

Het verbeteren van onjuistheden bij een object, waarbij materiële geschiedenis wordt opgebouwd, is ingewikkelder dan bij een object waarbij dat niet het geval is. Dat komt doordat de innamewebservice van de BRO allerlei controles uitvoert om de integriteit van de tijdlijnen in de BRO te borgen. Daarom worden er vier types correctieverzoeken onderscheiden. Een verzoek om de waarde gegevens te verbeteren en drie verzoeken om de tijdlijn te verbeteren. Alle vier verzoeken worden beschreven in de volgende paragraaf. De verschillen tussen de verzoeken zijn klein. Het belangrijkste verschil is dat de dataleverancier moet aangeven wat de aard van de vergissing is.

Een correctieverzoek wordt net als een registratieverzoek via het bronhouderportaal aangeboden bij de innamewebservice. Het BRO systeem valideert de gegevens in het correctieverzoek 'op zichzelf' en in relatie tot de in de registratie aanwezige gegevens. Welke regels hierbij gecontroleerd worden verschilt per type correctieverzoek en de inhoud van (d.w.z. het brondocument in) het correctieverzoek.

Definities van de BRO-verzoeken

De GMN innamewebservice ondersteunt vijf requests (verzoeken). Zie onderstaande tabel.

De volgende paragrafen beschrijven in detail de opbouw van de diverse BRO-verzoeken.

RegistrationRequest

Met dit verzoek kan een bronhouder en/of dataleverancier nieuwe gegevens overdragen aan de BRO (registreren). Afhankelijk van het brondocument kan het gaan om:

• Het starten van de registratie, waarbij de initiële waarden van gegevens die op dat moment beschikbaar zijn worden aangeboden.

• Het aanvullen van de registratie, waarbij er materiële geschiedenis opgebouwd:

  • Door nieuwe gegevens toe te voegen.

  • Door voor bestaande gegevens een nieuwe waarde toe te voegen .

• Het beëindigen van de registratie (voltooien van de registratie). Vanaf dat moment kan de registratie niet meer worden aangevuld. Geregistreerde gegevens kunnen nog wel gecorrigeerd worden (zie paragraaf 2.2.2 t/m 2.2.5).

De gegevens worden aangeboden met één van de gedefinieerde brondocumenten. Zie paragraaf 2.3 26405905. De aangeboden gegevens worden opgenomen in de BRO registratie. Bij het aanvullen of beëindigen van de registratie moeten de gebeurtenissen in chronologische volgorde van eventDate (datum gebeurtenis) worden aangeleverd. Zie paragraaf 2.1 26405905 voor een nadere toelichting.

De inhoud van een registrationRequest (innameverzoek) wordt gedefinieerd door het type RegistrationRequest. Zie onderstaande figuur. De inhoud bestaat uit enkele transactiegegevens en een sourceDocument (brondocument). Het type SourceDocument komt aan de orde in paragraaf 2.3 26405905 .

De definities van de transactiegegevens staan in onderstaande tabel:

ReplaceRequest

Met dit verzoek kan een bronhouder en/of dataleverancier onjuiste gegevens in de BRO op een bepaald punt op de tijdlijn vervangen door de juiste gegevens. Met dit verzoek kunnen de identificerende gegevens en/of het punt op de tijdlijn niet gecorrigeerd worden.

De juiste gegevens worden aangeboden met één van de gedefinieerde brondocumenten. Zie paragraaf 26405905. Het is niet mogelijk de waarde van een individueel gegeven te corrigeren. De aangeboden gegevens vervangen de geregistreerde gegevens op het bestaande punt op de tijdlijn.

Vervangen is een correctie die op geen enkele wijze iets verandert in de tijdlijn van een registratieobject. De dataleverancier dient een vervangverzoek in wanneer er eerder een brondocument is aangeleverd met daarin de goede datum van de gebeurtenis, maar met fouten in een of meer van de andere gegevens. Alle gebeurtenissen zijn in de juiste volgorde en met de juiste datum geregistreerd. Bij het verwerken van een vervangverzoek wordt er formele geschiedenis opgebouwd. Zie voor nadere toelichting de inleiding in de gegevenscatalogus.

Onderstaande figuur geeft weer dat de (waarden van) gegevens op het punt T2 op de tijdlijn worden vervangen.

De inhoud van een replaceRequest (vervangverzoek) wordt gedefinieerd door het type CorrectionRequest. Zie onderstaande figuur. De inhoud bestaat uit enkele transactiegegevens, een correctionReason (correctie reden) en een sourceDocument (brondocument). 

De definities van de transactiegegevens staan in onderstaande tabel:

De onderstaande tabel toont de toegestane waarden voor de codelijst (beheerde waardelijst) CorrectionReason. De eerste kolom bevat de toegestane waarden, die gebruikt mogen worden in een BRO-verzoek.

InsertRequest

Met dit verzoek kan een bronhouder en/of dataleverancier de materiële geschiedenis corrigeren door het invoegen van een gebeurtenis op de tijdlijn. Het kan daarbij gaan om het invoegen van nieuwe gegevens op een bepaalde datum, of om het invoegen van nieuwe waarden voor bestaande gegevens op een bepaalde datum. In beide gevallen ligt de bepaalde datum vóór de datum waarop de actuele waarde van de gegevens geldig zijn geworden. 

Invoegen is een correctieverzoek dat ingrijpt in de materiële geschiedenis van een registratieobject. Het gaat om de eenvoudigste variant, namelijk de situatie waarin de dataleverancier vergeten was een gebeurtenis te registreren terwijl er intussen een andere gebeurtenis is geregistreerd.

Onderstaande figuur geeft weer dat nieuwe (waarden voor) gegevens worden ingevoegd op het punt T3 van de tijdlijn tussen de punten T2 en Tn.

De tussen te voegen gegevens (of waarden) worden aangeboden met één van de gedefinieerde brondocumenten. Zie paragraaf 26405905. Het is niet mogelijk de waarde van een individueel gegeven tussen te voegen.

De tussen te voegen (waarde van de) gegevens zijn geldig vanaf het moment dat in het brondocument is opgenomen tot en met het moment van de chronologisch eerstvolgende tussentijdse gebeurtenis, waarin hetzelfde feature (object) met dezelfde identificerende gegevens voorkomt. De (waarde van de) gegevens van het feature (object) met dezelfde identificerende gegevens, dat voorkomt in een chronologisch voorafgaande tussentijdse gebeurtenis, verliezen hun geldigheid vanaf het moment dat in het brondocument is opgenomen.

De inhoud van een insertRequest (invoegverzoek) wordt gedefinieerd door het type CorrectionRequest. Zie paragraaf 26405905. Aanvullende regels staan beschreven bij de brondocumenten.

MoveRequest

Met dit verzoek kan een bronhouder en/of dataleverancier onjuiste gegevens in de BRO op een bepaald punt op de tijdlijn vervangen door de juiste gegevens. Met dit verzoek kunnen de identificerende gegevens en/of het punt op de tijdlijn niet gecorrigeerd worden.

Met dit verzoek kunnen gegevens verplaatst worden op de tijdlijn, omdat de dataleverancier een gebeurtenis heeft laten registreren met een verkeerde datum.

Verplaatsen is een correctie die ingrijpt in de materiële geschiedenis van een registratieobject. Het gaat om de situatie waarin de dataleverancier de juiste gegevens heeft aangeleverd maar met de verkeerde datum. Om de fout te herstellen, levert de dataleverancier het brondocument nogmaals aan maar nu met de juiste datum erin en met het verzoek de gegevens te verplaatsen. Om aan te geven over welke gebeurtenis het precies gaat geeft hij de onjuiste datum mee in het correctieverzoek.

Onderstaande figuur geeft weer dat de begingeldigheid van de (waarden van) gegevens op het punt T2 op de tijdlijn wordt verschoven naar T2'. Merk op dat de eindgeldigheid van de (waarden van) gegevens, die op T2 gewijzigd werden, nu een eindgeldigheid T2' hebben.

Met een moveRequest (verplaatsverzoek) kan de dataleverancier de materiële geschiedenis corrigeren door een gebeurtenis te verplaatsen op de tijdlijn (wijzigen van de datum van een gebeurtenis). De te verplaatsen gegevens, inclusief de gewenste nieuwe datum van de gebeurtenis, worden aangeboden met één van de gedefinieerde brondocumenten. Zie paragraaf 26405905. De huidige, onjuiste datum van de gebeurtenis moet ook aangeboden worden, als één van de transactiegegevens van het BRO-verzoek. 

De inhoud van een moveRequest (verplaatsverzoek) wordt gedefinieerd door het type MoveRequest. Zie onderstaande figuur.

De definities van het transactiegegeven dateToBeCorrected staat in onderstaande tabel. De definities van de overige gegevens zijn al beschreven in paragraaf 26405905.

DeleteRequest

Met dit verzoek kan een bronhouder en/of dataleverancier onjuiste gegevens in de BRO op een bepaald punt op de tijdlijn vervangen door de juiste gegevens. Met dit verzoek kunnen de identificerende gegevens en/of het punt op de tijdlijn niet gecorrigeerd worden.

Met dit verzoek kunnen gegevens verwijderd worden van de tijdlijn, omdat de dataleverancier een gebeurtenis heeft laten registreren die nooit heeft plaatsgevonden.

Verwijderen is een correctie die ingrijpt in de materiële geschiedenis van een registratieobject. Het gaat om de situatie waarin de dataleverancier ten onrechte een brondocument heeft aangeleverd. Om de fout te herstellen, levert de dataleverancier het eerder aangeleverde brondocument nogmaals aan maar nu met het verzoek de gegevens die erin staan uit de registratie te verwijderen.

Onderstaande figuur geeft weer dat de (waarden voor) gegevens op het punt T3 op de tijdlijn worden verwijderd. Merk op dat dit complexe gevolgen heeft voor de begingeldigheid en de eindgeldigheid van de (waarden van) gegevens op T1 en Tn op de tijdlijn.

Met een deleteRequest (verwijderverzoek) kan de dataleverancier de materiële geschiedenis corrigeren door een gebeurtenis te verwijderen van de tijdlijn (verwijderen van gegevens op een bepaalde datum). De te verwijderen gegevens worden aangeboden met één van de gedefinieerde brondocumenten. Zie paragraaf 26405905. Het is niet mogelijk de waarde van een individueel gegeven te verwijderen.

De inhoud van een deleteRequest (verwijderverzoek) wordt gedefinieerd door het type CorrectionRequest. Zie paragraaf 26405905. Aanvullende regels staan beschreven bij de brondocumenten.

Brondocumenten

GMN is een registratieobject met materiële geschiedenis. De gegevens waarover geschiedenis wordt opgebouwd zijn:

• Het meetpunt: er kunnen in de loop van de tijd meetpunten bijkomen en meetpunten af gaan;

• De relatie naar de grondwatermonitoringbuis die aan een meetpunt is gekoppeld: in de loop van de tijd kan een meetpunt naar een andere grondwatermonitoringbuis (en put) gaan verwijzen, bijvoorbeeld als de eerst put kapot is gegaan of als een filter verstopt is geraakt.

Het registreren van de gegevens van een object is een doorlopend proces, waarvoor de volgende vijf brondocumenten beschikbaar zijn:

Onderstaande tabel geeft per brondocument weer in welke BRO-verzoeken het brondocument aangeboden mag worden.

GMN_StartRegistration

Het brondocument kan met de onderstaande BRO-verzoeken aangeboden worden voor de onderstaande gebruiksdoelen:

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

De gegevens zijn volledig gedefinieerd in de gegevenscatalogus. Het brondocument bevat alle gegevens uit de gegevenscatalogus met uitzondering van de volgende gegevens:

• Attribuut broId (BRO-ID), wordt gegenereerd door de innamewebservice als het brondocument wordt aangeboden in een registrationRequest; zit bij de transactiegegevens van het verzoek als het brondocument wordt aangeboden met de andere verzoeken.

• Entiteit RegistrationHistory (Registratiegeschiedenis), wordt afgeleid.

• Attribuut endDateMonitoring (einddatum monitoring) in entiteit MonitoringNetHistory (Monitoringnetgeschiedenis), krijgt pas een waarde als het grondwatermonitoringnet wordt afgesloten/beëindigd.

• Entiteit IntermediateEvent (Tussentijdse gebeurtenis), wordt afgeleid en toegevoegd als er aanvullende gebeurtenissen worden aangeboden.

Onderstaande tabel geeft de aanvullende regels (zie de GMN gegevenscatalogus en de GMN berichtencatalogus uitgiftewebservice):

GMN_MeasuringPoint

Het brondocument kan met de onderstaande BRO-verzoeken aangeboden worden voor de onderstaande gebruiksdoelen:

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

De eventDate (datum gebeurtenis) is de begindatum vanaf wanneer het meetpunt in gebruik is genomen. De overige gegevens zijn volledig gedefinieerd in de gegevenscatalogus.

Onderstaande tabel geeft de aanvullende regels (zie ook de GMN gegevenscatalogus en de GMN berichtencatalogus uitgiftewebservice):

GMN_TubeReference

Het brondocument kan met de onderstaande BRO-verzoeken aangeboden worden voor de onderstaande gebruiksdoelen: 

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

Toelichting bij de gegevens in het brondocument:

• De eventDate (datum gebeurtenis) is de datum waarop de huidige (actuele) buisverwijzing van het meetpunt in het brondocument wordt vervangen door de buisverwijzingen in het brondocument.

• De measuringPointCode (meetpuntcode) is de unieke identificatie van het meetpunt waarvan de buisverwijzing wordt vervangen.

• De vervangende monitoringTube (monitoringbuis) bestaat uit:

  • De broId (BRO-ID) van de grondwatermonitoringput.

  • Het tubeNumber (buisnummer) van een buis in die put.

Onderstaande tabel geeft de aanvullende regels (zie ook de GMN gegevenscatalogus en de GMN berichtencatalogus uitgiftewebservice):

Als een huidige buisverwijzing wordt vervangen door een andere buisverwijzing, dan wordt bij de betreffende monitoringbuizen in de GMW grondwatermonitoringput(ten) de waarde van het gegeven 'buis in gebruik' aangepast zoals beschreven in de bovenstaande aanvullende regels, ook als een betreffende GMW grondwatermonitoringput al is opgeruimd.

GMN_MeasuringPointEndDate

Het brondocument kan met de onderstaande BRO-verzoeken aangeboden worden voor de onderstaande gebruiksdoelen:

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

Toelichting bij de gegevens in het brondocument:

• De eventDate (datum gebeurtenis) is de datum waarop het aangeleverde meetpunt wordt beëindigd (niet meer wordt gebruikt binnen het kader van dit grondwatermonitoringnet).

• De measuringPointCode (meetpuntcode) is de unieke identificatie van het meetpunt dat wordt beëindigd.

Onderstaande tabel geeft de aanvullende regels (zie ook de GMN gegevenscatalogus en de GMN berichtencatalogus uitgiftewebservice):

Als een meetpunt in een grondwatermonitoringnet buiten gebruik wordt gesteld (het krijgt een waarde voor het gegeven einddatum meetpunt), dan wordt de op dat moment actuele buisverwijzing NIET beëindigd; er wordt op dat moment geen einddatum afgeleid voor de buisverwijzing. We hebben hier bewust voor gekozen zodat de bronhouder op een later moment makkelijk de laatste stand van zaken van het grondwatermonitoringnet kan achterhalen voordat het meetpunt buiten gebruik werd gesteld.

Wel moet bij het buiten gebruik stellen van een meetpunt voor de actuele buisverwijzing bij de betreffende monitoringbuis van de GMW grondwatermonitoringput de waarde van het gegeven 'buis in gebruik' op 'nee' worden gezet, tenzij de monitoringbuis nog in gebruik is bij een ander grondwatermonitoringnet. Dit wordt ook gedaan als de betreffende GMW grondwatermonitoringput al is opgeruimd.

GMN_Closure

Het brondocument kan met de onderstaande BRO-verzoeken aangeboden worden voor de onderstaande gebruiksdoelen:

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

Toelichting bij de gegevens in het brondocument:

• De endDateMonitoring (einddatum monitoring) is de datum waarop de registratie van het grondwatermonitoringnet wordt beëindigd.

Onderstaande tabel geeft de aanvullende regels (zie ook de GMN gegevenscatalogus en de GMN berichtencatalogus uitgiftewebservice):

Als een grondwatermonitoringnet wordt beëindigd, dan worden de op dat moment actieve meetpunten en buisverwijzingen NIET beëindigd; er wordt op dat moment geen einddatum afgeleid voor het meetpunt en de buisverwijzing. We hebben hier bewust voor gekozen zodat de bronhouder op een later moment makkelijk de laatste stand van zaken van het grondwatermonitoringnet kan achterhalen voordat het grondwatermonitoringnet werd beëindigd.

Wel moet bij het beëindigen van een grondwatermonitoringnet voor de actuele buisverwijzing van de actieve meetpunten bij de betreffende monitoringbuis van de GMW grondwatermonitoringput de waarde van het gegeven 'buis in gebruik' op 'nee' worden gezet, tenzij de monitoringbuis nog in gebruik is bij een ander grondwatermonitoringnet. Dit wordt ook gedaan als de betreffende GMW grondwatermonitoringput al is opgeruimd.

Scenario's

Dit hoofdstuk bevat enkele fictieve praktijkscenario's, aan de hand waarvan wordt utgelegd hoe en in welke volgorde welke brondocumenten in welke BRO-verzoeken gebruikt kunnen worden.

Ieder scenario begint met een beschrijving van de casus. Daarna komen de opeenvolgende gebeurtenissen aan de orde zoals die zich in de werkelijkheid zouden kunnen voordoen. Per gebeurtenis wordt aangegeven welke informatie op dat moment in de werkelijkheid beschikbaar komt (of gewijzigd wordt) en hoe deze in de vorm van een of meerdere brondocumenten middels een BRO-verzoek aangeboden kunnen worden.

Het tijdstip waarop een gebeurtenis in de werkelijk opgetreden is, wordt aangegeven met de hoofdletter T gevolgd door een cijfer of kleine letter. Bijvoorbeeld T1, T2, T3, Tn of Te.

In de beschrijving van de gebeurtenissen wordt een in de BRO geregistreerd grondwatermonitoringnet aangeduid door een broId (BRO-ID) , bijvoorbeeld GMN123456789012.

De unieke identificatie van een meetpunt (binnen een grondwatermonitoringnet) is de measuringPointCode (meetpuntcode). In de beschrijving van de gebeurtenissen wordt hiervoor een cijfer gebruikt, bijvoorbeeld 1, 2 of 3.

Een buisverwijzing bestaat uit de combinatie van de unieke waarde voor de broId (BRO-ID) van de grondwatermonitoringput en het unieke tubeNumber (buisnummer) binnen die put. In de beschrijving van de gebeurtenissen wordt hiervoor een hoofdletter en een cijfer gebruikt, bijvoorbeeld A2, B1 of C3.

Voor de complete informatie over een meetpunt en de actuele buisverwijzing gebruiken we in de beschrijving van de gebeurtenissen de combinatie van het bovenstaande, bijvoorbeeld 1-A2, 2-B1 of 3-C3

Boer rijdt put omver

Dit scenario is gebaseerd op de volgende casus.

Binnen het verzorgingsgebied van een organisatie bestaat het vermoeden van een lokale verdroging, op de onderstaande kaart afgebakend door de blauwe polygoon.

Om dit vermoeden te toetsen wordt er een monitoringnet ingericht. 

Er zijn 2 bestaande putten, die voor dit doel als meetpunt kunnen worden ingezet (1 en 2 op de onderstaande kaart). Op dit moment vindt er nog geen grondwaterstandsonderzoek plaats in deze putten.

Voor het verkrijgen van een goed inzicht zijn er 3 additionele meetpunten gewenst (3 .. 5 op onderstaande kaart).

Monitoringnet inrichten

In deze beginfase komt er veel informatie beschikbaar, c.q. moet er veel bestaande informatie verzameld worden.

1. Van de bestaande putten moeten de GMW gegevens in de BRO geraadpleegd worden. Van belang zijn onder anderen of de geometrische locatie binnen ons aandachtsgebied ligt, of de put actief en gebruiksklaar is en geschikt is voor ons doel (grondwaterstandsonderzoek) en of er een geschikte monitoringbuis is die niet in gebruik is. Uiteindelijk moeten we van de monitoringbuis, die we willen gebruiken, weten wat het buisnummer is en wat de BRO-ID is van de grondwatermonitoringput waarvan de monitoringbuis een onderdeel is.

2. Vervolgens laten we putten voor de aanvullende meetpunten slaan. We houden deze putten eenvoudig, namelijk dat ze bestaan uit één monitoringbuis die geschikt is voor ons doel. Nadat de putten zijn geslagen registreren we de inrichting van de nieuwe putten in de BRO.

3. Daarna starten we de registratie van ons onderzoek bij de BRO door de inrichting van het grondwatermonitoringnet aan te bieden. Onderdeel van de gegevens zijn de 5 meetpunten 1...5 met per meetpunt de betreffende buisverwijzing, respectievelijk A2, B3, C1, D1 en E1. We gaan ervan uit dat het grondwatermonitoringnet is ingericht op de datum T1 en dat een korte tijd later het brondocument wordt aangeboden bij en verwerkt in de BRO (het exacte tijdstip is niet relevant in dit scenario). We veronderstellen dat de LV-BRO de waarde GMN123456789012 toekent aan de broId van het nieuwe registratieobject.

4. Vervolgens kan het grondwaterstandsonderzoek gestart worden in de 5 monitoringbuizen. Dit melden we ook bij de BRO. Onderdeel van de gegevens is dat het grondwaterstandsonderzoek wordt uitgevoerd in een monitoringbuis, bijvoorbeeld buis 2 van put A, afgekort tot A2, en dat het onderzoek wordt uitgevoerd in het kader van ons grondwatermonitoringnet.

Informatie die beschikbaar komt bij de bovenstaande gebeurtenissen wordt door middel van de volgende brondocumenten gemeld bij de BRO:

1. GMW_Construction (C, 1).

2. GMW_Construction (D, 1).

3. GMW_Construction (E, 1).

4. GMN_StartRegistration (T1, 1-A2, 2-B3, 3-C1, 4-D1, 5-E1).

5. GLD_Start (A2, GMN123456789012).

6. GLD_Start (B3, GMN123456789012).

7. GLD_Start (C1, GMN123456789012).

8. GLD_Start (D1, GMN123456789012).

9. GLD_Start (E1, GMN123456789012).

De details en aanvullende berichten over de GMW grondwatermonitoringputten en de GLD grondwaterstandsonderzoeken vallen buiten de scope van dit document. Voor een nadere uitleg wordt verwezen naar de "GMW koppelvlakbeschrijving innameservice" en de "GLD berichtencatalogus innamewebservice".

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_StartRegistration (GMN-StartRegistratie) brondocument wordt verwezen naar het voorbeeldbericht 26405905 . Dit voorbeeldbericht bevat weliswaar een grondwatermonitoringnet met 2 meetpunten, maar de uitbreiding naar een bericht met 5 meetpunten is triviaal.

De inhoud van de BRO na verwerking van het GMN_StartRegistration (GMN-StartRegistratie) brondocument wordt schematisch weergeven in onderstaande figuur. Naast de identificerende gegevens van het grondwatermonitoringnet, de meetpunten en de buisverwijzingen staat de waarde voor datum begin geldigheid van de materiële historie van die gegevens; in dit geval begint de geldigheid van alle gegevens op de datum T1.

Meetpunt 4 levert geen zinvolle informatie op en is niet meer nodig

Na verloop van tijd blijkt dat de gegevens verkregen uit meetpunt 4 geen zinvolle bijdrage leveren aan het onderzoek. Het grondwaterstandsonderzoek wordt gestaakt met ingang van T2. In het grondwatermonitoringneten wordt het meetpunt buiten gebruik gesteld. Omdat voor meetpunt 4 een put was geslagen specifiek voor dit onderzoek en omdat het grondwaterstandsonderzoek in deze put niet meer plaats vindt, wordt conform de vigerende afspraken de put D opgeruimd.

Informatie die beschikbaar komt bij de bovenstaande gebeurtenis wordt door middel van de volgende brondocumenten gemeld bij de BRO:

1. GLD_End.

2. GMN_MeasuringPointEndDate (GMN123456789012, T2, 4).

3. GMW_Removal (D).

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_MeasuringPointEndDate (GMN-EinddatumMeetpunt) brondocument wordt verwezen naar het voorbeeldbericht 26405905.

Na verwerking van GMN_MeasuringPointEndDate (GMN-EinddatumMeetpunt) in de BRO ziet de geregistreerde informatie er schematisch als volgt uit. Merk op dat het meetpunt 4 de waarde T2 voor de einddatum geldigheid in de materiële geschiedenis heeft gekregen. Merk ook op dat de buisverwijzing D1 van meetpunt 4 niet een einddatum geldigheid heeft gekregen.

Extra meetpunt is nodig om beter inzicht te verkrijgen

Na verloop van tijd blijkt dat er een blinde vlek zit in de onderzoeksgegevens. We besluiten een extra meetpunt 6 in te richten. Daarvoor laten we een nieuwe grondwatermonitoringput F slaan, met daarin één monitoringbuis. Zodra de put is geslagen kan met ingang van T3 een grondwaterstandsonderzoek gestart worden in die monitoringbuis ten behoeve van ons grondwatermonitoringnet.

De volgende brondocumenten worden gebruikt om de informatie uit deze gebeurtenis te melden bij de BRO:

1. GMW_Construction (F, 1).

2. GMN_MeasuringPoint (GMN123456789012, T3, 6-F1).

3. GLD_Start (F1, GMN123456789012).

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_MeasuringPoint (GMN-Meetpunt) brondocument wordt verwezen naar het voorbeeldbericht 26405905.

Na verwerking van GMN_MeasuringPoint (GMN-Meetpunt) in de BRO ziet de geregistreerde informatie er schematisch als volgt uit. Merk op dat het meetpunt 6 en de buisverwijzing F1 een waarde T3 voor de begindatum geldigheid in de materiële geschiedenis hebben gekregen.

Boer rijdt een put omver

Terwijl we nog bezig zijn met ons grondwaterstandsonderzoek rijdt een boer, per ongeluk, de kop van grondwatermonitoringput B van meetpunt 2 omver. De monitoringbuis B3 is nu onbruikbaar. We staken het grondwaterstandsonderzoek in monitoringbuis B3. We laten vlak bij grondwatermonitoringput B een nieuwe, vervangende grondwatermonitoringput G slaan, met daarin één monitoringbuis. Daarin starten we met ingang van T4 een nieuw grondwaterstandsonderzoek. Zie onderstaande figuur.

De volgende brondocumenten worden gebruikt om de informatie uit deze gebeurtenis te melden bij de BRO:

1. GLD_End (B3).

2. GMN_TubeReference (GMN123456789012, T4, 2-G1).

3. GLD_Start (G1, GMN123456789012).

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_TubeReference (GMN-Buisverwijzing) brondocument wordt verwezen naar het voorbeeldbericht 26405905.

Na verwerking van GMN_TubeReference (GMN-Buisverwijzing) in de BRO ziet de geregistreerde informatie er schematisch als volgt uit. Merk op dat buisverwijzing B3 van meetpunt 2 de waarde T4 voor de einddatum geldigheid in de materiële geschiedenis heeft gekregen en dat buisverwijzing G1 dezelfde waarde heeft gekregen voor de begindatum geldigheid.

Monitoringnet beëindigen

Zodra we voldoende resultaten hebben bereikt in ons grondwaterstandsonderzoek kunnen we stoppen met onze activiteiten. We beëindigen met ingang van T5 het grondwatermonitoringnet, de administratieve kaders voor ons onderzoek. Volgens de vigerende afspraken ruimen we de overbodig geraakte infrastructuur op, dat wil zeggen de speciaal voor dit onderzoek geslagen putten C, E, F en G (de grondwatermonitoringput D hebben we in een voorgaande gebeurtenis al opgeruimd). Nadat de meetresultaten van de grondwaterstandsonderzoeken in de 5 overgebleven meetpunten volledig zijn beoordeeld, kunnen ook deze grondwaterstandsonderzoeken worden voltooid.

De volgende brondocumenten worden gebruikt om de informatie uit deze gebeurtenis te melden bij de BRO:

1. GMN_Closure.

2. GMW_Removal (C).

3. GMW_Removal (E).

4. GMW_Removal (F).

5. GMW_Removal (G).

6. GLD_End (A2).

7. GLD_End (G1).

8. GLD_End (C1).

9. GLD_End (E1).

10. GLD_End (F1).

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_Closure (GMN-EindeRegistratie) brondocument wordt verwezen naar het voorbeeldbericht 26405905.

Na verwerking van GMN_Closure (GMN-EindeRegistratie) in de BRO ziet de geregistreerde informatie er schematisch als volgt uit. Merk op dat alleen het monitoringnet GMN123456789012 de waarde T5 voor de einddatum geldigheid in de materiële geschiedenis heeft gekregen. Voordeel hiervan is dat als bij een eventuele correctie, waarbij het beëindigen van het grondwatermonitoringnet ongedaan gemaakt moet worden, alleen deze einddatum geldigheid van het monitoringnet gewist hoeft te worden. Als bij de verwerking van het brondocument GMN_Closure (GMN-EindeRegistratie) als een sneeuwbaleffect ook alle actuele meetpunten en alle actuele buisverwijzingen beëindigd zouden worden, dan zou het ongedaan maken van de beëindiging van het grondwatermonitoringnet veel meer voeten in de aarde hebben gehad dan nu het geval is.

Buisverwijzing vervangen door bestaande buis in eigen put

Dit scenario is een variant op het scenario 26405905.

Bij gebeurtenis 4 blijkt dat we een bestaande grondwatermonitoringput K hebben, vlak bij de omvergereden but B van meetpunt 2, met een geschikte, ongebruikte monitoringbuis 4. We nemen aan dat resultaten uit een hierin uitgevoerd grondwaterstandsonderzoek vergelijkbare resultaten zullen opleveren als uit onze verloren gegane monitoringbuis B3. De monitoringbuis K4 kan dus gebruikt worden als vervangende buisverwijzing in meetpunt 2. We staken het grondwaterstandsonderzoek in monitoringbuis B3, we gebruiken monitoringbuis K4 als vervangende buisverwijzing in meetpunt 2 en we starten een grondwaterstandsonderzoek in monitoringbuis K4 ten behoeve van ons grondwatermonitoringnet. Zie onderstaande figuur.

De volgende brondocumenten worden gebruikt om de informatie uit deze gebeurtenis te melden bij de BRO:

1. GLD_End (B3).

2. GMN_TubeReference (2-K4).

3. GLD_Start (K4, GMN123456789012).

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_TubeReference (GMN-Buisverwijzing) brondocument wordt verwezen naar het voorbeeldbericht 26405905.

Na verwerking van GMN_TubeReference (GMN-Buisverwijzing) in de BRO ziet de geregistreerde informatie er schematisch als volgt uit. Merk op dat buisverwijzing B3 van meetpunt 2 de waarde T4 voor de einddatum geldigheid in de materiële geschiedenis heeft gekregen en dat buisverwijzing K4 dezelfde waarde heeft gekregen voor de begindatum geldigheid.

Bij het voltooien van ons onderzoek (gebeurtenis 5 in het scenario 26405905) staken we het grondwaterstandsonderzoek in buis K4 (we sturen een brondocument GLD_End(K4) in plaats van GLD_End(G1)), maar we laten de bestaande put K in takt (we sturen niet een brondocument GMW_Removal(K) in plaats van GMW_Removal(G)). De volgende brondocumenten zijn nodig om de informatie bij deze gebeurtenis te melden bij de BRO:

1. GMN_Closure (GMN123456789012, T5).

2. GMW_Removal (C).

3. GMW_Removal (E).

4. GMW_Removal (F).

5. GLD_End (A2).

6. GLD_End (K4).

7. GLD_End (C1).

8. GLD_End (E1).

9. GLD_End (F1).

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_Closure (GMN-EindeRegistratie) brondocument wordt verwezen naar het voorbeeldbericht. 26405905.

Na verwerking van GMN_Closure (GMN-EindeRegistratie) in de BRO ziet de geregistreerde informatie er schematisch als volgt uit.

Buisverwijzing vervangen door bestaande buis in put van buurman

Dit scenario is een variant op het scenario 26405905.

Bij gebeurtenis 4 blijkt dat onze buurman een put X heeft, in de nabijheid van bij onze omvergereden put B van meetpunt 2, met een geschikte, ongebruikte monitoringbuis n. We nemen aan dat resultaten uit een hierin uitgevoerd grondwaterstandsonderzoek vergelijkbare resultaten zullen opleveren als uit onze verloren gegane monitoringbuis B3. De monitoringbuis Xn kan dus gebruikt worden als vervangende buisverwijzing in meetpunt 2. Zie onderstaande figuur. We vragen onze buurman of we een sensor mogen plaatsen in zijn monitoringbuis Xn. We besluiten met ingang van T4 een grondwaterstandsonderzoek te starten in monitoringbuis Xn ten behoeve van ons grondwatermonitoringnet.

De volgende brondocumenten worden gebruikt om de informatie uit deze gebeurtenis te melden bij de BRO:

1. GLD_End (B3).

2. GMN_TubeReference (GMN123456789012, T4, 2-Xn).

3. GLD_Start (Xn, GMN123456789012).

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_TubeReference (GMN-Buisverwijzing) brondocument wordt verwezen naar het voorbeeldbericht 26405905.

Na verwerking van GMN_TubeReference (GMN-Buisverwijzing) in de BRO ziet de geregistreerde informatie er schematisch als volgt uit. Merk op dat buisverwijzing B3 van meetpunt 2 de waarde T4 voor de einddatum geldigheid in de materiële geschiedenis heeft gekregen en dat buisverwijzing Xn dezelfde waarde heeft gekregen voor de begindatum geldigheid.

Bij het voltooien van ons onderzoek (gebeurtenis 5 in het scenario 26405905) staken we met ingang van T5 ons onderzoek, waaronder het grondwaterstandsonderzoek in de buis Xn van onze buurman (we sturen een brondocument GLD_End(Xn) in plaats van GLD_End(G1)). Uiteraard laten we put X van onze buurman in takt (we sturen niet een brondocument GMW_Removal(X) in plaats van GMW_Removal(G)). De volgende brondocumenten zijn nodig om de informatie bij deze gebeurtenis te melden bij de BRO:

1. GMN_Closure (GMN123456789012, T5).

2. GMW_Removal (C).

3. GMW_Removal (E).

4. GMW_Removal (F).

5. GLD_End (A2).

6. GLD_End (Xn).

7. GLD_End (C1).

8. GLD_End (E1).

9. GLD_End (F1).

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_Closure (GMN-EindeRegistratie) brondocument wordt verwezen naar het voorbeeldbericht 26405905.

Na verwerking van GMN_Closure (GMN-EindeRegistratie) in de BRO ziet de geregistreerde informatie er schematisch als volgt uit .

Meeliften met grondwaterstandsonderzoek van buurman

Dit scenario is een variant op het scenario 26405905.

Bij gebeurtenis 4 blijkt dat onze buurman een put X heeft, in de nabijheid van bij onze omvergereden but B van meetpunt 2, waarin hij al een grondwaterstandsonderzoek uitvoert in buis n. We nemen aan dat resultaten uit dit grondwaterstandsonderzoek vergelijkbare resultaten opleveren als uit onze verloren gegane monitoringbuis B3. We vragen onze buurman of we mogen meeliften met zijn grondwaterstandsonderzoek. Dan kan buis Xn met ingang van T4 gebruikt worden als vervangende buisverwijzing voor meetpunt 2. Zie onderstaande figuur.

De volgende brondocumenten worden gebruikt om de informatie uit deze gebeurtenis te melden bij de BRO:

1. GLD_End (B3).

2. GMN_TubeReference (GMN123456789012, T4, 2-Xn).

3. GLD_Monitoringnet (GMN123456789012).

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_TubeReference (GMN-Buisverwijzing) brondocument wordt verwezen naar het voorbeeldbericht 26405905.

Merk op dat wij (niet onze buurman) een GMN_TubeReference (GMN-Buisverwijzing) brondocument aanbieden bij de BRO, waarin wij de verwijzing naar een buis van een andere organisatie opnemen in ons grondwatermonitoringnet.

Merk op dat onze buurman (niet wij) een GLD_Monitoringnet brondocument aanbiedt bij de BRO, waarin hij de broId GMN123456789012 van ons grondwatermonitoringnet toevoegt als kader waarbinnen zijn (lopende) grondwaterstandsonderzoek wordt uitgevoerd.

Merk op dat wij geen resultaten uit het grondwaterstandsonderzoek (GLD) hoeven aan te bieden bij de BRO. Dat doet onze buurman al. Door middel van ons grondwatermonitoringnet met broId GMN123456789012 is duidelijk dat de resultaten van het grondwaterstandsonderzoek (GLD) uitgevoerd door onze buurman relevant zijn binnen de kaders van ons grondwatermonitoringnet (GMN).

Na verwerking van GMN_TubeReference (GMN-Buisverwijzing) in de BRO ziet de geregistreerde informatie er schematisch als volgt uit. Merk op dat buisverwijzing B3 van meetpunt 2 de waarde T4 voor de einddatum geldigheid in de materiële geschiedenis heeft gekregen en dat buisverwijzing Xn dezelfde waarde heeft gekregen voor de begindatum geldigheid.

Bij het voltooien van ons onderzoek met ingang van T5 (gebeurtenis 5 in het scenario 26405905) gaat het grondwaterstandsonderzoek in de buis Xn van onze buurman gewoon door (we sturen geen brondocument GLD_End(Xn) in plaats van GLD_End(G1)) en we laten put X van onze buurman in takt (we sturen niet een brondocument GMW_Removal(X) in plaats van GMW_Removal(G)). De volgende brondocumenten zijn nodig om de informatie bij deze gebeurtenis te melden bij de BRO:

1. GMN_Closure (GMN123456789012, T5).

2. GMW_Removal (C).

3. GMW_Removal (E).

4. GMW_Removal (F).

5. GLD_End (A2).

6. GLD_End (C1).

7. GLD_End (E1).

8. GLD_End (F1).

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_Closure (GMN-EindeRegistratie) brondocument wordt verwezen naar het voorbeeldbericht  26405905.

Na verwerking van GMN_Closure (GMN-EindeRegistratie) in de BRO ziet de geregistreerde informatie er schematisch als volgt uit.

Merk op dat vanaf T4 tot en met T5 buis Xn een buisverwijzing was binnen ons meetpunt 2. Deze periode vormt binnen de kaders van ons onderzoek de temporele afbakening van de resultaten uit het grondwaterstandsonderzoek uitgevoerd in buis Xn.

Monitoringnet eenvoudig beginnen en later uitbreiden

Dit scenario is gebaseerd op de volgende casus.

Een organisatie voert een langlopend, uitgebreid onderzoek uit. Over de afgelopen jaren zijn vele gegevens over de grondwaterstand beschikbaar, die geconverteerd moeten worden naar de BRO. Op dit moment is niet precies bekend in welke grondwatermonitoringputten het onderzoek heeft plaats gevonden. Deze informatie boven water krijgen gaat enige tijd kosten. Beschikbare informatie wil men zo spoedig mogelijk aanbieden.

De organisatie heeft gekozen voor het volgende stappenplan:

1. Verzamel de algemene gegevens over het monitoringnet en van ten minste één bekende put / meetpunt.

   1. Start de registratie van het grondwatermonitoringnet (GMN) met deze bekende putten / meetpunten en de juiste gegevens voor kader aanlevering, monitoringdoel, grondwateraspect en startdatum.

   2. Start de registratie van de grondwaterstandsonderzoeken (GLD), die zijn of worden uitgevoerd in deze bekende putten, onder verwijzing naar het grondwatermonitoringnet in het kader waarvan het onderzoek plaats vindt of heeft plaats gevonden.

   3. Voeg nieuwe standgegevens toe aan het betreffende grondwaterstandsonderzoek (GLD) als aanvullende observaties met tijdmeetwaardereeksen, zodra deze beschikbaar komen.

   4. Registreer de resultaten van de uitgevoerde grondwatersamenstellingsonderzoeken (GAR), die zijn uitgevoerd in deze bekende putten, onder verwijzing naar het grondwatermonitoringnet in het kader waarvan het onderzoek is uitgevoerd.

   5. Converteer de standgegevens van in het verleden uitgevoerde metingen van deze bekende putten. Voeg deze gegevens toe aan het betreffende grondwaterstandsonderzoek (GLD) als aanvullende observaties met tijdmeetwaardereeksen.

2. Verzamel de gegevens over de overige actuele meetpunten:

   1. Voeg die toe aan het grondwatermonitoringnet (GMN).

   2. Verzamel en converteer beschikbare standgegevens en biedt die aan als een grondwaterstandsonderzoeken (GLD).

   3. Verzamel en converteer beschikbare kwaliteitsgegevens en biedt die aan als een grondwatersamenstellingsonderzoeken (GAR).

3. Verzamel de gegevens over de historische meetpunten (welke buis/put werd van wanneer tot wanneer gebruikt in het meetpunt):

   1. Voeg die toe aan het grondwatermonitoringnet (GMN).

   2. Verzamel en converteer beschikbare standgegevens en biedt die aan als een grondwaterstandsonderzoeken (GLD).

   3. Verzamel en converteer beschikbare kwaliteitsgegevens en biedt die aan als een grondwatersamenstellingsonderzoeken (GAR).

Van deze stappen zijn alleen de stappen 1a, 2a en 3a relevant binnen de scope van deze berichtencatalogus. Deze worden in de volgende paragrafen verder toegelicht.

Monitoringnet inrichten

Uit stap 1 van het stappenplan komt naar voren dat het oudste onderzoek in dit grondwatermonitoringnet is gestart (c.q. heeft plaats gevonden) op T1. En dat dit was in monitoringbuis 2 van grondwatermonitoringput A.

Deze informatie wordt door middel van het volgende brondocument gemeld bij de BRO:

1. registrationRequest(GMN_StartRegistration (T1, 1-A2, 2-B3)).

We veronderstellen dat de LV-BRO de waarde GMN210987654321 toekent aan de broId van het nieuwe registratieobject.

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_StartRegistration (GMN-StartRegistratie) brondocument wordt verwezen naar het voorbeeldbericht 26405905.

Meetpunten toevoegen

In stap 2 van het stappenplan blijkt dat het grondwatermonitoringnet momenteel wordt uitgevoerd in in totaal 9 meetpunten. De additionele 7 meetpunten zijn op drie datums in gebruik genomen: 3 op T1, samenvallend met de oorspronkelijke inrichting van het grondwatermonitoringnet, daarna 3 op T2 en ten slotte 1 op T3. Alle meetpunten hebben een eigen monitoringbuis in 9 verschillende grondwatermonitoringputten.

In stap 3 van het stappenplan blijkt dat bij alle meetpunten nog steeds de oorspronkelijke monitoringbuis in gebruik is; er is nooit sprake geweest van een vervangen monitoringbuis bij een meetpunt. Tevens is er niet sprake van een meetpunt dat in gebruik is geweest maar inmiddel buiten gebruik is gesteld.

Zie onderstaande tabel voor het complete overzicht:

Omdat de combinatie van EventName (NaamGebeurtenis), eventDate (datum gebeurtenis) en measuringPointCode (meetpuntcode) uniek moet zijn, moet er per op een bepaalde datum in gebruik genomen put een bericht worden aangeboden. Voor zover deze niet in één keer met het GMN_StartRegistration (GMN-StartRegistratie) brondocument zijn aangeboden. In dit voorbeeld moeten we dus 7 keer een GMN_MeasuringPoint (GMN-Meetpunt) brondocument aanbieden bij de BRO:

1. GMN_MeasuringPoint (GMN210987654321, T1, 3-C1).

2. GMN_MeasuringPoint (GMN210987654321, T1, 4-D1).

3. GMN_MeasuringPoint (GMN210987654321, T1, 5-E1).

4. GMN_MeasuringPoint (GMN210987654321, T2, 6-F1).

5. GMN_MeasuringPoint (GMN210987654321, T2, 7-G1).

6. GMN_MeasuringPoint (GMN210987654321, T2, 8-H2).

7. GMN_MeasuringPoint (GMN210987654321, T3, 9-J1).

Voor een nadere uitleg over de inhoud van het GMN registrationRequest (registratieverzoek) met het GMN_MeasuringPoint (GMN-Meetpunt) brondocument wordt verwezen naar het voorbeeldbericht 26405905.

Corrigeren van algemene gegevens

Dit scenario is gebaseerd op de volgende casus.

Een bronhouder heeft een grondwatermonitoringnet met 6 meetpunten. De bronhouder heeft het aanbieden van de gegevens uitbesteed aan een dataleverancier. De dataleverancier heeft de gegevens aangeboden in 2 registratieverzoeken: een verzoek om de registratie te starten ergens in 2021 en een verzoek om de registratie aan te vullen met vier meetpunten met ingang van 15 augustus 2021.

Ondanks controle door de bronhouder voordat de verzoeken worden verwerkt in de BRO, blijkt na enige tijd dat er een paar fouten zitten in de geregistreerde gegevens:

• Het KvK-nummer van de bronhouder is fout.

• Het grondwateraspect heeft een verkeerde waarde.

• De registratie was gestart met een kwaliteitsregime IMBRO/A, maar alle gegevens blijken te voldoen aan de IMBRO eisen. Het kwaliteitsregime kan verhoogd worden.

Uitgangssituatie

We veronderstellen een uitgangssituatie die is ontstaan doordat de dataleverancier de volgende twee registrationRequests (registratieverzoeken) heeft aangeboden:

• GMN_StartRegistration (27276655, IMBRO/A, 2021, 1-A2, 2-B3).
  Zie het het voorbeeldbericht 01registrationRequestStartRegistration.xml.
  

• GMN_MeasuringPoint (GMN123456789012, IMBRO, 15-08-2021, 3-C1, 4-D1, 5-E1, 6-F1).
  Zie het het voorbeeldbericht 02registrationRequestMeasuringPoint.xml.

Na verwerking van deze twee verzoeken zien de gegistreerde gegevens er als volgt uit:

Corrigeren van de bronhouder

De dataleverancier kan het deliveryAccountableParty (bronhouder) aanpassen door een replaceRequest (vervangverzoek) aan te bieden, met daarin een GMN_StartRegistrationRequest, geen lijst met meetpunten, de juiste waarde voor het transactiegegeven deliveryAccountableParty (bronhouder) en de waarde 'bronhouder' voor het transactiegegeven correctionReason (correctie reden):

• GMN_StartRegistration (GMN123456789012, 55667372, IMBRO/A, bronhouder, 2021)

Zie het voorbeeldbericht 26405905

Corrigeren van het grondwateraspect

De dataleverancier kan de administratieve gegevens, waaronder het groundwaterAspect (grondwateraspect), aanpassen door een replaceRequest (vervangverzoek) aan te bieden, met daarin een GMN_StartRegistrationRequest met de juiste administratieve gegevens en geen lijst met meetpunten. Het transactiegegeven correctionReason (correctie reden) heeft de waarde 'inOnderzoek' als de correctie plaats vindt naar aanleiding van een terugmelding, waarbij het registratieobject in onderzoek is geplaatst, en anders de waarde 'eigenCorrectie'.

• GMN_StartRegistration (GMN123456789012, IMBRO/A, eigenCorrectie, kwaliteit, 2021)

Zie het voorbeeldbericht 26405905

Corrigeren van het kwaliteitsregime.

De dataleverancier kan het qualityRegime (kwaliteitsregime) aanpassen door een replaceRequest (vervangverzoek) aan te bieden, met daarin een GMN_StartRegistrationRequest, geen lijst met meetpunten, de juiste waarde voor het transactiegegeven qualityRegime (kwaliteitsregime) en de waarde 'kwaliteitsregime' voor het transactiegegeven correctionReason (correctie reden):

• GMN_StartRegistration (GMN123456789012, IMBRO, kwaliteitsregime, 21-03-2021)

Zie het voorbeeldbericht 26405905

Corrigeren van begindatum monitoring

Dit scenario is gebaseerd op de volgende casus.

Een bronhouder heeft een grondwatermonitoringnet met 6 meetpunten. De gegevens zijn aangeboden in 2 registratieverzoeken: een verzoek om de registratie te starten ergens in 2021 en een verzoek om de registratie aan te vullen met vier meetpunten met ingang van 15 augustus 2021.

Na enige tijd blijkt

• Dat de aanvankelijk onzekere begindatum van het onderzoek (ergens in 2021) is nu wel bekend, namelijk 21 maart 2021.

• Het onderzoek in een van de twee meetpunten met een oorspronkelijke startdatum ergens in 2021 blijkt niet op 21 maart 2021 gestart te zijn, maar op 15 augustus 2021.

• Het onderzoek in een van de vier meetpunten met een oorspronkelijke startdatum 15 augustus 2021 blijkt niet op die datum gestart te zijn, maar op 21 maart 2021.

• Nu alle gegevens voldoen aan de IMBRO eisen is het gebruik van IMBRO/A niet langer noodzakelijk. Het kwaliteitsregime kan verhooogd worden.

Uitgangssituatie

We veronderstellen een uitgangssituatie die is ontstaan doordat de dataleverancier de volgende twee registrationRequests (registratieverzoeken) heeft aangeboden:

• GMN_StartRegistration (IMBRO/A, 2021, 1-A2, 2-B3).
  Zie het het voorbeeldbericht 01registrationRequestStartRegistration.xml.
  

• GMN_MeasuringPoint (GMN123456789012, IMBRO, 15-08-2021, 3-C1, 4-D1, 5-E1, 6-F1).
  Zie het het voorbeeldbericht 02registrationRequestMeasuringPoint.xml.

Na verwerking van deze twee verzoeken zien de gegistreerde gegevens er als volgt uit:

Corrigeren van de begindatum monitoring

De dataleverancier kan de startDateMonitoring (begindatum monitoring) aanpassen door een moveRequest (verplaatsverzoek) aan te bieden, met daarin een GMN_StartRegistrationRequest, met daarin en lijst met meetpunten waarvan de begindatum monitoring moet mee verhuizen. Het transactiegegeven correctionReason (correctie reden) heeft de waarde 'inOnderzoek' als de correctie wordt gedaan in de context van een onderzoek naar aanleiding van een terugmelding en de waarde 'eigenCorrectie' in alle andere gevallen. 

• GMN_StartRegistration (GMN123456789012, IMBRO, inOnderzoek, 21-03-2021, 2021, 1-A2, 2-B3).

Zie het voorbeeldbericht 14moveRequestStartRegistration.xml. Na verwerking van dit verzoek zien de geregistreerde gegevens er als volgt uit:

Corrigeren van de startdatum meetpunt

Blabla

Voorbeeldberichten

Dit hoofdstuk bevat enkele voorbeeldberichten met regel voor regel een toelichting. Enkele voorbeeld testberichten zijn te vinden via GMN inname voorbeeldberichten

Paragraaf 4.1 bevat enkele voorbeeldberichten voor het registreren van nieuwe gegevens (starten, aanvullen en beëindigen).

Paragraaf 4.2 bevat enkele voorbeeldberichten voor het corrigeren van bestaande gegevens (vervangen, verplaatsen, invoegen, verwijderen).

Gegevens registreren

01registrationRequestStartRegistration

Het voorbeeldbericht 01registrationRequestStartRegistration.xml bevat een registratieverzoek, waarmee de registratie van een nieuw registratieobject in de BRO wordt gestart.

Onderstaande figuur toont op hoofdlijnen de structuur van het registratieverzoek en het brondocument. 

Dan volgt hier regel voor regel een beschrijving van het voorbeeldbericht. Zie de onderstaande tabellen met regelnummers en XML-code van de regel.

De eerste regel van het voorbeeldbericht bevat de XML-proloog. Merk op dat de tekens volgens UTF-8 gecodeerd moeten worden. Dit is met name van belang voor speciale tekens, zoals à, á, ï.

Regel 2 t/m 7 bevatten de opening tag van het registrationRequest (registratieverzoek) als root XML-element en de namespaces van de gebruikte XML-schemadefinities (XSD's).

Regel 12 t/m 21 bevatten de transactiegegevens.

Regel 12 bevat de requestReference (verzoekkenmerk), een voor de dataleverancier unieke aanduiding van het BRO-verzoek.

Regel 14 bevat het optionele element deliveryAccountableParty (bronhouder). De waarde is het KvK-nummer van de bronhouder. Dit element is opgenomen in het voorbeeldbericht, omdat in dit voorbeeld de dataleverancier niet de bronhouder is.

Regel 18 bevat het qualityRegime (kwaliteitsregime) als aanduiding van de kwaliteitseis waaraan de gegevens in het brondocument voldoen . De waarde IMBRO/A is nodig, omdat de waarde van startDateMonitoring (begindatum monitoring) niet een volledige datum is.

<registrationRequest 
      xmlns="http://www.broservices.nl/xsd/isgmn/1.0"
      xmlns:brocom="http://www.broservices.nl/xsd/brocommon/3.0"
      xmlns:gml="http://www.opengis.net/gml/3.2"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.broservices.nl/xsd/isgmn/1.0 ../../XSD/isgmn-messages.xsd"
      >
  <!-- Disclaimer: dit voorbeeldbericht valideert tegen de XSD van de innameservice.
       Het is niet gevalideert door de innamewebservice en is vaktechnisch/inhoudelijk niet voorbeeldig.
  -->
  <brocom:requestReference>Groningen_01</brocom:requestReference>
  <!--Optional: dataleverancier is niet de bronhouder, dus is het gegeven aanwezig. -->
  <brocom:deliveryAccountableParty>27376655</brocom:deliveryAccountableParty>
  <!--Optional: brondocument is GMN_StartRegistration, dus mag het gegeven niet aanwezig zijn.
  <brocom:broId>GMN123456789012</brocom:broId>
  -->
  <brocom:qualityRegime>IMBRO</brocom:qualityRegime>
  <!--Optional: niet toegestaan bij GMN.
  <brocom:underPrivilege>ja</brocom:underPrivilege>
  -->

Regel 22 bevat de opening tag van het sourceDocument (brondocument).

Regel 23 geeft aan dat GMN_StartRegistration het type is van het brondocument. Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 24 is het eerste gegeven binnen dit brondocument, de objectIdAccountableParty (object-ID bronhouder).

Regel 25 bevat de binnen het werkveld herkenbare naam voor het grondwatermonitoringnet.

Regel 26 bevat de deliveryContext (kader aanlevering). Het XML-attribuut codeSpace bevat de unieke aanduiding van de gebruikte codelijst (urn:bro:gmn:DeliveryContext) . De waarde 'kaderrichtlijnWater' van het XML-element is één van de toegestane waarden uit die codelijst (zie de catalogus).

Regel 27 en 28 bevatten ook elementen met een waarde uit een codelijst.

Regel 29 t/m 38 bevat de startDateMonitoring (begindatum monitoring). In het voorbeeldbericht heeft dit de waarde 2021 (het jaar 2021). Volgens de catalogus kan er naast een jaartal ook sprake zijn van 3 andere varianten. Regel 32 t/m 35 bevatten als commentaar alle 4 varianten voor 1 maart 2021 met een afnemende nauwkeurigheid.

  <sourceDocument>
    <GMN_StartRegistration gml:id="id_0001">
        <objectIdAccountableParty>meetnet_07</objectIdAccountableParty>
        <name>Provinciaal meetnet grondwater Groningen; Delfzijl</name>
        <deliveryContext codeSpace="urn:bro:gmn:DeliveryContext">kaderrichtlijnWater</deliveryContext>
        <monitoringPurpose codeSpace="urn:bro:gmn:MonitoringPurpose">strategischBeheerKwaliteitRegionaal</monitoringPurpose>
        <groundwaterAspect codeSpace="urn:bro:gmn:GroundwaterAspect">kwantiteit</groundwaterAspect>
        <startDateMonitoring>
          <!--You have a CHOICE of the next 4 items at this level-->
          <!-- 
          <brocom:date>2021-03-01</brocom:date>
          <brocom:yearMonth>2021-03</brocom:yearMonth>
          <brocom:year>2021</brocom:year>
          <brocom:voidReason>onbekend</brocom:voidReason>
           -->
          <brocom:date>2021-03-01</brocom:date>
        </startDateMonitoring>

Vanaf regel 39 volgen één of meer voorkomens van een measuringPoint (meetpunt) waaruit het grondwatermonitoringnet bestaat. Het voorbeeldbericht bevat er 2, maar dat hadden er ook meer of minder kunnen zijn.

Regel 41 geeft aan dat MeasuringPoint (Meetpunt) het type is van het element measuringPoint (meetpunt). Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 42 bevat de measuringPointCode (meetpuntcode) van het meetpunt.

Regel 43 bevat de opening tag van de monitoringTube (monitoringbuis).

Regel 44 geeft aan dat GroundwaterMonitoringTube (GMW-monitoringbuis) het type is van het element monitoringTube (monitoringbuis). Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Elke monitoringbuis wordt geïdentificeerd door de combinatie van broId (BRO-id) en tubeNumber (buisnummer).

Regel 45 bevat de broID (BRO-id) van het monitoringbuis.

Regel 46 bevat de tubeNumber (buisnummer) van het monitoringbuis.

Regel 47 bevat de closing tag van de GroundwaterMonitoringTube (GMW-monitoringbuis) als type van de monitoringTube (monitoringbuis).

Regel 48 bevat de closing tag van de monitoringTube (monitoringbuis).

Regel 49 bevat de closing tag van de MeasuringPoint (Meetpunt) als type van het measuringPoint (meetpunt).

Regel 50 bevat de closing tag van de measuringPoint (meetpunt).

Regel 51 t/m 61 bevatten een tweede measuringPoint (meetpunt). 

        <!-- 1 or more repetitions: -->
        <measuringPoint>
          <MeasuringPoint gml:id="id_0002">
            <measuringPointCode>GMW07F000001</measuringPointCode>
            <monitoringTube>
              <GroundwaterMonitoringTube gml:id="id_0003">
                <broId>GMW123456789001</broId>
                <tubeNumber>2</tubeNumber>
              </GroundwaterMonitoringTube>
            </monitoringTube>
          </MeasuringPoint>
        </measuringPoint>
        <measuringPoint>
          <MeasuringPoint gml:id="id_0004">
            <measuringPointCode>GMW07F000002</measuringPointCode>
            <monitoringTube>
              <GroundwaterMonitoringTube gml:id="id_0005">
                <broId>GMW123456789002</broId>
                <tubeNumber>3</tubeNumber>
              </GroundwaterMonitoringTube>
            </monitoringTube>
          </MeasuringPoint>
        </measuringPoint>

Regel 62 bevat de closing tag GMN_StartRegistration als type van het sourceDocument (brondocument).

Regel 63 bevat de closing tag van het sourceDocument (brondocument).

Regel 64 bevat de closing tag van het registrationRequest (registratieverzoek).

    </GMN_StartRegistration>
  </sourceDocument>
</registrationRequest>

02registrationRequestMeasuringPoint

Het voorbeeldbericht 02registrationRequestMeasuringPoint.xml bevat een registratieverzoek, waarmee een meetpunt wordt toegevoegd aan een registratieobject dat al is opgenomen in de BRO. Het meetpunt speelt vanaf de eventDate (datum gebeurtenis) in het brondocument een rol binnen het meetnet. Het voorbeeldbericht borduurt voort op het voorbeeldbericht 01registrationRequestStartRegistration.xml.

NB 1: De combinatie van EventName (NaamGebeurtenis), eventDate (datum gebeurtenis) en measuringPointCode (meetpuntcode) moet uniek zijn binnen een registratieobject. Dit heeft tot gevolg er per meetpunt een GMN_MeasuringPoint (GMN-Meetpunt) brondocument in een registrationRequest (registratieverzoek) aangeboden moeten worden.

Onderstaande figuur toont op hoofdlijnen de structuur van het registratieverzoek en het brondocument. 

Dan volgt hier regel voor regel een beschrijving van het voorbeeldbericht. Zie de onderstaande tabellen met regelnummers en XML-code van de regel.

De eerste regel van het voorbeeldbericht bevat de XML-proloog. Merk op dat de tekens volgens UTF-8 gecodeerd moeten worden. Dit is met name van belang voor speciale tekens, zoals à, á, ï.

Regel 2 t/m 8 bevatten de opening tag van het registrationRequest (registratieverzoek) als root XML-element en de namespaces van de gebruikte XML-schemadefinities (XSD's).

Regel 13 t/m 21 bevatten de transactiegegevens.

Regel 13 bevat de requestReference (verzoekkenmerk), een voor de dataleverancier unieke aanduiding van het BRO-verzoek.

Regel 15 bevat het optionele element deliveryAccountableParty (bronhouder). De waarde is het KvK-nummer van de bronhouder. Dit element is opgenomen in het voorbeeldbericht, omdat in dit voorbeeld de dataleverancier niet de bronhouder is.

Regel 17 bevat de broId (BRO-id) als unieke identificatie van het registratieobject dat aangevuld moet worden met de gegevens in het brondocument van dit registratieverzoek .

Regel 18 bevat het qualityRegime (kwaliteitsregime) als aanduiding van de kwaliteitseis waaraan de gegevens in het brondocument voldoen .

<registrationRequest 
      xmlns="http://www.broservices.nl/xsd/isgmn/1.0"
      xmlns:brocom="http://www.broservices.nl/xsd/brocommon/3.0"
      xmlns:gml="http://www.opengis.net/gml/3.2"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.broservices.nl/xsd/isgmn/1.0 ../../XSD/isgmn-messages.xsd"
      >

  <!-- Disclaimer: dit voorbeeldbericht valideert tegen de XSD van de innamewebservice.
       Het is niet gevalideert door de innamewebservice en is vaktechnisch/inhoudelijk niet voorbeeldig.
  -->
  <brocom:requestReference>Groningen_02</brocom:requestReference>
  <!--Optional: dataleverancier is niet de bronhouder, dus is het gegeven aanwezig. -->
  <brocom:deliveryAccountableParty>27376655</brocom:deliveryAccountableParty>
  <!--Optional: brondocument is GMN_AddMeasuringPoint, dus moet het gegeven aanwezig zijn. -->
  <brocom:broId>GMN123456789012</brocom:broId>
  <brocom:qualityRegime>IMBRO</brocom:qualityRegime>
  <!--Optional: niet toegestaan bij GMN.
  <brocom:underPrivilege>ja</brocom:underPrivilege>
  -->

Regel 22 bevat de opening tag van het sourceDocument (brondocument).

Regel 23 geeft aan dat GMN_MeasuringPoint het type is van het brondocument. Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 24 t/m 33 bevat de eventDate (datum gebeurtenis) waarop de gegevens in de werkelijkheid hun geldigheid hebben gekregen. In het voorbeeldbericht heeft dit de waarde 2021-08-15 (15 augustus 2021). Volgens de catalogus kan er naast een volledige datum (jaar, maand, dag) ook sprake zijn van 3 minder nauwkeurige varianten. Regel 27 t/m 30 bevatten als commentaar alle 4 varianten voor 15 augustus 2021 met een afnemende nauwkeurigheid.

  <sourceDocument>
    <GMN_MeasuringPoint gml:id="id_0001">
        <eventDate>
          <!--You have a CHOICE of the next 4 items at this level-->
          <!-- 
          <brocom:date>2021-08-15</brocom:date>
          <brocom:yearMonth>2021-08</brocom:yearMonth>
          <brocom:year>2021</brocom:year>
          <brocom:voidReason>onbekend</brocom:voidReason>
           -->
          <brocom:date>2021-08-15</brocom:date>
        </eventDate>

Regel 34 t/m 44 bevat het measuringPoint (meetpunt), waaruit het grondwatermonitoringnet bestaat.

Regel 35 geeft aan dat MeasuringPoint (Meetpunt) het type is van het element measuringPoint (meetpunt). Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 36 bevat de measuringPointCode (meetpuntcode) van het meetpunt.

Regel 37 bevat de opening tag van de monitoringTube (monitoringbuis).

Regel 38 geeft aan dat GroundwaterMonitoringTube (GMW-monitoringbuis) het type is van het element monitoringTube (monitoringbuis). Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Elke monitoringbuis wordt geïdentificeerd door de combinatie van broId (BRO-id) en tubeNumber (buisnummer).

Regel 39 bevat de broID (BRO-id) van het monitoringbuis.

Regel 40 bevat de tubeNumber (buisnummer) van het monitoringbuis.

Regel 41 bevat de closing tag van de GroundwaterMonitoringTube (GMW-monitoringbuis) als type van de monitoringTube (monitoringbuis).

Regel 42 bevat de closing tag van de monitoringTube (monitoringbuis).

Regel 43 bevat de closing tag van de MeasuringPoint (Meetpunt) als type van het measuringPoint (meetpunt).

Regel 44 bevat de closing tag van de measuringPoint (meetpunt).

        <measuringPoint>
          <MeasuringPoint gml:id="id_0002">
            <measuringPointCode>GMW07E000001</measuringPointCode>
            <monitoringTube>
              <GroundwaterMonitoringTube gml:id="id_0003">
                <broId>GMW123456789003</broId>
                <tubeNumber>1</tubeNumber>
              </GroundwaterMonitoringTube>
            </monitoringTube>
          </MeasuringPoint>
        </measuringPoint>

Regel 45 bevat de closing tag GMN_StartRegistration als type van het sourceDocument (brondocument).

Regel 46 bevat de closing tag van het sourceDocument (brondocument).

Regel 47 bevat de closing tag van het registrationRequest (registratieverzoek).

    </GMN_MeasuringPoint>
  </sourceDocument>
</registrationRequest>

03registrationRequestTubeReference

Het voorbeeldbericht 03registrationRequestTubeReference.xml bevat een registratieverzoek, waarmee van een meetpunt de actuele buisverwijzing wordt vervangen door een andere buisverwijzing. De vervangende buisverwijzingen vormt vanaf de eventDate (datum gebeurtenis) in het brondocument de monitoringbuis waarin een (de) gerelateerd(e) grondwaterstandonderzoek(en) en/of grondwatersamenstellingsonderzoek(en) uitgevoerd worden. Het voorbeeldbericht borduurt voort op de voorbeeldberichten 01registrationRequestStartRegistration.xml en 02registrationRequestMeasuringPoint.xml.

NB 1: De combinatie van EventName (NaamGebeurtenis), eventDate (datum gebeurtenis) en measuringPointCode (meetpuntcode) moet uniek zijn binnen een registratieobject. Dit heeft tot gevolg er per veranderende buisverwijzingen een GMN_TubeReference (GMN-Buisverwijzing) brondocument in een registrationRequest (registratieverzoek) aangeboden moeten worden.

Onderstaande figuur toont op hoofdlijnen de structuur van het registratieverzoek en het brondocument. 

Dan volgt hier regel voor regel een beschrijving van het voorbeeldbericht. Zie de onderstaande tabellen met regelnummers en XML-code van de regel.

De eerste regel van het voorbeeldbericht bevat de XML-proloog. Merk op dat de tekens volgens UTF-8 gecodeerd moeten worden. Dit is met name van belang voor speciale tekens, zoals à, á, ï.

Regel 2 t/m 8 bevatten de opening tag van het registrationRequest (registratieverzoek) als root XML-element en de namespaces van de gebruikte XML-schemadefinities (XSD's).

Regel 13 t/m 21 bevatten de transactiegegevens.

Regel 13 bevat de requestReference (verzoekkenmerk), een voor de dataleverancier unieke aanduiding van het BRO-verzoek.

Regel 15 bevat het optionele element deliveryAccountableParty (bronhouder). De waarde is het KvK-nummer van de bronhouder. Dit element is opgenomen in het voorbeeldbericht, omdat in dit voorbeeld de dataleverancier niet de bronhouder is.

Regel 17 bevat de broId (BRO-id) als unieke identificatie van het registratieobject waarvoor bij een meetpunt de actuele buisverwijzing vervangen moet worden.

Regel 18 bevat het qualityRegime (kwaliteitsregime) als aanduiding van de kwaliteitseis waaraan de gegevens in het brondocument voldoen.

<registrationRequest 
      xmlns="http://www.broservices.nl/xsd/isgmn/1.0"
      xmlns:brocom="http://www.broservices.nl/xsd/brocommon/3.0"
      xmlns:gml="http://www.opengis.net/gml/3.2"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.broservices.nl/xsd/isgmn/1.0 ../../XSD/isgmn-messages.xsd"
      >

  <!-- Disclaimer: dit voorbeeldbericht valideert tegen de XSD van de innamewebservice.
       Het is niet gevalideert door de innamewebservice en is vaktechnisch/inhoudelijk niet voorbeeldig.
  -->
  <brocom:requestReference>Groningen_03</brocom:requestReference>
  <!--Optional: dataleverancier is niet de bronhouder, dus is het gegeven aanwezig. -->
  <brocom:deliveryAccountableParty>27376655</brocom:deliveryAccountableParty>
  <!--Optional: brondocument is GMN_AddMeasuringPoint, dus moet het gegeven aanwezig zijn. -->
  <brocom:broId>GMN123456789012</brocom:broId>
  <brocom:qualityRegime>IMBRO</brocom:qualityRegime>
  <!--Optional: niet toegestaan bij GMN.
  <brocom:underPrivilege>ja</brocom:underPrivilege>
  -->

Regel 22 bevat de opening tag van het sourceDocument (brondocument).

Regel 23 geeft aan dat GMN_TubeReference het type is van het brondocument. Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 24 t/m 33 bevat de eventDate (datum gebeurtenis) waarop de gegevens in de werkelijkheid hun geldigheid hebben gekregen. In het voorbeeldbericht heeft dit de waarde 2021-11-27 (27 november 2021). Volgens de catalogus kan er naast een volledige datum (jaar, maand, dag) ook sprake zijn van 3 minder nauwkeurige varianten. Regel 27 t/m 30 bevatten als commentaar alle 4 varianten voor 27 november 2021 met een afnemende nauwkeurigheid.

  <sourceDocument>
    <GMN_TubeReference gml:id="id_0001">
        <eventDate>
          <!--You have a CHOICE of the next 4 items at this level-->
          <!-- 
          <brocom:date>2021-11-27</brocom:date>
          <brocom:yearMonth>2021-11</brocom:yearMonth>
          <brocom:year>2021</brocom:year>
          <brocom:voidReason>onbekend</brocom:voidReason>
           -->
          <brocom:date>2021-11-27</brocom:date>
        </eventDate>

Regel 34 t/m 44 bevat het measuringPoint (meetpunt) waarvan de actuele buisverwijzing moet worden vervangen door de gegevens in het brondocument.

Regel 35 geeft aan dat MeasuringPoint (Meetpunt) het type is van het element measuringPoint (meetpunt). Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 36 bevat de measuringPointCode (meetpuntcode) van het meetpunt waarvan de actuele buisverwijzing moet worden vervangen.

Regel 37 bevat de opening tag van de monitoringTube (monitoringbuis).

Regel 38 geeft aan dat GroundwaterMonitoringTube (GMW-monitoringbuis) het type is van het element monitoringTube (monitoringbuis). Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 39 en 40 bevatten de broID (BRO-id) en de tubeNumber (buisnummer) als unieke identificatie van de monitoringbuis die de huidige actuele buisverwijzing moet vervangen.

Regel 41 bevat de closing tag van de GroundwaterMonitoringTube (GMW-monitoringbuis) als type van de monitoringTube (monitoringbuis).

Regel 42 bevat de closing tag van de monitoringTube (monitoringbuis).

Regel 43 bevat de closing tag van de MeasuringPoint (Meetpunt) als type van het measuringPoint (meetpunt).

Regel 44 bevat de closing tag van de measuringPoint (meetpunt) van het meetpunt.

        <measuringPoint>
          <MeasuringPoint gml:id="id_0002">
            <measuringPointCode>GMW07F000002</measuringPointCode>
            <monitoringTube>
              <GroundwaterMonitoringTube gml:id="id_0003">
                <broId>GMW123456789007</broId>
                <tubeNumber>1</tubeNumber>
              </GroundwaterMonitoringTube>
            </monitoringTube>
          </MeasuringPoint>
        </measuringPoint>

Regel 45 bevat de closing tag GMN_TubeReference als type van het sourceDocument (brondocument).

Regel 46 bevat de closing tag van het sourceDocument (brondocument).

Regel 47 bevat de closing tag van het registrationRequest (registratieverzoek).

    </GMN_TubeReference>
  </sourceDocument>
</registrationRequest>

04registrationRequestMeasuringPointEndDate

Het voorbeeldbericht 04registrationRequestMeasuringPointEndDate.xml bevat een registratieverzoek, waarmee een meetpunt wordt beëindigd (buiten gebruik gesteld). Het meetpunten wordt vanaf de eventDate (datum gebeurtenis) in het brondocument niet meer gebruikt binnen de context van dit grondwatermonitoringnet. Het voorbeeldbericht borduurt voort op de voorbeeldberichten 01registrationRequestStartRegistration.xml en 02registrationRequestMeasuringPoint.xml.

NB 1: De combinatie van EventName (NaamGebeurtenis), eventDate (datum gebeurtenis) en measuringPointCode (meetpuntcode) moet uniek zijn binnen een registratieobject. Dit heeft tot gevolg dat per buiten gebruik gesteld meetpunt een GMN_MeasuringPointEndDate (GMN-EinddatumMeetpunt) brondocument in een registrationRequest (registratieverzoek) aangeboden moeten worden.

Onderstaande figuur toont op hoofdlijnen de structuur van het registratieverzoek en het brondocument. 

Dan volgt hier regel voor regel een beschrijving van het voorbeeldbericht. Zie de onderstaande tabellen met regelnummers en XML-code van de regel.

De eerste regel van het voorbeeldbericht bevat de XML-proloog. Merk op dat de tekens volgens UTF-8 gecodeerd moeten worden. Dit is met name van belang voor speciale tekens, zoals à, á, ï.

Regel 2 t/m 8 bevatten de opening tag van het registrationRequest (registratieverzoek) als root XML-element en de namespaces van de gebruikte XML-schemadefinities (XSD's).

Regel 13 t/m 21 bevatten de transactiegegevens.

Regel 13 bevat de requestReference (verzoekkenmerk), een voor de dataleverancier unieke aanduiding van het BRO-verzoek.

Regel 15 bevat het optionele element deliveryAccountableParty (bronhouder). De waarde is het KvK-nummer van de bronhouder. Dit element is opgenomen in het voorbeeldbericht, omdat in dit voorbeeld de dataleverancier niet de bronhouder is.

Regel 17 bevat de broId (BRO-id) als unieke identificatie van het registratieobject dat aangevuld moet worden met de gegevens in het brondocument van dit registratieverzoek .

Regel 18 bevat het qualityRegime (kwaliteitsregime) als aanduiding van de kwaliteitseis waaraan de gegevens in het brondocument voldoen .

<registrationRequest 
      xmlns="http://www.broservices.nl/xsd/isgmn/1.0"
      xmlns:brocom="http://www.broservices.nl/xsd/brocommon/3.0"
      xmlns:gml="http://www.opengis.net/gml/3.2"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.broservices.nl/xsd/isgmn/1.0 ../../XSD/isgmn-messages.xsd"
      >

  <!-- Disclaimer: dit voorbeeldbericht valideert tegen de XSD van de innamewebservice.
       Het is niet gevalideert door de innamewebservice en is vaktechnisch/inhoudelijk niet voorbeeldig.
  -->
  <brocom:requestReference>Groningen_04</brocom:requestReference>
  <!--Optional: dataleverancier is niet de bronhouder, dus is het gegeven aanwezig. -->
  <brocom:deliveryAccountableParty>27376655</brocom:deliveryAccountableParty>
  <!--Optional: brondocument is GMN_AddMeasuringPoint, dus moet het gegeven aanwezig zijn. -->
  <brocom:broId>GMN123456789012</brocom:broId>
  <brocom:qualityRegime>IMBRO</brocom:qualityRegime>
  <!--Optional: niet toegestaan bij GMN.
  <brocom:underPrivilege>ja</brocom:underPrivilege>
  -->

Regel 22 bevat de opening tag van het sourceDocument (brondocument).

Regel 23 geeft aan dat GMN_MeasuringPointEndDate het type is van het brondocument. Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 24 t/m 33 bevat de eventDate (datum gebeurtenis) waarop de gegevens in de werkelijkheid hun geldigheid hebben gekregen. In het voorbeeldbericht heeft dit de waarde 2021-12-02 (2 december 2021). Volgens de catalogus kan er naast een volledige datum (jaar, maand, dag) ook sprake zijn van 3 minder nauwkeurige varianten. Regel 27 t/m 30 bevatten als commentaar alle 4 varianten voor 2 december 2021 met een afnemende nauwkeurigheid.

Regel 35 bevat de measuringPointCode (meetpuntcode) van het meetpunt dat moet worden beëindigd.

Regel 36 bevat de closing tag GMN_MeasuringPointEndDate als type van het sourceDocument (brondocument).

Regel 37 bevat de closing tag van het sourceDocument (brondocument).

Regel 38 bevat de closing tag van het registrationRequest (registratieverzoek).

  <sourceDocument>
    <GMN_MeasuringPointEndDate gml:id="id_0001">
        <eventDate>
          <!--You have a CHOICE of the next 4 items at this level-->
          <!-- 
          <brocom:date>2021-12-02</brocom:date>
          <brocom:yearMonth>2021-12</brocom:yearMonth>
          <brocom:year>2021</brocom:year>
          <brocom:voidReason>onbekend</brocom:voidReason>
           -->
          <brocom:date>2021-12-02</brocom:date>
        </eventDate>
        <measuringPointCode>GMW07E000002</measuringPointCode>
    </GMN_MeasuringPointEndDate>
  </sourceDocument>
</registrationRequest>

05registrationRequestClosure

Het voorbeeldbericht 05registrationRequestClosure.xml bevat een registratieverzoek, waarmee de registratie van het gehele grondwatermonitoringnet wordt beëindigd.

Onderstaande figuur toont op hoofdlijnen de structuur van het registratieverzoek en het brondocument. 

Dan volgt hier regel voor regel een beschrijving van het voorbeeldbericht. Zie de onderstaande tabellen met regelnummers en XML-code van de regel.

De eerste regel van het voorbeeldbericht bevat de XML-proloog. Merk op dat de tekens volgens UTF-8 gecodeerd moeten worden. Dit is met name van belang voor speciale tekens, zoals à, á, ï.

Regel 2 t/m 8 bevatten de opening tag van het registrationRequest (registratieverzoek) als root XML-element en de namespaces van de gebruikte XML-schemadefinities (XSD's).

Regel 13 t/m 21 bevatten de transactiegegevens.

Regel 13 bevat de requestReference (verzoekkenmerk), een voor de dataleverancier unieke aanduiding van het BRO-verzoek.

Regel 15 bevat het optionele element deliveryAccountableParty (bronhouder). De waarde is het KvK-nummer van de bronhouder. Dit element is opgenomen in het voorbeeldbericht, omdat in dit voorbeeld de dataleverancier niet de bronhouder is.

Regel 17 bevat de broId (BRO-id) als unieke identificatie van het registratieobject waarvan de registratie beëindigd moet worden .

Regel 18 bevat het qualityRegime (kwaliteitsregime) als aanduiding van de kwaliteitseis waaraan de gegevens in het brondocument voldoen .

<registrationRequest 
      xmlns="http://www.broservices.nl/xsd/isgmn/1.0"
      xmlns:brocom="http://www.broservices.nl/xsd/brocommon/3.0"
      xmlns:gml="http://www.opengis.net/gml/3.2"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.broservices.nl/xsd/isgmn/1.0 ../../XSD/isgmn-messages.xsd"
      >

  <!-- Disclaimer: dit voorbeeldbericht valideert tegen de XSD van de innamewebservice.
       Het is niet gevalideert door de innamewebservice en is vaktechnisch/inhoudelijk niet voorbeeldig.
  -->
  <brocom:requestReference>Groningen_05</brocom:requestReference>
  <!--Optional: dataleverancier is niet de bronhouder, dus is het gegeven aanwezig. -->
  <brocom:deliveryAccountableParty>27376655</brocom:deliveryAccountableParty>
  <!--Optional: brondocument is GMN_AddMeasuringPoint, dus moet het gegeven aanwezig zijn. -->
  <brocom:broId>GMN123456789012</brocom:broId>
  <brocom:qualityRegime>IMBRO</brocom:qualityRegime>
  <!--Optional: niet toegestaan bij GMN.
  <brocom:underPrivilege>ja</brocom:underPrivilege>
  -->

Regel 22 bevat de opening tag van het sourceDocument (brondocument).

Regel 23 geeft aan dat GMN_Closure het type is van het brondocument. Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 24 t/m 33 bevat de endDateMonitoring (einddatum monitoring) waarop de registratie is beëindigd. In het voorbeeldbericht heeft dit de waarde 2021-12-30 (30 december 2021). Volgens de catalogus kan er naast een volledige datum (jaar, maand, dag) ook sprake zijn van 3 minder nauwkeurige varianten. Regel 27 t/m 30 bevatten als commentaar alle 4 varianten voor 30 december 2021 met een afnemende nauwkeurigheid.

Regel 34 bevat de closing tag GMN_Closure als type van het sourceDocument (brondocument).

Regel 35 bevat de closing tag van het sourceDocument (brondocument).

Regel 36 bevat de closing tag van het registrationRequest (registratieverzoek).

  <sourceDocument>
    <GMN_Closure gml:id="id_0001">
      <endDateMonitoring>
        <!--You have a CHOICE of the next 4 items at this level-->
        <!-- 
        <brocom:date>2021-12-30</brocom:date>
        <brocom:yearMonth>2021-12</brocom:yearMonth>
        <brocom:year>2021</brocom:year>
        <brocom:voidReason>onbekend</brocom:voidReason>
         -->
        <brocom:date>2021-12-30</brocom:date>
      </endDateMonitoring>
    </GMN_Closure>
  </sourceDocument>
</registrationRequest>

Gegevens corrigeren

11replaceRequestStartRegistrationBronhouder

Het voorbeeldbericht 11replaceRequestStartRegistrationBronhouder.xml bevat een correctieverzoek, waarmee de waarde voor de bronhouder van een grondwatermonitoringnet wordt vervangen.

Onderstaande figuur toont op hoofdlijnen de structuur van het registratieverzoek en het brondocument. 

Merk op dat het brondocument GMN_StartRegistration alle gegevens van de entiteit GroundwaterMonitoringNet (GrondwaterMonitoringNet) bevat, maar niet de lijst met measuringPoints (meetpunten).

Dan volgt hier regel voor regel een beschrijving van het voorbeeldbericht. Zie de onderstaande tabellen met regelnummers en XML-code van de regel.

De eerste regel van het voorbeeldbericht bevat de XML-proloog. Merk op dat de tekens volgens UTF-8 gecodeerd moeten worden. Dit is met name van belang voor speciale tekens, zoals à, á, ï.

Regel 2 t/m 8 bevatten de opening tag van het correctionRequest (correctieverzoek) als root XML-element en de namespaces van de gebruikte XML-schemadefinities (XSD's).

Regel 13 t/m 21 bevatten de transactiegegevens.

Regel 13 bevat de requestReference (verzoekkenmerk), een voor de dataleverancier unieke aanduiding van het BRO-verzoek.

Regel 15 bevat het optionele element deliveryAccountableParty (bronhouder). De waarde is het KvK-nummer van de bronhouder. Deze waarde moet de momenteel geregistreerde waarde vervangen.

Regel 16 bevat de broId (BRO-id) als unieke identificatie van het registratieobject waarvan we de waarde voor het gegeven deliveryAccountableParty (bronhouder) willen corrigeren.

Regel 17 bevat het qualityRegime (kwaliteitsregime) als aanduiding van de kwaliteitseis waaraan de gegevens in het brondocument voldoen. De waarde IMBRO/A is nodig, omdat de waarde van startDateMonitoring (begindatum monitoring) niet een volledige datum is.

Regel 21 bevar de correctionReason (correctie reden), met in dit voorbeeldbericht de waarde bronhouder, omdat we de waarde voor het gegeven deliveryAccountableParty (bronhouder) willen corrigeren.

Regel 22 bevat de opening tag van het sourceDocument (brondocument).

Regel 23 geeft aan dat GMN_StartRegistration het type is van het brondocument. Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 24 t/m 38 bevatten de elementen van de entiteit GroundwaterMonitoringNet (GrondwaterMonitoringNet).

Regel 39 bevat de closing tag GMN_StartRegistration als type van het sourceDocument (brondocument).

Regel 40 bevat de closing tag van het sourceDocument (brondocument).

Regel 41 bevat de closing tag van het correctionRequest (correctieverzoek).

12replaceRequestStartRegistrationAspect

Het voorbeeldbericht 12replaceRequestStartRegistrationAspect.xml bevat een correctieverzoek, waarmee de waarde voor het groundwaterAspect (grondwateraspect) van een grondwatermonitoringnet wordt vervangen.

Onderstaande figuur toont op hoofdlijnen de structuur van het registratieverzoek en het brondocument. 

Merk op dat het brondocument GMN_StartRegistration alle gegevens van de entiteit GroundwaterMonitoringNet (GrondwaterMonitoringNet) bevat, maar niet de lijst met measuringPoints (meetpunten).

Dan volgt hier regel voor regel een beschrijving van het voorbeeldbericht. Zie de onderstaande tabellen met regelnummers en XML-code van de regel.

De eerste regel van het voorbeeldbericht bevat de XML-proloog. Merk op dat de tekens volgens UTF-8 gecodeerd moeten worden. Dit is met name van belang voor speciale tekens, zoals à, á, ï.

Regel 2 t/m 8 bevatten de opening tag van het correctionRequest (correctieverzoek) als root XML-element en de namespaces van de gebruikte XML-schemadefinities (XSD's).

Regel 13 t/m 21 bevatten de transactiegegevens.

Regel 13 bevat de requestReference (verzoekkenmerk), een voor de dataleverancier unieke aanduiding van het BRO-verzoek.

Regel 15 bevat het optionele element deliveryAccountableParty (bronhouder). De waarde is het KvK-nummer van de bronhouder. Dit element is opgenomen in het voorbeeldbericht, omdat in dit voorbeeld de dataleverancier niet de bronhouder is.

Regel 16 bevat de broId (BRO-id) als unieke identificatie van het registratieobject waarvan we de waarden van enkele administratieve gegevens willen corrigeren .

Regel 17 bevat het qualityRegime (kwaliteitsregime) als aanduiding van de kwaliteitseis waaraan de gegevens in het brondocument voldoen. De waarde IMBRO/A is nodig, omdat de waarde van startDateMonitoring (begindatum monitoring) niet een volledige datum is.

Regel 21 bevar de correctionReason (correctie reden), met in dit voorbeeldbericht de waarde eigenCorrectie, omdat we de waarden van enkele administratieve gegevens op eigen initiatief (d.w.z. niet naar aanleiding van een terugmelding en in-onderzoek plaatsing) willen corrigeren.

Regel 22 bevat de opening tag van het sourceDocument (brondocument).

Regel 23 geeft aan dat GMN_StartRegistration het type is van het brondocument. Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 24 t/m 38 bevat de elementen van de entiteit GroundwaterMonitoringNet (GrondwaterMonitoringNet).

Regel 28 bevat het element groundwaterAspect (grondwateraspect) met daarin de waarde die de momenteel geregistreerde waarde moet vervangen.

Regel 39 bevat de closing tag GMN_StartRegistration als type van het sourceDocument (brondocument).

Regel 40 bevat de closing tag van het sourceDocument (brondocument).

Regel 41 bevat de closing tag van het correctionRequest (correctieverzoek).

13replaceRequestStartRegistrationQualityRegime

Het voorbeeldbericht 13replaceRequestStartRegistrationQualityRegime.xml bevat een correctieverzoek, waarmee de waarde voor het qualityRegime (kwaliteitsregime) van een grondwatermonitoringnet wordt vervangen.

Onderstaande figuur toont op hoofdlijnen de structuur van het registratieverzoek en het brondocument.

Merk op dat het brondocument GMN_StartRegistration alle gegevens van de entiteit GroundwaterMonitoringNet (GrondwaterMonitoringNet) bevat, maar niet de lijst met measuringPoints (meetpunten).

Dan volgt hier regel voor regel een beschrijving van het voorbeeldbericht. Zie de onderstaande tabellen met regelnummers en XML-code van de regel.

De eerste regel van het voorbeeldbericht bevat de XML-proloog. Merk op dat de tekens volgens UTF-8 gecodeerd moeten worden. Dit is met name van belang voor speciale tekens, zoals à, á, ï.

Regel 2 t/m 8 bevatten de opening tag van het correctionRequest (correctieverzoek) als root XML-element en de namespaces van de gebruikte XML-schemadefinities (XSD's).

Regel 13 t/m 21 bevatten de transactiegegevens.

Regel 13 bevat de requestReference (verzoekkenmerk), een voor de dataleverancier unieke aanduiding van het BRO-verzoek.

Regel 15 bevat het optionele element deliveryAccountableParty (bronhouder). De waarde is het KvK-nummer van de bronhouder. Dit element is opgenomen in het voorbeeldbericht, omdat in dit voorbeeld de dataleverancier niet de bronhouder is.

Regel 16 bevat de broId (BRO-id) als unieke identificatie van het registratieobject waarvan we de waarde voor het gegeven qualityRegime (kwaliteitsregime) willen corrigeren.

Regel 17 bevat het qualityRegime (kwaliteitsregime) welke waarde de momenteel geregistreerde waarde moet vervangen. Deze waarde is zowel een aanduiding van de kwaliteitseis waaraan de gegevens in het brondocument voldoen, als waaraan de geregistreerde gegevens moeten voldoen na verwerking van dit verzoek.

Regel 21 bevar de correctionReason (correctie reden), met in dit voorbeeldbericht de waarde kwaliteitsRegime, omdat we de waarde voor het gegeven qualityRegime (kwaliteitsregime) willen corrigeren.

Regel 22 bevat de opening tag van het sourceDocument (brondocument).

Regel 23 geeft aan dat GMN_StartRegistration het type is van het brondocument. Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 24 t/m 31 bevatten de elementen van de entiteit GroundwaterMonitoringNet (GrondwaterMonitoringNet).

Regel 32 bevat de closing tag GMN_StartRegistration als type van het sourceDocument (brondocument).

Regel 33 bevat de closing tag van het sourceDocument (brondocument).

Regel 34 bevat de closing tag van het correctionRequest (correctieverzoek).

14moveRequestStartRegistration

Het voorbeeldbericht 14moveRequestStartRegistration.xml bevat een correctieverzoek, waarmee de startDateMonitoring (begindatum monitoring) van een grondwatermonitoringnet wordt gecorrigeerd, waardoor het punt op de tijdlijn van de materiële historie wordt verplaatst.

Onderstaande figuur toont op hoofdlijnen de structuur van het registratieverzoek en het brondocument.

Merk op dat het brondocument GMN_StartRegistration twee meetpunten bevat. Van de in de registratie opgenomen meetpunten zal alleen voor deze meetpunten de startDate (startdatum meetpunt) worden aangepast.

Dan volgt hier regel voor regel een beschrijving van het voorbeeldbericht. Zie de onderstaande tabellen met regelnummers en XML-code van de regel.

De eerste regel van het voorbeeldbericht bevat de XML-proloog. Merk op dat de tekens volgens UTF-8 gecodeerd moeten worden. Dit is met name van belang voor speciale tekens, zoals à, á, ï.

Regel 2 t/m 8 bevatten de opening tag van het moveRequest (verplaatsverzoek) als root XML-element en de namespaces van de gebruikte XML-schemadefinities (XSD's).

Regel 13 t/m 21 bevatten de transactiegegevens.

Regel 13 bevat de requestReference (verzoekkenmerk), een voor de dataleverancier unieke aanduiding van het BRO-verzoek.

Regel 15 bevat het optionele element deliveryAccountableParty (bronhouder). De waarde is het KvK-nummer van de bronhouder. Dit element is opgenomen in het voorbeeldbericht, omdat in dit voorbeeld de dataleverancier niet de bronhouder is.

Regel 16 bevat de broId (BRO-id) als unieke identificatie van het registratieobject waarvan we de startDateMonitoring (begindatum monitoring) van het grondwatermonitoringnet en de startDate (startdatum meetpunt) van enkele meetpunten willen corrigeren.

Regel 17 bevat het qualityRegime (kwaliteitsregime) als aanduiding van de kwaliteitseis waaraan de gegevens in het brondocument voldoen.

Regel 21 bevar de correctionReason (correctie reden), met in dit voorbeeldbericht de waarde eigenCorrectie, omdat we de correcties uitvoeren op eigen initiatief, d.w.z. niet naar aanleiding van een terugmelding en in-onderzoek plaatsing.

Regel 22 bevat de opening tag van het sourceDocument (brondocument).

Regel 23 geeft aan dat GMN_StartRegistration het type is van het brondocument. Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 24 t/m 38 bevat de elementen van de entiteit GroundwaterMonitoringNet (GrondwaterMonitoringNet).

Regel 29 t/m 38 bevat de startDateMonitoring (begindatum monitoring) met daarin de waarde die die momenteel geregistreerde waarde gaat vervangen. In het voorbeeldbericht heeft dit de waarde 2021-03-01 (1 maart 2021). Volgens de catalogus kan er naast een volledige datum (jaar, maand, dag) ook sprake zijn van 3 minder nauwkeurige varianten. Regel 32 t/m 35 bevatten als commentaar alle 4 varianten voor 1 maart 2021 met een afnemende nauwkeurigheid.

Vanaf regel 39 volgen één of meer voorkomens van een measuringPoint (meetpunt) waaruit het grondwatermonitoringnet bestaat. Het voorbeeldbericht bevat er 2, maar dat hadden er ook meer of minder kunnen zijn.

Regel 41 geeft aan dat MeasuringPoint (Meetpunt) het type is van het element measuringPoint (meetpunt). Het attribuut gml:id bevat een door de dataleverancier aangeleverde waarde die uniek moet zijn binnen dit bericht.

Regel 42 bevat de measuringPointCode (meetpuntcode) van het meetpunt. Van dit meetpunt wordt de momenteel geregistreerde waarde voor startDate (startdatum meetpunt) vervangen door de waarde van het element startDateMonitoring (begindatum monitoring) in dit brondocument.

Regel 53 bevat idem dito de measuringPointCode (meetpuntcode) van een meetpunt waarvan de startDate (startdatum meetpunt) zal worden aangepast.

Regel 62 bevat de closing tag GMN_StartRegistration als type van het sourceDocument (brondocument).

Regel 63 bevat de closing tag van het sourceDocument (brondocument).

Regel 64 t/m 73 bevat de dateToBeCorrected (te corrigeren datum). De waarde moet overeenkomen met de momenteel geregistreerde waarde voor startdateMonitoring (startdatum monitoring). In het voorbeeldbericht heeft dit de waarde 2021 (het jaar 2021). Volgens de catalogus kan er naast een jaartal ook sprake zijn van 3 andere varianten. Regel 67 t/m 70 bevatten als commentaar 4 varianten met een grotere of kleinere nauwkeurigheid dan het jaartal 2021.

Regel 74 bevat de closing tag van het moveRequest (verplaatsverzoek).

Enumeraties

Dit hoofdstuk bevat de toegestane waarden van de enumeraties (niet-beheerde waardenlijsten).

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 enumeraties die van belang zijn bij het maken van een BRO-verzoek over een grondwatermonitoringnet. 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.

Codelijsten

Dit hoofdstuk bevat verwijzingen (URN's en URL's) naar de codelijsten (beheerde waardenlijsten).

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. Bij een codelijst kan de lijst met toegestane waarden worden aangepast zonder dat aanpassingen nodig zijn in de berichtdefinities (XSD-bestanden) en/of de software (voor het maken of verwerken van een bericht). De gegevenscatalogus bevat per codelijst de toegestane waarden, zoals gedefinieerd op het moment dat de gegevenscatalogus werd vastgesteld.

De onderstaande tabel geeft een overzicht van de codelijsten die van belang zijn bij het maken van een BRO-verzoek over een grondwatermonitoringnet. 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 als waarde voor het XML-attribuut codeSpace. De vierde kolom bevat een link naar de website waar de actuele lijst is te raadplegen met toegestane waarden die in een BRO-verzoek gebruikt mogen worden als waarde voor een XML-element.

Vertaallijst

Dit hoofdstuk bevat een vertaaltabel, aan de hand waarvan, gegeven de Engelstalige naam van een entiteit of een attribuut, de Nederlandse naam in de gegevenscatalogus kan worden opgezocht.

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