Handreiking aanleveren BRO-gegevens

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 streven met deze handreiking naar het weergeven van generieke informatie uit de diverse berichtencatalogi. Mocht u een fout aantreffen of een tekortkoming constateren, of anderszins feedback willen geven, neem dan contact op met de BRO Servicedesk via een mail naar support@broservicedesk.nl.

Inleiding

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.

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.

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.

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.

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

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.

Versiehistorie

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.

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

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.

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

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.

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!

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.

Terugmelden van fouten

De gegevens in de LV-BRO moeten voldoen aan 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.

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.

Levensloop

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

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

Aanlevertermijn

Gegevens moeten worden aangeboden met een registratieverzoek. Zie hoofdstuk "Definities van requests en hun transactiegegevens". 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.

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 "Definities van requests en hun transactiegegevens". 

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. De identification (identificatie) van een entiteit mag na eerste aanlevering niet worden gewijzigd door middel van een correctieverzoek, omdat anders niet correct gerefereerd kan worden naar deze entiteit in vervolg gebeurtenissen.

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.

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 Geregistreerd. Totdat 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 Voltooid. Hierna kan het registratieobject niet meer worden aangevuld. De geregistreerde gegevens blijven na het beëindigen van de registratie opvraagbaar door afnemers.

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.

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 registratieverzoek. Zie hoofdstuk "Definities van requests en hun transactiegegevens".

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 "Definities van requests en hun transactiegegevens".

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.

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.
• De identification (identificatie) van een entiteit mag na eerste aanlevering niet worden gewijzigd door middel van een correctieverzoek, omdat anders niet correct gerefereerd kan worden naar deze entiteit in vervolg gebeurtenissen.
• 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 zijn.

BRO-verzoek

Dit hoofdstuk beschrijft de opbouw van een BRO-verzoek.

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 "Definities van requests en hun transactiegegevens" 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.

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  "Definities van requests en hun transactiegegevens" 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.

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:

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 "Definities van requests en hun transactiegegevens" 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.

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:

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 rol als er bij een registratieobject meerdere brondocumenten zijn aangeleverd en één daarvan wordt gecorrigeerd. Voorbeeld: bij een booronderzoek mag slechts één boormonsterbeschrijving en één boormonsteranalyse aanwezig zijn. Voorbeeld: 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 "Definities van requests en hun transactiegegevens" 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.

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.

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.

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

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

Definities van requests en hun transactiegegevens

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

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.

requestReference

deliveryAccountableParty 

broId

qualityRegime 

underPrivilege

correctionReason

dateToBeCorrected

Scenario's

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

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 b odem- 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:

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 a angeleverd worden?

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.

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.

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.

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.

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 "Definities van requests en hun transactiegegevens" 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>

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 FeatureType.  Conform 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>
 ...

Codelijst

Zie de pagina Codelist (Codelijst)

CorrectionReason

Zie de pagina CorrectionReason (Correctiereden)

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>

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>

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

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  

gml:id

Zie de pagina gml:id

Lijngeometrie

Diverse gegevenscatalogi definieren een geometrie in de vorm van een lijn, zoals bijvoorbeeld de geometrie van een boortraject als onderdeel van een boorgat van een EPC Mijnbouwconstructie.

De OGC standaard voor GML definieert een lijn als een 1-dimensionele geometrie in een 2-dimensioneel vlak of in een 3-dimensionele ruimte. Een lijn is continue en doorsnijdt zichzelf niet.

Een lijn bestaat uit een of meer lijnsegmenten waarbij de lijnsegmenten verschillende interpolatiemethoden kunnen gebruiken. Lijnsegmenten zijn aan elkaar verbonden waarbij het eindpunt van elk segment, behalve de laatste, verbonden is aan het beginpunt van het volgende.

In het GML profiel dat gebruikt wordt binnen de BRO kan een lijnsegment een lijnstuk of een cirkelsegment zijn. Daarbij is de interpolatie tussen de punten van een lijnstuk altijd 'linear' (rechte lijnstukken) en is de interpolatie tussen de drie punten van een cirkelsegment altijd 'circularArc3Points' (cirkelvormige boog die begint bij het eerste punt, door het tweede punt gaat en eindigt bij het derde punt).

De punten van de lijnsegmenten en/of cirkelsegmenten worden uitgedrukt in een referentiestelsel. Een punt in een 2-dimensioneel vlak heeft twee coöridnaten en een punt in een 3-dimensionele ruimte heeft drie coördinaten. De betekenis en h et bereik 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.

Conform NEN3610 wordt op technisch niveau een lijngeometrie in UML gemodelleerd als een GM_Curve. Conform de GML XML encoding rules wordt bij een gm_Curve het property type pattern toegepast, zodat een betreffend attribuut het type gml:CurvePropertyType krijgt. Zie ook de paragraaf Property type pattern. Daardoor krijgt in een XSD-bestand het betreffende XML-element een type gml:PointPropertyType.  Dit 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.

Als voorbeeld de onderstaande lijn, die bestaat uit 3 lijnstukken en 1 cirkelsegment.

Hieronder volgt de XML-code bevat voor deze geometrie in RD en in ETRS89. Merk op dat de coördinaten worden gescheiden door een spatie en dat het decimale scheidingsteken een punt is.

... 
<epccom:geometry>
	<gml:Curve gml:id="id_0006" srsDimension="3" srsName="EPSG:28992">
		<gml:segments>
			<gml:LineStringSegment interpolation="linear">
				<gml:posList>
					193050 320700 86.55 
					193050 320700 -14.73 
					193052 320705 -264.18 
					193049 320702 -516.51
				</gml:posList>
			</gml:LineStringSegment>
			<gml:ArcString interpolation="circularArc3Points" numArc="1">
				<gml:posList>
					193049 320702 -516.51 
					193051 320703 -674 
					193048 320701 -972
				</gml:posList>
			</gml:ArcString>
		</gml:segments>
	</gml:Curve>
</epccom:geometry>
...
<epccom:geometry>
	<gml:Curve gml:id="id_0006" srsDimension="3" srsName="EPSG:4258">
		<gml:segments>
			<gml:LineStringSegment interpolation="linear">
				<gml:posList>
                    50.8748397 5.9277708 129.55
                    50.8748397 5.9277708 29.73
                    50.8748844 5.9277996 -221.18
                    50.8748577 5.9277567 -473.51
				</gml:posList>
			</gml:LineStringSegment>
			<gml:ArcString interpolation="circularArc3Points" numArc="1">
				<gml:posList>
                    50.8748577 5.9277567 -473.51
                    50.8748665 5.9277852 -631
                    50.8748487 5.9277424 -929
				</gml:posList>
			</gml:ArcString>
		</gml:segments>
	</gml:Curve>
</epccom:geometry>
...

Meetreeks

Zie de pagina Meetreeks

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"/>
...

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

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

PartialDate

Diverse gegevenscatalogi definieren een aantal gegevens met als domein een  Datum  (zie ook de paragraaf Datum) onder 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>

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.

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

Puntgeometrie

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:PointPropertyType.  Dit 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.

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

Vlakgeometrie

TODO

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:PointPropertyType.  Dit 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.

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

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 e numeratie. Bij een e numeratie  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.

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