volledige teksten BRO wijzigingsverzoeken

volgnr.	meldingsnr.	volledige tekst wijzigingsverzoek

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	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’). image001.png 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) 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?
273	BM23 11 00050	Via Dinoloket kan ik GMW en GLD files downloaden als XML-files. Is het mogelijk om de levering van deze bestanden uit te breiden met een bestand waarin de relatie tussen de GWM filters en de GLD-codes wordt gegeven? Ik weet dan welk GLD-file ik moet inlezen om de reeks van een gegeven putfilter te krijgen. Bij de huidige uitlevering kan ik het verband tussen GLD-bestanden en GMW-bestanden alleen achterhalen door alle GLD-bestanden één voor één in te lezen en de GMWcode en filtercode op te zoeken. Dat is niet erg efficiënt. Via de REST-service is deze relatie wel op te vragen ('"gmw-relations"). Het zou handig zijn als de levering via bestanden een vergelijkbare tabel zou bevatten.
272	BM23 12 15761	Zoals de titel van de mail al aangeeft zou ik graag een wijzigingsverzoek willen indienen, om ervoor te zorgen dat de BROServices REST API /bro-ids endPoint(s) alleen BRO-IDs uitgeeft (van de aangegeven bronhouder) die niet uit registratie zijn genomen. Het is mij recent opgevallen dat deze endPoint alle BRO-IDs uitgeeft van de gevraagde bronhouder, onafhankelijk van het feit of deze uit registratie zijn genomen. Bijvoorbeeld, een GET request naar de URL https://publiek.broservices.nl/gm/gmw/v1/bro-ids?bronhouder=17274037 levert op dit moment als respons; Zoals te zien viel me dit nu op bij de BROServices REST API van GMW, maar dezelfde /bro-ids endPoint komt ook bij alle andere registratieobjecten voor, en ik neem aan dat de implementatie daar hetzelfde is. Het lijkt me derhalve handig om deze wijziging (bij inwilligen), bij alle registratieobjecten door te voeren. In plaats van in alle gevallen alleen BRO-IDs terug te geven die niet uit registratie zijn genomen, is het misschien ook wel elegant om dit optioneel te maken, bijvoorbeeld via een extra optionele (?) ‘query parameter’. Bijvoorbeeld een query parameter ‘uit_registratie_genomen’ waarvoor je dan de waarde ‘ja’ of ‘nee’ kan aangeven. M.a.w. dat je een GET request zou kunnen uitvoeren naar de volgende URLs;
271	BM23 11 00277	20231120_wijzigingsverzoek_bhrgt_waarde_bereiken.pdf
270	BM23 12 00011
269	BM23 11 00410	Wat betreft software / functioneel: Het organisatie- en mandatenregister (OMR) heeft al sinds de invoering van de BRO een aantal vereenvoudigingen doorgemaakt. Het kent “validatie rollen: producent, eigenaar, mijnbouworganisatie, bronhouder, dataleverancier etc”. De rollen: bronhouder / dataleverancier” hebben daarnaast ook toegang tot de inname / uitgifte via SOAP (client rollen register, CRR). Dit veranderverzoek gaat over het OMR. Op verzoek van BZK (2018) worden alle rollen toegekend aan alle gebruikers in het OMR. Op verzoek van de toenmalige ketenarchitect (2018/2019) worden de mandaten niet meer toegekend aan rollen. Dit wordt namelijk in het bronhouderportaal afgedwongen door machtigingen. De huidige situatie leid tot onnodig veel complexiteit en beheer. Bijvoorbeeld: op dit moment wordt de registerbeheerapplicatie her-ontwikkeld. De registerbeheerder moet zo dadelijk voor elke partijen, individueel elke rol voor elk registratie-object toekennen. Voorstel: Beperk de systematiek alleen tot rollen en niet per registratie-object. Impact: services, registerbeheer, database, catalogus?
268	BM23 11 00321	Wij hebben hier een Triaxiaal test welke water uitperst maar ook opneemt. Het opgenomen volume van deze test is meer dan de toegestane maximum van 5. Het aangegeven waardebereik staat op -5 tot 70. Hierbij is het niet geheel duidelijk beschreven of bij deze test uitpersen negatief dan wel positief gezien wordt. Aangenomen is dat opnemen negatief is en uitpersen een positieve waarde. Kun u dit bevestigen. Voor wat betreft het waardebereik. Op dit moment kunnen we de genoemde test niet aanleveren, de test komt niet door de validatie heen vanwege het gestelde waardebereik. Is het mogelijk dit waardebereik aan te passen zodat deze en toekomstige testen wel door de validatie heen komen.
267	BM23 11 00354	Daarnaast heb ik de volgende vraag: Waarom kan ik geen meetwaarden aanleveren als een object in onderzoek is? Dat is niet handig. De hele levering 848 stukjes meetwaarden worden niet geaccepteerd als het ene object in onderzoek is!!! Dat is iets waar ik eigenlijk wel vanaf wil! Als Bronhouder wil meetwaarden aanleveren als een object in onderzoek is. Zodat leveringen kunnen door blijven lopen en ik geen handmatige acties hoe uit te voeren. Bij automatische bulk aanleveringen.
266	BM23 10 00511	In ‘Details van de levering’ zijn ‘Labels’ en ‘Externe referentie leverancier’ aan te passen. Ik ben erg geholpen met de mogelijkheid om deze 2 attributen in 1 keer te kunnen invullen per project
265	BM23 11 00404	De indicatie “onder voorrecht” wordt alleen bij GMW gebruikt. Het doel was om de controle op met name begin- en einddatum bij een put dmv een database veld en dmv een (optionele) indicatie in de transactiegegevens af te zwakken. Hiermee werd het mogelijk om ook de datumformaten: onbekend, JJJJ en JJJJ-MM voor deze gegevens te gebruiken. BZK heeft besloten (reeds enige tijd geleden) dit recht aan eenieder toe te kennen. Daarmee is het nut (uit kunnen zetten) verdwenen. Het veld levert (nog steeds) de nodige verwarring op en heeft de nodige verwarring opgeleverd. Voorstel: Verwijder de indicatie “onder voorrecht” en de daarmee samenhangende attributen “met voorgeschiedenis” uit de documentatie van GMW. De indicatie is onderdeel van de transactiegegevens, en is daarmee aanwezig in de uitwisseling van alle registratieobjecten. Het voorstel hier is om deze indicatie te negeren (mits verzonden in de transactiegegevens). Merk op: als we dit weghalen uit de transactiegegevens, dan moet iedere dataleverancier aanpassingen maken. Laat dit samenhangen met de GMW update. We kunnen er nu bijvoorbeeld voor kiezen om alleen maar volledige datums voor start- en eind te accepteren (de-facto voor eenieder de ‘onder voorrecht periode’ voorbij).
264	BM23 11 00256	Als bronhouder kun je geen overzicht van projecten opvragen via de volgende BHP API endpoint: https://www.bronhouderportaal-bro.nl/api/v2/ontvangen-machtigingen Dit omdat bronhouders zichzelf niet kunnen machtigen. Het opvragen van een overzicht van projecten is om verschillende redenen echter wel nodig of iig nuttig voor grotere bronhouders zoals RWS, die veel projecten hebben. Ik dien n.a.v. het overleg dan ook graag formeel het volgende RFC-verzoek in, in de vorm van de volgende User Story: Als bronhouder wil ik een overzicht van al mijn projecten op kunnen vragen via de BHP API. In ons overleg hebben we ook verschillende oplossingen daarvoor besproken, incl. de vraag of het dan ook nuttig kan zijn om van ieder project een overzicht te krijgen van de machtigingen daarop. Dat laatste lijkt zo snel geen noodzaak, ik zie iig zo snel geen concrete toepassing daarvoor. Een mogelijk eenvoudige oplossing is om deze RFC te implementeren in de vorm van het tot nu toe door mij verwachtte gedrag, namelijk dat je via BHP API endpoint: https://www.bronhouderportaal-bro.nl/api/v2/ontvangen-machtigingen eenvoudigweg de lijst krijgt van alle projecten die je als bronhouder hebt (met bijv. als machtigingstype ‘bronhouder’ o.i.d.) Met dank tot zo ver maar weer! We zien uit naar jullie reactie dan wel die van de CAB...
263	BM23 11 00189	Voorstel om naast de grootte van het zip-bestand ook de grootte van het uitgepakte zip-bestand te vermelden op de bestelpagina van BROloket.
262	BM23 10 00507	In tabblad 'Bekijken' graag bij zowel 'Registratieobjecten' en 'Transacties' het project 'ID/kenmerk' en 'Kolommen selecteren'. Ook graag onder 'Transacties' de mogelijkheid om te kunnen filteren op 'Objecttype', zoals al kan in 'Registratieobjecten'. Ook onder 'Transacties' kunnen filteren op ‘Levering-ID’ is wenselijk
261	BM23 10 00507	In tabblad 'Bekijken' graag bij zowel 'Registratieobjecten' en 'Transacties' het project 'ID/kenmerk' en 'Kolommen selecteren'. Ook graag onder 'Transacties' de mogelijkheid om te kunnen filteren op 'Objecttype', zoals al kan in 'Registratieobjecten'. Ook onder 'Transacties' kunnen filteren op ‘Levering-ID’ is wenselijk
260	BM23 11 00050	Via Dinoloket kan ik GMW en GLD files downloaden als XML-files. Is het mogelijk om de levering van deze bestanden uit te breiden met een bestand waarin de relatie tussen de GWM filters en de GLD-codes wordt gegeven? Ik weet dan welk GLD-file ik moet inlezen om de reeks van een gegeven putfilter te krijgen. Bij de huidige uitlevering kan ik het verband tussen GLD-bestanden en GMW-bestanden alleen achterhalen door alle GLD-bestanden één voor één in te lezen en de GMWcode en filtercode op te zoeken. Dat is niet erg efficiënt. Via de REST-service is deze relatie wel op te vragen ('"gmw-relations"). Het zou handig zijn als de levering via bestanden een vergelijkbare tabel zou bevatten.
259	BM23 11 00018	Als de gebruikers op het BROloket de detail info willen ophalen van een GUF of GPD krijgen zij een email met een link naar XML bestanden. Dit si voor de gemiddelde gebruiker niet leesbaar zou dit ook weer kunnen gepresenteerd als XLS bestand(was iin het verleden ook zo) en graag alles wat er opgevraagd wordt in 1 bestand? Nu worden het ook allemaal losse XML bestanden dus graag alle detailinfo in 1 XLS bestand(van bv 100 GUF’s en 10 GPD’s) Is dit mogelijk om dit weer aan te bieden voor de gebruikers naast de XML bestanden?
258	BM23 10 00509	Mogelijkheid om onder tabblad ‘Aanleveren’ onder ‘Projectgegevens‘ ook “Object-ID Bronhouder” te tonen, én het ook mogelijk te maken om deze na een aanlevering aan te kunnen passen door de bronhouder
257	BM23 10 00508	De tijdsduur van automatisch uitloggen uit het BHP (waarna je dus weer opnieuw moet inloggen) graag verlengen! Moet nu om de haverklap opnieuw inloggen. Het uitloggen gebeurt zelfs wanneer je in het BHP aan het werken bent, zou niet moeten
256	BM23 10 00198	Als dataleverancier wil ik ook kunnen zien voor welke projecten leveringen nog niet zijn doorgeleverd door de bronhouder. Zodat ik erop kan toezien dat leveringen worden afgerond voordat ze voorlopen.
255	BM23 09 00370	wij lopen tegen het probleem aan dat complexe geotechnische laboratoriumproeven in leveringen aan de BRO niet controleerbaar zijn en daardoor blijven openstaan na levering. Hier hebben we eerder contact overgehad. We zijn op zoek naar een praktische oplossing. Een van de opties die we overwegen is het leveren van separate bestanden met: - veldbeschrijving - laboratoriumbeschrijving - eenvoudige proeven - triaxiaal proeven - DSS proeven - samendrukkingsproeven - enz. Zo kunnen we de onderdelen die controleerbaar zijn in ieder geval goedkeuren en accorderen en hoeven er geen complete boringbestanden open te blijven staan omdat een onderdeel (proef) niet te controleren is. Is dit mogelijk binnen het huidige BRO-databasemodel? De beperkte visualisatiemogelijkheden en ruwe data in de XML zijn inderdaad het probleem. Nu wordt van een boring één beschrijving gevisualiseerd. Als er een veldbeschrijving en een labbeschrijving zijn, dan is maar een van beiden te zien. Eenvoudige en complexe laboratoriumproeven worden helemaal niet gevisualiseerd. Omdat we de proeven in de bestanden niet kunnen inzien, kunnen de complete (bestanden niet goedgekeurd of geaccordeerd worden. Dit betekent dat ook de delen die wél gecontroleerd kunnen worden niet in BRO terecht komen. We kunnen namelijk alleen complete bestanden goedkeuren of afkeuren.
254	BM23 09 00362	Graag NEN-EN-ISO 17892-7 (UCS) opnenen als proef in BHR-GT
253	BM23 09 00361	NEN-ISO 13320:2009 geïmplementeerd in BHR-GT terwijl de 2020 reeds een paar jaar beschikbaar is. Graag deze tevens opnemen in de waardenlijst.
252	BM23 09 00360	Je bericht: NEN-EN-ISO 17982-6 is de nieuwe standaard voor consistentiegrenzen. Graag deze spoedig opnemen in de BRO BHR-GT

251	BM23 08 00472	In de tekst wordt voor de doorlatendheid van zwelklei meermaals aangegeven: "een doorlatendheid die kleiner is dan 10 - 9 m/s". Maar dat kan niet kloppen, want dat is een doorlatendheid die hoort bij zeer grof zand of fijn grind 😉 Zie ook: doorlatendheid grondsoorten (grondwaterformules.nl). Waarschijnlijk wordt er een doorlatendheid bedoeld van 10-9 m/s wat overeenkomt met ongeveer 0.9 mm/d! Ik vermoed dat dit het gevolg is van een (te) snelle knip-plak actie. Er staat namelijk ook aangegeven dat de doorlatendheid een waardebereik heeft van 1x10-12 tot 5x10-4. Daaruit blijkt dus al dat de aangegeven waarde 10-9 m/s niet kan kloppen. Excuus. Ik zie dat het getal in mijn mail helaas ook automatisch was veranderd naar 10-9. Wat ik bedoel is dat de tekst zou moeten worden veranderd naar: "een doorlatendheid die kleiner is dan 10^- 9 m/s". Het probleem is namelijk dat veel mensen "*10-9 m/s*" zullen interpreteren als een getal tussen 10 en 9 m/s. Terwijl er dus een veel kleiner getal wordt bedoeld, namelijk 10^-9 m/s (= 0,000000001).
250	BM23 08 00564	CPT norm. Verzoek in waardenlijst sondeernorm het publicatiejaar van een norm vermelden. De Europese (NEN-EN-ISO) normen blijven qua aanduiding gelijk maar evalueren. In de nieuwe norm zijn de klassegrenzen aangepast en is er een veld voor test categorie toegevoegd. De huidige norm is NEN-EN-ISO 22467-1:2023 en. Graag de omschrijving NEN-EN-ISO 22467 deel 1 aanpassen naar NEN-EN-ISO 22476-1:2012 en, NEN-EN-ISO 22476-1:2012/C1:2013 en
249	BM23 08 00491	Voor het registratiebeheer van de BRO is het wenselijk dat er tooling komt om maaiveldhoogtes te kunnen controleren aan de hand van het Actueel Hoogtebestand Nederland. Als output zit ik te denken aan o.a.: - BRO-ID - maaiveld van het object in de BRO - NAP hoogte volgens het AHN op dezelfde locatie - Afwijking tussen maaiveld BRO en AHN - Bronhouder - Dataleverancier
248	BM23 08 00303	Verzoek verruimen QM klassen voor geotechnisch laboratoriumonderzoek voor opname proefresultaten in de BRO. Reden: In principe kunnen ook monsters van een lagere kwaliteit beproeft worden (vibrocores) dus een beperking in QM klasse bij opname laboratoriumresultaten is ongewenst. Het is de verantwoordelijkheid van de adviseur om de data te interpreteren.
247	BM23 07 00260	Op het Bronhouderportaal hebben wij de rol dataleverancier. Dit wordt per 1-1-2024 bronhouder. Kunnen wij de rol van bronhouder krijgen in het Bronhouderportaal, zodat we projecten aan kunnen maken?
246	BM23 07 00011	Naar aanleiding van de technische BRO sessie van 29 juni j.l. dien ik namens WS Aa en Maas, WS De Dommel en WS Brabantse Delta een wijzigingsverzoek in op de GMN standaard. Hun behoefte is om het voor een bronhouder mogelijk te maken om ‘ tijdens’ de levensduur van een GLD van een andere bronhouder dit GLD ‘ op te nemen’ in een eigen GMN (daarmee en dus ook de betreffende GMW buisverwijzing als GMN meetpunt op te nemen in het eigen GMN), zonder daar die bronhouder van dat GLD mee ‘ te hoeven belasten’. Tijdens de technische sessie is geconcludeerd dat een verdere verkenning/haalbaarheidsanalyse /impactanalyse hierover zinvol is op het moment dat de huidige, tijdelijke werkafspraken GLD en GAR mbt de ‘ optionele relatie met GMN ‘ geëvalueerd gaan worden met het werkveld.
245	BM23 07 00159	In sommige BRO-registraties blijkt dat er partijen zijn die het GMW inrichtings-voorbeeldbericht als template hebben gebruikt, waarbij ze vergeten zijn om het kvk nr van het attribuut puteigenaar aan te passen, waardoor dit nu verkeerd in de BRO staat. Het is mogelijk dat door het gebruik van het voorbeeldbericht als template meer gegevens verkeerd in de BRO terechtkomen. De voorbeeldberichten waren oorspronkelijk bedoeld waren om slechts’ te dienen als testberichten om de software van leveranciers te testen. N.a.v. van deze geconstateerde ontwikkeling wordt voorgesteld om ‘BRO breed’ alle voorbeeldberichten te gaan aanpassen door de attributen te gaan ‘parametriseren’, waardoor alle inhoud ervan expliciet moet worden aangepast door leveranciers/bronhouders als ze de berichten als template gebruiken.
244	BM23 06 00380	We hebben een vraag over het waardebereik van het attribuut “vervormingssnelheid” van de entiteit “Belastingfase”. De catalogus zegt: Eenheid mm/uur Waardebereik vanaf 0 Meetwaarde 1.4, en dat betekent max 9.999 Voor CU-tests (consolidated, undrained) en CD-tests (consolidated, drained) geldt dat de vervormingssnelheid inderdaad onder de 10mm per uur blijft. Bij UU-tests (unconsolidated, undrained) hebben we echter vervormingssnelheden die groter zijn dan 10mm/uur. En die waarden worden door de validatieservice niet goedgekeurd. Het komt erop neer dat wij onze UU-tests op dit moment niet kunnen leveren.
243	BM23 07 00104	Het ‘controleren’ van leveringen is een van de typen machtigingen die je als bronhouder kunt geven en delegeren aan derden Zowel in de user interface van het bronhouderportaal als bij het opvragen van de machtigingen via de nieuwe API versie 2 komt dat terug. Het uitvoeren van die controle op leveringen (goed- of afkeuren) kan zoals het is echter niet via de API, zie https://www.bronhouderportaal-bro.nl/doc/api.html#tag/Leveringen, terwijl zowel RWS als anderen bezig zijn met het (laten) ontwikkelen van eigen controle-tooling en controleregels, en die geautomatiseerd zouden willen toepassen op leveringen. - We dienen bij deze dan ook graag bij jullie het verzoek in (in de vorm van een RFC) om ook deze mogelijkheid in de nieuwe versie 2 van de bronhouderportaal API op te nemen.
242	BM23 07 00096	Voor de bepaling korrelgrootteverdeling in de registratieobjecten SFR en BHR-P is de omschrijving niet helemaal helder. In de catalogus staat op dit moment: - BHR-P 4.2.12, SFR 4.2.17, ”Bepaling van de korrelgrootteverdeling”, laatste zin van de eerste paragraaf: “De metingen worden altijd omgerekend naar een percentage van de totale massa tot 2 millimeter.” - BHR-P 6.3.33, SFR 6.3.32, “Bepaling korrelgrootteverdeling”, een-na-laatste zin van de toelichting: “De droge massa van iedere fractie wordt bepaald en het resultaat wordt omgerekend naar een percentage van de totale massa van alle deeltjes kleiner dan 2 millimeter.” De omschrijvingen maken nog niet expliciet duidelijk dat het gaat om het percentage van de totale massa van de granulaire delen <2mm. Dit moet eigenlijk expliciet vermeld worden. Om veel discussies en vragen te voorkomen is ons voorstel om de omschrijvingen te veranderen naar respectievelijk: - BHR-P 4.2.12, SFR 4.2.17, ”Bepaling van de korrelgrootteverdeling”, laatste zin van de eerste paragraaf: “De metingen worden altijd omgerekend naar een percentage van de totale granulaire massa van alle deeltjes kleiner dan 2 millimeter. De vooraf verwijderde organische stof, carbonaten en delen >2mm worden hierin dus niet meegenomen.” - BHR-P 6.3.33, SFR 6.3.32, “Bepaling korrelgrootteverdeling”, een-na-laatste zin van de toelichting: “De droge massa van iedere granulaire fractie wordt bepaald en het resultaat wordt omgerekend naar een percentage van de totale granulaire massa van alle deeltjes kleiner dan 2 millimeter. De vooraf verwijderde organische stof, carbonaten en delen >2mm worden hierin dus niet meegenomen.” In BHR-P 4.2.12 mist overigens ook een haakje achter dispersie.
241	BM23 06 00176	Volgens https://docs.geostandaarden.nl/bro/def-im-BHR-GT-20220901/#global_class_Model_Bepalingmaximaleongedraineerdeschuifsterkte kunnen we zowel een Pocket penetro als Torvane test op hetzelfde interval in de XML invoeren: "Normaliter wordt 1 bepaling per onderzocht interval uitgevoerd. Bij wijze van uitzondering kunnen 2 bepalingen 'naast elkaar' worden uitgevoerd. De schuifsterkte wordt dan op verschillende manieren bepaald" Ik vraag me alleen af hoe we dit correct in de XML kunnen zetten voor de BRO. In bijgevoegde XML hebben we twee maximumUndrainedShearStrengthDetermination in één interval (vanaf regel 1193) maar dit geeft een foutmelding op het demo bronhouderportaal.
240	BM23 07 00030	Constatering van LV-BRO (Jan Willem): Bij BHR-GT Grond.grondsoort NEN5104 staat de volgende regel: Het attribuut mag niet aanwezig zijn wanneer de waarde van het attribuut beschrijfprocedure van de entiteit Boormonsterbeschrijving niet gelijk is aan NEN5104Synthetisch en dat is onder IMBRO altijd het geval. Dit laat de mogelijkheid open om grondsoort NEN5104 weg te laten bij beschrijfprocedure = NEN5104Synthetisch, en dat is natuurlijk niet de bedoeling.
239	BM23 07 00029	BHR-GT: in omschrijving waarde ISO17892d12v2018 jaartal toevoegen Bevinding vanuit BRO Standaarden in de omschrijving van de waarde ISO17892d12v2018 waarde van Bepalingsprocedure ontbreekt het jaartal. In een volgende versie jaartal in omschrijving toevoegen en omschrijving updaten in de LV-BRO (en refservice). Verder geen impact (en geen verandering van betekenis)
238	BM23 07 00028	Bevinding vanuit BRO Standaarden in BHR-G en BHR-GT catalogi. BHR-GT en BHR-G: fout in naam waarde: ISO14688d2v2019NEN8990v2020 moet zijn ISO14688d2v2019NEN8991v2020 ISO14688d2v2019NEN8990v2020 waarde van Bepalingsprocedure moet zijn ISO14688d2v2019NEN8991v2020 van toepassing op BHR-G en BHR-GT
237	BM23 07 00027	We hebben een bevinding vanuit BRO Standaarden voor de BHR-G en BHR-GT catalogi: scheuzeria moet eigenlijk zijn scheuchzeria Bij BHR-G als SoortVeen = scheuchzeriaveen (= goed) SoortPlantenrest = scheuzeria (= fout) -> wordt aangepast naar scheuchzeria (in versie 2.99) Bij BHR-GT Veensoort = scheuzeriaveen (= fout) aanpassen waarde kan niet meer (is niet backwards compatible) komt niet voor bij SFR, BHR-P en BHR-AG
236	BM23 06 00394	- De huidige versie 1 van de bronhouderportaal API biedt de mogelijkheid om via de verrijkingsoptie, bestanden mee te geven, op te laten nemen en op te laten slaan op de bronhouderportaal-server zelf. Dergelijke verrijking is niet mogelijk voor leveringen die zijn doorgeleverd (omdat ze bijv. automatisch worden doorgeleverd), de verrijkingsinformatie vervalt daarnaast ook logischerwijze bij het opruimen van BHP-projecten. De verrijkingsoptie is in beginsel een route die verschillende organisaties in staat stelt om ‘meta-, bron- en/of QC-gegevens’ over leveringen uit te wisselen met elkaar, maar die route is vanwege de genoemde beperking niet generiek en niet bruikbaar in het grondwaterdomein waar leveringen doorgaans automatisch worden doorgeleverd vanwege de hoge frequentie daarvan. - In het overleg is een alternatieve vorm van verrijking besproken, die wel generiek bruikbaar lijkt, namelijk het kunnen meegeven en opnemen van een URL in bronhouderportaal API Versie 2 bij transacties en (naar zo snel lijkt tenminste ook) in het transactieregister. Het opslaan van een URL heeft beperkte impact qua dataopslag, en lijkt wel generiek bruikbaar om dat ze kan verwijzen naar verrijkingsinformatie op een server bij bronhouders en/of hun leveranciers, maar ook meer algemeen naar ‘meta-, bron- en/of QC-gegevens’ of ook een bronhouders- of leveranciersapplicatie of API. We dienen bij deze dan ook graag (in de vorm van een RFC) het verzoek in om deze mogelijkheid in de nieuwe versie 2 van de bronhouderportaal API op te nemen.
235	BM23 06 00392	- In de huidige versie 1 van de bronhouderportaal API hebben tokens die een bronhouder aanmaakt waarmee je leveringen kunt opvragen, en de tokens waarmee je leveringen kunt verrijken, rechten voor de bronhouder als geheel, d.w.z. dat ze gelden voor alle projecten. Dat dat voor de verrijkingsoptie zo is, was bij sommigen bekend. Dat dat ook het geval is voor het opvragen van leveringen was een verrassing, waar we bij provincie Gelderland toevallig achter kwamen (zie bijlage, en gelieve deze gegevens te beschouwen als onder embargo, omdat het gegevens van Gelderland zijn). - In de nieuwe versie 2 van de bronhouderportaal API is deze mogelijkheid er nog niet. We dienen bij deze dan ook graag (in de vorm van een RFC) het verzoek in om de mogelijkheid om leveringen op te vragen en te verrijken voor alle projecten van een bronhouder tegelijk, ook in de nieuwe versie 2 van de bronhouderportaal API op te nemen.
234	BM23 06 00265	Kan de zoekfunctie in het BHP onder 'zoeken in' uitgebreid worden met het zoeken binnen het attribuut "Object-ID Bronhouder". Via dit veld knoopt RWS de projecten in het BHP aan de eigen administratie, en door in "Object-ID Bronhouder" te kunnen zoeken kunnen we efficienter werken. ps. was het voorheen ook verplicht om 'zoeken in' in te vullen of is dat een nieuwe vereiste?
233	BM23 06 00233	Nav de bijeenkomst ‘ SIKB Bijeenkomst Platform Bronbemalen ‘Grondwatergebruiksystemen in de BRO’ van 16 juni j.l. breng ik ‘namens diverse deelnemers’ het volgende wijzigingsverzoek in: In de huidige BROLoket functionaliteit ‘ tonen kengegevens’ op de tabbladen’ wordt een beperkt aantal GUF kengegevens getoond. Het is wenselijk om dit uit te breiden met ‘ verder met het werkveld te verkennen ( lees ‘ workshop’) ’ andere (ken)gegevens zoals (vergunde) maximale waterverplaatsing. Gebruikers hebben met de huidige BROLoket functionaliteit (onterecht, maar wel voorstelbaar) het idee dat er van een object slechts een ‘zeer beperkte gegevensset ‘ in de BRO is gekomen, en vragen zich dan af of ‘ het aanleverproces wel werkt’. Het is daarmee ook wenselijk om bij de tabbladen een opmerking/disclainmer te plaatsen die de gebruiker wijst op het feit dat ‘ de weergave op het tabblad slechts een deel van de in de BRO aanwezige gegevens betreft.
232	BM23 05 00341 - BM23 06 00090	In de catalogus van BHR-P, zoals gepubliceerd op https://docs.geostandaarden.nl/bro/sfr/#detail_attribute_Model_Bepalingorganischestofgehalte_lutumcorrectietoegepast. Staan 2 fouten. 1. Bij "6.3.40.4 lutumcorrectie toegepast" staat de verkeerde informatie. De juiste informatie is te vinden bij SFR: 6.3.41.4 lutumcorrectie toegepast 2. Bij "6.3.41.2 bepalingsmethode" ontbreekt de methode "natOxiderenH2O2" bij de IMBRO/A regel. Die moet worden toegevoegd.
231	BM23 06 00011	In de GMM zit momenteel een verschil tussen GML en GPKG voor 5.10 uit de catalogus van de Geomorfologische Kaart. Hier is een enumeratie van slechts twee waarden: AHN en Topografische hoogtelijnenkaart. FileNameType fileNameType = FileNameType.TOPOGRAFISCHE_HOOGTELIJNENKAART; fileType.setVersion("1.0"); Bovenstaande code wordt gebruikt voor GML en heeft voor alle vlakken dezelfde waarden. In de GPKG wordt de tekst overgenomen uit de brondata. Door de toevoeging van de dijken en wateren van geomorfologisch belang en hun bronnen worden er meer waarden gebruikt dan alleen het AHN en de Topografische hoogtelijnenkaart. Daarnaast wordt er onderscheid gemaakt in de versies van het AHN en de nieuwe bronbestanden. Om te zorgen dat de GML en GPKG weer overeenkomen is er actie vereist waarbij Yke drie verschillende opties ziet: - Het blijft een enumeratie en wordt uitgebreid bij nieuwe bronnen, niet handig als er een nieuwe versie of type bij komt. - Codelijst: praktisch kunnen we dan types invullen die nog niet in de codelijst staan, maar dit is minder netjes. - Vrije tekst veld: Dan zijn we zelf verantwoordelijk dat het begrijpelijke data is. Onszelf lijkt de codelijst hier de beste oplossing, maar we zijn benieuwd hoe jullie hier over denken en wat mogelijk is. Deze issue hoeft overigens niet de levering van 30-6-2023 in de weg te zitten omdat we net als de huidige versie de tekst uit de brondata kunnen overnemen voor de GPKG en de GML nu even te laten voor wat het is. Dit is echter wel iets wat aangepakt moet worden richting te toekomst als we de modellen niet meer as-is willen leveren.
230	BM23 06 00113	Als servicedeskmedewerker dien ik naar aanleiding van veelgestelde vragen dit wijzigingsverzoek in: Als dataleverancier in het Bronhouderportaal Wil ik kunnen zien welke collega's nog meer toegang hebben tot het Bronhouderportaal Zodat ik weet welke collega's actief zijn Als inzichtelijk is wie dat zijn, dan hoef je als dataleverancier geen contact meer met de servicedesk op te nemen: - Als er iets gewijzigd is in het BHP, maar je niet weet wie dat gedaan zou kunnen hebben - Als je collega's zoekt die al ervaring hebben met het BHP
229	BM23 05 00435	Vanuit 2 richtingen is de behoefte geuit voor een ‘ handreiking/handleiding gebruik van BRO geopackages/atomfeeds’ -PDOK Geoforum: uitleg over hoe GAR geopackage te gebruiken ( want in GAR zelf zit geen geometrie; er is een koppeling met GMW geopackage nodig) -BRO regioronde zuid: men snapt de inhoud van een geopackage niet (waarin de gehele inhoud van een RO zit, ingedeeld volgens domeinmodel) en al helemaal niet hoe die in een GIS systeem te gebruiken. Daarom is de wens om de huidige informatievoorziening hierover ( par 5.3.5 van Handreiking Afname BRO Gegevens (bro-productomgeving.nl)) uit te breiden met een uitgebreide handleiding, voorzien van een aantal praktijk gebruiks voorbeelden ( in een GIS).
228	BM23 05 00401	Is het mogelijk om ‘ iedere nacht de totale inhoud van de BRO productieomgeving ( BHP en LVBRO) te ‘ kopieren’ naar de TEST/DEMO-omgeving, zodat Bronhouders en of Dataleveranciers correcties en aanvullingen daar kunnen testen, waarbij ze de ’in hun eigen systemen bekende’ BHP projectnamen en leveringsIDs etc. en de BRO-IDs van betreffende registratieobjecten uit de BRO productieomgeving kunnen gebruiken.
227	BM23 05 00225	Beste BRO servicedesk, Naar aanleiding van het BRO softwareplein (do 11 mei) dien ik een feature verzoek in. Zie de beschrijving / visualisaties hieronder. Mocht er aanvullende informatie nodig zijn, hoor ik dat graag. PDOK -wens In onze applicatie (Delft-FEWS) visualiseren wij de PDOK Kaart als WMS kaartlaag die we vervolgens gebruiken om een locatie te bevragen op GLDs Wat automatisch al werkt is dat de GetFeatureInfo al een behoorlijke lijst aan interessante metadata oplevert, zie hieronder. Die wordt vervolgens getoond als tooltip Het karakter van deze metadata is niet overal even goed interpreteerbaar daar waar het KvK gegevens betreft. De getallen die bij Bronhouder en Eigenaar staan zijn KvK nummers. Op het BRO loket zijn die nummers al wel vertaald naar een naam van een Bronhouder (zoals bv een waterschap of provincie). Is zoiets ook mogelijk te maken voor de PDOK kaartlaag?
226	BM23 05 00008	Reeds vele jaren maak ik gebruik van de 'DINO WebService - Excel add-in', om onder andere tabellen te creëren met de REGIS-bodemopbouw. Sinds enkele jaren wordt deze tool volgens mij niet meer formeel door jullie ondersteund. Vorig jaar hebben we een gesprek gehad met jullie productmanager Hans van der Ven, waaruit volgde dat bij hem bekend was dat er nog steeds vraag naar deze tooling is. Die vraag herken ik vanuit onze eigen organisatie. De wens om de tool weer in de lucht te brengen hebben we ook bij Hans aangegeven. Omdat jullie de tool momenteel niet meer formeel ondersteunen, heeft onze IT-afdeling ook besloten de tool niet meer te installeren voor haar werknemers. Dus ik ben zelfs huiverig dat mijn laptop-op-leeftijd een keer de geest geeft en ik de tool ook niet meer heb. Ook krijg ik nu wel eens vragen van collega's (die de tool niet hebben) om even een REGIS-profiel te maken met behulp van de tool. Concreet, gezien de meerwaarde van de tool (handig, snel, overzichtelijk, gestructureerd), verneem ik graag of en wanneer deze tooling weer beschikbaar wordt gesteld en wordt ondersteund? We zouden er graag weer gebruik van willen maken. De appelboor-functionaliteit in de huidige DINO/BRO-viewer is daarvoor niet afdoende, omdat deze met (te grote) bandbreedtes werkt en geen snel volledig overzicht geeft van alle beschikbare parameters.
225	BM23 05 00216	Vorm doorlatendheidscurve *Foutmelding* BoreholeResearch.boreholeSampleAnalysis.investigatedInterval.hydrophysicalCharacteristicsModelling.hydraulicConductivityCharacteristic.hydraulicConductivityCurve.shapefactorLambda} = 16.50530 waarde heeft geen correct formaat: moet zijn Getalswaarde(1.5). *Toelichting* De vormfactor lambda heeft een waarde groter dan 10 voor een aantal analyses. In het algemeen ligt de waarde tussen -20 en 20. Eenzelfde iets geldt voor de vormfactor n. Die is in onze huidige analyses kleiner dan 10, maar kan ook groter zijn. *Verzoek aan BRO* De bodemfysische gegevens zijn voor veel partijen van belang, zoals ook aangegeven vanuit de Stuurgroep Regionale en Landelijke Modelinstrumentaria (RLMI). Op dit moment blokkeert dit issue onze leveringen van de bodemfysische gegevens. Ons voorstel is om het domein van de vormfactor lambda en van de vormfactor n te wijzigen van Meetwaarde 1.5 naar Meetwaarde 2.5.
224	BM23 05 00125	Mede op verzoek van Marjan Bevelander (BZK) en Sander Dijkstra (prov. Overijssel) wil ik graag een wijzigingsverzoek indienen voor de BRO, waarmee het mogelijk wordt om ook hydrologisch belangrijke peilbuizen buiten de landsgrenzen op te nemen in de BRO. Terreinbeheerders, delfstoffenwinners, provincies (en mogelijk ook waterschappen) hebben nu op diverse locaties (net) over de grens peilbuizen geplaatst. De reden daarvoor is dat deze buizen belangrijke informatie geven over de grenshydrologie en de kansen en bedreigingen voor de hydrologie in Nederland. Om te kunnen voldoen aan het Nederlandse beleidsprincipe om water en bodem sturend te maken voor ruimtelijke plannen, zijn deze buitenlandse peilbuizen ook onmisbaar. Het verkrijgen van deze informatie kost momenteel veel extra moeite, omdat ze in allerlei verschillende datasystemen (en in verschillende formaten en met wisselende kwaliteit) zijn opgeslagen. Dat is met opname in de BRO te voorkomen. Ook in verband met delfstoffenwinning zijn er wederzijdse meetverplichtingen met de buurlanden. Zo staan er peilbuizen van zandwinner Combi-Dooze uit Kloosterhaar in Duitsland en levert Natuurmonumenten metingen van peilbuizen uit het IJzeren bos (nabij Susteren) aan LANUV in NordRheinWestfalen tbv de monitoring van de bruinkoolwinning aldaar. Daarnaast strekken natuurgebieden zich uit over de landsgrenzen heen (Aamsveen, Plateaux) en wordt er ook aan weerszijden van de grens 'voor elkaar' gemeten. Het betreft hier ook N2000 gebieden met 'Europese (meet)verplichtingen'.
223	BM23 05 00034	Als admin van het Bronhouder portaal. Wil ik leveringen die Status LV onbereikbaar kunnen doorleveren per project en niet met een beperking van 20 leveringen.
222	BM23 04 00352	Als gebruiker met een e-mailaccount Wil ik in de activatiemail zien dat de link maar 48 uur geldig is Zodat ik begrijp waarom de link niet meer werkt Tekstsuggestie: Let op: deze activatielink is 48 uur geldig. Is de link verlopen? Vraag dan een nieuwe link aan via de optie 'wachtwoord vergeten' op het Bronhouderportaal. (met een hyperlink naar de juiste omgeving van het Bronhouderportaal)
221	BM23 04 00170	De warme en koude ingebrachte volumereeksen hebben dezelfde kleur op het BROloket. Dit is verwarrend. Zou het visueel duidelijk gemaakt kunnen worden dat het om 2 verschillende type volumereeksen gaat? Zie bijvoorbeeld deze afbeelding.
220	BM23 03 00059	Wijzigingsverzoek: als dataleverancier wil ik niet-geaccordeerde leveringen kunnen verwijderen (nu kan alleen de bronhouder dat).
219	BM23 03 00567	Als dataleverancier in het Bronhouderportaal Wil ik in de notificatiemail zien van welk project de notificatie afkomstig is
218	BM23 03 00263	Omdat TNO de enige partij is die kan controleren of een ingevuld NITG-putnummer ook in DINO stond zou ik willen voorstellen om bij het testen van de validiteit van een XML-putbericht ook daarop direct inhoudelijk te toetsen. En niet alleen syntactisch. TNO is eigenlijk een soort bronhouder voor het voormalige DINO GQN. En als je achteraf dit soort fouten uit de aangeleverde BRO gegevens kunt halen, moet dat natuurlijk ook vooraf kunnen. Dat is wél zo prettig voor een gegevensleverancier (en de bronhouder).
217	BM23 03 00261	Wilt u in csv of andere bestanden de KOMMA als decimaal teken gebruiken. De huidige punt (bv 4.58) wordt niet herkent door Excel en dan is weer een extra bewerking nodig om bestand te kunnen gebruiken.
216	BM23 03 00255	De geopackage van GMW op de PDOK website bevat niet de putten die uit registratie zijn genomen. Terwijl er wel een kolom is die dit aan zou geven: 'deregistered' en 'deregistration time'. Maar 'deregistered' staat dus nooit op ja, want de putten die uit registratie zijn genomen zitten niet in de geopackage. Lijkt me eigenlijk wel goed als dat er in zit, toch? Want als een organisatie een put heeft gebruikt en die in eens niet meer kan terugvinden dan weten ze nu niet waardoor dat komt. Terwijl ze anders kunnen zien dat de put uit registratie is genomen + het tijdstip waarop dat is gebeurd.
215	BM23 03 00072	Vanuit ProRail en waarschijnlijk vanuit het hele Civieltechnische veld het verzoek om bij boringen de diepteschaal in NAP maten op te nemen. net zoals bij de sonderingen (presentatie Sondeertrajectdiepte) kan de NAP schaal rechts worden gepresenteerd.
214	BM23 02 00310	Ik leerde vorige week een interessante feature van BRO-loket, nl, dat als je in Regis een bepaalde formatie aanklikt in een doorsnede, je een ruimtelijk plaatje van de top- of basisdiepte van de betreffende formatie kunt krijgen. Heel mooi, maar de kleuring is geschaald op de nationale hoogterange waarop de betreffende formatie voorkomt. Voor Zeeland, met zijn bescheiden reliëf, zou een dynamische schaling erg prettig zijn, omdat voor de meeste formaties de regionale top weinig boven NAP ligt en dus een groot deel van de kleurschaal onbenut blijft. Ook de diepte in zou beperking soms heel handig zijn. Ter illustratie heb ik de Top van de Eemafzetting bijgevoegd, waarbij de schaal tot -90 m gaat, maar voor het deelgebied waarin wij geïnteresseerd zijn -30 al heel ruim is. Mijn vraag is dus of er een mogelijkheid is voor de inkleuring een andere schaal aan te houden dan de nationale?
213	BM23 02 00180	Beste servicedesk, In de toelichting bij een aantal attributen uit de BHR-GT catalogus (zie screenshots verderop hieronder), is het symbool voor de grootheid niet correct. Het betreft verticale en horizontale spanningen die deel uitmaken van de proef: 6.3.39 Bepaling schuifspanningsverloop bij belasting. Aangezien het hier spanningen betreft t.o.v. de waterdruk (u) in het proefstuk, is hier sprake van een effectieve spanning (σ’v of σ’h) en geen totaalspanning (σv of σh). Dit kan tot misverstanden leiden en aanleveren van verkeerde waarden. De grootheden moeten dus voorzien worden van een quote / accentje. Zie ook de formules hieronder uit de norm NEN-EN-ISO 17892-9:2018, waarbij ‘u’ dus de waterdruk in het proefstuk is. image005.png image006.png 6.3.46.3 verticale spanning Type gegeven Attribuut van Volume bij bepaalde consolidatie Definitie De verticale spanning in het proefstuk op het moment van de meting. Juridische status Authentiek Kardinaliteit 0..1 Domein Naam Meetwaarde 5.2 Eenheid kPa (kilopascal) Waardebereik 0 tot 10000 Regels Het attribuut mag niet aanwezig zijn wanneer de waarde van het attribuut consolidatiemethode van de entiteit Consolidatiefase bij belasten gelijk is aan isotroop. Het attribuut moet aanwezig zijn in alle andere gevallen. Toelichting De verticale spanning wordt vastgelegd wanneer tijdens de consolidatiefase de verticale druk geleidelijk wordt verhoogd. De verticale spanning, aangeduid met het symbool σv, wordt berekend uit de kracht waarmee de drukstang op het proefstuk duwt en de druk die de celvloeistof op het proefstuk uitoefent ten opzichte van de waterdruk in het proefstuk. Wanneer de consolidatie getrapt wordt uitgevoerd (consolidatiemethode isotroopAnisotroop) zal de verticale spanning gedurende het eerste deel van de consolidatiefase constant zijn. De verticale spanning is gecorrigeerd voor de invloed van het membraan en indien drainagestroken zijn geplaatst voor de invloed van de drainagestroken. 6.3.46.4 horizontale spanning Type gegeven Attribuut van Volume bij bepaalde consolidatie Definitie De horizontale spanning in het proefstuk op het moment van de meting. Juridische status Authentiek Kardinaliteit 0..1 Domein Naam Meetwaarde 5.2 Eenheid kPa (kilopascal) Waardebereik 0 tot 10000 Regels Het attribuut mag niet aanwezig zijn wanneer de waarde van het attribuut consolidatiemethode van de entiteit Consolidatiefase bij belasten gelijk is aan isotroop of isotroopAnisotroop. Het attribuut moet aanwezig zijn in alle andere gevallen. Toelichting De horizontale spanning wordt vastgelegd wanneer tijdens de consolidatiefase de celdruk geleidelijk wordt verhoogd. De horizontale spanning, aangeduid met het symbool σh, wordt berekend uit de druk die de celvloeistof op het proefstuk uitoefent ten opzichte van de waterdruk in het proefstuk. De spanning is gecorrigeerd voor de invloed van het membraan. *6.3.49.3 verticale spanning* Type gegeven Attribuut van Schuifspanning bij bepaalde belasting Definitie De verticale spanning in het proefstuk op het moment van de meting. Juridische status Authentiek Kardinaliteit 1 Domein Naam Meetwaarde 5.2 Eenheid kPa (kilopascal) Waardebereik 0 tot 10000 Toelichting De verticale spanning is het gevolg van de druk die op het proefstuk wordt uitgeoefend en wordt aangeduid met het symbool σv. De verticale spanning wordt berekend uit de kracht waarmee de drukstang op het proefstuk duwt en de druk die de celvloeistof effectief op het proefstuk uitoefent (het verschil tussen de celdruk en de waterdruk in het proefstuk). Bij de gedraineerde uitvoering wordt de verticale druk van de drukstang direct en gedurende de hele schuiffase door het korrelskelet gedragen. Bij de ongedraineerde uitvoering wordt de druk van de drukstang direct en gedurende de hele schuiffase volledig door het poriënwater gedragen, waardoor een wateroverspanning ontstaat. De verticale spanning is gecorrigeerd voor de invloed van het membraan en indien drainagestroken zijn geplaatst voor de invloed van de drainagestroken.
212	BM23 01 00370	Kunnen jullie op korte termijn werken aan een exportfuctie die ons (dataleveranciers) in staat stelt de toegekende id’s foutloos te verwerken? Tot nu toe moeten we op een habbie babbie wijze de id’s kopieren en ontdoen van allerlei non-informatie en dan in aangepaste vorm zien te uploaden in onze systemen. Idealiter ontvang ik graag in de e-mail (die ik ontvang na doorlevering) een bijlage met daarin in csv formaat de descriptions (vanuit de XML-bestanden in de desbetreffende levering) en de toegekende BRO-ID’s daarbij. Second best is dat ik dat kan downloaden vanuit de levering.
211	BM23 02 00046	Ik maak gebruik van REST API om een grondwaterstandendossier (GLD) op te vragen: https://publiek.broservices.nl/gm/gld/v1/swagger-ui/#/default/objects Regelmatig ben ik geïnteresseerd in een langjarige tijdreeks waarbij een meting van 1x per dag voldoende is. Op dit moment haal ik daarvoor de volledige reeks op. Soms heeft deze reeks een meetinterval van 1x per uur waardoor ik 24x zoveel data ophaal als dat ik nodig heb. Als ik bijvoorbeeld de meetreeks van broId GLD000000009378 ophaal vanaf 1 januari 2020 tot nu (https://publiek.broservices.nl/gm/gld/v1/objects/GLD000000009378?observationPeriodBeginDate=2020-01-01), krijg ik 9,1 MB aan data terug. Om de hoeveelheid data te beperken die ik opvraag zou ik graag de optie hebben om naast een begin- en einddatum van de reeks ook het gewenste meetinterval mee te kunnen geven in mijn verzoek. Is het mogelijk om deze optie toe te voegen?
210	BM23 02 00126	Graag aandacht voor de presentatie van GAR-metingen in het BRO-loket. In de GAR-metingen die wij doen, wordt een stof vaak niet aangetroffen in het grondwater. In dat geval wordt de rapportagegrens (de laagste waarde die detecteerbaar is) vermeld op de plek waar normaal de meetwaarde komt te staan , met een <-teken ervoor. In het BRO-loket wordt dit <-teken echter losgekoppeld van de meetwaarde. In plaats daarvan wordt er in een aparte kolom de letters LT getoond. Het gevolg is dat er in de kolom met meetwaarden een getal wordt genoemd, dat lijkt op een daadwerkelijke meting. Nergens wordt de gebruiker er op geattendeerd, dat de letters LT betekenen dat er geen sprake is van een meetwaarde. Dit kan voor verwarring zorgen. Als bijlage is een illustratie hiervan meegestuurd. Dit geldt ook voor de tabel die via downloaden beschikbaar komt. Is het mogelijk om bij het tonen van de metingen de gebruiker er op te wijzen wat de kolom met LT betekent?
209	BM23 02 00020	Probleemstelling: Met de huidige mappenstructuur van de BRO kan niet meer dan één machtiging per project worden gemaakt. Voorheen kon je projecten cq. machtigingen zoveel mogelijk per (provinciale) weg of vaarweg aanmaken. Iedere machtiging kreeg een uniek referentienummer bestaande uit weg- of vaarwegnummer en opdrachtnummer van de gemachtigde en een korte projectomschrijving. Met de huidige structuur is dat niet meer mogelijk. Het is niet wenselijk om:  Per weg of vaarweg één gemachtigde te kunnen aanmaken. Op die manier krijg je dus allemaal verschillende projecten. Om overzicht te behouden wil ik juist clusteren op weg- of vaarweg.  Bij gemachtigde het opdrachtnummer en projectomschrijving weg te laten en meerdere opdrachten onder dezelfde machtiging te laten vallen. Ten eerste is dit administratief niet logisch en ten tweede is dit onduidelijk voor zowel de bronhouder als gemachtigde. Als voorbeeld van het bovenstaande heb ik onderstaand een schermafdruk toegevoegd van vaarweg A 002 – Van Harinxmakanaal. Met de aanpassing naar de huidige structuur ben ik dus niet geholpen.
208	BM23 01 00320	Als dataleverancier Wil ik bij dat een registratieobject na 'in onderzoek' zetten alsnog te bekijken is in de BRO Omdat ik het registratieobject bij een terugmelding wil kunnen bekijken
207	BM23 01 00504	verzoek 5: verkenning op aanmaken projecten RWS werkt met veel projecten zowel centraal als decentraal in de regio Wens: projecten gestapeld kunnen aanmaken. (denk hierbij aan windows verkenner... met mapjes) Bijvoorbeeld, een project voor Rijkswaterstaat Noord Nederland met rolhouders en daaronder tijdelijke uitvoerings- en of beheer en onderhoudsprojecten. Waarom, de Regio verander niet snel, zal jaren bestaan maar daar onder lopen verschillende kortdurende en langlopende projecten. Dit houd het BHP overzichtelijker...
206	BM23 01 00503	verzoek 4: betreft correspondentie over dubbelingen. Uit het toegezonde bestandje was niet direct duidelijk vanuit welk project of leverancier de data afkomstig was. Ik moest grasduinen via een dump in een .csv naar levering, dan check project om vervolgens de leverancier te achterhalen. Dit moet veel makkelijker kunnen in de excel!! of wel via een link naar de leveringen in het BHP (kom je direct in het project uit) dit kan namelijk al met de overzichtsmails die op vrijdag verschijnen.
205	BM23 01 00502	Verzoek 3: directe mailing vanuit BHP als er een levering open staat zou je direct de rolhouder willen mailen met een overzichtje (zoals die vrijdags altijd in mijn mail verschijnt) en misschien ook wel de leverancier als dat opportuun is b.v. bij controle op dubbelingen.
204	BM23 01 00501	Verzoek 2: betreft een soort managementsamenvatting bij inloggen 1. Hier zou ik bv. graag willen zien welke projecten afgelopen x weken/ afgelopen maand data heeft aangeleverd 2. de laatste stand van zaken t.a.v. openstaande leveringen, hiermee zou je kunnen sturen op de 20dagen. Bv. Project x heeft als 15 dagen open staande leveren. Luxe hierbij zou zijn dat ook de rol/naam rolhouder direct inbeeld komt (dus de interne controleur of bronhouder afhankelijk van welke fase de levering zich bevind) IS dit onderdeel van mijnBRO?? hier zouden wij dan vanuit RWS over willen doorspreken met bv. Sjaak
203	BM23 01 00500	Verzoek 1: onder organisatie, gebruiksbeheren 1. ik zou willen dat alle rollen worden aangegeven bij de verschillende accounts (iemand kan bronhouder van meerdere projecten zijn) 2. Ik zou graag de betreffende projecten onder het uitklap knopje willen zien 3. is zou graag een hyperlink hebben naar het betreffende project N.b. Sjaak heeft ook aangegeven om mij eens met zijn team te bevragen on the fly over verbeterpunten HBP.
202	BM23 01 00487	In de huidige gegevenscatalogus van object GMW is m.b.t. de NITG-code de volgende regel opgenomen: - Het gegeven is alleen aanwezig wanneer de put geregistreerd was in de registratie DINO. In praktijk komt het echter voor dat een boorbeschrijving die van een put gemaakt is WEL in DINO geregistreerd is, terwijl de bijbehorende putgegevens (abusievelijk) NIET aangeleverd en geregistreerd zijn in DINO. Omdat putten en bijbehorende boorbeschrijvingen in principe dezelfde NITG-code hebben, is het verzoek om de regel omtrent de NITG-code te wijzigen in: - Het gegeven is alleen aanwezig wanneer de put en/of de bijbehorende boorbeschrijving geregistreerd waren in de registratie DINO. Daarnaast brengen we graag ook via deze weg het eerdere verzoek om levering van de onderliggende datadumps van de putgerelateerde boorbeschrijvingen uit DINO nog eens onder de aandacht. Dit als basis om de onderliggende gegevens ook daadwerkelijk te kunnen beoordelen en de koppeling tussen de putten en hun bijbehorende boorbeschrijvingen ook daadwerkelijk te kunnen leggen.
201	BM22 12 00327	Wij zouden het voor de controle handig vinden als alle informatie uit een xml bestand die gecontroleerd moet worden omdat deze in de BRO komt, weergegeven kan worden in een Excel bestand.
200	BM22 12 00180	Onlangs kregen we onze eerste BHR-GT-BMA aangeleverd. Bij de controle bleek het echter lastig om na te gaan of bepaalde gegevens (die wel in het rapport stonden) aangeleverd waren aan de BRO. Het ging om Watergehalte en Volumieke Massa. Om na te kunnen gaan of deze gegevens inderdaad aangeleverd zijn aan de BRO, en om een idee te hebben van de waarde, lijkt het me nuttig om deze gegevens op één of andere manier te tonen in het bronhouderportaal. De informatie bleek besloten te liggen in het XML-bestand, maar is op deze manier niet echt toegankelijk. Wat betreft het tonen van BMA-gegevens in BROloket….. ik begrijp dat de gegevens beschikbaar zijn via PDOK, maar wederom niet heel toegankelijk en gebruiksvriendelijk. Wat zou het bezwaar zijn om de gegevens van de boormonsteranalyse ook toegankelijk in BROloket te tonen? Ik hoor het graag.
199	BM22 12 00244	Als gebruiker van het Bronhouderportaal Wil ik in de rapportage van het Bronhouderportaal 'Brondocumentenlijst voor bronhouders' een kolom 'dataleverancier' Zodat ik weet welke organisatie de gegevens heeft aangeleverd
198	BM22 10 00280	Het SIKB 2001 protocol ( "Plaatsen van handboringen en peilbuizen, maken van boorbeschrijvingen, nemen van grondmonsters en waterpassen' uit 2018) is een nieuwere versie van het initiele protocol uit 2005 dat in de waardenlijst van GMW kwaliteitsnormInrichting als 'VKB2001' is opgenomen. Geadviseerd wordt dan ook om vooralsnog die waarde te gebruiken. Tegelijkertijd zal een wijzigingsverzoek worden gemaakt om de waarde SIKB2001 (2018) toe te gaan voegen aan de waarde lijst.
197	BM22 11 00249	We werken momenteel aan een nieuwe, kleine release van het BRO-model REGIS II. Met deze release wordt het model voorzien van onzekerheidsinformatie van de geometrie (top, basis en dikte) van de in REGIS II gekarteerde hydrogeologische eenheden (in de volksmond ‘de kleilagen’). Onzekerheidsinformatie van de geometrie is nieuw in REGIS II. In de gegevenscatalogus is er al wel iets over opgenomen, maar die informatie wordt met de nieuwe release achterhaald. Dit betekent dat de gegevenscatalogus moet worden aangepast, zie ook het mailtje van Michiel hieronder. De huidige gegevenscatalogus vind je hier: Basisregistratie Ondergrond Catalogus REGIS II (Hydrogeologisch model) (geostandaarden.nl)
196	BM22 11 00023	Volgend jaar kunnen tevens off-shore data van boringen, sonderingen en geotechnisch laboratoriumonderzoek aan de BRO worden aangeleverd. De bulk van de onderzoeksdata zijn echter de (ondiepe) seismische surveys zoals voor bijvoorbeeld off-shore wind projecten. Graag in de planning meenemen deze data eveneens via de BRO beschikbaar te maken.
195	BM22 10 00181	Goedendag. Ik heb van verschillende gemeenten in Noord-Brabant de volgende vraag gekregen: ''Is het mogelijk de meetpuntnaam (zoals gebruikt door de gemeente ook zichtbaar te maken in de BRO?'' als voorbeeld, voor de gemeente Breda is put BRED0001 aangeleverd, na aanlevering hebben we daar de BROID GMW000000058767 en putcode GMW44C131960 voor teruggekregen. De administratie van de gemeente (omdat de betreffende put is aangelegd als BRED0001) is echter afhankelijk van de naam BRED0001. Ook in de aanlevering is terug te vinden dat het verzoekkenmerk BRED0001 is en de Object-ID bronhouder BRED0001 is. Is het dus mogelijk om deze ''object ID bronhouder'' zichtbaar en/of selecteerbaar te maken in het broloket?
194	BM22 09 00246	Verzoek: is het mogelijk om het kenmerk IMBRO danwel IMBRO/A toe te voegen aan de rapportages welke de bronhouder kan downloaden in het Bronhouderportaal?
193	BM22 09 00205	Graag grondwaterstanden aanvullen met verwachtte/gemeten waterdruk op filterdiepte of markering indien de grondwaterstand niet gecorrigeerd is voor dichtheidsverschillen in de waterkolom. Achtergrond: onder normale omstandigheden (d.w.z. met een dichtheid van zoet grondwater) gewerkt kan worden met ‘gewone’ stijghoogten, moet je in een situatie met zoet, brak en zout grondwater alles omrekenen naar drukken. Opgeloste stoffen in het grondwater verhogen namelijk de druk. De zoetwaterstijghoogte is eigenlijk een fictieve parameter zonder fysische betekenis. De fysische interpretatie van zoetwaterstijghoogten patronen is niet gemakkelijk. Zo staan zoetwaterstijghoogten niet meer loodrecht op stroomlijnen als de dichtheid varieert, en betekent een gradiënt in zoetwaterstijghoogte niet automatisch dat er stroming van grondwater optreedt. De noodzakelijke correcties voor de dichtheid kunnen significant zijn: een filterbuis gevuld met 20 m zout grondwater heeft een equivalente zoetwaterstijghoogte van 20.5 m: een verschil van 0.5m (Santing, 1980; Oude Essink, 2001).
192	BM22 09 00177	Is het mogelijk dat er een rapportage wordt toegevoegd bij de rapportages met statussen? Uit de bestaande rapportages is op te maken dat de gegevens er wel zijn, maar ik zie ze graag gekoppeld. Het gaat erom dat per project gezien kan worden of er een machtiging tot leveren is aangemaakt en aan welke leverancier en/of er gegevens zijn geleverd en zijn doorgeleverd aan de BRO. Met veel openstaande langlopende projecten wil ik overzicht houden op de status van de projecten (liefst met een soort dashboard). In de bijlage heb ik een eerste opzet van een voorstel gedaan van de velden die ik graag terug zie in een rapportage.
191	BM22 08 00380	Hallo, Is het mogelijk om de sluitingsdatum bij de gesloten projecten weer te geven. Ook had ik deze datum graag in de export gezien. Als dat kan dan zou je door de tijd kunnen lopen zodat duidelijk wordt wanneer welke projecten afgelopen waren. Bij ons duren dijkversterkingsprojecten namelijk meerdere jaren. Ik hoor wel wat er mogelijk is,
190	BM22 08 00383	Als beheerder van mijn organisatie Wil ik zien wanneer een gebruiker voor de laatste keer heeft ingelogd Zodat ik verouderde accounts kan opsporen en opschonen
189	BM22 07 00173	Binnen Fugro zijn wij bezig met een GAP analyses tussen onze bestaande applicaties en de BRO voorschriften m.b.t. sondeer en boor onderzoek. De beschikbare catalogus zijn zeer behulpzaam en gedetailleerd. Om een goed overzicht te maken zou het erg handig zijn om alle attributen in een bijvoorbeeld een Excel overzicht te hebben, zodat wij deze kunnen mappen met de beschikbare parameters in onze gebruikte applicaties. Heeft de BRO beschikking tot zulke overzichten en zouden deze gedeeld kunnen worden?
188	BM22 08 00309	Graag zouden wij als data leveranciers de mogelijkheid hebben de voor ons afgeronde projecten te kunnen archiveren. In de bijlage vind u een schermafbeelding met de projecten die volgens de BRO nog open staan. Maar bij ons al zijn afgerond. Is er een mogelijkheid in te bouwen waar wij deze projecten kunnen archiveren, zo dat ze niet direct in onze home page staan. Hier door is het voor ons overzichtelijker, wat er nog open staan. En is het meteen duidelijk als er zich een nieuwe machtig voor doet.
187	BM22 08 00077	Gezien de gigantische hoeveelheid data (die weliswaar minder wordt, het blijft gaan over GB’s, maar het tempo mag gedecimeerd worden), zou ik graag zien dat de methode van verwerken en opnieuw aanleveren van gecorrigeerde niet-valide xml-files op deze performance wordt aangepast. Bijvoorbeeld door niet op leveringsniveau, maar op fileniveau gecorrigeerde bestanden in de verwerking toe te voegen en alles wat al foutloos was in de levering wél verder te verwerken.
186	BM22 08 00077	In de aanlevering van bulk komen verschillende foutjes naar voren tijdens de validatie. Er worden in mijn geval ca. 50 bestanden per keer aangeboden. De validatie kost vrij veel tijd. Soms is er een generieke fout, dan zie ik bij het eerste bestand al wat er mis gaat en zou de validatie dus afgebroken kunnen worden. Voorbeelden: - 3x een levering, omdat de respons van de inname even stagneert (ik zou er twee willen cancellen, zodat inname niet met onnodige leveringen bezig is). - Een IMBRO/A waarde, bij een IMBRO levering - Syntaxisfouten in het XML-bestand Soms is er een incidentele fout. Van de 50 bestanden zijn er enkele niet-valide, maar een groot deel is valide. Voorbeelden: - Tijdwaardeparen komen dubbel voor (omdat wij in milliseconden registreren kunnen er meerdere in dezelfde seconde vallen) - Een meetwaarde voldoet niet aan de criteria In dit geval moet de hele levering opnieuw worden aangeboden, met dus dubbel belasting van de validatiecapaciteit op eerder gevalideerde (en valide) bestanden.
185	BM22 08 00129	Wat ik begrijp, ook uit de mail die in de bijlage stond en uit de veelgestelde vragen, is dat je bij elk registratie object de URL moet kopiëren. Ik ben er mee aan de slag gegaan, maar het lukt me nog niet om de URL te produceren. Als ik bij het registratie object sta en de URL kopieer, is dat voor elk meetpunt hetzelfde (zie screenshot). De BRO id staat hier niet in. Wat wel lukt is de link die in de bijlage van jouw reactie staat aan te passen door de BRO id te verwijderen en onze BRO id toe te voegen. Dat is nogal bewerkelijk, maar voor de test nog wel te overzien. Indien het goed bevalt willen we over circa 1,5 jaar al onze buizen voorzien van een sticker. Dan praten we over zo’n 2500 stickers en is dat niet meer te doen. Mijn oorspronkelijke vraag was dan ook of er een rapportagetool is, waarbij ik een rapport (xls of csv) kan produceren met de BRO id’s en de bijbehorende URL.
184	BM22 08 00129	Daarnaast heb ik al een QR code gemaakt en uitgeprobeerd op mijn smartphone. De resolutie bij een staande positie van de telefoon is erg slecht. Je ziet er geen gegevens op (zie bijlage). Bij het draaien van de telefoon in een liggende stand zie je de data wel. Om uit te sluiten of dit aan mijn telefoon lag, heb ik Bas Nelemans ook gevraagd de Qr code te scannen. Ook hij kreeg geen gegevens te zien. Kunnen jullie daar naar kijken?
183	BM22 08 00073	Geef mij van PUT GMW.... van filters 0, 1,2,3 (0 = default alle filters) de waterstanden met optioneel "vanaf startdatum tot einddatum" Resulterend in een simpel antwoord bestand met 'kolommen' GMW putid - filternr - DatumTijd-Tijdzone (UTC (+0+1/+2)-NAPstand en eventueel nog een kolom GLD id
182	BM22 08 00064	Bij de gemeente zijn we bezig om iedereen met een account te instrueren hoe ze 2-factorauthenticatie moeten activeren en toepassen. Nu vragen wij ons af of wij (in de rol van beheerder) kunnen zien welke collega's dit inderdaad hebben ingesteld en wie hier 'nog niet aan toe is gekomen'.
181	BM22 07 00397	Ik heb de wens voor grotere symbolen/driehoekjes in een maximaal contrasterende kleur tegen de kaartachtergrond.
180	BM22 07 00339	Ik stuur jullie mede namens Rijkswaterstaat en het platform meetnetbeheerders van de provincies een Request for Change voor toevoeging van de mogelijkheid van het geautomatiseerd kunnen vaststellen en doorleveren of juist afkeuren van leveringen via de API van het bronhouderportaal. Dit is van belang voor bronhouders die de beoordeling en vaststelling van leveringen geautomatiseerd m.b.v. eigen software of applicaties willen doen, en uiteraard voor marktpartijen die daar op die manier eigen en efficiënte softwarematige oplossingen voor kunnen maken en aanbieden. Deze request gaat niet over automatisch goedkeuren en automatisch accorderen maar juist om levering op maat kunnen goedkeuren (of afkeuren) en accorderen via een API. De rationale daarachter is dat je automatisch álles doorlaat als je kiest voor automatisch goedkeuren en accorderen. Doel van deze request is dat het mogelijk moet zijn om leveringen te beoordelen en vast te stellen m.b.v. software of applicaties van derden.
179	BM22 07 00257	Na het verwijderen van de gebruiker is deze uit alle projecten verdwenen (althans aan de client kant van het Portaal). Voor de bronhouderorganisatie zou het wellicht interessant kunnen zijn om te kunnen achterhalen welke gebruiker bij gesloten projecten bronhouder was. Een suggestie is daarom om bij het verwijderen van een gebruiker deze gebruiker bij gesloten projecten op ‘historisch’ te zetten (of iets dergelijks). Dat voorkomt ook de ! in de gesloten projectenlijst vanwege het niet bekend zijn van een bronhouder (aangezien deze uit de gebruikerslijst is verwijderd)…
178	BM22 06 00376	Ik gebruik de OPeNDAP service om stukjes NetCDF op te halen. De hele NetCDF file is enkele GB. Ik kan de gebruiker dat niet elke keer laten downloaden. Voor de applicatie die ik momenteel aan het bouwen ben, wil ik de put filter koppelen aan REGIS. Verder gebruik ik de service als basis voor het opstellen van mijn hydrologisch model. Door direct toegang te hebben tot de NetCDF file kan direct de analyse maken voor het onderzoeksgebied. Wil nogmaals benadrukken dat de OpenDAP server een onmisbare uitgiftebon is voor de grondmodellen (REGIS, GEOTOP). Ik hoop dat de server t.z.t. opgenomen zal worden in de BRO. De manier van dataontsluiting heeft in veel opzichte voordelen ten opzichte van de bestaande methode (PDOK, BRO).
177	BM22 07 00188	Vanuit standaarden houden we vanwege doorlopende aanpassingen aan de GAR parameterlijst een html pagina bij waar de actuele lijst in mens leesbare vorm te vinden is. https://www.bro-productomgeving.nl/bpo/latest/grondwatermonitoring/grondwatersamenstellingsonderzoek-gar/catalogus-gar/actuele-parameterlijst/parameterlijst Het zou werk en potentieel fouten kunnen schelen wanneer de refcode service van de LV-BRO voor de GAR parameterlijst naast de huidige JSON encoding (voor machines) https://publiek.broservices.nl/bro/refcodes/v1/attribute_values?domain=urn:bro:gar:ParameterList&version=latest ook een html encoding zou kunnen uitleveren.
176	BM22 06 00314	Als dataleverancier Wil ik een IMBRO/A GMN aan kunnen maken zonder dat de buizen de buisstatus 'gebruiksklaar' hoeven te hebben Omdat de buisstatus 'onbekend' is bij de IMBRO/A GMW's
175	BM22 07 00022	De aangepaste NEN-EN-ISO 14688-1 en -2 liggen bij NEN voor gereedmaken voor groene versie. Hierna 3 maanden ter inzake en een maand of twee commentaar verwerken voor definitieve versie (eind Q1 2023). Hierin is de bijlage opgenomen voor de RWS Noordzee boringen. Voor onze interne ICT planning zouden we graag willen weten wanneer we deze boringen straks in de BRO kunnen zetten
174	BM22 06 00242	Pas als de stoffen op de IHW site als pdf en xslx zijn gepubliceerd, kan de BRO-organisatie (Team Standaardisatie) de deltalijst (verschillenlijst met nieuw op te nemen stoffen) maken en die aanbieden aan Bouw (Team Landelijke voorziening BRO/ Bronhouderportaal (LVBRO/BHP)) in afgesproken vorm en bestandsformaat. Het CAB zal verzoeken voor toevoeging van stoffen pas behandelen als IHW lijst gepubliceerd is.
173	BM22 06 00371	Voor het weergeven van de GWM-locaties op een kaart gebruik ik de WMS-services van de PDOK. Hierop staan alle GMW's zie>https://nationaalgeoregister.nl/geonetwork/srv/dut/catalog.search#/metadata/937159b9-0dcd-4683-98ec-c262cf309846 Voor mijn applicatie ben ik alleen benieuwd naar putten met een GLD. Op broloket gebruiken jullie voor het filter een Esri arcgis rest services. Binnen mijn applicatie is die mogelijkheid er niet, ook wil ik liever gebruikmaken van alleen maar openbare software. Is er een WMS services die net als de filteroptie van de rest services alleen de putten met een GLD weergeeft? Voor mijn applicatie ben ik afhankelijk van het vue leaflet voor de map functionaliteit.
172	BM22 06 00260	Ik stuur jullie mede namens provincie Flevoland, de OFGV en het platform meetnetbeheerders van de provincies een Request for Change voor toevoeging van een tweetal waarden aan de codelijst Kousmateriaal van registratieobject GMW (de put). Het gaat om: - Kopergaas – dit komt niet voor in de codelijst, maar wordt wel toegepast als kousmateriaal. De waarde ‘kopergaas’ kan ons inziens dus eenvoudigweg toegevoegd worden. - dubbelwandigPVC – deze toevoeging ligt wat lastiger, omdat het hier feitelijk niet om een kous gaat maar om een alternatieve constructie met hetzelfde doel, namelijk het tegengaan van de instroom van sediment in de buis. Het gaat hier om monitoringbuizen van PVC die ter plekke van het filter dubbelwandig zijn uitgevoerd, waarbij er zich tussen beide wanden een grindomstorting bevindt. Een ons inziens correcte oplossing zou zijn dat de codelijst Kousmateriaal veralgemeniseerd wordt tot een codelijst ‘Filterbescherming’ of codelijst met vergelijkbare inhoud en term, die als waarden ‘geen’ , ‘nylonKous’, ‘ppKous’, ‘kopergaasKous’, ‘dubbelwandigPVC’, en ‘onbekend’ heeft.
171	BM22 06 00117	Als gebruiker van de BRO Wil ik bij GLD een limiet op de meetfrequentie Omdat metingen per minuut overbodig zijn Nav de discussie in het Softwareplein ( 9 juni) over de GLD leveringsproblematiek dien ik ‘namens het Softwareplein gremium’ het verzoek in (gemeente Rottedam) om de te registreren GLD ‘meetfrequentie’ van tijdmeetwaarde paren bij sensormetingen te beperken tot een nog nader ‘met het werkveld’ te onderzoeken minimum’, bijvoorbeeld ‘niet frequenter dan 1 x per 10 minuten’. Dit voorkomt dat de leveringen met GLD aanvullingen onnodig groot worden, wat de verwerkingssnelheid zowel aan de voorkant als aan de achterkant vd BBRO ten goede komt. Mogelijk is de limitatie afhankelijk te maken van het monitoringdoel van het GMN ; het lijkt bijvoorbeeld logisch om GLD’s van GMN met monitoringdoel ‘gevolgen OnttrekkingKwantiteit’ een lagere limiet te geven dan een GLD van een GMN met monitoringdoel ‘strategischBeheerKwantiteitRegionaal’…bij de laatste volstaat een frequentie van 1 x per dag of uur, bij de eerste is het mogelijk gewenst om 1 x per 10 minuten of 1 x per minuut te monitoren…. …maar dan moet dus wel de GMN relatie weer ‘verplicht’ worden , maw de GLD werkafspraak ‘Samenhang’ moet dan beieindigd worden…
170	BM22 06 00068	Als bronhouder wil ik grondwatermonitoringgegevens aan kunnen merken als niet-openbaar.
169	BM22 05 00329	Graag wil ik de wens inbrengen om het NITG-nr als historisch ID toe te voegen bij BHR-GT. Dit is relevant voor de conversie vanuit DINO naar de BRO. Vanuit BHR-G is het verzoek gekomen om deze toe te voegen om vanuit oude rapporten deze link te kunnen leggen naar de BRO. Dit verzoek is geaccepteerd en wordt momenteel in de nieuwe catalogus opgenomen. Echter worden er ook vanuit DINO objecten naar BHR-GT geconverteerd waardoor het hier ook relevant is. Het betreft dus een uitbreiding van het informatiemodel met 1 attribuut wat optioneel is en alleen voor IMBRO/A van toepassing is. Het heeft dus eigenlijk geen impact voor leveranciers buiten TNO, maar geeft extra info aan de gebruikerskant. De aanpassing is ook backwards compatible!
168	BM22 05 00248	Als gebruiker van het Bronhouderportaal Wil ik in het tabbladen "gebruikers beheren" en "projectautorisaties" zien of een gebruiker een e-mailaccount of eherkenningsaccount heeft Zodat ik begrijp waarom sommige gebruikers er 2x in staan en zodat ik hierin onderscheid kan maken
167	BM22 05 00227	Als gebruiker van het Bronhouderportaal Wil ik in een project de autorisaties kunnen zien Omdat ik anders na moet vragen bij de servicedesk welke collega ik moet hebben / Als gebruiker van het Bronhouderportaal Wil ik kunnen zien wie beheerder is van mijn organisatie Zodat ik dit niet na hoef te vragen bij de servicedesk
166	BM22 05 00164	Het betreffende issue is van Fugro tijdens het softwareleveranciersoverleg besproken. Hier onder het antwoordt wat daar gegeven is. Je kunt een verzoek alleen maar corrigeren met een soortgelijk verzoek. Dus: • Start mag door start worden vervangen • End mag door end worden vervangen • Complete mag door complete worden vervangen. An JW de Pater verzocht evt een wv in te dienen om ook een leeg end-verzoek toe te staan Uit je mail haal ik op dat dit niet het juiste antwoord is op de vraag omdat daarmee het issue niet opgelost is. Ik zal daarom deze doorsturen als wijzigingsverzoek zodat we gaan kijken hoe we dit oplossen. Jou voorstel is een mogelijke oplossing maar het zou mogelijk ook op een andere wijze opgelost kunnen worden. Aangezien de oplossing niet direct beschikbaar is omdat dit eerst nog ingepland moet worden wil ik je wel alvast een suggestie voorleggen voor dit moment. Normaliter zou dit niet wenselijk zijn maar voor nu is het een omweg die je zou kunnen nemen. Hierbij moet je denken aan het feit om het eerst aangeleverde object te verwijderen en hem als CompleteReport vervolgens opnieuw aan te leveren. Nogmaals is dit niet de gewenste situatie maar een tijdelijke oplossing. Je verzoek wordt dus opgenomen en je hoort zo snel mogelijk terug wanneer hier aan gewerkt wordt. Ik hoop je daarmee voldoende te hebben geïnformeerd!
165	BM22 03 00358	Bij een oplenging van een buis krijg ik een foutmelding: Het lijkt erop dat dit te maken heeft met een ongewijzigde beschermconstructie. Dit soort regels maken het opstellen van een XML-bericht complex. Het zou de aanlevering voor ons minder complex maken wanneer ongewijzigde attributen meegeleverd mogen worden (en dat de BRO ze dan bijvoorbeeld negeert).
164	BM22 04 00352	In deze situatie zou ik het wenselijk vinden dat bij gewenst overleg er langs een korte lijn overleg mogelijk is tussen de controleur en de gegevensleverancier. Het antwoord op de gestelde vraag is kort, maar ik kan het niet kwijt in deze levering. Ik wil in het Bronhouderportaal een reactie terug kunnen typen naar de bronhouder/controleur wanneer een levering is bevroren voor overleg. En/of ik wil de naam van de desbetreffende controleur in kunnen zien, zodat de betreffende personen aan elkaar worden geknoopt.
163	BM22 04 00339 & BM22 03 00358	Nogmaals bedankt voor de reactie. Ik heb dit besproken en we zouden graag verzoeken de limietwaarde aan te passen naar 200000 nT (het dubbele van de huidige limiet). Op het moment komen we een paar opnames tegen waarbij we een paar records van rond de 110000 nT hebben, met een verdubbeling van de limietwaarde zitten we hopelijk altijd goed. Zoals ik in mijn eerste bericht al had gezegd, worden magneto waarden alleen gebruikt om de gradiënt en heeft de meting zelf geen absolute betekenis (omdat een referentiepunt mist). Een limietwaarde is natuurlijk handig om een fout in de eenheid te testen, maar heeft in dit geval dus niet een reële betekenis.
162	BM22 04 00301	We zijn bezig met het aanleverproces van onze GAR IMBRO/A gegevens. Hierbij voldoet de beoordelingsprocedure 'handboekProvinciesRIVMv2017' niet voor al onze gegevens. Daarom willen we graag twee nieuwe opties hiervoor aandragen: ‘LMGQC_intern’ en ‘KRWQC_protocol_v2021’. Voor onze gegevens ouder dan 2017 voldoet de beoordelingsprocedure ‘LMGQC_intern’. En voor gegevens na 2020 de beoordelingsprocedure ‘KRWQC_protocol_v2021’.
161	BM22 04 00092	Er komen meer dan 2500 meetwaardeparen terug in het uitgiftedocument, terwijl is beschreven dat dit beperkt zou worden tot max. 2500 TVPs (in dit gebruiksgeval van niet opnemen observationPeriod) In hoofdstuk ‘2.3.1. DispatchDataRequest’ van de GLD Berichtencatalogus uitgiftewebservice is in de tabel m.b.t. de 4 transactiegegevens, bij het attribuut ‘observationPeriod’, o.a. de volgende regel opgenomen: Het aantal meetwaardeparen in het antwoord wordt beperkt tot maximaal 2500 als het gegeven observationPeriod* (periode van monitoring) niet aanwezig is.* Bij mijn GET Request naar de URL: ‘https://publiek.broservices.nl/gm/gld/v1/objects/GLD000000011922’ heb ik ook geen observatiePeriode meegegeven. Als ik dat wel zou doen, zou de bijvoorbeeld de volgende URL krijgen: https://publiek.broservices.nl/gm/gld/v1/objects/GLD000000011922?observationPeriodBeginDate=2018-11-21&observationPeriodEndDate=2022-01-01 Nu zie ik dat in de respons van het XML bericht 1 observatie terugkomt, met daarin 10.000 TVPs. Dit is dus niet afgekapt op de 2500 zoals de catalogus aangeeft. Wel valt me op dat alleen de eerste observatie is teruggeleverd, terwijl het gehele GLD document bestaat uit 4 observaties, met in totaal 35996 TVPs (wat ik terug krijg vanuit de export van het BRO Loket en bij opvraag met de geillustreerde observatiePeriode query parameters). Ook al krijg je dus meer dan 2500 TVPs op als je geen observatieperiode meegeeft, krijg je dus alsnog niet alle observaties/TVPs terug. Dat is nog wel even iets wat ik in m’n eigen implementatie moet verbeteren, maar dat ter zijde… Daarnaast, ook al lijkt er nu een discrepantie te zijn tussen de beschrijving in de catalogus en de implementatie m.b.t. de afkapping tot max. 2500 TVPs als de observatie periode niet wordt meegegeven. Ik vind persoonlijk deze extra limiet van 2500 TVPs wat vreemd en arbitrair, en als het aan mij ligt (c.q. lees wijzigingsvoorstel), is het misschien een idee om die limiet weg te halen. Persoonlijk zou ik het het fijnst (en misschien ook wel meest logisch) vinden dat als je de GET request niet beperkt/verfijnt tot een specifieke periode, dat je alle observaties (en bijbehorende TVPs) terugkrijgt voor het GLD object. Aan de andere kant, als er vanuit bepaalde ontwerpkeuze’s nodig is geacht om zonder opgaaf van de observatieperiode het aantal observaties/TVPs in het uitgiftedocument te beperken, lijkt het mij logischer om bijvoorbeeld alleen de eerst aangeleverde observatie terug te leveren (zoals dat nu het geval lijkt).
160	BM22 04 00260	Bro Servicedesk : Als gebruiker zou ik op het Bro loket en Dino loket duidelijker vermeld willen zien welke terugmeldingen er zijn op het betreffende BRO Model Misschien door een Button voor downloaden van dit document of toevoegen in opgevraagde lijst. Aanleiding is BW22 02 002. Waarin het model niet direct gaat worden aangepast. Er moet een soort van kleine disclaimer op of een terugmelding die jij krijgt als je gebied selecteert.
159	BM22 04 00037	Wij hebben een flink aantal machtigingen (bijna 80), en dat worden er meer (misschien wel veel meer). Met de vorige opzet was dat veel scrollwerk, Het scrollwerk is minder geworden dankzij de filtermogelijkheid. Echter, in de oude opzet kon je de omschrijvingen zien. Wij hebben klanten die op dezelfde projecten meerdere machtigingen afgeven (vanwege de rechten), en nou moet ik daar de projecten bij openen om de omschrijving alsnog te kunnen zien.
158	BM22 04 00049	Op het moment dat met online sensoren de grondwaterstand wordt gemeten, is het de bedoeling dat deze dagelijks worden aangeleverd als een voorlopige meetreeks. Een maal per half jaar voeren wij een controle meting uit bij deze sensoren. Dan worden de meetgegevens opgehaald die niet online zijn binnengekomen. Incidenteel blijkt ook dat de inhangdiepte van een sensor dan niet juist was geregistreerd. Deze meetgegevens zouden wij dan graag aan willen leveren als een nieuwe voorlopige meetreeks waarbij de voorgaande gegevens die dagelijks zijn aangeleverd komen te vervallen. Kan dit mogelijk gemaakt worden. In de huidige situatie zou dit betekenen volgens mij betekenen dat eerst 180 verwijdercorrecties aangeleverd moeten en pas dan een nieuwe voorlopige meetreeks aangeleverd kan worden. Wij zijn van plan om 1 x per jaar de meetreeks definitief te maken.
157	BM22 03 00421	Ik had een vraagje over notificaties bij het aanleveren van grondwaterstandonderzoek. Binnen een bepaald project ontvangen we 2 leveringen per dag van grondwaterstanden. Per levering ontvang ik sinds kort 2 e-mails (voorheen kreeg ik er 1 per levering). Omdat er uiteraard ook in de weekenden wordt gemeten, stapelen de e-mails zich snel op. De GLD-leveringen staan op automatisch goedkeuren en automatisch accorderen maar ik kan de notificaties hiervoor niet uitzetten zonder dat dit gevolgen heeft voor notificaties binnen andere projecten. Het zou handig zijn als het mogelijk was om per project aan te kunnen geven of je notificaties wilt ontvangen. Ik kan me voorstellen dat als straks de GLD-leveringen voor alle projecten met peilbuizen gaan lopen, dat het dan erg druk wordt in mijn mailbox. Ik hoor graag of hier iets aan te doen is. Alvast bedankt!
156	BM22 03 00381	Heel graag zouden we het Vitens beoordelingsprocedure toe laten voegen aan de catalogus GLD. In de catalogus zelf staat geschreven "Bij het moment van vaststellen van versie 1.0 van de catalogus is een aantal procedures beschreven en beschikbaar. Voor de partijen die deze procedures niet gebruiken maar op een andere, niet beschreven wijze beoordelen, is er de mogelijkheid om aan te geven dat beoordeeld is op basis van het oordeel van een deskundige. Omdat het voor een gebruiker waardevol is om te weten op welke wijze er is beoordeeld, is het is de bedoeling dat de waardelijst van beoordelingsprocedures wordt aangevuld ten behoeve van volgende versies van de catalogus." Wat heeft u nodig om onze beoordelingsprocedure te overwegen voor opname in de volgende versie van de catalogus? Valt dat samen met het bijwerken van de waardenlijst die we voor de technische koppeling zelf zouden benutten? Voor Eijkelkamp heb ik destijds een globale beschrijving aangeleverd van het validatieproces, als ook een technische beschrijving, via Erik Simmelink. De details staan me niet meer helder voor de geest hoe ik dat proces toen ben gestart en wat door jullie is gevraagd. Alvast bedankt voor uw overweging!
155	BM22 03 00269	Hoe kan ik grondwaterstanden uit het BRO-loket lezen / bewerken / analyseren? Een XML kan mijn computer niks mee. Waarom geen csv of Excel export?? Het verzoek aan het BROloket is dat wanneer je een gebied selecteert en dan gegevens downloadt, dat je dan in de geleverde zip-file de excel-bestanden meegeleverd krijgt. Nu moet je dat per grondwaterstand per jaar downloaden en dat is erg veel werk. Ook boorgegevens in XML kunnen nergens ingelezen worden voor analyse.
154	BM22 03 00270	Zou de bronhouder toegevoegd kunnen worden aan de notificaties van het Bronhouderportaal? Ik werk voor 4 verschillende bronhouders en wanneer ik een nieuwe levering ontvang, dan staat daar alleen het levering-ID in. Ik moet dan soms 4x inloggen voordat ik de levering gevonden heb.
153	BM22 03 00148	Graag zou ik een wijzigingsverzoek willen indienen voor het beschikbaar stellen van de waarde van het veld ‘objectIDAccountableParty’ in de GWM REST uitgifte webservice (https://publiek.broservices.nl/gm/gmw-v1.1/) voor alle rollen (Bronhouder, dataleverancier, anders). Deze attribuutwaarde willen we graag gebruiken als één van de kenmerken voor identificatie van het meetpunt met gegevens in ons bronsysteem
152	BM22 03 00113	Oproep 2 is om Polyethyleen dichtheid onbekend alleen IMBRO-A te maken en niet meer toe te staan bij nieuwe buizen: daar hoor je van te weten waar welke materialen zijn gebruikt.
151	BM22 03 00113	Voorstel: schrap die combinatiematerialen. Redenatie 1. Als ik de buis weer met staal op zou lengen moet er een combinatie pePvcStaal komen en zo voort en zo verder. Redenatie 2. Als ik een onderbuis van PVC heb en die opleng met pe moet de combi pvcPe zijn? Circelredenatie 3. Als redenatie2 niet zou kloppen omdat je uit de volgorde van aanlevering van de buisdelen de materiaalvolgorde af kunt leiden, is dus ook een combimateriaal af te leiden en derhalve onnodig. Redenatie 4. Nu ontbreken pehdPvc, peldPvc, ...... infinitum Je kunt beter uitgaan van de logica dat als je een oplenging aanlevert met een andere basismateriaalsoort dan de materiaalsoort die in de voorgaande geldigheidsperiode is aangeleverd, je aan moet nemen dat die nieuwe materiaalsoort uitsluitend op de oplenging betrekking heeft en niet op de totale buis (want dan moet je ook een nieuwe put aanmaken). Vandaar mijn dringende oproep om de combimaterialen hooguit te gebruiken bij IMBRO-A als je een oude buis hebt, waarvan je de samenstellende materialen niet precies meer kunt lokaliseren. of als je een filter /zandvang hebt van een afwijkend materiaal.
150	BM22 03 00108	De huidige zoekfunctie van het portaal is vrij beperkt (zie bijlage). Het zou fijn zijn als de zoekfunctionaliteiten worden uitgebreid om het gebruiksgemak te bevorderen. en aantal suggesties: - Leverancier - Registratie datum - Type objecten Waarbij er in alle leveringen gezocht wordt, zonder dat je in de specifieke levering moet zitten.
149	BM22 03 00110	Het is niet mogelijk om van de filterfunctionaliteit gebruikmaken om alle objecten te selecteren en te verwijderen. Hier ligt nog een kans om het gebruiksgemak van de gebruiker te vergroten.
148	BM22 03 00082	Het probleem waardoor wij hier tegenaan lopen: onze software genereert de XML berichten automatisch op basis van de XSD’s. In het geval van default waarden, zoals het geval bij het ‘owns’ attribute, worden deze standaard ingevuld. Wij vinden het niet bezwaarlijk dat het element niet wordt gebruikt binnen de BRO. Echter vinden wij wel dat het bericht daarop niet mag worden afgekeurd, omdat het wel aan de GML standaard voldoet. Het lijkt ons dan ook niet dat wij aan onze kant een aanpassing dienen te maken, maar dat er aan de kant van de validatie bij het BRO portaal iets moet worden gewijzigd, waardoor een bericht niet meer hierop wordt afgekeurd.
147	BM22 03 00049	Wij zijn als RWS bezig met een aanvullende datakwaliteitscontrole (DKC) welke 'ingeplugd' wordt in het Bronhouderportaal. Hiervoor dient een verrijkingstoken te worden aangemaakt om de koppeling met de DKC tot stand te brengen. Nu is het de rol van Bronhouder die deze tokens kan aanmaken. Dat is niet logisch. Moet het niet de rol Beheerder zijn in Bronhouderportaal die een verrijkingstoken aanmaakt voor de DKC? Want een verrijkingstoken geldt voor de hele Rijkswaterstaat-organisatie, niet voor een afzonderlijk Rijkswaterstaat-project. Verzoek: de autorisatie voor het genereren van verrijkingstokens niet meer bij de rol van Bronhouder, maar uitsluitend bij de rol van Beheerder beleggen.
145 + 146	BM22 02 00224	Ik zou graag als gemachtigde een notificatie ontvangen als er leveringen kunnen worden gecontroleerd (dus wanneer bestanden worden aangeleverd). Daarnaast hierbij het verzoek om notificatie te versturen aan de leverende partij wanneer er door een controleur overleg is gewenst. "Overleg gewenst" melding heeft nu geen notificatie. Althans, die notificatie kan niet worden geselecteerd in de instellingen van de bronhoudersportaal.
144	BM22 02 00123	De informatie van de filterdiepte van peilbuizen is niet consequent. Het betreft de informatie onder het tabblad “Basisgegevens” zoals in de onderstaande schermbeelden van twee voorbeelden. Bij de aanwezigheid van 1 monitoringbuis wordt aangegeven: · Positie bovenkant ondiepste filter · Positie onderkant diepste filter Er is echter maar 1 filter en dus geen ondiep en diep filter. Hier wordt dus aangegeven de bk en ok van het filter Bij de aanwezigheid van 2 monitoringbuizen wordt aangegeven: · Positie bovenkant ondiepste filter · Positie onderkant diepste filter Hier is wel sprake van een ondiep en een diep filter, dus dat klopt. Echter wordt hier, in tegenstelling tot de situatie met 1 monitoringbuis, de bk van het ondiepe filter weergegeven en de ok van het diepe filter. Dat is verwarrend. Mijn voorstel is: geef voor elke buis alleen onderkant filter aan.
143	BM22 02 00028	Van al deze putten in mijn regio wil ik maar één ding weten: wat is de laatst gemeten grondwaterstand binnen de betreffende filterbuis (waarover ik via de GMW koppeling al alle info heb ontvangen). Dat had ik verwacht te kunnen doen via de GLD SOAP API, maar daarin is alleen een dispatchData request mogelijk waarbij een ID verplicht is die ik niet heb en waar ik niet aan kan komen. Ik hoor graag hoe we op korte termijn over actuele grondwaterstanden kunnen beschikken voor alle actieve grondwatermonitoringsputten die we al in onze regio-dataset hebben staan afkomstig uit de GMW SOAP API.
142	BM21 11 00059	We zijn bezig met de implementatie van het BRO gegevensmodel in onze eigen systemen. Het zou ons hierbij helpen als de domeinmodellen waarvan de UML afbeeldingen in de catalogus staan (entiteiten, attributen, relaties, keuzewaardelijsten,...) beschikbaar zijn in een machine leesbaar formaat (bijvoorbeeld in Enterprise Architect of ander UML formaat).
141	BM21 11 00164	Uw bericht: Mbt https://github.com/BROprogramma/SFR/issues/41 het volgende. In de werkafspraak staat het zo: Bij BHR-P is het domein van het attribuut bovengrens (attribuut van Strooisellaag) Meetwaarde 1.3 - Bij BHR-P is het domein van het attribuut ondergrens (attribuut van Strooisellaag) Meetwaarde 1.3 - Bij SFR is het domein van het attribuut bovengrens (attribuut van Strooisellaag) Meetwaarde 1.3 - Bij SFR is het domein van het attribuut ondergrens (attribuut van Strooisellaag) Meetwaarde 1.3 en als het goed is het dus ook zo geïmplementeerd. Echter, dit lost niet alles op. Indien de begindiepte van de strooisellaag niet een geheel aantal cm boven maaiveld is, werkt dit niet. Oftewel als de strooisellaag is uitgedrukt in mm. Uit WENR GIT https://git.wur.nl/BRO/bkr-kuil/-/issues/208 Antwoord Fokke 21-1-2021: Vorige week afspraak met Bregje (TNO) gemaakt dat we zowel voor BHR-p als voor SFR alle lagen gaan opslaan met drie decimalen. Omdat de dimensie van deze dieptes in meters is, kunnen we binnenkort (na aanpassingen van het bouwteam) de lagen dus in mm nauwkeurig gaan aanleveren. Volgens WENR zoude alle begin en einddieptes zoals https://docs.geostandaarden.nl/bro/sfr/#detail_attribute_Model_Wandontsluiting_einddieptewand 3 decimalen moeten krijgen, dit blokkeert ruim 500 beschrijvingen.
140	BM22 01 00420	Zie vorige verzoek: Nog een ander issue hieraan gerelateerd: Nu is een download als xls ook alleen per jaar mogelijk. De behoefte is de gehele periode als xls of ander beschikbaar format te kunnen downloaden.
139	BM22 01 00420	Voor controle van reeksen zien wij graag de gehele meetreeks grafisch weergegeven in het BROloket, echter is dat alleen per jaar mogelijk (overigens is de laatste registratie niet zichtbaar). Deze beperking is een groot gemis. Wellicht heeft de beperking te maken met de grote hoeveelheid registraties van sommige reeksen. Mijn verzoek is deze wens technisch wel mogelijk te maken. Wanneer dat op dit moment nog niet te realiseren is dan stel ik voor: · Kleine reeksen wel geheel te vertonen (bij de betreffende GLD gaat het om een paar honderd registraties over een periode van 10 jaar). · De te vertonen reeks beperken tot een maximum aantal registraties; · Of bij overschrijding van maximum de frequentie van het tonen van registraties beperken (bijvoorbeeld bij; uurregistratie visialisatie per dag bijv. 12:00 uur); bij inzoomen wordt weer de volledige reeks gepresenteerd; · Of idem als vorige, maar dan daggemiddelden vertonen.
138		Als admin van het Bronhouderportaal Wil ik organisaties kunnen beheren met behulp van selecties Zodat ik de organisaties actueel kan houden Voorbeelden selectiecriteria: gebruikers (+laatste inlogmoment) Laatst aangeleverde levering (dit moet 0 zijn als een organisatie nog niet geleverd heeft, dan weten we dat de organisatie nog niet actief is) Gebruikers met de rol beheerder kunnen opvragen (daarbij moet duidelijk zijn bij welke bronhouderorganisatie de beheerder hoort)
137	BM22 01 00385	Als admin van het Bronhouderportaal Wil ik op alle leveringen kunnen zoeken (adhv een aantal selectiecriteria) Zodat ik bij storingen kan beoordelen of het aanleverproces verstoord is /Zodat ik niet op de gok hoef te zoeken naar een bepaalde levering Voorbeelden selectiecriteria: Hoe lang leveringen openstaan op registratieobject op datum-tijd van aanleveren/controleren/doorleveren Op bronhouder Op dataleverancier
136	BM22 01 00310	Als dataleverancier wil ik alle historische aanvullingen van een put die ik al eerder aan de BRO heb aangeleverd in 1 bericht kunnen aanleveren zodat ik geen problemen krijg met de volgorde van de aanvullingen.
134 en 135	BM22 01 00132	Onderwerp: Verzoek uitbreiding eenvoudige geotechnische labtesten en peilbuismetingen In verband met het door de energietransitie gedreven elektrificeren van Nederland worden grote hoeveelheden thermische geleidbaarheidstesten uitgevoerd voor netbeheerders (on-shore maar zeker ook off-shore). Het gaat om genormaliseerde testen. Graag in overweging nemen om deze data op te nemen in de BRO. Naast doorlatendheidsbepalingen in geotechnische laboratoria worden in peilbuizen vrij regelmatig genormaliseerde slugtesten uitgevoerd. Het gebruik hiervan is divers (van bemalingen tot stedelijk waterbeheer o.a. ivm klimaatadaptatie). Graag in overweging nemen om deze data op te nemen in de BRO. OPMERKING: Nav het BRO tje van 13 januari. Graag terughoudendheid met visualisaties in het uitgifteportaal om marktinitiatieven niet te frustreren. Een helder beleid op dit gebied voor de komende jaren is noodzakelijk om te stimuleren van commerciële partijen hierin blijven investeren waardoor het gebruik van de BRO toe zal nemen.
133	BM22 01 00178	Ik zie verschillende leveringen die de status doorgeleverd/afgekeurd_LVBRO hebben. Ze hebben het proces wel doorlopen, Ze zijn dus wel valide, gecontroleerd en vastgesteld maar worden niet in de LV opgenomen. Wat gaat hier mis?
132	BM22 01 00144	Eerder hebben we met Erik contact gehad over onze wens vanuit de Brabantse waterschappen, provincie en Brabant Water om QR-codes te gaan toepassen op onze peilbuizen zodat "voorbijgangers" deze kunnen scannen en daarbij meer informatie krijgen. Deze QR-codes zouden dan direct moeten linken naar BROloket, waar informatie over de betreffende peilbuis (GMW) en de daarbij horende meetgegevens te zien zijn (GLD en/of GAR). Qua visualisatie zoeken wij dus niks nieuws in principe. Wat we nodig hebben voor een QR-code is echter een uniek URL voor iedere GMW met unieke BRO-ID. Klopt het dat BRO-loket geen aparte URL's hanteert voor iedere GMW (BRO-ID)? Zou dit wel mogelijk zijn of zijn er andere (eenvoudige) oplossingen om een dergelijke QR-code te generen o.b.v. de presentatie van gegevens door de BRO? Erik gaf aan contact op te nemen met de servicedesk hierover om de mogelijkheden te bespreken. Ik hoor het graag.
131	BM22 01 00129	Als gebruiker van het bronhouderportaal wil ik door kunnen klikken naar de volgende levering in mijn project, zodat ik niet na het bekijken van een levering terug naar het leveringenoverzicht moet, om vervolgens de volgende levering te moeten zoeken en aan te klikken.
130	BM22 01 00102	Als wij een GMW_Construction in IMBRO aangeleverd krijgen willen wij graag weten welke partij de put geslagen heeft. We kunnen echter geen attribuut hiervoor vinden in de GMW-standaard (Catalogus of de xsd). De beheerder van een put kunnen we wel vinden via 'maintenanceResponsibleParty' en ook dat wij bronhouder zijn via 'deliveryAccountableParty', maar een uitvoerende partij lijkt te ontbreken. Is dit gegeven niet opgenomen in de standaard of zien we wat over het hoofd? Is er een manier om het toch mee te geven als het buiten de standaard valt? Informatie door de BRO Servicedesk toegestuurd: De organisaties die geregistreerd (kunnen) worden bij een grondwatermonitoringput zijn: - De bronhouder (verplicht) - De dataleverancier (dit wordt afgeleid uit het bronhouderportaal en is de organisatie die gemachtigd is door de bronhouder) - De onderhoudende instantie (optioneel) - De eigenaar (verplicht onder IMBRO, niet verplicht bij IMBRO/A)
129	BM22 01 00108	Als gebruiker van het bronhouderportaal Wil ik zien waarom de grafiek en kaart niet meer te raadplegen zijn na doorlevering Omdat ik deze wel verwacht
128	BM22 01 00097	Hierbij dien ik een wijzigingsverzoek in voor het opnemen van de verticale verschuiving in het overzicht bij een gegevensaanvraag. Dit geld ten minste voor boringen en sonderingen maar misschien ook voor andere gegevens. Op dit moment wordt een BRO-ID/boornummer, locatie en wat metadata getoond. Echter, in gebieden met hoogteverschillen, bijvoorbeeld bij dijken, taluten of gewoon op de stuwwallen of beekdalen kan je nu niet makkelijk bekijken welke boring/sondering wel en welke niet in aanmerking komt en je dus wel/niet wilt hebben. Zie onderliggende voorbeeld vlak bij Utrecht: Hier zitten meerdere meters verschil tussen, wat uit kan maken of je de boring/sondering wel of niet wilt hebben. Ook kan je zo makkelijk zien welke voor en welke na verandering van het maaiveld gezet zijn doordat het snelwegtalud aangelegd is.
127	BM22 01 00096	Ik dien hierbij een verzoek in om extra gegevens op te nemen bij de weergave en export van de sondeergrafiek. Nu worden in het informatieblokje bij de grafiek het BRO-ID en de Aangeleverde coordinaten (in RD) weergegeven. Het zou erg helpen als hierbij ook de verticale verschuiving weergegeven wordt in het informatieblokje en dat ook meekomt in de export. Op deze manier hoef je voor het beoordelen van de sondering niet elke keer naar het tabje basisgegevens te klikken, en als je de export opslaat hoef je dat ook niet er bij te typen of editen:
126	BM21 12 00752	Mij lijkt het logisch als een bronhouder altijd brondocumenten mag valideren/aanleveren voor zijn/haar eigen registratieobjecten, en dat een bronhouder via de machtigingen in het bronhouderportaal kan instellen welke dataleverancier (óók) BRO registratieobjecten mag (valideren en) aanleveren voor de bronhouder.
125	BM21 12 00268	Bij het filteren binnen de leveringen in een project komen niet alle leveringen naar voren. Er waren een aantal leveringen niet goed gegaan en daar kan je niet op filteren dus die komen niet naar voren (is wel een idee lijkt mij!).
124	BM21 12 00285	Het BRO-ID wordt niet meer weergegeven in de samenvatting in het bronhouderportaal, terwijl dit eerder wel werd toegevoegd op het moment dat de levering was doorgeleverd. Kan dit weer toegevoegd worden? De plek waar het BRO-ID nu getoond wordt, kan niet gekopieerd worden. Dit zorgt ervoor dat ik het BRO-ID over moet typen, of uit een rapportage moet halen, wat beide geen wenselijke situaties zijn.
123	BM21 12 00286	In het bronhouderportaal kan ik bij een machtiging niet aangeven welke gegevens wel of niet automatisch doorgeleverd moeten worden. Wanneer ik het automatisch goedkeuren en accorderen aanzet, dan geldt dit voor alle leveringen. Ik wil bijvoorbeeld mijn grondwatermonitoringputten wel controleren, en de voorlopige grondwaterstanden niet. Deze gegevens worden door dezelfde leverancier aangeleverd, waardoor ik 2 projecten aan moet maken. Mijn leverancier vraagt zich af of dit niet makkelijker kan door in een machtiging aan te kunnen vinken welke gegevens wel en welke gegevens niet automatisch doorgeleverd mogen worden.
122	BM21 12 00258	Als registratiebeheerder wil ik op basis van bro-id de dataleverancier en/of bronhouder aan kunnen passen zodat ik bij een grote aanpassing niet honderden bro-id's handmatig aan hoef te klikken In de originele melding zit een voorbeeld
121	BM21 09 00030	Ik en we lopen inmiddels vaker tegen het punt aan dat de rol van ‘ontzorger van de Bronhouder’ niet expliciet benoemd of geregeld is in BRO-kader. Bronhouders kunnen zich op dit moment wel laten ontzorgen door marktpartijen als het gaat om individuele data- of softwareleveringen, maar niet als het gaat om ontzorging of ondersteuning als dienstverlening zelf, bijvoorbeeld in de vorm van overkoepelend databeheer (zie ook melding BM21 08 00255 en memo https://github.com/PlatformMeetnetbeheerders/BRO-Protocol/blob/main/Memo%2021101AEV0.91%20%E2%80%93%20Verschillende%20leveranciers%20en%20de%20BRO%2C%20probleem%20en%20oplossingen.pdf). Een andere vorm van overkoepelend databeheer is het uit registratie (kunnen) nemen van objecten namens de bronhouder, en zo zijn er meer voorbeelden te geven. Voor Bronhouders blijkt het inmiddels vaker wenselijk of nuttig te zijn om zich ook te laten ontzorgen in hun eigen rol, en marktpartijen zo mogelijk ook formeel dat vertrouwen en die machtiging te geven, als daar om welke reden dan ook aanleiding voor is. Vandaar het formele verzoek en vraag aan jullie: kan dit inderdaad ook in formele en technische zin mogelijk gemaakt worden?
120	BM21 11 00490	Naar aanleiding van de constatering van (Verbelco) (zie BM21 11 00354 GLD vragen) van een 2-tal ontbrekende waardes in de waardelijst van attribuut Typemeetinstrument ( 6.3 in de gebruiksvriendelijke catalogus) in de GLD gegevensinhoud , hierbij het volgende wijzigingsverzoek: ‘graag de waardelijst 6.3 Typemeetinstrument uitbreiden met een 2-tal waardes, voor zowel IMBRO als IMBRO/A kwalregime: -Lineaal; definitie: een duimstok of rolmaat waarmee een hoge waterstand, vlak onder de bovenkant van een monitoringbuis, handmatig wordt afgelezen, omdat er in dat geval geen klokje gebruikt kan worden; -Manometer; definitie: een manometer waarmee een waterstand handmatig wordt vastgesteld in monitoringbuizen, die zijn voorzien van een drukdop (bij artesisch water).
119	BM21 11 00443	US acceptatiecriteria Ik kan mijn selectiegebied geografisch op kaart intekenen Ik kan alle data van mijn bronhouder (DeliveryAcountableParty) opvragen Ik kan aangeven welke data ik wil ontsluiten (GMW, GMN en/of GLD) Ik krijg de gegevens in de TAUW aanleversjablonen BRO retour Omdat de wens is om o.a. de optie te hebben om een geografische selectie te gebruiken voor de ontsluiting van gegevens, wil je graag voor GMN en GLD een ruimtelijke relatie kunnen leggen die m.i. nu via de officiële weg niet mogelijk is (danwel verre van efficient is). Zoals aangegeven heb ik dat nu gedaan via de achterliggende systematiek die bij het BRO loket wordt gebruikt; ArcGIS Rest API geeft putten met informatie over aanwezigheid GMN en GLD. API Call https://publiek.broservices.nl/gm/gmn-v1.0/{BRO-ID_GMW} geeft informatie over meetnetten gerelateerd aan put (o.a. BRO-ID_GMN), en net zo geeft https://publiek.broservices.nl/gm/gld-v1.0/{BRO-ID_GMW} informatie over meetpunten gerelateerd aan put (o.a. BRO-ID_GLD). Op basis van de BRO-ID’s van GMN en GLD kun je vervolgens met de REST API de gerelateerde gegevens ophalen. Waar het mij vooral om gaat is dat je de relatie kunt leggen tussen GMW – GMN en GLD. De vorm waarin/waarop maakt me niet alles uit. Ansich is bovenstaande methodiek voor mij prima. Overigens weet ik dat ik ipv de ArcGIS Rest API. de putten ook had kunnen opvragen aan de hand van een ‘https://publiek.broservices.nl/gm/gmw-v1.1/characteristics/searches’. Echter, daarbij kan alleen gebruik gemaakt worden van rechthoeken of cirkels (en moet je (iig bij de REST API, bij SOAP miss niet), de coordinaten transformeren naar LL-WGS84 (EPSG:4258)). Maar het belangrijkste is dat je bij deze characteristics/searches geen informatie terugkrijgt over of de betreffende putten gelinkt zijn aan GMN en GLD, wat je bij de ArcGIS REST API wel krijgt (de GMW features die je daar terugkrijgt hebben o.a. attributen ‘NUMBER_OF_GMN’ en ‘NUMBER_OF_GLD’). Het is wenselijk deze attributen wel te hebben, gezien je dan geen requests hoeft te doen voor GMN respectievelijk GLD gegevens voor putten waarvan je weet dat ze niet in een meetnet zijn opgenomen respectievelijk meetpunten bevatten. Wat in deze systematiek niet ideaal is, is dat je bi de call https://publiek.broservices.nl/gm/gld-v1.0/{BRO-ID_GMW} ook alle metingen terugkrijgt, waar ik eigenlijk allen ge-interesseerd ben in de bijbehorende BRO-IDs van de meetpunten (BRO-ID_GLD). Ik weet dus dat deze methodiek niet ‘officieel’ door jullie wordt ondersteund/aangeraden, maar m.i. is er momenteel geen alternatief om dit toch te regelen. Of nou ja, het enige alternatief dat ik zie is de volledige ontsluiting van GMN en GLD (ALLE gegevens, ihb ook ieder waterstand waar dan ook in nederland gemeten), waarmee je dan eigenlijk eerst de volledige databases download, om vervolgens zelf de achterliggende (SQL) joins te implementeren om de gegevens aan elkaar te relateren.
118	BM21 11 00257	User story: Als leverancier, bronhouder en gebruiker wil ik in dat er in de BRO de juiste naam genoteerd wordt van e NPR met betrekking tot de Analyseprocedure.
117	BM21 11 00183	Het is nu niet helemaal helder wat in welk veld moet staan: dat de rapportagegrens bij een gemeten waarde onder de rapportagegrens ook in het veld analysemeetwaarde gezet moet worden. Goed kijken naar definities en toelichting. Daarnaast is het niet voor iedereen helder waarom dat moet en waarom het niet gewoon in het rapportagegrens veld moet en je het analysemeetwaardeveld dan leeg laat (dit is eerder juist zo gedaan op verzoek van stakeholder omdat je zo aansluit bij SIKB). Zou het veld rapportagegrens niet verplicht gevuld moeten worden? Zie confluence voor de gehele discussie: Discussie rapportagegrens - SIKB (voorjaar 2020)
116	BM21 11 00200	Op het Softwareplein van vanmorgen werd door enkele leveranciers uitgesproken dat zij het bericht ‘RO+history’ (aanleiding was GMN maar het speelt ook bij andere RO’s) niet alleen voor Imbro/a maar ook voor Imbro zouden willen gebruiken. Reden daarvoor is dat het nu niet mogelijk is om archiefgegevens met Imbro-kwaliteit in één keer aan te leveren. Graag als issue opvoeren en aan het CAB voorleggen.
115	BM21 11 00186	Als beheerder voor ontwikkeling en realisatie van de BRO; Wil ik voor de ontwikkeling van nieuwe RO's (in elk geval FRD) de waardelijsten van GMN aanpassen; Zodat dit vanuit een beheeroogpunt, via een ‘generieke open werkafspraak’, de uitbreiding van de waardelijst mogelijk gemaakt wordt.
114	BM21 11 00185	Als gebruiker van de BRO; Wil ik dat het kwaliteitsregime NIET bepalend moet zijn of een IMBRO GAR aan een GMN gekoppeld mag worden, maar de 3 inhoudelijk variabelen (doel, kader aanlevering, gw-aspect); Zodat de drie variabelen niet de waarde onbekend mogen hebben, waardoor een IMBRO GLD aan een IMBRO/A GMN gekoppeld kan worden.
113	BM21 11 00104	In de catalogus GUF (geraadpleegde werkversie 04) hebben de ontwerpput en gerealiseerde put (gegevensnrs. 5.3.6.4 resp. 5.3.10.6) het attribuut "openbaar raadpleegbaar" (ontwerpput 5.3.6.5, gerealiseerde put 5.3.10.6), dat aangeeft of de putgeometrie publiekelijk beschikbaar is ingeval het een put voor de openbare drinkwatervoorziening betreft. Dit attribuut "openbaar raadpleegbaar" dient vanwege beveiligingsaspecten echter ook te staan bij de putdiepte en het filtertraject van de ontwerpput (5.3.6.6 resp. 5.3.6.9) en bij putdiepte en filterattributen van de gerealiseerde put (5.3.10.4 resp. 5.3.11.2-4); wellicht ook 5.3.11.2 (filtertype). Dit is ter sprake gekomen in de vergadering van de DomeinBegeleidinggroep Grondwater van 2 nov. jl. Afgesproken is daar dat ik dit punt bij de Servicedesk BRO zou inbrengen. Ter vergadering is niet duidelijk uitgesproken of het alleen de gerealiseerde put danwel ook de ontwerpput betreft; maar vanwege de beveiliging lijkt mij dat dit ook voor de ontwerpput zou moeten gelden. Dit is omdat veelal de voorgenomen filterstellingen van ontwerpputten afhangen van de diepteligging van het/de watervoerend(e) pakket(ten) waaruit gewonnen zal worden. Die af te pompen pakketten en daaruit af te leiden globale filterstelingen worden meestal al tijdens verkenningsonderzoeken vastgesteld ruim voordat het ontwerp van de installatie wordt gemaakt en zullen maar hoogst zelden veranderen tussen ontwerp en realisatie. Derhalve kunnen de (globale) filterstellingen voor de gerealiseerde put vaak, zo niet: vrijwel altijd, worden afgeleid uit de geregistreerde gegevens van de ontwerpput.
112	BM21 11 00086	Verzoek om procesmetingen uit te sluiten van verplichte aanlevering aan de BRO. Dit betreft een scopewijziging, of scopewijzigingen (zie helemaal onder). (Dit is in de vergadering van de DomeinBegeleidingsgroep Grondwater van 2 nov. jl. aan de orde geweest, afgesproken is dat ik dit wijzigingsverzoek mede namens de DBG indien). Het criterium dat aanleveren van metingen verplicht is vanaf een meetperiode van één jaar of langer, heeft een te grote reikwijdte. Procesmetingen betreft metingen die bijvoorbeeld om de zoveel jaar, maar wel met enige regelmaat, worden uitgevoerd: * Meten bodemweerstand van infiltratiegeulen (GLD, evt. GPD) * Volgen geleidelijke verstopping en onderhoudstoestand winmiddelen * Testen calamiteitenvoorzieningen (-putten) (GLD, GAR, evt. GPD) * Enz. ... vooral als hiervoor dedicated meetpunten worden gebruikt. Herbruikbaarheid hiervan voor derden is twijfelachtig en aanleveren levert voor gegevensleveranciers onnodig werk op. Dit betreft niet alleen metingen die onder GLD zouden vallen maar ook sommige GAR en wellicht ook sommige GPD.
111	BM21 10 00405	Hierbij dien ik namens TNO-GDN en de VOTB een wijzigingsverzoek in op de registratieobjecten Geologische Boormonsterbeschrijving (BHR-G BMB) en Geotechnische boormonsterbeschrijving (BHR-GT BMB) voor zowel het IMBRO als het IMBRO/A deel. De gewenste wijzigingen zijn uitsluitend in een tweetal waardenlijsten om in de toekomst verwarring en mogelijke fouten te voorkomen. Zie het bijgevoegde document voor een uitgebreide beschrijving.
110	BM21 10 00179	Hierbij het verzoek voor het toevoegen van het referentieniveau aan de gegevensdefinities in (volgende versies van) de catalogi. Dit met als argumenten: - Er blijken misverstanden op te treden m.b.t. het geldende referentieniveau bij o.a. de stijgbuisdeellengte en filterdiepte van putten (GMW’s) - Die misverstanden zijn zowel opgetreden bij provincie Limburg als bronhouder, als bij het standaardisatieteam zelf. Dit laatste getuige de verkeerd gekozen QC-regel m.b.t. de stijgbuisdeellengte. - Het referentieniveau kan weliswaar elders in de catalogus gedefinieerd worden, maar mensen lezen nu eenmaal niet een hele catalogus als ze specifiek op zoek zijn naar één bepaalde gegevensdefinitie.
109	BM21 10 00247	We lopen tegen het feit aan dat de object-ID bronhouder van een registratieobject standaard niet uitgeleverd wordt aan anderen dan de bronhouder zelf, en dat laatste ook alléén als de bronhouder in staat is om zichzelf te identificeren via een PKI-certificaat en zelf de secure SOAP-service geimplementeerd heeft en in staat is om deze te gebruiken e.d. ‘We’ is in dit geval een samenwerkingsproject van provincie Utrecht met RHDHV en ondergetekende, maar eerder bleek implementatie voor en bij provincie Gelderland ook al niet zomaar te realiseren. Dit ook niet met ondersteuning daarbij van jullie als servicedesk, althans na een verzoek daartoe. Om bovengenoemde redenen dienen we graag bij deze als verzoek in om de object-ID bronhouder vrij te geven en uitgifte daarvan via REST-services mogelijk te maken.
108	BM21 09 00328	Deze “automatisch ingestelde schaalverdeling” geeft een vertekend beeld en grafieken komen niet overeen met de aangeleverde sondeerresultaten. De bovenste grafiek 04 waar het om gaat heeft maximaal 1 graden afwijking en grafiek 03, 2 graden. Dus graag zoals eerder aangevraagd de schaalverdeling graag standaard houden. Puntweerstand max 20 mPa of 30 mPa Plaatselijke wrijving max 0.5 mPa of 0.75 mPa Graag combinatie 20 mPa – 0,5 mPa of 30 mPa – 0,75 mPa aanhouden / vast zetten voor de juiste combinatie. Want de percentage van het wrijvingsgetal komt niet overeen met de quotiënt volgens de norm NEN-EN-ISO 22475-1. Wrijvingsgetal maximaal op 10 % houden. Soms staat hij op 100 % (grafiek 05 levering 0000040785), dan is de grafiek compleet uit proporties. Schaalverdeling van de helling ‘vastzetten’ op max 15 graden. Anders veel te veel verwarrende paarse lijnen door de grafiek.
107	BM21 06 00490	- GAR issues (GitHUB) Onze prioritering voor het volgend CAB overleg zijn de geel ingekleurde rijen van de bijgevoegde Excel tabel. Het gaat om GitHUB issues nummers: 45, 159, 162, 81-2 De Excel tabel kan gefilterd worden (dropdownknop) in redactionele issues en (wens)wijzigingen. Ook het issue over de parameterlijst (stoffenlijst) voor GAR (waarschijnlijk commitment in PI-event Q4 2021) grg inbrengen inhet CAB zie onder de kop ‘Andere onderwerpen’. Andere onderwerpen: - GAR Parameterlijsten IHW Alvast in CAB voor de backlog indien er wordt gecommit in PI-event Q4 2021. Gebundelde informatie verzamelt in gezipte meegestuurd bestand IHW GAR.zip. Voorlopig is er een tijdelijke oplossing afgesproken in een later stadium volgt een oplossingsrichting voor de BRO in overleg met IHW - GLD issues Het is belangrijk dat de ingediende een topdesknummer krijgen al dan niet in het CAB komen. Dat blijkt uit een vraag van Sjaak zie mailwisseling in de bijlage. Sjaak had graag de opbossing van issues van GLD over de dataum (reeds ingediend) mee laten komen in komend CAB: - Afhandeling van datums (tussentijdse gebeurtenissen mogen niet de datum onbekend hebben). Alleen kop en staart. - Afhandeling van tijdstippen waarin het tijdstip wordt vergeleken met een datum. Dus, eerst het tijdstip terugrekenen naar de locale datum en daarna vergelijken. Niet simpelweg het datumdeel vergelijken (verscheidene issues). 201210628 GAR GitHUB issues (4).xlsx
106	BM21 09 00379	De wens is om deel-leveringen op te vragen. Er is al dergelijk wijzigingsverzoek gedaan voor BRO-loket. Is in onderzoek: zal evt worden ingepland. iets om uit te zoeken voor PDOK
105	BM21 08 00178	Er zijn afgekeurde observaties aangeleverd aan de BRO (GLD000000000141). In de visualisatie van het BROloket wordt deze reeks getoond als "volledig beoordeeld". Het is in de visualisatie niet duidelijk dat er afgekeurde observaties zijn. Dit zou de verkeerde indruk kunnen wekken. De bronhouder heeft ook aangegeven dat zij afgekeurde gegevens liever niet aanleveren aan de BRO, als in het BROloket niet duidelijk is dat deze afgekeurd zijn. In het BROloket is alleen te zien dat de data volledig beoordeeld zijn, maar niet dat de data afgekeurd is. Dit kan voor verwarring zorgen. In de GLD-catalogus zijn de verschillende Status Kwaliteitscontroles te vinden. De wens is om in de visualisatie inzichtelijk te maken wat de Status Kwaliteitscontrole is.
104	BM21 09 00316	- Definitieve standen corrigeren wanneer er toch fouten blijken te zijn in de waterstanden is dat mogelijk en zo ja hoe. - Uit de documentatie begrijpen wij dat het momenteel enkel mogelijk is om standen te corrigeren door deze eerst volledig te verwijderen en vervolgens opnieuw met de juiste data (met het zelfde observation id?) aan te bieden aan de BRO. In de documentatie wordt wel gesproken over een specifiek replaceRequest maar deze zit niet in de huidige software. - Is het verwijderen en opnieuw toevoegen met de juiste data echt de juiste manier om eventuele fouten in definitieve standen te corrigeren? Of is men van plan om het replaceRequest daar in de toekomst voor te gebruiken?
103	BM21 09 00249	Graag mijnbouwafval toevoegen aan tabel 12 bijzonder materiaal Dit betreft een wens voor BHR-GT - BMB om mijnbouwafval toe te voegen als domeinwaarde bij het attribuut bijzonder materiaal.
102	BM21 09 00176	Bij GLD000000000005 is geen visualisatie aanwezig. Nu blijkt dat dit komt doordat er geen grondwaterstanden aangeleverd zijn. Het is erg verwarrend dat er wel een tabje 'grondwaterstandonderzoek' getoond wordt.
101	BM21 08 00004	Vanuit Gebruik en Baten zijn wij op zoek naar de gebruikers van BROgegevens. We willen graag aan de mail die je ontvangt na een bestelling een korte tekst toevoegen met de vraag of we de personen mogen benaderen met informatie en of zij mee willen werken aan een enquête. In die tekst zit dan een link naar een formulier en daar kunnen ze hun gegevens op invullen. De exacte tekst wordt nog afgestemd. De gegevens uit het formulier kunnen wij zelf uitlezen, dus daar is voor jullie geen extra werk voor nodig.
100	BM21 08 00255 BM21 09 00364	Uitgifte van leveringen en dataleveranciers – Het huidige bronhouderportaal is al voorzien van webservices en een API waarmee leveranciers hun eigen leveringen op kunnen vragen. Het implementeren van een service (+ machtiging) om de leveringen van alle leveranciers op te kunnen vragen lijkt dan een relatief beperkte en logische stap. voor volledig memo: Memo 21101AEV0.9 - Verschillende leveranciers en de BRO probleem en oplossingen.pdf
99	BM21 08 00254 BM21 09 00364	Controle op dataleverancier bij doorlevering – Voor bronhouders is het bronhouderportaal dé manier om dataleveranciers (en controleurs) te machtigen voor leveringen en/of taken. We stellen voor om de huidige controle op dataleverancier bij (en daarmee blokkade van) doorlevering aan de BRO te laten vervallen. De bronhouder is dan vrij om eigen keuzes te maken voor dataleveringen en dataleveranciers. voor volledig memo: Memo 21101AEV0.9 - Verschillende leveranciers en de BRO probleem en oplossingen.pdf
98	BM21 08 00253 BM21 09 00364	Werkafspraak dataleverancier – Deze richt zich in essentie op het gegevensdefinitieaspect. De administratie van leveringen en dataleveranciers vindt (sinds de komst daarvan) op sluitende en eenduidige wijze plaats in het bronhouderportaal. We stellen als kern van de werkafspraak voor om het attribuut dataleverancier in de BRO zelf te definiëren als afgeleid en dus niet authentiek gegeven (of eventueel geheel te laten vervallen). voor volledig memo: Memo 21101AEV0.9 - Verschillende leveranciers en de BRO probleem en oplossingen.pdf
97	BM21 08 00240	Ik heb de rol van beheerder voor BRO Gelderland Het was mij niet mogelijk om een interne collega ook de rol van controleur te geven, het keuzevakje waarin normaal die drie keuzes worden getoond gaf slechts de optie om een bronhouder te maken. De betreffende collega was in het project al bronhouder. De oplossing die werd aangereikt is om eerst mezelf bronhouder te maken in dit specifieke project. Daarna kreeg ik wel de mogelijkheid om uit de 3 opties te kiezen. Ik heb de collega vervolgens controleur gemaakt. Uw servicedesk medewerker gaf aan dat ik desgewenst nu mezelf weer zou kunnen verwijderen als bronhouder van het project. Graag aanpassing van het systeem zodat deze omweg niet nodig is en ik meteen de 3 keuze optie voorgeschoteld krijg zonder dat ik eerst bronhouder moet worden.
96	BM21 07 00316	Als er maar 1 grondwaterput wordt gedownload via het BROLoket komt er een bestand terug met IMBRO(-A) xml. Hier kunnen onze gebruikers (en burgers) verder niet zoveel mee. (De enige optie is dan om via PDOK de hele datasets te downloaden) Het zou erg handig zijn als er ook een optie is om de download in een geopackage of andere open standaard terug te krijgen. Dat is voor veel gebruikers een werkbaar formaat en vergroot de bruikbaarheid van het BROLoket.
95	BM21 07 00210	Naar aanleiding van het aanleveren van waterstanden aan de demo omgeving hebben wij een aantal problemen en opmerkingen gesignaleerd. Er is een fout met afgekeurde data wat toch wordt weergegeven als goedgekeurde data. Daarnaast blijkt dat het controleren van aangeleverde gegevens op deze manier niet mogelijk is. Het portaal moet ons inziens op een aantal punten worden aangepast. Zie de bijlage.
94	BM21 07 00225	Vitens is geintresseerd in de ideeen en ontwikkelingen die het team in gedachten heeft rond de terugmeldingen. D.m.v. een ticketsysteem zien we kans binnenkomende terugmeldingen (via onze bronhouders) in behandeling te nemen. Toch denken we dat onze dienstverlening er veel op vooruit gaat als we zouden kunnen koppelen d.m.v. webservices.
93	BM21 07 00322	Graag een extra selectie mogelijkheid op bestuurlijke grenzen. Nu alleen zoeken op provincies en waterschappen mogelijk en selectie op polygoon en rechthoek. Praktijk is selectie op bestuurlijke grenzen van gemeenten, provincies en waterschappen gewenst.
92	BM21 07 00301	Melding over bronhoudersportaal (Controle scherm): Niet alle gegevens worden getoond in de grafiek bij boringen BHR-GT Als je de xml bekijkt dan zitten er veel meer gegevens in dan er getoond worden in de grafiek. Je kunt ook geen exacte waarde opvragen in de grafiek waardoor het onmogelijk is om precies de juiste gegeven op te vragen. De kleuren zijn ook niet te onderscheidend. Ziltigzand en zand is beide geel (zie bijlage).
91	BM21 06 00443	Graag zouden wij de waardenlijst willen uitbreiden met de waarde: “Validatieprotocol Evides Waterbedrijf”. Overigens kan ik me voorstellen dat jullie niet voor ieder bedrijf een aparte waarde willen aanmaken, dus jullie zouden kunnen overwegen om een meer algemene waarde toe te voegen in de trant van “volgens vastgesteld overig validatieprotocol”. Maar dat laat ik aan de BRO-organisatie zelf. In alle gevallen kan een BRO-gebruiker het bewuste protocol uiteraard gewoon opvragen.
90	BM21 07 00124	In opvolging van een eerder vooraankondiging zijn voor het model Geomorfologisch Kaart (GMM) nu de voorstellen voor wijzigingen nader uitgewerkt. In de bijlage zijn alle wijzigingen nader gedetailleerd en in een concrete werkafspraken vertaald. Indien onze voorstellen worden opgevaolg voorzien we het werkveld graag mee een aangepast werkversie van de catalogus, zodat de gehele datastructuur eenvoudig en up-to-dat kan worden geraadplaagd. Graag willen we de data van de eerstvolgende update van de GMM-data, waarvoor de levering die nu in voorbereiding is samen met de publicatie in Q3 afgerond hebben zodat de gebruiker ook van de meest actuele data gebruik kan maken.
89	BM21 07 00106	Wens is: handleiding mapping van GEF naar IMBRO/A
88	BM21 05 00170	In de catalogus "20190507_catalogus_bodemkundig_wandonderzoek_1.pdf", pagina 117, paragraaf 3.46.2 bepalingsprocedure en paragraaf 3.46.3 bepalingsmethode Regel: 3.46.2 IMBRO/A: "Naast de IMBRO waarden mag de waarde van het attribuut ook gelijk zijn aan onbekend Wijzigingsverzoek: 3.46.3 bepalingsmethode: Als procedure onbekend is, mag methode leeg zijn als dataregel. Dus cardinaliteit aanpassen naar [0..1] Extra informatie: Issue is besproken met WENR in jan-feb '21. Afgesproken dat dit geen werkafspraak wordt maar opgepakt wordt in een volgende versie. Dit moet dus op de backlog van standaardisatie voor een volgende versie.
87	BM21 06 00358	Vandaag kregen we 43 sonderingen, 13 geotechnische boringen en 5 putten tegelijk aangeleverd. Voor iedere sondering, boring of put kwam er een afzonderlijke notificatie binnen, dus dat waren 61 mails. Dit is natuurlijk vrij uitzonderlijk, maar als de notificaties per soort registratieobject gecombineerd zouden kunnen worden, dan zou dat fijn zijn. Eén notificatie per project is wat mij betreft ook goed, ook al worden er verschillende registratieobjecten aangeleverd. Ik hoor graag of zo’n instelling mogelijk is. Extra informatie servicedesk: Naar verwachting zullen in de loop van 2021 steeds meer bronhouders dagelijks leveringen ontvangen van GLD. In het verzoek graag rekening houden met het kunnen selecteren welke notificaties je wel wilt ontvangen (beoordeelde GLD'sn) en welke notificaties niet (voorlopige GLD's).
86	BM21 05 00171	In de catalogus "20190507_catalogus_bodemkundig_wandonderzoek_1.pdf", pagina 13, entiteit 57 Watergehalte en doorlatendheid bij bepaalde bodemvochtpotentiaal. Wijzigingsverzoek: bodemvochtpotentiaal cardinaliteit [1] -> correct volumetrisch watergehalte cardinaliteit [1] -> veranderen naar [0..1] waterdoorlatendheid cardinaliteit [0..1] -> correct Let op: ook datarecord moet worden aangepast Extra informatie: Voor de het aanleveren van meetreeksen voor bepalingen voor SFR/BHR-P is in het technisch ontwerp gekozen dit te implementeren als SWE Data records. Een Swe Data Record bevat de data als een reeks getallen met een verwijzing naar een extern XML bestand waarin de structuur is gedefinieerd. Een voorbeeld (voor een krimpbepaling maar ik had even niets anders) <ns4:shrinkageDetermination> <ns9:ShrinkageDetermination ns2:id="wenr.sr.PFB-8654.002"> <ns9:determinationProcedure codeSpace="urn:bro:sr:DeterminationProcedure">schuifmaat</ns9:determinationProcedure> <ns9:determinationMethod codeSpace="urn:bro:sr:DeterminationMethod">aantalD2</ns9:determinationMethod> <ns9:disturbed>nee</ns9:disturbed> <ns9:temperature uom="Cel" xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/> <ns9:shrinkage> <ns10:DataArray id="wenr.sr.PFB-8654.003"> <ns10:identifier>Krimptoestand</ns10:identifier> <ns10:elementCount> <ns10:Count> <ns10:value>3</ns10:value> </ns10:Count> </ns10:elementCount> <ns10:elementType name="Krimptoestand" ns5:href="https://schema.broservices.nl/xsd/srcommon/1.0/ShrinkageState.xml"/> <ns10:encoding> <ns10:TextEncoding collapseWhiteSpaces="true" decimalSeparator="." tokenSeparator="," blockSeparator=";"/> </ns10:encoding> <ns10:values xsi:type="ns10:EncodedValuesPropertyType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">1130.9,653.7,8.0,10.2;1048.7,NaN,7.9,9.6;883.0,NaN,7.8,9.4</ns10:values> </ns10:DataArray> </ns9:shrinkage> </ns9:ShrinkageDetermination> </ns4:shrinkageDetermination> De waarden zijn dus 1130.9,653.7,8.0,10.2;1048.7,NaN,7.9,9.6;883.0,NaN,7.8,9.4. De velden zijn komma gescheiden en de records zijn gescheiden door een ;. Voor de betekenis van de waarden en eventuele missing value indicatoren moet je in https://schema.broservices.nl/xsd/srcommon/1.0/ShrinkageState.xml kijken (dit is wat ik bedoelde met ‘het datarecord moet worden aangepast’. In deze XML staat de volgorde van de velden gedefinieerd maar tevens welke waarde moet worden opgenomen als een element geen waarde heeft. Omdat in de meetreeks horend bij de bepaling Watergehalte en doorlatendheid bij bepaalde bodemvochtpotentiaal een wijziging wordt aangebracht : volumetrisch watergehalte cardinaliteit [1] -> veranderen naar [0..1] moet voor dit element dus een missing value worden toegevoegd.
85	BM21 06 00469	https://www.bro-productomgeving.nl/bpo/latest/grondwatermonitoring/grondwaterstandonderzoek-gld/gld-berichtencatalogus-uitgiftewebservice Het aantal meetwaardeparen in het antwoord wordt beperkt tot maximaal 2500 als het gegeven observationPeriod (periode van monitoring) niet aanwezig is. Dit lijkt arbitrair. Zeker als je bedenkt dat er bij inname series van 10000 meetwaarde paren worden aangeleverd. Als deze regel is om het systeem te beschermen, dan klopt hij niet. Wellicht moeten we limiteren op een slimmere manier. We kunnen niet het aan meetwaardeparen tellen. Maar we kunnen wellicht wel op KB's limiteren. Impact bouw en uitgifte specificatie. Bouw denkt na over oplossing, specificatie volgt.
84	BM21 06 00460	In de catalogus "20190507_catalogus_bodemkundig_wandonderzoek_1.pdf", pagina 123, paragraaf 3.49 Bepaling waterretentiestapsgewijs Ringmonster gebruikt: IndicatieJaNee. Het is bij IMBRO/A niet altijd bekend of er een ringmonster is gebruikt, Wijzigingsverzoek Ringmonster gebruikt: IndicatieJaNee vervangen door IndicatieJaNeeOnbekend
83
82	BM21 06 00382	ObservationMetadata:principalInvestigator: value not nillable. Het is niet mogelijk de waarde weg te laten, de xsd heeft hiervoor geen voorzienning. Onze interpretatie van de regel is dat als de waarde ontbreekt, het ook niet bekend is of het om een KvK-nummer of ECRN gaat, en dat de constructie in het innameverzoek als volgt moet zijn: ... Oplossingsrichtin: pas de XSD aan zodat het element nillable kan zijn Screenshot issue 121
81	BM21 06 00381	"Moet er niet gecontroleerd worden of de meetnet(ten) (BRO-ID) en buis (=BRO-ID van de put + buisnummer) die in een registratieverzoek worden aangeleverd in de BRO bekend zijn? Een dergelijke controle is doorgaans gebruikelijk, om in elk geval te voorkomen dat er aan een niet bestaand RO wordt gerefereerd." Beschrijving: Er is geen expliciete regel op bestaan van GMW put/buis en GMN. Er staat nu wel in de toelichtende tekst dat daarop gecontroleerd wordt maar het is niet als regel opgenomen in de gegevensdefinitie of in de berichtencatalogus. Ook is de controle niet gebouwd. GLD hangt aan GMW. Regel catalogus en controle op GMW moet worden gebouwd. Validatieregel GLD naar GMN is niet gebouwd. Belangrijke entiteiten bij grondwaterstand onderzoek. Verwacht regel in de gegevensdefinitie (goede toevoeging en niet geformuleerd) en staat niet in 3.8 van de catalogus. Screenshot issue 120
80	BM21 06 00376	Beschrijving: Kardinaliteiten verkeerd. Referentie-by-ID is mogelijk. Echter 5.3.8.2 meetprocedure, 5.3.8.3 type meetinstrument, 5.3.8.5 procestype, 5.3.8.6 beoordelingsprocedure hebben allen kardinaliteit 1 en zijn daarmee verplicht. Dit is een gegevensinhoudelijke inconsistentie. Observation verwijst (linkt) naar proces, maar kan ook via 'Reference by ID' doen. In dat geval noem je dan niet de meetprocedure, meetinstrument en procestype. Daarmee is de kardinaliteit gelijk aan 1 en dat klopt dus niet als je reference by ID doet (want dan moet het 0 zijn). CAB: Impactanalyse oplossing in volgende catalogus. Afhankelijk hoe het wordt aangeleverd is het de (gegevens) catalogus of meer de berichtencatalogus.
79	BM21 06 00375	Redactionele lijst GLD catalogus.
78	BM21 06 00374	De Github issues 109 en 110 gaan over de toepassing van WaterML. Dat is bij enkele details niet goed gegaan in het conceptuele model. Dit houdt in dat het Conceptuele model en vervolgende Gegevenscatalogus aangepast moeten worden. Het Logisch model en de daarvan afgeleide XSD-bestanden zijn wel goed. In de Berichtencatalogus staan de afwijkingen tussen WaterML en de Gegevenscatalogus beschreven. Dus moet de Berichtencatalogus redactioneel aangepast worden nadat de Gegevenscatalogus inhoudelijk is aangepast. De opmerking is begrijpelijk dat de Berichtencatalogus consistent moet zijn met de Gegevenscatalogus. Echter zoals opgemerkt in issues 109 en 110 is de Gegevenscatalogus niet consistent met WaterML (een externe standaard). De XSD’s en de Berichtencatalogus zijn wel consistent met WaterML. De inconsistentie tussen de Berichtencatalogus en de Gegevenscatalogus wordt veroorzaakt doordat de Gegevenscatalogus niet consistent is met WaterML. Dus moet naar Han zijn mening de Gegevenscatalogus aangepast worden. Toentertijd heeft Han deze inconsistienties tussen de Gegevenscatalogus en WaterML al opgemerkt, maar hij mocht geen werkafspraak op (laten) stellen. In plaats daarvan mocht hij de afwijkingen tussen de Gegevenscatalogus en WaterML wel aanduiden in de Berichtencatalogus. (WaterML is nog niet verwerkt in de catalogus en veel mensen werken niet daarmee (WaterML)). Oplossingsrichting: Associatie relatie van/naar Observatie vervangen door een associatie relatie van Observatie naar Observatiecontext (ObservationContext) en vandaar met een associatierelatie naar Observatie. Screenshot issue 109 Screenshot issue 110 Met betrekking tot 3.6 en 3.7 Definieer een gegevensgroeptype BenoemdeWaarden (NamedValues). Met een verplicht attribuut naam (name) van het type Referentie (Reference). Met een verplicht attribuut waarde (value) van het type Willekeurig (Any). Voeg aan entiteit Metadata Observatie toe een gegevensgroep met de naam parameter en als type het gegevensgroeptype BenoemdeWaarden (NamedValues). Verwijder het attribuut observatietype uit de entiteit Metadata Observatie. Verwijder het attribuut identificatie uit de entiteit Organisatiegegevens. Voeg toe een Regel aan de entiteit Metadata Observatie: De lijst met parameters moet een vookomen hebben met als naam de referentie 'observationType', waarbij het type van het attribuut value de codelijst ObservatieType is. Voeg toe een Regel aan de entiteit Metadata Observatie: De lijst met parameters moet een vookomen hebben met als naam de referentie 'principalInvestigator', waarbij het type van het attribuut value het domien Organisatie is. Soortgelijke aanpassingen zijn nodig voor 3.8 en 3.11. Opmerking: In de berichtencatalogus staat hoe dit aangepast zou moeten worden Voor issue 113 geldt hetzelfde als issue 110. De in issue 113 genoemde waarden komen uit de codelijsten “CensoredReason”, “InterpolationType” en “ProcessType” uit WaterML. Deze externe standaard kunnen wij niet zomaar aanpassen. De waarden uit deze codelijsten zijn niet goed opgenomen in de Gegevenscatalogus, waardoor deze inconsistent is met WaterML. Screenshot issue 113 Attribuut 5,3,10,1 tijdstip meting Inconsistentie toepassen bedrijfsregels. Annex A van Part 1 - Timeseries OGC WaterML lijkt een aantal regels te stellen. Hiervan is alleen de "kop/staart" regel overgenomen in de catalogus. Screenshot issue 117
77	BM21 06 00325	Bij Fugro wordt bij sommige projecten een steekapparaat gebruikt (Folie sampler) waarvan de maatvoering momenteel niet binnen de marges vallen zoals in de BRO aangegeven bij het attribuutsteekmonddiameter. Dit betekent dat dergelijke booronderzoeken momenteel niet aangeleverd kunnen worden. Het betreft de maatvoering van de steekmonddiameter. Deze heeft een waardebereik van 50 tot 510 en zou gewijzigd moeten worden naar 40 tot 510. *6.3.14.8 steekmonddiameter* Type gegeven Attribuut van Bemonsteringsapparaat Definitie De grootste uitwendige diameter van de steekmond. Juridische status Authentiek Kardinaliteit 0..1 Domein Naam Meetwaarde 3.0 Eenheid mm (millimeter) Waardebereik 50 tot 510 Regels Het attribuut moet aanwezig zijn wanneer de waarde van het attribuut apparaattype gelijk is aan steekbus, steekbusDLDS of steekbusMetLiner. Het attribuut mag niet aanwezig zijn in alle andere gevallen.
76	BM21 06 00296	In het Bronhouderportaal is het overzichtsscherm van een levering identiek voor een bronhouder en dataleverancier. De bronhouder ziet in de lijstweergave van een levering het verzoekkenmerk (referentie) van de leverancier in zowel de kolom als in het overzicht wanneer je een levering openklapt. Daarnaast is de referentie van de leverancier te zien onder de grafiekweergave. De wens luidt als volgt: Als dataleverancier wil ik dat mijn opdrachtgever (bronhouder) en een eventuele externe controleur het Object-ID van de bronhouder te zien krijgen in de lijstweergave en grafiekweergave, op de plek waar nu de referentie van de dataleverancier staat. Motivatie: de bronhouder herkend het registratieobject op basis van zijn eigen Object ID, maar is niet bekend met de (interne) referentie van de dataleverancier. Het “verzoekkenmerk” (referentie dataleverancier) en “Object-ID bronhouder” dat je te zien krijgt onder Transactiegegevens als je een levering openklapt graag laten staan.
75	Wiertsema-Inpijn-Blokpoel V.O.F.	Er is vanuit de NEN/VOTB te kennen gegeven dat er momenteel gewerkt gaat worden aan een nieuwe versie van de NEN-EN-ISO 22476-1. Welke veranderingen deze nieuwe versie met zich meebrengen t.b.v. de uitwisseling van gegevens is nog niet duidelijk. Momenteel lopen de wijzigingen nog op ISO niveau. Wanneer het daar is afgestemd moet dit nog op NEN-EN-ISO niveau worden vastgesteld. De verwachting is dat de nieuwe versie van de NEN-EN-ISO Norm in Q1 van 2022 wordt geconsulteerd en afhankelijk van de feedback vervolgens wordt vastgesteld. Hierna volgt implementatie in de branche en wil men zo snel mogelijk aanleveren. De gedachten m.b.t. de implementatie impact wordt als beperkt ingeschat wat betekend dat men vermoedelijk snel wil gaan leveren.
74	Wiertsema-Inpijn-Blokpoel V.O.F.	Er is vanuit de NEN/VOTB te kennen gegeven dat er momenteel gewerkt gaat worden aan een nieuwe versie van de NEN-EN-ISO 14688-1. Belangrijkste veranderingen welke momenteel in gedachten zijn betreffen: - Uitbreiding van de norm met een klasse 4 met name t.b.v. beschrijvingen met een hydrologisch karakter - Uitbreiding van de norm met de inhoudelijk invulling van de klasse 1 met name t.b.v. de offshore booronderzoeken De verwachting is dat de Norm uitbreiding in Q1 van 2022 wordt geconsulteerd en afhankelijk van de feedback vervolgens wordt vastgesteld. Hierna volgt implementatie in de branche en wil men zo snel mogelijk aanleveren.
73	BM21 05 00198 BM21 05 00129	Onze gebruikers hebben toch wat moeite om het BROloket te vinden en te raadplegen. Wij gebruiken als GEO-viewer de applicatie Geonovation. Daarin hebben wij een laag toegevoegd BRO en daarin hebben wij bij de sonderingsgegevens opgenomen. We kunnen echter alleen de Kenset laten zien. Het zou mooi zijn als er ergens in die Kenset een URL ingebouwd kan worden die direct naar de betreffende punt verwijst in het BRO loket. OP die manier hebben we bijvoorbeeld ook de lokale bekendmakingen gekoppeld. Als dit kan is het namelijk ook mogelijk om de grafieken te zien van de sondering. Dit zal het gebruiksgemak sterk verbeteren. In de bijlagen een voorbeeld zoals we dat hebben gedaan met bekendmakingen uit gemeenteblad/staatscourant. Door uiteindelijk op de link te klikken wordt je doorverwezen naar het bericht in de staatscourant/gemeenteblad Bijlage 1 Bijlage 2
72	BM21 05 00168	In de catalogus "20190507_catalogus_bodemkundig_wandonderzoek_1.pdf", pagina 59, paragraaf 3.16.14 rijpingsklasse Regel: Het attribuut moet aanwezig zijn wanneer de waarde van het attribuut bodemkundige grondsoort gelijk is aan kleiarmSilt, kleiigSilt, lichteKlei, matigLichteZavel, matigZwareKlei, siltigeLeem, zandigeLeem, zeerLichteZavel, zeerZwareKlei of zwareZavel. Het attribuut mag niet aanwezig zijn in alle andere gevallen. Verzoek tot wijziging: Aan bovenstaande lijst moet "kleiigeLeem" worden toegevoegd.
71	BM21 05 00167	In de catalogus "20190507_catalogus_bodemkundig_wandonderzoek_1.pdf", pagina 14, entiteit 58 Modellering van hydrofysische karakteristieken: - bepalingsID: Bepalingscode [1..] De cardinaliteit moet veranderen bepalingsID: Bepalingscode [1..] moet worden [0..*]. Toelichting: Soms worden geen aanvullende data in de fit gebruikt tov de verdampingsgegevens.
70	BM21 05 00174	Zie bijvoorbeeld GLD000000000101: Op het tabblad Grondwaterstandsonderzoek (bij een GMW weergave) wordt nu rechtsboven, bij de buisselectie knop, de waarde van de diepte (hoogte) bovenkant monitoringbuis getoond; het is logischer om daar de positie van de bovenkant filter van de monitoringbuis te tonen
69	BM21 04 00175	Horizontcode "Of" is alleen toegestaan bij strooisellagen en deze kunnen niet geregistreerd worden onder maaiveld. zie bijlage In de praktijk komt het een enkele keer voor dat door een verwerking strooisel als een laagcomponent dieper in het profiel is gebracht. In dat geval kan strooisel nu niet in de registratieobjecten worden opgenomen. Voor deze laatste situatie, namelijk strooisel als een laagcomponent en dus beneden maaiveld, zou een oplossing bedacht moeten worden.
68	BM21 04 00037	Nadat je op de kaart hebt geklikt verschijnt een pop-up met de gevraagde informatie. Helaas verschijnt die pop-up vaak midden op de kaart, waardoor relevante kaartpatronen niet meer zichtbaar zijn. Oplossing: opdelen van het scherm in meerdere (vaste of fluid) panelen: 1 voor de kaart en 1 voor de legenda. Dat oogt enerzijds veel rustiger (de pop-ups, met variabele grootte zijn immers niet meer nodig) en bovendien hou je overzicht.
67	BM21 04 00124	Op verzoek van/namens het DINO-BRO migratieteam Ook wij hebben voor de migratie van Gw-standen van DINO naar BRO de behoefte aan een “alles-in-één-bericht” voor historische GMN’s ‘a-la GMW’, waarmee het mogelijk wordt om met 1 bericht een historisch GMN te registreren met alle meetpunten ( GMW buis verwijzingen) die na startdatum van het GMN zijn ontstaan. Dit ter vervanging van het huidige noodzakelijke aanleverproces voor het vullen van een historisch GMN waarbij eerst een GMN startregistratie bericht (met bekende start datum) moet worden geregistreerd met daarin de meetpunten die bij de start GMN aanwezig waren, gevolgd door successievelijke en volg ordelijk kloppende aanvullingsberichten (één per meetpunt) voor ieder toegevoegd meetpunt op de datum waarop de betreffende GMW is ingericht.
66	BM21 04 00122	Deze werkafspraken worden nu vastgelegd en gecommuniceerd dmv een spreadsheet. Alhoewel dit wel enige duidelijkheid verschaft, blijkt het toch dat voor de inhoudelijk deskundigen deze werkafspraken moeilijk te lezen zijn. Wij pleiten ervoor dat er een beta versie van de catalogi komt waarin de werkafspraken zijn geïntegreerd. Hierdoor is er maar 1 document nodig waarop zowel de domeindeskundigen als de software engineers kunnen terugvallen bij het controleren van voorwaarden waaraan de data moet voldoen.
65	BM21 04 00112	Waternet hanteert voor grondwaterstanden eigen meet- en beoordelingsprocedures die niet (volledig) overeen komen met de bestaande waardes in de BRO-catalogus. Verzoek om de BRO-GLD codelijsten 6.2 Meetprocedure en 6.6 Beoordelingsprocedure aan te vullen met waardes die verwijzen naar procedures bij Waternet (iets in de trant van waternetMeetprocedure2021 en waternetBeoordelingsprocedure2021). Extra informatie 18 mei 2021: De behoefte is helder en legitiem; het betreft een gewenste uitbreiding van 2 waardelijsten van de GLD gegevensinhoud: die van meetprocedure en van beoordelingsprocedure. Aanpassingen aan de gegevensinhoud GLD vergen op dit moment echter een formeel juridisch proces (incl. publieke consultatie). Deze gewenste uitbreiding van de GLD gegevensinhoud kan dus nu alleen in een formele nieuwe release van de GLD standaard, waarbij een aantal uitbreidingen/aanpassingen 'in opgeboste vorm' zullen worden 'verwerkt'. Momenteel is er nog geen concreet zicht op wanneer een nieuwe release van de GLD standaard wordt opgepakt. De gewenste uitbreidingen van de waardelijst van meetprocedure en beoordelingsprocedure moeten daarom op de backlog worden geplaatst.
64	BM21 02 00072	In samenwerking met een studente van de WUR probeer ik wat boorgegevens te gebruiken die ik uit dinoloket haal; het gaat in dit geval om BRO-xml data van wat bodemkundige boringen. De grafische weergave (zie onder) is echter niet voldoende, ik wil de volledige beschrijving in een werkbaar formaat gebruiken. Na het downloaden van de BRO-xml, waar wel data instaat die ik nodig heb (zoals grindgehalteklasse e.d.,). Nu probeer ik een tool te vinden, vergelijkbaar met Profiler, om deze data in een leesbaar formaat weer te geven. XML is prima voor opslag en uitlevering, maar onmogelijk te lezen. Voor DINOdata is Proflier met wat handigheid prima geschikt en kan daar best mee gewerkt worden; een update zou wel fijn zijn voor stabiliteit en duidelijkheid, maar het gaat. Mijn wens voor de BRO gegevens is voor een simpele weergave van een volledige boorbeschrijving van de verschillende BHR registratieobjecten. Het doel daarvan zijn geen analyses of gespecialiseerde werkzaamheden, maar het kunnen lezen van de informatie van BHR registratieobjecten voor iedere gebruiker: publiek, specialisten, ambtenaren, iedereen. Mijns inziens zou in de datalevering na een bestelling van BHR-gegevens van een uitgeschreven beschrijving in de vorm van een PDF, waar van een specifiek object alle gegevens volledig en uitgeschreven zijn in tekst. Hierbij gaat het om zowel de gegevens van het booronderzoek zelf als het boorprofiel en daaronder hangende boorbeschrijving(en). Om een parallel met de modellen te trekken: deze zijn voor de gemiddelde gebruiker niet te hanteren zonder specialistische software; om deze toch beschikbaar te stellen voor mensen zonder deze software, wordt bij het opvragen van modellen de SubSurfaceviewer meegeleverd, waarmee dit voor iedereen bruikbaar is. Zoals we nu gegevens beschikbaar stellen van booronderzoek, is dit niet leesbaar zonder specialistische software. Graag ga ik in verder gesprek hierover, ook over de vorm en opbouw van een makkelijke, leesbare vorm.
63	BM21 03 00190	Mijn vraag behelst of de onterecht gegenereerde putcodes alsnog kunnen worden veranderd / gecorrigeerd. Ik begrijp dat dat nu (nog) niet kan. Mijn vraag dient derhalve te worden omgevormd tot een formeel verzoek om dit mogelijk te maken. Bij de aanlevering afgelopen zomer van onze organisatie (ordegrootte 4000 GMW putten) is bij een flink aantal putten verzuimd de NITG-code mee te geven. Achteraf is aan onze kant wel duidelijk hoe dat zo gekomen is - onvolledige data in de database. Ooit hebben wij enkele duizenden NITG-codes toegekend gekregen maar die zijn maar voor een klein deel doorgevoerd in de eigen database. Die NITG-codes wensen wij alsnog te reanimeren. Wat niet hielp is dat vanuit de BRO bij aanlevering alleen een betekenisloos BRO-ID terug kwam maar niet de gegenereerde putcode; was die wel meegekomen dan hadden we dit al veel eerder in de gaten gehad. Het betreft 35 GMW-putten met foute BRO putcodes. De overgrote meerderheid van de NITG-codes blijkt goed te zijn overgekomen.
62	BM21 04 00091	We hebben een boring waarbij een steekbus is gebruikt met 38mm steekmonddiameter. Deze willen we leveren aan BRO, maar dat gaat niet omdat de waarde tussen 50 tot 510 moet liggen. Ons verzoek is de waarde bereik veranderen, zodat we de boring wel kunnen aanleveren. Het gaat om 20 boringen, die nu tijdelijk niet geleverd kunnen worden. Ik zal nog even navragen of er nog kleinere formaten bestaan. Maar het is geen uitzondering dat deze formaat gebruikt wordt.
61	BM21 04 00056	Is er ook een zogenaamde API waarmee ik appelboor data kan opvragen? Dus dat ik een request doe met een x en y en dat ik dan een profiel terugkrijg met lithoklasse voor verschillende dieptes en met kansen op lithoklasses
60	BM21 03 00081	In het broloket kun je filters gebruiken. Bij Bodem- en grondonderzoek is een diepte filter. Laagste waarde is 0 maar vanuit WENR zijn profielen geleverd met informatie op het maaiveld , dus diepte < 0. Ik bedoel dat er soms lagen zijn (bladerstrooisel etc) die boven de harde grond liggen. Deze lagen hebben dieptes < 0. Booronderzoeken waarbij dit van toepassing is: BHR000000335910 BHR000000335910 BHR000000335958 BHR000000335958 BHR000000335958 BHR000000335962 BHR000000335768 BHR000000335768 BHR000000335768 BHR000000335809 BHR000000335809
59	BM21 04 00015	Bij PDOK zijn wij bezig om een nieuwe manier te implementeren voor metadata bestanden. Tot op heden gaven wij bij elke download een pdf/word file mee met documentatie of metadata. Dat is eigenlijk niet heel efficient. Bij elke vernieuwing gaan wij daarom een websitepagina maken met daarop de documentatie of metadata. In de download zetten wij dan hyperlinkjes naar die pagina’s. Omdat de BRO-downloads nu ook deze bijlagen kennen is het wellicht een idee om dit ook bij de BRO zo in te richten?
58	BM21 04 00030	Als dataleverancier wil ik leveringen in de demo omgeving van het bronhouderportaal kunnen verwijderen (archiveren), zodat ik al mijn tests met een schone lei kan beginnen.
57	BM21 04 00023	Ik had de vraag of het mogelijk is twee sondeeronderzoeken toe te sturen in PDF en GEF- bestand? Ik kan alleen de grafiek downloaden.
56	BM21 03 00191	Bij aanlevering van een "nieuwe" GMW-put kan een NITG-code worden meegegeven. De gegenereerde putcode bevat dan het putnummer van de oorspronkelijke NITG-code. Is het ook mogelijk, of kan het mogelijk gemaakt worden, om ook RGD-nummers van boringen mee te geven zodat de BRO-putcode wordt gebaseerd op het RGD-nummer van de boring?
55	BM21 03 00094	Een correctie gaat in dit geval fout omdat een recenter aangeleverd bericht door de BRO eerder wordt verwerkt dan een ouder bericht. Omdat een correctie van grondwaterstanden momenteel uit 2 berichten moet bestaan (‘deleteRequest’ van de ‘oude’ + een “Registration’ van de ‘correcte’ standen) is het van belang dat het eerst aangeleverde bericht (delete) eerst wordt verwerkt en dan pas de aanvulling (registratie). In mijn voorbeeld werd eerst de registratie uitgevoerd wat tot een foutmelding leidt dat de observatie al aanwezig is. Dus kort samengevat: ik lever aan in de juiste volgorde maar de BRO verwerkt in een andere volgorde.
54	BM21 03 00156	In 2019 zijn de putten door Leverancier X in opdracht van RWS aangeleverd aan de LV BRO waarbij aanvullende attributen zijn opgenomen en attributen zijn gecorrigeerd. Per abuis zijn deze putten bij de DINO conversie van alle RWS putten nogmaals aangeleverd in 2020. Een check op NITG-code kan dat voorkomen, misschien kan dat bij het aanbieden van putten aan de LV BRO meegenomen worden.
53	BM21 03 00188	Waar we tegenaan lopen is het feit dat het niet mogelijk is om een uitdraai te genereren op basis van BRO-ID. Je kunt in het bronhouderportaal zoeken op BRO-ID en per BRO-ID bekijken welke info in de BRO staat, maar het is een omslachtig proces om op die manier putten bij langs te gaan. Wat: Een mogelijkheid om op basis van BRO-ID's een Excelsheet te genereren met daarin de putinfo per BRO-ID. Helemaal mooi zou zijn als er ook een link naar de grafiek in wordt opgenomen. Hoe: Ik wil een hele rits BRO-ID's kunnen opgeven om vervolgens in een spreadsheet alle in de BRO bekende info per BRO-ID weergegeven te krijgen.
52	BM21 03 00100	Notatie van een tijdstip, vergelijk met een datum Allereerst is de term datumdeel discutabel. Neem bijvoorbeeld 12 juni 2014. De tijd kan worden genoteerd in wintertijd en in zomertijd. Maar we hebben het over dezelfde datum (en hetzelfde tijdstip in UTC). 2014-06-11T23:30:00+01:00 == Jun 12, 2014, 12:30:00 AM 2014-06-12T00:30:00+02:00 == Jun 12, 2014, 12:30:00 AM Te controleren: https://www.timestamp-converter.com/ Dus, als ik een vergelijk met een volledige datum, dan zou 2014-06-11 in aanmerking komen, maar ook 2014-06-12. Ik denk dat de tekst rond het vergelijk van het datum deel genuanceerd moet worden tot: "De waarde van het attribuut moet gelijk zijn aan het datumdeel van het attribuut tijdstip resultaat van de entiteit Observatie. De tijdstipnotatie wordt gecorrigeerd voor juiste tijdzone conform de op die datum geldende zomer / wintertijd. Pas daarna wordt het aldus ontstane datumdeel gebruikt voor vergelijk." Toelichting Beide onderstaande tijdstipnotaties betreffen een datum 12 juni 2014 2014-06-11T23:30:00+01:00 == Jun 12, 2014, 12:30:00 AM 2014-06-12T00:30:00+02:00 == Jun 12, 2014, 12:30:00 AM
51	BM20 11 00009	Deel van oorspronkelijk wijzigingsverzoek volgnr. 16. Er zijn twee concrete gegevensinhoudelijke wijzigingsverzoeken op de huidige GMW gegevensinhoud: - het 'loslaten' van de constraint van het attribuut 'putstabiliteit' op de gebeurtenissen 'nieuweBepalingMaaiveld en nieuweBepalingPosities - het toevoegen van een waarde in de waardelijst 'methodePositiebepalingMaaiveld': afgeleidVerschilmaaiveldBovenkantBuis Ten aanzien van de werkafspraak inmeten GMW is de conclusie dat de in deze werkafspraak gebruikte term 'inmeten' beter vervangen kan worden door de term 'nameten'. De 2 additionele gebeurtenissen die in de werkafspraak worden beschreven, betreffen immers hoogtemetingen die worden gedaan gedurende de levensduur van een GMW, na het inrichten van de put. Het initiële 'inmeten' is onderdeel van het inrichtingsproces van de put, dat leidt tot registratie in de BRO van gegevens middels een inrichtingsdocument.
50	BM21 03 00098	zie overzichtstabel , daar volledige tekst opgenomen
49	BM20 12 00056 BM21 03 00011	1e verzoek (Gebruikersplatform BZK): De downloads op Downloads - PDOK functioneren op 3 verschillende manieren: 1) De zip downloadt direct bij het indrukken van de download-knop (BHR-P, GMW) 2) Je komt op een aparte download-pagina waar je nogmaals op het RO moet drukken, waarna je wéér op een aparte downloadpagina komt (CPT, SFR, BHR-GT, GMM, GLD, GMN, GAR) 3) Je krijg een XML-bericht te zien (DGM, GeoTOP, HGM, SGM) 2e verzoek (PDOK): Wij kregen via geoforum vragen over het gebruik van de SLD en de readme in deze download. We constateren dat de readme spreekt over een ander geopackage dan er wat naam betreft in zit. Kan dit aangepast worden? Ik zie inderdaad dat er een readme in zit, en in die readme word er verwezen naar een geopackage met de naam BRO-GMM-ViewServiceData-GEOM50000-V2019-2-31.gpkg Eigenlijk hebben ze het erover dat er twee in moeten zitten. BRO-GMM-DownloadServiceData-GEOM50000-V2019-2-31.gpkg en BRO-GMM-ViewServiceData-GEOM50000-V2019-2-31.gpkg Wat ze aanleveren bij ons is bro-geomorfologischekaart.gpkg Dit is ook besproken met de intake als het goed is, zo richten we dan onze services in. Wij willen geen datums in de naam van de gpkg. Op het moment dat er een atom service word ingericht, word de naam van de gpkg ook besproken. En deze word dan geconfigureerd zodat we weten wat er in en uit gaat. Het lijkt me dan ook verstandig dat ze de readme aanpassen naar een generieke bestands naam. Want op het moment als hun bijvoorbeeld wel een aanlevering doen en in die aanlevering zit een gpkg met een andere naam dan wat wij hebben geconfigureerd zal deze update falen. De Atom link is deze: https://service.pdok.nl/bzk/bro-geomorfologischekaart/atom/v1_0/brogeomorfologie.xml
48	BM21 02 00150	In de catalogus van GMW (https://bro-productomgeving.nl/bpo/latest/grondwatermonitoring/grondwatermonitoringput-gmw/catalogus-gmw) staat bij het attribuut “Maaiveld stabiel” de volgende omschrijving: “De aanduiding die aangeeft of de grondwatermonitoringput, naar het oordeel van de bronhouder, in een gebied ligt waar de positie van het maaiveld veranderlijk is”. In de XML wordt echter de aanduiding “groundLevelStable" gebruikt. Begrijp ik het nu goed dat je, als het antwoord op de omschrijving “Nee” is, in de XML “ja” in moet vullen? Dat zou wel erg verwarrend zijn. Hetzelfde probleem doet zich voor bij “VariableDiameter”. De omschrijving is “De aanduiding die aangeeft of de diameter van de monitoringbuis over de gehele lengte hetzelfde is”. “hetzelfde” moet “variabel” zijn, volgens mij...
47	BM21 03 00047	Bij deze zou ik een verzoek willen indienen om bestaande reeds aangeleverde grondwaterobservaties middels een ‘replaceRequest’ te kunnen corrigeren indien dit nodig is. Volgens de catalogus zou de huidige werkwijze om een GLD-observatie te corrigeren bestaan uit het versturen van een ‘deleteRequest’ met gegevens van het originele brondocument, gevolgd door een ‘registrationRequest’ met de juiste gegevens. Dus 2 berichten om een correctie uit te voeren. Dit wijkt af van de manier hoe binnen andere domein objecten kan worden gecorrigeerd (bijv. GMW, GMN) en waarbij wel de mogelijkheid bestaat om met één ‘replaceRequest’ bestaande gegevens te corrigeren. // Met de huidige versie van de GLD innamewebservice kunnen fouten in de geregistreerde gegevens // van een Observation (Observatie) niet met één BRO-verzoek worden gecorrigeerd. // In plaats daarvan moet eerst de Observation (Observatie) met foute gegevens worden verwijderd met een deleteRequest (verwijderverzoek), // waarna dezelfde Observation (Observatie) met gecorrigeerde gegevens met een // registrationRequest (registratieverzoek) opnieuw moet worden aangeboden.
46	BM21 03 00015	Namens en in overleg met het platform meetnetbeheerders van de provincies zou ik bij deze graag een verzoek indienen voor het vermelden van de bronhouder in de basisgegevens van de put (GMW) op BROloket. Achtergrond van dit verzoek is dat dit het voor meetnetbeheerders eenvoudiger zou maken om de herkomst van een put te achterhalen, indien daar vragen over zijn.
45	BM21 03 00002	Het is correct dat geo-ohm-kabels altijd aan peilbuizen zijn gekoppeld. De geo-ohm-kabels liggen geografisch op dezelfde plek als een peilbuis, maar functioneren er verder los van. De peilbuizen kunnen in de loop van de tijd verzand raken ofwel er zijn onvoldoende gegevens van de peilbuis bekend om deze volgens IMBRO(/A) aan te kunnen leveren. Een vervallen of onbekende peilbuis (die niet aan de BRO wordt aangeleverd) kan dan nog altijd een functionerende zoutwachter hebben, die je in de BRO zou willen zetten.
44	BM21 02 00144	Ik probeer GMW-PPO documenten op te vragen via BROloket. Klopt het dat dat (nog) niet mogelijk is? Indien: - dat niet klopt, dan hoor ik graag hoe ik dat voor elkaar krijg; - dat wel klopt, dan zou ik bij deze graag het toevoegen van die mogelijkheid indienen als change request. Uitgiftehandboek 4.3.8. Uitgiftedocumenttype: GMW-PPO: Het uitgiftedocument dat chronologisch geordend de gegevens van een grondwatermonitoringput die niet uit registratie is genomen bevat die voor een standaard afnemer beschikbaar zijn. GMW-PO: HetGMW-PO: Het uitgiftedocument dat de actuele gegevens van een grondwatermonitoringput die niet uit registratie is genomen bevat die voor een standaard afnemer beschikbaar zijn. uitgiftedocument dat de actuele gegevens van een grondwatermonitoringput die niet uit registratie is genomen bevat die voor een standaard afnemer beschikbaar zijn.
43	BM21 02 00060	In Dinoloket was het altijd mogelijk om (geotechnische) boringen te bekijken. De boorbeschrijving werd grafisch getoond, daarmee was deze informatie direct toegankelijk voor de bezoeker die direct een beeld kreeg van de bodemopbouw. Bij recent aangeleverde boringen die conform BRO-format worden aangeleverd is deze zichtbaarheid verdwenen. Nieuwe boringen kunnen alleen als XML-bestand gedownload worden en een XML is met algemene gangbare applicaties niet te bekijken. Een direct grafische presentatie is niet beschikbaar. Oftewel: voor een bezoeker van de landelijke voorziening is minder informatie voorhanden op dit gebied dan in het verleden via Dinoloket. Kan er een viewer beschikbaar worden gesteld, zodat gebruikers van het BRO-loket als vanouds de gegevens van boorstaten kunnen bekijken? Als voorbeeld geotechnische boring met BRO-ID: BHR000000336389
42	BM21 02 00098	Ik en we lopen ertegenaan dat de BRO het inkorten en/of oplengen van de buistypen ‘filterlozeBuis’ en ‘volledigFilter’ niet accepteert, zie bijlagen. Dit maakt registratie van deze put op dit moment onmogelijk, terwijl inkorten en/of oplengen ook hierbij in praktijk wel mogelijk is en ook voorkomt. Kan deze controle en weigering opgeheven worden? Ik dien deze melding in overleg graag in namens het platform meetnetbeheerders van de provincies.
41	BM21 02 00099	Namens en in overleg met het platform meetnetbeheerders van de provincies zou ik deze melding graag weer heropenen. De reden daarvoor is dat het toevoegen van de waarde 'nogNietBeoordeeld' aan de waardelijst ‘StatusKwaliteitscontrole’ bij registratieobject GAR zorgt voor uniformering van de gelijknamige waardelijst ‘StatusKwaliteitscontrole’ bij registratieobject GLD. We beroepen ons op het gehanteerde principe t.a.v. de uniformering van de waardelijsten GMN_DeliveryContext en GMW_DeliveryContext. Jullie reactie daarbij was (ik citeer): “We hanteren bij de standaardisatie van registratieobjecten en onderliggende objecten het ontwerp-principe: gelijke objecten hebben gelijke namen. Waar objecten niet voldoen aan dit principe, worden meldingen hierover meegenomen op de backlog voor de volgende release van de catalogus.” We horen graag of ook deze waardelijsten op termijn inderdaad geüniformeerd kunnen worden, en zien alvast uit naar de reactie!
40	BM21 02 00014	De productowner van team Standaardisatie Frank Terpstra heeft vorige week inderdaad de oplossingsrichting voor de gevraagde koppeling toegelicht in het platformoverleg, zoals hieronder al aangekondigd. Het platform is en was blij met de toelichting en de voorkeursoplossing van Frank, en gaat akkoord daarmee. Ik stuur jullie bij deze namens het platform dan ook graag een change request voor de realisatie daarvan (zoals ook daar besproken): Zouden jullie in een volgende versie van de GMW-catalogus a.u.b. een optionele relatie op kunnen nemen naar de boorbeschrijving die van desbetreffende put gemaakt is (met kardinaliteit: 0..1)?
39	BM21 02 00009	waar: 3.10.1 Tijdstip meting Beschrijving Tijdstip meting heeft het domein DatumTijd. Bij handmetingen in het verleden, waarbij bijvoorbeeld eens in de twee weken een meting werd gedaan, ontbreekt regelmatig het tijdstip van de meting en is alleen de datum (volledig) bekend. Oplossingsrichting Voor IMBRO/A mogelijk maken dat bij handmetingen (en dus niet bij sensor metingen, daar speelt dit niet) alleen de datum ingevuld kan worden.
38	BM21 02 00056	In de catalogus van de grondwatermonitoringput (GMW) is vastgesteld dat een filterlengte een waardebereik mag hebben van 0.1 tot 100 meter (Zie pagina 74 van de catalogus, attribuut 7.2.1). De catalogus is vastgesteld na input van stakeholders in 2015. Filters kleiner dan 10 centimeter kunnen als gevolg hiervan niet aangeleverd worden aan de BRO.
37	BM21 01 00232	Bij Veldonderzoek.tijdstip veldonderzoek [DatumTijd] (zie catalogus – 5.3.5.1) beschikken we niet over een tijdstip en missen daarom de mogelijkheid ‘OnvolledigeDatum’ (zie 4.1.3.3) hiervoor te kunnen gebruiken. Hetzelfde hadden we bij de GLD. De BRO data analist heeft daarvoor een Issue aangemaakt. Zou dat voor dit veld ook gedaan kunnen worden? En dat we tot die tijd, net zoals we voor GLD hebben afgesproken, hier een vast tijdstip voor gaan gebruiken en dit gaan ‘verbeteren’ als we kunnen beschikken over ‘OnvolledigeDatum’ voor dit attribuut.
36	B18 08 00099	Het is gewenst om in de omschrijving van waarden in de lijst toe te lichten dat het gaat om telemetrie binnen de beschermconstructie van de put, zonder aanbrengen van antennes of iets dergelijks. De combinatie van kunststof en metaal in eenbeschermconstructie is nieuw, hiervoor zijn twee oplossingen waar nog uit gekozen gaat worden
35	BM21 01 00172	De wens is: graag een aanduiding van de laag bij foutmelding (BHR-GT). Verzoek is om hierbij ook de veldinformatie te leveren (XML) Naamgeving komt namelijk niet altijd overeen. Foutmelding moet leesbaar zijn voor de gebruiker.
34	BM21 01 00159	Voordat er sprake was van een CAB zijn er in maart 2020 besluiten genomen over o.a. 3 chemische analyses. Het zou kunnen dat WENR dit via de BRO servicedesk doch zeker via GitHub heeft gemeld. Er is een Werkafspraak chemische analyses afgekondigd door het Programmabureau en WENR voor inwerkingtreding per 1 juli 2020, via werkafspraak. Graag wil het dat het bovenaan de agenda wordt geplaatst in het eerstvolgende Backlogoverleg. Voor de analyses zoals gemodelleerd voor SFR en BHR-p (BMA) bleek aan het eind van de het modelleren voor de catalogus van alle mogelijk chemische bepalingen er slechts 3 te zijn gemodelleerd. Voor WENR is het niet zinvol leek voor chemische eigenschappen slechts gedeeltelijk het chemische deel in de BRO op te nemen. Om dit compleet te maken met de meest gebruikte parameters gaat WENR deze ook nog generiekere te modelleren zoals dat in de ISO standaard voor ‘observations & measurements’ is vastgelegd. Dit is door de BRO onderkent maar gezien de planning naar een volgende versie verschoven. Dat kwam neer op opnemen in de ‘beheerfase’. Echter deze 3 bepalingen waren al wel in de catalogus opgenomen en op dat moment zover in het proces dat deze eruit halen geen optie meer was. Daarvoor is afgesproken om hiervoor een werkafspraak te maken om voor alleen voor deze registratieobjecten het aanleveren van data voor deze bepalingen niet verplicht is.
33	BM21 01 00105	In de catalogus van het registratieobject GMW wordt voor elektroden van geo-ohmkabels (zoutwachterkabels) een maximale diepte van 200 m vermeld (par. 7.6.4). Dit lijkt mij te ondiep. De maximale diepte van de zoet/brak/zoute overgangszone ligt in Nederland op maximaal zo'n 500 m diepte (ZO-Brabant); zelfs voor geo-ohmkabels is dat wel erg diep maar het lijkt mij een zinniger begrenzing dan 200 m. Inmiddels hebben wij ten OZO van Amsterdam al zoet water aangetroffen op > 230 m-mv. En het zou maar zo kunnen dat bij toekomstige diepinfiltratietrajecten ook grotere dieptes dan 200 m-mv zullen worden gemonitord met zoutwachterkabels. Verzoeke derhalve de maximale diepte van geo-ohmkabel elektrodes te verhogen naar minimaal 500 m (misschien zelfs 750 m zodat dit overeenkomt met de maximale lengte van een peilfilterstijgbuis waar zo'n kabel per definitie aan hangt).
32	BM21 01 00092	Ik ga vanaf nu verder testen op de demo omgeving (ik heb daar nog wel een machtiging voor). Om de aanlevering te controleren, bestaat er voor de demo omgeving ook een demo BROloket? Ik heb de url: https://demo.broloket.nl/ondergrondgegevens geprobeerd maar deze bestaat niet. Met vriendelijke groeten,
31
30b	BM21 01 00008	De vraag of het twee keer registreren van de KaderAanlevering van een put (de ene keer als put zelf en de andere keer als put die onderdeel is van een meetnet) inhoudelijk niet dubbelop en potentieel conflicterend is, lijkt ook gerechtvaardigd.
30a	BM21 01 00008	Aanleiding voor deze Request for Change is het feit dat de waarden in deze waardenlijsten feitelijk grotendeels identiek zijn, maar verschillen qua codering en omschrijving. Zo is de waarde voor de Kaderrichtlijn Water bij GMW ‘KRW’ en bij GMN ‘kaderrichtlijnWater’. Het verschil in codering en omschrijving van de waarden c.q. gegevensinhoud lijkt in te gaan tegen de vereisten van eenduidigheid, uniciteit en authenticiteit van BRO-gegevens.
29	BM20 12 00183	Is het mogelijk om bij de leverancier een extra vak toe te voegen? Je kan daar dan een contactpersoon met telefoonnummer noteren. Tussen de leveranciersnaam en het vakje; omschrijving. (zie 1e plaatje) Zo heb je alle gegevens bij elkaar. Is wel zo handig J Nu noteer ik dat eigenlijk op de verkeerde plaats (zie 2e plaatje)
28	BM20 12 00130	Zie screenshot 'gedelegeerde machtiging verwijderen' in de bijlage. Het is op dit moment niet mogelijk om een gedelegeerde machtiging te verwijderen. Het gevolg is dat de bronhouder zijn machtiging ook niet meer kan verwijderen, omdat er nog een gedelegeerde machtiging openstaat. Zie screenshot 'bronhouder kan machtiging niet sluiten.'
27	BM201200128	Nu de BRO putcode een wat meer prominente rol gaat spelen zou ik het wenselijk vinden om bij de registratie van een nieuwe GMW object naast de GMW-id ook de BRO_putcode in het retourbericht op te nemen zodat deze ook meteen in het bronsysteem kan worden vastgelegd. Is dit mogelijk?
26	BM20 12 00124 & BM20 12 00125	Via een token levert de provincie gegevens aan aan het bronhouderportaal. Hier zit geen leverancier tussen. Het is niet mogelijk om deze leveringen geautomatiseerd te laten controleren en accorderen. Zou deze functionaliteit toegevoegd kunnen worden?
25	BM20 12 00146	Bij het controleren van 8 geotechnische boringen kon de gebruiker niet vinden wat de hoogste en laagste gemeten grondwaterstand is. De gebruiker zou deze informatie graag willen kunnen controleren in het bronhouderportaal.
24	BM20 11 00143	Bij controle van de boorbeschrijvingen, kan ik niet controleren, wat de hoogte van het maaiveld ten opzichte van NAP bedraagt. De referentie ten opzichte van NAP is essentieel voor nu en de toekomst ivm wijzigingen in maaiveld. Kan de maaiveld hoogte tov NAP bij de lijst bij "Brondocument" worden weergegeven?
23	BM20 11 00180	Ik stuur jullie mede namens het platform meetnetbeheerders van de provincies, en in overleg met o.a. Kor Gerritsma, een Change Request voor het toevoegen van de waarde ‘nogNietBeoordeeld’ aan attribuut StatusKwaliteitscontrole van registratieobject GAR (grondwatersamenstellingsonderzoek). Aanleiding voor deze Request for Change is erkenning van het feit dat gegevens van het grondwatersamenstellingsonderzoek ook aangeleverd kunnen worden aan de BRO zonder dat deze beoordeel zjin op hun kwaliteit. Toevoeging van de waarde ‘nogNietBeoordeeld’ aan attribuut StatusKwaliteitscontrole van registratieobject GAT zorgt daarbij voor uniformiteit binnen en vergelijkbaarheid tussen de verschillende objecten in het grondwaterdomein.
22	BM20 11 00181	Ik stuur jullie mede namens het platform meetnetbeheerders van de provincies, en in overleg met o.a. Kor Gerritsma, een Change Request voor het toevoegen van attribuut StatusKwaliteitscontrole aan registratieobject GMW (grondwatermonitoringput). Aanleiding voor deze Request for Change is erkenning van het feit dat ook de gegevens van de grondwatermonitoringput fouten en problemen kunnen bevatten en/of onzeker kunnen zijn, én dat de kwaliteit van gegevens van de grondwatermonitoringput in de praktijk ook beoordeeld wordt. Toevoeging van attribuut StatusKwaliteitscontrole aan registratieobject GMW zorgt bovendien voor uniformiteit binnen en vergelijkbaarheid tussen de verschillende objecten in het grondwaterdomein.
21	BM20 11 00174	Na aanleiding van onderstaand email ( mail van Lex Bolkesteijn.pdf) ben ik benieuwd of het mogelijk is om in Bronhoudersportaal handmatige (via user/web interface) een StartRegistration te doen waarbij de BRO-ID wordt weergegeven? Dus ik bedoel niet met het versturen van een GLD_StartRegistration.XML aan het BronhouderPortaal (groen gemarkeerd) maar echt handmatig aanmaken.
20	BM20 11 00170	Het is heel verwarrend dat termen als "goedkeuren", "controleren", "accorderen" en "vaststellen" naast elkaar gebruikt worden. Kan dat eenduidiger? In de voortgangsbalk staat bijvoorbeeld "vaststellen" terwijl de gebruiker moet "accorderen". Dat zou toch gelijk getrokken moeten kunnen worden. Onder machtiging staat "automatisch goedkeuren", maar wat is dat? Betekent het "automatisch controleren"?
19	BM20 11 00161	We moeten bij een wandmonsteranalyse de uitvoerder invullen. Dat vindt plaats door invullen van KvK nummer van de uitvoerder. Op dit moment worden alleen Europese KvK nummers ondersteund, echter, we hebben ook Amerikaanse KvK nummers omdat sommige analyses worden gedaan door Amerikaanse laboratoria. Maw, de enumeratie moet worden uitgebreid om ook Amerikaanse KvK nummers te ondersteunen. Dat moet dus een uitbreiding worden van de choice OrganizationType in BROCOmmon. <complexType name="OrganizationType"> <choice> <element name="chamberOfCommerceNumber" type="brocom:ChamberOfCommerceNumberType"/> <element name="europeanCompanyRegistrationNumber" type="brocom:EuropeanCompanyRegistrationNumberType"/> </choice> </complexType>
18		Zie Geaccepteerde BRO wijzigingsverzoeken (bro-productomgeving.nl)
17		Zie Geaccepteerde BRO wijzigingsverzoeken (bro-productomgeving.nl)
16	BM20 11 00009	Ik stuur jullie mede namens het platform meetnetbeheerders van de provincies, en in overleg met o.a. Kor Gerritsma, een Request for Change voor de manier waarop de putposities geïnterpreteerd en uitgewerkt worden in de BRO in de huidige GMW-catalogus en werkafspraak inmeten. Een naar onze mening verbeterde interpretatie en uitwerking is te vinden in rapport ‘Historie van putten en meetpunten in de BRO’ v0.31 van 07-07-2020. Dit rapport is te downloaden van GitHub via: https://github.com/PlatformMeetnetbeheerders/BRO-Protocol Aanleiding voor deze Request for Change zijn problemen en onduidelijkheden in de huidige uitwerking van het domeinmodel van de put en de gegevensdefinities daarvan, incl. bevindingen in een ketentest van Q2 2020 m.b.t. de put dat de huidige regels in de BRO inhoudelijk niet correct zijn en de aanlevering van gegevens in bepaalde situaties onterecht blokkeren. Verslag 9 maart 2021: Er zijn twee concrete gegevensinhoudelijke wijzigingsverzoeken op de huidige GMW gegevensinhoud: - het 'loslaten' van de constraint van het attribuut 'putstabiliteit' op de gebeurtenissen 'nieuweBepalingMaaiveld en nieuweBepalingPosities - het toevoegen van een waarde in de waardelijst 'methodePositiebepalingMaaiveld': afgeleidVerschilmaaiveldBovenkantBuis Ten aanzien van de werkafspraak inmeten GMW is de conclusie dat de in deze werkafspraak gebruikte term 'inmeten' beter vervangen kan worden door de term 'nameten'. De 2 additionele gebeurtenissen die in de werkafspraak worden beschreven, betreffen immers hoogtemetingen die worden gedaan gedurende de levensduur van een GMW, na het inrichten van de put. Het initiële 'inmeten' is onderdeel van het inrichtingsproces van de put, dat leidt tot registratie in de BRO van gegevens middels een inrichtingsdocument. Daarnaast is het verzoek om in de catalogus (H3) de uitleg te verbeteren over de verschillende processen die leiden tot te registreren gebeurtenissen ten aanzien van positieveranderingen. Dit is ook in de werkafspraak 'inmeten' reeds onderkend.
15	BM20 11 00120	Als gebruiker van het BROloket wil ik kunnen zien dat ik het BROloket niet kan gebruiken vanwege een storing of technisch onderhoud
14	BM20 05 00065 Provincie Zuid-Holland	Het is niet wenselijk dat andere organisaties zomaar gegevens aan kunnen leveren aan een peilbuis van de provincie Zuid-Holland. Dat zou betekenen dat meetlocaties van de provincie worden gebruikt zonder dat hier instructies voor zijn mee gegeven en zonder dat er toestemming voor is verleend. Wat bedoelde ik dan wel? -> ik zou als bronhouder graag een notificatie ontvangen zodra een externe partij putten van de provincie opneemt als onderdeel van een ‘ander/extern’ meetnet. Een dergelijke notificatie kan aanleiding zijn voor een gesprek tussen bronhouder en de andere partij. Middels een notificatie ben je als bronhouder voorafgaand aan het ‘gebruik’ van een put al op de hoogte en niet pas achteraf wanneer de gegevens worden aangeleverd. In het laatste geval is het ‘kwaad’ mogelijk al geschied, en ben je als bronhouder te laat om instructies mee te geven voor het gebruik van het grondwatermeetpunt in eigen beheer. Als meetnetbeheerder is het niet wenselijk om de ‘controle’ over het meetnetbeheer te verliezen doordat externen partijen vrij uit putten kunnen opnemen in hun eigen meetnetten. Hier is (in mijn ogen) op zijn minst een notificatie of iets dergelijks voor nodig, anders is er straks geen enkele vorm van controle op de kwaliteit van het meetnetbeheer en/of de data vanuit de bronhouder. Kortom een wenselijke werkwijze is: eerst een notificatie (en contact tussen beiden partijen) bij het opnemen van een put in een extern meetnet, daarna pas de handeling/uitvoering (monitoren) en niet andersom.
13	BM20 11 00119	Er is besloten dat bij een gemeentelijke herindeling, een bronhouder een nieuw account krijgt en dat de bronhouder toegang krijgt tot het archief van de voorgaande bronhouderorganisatie. Om dit te kunnen doen, wil ik als admin van het bronhouderportaal: Organisaties kunnen archiveren (niet verwijderen) Het archief van een bronhouderorganisatie kunnen toevoegen aan de nieuwe bronhouderorganisatie
12	BM20 10 00172	In een aantal gevallen kloppen de opgegeven decimalen voor sommige attributen niet. Mijn collega Gerben Bakker is door de catalogus gegaan en heeft gecorrigeerd. De nrs in kolom A refereren aan de paragraaf nrs en de nrs van de entiteiten in de diverse diagramman. Dit vervangt issues 59,61,67,68,69 https://github.com/BROprogramma/SFR/issues/70
11	BM20 09 00020	Als bronhouder wil ik een label toe kunnen voegen aan een RO waarmee ik aan de buitenwereld aangeef dat ze nog niet compleet zijn (bijvoorbeeld het label 'in transitie'). + Als bronhouder wil ik geen terugmelding ontvangen op RO’s waarvan ik weet dat ze incompleet zijn.
10	BM20 09 00020	Als bronhouder wil ik geen terugmeldingen ontvangen op een GAR en GLD die Afgekeurd, Onbeslist of Onbekend als QCstatus hebben.
9	BM20 09 00029	Ik loop er tegenaan dat er binnen eigenlijk de hele BRO-keten issues spelen m.b.t. de DatumTijd-definitie, c.q. de interpretatie van de tijd in het licht van zomer- en wintertijd en/of de tijdzone. Dit issue is besproken met en binnen het standaardisatieteam (zie bijlage), maar ik het stuur bij deze graag ook naar en via jullie zodat het netjes op de backlog kan worden gezet e.d.In de laatste ketentest was al naar voren gekomen dat dit probleem ook speelt tussen LV-BRO en Bronhouderportaal. Een kleine proef met Excel laat zien dat dit ook in Excel verwarring en problemen kan geven. Excel kent de notatie die de BRO hanteert helaas ook niet.Het is klaarblijkelijk een hardnekkig probleem, ik en we horen graag meer over jullie oplossing(en) en de termijn(en) die hiervoor haalbaar zijn. Met dank alvast…
8	BM20 08 00098	Bij het versturen van een terugmelding aan de bronhouder, ook de dataleverancier in CC zetten.
7	BM20 09 00160	Wij zijn inmiddels al aardig bezig sonderingen in de BRO te zetten en kunnen die evt ook zelf controleren. nu we ook enkele boringen in de BRO zetten hebben wij de behoefte deze ook te kunnen zien om controle uit te voeren. Wanneer kunnen wij een XML viewer op BRO verwachten zodat we ook de boringen kunnen controleren?
6.	BM20 10 00002 BM20 07 00068	Hoe leveren wij wijzigingsverzoeken aan? Voor SFR hebben zij een lijstje gemaakt: https://github.com/BROprogramma/SFR/issues
5.	BM20 09 00159-5	Voor elke monitoringbuis moet een bovenkant buis opgegeven worden. Minifilters hebben meestal geen ‘echte’ bovenkant; het is dan een soepele slang die in de koker ligt en bij afpompen buiten de schutkoker op een afpompinstallatie wordt aangesloten. Voor nu is daarvoor als bovenkant buis een waarde van het maaiveld+3 meter ingevuld, zodat deze informatie makkelijk terug te vinden is. Voor de toekomst moet hiervoor (vanuit de BRO) een nette oplossing komen. Mijn voorstel zou zijn om de bovenkant buis optioneel te maken. Een soortgelijk issue is al veel eerder aan de orde gekomen bij GAR. Het punt is dat de bovenkant buis er niet toe doet voor peilfilters waarin nooit grondwaterstanden gemeten zullen laat staan kunnen worden.
4.	BM20 09 00159-4	In de BRO wordt uitgegaan van een onveranderlijke X,Y locatie van een put. Ook dat ligt genuanceerder.Een vorbeeld:In de Bethunepolder hebben we op het binnentalud van een dijk een 80 m diepe peilput staan. Bij de dijkverbetering is door een aannemer een 2 m dik kleidek opgebracht dat is gaan schuiven; de put is daardoor 3 m naar beneden geschoven (en de stijgbuizen zijn krom). Wat moeten we nu in de BRO gaan zetten?Het gaat hydrologisch gezien meestal om de X,Y,Z locaties van de peilfilters. Maar voor beheersinfo is de locatie van de schutbuis van belang.Nog een voorbeeld:Peilbuizen die in de omgeving van Hillegom zijn gemaakt onder bollenvelden. De peilbuis zelf staat midden in een perceel, en is op 1,5 à 2 m onder maaiveld door een licht hellend stuk stijgbuis verbonden met een “put” die 40 m verderop langs een sloot aan de rand van het perceel staat. Ook hier weer de vraag: wat moet je voor X,Y-coordinaten invullen?
3.	BM20 09 00159-3	Veranderingen van waterpassingen kunnen alleen correcties zijn of inkorten/oplengen van peilbuizen. Maar de werkelijkheid is kleurrijker.In bijvoorbeeld veengebieden of opgespoten terreinen kunnen ondiepe peilbuizen in hun geheel wegzakken; voor zover ik weet is daar in de catalogus nog wel rekening mee gehouden (maaiveld stabiel of niet). Maar we hebben ook gevallen van geleidelijke daling van bovenkant buis over vele tientallen jaren waarbij je moet concluderen dat de stijgbuizen heel geleidelijk vervormd en/of gekringeld geraakt zijn en de waterpassingen feitelijk wel goed waren (zeker weet je het natuurlijk nooit).Het gaat er dan om dat we historische gemeten waterstanden wel moeten omrekenen met overeenkomende historische gemeten waterpassingen. Als je alleen maar uitgaat van correcties (i.c., de laatste waterpassing is de enige correcte) gaat dat fout.De BRO vraagt gelukkig grondwaterstanden en stijghoogtes t.o.v. NAP, dat scheelt hoofdbrekens, maar wij hebben veranderende waterpassingen vrijwel allemaal als inkorten/oplengen van peilbuizen ingevoerd terwijl dat in werkelijkheid niet altijd is gebeurd.
2.	BM20 09 00159-2	Voor de aanvulling ‘Inplaatsen’ kan slechts één buis in een put per keer aangeleverd worden. Dit is onwenselijk; dit moeten er meer kunnen zijn. Wij hebben een flink aantal peilputten met 6 of misschien zelfs meer peilfilters opgelapt door in alle peilfilters nieuwe dunnere peilbuizen in te plaatsen, soms/vaak meerdere per dag.- Voor elke monitoringbuis moet een bovenkant buis opgegeven worden. Minifilters hebben meestal geen ‘echte’ bovenkant; het is dan een soepele slang die in de koker ligt en bij afpompen buiten de schutkoker op een afpompinstallatie wordt aangesloten. Voor nu is daarvoor als bovenkant buis een waarde van het maaiveld+3 meter ingevuld, zodat deze informatie makkelijk terug te vinden is. Voor de toekomst moet hiervoor (vanuit de BRO) een nette oplossing komen. Mijn voorstel zou zijn om de bovenkant buis optioneel te maken. Een soortgelijk issue is al veel eerder aan de orde gekomen bij GAR. Het punt is dat de bovenkant buis er niet toe doet voor peilfilters waarin nooit grondwaterstanden gemeten zullen laat staan kunnen worden.
1.	BM20 09 00159-1	De lengte van ingeplaatste peilbuizen (dunne peilbuizen die in een defecte of lekke, wijdere peilbuis zijn geplaatst) blijkt minimaal 50 m te moeten zijn. Die ondergrens van 50 m is veel te groot en wij snappen ook niet waar die vandaan komt. In de Amsterdamse Waterleidingduinen hebben wij putten waar het ingeplaatste stuk maar 10 m lang is (en oorspronkelijke peilbuis iets van 12 m) en het kan best dat we ooit nog kortere stukken gaan inplaatsen. Ook heel ondiepe peilbuizen kunnen nl. lek zijn.Ik kan me voorstellen dat de ondergrens iets zou kunnen zijn als de lengte van oorspronkelijke (wijdere) peilbuis incl. peilfilter.