Skip to main content
Skip table of contents

GLD Berichtencatalogus uitgiftewebservice


Inleiding

Dit document beschrijft hoe een afnemer van de Basisregistratie Ondergrond (BRO) de gegevens over een grondwaterstandonderzoek (GLD) kan opvragen.

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

Leeswijzer

Hoofdstuk 2 beschrijft de algemene werking van de GLD uitgiftewebservice.

Hoofdstuk 3 bevat een toelichting op enkele voorbeeldberichten.

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

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

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

Versiehistorie

Versie

Datum

Omschrijving

0.308-04-2020Eerste versie.
0.401-05-2020Increment 3: conform catalogus 0.99 exclusief correcties.
0.512-05-2020Review commentaar verwerkt.
1.118-12-2020Releasedatum registratieobject en publicatie document
1.1.123-12-2020Verwijzing naar (test-)voorbeeldberichten op BRO productomgeving
1.1.216-02-2021URLs naar codelijsten aangepast


Open issues

NrParagraafOmschrijving
12.4Resultaten discussie over correcties en geschiedenis verwerken.


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.

Algemene werking van de GLD uitgiftewebservice

Dit hoofdstuk beschrijft de algemene werking van de GLD uitgiftewebservice.

Paragraaf 2.1 bevat een inleiding tot de GLD uitgiftewebservice

Paragraaf 2.2 beschrijft de operaties die de GLD uitgiftewebservice ondersteunt.

Paragraaf 2.2 beschrijft de BRO-berichten die een rol spelen bij die operaties.

Paragraaf 2.3 beschrijft de verschillende uitgiftedocumenten die in een BRO-bericht uitgegeven kunnen worden. 

Inleiding

Met de GLD uitgiftewebservice kunnen de gegevens van een bepaald object worden opgevraagd. Het kan daarbij gaan om de actuele toestand of om alle gegevens van het object inclusief zijn geschiedenis.

De uitgifte van GLD kengegevens is buiten scope, omdat de coördinaten een verplicht deel uitmaken van kengegevens, terwijl een GLD zelf geen geometrische gegevens bevat. De geometrie komt beschikbaar is als we cross-RO en/of binnen de scope van een domein in plaats van binnen de scope van een enkel registratieobjecttype gaan werken. Een besluit dienaangaande wordt later gemaakt op initiatief van de BRO keten. De scope van dit document gaat niet verder dan alleen GLD. 

Een GLD kan jaren actief blijven en aangevuld worden. Wanneer de meetfrequentie hoog is, kan een GLD in de loop van de tijd zeer veel metingen bevatten. Een gebruiker is niet altijd geïnteresseerd in al die metingen en zal willen filteren op:

  • Alleen observaties uit een bepaalde periode.
  • Alleen observaties waarbij het attribuut mate beoordeling gelijk is aan 'volledigBeoodeeld'. Dit omdat er een hiërarchie van de juridische gebruiksplicht is namelijk: gebruik volledig beoordeelde gegevens en indien deze er (nog) niet zijn voorlopige gegevens.

Beide filters leiden niet tot een andere inhoud van het uitgiftedocument, dezelfde gegevens worden uitgegeven (alle entiteiten en attributen). Alleen wordt op een van de attributen eerst een filter toegepast.

Operaties

De GLD uitgiftewebservice wordt gerealiseerd als een SOAP-webservice.

De GLD uitgiftewebservice ondersteunt één soap operatie: dispatchData (uitgifte van objectgegevens).

Een soap operatie heeft een request en een response. Het DispatchDataRequest bevat het uitgifteverzoek tot het leveren van alle geregistreerde gegevens van een bepaald registratieobject. De response bevat het antwoord op het verzoek. Naast een antwoord kan de reactie op een uitgifteverzoek ook een foutmelding zijn. Er zijn dus drie mogelijke reacties:

  • DispatchDataResponse (Antwoord): een functioneel antwoord op een uitgifteverzoek.
  • SOAP:Fault (Systeemfout): als er tijdens de verwerking van het request een onverwachte fout optreedt in het BRO-systeem, dan leidt dit tot een SOAP:Fault.
  • ParseFault (Validatiefout): als de GLD uitgiftewebservice constateert dat een DispatchDataRequest niet een welgevormd XML-bericht is of dat het niet voldoet aan de schema validatie, dan leidt dit tot een ParseFault.

BRO-berichten

Deze paragraaf beschrijft de vier verschillende BRO-berichten die een rol spelen in de GLD uitgiftewebservice.

DispatchDataRequest

Het BRO-bericht DispatchDataRequest bevat het uitgifteverzoek tot het leveren van de in het BRO-register opgenomen gegevens van een bepaald registratieobject. Daarbij wordt het registratieobject geïdentificeerd door zijn BRO-ID.


De DispatchDataRequest (Verzoek tot uitgifte van gegevens) van de GLD uitgiftewebservice is een specialisatie van DispatchRequest in de package brocommon, waaraan het twee optionele attributen toevoegt.

Dit BRO-bericht bestaat uit vier transactiegegevens. De definities van de transactiegegevens staan in onderstaande tabel:

Naam in XML-bestand

Nederlandse naam

Type

Kardinaliteit

Definitie

requestReference verzoekkenmerkCharacterString1..1Een voor de afnemer unieke aanduiding van het uitgifteverzoek.
broIdBRO-IDRegistrationObjectCode1..1

De unieke aanduiding van het registratieobject in de Basisregistratie Ondergrond.

Toelichting:
De registratieobjectcode van een grondwaterstandonderzoek bestaat uit de drie (hoofd)letters GLD, gevolgd door een code van 12 cijfers, dus inclusief eventuele voorloopnullen. Voorbeeld: GLD000000123456.

observationPeriodperiode van monitoringDatePeriod0..1

Het datuminterval waarbinnen de observatieperiode van een observatie geheel of gedeeltelijk ligt.

Regels:
Het aantal meetwaardeparen in het antwoord wordt beperkt tot maximaal 2500 als het gegeven observationPeriod (periode van monitoring) niet aanwezig is.

Toelichting:
Een Grondwaterstandonderzoek kan meerdere observaties bevatten, die ieder, onder anderen, een observatieperiode en een tijdmeetwaardereeks van tijdmeetwaardeparen hebben. Zo'n observatie wordt in haar geheel opgenomen in het uitgiftedocument als observatieperiode van de observatie geheel of gedeeltelijk valt binnen de periode van monitoring in het uitgifteverzoek, tenzij dit wordt verhinderd door andere filter gegevens in het uitgifteverzoek.

filteredgefilterdIndicationYesNo0..1

Aanduiding of de te leveren gegevens gefilterd moeten worden volgens de juridische gebruiksplicht of niet.

Toelichting:
Er worden in het grondwaterstandonderzoek volledig beoordeelde gegevens vastgelegd, voorlopige gegevens en gegevens over controlemetingen. Een volledig beoordeelde meetwaarde heeft alle in het beoordelingsprocedure vermelde controles ondergaan en is daardoor, in samenhang met het attribuut status kwaliteitscontrole, betrouwbaarder dan een voorlopige meetwaarde die geen of niet alle controles heeft ondergaan. Als het gegeven gefilterd de waarde ja heeft, dan worden de geleverde gegevens beperkt conform de hiërarchie van de juridische gebruiksplicht. Dat wil zeggen, indien geregistreerd worden de volledig beoordeelde gegevens uitgeleverd, zo niet de voorlopige gegevens en anders de ruwe meetgegevens (maken nu geen deel uit van de basisregistratie ondergrond), tenzij dit wordt verhinderd door andere filter gegevens in het uitgifteverzoek. Als het gegeven gefilterd de waarde nee heeft, dan worden alle geregistreerde gegevens uitgeleverd, tenzij dit wordt verhinderd door andere filter gegevens in het uitgifteverzoek.


SOAP:Fault

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


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

Naam in XML-bestand

Nederlandse naam

Type

Kardinaliteit

Definitie

faultcode foutcodeCharacterString1..1

Aanduiding waar de fout is opgetreden.

Toelichting:
Vaste waarde “soap:Server”.

faultstringfouttekstCharacterString1..1

Summiere beschrijving van de fout.

Toelichting:
Vaste waarde “Er is een fout in het BRO-systeem geconstateerd”.

detaildetailsAny0..1

Aanvullende informatie over de opgetreden fout en de vermoedelijke oorzaak.

Toelichting:
Het gegeven kan een simpele waarde (b.v. tekst) hebben of een samengestelde waarde (b.v. ParseFault).


ParseFault

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

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


Dit BRO-bericht begint met een SOAP:Fault (Systeemfout), bestaande uit drie gegevens. De definities van deze gegevens staan in onderstaande tabel:

Naam in XML-bestand

Nederlandse naam

Type

Kardinaliteit

Definitie

faultcode foutcodeCharacterString1..1

Aanduiding waar de fout is opgetreden.

Toelichting:
Vaste waarde “soap:Client”.

faultstringfouttekstCharacterString1..1

Summiere beschrijving van de fout.

Toelichting:
Vaste waarde “Het verzoek voldoet niet aan het schema”.

detaildetailsParseFault0..1

Aanvullende informatie over de opgetreden fout en de vermoedelijke oorzaak.

Regel:
Het gegeven is aanwezig bij een softwarefout. Het type van het gegeven is ParseFault (Validatiefout).


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

Naam in XML-bestand

Nederlandse naam

Type

Kardinaliteit

Definitie

requestReferenceverzoekkenmerkCharacterString0..1

Een voor de dataleverancier unieke aanduiding van het uitgifteverzoek.

Toelichting:
Waarde overgenomen uit het request. Dit gegeven is optioneel omdat de softwarefout geconstateerd kan worden voordat het BRO-systeem het uitgifteverzoek heeft kunnen lezen.

transactionIdtransactiecodeCharacterString0..1

Een voor het BRO-systeem unieke aanduiding voor de verwerking van een innameverzoek of uitgifteverzoek.

Toelichting:
Waarde toegekend door het transactieregister. Dit gegeven is optioneel omdat de softwarefout geconstateerd kan worden voordat het BRO-systeem een transactie heeft kunnen aanmaken.

abortTimemoment van afbrekenDateTime1..1Tijdstip, toegekend door de webservice, waarop de verwerking van het uitgifteverzoek is afgebroken.
abortReasonreden afbrekenAbortReason1..*

Lijst met redenen waarom de verwerking van het uitgifteverzoek is afgebroken.

Toelichting:
Om praktische redenen wordt de lijst beperkt tot maximaal 99 redenen.


De lijst met abortReasons (redenen afbreken) bestaat uit minimaal 1 en maximaal 99 voorkomens van een AbortReason (Reden afbreken). Iedere AbortReason (Reden afbreken) bestaat uit twee gegevens. De definities staan in onderstaande tabel:

Naam in XML-bestand

Nederlandse naam

Type

Kardinaliteit

Definitie

sequenceNumbervolgnummerInteger1..1

Een binnen deze lijst van abortReasons (redenen afbreken) uniek nummer.

Toelichting:
Numerieke waarde bedoelt om de lijst met foutmeldingen te kunnen sorteren.

specificationfoutmeldingCharacterString1..1Omschrijving van de validatie fout.


DispatchDataResponse

Het BRO-bericht DispatchDataResponse (Antwoord) bevat het functionele antwoord op een uitgifteverzoek. De DispatchDataResponse (Antwoord) van de GLD uitgiftewebservice is een specialisatie van DispatchResponse in de package brocommon, waaraan het een dispatchDocument (uitgiftedocument) toevoegt. De DispatchResponse in brocommon definieert een aantal gegevens en een optionele lijst met criterionErrors (kenmerkfouten).


Het BRO-bericht DispatchDataResponse (Antwoord) kan twee betekenissen hebben:

  • Een bericht van afwijzing.
  • Een bericht van verzending van objectgegevens.

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

GegevenAfwijzingVerzending
responseType
requestReference
rejectionTime
dispatchTime
rejectionReason
criterionError

dispatchDocument


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

Naam in XML-bestand

Nederlandse naam

Type

Kardinaliteit

Definitie

responseTypetype antwoordResponseType1..1Aanduiding van de betekenis van het antwoord.
requestReference verzoekkenmerkCharacterString1..1

Een voor de afnemer unieke aanduiding van het uitgifteverzoek.

Toelichting:
Waarde overgenomen uit het request.

rejectionTime tijdstip van afwijzingDateTime0..1

Tijdstip, toegekend door de webservice, waarop het uitgifteverzoek is afgewezen.

Regels:
Dit gegeven is alleen aanwezig als het gegeven responseType de waarde 'rejection' heeft.

dispatchTime tijdstip van uitgifteDateTime0..1

Tijdstip, toegekend door de webservice, waarop de opgevraagde gegevens zijn verzonden.

Regels:
Dit gegeven is alleen aanwezig als het gegeven responseType de waarde 'dispatch' heeft.

rejectionReason reden afwijzingCharacterString0..1

De reden waarom het uitgifteverzoek is afgewezen.

Regels:
Dit gegeven is alleen aanwezig als het gegeven responseType de waarde 'rejection' heeft.

criterionError kenmerkfoutCriterionError 0..*

Lijst met foutmeldingen met betrekking tot een geconstateerde fout in de kenmerkenverzameling van een uitgifteverzoek, bestaande uit een volgnummer en een omschrijving.

Regels:
Dit gegeven is alleen aanwezig als het gegeven responseType de waarde 'rejection' heeft.

Toelichting:
De GLD uitgiftewebservice gebruikt deze lijst niet.

dispatchDocumentuitgiftedocumentAbstractRegistrationObject0..1

Dit element bevat de gegevens van het opgevraagde registratieobject, die in het BRO-systeem geregistreerd zijn.

Regels:
Dit gegeven is alleen aanwezig als het gegeven responseType de waarde 'dispatch' heeft.


Uitgiftedocumenten

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

De GLD uitgiftewebservice kent drie types uitgiftedocumenten; zie onderstaande tabel. Welke type wordt uitgeleverd hangt af van de identiteit van de afnemer en van de registratiestatus van het registratieobject. Uitgiftedocument GLD_O_DP bevat alle gegevens uit de catalogus.

UitgiftedocumentWordt uitgeleverd als:

AfnemerRegistratieobject
BRO_DOIs niet de bronhouder en/of dataleverancier.Uit registratie genomen.
GLD_OIs niet de bronhouder en/of dataleverancier.Niet uit registratie genomen.
GLD_O_DPIs tevens de bronhouder en/of dataleverancier.Ongeacht.


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


Gegevens met een minteken voor hun naam (in plaats van een plusteken) worden alleen uitgeleverd als de afnemer tevens bronhouder en/of dataleverancier is van het opgevraagde registratieobject. Met andere woorden, deze gegevens worden opgenomen in het dispatchDocument (uitgiftedocument) GLD_O_DP.

Gegevens met een deelteken voor hun naam worden niet aangeboden in een brondocument bij de innamewebservice. In plaats daarvan wordt een waarde voor deze gegevens afgeleid door het BRO-systeem.

Gegevens met de tekst id tussen accolades achter hun naam zijn gegevens die een object (een voorkomen van het FeatureType (Objecttype)) uniek identificeren.

Onderstaande figuur geeft de structuur weer van de individuele items in de lijst met observations (groene achtergrond). Deze is volledig gebaseerd op de OpenGis standaarden WaterML (WML2), Observations & Measurements (OM), Geographic MetaData (GMD), Geographic COmmon (GCO) en de OGC standaard Geography Markup Language (GML).


Alle gegevens zijn gedefinieerd in de GLD catalogus.:

BRO_DO

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

  • broId (BRO-ID).
  • deregistered (uit registratie genomen).
  • deregistrationTime (tijdstip uit registratie genomen).

GLD_O_DP

Het uitgiftedocument van het type GLD_O_DP is een specialisatie van GLD_O. Dit uitgiftedocument bevat alle gegevens uit de GLD catalogus.

GLD_O

Het uitgiftedocument van het type GLD_PO is een specialisatie van RegistrationObject, wat op zijn beurt een specialisatie is van AbstractRegistrationObject in de package brocommon. Dit uitgiftedocument bevat dezelfde gegevens als uitgiftedocument GLD_O_DP, met uitzondering van de volgende gegevens (die ontbreken in GLD_O):

  • objectIdAccountableParty (object-ID bronhouder).
  • deliveryResponsibleParty (dataleverancier).
  • contact (uitvoerder), dat wil zeggen:
    • parameterPrincipalInvestigator (identificatie).
    • contactOrganisationName (organisatienaam).

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.

Integrale voorbeeldberichten

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

NaamDoel en inhoud
DO_Request.xmlVerzoek tot het leveren van alle geregistreerde gegevens van een bepaald registratieobject.
SoapFault.xmlSysteemfout als reactie op een uitgifteverzoek met een syntactische fout.
ParseFault.xmlValidatiefout als reactie op een uitgifteverzoek waarvan de inhoud niet voldoet aan de XML-schemadefinities.
DO_Response_Rejection.xmlBericht van afwijzing.
DO_Response_BRO_DO.xmlBericht van verzending van objectgegevens van een registratieobject dat uit registratie is genomen, terwijl de afnemer niet de bronhouder nog de dataleverancier is van het uitgegeven registratieobject.
DO_ResponseGLD_DO.xmlBericht van verzending van objectgegevens van een registratieobject dat niet uit registratie is genomen, terwijl de afnemer niet de bronhouder nog de dataleverancier is van het uitgegeven registratieobject.
DO_ResponseGLD_DO_DP.xmlBericht van verzending van objectgegevens van een registratieobject, terwijl de afnemer tevens de bronhouder en/of dataleverancier (Data Provider) is van het uitgegeven registratieobject.


Code snippets.

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

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 14 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. In het voorbeeldbericht heeft de URL van de schemalocation van de isgld namespace de waarde ../../XSD/isgld-messages.xsd. Dit is een relatief pad naar een lokaal bestand, met een mappenstructuur alsof de GitHub GLD repo is gecloned naar een lokale repo. Deze waarde is met name bedoeld in de projectfase voordat de GLD innameservice beschikbaar is. De laatste regel van de disclaimer bevat de waarde voor de schemalocation zoals die in de productiefase opgenomen zal worden. Vanaf dat moment kunnen de XSD-bestanden vanaf die URL gedownload worden.

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

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

CODE
<?xml version="1.0" encoding="UTF-8"?>
<registrationRequest
        xmlns="http://www.broservices.nl/xsd/isgld/1.0"
        xmlns:gldcom="http://www.broservices.nl/xsd/gldcommon/1.0"
        xmlns:wml2="http://www.opengis.net/waterml/2.0"
        xmlns:gmd="http://www.isotc211.org/2005/gmd"
        xmlns:gco="http://www.isotc211.org/2005/gco"
        xmlns:om="http://www.opengis.net/om/2.0"
        xmlns:swe="http://www.opengis.net/swe/2.0"
        xmlns:brocom="http://www.broservices.nl/xsd/brocommon/3.0"
        xmlns:gml="http://www.opengis.net/gml/3.2"
        xmlns:xlink="http://www.w3.org/1999/xlink"
        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 XSD van de innameservice.
       Het is niet gevalideerd door de innameservice en is vaktechnisch/inhoudelijk niet voorbeeldig.
  -->
  <brocom:requestReference>BRO-GLD-1596</brocom:requestReference>
  <!-- Optional: -->
  <brocom:deliveryAccountableParty>27376655</brocom:deliveryAccountableParty>
  <!--Optional: -->
  <brocom:broId>GLD123456789012</brocom:broId>
  <brocom:qualityRegime>IMBRO</brocom:qualityRegime>
  <sourceDocument>
    ...
  </sourceDocument>
</registrationRequest>


SourceDocument

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

...
<sourceDocument>
  <GLD_StartRegistration gml:id="id_0001">
    <!-- optional -->
    <objectIdAccountableParty>myIdForThisLevelDossier_102989</objectIdAccountableParty>
    ...
  </GLD_StartRegistration>
</sourceDocument>
...

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 gegevens (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 gegeven met dit FeatureType als type ofwel de inhoud van het FeatureType kan bevatten (in-line) 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' gegeven: 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.

...
<GLD_StartRegistration gml:id="id_0001">
...
<gldcom:GroundwaterMonitoringNet gml:id="id_0002">
...
<gldcom:GroundwaterMonitoringTube gml:id="id_0004">
...
<gml:TimePeriod gml:id="id_0005">
...
<om:OM_Observation gml:id="_09722017-d5be-4d47-b966-4dda6abfa02b">
...
<wml2:ObservationProcess gml:id="_e1821667-0704-47c0-ade5-5fda651f0895">
...
<wml2:MeasurementTimeseries gml:id="_53387174-d17e-4aeb-90c2-13c50c4b83a9">
...
<om:relatedObservation xlink:href="_09722017-d5be-4d47-b966-4dda6abfa02b"/>
...
<om:procedure xlink:href="_e1821667-0704-47c0-ade5-5fda651f0895"/>
...

DateStamp

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

<gmd:dateStamp>
  <gco:Date>2018-01-28</gco:Date>
</gmd:dateStamp>
<gmd:dateStamp>
  <gco:Date>2018-01</gco:Date>
</gmd:dateStamp>
<gmd:dateStamp>
  <gco:Date>2018</gco:Date>
</gmd:dateStamp>
<gmd:dateStamp gco:nilReason="unknown"/>

Uitvoerder van een observatie.

Volgens de GLD gegevenscatalogus worden van de uitvoerder van een observatie twee gegevens geregistreerd: organisatienaam en identificatie. Daarbij is het type van de identificatie een Organisatie, wat een keuze is tussen een kamer van KvK-nummer of een Europees handelsnummer. Stel dat de uitvoerder 'Meten is ons vak' heet en dat het gaat om een Nederlandse onderneming 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>
          <!-- empty string represents void value -->
          <!-- gco:CharacterString/ -->
          <gco:CharacterString>Meten is ons vak</gco:CharacterString>
        </gmd:organisationName>
        <gmd:role>
          <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>
        <om:name xlink:href="urn:bro:gld:ObservationMetadata:principalInvestigator"/>
        <om:value xsi:type="brocom:OrganizationType">
          <brocom:chamberOfCommerceNumber>27376655</brocom:chamberOfCommerceNumber>
        </om:value>
      </om:NamedValue>
    </wml2:parameter>
    ...


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

...
<wml2:parameter>
  <om:NamedValue>
    <om:name xlink:href="urn:bro:gld:ObservationMetadata:principalInvestigator"/>
    <om:value xsi:type="brocom:OrganizationType">
      <brocom:europeanCompanyRegistrationNumber>DEB8537.HRB66039</brocom:europeanCompanyRegistrationNumber>
    </om:value>
  </om:NamedValue>
</wml2:parameter>
...


In de GLD gegevenscatalogus is bij beide gegevens aangegeven dat onder IMBRO/A de waarde ontbreken. In een XML-bericht uit zich dat als een lege string voor de organisatienaam en/of het ontbreken van de betreffende parameter:

...
<om:metadata>
  <wml2:ObservationMetadata>
    <gmd:contact>
      <gmd:CI_ResponsibleParty>
        <gmd:organisationName>
          <gco:CharacterString/>
        </gmd:organisationName>
        <gmd:role>
          <gmd:CI_RoleCode
            codeList="urn:ISO:19115:CI_RoleCode"
            codeListValue="principalInvestigator">principalInvestigator</gmd:CI_RoleCode>
        </gmd:role>
      </gmd:CI_ResponsibleParty>
    </gmd:contact>
  ...

Observatietype

Volgens de GLD gegevenscatalogus heeft het gegeven observatietype het type Observatietype, een uitbreidbare waardelijst. Binnen het ComplexType ObservationMetadata van WaterML is hiervoor geen geschikt gegeven gedefinieerd. Daarom is het gegeven gemapt op een parameter van het type NamedValue. Het XML-element name bevat in dit geval een vaste waarde, die uniek het gegeven 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.

...
<wml2:parameter>
  <om:NamedValue>
    <om:name xlink:href="urn:bro:gld:ObservationMetadata:observationType"/>
    <om:value xsi:type="gml:CodeWithAuthorityType" codeSpace="urn:bro:gld:ObservationType">reguliereMeting</om:value>
  </om:NamedValue>
</wml2:parameter>
...

Gerelateerd aan

In de GLD gegevenscatalogus heeft een Observatie een optionele lijst van gerelateerde observaties. Bij een observatie met een volledig beoordeelde tijd-meetwaardereeks moet hier geregistreerd worden op welke observatie(s) met een voorlopige tijd-meetwaardereeks de observatie is gebaseerd en/of welke observaties met een controlemeting gebruikt zijn tijdens de beoordeling.

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.

...
<om:relatedObservation>
  <om:ObservationContext>
    <om:role xlink:href="http://resource.gwml.org/def/role/supportObservation"/>
    <om:relatedObservation xlink:href="_48bf6066-fdc4-475e-a205-46607d37a17c"/>
  </om:ObservationContext>
</om:relatedObservation>
...

PhenomenonTime

Het gegeven phenomenonTime (observatieperiode) bestaat uit een periode, aangegeven door een beginPosition (begindatum) en een endPosition (einddatum). Beide gegevens 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

<om:phenomenonTime>
  <gml:TimePeriod gml:id="SEQ_0001">
    <gml:beginPosition>2018-01-07</gml:beginPosition>
    <gml:endPosition>2018-07-12</gml:endPosition>
  </gml:TimePeriod>
</om:phenomenonTime>

ResultTime.

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

  • volledige datum en tijd
  • volledige datum
  • jaar en maand
  • jaartal
  • 'onbekend'

Dit gegeven 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:

<om:resultTime>
  <gml:TimeInstant gml:id="SEQ_0001">
    <gml:timePosition>2018-07-12T16:58:07+02:00</gml:timePosition>
  </gml:TimeInstant>
</om:resultTime>
<om:resultTime>
  <gml:TimeInstant gml:id="SEQ_0002">
    <gml:timePosition>2018-07-12T14:58:07Z</gml:timePosition>
  </gml:TimeInstant>
</om:resultTime>
<om:resultTime>
  <gml:TimeInstant gml:id="SEQ_0003">
    <gml:timePosition>2018-07-12</gml:timePosition>
  </gml:TimeInstant>
</om:resultTime>
<om:resultTime>
  <gml:TimeInstant gml:id="SEQ_0004">
    <gml:timePosition>2018-07</gml:timePosition>
  </gml:TimeInstant>
</om:resultTime>
<om:resultTime>
  <gml:TimeInstant gml:id="SEQ_0005">
    <gml:timePosition>2018</gml:timePosition>
  </gml:TimeInstant>
</om:resultTime>
<om:resultTime>
  <gml:TimeInstant gml:id="SEQ_0006">
    <gml:timePosition indeterminatePosition="unknown" />
  </gml:TimeInstant>
</om:resultTime>

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:

<wml2:processReference xlink:href="urn:bro:gld:ProcessReference:NEN_EN_ISO22475v2006_C11v2010"/>

ObservationType

Voor het gegeven observationType (observatietype) definieert WaterML geen geschikt gegeven. Daarom is dit gegeven gemakt op een NamedValue parameter. Zie onderstaande voorbeeld. Het XML-element om:name geeft in het XML-attribuut xlink:href aan om welk gegeven 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.

<wml2:parameter>
  <om:NamedValue>
    <om:name xlink:href="urn:bro:gld:ObservationMetadata:observationType"/>
    <om:value xsi:type="gml:CodeWithAuthorityType" codeSpace="urn:bro:gld:ObservationType">reguliereMeting</om:value>
  </om:NamedValue>
</wml2:parameter>

EvaluationProcedure

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

AirPressureCompensationType

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

MeasurementInstrumentType

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

StatusQualityControl

Voor het gegeven statusQualityControl (statusKwaliteitscontrole) definieert WaterML geen geschikt gegeven. Daarom is dit gegeven gemakt 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.

<wml2:qualifier>
  <swe:Category>
    <swe:codeSpace xlink:href="urn:bro:gld:StatusQualityControl"/>
    <swe:value>goedgekeurd</swe:value>
  </swe:Category>
</wml2:qualifier>


CensoringLimitvalue

Voor het gegeven censoringLimitvalue (censuurlimietwaarde) definieert WaterML geen geschikt gegeven. Daarom is dit gegeven gemakt op een Quantity qualifier. Zie onderstaande voorbeeld. Het XML-attribuut definition van het XMLelement swe:Quantity bevat de unieke identificatie van het gegeven, 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.

<wml2:qualifier>
  <swe:Quantity definition="urn:bro:gld:PointMetadata:censoringLimitvalue">
    <swe:uom code="m"/>
    <swe:value>-5.123</swe:value>
  </swe:Quantity>
</wml2:qualifier>

CensoredReason

Het gegeven 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:


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.

Type

Naam

Waarde

Omschrijving

IndicationYesNoIndicatieJaNeeja


nee
IndicationYesNoUnknownIndicatieJaNeeOnbekendja


nee


onbekendHet is niet bekend of het gegeven een waarde ja of nee heeft.
QualityRegimeKwaliteitsregimeIMBROKwaliteitsregime waarbij de innamewebservice tijdens het verwerken van een innameverzoek de normale (strikte) regels hanteert, zoals gedefinieerd in de gegevenscatalogus.


IMBRO/AKwaliteitsregime waarbij de innamewebservice tijdens het verwerken van een innameverzoek andere (minder strenge) bedrijfsregels, toegestane waarden van codelijsten en/of domeinen van gegevens toepast dan onder het (normale) IMBRO kwaliteitsregime.


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

  • 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 of het XML-attribuut href. Bij een XML-attribuut codeSpace wordt de gekozen waarde uit de codelijst opgenomen als waarde van het XML-element. Bij een XML-attribuut href wordt de gekozen waarde uit de codelijst samen met de URI geplaatst in het XML-attribuut. Zie de voorbeeldberichten voor nadere informatie.
  • 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.

Overzicht met codelijsten voor de berichtencatalogi:

Type

Naam

URI

Link

AirPressureCompensationTypeTypeLuchtdrukcompensatieurn:bro:gld:AirPressureCompensationTypehttps://publiek.broservices.nl/refcodes/api/get_codes?domain=urn:bro:gld:AirPressureCompensationType
CensoredReasonCensuurredenhttp://www.opengis.net/def/nil/OGC/0/ http://defs.opengis.net/elda-common/ogc-def/resource?uri=http://www.opengis.net/def/nil/OGC/0/&_format=html
EvaluationProcedureBeoordelingsprocedureurn:bro:gld:EvaluationProcedurehttps://publiek.broservices.nl/refcodes/api/get_codes?domain=urn:bro:gld:EvaluationProcedure
InterpolationTypeInterpolatietypehttp://www.opengis.net/def/waterml/2.0/interpolationType http://defs.opengis.net/elda-common/ogc-def/resource?uri=http://www.opengis.net/def/waterml/2.0/interpolationType/&_format=html
MeasurementInstrumentTypeTypeMeetinstrumenturn:bro:gld:MeasurementInstrumentTypehttps://publiek.broservices.nl/refcodes/api/get_codes?domain=urn:bro:gld:MeasurementInstrumentType
ObservationTypeObservatietypeurn:bro:gld:ObservationTypehttps://publiek.broservices.nl/refcodes/api/get_codes?domain=urn:bro:gld:ObservationType
ProcessReferenceMeetprocedureurn:bro:gld:ProcessReferencehttps://publiek.broservices.nl/refcodes/api/get_codes?domain=urn:bro:gld:ProcessReference
ProcessTypeProcestypehttp://www.opengis.net/def/waterml/2.0/processType http://defs.opengis.net/elda-common/ogc-def/resource?uri=http://www.opengis.net/def/waterml/2.0/processType/&_format=html
StatusCodeMateBeoordelingurn:bro:gld:StatusCodehttps://publiek.broservices.nl/refcodes/api/get_codes?domain=urn:bro:gld:StatusCode
StatusQualityControlStatusKwaliteitscontroleurn:bro:gld:StatusQualityControlhttps://publiek.broservices.nl/refcodes/api/get_codes?domain=urn:bro:gld:StatusQualityControl

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.3.3.3. Aanvullende regels.

Waarde in XML-verzoek

Toegestane waarde in codelijst

CensoredReasonCensuurreden
http://www.opengis.net/def/nil/OGC/0/AboveDetectionRangegroterDanLimietwaarde
http://www.opengis.net/def/nil/OGC/0/BelowDetectionRangekleinerDanLimietwaarde
http://www.opengis.net/def/nil/OGC/0/unknownonbekend
InterpolationTypeInterpolatietype
http://www.opengis.net/def/waterml/2.0/interpolationType/Discontinuousdiscontinu
ProcessTypeProcestype
http://www.opengis.net/def/waterml/2.0/processType/Algorithmalgoritme


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.

Complextype (stereotype)
element

Naam entiteit
naam gegeven

AbstractRegistrationObject (FeatureType)Abstract Registratieobject  
broId  BRO-ID  
ChamberOfCommerceNumber (PrimitiveDatatype)KvK-nummer  
Date (PrimitiveDatatype)Datum  
DispatchDataRequest (FeatureType)Verzoek tot uitgifte van objectgegevens  
DispatchDataResponse (FeatureType)Bericht van verzending gegevens  
dispatchDocument  uitgiftedocument  
GLD_O (FeatureType)Grondwaterstandonderzoek  
registrationHistory  registratiegeschiedenis  
researchFirstDate  datum eerste meting  
researchLastDate  datum recentste meting  
GLD_O_DP (FeatureType)Grondwaterstandonderzoek  
GroundwaterMonitoringNet (FeatureType)Grondwatermonitoringnet  
broId  BRO-ID  
GroundwaterMonitoringTube (FeatureType)GMW-monitoringbuis  
broId  BRO-ID  
tubeNumber  buisnummer  
MeasurementTimeseries (FeatureType)Tijdmeetwaardereeks  
gmlAtrributeId  tijdmeetwaardereeks ID  
point  tijdmeetwaardepaar  
MeasurementTimeseriesTVPObservation (FeatureType)Observatie  
gmlAtrributeId  observatie ID  
metaDatametadata observatie  
phenomenonTimeobservatieperiode  
resultTime  tijdstip resultaat  
MeasurementTVP (AttributeGroupType)Tijdmeetwaardepaar  
metadata  metadata tijdmeetwaardepaar  
time  tijdstip meting  
value  waterstand  
Number4 (PrimitiveDatatype)Aantal4  
ObservationMetadata (AttributeGroupType)Metadata observatie  
contactuitvoerder  
dateStamp  datum metadata  
parameterObservationTypeobservatietype  
status  mate beoordeling  
ObservationProcess (FeatureType)Observatieproces  
gmlAtrributeIdobservatieproces ID  
parameterAirPressureCompensationType  type luchtdrukcompensatie  
parameterEvaluationProcedure  beoordelingsprocedure  
parameterMeasurementInstrumentType  type meetinstrument  
processReference  meetprocedure  
processType  procestype  
Organization (Union)Organisatie  
chamberOfCommerceNumber  KvK-nummer  
europeanCompanyRegistrationNumber  Europees handelsnummer  
PartialDate (Union)OnvolledigeDatum  
jaar en maand  yearMonth  
jaartal  year  
onbekend  voidReason  
volledige datum  date  
RegistrationHistory (AttributeGroupType)Registratiegeschiedenis  
corrected  gecorrigeerd  
deregistered  uit registratie genomen  
deregistrationTime  tijdstip uit registratie genomen  
latestAdditionTime  tijdstip laatste aanvulling  
latestCorrectionTime  tijdstip laatste correctie  
objectRegistrationTime  tijdstip registratie object  
registrationCompletionTime  tijdstip voltooiing registratie  
registrationStatus  registratiestatus  
reregistered  weer in registratie genomen  
reregistrationTime  tijdstip weer in registratie genomen  
underReview  in onderzoek  
underReviewTime  in onderzoek sinds  
RegistrationObject (FeatureType)Registratieobject  
deliveryAccountableParty  bronhouder  
deliveryResponsibleParty  dataleverancier  
objectIdAccountableParty  object-ID bronhouder  
qualityRegime  kwaliteitsregime  
RegistrationObjectCode (PrimitiveDatatype)Registratieobjectcode  
ResponsibleParty (AttributeGroupType)Organisatiegegevens  
contactOrganisationName  organisatienaam  
parameterPrincipalInvestigatoridentificatie  
Text40 (PrimitiveDatatype)Tekst40  
Text7 (PrimitiveDatatype)Tekst7  
TVPMeasurementMetadata (AttributeGroupType)Metadata tijdmeetwaardepaar  
censoredReason  censuurreden  
interpolationType  interpolatietype  
qualifierCategorystatus kwaliteitscontrole  
qualifierQuantitycensuurlimietwaarde  
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.