BHR-G Berichtencatalogus innamewebservice

1.1.1. DISCLAIMER

Dit document is nog in progress. 

Disclaimer - De voorbeeldberichten zijn bedoeld voor ontwikkeling van eigen software om aan te sluiten op de BRO. Onderstaande berichten zijn getest op de BRO-services waarbij attribuutvelden waarden hebben meegekregen. Deze berichten zijn niet bedoeld als template om uiteindelijke brondocumenten te genereren.

2. Inleiding

Dit document beschrijft hoe een bronhouder en/of dataleverancier de gegevens over een geologisch booronderzoek (BHR-G) kan opnemen in een verzoek voor de Basisregistratie Ondergrond (BRO).

Het document veronderstelt dat de lezer bekend is met de BHR-G catalogus 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 catalogus. Vervolgstappen, zoals het valideren (testen), aanbieden en verwerken van een BRO-verzoek, staan beschreven in het Bronhouderportaal (zie www.basisregistratieondergrond.nl).

2.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 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 catalogus kan worden opgezocht.

2.2. Versiehistorie

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

3. 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 verschillende requests van de BHR-G innamewebservice. Paragraaf 2.2 beschrijft het verband tussen de deelonderzoeken, waaruit een geologisch booronderzoek kan bestaan, en de wijze van aanleveren. Paragraaf 2.3 beschrijft de verschillende brondocumenten die in een request opgenomen kunnen worden. 

3.1. Requests

Om gegevens te registreren of te corrigeren 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 BHR-G innamewebservice ondersteunt op dit moment het registrationRequest (innameverzoek) en het correctionRequest (correctieverzoek). Zie onderstaande tabel.

Paragraaf 2.1.1 beschrijft in detail de opbouw van een registrationRequest, paragraaf 2.1.2 het correctionRequest.

3.1.1. RegistrationRequest

Met een registrationRequest (innameverzoek) wordt een nieuw registratieobject toegevoegd aan de BRO, of wordt een in de BRO aanwezig registratieobject aangevuld.

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

Naam in XML-bestand	Nederlandse naam	Type	Kardinaliteit	Definitie
requestReference	verzoekkenmerk	CharacterString	1..1	Een voor de dataleverancier unieke aanduiding van het innameverzoek.
deliveryAccountableParty	bronhouder	ChamberOfCommerceNumber	0..1	Het KvK-nummer van de bronhouder. Regels: Dit element mag niet aanwezig zijn als de dataleverancier tevens bronhouder is. Dit element moet aanwezig zijn als de dataleverancier niet de bronhouder is.
broId	BRO-ID	RegistrationObjectCode	0..1	De unieke aanduiding van een registratieobject, dat is opgenomen in de BRO. Regels: Dit element mag niet aanwezig zijn bij de initiële registratie van een registratieobject.
qualityRegime	kwaliteitsregime	QualityRegime	1..1	De aanduiding van het kwaliteitsregime waaraan de gegevens in het brondocument voldoen. Regels: Toegestane waarde binnen de huidige scope is IMBRO (anders zou het ook IMBRO/A zijn).  IMBRO/A Een paar elementen en attributen anticiperen al op IMBRO/A. Daar waar dat het geval is wordt dat met een Note bericht aangegeven Toelichting: De catalogus geeft aan wat de gevolgen van een waarde voor het kwaliteitsregime zijn op de kardinaliteit, het domein en de bedrijfsregels van de gegevensinhoud van een brondocument.
sourceDocument	brondocument	SourceDocument	1..1	Dit element bevat één van de gedefineerde brondocumenten. Regels: Binnen de huidige scope is het brondocument een van de volgende documenten BHR_G_StartReport of een BHR_G_CompleteReport Toelichting: Het brondocument bevat de gegevens die in de BRO opgenomen moeten worden. De gegevens in het brondocument zijn gespecificeerd in de catalogus. Zie paragraaf 2.3 voor nadere informatie.

3.1.2. CorrectieRequest

Met een correctionRequest (correctieverzoek) kan de dataleverancier een registratieobject in één keer corrigeren. Het is niet mogelijk de waarde van een individueel attribuut te corrigeren; correcties kunnen alleen uitgevoerd worden door één van de gedefinieerde brondocumenten aan te bieden.

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

Naam in XML-bestand	Nederlandse naam	Type	Kardinaliteit	Definitie
requestReference	verzoekkenmerk	CharacterString	1..1	Een voor de dataleverancier unieke aanduiding van het innameverzoek.
deliveryAccountableParty	bronhouder	ChamberOfCommerceNumber	0..1	Het KvK-nummer van de bronhouder. Regels: Dit element mag niet aanwezig zijn als de dataleverancier tevens bronhouder is. Dit element moet aanwezig zijn als de dataleverancier niet de bronhouder is.
broId	BRO-ID	RegistrationObjectCode	1..1	De unieke aanduiding van een registratieobject, dat is opgenomen in de BRO. Regels: Dit element moet aanwezig zijn bij een correctie op een registratieobject. Binnen de huidige scope is het brondocument een BHR_G_CompleteReport of een BHR_G_EndReport.
qualityRegime	kwaliteitsregime	QualityRegime	1..1	De aanduiding van het kwaliteitsregime waaraan de gegevens in het brondocument voldoen. Regels: Toegestane waarde binnen de huidige scope is IMBRO (anders zou het ook IMBRO/A zijn).  IMBRO/A Een paar elementen en attributen anticiperen al op IMBRO/A. Daar waar dat het geval is wordt dat met een Note bericht aangegeven Toelichting: De catalogus geeft aan wat de gevolgen van een waarde voor het kwaliteitsregime zijn op de kardinaliteit, het domein en de bedrijfsregels van de gegevensinhoud van een brondocument.
correctionReason	correctiereen	CorrectionReason	1..1	Aanduiding voor de reden waarom het registratieobject wordt vervangen/gecorrigeerd.
sourceDocument	brondocument	SourceDocument	1..1	Dit element bevat één van de gedefineerde brondocumenten. Regels: Binnen de huidige scope is het brondocument een van de volgende documenten BHR_G_CompleteReport of een BHR_G_EndReport. Toelichting: Het brondocument bevat de gegevens waar de al aanwezige gegevens in de BRO door vervangen moeten worden. De gegevens in het brondocument zijn gespecificeerd in de catalogus. Zie paragraaf 2.3 voor nadere informatie.

Het attribuut correctionReason (correctiereden) geeft aan waarom (een deel van) het registratieobject wordt vervangen/gecorrigeerd. De mogelijke waarden voor coorectionReason zijn online beschikbaar via https://publiek.broservices.nl/bro/refcodes/v1/codes?domain=urn:bro:bhr:CorrectionReason

3.2. Deelonderzoeken

De volledige omvang van BHR-G bestaat uit vier onderdelen:

• Boormonsterbeschrijving.

• Boormonsteranalyse.

• Boormonsterfotografie.

• Boorgatlogging.

De resultaten van een booronderzoek worden in delen of in hun geheel gerapporteerd. Wanneer de resultaten in delen worden gerapporteerd worden deze per deelonderzoek geregistreerd. Dat betekent in transactietermen dat het booronderzoek aangevuld moet kunnen worden en dat het daarmee een materiële geschiedenis opbouwt. Voor objecten met geschiedenis is het registreren een proces met een zekere duur. Het proces heeft een begin en een eind en daartussen kan zich de noodzaak voordoen nieuwe gegevens over te dragen.

BHR-G wordt gefaseerd gerealiseerd en daarmee ontstaat een tijdelijke situatie waarin het booronderzoek nog niet volledig is gedefinieerd en slechts een deel van de gegevens van het registratieobject aangeboden kan en mag worden. De registratie wordt voltooid op basis van de juridische verplichting en dat betekent dat de gegevens in de registratie niet meer mogen worden aangevuld.

3.3. Brondocumenten

Een brondocument is de eenheid waarin een verzameling gegevens worden geregistreerd, aangevuld of gecorrigeerd. De gegevens in het brondocument zijn gedefinieerd in de catalogus. De catalogus definieert ook gegevens die door het BRO-systeem worden gegenereerd of afgeleid; deze gegevens hoeven niet worden opgenomen in een brondocument.

Een brondocument wordt verpakt in een 'request'. Vervolgens wordt het geheel als een bestand in IMBRO/XML-formaat in de vorm van een BRO-verzoek aangeboden in het Bronhouderportaal.

Het brondocument BHR-G-volledigRapport wordt gebruikt wanneer de resultaten van een booronderzoek in hun geheel worden gerapporteerd. Vanaf versie 1.99 van de catalogus bestaat het geologisch booronderzoek uit meer dan 1 deelonderzoek en kunnen de resultaten van een booronderzoek ook in delen worden gerapporteerd. In dat geval start de registratie met het BHR-G-startrapport.
Beide brondocumenten beschrijven een deel van BHR-G en dat is de boormonsterbeschrijving en de boormonsteranalyse. Later worden boormonsterfotografie en boorgatlogging toegevoegd (termijn nog onbekend). Pas dan is BHR-G volledig gedefinieerd.

3.3.1. BHR_G_CompleteReport

Het brondocument wordt aangeboden wanneer de rapportage van het geologisch booronderzoek in een keer volledig wordt gerapporteerd. De registratie is met dit brondocument direct voltooid.

In deze versie omvat het onderzoek 1 of 2 deelonderzoeken en dat is de boormonsterbeschrijving en/of de boormonsteranalyse. Het brondocument beschrijft het algemene deel (veldwerk), de boormonsterbeschrijving en de boormonsteranalyse en dat zijn de bepalingen korrelgrootteverdeling, kalkgehalte, organischestofgehalte, organisch koolstofgehalte, zwavelgehalte, verzadigde waterdoorlatendheid, watergehalte, volumieke massa, droge volumieke massa en volumieke massa vaste delen.

Onderstaande tabel definieert dit brondocument, inclusief de inhoud als deelverzameling van de gegevensdefinitie in de catalogus en de regels aanvullend op de bedrijfsregels in de catalogus.

3.3.2. BHR_G_StartReport

De inhoud van BHR-G-startrapport is nagenoeg gelijk aan de inhoud van BHR-G-volledigRapport. Het enige verschil is dat de rapportagedatum onderzoek ontbreekt. Een BHR-G-startrapport kan alleen worden aangeboden via een registratieverzoek.

3.3.3.  BHR_G_Endreport

3.4. Rapportagegeschiedenis

De gegevens van de rapportagegeschiedenis staan niet in het brondocument, maar worden door de basisregistratie ondergrond afgeleid en vastgelegd als Gebeurtenis in de registratie ondergrond.

Bij brondocument BHR_G_CompleteReport:

• name (naam), attribuut van Event (Gebeurtenis), krijgt bij de aanlevering van het brondocument de waarde volledigGerapporteerd.

• date (datum), attribuut van Event (Gebeurtenis), wordt bij de aanlevering van het brondocument afgeleid van de rapportagedatum onderzoek van de entiteit BoreholeResearch Booronderzoek.

Bij brondocument BHR_G_StartReport:

• name (naam), attribuut van Event (Gebeurtenis), krijgt bij de aanlevering van het brondocument de waarde startGerapporteerd.

• date (datum), attribuut van Event (Gebeurtenis), wordt bij de aanlevering van het brondocument afgeleid van de descriptionReportDate (rapportagedatum beschrijving) van de entiteit BoreholeSampleDescription (Boormonsterbeschrijving) of van de analysisReportDate(rapportagedatum analyse) van de entiteit BoreholeSampleAnalysis (Boormonsteranalyse).

Bij brondocument BHR_G_EndReport:

• name (naam), attribuut van Event (Gebeurtenis), krijgt bij de aanlevering van het brondocument de waarde ?Gerapporteerd.

• date (datum), attribuut van Event (Gebeurtenis), wordt bij de aanlevering van het brondocument afgeleid van de descriptionReportDate (rapportagedatum beschrijving) van de entiteit BoreholeSampleDescription (Boormonsterbeschrijving) of van de analysisReportDate(rapportagedatum analyse) van de entiteit BoreholeSampleAnalysis (Boormonsteranalyse).

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

4.1. Integrale voorbeeldberichten

De onderstaande tabel bevat een opsomming van de beschikbare voorbeeldberichten, hun intentie en een summiere beschrijving van de inhoud.

4.2. Code snippets.

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

4.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 BHR-G innameservice. Deze twee attributen mogen weggelaten worden. In het voorbeeldbericht heeft de URL van de schemalocation de waarde ../../XSD/isbhr-g-messages.xsd. Dit is een relatief pad naar een lokaal bestand, met een mappenstructuur alsof de GitHub repo is gecloned naar een lokale repo. Deze waarde is met name bedoeld in de projectfase voordat de BHR-G 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 in regel 9 t/m 12 volgen vier transactiegegevens: requestReference (verzoekkenmerk), deliveryAccountableParty (bronhouder) en qualityRegime (kwaliteitsregime). Het element broId (BRO-ID) wordt niet opgenomen als het sourceDocument een BHR_G_CompleteReport is, 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/isbhrg/3.1"
    xmlns:bhrgcommon="http://www.broservices.nl/xsd/bhrgcommon3.1"
    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/isbhrg/3.1 ../../XSD/isbhr-g-messages.xsd">
  <!--Disclaimer: dit voorbeeldbericht valideert tegen de XSD van de innameservice.
      Het is niet gevalideert door de innameservice en is vaktechnisch/inhoudelijk niet voorbeeldig.
    xsi:schemaLocation="http://www.broservices.nl/xsd/isbhrg/3.1 https://schema.broservices.nl/xsd/isbhrg/3.1/isbhr-g-messages.xsd">
  -->
  <brocom:requestReference>BRO-BHR-G-1596</brocom:requestReference>
  <!-- Optional: -->
  <brocom:deliveryAccountableParty>27376655</brocom:deliveryAccountableParty>
  <!--Optional: not allowed in combination with sourceDocument BHR_G_CompleteReport.
  <brocom:broId>?</brocom:broId>
  -->
  <brocom:qualityRegime>IMBRO</brocom:qualityRegime>
  <sourceDocument>
    ...
  </sourceDocument>
</registrationRequest>

4.2.2. Brondocument

Een BRO-verzoek bevat een brondocument, wat de eenheid van aanleveren is. Zoals beschreven in paragraaf 2.3 kent versie 1.0 van de BHR-G innamewebservice 1 type brondocument. De UML-diagrammen geven aan dat het stereotype  van het brondocument FeatureType is. 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 BHR_G_CompleteReport. Deze regel geeft aan dat in dit bericht dit type brondocument wordt aangeleverd. Na deze regel komt het eerste XML element van het BHR_G_CompleteReport brondocument.

...
<sourceDocument>
  <BHR_G_CompleteReport gml:id="id_0001">
    <objectIdAccountableParty>myIdForThisBoreholeResearch</objectIdAccountableParty>
    ...
  </GLD_StartRegistration>
</sourceDocument>
...

4.2.3. gml:id

De BHR-G gegevensdefinitie maakt een onderscheid tussen objecttypes en gegevensgroeptypes. Bij het opstellen van de berichtdefinities worden deze stereotypes vertaald naar FeatureType en AttributeGroupType. Twee van de verschillen zijn 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.

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

• Een complex type, wat de inhoud van het FeatureType definieert en direct of indirect een specialisatie is van gml:AbstractFeatureType.

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

• Een property type ComplexType, wat in de XSD-bestanden gebruikt wordt als het type van een element dat fungeert als realisatie van de associatie relatie naar het FeatureType.

Als gevolg van de eerste bullet krijgt in een XML-bericht 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.

Enkele voorbeelden:

...
<BHR_G_CompleteReport gml:id="id_0001">
...
<gml:Point gml:id="id_0002" srsName="urn:ogc:def:crs:EPSG::28992">
...
<bhrgcommon:BoreholeSampleDescription gml:id="id_0003">
...
<bhrgcommon:DescriptiveBoreholeLog gml:id="id_0004">
...

4.2.4. Waarde uit een codelijst

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 is de lijst met toegestane waarden niet opgenomen in de XSD-bestanden.

Voor codelijsten volgt de BRO de GML XML encoding rules voor een CodeType. Dit is een algemeen patroon. Het voegt een XML-attribuut codeSpace toe aan een XML-element, waarvan de waarde verwijst naar een catalogus, thesaurus, classificatie schema of autoriteit voor de codelijst. Als conventie bestaat de waarde van het XML-attribuut uit een URN, bv.: urn:bro:bhrg:SurveyPurpose. Hoofdstuk 5 bevat een overzicht van de codelijsten en hun URN waarde. De gegevenscatalogus bevat per codelijst de toegestane waarden, zoals gedefinieerd op het moment dat de gegevenscatalogus werd vastgesteld.

Onderstaand een voorbeeld van een XML-element, waarvan de waarde gebiedsmodelOrdeningOndergrond een waarde uit een codelijst is:

<surveyPurpose codeSpace="urn:bro:bhrg:SurveyPurpose">gebiedsmodelOrdeningOndergrond</surveyPurpose>

4.2.5. Datum

De waarde van een XML-element met als type een xs:Date (Datum) wordt gecodeeerd volgens de ISO-8601 standaard: yyyy-mm-dd. Bijvoorbeeld:

<researchReportDate>2020-08-01</researchReportDate>

4.2.6. Organisatie

De BHR-G gegevenscatalogus definieert een aantal uitvoerders. Deze hebben een Organization (Organisatie) als gegevenstype. Bijvoorbeeld:

• researchOperator (uitvoerder onderzoek)

• horizontalPositioningOperator (uitvoerder locatiebepaling)

• verticalPositioningOperator (uitvoerder verticale positiebepaling)

• descriptionOperator (uitvoerder beschrijving)

• boringOperator (uitvoerder boring)

Het gegevenstype Organization (Organisatie) biedt de keuze tussen een kamer van koophandelnummer of een Europees handelsnummer. Hieonder twee voorbeelden van beide gevallen:

...
<researchOperator>
  <brocom:chamberOfCommerceNumber>52754834</brocom:chamberOfCommerceNumber>
</researchOperator>
...
<bhrgcommon:boringOperator>
  <brocom:europeanCompanyRegistrationNumber>DEB8537.HRB66039</brocom:europeanCompanyRegistrationNumber>
</bhrgcommon:boringOperator>
...

4.2.7. Locatie

De BHR-G gegevenscatalogus definieert voor de DeliveredLocation (Aangeleverde locatie) onder andere de volgende twee attributen:

• Coördinaten: De coördinaten die zijn aangeleverd.

• Referentiestelsel: Het referentiestelsel van de aangeleverde coördinaten.

Conform de GML encoding van NEN3610 worden deze twee attributen uitgewisseld met een gml:Point, bestaande uit:

• XML-element gml:pos - het coördinatenpaar

• XML-attribuut srsName - een verwijzing naar het referentiestelsel waarin het coördinatenpaar is uitgedrukt.

• XML-attribuut gml:id - een unieke identificatie van het object

Het bereik en de betekenis van het coördinatenpaar is afhankelijk van het gebruikte referentiestelsel. Onderstaande tabel geeft per referentiestelsel de waarde voor het XML-attribuut srsName en de betekenis, eenheid en volgorde van de ordinaten in het coördinatenpaar.

Voorbeeld van de XML-encoding voor dezelfde locatie in RD en in ETRS89:

...
<location gml:id="BRO_0001" srsName="urn:ogc:def:crs:EPSG::28992">
  <gml:pos>139794.52 455443.35</gml:pos>
</location>
...
<location gml:id="BRO_0001" srsName="urn:ogc:def:crs:EPSG::4258">
  <gml:pos>52.0870447 5.1653503</gml:pos>
</location>
...

4.2.8. Meetwaarde

De BHR-G gegevenscatalogus definieert een aantal gegevens als een meetwaarde. Deze bestaan uit een getalswaarde en een eenheid.

In de XSD-bestanden hebben de betreffende XML-element een type gml:Measure. Conform de GML XML encoding rules wordt de eenheid opgeslagen in het XML-attribuut uom (unit of measure; eenheid). Bijvoorbeeld een offset (verschuiving) van 1,38 meter onder NAP voor de deliveredVerticalPosition (Aangeleverde verticale positie) wordt:

...
<bhrgcommon:offset uom="m">-1.38</bhrgcommon:offset>
...

Merk op dat in de gegevenscatalogus (in de meeste gevallen) naast de afkorting ook tussen haakjes de voluitgeschreven naam van de eenheid is opgenomen, bijvoorbeeld: Eenheid: m (meter) . Alleen de afkorting volgens de UCUM lijst moet worden opgenomen in het BRO-verzoek. Deze afkorting van de eenheid staat genoemd in de XSD. 

5. Enumeraties

Dit hoofdstuk bevat de toegestane waarden van de enumeraties. In de gegevenscatalogus worden deze niet-beheerde waardenlijsten genoemd.

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 geologisch booronderzoek. 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.

6. Codelijsten

Dit hoofdstuk bevat verwijzingen (URN's en URL's) van de codelijsten. In de gegevenscatalogus worden deze beheerde waardenlijsten genoemd.

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 geologisch booronderzoek.

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

• De vierde kolom bevat een link naar de website waar de actuele lijst met toegestane waarden is te raadplegen.

Overzicht met BHR-G codelijsten:

7. Vertaallijst

Dit hoofdstuk bevat een vertaaltabel aan de hand waarvan, gegeven de Engelstalige naam van een complexType/element in de XSD-bestanden, de Nederlandse naam van de entiteit en het attribuut 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.

BHR_G_CompleteReport_vb1.xml BHR_G_EndReport_vb1.xml BHR_G_StartReport_vb1.xml