volledige teksten BRO wijzigingsverzoeken

volgnr.

meldingsnr.

volledige tekst wijzigingsverzoek

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.

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://www.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.