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

Open issues

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:

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:

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:

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

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:

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.

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

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.

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.

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

<?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

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.

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.

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:

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

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:

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.

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.

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. 

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:

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:

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.

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.

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.

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.

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:

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.

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.