volledige teksten BRO wijzigingsverzoeken

volgnr.

meldingsnr.

volledige tekst wijzigingsverzoek

337

BM24 11 00223

We zouden graag geotechnische boringen dieper dan 150 meter aan willen leveren. Deze vraag is al eerder gesteld en ook voor besproken met jullie medewerkers, en is extra relevant met de toevoeging van drinkwaterbedrijven aan de BRO. Drinkwaterbedrijven zijn namelijk juist partijen die vaak diepere boringen uitvragen, en het is nu blokkerend waardoor deze onderzoeken niet in de BRO kunnen worden meegenomen.

Bij veel bijzondere bestanddelen wordt in de BRO catalogus als onderscheid tussen of iets veel of weinig bevat de tekst “voorkomend in een mate die niet van invloed is op de geotechnische eigenschappen van de grond” gebruikt (https://docs.geostandaarden.nl/bro/def-im-BHR-GT-20220901/#detail_class_Model_BijzonderBestanddeel ). Dit is niet consistent met de NEN8990 (zie e hieronder), waar als definitie voor weinig 0-25% en voor veel 25-50% gebruikt wordt. Zou dit gelijk getrokken kunnen worden?

336

BM24 11 00223

We zouden graag geotechnische boringen dieper dan 150 meter aan willen leveren. Deze vraag is al eerder gesteld en ook voor besproken met jullie medewerkers, en is extra relevant met de toevoeging van drinkwaterbedrijven aan de BRO. Drinkwaterbedrijven zijn namelijk juist partijen die vaak diepere boringen uitvragen, en het is nu blokkerend waardoor deze onderzoeken niet in de BRO kunnen worden meegenomen.

Bij veel bijzondere bestanddelen wordt in de BRO catalogus als onderscheid tussen of iets veel of weinig bevat de tekst “voorkomend in een mate die niet van invloed is op de geotechnische eigenschappen van de grond” gebruikt (https://docs.geostandaarden.nl/bro/def-im-BHR-GT-20220901/#detail_class_Model_BijzonderBestanddeel ). Dit is niet consistent met de NEN8990 (zie e hieronder), waar als definitie voor weinig 0-25% en voor veel 25-50% gebruikt wordt. Zou dit gelijk getrokken kunnen worden?

335

BM24 11 00410

Zouden jullie bijgaand document willen agenderen in het CAB.

De DBG Milieukwaliteit heeft op 22 november j.l. positief geadviseerd op dit voorstel. De DBG ziet de voorgestelde aanpak als een goede eerste stap met de aantekening dat het zinvol blijft te kijken of de verwerkingstermijn voor nieuwe parameters in de toekomst verder verkort kan worden. Het risico dat nieuwe stoffen niet kunnen worden aangeleverd wordt hiermee welleswaar aanzienlijk gereduceerd maar nog niet geheel voorkomen. Ik stel voor een eerste update eind 2024 te agenderen.

Memo geautomatiseerd bijhouden stoffenlijst v4.pdf

334

BM24 11 00235

In de GMW-catalogus mis ik bij het attribuut “Buismateriaal” (7.1.2) de mogelijkheid om pvcKoper te kiezen.

In het overlegje met Erik is toegelicht dat deze waarde momenteel ontbreekt in de GMW standaard, waardelijst van attribuut 'buismateriaal'. Dit zal als wijzigingsverzoek worden behandeld waarbij het proces generieke werkafspraakcodelijsten van toepassing is
Proces generieke werkafspraken BRO codelijsten

333

BM24 11 00252

ij deze een wijzigingsverzoek voor de opslag en uitgifte van aangeleverde locaties in de BRO.
In mijn optiek wordt dit op een behoorlijk complexe manier opgeslagen (in de LV_BRO DB), en zou het handiger zijn om dit via een standaard encoding op te slaan, zoals GeoJSON, GML, etc.

Momenteel wordt de aangeleverde locatie opgeslagen als een ‘bro_location’ entiteit in de BRO, die dan een relatie hebben met de verschillende typen aangeleverde locaties (met ieder weer een eigen tabel).

Ook is er voor eindgebruikers geen uitleg over deze BRO eigen manier van het opslaan van aangeleverde locaties. Ik betwijfel eerlijk gezegd of er ook maar een externe gebruiker is van de objectset GPKGs voor wie het duidelijk is hoe die op basis van de tabellen in de objectset GPKGs een aangeleverde locatie moet destilleren.

Neem bijvoorbeeld een EPC Mijnstelsel. Dat is een MultiPolygon. Als een gebruiker daar de aangeleverde locatie van wil achterhalen, moet hij een combinatie maken van de volgende tabellen;

mining_system
benodigde attributen;
mining_system_pk
bro_location
benodigde attributen;
bro_location_pk
mining_system_fk
crs
bro_multi_polygon;
benodigde attributen;
bro_multi_polygon_pk
bro_location_fk
bro_polygon;
benodigde attributen;
bro_polygon_pk
bro_multi_polygon_fk
bro_linear_ring
benodigde attributen;
bro_linear_ring_pk
bro_polygon_fk
bro_interior_fk
bro_interior
benodigde attributen;
bro_interior_pk
bro_polygon_fk
bro_point
benodigde attributen;
bro_point_pk
bro_linear_ring_fk
x_or_lon
y_or_lat

Zie evt ook bijgevoegd een plaatje van het ERD schema van bro_location (export vanuit DBeaver).
Daarnaast evt de structuur zoals die vanuit de meta entiteiten van de LV_BRO terugkomen;

Ik vind dit eigenlijk ondoenlijk vanuit een GIS gebruikers perspectief. Die wil de geometrie gewoon op een internationaal gestandaardiseerde manier terugzien, zoals bijvoorbeeld GML of GeoJSON.
In de uitgiftedocumenten (XML), komt bijvoorbeeld GML terug. Bijgaand dus een voorbeeld hoe een gestandaardiseerde locatie van het type GM_MultiSurface wordt uitgeleverd;

N.b. Bovenstaand op basis van het EPL_PO uitgiftedocument van EPL000000067352 (in de tst DB).

332

BM24 10 00741

Hebben jullie ook een API voor het verkrijgen van doorsnedes door de diverse ondergrondmodellen? Ik zou graag een lijn als WKT opsturen naar zo’n API en de doorsnede als data/afbeelding terug krijgen.

331

BM24 10 00215

Wij hebben voor een project in Almere 20 bodemkundige boringen (BHR-P) gezet.
Deze dienen aangeleverd te worden bij de BRO, maar op de website is geen informatie te vinden met betrekking tot hoe wij dat doen.

Wij hebben al een account bij het bronhouderportaal en ook een machtiging van onze opdrachtgever om gegevens aan te leveren.
De gegevens hebben wij in een excelbestand, een voorbeeld van twee van de boringen stuur ik mee.
In het bronhoudersportaal moeten deze aangeleverd worden als .xml bestand.
Wij hebben echter geen ervaring met het aanleveren van boringen bij de BRO en weten niet hoe wij onze gegevens op de juiste manier om kunnen zetten naar een .xml bestand, die bij de BRO ook goed uit te lezen is.

Kunnen jullie ons informatie geven over het aanleveren van de BHR-P boringen in de BRO?

330

BM24 10 00621

zie nr 329

329

BM24 10 00621

Hierbij doe ik jullie een wijzigingsverzoek toekomen voor de standaard van BHR-G.
Achtergrond van het wijzigingsverzoek is dat er bij 2 attributen regels fout zijn gedefinieerd waardoor nu bij de migratie informatie wordt tegen gehouden maar die wel opgenomen zou moeten worden. Het betreft ca. 16.000 boringen in de set van NEN5104 dus het is een substantiële set waardoor het wenselijk is om deze met een werkafspraak op korte termijn te verwerken.

Wijziging 1.

>
In de catalogus BHR-G, versie 3.19, staat in par. 6.3.23.11 schelpmateriaalgehalteklasse archief, attribuut van Grond, een fout in de 2e IMBRO/A-regel.

De regel luidt nu:
“Het attribuut mag niet aanwezig zijn wanneer de waarde van het attribuut beschrijfkwaliteit van de entiteit Boorprofiel gelijk is aan geologischNEN5104Archief en de waarde van het attribuut grondsoort NEN5104 is niet gelijk aan schelpenNietGespecificeerd, siltigeSchelpen, zandigeSchelpen, zwakZandigeSchelpen, matigZandigeSchelpen, sterkZandigeSchelpen of uiterstZandigeSchelpen.”

Het tweede woordje ‘niet’ moet worden verwijderd.
<

Wijziging 2.

>
In de catalogus BHR-G, versie 3.19, staat in par. 6.3.32 Schelpenfractie archief, attribuut van Grond, een foute regel te weten de 2e IMBRO/A-regel.

De entiteit mag niet aanwezig zijn wanneer de waarde van het attribuut beschrijfkwaliteit van de entiteit Boorprofiel gelijk is aan geologischNEN5104Archief en de waarde van het attribuut grondsoort NEN5104 van de entiteit Grond is niet gelijk aan schelpenNietGespecificeerd, siltigeSchelpen, zandigeSchelpen, zwakZandigeSchelpen, matigZandigeSchelpen, sterkZandigeSchelpen of uiterstZandigeSchelpen.

Deze regel moet in het geheel komen te vervallen

328

BM24 09 00351

Bij de levering van boorgaten onder EPC lopen we tegen het bereik van de datum openbaarmaking (attribuut van Boortraject) aan. Waarom is de ondergrens op 1 januari 2003 gesteld? Wat is de bedoeling voor boorgaten die al voor de inwerkingtreding van de Mijnbouwwet openbaar zijn gemaakt? Het gaat om ca. 900 boorgaten waarvan de levering nu wordt belemmerd.

Overigens mag de boortraject locatie volgens de catalogus ontbreken onder IMBRO/A, waarom moet de datum openbaarmaking (van het boortraject locatie) verplicht worden aangeleverd wanneer de boortraject locatie ontbreekt?

327

BM24 09 00351

Bij de levering van boorgaten onder EPC lopen we tegen het bereik van de datum openbaarmaking (attribuut van Boortraject) aan. Waarom is de ondergrens op 1 januari 2003 gesteld? Wat is de bedoeling voor boorgaten die al voor de inwerkingtreding van de Mijnbouwwet openbaar zijn gemaakt? Het gaat om ca. 900 boorgaten waarvan de levering nu wordt belemmerd.

Overigens mag de boortraject locatie volgens de catalogus ontbreken onder IMBRO/A, waarom moet de datum openbaarmaking (van het boortraject locatie) verplicht worden aangeleverd wanneer de boortraject locatie ontbreekt?

Met vriendelijke groeten
Namens de dataleverancier BRO-EPC

326

BM24 10 00178

In het BRO Bronhouderportaal bij 'Bekijken' zou ik graag als BRO-coördinator inzicht willen hebben in de BRO middels een Dashboard.
Zie de voorgestelde tab ‘Dashboard’ hieronder (naast ‘Onderzoeken’) om nieuw aan te maken.

Wat ik hierop sowieso wil zien qua data:

Rapportage terugmeldingen BRO binnen/buiten de wettelijke termijn van 16 weken afgehandeld;
Rapportage van de verschillende registratie Domeinen (zoals: Grondwatergebruik, Grondwatermonitoring, ...etc.);
Rapportage van het aantal objecttype(n) per domein per maand.

Op deze manier kan ik als BRO-coördinator veel beter sturen op onder andere de gegevenskwaliteit van de BRO.
Hiermee zou ik de ENSIA Verklaring inzake de BRO beter kunnen invullen.
En het is voor BRO afnemers van belang dat de BRO actueel en zo volledig mogelijk is.

325

BM24 10 00108

Ik zie op BROLoket dat Bronhouders in de toekomst liggende (oftewel voorziene) einddata van een GUF licentie registreren, middels een Closure bericht. Dat is niet de bedoeling: de BRO moet feitelijke gegevens bevatten, geen ‘voorziene’ gegevens; de definitie van attribuut Eindtijd van GUF is ook “Tijdstip waarop het object in de werkelijkheid niet meer geldig is”.

Oorzaak is ( voor zover ik overzie) het ontbreken van een regel bij het GUF Closure brondocument waarin wordt afgedwongen dat endtime ( eindtijd) niet in de toekomst mag liggen. Dit staat niet in de GUF inname berichtencatalogus en is dus ook niet geimplementeerd.

Momenteel is er bij ongeveer 300 GUF objecten van de ruim 2800 objecten met een geregistreerde einddatum sprake van een foutieve ‘voorziene’ einddatum die in de toekomst ligt.

Verzoek is daarom om dit te corrigeren door:

De bussinessregel waarin wordt afgedwongen dat endtime ( eindtijd) niet in de toekomst mag liggen op te nemen in de GUF inname berichtencatalogus—GUF closure bericht, en XSD en die te implementeren in de LV;
Vervolgens de bestaande, verkeerde inhoud van betreffende GUF objecten te laten corrigeren door DL BIJ12 (via Registratie beheerder), middels het aanbieden van verwijderverzoeken van de betreffende GUF closureberichten.

324

BM24 10 00093

Als ik van één put met 3 filters alle grondwaterkwaliteit (GAR) uit BRO opvraag in csv-formaat, dan is het niet werkbaar dat iedere analyse in een aparte csv zit.
Die zou je ‘gewoon’ samengevoegd willen hebben tot 1 csv.

323

BM24 09 00057

Als bronhouder, wil ik in een aanlevermachtiging kunnen filteren op registratieobject,
zodat ik bv uitsluitend GLD wil laten aanleveren met automatische doorleveringen (wegens voorlopige beoordeling) terwijl GMW van diezelfde leverancier NIET kan worden aangeleverd.

322

BM24 08 00308

De aangeleverde parameters in het kader van de BRO zijn verwerkt op de hulplijst-Gegevensuitwisseling_Grondwaterkwaliteit (zie bijlage). Een groot aantal parameters waren nog niet opgenomen in de Aquo-domeintabel Parameter. Deze zijn nu toegevoegd.
Kunne jullie de lijst (laten) controleren en indien er nog wijzigingen moeten worden aangebracht, dan hoor ik dat graag. Omdat ik geen analysecertificaat heb ontvangen, weet ik de eenheid van de parameters niet en heb ik deze op µg/l gezet, maar er zijn vast parameters die in ng/l worden gerapporteerd. Dat hoor ik dan ook graag.

De hulplijst zoals opgenomen in de bijlage zijn gepubliceerd op de website van Aquo, zie https://www.aquo.nl/index.php/Hulplijsten_gegevensuitwisseling

Daarnaast wil ik aangeven dat het CAS-nummer van ID4336 Oxytetracycline onjuist in de standaard staat. Deze fout willen we graag herstellen. Hiervoor is wijzigingsvoorstel W-2407-0021 aangemaakt. Dit voorstel ligt momenteel ter advies bij de Expertgroep Chemie. Als zij akkkoord zijn dan moet het nog beoordeeld worden door de Technische Werkgroep IM Metingen. Als iedereen akkoord is dan kan de wijziging doorgevoerd worden in updateronde 2024-12. Als wijzigingsvoorstel W-2407-0021 is doorgevoerd zal ik dit verwerken op de hulplijst-Gegevensuitwisseling_Grondwaterkwaliteit. Jullie ontvangen eind van dit jaar hier van bericht

In de hulplijst is bij parameter Oxytetracycline onderstaande opmerking toegevoegd.

321

BM24 08 00297

De BHP-API Projecten (die met url https://www.bronhouderportaal-bro.nl/api/v2/projecten) is eerder in het leven geroepen in het kader van overleg tussen jullie, RWS en ondergetekende, en heeft vooralsnog een experimentele status. We gebruiken deze API nu ook voor en met provincie Utrecht t.b.v. het synchroniseren van de Bron- en BRO-data van de provincie. We lopen daarbij echter tegen een wens aan, die ik bij deze graag ook indien als Request for Change. Het eigenlijke verzoek:

Bij inloggen in het BHP zelf is ook de "Gemachtigde organisatie" zichtbaar. Het verzoek is om deze ‘Gemachtigde' ook toe te voegen aan de respons van de API
De ‘Verstrekker’ van de machtiging is daarentegen mijns inziens altijd gelijk aan de ‘Bronhouder’ en mag daarmee weg uit de respons (maar als ik iets over het hoofd zie, dan hoor ik het graag)

Zie verder voor het gemak nog eens de huidige API-respons zoals te vinden is onder https://www.bronhouderportaal-bro.nl/doc/api.html#tag/Algemeen

320

BM24 08 00200

Al langer, en niet alleen bij mij, speelt het idee dat er rondom de BRO meer inhoudelijke discussie en afstemming zou mogen zijn. Inhoudelijke discussie is iets voor inhoudelijk betrokkenen en inhoudelijk deskundigen, bij bronhouders maar zeker ook bij leveranciers, ingenieursbureaus en kennisinstituten en natuurlijk BRO-beheer en het BRO-programmabureau zelf. Inhoudelijk betrokkenen zijn logischerwijze ook degenen die bij hun werk tegen inhoudelijke issues aanlopen. Zij zijn degenen die nut en noodzaak van inhoudelijke issues ook het best op waarde kunnen schatten, ze hebben er in praktijk ook het meest hinder van en/of belang bij.

Eerder is vanuit provincies, RWS, BZK en TNO het initiatief genomen om inhoudelijke (keten)issues periodiek te bespreken in het zogeheten ketenissuesoverleg. Alhoewel dat overleg uiteraard waardevol is of was, is het al een tijdje niet meer bijeen geweest en is het vooralsnog de vraag of en hoe het voortgezet wordt. Het ketenissuesoverleg is bovendien geen formeel onderdeel van de begeleidingsstructuur van de BRO. Ook het aandragen van onderwerpen voor de agenda, deelname en/of toegang tot agendastukken en resultaten is niet formeel of open geregeld.

Om die reden dien ik bij deze graag als Request for Change een verzoek tot formele organisatie van een breder, inhoudelijk BRO-(Ketenissues)overleg in. Ik ben zelf nog lid geweest van de eerdere DINO-gebruikersraad, waar destijds juist vooral inhoudelijk deskundigen bij leveranciers, ingenieursbureaus en kennisinstituten aan deelnamen, en dat wellicht ook als voorbeeld kan dienen voor de BRO.

Aanleiding voor dit verzoek is overigens de bijgaande, ingewikkelde terugmelding en onderlinge discussie daarover tussen de inhoudelijk betrokkenen. De ‘driehoeksrelatie’ (of eigenlijk zeshoeksrelatie als je de leveranciers en jullie als servicedesk ook meerekent) maakt dit tot een typisch ketenissue. Ketenissues gaan ook per definitie over issues die spelen tussen meerdere partijen tegelijk natuurlijk, waar je alleen via goed onderling overleg uit komt.

319-3

BM24 07 00444

Er zit nu verschil in de precisie van de datumtijd waarden die worden uitgegeven.

Bij de levering informatie tot tot op de micoseconde niveau (10^-6)
Bij de transactie informatie tot op de milliseconde (10^-3). Maar, omdat de (3) decimalen altijd 0 zijn, lijkt het erop dat de waarde praktisch gezien tot op de gehele seconde wordt opgeslagen/uitgegeven.

à Het is misschien eleganter om op de verschillende plekken eenzelfde precisie te hanteren.

319-2

BM24 07 00444

Er zit nu verschil in welke tijdzone de datumtijd waarden worden uitgegeven.

Bij de levering informatie worden de datumtijd waarden in de NL tijdzone uitgegeven.
De datum en tijd die je ziet, is dus de tijd zoals je die ‘op de klok in NL’ had gezien (waarbij dus niet wordt teruggegeven of toen +01:00 of +02:00 gold).
Bij de transactie informatie worden de datumtijd waarden in de UTC tijdzone uitgegeven.
De datum en tijd die je ziet, is dus de tijd zoals je die ‘op de klok in GMT’ zou zien (waarbij wél wordt teruggegeven dat dit in +00:00 is).

à Het lijkt mij eleganter als op de verschillende plekken het tijdstip in dezelfde tijdzone wordt uitgegeven.
Afhankelijk of het mogelijk blijkt om overal tijdstippen mét tijdzone uit te geven (zoals hoofdverzoek), lijkt het mij wenselijk om hier als volgt mee om te gaan;

Als dit mogelijk is, dan zou ik opteren om datumtijd altijd en overal conform de NL tijdzone uit te geven uitgegeven.
Als dit niet mogelijk is, dan zou ik opteren om datumtijd waarden altijd conform de UTC tijdzone (+00:00 of ook wel ‘Z’) uit te geven.

319-1

BM24 07 00444

Hoofdverzoek
Het lijkt mij wenselijk als in de informatie over BHP leveringen, bij de attributen met een datumtijd waarde, ook de tijdzone aan de waarde wordt toegevoegd.
Dit zodat;

Er een eenduidige/herleidbare datumtijd waarde wordt teruggegeven.
Duidelijk is om welke datumtijd waarde het gaat (utc of lokale tijd).

318

BM24 07 00122

Wijzigingsverzoek voor IMBRO/A regel bij het attribuut organischestofgehalteklasse NEN5104 (attribuut van Grond): De organischestofgehalteklasse mag bij de grondsoort dy niet worden vastgelegd. De regels zijn wat dit aspect betreft bij grondsoort NEN 5104 goed geformuleerd (organischestofgehalteklasse mag niet worden vastgelegd bij dy), maar bij de geologische grondsoort is dat niet goed geformuleerd, daar moet de organischestofgehalteklasse worden vastgelegd (dy namelijk binnen de categorie ‘bijzondere grond’).

317

BM24 07 00088

Als afdeling Hydrology and Reservoir Engineering do van TNO,

Wil ik dat de staandaart wordt aangepast

Zodat ik de boormonsteranalyses kan aanleveren volgens het huidig geldende protocol wat wordt gehanteerd binnen de afdeling.

316

BM24 07 00074

In verband met de migratie DINO2BRO voor boorgaten (EPC) blijkt nóg een werkafspraak nodig te zijn. Het attribuut ‘verschuiving’ van de entiteit ‘Aangeleverde verticale positie’ heeft als domein ‘Meetwaarde 3.0’ met als eenheid ‘m (meter’). Dit betekent een nauwkeurigheid van hele meters. Gewenst is een nauwkeurigheid op centimeters, dus Meetwaarde 3.2 (met ongewijzigde eenheid). Dit vanwege:

•Geen gegevensverlies t.o.v. DINO;
•Consistentie met nauwkeurigheid van ‘totale lengte’ en ‘werkelijke verticale einddiepte’ (attributen van Boortraject locatie).

Een correctie op dit issue: ik noemde het attribuut ‘verschuiving’, maar dat moet zijn: ‘oorspronkelijke verschuiving’.

Het is overigens wel goed om ook de nauwkeurigheid van ‘verschuiving’ direct mee te nemen.

315

BM24 07 00062

Bij een volgende versie van CPT willen we vanuit de standaard met de branche bespreken of het wenselijk en nodig is om een regel door te voeren om te voorkomen dat er metingen worden geregistreerd binnen het voorgegraven traject.

314

BM24 07 00019

Bij het klaar maken van de levering van booronderzoeken aan de BRO (BHR-G) zijn we tegen een onterechte IMBRO/A regel aangelopen bij de fractieverdeling volledig (attribuut van Fractieverdeling). Een volledige fractie verdeling wordt gevraagd bij natuurlijke homogene lagen (antropogeen = nee). De regel stelt nu dat wanneer het niet bekend is of een laag natuurlijk of antropogeen is (antropogeen = onbekend) de fractieverdeling ook volledig moet zijn. Dat laatste is onterecht.

Regels IMBRO/A: De waarde van het attribuut moet gelijk zijn aan ja wanneer de waarde van het attribuut beschrijfkwaliteit van de entiteit Boorprofiel gelijk is aan geologischUitgebreidArchief, en de waarde van het attribuut antropogeen van de entiteit Laag is gelijk is aan nee of onbekend, en de entiteit Laagje is niet aanwezig is.

313

BM24 06 00312

Als Bronhouder/Dataleverancier wil ik een aanpassing van de GAR standaard ( ihb parameterlijst) dan wel een generieke aanpassing aan de wijze waarop de AQUO domeinijsten worden gebruikt voor de parameterlijsten voor GAR ,SAD en BHR-P, zodat ik bij GAR zowel stoffen die vanuit gefiltreerde als stoffen die vanuit ongefiltreerde bemonstering zijn geanalyseerd kan registreren ( momenteel levert de wijze waarop de GAR parameterlijst wordt afgeleid uit de AQUO domeinlijst beperkingen op --vaste hoedanigheden).

312

BM24 07 00016

In verband met een aanvraag voor een opslagvergunning voor waterstof, dienen wij het verzoek in om de waardelijst Stof (Basisregistratie Ondergrond Catalogus Mijnbouwwetvergunning (broprogramma.github.io)) uit te breiden met de waarde ‘waterstof’.

311

BM24 07 00015

Als Leverancier van data uit DINO wil ik dat de standaard wordt aangepast,

Zodat ik de informatie van de schelpen juist aan kan leveren en geen objecten tegen gehouden worden bij de migratie.

310

BM24 07 00015

Als Leverancier van data uit DINO wil ik dat de standaard wordt aangepast,

Zodat ik de informatie van de schelpen juist aan kan leveren en geen objecten tegen gehouden worden bij de migratie.

309

BM24 06 00210

Als opdrachtgever geeft ik Tauw en Aequator opdrachten om bodemkundige booronderzoeken uit te voeren. Deze zouden moeten worden aangeleverd aan de BRO. Echter is er voor dit registratieobject geen "berichtencatalogus innamenservice" gemaakt aangezien tot op heden alleen WENR gegevens aanleverde.

308

BM24 04 00170

Als dataleverancier wil ik kunnen zien welke leveringen die zijn aangeleverd door een gedelegeerde dataleverancier

307

BM24 06 00156

Graag onderstaand verzoek opnemen als wijzigingsverzoek voor BHR-G

Vanuit de conversie willen we dat er voor het attribuut “6.3.47.3 reden niet beschreven” binnen de entiteit “Niet beschreven interval” het domein “RedenNietBeschreven” wordt uitgebreid met de domeinwaarde “gesteentelaag”

Zodat de betreffende boringen meegenomen kunnen worden bij de conversie en de gebruiker weet dat er op de betreffende diepte gesteente aanwezig is wat niet volgens de opgegeven procedure beschreven is.

306

BM24 05 00281

Het valideren van een XML-bestand voor een BHR-GT via de REST API levert foutmeldingen op voor een Triaxiaalproef:
"Volume bij bepaalde consolidatie.verlopen tijd (VolumeAtSpecificConsolidation.elapsedTime) = 705669.0 waarde is niet correct: mag niet groter zijn dan 700000.",
Zie bijlagen voor de BRO response en het XML-bestand.
De BHR-GT catalogus geeft weliswaar aan dat de Verlopen Tijd binnen 0 tot 700000 seconden moet liggen, maar ons lab geeft aan dat in de praktijk deze waarde boven de 700000 kan liggen zoals bij deze Triaxiaalproef het geval is.
https://broprogramma.github.io/BHR-GT/#detail_attribute_Model_Volumebijbepaaldeconsolidatie_verlopentijd
We kunnen 3 opties bedenken:

· Het bereik zoals vermeldt in de catalogus wordt vergroot.

· We kappen onze meetdata af 700000 seconden af.

· We nemen de gehele triaxiaalproef niet op in het XML-bestand.

305

BM24 06 00044

Als informatiemanager van TNO-GDN voor Bodem- en Grondonderzoek wil ik dat er een toelichting cq handreiking wordt opgesteld waarin gebruikte naamgevingen in de standaarden van de BRO worden geduid, zodat er duidelijkheid ontstaat voor gebruikers over de gebruikte terminologie.

304

BM24 06 00043

Als informatiemanager van TNO-GDN voor Bodem- en Grondonderzoek wil ik dat de norm NEN-6693 wordt geïmplementeerd in de standaard van SAD, nog voordat deze via een wettelijk traject wordt vastgesteld, zodat vanaf de verplichte datum conform deze dan gevraagde norm wordt aangeleverd.

303

BM24 06 00020

Als gebruiker van de CPT’s uit de BRO wil ik dat de notatiewijze van de gemeten parameters wordt aangepast.
Zodat ik de CPT’s uit de BRO kan gebruiken in rekenprogramma’s

302

BM24 05 00227

Als gebruiker zou ik graag willen dat :

Kunnen we op BRO/DINOloket ergens duidelijk vermelden hoe de gegevens ingewonnen op deze site te refereren is in een publicatie?

Het gaat dan ook om bv de grondwater kwaliteitsgegevens of grondwaterstanden die op te vragen zijn, in de pdf 'bericht van levering.pdf' zou volgens mij eenvoudig een actuele 'hoe deze data te citeren' regel opgenomen kunnen worden, met daarin opgenomen ook de datum van gegevens opgevraagd.

Zodat bij gebruik juist citatie gebruikt word.

301

BM24 05 000252

Op NLOG worden boorgaten getoond waarvan de vertrouwelijkheidsperiode nog niet voorbij is. Niet alle gegevens van boorgaten zijn namelijk vertrouwelijk.

Een voorbeeld van een gegeven dat wél (temporeel) vertrouwelijk is, is de ligging van het traject dat voor een boring in de ondergrond is gevolgd. Voor de migratie van gegevens vanuit het TNO-interne systeem (DINO) naar de BRO die we nu voorbereiden, is dat gegeven géén probleem. Ten eerste omdat we besloten hebben dat gegeven niet te migreren (maar alleen een 'puntje op de kaart'), ten tweede omdat de BRO EPC catalogus in vertrouwelijkheid van dat gegeven voorziet.

Een gegeven dat misschien wél een probleem geeft, is de wettelijke status (zie de BRO EPC catalogus https://broprogramma.github.io/EPC/#detail_attribute_Model_Mijnbouwconstructie_wettelijkestatus). Dat gegeven heeft volgens de catalogus geen vertrouwelijkheid. Zelf ben ik betrokken geweest bij het opstellen van de catalogus en van daaruit weet ik dat hier ook niet over is gesproken.

Echter is nu vanuit TNO-GDN, vanwege deze migratie, de vraag gesteld of de wettelijke status altijd openbaar is. Op NLOG wordt namelijk de operationele(!) status niet getoond bij boorgaten voor de termijn dat de boorgatgegevens vertrouwelijk zijn. Zie bijv. op NLOG boring MIDDENMEER-GT-10 (https://www.nlog.nl/nlog-mapviewer/brh/3910564522?lang=nl).

Voor boorgaten waarvan de vertrouwelijkheidsperiode voorbij is, wordt de operationele(!) status wél getoond. Zie bijv. boring NIEUWENDIJK-01 (https://www.nlog.nl/nlog-mapviewer/brh/421238697?lang=nl, veld 'Status').

Nu is de operationele status die op NLOG wordt getoond een ander gegeven dan de wettelijke status die in de BRO EPC catalogus staat. Ze hangen echter deels samen. Een operator heeft misschien (commercieel) belang bij het niet tonen van de wettelijke status.

Dus de vraag is: behoort de wettelijke status van een boorgat tot de vertrouwelijke boorgatgegevens?

1. De waardelijst WettelijkeStatus (https://docs.geostandaarden.nl/bro/EPC/#detail_class_Model_WettelijkeStatus) wordt uitgebreid met de waarde 'onbekend'. Alleen te gebruiken onder IMBRO/A. Omschrijving nader te bepalen. Voor boringen waarvoor we bij migratie de wettelijke status niet kunnen bepalen, wordt 'onbekend' ingevuld. Verzoek tot werkafspraak hiertoe zal ik indienen bij de BRO.

2. Als blijkt (uit overleg dat Jeroen zal initiëren met Frank Denys) dat de wettelijke status tot de vertrouwelijke gegevens van een boring behoort, dan zullen die betreffende boringen (op dit moment 83 stuks) niet meegenomen worden in de migratie.

300

BM24 05 00096

Gegevensgroep ‘locatiebepaling’ optioneel i.p.v. alle attributen ervan.

De gegevensgroep ‘locatiebepaling’ is verplicht maar de drie attributen ervan mogen alle weggelaten worden. Een later afgesproken manier van modelleren is dat de gegevensgroep in zo’n geval optioneel is, maar 1 of meer attributen ervan verplicht.

impact op: Catalogus + TO + LV-BRO

Aanpassing XSD + LV-BRO voorwaardelijk voor bouw migratietool.

3 EPC wijzigingsverzoeken 08052024.pdf

299

BM24 05 00094

De aanpassing is als volgt:

Onvolledige datums hoeft NIET geïmplementeerd te worden.
Gewenst is uitbreiding van de toelichting bij startdatum aanleg en einddatum aanleg, bij begindatum Levensduur en datum gebeurtenis, namelijk dat bij datums 1 januari en 31 december vóór 1956 er sprake kan zijn van een fictieve datum en dat alleen het jaar is bedoeld.

De achtergrond van deze aanpassing is dat ik met de domeinexperts heb afgesproken om álle datums met 01-01 en 31-12 1-op-1 te migreren.

3 EPC wijzigingsverzoeken 08052024.pdf

298

BM24 05 00093

Eigenaar wordt niet aangeleverd, wat kan volgens de catalogus. Echter moet er een nieuwe reden van niet aanleveren worden toegevoegd aan de catalogus. Allen impact op catalogus. geen implicatie op migratie. Formeel onjuiste situatie in BRO. Nl. boorgaten zonder eigenaar in BRO met een reden (nl. MVP-migratie) die niet in de catalogus staat.

Het attribuut wordt namelijk niet gevuld in deze migratie. Volgens de catalogus is het attribuut verplicht. Weliswaar geldt ‘Mogelijk geen waarde’ = ‘Ja’. Maar in het rijtje ‘Reden geen waarde’ dat hierbij hoort, is de reden voor dit geval – namelijk een minimale migratie – niet voorzien.

3 EPC wijzigingsverzoeken 08052024.pdf

297

BM24 05 00029

Voor het aanleveren van GLD staan er geen regels in de inname catalogus die controleren of een GMW in registratie is. Hierdoor is het mogelijk dat GLD wordt geleverd aan een put die uit registratie is.

Alleen de controle of het BRO-ID van de put bestaat is niet genoeg. Het is gewenst om de regels aan te scherpen met een controle of het BRO-ID in registratie is. Vanuit GLD is deze wens ontstaan, maar het zal ook gelden voor andere objecten die een relatie hebben naar een ander object, bijvoorbeeld GAR, GPD en GUF.

296

BM24 02 00212

Alhoewel we de BHP-API v2 zeker van harte verwelkomen (met weliswaar ook daarbij nog een openstaand verzoek tot ‘Change’), blijft het zo dat ons inziens de situatie bij bronhouders die gebruik maken van ontzorgende partijen niet wenselijk is. Dergelijke ontzorgende partijen moeten nu noodgedwongen een token van de bronhouder zelf gebruiken, met alle ongewenste gevolgen van dien. RWS is daarnaast als organisatie zo groot, dat het werken met één token dat noodgedwongen binnen en buiten de organisatie gedeeld wordt, al gauw onveilig te noemen is.

295

BM23 11 00179

N.a.v. overleg van de BRO-DBG van vandaag en het BRO-Ketenissues- annex BRO-Denktankoverleg van afgelopen donderdag dien ik bij deze dan ook graag formeel een RFC-verzoek in voor implementatie van het bron-format, zoals besproken.

294

BM24 02 00212

Alhoewel we de BHP-API v2 zeker van harte verwelkomen (met weliswaar ook daarbij nog een openstaand verzoek tot ‘Change’), blijft het zo dat ons inziens de situatie bij bronhouders die gebruik maken van ontzorgende partijen niet wenselijk is. Dergelijke ontzorgende partijen moeten nu noodgedwongen een token van de bronhouder zelf gebruiken, met alle ongewenste gevolgen van dien. RWS is daarnaast als organisatie zo groot, dat het werken met één token dat noodgedwongen binnen en buiten de organisatie gedeeld wordt, al gauw onveilig te noemen is.

293

BM24 04 00157

Als dataleverancier wil ik de leveringstatus op kunnen vragen, ook wanneer de machtiging gesloten is.

Als een bronhouder de levering geaccordeerd heeft dan kan deze de machtiging in principe sluiten.

Het gevolg is dat de dataleverancier de leveringstatus (inclusief de BRO id’s) dan niet meer kan ophalen.

Het lijkt me daarom een standaard situatie.

292

BM24 03 00383

⒈Het gaat hier om:

⒜Raadplegen via BROloket (bekijken grafiek): kan de kleur ook worden weergegeven?
⒝Via bronhouderportaal: alleen het type grond is zichtbaar; het zou mooi zijn als de andere gegevens uit de xml ook in de grafiek getoond kunnen.

⒉In de xml zit een omschrijving (description) aangegeven, zie daarvoor ook de tabel in het meegeleverde Worddocument. Deze description is uitgebreider dan staat weergegeven in de grafiek. Is het mogelijk om die uitgebreidere description ook op te nemen in de weergave van de grafiek?

291

BM24 04 00167

Verzoek RVO
Als: Bronhouder en opdrachtgeven van BHR-GT
Wil ik dat:

6.3.67 Bepaling verzadigde waterdoorlatendheid de 6.3.67.2 bepalingsmethode ISO 17892-11:2019
Ook de mogelijkheid is om de flexible wall permeameter te gebruiken

Gezien het feit dat voor offshore deze methode veelal gebruikt wordt en binnen de norm is toegestaan!
Bij de volgende versie graag doorvoeren!

290

BM24 04 00166

Verzoek RVO
Als: Bronhouder en opdrachtgeven van BHR-GT
Wil ik dat:

Bij 6.3.61 Bepaling korrelgrootteverdeling
De 6.3.61.1 bepalingsprocedure de procedure NEN-ISO 13322-2 (laserdiffractie) wordt toegevoegd

Gezien het feit dat deze methode een steeds vakere en veel toegepaste en goedkopere methode betreft
Bij de volgende versie graag doorvoeren!

289

BM24 04 00112

1. Wijzigingsverzoek BRO-EPL aardwarmte vergunningen: uitbreiding verleend gebied met reservoir interval
Op 1 juli 2023 is de wijziging van de Mijnbouwwet voor aardwarmte in werking getreden (dat is 1 jaar na vaststelling van de BRO-EPL catalogus op 1-juli 2022). Vanaf dat moment is het verplicht om in aardwarmte vergunningen de “aardlagen” op te nemen waarvoor de vergunning geldt.

Artikel in de Mijnbouwwet
Type vergunning (verleningsbesluit)
Definitie
Artikel 24v
Het besluit tot verlening van een startvergunning aardwarmte
“Onze Minister bepaalt in een startvergunning aardwarmte voor welke aardlagen en begrenzing daarvan zij geldt”
Artikel 24ak
Het besluit tot verlening van een vervolgvergunning aardwarmte
“In een vervolgvergunning aardwarmte wordt bepaald voor welk tijdvak zij geldt en voor welke aardlaag en begrenzing daarvan zij geldt”

Noot: vergunning aanvraag en toewijzing zoekgebied niet in scope BRO
Vóór de wetswijziging van de MBW werden aardwarmtevergunningen soms verticaal begrensd, dit werd op een andere manier gedaan, namelijk door de boven- en of ondergrens vast te leggen. In de nieuwe systematiek worden de stratigrafische eenheden (de zogenaamde ‘aardlagen’) waarop de vergunning van toepassing is vastgelegd (ofwel het zogenaamde reservoirinterval). De huidige catalogus staat alleen toe om de boven- en ondergrens van de vergunning te registreren (de ‘oude manier’). We zouden graag zien dat de catalogus wordt uitgebreid om naast het dieptebereik (de verticale begrenzing voor de vergunningen verleend voor 1 juli 2023) ook de lagen van het reservoirinterval te kunnen registreren (de ‘nieuwe manier’).

Gewenste aanpassing voor aardwarmte vergunningen: Verleend gebied (par. 5.3.9) uitbreiden met een ‘reservoir interval’ (naast het dieptebereik). Dat heeft impact op Catalogus, XSD en LV-BRO (uitbreiding is backwards compatible).

Noot: Waarschijnlijk is hiermee ook een uitbreiding van de waardelijst “GeologischeEenheid” nodig. Dit valt buiten dit wijzigingsverzoek en zal worden opgenomen met de generieke werkafspraak mbt uitbreiding codelijsten; Proces generieke werkafspraken BRO codelijsten (bro-productomgeving.nl)
1. Wijzigingsverzoek BRO-EPL aardwarmte vergunningen: diepte t.o.v. maaiveld
In de besluiten voor aardwarmte vergunningen waarbij het dieptebereik volgens de ‘oude manier’ is gedefinieerd d.m.v. een begin- en einddiepte (in meters), is de diepte gegeven t.o.v. maaiveld (aardwarmte vergunningen bevinden zich altijd op land). Dat is in lijn met artikel 2 van de Mijnbouwwet.
rtikel in de Mijnbouwwet

Definitie
Artikel 2.2
“Deze wet, met uitzondering van artikel 51, is met betrekking tot delfstoffen slechts van toepassing, voorzover de delfstoffen op een diepte van meer dan 100 meter beneden de oppervlakte van de aardbodem aanwezig zijn.”
Artikel 2.3
“Deze wet is met betrekking tot aardwarmte slechts van toepassing, voorzover de aardwarmte op een diepte van meer dan 500 meter beneden de oppervlakte van de aardbodem aanwezig is.”
Noot: de aardbodem is in BRO termen het maaiveld (op land) of de waterbodem
In de catalogus staat bij de attributen (par. 5.3.10.1) begindiepte en (par. 5.3.10.2) einddiepte (attributen van Dieptebereik) in de toelichting dat de diepte op land is gegeven t.o.v. van NAP. Dit moet voor aardwarmtevergunningen worden “t.o.v. maaiveld”
Gewenste aanpassing: toelichting in catalogus aanpassen.

288

BM24 04 00092

Graag zou ik de nieuwe versie van het QC-protocol van provincies en het RIVM voor GAR-gegevens willen aanmelden bij de BRO. Bijgevoegd is de documentatie ervan.
Naam: QCProtocolProvinciesRIVMv2024
Omschrijving: Het kwaliteitscontrole protocol: 'Protocol voor datakwaliteitscontrole (QC) - Kwaliteitsborging grondwaterkwaliteitsdata provincies & RIVM; versie 2024'.

287

BM24 04 00061

Bij deze wil ik graag een wijzigingsverzoek indienen. Met de nieuwe versie van DINOloket is het niet meer mogelijk om een url van de helpfunctie te gebruiken (voor verwijzingen etc).
Dat is niet praktisch. Is het mogelijk dat het weer een url wordt?

286

BM24 03 00354

Het zou handzaam zijn om binnen het Portaal - menu 'Bekijken' - tabbladen 'Registratieobjecten' en 'Transacties', een kolom 'Levering-ID' op te nemen.

Onder tab 'Transacties' kan nu gezocht worden op 'Transactie-ID'; het zou dan prettig zijn om tevens te kunnen zoeken op 'Levering-ID'.

285

BM24 03 00188

Bij het zoeken op ID's in het bronhouderportaal zou het mooi zijn als niet een geheel BRO-ID ingevuld hoeft te worden, maar bijvoorbeeld alleen de nummers aan het eind van de reeks die het object uniek maakt. In het BRO'tje van vandaag is het voorbeeld '70033' gebruikt om te zoeken, wat niet werkte omdat er geen 'wildcard' functionaliteit lijkt te zijn.

284

BM24 03 00187

In het BRO Bronhouderportaal bij 'Bekijken' -> 'Registratieobjecten' de functionaliteit toevoegen dat je een dropdown menu krijgt bij de kolom 'Dataleveranciers'.

Op deze manier is in één keer inzichtelijk welke dataleveranciers allemaal al een object hebben geregistreerd voor jouw organisatie.

283

BM24 03 00186

In het BRO Bronhouderportaal bij 'Bekijken' -> 'Transacties' de tekst bovenin toevoegen: ' Hier wordt bijgehouden wat er wordt aangeleverd aan de Landelijke Voorziening BRO.'

282

BM24 03 00185

In het BRO Bronhouderportaal bij 'Bekijken' -> 'Registratieobjecten' boven 'objecttype' de verschillende registratie 'Domeinen' toevoegen (zoals: Grondwatergebruik, grondwatermonitoring, ...). Op deze manier zou je kunnen filteren per domein. Waarna alleen de objecttype(n) per domein zichtbaar worden.

280 - 281

Voor de migratie van DINO – BRO m.b.t. GLD heb ik een aantal verzoeken.

Ik zie dat als experimentele functionaliteit is toegevoegd om transacties te bekijken. Dat lijkt mij heel nuttig, en de paginering methodiek is ook prettig.

Wel zou ik graag de mogelijkheid willen hebben om de resultaten te kunnen filteren op;

Projectnr (?)

Levering id (?)
bronhouderKvk
registratieobjecttype
brondocumenttype

Als ik nu bijv voor TNO zou zoeken zonder enige query parameters, dan blijken er 126386 transacties te zijn. Die wil je niet allemaal opvragen natuurlijk.
Wat ik eigenlijk nodig heb is om alleen de transacties op te kunnen vragen die zijn gedaan onder één project (dat is gerelateerd aan de DINO – BRO GLD migratie).

Vooralsnog heb ik de query kunnen/weten te beperken door gebruik te maken van de volgende query parameters;

‘zoekveld’ = ‘transactieId’
‘zoektekst’ = ‘GLD’
‘transactietype’ = ‘registreren’

Dat levert echter alsnog 9526 Zoekresultaten, waar ik er eigenlijk maar 544 nodig heb (alleen die van bronhouder ‘30281419’ (Waterschap Rivierenland)). Nu heb ik dit opgelost door achteraf de resultaten te filteren op deze bronhouder (want bronhouderKvK is wel gewoon een attribuut van de transaction array).

Verder zou ik graag de leveringen willen koppelen aan de transacties. Dat kan ik nu ook, door eerst alle leveringen op te vragen van het project. Voor iedere levering, krijg je dan een brondocument array met daarin ook het transactie Id.
Waar ik dan echter tegenaanloop is dat het opvragen van de details van de leveringen tergend langzaam is. Dat komt omdat je daarbij per levering de details moet opvragen. Voor de 545 leveringen (er zat een levering met GMW brondocument tussen) duurde dat bij mij nu: 25 min en 11 seconden

Merk op, ik maak dan al gebruik van maximaal 25 concurrent http requests. Als ik dat minder zet, duurt het naar mijn ervaring nog langer.
Graag zou ik dus zien dat voor het opvragen van de details van leveringen het mogelijk wordt gemaakt om deze in bulk op te kunnen vragen. Een soortgelijke manier als de paginering die bij de transacties toegepast kan worden zou bijvoorbeeld kunnen (misschien op basis van de volgorde zoals die bij levering opvragen terug komt).

Of dat je bijvoorbeeld via een POST request een array (van max x?) levering id’s kan opsturen om op te vragen.
Concluderend
Graag zou ik de volgende twee wijzigingsverzoeken willen inbrengen;

Meer query opties om het aantal zoekresultaten van query op transacties te kunnen beperken (de 3 c.q. 4 genoemde velden)

Betere performance c.q. snellere mechaniek om alle details van leveringen onder een project op te kunnen vragen

279

BM24 02 00153

Voor onze projecten maken wij veel gebruik van tijdreeksen van grondwaterstanden. Deze ontleenden we in het verleden aan het DINO-loket of werden door meetnetbeheerders direct aan ons verstrekt. Nu proberen wij de tijdreeksen aan de BRO te ontlenen. Daarbij lopen wij echter tegen het volgende aan:

1. Het format wijkt sterk af van wat tot nu toe voor ons gebruikelijk was. Gebruikelijk was een bestand met een aantal regels met metadata, zoals buisnummer, hoogte maaiveld t.o.v. NAP, diepte boven- en onderkant filter t.o.v. NAP, gevolgd door regels met datums/tijdstippen en waarnemingen. De bestanden die wij uit de BRO krijgen bevatten op meerdere plaatsen regels met metadata en daartussen elkaar overlappende tijdreeksen, dus met doublerende gegevens.

2. De bestanden bevatten informatie zonder toelichting, in het bijzonder over kwaliteitsstatus, waardoor niet duidelijk is of de grondwaterstanden definitief geschikt zijn voor het door ons beoogde gebruik.

3. Aan de tijden zijn twee uur toegevoegd, zonder nadere toelichting of de tijd met of zonder deze toevoeging UTC is.
Voor ons doel is DINO-format zoals gebruikelijk was en onder 1 is beschreven voldoende. Het huidige format van de BRO is alleen na veel interpretatie en handmatige bewerking toepasbaar, met alle risico van fouten. Wel zou de kolom met standen gevolgd kunnen worden door een kolom waarin staat of de stand gecensoreerd is of niet. Dit zou eenvoudig kunnen met “=”, “<” en “>”, afhankelijk van links- of rechtszijdige censorgrens.

278

BM24 02 00345

Als gemandateerd bronhouder wil ik bij de korrelgrootte verdeling zowel bij de “Standaard verdeling fractie 63tot2000um” als bij de “Uitgebreide verdeling fractie 63tot2000um” de “fractie 105tot210um” onder verdeelt hebben in “fractie 105tot150um” en “fractie 150tot210”

Zodat ik deze onderverdeling ook in kan brengen in de BRO aangezien we deze onderverdeling altijd in onze analyse aanwezig hebben.

277

BM24 02 00260

Het BRO programma heeft in November 2023 besloten om geen Bulkdownload ( geopackage) met alle grondwaterstanden (GLD) via PDOK ter beschikking te stellen; de omvang van de GLD dataset is daarvoor te groot;

Als ‘alternatief’ is een oplossing in de maak waarbij BRO gebruikers een Grondwatermonitoring-in-samenhang kenset kunnen gebruiken/opvragen, waarbij ze vervolgens in hun interessegebied per put/buis de daaraan gekoppelde Grondwaterstandsgegevens via de REST service kunnen opvragen; Deze generieke kenset oplossing zal worden geimplementeerd in BROloket/ PDOK service en REST service. Voorzien is dat deze functionaliteit in de loop van Q1-2024 beschikbaar komt.

Stantec heeft voor haar informatieproduct(en) echter wel de behoefte aan de landsdekkende, totale inhoud van grondwaterstandsgegevens uit de BRO in bulkdownload vorm. De usecase daarbij is dat voor hun informatieproduct landsdekkend afgeleide grondwaterkarakteristieken ( zoals actuele GxG’ s) worden berekend uit ‘ totale GLD gegevensset’ . Het informatieproduct wordt vervolgens op regionale of lokale schaal ingezet voor specifieke vraagstukken.

Voor de door Stantec uitgevoerde berekening van afgeleide grondwaterkarakteristieken is het echter niet nodig om in de dimensie ‘ tijd’, te beschikken over alle tijdmeetwaarde paren ( =de vaak toegepaste (en in de BRO geregistreerde) meetfrequentie van bijv. 24 standen per dag). Het beschikbaar komen van bijvoorbeeld een(1) stand 1 per dag volstaat voor hun berekening. Ook is het mogelijk niet nodig om bij lange meetreeksen te beschikken over de complete historische reeks. Daarmee neemt het benodigde gegevensvolume aanzienlijk af.

Voorgesteld wordt om te onderzoeken:

-of deze usecase bij meerdere stakeholders wordt toegepast (die verwachting is er wel);
- welke predefined selectie op GLD tijdmeetwaardeparen daarbij volstaat;
-of het legitiem is om deze gewenste bulk-uitgiftefunctionaliteit (waarbij er door ‘ predefined selectie’ een ‘subset’ aan GLD gegevens wordt uitgegeven) aan te bieden, naast/ bovenop de hierboven beschreven oplossing “kenset grondwatermonitoring in samenhang” , in de onderkenning dat deze functionaliteit afwijkt van het tot nu toe gehanteerde uitgangspunt dat er bij uitgifte geen extra ‘ waarde’ (zoals selectie) aan gegevens wordt toegevoegd.
-wat de haalbaarheid en impact van de gewenste bulk-uitgiftefunctionaliteit is.

276

BM24 02 00203

Hoe vaak verwacht het BRO programma / CAB Updates van Waardelijsten nodig
Zoals bijvoorbeeld toevoegen van waardes in het proces.

Zodat Prioritering beter bepaald kan worden voor bijvoorbeeld het updaten van GAR Hulpstoffenlijst

275

BM24 02 00174

Op basis van de huidige service voor ‘uitgifte van grondwater in samenhang’ kun je alleen resultaten opvragen o.b.v. de GMW BroId, zie:
https://publiek.broservices.nl/gm/v1/swagger-ui/#/default/gmw-relations

Net als in BROloket wil je echter ook de gegevens in samenhang kunnen opzoeken via de API op GLD, GAR en/of FRD BroId. Vanwege de data-hoeveelheden is met name de GLD-service zelf erg traag, dus voldoet niet goed voor dit doel. Alternatief dat ook zou voldoen is het toevoegen van de GMW BroId en buisnummer aan de observationsSummary, zie:
/gm/gld/v1/objects/{broId}/observationsSummary

274

BM24 02 00173

Er zijn afgelopen jaar behoorlijk wat verbeteringen aangebracht bij de fysische analyses van BHR-P en SFR. En we hebben dan nu ook bijna alles compleet om te kunnen leveren. Dank daarvoor.

Er is nog wel een punt boven gekomen als gevolg van het toevoegen van de mogelijkheid ‘onbekend’ voor de methode van de bepaling ‘Bepaling waterretentie stapsgewijs’. Als de methode onbekend is dan is het attribuut ‘Bepalingsmethode volumetrisch watergehalte’ ook onbekend. Het is nu zo dat dan het attribuut ‘Volumetrisch watergehalte’ niet aanwezig mag zijn. Maar dit is voor IMBRO/A gegevens wel aanwezig. Is dit aan te passen?