Dit is versie 1.1 van deze handreiking. Ons doel is hiermee om de informatie mbt technische aanlevering van BRO gegevens in 1 document weer te geven. We zien versie 1.1 als een vroege iteratie en streven in het derde kwartaal van 2021 naar een volgende versie die de generieke informatie uit de diverse berichtencatalogi (en handboeken/koppelvlakbeschrijvingen) kan vervangen. Mocht u een fout aantreffen of een tekortkoming constateren, of anderszins feedback willen geven, neem dan contact op met de BRO servicedesk (zie paragraaf Contactinformatie).

1. Inleiding

1.1. Voorwoord

Betrouwbare en toegankelijke informatie over de samenstelling en opbouw van de ondergrond is van groot belang voor een dichtbevolkt land als Nederland. Het helpt overheden, bedrijven en burgers om op feiten gebaseerde beslissingen te nemen over het gebruik van de ondergrond, bijvoorbeeld in verband met bereikbaarheid, waterveiligheid, warmte- en koudeopslag, aardgasproductie en de winning van aardwarmte. Centrale registratie van gegevens voorkomt dat informatie dubbel moet worden ingewonnen.

Het verzamelen, beschikbaar stellen, en gebruiken van al deze informatie is sinds september 2015 wettelijk vastgelegd in de Basisregistratie Ondergrond (BRO). Op 1 januari 2018 is het eerste deel van de Wet BRO in werking getreden, op 1 januari 2020 het tweede deel en op 1 januari c.q. 1 juli 2021 het derde deel. 

Omdat de BRO een onderdeel is van het Stelsel van Basisregistraties, zijn verplichtingen met betrekking tot aanlevering, gebruik, terugmelding en onderzoek in de werkprocessen van overheidsorganisaties opgenomen in de Wet BRO. De BRO-gegevens worden centraal geregistreerd in de Landelijke Voorziening BRO (LV-BRO).

In het document Handreiking Afname BRO Gegevens wordt beschreven via welke uitgiftekanalen BRO-gegevens geraadpleegd of gedownload kunnen worden en welke functionele en technische mogelijkheden deze kanalen bieden.

Blijft over de vraag hoe een bronhouder of dataleverancier gegevens aan kan leveren.

1.2. Doelstelling

Veel partijen worstelen met het op gang brengen van (de ontwikkeling van software voor) het aanleveren van BRO-gegevens. De weg naar een Gegevenscatalogus weet men over het algemeen wel te vinden. Ook het bestaan van het bronhouderportaal is meestal wel bekend. Maar hoe moet men een BRO-verzoek in de vorm van een XML-bestand opstellen? Hoe ziet zo'n XML-bestand er uit? Hoe moet je te werk gaan als de gegevens niet in één keer beschikbaar komen maar beetje bij beetje in de loop der tijd? Of veranderen in de loop der tijd? En hoe kun je een fout corrigeren, die is geslopen in de geregistreerde gegevens?

Op deze vragen probeert deze handreiking een antwoord in algemene zin te geven.

Dit document bevat geen informatie, die specifiek is voor een bepaald registratieobject. Daarvoor wordt doorverwezen naar de Berichtencatalogus innamewebservice en de Gegevenscatalogus, in die volgorde, van het betreffende registratieobject. Dit document beschrijft ook niet hoe een bronhouder of dataleverancier met het bronhouderportaal een BRO-verzoek kan aanleveren. Dat staat beschreven in de handleiding van het bronhouderportaal. Zie paragraaf Samenhang met andere documentatie voor nadere informatie over deze 2 onderwerpen.

1.3. Doelgroep

Doelgroep voor dit document zijn organisaties en personen, waaronder bestuursorganen en bedrijven, die opereren als bronhouder, gegevensleverancier of softwareleverancier en die betrokken zijn bij het opstellen van BRO-verzoeken. En waarvoor het opstellen van een BRO-verzoek en het aanleveren daarvan via het bronhouderportaal een nieuwe aangelegenheid is. Voor hen kan de hier aangereikte algemene informatie een waardevolle tussenstap zijn, voordat men verder gaat met de Berichtencatalogus of Gegevenscatalogus van een bepaald type registratieobject.

1.4. Samenhang met andere documentatie

De informatievoorziening over het aanleveren aan de BRO vindt plaats op 3 niveaus. Zie onderstaande figuur.


  1. Het startpunt met algemene informatie over de BRO is de website www.basisregistratieondergrond.nl. Een stappenplan voor het verkrijgen van toegang tot het Bronhouderportaal is te vinden op https://basisregistratieondergrond.nl/inhoud-bro/aanleveren-opvragen/tools-tips/bronhouderportaal
  2. Het tweede niveau is het Bronhouderportaal, met rechtsonderaan een link naar de gebruikshandleiding, zie BRO bronhouderportaal-handleiding
  3. Het derde niveau is de BRO Productomgeving. Hier vindt u onder meer algemene informatie en specifieke informatie per domein/registratieobjecttype, zie https://www.bro-productomgeving.nl/bpo/latest

Het verdient aanbeveling dat u zich eerst bekend maakt met de aangeven informatie uit de eerste 2 niveau's en daarna met de inhoud van dit document, de 'Handreiking aanleveren BRO-gegevens'. Deze algemene informatie kan een waardevolle tussenstap zijn, voordat u verder gaat met de Berichtencatalogus of Gegevenscatalogus van een bepaald type registratieobject (zie paragraaf BRO Productomgeving).

In de BRO Productomgeving vindt u zowel algemene informatie als specifieke informatie per domein/registratieobjecttype. Toegang tot specifieke informatie per domein en vervolgens registratieobjecttype is samengevat op landingspagina's. Zie de onderstaande tabel.

De specifieke informatie per domein en vervolgens per registratieobjecttype in de BRO Productomgeving is toegankelijk via landingspagina's. Zie de links in onderstaande tabel.

DomeinRegistratieobjectLandingspagina
Bodem- en grondonderzoek




Bodemkundig booronderzoekBodemkundig booronderzoek (BHR-P) (bro-productomgeving.nl)
Geologisch booronderzoekGeologisch booronderzoek (BHR-G) (bro-productomgeving.nl)
Geotechnisch booronderzoekGeotechnisch booronderzoek (BHR-GT) (bro-productomgeving.nl)
Geotechnisch sondeeronderzoekGeotechnisch sondeeronderzoek (CPT) (bro-productomgeving.nl)
WandonderzoekWandonderzoek (SFR) (bro-productomgeving.nl)
GrondwatergebruikGrondwatergebruiksysteemnog niet beschikbaar, release gepland 2022
Grondwaterproductiedossiernog niet beschikbaar, release gepland 2022
Grondwatermonitoring



GrondwatermonitoringnetGrondwatermonitoringnet (GMN) (bro-productomgeving.nl)
GrondwatermonitoringputGrondwatermonitoringput (GMW) (bro-productomgeving.nl)
GrondwatersamenstellingsonderzoekGrondwatersamenstellingsonderzoek (GAR) (bro-productomgeving.nl)
GrondwaterstandonderzoekGrondwaterstandonderzoek (GLD) (bro-productomgeving.nl)
FormatieweerstandonderzoekFormatieweerstandonderzoek (FRD) (bro-productomgeving.nl)
MijnbouwwetMijnbouwwetvergunningnog niet beschikbaar, release gepland 2022
Mijnbouwconstructiesnog niet beschikbaar, release gepland 2022

Op iedere landingspagina vindt u links naar:

  • Het Scope document.
  • De Gegevenscatalogus, met daarin de definities van de gegevens, en ook links naar de gemaakte werkafspraken.
  • De betreffende Berichtencatalogus innamewebservice, met daarin de definities van de beschikbare brondocumenten.
  • Een pagina met integrale voorbeeldberichten.
  • De website waar de WSDL-bestanden en de XSD-bestanden gevonden kunnen worden.

Voor het aanleveren van Modellen gelden andere regels. Neem in voorkomende gevallen contact op met de BRO Servicedesk (zie Contactinformatie).

1.5. Leeswijzer

Hoofdstuk 2 beschrijft de rol van het bronhouderportaal in het aanleverproces.

Hoofdstuk 3 bevat de beschrijving van een aantal Algemene concepten.

Hoofdstuk 4 bevat de beschrijving van de opbouw van een BRO-verzoek.

Hoofdstuk 5 bevat de definities van requests en hun transactiegegevens

Hoofdstuk 6 bevat enkele Scenario's voor het aanleveren van registratieverzoeken en correctieverzoeken.

Hoofdstuk 7 bevat enkele specifieke XML Code snippets uit de XML-bestanden van een BRO-verzoek.

Hoofdstuk 8 bevat een overzicht van Enumeraties (niet beheerde codelijsten) met hun toegestane waarden.

Hoofdstuk 9 bevat een doorkijkje naar de specifieke berichtencatalogi.

1.6. Versiehistorie

Versie

Datum

Omschrijving

1.030-06-2021Eerste versie; afgeleid van de registratieobjecttype specifieke berichtencatalogi innameservice uit tranche 2 en 3.
1.103-09-2021Redactionele aanpassingen, met name hoofdstuk1 (ten dele afgesplitst in wat nu hoofdstuk 2 is).

1.7. Contactinformatie

Algemene informatie en documentatie over de BRO kunt u vinden op https://basisregistratieondergrond.nl/.

Heeft u een vraag over de BRO? Wij staan voor u klaar om u te helpen. Voor vragen, suggesties of opmerkingen kunt contact opnemen met de BRO Servicedesk via een mail naar support@broservicedesk.nl.

Als u toegang heeft tot de BRO Selfservicedesk via http://topdeskbro.gdnnet.lan/ kunt u daar inloggen en uw vraag stellen voor een extra snelle afhandeling.

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

2. Bronhouderportaal nodig om gegevens aan te leveren

Om het werk voor de bronhouders en gegevensleveranciers te vergemakkelijken, is het bronhouderportaal ontwikkeld. Het bronhouderportaal is een voorportaal voor het leveren aan de LV-BRO. Bronhouders van de BRO zijn wettelijk verantwoordelijk voor het aanleveren van gegevens en de kwaliteit daarvan. 

Vaak besteden bronhouders het inwinnen en aanleveren van gegevens uit aan een gegevensleverancier (bijvoorbeeld een ingenieursbureau voor sonderingen en boringen). Het is aan te raden contractueel vast te leggen dat een gegevensleveranciers de gegevens moet aanleveren bij de BRO. Let wel: de bronhouder blijft eindverantwoordelijk voor, onder andere, de kwaliteit van de aangeleverde gegevens.

Het bronhouderportaal is een webapplicatie voor de aanlevering van ondergrondgegevens aan de Basisregistratie Ondergrond (BRO). Met het bronhouderportaal kunnen de betrokken partijen zaakgericht de gegevens aanbieden, valideren, controleren, vaststellen en aanleveren bij de LV-BRO.

2.1. Gegevens aanleveren

Het bronhouderportaal is te vinden op webpagina https://www.bronhouderportaal-bro.nl/login. Rechtsonderaan op deze webpagina is een link is te vinden naar de gebruikshandleiding (zie BRO Bronhouderportaal handleiding).

Aanleveren van gegevens bij de LV-BRO kan alleen via het Bronhouderportaal. Zie Bronhouderportaal voor een inleiding en een link naar de handleiding. Bronhouders én gegevensleveranciers zijn verplicht te werken met het Bronhouderportaal. 

Het Bronhouderportaal is een zelfstandige webapplicatie met een automatische koppeling naar de LV-BRO. Hier kan een bronhouder de betrokken partijen en personen opvoeren en hun taken/autorisaties inrichten. Vervolgens kunnen nieuwe gegevens in vijf stappen worden aangeleverd, gevalideerd, gecontroleerd, vastgesteld en doorgeleverd aan de LV-BRO (zie onderstaande screenshots als toelichting).

Leveringsoverzicht


Naast de webpagina's beschikt het Bronhouderportaal ook over een REST API, waarmee u BRO-verzoeken geautomatiseerd kunt (laten) aanleveren. Volg hiervoor de online instructie REST API. De zendende software heeft voor dit proces een token nodig. De handleiding van het Bronhouderportaal beschrijft hoe een dataleverancier zo'n token kan aanmaken.

De demo-omgeving van de LV-BRO beschikt over een validatieservice. Volg hiervoor de online instructie validatiesevice. Met de validatieservice kunt u testen of een levering verwerkt kan worden door het Bronhouderportaal. U kunt op die manier fouten eruit halen voordat u de gegevens aanlevert bij het Bronhouderportaal. De validatieservice is alleen beschikbaar in de demo-omgeving. Op die manier wordt voorkomen dat een testbestand per ongeluk terecht komt in de productie-omgeving. In de demo-omgeving kunt u de validatieservice dus veilig gebruiken om uw bestanden te testen.

Elke levering bevat één of meer BRO-verzoeken om ondergrondgegevens in de BRO te registreren of te corrigeren (in het Bronhouderportaal worden de BRO-verzoeken abusievelijk omschreven als brondocumenten). Elk BRO-verzoek is vastgelegd in een apart bestand in XML-formaat. De rest van dit document gaat over hoe zo'n BRO-verzoek opgesteld kan worden.

2.2. Wat gebeurt er met uw aangeleverde gegevens?

Nadat u de aangeleverde gegevens in het bronhouderportaal hebt gecontroleerd en vastgesteld, worden deze doorgeleverd naar de LV-BRO. Als een levering meerdere BRO-verzoeken bevat, dan worden deze een voor een verstuurd naar de innameservice van de LV-BRO. Helaas kan hierbij de onderlinge volgorde niet worden gegarandeerd. Dit kan ernstige nadelige gevolgen hebben als een BRO-verzoek voortborduurt op een ander BRO-verzoek in dezelfde levering. Plaats in voorkomende gevallen BRO-verzoeken in aparte leveringen, zodat u door het achtereenvolgens vaststellen van de leveringen controle behoudt over de volgorde waarin onderling afhankelijke BRO-verzoeken worden verwerkt.


De LV-BRO verwerkt een voor een de binnenkomende BRO-verzoeken. Iedere poging een BRO-verzoek te verwerken leidt tot een record in het transactieregister van de LV-BRO. Vervolgens wordt het BRO-verzoek inhoudelijk gecontroleerd. Dit begint met een validatie tegen de XML schema definities (de XSD-bestanden; zie https://schema.broservices.nl/). Daarna wordt gecontroleerd of de inhoud van het BRO-verzoek voldoet aan de bedrijfsregels, zoals vastgelegd in de betreffende gegevenscatalogus, de aanvullende regels in dit document en de aanvullende regels in de betreffende berichtencatalogus. Dit kan zijn op basis van de inhoud van het BRO-verzoek 'an sich' en/of binnen de context van de voor het registratieobject in de LV-BRO reeds geregistreerde gegevens. Als het BRO-verzoek akkoord wordt bevonden, wordt het brondocument in het BRO-verzoek opgeslagen in het brondocumentenregister en wordt de inhoud van het BRO-verzoek verwerkt in het objectregister van de LV-BRO. In alle gevallen leidt de poging een BRO-verzoek te verwerken tot een antwoord (naar het bronhouderportaal). In het antwoord staat ondermeer of de verwerking is geslaagd of niet. Als het om een nieuw registratieobject gaat, dan staat in het antwoord ook welke waarde voor het BRO-ID het registratieobject heeft gekregen. Op basis daarvan kunnen de geregistreerde gegevens worden gecorrigeerd, voor het geval het aangeleverde BRO-verzoek een fout bevatte, of kan het registratieobject, indien van toepassing, worden aangevuld, of kunnen de geregistreerde gegevens worden opgevraagd. Bewaar dit BRO-ID dus zorgvuldig!

2.3. Geregistreerde gegevens raadplegen

Een afnemer van de LV-BRO heeft de beschikking over diverse uitgifteportalen, waarmee in de LV-BRO geregistreerde gegevens geraadpleegd kunnen worden (zie Handreiking Afname BRO Gegevens). Overheidsorganen zijn in het kader van het Stelsel van Basisregistraties verplicht authentieke gegevens in de LV-BRO te gebruiken.

2.4. Terugmelden van fouten

De gegevens in de LV-BRO moeten voldaan aan hoge kwaliteitseisen. Desondanks kan een afnemer gerede twijfel hebben over de correctheid van een bepaald authentiek gegeven. In dat geval kan de afnemer een terugmelding plaatsen. Overheidsorganen zijn in het kader van het Stelsel van Basisregistraties verplicht in voorkomende gevallen een terugmelding te plaatsen. De terugmelding bevat in ieder geval het BRO-ID van het betreffende registratieobject. Terugmelden is een belangrijk middel om de kwaliteit van de geregistreerde gegevens te verbeteren.

Op basis van de terugmelding zal de registratiebeheerder (zie BRO Servicedesk bij Contactinformatie) het registratieobject 'in onderzoek' plaatsen. Dat geeft voor andere afnemers aan, dat er een terugmelding is geplaatst op het registratieobject. Dat laat onverlet dat overheidsorganen verplicht zijn de momenteel geregistreerde authentieke gegevens in de LV-BRO te gebruiken.

De registratiebeheerder stuurt de terugmelding door naar de bronhouder van het registratieobject. Deze start een onderzoek of de gerede twijfel correct is. Zo ja, dan zal de bronhouder een correctieverzoek indienen, nu met de juiste gegevens. Zie paragraaf Corrigeren van gegevens bij een object zonder materiele geschiedenis of paragraaf Corrigeren van gegevens bij een object met materiële geschiedenis in het algemeen en de waarde 'inOnderzoek' in de codelijst CorrectionReason in het bijzonder. Het object is dan niet langer 'in onderzoek'. Ook als de bronhouder tot de conclusie komt dat de momenteel geregistreerde gegevens correct zijn, moet het object 'uit in onderzoek' genomen worden. Dat kan geautomatiseerd met een correctieverzoek, met als correctiereden 'inOnderzoek' en als inhoud van het brondocument nogmaals de actuele gegevens, of handmatig door de registratiebeheerder te vragen het registratieobject 'uit in onderzoek' te nemen. De bronhouder moet het correctieverzoek (laten) aanleveren via het bronhouderportaal.

3. Algemene concepten

De inhoud van de diverse BRO-verzoeken volgt een simpele, vaste structuur. Om deze varianten en hun structuur te kunnen begrijpen, beschrijft dit hoofdstuk een viertal algemene concepten. Kennisnemen van deze concepten helpt bij het bepalen wanneer welk type BRO-verzoek gebruikt moet worden en welke onderdelen van de vaste structuur van deze BRO-verzoeken dan van belang zijn.

3.1. Levensloop

3.1.1. Geen levensloop

Bij sommige objecten worden alle beschikbare gegevens altijd in een keer geregistreerd. Deze objecten hebben geen levensloop. De registratie van gegevens over zo'n object is dan een eenmalige gebeurtenis. 


Bovenstaande figuur visualiseert deze situatie. Een medewerker van de dataleverancier overhandigt alle gegevens in één keer aan de bronhouder (via het bronhouderportaal). De bronhouder zorgt ervoor dat de gegevens in één brondocument worden doorgeleverd naar de LV-BRO. Twee voorbeelden van registratieobjecttypes zonder levensloop: Geotechnisch Sondeeronderzoek (CPT) en Grondwatersamenstellingsonderzoek (GAR).

3.1.2. Wel levensloop

Andere objecten kennen een levensloop. De levensloop van een object heeft een begin en een eind. In deze periode kunnen gebeurtenissen optreden, naar aanleiding waarvan veranderingen in gegevens geregistreerd moeten worden in de LV-BRO. De registratie van gegevens over zo'n object is dus een proces dat zo lang duurt als het object bestaat.


Bovenstaande figuur visualiseert deze situatie.

Een medewerker van de dataleverancier en/of de bronhouder stelt een 'start document' op, waarmee de eerste gegevens voor het registratieobject worden aangeleverd bij het bronhouderportaal. De bronhouder zorgt ervoor dat de gegevens in één brondocument worden doorgeleverd naar de LV-BRO. Het spreekt voor zich dat het starten van de registratie een eenmalige gebeurtenis is.

Dezelfde of een andere medewerker zorgt ervoor dat er een of meerdere keren 'aanvullende gegevens', bijvoorbeeld naar aanleiding van een labonderzoek of wederkerend veldwerk, worden aangeleverd bij het bronhouderportaal. De bronhouder zorgt ervoor dat ieder brok met aanvullende gegevens automatisch of handmatig in een brondocument wordt doorgeleverd naar de LV-BRO. Het aanvullen van de registratie is een gebeurtenis die meerdere keren kan plaats vinden.

Als met de laatste aanvulling de registratie niet meteen wordt voltooid, dan zorgt de bronhouder ervoor dat er een 'afsluitend document' wordt opgesteld en dat de gegevens daarin via het bronhouderportaal als brondocoment worden doorgeleverd naar de LV-BRO. Het spreekt voor zich dat het voltooien van de registratie een eenmalige gebeurtenis is. Nadat de registratie van een registratieobject is voltooid, kan de registratie niet meer worden aangevuld.

Twee voorbeelden van registratieobjecttypes met levensloop: Bodemkundig booronderzoek (BHR-P) en Grondwaterstandonderzoek (GLD).

3.1.3. Aanlevertermijn

Gegevens moeten worden aangeboden met een registratieverzoekZie hoofdstuk Requests. Ongeacht of dit is naar aanleiding van een eenmalige gebeurtenis of een gebeurtenis gedurende een levensloop. Een dataleverancier moet gegevens tijdig registreren (binnen 20 werkdagen, zie artikel 9 in de Wet bro). Het uitgangspunt is dat gegevens worden aangeleverd zo kort mogelijk nadat zij zijn geproduceerd. Bij objecten met een levensloop betekent tijdig ook in de juiste chronologische volgorde, namelijk de volgorde waarin de gebeurtenissen in de werkelijkheid zijn opgetreden. Dat veronderstelt dat de processen bij de dataleverancier zo zijn ingericht dat ze aansluiten op de productie van gegevens.

3.2. Gebeurtenissen

De aard van de gebeurtenis, die in de werkelijkheid optreedt tijdens de levensloop van een object, kan verschillen. Tenzij anders vastgelegd in de berichtencatalogus houdt de LV-BRO bij een object met levensloop een lijst bij van alle gemelde gebeurtenissen, c.q. de aangeboden brondocumenten. Daarbij worden de volgende gegevens opgeslagen, zodat binnnen een registratieobject een aangeleverd brondocument uniek geïdentificeerd kan worden:


  • date (datum): de datum waarop de gebeurtenis heeft plaats gevonden in de werkelijkheid. Dat is niet noodzakelijkerwijs dezelfde datum als waarop de betreffende gegevens worden aangeboden bij de LV-BRO (tijdstip registratie).
  • name (naam): de naam van de gebeurtenis, afgeleid van het type brondocument. Deze namen zijn opgenomen in een codelijst en per registratieobject gedefinieerd in de gegevenscatalogus.
  • (indien van toepassing) identification (identificatie): de unieke identificatie van een entiteit in een lijst van entiteiten binnen het registratieobject. Bijvoorbeeld meetpuntcode bij Grondwatermonitoringnet (GMN) of observatie ID bij Grondwaterstandonderzoek (GLD).

De gebeurtenissen moeten in chronologische volgorde worden aangeboden, dat wil zeggen in oplopende waarde voor het attribuut date (datum). Een 'vergeten' gebeurtenis, waarvan de date (datum) ouder is dan de meest recente, geregistreerde gebeurtenis, moet met een insertRequest (invoegverzoek) worden ingevoegd in de tijdlijn. Zie hoofdstuk Requests

In de LV-BRO moet elke geregistreerde gebeurtenis uniek zijn. In de werkelijkheid kunnen op een bepaalde datum meerdere gebeurtenissen optreden. Bij de meeste types registratieobjecten volstaat het dat de combinatie van date (datum) en name (naam) van het Event (Gebeurtenis) uniek is. Bij sommige types registratieobjecten, met name wanneer er sprake is van een lijst van gegevens die aangevuld moet kunnen worden, is dit niet voldoende. Dan heeft ieder object of iedere gegevensgroep in een lijst met gegevens een unieke aanduiding. In dat geval vormt de combinatie van date (datum), name (naam) en identification (identificatie) een unieke combinatie in de lijst met Events (Gebeurtenissen). In voorkomende gevallen is dit aangeveven in de berichtencatalogus innamewebservice van het betreffende type registratieobject.

Deze lijst met gebeurtenissen wordt beschikbaar gesteld via de uitgifteservice. Aan de hand van de gebeurtenisnaam weet de dataleveranciers welk brondocument opgenomen moet worden in een correctieverzoek. En, indien van toepassing, aan de hand van de identification (identificatie) weet de leverancier welke entiteit (in de lijst met entiteiten) gecorrigeerd moet worden.

3.3. Tijdlijn

Bij een object met levensloop begint het proces van registreren met het starten van de registratie, gevolgd door het aanvullen en uiteindelijk het beëindigen van de registratie.


Bij het starten van de registratie geeft de bronhouder/dataleverancier een begindatum op. Deze datum moet in het verleden liggen. In de LV-BRO krijgt het registratieobject de registratiestatus GeregistreerdTotdat de registratie is voltooid blijft het registratieobject vanuit het oogpunt van de LV-BRO actief. Ook als er gedurende enige of langere tijd geen gebeurtenissen optreden in de werkelijkheid.

Wanneer zich gedurende de levensloop een relevante verandering voordoet, worden de nieuwe gegevens aangeboden bij de LV-BRO. In de LV-BRO krijgt het registratieobject de registratiestatus Aangevuld

Bij het beëindigen van de registratie geeft de bronhouder/dataleverancier een einddatum op. In de LV-BRO krijgt het registratieobject de registratiestatus VoltooidHierna kan het registratieobject niet meer worden aangevuld. De geregistreerde gegevens blijven na het beëindigen van de registratie opvraagbaar door afnemers.

3.4. Geschiedenis

De BRO maakt een onderscheid tussen materiële geschiedenis en formele geschiedenis. Bij materiële geschiedenis gaat het om een verandering in de werkelijkheid, waardoor bestaande gegevens een andere waarde krijgen of bestaande gegevens niet langer van belang zijn of dat er nieuwe gegevens ontstaan. Bij formele geschiedenis gaat het om corrigeren van (de waarde van) een in de LV-BRO geregistreerd gegeven, omdat er een fout is gemaakt. Zie voor een inleiding op dit onderwep de paragraaf met de titel "Formele en materiële geschiedenis" in één van de gegevenscatalogi.

3.4.1. Materiële geschiedenis

Bij materiële geschiedenis is de aanleiding voor het aanleveren van gegevens het optreden van een gebeurtenis in de werkelijkheid. Daarbij kan het gaan om het aanleveren van nieuwe gegevens, of het aanleveren van een nieuwe waarde voor een geregistreerd gegeven, of het melden dat een geregisteerd gegeven niet meer van belang is. Enkele voorbeelden: de inrichting van de put is gewijzigd; er is een nieuwe grondwaterstand gemeten; de vergunning is aangepast; een meetpunt wordt buiten gebruik genomen.

Bij het opbouwen van materiële geschiedenis is van belang dat de gegevens in de juiste chronologische volgorde worden aangeboden, namelijk de volgorde waarin de gebeurtenissen in de werkelijkheid zijn opgetreden.

Bij het opbouwen van materiële geschiedenis wordt een onderscheid gemaakt tussen aanvullingen en aanpassingen:

  • Aanvulling: er worden nieuwe gegevens toegevoegd aan het in de LV-BRO geregistreerde object. Hierbij is van belang dat de aangeboden gegevens nieuw zijn, dat wil zeggen hetzelfde gegeven is niet reeds aanwezig in de registratie.
  • Aanpassing: er worden nieuwe waarden voor reeds in de LV-BRO geregistreerde gegevens gemeld. Hierbij is van belang dat ieder tweetal van opeenvolgende waarden verschillend moet zijn.

In beide gevallen is het nieuwe gegeven of de nieuwe waarde geldig vanaf de datum van de gebeurtenis (datum begin geldigheid). Een voorgaande waarde blijft behouden en is geldig tot de datum van de gebeurtenis (datum einde geldigheid).

  • Een gegeven zonder een datum einde geldigheid noemen we een actueel gegeven.
  • Een gegeven met een datum einde geldigheid noemen we een historisch gegeven.
  • De waarde van een gegeven zonder een datum einde geldigheid noemen we de actuele waarde van het gegeven.
  • Een waarde van een gegeven met een datum einde geldigheid noemen we een historische waarde voor het gegeven.

Het opbouwen van materiële geschiedenis vindt plaats met een registratieverzoekZie hoofdstuk Requests.

3.4.2. Formele geschiedenis

Bij formele geschiedenis gaat het om het corrigeren van een onjuiste waarde in de registratie. De correctie vindt dus niet plaats naar aanleiding van een verandering in de werkelijkheid (materiële geschiedenis).

Een dataleverancier kan zich op allerlei manieren vergissen bij het aanbieden van gegevens. De dataleverancier kan bijvoorbeeld een typefout maken, of per ongeluk een onjuiste waarde voor een gegeven aanleveren, of een optioneel gegeven vergeten.

Bij een object met levensloop, waarbij er materiële geschiedenis wordt opgebouwd, kan er daarnaast sprake zijn van bijzondere fouten. Bijvoorbeeld een fout in de datum van een gebeurtenis, of vergeten gegevens aan te bieden naar aanleiding van een gebeurtenis, of omgekeerd aanbieden van gegevens naar aanleiding van een gebeurtenis maar deze gebeurtenis is helemaal niet opgetreden of is opgetreden voor een ander registratieobject.

Voor het corrigeren van fouten ondersteunt de LV-BRO een aantal verschillende soorten correctieverzoeken.Zie hoofdstuk Requests.

Bij een correctie wordt het betreffende gegeven in de registratie ondergrond overschreven, toegevoegd in de tijdlijn, verplaatst in de tijdlijn of verwijderd uit de tijdlijn. De oude waarde van een gegeven is niet meer direct beschikbaar voor een afnemer. Zou een afnemer toch willen weten wat de eerdere foute waarde was, dan moet deze het register brondocumenten van de LV-BRO raadplegen.

De formele geschiedenis wordt in de registratie ondergrond globaal vastgelegd in de registrationHistory (registratiegeschiedenis) van het object. Globaal wil zeggen dat alleen het tijdstip van de meest recente correctie wordt bijgehouden.

3.5. Aanvullende regels

Tijdens het verwerken van een BRO-verzoek voert de LV-BRO diverse controles uit. Zo wordt de inhoud van het brondocument gevalideerd tegen de gegevensdefinities in de gegevenscatalogus van het betreffende type registratieobject, inclusief de regels of indien van toepassing de IMBRO/A regels.

Het verwerken van een aanvulling, een beëindiging of een correctie verloopt anders dan (het starten van) een registratie in de zin dat er aanvullende regels worden toegepast. Die aanvullende regels zijn nodig omdat beoordeeld moet worden of de (gecorrigeerde) datum van de gebeurtenis past in de chronologische volgorde van de reeds geregistreerde gebeurtenissen en of de (gecorrigeerde) gegevens in het aangeboden brondocument passen bij de reeds in de LV-BRO geregistreerde gegevens. Deze aanvullende regels staan in de berichtencatalogus innamewebservice van het betreffende type registratieobject. 

Voor alle registratieobjecten met een levensloop gelden de volgende, algemene aanvullende regels:

  • De brondocumenten moeten in chronologische volgorde van date (datum) van het Event (Gebeurtenis) worden aangeleverd.
  • De combinatie van date (datum) en name (naam) van het Event (Gebeurtenis) en indien van toepassing de identification (identificatie) moet uniek zijn.
  • Indien het domein PartialDate (OnvolldigeDatum) van toepassing is, mogen alleen de date (datum) van de start/eind gebeurtenis de waarde 'onbekend' hebben; de date (datum) van een tussenliggende gebeurtenis mag niet de waarde 'onbekend' hebben.
  • De registratie kan niet meer aangevuld of beëindigd worden zodra de registratie is beëindigd (registrationStatus = voltooid).
  • Bij het opbouwen en corrigeren van materiële geschiedenis moet ieder tweetal van opeenvolgende waarden van een gegeven verschillend moet zijn.

4. BRO-verzoek

Dit hoofdstuk beschrijft de opbouw van een BRO-verzoek.

4.1. Inleiding

Om gegevens te registreren in de LV BRO moet u deze aanleveren bij het Bronhouderportaal in de vorm van een BRO-verzoek. Het BRO-verzoek is een bestand in IMBRO/XML-formaat. De eenheid van aanleveren is een brondocument. Voor ieder onderkend type gebeurtenis, dat kan optreden in de werkelijkheid, definieert de BRO een apart type brondocument, toegesneden op het aanleveren van de gegevens die beschikbaar komen bij die gebeurtenis. De onderstaande figuur schetst de algemene opbouw van een BRO-verzoek.


Een BRO-verzoek bestaat uit de naam van het type request (BRO-verzoek), de transactiegegevens en een brondocument. 

De LV-BRO kent 6 request-types. De volgende 3 paragrafen leggen uit welk type request u wanneer moet gebruiken. Hoofdstuk Requests definieert in detail de request-types en de bijbehorende transactiegegevens. De definities van de mogelijke brondocumenten kunt u vinden in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

4.2. Registreren van gegevens

Zoals beschreven in het hoofdstuk Algemene concepten kan er sprake zijn van het aanbieden van nieuwe gegevens in vier omstandigheden:

  1. Bij een object zonder levensloop: alle gegevens in één keer aanbieden naar aanleiding van een eenmalige gebeurtenis.
  2. Bij een object met levensloop:
    1. Als start van de registratie bij de eerste gebeurtenis.
    2. Als aanvulling bij een daarop volgende gebeurtenissen.
    3. Als beëindiging van de registratie bij de laatste gebeurtenis.

Voor alle 4 omstandigheden kan het registrationRequest (registratieverzoek) worden gebruikt. Zie de onderstaande figuur. Hoofdstuk Requests definieert in detail het registrationRequest en de bijbehorende transactiegegevens. 


De linker variant (initieel) kunt u gebruiken bij de omstandigheden 1 en 2a. In dit geval maakt de LV-BRO bij de verwerking van dit BRO-verzoek een nieuw registratieobject aan.

De rechter variant (aanvulling of beëindiging) kunt u gebruiken bij de omstandigheden 2b en 2c. In dit geval wordt de registratie van een object aangevuld of beëindigd. Het verschil met de linker variant is dat in de rechter variant het attribuut broID (BRO-ID) moet worden opgenomen, terwijl dit attribuut bij de linker variant afwezig moet zijn. Het attribuut broId (BRO-ID) geeft aan welk registratieobject in de LV-BRO u wilt aanvullen (2b) of beëindigen (2c).

Ieder registratieobject in de LV-BRO heeft een unieke identificatie, het BRO-ID. Deze bestaat uit 3 letters en 12 cijfers. De drie letters bevatten de mnemonic (afkorting) van het type registratieobject en de 12 cijfers zijn een volgnummer inclusief voorloopnullen. Bijvoorbeeld BHR000000342786. Nadat een Levering is vastgesteld en de BRO-verzoeken daarin zijn doorgeleverd aan de LV-BRO en daar succesvol zijn verwerkt, toont het bronhouderportaal in het tabblad Lijst de BRO-ID's van de aangemaakt registratieobjecten. Zie onderstaande figuur.

Dit BRO-ID hebt u nodig als u een registratieobject wilt aanvullen, de registratie ervan wilt beëindigen, de geregistreerde gegevens wilt corrigeren of wilt verwijzen naar het registratieobject vanuit een ander registratieobject.

 


4.3. Corrigeren van gegevens bij een object zonder materiële geschiedenis

Het corrigeren van gegevens, dat wil zeggen het verbeteren van onjuistheden in de geregistreerde gegevens, is eenvoudig bij een object waarbij geen materiële geschiedenis wordt opgebouwd.

De eenheid van corrigeren is een brondocument.

De LV-BRO kent 1 type correctieverzoek voor het corrigeren van gegevens bij een object zonder materiële geschiedenis:

Naam in XML-bestand

Nederlandse naam

Doel

correctionRequestcorrectieverzoek

Vervangen van een eerder aangeleverd brondocument bij een registratieobject zonder materiële geschiedenis.


Bij een correctieverzoek moet het volledige brondocument nogmaals worden aangeboden, maar nu met aangepaste (gecorrigeerde) gegegevens. Tenzij anders aangegegeven (zie de toegestane waarden van de codelijst CorrectionReason (correctiereden) in de betreffende Berichtencatalogus innamewebservice) is het niet mogelijk een brondocument te vervangen door een ander type brondocument.


De inhoud van een correctionRequest lijkt veel op die van een registrationRequest. Zie de onderstaande figuur. In vergelijking met een initieel registrationRequest zijn er 2 extra transactiegegevens. Het attribuut broID (BRO-ID) geeft aan welk registratieobject in de LV-BRO u wilt corrigeren. Het attribuut correctionReason (correctiereden) geeft aan waarom u de geregistreerde gegevens wilt corrigeren. Zie het hoofdstuk Requests voor nadere details.


Of dit type correctieverzoek van toepassing is voor een bepaald type registratieobject kunt u vinden in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

Een correctieverzoek wordt net als een registratieverzoek via het bronhouderportaal aangeboden bij de innamewebservice. De LV-BRO valideert de gegevens in het correctieverzoek 'op zichzelf' en in relatie tot de in de registratie aanwezige gegevens. Welke regels, als aanvulling op de regels in de gegegevenscatalogus, hierbij van toepassing zijn, is afhankelijk van het type brondocument. Deze aanvullende regels kunt u vinden in de Berichtencatalogus innamewebservice van het betreffende type registratieobject. Enkele algemene aanvullende regels staan in paragraaf Aanvullende regels van dit document.

4.4. Corrigeren van gegevens bij een object met materiële geschiedenis

Het corrigeren van gegevens, dat wil zeggen het verbeteren van onjuistheden in de geregistreerde gegevens, bij een object waarbij materiële geschiedenis wordt opgebouwd, is ingewikkelder dan bij een object waarbij dat niet het geval is. Dat komt doordat de temporele integriteit van de tijdlijn in stand moet worden gehouden. Daartoe voert de LV-BRO een aantal controles uit tijdens het verwerken van een BRO-verzoek.

De eenheid van corrigeren is een brondocument.

De LV-BRO kent 4 types correctieverzoeken voor het corrigeren van gegevens bij een object met materiële geschiedenis:

Naam in XML-bestand

Nederlandse naam

Doel

replaceRequestvervangverzoek

Vervangen van een eerder aangeleverd brondocument.

insertRequestinvoegverzoek

Invoegen van een 'vergeten' brondocument.

moveRequestverplaatsverzoek

Verplaatsen van een eerder aangeleverd brondocument op de tijdlijn van de materiële geschiedenis.

deleteRequestverwijderverzoek

Verwijderen van een eerder aangeleverd brondocument.


4.4.1. Algemene schets van de inhoud van de 4 correctieverzoeken

Bij een correctieverzoek moet hetzelfde brondocument nogmaals worden aangeboden, maar nu met aangepaste (gecorrigeerde) gegegevens. Tenzij anders aangegegeven (zie de toegestane waarden van de codelijst CorrectionReason (correctiereden) in de betreffende Berichtencatalogus innamewebservice) is het niet mogelijk een brondocument te vervangen door een ander type brondocument.

Alhoewel de LV-BRO tijdens het verwerken van een BRO-verzoek een aantal controles uitvoert m.b.t. de temporele integriteit van de tijdlijn, is het aan de bronhouder erop toe te zien dat het registratieobject in zijn geheel blijft voldoen aan de regels opgesteld in de gegevenscatalogus en de aanvullende regels in de berichtencatalogus innamewebservice. Dit speelt met name een rols als er bij een registratieobject meerdere brondocumenten zijn aangeleverd en één daarvan wordt gecorrigeerd. Bijvoorbeeld bij een booronderzoek mag er slechts één boormonsterbeschrijving en één boormonsteranalyse aanwezig zijn. Bijvoorbeeld bij een grondwatermonitoringput mag alleen een aanwezige monitoringbuis opgelengd worden.

De inhoud van deze 4 correctieverzoeken lijkt veel op die van een registrationRequest. Zie de onderstaande figuur. In vergelijking met een registrationRequest zijn er 2 extra transactiegegevens. Het attribuut broID (BRO-ID) geeft aan welk registratieobject in de LV-BRO u wilt corrigeren. Het attribuut correctionReason (correctiereden) geeft aan waarom u de geregistreerde gegevens wilt corrigeren. Het moveRequest (verplaatsverzoek) heeft een derde extra transactiegegeven, dateToBeCorrected (te corrigeren datum). Dit bevat de datum van de gebeurtenis waarvan het brondocument verplaatst moet worden naar een andere datum (de juiste datum is opgenomen in het brondocument van het moveRequest). Zie het hoofdstuk Requests voor nadere details.

Welke types correctieverzoeken van toepassing zijn voor een bepaald type registratieobject kunt u vinden in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

Alle 4 types van een correctieverzoek worden net als een registratieverzoek via het bronhouderportaal aangeboden bij de innamewebservice. De LV-BRO valideert de gegevens in het correctieverzoek 'op zichzelf' en in relatie tot de in de registratie aanwezige gegevens. Welke regels, als aanvulling op de regels in de gegegevenscatalogus, hierbij van toepassing zijn verschilt per type correctieverzoek en de inhoud van het correctieverzoek (met name het type brondocument). Deze aanvullende regels kunt u vinden in de Berichtencatalogus innamewebservice van het betreffende type registratieobject. Enkele algemene aanvullende regels staan in paragraaf Aanvullende regels van dit document.

4.4.2. ReplaceRequest

Met dit verzoek kan een bronhouder en/of dataleverancier onjuiste gegevens in de BRO op een bepaald punt op de tijdlijn vervangen door de juiste gegevens. De juiste gegevens worden aangeboden met één van de brondocumenten, zoals gedefinieerd in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie. Het aangeboden brondocument vervangt het momenteel geregistreerde brondocument.

Het is niet mogelijk de waarde van een individueel gegeven te corrigeren. Immers, de eenheid van aanleveren is een brondocument.

Met dit verzoek is het niet mogelijk de identificerende gegevens te corrigeren. 

Met dit verzoek is niet mogelijk de datum van de gebeurtenis te corrigeren (de gebeurtenis te verplaatsen op de tijdlijn).

Vervangen is een correctie die op geen enkele wijze iets verandert in de tijdlijn van een registratieobject. De dataleverancier dient een vervangverzoek in wanneer er eerder een brondocument is aangeleverd met daarin de goede datum van de gebeurtenis, maar met fouten in een of meer van de andere gegevens. Alle gebeurtenissen zijn in de juiste volgorde en met de juiste datum geregistreerd. Bij het verwerken van een vervangverzoek wordt er formele geschiedenis opgebouwd. Zie voor nadere toelichting de inleiding in de gegevenscatalogus.

Onderstaande figuur geeft weer dat de (waarden van) gegevens op het punt T2 op de tijdlijn worden vervangen.


4.4.3. InsertRequest

Met dit verzoek kan een bronhouder en/of dataleverancier de materiële geschiedenis corrigeren door het invoegen van een gebeurtenis op de tijdlijn. Het kan daarbij gaan om het invoegen van nieuwe gegevens op een bepaalde datum, of om het invoegen van nieuwe waarden voor bestaande gegevens op een bepaalde datum. In beide gevallen ligt de bepaalde datum vóór de datum van de meest recente, geregistreerde gebeurtenis. 

Invoegen is een correctieverzoek dat ingrijpt in de materiële geschiedenis van een registratieobject. Het gaat om de eenvoudigste variant, namelijk de situatie waarin de dataleverancier vergeten was een gebeurtenis te registreren terwijl er ondertussen een andere gebeurtenis is geregistreerd.

De tussen te voegen (waarden van) gegevens worden aangeboden met één van de brondocumenten, zoals gedefinieerd in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

Het is niet mogelijk de waarde van een individueel gegeven tussen te voegen. Immers, de eenheid van aanleveren is een brondocument.

De tussen te voegen (waarden van) gegevens zijn geldig vanaf de datum gebeurtenis opgenomen in het brondocument tot en met de datum van de chronologisch eerstvolgende gebeurtenis, waarin hetzelfde feature (object) met dezelfde identificerende gegevens voorkomt. De (waarden van) gegevens van het feature (object) met dezelfde identificerende gegevens, dat voorkomt in een chronologisch voorafgaande gebeurtenis, verliezen hun geldigheid vanaf de datum gebeurtenis opgenomen in het brondocument.

Onderstaande figuur geeft weer dat nieuwe (waarden voor) gegevens worden ingevoegd op het punt T3 van de tijdlijn tussen de punten T2 en Tn.


4.4.4. MoveRequest

Met dit verzoek kunnen gegevens worden verplaatst op de tijdlijn.

Verplaatsen is een correctie die ingrijpt in de materiële geschiedenis van een registratieobject. Het gaat om de situatie waarin de dataleverancier de juiste gegevens heeft aangeleverd maar met de verkeerde datum voor de gebeurtenis. Om de fout te herstellen, levert de dataleverancier het brondocument nogmaals aan maar nu met de juiste datum erin en met het verzoek de gegevens te verplaatsen. Om aan te geven over welke gebeurtenis het precies gaat geeft hij de onjuiste datum mee in het attribuut dateToBeCorrected (te corrigeren datum) van de transactiegegevens van het moveRequest.

De te verplaatsen gegevens, inclusief de gewenste nieuwe datum van de gebeurtenis, worden aangeboden met één van de brondocumenten, zoals gedefinieerd in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

Het is niet mogelijk de begingeldigheid van een individueel gegeven te verplaatsen in de tijd. Immers, de eenheid van aanleveren is een brondocument.

Onderstaande figuur geeft weer dat de begingeldigheid van de (waarden van) gegevens op het punt T2 op de tijdlijn wordt verschoven naar T2'. Merk op dat de eindgeldigheid van de (waarden van) gegevens, die op T2 gewijzigd werden, nu een eindgeldigheid T2' hebben. De gecorrigeerde datum T2' mag niet liggen voor T0 (de datum waarmee de registratie wordt gestart). De gecorrigeerde datum T2' mag niet liggen na Te (de datum waarmee de registratie wordt beëindigd).


4.4.5. DeleteRequest

Met dit verzoek kan een bronhouder en/of dataleverancier gegevens verwijderen uit de tijdlijn, omdat de dataleverancier een gebeurtenis heeft geregistreerd die nooit heeft plaatsgevonden (voor dit registratieobject).

Verwijderen is een correctie die ingrijpt in de materiële geschiedenis van een registratieobject. Het gaat om de situatie waarin de dataleverancier ten onrechte een brondocument heeft aangeleverd. Om de fout te herstellen, levert de dataleverancier het eerder aangeleverde brondocument nogmaals aan maar nu met het verzoek de gegevens die erin staan uit de registratie te verwijderen.

Met een deleteRequest (verwijderverzoek) kan de dataleverancier de materiële geschiedenis corrigeren door een gebeurtenis te verwijderen van de tijdlijn (verwijderen van gegevens op een bepaalde datum). De te verwijderen gegevens worden aangeboden met één van de brondocumenten, zoals gedefinieerd in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie. 

Het is niet mogelijk de waarde van een individueel gegeven te verwijderen. Immers, de eenheid van aanleveren is een brondocument.

Onderstaande figuur geeft weer dat de (waarden voor) gegevens op het punt T3 op de tijdlijn worden verwijderd. Merk op dat dit complexe gevolgen heeft voor de begingeldigheid en de eindgeldigheid van de (waarden van) gegevens (hoogstwaarschijnlijk T1 en Tn, maar misschien T0 .. Te).


5. Definities van requests en hun transactiegegevens

De LV-BRO kent 6 request-types (verzoeken). Zie onderstaande tabel. 

Naam in XML-bestand

Nederlandse naam

Doel

registrationRequestregistratieverzoek

Registreren van nieuwe gegevens in de LV-BRO. Dit kan zijn het in één keer aanbieden van alle gegevens bij een object zonder levensloop. Of het starten, aanvullen of beëindigen van de registratie bij een object met levensloop.

correctionRequestcorrectieverzoekVervangen van een eerder aangeleverd brondocument bij een registratieobject zonder materiële geschiedenis.
replaceRequestvervangverzoekVervangen van een eerder aangeleverd brondocument op een bepaald punt op de tijdlijn bij een registratieobject met materiële geschiedenis.
insertRequestinvoegverzoekInvoegen van een brondocument op de tijdlijn bij een registratieobject met materiële geschiedenis.
moveRequestverplaatsverzoekverplaatsen van een brondocument op de tijdlijn (wijzigen van de datum van een gebeurtenis) bij een registratieobject met materiële geschiedenis.
deleteRequestverwijderverzoekVerwijderen van een brondocument uit de tijdlijn bij een registratieobject met materiële geschiedenis.


Ieder van deze requests (verzoeken) bevat een aantal transactiegegevens en een brondocument. Welke transactiegegevens opgenomen mogen/moeten worden in welk type request, is geschetst in het vorige hoofdstuk. De volgende paragrafen van dit hoofdstuk bevatten de definities van de transactiegegevens. De brondocumenten zijn gedefinieerd in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

5.1. requestReference

Naam in XML-bestandrequestReference
Nederlandse naamverzoekkenmerk
DefinitieEen voor de dataleverancier unieke aanduiding van het  innameverzoek.
Juridische statusNiet-authentiek
Kardinaliteit1
Domein
  TypeCharacterString
  Maximale lengte200
Materiële geschiedenisNee


5.2. deliveryAccountableParty 

Naam in XML-bestanddeliveryAccountableParty
Nederlandse naambronhouder
DefinitieHet KvK-nummer van de maatschappelijke activiteit van de publiekrechtelijke rechtspersoon die bronhouder is van de gegevens in de basisregistratie ondergrond.
Juridische statusAuthentiek
Kardinaliteit0..1
Domein
  NaamChamberOfCommerceNumber
  TypeInteger
  OpbouwNNNNNNNN
Regels

Dit transactiegegeven moet aanwezig zijn als de dataleverancier niet de bronhouder is.

Dit transactiegegeven mag afwezig zijn als de dataleverancier tevens bronhouder is en zelf het verzoek indient.

Materiële geschiedenisNee
ToelichtingHet transactiegegeven wordt door de dataleverancier bij het aanbieden van het BRO-verzoek meegegeven in het geval de dataleverancier niet de bronhouder is.


5.3. broId

Naam in XML-bestandbroId
Nederlandse naamBRO-ID
Definitie

De unieke identificatie van een registratieobject in de LV-BRO.

Juridische statusAuthentiek
Kardinaliteit0..1
Domein
  NaamRegistratieobjectcode
  TypeCharacterString
  OpbouwAAANNNNNNNNNNNN
Regels

Dit transactiegegeven mag niet aanwezig zijn bij het starten van de registratie.

Dit transactiegegeven moet aanwezig zijn bij het aanvullen of beëindigen van de registratie.

In de LV-BRO moet een registratieobject met deze broId aanwezig zijn, als dit attribuut aanwezig is.

Materiële geschiedenisNee
Toelichting

De basisregistratie ondergrond kent bij (het starten van) de registratie automatisch een waarde toe aan het registratieobject.


5.4. qualityRegime 

Naam in XML-bestandqualityRegime
Nederlandse naamkwaliteitsregime
DefinitieDe aanduiding van het kwaliteitsregime waaraan de gegevens in het brondocument voldoen.
Juridische statusAuthentiek
Kardinaliteit1
Domein
  NaamQualityRegime
  TypeWaardelijst niet uitbreidbaar
Regels

Toegestane waarden zijn IMBRO en IMBRO/A.

De waarde IMBRO/A is bij het aanvullen of beëindigen van een registratie alleen toegestaan als de registratie is gestart met een kwaliteitsregime IMBRO/A.

Materiële geschiedenisNee
ToelichtingDe gegevenscatalogus geeft aan wat bij een waarde voor het kwaliteitsregime de gevolgen zijn voor de kardinaliteit, het domein en de bedrijfsregels van de gegevensinhoud van een brondocument.


5.5. underPrivilege

Naam in XML-bestandunderPrivilege
Nederlandse naamonder voorrecht
Definitie

De aanduiding die aangeeft dat de dataleverancier het recht heeft putten met voorgeschiedenis aan te leveren. Tijdelijk voor iedereen van toepassing.

Juridische statusNiet-authentiek
Kardinaliteit0..1
Domein
  NaamIndicatieJaNee
  TypeWaardelijst niet uitbreidbaar
Regels

Alleen de waarde 'ja' is toegestaan.

Dit transactiegegeven mag aanwezig zijn bij het aanbieden van een GMW (Grondwatermonitoringput) brondocument.

Dit transactiegegeven mag niet aanwezig zijn bij alle andere registratieobjecttypes.

Materiële geschiedenisNee
Toelichting

Bij het aanbieden van historische (archief) gegevens van een object met levensloop kan het voorkomen dat niet alle datums van de gebeurtenissen exact bekend zijn. Onder dit voorrecht mag een brondocument van een put met voorgeschiedenis een gebeurtenisdatum bevatten met een waarde uit het domein PartialDate (OnvolledigeDatum). Om de brondocumenten toch aan te kunnen leveren, moet hiervoor vanaf 3 juni 2019 dit transactiegegeven altijd worden toegevoegd, zowel bij IMBRO als IMBRO/A als kwaliteitsregime.

XML coderegel: <brocom:underPrivilege>ja</brocom:underPrivilege>


5.6. correctionReason

Naam in XML-bestandcorrectionReason
Nederlandse naamcorrectiereden
DefinitieAanduiding voor de reden waarom het registratieobject wordt gecorrigeerd/vervangen/ingevoegd/verplaatst/verwijderd.
Juridische statusNiet-authentiek
Kardinaliteit0..1
Domein
  NaamCorrectionReason
  TypeWaardelijst uitbreidbaar
Regels

Tenzij anders vastgelegd in de Berichtencatalogus innamewebservice van het betreffende registratieobject (zie de paragraaf Samenhang met andere documentatie voor nadere informatie) is de lijst met toegestane waarden, hun betekenis en de generieke, aanvullende regels van toepassing zoals beschreven op de pagina CorrectionReason.

Materiële geschiedenisNee


5.7. dateToBeCorrected

Naam in XML-bestanddateToBeCorrected
Nederlandse naamte corrigeren datum
DefinitieDe gebeurtenisdatum die moet worden verbeterd.
Juridische statusAuthentiek
Kardinaliteit0..1
Domein
  NaamDate
  WaardebereikDe waarde mag niet in de toekomst liggen.
Domein IMBRO/APartialDate
Regels

Dit transactiegegeven moet aanwezig zijn in een moveRequest (verplaatsverzoek).

Dit transactiegegeven mag niet aanwezig zijn bij alle andere requesttypes.

Regels IMBRO/ADit transactiegegeven mag een PartialDate (Onvolledige datum) bevatten wanneer het transactiegegeven qualityRegime (kwaliteitsregime) de waarde IMBRO/A heeft.
Materiële geschiedenisNee


6. Scenario's

Dit hoofdstuk bevat enkele scenario's voor het aanleveren van registratieverzoeken en correctieverzoeken.

6.1. Aanleveren deelonderzoeken bij Bodem- en grondonderzoek

De registratieobjecten in het domein Bodem- en grondonderzoek, met uitzondering van Geotechnisch sondeeronderzoek (CPT), hebben de kenmerkende eigenschappen dat zij bestaan uit diverse deelonderzoeken, die ook nog eens in fasen zijn opgeleverd.

Als gevolg van de eerste eigenschap is het mogelijk de resultaten van een bodem- of grondonderzoek per deelonderzoek aan te leveren. Deze registratieobjecten kennen dus een levensloop (zie hoofdstuk Algemene concepten). 

De tweede eigenschap heeft geleid tot verschillende versies van de gegevenscatalogi, berichtencatalogi en XSD-bestanden, die door verschillende versies van de betreffende innamewebservice worden ondersteund.

Dit heeft geleid tot een aantal brondocumenten:

BrondocumentDoel
BHR_PHet brondocument dat het bodemkundig booronderzoek in zijn volledigheid beschrijft. De registratie is met dit brondocument voltooid.
BHR_P_BSDHet brondocument dat van een bodemkundig booronderzoek, dat zowel een bodemkundige boormonsterbeschrijving als een boormonsteronderzoek beslaat, alleen de boormonsterbeschrijving bevat. De registratie is met dit brondocument gestart.
BHR_GT_CompleteReport_V1Het brondocument wordt aangeboden wanneer de rapportage van het geotechnisch booronderzoek in een keer volledig wordt gerapporteerd. De registratie is met dit brondocument direct voltooid.
BHR_GT_StartReport_V1Het brondocument wordt aangeboden wanneer de rapportage van het geotechnisch booronderzoek in delen wordt gerapporteerd. De registratie is met dit brondocument gestart.
BHR_GT_EndReport_V1Het brondocument wordt aangeboden wanneer het geotechnisch booronderzoek wordt aangevuld met de laatste rapportage en daarmee volledig is gerapporteerd. De registratie is met dit brondocument voltooid.
SFR_CompleteReport_V1Het brondocument wordt aangeboden wanneer het bodemkundig wandonderzoek uit 1 deelonderzoek bestaat en daarmee in een keer volledig wordt gerapporteerd. De registratie is met dit brondocument voltooid.
SFR_StartReport_V1Het brondocument wordt aangeboden wanneer het bodemkundig wandonderzoek uit meerdere deelonderzoeken bestaat en het eerste deelonderzoek wordt gerapporteerd. De registratie is met dit brondocument gestart.
SFR_EndReport_V1Het brondocument wordt aangeboden wanneer het bodemkundig wandonderzoek wordt aangevuld met de laatste rapportage en daarmee volledig is gerapporteerd. De registratie is met dit brondocument voltooid.


Merk op dat in de naam van de brondocumenten een versienummer is opgenomen (uitgezond bij BHR-P), die overigens altijd een waarde _V1 heeft.

Merk op dat ieder deelonderzoek altijd in 1 keer compleet moet worden aangeleverd. Dus bijvoorbeeld bij het aanleveren van de boormonsteranalyse moet men alle resultaten van bepalingen op diverse dieptes als 1 geheel aanleveren.

De vragen die hier beantwoord worden zijn: in welke volgorde, met welke brondocumenten en met welke BRO-verzoeken moeten de deelonderzoeken aangeleverd worden?

6.1.1. Alle deelonderzoeken in 1 keer aanleveren

Stel dat de gegevens van de deelonderzoeken tegelijkertijd beschikbaar komen, of in ieder geval binnen 20 dagen, de wettelijke termijn waarbinnen beschikbaar gekomen gegevens aangeleverd moeten worden bij de LV-BRO. Dan kunnen deze het beste in één keer aangeleverd worden:

  • Bij BHR-P in een BHR_P brondocument, verzonden in een initieel registrationRequest.
  • Bij BHR-GT in een BHR_GT_CompleteReport_V1 brondocument, verzonden in een initieel registrationRequest.
  • Bij SFR in een SFR_CompleteReport_V1 brondocument, verzonden in een initieel registrationRequest.

Zie paragraaf Registreren van gegevens voor een beschrijving van het registrationRequest.

6.1.2. Tweede deelonderzoek aanleveren door aanvullen

Stel dat de gegevens van de deelonderzoeken enige tijd na elkaar beschikbaar komen, dan moeten deze in chronologische volgorde worden aangeboden. Stel dat eerst de beschrijving en daarna de analyse beschikbaar komt, dan kunnen deze als volgt aangeleverd worden:

  • Bij BHR-P:
    • eerst de beschrijving in een BHR_P_BSD brondocument, verzonden in een initieel registrationRequest.
    • voor het daarna aanleveren van de analyse is nog geen brondocument gedefinieerd. Neem in voorkomende gevallen contact op het de BRO (Self)Servicedesk (zie paragraaf Contactinformatie).
  • Bij BHR-GT:
    • eerst de beschrijving in een BHR_GT_StartReport_V1 brondocument, verzonden in een initieel registrationRequest.
    • daarna de analyse in een BHR_GT_EndReport_V1, verzonden in een aanvulling of beëindiging registrationRequest
  • Bij SFR:
    • eerst de beschrijving in een SFR_StartReport_V1 brondocument, verzonden in een initieel registrationRequest.
    • daarna de analyse in een SFR_EndReport_V1, verzonden in een aanvulling of beëindiging registrationRequest.

Zie paragraaf Registreren van gegevens voor een beschrijving van het registrationRequest.

Merk op dat alle deelonderzoeken van 1 bodem- of grondonderzoek uiteraard bij elkaar horen en dus vallen onder 1 BRO-ID. Levert u de gegevens per deelonderzoek aan, dan krijgt u bij het initiële registrationRequest, met het eerste deelonderzoek, het BRO-ID retour. Dit BRO-ID moet u dus gebruiken bij de aanvullende registrationRequests met de andere deelonderzoeken.

6.1.3. Tweede deelonderzoek aanleveren door corrigeren

Stel dat de gegevens van de deelonderzoeken enige tijd na elkaar beschikbaar komen, dan moeten deze in chronologische volgorde worden aangeboden. Stel dat eerst de beschrijving beschikbaar komt en dat deze is aangeleverd met een 'complete' report. Stel dat enige tijd later de analyse beschikbaar komt. Dan kan de oorspronkelijke registratie als volgt worden gecorrigeerd:

  • Bij BHR-P:
    • eerst de beschrijving in een BHR_P brondocument, verzonden in een initieel registrationRequest.
    • daarna het oorspronkelijke BHR_P brondocument met de beschrijving, aangevuld met de analyse, verzonden in een correctionRequest
  • Bij BHR-GT:
    • eerst de beschrijving in een BHR_GT_CompleteReport_V1 brondocument, verzonden in een initieel registrationRequest.
    • daarna het oorspronkelijke BHR_GT_CompleteReport_V1 brondocument met de beschrijving, aangevuld met de analyse, verzonden in een correctionRequest
  • Bij SFR:
    • eerst de beschrijving in een SFR_CompleteReport_V1 brondocument, verzonden in een initieel registrationRequest.
    • daarna het oorspronkelijke SFR_CompleteReport_V1 brondocument met de beschrijving, aangevuld met de analyse, verzonden in een correctionRequest.

Zie paragraaf Registreren van gegevens voor een beschrijving van het registrationRequest en paragraaf Corrigeren van gegevens bij een object zonder materiële geschiedenis voor een beschrijving van het correctionRequest.

Merk op dat alle deelonderzoeken van 1 bodem- of grondonderzoek uiteraard bij elkaar horen en dus vallen onder 1 BRO-ID. Levert u de gegevens per deelonderzoek aan, dan krijgt u bij het initiële registrationRequest, met het eerste deelonderzoek, het BRO-ID retour. Dit BRO-ID moet u dus gebruiken bij het correctionRequest om de geregistreerde gegevens met het ene deelonderzoek te vervangen door de gegevens van beide deeelonderzoeken.

7. XML Code snippets

Dit hoofdstuk bevat enkele specifieke, kleine stukjes code uit de XML-bestanden van een BRO-verzoek.

Integrale voorbeeldberichten zijn te vinden via de links op de landingspagina van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

7.1. De kop van een request

De kop van elk type request (BRO-verzoek) heeft dezelfde structuur.

De eerste regel bevat de XML-proloog. Merk op dat de tekens volgens UTF-8 moeten worden gecodeerd. Dit is met name van belang voor speciale tekens, zoals à, á, ï.

Regel 2 bevat de opening tag van het request (BRO-verzoek). Dat moet dus zijn registrationRequest (registratieverzoek), correctionRequest (correctieverzoek), replaceRequest (vervangverzoek), insertRequest (invoegverzoek), moveRequest (verplaatsverzoek) of deleteRequest (verwijderverzoek). Zie de hoofdstukken BRO-verzoek en Scenario's voor nadere informatie welk type request u wanneer kunt/moet gebruiken.

Regel 3 t/m 8 bevatten prefixes voor de namespaces van de gebruikte XML-schemadefinities (XSD's). Welke namespaces precies nodig zijn hangt af van het registratieobject, het BRO-verzoek en de inhoud van het brondocument. Het aantal regels met namespaces kan dus variëren.

Regel 9 en 10 maken het mogelijk het BRO-verzoek te valideren tegen de XSD-bestanden van de innamewebservice. Deze twee XML-attributen mogen worden weggelaten.

Regel 12 bevat een disclaimer. Deze tekst is opgenomen als commentaar (begint met <!-- en eindigt met -->) en mag worden weggelaten. Commentaar mag meerdere regels beslaan. Commentaar binnen commentaar is niet toegestaan. Binnen een commentaar mogen geen 2 of meer mintekens (--) naast elkaar voorkomen.

Na de disclaimer volgen twee tot zeven transactiegegevens en het brondocument: requestReference (verzoekkenmerk), deliveryAccountableParty (bronhouder), broId (BRO-ID), qualityRegime (kwaliteitsregime), underPrivilege (onder voorrecht), correctionReason (correctiereden), sourceDocument (brondocument) en dateToBeCorrected (te corrigeren datum). Zie paragraaf Brondocument voor een beschrijving van dit stukje XML-code. Zie hoofdstuk Requests voor een gedetailleerde specificatie van de transactiegegevens, inclusief uitleg wanneer een transactiegegeven mag of moet voorkomen. Merk op dat de transactiegegevens correctionReason (correctiereden) en dateToBeCorrected (te corrigeren datum) en het sourceDocument (brondocument) gedefinieerd zijn binnen de namespace van de betreffende innamewebservice (geen namespace prefix hebben) en dat de andere transactiegegevens gedefinieerd zijn binnen de namespace van brocommon.xsd (met de namespace prefix brocom).

Het BRO-verzoek wordt afgesloten met de closing tag van het request (BRO-verzoek).

<?xml version="1.0" encoding="UTF-8"?>
<moveRequest
        xmlns="http://www.broservices.nl/xsd/isbhr-gt/2.1"
        xmlns:bhrgtcom="http://www.broservices.nl/xsd/bhrgtcommon/2.1"
        xmlns:brocom="http://www.broservices.nl/xsd/brocommon/3.0"
        xmlns:swe="http://www.opengis.net/swe/2.0"
        xmlns:gml="http://www.opengis.net/gml/3.2"
        xmlns:xlink="http://www.w3.org/1999/xlink"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.broservices.nl/xsd/isbhr-gt/2.1 https://schema.broservices.nl/xsd/isbhr-gt/2.1/isbhr-gt-messages.xsd"
    >
    <!-- Disclaimer: dit voorbeeldbericht valideert tegen de validatieservice van de acceptatie omgeving van het bronhouderportaal, maar de gegevens zijn fictief en waarschijnlijk niet correct.-->
    <brocom:requestReference>verzoek_2</brocom:requestReference>
    <!--Optional:-->
    <brocom:deliveryAccountableParty>27376655</brocom:deliveryAccountableParty>
    <!--Optional: alleen toegestaan bij een registrationRequest voor het aanvullen of beëindigen van de registratie of een correction/replace/insert/move/delete request.-->
    <brocom:broId>BHR000000342106</brocom:broId>
    <brocom:qualityRegime>IMBRO</brocom:qualityRegime>
    <!--Optional: alleen toegestaan bij GMW
    <brocom:underPrivilege>ja</brocom:underPrivilege>
    <!--Optional: alleen toegestaan bij een correction/replace/insert/move/delete request.-->
    <correctionReason codeSpace="urn:bro:bhrgt:CorrectionReason">eigenCorrectie</correctionReason>
    <sourceDocument>
        ...
    </sourceDocument>
    <!--Optional: alleen toegestaan bij een moveRequest.
    <dateToBeCorrected>
        <brocom:date>2015-02-08</ns1:date>
    </dateToBeCorrected>
    -->
</moveRequest>
CODE


7.2. Brondocument

Ieder BRO-verzoek bevat een brondocument. Een brondocument is de eenheid van aanleveren. Tenzij een brondocument slechts één attribuut bevat is het niet mogelijk individuele attributen aan te leveren of te corrigeren.

Voor de meeste registratieobjecten kent de betreffende innamewebservice meerdere types brondocumenten. Deze worden gedefinieerd in de betreffende berichtencatalogus; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

Ieder brondocument heeft in het UML ontwerp het stereotype FeatureTypeConform de GML XML encoding rules wordt daarom bij een brondocument het property type pattern toegepast. Zie ook de paragraaf Property type pattern.

Onderstaand stukje XML van een voorbeeldbericht laat zien hoe dat uitpakt. Na de opening tag sourceDocument (brondocument) volgt een XML-element met als tag de naam van het type brondocument, bijvoorbeeld GMN_StartRegistration. Dit XML-element geeft aan welk type brondocument in dit BRO-verzoek is opgenomen. Om deze constructie mogelijk te maken zijn de brondocumenten als root element gedefinieerd in het betreffende XSD-bestand. Zo is het XML-element GMN_StartRegistration als root element gedefinieerd in het XSD-bestand isgmn-messages.xsd van de GMN innamewebservice.

De daadwerkelijke inhoud van het brondocument volgt na de opening tag van het type brondocument; hier weergegeven door 3 punten.

...
 <sourceDocument>
     <GMN_StartRegistration gml:id="id_0001">
         ...
     </GMN_StartRegistration>
 </sourceDocument>
 ...
CODE


7.3. Codelijst

Zie de pagina Codelist (Codelijst)

7.4. CorrectionReason

Zie de pagina CorrectionReason (Correctiereden)

7.5. Datum

Diverse gegevenscatalogi definieren een aantal gegevens met als domein Datum. In een XSD-bestand heeft het betreffende XML-element het type xs:Date (Datum).

De datum wordt gecodeeerd volgens de ISO-8601 standaard: yyyy-mm-dd. Bijvoorbeeld:

<bhrgtcom:analysisReportDate>2018-10-23</bhrgtcom:analysisReportDate>
CODE


7.6. DatumTijd

Diverse gegevenscatalogi definieren een aantal gegevens met als domein DatumTijd. In een XSD-bestand heeft het betreffende XML-element het type xs:DateTime (DatumTijd).

De datum en tijd worden gecodeeerd volgens de ISO-8601 standaard: yyyy-mm-ddThh:mm:ss+hh:mm.

Daarbij is de tijdzone (+hh:mm) verplicht. De tijdzone ten opzichte van UTC (aka GMT) zijn de uren en minuten na het plus teken. In theorie kan dit ook een min teken zijn (tijdzones ten westen van Greenwich), maar voor Nederland is de tijdzone + 1 uur (wintertijd) of + 2 uur (zomertijd).

Hieronder twee voorbeelden:

  • lokale tijd 08:14:38 tijdens wintertijd, terwijl het 'in Londen' 07:14:38 is (want de tijdzone van de lokale tijd is +1 uur ten opzichte van UTC aka GMT).
  • lokale tijd 13:52:44 tijdens zomertijd, terwijl het 'in Londen' 11:52:44 is (want de tijdzone van de lokale tijd is +2 uur ten opzichte van UTC aka GMT).


<wml2:time>2018-01-07T08:14:38+01:00</wml2:time>
<wml2:time>2018-07-18T13:52:44+02:00</wml2:time>
CODE


Zie ook de informatie op de pagina over het afhandelen van tijdstippen.

7.7. Dataleverancier

De diverse gegevenscatalogi definiëren het attribuut dataleverancier (deliveryResponsibleParty). Dit attribuut wordt niet aangeleverd in een brondocument en ook niet als transactiegegeven in het omvattende request (BRO-verzoek).

Als dataleverancier hoeft u voor dit attribuut geen specifieke actie te ondernemen. Het bronhouderportaal zorgt er automatisch voor dat de waarde van dit attribuut wordt gemeld bij de LV-BRO.

Nadere informatie:
Zodra iemand een levering aanmaakt en de bijbehorende XML-bestanden uploadt, weet het bronhouderportaal op basis van de projectautorisatie of de projectmachtiging namens welke organisate deze persoon als dataleveracier optreedt. Als in een vervolgstap de levering wordt doorgeleverd, plaats de software van het bronhouderporaal het kvk-nummer van de dataleverancier in de SOAP header van het bericht dat naar de LV-BRO wordt gestuurd. Om dit mogelijk te maken bevat het WSDL-bestand van de innamewebservice van het betreffende registratieobject een message part deliveryResponsiblePartyHeader (dataleverancier), wat bij de SOAP binding is opgenomen in de header van de input messages van alle operations. Zie bijvoorbeeld https://schema.broservices.nl/isgld-v1.0.wsdl 

7.8. gml:id

Zie de pagina gml:id

7.9. Locatie

Diverse gegevenscatalogi definieren een locatie of geometrie, zoals bij de DeliveredLocation (Aangeleverde locatie) of de StandardizedLocation (Gestandaardiseerde locatie).

Een puntgeometrie wordt daar gedefinieerd door de volgende twee attributen:

  • Coördinaten: de coördinaten van de puntgeometrie.
  • Referentiestelsel: het referentiestelsel van de aangeleverde coördinaten.

Conform NEN3610 wordt op technisch niveau een puntgeometrie omgezet in het UML datatype gml:Point. Conform de GML XML encoding rules wordt bij een gml:Point het property type pattern toegepast. Zie ook de paragraaf Property type pattern. Daardoor krijgt in een XSD-bestand het betreffende XML-element een type gml:PointPropertyTypeDit leidt in een XML-bestand tot:

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

Het bereik en de betekenis van de coördinaten is afhankelijk van het gebruikte referentiestelsel. Tenzij anders aangegeven in de betreffende gegevenscatalogus, kunnen de referentiestelsels in de onderstaande tabel worden gebruikt. De tabel geeft ook de betekenis, volgorde en eenheid van de coördinaten en het toepassingsgebied van het referentiestelsel.

Referentiestelsel

srsName

Betekenis

Eenheid

Toepassingsgebied

RD (Rijksdriehoek)urn:ogc:def:crs:EPSG:28992X, YMeterLand
WGS94urn:ogc:def:crs:EPSG:4326Latitude, Longitude (φ,λ)Graden, decimaalZee
ETRS89urn:ogc:def:crs:EPSG:4258Latitude, Longitude (φ,λ)Graden, decimaalLand en zee


Onderstaand voorbeeld bevat de XML-code voor dezelfde locatie in RD en in ETRS89. Merk op dat de coördinaten worden gescheiden door een spatie en dat het decimale scheidingsteken een punt is.

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


7.10. Meetreeks

Zie de pagina Meetreeks

7.11. Meetwaarde

Diverse gegevenscatalogi definieren een aantal gegevens met als domein een meetwaarde. Dit domein bestaat uit een getalswaarde en een eenheid. Bijvoorbeeld 123,321 meter.

In een XSD-bestand heeft het betreffende XML-element het type gml:Measure. Conform de GML XML encoding rules wordt de eenheid opgeslagen in het XML-attribuut uom (unit of measure; eenheid) en wordt de getalswaarde opgenomen als de waarde van het XML-element.

Als een gegeven van het type meetwaarde geen waarde heeft, dan wordt er een XML-attribuut xsi:Nil="true" opgenomen en heeft het XML-element geen waarde. Het XML attribuut uom (eenheid) wordt wel opgenomen.

Zie onderstaande voorbeelden voor een XML-element met de naam offset (verschuiving) met en zonder een waarde.

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


Merk op dat in de gegevenscatalogus (in de meeste gevallen) naast de afkorting ook tussen haakjes de voluitgeschreven naam van de eenheid is opgenomen, bijvoorbeeld: Eenheid: m (meter) . Alleen de afkorting volgens de UCUM lijst moet worden opgenomen in het BRO-verzoek (zie https://ucum.org/ucum.html).

7.12. Organisatie

Diverse gegevenscatalogi definieren een aantal gegevens met als domein een Organisatie.

Het domein Organisatie biedt de keuze tussen een kamer van koophandel nummer of een Europees handelsnummer als identificatie van een organisatie. In de XSD-bestanden leidt deze keuze tot een xs:choice.

Conform de GML XML encoding rules wordt bij een xs:choice het property type pattern toegepast. Zie ook de paragraaf Property type pattern. Daardoor krijgt een XML-element, waarvan het type een Organization (Organisatie) is, een kind-element met als tag de gekozen variant. Daardoor weet de ontvangende partij wat de betekenis van de waarde is. In onderstaande voorbeelden is 09098104 een kamer van koophandel nummer en is DER2507_R2 een Europees handelsnummer.

Hieronder twee voorbeelden:

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


7.13. PartialDate

Diverse gegevenscatalogi definieren een aantal gegevens met als domein een Datum (zie ook de paragraaf Datumonder het kwaliteitsregime IMBRO en een OnvolledigeDatum onder IMBRO/A.

In de XSD-bestanden is de OnvolledigeDatum gerealiseerd door het complexType PartialDateType, wat een xs:choice is van 4 mogelijkheden met afnemende nauwkeurigheid:

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

Conform de GML XML encoding rules wordt bij een xs:choice het property type pattern toegepast. Zie ook de paragraaf Property type pattern. Daardoor krijgt een XML-element met een PartialDateType (OnvolledigeDatum) als type een kind-element met als tag de gekozen variant. Daardoor weet de ontvangende partij wat de betekenis van de waarde is.

Hieronder vier voorbeelden:

<bhrgtcom:descriptionReportDate>
    <brocom:date>2018-09-23</brocom:date>
</bhrgtcom:descriptionReportDate>
...
<bhrgtcom:descriptionReportDate>
    <brocom:yearMonth>2018-09</brocom:yearMonth>
</bhrgtcom:descriptionReportDate>
...
<bhrgtcom:descriptionReportDate>
    <brocom:year>2018</brocom:year>
</bhrgtcom:descriptionReportDate>
...
<bhrgtcom:descriptionReportDate>
    <brocom:voidReason>onbekend</brocom:voidReason>
</bhrgtcom:descriptionReportDate>
CODE


Bij een PartialDate (OnvolledigeDatum) geldt dat een minder volledige datum voorafgaat aan een meer volledige datum:

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

In het algemeen kan een datum met de waarde 'onbekend' niet worden vergeleken met een andere datum. Daarom wordt tijdens het valideren of verwerken van een BRO-verzoek een bedrijfsregel genegeerd, als er twee datums met elkaar worden vergeleken waarvan één (of beide) de waarde 'onbekend' heeft.

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

7.14. Property type pattern

In een gegevenscatalogus wordt een onderscheid gemaakt tussen objecttypes en gegevensgroeptypes. Bij de opstellen van de berichtdefinities worden deze stereotypes vertaald naar FeatureType en AttributeGroupType. Beide kunnen in software omgezet worden naar classes. Beide hebben als onderdelen attributes (attributen), attributeGroups (gegevensgroepen) of associations (relaties) naar andere Featuretypes (objecttypes). De verschillen zijn onder meer dat een Feature uniek identificeerbaar moet zijn en dat een AttributeGroup alleen bestaat bij de gratie van het Feature waarvan het, direct of indirect, een onderdeel is.

Onderstaande voorbeeld toont het objecttype Grondwatermonitoringnet. Deze entiteit heeft 4 attributen, 2 gegevensgroepen en 1 associatie relatie (naar het objecttype Meetpunt). Ter illustratie is de structuur van het gegevensgroeptype Registratiegeschiedenis opgenomen in de figuur.

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

  • Een complex type, wat de inhoud van het FeatureType (objecttype) definieert en direct of indirect een specialisatie is van gml:AbstractFeatureType.
  • Een root element, zodat objecten van het ComplexType geïnstantieerd kunnen worden.
  • Een property type ComplexType, wat in de XSD-bestanden gebruikt wordt als het type van een element dat fungeert als realisatie van de associatie relatie naar het FeatureType (objecttype).

Als gevolg van de eerste bullet krijgt in een XML-bericht ieder XML-element met zo'n complex type als datatype een XML-attribuut gml:id (zie ook de paragraaf gml:id).

De combinatie van het tweede bullet en het derde bullet heeft tot gevolg dat in een XML-bericht een associatie relatie naar een objecttype wordt omgezet in:

  • Een XML-element, met als tag de naam bij het eindpunt van de relatie.
  • Met daarin een kind-element met als tag de rol die het eindpunt van de relatie heeft of de naam van het objecttype van het eindpunt van de relatie.
  • Met daarin de onderdelen van het objecttype van het eindpunt van de relatie. 

Door deze constructie weet een ontvangend systeem eenduidig wat het objecttype van het eindpunt van de relatie is en weet het hoe de inhoud geparsed moet worden.

Onderstaand voorbeeld toont een stuk XML-bericht, dat past bij bovenstaande UML diagram. Merk op dat de registrationHistory (registratiegeschiedenis) als XML-element direct zijn onderdelen als kind-elementen heeft. Merk op dat measuringPoint (meetpunt) als XML-element eerst een MeasuringPoint (Meetpunt) als kind-element heeft, met gml:id als XML-attribuut voor de unieke identificatie, met daarbinnen de onderdelen van het MeasuringPoint (Meetpunt) als kleinkind-elementen.

          ...
          <gmn:name>Provinciaal meetnet grondwater Groningen; Delfzijl</gmn:name>
          <gmn:deliveryContext codeSpace="urn:bro:gmn:DeliveryContext">kaderrichtlijnWater</gmn:deliveryContext>
          <gmn:monitoringPurpose codeSpace="urn:bro:gmn:MonitoringPurpose">strategischBeheerKwaliteitRegionaal</gmn:monitoringPurpose>
          <gmn:groundwaterAspect codeSpace="urn:bro:gmn:GroundwaterAspect">kwantiteit</gmn:groundwaterAspect>
          <gmn:monitoringNetHistory>
            ...
          </gmn:monitoringNetHistory>
          <gmn:registrationHistory>
            <brocom:objectRegistrationTime>2021-03-07T13:11:57+01:00</brocom:objectRegistrationTime>
            <brocom:registrationStatus codeSpace="urn:bro:RegistrationStatus">voltooid</brocom:registrationStatus>
            <brocom:latestAdditionTime>2021-12-03T13:11:57+01:00</brocom:latestAdditionTime>
            <brocom:registrationCompletionTime>2021-12-30T15:42:08+01:00</brocom:registrationCompletionTime>
            <brocom:corrected>nee</brocom:corrected>
            <brocom:underReview>nee</brocom:underReview>
            <brocom:deregistered>nee</brocom:deregistered>
            <brocom:reregistered>nee</brocom:reregistered>
          </gmn:registrationHistory>
          <!-- 1 or more repetitions: -->
          <gmn:measuringPoint>
            <gmn:MeasuringPoint gml:id="SEQ_0002">
              <gmn:measuringPointCode>GMW07F000001</gmn:measuringPointCode>
              ...
            </gmn:MeasuringPoint>
          </gmn:measuringPoint>
          <gmn:measuringPoint>
            <gmn:MeasuringPoint gml:id="SEQ_0004">
              <gmn:measuringPointCode>GMW07F000002</gmn:measuringPointCode>
              ...
            </gmn:MeasuringPoint>
          </gmn:measuringPoint>
          ...
CODE


8. Enumeraties

Dit hoofdstuk bevat een overzicht van enumeraties (niet beheerde waardenlijsten) met hun toegestane waarden.

In de BRO wordt een onderscheid gemaakt tussen beheerde waardenlijsten en niet-beheerde waardenlijsten:

  • In de gegevenscatalogus en de XSD-bestanden noemen we een niet-beheerde waardenlijst een enumeratie. Bij een enumeratie staat de lijst met toegestane waarden vast en kan de lijst met toegestane waarden niet veranderd worden zonder aanpassingen in de gegevenscatalogus, de berichtdefinities (XSD-bestanden) en de software (voor het maken of verwerken van een bericht).
  • In de gegevenscatalogus en de XSD-bestanden noemen we een beheerde waardenlijst een codelijst. Het domein van een codelijst is een uitbreidbare opsomming van toegestane waarden. Bij een codelijst wordt de lijst met toegestane waarden gepubliceerd, waarbij iedere codelijst een unieke identificatie heeft (de codeSpace). De lijst met toegestane waarden kan worden aangepast zonder dat aanpassingen nodig zijn in de berichtdefinities (XSD-bestanden) of de software (voor het maken of verwerken van een bericht). Om juridische redenen vormt de lijst met toegestane waarden een onderdeel van de gegevenscatalogus, zodat aanpassingen in de lijst met toegestane waarden leidt tot een nieuwe versie van de gegevenscatalogus.

De onderstaande tabel geeft een overzicht van de enumeraties die van belang kunnen zijn bij het maken van een BRO-verzoek. De eerste kolom bevat de Engelstalige naam van de enumeratie, zoals deze voorkomt in de XSD-bestanden. De tweede kolom bevat de Nederlandstalige naam, zoals die voorkomt in de gegevenscatalogus. De derde kolom bevat de toegestane waarden, die gebruikt mogen worden in een BRO-verzoek.

Type

Naam

Waarde

Omschrijving

DataToBeDeliveredTe leveren gegevensactueelBij de uitgifte van gegevens van een object met materiële geschiedenis worden alleen de actuele gegevens uitgeleverd.


actueelHistorischBij de uitgifte van gegevens van een object met materiële geschiedenis worden naast de actuele ook de historische gegevens uitgeleverd.
IndicationYesNoIndicatieJaNeeja


nee
IndicationYesNoUnknownIndicatieJaNeeOnbekendja


nee


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


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


9. Doorkijkje naar de specifieke berichtencatalogi

Zoals het eerste hoofdstuk aangeeft, probeert deze handreiking in algemene zin een antwoord te geven op de volgende vragen:

  • Hoe kun je een BRO-verzoek als een XML-bestand opstellen?
  • Hoe ziet zo'n XML-bestand er uit?
  • Hoe moet je te werk gaan als de gegevens in één keer beschikbaar komen dan wel beetje bij beetje in de loop der tijd?
  • Hoe kunnen verandering van waarden in de loop der tijd gemeld kunnen worden?
  • Hoe kun je een fout in de geregistreerde gegevens corrigeren?

Paragraaf 1.4 bevat een tabel met links naar landingspagina's waar per registratieobjecttype specifieke informatie gevonden kan worden. De Berichtencatalogus innamewebservice van de betreffende registratieobjecttypes geven nadere informatie over de volgende onderwerpen:

  • Definitie van de brondocumenten, waarmee gegevens over het registratieobject aangeleverd of gecorrigeerd kunnen worden.
  • Scenario's waarin praktische reeksen van gebeurtenissen worden omgezet in aan te bieden brondocumenten en/of BRO-verzoeken.
  • Voorbeeldberichten en XML-code snippets die specifiek zijn voor het betreffende registratieobjecttype.
  • Indien relevant, een overzicht met enumeraties en hun toegestane waarden (niet-beheerde waardenlijsten).
  • Een overzicht met codelijsten (beheerde waardenlijsten).
  • Een vertaaltabel, waarmee de Engelstalige naam van een complextype of element, zoals gebruikt in de de XSD-bestanden, kan worden omgezet in de Nederlandse naam, zoals gebruikt in de gegevenscatalogus.

Daarmee geven deze drie documenten (Gegevenscatalogus, Handreiking aanleveren en Berichtencatalogus innamewebservice) u de noodzakelijke informatie om gegevens aan te leveren bij de BRO en indien nodig te corrigeren. Mochten er daarna nog vragen zijn, neem dan een kijke op de pagina Informatie voor softwareleveranciers of neem contacft op met de BRO servicedesk (zie paragraaf Contactinformatie).

De inhoud van dit document is met zorg opgesteld. Mocht u een fout aantreffen of een tekortkoming constateren, of anderszins feedback willen geven, neem dan contact op met de BRO servicedesk (zie paragraaf Contactinformatie).