GLD Berichtencatalogus innamewebservice

1. Inleiding

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

Het document veronderstelt dat de lezer bekend is met de GLD 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).

1.1. Leeswijzer

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

Hoofdstuk 3 bevat een toelichting op enkele voorbeeldberichten.

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

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

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

1.2. Versiehistorie

Open issue (in uitvoering)

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

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

2. BRO-Verzoek

Dit hoofdstuk beschrijft de algemene opbouw van een BRO-verzoek. Een BRO-verzoek bestaat uit een brondocument verpakt in een 'request'.

Paragraaf 2.1 beschrijft de levensloop van een GLD registratieobject.

Paragraaf 2.2 beschrijft de verschillende brondocumenten waarmee de GLD gegevens aangeboden kunnen worden.

Paragraaf 2.3 beschrijft de verschillende requests van de GLD innamewebservice.

Paragraaf 2.4 beschrijft de omzetting van het het conceptuele model van GLD naar een XML implementatie.

2.1. Object met levensloop

Het grondwaterstandonderzoek is een object met een levensloop. De levensloop van een grondwaterstandonderzoek heeft een begin en een eind, en loopt gelijk met de periode waarin de kwantiteit van het grondwater wordt gemonitord. Gedurende de levensloop van een grondwaterstandonderzoek worden periodiek metingen verricht naar de grondwaterstand, die geregistreerd moeten worden in de BRO. De registratie van gegevens van een grondwaterstandonderzoek is dus geen eenmalige gebeurtenis, maar een proces dat zo lang duurt als het grondwaterstandonderzoek plaats vindt. 

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.

2.1.1. Gebeurtenissen

Het grondwaterstandonderzoek leidt in praktijk tot het ontstaan van gegevens op min of meer vastomlijnde momenten. Deze gebeurtenissen vormen een rechtstreekse aanleiding voor het aanleveren van de bijbehorende gegevens.

De GLD innamewebservice maakt een onderscheid in 3 gebeurtenissen. Normaal gesproken begint de registratie van een grondwaterstandonderzoek met het starten van de registratie, gevolgd door het aanvullen van de registratie en uiteindelijk het beëindigen van de registratie.

De GLD innamewebservice definieert voor iedere gebeurtenis een brondocument, waarmee de op dat moment beschikbaar gekomen gegevens kunnen worden aangeboden. Deze brondocumenten worden verder besproken in paragraaf 2.2.

Een brondocument wordt verpakt in een BRO-verzoek. Daarbij zijn de gedefinieerde brondocumenten de eenheid van aanleveren. De types BRO-verzoeken worden beschreven in paragraaf 2.3.

Een BRO-verzoek wordt via het bronhouderportaal aangeboden bij de innamewebservice. Het BRO systeem valideert de gegevens in het BRO-verzoek 'op zichzelf' en in relatie tot de in de registratie aanwezige gegevens. Welke regels hierbij gecontroleerd worden is afhankelijk van het type brondocument in het type BRO-verzoek.

In tegenstelling tot andere BRO registratieobjecten die aanvullingen kennen, worden bij GLD de aanvullingen niet vastgelegd in een opvraagbare reeks van tussentijdse gebeurtenissen. Wel worden de in een brondocument aangeboden gegevens vastgelegd in de registratie ondergrond. De reden voor het niet vastleggen van de tussentijdse gebeurtenissen is dat er bij GLD een zeer grote overlap bestaat tussen de aangeboden gegevens bij een tussentijdse gebeurtenis en de gegevens die zijn toegevoegd aan de registratie ondergrond. Bovendien gaat het hier potentieel om grote hoeveelheden gegevens, die dan dubbel opgeslagen zouden worden.

2.1.2. Materiële geschiedenis

GLD is een registratieobject zonder materiële geschiedenis. Wel worden er in de loop van de tijd aanvullingen aangeleverd (zie paragraaf 2.1.1). Daarnaast kunnen uiteraard de geregistreerde gegevens gecorrigeerd worden; dit noemen we formele geschiedenis (zie paragraaf 2.1.3).

2.1.3. 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 een geconstateerde fout in de geregistreerde gegevens in de BRO. Zie voor een nadere toelichting paragraaf 2.5 van de GLD gegevenscatalogus.

Bij GLD is het belangrijk een onderscheid te maken tussen de registratie van een verbeterde waarde naar aanleiding van een beoordelingsproces aan de ene kant, en het corrigeren van een foute waarde aan de andere kant.

Verbeteringen die het gevolg zijn van een beoordelingsproces komen vaak pas na langere tijd, bijvoorbeeld een jaar, beschikbaar. Daarom hebben de stakeholders afgesproken om nog niet beoordeelde gegevens of nog niet volledig beoordeelde gegevens meteen in de BRO te registreren zodra deze gegevens beschikbaar komen. Op een later tijdstip, zodra de volledig beoordeelde (en eventueel verbeterde) gegevens beschikbaar komen, worden deze apart geregistreerd. Beide worden geregistreerd met een aanvulling. Beide zijn opvraagbaar via de uitgiftewebservice. Het onderscheid tussen beide wordt gemaakt door het attribuut mate beoordeling .

Correcties van foutief geregistreerde gegevens worden aangeboden nadat de fout is geconstateerd en de juiste waarde bekend is. Deze correcties leiden tot het opbouwen van formele geschiedenis. Bij het corrigeren van een foutief geregistreerde waarde wordt de oorspronkelijke waarde overschreven. Alleen de nieuwe waarde is op te vragen via de uitgiftewebservice. Voorbeelden van correcties zijn wanneer het verkeerde type meetinstrument is geregistreerd, of een fout in een meetwaarde, of het ontbreken van de censurering van een out-of-bounds meetwaarde.

Omdat GLD een registratieobject zonder materiële geschiedenis is, is het corrigeren van gegevens een eenvoudig proces. Met behulp van een vervangverzoek kunnen foute waardes van geregistreerde gegevens worden vervangen. Met behulp van een verwijderverzoek kunnen ten onrechte aangevulde gegevens worden verwijderd. In beide types verzoeken zijn de gedefinieerde brondocumenten de eenheid van correctie. Het is dus niet mogelijk een individueel gegeven te corrigeren. De details van een BRO-verzoek worden beschreven in paragraaf 2.3.

Een vervangverzoek of een verwijderverzoek wordt net als een registratieverzoek via het bronhouderportaal aangeboden bij de innamewebservice. Het BRO systeem valideert de gegevens in het verzoek 'op zichzelf' en in relatie tot de in de registratie aanwezige gegevens. Welke regels hierbij gecontroleerd worden is afhankelijk van het brondocument en het type verzoek. Zie paragraaf 2.3 voor nadere details over deze aanvullende regels naast de regels (IMBRO en IMBRO/A) in de gegevenscatalogus.

2.2. Brondocumenten

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

Naast de gegevens in een brondocument moeten in een BRO-verzoek ook nog enkele transactiegegevens worden aangeleverd. Zie paragraaf 2.3.

Tijdens het verwerken van een BRO-verzoek leidt het BRO-systeem enkele attributen af. Deze attributen hebben in het domeinmodel in de GLD catalogus een deelteken staan voor hun naam. Deze attributen hoeven niet aangeleverd te worden. Het gaat daarbij om: broId (BRO-ID), research FirstDate (datum eerste meting), researchLastDate (datum recentste meting) en registrationHistory (registratiegeschiedenis).

2.2.1. GLD_StartRegistration

Het brondocument GLD_StartRegistration (GLD-StartRegistratie) kan met de onderstaande verzoeken worden aangeboden bij de volgende aanleidingen:

• registrationRequest (registratieverzoek) - De initiële inrichting van een grondwaterstandonderzoek.

• replaceRequest (vervangverzoek) - Een fout herstellen in de geregistreerde gegevens over de initiële inrichting. Bijvoorbeeld wanneer bij de initiële registratie de verwijzing naar een verkeerde monitoringbuis (GMW broID en tubeNumber) is geregistreerd.

Het brondocument GLD_StartRegistration (GLD-StartRegistratie) kan niet worden verwijderd met een deleteRequest (verwijderverzoek). Het verwijderen van een registratie kan alleen door het registratieobject uit registratie te nemen. Neem hiervoor contact op met de BRO Servicedesk via een mail naar support@broservicedesk.nl.

2.2.1.1. Inhoud

Het brondocument GLD_StartRegistration (GLD-StartRegistratie) is bedoeld om de registratie van een nieuw GLD te starten. De bronhouder levert daarbij alleen het monitoringPoint (verwijzing naar de buis in een grondwatermonitoringput), waarin het grondwaterstandonderzoek wordt uitgevoerd en een optionele lijst met groundwatermonitoringnets (grondwatermonitoringnetten) aan, in het kader waarvan het grondwaterstandonderzoek wordt uitgevoerd.

De gegevens in het brondocument GLD_StartRegistration (GLD-StartRegistratie)  zijn volledig gedefinieerd in de gegevenscatalogus. Het brondocument GLD_StartRegistration (GLD-StartRegistratie)  bevat alle gegevens uit de gegevenscatalogus met uitzondering van de volgende gegevens:

• Attribuut  broId  (BRO-ID). Deze wordt niet opgenomen in het brondocument maar in het BRO-verzoek, behalve bij het registrationRequest  (registratieverzoek) want dan genereert de BRO een waarde voor dit gegeven.

• Attribuut  deliveryAccountableParty  (bronhouder). Deze wordt niet opgenomen in het brondocument maar in het BRO-verzoek.

• Attribuut deliveryResponsibleParty  (dataleverancier). Deze wordt niet opgenomen in het brondocument maar in de SOAP header van het bericht.

• Attribuut  qualityRegime  (kwaliteitsregime). Deze wordt niet opgenomen in het brondocument maar in het BRO-verzoek.

• Attribuut researchFirstDate (datum eerste meting), wordt afgeleid door de BRO.

• Attribuut researchLastDate (datum recentste meting), wordt afgeleid door de BRO.

• Entiteit OM_Observation (Observatie): alle attributen en sub-entiteiten. Deze worden aangeleverd met een GLD_Addition (GLD-Aanvulling) brondocument.

• Entiteit  RegistrationHistory  (Registratiegeschiedenis), wordt afgeleid door de BRO.

2.2.1.2. Aanvullende regels

Aanvullende regels naast de regels (IMBRO en IMBRO/A) in de GLD gegevenscatalogus:

• De BRO geeft het attribuut registrationStatus (registratiestatus) van de entiteit RegistrationHistory (Registratiegeschiedenis) de waarde 'geregistreerd' als dit brondocument wordt aangeboden met een registrationRequest (registratieverzoek). In alle andere gevallen blijft de waarde van het attribuut registrationStatus (registratiestatus) ongewijzigd.

2.2.2. GLD_Addition

Nadat de registratie van een GLD is gestart kan een observatie worden toegevoegd via het GLD_Addition (GLD-Aanvulling) brondocument. GLD_Addition (GLD-Aanvulling) wordt gebruikt:

1. Als de gegevens van een controlemeting beschikbaar zijn gekomen.

2. Als de gegevens van een meetreeks met reguliere metingen beschikbaar zijn gekomen, met tijdmeetwaardeparen die geen of een voorlopige beoordeling hebben ondergaan.

3. Als de gegevens van een meetreeks met reguliere metingen beschikbaar zijn gekomen, met tijdmeetwaardeparen die volledig beoordeeld zijn.

Het brondocument GLD_Addition (GLD-Aanvulling) kan met de onderstaande verzoeken worden aangeboden voor de onderstaande gebruiksdoelen:

• registrationRequest (registratieverzoek) - Een (1) aanvullende observatie registreren.

• replaceRequest (vervangverzoek) - N.B. Een fout herstellen in de geregistreerde gegevens van een observatie. Bijvoorbeeld wanneer in de ObservationMetadata (Metadata observatie) was aangegeven dat het om een reguliere meting ging terwijl het in de werkelijkheid om een controlemeting ging.

• deleteRequest (verwijderverzoek) - Een observatie verwijderen uit het grondwaterstandonderzoek. Bijvoorbeeld omdat een controlemeting is toegevoegd aan dit registratieobject, terwijl de meting is uitgevoerd in een andere put.

2.2.2.1. Inhoud

Het brondocument bevat een observatie met een tijdmeetwaardereeks met daarin minstens 1 en maximaal 10.000 tijdmeetwaardeparen inclusief hun metadata, metadata over de observatie en een observatieproces. Dit maximum is gebaseerd op de aannames dat er niet vaker dan één keer per uur een meting wordt gedaan en dat een datalogger minstens één keer per jaar wordt uitgelezen en dat de periode van een tijdmeetwaardereeks met volledig beoordeelde tijdmeetwaardeparen niet langer is dan één jaar. Als de meetfrequentie hoger is, dan moet de dataleverancier de periode van de tijdmeetwaardereeks aanpassen zodat het totaal aantal tijdmeetwaardeparen in het brondocument de limiet niet overschrijdt.

De volgende attributen worden niet via het brondocument aangeleverd:

• Attribuut broId (BRO-ID). Deze wordt niet opgenomen in het brondocument maar in het BRO-verzoek.

• Attribuut deliveryAccountableParty (bronhouder). Deze wordt niet opgenomen in het brondocument maar in het BRO-verzoek.

• Attribuut deliveryResponsibleParty (dataleverancier). Deze wordt niet opgenomen in het brondocument maar in de SOAP header van het bericht.

• Attribuut qualityRegime (kwaliteitsregime). Deze wordt niet opgenomen in het brondocument maar in het BRO-verzoek.

Eerder aangeleverde observaties kunnen niet aangevuld worden met nieuwe tijdmeetwaardeparen! Nieuwe tijdmeetwaardeparen moeten geregistreerd worden door deze als een nieuwe observatie in een GLD_Addition (GLD-Aanvulling) brondocument in een registrationRequest (registratieverzoek) aan te bieden. N.B.  Ontbrekende tijdmeetwaardeparen (binnen de observatie periode aangegeven door het attribuut phenomenonTime) kunnen worden toegevoegd met een replaceRequest (vervangverzoek).

2.2.2.2. Gerelateerde observatie

Bij een observatie met volledig beoordeelde tijdmeetwaardeparen kan een relatie relatedObservation (gerelateerde observatie) worden gelegd naar een of meer andere observaties (met een controlemeting of een reguliere meting met voorlopig beoordeelde tijdmeetwaardeparen), waarop de volledig beoordeelde tijdmeetwaardeparen zijn gebaseerd. Voor het verwijzen naar een observatie, wordt gebruik gemaakt van het gml:id (observatie ID) van de gerelateerde observatie.

Een in de BRO geregistreerde observatie mag niet worden verwijderd (met een deleteRequest (verwijderverzoek)) als hiernaar wordt verwezen vanuit een observatie met volledig beoordeelde tijdmeetwaardeparen. N.B. In dat geval moet eerst de observatie met volledig beoordeelde tijdmeetwaardeparen worden vervangen (zonder de genoemde verwijzingen) of verwijderd.

2.2.2.3. Hergebruik van een ObservationProcess (Observatieproces)

Het komt vaak voor dat meerdere observaties zijn uitgevoerd met hetzelfde observatieproces. Bij het aanbieden van een observatie kan dan worden verwezen naar het observatieproces zoals eerder aangeleverd bij een andere observatie. Voor het verwijzen naar een observatieproces wordt gebruik gemaakt van de gml:id (observatieproces ID) van het eerder aangeleverde observatieproces.

Het gebruik van een verwijzing is niet verplicht, maar wordt wel dringend aangeraden. Het alternatief is dat alle attributen van het observatieproces als duplicaat nogmaals worden aangeleverd.

Als geen verwijzing wordt gebruikt, moeten alle attributen van het observatieproces worden aangeleverd. De waarde voor gml:id (observatieproces ID) moet uniek zijn binnen het registratieobject. Zie het voorbeeldbericht 11_GLD_Addition_sensorisch.xml in paragraaf 3.1.

Als een verwijzing wordt gebruikt, moeten niet de attributen van het observatieproces worden aangeleverd, maar alleen een xlink:href (observatieproces ID) naar de gml:id (observatieproces ID) van het eerder aangeleverde observatieproces. Zie het voorbeeldbericht 12_GLD_Addition_sensorischHerhaling.xml in paragraaf 3.1.

Een in de BRO geregistreerde observatie mag niet worden verwijderd (met een deleteRequest (verwijderverzoek)), als deze observatie een volledig uitgeschreven ObservationProcess (Observatieproces) bevat waarnaar wordt verwezen vanuit een andere in de BRO geregistreerde OM_Observation (Observatie). N.B. In dat geval moet eerst de observatie met de verwijzing naar het ObservationProcess (Observatieproces) worden vervangen (waarbij het ObservationProcess (Observatieproces) volledig is uitgeschreven) of verwijderd.

2.2.2.4. Aanvullende regels

Aanvullende regels naast de regels (IMBRO en IMBRO/A) in de GLD gegevenscatalogus:

• Het brondocument bevat één (1) OM_Observation (Observatie).

• De tijdmeetwaardereeks in de observatie bestaat uit minimaal 1 tijdmeetwaardepaar.

• De tijdmeetwaardereeks in de observatie bestaat uit maximaal 10.000 tijdmeetwaardeparen.

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

• N.B. Feature by-value of by-reference maar niet beide:

  • Een procedure (uitgevoerd met) bevat óf een attribuut  xlink:href  (observatieproces ID) óf een ObservationProcess (Observatieproces), maar niet beiden.

  • Een relatedObservation (gerelateerd aan) bevat óf een attribuut  xlink:href  (observatie ID) óf een OM_Observation (Observatie), maar niet beiden.

• De waarde van gml:id moet uniek zijn binnen het registratieobject:

  • N.B. Een waarde voor gml:id (observatie ID of observatieproces ID) moet uniek zijn binnen het brondocument.

  • Een waarde voor gml:id (observatie ID) mag niet worden aangeboden in een registratieRequest (registratieverzoek) als deze waarde als gml:id aanwezig is binnen het registratieobject in de BRO.

  • Een waarde voor gml:id (observatieproces ID) mag niet worden aangeboden in een registratieRequest (registratieverzoek) als deze waarde als gml:id aanwezig is binnen het registratieobject in de BRO.

  • N.B. Een waarde voor gml:id (observatie ID) mag niet worden aangeboden in een replaceRequest (vervangverzoek) als deze waarde als gml:id aanwezig is bij een andere OM_Observation (Observatie) binnen het registratieobject in de BRO.

  • N.B. Een waarde voor gml:id (observatieproces ID) mag niet worden aangeboden in een replaceRequest (vervangverzoek) als deze waarde als gml:id aanwezig is bij een andere OM_Observation (Observatie) binnen het registratieobject in de BRO.

• De waarde van xlink:href moet als gml:id aanwezig zijn binnen het registratieobject:

  • N.B. De aangeleverde waarde van het XML-attribuut xlink:href (observatie ID) in een relatedObservation (gerelateerd aan)  moet als gml:id (observatie ID) aanwezig zijn in de BRO voor het registratieobject als het brondocument wordt aangeboden in een registratieRequest (registratieverzoek) of een replaceRequest (vervangverzoek).

  • De aangeleverde waarde van het attribuut xlink:href (observatieproces ID) in een procedure (uitgevoerd met) moet N.B. als gml:id (observatieproces ID) aanwezig zijn in de BRO voor het registratieobject als het brondocument wordt aangeboden in een registratieRequest (registratieverzoek) N.B. of een replaceRequest (vervangverzoek).

  • Een OM_Observation (Observatie) mag niet worden aangeboden in een deleteRequest (verwijderverzoek) als de waarde van de gml:id (observatie ID) van de OM_Observation (Observatie) aanwezig is in de BRO in een andere OM_Observation (Observatie) in een xlink:href (observatie ID) van een relatedObservation (gerelateerde observatie).

  • Een by-value opgenomen ObservationProcess (Observatieproces) mag niet worden verwijderd (door aanbieden in een deleteRequest (verwijderverzoek) of door niet opnemen in een replaceRequest (vervangverzoek)) als de gergistreerde waarde van de betreffende gml:id (observatieprocess ID) aanwezig is in de BRO in een andere OM_Observation (Observatie) in een xlink:href (observatieprocess ID) van een om:procedure (uitgevoerd met).

• De BRO leidt (opnieuw) een waarde af voor het attribuut researchFirstDate (datum eerste meting) van de entiteit GroundwaterLevelDossier (Grondwaterstandonderzoek):

  • De waarde voor researchFirstDate (datum eerste meting) is het datumdeel van de aangeleverde begindatum van het attribuut phenomenonTime (observatiePeriode) als researchFirstDate (datum eerste meting) nog geen waarde heeft.

  • De waarde voor researchFirstDate (datum eerste meting) is het datumdeel van de aangeleverde begindatum van het attribuut phenomenonTime (observatiePeriode) als researchFirstDate (datum eerste meting) een waarde heeft en het datumdeel van de begindatum van het aangeleverde attribuut phenomenonTime (observatiePeriode) ligt voor de huidige waarde van researchFirstDate (datum eerste meting).

• De BRO leidt (opnieuw) een waarde af voor het attribuut researchLastDate (datum recentste meting) van de entiteit GroundwaterLevelDossier (Grondwaterstandonderzoek):

  • De waarde voor researchLastDate (datum recentste meting) is het datumdeel van de aangeleverde einddatum van het attribuut phenomenonTime (observatiePeriode) als researchLastDate (datum recentste meting) nog geen waarde heeft.

  • De waarde voor researchLastDate (datum recentste meting) is het datumdeel van de aangeleverde einddatum van het attribuut phenomenonTime (observatiePeriode) als researchLastDate (datum recentste meting) een waarde heeft en het datumdeel van de aangeleverde einddatum van het attribuut phenomenonTime (observatiePeriode) ligt na de huidige waarde van researchLastDate (datum recentste meting).

2.2.3. GLD_Closure

Het brondocument GLD_Closure (GLD-Beeindiging) wordt met de onderstaande verzoeken aangeboden voor de onderstaande gebruiksdoelen:

• registrationRequest (registratieverzoek) - Bij de formele afsluiting van een grondwaterstandonderzoek. De registratie van het grondwaterstandonderzoek is daarmee beëindigd.. Nadat de registratie is voltooid kan deze niet met nieuwe reguliere metingen en/of controlemetingen worden aangevuld.

• deleteRequest (verwijderverzoek) - Het ongedaan maken van de formele afsluiting van een grondwaterstandonderzoek. Hierna kan het grondwaterstandonderzoek weer worden aangevuld met reguliere metingen en/of controlemetingen.

2.2.3.1. Inhoud

Het brondocument GLD_Closure (GLD-Beeindiging) heeft feitelijk geen inhoud.

De volgende attributen worden niet via het brondocument aangeleverd:

• Attribuut broId (BRO-ID). Deze wordt niet opgenomen in het brondocument maar in het BRO-verzoek.

• Attribuut deliveryAccountableParty (bronhouder). Deze wordt niet opgenomen in het brondocument maar in het BRO-verzoek.

• Attribuut deliveryResponsibleParty (dataleverancier). Deze wordt niet opgenomen in het brondocument maar in de SOAP header van het bericht.

• Attribuut qualityRegime (kwaliteitsregime). Deze wordt niet opgenomen in het brondocument maar in het BRO-verzoek.

2.2.3.2. Aanvullende regels

Aanvullende regels naast de GLD gegevenscatalogus, BRO-verzoek en WaterML:

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

• De BRO geeft het attribuut registrationStatus (registratiestatus) van de entiteit RegistrationHistory (Registratiegeschiedenis) de waarde 'geregistreerd' als het brondocument wordt aangeboden in een deleteRequest (verwijderverzoek) en er in de BRO voor het registratieobject geen OM_Observation (observatie) is geregistreerd.

• De BRO geeft het attribuut registrationStatus (registratiestatus) van de entiteit RegistrationHistory (Registratiegeschiedenis) de waarde 'aangevuld' als het brondocument wordt aangeboden in een deleteRequest (verwijderverzoek) en er in de BRO voor het registratieobject minstens een OM_Observation (observatie) is geregistreerd.

• De BRO leidt een waarde af voor het attribuut registrationCompletionTime (tijdstip voltooiing registratie) van de entiteit RegistrationHistory (Registratiegeschiedenis) als het brondocument wordt aangeboden in een registrationRequest (registratieverzoek).

• De BRO verwijdert de waarde voor het attribuut registrationCompletionTime (tijdstip voltooiing registratie) van de entiteit RegistrationHistory (Registratiegeschiedenis) als het brondocument wordt aangeboden in een deleteRequest (verwijderverzoek).

2.3. Definities van de BRO-verzoeken

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.

De GLD innamewebservice ondersteunt drie BRO-verzoeken. Zie onderstaande tabel.

De volgende tabel geeft weer welk brondocument met welk request kan worden aangeboden

N.B. het GLD_Closure brondocument is niet toegestaan bij een replaceRequest, omdat dit brondocument feitelijk leeg is; derhalve valt er niets te corrigeren/vervangen.

De volgende paragrafen beschrijven in detail de opbouw van de diverse requests (verzoeken).

2.3.1. RegistrationRequest

Met een registrationRequest (registratieverzoek) kan een nieuw grondwaterstandonderzoek in de BRO worden opgenomen of kan een een geregistreerd grondwaterstandonderzoek worden aangevuld of voltooid.

Een registrationRequest (registratieverzoek) bestaat uit enkele transactiegegevens en een brondocument. De definities van de transactiegegevens staan in onderstaande tabel:

Naast bovenstaande tabel bevatten ook de paragrafen 2.2 en 2.4 aanvullende regels naast de regels (IMBRO en IMBRO/A) in de gegevenscatalogus.

2.3.2. replaceRequest

Met een replaceRequest (vervangverzoek) kan een bronhouder en/of dataleverancier in de BRO opgenomen gegevens vervangen/corrigeren. De eenheid van vervangen is een brondocument, dat eerder met een registrationRequest (registratieverzoek) is aangeboden bij de BRO. Het is niet mogelijk de waarde van een individueel attribuut te corrigeren.

Een replaceRequest (vervangverzoek) bestaat uit enkele transactiegegevens en vooral een brondocument. De definities van de transactiegegevens, voor zover nog niet beschreven bij het registrationRequest (registratieverzoek), staan in onderstaande tabel:

Het is niet mogelijk identificerende gegevens te vervangen/corrigeren, zoals de gml:id (observatie ID) van een OM_Observation (Observatie) of de gml:id (observatieproces ID) van een ObservationProcess (Observatieproces).

Naast bovenstaande tabel bevatten ook de tabel in paragraaf 2.3.1 en de paragrafen 2.2 en 2.4 aanvullende regels naast de regels (IMBRO en IMBRO/A) in de gegevenscatalogus.

2.3.3. deleteRequest

Met een deleteRequest (verwijderverzoek) kan een bronhouder en/of dataleverancier in de BRO opgenomen gegevens verwijderen. De eenheid van verwijderen is een brondocument, dat eerder met een registrationRequest (registratieverzoek) is aangeboden bij de BRO. Het is niet mogelijk een individueel attribuut te verwijderen.

Een deleteRequest (verwijderverzoek) bestaat uit enkele transactiegegevens en vooral een brondocument. De definities van de transactiegegevens, voor zover nog niet beschreven bij het registrationRequest (registratieverzoek), staan in onderstaande tabel:

Naast bovenstaande tabel bevatten ook de tabellen in de paragrafen 2.3.1 en 2.3.2 en de paragrafen 2.2 en 2.4 aanvullende regels naast de regels (IMBRO en IMBRO/A) in de gegevenscatalogus.

2.4. WaterML

Het domeinmodel in de GLD gegevenscatalogus is gebaseerd op WaterML 2.0, een door het Open Geospatial Consortium (OGC) gepubliceerde internationale, open standaard over waterobservatiegegevens, met als doel de uitwisseling van dergelijke gegevens tussen informatiesystemen mogelijk te maken.

De specificaties van WaterML (https://www.ogc.org/standards/waterml) beschrijven een conceptueel model voor het uitwisselen van waterobservatiegegevens, gebaseerd op de O&M (Observations & Measurements) standaard. Daarnaast bevatten de specificaties van WaterML een XML implementatie conform de GML (Geography Markup Language version 3.2.1) standaard in de vorm van een applicatie schema. Het applicatie schema bestaat uit een XSD (XML Schema Definition) en een aantal schema constraints (bedrijfsregels), die zich met name richten op het gebruik van specifieke XML-datatypes, de aanwezigheid van XML-elementen, en het beperken van toegestane waarden.

Het gevolg is dat de GLD XML implementatie grotendeels wordt vastgelegd door deze standaarden. De omvang van de GLD specifieke XML implementatie is daarmee zeer beperkt.

Alhoewel het verband tussen de XML implementatie en het domeinmodel van GLD eenduidig is, beschrijft deze paragraaf ter verduidelijking hoe het conceptuele model van GLD en WaterML is omgezet in een XML implementatie.

2.4.1. GLD domeinmodel

Het domeinmodel in de GLD gegevenscatalogus hanteert Nederlandse namen voor alle entiteiten en attributen, inclusief die uit WaterML. De onderstaande figuur bevat het relevante deel van het GLD domeinmodel.

2.4.2. WaterML conceptueel model

Het WaterML conceptueel model hanteert Engelse namen voor de entiteiten en attributen. Onderstaande figuur toont hoe WaterML een MeasurementTimeseriesTVPObservation (Observatie met een tijdmeetwaarde reeks van tijdmeetwaarde paren als resultaat) definieert als een specialisatie van TimeseriesTVPObservation (Observatie met een tijdreeks van tijd-waarde paren als resultaat), wat op zijn beurt een specialisatie is van TimeseriesObservation (Observatie met een tijdreeks als resultaat).

De onderstaande figuur toont de context van een TimeseriesObservation (Observatie met een tijdreeks als resultaat). De TimeseriesObservation (Observatie met een tijdreeks als resultaat) is een specialisatie van de OM_DiscreteCoverageObservation, wat op zijn beurt een specialisatie is van OM_Observation (Observatie). De OM_Observation (Observatie) bevat attributen over een meting of een waarneming van een observedProperty (Waargenomen eigenschap) van een featureOfInterest (kenmerk van belang). De optionele lijst van het attribuut parameter (parameter) heeft als type NamedValue, wat bestaat uit het attribuut name (naam) en het attribuut value (waarde). Het datatype van value (waarde) is Any (willekeurig), maar kan via een XML-attribuut sterk getypeerd worden. Het featureOfInterest (Kenmerk van belang) is de intentie van een SF_SamplingFeature (Bemonsterd kenmerk) en de OM_Observation (Observatie) is één van de daarmee gerelateerde metingen of een waarnemingen. De TimeseriesObservation (Observatie met een tijdreeks als resultaat) voegt aan de OM_Observation (Observatie) toe een ObservationProcess (Observatieproces) en optionele ObservationMetadata (Metadata over een observatie).

De betekenis van de achtergrondkleur is als volgt:

• Blauw: entiteiten gedefinieerd in WaterML.

• Groen: entiteiten gedefinieerd in O&M (Observation and Measurement).

• Bruin: entiteiten gedefinieerd in SF (Sampling Features).

• Rood: entiteiten gedefinieerd in GML (Geography Markup Language).

• Geel: entiteiten gedefinieerd in GMD (Geographic MetaData).

Het MeasurementTimeseriesTVP (tijdmeetwaarde reeks van tijdmeetwaarde paren) uit de eerste figuur is een specialisatie van het TimeseriesTVP (Tijdreeks van tijd-waarde paren). Het voegt daaraan toe optionele MeasurementTimeseriesMetadata (Metadata over een tijdreeks van tijd-waarde paren). Het MeasurementTimeseriesTVP (tijdmeetwaarde reeks van tijdmeetwaarde paren) bevat een optionele reeks van MeasurementTimeValuePairs (tijdmeetwaarde paren), wat een specialisatie is van TimeValuePair (Tijd-waarde paar) en daarmee bestaat uit een geometry (geometrie), waarin een tijdstip wordt opgenomen, en een value (waarde), waarin de gemeten of waargenomen waarde van de eigenschap van het kenmerk van belang wordt opgenomen, in het geval van grondwaterstandonderzoek dus de waterstand. Het MeasurementTimeValuePair (tijdmeetwaarde paar) bevat ook optionele MeasurementPointMetadata (Metadata over een tijdmeetwaarde paar).

De MeasurementPointMetadata (Metadata over een tijdmeetwaarde paar) is een specialisatie van PointMetadata (Metadata over een tijd-waarde paar), waaraan het een aantal metagegevens toevoegt die specifiek zijn voor een gemeten waarde.

De MeasurementTimeseriesMetadata (Metadata over een tijdreeks van tijd-waarde paren is een specialisatie van TimeseriesMetadata (Metadata over een tijdreeks), waaraan het een aantal metagegevens toevoegt die specifiek zijn voor een reeks van gemeten waarden.

De ObservationMetadata (Metadata over een observatie) is een specialisatie van MD_Metadata (metadata), waaraan het een aantal metagegevens toevoegt die specifiek zijn voor een meetreeks in het algemeen en grondwatermonitoring in het bijzonder.

In O&M is het ObservationProcess (Observatieproces) een OM_Process (Proces), wat uit alleen een URL (verwijzing) bestaat. WaterML definieert ObservationProcess (Observatieproces) als specialisatie van OM_Process (Proces), zodat de mogelijkheid ontstaat om naast by-reference ook by-value een aantal attributen op te nemen die specifiek zijn voor WaterML.

2.4.3. XML implementatie

De XML-implementatie van WaterML is gedefinieerd in (https://www.ogc.org/standards/waterml). Voor gebruik binnen de BRO is hiervan een profiel gemaakt, wat de standaard beperkt tot de onderdelen die relevant zijn voor GLD. Het profiel bestaat uit:

• Een aantal XSD-bestanden.

• Een mapping van het relevante deel van het GLD conceptueel model via het WaterML conceptueel model naar de WaterML XML implementatie.

• Aanvullende regels (voornamelijk een deelverzameling van de WaterML XML conformance classes).

2.4.3.1. XSD-bestanden

De XSD-bestanden van het BRO WaterML profiel zijn te vinden op  https://schema.broservices.nl/profile/. Onderstaande figuur toont het package diagram met de onderlinge afhankelijkheden. De betekenis van de achtergrondkleur is als volgt:

• Groene packages zijn gedefinieerd door OGC (Open Geospatial Consortium).

• Gele packages zijn gedefinieerd door ISO/TC 211 (Geographic information/Geomatics).

• Blauwe packages zijn gedefinieerd door W3C (World Wide Web Consortium).

2.4.3.2. Mapping

De onderstaande tabel bevat de mapping van entiteiten en attributen in het GLD conceptueel model, via het WaterML conceptueel model naar de XML-complexTypes en XML-elementen in het WML-profiel. De tabel is gesorteerd op alfabetische volgorde van de Nederlandse naam van de entiteit/attribuut in de eerste kolom. De tweede kolom bevat de Engelstalige naam in een XML-document. Het laatste hoofdstuk van deze berichtencatalogus bevat de vertaaltabel in de omgekeerde richting. 

*¹: De modellering van het attribuut 'uitvoerder' en de bijbehorende Organisatiegegevens in het GLD conceptueel model is niet conform het WaterML conceptueel model. Hiervoor is een werkafspraak opgesteld (een 'issue' voor de beheerfase van de GLD standaard). Een correcte modellering kan worden bereikt door:

• Vervangen van het attribuut uitvoerder door het attribuut contact met als type VerantwoordelijkeOrganisatie. Het attribuut kan dan worden gemapt op het verplichte WaterML attribuut contact met als type CI_ResponsibleParty.

• Toevoegen van een parameter uitvoerder met als type Organisatie. Deze parameter kan dan worden opgenomen in de optionele WaterML NamedValue lijst parameter, met name = 'principalInvestigator' en het type Organization uit gldcommon.

Zie paragraaf 3.2.5 voor nadere informatie.

*²: De GLD gegevenscatalogus vermeldt dat WaterML niet een attribuut definieert voor enkele, gewenste attributen. In die gevallen is gebruik gemaakt van het ‘parameter’ mechanisme in WaterML. Iedere parameter is van het type NamedValue, wat bestaat uit de XML-elementen name (naam) en value (waarde). Zie de betreffende paragrafen in hoofdstuk 3 voor nadere informatie.

*³: De attributen 'status kwaliteitscontrole' en 'censuurlimietwaarde' worden gemapt op een XML-element qualifier in WaterML. Zie de betreffende paragrafen 3.2.15 en 3.2.16 voor nadere informatie.

2.4.3.3. Aanvullende regels

Deze paragraaf bevat aanvullende regels die deel uitmaken van het BRO profiel van WaterML. Enerzijds gaat het daarbij om regels over de XML-structuur van het brondocument. Anderzijds gaat het om regels over de inhoud van het brondocument.

Merk op dat de paragrafen 2.2 en 2.3 ook aanvullende regels bevatten, respectievelijk per brondocument en per request, naast de regels (IMBRO en IMBRO/A) in de gegevenscatalogus.

De onderstaande tabel bevat de aanvullende regels met betrekking tot de structuur van de gegevens. Niet voldoen aan deze regels kan worden vergeleken met het niet voldoen aan een XML Schema Definite (XSD). In voorkomende gevallen geeft de LV-BRO een ParseFault. De eerste en de tweede kolom bevatten de Engelse tags van het XML-ComplexType en het XML-element c.q. Tussen haakjes staat de Nederlandse naam van de entiteit en het attribuut uit de GLD gegevenscatalogus. De derde kolom bevat de parse structuurregel.

De onderstaande tabel bevat de aanvullende regels met betrekking tot de inhoud van de gegevens. Hierbij gaat het om regels met betrekking tot de aanwezigheid van een attribuut (optionaliteit, de afwezigheid of aanwezigheid van een waarde voor een attribuut (mogelijk geen waarde / voidable / nillable) of de waarde van een attribuut (domein). Deze regels kunnen worden vergeleken met de bedrijfsregels in de GLD gegevenscatalogus. De formulering volgt hetzelfde formaat als de bedrijfsregels in de gegevenscatalogus. In voorkomende gevallen geeft de LV-BRO een brondocumentfout. De eerste en de tweede kolom bevatten de Nederlandse naam van de entiteit en het attribuut uit de GLD gegevenscatalogus. Tussen haakjes staan de Engelse tags van het XML-ComplexType en het XML-element. De derde kolom bevat de bedrijfsregel.

3. Voorbeeldberichten

Dit hoofdstuk geeft een toelichting bij enkele voorbeeldberichten.

Paragraaf 3.1 bevat een opsomming van beschikbare voorbeeldberichten, hun intentie en een summiere beschrijving van de inhoud.

Paragraaf 3.2 bevat een gedetailleerde beschrijving van kleine, bijzondere stukken uit de voorbeeldberichten.

3.1. Integrale voorbeeldberichten

Integrale voorbeeld testberichten zijn te vinden via deze link: GLD inname voorbeeldberichten. De onderstaande tabel bevat een opsomming van beschikbare voorbeeldberichten, hun intentie en een summiere beschrijving van de inhoud.

3.2. Code snippets.

Deze paragraaf bevat voor een aantal kleine, bijzondere stukken XML-code uit de voorbeeldberichten een gedetailleerde beschrijving.

3.2.1. De kop van een registrationRequest

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). De laatste twee XML-attributen (xmlns:xsi en xsi:schemaLocation) maken het mogelijk om het BRO-verzoek te valideren tegen de XSD-bestanden van de GLD innameservice. Deze twee attributen mogen weggelaten worden.

Na de disclaimer en het commentaar met de beschrijving van de inhoud van het bericht volgen drie transactiegegevens: requestReference (verzoekkenmerk), deliveryAccountableParty (bronhouder), broId (BRO-ID) en qualityRegime (kwaliteitsregime). Zie hoofdstuk 2 voor nadere informatie.

Regel 26, 27 en 28 bevatten een optioneel element underPrivilege (onder voorrecht), wat echter niet is toegestaan bij GLD berichten.

Na de transactiegegevens volgt de opening tag van het sourceDocument (brondocument). Daarbinnen volgt het aan te bieden brondocument.

Het BRO-verzoek wordt afgesloten met de closing tags van het sourceDocument (brondocument) en het registrationRequest (registratieverzoek).

<registrationRequest
        xmlns="http://www.broservices.nl/xsd/isgld/1.0"
        xmlns:gldcom="http://www.broservices.nl/xsd/gldcommon/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/isgld/1.0 https://schema.broservices.nl/xsd/isgld/1.0/isgld-messages.xsd">
    <!-- Disclaimer: dit voorbeeldbericht valideert tegen de validatieservice van het demo-bronportaal, maar de gegevens zijn fictief en waarschijnlijk niet correct.
	Het voorbeeldbericht 10_GLD_StartRegistration.xml start de registratie van een grondwaterstandonderzoek.
    Na het aanleveren en doorleveren in het BROnhouderportaal wordt teruggemeld wat het BRO-ID van deze GMW is: GLD000000000153
	Dit BRO-ID is relevant voor vervolgberichten voor dit registratieobject.
    -->
	<!-- Het GLD wordt uitgevoerd in een monitoringbuis ten behoeve van 1 of meerdere doelen.
        GroundwaterMonitoringTube  (GMW-monitoringsbuis):       GMW000000016118, buis 1.
        GroundwaterMonitoringNet 1 (Grondwatermonitoringnetten):GMN000000000083, kaderrichtlijnWater, strategischBeheerKwantiteitRegionaal.
        GroundwaterMonitoringNet 1 (Grondwatermonitoringnetten):GMN000000000084, waterschapswet, strategischBeheerKwantiteitRegionaal.
    -->
    <brocom:requestReference>10_GLD_StartRegistration</brocom:requestReference>
    <!-- Optional: -->
    <brocom:deliveryAccountableParty>27376655</brocom:deliveryAccountableParty>
    <!-- Optional: maar niet toegestaan bij een GLD_StartRegistration brondocument
    <brocom:broId>GLD123456789012</brocom:broId>
    -->
    <brocom:qualityRegime>IMBRO</brocom:qualityRegime>
    <!-- Optional: maar niet toegestaan bij GLD
    <brocom:underPrivilege>ja</brocom:underPrivilege>
    -->
    <sourceDocument>
        ...
    </sourceDocument>
</registrationRequest>

3.2.2. Brondocument

Een BRO-verzoek bevat een brondocument, wat de eenheid van aanleveren is (zie paragraaf 2.2). Zoals beschreven in paragraaf 2.4 kent de GLD innamewebservice 4 types brondocumenten. De UML-diagrammen geven aan dat de brondocumenten het FeatureType als stereotype hebben. Conform de GML XML encoding rules wordt het property type pattern toegepast bij het omzetten van de gegevensdefinitie in UML naar de berichtdefinities in XML. Onderstaand stukje XML van een voorbeeldbericht laat zien hoe dat uitpakt. Na de opening tag sourceDocument van het brondocument volgt een regel met GLD_StartRegistration. Deze regel geeft aan dat in dit bericht het brondocument dit element als type heeft. Het element GLD_StartRegistration is als root element gedefinieerd in het XSD-bestand isgld-messages.xsd van de GLD innamewebservice. Na deze regel komt het eerste XML element van het type GLD_StartRegistrationType, wat het XML-type is van het root XML-element GLD_StartRegistration.

3.2.3. gml:id

De GLD gegevensdefinitie maakt een onderscheid tussen objecttypes en gegevensgroeptypes. Bij de opstellen van de berichtdefinities worden deze stereotypes vertaald naar FeatureType en AttributeGroupType. Beide kunnen in software omgezet worden naar classes. De verschillen zijn onder meer dat een FeatureType identificeerbaar is en dat een AttributeGroupType alleen bestaat bij de gratie van een FeatureType waarvan het, direct of indirect, een onderdeel is. Daartoe hebben beide attributen (attributes) of gegevensgroepen (attributeGroups).

Conform de GML XML encoding rules leidt ieder FeatureType in de XSD-bestanden tot:

• Een ComplexType, wat de inhoud van het FeatureType definieert en een specialisatie is van gml:AbstractFeatureType.

• Een root element, zodat objecten geïnstantieerd kunnen worden van het ComplexType.

• Een propertyType ComplexType, zodat in een XML-document:

  • Een attribuut met dit FeatureType als type ofwel de inhoud van het FeatureType kan bevatten (by-value) ofwel een verwijzing naar een feature (object) van dit type (by-reference).

  • Het type van het element kan worden vervangen door een specialisatie van het FeatureType, waarvan het bijbehorende root-element in het XSD-bestand een substitutionGroup heeft die direct of indirect herleidt naar het root element van dit FeatureType (polymorfisme).

Als gevolg van de eerste bullet krijgt ieder betreffend XML-element een XML-attribuut gml:id. De waarde van deze gml:id moet uniek zijn binnen het BRO-verzoek. In de voorbeeldberichten is dit gedaan met een waarde die begint met 'id_', gevolgd door een volgnummer. Het BRO-systeem slaat de waarden van deze gml:id niet op.

Uitzondering zijn de gml:id's van de XML-elementen, die in de GLD gegevenscatalogus expliciet zijn voorzien van een 'ID' attribuut: observatie ID, observatieproces ID en tijdmeetwaardereeks ID. Deze hebben in de voorbeeldberichten een waarde die begint met een '_'. Het BRO-systeem slaat de waarden van deze gml:id's wel op. Gevolg is dat de waarden van deze gml:id's uniek moeten zijn binnen een GLD registratieobject en dat een BRO-verzoek mag verwijzen naar een gml:id die in een eerder BRO-verzoek is aangeleverd. In de voorbeeldberichten is aan deze eis voldaan door gebruik te maken van een GUID-generator. De laatste regel in onderstaande voorbeelden bevat een verwijzing naar een gml:id die niet voorkomt in hetzelfde BRO-verzoek.

3.2.4. DateStamp

Het attribuut dateStamp (datum metadata) heeft als type een gco:Date_Type. In de GLD gegevenscatalogus het dit attribuut als type een Datum onder kwaliteitsregime IMBRO en een OnvolledigeDatum onder IMBRO/A. Onderstaande voorbeelden geven mogelijke waarden met afnemende nauwkeurigheid.

3.2.5. Uitvoerder van een observatie.

Volgens de GLD gegevenscatalogus worden van de uitvoerder van een observatie twee attributen geregistreerd: organisatienaam en identificatie. Volgens een werkafspraak moet de naam leeg zijn.

De identificatie van een organisatie is een keuze tussen een KvK-nummer of een Europees handelsnummer. Stel dat de uitvoerder een Nederlandse onderneming is met 27376655 als KvK-nummer. Dan ziet de betreffende XML-code er als volgt uit:

<om:metadata>
    <wml2:ObservationMetadata>
        <gmd:contact>
            <gmd:CI_ResponsibleParty>
                <gmd:organisationName>
                    <!-- vaste waarde; lege string voor de naam van de organisatie. -->
                    <gco:CharacterString/>
                </gmd:organisationName>
                <gmd:role>
                    <!-- vaste waarde; geeft aan dat de contactgegevens de uitvoerder betreffen. -->
                    <gmd:CI_RoleCode codeList="urn:ISO:19115:CI_RoleCode" codeListValue="principalInvestigator">principalInvestigator</gmd:CI_RoleCode>
                </gmd:role>
            </gmd:CI_ResponsibleParty>
        </gmd:contact>
        ...
        <wml2:parameter>
            <om:NamedValue>
                <!-- vaste waarde; geeft aan dat deze namedValue de uitvoerder bevat -->
                <om:name xlink:href="urn:bro:gld:ObservationMetadata:principalInvestigator"/>
                <om:value xsi:type="gldcom:OrganizationType">
                    <gldcom:chamberOfCommerceNumber>27376655</gldcom:chamberOfCommerceNumber>
                </om:value>
            </om:NamedValue>
        </wml2:parameter>
        ...
    </wml2:ObservationMetadata>
</om:metadata>

Als het gaat om een buitenlandse onderneming met DEB8537.HRB66039 als Europees handelsnummer, dan ziet de betreffende XML-code er als volgt uit:

<om:metadata>
    <wml2:ObservationMetadata>
        <gmd:contact>
            <gmd:CI_ResponsibleParty>
                <gmd:organisationName>
                    <!-- vaste waarde; lege string voor de naam van de organisatie. -->
                    <gco:CharacterString/>
                </gmd:organisationName>
                <gmd:role>
                    <!-- vaste waarde; geeft aan dat de contactgegevens de uitvoerder betreffen. -->
                    <gmd:CI_RoleCode codeList="urn:ISO:19115:CI_RoleCode" codeListValue="principalInvestigator">principalInvestigator</gmd:CI_RoleCode>
                </gmd:role>
            </gmd:CI_ResponsibleParty>
        </gmd:contact>
        ...
        <wml2:parameter>
            <om:NamedValue>
                <!-- vaste waarde; geeft aan dat deze namedValue de uitvoerder bevat -->
                <om:name xlink:href="urn:bro:gld:ObservationMetadata:principalInvestigator"/>
                <om:value xsi:type="gldcom:OrganizationType">
                    <gldcom:europeanCompanyRegistrationNumber>DEB8537.HRB66039</gldcom:europeanCompanyRegistrationNumber>
                </om:value>
            </om:NamedValue>
        </wml2:parameter>
        ...
    </wml2:ObservationMetadata>
</om:metadata>

Volgens de gegevenscatalogus, paragraaf 5.3.7.1, mag onder het kwaliteitsregime IMBRO/A de waarde van het attribuut identificatie (van de organisatiegegevens van de uitvoerder) ontbreken. In dat geval ziet de betreffende XML-code er als volgt uit:

<om:metadata>
    <wml2:ObservationMetadata>
        <gmd:contact>
            <gmd:CI_ResponsibleParty>
                <gmd:organisationName>
                    <!-- vaste waarde; lege string voor de naam van de organisatie. -->
                    <gco:CharacterString/>
                </gmd:organisationName>
                <gmd:role>
                    <!-- vaste waarde; geeft aan dat de contactgegevens de uitvoerder betreffen. -->
                    <gmd:CI_RoleCode codeList="urn:ISO:19115:CI_RoleCode" codeListValue="principalInvestigator">principalInvestigator</gmd:CI_RoleCode>
                </gmd:role>
            </gmd:CI_ResponsibleParty>
        </gmd:contact>
        ...
        <wml2:parameter>
            <om:NamedValue>
                <!-- vaste waarde; geeft aan dat deze namedValue de uitvoerder bevat -->
                <om:name xlink:href="urn:bro:gld:ObservationMetadata:principalInvestigator"/>
                <!-- leeg element geeft aan dat de waarde van de identificatie van de uitvoerder afwezig is. -->
                <om:value xsi:type="gldcom:OrganizationType"/>
            </om:NamedValue>
        </wml2:parameter>
        ...
    </wml2:ObservationMetadata>
</om:metadata>

3.2.6. Observatietype

Volgens de GLD gegevenscatalogus heeft het attribuut observatietype het type Observatietype, een uitbreidbare waardelijst. Binnen het ComplexType ObservationMetadata van WaterML is hiervoor geen geschikt attribuut gedefinieerd. Daarom is het attribuut gemapt op een parameter van het type NamedValue. Het XML-element name bevat in dit geval een vaste waarde, die uniek het attribuut aanduidt. NB: let op de kleine letter o in het woord observationType. Het XML-element value heeft een waarde en 2 XML-attributen. De waarde komt uit de GLD gegevenscatalogus. De beide XML-attributen hebben een vaste waarde. NB: let op de hoofdletter O in het woord ObservationType.

3.2.7. Gerelateerd aan

In de GLD gegevenscatalogus heeft een Observatie een optionele lijst van gerelateerde observaties. Bij een observatie met een volledig beoordeelde tijdmeetwaardereeks kan, indien aanwezig, hier geregistreerd worden op welke observaties met een controlemeting en/of observaties met een voorlopige tijdmeetwaardereeks de beoordeling is gebaseerd.

Deze gerelateerde observaties zitten in hetzelfde brondocument of zijn geregistreerd met een eerder aangeboden brondocument. In beide gevallen hebben de gerelateerde observaties een gml:id als unieke identificatie. De relatie bestaat uit een xlink:href XML-attribuut met als waarde de waarde van de betreffende gerelateerde observatie. De rest van onderstaande code bestaat uit vaste tekst en vaste waarden.

3.2.8. PhenomenonTime

Het attribuut phenomenonTime (observatieperiode) bestaat uit een periode, aangegeven door een beginPosition (begindatum) en een endPosition (einddatum). Beide attributen hebben als type een gml:TimePositionType. Dit datatype ondersteunt een variabele nauwkeurigheid. Binnen de phenomenonTime (observatieperiode) gebruiken we alleen waarden die bestaan uit een volledige datum. De waarde voor beginPosition (begindatum) komt overeen met het datumdeel van de oudste waarde van het XML-element wml2:time in de MeasurementTimeseries (Tijdmeetwaardereeks) van het om:result. De waarde voor endPosition (einddatum) komt overeen met het datumdeel van de jongste waarde van het XML-element wml2:time in de MeasurementTimeseries (Tijdmeetwaardereeks) van het om:result. 

3.2.9. ResultTime.

Volgens de GLD gegevenscatalogus heeft het attribuut resultTime (tijdstip resultaat) het type DatumTijd onder IMBRO en het type OnvolledigeDatum onder IMBRO/A. Daarmee bestaat de nauwkeurigheid van dit attribuut uit:

• volledige datum en tijd

• volledige datum

• jaar en maand

• jaartal

• 'onbekend'

Dit attribuut is gemapt op het XML-element om:resultTime uit Observations and Measurements, wat een gml:TimeInstantPropertyType als type heeft wat op zijn beurt een gml:TimePositionType is. Conform de GML specificaties moet een lokale tijd aangevuld worden met een tijdzone. Als alternatief kan een lokale tijd worden omgezet naar UTC (Universal Time Coordinated, voorheen Greenwich Mean Time) en daarna aangevuld met een hoofdletter Z (Zulu). Nederland heeft als tijdzone +1 uur tijdens wintertijd en +2 uur tijdens zomertijd. Onderstaande XML-code zijn voorbeelden voor bovenstaande nauwkeurigheden. De eerste twee voorbeelden geven dezelfde datum en tijd weer:

3.2.10. ProcessType

Het binnen WaterML verplichte attribuut processType (procestype) heeft binnen GLD een vaste waarde:

3.2.11. ProcessReference

De processReference (meetprocedure) heeft als type een codelijst. Conform de WaterML specificaties wordt dit niet gecodeerd als een gml:CodeWithAuthorityType, maar wordt de waarde opgenomen in een xlink:href XML-attribuut. De waarde van dit attribuut begint met de URN van de codelijst (urn:bro:gld:ProcessReference) gevolgd door een dubbele punt (:) en dan de gekozen waarde uit de codelijst. Zie onderstaande voorbeeld:

3.2.12. ObservationType

Voor het attribuut observationType (observatietype) definieert WaterML geen geschikt attribuut. Daarom is dit attribuut gemapt op een NamedValue parameter. Zie onderstaande voorbeeld. Het XML-element om:name geeft in het XML-attribuut xlink:href aan om welk attribuut het gaat. Het XML-element om:value bevat de waarde uit de codelijst, gecodeerd als een gml:CodeWithAuthorityType, waarbij het XML-attribuut codeSpace de URN van de codelijst bevat.

3.2.13. EvaluationProcedure

Voor het attribuut evaluationProcedure  (beoordelingsprocedure) geldt hetzelfde als voor het attribuut observationType (observatietype).

3.2.14. AirPressureCompensationType

Voor het attribuut  airPressureCompensationType  (type luchtdrukcompensatie) geldt hetzelfde als voor het attribuut observationType (observatietype).

3.2.15. MeasurementInstrumentType

Voor het attribuut measurementInstrumentType  (type meetinstrument) geldt hetzelfde als voor het attribuut observationType (observatietype).

3.2.16. StatusQualityControl

Voor het attribuut statusQualityControl (statusKwaliteitscontrole) definieert WaterML geen geschikt attribuut. Daarom is dit attribuut gemapt op een Category qualifier. Zie onderstaande voorbeeld. Het XML-element swe:codeSpace bevat de URN van de codelijst. Het XML-element swe:value bevat de waarde uit de codelijst.

3.2.17. CensoringLimitvalue

Voor het attribuut censoringLimitvalue (censuurlimietwaarde) definieert WaterML geen geschikt attribuut. Daarom is dit attribuut gemapt op een Q uantity qualifier. Zie onderstaande voorbeeld. Het XML-attribuut definition van het XMLelement swe:Quantity bevat de unieke identificatie van het attribuut, gecodeerd als een URN. Het XML-attribuut code van het XML-element swe:uom bevat de vaste waarde 'm' (meter) als eenheid voor de censuurlimietwaarde. Het XML-element swe:value bevat de waarde van de censuurlimietwaarde.

Onder IMBRO/A kan het zijn dat de limitewaarde niet bekend is. Volgens de GLD gegevenscatalogus mag dan de waarde ontbreken. In de sweQuantifier is het XML-element value niet nillable, maar wel optioneel. Daarom wordt de regel 'het attribuut heeft geen waarde' uit de GLD gegevenscatalogus in een XML-bericht als volgt omgezet (merk op dat het XML-element swe:uom wel aanwezig is):

3.2.18. InterpolationType

Het binnen WaterML verplichte attribuut interpolationType (Interpolatietype) heeft binnen GLD een vaste waarde:

3.2.19. CensoredReason

Het attribuut censoredReason (censuurreden) heeft als type een codelijst. Conform de WaterML specificaties wordt dit niet gecodeerd als een gml:CodeWithAuthorityType, maar wordt de waarde opgenomen in een XML-attribuut xlink:href. Zie onderstaande tabel voor de mapping van toegestane waarde in ge GLD gegevenscatalogus en de waarde voor het XML-attribuut xlink:href en het onderstaande XML voorbeeld:

4. 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 grondwaterstandonderzoek. 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.

5. Codelijsten

Binnen GLD volgen de meeste codelijsten het patroon zoals algemeen toegepast binnen de BRO en beschreven in Codelist (Codelijst). Dat zijn de codeljisten in de onderstaande tabel .

• 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 URI, die in een BRO-verzoek gebruikt moet worden bij het XML-attribuut codeSpace . Zie Codelist (Codelijst). en de voorbeeldberichten voor nadere informatie.

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

De GLD catalogus definieert voor de codelijsten Censuurreden, Interpolatietype en Procestype Nederlandse toegestane waarden. De betreffende codelijsten in WaterML definiëren Engelse toegestane waarden. De onderstaande tabel geeft een vertaling van de Engelstalige toegestane waarde in de XSD-bestanden naar de Nederlandse toegestane waarde in de gegevenscatalogus. Zie ook paragraaf 2.4.3.3. Aanvullende regels.

Binnen GLD worden 6 codelijsten uit de internationale standaard voor WaterML gebruikt, die niet het bovenstaande patroon volgen. Deze staan in de onderstaande tabel. De derde kolom verwijst naar de paragraaf in dit document met nadere informatie.

6. Vertaallijst

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

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