Skip to main content
Skip table of contents

Koppelvlakbeschrijving Uitgifteservice CPT

Inleiding

Dit document beschrijft het koppelvlak voor de uitgiftewebservice voor het registratieobject geotechnisch sondeeronderzoek (CPT: Cone Penetration Test) door de Landelijke Voorziening Basisregistratie ondergrond (BRO). Deze koppelvlakbeschrijving gaat in op de technische werking van het koppelvlak om CPT-gegevens uit te kunnen wisselen tussen het systeem van de data-afnemer en het systeem van de BRO.

Doel en doelgroep

Doel van dit document is inzicht bieden in de werking van de uitgiftewebservice. Het proces van gegevensuitgifte zoals beschreven in het 'Uitgiftehandboek Geotechnisch Sondeeronderzoek' is in dit document vertaald naar het technische koppelvlak van de webservice: de Application Programming Interface (API).
Dit document richt zich op de technisch specialisten die de aansluiting realiseren tussen de systemen van de data-afnemers en de Landelijke Voorziening BRO. Kennis van XML en webservices is daarvoor vereist. Het document is echter zo geschreven dat overige belangstellenden de technische werking van het koppelvlak kunnen volgen.

Leeswijzer

Hoofdstuk 2 beschrijft de algemene technische werking van het koppelvlak van de uitgiftewebservice van de Landelijke Voorziening BRO. Dit hoofdstuk is bedoeld voor de lezer die een globaal idee wil krijgen hoe de geautomatiseerde gegevensuitwisseling van de BRO werkt.
Hoofdstuk 3 beschrijft vervolgens het koppelvlak van de CPT uitgiftewebservice in technische termen: de Application Programming Interface (API). De functionaliteit voor opvragen van de kengegevens van een verzameling registratieobjecten die voldoen aan bepaalde zoekcriteria en de functionaliteit voor het opvragen van de gegevens van een bepaald registratieobject komen daarbij aan bod.
De hoofdstukken 4 en verder beschrijven het UML-model van de uitgiftewebservice. Dezelfde structuur is van toepassing op de WSDL en XSD-bestanden van de uitgiftewebservice.
Bijlage A bevat de vertalingen van de berichten en de codelijsten van het Engels naar het Nederlands. Deze bijlage is een praktisch hulpmiddel aangezien de Engelstalige XML-berichten gebaseerd zijn op Nederlandse definities uit het uitgiftehandboek en de catalogus.

Referenties

Titel

Vindplaats

[1] Nederlandse Overheid Referentie Architectuur (NORA)

NORA website

[2] Digikoppeling

Logius website

[3] NEN3610

Geonovum website

[4] Guidance and profile of GML for use with Aviation Data

OGC 12-028 http://www.opengis.net/doc/dp/gml-aviation-guidance

Versiehistorie

Versie

Datum

Omschrijving

1.0

27 juni 2017

Bijgewerkt n.a.v. review commentaar.

1.0.1

25 juli 2017

Stereotype FeatureType toegevoegd aan RegistrationObject

1.0.2

27 juli 2017

Tabel in 14.1.3 gecompleteerd i.r.t. hoofdstuk 8

1.0.3

2 augustus 2017

Paragraaf 7.4, 7.13 en 14.3: nilValue in DataRecord -999999 i.p.v. 999999 (artf52175).

1.1

december 2017

Aangepast op de BRO-keten (Project Start Architectuur versie 1.0)

1.1.128 januari 2019Aangepast ‘deliveryAccountableParty’ en contactgegevens BRO Servicedesk.

Contactinformatie

Voor vragen, suggesties of opmerkingen over de inhoud van dit document kunt u contact opnemen met de BRO Servicedesk. Bel 088 – 8644 999 of mail naar support@broservicedesk.nl.

 Verder vindt u op basisregistratieondergrond.nl verdere technisch inhoudelijke instructie voor het aanleveren van gegevens aan de landelijke voorziening BRO.

Opvragen van sondeeronderzoek

Inleiding

Dit hoofdstuk beschrijft hoe het opvragen van gegevens van het CPT-registratieobject werkt. Hierbij wordt ingegaan op de algemene technische werking van het koppelvlak van de CPT uitgiftewebservice. Er wordt uitgelegd hoe het systeem van de data-afnemer en de Landelijke Voorziening BRO communiceren en welke standaarden worden gehanteerd. Dit geeft een beeld hoe de geautomatiseerde gegevensuitwisseling met de BRO werkt.

Communicatie tussen twee systemen

Een data-afnemer kan geautomatiseerd gegevens van het CPT-registratieobject opvragen bij de BRO via de CPT uitgiftewebservice. Het systeem van de dataleverancier stuurt hiervoor een verzoek (request) aan de CPT uitgiftewebservice van de BRO. Het systeem van de BRO reageert op dit verzoek met een antwoord (response). Deze response bevat het resultaat van de verwerking van het request. Onderstaande afbeelding geeft dit schematisch weer.


Via het verzoek aan de CPT uitgiftewebservice kunnen met verschillende bewerkingen (operaties) verschillende gegevensverzamelingen worden opgevraagd. Elke operatie heeft een eigen request en een eigen response. De CPT uitgiftewebservice is daarmee het koppelvlak ofwel de Application Programming Interface (API) voor de uitgifte van CPT.

Communicatie standaarden








De communicatie tussen het systeem van de data-afnemer en het BRO-systeem verloopt over een aantal lagen. In de volgende afbeelding is per laag aangegeven welke communicatiestandaard van toepassing is.

De keuzes van de communicatiestandaarden die zijn gebruikt bij de inrichting van het BRO-systeem zijn gebaseerd op de NORA (Nederlandse Overheid Referentie Architectuur [1]) en de Digikoppeling specificaties ([2]).








Gegevens- en berichtenstandaarden








Omdat alle registratieobjecten van de BRO een relatie hebben met een locatie op het aardoppervlak, zijn de gegevens en berichten volgens de NEN3610 standaard ([3]) gemodelleerd.








Logistieke standaard








<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="9d076b2f-5048-4bca-8066-99fca0b706c7"><ac:parameter ac:name="">_Toc410641244</ac:parameter></ac:structured-macro><ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="9a078b9b-099a-49d1-a53c-3e067875f61a"><ac:parameter ac:name="">_Toc421040311</ac:parameter></ac:structured-macro><ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="5d26096c-67cb-4ea3-888d-aab224898612"><ac:parameter ac:name="">_Toc421040514</ac:parameter></ac:structured-macro>Als logistieke standaard is voor de BRO het 2W-be profiel van Digikoppeling ([2]) gehanteerd. Het koppelvlak is daarom gerealiseerd als een WUS-webservice waarvoor een aantal onderliggende standaarden zijn voorgeschreven, waaronder WSDL 1.0 en SOAP 1.1. In onderstaande afbeelding is dat schematisch weergegeven.

Het WSDL-document (Web Service Definition Language) beschrijft in technische termen de volledige API (Application Programming Interface) van de CPT uitgiftewebservice (zie hoofdstuk 3). Het beschrijft de operaties, inclusief request en response, maar ook het protocol (in dit geval SOAP) waarmee request en response worden uitgewisseld en de URL waarop de webservice benaderd kan worden.
SOAP (Simple Object Access Protocol) is een protocol voor het versturen van berichten. Een SOAP bericht bestaat uit een Envelope met daarin de Header en de Body. De Body bevat het eigenlijke XML-bericht dat uitgewisseld wordt. Ieder XML-bericht dat als onderdeel van een SOAP-bericht met het BRO-systeem uitgewisseld wordt, is beschreven in een aantal BRO XML-schema's (XSD). Deze structuur van een SOAP-bericht is in de volgende afbeelding samengevat.

<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="76c71bac-e219-424d-978e-10435e099ebd"><ac:parameter ac:name="">_Hlk483394571</ac:parameter></ac:structured-macro>De XML-schema's (XSD) volgen de gegevensdefinities van de catalogus nauwkeurig, maar soms leidt de toepassing van de NEN3610 standaard tot afwijkingen. Daar waar wordt afgeweken van de catalogus wordt dat expliciet toegelicht. Omdat de XSD is uitgewerkt in het Engels en de catalogus in het Nederlands is beschreven, is in bijlage A een vertaling van de berichtgegevens opgenomen.








Netwerkstandaard

Als netwerkstandaard wordt TCP/IP over het internet gehanteerd.

Toegangscontrole








Voordat een bericht terecht komt in een operatie van de applicatie laag, vindt er een toegangscontrole plaats binnen de logistieke laag. Dit gebeurt conform de Digikoppeling standaard (zie referentie [2]). De toegangscontrole bestaat uit versleuteling, identificatie, authenticatie en autorisatie. Nadere details staan beschreven in paragraaf 3.3.








API voor het opvragen van geotechnisch sondeeronderzoek

Inleiding

In dit hoofdstuk wordt het koppelvlak in technische termen beschreven: de API (Application Programming Interface). Hierbij staan de twee functionaliteiten centraal: opvragen van kengegevens en opvragen van gegevens.
Elke functionaliteit heeft verschillende operaties. Deze worden beschreven in paragraaf 3.2. Paragraaf 3.3 beschrijft het patroon van verwerking van de operaties. De daaropvolgende paragrafen beschrijven de mapping van de berichten uit het uitgiftehandboek op requests en responses in de API. De inhoud van de requests/responses wordt beschreven in hoofdstuk 4 en verder.

Operaties

De API voor het opvragen van geotechnisch sondeeronderzoek biedt de data-afnemer basale functionaliteit. Deze functionaliteit wordt gerealiseerd door twee operaties van de CPT uitgiftewebservice:

  • dispatchCharacteristics voor het opvragen van de kengegevens van geotechnisch sondeeronderzoek, die voldoen aan bepaalde kenmerken.
  • dispatchData voor het opvragen van de gegevens van een bepaald geotechnisch sondeeronderzoek.


Onderstaande tabel bevat een samenvatting van de operaties en de bijbehorende requests:

Operatie

Request

Response

dispatchCharacteristics

dispatchCharacteristicsRequest

dispatchCharacteristicsResponse

dispatchData

dispatchDataRequest

dispatchDataResponse


Elke operatie heeft een eigen request en response, die de verschillende verzoeken en antwoorden realiseren die in het uitgiftehandboek beschreven zijn. In de volgende paragrafen wordt deze mapping kort toegelicht.

Verwerking

De verwerking van een uitgifteverzoek verloopt volgens een vast patroon. Een uitgifte operatie begint bij het doen van een uitgifteverzoek door middel van een request en eindigt met de response. Het patroon van de verwerking van een uitgifte operatie is hieronder weergegeven.



Stap 1: Doen van een verzoek tot levering
Het initiatief om een operatie te beginnen ligt bij het systeem van de data-afnemer. Dat roept de betreffende operatie van de uitgiftewebservice aan met het request als parameter.
Stap 2: Uitvoeren toegangscontrole
Dit bestaat uit identificatie, authenticatie, versleuteling en autorisatie.
Voor de beveiliging van de gegevensuitwisseling worden, conform de Digikoppeling specificaties, PKIoverheid services server certificaten gebruikt. Zowel de data-afnemer als de BRO beschikt over een dergelijk certificaat. In het certificaat is een identificatie op basis van 20 cijfers opgenomen die uniek is voor de houder van het certificaat.
Op het moment dat het systeem van een data-afnemer een operatie aanroept van de webservice van het BRO-systeem wisselen beide systemen eerst hun PKIoverheid services server certificaten uit. Aan de hand van de identificatie in de certificaten weten beide partijen met wie gegevens uitwisseling plaatsvindt. De techniek van het PKIoverheid services server certificaat garandeert dat de identificatie in het certificaat ook daadwerkelijk van die partij is (authenticatie).
Als authenticatie succesvol is verlopen, worden beide certificaten vervolgens gebruikt om al het dataverkeer tussen de systemen te versleutelen. Deze versleuteling maakt het voor derden onmogelijk om de data te lezen of te wijzigen.
Voor het opvragen van gegevens bij het BRO-systeem zijn rechten nodig. Aan de hand van de identificatie in het certificaat wordt bepaald of het systeem van de data-afnemer geautoriseerd is de operatie uit te voeren. Als hierbij een fout optreedt, ontvangt de data-afnemer een melding met een http-statuscode.
Als niet wordt voldaan aan de toegangscontrole, dan leidt dit tot:

  • Een http '401 Unauthorized' foutmelding.
  • Of een 'ssl error invalid certificate' foutmelding.
  • Of een andere http-foutmelding met een http-statuscode anders dan '200 OK'.

Stap 3: Controleren verzoek
Als de toegangscontrole succesvol is verlopen, dan wordt het request technisch en inhoudelijk gecontroleerd.
De technische controle vindt plaats door het request te valideren op basis van de XSD. Als hierbij fouten gevonden worden, dan worden deze beschouwd als een technische fout van het systeem van de data-afnemer en teruggegeven als een parseFault.
De inhoudelijke controle vindt plaats door het request te controleren volgens de regels die zijn gedefinieerd in de catalogus of het uitgiftehandboek (business rules). Deze regels zijn niet in de XSD vastgelegd, maar worden gecontroleerd door de programmatuur van het BRO-systeem. Voorbeelden van controles zijn:

  • Is een waarde niet groter dan de toegestane maximale waarde?
  • Voldoet een waarde aan de toegestane waardes voor een gegeven?

Als hierbij fouten worden gevonden, dan worden deze beschouwd als een gebruiksfout en teruggegeven in een response bericht.
Stap 4: Verzamelen van gegevens
Als alle controles succesvol zijn verlopen dan verzamelt het BRO-systeem de opgevraagde gegevens en wordt het resultaat teruggegeven in een response bericht.

Berichten bij het opvragen van kengegevens

Bij het opvragen van kengegevens zijn drie berichten van toepassing: een verzoek tot levering, een bericht van afwijzing en een bericht van verzending.

Request: verzoek tot levering van kengegevens

Het verzoek tot levering van kengegevens wordt gerealiseerd door DispatchCharacteristicsRequest. Onderstaande figuur geeft de mapping weer van het verzoek tot levering in het uitgiftehandboek op het datatype DispatchCharacteristicsRequest in dit document (zie paragraaf 6.1), zoals gebruikt door de dispatchCharacteristics operatie (zie hoofdstuk 5).


Het (platte) element requestReference is een voor de data-afnemer unieke aanduiding van het request.
Het (gestructureerde) element criteria specificeert de afzonderlijke kenmerken waaraan de registratieobjecten moeten voldaan.
Zie paragraaf 6.1 voor nadere details.

Response: bericht van afwijzing

Het uitgiftehandboek benoemt als mogelijke reactie op een uitgifteverzoek een bericht van afwijzing. De webservice gebruikt hiervoor een response van het datatype DispatchCharacteristicsResponse.


Het handboek definieert een aantal berichten als antwoord op een uitgifteverzoek. In de SOAP webservice definities mag elk request slechts één response hebben. Daarom is het element responseType toegevoegd, om de betekenis van de response te duiden. In dit geval heeft het element responseType de vaste waarde rejection.
De waarde van het element requestReference is overgenomen uit het request. De waarde van de overige elementen wordt toegekend door de webservice. Het element rejectionReason bevat een waarde uit de tabel met gebruiksfouten; zie het uitgiftehandboek.
Als deze response wordt gegeven omdat er een of meer gebruiksfouten in het element criteria in het request zijn geconstateerd, dan is de waarde van rejectionReason "er zijn 1 of meer fouten geconstateerd in de kenmerkenverzameling" en volgen er na dit element een of meer criterionErrors.
Zie paragraaf 6.2 voor nadere details.

Response: bericht van verzending

Het uitgiftehandboek benoemt als mogelijke reactie op een uitgifteverzoek een bericht van verzending. De webservice gebruikt hiervoor een response van het datatype DispatchCharacteristicsResponse.


Het handboek definieert een aantal berichten als antwoord op een uitgifteverzoek. In de SOAP webservice definities mag elk request slechts één response hebben. Daarom is het element responseType toegevoegd, om de betekenis van de response te duiden. In dit geval heeft het element responseType de vaste waarde dispatch.
De waarde van het element requestReference is overgenomen uit het request. De waarde van de overige elementen wordt toegekend door de webservice. Het tijdstip van verzending en het aantal uitgiftedocumenten staan in de elementen dispatchTime en numberOfDocuments. De kengegevens van de objecten, die voldoen aan de kenmerkenverzameling in het request, staan in de lijst met dispatchDocuments.
Zie paragraaf 6.2 voor nadere details.

Berichten bij opvragen van gegevens

Bij het opvragen van gegevens van een bepaald registratieobject zijn drie berichten van toepassing: een verzoek tot levering, een bericht van afwijzing en een bericht van verzending.

Request: verzoek tot levering

Onderstaande figuur geeft de mapping weer van het uitgifteverzoek in het uitgiftehandboek op het datatype DispatchDataRequest in dit document (zie paragraaf 6.3), zoals gebruikt door de dispatchData operatie (zie hoofdstuk 5).


Het element requestReference is een voor de data-afnemer unieke aanduiding van het request.
Het element broId is de unieke aanduiding van het registratieobject waarvan de gegevens worden opgevraagd.
Zie paragraaf 6.3 voor nadere details.

Response: bericht van afwijzing

Het uitgiftehandboek benoemt als mogelijke reactie op een uitgifteverzoek een bericht van afwijzing. De webservice gebruikt hiervoor een response van het datatype DispatchDataResponse.


Het handboek definieert een aantal berichten als antwoord op een uitgifteverzoek. In de SOAP webservice definities mag elk request slechts één response hebben. Daarom is het element responseType toegevoegd, om de betekenis van de response te duiden. In dit geval heeft het element responseType de vaste waarde rejection.
De waarde van het element requestReference is overgenomen uit het request. De waarde van de overige elementen wordt toegekend door de webservice. Het element rejectionReason bevat een waarde uit de tabel met gebruiksfouten; zie het uitgiftehandboek.
Zie paragraaf 6.4 voor nadere details.

Response: bericht van verzending

Het uitgiftehandboek benoemt als mogelijke reactie op een uitgifteverzoek een bericht van verzending. De webservice gebruikt hiervoor een response van het datatype DispatchDataResponse.


Het handboek definieert een aantal berichten als antwoord op een uitgifteverzoek. In de SOAP webservice definities mag elk request slechts één response hebben. Daarom is het element responseType toegevoegd, om de betekenis van de response te duiden. In dit geval heeft het element responseType de vaste waarde dispatch.
De waarde van het element requestReference is overgenomen uit het request. De waarde van de overige elementen wordt toegekend door de webservice. Het tijdstip van verzending staat in het elementen dispatchTime. Het element dispatchDocument bevat de gegevens over de opgevraagde sondeeronderzoek.
Zie paragraaf 6.4 voor nadere details.

Berichten bij technische fouten

Er zijn twee soorten berichten mogelijk bij een technische fout: een softwarefout of een systeemfout. In de volgende paragrafen wordt dit toegelicht.

Softwarefout

Als bij de technische controle van het request fouten in het verzoek en/of de kenmerkenverzameling worden gevonden (bijvoorbeeld het request is niet een welgevormd XML bericht of het request 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 melding in de vorm van een parseFault. Zie paragraaf 8.16 voor nadere details.

Systeemfouten

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 systeemfout in het BRO-systeem. De BRO stuurt dan een bericht in de vorm van een generieke, niet gemodelleerde Fault uit de package SOAP. Zie paragraaf 8.24 voor nadere details.

Modellering van de interface

Dit hoofdstuk en de volgende hoofdstukken beschrijven in detail de interface van de CPT uitgiftewebservice aan de hand van een UML-model.

Overzicht

De interface beschrijving is onderverdeeld in verschillende packages. Deze paragraaf beschrijft de samenhang van de packages. Deze onderverdeling is ook van toepassing op de WSDL en XSD-bestanden. De hoofdstukken 5 en verder beschrijven elk een van de packages.
Onderstaande figuur geeft een overzicht van de packagestructuur.


De interfaces van de innamewebservice en de uitgiftewebservice zijn gemodelleerd in de iscpt en dscpt packages.
Om de beheerbaarheid van de modellen en de software te vergroten, is gestreefd naar herbruikbaarheid van gemodelleerde gegevenstypes. Er is bijvoorbeeld veel overlap in de gegevens in het registratieverzoek en de objectgegevens bij uitgifte. Door deze overlappende gegevens onder te brengen in een gemeenschappelijk model voor inname en uitgifte is hergebruik mogelijk.
De gegevenstypes voor de inname- respectievelijk uitgiftewebservice zijn gemodelleerd in package iscpt-messages respectievelijk dscpt-messages.
Herbruikbare gegevenstypes die specifiek zijn voor CPT zijn gemodelleerd in package cptcommon.
Gegevenstypes die herbruikbaar zijn voor alle registratieobjecten van de BRO zijn gemodelleerd in package brocommon.
CPT maakt verder op diverse manieren gebruik van concepten uit diverse OGC-standaarden. Aan het gebruik van deze standaarden kleven enkele praktische bezwaren:

  • De standaarden zijn omvangrijk en slechts een klein deel wordt gebruikt in de BRO.
  • De software om de standaarden te ondersteunen is omvangrijk.
  • Het gebruik van de standaarden is niet eenvoudig.

Om deze bezwaren weg te nemen zijn in overleg met GeoNovum profielen opgesteld. Rand voor waarde bij het opstellen van de profielen was dat berichten die voldoen aan de profielen ook moeten voldoen aan de OGC-standaarden. De profielen zijn gemodelleerd in de packages swe-profile, sa-profile, om-profile, gml-profile en xlink-profile.
De volgende hoofdstukken beschrijven deze packages als gegevensmodel voor de CPT uitgiftewebservice. De packages iscpt en iscpt-messages worden buiten beschouwing gelaten, aangezien deze de innamewebservice betreffen.

Modelleerregels

In het UML-model worden de volgende stereotypes gebruikt om bepaalde functionaliteit te duiden.

CodeList

De catalogus maakt een onderscheid in beheerde en niet-beheerde enumeraties.
Het domein van een beheerde enumeratie is een uitbreidbare opsomming van toegestane waarden. Er wordt voor een beheerde enumeratie gekozen als niet alle waarden bekend zijn en uitbreiding mogelijk moet zijn (zie paragraaf 4.2.3 voor niet-beheerde enumeraties).
Het stereotype CodeList wordt in UML gebruikt om aan te geven dat een datatype een beheerde enumeratie is. In de XSD leidt dit tot een complexType wat een restrictie is van het complexType CodeWithAuthority uit de package gml-profile (zie paragraaf 12.3).

DataType

Het stereotype DataType wordt in UML gebruikt om aan te geven dat een datatype een niet-identificeerbaar, gestructureerd data type is. In de XSD leidt dit tot een complexType zonder een gml:id attribuut.

Enumeration

De catalogus maakt een onderscheid in beheerde en niet-beheerde enumeraties.
Het domein van een niet-beheerde enumeratie is een vaste, limitatieve opsomming van toegestane waarden. Er wordt voor een niet-beheerde enumeratie gekozen als alle waarden bekend zijn en uitbreiding niet nodig is (zie paragraaf 4.2.1 voor beheerde enumeraties).
Het stereotype Enumeration wordt in UML gebruikt om aan te geven dat een datatype een niet-beheerde enumeratie is. In de XSD leidt dit tot een simpleType als restrictie van het type string met een lijst van benoemde waarden. Voorbeeld:

< simpleType name= "IndicationYesNoEnumeration" >
< restriction base= "string" >
<enumera tion value= "ja" >
<enumera tion value= "nee" >
</ restriction >
</ simpleType >

FeatureType

Het stereotype FeatureType wordt in UML gebruikt om aan te geven dat een klasse een identificeerbaar fenomeen in de werkelijkheid representeert, dat direct of indirect is geassocieerd met een locatie relatief ten opzichte van de aarde. In de XSD leidt dit tot een complexType dat is afgeleid van AbstractFeature uit de package gml-profile (zie paragraaf 12.1). In een XML-bericht heeft een object van deze klasse een gml:id attribuut.

Type

Het stereotype Type wordt in UML gebruikt om aan te geven dat een klasse een identificeerbaar object anders dan een FeatureType (zie paragraaf 4.2.4) representeert. In de XSD leidt dit tot een complexType dat is afgeleid van AbstractGML uit de package gml-profile (zie paragraaf 12.2). In een XML-bericht heeft een object van deze klasse een gml:id attribuut (zie paragraaf 12.1).

Union

Het stereotype Union wordt in UML gebruikt om aan te geven dat in een voorkomen precies een van de eigenschappen aanwezig is (polymorfisme). In de XSD wordt dit gerealiseerd als een choice.

Voidable

Het stereotype Voidable wordt in UML gebruikt om aan te geven dat een element aanwezig is maar geen waarde heeft. De modellering in UML en XSD en het gebruik in XML is afhankelijk van het datatype of domein van het betreffende attribuut:

  • Codelijst, enumeratie
    • De uitwerking is opgenomen in de lijst met toegestane waarden.
    • In het UML-model is het stereotype Voidable niet opgenomen.
    • In een XSD-bestand krijgt zo'n element niet het attribuut nilllable="true".
    • Als in een XML-bericht het element wordt opgenomen, dan heeft het element een waarde uit de codelijst.
  • Integer, double, string
    • Het gegeven is aanwezig, maar heeft geen waarde.
    • In het UML-model is het stereotype Voidable opgenomen voor deze situatie.
    • In een XSD-bestand krijgt zo'n element het attribuut nilllable="true".
    • In een XML-bericht wordt in voorkomende gevallen het element opgenomen, met een lege waarde en met het attributen xsi:nil="true".
    • Er wordt geen onderscheid gemaakt in de waarden geen, onbekend, o.i.d.
  • PartialDate
    • Voor IMBRO/A-gegevens kan de situatie zich voordoen, dat er wel een waarde is, maar dat deze onbekend is bij de dataleverancier.
      • Voor deze situatie voorziet het UML-model de optie voidReason met als vaste waarde onbekend.
      • In een XSD-bestand krijgt zo'n element niet het attribuut nilllable="true".
      • In een XML-bericht wordt het element opgenomen, met als kind-element voidReason met als waarde onbekend.
    • Daarnaast kan (tot nu toe alleen bij IMBRO/A) sprake zijn van het feit, dat het gegeven überhaupt geen waarde heeft.
      • In het UML-model wordt het stereotype Voidable opgenomen.
      • In een XSD-bestand krijgt zo'n element het attribuut nilllable="true".
      • In een XML-bericht wordt het element opgenomen met een lege waarde (er is geen kind-element voidReason aanwezig).

Package dscpt – de uitgiftewebservice interface

De onderstaande figuur geeft het interface van de CPT uitgiftewebservice weer:


Onderstaande tabel bevat een samenvatting van operaties met bijbehorende datatype van het request en response:

Operatie

Request

Response

dispatchCharacteristics

dispatchCharacteristicsRequest

dispatchCharacteristicsResponse

dispatchData

dispatchDataRequest

dispatchDataResponse


Zie hoofdstuk 6 voor de request en response datatypes uit de package dscpt-messages. Zie paragraaf 3.6 voor de afhandeling van technische fouten.

De WSDL

De CPT uitgiftewebservice wordt technisch volledig beschreven door de WSDL van de CPT uitgiftewebservice (dscpt.wsdl). De onderdelen van dit bestand worden hieronder kort toegelicht.

Types

Het onderdeel types in een WSDL definieert een XML-schema met daarbinnen XML-types en XML-elementen. Voor de CPT uitgiftewebservice zijn deze opgenomen in een afzonderlijke berichten XSD (dscpt-messages.xsd) die in het types element wordt geïmporteerd.

Message

Het onderdeel message in een WSDL specificeert de berichten die per operatie worden uitgewisseld, uitgedrukt in parts. In de parts worden XML-elementen uit het types onderdeel van de WSDL gebruikt. Voor elke operatie wordt een request message en een response message gespecificeerd.

PortType

Het onderdeel portType in een WSDL specificeert de beschikbare functionaliteit van de webservice in de vorm van een of meer operaties (operations) met hun request en response messages en de parseFault.

Binding

Het onderdeel binding in een WSDL specificeert details over het transportmechanisme dat gebruikt wordt voor de webservice, waaronder het communicatieprotocol en het formaat van de input en de output. Digikoppeling schrijft als binding SOAP 1.1, 'document-literal wrapped' met als transport binding http voor. Voor elke operatie is de style 'document' en de input en output use 'literal'.

Service

Het onderdeel service in een WSDL beschrijft volgens welke portType en op welke URL de webservice gepubliceerd is.

De XSD-bestanden

In de XSD-bestanden worden alle XML types en elementen gedefinieerd die gebruikt worden in de WSDL voor de CPT uitgiftewebservice. In alle XSD-bestanden van de BRO wordt, conform de NEN3610 voorschriften, gebruik gemaakt van verschillende XSD-bestanden van de internationale W3C en OGC-standaarden.
Deze schema's worden in de navolgende hoofdstukken beschreven, elk schema in een eigen hoofdstuk. De opbouw van een element of datatype in een schema wordt afgebeeld in een diagram en waar relevant worden bijzonderheden in de tekst toegelicht. Voor de inhoudelijke betekenis van de afzonderlijke gegevens wordt verwezen naar het uitgiftehandboek en de catalogus van de CPT.
De XSD-bestanden zijn opgesteld in het Engels. De vertaling naar Nederlandse termen die gebruikt worden in het uitgiftehandboek en in de catalogus staat in bijlage A (zie paragraaf 14.1).

Package dscpt-message – de berichten XSD

De package dscpt-messages bevat datatypes voor de requests, responses, kenmerkenverzameling en uitgiftedocumenten voor de uitgifteverzoeken.

DispatchCharacteristicsRequest

Het datatype DispatchCharacteristicsRequest bevat alleen een (plat) element requestReference en een (gestructureerd) element criteria.


Het element criteria bevat de kenmerkenverzameling, inclusief een verplicht element area. Alleen kengegevens van registratieobjecten, waarvan de gestandaardiseerde locatie (zie paragraaf 8.26) valt binnen het opgegeven gebied, worden uitgeleverd.
Zie het uitgiftehandboek voor nadere details over de betekenis en toepassing van de kenmerkenverzameling.

CriteriaSet

Het datatype CriteriaSet bevat een aantal optionele elementen voor de kenmerkenverzameling.


Het datatype CriteriaSet is een specialisatie van CriteriaSet uit de package brocommon (zie paragraaf 8.8), waaraan enkele CPT specifieke elementen en een optionele verzameling Parameters worden toegevoegd.
Merk op dat CriteriaSet uit de package brocommon een verplicht element area bevat (zie paragraaf 8.2), waarin of een boundingBox (zie paragraaf 12.5) of een enclosingCircle (zie paragraaf 8.5) moet worden opgegeven.

Parameters

Met een element van het datatype Parameters kan een data-afnemer aangeven dat hij geïnteresseerd is in sondeeronderzoeken waarvoor een specifieke gegeven beschikbaar is.


Indien een element de waarde Ja heeft, dan worden alleen sonderingen uitgegeven waar het desbetreffende element gemeten is. De waarde Ja is de enige waarde, die zin heeft. De waarde Nee heeft geen betekenis en leidt tot een gebruiksfout, omdat selecteren van sonderingen op basis van een element dat niet gemeten is geen toegevoegde waarde heeft. Afwezig zijn van een element in de lijst met parameters betekent dat een sondering deel kan zijn van de selectie ongeacht of het desbetreffende element gemeten is of niet.

DispatchCharacteristicsResponse

Het datatype DispatchCharacteristicsResponse is een specialisatie van DispatchResponse in de package brocommon (zie paragraaf 8.13), waaraan het een element numberOfDocuments en een optionele lijst met dispatchDocuments toevoegt.


Merk op dat DispatchResponse in package brocommon naast de platte elementen ook een optionele lijst met criterionErrors bevat. Zie paragraaf 3.4.2 voor nadere informatie hierover en over welke elementen onder welke omstandigheden verwacht kunnen worden.
De kardinaliteit van de lijst met dispatchDocuments is onbegrensd (maxOccurs="unbounded"), maar het BRO-systeem beperkt de lijst softwarematig tot maximaal 2000 uitgiftedocumenten.

DispatchCharacteristics

Het datatype DispatchCharacteristics bevat de kengegevens van een CPT-registratieobject.


Het datatype heeft het stereotype Union (zie paragraaf 4.2.6), waarmee wordt aangegeven dat het uitgiftedocument polymorf is en dat voor ieder element één van de twee mogelijke alternatieven uitgegeven zal worden:

  • met de naam BRO_DO en van het datatype DeregisteredObject (zie paragraaf 8.11) met de kengegevens van een sondeeronderzoek dat voldoet aan de criteria in het request en dat uit registratie is genomen.
  • met de naam CPT_C en van het datatype Characteristics (zie paragraaf 6.2.2) met de kengegevens van een sondeeronderzoek dat voldoet aan de criteria in het request en dat niet uit registratie is genomen.

In de XSD is dit gerealiseerd als een choice uit een lijst van elementen met paarsgewijs de naam en het datatype zoals aangegeven in bovenstaande figuur. Merk op dat de naam van het alternatief opgenomen moet worden in het element dispatchDocument; daarmee wordt bij een gegeven verzameling kengegevens eenduidig bekend welk alternatief gekozen is voordat de feitelijke elementen van dat alternatief aan bod komen. Voorbeeld:

<dispatchCharacteristicsResponse xmlns = "http://www.broservices.nl/xsd/dscpt/1.1"
xmlns:brocom = "http://www.broservices.nl/xsd/brocommon/3.0" >
<brocom:responseType>dispatch</brocom:responseType>
...
<numberOfDocuments>1</numberOfDocuments>
<dispatchDocument>
<CPT_C>
<broId>CPT123456789012</broId>
...
</CPT_C>
</dispatchDocument>
</dispatchCharacteristicsResponse>

Characteristics

Het datatype DispatchCharacteristics bevat de kengegevens van een CPT-registratieobject dat niet uit registratie is genomen.


Het datatype Characteristics is een specialisatie van Characteristics in de package brocommon (zie paragraaf 8.3), waaraan het een aantal CPT specifieke elementen toevoegt.
Merk op dat het element startTime een datatype TM_Position heeft (zie paragraaf 12.9). Reden hiervoor is dat startTime een datum en een tijd moet kunnen bevatten, maar dat onder het IMBRO/A-regime ook een onnauwkeurige aanduiding mag zijn aangeleverd (alleen een datum, of alleen een jaartal en een maand, of alleen een jaartal, of in het geheel geen waarde).

DispatchDataRequest

Het datatype DispatchDataRequest is het standaard datatype uit package brocommon (zie paragraaf 8.12).


Het request bevat twee elementen: een requestReference en het broId van het CPT-registratieobject dat de data-afnemer opvraagt.

DispatchDataResponse

Het datatype DispatchDataResponse is een specialisatie van DispatchResponse in de package brocommon (zie paragraaf 8.13), waaraan het een CPT specifiek element dispatchDocument toevoegt.


Merk op dat DispatchResponse in package brocommon naast de platte elementen ook een optionele lijst met criterionErrors bevat. Zie paragraaf 3.5.2 voor nadere informatie hierover en over welke elementen onder welke omstandigheden verwacht kunnen worden.

DispatchData

Het datatype DispatchData bevat de gegevens van een CPT-registratieobject.


Het datatype DispatchData heeft het stereotype Union (zie ook paragraaf 4.2.6), waarmee wordt aangegeven dat het uitgiftedocument polymorf is. Onderstaande tabel geeft aan onder welke omstandigheden welk alternatief zal worden uitgegeven:

Object is uit registratie genomen

Data-afnemer is bronhouder of dataleverancier

Alternatief

Ja

Doet er niet toe

BRO_DO

Nee

Ja

CPT_O_DP

Nee

Nee

CPT_O


De eerste variant is van het type DeregisteredObject in de package brocommon (zie paragraaf 8.11), de overige varianten zijn van het type GeotechnicalCPTSurveyType.

GeotechnicalCPTSurveyType

Het datatype GeotechnicalCPTSurveyType bevat de gegevens van een CPT-registratieobject dat niet uit registratie is genomen.


Het datatype GeotechnicalCPTSurveyType heeft het stereotype FeatureType (zie paragraaf 4.2.4), wat aangeeft dat een object van dit datatype een fenomeen in de werkelijkheid representeert, dat direct of indirect is geassocieerd met een locatie relatief ten opzichte van de aarde.
Het datatype GeotechnicalCPTSurveyType is een specialisatie is van Registration Object in de package brocommon (zie paragraaf 8.20). De attributen die specifiek zijn voor de uitgifte van een CPT-registratieobject zijn toegevoegd. Ook zijn associaties naar RegistrationHistory en StandardizedLocation uit package brocommon toegevoegd en CPT specifieke associaties naar DeliveredLocation, DeliveredVerticalPosition, AdditionalInvestigation en ConePenetrometerSurvey.
De informatie in RegistrationHistory en StandardizedLocation worden niet aangeleverd door de dataleverancier, maar tijdens inname vastgelegd door de BRO.
De elementen objectIdAccountableParty, delivery Responsible Party en researchOperator worden alleen uitgegeven als de data-afnemer tevens bronhouder en/of dataleverancier is van het opgevraagde object. Hetzelfde geldt voor de elementen horizontalPositioningOperator binnen DeliveredLocation en verticalPositioningOperator binnen DeliveredVerticalPosition. Voor andere data-afnemers worden deze attributen weg gelaten.

Package cptcommon

De package cptcommon bevat de entiteiten en relaties, die gemeenschappelijk zijn voor zowel de CPT innamewebservice als de CPT uitgiftewebservice.

AdditionalInvestigation

Het datatype AdditionalInvestigation bevat de gegevens over een aanvullend onderzoek uitgevoerd als onderdeel van een geotechnisch sondeeronderzoek.


Het aanvullende onderzoek kan ook aanvullende gegevens bevatten over enkele verwijderde lagen.

Codelijsten

De catalogus maakt een onderscheid in beheerde en niet-beheerde enumeraties. Het stereotype CodeList wordt in UML gebruikt om aan te geven dat een datatype een beheerde enumeratie is (zie paragraaf 4.2.1).
De package cptcommon bevat een aantal codelijsten. Zie paragraaf 8.6 voor een overzicht. Voorbeeld:

ConePenetrationTest

Het datatype ConePenetrationTest bevat de feitelijke resultaten van de conuspenetratietest, uitgevoerd als onderdeel van het sondeeronderzoek.


Het datatype ConePenetrationTest is een specialisatie van CptObservation (zie paragraaf 7.7) wat op zijn beurt een extensie is van OM_Observation uit package om-profile (zie paragraaf 10.1), waardoor een element van het datatype ConePenetrationTest een verplicht attribuut gml:id heeft.
Het datatype ConePenetrationTest voegt geen elementen of relaties toe aan de van CptObservation overerfde elementen en relaties.

ConePenetrationTestResult en CPTTestResultRecord

Tijdens een conuspenetratietest wordt op meerdere dieptes een aantal parameters gemeten. Het resultaat is daarmee een dieptereeks.
Voor een element van de dieptereeks (de parameterwaarden gemeten op een bepaalde diepte) wordt gebruik gemaakt van het SWE-profiel. De CPT-datatypen die als extensies van SWE zijn gemodelleerd zijn groen aangegeven.


Het datatype CPTTestResultRecord bevat de definities van de parameters. Deze definitie hoeft voor een dieptereeks slechts eenmaal geleverd te worden. Daartoe bevat het attribuut xlink:href van het element elementType de URL die verwijst naar een XML bestand dat offline op een door TNO aangewezen server wordt geplaatst. De opbouw van dat bestand is conform een subklasse van het datatype DataRecord (zie paragraaf 11.2). Zie bijlage B voor een voorbeeld van dit bestand.
Het datatype ConePenetrationTestResult bevat de gemeten waarden van de parameters op een bepaalde diepte (één voorkomen in de dieptereeks). Zie paragraaf 11.1 voor nadere details. Een parameter waarvan de waarde niet is vastgesteld (zie paragraaf 7.15) wordt opgenomen met een dummy waarde, zoals gedefinieerd in CPTTestResultRecord. Voor sondeeronderzoek wordt hiervoor de waarde "-999999" gebruikt.

ConePenetrometer

Het datatype ConePenetrometer bevat de gegevens van het sondeerapparaat, waarmee het sondeonderzoek is uitgevoerd.


Een aantal elementen heeft het stereotype Voidable (zie paragraaf 4.2.7). Zo'n element mag onder het IMBRO/A regime een lege waarde hebben, ook als plaatselijke wrijving is bepaald, en krijgt dan het attribuut xsi:nil="true".

ConePenetrometerSurvey

Het datatype ConePenetrometerSurvey bevat de feitelijke gegevens over het sondeonderzoek. Dit datatype is een specialisatie van het abstract datatype SF_SamplingFeature uit package sa-profile (zie paragraaf 9.1), waar het zes platte elementen en zes relaties aan toevoegt.


Doel van datatype SF_SamplingFeature uit package sa-profile (zie paragraaf 9.1) is het beschrijven van een monster op basis waarvan een waarneming of een meting wordt gedaan.
Het stereotype FeatureType (zie paragraaf 4.2.4) geeft aan dat het monster direct of indirect is geassocieerd met een locatie relatief ten opzichte van de aarde, waardoor het datatype ConePenetrometerSurvey een specialisatie is van AbstractGML uit de package gml-profile (zie paragraaf 12.2) en een element van dit datatype een verplicht attribuut gml:id heeft.
Het gerelateerde element ConePenetrationTest en de optionele lijst met gerelateerde elementen DissipationTest beschrijven de meetresultaten die het gevolg zijn van het sondeonderzoek.
Onderstaande tabel geeft aan hoe de overerfde elementen (zie paragraaf 9.1) worden gebruikt in de BRO:

element

Toelichting

gml:id

Verplicht; zie paragraaf 4.2.4

sa:sampledFeature

Verplicht maar voidable. Wordt in de BRO niet gebruikt; het element is aanwezig met een lege waarde en attribuut xsi:nil="true"

sa:typesa:parametersa:relatedSamplingFeature

Optioneel. Worden niet gebruikt in de BRO; de elementen zijn afwezig.

sa:relatedObservation

Optioneel. Wordt niet gebruikt in de BRO; het element is afwezig en vervangen door ConePenetrationTest en (een optionele reeks van) DissipationTest.

CptObservation

Het datatype CptObservation is een specialisatie van OM_Observation uit package om-profile (zie paragraaf 10.1).


Het datatype CptObservation vervangt via restrictie en extensie het element result met datatype Any door een element cptResult met datatype ConePenetrationTestResult (zie paragraaf 7.4).
Zie paragraaf 10.1 voor het gebruik van de elementen en relaties van OM_Observation.
Merk op dat OM_Observation het stereotype FeatureType heeft (zie paragraaf 4.2.4), waardoor een element van het datatype CptObservation een verplicht attribuut gml:id heeft.

DeliveredLocation

Het datatype DeliveredLocation bevat de gegevens, zoals die zijn aangeleverd door de data-leverancier aan de basisregistratie ondergrond, over de plaats op het aardoppervlak waar het sondeeronderzoek heeft plaats gevonden.


Het element horizontalPositioningOperator wordt alleen uitgegeven als de data-afnemer tevens bronhouder en/of dataleverancier is van het opgevraagde object.
Het datatype DeliveredLocation bevat een element location van het datatype Point uit de package gml-profile (zie paragraaf 12.7). Voor de XML berichten heeft dit tot gevolg dat het element location twee attributen moet hebben, namelijk srsName en gml:id, en een element pos, waarin de geometrische positie volgens het in srsName aangegeven coördinatenstelsel is opgenomen.
Voorbeeld van het element DeliveredLocation in een XML-bestand:

<deliveredLocation>
<horizontalPositioningDate>
<brocom:date>2015-10-28</brocom:date>
</horizontalPositioningDate>
<horizontalPositioningMethod>DGPS50tot200cm</horizontalPositioningMethod>
<location gml:id= "BRO_0001" srsName= "urn:ogc:def:crs:EPSG::28992" >
<gml:pos>134750.000 477800.000</gml:pos>
</location>
</deliveredLocation>

DeliveredVerticalPosition

Het datatype DeliveredVerticalPosition bevat de gegevens over de positie in het verticale vlak van het beginpunt van het sondeeronderzoek.


De elementen offset, waterDepth en verticalPositioningDate hebben het stereotype Voidable (zie paragraaf 4.2.7). Zie de catalogus voor de regels wanneer de waarde van deze elementen leeg mag zijn.
Het element verticalPositioningOperator wordt alleen uitgegeven als de data-afnemer tevens bronhouder en/of dataleverancier is van het opgevraagde object.

DepthInterval

Het datatype DepthInterval geeft een diepte interval in meters aan.


De elementen beginDepth en endDepth hebben het datatype Depth (zie paragraaf 7.14) wat een diepte in meters aangeeft.

DisObservation

Het datatype DisObservation is een specialisatie van OM_Observation uit package om-profile (zie paragraaf 10.1).


Het datatype DisObservation vervangt via restrictie en extensie het element result met datatype Any door een element disResult met datatype DissipationTestResult (zie paragraaf 7.13).
Zie paragraaf 10.1 voor het gebruik van de elementen en relaties van OM_Observation.
Merk op dat OM_Observation het stereotype FeatureType heeft (zie paragraaf 4.2.4), waardoor een element van het datatype DisObservation een verplicht attribuut gml:id heeft.

DissipationTest

Het datatype DissipationTest bevat de feitelijke resultaten van een dissipatietest, uitgevoerd als onderdeel van het sondeeronderzoek.


Het datatype DissipationTest is een specialisatie van DisObservation (zie paragraaf 7.11) wat op zijn beurt een extensie is van OM_Observation uit package om-profile (zie paragraaf 10.1), waardoor een element van het datatype DissipationTest een verplicht attribuut gml:id heeft.
Het datatype DissipationTest voegt het element penetrationLength toe aan de van DisObservation overerfde elementen en relaties.

DissipationTestResult en DissipationTestResultRecord

Tijdens een dissipatietest wordt op meerdere dieptes een aantal parameters gemeten. Het resultaat is daarmee een dieptereeks.
Voor een element van de dieptereeks (de parameterwaarden gemeten op een bepaalde diepte) wordt gebruik gemaakt van het SWE-profiel. De CPT-datatypen die als extensies van SWE zijn gemodelleerd zijn groen aangegeven.


Het datatype DissipationTestResultRecord bevat de definities van de parameters. Deze definitie hoeft voor een dieptereeks slechts eenmaal geleverd te worden. Daartoe bevat het attribuut xlink:href van het element elementType de URL die verwijst naar een XML bestand dat offline op een door TNO aangewezen server wordt geplaatst. De opbouw van dat bestand is conform een subklasse van het datatype DataRecord (zie paragraaf 11.2). Zie bijlage B voor een voorbeeld van dit bestand.
Het datatype DissipationTestResult bevat de gemeten waarden van de parameters op een bepaalde diepte (één voorkomen in de dieptereeks). Zie paragraaf 11.1 voor nadere details. Een parameter waarvan de waarde niet is vastgesteld wordt opgenomen met een dummy waarde, zoals gedefinieerd in DissipationTestResultRecord. Voor sondeeronderzoek wordt hiervoor de waarde "-999999" gebruikt.

Meetwaarden

De package cptcommon bevat een aantal meetwaarden, dat wil zeggen datatypes die de waarde uitdrukken in een zekere eenheid. In de catalogus zijn deze attributen gespecificeerd met getalswaarde.
In de koppelvlakdefinitie is ervoor gekozen om deze types naar fysische grootheid te modelleren als extensie van het datatype Measure uit de package gml-profile (zie paragraaf 12.6) en met het stereotype DataType. Dit heeft als voordeel, dat er minder types nodig zijn en dat de meeteenheid expliciet kan worden vastgelegd in het attribuut uom (unit of measure). Zie onderstaande figuur.


Zie paragraaf 4.2.2 voor nadere details over het stereotype DataType.
Het formaat in de constraint syntax wordt niet door de XSD afgedwongen, maar wordt door de webservice softwarematig gecontroleerd. Zie onderstaande figuur voor een overzicht van de meetwaarden met hun formaat en eenheid.

Voorbeeld van een element met een zo'n datatype in een GML bericht:

<coneDiameter uom= "mm" >42</coneDiameter>

Parameters

Het datatype Parameters geeft aan welke meetparameters tijdens de conuspenetratietest (zie paragraaf 7.4) als onderdeel van het sondeonderzoek (zie ConePenetrometerSurvey in paragraaf 7.6) zijn vastgesteld.

Processing

Het datatype Processing bevat een globale karakterisering van de bewerking die de resultaten van het sondeonderzoek hebben ondergaan.

RemovedLayer

Het datatype RemovedLayer bevat gegevens over een verwijderde laag (zie de catalogus), verkregen als onderdeel van een aanvullend onderzoek (zie AdditionalInvestigation, paragraaf 7.1) bij een geotechnisch sondeeronderzoek.

Trajectory

Het datatype Trajectory bevat de diepte van het begin en het eind van de weg die de sondeerconus in de ondergrond heeft afgelegd.


Het element predrilledDepth heeft het stereotype Voidable (zie paragraaf 4.2.7). Als geen waarde beschikbaar is, dan moet het element opgenomen worden met een lege waarde en een attribuut xsi:nil="true".

ZeroLoadMeasurement

Het datatype ZeroLoadMeasurement bevat de meetresultaten meting van een of meerdere parameters met de sondeerconus in onbelaste situatie.


Zie ConePenetrometer in paragraaf 7.5 en de catalogus voor nadere informatie.

Package brocommon

De package brocommon bevat de entiteiten en relaties, die gemeenschappelijk zijn voor alle registratieobjecten.

AbortReason

Zie ParseFault in paragraaf 8.16.

Area

Het datatype Area geeft de begrenzing aan van een geografisch gebied aan het aardoppervlak.


Het datatype heeft een stereotype Union (zie paragraaf 4.2.6) wat aangeeft dat óf een enclosingCircle (zie paragraaf 8.5) óf een boundingBox (zie paragraaf 12.5) moet worden opgenomen.

Characteristics

Het datatype Characteristics bevat de registratieobject onafhankelijke kengegevens van een registratieobject dat niet uit registratie is genomen.


Het datatype Characteristics bevat naast enkele platte elementen ook twee gestructureerde elementen deliveredLocation en standardizedLocation, beiden van het datatype Point uit de package gml-profile (zie paragraaf 12.7). Het element standardizedLocation wordt niet aangeleverd door de dataleverancier, maar tijdens inname vastgelegd door de BRO.

ChamberOfCommerceNumber

Het datatype ChamberOfCommerceNumber bevat het Kamer van Koophandel nummer.


In de XSD is dit een extensie van het type string. Merk op dat het formaat in de constraint Value niet door de XSD wordt afgedwongen, maar dat dit softwarematig door het BRO-systeem wordt gecontroleerd.

Circle

Het datatype Circle geeft een cirkelvormige begrenzing aan van een gebied aan het aardoppervlak.


De cirkel wordt gedefinieerd door het middelpunt (element center met datatype Doublelist; zie paragraaf 12.4) en de straal (element radius met datatype Radius, een lengtemaat in kilometers; zie paragraaf 12.6). Het attribuut srsName geeft aan in welk coördinatensysteem het middelpunt is uitgedrukt (zie paragraaf 12.7).

CoordinateTransformation

Het datatype CoordinateTransformation is een beheerde enumeratie en het heeft daarom een stereotype CodeList (zie paragraaf 4.2.1). De waarde geeft aan welke transformatiemethode is toegepast. Merk op dat de toegestane waarde anders kan zijn voor IMBRO dan voor IMBRO/A.

CorrectionRequest

Het datatype CorrectionRequest bevat de gemeenschappelijke gegevens voor het samenstellen van een request om de gegevens voor een bepaald registratieobject te corrigeren.


Het element requestReference is een voor de data-afnemer unieke aanduiding van het request.
Het element deliveryAccountableParty bevat het kamer van koophandel nummer van de bronhouder. Dit element is verplicht als de dataleverancier niet de bronhouder is.
Het element broId is de unieke aanduiding van het registratieobject waarvoor gegevens worden gecorrigeerd.
Zie de catalogus voor aanvullende informatie over de andere elementen.

CriteriaSet

Het datatype CriteriaSet is een abstract datatype ten behoeve van het samenstellen van DispatchCharacteristicsRequest.


Het abstracte datatype CriteriaSet definieert een aantal optionele elementen voor de kenmerkenverzameling en één verplicht element area (zie paragraaf 8.2). Alleen kengegevens van registratieobjecten, waarvan de gestandaardiseerde locatie (zie paragraaf 8.26) valt binnen het opgegeven gebied worden uitgeleverd.

CriterionError

Het datatype CriterionError bevat als onderdeel van een DispatchResponse (zie paragraaf 8.13) één foutmelding met betrekking tot een geconstateerde fout in de kenmerkenverzameling van een uitgifteverzoek, bestaande uit een volgnummer en een omschrijving.

DatePeriod

Het datatype DatePeriod bevat een begin en eindwaarde, beiden van het standaard datatype Date, zodat in de CriteriaSet een periode kan worden opgenomen waarbinnen een datum moet liggen.


Merk op dat beide elementen verplicht zijn en niet een lege waarde mogen hebben.

DeregisteredObject

Het datatype DeregisteredObject bevat de gegevens over een registratieobject dat uit registratie is genomen.

DispatchDataRequest

Het datatype DispatchDataRequest bevat de gemeenschappelijke gegevens voor het samenstellen van een request om de gegevens over een bepaald registratieobject op te vragen.


Het element requestReference is een voor de afnemer unieke aanduiding van het request.
Het element broId is de unieke aanduiding van het registratieobject waarvan de gegevens worden opgevraagd.

DispatchResponse

Het datatype DispatchResponse is een abstract datatype voor het samenstellen van een response als reactie op een uitgifteverzoek (dispatch request).


Het datatype DispatchResponse is een generiek response. Het definieert een aantal platte elementen, sommigen verplicht en anderen optioneel, inclusief een optionele lijst met foutmeldingen (zie paragraaf 8.9). Zie hoofdstuk 3 voor een beschrijving van welke velden onder welke omstandigheden gevuld zullen worden.

Enumeraties

De catalogus maakt een onderscheid in beheerde en niet-beheerde enumeraties. Het stereotype Enumeration wordt in UML gebruikt om aan te geven dat een datatype een niet-beheerde enumeratie is (zie paragraaf 4.2.3).
De package brocommon definieert zes datatypes met als domein een enumeratie van toegestane waarden.


In de XSD zijn deze gerealiseerd als een simpleType als restrictie van het standaard XSD type string. Voorbeeld:

< simpleType name= "IndicationYesNoEnumeration" >
< restriction base= "string" >
< enumeration value= "ja" />
< enumeration value= "nee" />
</ restriction >
</ simpleType >


Voorbeeld van een element in een XML bericht:

<deregistered>nee</ deregistered >


IntakeResponse

Als het BRO-systeem na de toegangscontrole het request kan verwerken zonder dat er fouten worden geconstateerd in het request en/of het sourceDocument en zonder dat er een onverwachte fout optreedt in het BRO-systeem, dan reageert het BRO-systeem met een functionele response. Deze functionele response is van het datatype IntakeResponse.


Het element responseType geeft aan of het request succesvol kon worden verwerkt (waarde completion bij een RegistrationRequest; waarde acceptance bij een CorrectionRequest) of dat de verwerking om functionele redenen niet succesvol is (waarde rejection).
De waarde voor het element requestReference wordt overgenomen uit het request, zodat de zendende partij weet voor welk request dit een response is.
De waarde voor het element transactionId wordt toegekend door het transactieregister. De zendende partij kan dit gegeven gebruiken in de (mondelinge) communicatie met de BRO Servicedesk, zodat deze de transactie kan terugvinden in het transactieregister.
Het element broId bevat de identificatie van het object in de BRO. Dit element is afwezig als de response een reactie is op een RegistrationRequest en als het element responseType een waarde rejection heeft.
Het element ObjectIdAccountableParty is alleen aanwezig als de response een reactie is op een RegistrationRequest en als het element responseType een waarde rejection heeft. De waarde wordt overgenomen uit het RegistrationRequest, zodat de zendende partij weet wat zijn identificatie is van het geweigerde registratieobject.
Van de elementen acceptanceTime, completionTime en rejectionTime zal steeds één daarvan aanwezig zijn, afhankelijk van de waarde voor het element responseType. In deze elementen staat het (datum en) tijdstip waarop het request is geaccepteerd, het request is verwerkt of het request is afgewezen.
Als het request is afgewezen, dan staat in element rejectionReason de reden. Als de reden is dat er een of meer gebruiksfouten in het sourceDocument zijn geconstateerd, dan is de waarde van rejectionReason "er zijn 1 of meer fouten geconstateerd in het brondocument" en bevat IntakeResponse een lijst sourceDocumentErrors, waarbij iedere sourceDocumentError bestaat uit een sequenceNumber (voor het sorteren van de gebruiksfout) en een specification (een tekstuele beschrijving van de gebruiksfout).

ParseFault

Als het BRO-systeem, na de toegangscontrole, fouten constateert in het request en/of het sourceDocument (bijvoorbeeld het request is niet een welgevormd XML-bericht of het request voldoet niet aan de schemavalidatie), dan worden deze geduid als een softwarefout in het systeem van de dataleverancier. Het BRO-systeem reageert dan niet met een IntakeResponse, maar met een Fault uit de package SOAP, waarbij het element detail van het datatype ParseFaultDetail is. Het datatype ParseFaultDetail bevat één element parseFault van het datatype ParseFault.


De elementen van Fault uit de package SOAP hebben de volgende betekenis:

SOAP:Fault

Inhoud

Faultcode

Vaste waarde "soap:Client"

Faultstring

Vaste waarde "Het verzoek voldoet niet aan het schema"

Detail

ParseFaultDetail


Het datatype ParseFault bevat drie platte elementen en een lijst met abortReasons. De lijst abortReasons bestaat uit minimaal 1 en maximaal 99 voorkomens van het complex type AbortReason.


De elementen van ParseFault en AbortReason hebben de volgende betekenis:

ParseFault

Inhoud

RequestReference

Waarde overgenomen uit request (dit element is optioneel omdat de softwarefout geconstateerd kan worden voordat het request is gelezen).

TransactionId

Waarde toegekend door transactieregister (dit element is optioneel omdat de softwarefout geconstateerd kan worden voordat een transactie is aangemaakt).

AbortTime

Tijdstip, toegekend door webservice, waarop de fout is opgetreden.

AbortReason

  • SequenceNumber
  • Specification


Numerieke waarde bedoelt om de lijst met schema validatie fouten te kunnen sorteren
Omschrijving van de validatie fout

PartialDate

Het datatype PartialDate ondersteunt een datum met een aantal mogelijke nauwkeurigheden.


PartialDate heeft het stereotype Union (zie paragraaf 4.2.6), waarmee wordt aangegeven dat het element met dit datatype polymorf is en dat bij een voorkomen precies een van de alternatieven gekozen moet worden. De beschikbare alternatieven zijn:

  • date: Volledig datum tot op de dag nauwkeurig (formaat "YYYY-MM-DD")
  • yearMonth: Onvolledige datum tot op de maand nauwkeurig (formaat "YYYY-MM")
  • year: Onvolledige datum tot op het jaar nauwkeurig (formaat "YYYY")
  • voidReason: Geen datum bekend (vaste waarde onbekend)

Gegevens met dit datatype, die worden aangeleverd onder het kwaliteitsregime IMBRO, mogen alleen het alternatief date gebruiken. Onder het kwaliteitsregime IMBRO/A mogen alle vier alternatieven gebruikt worden.
De datatypes Date, gYearMonth en gYear zijn standaard XSD-datatypes, met een bereik conform ISO 8601. Deze datatypes mogen optioneel worden aangevuld met een tijdzone (Z voor UTC; +01:00 voor wintertijd in Nederland; +02:00 voor zomertijd in Nederland).
Voorbeelden van een aantal keren hetzelfde element in een XML bericht met als waarde steeds een andere variant van het type partialDate:

<researchReportDate>
<brocom:date>2015-10-28</brocom:date>
</researchReportDate>
<researchReportDate>
<brocom:date>2015-10-28+02:00</brocom:date>
</researchReportDate>
<researchReportDate>
<brocom:date>2015-10-28Z</brocom:date>
</researchReportDate>
<researchReportDate>
<brocom:yearMonth>2015-10</brocom:yearMonth>
</researchReportDate>
<researchReportDate>
<brocom:year>2015</brocom:year>
</researchReportDate>
<researchReportDate>
<brocom:voidReason>onbekend</brocom:voidReason>
</researchReportDate>

Radius

Het datatype Radius is voor het uitdrukken van een straal in kilometers. Zie paragraaf 12.6 voor nadere details over het datatype Measure uit de package gml-profile en de realisatie in de XSD.


Voorbeeld van zo'n element in een GML bericht, waarbij de straal 8,5 kilometer is:

<radius uom= "km" >8.5</radius>

RegistrationHistory

Het datatype RegistrationHistory bevat gegevens die de geschiedenis van het object in de registratie markeren.

RegistrationObject

Het abstract datatype RegistrationObject bevat de algemene gegevens van een registratieobject dat niet uit registratie is genomen.


Het datatype RegistrationObject heeft het stereotype FeatureType (zie paragraaf 4.2.4), wat aangeeft dat een object van dit datatype een fenomeen in de werkelijkheid representeert, dat direct of indirect is geassocieerd met een locatie relatief ten opzichte van de aarde en dat een element van dit datatype een verplicht attribuut gml:id heeft.
Het datatype RegistrationObject definieert een aantal platte elementen en twee gestructureerde elementen: RegistrationHistory en StandardizedLocation.
De informatie in RegistrationHistory en StandardizedLocation worden niet aangeleverd door de dataleverancier, maar tijdens inname vastgelegd door de BRO.
De elementen objectIdAccountableParty en delivery Responsible Party worden alleen uitgegeven als de data-afnemer tevens bronhouder en/of data-afnemer is van het registratieobject. Voor andere data-afnemers worden deze attributen weg gelaten.

RegistrationObjectCode

Het datatype RegistrationObjectCode is een restrictie van het standaard datatype string. De eerste drie posities zijn de afkorting van type registratieobject, gevolgd door een twaalf cijferig, registratieobject afhankelijk volgnummer.

RegistrationRequest

Het datatype RegistrationRequest bevat de gemeenschappelijke gegevens voor het samenstellen van een request om de gegevens voor een bepaald registratieobject te registreren.


Het element requestReference is een voor de data-afnemer unieke aanduiding van het request.
Het element deliveryAccountableParty bevat het kamer van koophandel nummer van de bronhouder. Dit element is verplicht als de dataleverancier niet de bronhouder is.
Het element broId is de unieke aanduiding van het registratieobject waarvoor gegevens worden geregistreerd. Dit element is niet toegestaan bij de initiële registratie van de gegevens van een registratieobject.
Zie de catalogus voor aanvullende informatie over de andere elementen.

RegistrationStatus

Het datatype RegistrationStatus is een beheerde enumeratie en het heeft daarom een stereotype CodeList (zie paragraaf 4.2.1). Zie de catalogus voor het domein en de betekenis van de waarden.

SOAP Fault

Als tijdens de uitvoering van een operatie er een onverwachte fout optreedt in het BRO-systeem, dan reageert het BRO-systeem niet met een IntakeResponse, maar met een Fault uit de package SOAP.


Alhoewel dit een standaard niet-gemodelleerde fout is uit de SOAP namespace, wordt dit hier toch beschreven als tegenhanger van de ParseFault, wat gebruikt wordt in geval van een softwarefout.
De elementen van Fault uit de package SOAP hebben de volgende betekenis:

SOAP:Fault

Inhoud

Faultcode

Vaste waarde "soap:Server"

Faultstring

Vaste waarde "Er is een fout in het BRO-systeem geconstateerd"

Detail

Optioneel complex element (zie volgende tabel)


Binnen het element detail zal het BRO-systeem de volgende elementen opnemen:

Element

Inhoud

RequestReference

Waarde overgenomen uit request (dit element is optioneel omdat de softwarefout geconstateerd kan worden voordat het request is gelezen).

TransactionId

Waarde toegekend door transactieregister (dit element is optioneel omdat de softwarefout geconstateerd kan worden voordat een transactie is aangemaakt).

AbortTime

Tijdstip, toegekend door webservice, waarop de fout is opgetreden.


Er wordt summiere informatie teruggegeven dat de fout is opgetreden en dat het verzoek niet is verwerkt. Deze fouten kunnen niet door de data-afnemer worden opgelost. Neem contact op met de BRO Servicedesk voor de verdere afhandeling van dit type fouten.
De requestReference is opgenomen in de foutmelding, zodat de zendende partij weet bij welk verzonden bericht de systeemfout is opgetreden, ook als deze foutmelding buiten de context van de synchrone requestresponse interactie geanalyseerd wordt. Dit kan behulpzaam zijn bij de analyse en reproductie het probleem.
De transactionId is opgenomen in de foutmelding, zodat de zendende partij dit kan doorgeven aan de BRO Servicedesk. De BRO Servicedesk kan daarmee de mislukte transactie terugvinden in het transactieregister, waarin aanvullende informatie (zoals een deel van de stacktrace) is opgeslagen.
De abortTime is opgenomen in de foutmelding, zodat de zendende partij, in het bijzonder in het geval de beide voorgaande gegevens niet bekend zijn, in ieder geval dit gegeven kan doorgeven aan de BRO Servicedesk, waarmee een technisch BRO-medewerker gericht kan zoeken in de logfiles.

SourceDocumentError

Zie IntakeResponse in paragraaf 8.15.

StandardizedLocation

Het datatype StandardizedLocation bevat een element location van het datatype Point uit de package gml-profile (zie paragraaf 12.7) en een element CoordinateTransformation met toegestane waarden uit een codelijst (zie paragraaf 8.6).


De StandardizedLocation maakt het mogelijk alle gegevens in de registratie ondergrond in een en hetzelfde referentiestelsel te ontsluiten.
Het coördinatensysteem van het element location binnen StandardizedLocation is altijd ETRS89, oftewel de waarde van attribuut srsName van element location is urn:ogc:def:crs:EPSG::4258.
Het BRO-systeem berekent tijdens inname de gestandaardiseerde locatie op basis van de aangeleverde locatie. Het element CoordinateTransformation geeft aan welke transformatiemethode daarbij is toegepast.
Voorbeeld van het element location binnen StandardizedLocation in een XML-bestand:

<location gml:id= "BRO_0001" srsName= "urn:ogc:def:crs:EPSG::4258" >
<gml:pos>52.28782 5.09042</gml:pos>
</location>

Package sa-profile

De package sa-profile bevat het profiel met de concepten uit de Sampling Features standaard van de OGC die gebruikt worden in de BRO. Sampling Features is een onderdeel van Observations & Measurements.

SF_SamplingFeature

Het datatype SF_SamplingFeature beschrijft een monster op basis waarvan een waarneming of een meting wordt gedaan.


Het stereotype FeatureType (zie paragraaf 4.2.4) geeft aan dat het monster direct of indirect is geassocieerd met een puntlocatie aan het aardoppervlak, waardoor een element met als datatype een subklasse van dit datatype een verplicht attribuut gml:id heeft.
Het gerelateerde datatype OM_Observation (zie paragraaf 10.1) beschrijft de resultaten die het gevolg zijn van de bemonstering.

Package om-profile

De package om-profile bevat het profiel met de concepten uit de Observations and Measurements standaard van de OGC die gebruikt worden in de BRO.

OM_Observation

OM_Observation is een model dat bedoeld is om het proces van waarnemen en de resultaten daarvan te beschrijven. Het is toegepast op de ConePenetrationTest (zie paragraaf 7.3) en DissipationTest (zie paragraaf 7.12).


Alleen de volgende elementen worden gebruikt:

  • phenomenonTime wordt gevuld met "datum voltooiing beschrijving" uit de catalogus.
  • resultTime is een verplicht element. Omdat vanuit het domeinmodel geen geschikte waarde voorhanden is wordt geadviseerd het element te vullen met dezelfde waarde als voor phenomenonTime, dat wil zeggen "datum voltooiing beschrijving" uit de catalogus.


De overige elementen zijn optioneel en kunnen in een XML bericht weggelaten worden.
De lijst met relaties relatedObservation wordt niet gebruikt; deze lijst heeft een minimale kardinaliteit 0 kan in een XML bericht weggelaten worden.
De relaties procedure, featureOfInterest en observedProperty worden niet gebruikt. Deze relaties zijn verplicht maar hebben het stereotype Voidable (zie paragraaf 4.2.7). In het XML bericht moeten deze elementen worden opgenomen met een lege waarde en een attribuut xsi:nil="true".
De relatie result wordt via een substitutiongroup vervangen; zie paragraaf 7.3 en 7.12.

Package swe-profile

De package swe-profile bevat het profiel met de concepten uit de Sensor Web Enablement - Common Data Model Encoding standaard van de OGC die gebruikt worden in de BRO.

DataArray

Het datatype DataArray implementeert het 'composite pattern', waarbij ieder element in de array elk datatype kan hebben.


Het element elementCount bevat het aantal gemeten parameters.
Het element elementType (met datatype AbstractDataComponent) bevat de definities van de lijst met parameters. De BRO hanteert hiervoor een voorgeschreven opbouw. Het attribuut xlink:href van het element elementType bevat een URL die verwijst naar een XML bestand met deze opbouw, dat offline op een door TNO aangewezen server wordt geplaatst. De opbouw is conform een subklasse van het datatype DataRecord (zie paragraaf 11.2).
Het element encoding geeft aan met welke encoding de gemeten waarden worden opgenomen. De BRO gebruikt als decimaal scheidingsteken een ".", als element scheidingsteken een "," en als record scheidingsteken een ";".
Het element values bevat, in de vorm van een gecodeerde string (zie element encoding), de waarden van de gemeten parameters.
Alle overige elementen en attributen van DataArray zijn optioneel en worden binnen de BRO niet gebruikt.

DataRecord

Het datatype DataRecord definieert de opbouw van de gemeten parameters in een DataArray (zie paragraaf 11.1), waarbij ieder element in de array elke datatype kan hebben.


Een DataRecord is afgeleid van AbstractDataComponent, waaraan het een lijst elementen met de naam field en met datatype AbstractDataComponentProperty toevoegt.
Ieder element field definieert conform de catalogus de naam en het datatype van een parameter. Met het optionele attribuut nilValue kan worden aangegeven welke dummy waarde wordt gebruikt om aan te geven dat de waarde van een parameter niet is vastgesteld.
Alle overige elementen en attributen van DataRecord zijn optioneel en worden binnen de BRO niet gebruikt.

Package gml-profile

De package gml-profile bevat de concepten uit de GML-standaard van de OGC die gebruikt worden in de BRO.

AbstractFeature

Een aantal gegevens in de BRO is conform NEN3610 geclassificeerd met een stereotype FeatureType. Dit heeft tot gevolg dat hun XML-schema-type is afgeleid van AbstractFeature.


Hierdoor overerft een element van dit datatype het attribuut gml:id met als datatype het XML-standaard type ID. Zie paragraaf 12.2.

AbstractGML

Het datatype AbstractGML definieert een verplicht attribuut id.


Dit XML-attribuut voorziet in het gebruik als referentie binnen één XML-bericht. Het datatype van het attribuut id is het XML-standaard type ID, zodat het uniek is binnen het XML-document waarin het voorkomt. In de BRO wordt deze identificatie niet gebruikt en daarom ook niet opgeslagen. Bij uitgifte wordt de identificatie gegenereerd. Een element kan op ander moment een andere waarde krijgen.

<registrationObject gml:id= "ro-4774" >

CodeWithAuthority

Het complexType CodeWithAuthority wordt gebruikt voor beheerde enumeraties c.q. codelijsten (zie paragraaf 4.2.1).
Het complexType CodeWithAuthority is een restrictie van het type string, waaraan het een attribuut codespace van het type anyURI toevoegt. Deze codespace bevat de naam van de codelijst. Elke codelijst in de BRO heeft daarom een eigen codespace die in de XSD als vaste waarde is opgenomen. Zie onderstaande figuur.


In een XSD leidt dit tot een restrictie van het complexType CodeWithAuthority. Voorbeeld van een codelijst in XSD:

<complexType name = "DeliveryContext" >
<simpleContent>
<restriction base = "gml:CodeWithAuthorityType" >
<attribute name = "codeSpace" type = "anyURI" use = "required" fixed = "urn:bro:cpt:DeliveryContext" />
</restriction>
</simpleContent>
</complexType >


Voorbeeld van een element, met als datatype een codelijst, in een XML bericht. Zo'n element heeft een attribuut codeSpace, waarvan de waarde aangeeft in welke tabel de toegestane waarden zijn vastgelegd, en als waarde een van de waarden uit die tabel. Voorbeeld:

<deliveryContext codeSpace= "urn:bro:cpt:DeliveryContext" >publiekeTaak</deliveryContext>


Merk op dat in de catalogus en in het UML-diagram het domein expliciet wordt benoemd. Het domein is niet opgenomen in het XSD-bestand. Als dat wel het geval zou zijn, dan zou een wijziging in het domein leiden tot een wijziging van het XSD-bestand. Het domein wordt niet afgedwongen door het XSD-bestand. In plaats daarvan valideert het BRO-systeem de gebruikte waarde softwarematig via een database tabel.
Merk op dat bij een codelijst de toegestane waarden anders kunnen zijn voor IMBRO dan voor IMBRO/A. Zie de catalogus voor nadere details.

Doublelist

Het datatype Doublelist bevat een reeks floating point getallen als waarde voor een element of een attribuut.


De getallen worden gescheiden door een spatie. De decimalen worden gescheiden van de eenheden door een punt.

Envelope

Het datatype Envelope geeft een rechthoekige begrenzing aan van een gebied aan het aardoppervlak.


Het datatype Envelope is een extensie van AbstractGeometricPrimitive, waaraan het twee elementen toevoegt.
De rechthoek wordt gedefinieerd door het onderhoek (element lowerCorner met als coördinatenpaar de minimale waarden voor de twee dimensies binnen de rechthoek) en de bovenhoek (element upperCorner met als coördinatenpaar de minimale waarden voor de twee dimensies binnen de rechthoek). Beide locaties zijn van het datatype Doublelist (zie paragraaf 12.4).
Zie paragaaf 12.7 voor een toelichting op de attributen die geërfd worden van AbstractGeometricPrimitive.
Voorbeeld een element van het datatype Envelope, zijnde een vierkant van 10 * 10 km in RD-coördinaten:

<boundingBox gml:id= "BRO_0001" srsName= "urn:ogc:def:crs:EPSG::28992" >
<gml:lowerCorner>136000.0 472000.0</gml:lowerCorner>
<gml:upperCorner>146000.0 482000.0</gml:upperCorner>
</boundingBox>

Measure

Het datatype Measure is een extensie van het standaard XSD type double, waaraan het een verplicht attribuut uom (unit of measure) toevoegt:


In de koppelvlakdefinitie is ervoor gekozen om deze types naar fysische grootheid te modelleren. Dit heeft als voordeel, dat er minder types nodig zijn en dat de meeteenheid expliciet kan worden vastgelegd in het attribuut uom.
NB: het attribuut uom is verplicht, ook als de elementwaarde leeg is.

Point

Point is een datatype voor elementen met een puntlocatie aan het aardoppervlak. Het definieert een element pos en drie attributen id, srsName en srsDimension.


Het attribuut id voorziet in een referentie voor het XML-element dat een GML-object vertegenwoordigt. Het gebruik ervan is verplicht voor alle GML-objecten. Het datatype is het standaard XML-type ID, zodat het uniek is binnen het XML-document waarin het voorkomt.
Het attribuut srsName bevat de URI van het coördinatensysteem waarin de locatie van het punt wordt uitgedrukt. Onderstaande tabel geeft de toegestane waarden binnen CPT.

Naam

Betekenis

Waarde voor srsName

ETRS89

European Terrestrial Reference System 1989

urn:ogc:def:crs:EPSG::4258

RD

Rijks Driehoeksmeting – Amersfoort RD New

urn:ogc:def:crs:EPSG::28992

WGS84

World Geodetic System 1984 (GPS)

urn:ogc:def:crs:EPSG::4326










Het attribuut srsDimension bevat het aantal dimensies van de coördinaten. Omdat het attribuut srsDimension optioneel is en omdat de referentiestelsels ETRS89 en RD beiden tweedimensionaal zijn, is alleen srsDimension="2" toegestaan. Daarom en om inconsistenties te voorkomen wordt aangeraden het attribuut weg te laten (zie referentie [4]).
Conform NEN3610 wordt voor het coördinatenpaar van de locatie het attribuut pos gebruikt van datatype Doublelist (zie paragraaf 12.4). Het bereik en de betekenis is afhankelijk van het gebruikte coördinatensysteem. Onderstaande tabel geeft per coördinatensysteem de betekenis en de eenheid van het coördinatenpaar.









Naam

Betekenis coördinaten

Eenheid

ETRS89

Latitude, Longitude

Decimale graden

RD

X, Y

Meter

WGS84

Latitude, Longitude

Decimale graden


In een XSD ziet de definitie van een element met dit datatype er bijvoorbeeld als volgt uit:

<element name = "location" type = "gml:PointType" />


In een XML-bericht krijgt een element van het type datatype Point drie attributen en als inhoud een pos element. Voorbeeld:

<location gml:id= "BRO_0001" srsName= "urn:ogc:def:crs:EPSG::4258" >
<gml:pos>52.08860451 5.16575333</gml:pos>
</location>
<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::4326" >
<gml:pos>52.08860451 5.16575333</gml:pos>
</location>

TM_TimeInstant

Het datatype TM_TimeInstant bevat een identificeerbare datum of tijdstip.


Het element position, met als datatype TM_Position (zie paragraaf 12.9), bevat de datum of datum en tijd, inclusief tijdzone, in ISO 8601 formaat.
Het overerfde attribuut id is verplicht (zie de beschrijving in paragraaf 12.2) en kan gebruikt worden om te verwijzen naar een specifiek tijdstip. Elementen van het type TM_TimeInstant die dezelfde datum of hetzelfde tijdstip vertegenwoordigen (al kan de waarde gezien de tijdzone kan verschillen) hebben dezelfde waarde voor het attribuut id.
Voorbeeld van een datum en tijd volgens Nederlandse zomertijd:

<phenomenonTime gml:id= "to-3772" >
<gml:timePosition>2013-07-12T10:04:38+02:00</gml:timePosition>
</phenomenonTime>

TM_Position


Dit type is een Union waarin verschillende mogelijkheden voor het beschrijven van een positie in de tijd uit de ISO 19108 standaard zijn gecombineerd.
Een element van type TM_Position heeft onder het kwaliteitsregime IMBRO als domein:

  • Datum en tijd
  • Of een datum


Onder het kwaliteitsregime IMBRO/A is het domein:

  • Datum en tijd
  • Of een datum
  • Of jaartal en maand
  • Of jaartal
  • Of onbekend


Binnen de BRO geldt als conventie dat een element met een naam met een suffix Time als domein datum en tijd of minder nauwkeurig heeft en een element met een naam met een suffix Date als domein datum of minder nauwkeurig heeft.
Binnen de BRO geldt voor een datum de codering ISO-8601 en de kalender Gregoriaans. Formaat: YYYY-MM-DD.
Binnen de BRO bestaat een tijd uit uren, minuten en secondes conform UTC; milliseconden worden niet gebruikt. Formaat: YYYY-MM-DDThh:mm:ss.
Voorbeelden:

<resultTime>2013-07-12T10:04:38+02:00</resultTime>
<resultTime>2013-07-12T10:04:38Z</resultTime>
<resultTime>2013-07-12T10:04:38</resultTime>
<resultTime>2013-07-12</resultTime>
<resultTime>2013-07</resultTime>
<resultTime>2013</resultTime>
<resultTime indeterminatePosition= "unknown" />
<reportDate>2015-01-01+01:00</reportDate>
<reportDate>2015-01-01Z</reportDate>
<reportDate>2015-01-01</reportDate>
<reportDate>2015-01</reportDate>
<reportDate>2015</reportDate>
<reportDate indeterminatePosition= "unknown" />

De package xlink-profile bevat het XLINK-profiel, oftewel die concepten uit de XLINK-standaard van de OGC die gebruikt worden in de BRO.

Href

Het datatype href definieert een XML-attribuut (niet een XML-element) van het datatype hrefType.

HrefType

Het datatype hrefType definieert een simpleType als afgeleide van anyURI.

SimpleAttrs

Het datatype simpleAttrs definieert een XML attributeGroup met twee XML-attributen (geen XML-elementen).

Type

Het datatype type definieert een XML-attribuut (niet een XML-element) van het datatype TypeType.

TypeType

Het datatype TypeType definieert een enumeratie met één toegestane waarde.

Bijlages

Bijlage A: Vertaalslag Engels – Nederlands

A1: dscpt-messages

Engels

Nederlands

Characteristics

Kengegevens

broId

BRO-ID  

deliveryAccountableParty

bronhouder  

deregistered

uit registratie genomen  

dissipationTestPerformed

dissipatietest uitgevoerd  

finalDepth

einddiepte  

localVerticalReferencePoint

lokaal verticaal referentiepunt  

objectRegistrationTime

tijdstip registratie object  

offset

verschuiving  

predrilledDepth

voorgeboord tot  

qualityClass

kwaliteitsklasse  

qualityRegime

kwaliteitsregime  

researchReportDate

rapportagedatum  

cptStandard

sondeernorm  

startTime

starttijd meten conuspenetratietest  

stopCriterion

stopcriterium

surveyPurpose

kader inwinning  

underReview

in onderzoek  

verticalDatum

verticaal referentievlak  

CriteriaSet

Kenmerkenverzameling CPT 

area

Gebied

correctionPeriod

periode van correctie  

cptStandard

sondeernorm  

deliveryAccountableParty

bronhouder  

depthInterval

diepteinterval  

dissipationTestPerformed

dissipatietest uitgevoerd  

Parameters

Parameters

qualityClass

kwaliteitsklasse  

qualityRegime

kwaliteitsregime  

registrationPeriod

periode van registratie  

researchReportPeriod

periode van uitvoering  

stopCriterion

Stopcriterium

underReview

in onderzoek  

DispatchCharacteristics

Uitgifte document

characteristics

Kengegevens

deregisteredObject

Uit registratie genomen object

DispatchCharacteristicsRequest

Verzoek tot verzending kengegevens  

criteria

Kenmerkenverzameling

requestReference

verzoekkenmerk  

DispatchCharacteristicsResponse

Bericht van verzending kengegevens  

dispatchDocument

Uitgiftedocument

dispatchTime

tijdstip van uitgifte  

numberOfDocuments

aantal documenten

rejectionReason

Reden van afwijzing

rejectionTime

tijdstip van afwijzing  

requestReference

verzoekkenmerk  

responseType

(verwerkt in berichtnamen)

DispatchData

UitgifteDocument

deregisteredObject


geotechnicalCPTSurvey


DispatchDataRequest

Verzoek tot verzending gegevens  

broId

BRO-ID

requestReference

verzoekkenmerk  

DispatchDataResponse

Bericht van verzending gegevens  

dispatchDocument

Uitgiftedocument

dispatchTime

tijdstip van uitgifte  

rejectionReason

Reden van afwijzing

rejectionTime

tijdstip van afwijzing  

requestReference

verzoekkenmerk  

responseType

(verwerkt in berichtnamen)

Parameters

onderdeel van Kenmerkenverzameling CPT 

correctedConeResistance

gecorrigeerde conusweerstand  

depth

diepte  

elapsedTime

verlopen tijd  

electricalConductivity

elektrische geleidbaarheid  

FrictionRatio

wrijvingsgetal  

InclinationEW

helling oost-west  

InclinationNS

helling noord-zuid  

inclinationResultant

hellingresultante  

inclinationX

helling x  

inclinationY

helling y  

localFriction

plaatselijke wrijving  

magneticDeclination

magnetische declinatie  

magneticInclination

magnetische inclinatie  

magneticFieldStrengthX

magnetische veldsterkte x  

magneticFieldStrengthY

magnetische veldsterkte y  

magneticFieldStrengthZ

magnetische veldsterkte z  

magneticFieldStrengthTotal

totale magnetische veldsterkte  

netConeResistance

netto conusweerstand  

poreRatio

porienratio  

porePressureU1

waterspanning u1  

porePressureU2

waterspanning u2  

porePressureU3

waterspanning u3  

temperature

temperatuur  

GeotechnicalCPTSurvey

Geotechnisch sondeeronderzoek  

additionalInvestigation

aanvullend onderzoek  

additionalInvestigationPerformed

aanvullend onderzoek uitgevoerd  

broId

BRO-ID

conePenetrometerSurvey

Sondeonderzoek

cptStandard

sondeernorm  

deliveredLocation

Aangeleverde locatie

deliveredVerticalPosition

Aangeleverde verticale positie

deliveryAccountableParty

bronhouder  

deliveryContext

kader aanlevering  

deliveryResponsibleParty

dataleverancier  

objectIdAccountableParty

object-ID bronhouder  

qualityRegime

kwaliteitsregime  

registrationHistory

registratiegeschiedenis

researchOperator

uitvoerder  

researchReportDate

rapportagedatum  

standardizedLocation

Gestandaardiseerde locatie

surveyPurpose

kader inwinning  

A2: cptcommon

Engels

Nederlands

AdditionalInvestigation

Aanvullend onderzoek  

conditions

omstandigheden  

investigationDate

datum onderzoek  

groundwaterLevel

grondwaterstand  

removedLayer

Verwijderde laag

surfaceDescription

hoedanigheid oppervlakte  

ConePenetrationTest

Conuspenetratietest  

startTime

starttijd meten  

ConePenetrationTestResultRecord


coneResistance

conusweerstand  

correctedConeResistance

gecorrigeerde conusweerstand  

depth

diepte  

elapsedTime

verlopen tijd  

electricalConductivity

elektrische geleidbaarheid  

frictionRatio

wrijvingsgetal  

inclinationResultant

hellingresultante  

inclinationEW

helling oost-west  

inclinationNS

helling noord-zuid  

inclinationX

helling x  

inclinationY

helling y  

localFriction

plaatselijke wrijving  

magneticDeclination

magnetische declinatie  

magneticFieldStrengthTotal

totale magnetische veldsterkte  

magneticFieldStrengthX

magnetische veldsterkte x  

magneticFieldStrengthY

magnetische veldsterkte y  

magneticFieldStrengthZ

magnetische veldsterkte z  

magneticInclination

magnetische inclinatie  

netConeResistance

netto conusweerstand  

penetrationLength

sondeertrajectlengte  

porePressureU1

waterspanning u1  

porePressureU2

waterspanning u2  

porePressureU3

waterspanning u3  

poreRatio

porienratio  

temperature

temperatuur  

ConePenetrometer

Sondeerapparaat  

coneDiameter

conusdiameter  

conePenetrometerType

conustype  

coneSurfaceArea

oppervlakte conuspunt  

coneSurfaceQuotient

oppervlaktequotiënt conuspunt  

coneToFrictionSleeveDistance

afstand conus tot midden kleefmantel  

description

omschrijving  

frictionSleeveSurfaceArea

oppervlakte kleefmantel  

frictionSleeveSurfaceQuotient

oppervlaktequotiënt kleefmantel  

zeroLoadMeasurement

nulmeting

ConePenetrometerSurvey

Sondeonderzoek  

cptMethod

sondeermethode  

dissipationTestPerformed

dissipatietest uitgevoerd  

finalProcessingDate

datum laatste bewerking  

qualityClass

kwaliteitsklasse  

sensorAzimuth

sensorazimuth  

stopCriterion

stopcriterium  

DeliveredLocation

Aangeleverde locatie  

horizontalPositioningDate

datum locatiebepaling  

horizontalPositioningMethod

methode locatiebepaling  

horizontalPositioningOperator

uitvoerder locatiebepaling  

location

Locatie

DeliveredVerticalPosition

Aangeleverde verticale positie  

localVerticalReferencePoint

lokaal verticaal referentiepunt  

offset

verschuiving  

verticalDatum

verticaal referentievlak  

verticalPositioningDate

datum verticale positiebepaling  

verticalPositioningMethod

methode verticale positiebepaling  

verticalPositioningOperator

uitvoerder verticale positiebepaling  

waterDepth

Waterdiepte

DepthInterval

Diepteinterval

beginDepth

Begindiepte

endDepth

Einddiepte

DissipationTest

Dissipatietest  

penetrationLength

sondeertrajectlengte  

startTime

starttijd meten  

DissipationTestResultRecord

Dissipatietest resultaat  

coneResistance

conusweerstand  

elapsedTime

verlopen tijd  

porePressureU1

waterspanning u1  

porePressureU2

waterspanning u2  

porePressureU3

waterspanning u3  

Parameters

Bepaalde parameters  

coneResistance

conusweerstand  

correctedConeResistance

gecorrigeerde conusweerstand  

depth

diepte  

elapsedTime

verlopen tijd  

electricalConductivity

elektrische geleidbaarheid  

frictionRatio

wrijvingsgetal  

inclinationEW

helling oost-west  

inclinationNS

helling noord-zuid  

inclinationResultant

hellingresultante  

inclinationX

helling x  

inclinationY

helling y  

localFriction

plaatselijke wrijving  

magneticDeclination

magnetische declinatie  

magneticFieldStrengthTotal

totale magnetische veldsterkte  

magneticFieldStrengthX

magnetische veldsterkte x  

magneticFieldStrengthY

magnetische veldsterkte y  

magneticFieldStrengthZ

magnetische veldsterkte z  

magneticInclination

magnetische inclinatie  

netConeResistance

netto conusweerstand  

penetrationLength

sondeertrajectlengte  

poreRatio

porienratio  

porePressureU1

waterspanning u1  

porePressureU2

waterspanning u2  

porePressureU3

waterspanning u3  

temperature

temperatuur  

Processing

Bewerking

expertCorrectionPerformed

expertcorrectie uitgevoerd  

interruptionProcessingPerformed

bewerking onderbrekingen uitgevoerd  

signalProcessingPerformed

signaalbewerking uitgevoerd  

RemovedLayer

Verwijderde laag  

lowerBoundary

onderdiepte  

description

beschrijving  

sequenceNumber

volgnummer  

upperBoundary

bovendiepte  

Trajectory

Traject  

finalDepth

einddiepte  

predrilledDepth

voorgeboord tot  

ZeroLoadMeasurement

Nulmeting  

coneResistanceBefore

conusweerstand vooraf  

coneResistanceAfter

conusweerstand achteraf  

electricalConductivityBefore

elektrische geleidbaarheid vooraf  

electricalConductivityAfter

elektrische geleidbaarheid achteraf  

inclinationEWBefore

helling oost-west vooraf  

inclinationEWAfter

helling oost-west achteraf  

inclinationNSBefore

helling noord-zuid vooraf  

inclinationNSAfter

helling noord-zuid achteraf  

inclinationResultantBefore

hellingresultante vooraf  

inclinationResultantAfter

hellingresultante achteraf  

localFrictionBefore

plaatselijke wrijving vooraf  

localFrictionAfter

plaatselijke wrijving achteraf  

porePressureU1Before

waterspanning u1 vooraf  

porePressureU1After

waterspanning u1 achteraf  

porePressureU2Before

waterspanning u2 vooraf  

porePressureU2After

waterspanning u2 achteraf  

porePressureU3Before

waterspanning u3 vooraf  

porePressureU3After

waterspanning u3 achteraf  

A3: brocommon

Engels

Nederlands

AbortReason

Reden afbreken

sequenceNumber

Volgnummer

specification

Foutmelding

Area

Gebied

boundingBox

Omsluitende rechthoek

enclosingCircle

Omsluitende cirkel

Characteristics

Kengegevens

broId

BRO-ID

deliveryAccountableParty

Bronhouder

deregistered

Uit registratie genomen

latestCorrectionTime

Tijdstip laatste correctie

objectRegistrationTime

Tijdstip registratie object

qualityRegime

Kwaliteitsregime

underReview

In onderzoek

Circle

Cirkel

center

Middelpunt

radius

Straal

srsName

Referentiestelsel

CorrectionRequest

Correctieverzoek

broId

BRO-ID

deliveryAccountableParty

Bronhouder

qualityRegime

Kwaliteitsregime

requestReference

Verzoekkenmerk

underPrivilege

Onder voorrecht

CriteriaSet

Kenmerkenverzameling

correctionPeriod

Periode van correctie

deliveryAccountableParty

Bronhouder

qualityRegime

Kwaliteitsregime

registrationPeriod

Periode van registratie

underReview

In onderzoek

CriterionError

Kenmerkfout

sequenceNumber

Volgnummer

specification

Foutmelding

DatePeriod

Datuminterval

beginDate

Begindatum

endDate

Einddatum

DeregisteredObject

Object uit registratie genomen

broId

BRO-ID

deregistered

Uit registratie genomen

deregistrationTime

Tijdstip uit registratie genomen

DispatchDataRequest

Verzoek tot verzending gegevens

broId

BRO-ID

requestReference

Verzoekkenmerk

DispatchResponse

Bericht van verzending

dispatchTime

Tijdstip van uitgifte

rejectionReason

Reden afwijzing

rejectionTime

Tijdstip van afwijzing

requestReference

Verzoekkenmerk

responseType


IntakeResponse

Bericht van registratie

acceptanceTime

Tijdstip van acceptatie

broId

BRO-ID

completionTime

Tijdstip van verwerking

objectIdAccountableParty

Object-ID bronhouder

rejectionReason

Reden afwijzing

rejectionTime

Tijdstip van afwijzing

requestReference

Verzoekkenmerk

responseType


transactionId

Transactie-ID

ParseFault

Validatiefout

abortTime

Moment van afbreken

requestReference

Verzoekkenmerk

transactionId

Transactiecode

PartialDate

Onvolledige datum

date

Datum tot op de dag nauwkeurig

voidReason

Geen datum bekend

year

Datum tot op het jaar nauwkeurig

yearMonth

Datum tot op de maand nauwkeurig

Radius

Straal

uom (unit of measure)

Eenheid

value

Waarde

RegistrationHistory

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

Registratieobject

broId

BRO-ID

deliveryAccountableParty

Bronhouder

deliveryResponsibleParty

Dataleverancier

objectIdAccountableParty

Object-ID bronhouder

qualityRegime

Kwaliteitsregime

RegistrationRequest

Registratieverzoek

broId

BRO-ID

deliveryAccountableParty

Bronhouder

requestReference

Verzoekkenmerk

qualityRegime

Kwaliteitsregime

underPrivilege

Onder voorrecht

SourceDocumentError

Brondocumentfout

sequenceNumber

Volgnummer

specification

Foutmelding

StandardizedLocation

Gestandaardiseerde locatie

coordinateTransformation

Coördinaattransformatie  

CRS

Referentiestelsel  

location

Coördinaten  

srsName

Referentiestelsel  

A4: Codelijsten

CPT codelijsten
Codespace URI: urn:bro:cpt:<Engelse naam>

Engels

Nederlands

CPTMethod

*Sondeermethode  

CPTStandard

*Sondeernorm  

DeliveryContext

*KaderAanlevering  

HorizontalPositioningMethod

*MethodeLocatiebepaling  

LocalVerticalReferencePoint

*LokaalVerticaalReferentiepunt  

QualityClass

*Kwaliteitsklasse  

StopCriterion

*Stopcriterium  

SurveyPurpose

*KaderInwinning  

VerticalDatum

*VerticaalReferentievlak  

VerticalPositioningMethod

*MethodeVerticalePositiebepaling  


BRO algemene codelijsten
Codespace URI: urn:bro:<Engelse term>

Engelse naam

Nederlandse naam

CoordinateTransformation

Coördinaattransformatie

RegistrationStatus

Registratiestatus

A5 Enumeraties

Engels

Nederlands

DispatchResponseTypeEnumeration

n.v.t.

IndicationYesNoEnumeration

IndicatieJaNee

IndicationYesNoUnknownEnumeration

IndicatieJaNeeOnbekend

IntakeResponseTypeEnumeration

n.v.t.

QualityRegimeEnumeration

KwaliteitsRegime

VoidReasonEnumeration

n.v.t.


De enumeraties, die in de kolom Nederlands een waarde "n.v.t." hebben, zijn niet gedefinieerd in de catalogus, het innamehandboek of het uitgiftehandboek. Deze enumeraties zijn geïntroduceerd in de koppelvlakdefinities.

Bijlage B: DataRecord definitie bestanden

CPTTestResultRecord

<? xml version= "1.0" encoding= "UTF-8" ?>
< swe:DataRecord id= "EXAMPLE_03" xmlns:swe= "http://www.opengis.net/swe/2.0"
xmlns:gml= "http://www.opengis.net/gml/3.2" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance"
xmlns:xlink= "http://www.w3.org/1999/xlink"
xsi:schemaLocation= "http://www.opengis.net/swe/2.0 http://schemas.opengis.net/sweCommon/2.0/swe.xsd" >
< swe:label > Conuspenetratietest resultaat record</ swe:label >
< swe:description > Beschrijving/formaat van de parameters van een Conuspenetratietest </ swe:description >
< swe:field name= "penetrationLength" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "m" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "depth" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "m" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "elapsedTime" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "s" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "coneResistance" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "MPa" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "correctedConeResistance" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "MPa" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "netConeResistance" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "MPa" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "magneticFieldStrengthX" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "nT" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "magneticFieldStrengthY" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "nT" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "magneticFieldStrengthZ" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "nT" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "magneticFieldStrengthTotal" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "nT" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "electricalConductivity" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "S/m" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "inclinationEW" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "deg" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "inclinationNS" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "deg" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "inclinationX" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "deg" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "inclinationY" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "deg" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "inclinationResultant" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "deg" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "magneticInclination" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "deg" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "magneticDeclination" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "deg" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "localFriction" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "MPa" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "poreRatio" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "1" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "temperature" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "degC" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "porePressureU1" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "MPa" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "porePressureU2" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "MPa" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "porePressureU3" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "MPa" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "frictionRatio" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "%" />
</ swe:Quantity >
</ swe:field >
</ swe:DataRecord >

DissipationTestResultRecord

<? xml version= "1.0" encoding= "UTF-8" ?>
< swe:DataRecord id= "EXAMPLE_03" xmlns:swe= "http://www.opengis.net/swe/2.0"
xmlns:gml= "http://www.opengis.net/gml/3.2" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance"
xmlns:xlink= "http://www.w3.org/1999/xlink"
xsi:schemaLocation= "http://www.opengis.net/swe/2.0 http://schemas.opengis.net/sweCommon/2.0/swe.xsd" >
< swe:field name= "elapsedTime" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "s" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "coneResistance" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "MPa" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "porePressureU1" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "MPa" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "porePressureU2" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "MPa" />
</ swe:Quantity >
</ swe:field >
< swe:field name= "porePressureU3" >
< swe:Quantity >
< swe:nilValues >
< swe:NilValues >
< swe:nilValue reason= "urn:ogc:def:nil:OGC:unknown" >-999999</ swe:nilValue >
</ swe:NilValues >
</ swe:nilValues >
< swe:uom code= "MPa" />
</ swe:Quantity >
</ swe:field >
</ swe:DataRecord >

JavaScript errors detected

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

If this problem persists, please contact our support.