Berichtencatalogus Innamewebservice BHR-GT

Deze versie is onderdeel van de documentatie voor versie 2.1 BHR-GT 

Inleiding

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

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

Leeswijzer

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

Hoofdstuk 3 bevat een toelichting op enkele voorbeeldberichten.

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

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

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

Versiehistorie

Contactinformatie

Algemene informatie, documentatie en voorbeeld XML-berichten kunt u vinden op  www.basisregistratieondergrond.nl.

Heeft u een vraag over de BRO? Wij staan voor u klaar om u te helpen.

Voor vragen, suggesties of opmerkingen kunt contact opnemen met de BRO Servicedesk via een mail naar support@broservicedesk.nl .

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

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-GT inname webservice. Paragraaf 2.2 beschrijft de verschillende brondocumenten die in een request opgenomen kunnen worden. Paragraaf 2.3 beschrijft het verband tussen de deelonderzoeken, waaruit een geotechnisch booronderzoek kan bestaan, de gefaseerde oplevering en de wijze van aanleveren.

Requests

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

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

De BHR-GT innamewebservice ondersteunt twee soorten requests.  Zie onderstaande tabel.

Paragraaf 2.1.1 beschrijft in detail de opbouw van een  registrationRequest . Paragraaf 2.1.2 beschrijft op dezelfde manier een  correctionRequest .

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:

CorrectionRequest

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 :

Brondocumenten

Een brondocument bevat de gegevens die geregistreerd worden in de LV BRO. Voor elk registratieobject staat in de bijbehorende catalogus waaraan die gegevens moeten voldoen.

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 feit, dat de resultaten van een geotechnisch booronderzoek per deelonderzoek geregistreerd moeten kunnen worden en dat het geotechnisch booronderzoek gefaseerd gerealiseerd wordt, leidt ertoe dat momenteel de volgende drie brondocumenten zijn gedefinieerd:

Onderstaande tabel geeft per brondocument de belangrijkste onderdelen weer.

De betekenis van de tekens in de laatste 4 kolommen is als volgt:

• Een √ geeft aan dat het onderdeel aanwezig moet zijn in het brondocument.
• Een + geeft aan dat het onderdeel aanwezig mag zijn in het brondocument.
• Een leeg veld geeft aan dat het onderdeel niet aanwezig mag zijn in het brondocument.

In de huidige fase van de definitie van het geotechnisch booronderzoek bestaat de boormonsteranalyse (BMA) uit de bepalingen:

1. SettlementCharacteristicsDetermination (Bepaling zettingseigenschappen).
2. MaximumUndrainedShearStrengthDetermination (Bepaling maximale ongedraineerde schuifsterkte).
3. ParticleSizeDistributionDetermination (Bepaling korrelgrootteverdeling).
4. ShearStressChangeDuringLoadingDetermination (Bepaling schuifspanningsverloop bij belasting).
5. ShearStressChangeDuringHorizontalDeformationDetermination (Bepaling schuifspanningsverloop bij horizontale vervorming).
6. ConsistencyLimitsDetermination (Bepaling consistentiegrenzen).
7. SaturatedPermeabilityDetermination (Bepaling verzadigde waterdoorlatendheid).
8. WaterContentDetermination (Bepaling watergehalte).
9. OrganicMatterContentDetermination (Bepaling organischestofgehalte).
10. CarbonateContentDetermination (Bepaling kalkgehalte).
11. VolumetricMassDensityDetermination (Bepaling volumieke massa).
12. VolumetricMassDensitySolidsDetermination (Bepaling volumieke massa vaste delen).

Onderstaande tabel geeft voor de eerste 7 bepalingen weer of deze moeten (√), mogen (+) of niet mogen (blanco) worden aangeboden, afhankelijk van de waarde van het attribuut analysisType (type analyse) van de entiteit InvestigatedInterval (Onderzocht interval). De aanwezigheid van de andere bepalingen wordt daarnaast mede bepaald door de waarde van de attributen waterContentDetermined (watergehalte bepaald), organicMatterContentDetermined (organischestofgehalte bepaald), carbonateContentDetermined (kalkgehalte bepaald), volumetricMassDensityDetermined (volumieke massa bepaald), volumetricMassDensitySolidsDetermined (volumieke massa vaste delen bepaald) van de entiteit InvestigatedInterval (Onderzocht interval) en de attributen specialMaterial (bijzonder materiaal) en geotechnicalSoilName (geotechnische grondsoort) van de entiteit InvestigatedMaterial (Onderzocht materiaal).

BHR_GT_CompleteReport_V1

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.

BHR_GT_StartReport_V1

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.

BHR_GT_EndReport_V1

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.

Deelonderzoeken en gefaseerde oplevering

BHR-GT bestaat uit vier deelonderzoeken:

• Boormonsterbeschrijving.
• Boormonsteranalyse.
• Boormonsterfotografie.
• Boorgatlogging.

De resultaten van een geotechnisch booronderzoek worden in hun geheel of in delen gerapporteerd. Wanneer de resultaten in delen worden gerapporteerd, dan worden deze per deelonderzoek geregistreerd. Daarmee 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.

Alles in 1 keer aanleveren

Voorbeeld 1: stel een geotechnisch booronderzoek omvat een boormonsterbeschrijving en een boormonsteranalyse. Stel dat de gegevens van deze 2 deelonderzoeken min of meer tegelijkertijd beschikbaar komen. In dit geval kunnen de resultaten in hun geheel aangeboden worden. Zie onderstaande figuur.

Per deelonderzoek aanleveren

Voorbeeld 2: stel een geotechnisch booronderzoek omvat een boormonsterbeschrijving en een boormonsteranalyse. Stel dat er een zekere tijd zit tussen de tijdstippen waarop de gegevens van deze 2 deelonderzoeken beschikbaar komen. Een brondocument moet binnen 20 werkdagen worden aangeboden (zie de Wet basisregistratie ondergrond, d.d. 30 september 2015). In dat geval wordt de registratie van een BHR-GT registratieobject gestart met het eerste deelonderzoek en daarna aangevuld en beëindigd met het tweede deelonderzoek. Afhankelijk van de volgorde waarin de gegevens beschikbaar komen, wordt eerst de boormonstebeschrijving aangeboden en daarna de boormonsteranalyse, of omgekeerd. Zie onderstaande figuur.

BHR-GT wordt gefaseerd gerealiseerd en daarmee ontstaat een tijdelijke situatie waarin BHR-GT nog niet volledig is gedefinieerd en slechts een deel van de gegevens aangeboden kan worden. De huidige brondocumenten beschrijven een deel van BHR-GT en dat is de boormonsterbeschrijving en de boormonsteranalyse. Later worden boormonsterfotografie en boorgatlogging toegevoegd (termijn nog onbekend). Pas dan is BHR-GT volledig gedefinieerd. Raadpleeg voor meer informatie de planning op www.basisregistratieondergrond.nl. 

Boormonsterfotografie en boorgatlogging

Voorbeeld 3: stel een geotechnisch booronderzoek omvat een boormonsterbeschrijving, een boormonsteranalyse, boormonsterfotografie en een boorgatlogging. Op dit moment kunnen alleen de boormonsterbeschrijving en de boormonsteranalyse worden aangeboden. Dat kan zoals beschreven in de bovenstaande voorbeelden 1 of 2. De resultaten van de boormonsterfotografie en/of de boorgatlogging kunnen later door middel van correctieverzoeken worden aangeboden.

De gefaseerde realisatie houdt ook in dat er per 1-1-2020 een versie 1.0 van de innamewebservice in productie is en dat er per 1-7-2021 een versie 2.1 in productie genomen zal worden. De onderstaande tabel geeft weer welke versie welke bepalingen van de boormonsteranalyse ondersteunt. 

Als via versie 1.0 van de innamewebservice de toentertijd ondersteunde bepalingen zijn aangeboden, maar er waren ook resultaten van andere bepalingen beschikbaar welke nu via versie 2.1 kunnen worden aangeboden, dan kan dit door middel van een correctiebericht.

Aanvullende analyses aanleveren

Voorbeeld 4: stel een geotechnisch booronderzoek omvat een boormonsterbeschrijving (BMB) en een boormonsteranalyse (BMA), bestaande uit bepalingen van de korrelgrootteverdeling, watergehalte en consistentiegrenzen. Voor 1-7-2021 zijn de BMB en de bepaling van de korrelgrootteverdeling en de bepaling van de watergehalte van de BMA aangeboden. Vanaf 1-7-2021 kan ook de bepaling van de consistentiegrenzen van de BMA worden aangeboden door (een van de) het oorspronkelijke bericht(en) te corrigeren. Zie onderstaande figuur.

Voorbeeldberichten

Dit hoofdstuk bevat enkele voorbeeldberichten en van diverse onderdelen van de berichten een uitgebreide toelichting.

Integrale voorbeeldberichten

De integrale voorbeeldberichten zijn te vinden op BHR-GT voorbeeldberichten. 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 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 innamewebservice. Deze twee attributen mogen weggelaten worden. Regel 2 mag ook de opening tag van een correctionRequest (correctieverzoek) zijn.

Na de disclaimer volgen vier transactiegegevens: requestReference (verzoekkenmerk), deliveryAccountableParty (bronhouder), broId (BRO-ID) en qualityRegime (kwaliteitsregime). Zie hoofdstuk 2 voor nadere informatie. Het attribut broID (BRO-ID) is bij een registrationRequest (registratieverzoek) alleen toegestaan als het sourceDocument (brondocument) een BHR_GT_EndReport_V1 is. Bij een correctionRequest (correctieverzoek) is dit attribuut verplicht.

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) c.q. het correctionRequest (correctieverzoek).

<?xml version="1.0" encoding="UTF-8"?>
<registrationRequest 
        xmlns="http://www.broservices.nl/xsd/isbhr-gt/2.1"
        xmlns:bhrgtcom="http://www.broservices.nl/xsd/bhrgtcommon/2.1"
        xmlns:brocom="http://www.broservices.nl/xsd/brocommon/3.0"
        xmlns:swe="http://www.opengis.net/swe/2.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/isbhr-gt/2.1 https://schema.broservices.nl/xsd/isbhr-gt/2.1/isbhr-gt-messages.xsd">
    <!-- Disclaimer: dit voorbeeldbericht valideert tegen de validatieservice van de acceptatie omgeving van het bronhouderportaal, maar de gegevens zijn fictief en waarschijnlijk niet correct.-->
    <brocom:requestReference>verzoek_2</brocom:requestReference>
    <!--Optional:-->
    <brocom:deliveryAccountableParty>27376655</brocom:deliveryAccountableParty>
    <!--Optional:-->
    <brocom:broId>BHR000000342106</brocom:broId>
    <brocom:qualityRegime>IMBRO</brocom:qualityRegime>
    <sourceDocument>
        ...
    </sourceDocument>
</registrationRequest>

Brondocument

Een BRO-verzoek bevat een brondocument. Een brondocument is de eenheid van aanleveren. De BHR-GT innamewebservice kent meerdere types brondocumenten, die allen 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 als tag de naam van het type brondocument, bijvoorbeeld BHR_GT_CompleteReport_V1. Deze regel geeft aan dat in dit bericht dat type brondocument is opgenomen. Het element BHR_GT_CompleteReport_V1 is als root element gedefinieerd in het XSD-bestand isbhr-gt-messages.xsd van de BHR-GT innamewebservice. Na deze regel komt het eerste XML element van het brondocument.

   ...
    <sourceDocument>
        <BHR_GT_CompleteReport_V1 gml:id="id_0001">
            ...
        </BHR_GT_CompleteReport_V1>
    </sourceDocument>
    ...

gml:id

De BHR-GT 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. Beide hebben attributen (attributes), gegevensgroepen (attributeGroups) of associations (relaties) naar andere Featuretypes als onderdelen. De verschillen zijn onder meer dat een Feature identificeerbaar is en dat een AttributeGroup alleen bestaat bij de gratie van het Feature waarvan het, direct of indirect, een onderdeel is.

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

• Een ComplexType, wat de inhoud van het FeatureType definieert en een specialisatie is van gml:AbstractFeatureType.
• Een root element, zodat objecten van dit ComplexType geïnstantieerd kunnen worden.
• Een propertyType ComplexType, zodat in een XML-document een association (relatie) naar dit FeatureType gelegd kan worden vanuit een ander FeatureType of AttributeGroupType.

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.

Waarde uit een codelijst

Zie Codelist (Codelijst) voor een algemene beschrijving van het gebruik van codelijsten in de BRO.

Datum en DatumTijd

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

<brocom:date>2019-03-18</brocom:date>

De waarde van een XML-element met als type een  xs:DateTime  (Datum) wordt ook gecodeeerd volgens de ISO-8601 standaard: yyyy-mm-ddThh:mm:ss+hh:mm. Daarbij is de tijdzone (+hh:mm) verplicht. Bijvoorbeeld:

<brocom:dispatchTime>2019-04-16T09:01:52+01:00</brocom:dispatchTime>

De uren en minuten na het plus teken is de tijdzone ten opzichte van UTC (aka GMT). In theorie kan dit ook een min teken zijn (tijdzones ten westen van Greenwich), maar voor Nederland is de tijdzone + 1 uur (wintertijd) of + 2 uur (zomertijd). In het voorbeeld is de lokale tijd 09:01:52, terwijl het 'in Londen' 08:01:52 is. 

PartialDate

In de gegevenscatalogus hebben diverse gegevens een Datum onder kwaliteitsregime IMBRO en een OnvolledigeDatum onder IMBRO/A. In de XSD-bestanden is de OnvolledigeDatum gerealiseerd door het complexType PartialDateType. Deze ondersteunt 4 mogelijkheden met afnemende nauwkeurigheid:

• date (volledige datum)
• yearMonth (datum en jaartal)
• year (jaartal)
• voidReason (de vaste waarde 'onbekend').

Bijvoorbeeld:

<bhrgtcom:descriptionReportDate>
    <!--You have a CHOICE of the next 4 items at this level
    <brocom:date>2018-09-23</brocom:date>
    <brocom:yearMonth>2018-09</brocom:yearMonth>
    <brocom:year>2018</brocom:year>
    <brocom:voidReason>onbekend</brocom:voidReason>
    -->
    <brocom:date>2018-09-23</brocom:date>
</bhrgtcom:descriptionReportDate>

Bij een PartialDate (OnvolledigeDatum) geldt dat binnen hetzelfde jaar (of jaar en maand) een minder volledige datum voorafgaat aan een meer volledige datum:

• het jaartal 2015 voor de datum en jaartal juli 2015
• de datum en jaartal juli 2015  gaat voor de volledige datum 17 juli 2015.

In het algemeen kan een datum met de waarde 'onbekend' niet worden vergeleken met een andere datum. Daarom wordt bij het toepassen van een regel, waarin twee datums met elkaar worden vergeleken waarvan één (of beide) de waarde 'onbekend' heeft, de bedrijfsregel genegeerd.

Uitzondering is het sorteren van gebeurtenissen op een tijdlijn. Daarbij wordt op basis van de betekenis van de gebeurtenis een begin/inrichten/start gebeurtenis altijd vooraan in de lijst met gebeurtenissen geplaatst, ook als de datum van de gebeurtenis de waarde 'onbekend' heeft. En wordt een eind/opruimen/voltooien gebeurtenis altijd achteraan in de lijst met gebeurtenissen geplaatst, ook als de datum van de gebeurtenis de waarde 'onbekend' heeft. Opdat een lijst met gebeurtenissen eenduidig kan worden gesorteerd, mag bij andere gebeurtenissen de datum van de gebeurtenis niet de waarde 'onbekend' hebben. Dit wordt expliciet als aanvullende regel vermeld bij de betreffende brondocumenten.

Organisatie

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

• descriptionOperator  (uitvoerder beschrijving)
• analysisOperator  (uitvoerder analyse)
• researchOperator (uitvoerder onderzoek)
• horizontalPositioningOperator  (uitvoerder locatiebepaling)
• verticalPositioningOperator  (uitvoerder verticale positiebepaling)
• boringOperator (uitvoerder boring)

Het gegevenstype  Organization  (Organisatie) biedt de keuze tussen een kamer van koophandel nummer of een Europees handelsnummer. Hieronder twee voorbeelden:

...
<bhrgtcom:descriptionOperator>
    <brocom:chamberOfCommerceNumber>09098104</brocom:chamberOfCommerceNumber>
</bhrgtcom:descriptionOperator>
...
<bhrgtcom:descriptionOperator>
    <brocom:europeanCompanyRegistrationNumber>DER2507_R2</brocom:europeanCompanyRegistrationNumber>
</bhrgtcom:descriptionOperator>
...

Locatie

De gegevenscatalogus definieert voor de  DeliveredLocation  (Aangeleverde locatie) en StandardizedLocation  (Gestandaardiseerde 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 rules van NEN3610 worden deze twee attributen omgezet in een gml:Point. Die bestaat op zijn beurt uit:

• XML-element gml:pos - de coördinaten
• XML-attribuut srsName - een verwijzing naar het referentiestelsel waarin de coördinaten zijn uitgedrukt.
• XML-attribuut gml:id - een unieke identificatie van het object

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

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

...
<bhrgtcom:location>
    <gml:Point gml:id="id_0003" srsName="urn:ogc:def:crs:EPSG::28992">
        <gml:pos>134750.000 477800.000</gml:pos>
    </gml:Point>
</bhrgtcom:location>
...
<bhrgtcom:location>
    <gml:Point gml:id="id_0003" srsName="urn:ogc:def:crs:EPSG::4258">
        <gml:pos>52.28782, 5.09042</gml:pos>
    </gml:Point>
</bhrgtcom:location>
...

Meetwaarde

De 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). Als een gegeven van het type meetwaarde geen waarde heeft, dan wordt er een XML-attribuut xsi:Nil="true" opgenomen en heeft het XML-element geen waarde, maar wordt het XML attribuut uom (eenheid) wel opgenomen. Zie onderstaande voorbeelden voor een offset (verschuiving) met en zonder een waarde.

...
<bhrgtcom:offset uom="m">123.321</bhrgtcom:offset>
...
<bhrgtcom:offset uom="m" xsi:nil="true"/>
...

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.

Meetreeks

De gegevenscatalogus definieert voor een aantal bepalingen een meetreeks als resultaat. Daarbij wordt op gezette tijden (of bij bepaalde waarden van een andere onafhankelijke grootheid) steeds een aantal grootheden bepaald. Concreet gaat het om:

• Zettingsverloop als onderdeel van de Bepaling zettingseigenschappen.
• Spanningsverloop bij zetting als onderdeel van de bepaling zettingseigenschappen.
• Volumeverloop bij consolidatie) als onderdeel van de bepaling schuifspanningsverloop bij belasting.
• Schuifspanningsverloop bij belasting) als onderdeel van de bepaling schuifspanningsverloop bij belasting.
• Hoogteverloop bij consolidatie) als onderdeel van de bepaling schuifspanningsverloop bij horizontale vervorming.
• Schuifspanningsverloop bij horizontale vervorming) als onderdeel van de bepaling schuifspanningsverloop bij horizontale vervorming.

Omdat het in deze situaties potentieel om een groot aantal waarden kan gaan, worden de waarden van de grootheden niet uitgeleverd als XML-elementen, maar wordt er gebruikt gemaakt van een compacte codering volgens de SWE standaard (Sensor Web Enablement) van het OGC (Open Geospatial Consortium). De meetreeks is daarbij gemodelleerd als een swe:DataArray. De gemeten of bepaalde waarden van de grootheden worden gemodelleerd als een swe: DataRecord.

Een swe:DataArray bestaat uit vier XML-elementen:

• elementCount: het aantal meetpunten in de meetreeks.
• elementType: beschrijving van een meetpunt als onafhankelijke en afhankelijke grootheden in een swe:DataRecord.
• encoding: aanduiding voor de codering van:
  • Een decimalSeparator (decimaalscheidingsteken) voor de waarden van een grootheid in een meetpunt.
  • Een tokenSeparator (tokenscheidingsteken) om de waarden van de grootheden binnen een meetpunt te scheiden.
  • Een blockSeparator (recordscheidingsteken) om de  meetpunten binnen de meetreeks te scheiden.
• values: de 'CSV'-gecodeerde reeks van waarden van de grootheden van de meetpunten van de meetreeks.

Het DataRecord met de beschrijving van de onafhankelijke en afhankelijke grootheden kan in-line worden opgenomen of externe gedefinieerd worden. Bij de BRO is ervoor gekozen om de definitie van de swe:DataRecords niet in-line op te nemen, maar om deze centraal vast te leggen. In een DataArray wordt dan een verwijzing (xlink:href) opgenomen naar het bestand met daarin een DataRecord. De bestanden met de DataRecords kunnen gedownload worden vanaf dezelfde locatie als de XSD-bestanden (zie bijvoorbeeld https://schema.broservices.nl/xsd/bhrgtcommon/2.1/).

Voor iedere grootheid moet een waarde opgenomen worden in de values met meetpunten van de meetreeks. Het DataRecord geeft aan hoe het ontbreken van een waarde moet worden weergegeven door middel van een nilValue.

Onderstaande tabel geeft een samenvatting van de meetreeksen in de gegevenscatalogus waar dit SWE patroon is toegepast, de XML-elementen die dientengevolge het datatype swe:DataArray hebben gekregen en de bijbehorende XML-bestanden waarin de definities van de swe:DataRecords zijn opgenomen.

Hieronder een voorbeeld van een meetreeks voor de volumeverloop bij consolidatie bestaande uit 2 dataRecords:, waarbij de waaarde voor de vierde grootheid (horizontalStress) in het tweede dataRecord ontbreekt:

<bhrgtcom:volumeChangeDuringConsolidation>
    <swe:elementCount>
        <swe:Count>
            <swe:value>2</swe:value>
        </swe:Count>
    </swe:elementCount>
    <swe:elementType name="VolumeAtSpecificConsolidation" xlink:href="https://schema.broservices.nl/xsd/bhrgtcommon/2.1/VolumeAtSpecificConsolidation.xml"/>
    <swe:encoding>
        <swe:TextEncoding collapseWhiteSpaces="false" decimalSeparator="." tokenSeparator="," blockSeparator=";"/>
    </swe:encoding>
    <bhrgtcom:values>1,?,200,180.12;2,?,400,NaN</bhrgtcom:values>
</bhrgtcom:volumeChangeDuringConsolidation>

Als we als blockSeparator (recordscheidingsteken) een spatie gebruiken in plaats van een punt-komma en voor collapseWhiteSpaces de waarde true invullen (we mogen spaties toevoegen voor en na iedere tokenseparator en blockseparator), dan ontstaat het volgende voorbeeld, met een betere human-readability:

<bhrgtcom:volumeChangeDuringConsolidation>
    <swe:elementCount>
        <swe:Count>
            <swe:value>2</swe:value>
        </swe:Count>
    </swe:elementCount>
    <swe:elementType name="VolumeAtSpecificConsolidation" xlink:href="https://schema.broservices.nl/xsd/bhrgtcommon/2.1/VolumeAtSpecificConsolidation.xml"/>
    <swe:encoding>
        <swe:TextEncoding collapseWhiteSpaces="true" decimalSeparator="." tokenSeparator="," blockSeparator=" "/>
    </swe:encoding>
    <bhrgtcom:values>
        120, 2, 400, 180.12
        240, 8, 8000, NaN
    </bhrgtcom:values>
</bhrgtcom:volumeChangeDuringConsolidation>

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 catalogus 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 catalogus, 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 geotechnisch 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 catalogus. 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 catalogus 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 catalogus bevat per codelijst de toegestane waarden, zoals gedefinieerd op het moment dat de catalogus werd vastgesteld.

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

Vertaaltabel

Dit hoofdstuk 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.

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