volledige teksten BRO wijzigingsverzoeken
volgnr. | meldingsnr. | volledige tekst wijzigingsverzoek | |||||||
303 | VOTB, Prorail en gemeente Utrecht. | Als gebruiker van de CPT’s uit de BRO wil ik dat de notatiewijze van de gemeten parameters wordt aangepast. | |||||||
302 | TNO | Als gebruiker zou ik graag willen dat : Kunnen we op BRO/DINOloket ergens duidelijk vermelden hoe de gegevens ingewonnen op deze site te refereren is in een publicatie? Het gaat dan ook om bv de grondwater kwaliteitsgegevens of grondwaterstanden die op te vragen zijn, in de pdf 'bericht van levering.pdf' zou volgens mij eenvoudig een actuele 'hoe deze data te citeren' regel opgenomen kunnen worden, met daarin opgenomen ook de datum van gegevens opgevraagd. Zodat bij gebruik juist citatie gebruikt word. | |||||||
301 | BM24 05 000252 | Op NLOG worden boorgaten getoond waarvan de vertrouwelijkheidsperiode nog niet voorbij is. Niet alle gegevens van boorgaten zijn namelijk vertrouwelijk. Een voorbeeld van een gegeven dat wél (temporeel) vertrouwelijk is, is de ligging van het traject dat voor een boring in de ondergrond is gevolgd. Voor de migratie van gegevens vanuit het TNO-interne systeem (DINO) naar de BRO die we nu voorbereiden, is dat gegeven géén probleem. Ten eerste omdat we besloten hebben dat gegeven niet te migreren (maar alleen een 'puntje op de kaart'), ten tweede omdat de BRO EPC catalogus in vertrouwelijkheid van dat gegeven voorziet. Een gegeven dat misschien wél een probleem geeft, is de wettelijke status (zie de BRO EPC catalogus https://broprogramma.github.io/EPC/#detail_attribute_Model_Mijnbouwconstructie_wettelijkestatus). Dat gegeven heeft volgens de catalogus geen vertrouwelijkheid. Zelf ben ik betrokken geweest bij het opstellen van de catalogus en van daaruit weet ik dat hier ook niet over is gesproken. Echter is nu vanuit TNO-GDN, vanwege deze migratie, de vraag gesteld of de wettelijke status altijd openbaar is. Op NLOG wordt namelijk de operationele(!) status niet getoond bij boorgaten voor de termijn dat de boorgatgegevens vertrouwelijk zijn. Zie bijv. op NLOG boring MIDDENMEER-GT-10 (https://www.nlog.nl/nlog-mapviewer/brh/3910564522?lang=nl). Voor boorgaten waarvan de vertrouwelijkheidsperiode voorbij is, wordt de operationele(!) status wél getoond. Zie bijv. boring NIEUWENDIJK-01 (https://www.nlog.nl/nlog-mapviewer/brh/421238697?lang=nl, veld 'Status'). Nu is de operationele status die op NLOG wordt getoond een ander gegeven dan de wettelijke status die in de BRO EPC catalogus staat. Ze hangen echter deels samen. Een operator heeft misschien (commercieel) belang bij het niet tonen van de wettelijke status. Dus de vraag is: behoort de wettelijke status van een boorgat tot de vertrouwelijke boorgatgegevens? 1. De waardelijst WettelijkeStatus (https://docs.geostandaarden.nl/bro/EPC/#detail_class_Model_WettelijkeStatus) wordt uitgebreid met de waarde 'onbekend'. Alleen te gebruiken onder IMBRO/A. Omschrijving nader te bepalen. Voor boringen waarvoor we bij migratie de wettelijke status niet kunnen bepalen, wordt 'onbekend' ingevuld. Verzoek tot werkafspraak hiertoe zal ik indienen bij de BRO. 2. Als blijkt (uit overleg dat Jeroen zal initiëren met Frank Denys) dat de wettelijke status tot de vertrouwelijke gegevens van een boring behoort, dan zullen die betreffende boringen (op dit moment 83 stuks) niet meegenomen worden in de migratie. | |||||||
300 | BM24 05 00096 | Gegevensgroep ‘locatiebepaling’ optioneel i.p.v. alle attributen ervan. De gegevensgroep ‘locatiebepaling’ is verplicht maar de drie attributen ervan mogen alle weggelaten worden. Een later afgesproken manier van modelleren is dat de gegevensgroep in zo’n geval optioneel is, maar 1 of meer attributen ervan verplicht. impact op: Catalogus + TO + LV-BRO Aanpassing XSD + LV-BRO voorwaardelijk voor bouw migratietool. | |||||||
299 | BM24 05 00094 | De aanpassing is als volgt:
De achtergrond van deze aanpassing is dat ik met de domeinexperts heb afgesproken om álle datums met 01-01 en 31-12 1-op-1 te migreren. | |||||||
298 | BM24 05 00093 | Eigenaar wordt niet aangeleverd, wat kan volgens de catalogus. Echter moet er een nieuwe reden van niet aanleveren worden toegevoegd aan de catalogus. Allen impact op catalogus. geen implicatie op migratie. Formeel onjuiste situatie in BRO. Nl. boorgaten zonder eigenaar in BRO met een reden (nl. MVP-migratie) die niet in de catalogus staat. Het attribuut wordt namelijk niet gevuld in deze migratie. Volgens de catalogus is het attribuut verplicht. Weliswaar geldt ‘Mogelijk geen waarde’ = ‘Ja’. Maar in het rijtje ‘Reden geen waarde’ dat hierbij hoort, is de reden voor dit geval – namelijk een minimale migratie – niet voorzien. | |||||||
297 | BM24 05 00029 | Voor het aanleveren van GLD staan er geen regels in de inname catalogus die controleren of een GMW in registratie is. Hierdoor is het mogelijk dat GLD wordt geleverd aan een put die uit registratie is. | |||||||
296 | BM24 02 00212 | Alhoewel we de BHP-API v2 zeker van harte verwelkomen (met weliswaar ook daarbij nog een openstaand verzoek tot ‘Change’), blijft het zo dat ons inziens de situatie bij bronhouders die gebruik maken van ontzorgende partijen niet wenselijk is. Dergelijke ontzorgende partijen moeten nu noodgedwongen een token van de bronhouder zelf gebruiken, met alle ongewenste gevolgen van dien. RWS is daarnaast als organisatie zo groot, dat het werken met één token dat noodgedwongen binnen en buiten de organisatie gedeeld wordt, al gauw onveilig te noemen is. | |||||||
295 | BM23 11 00179 | N.a.v. overleg van de BRO-DBG van vandaag en het BRO-Ketenissues- annex BRO-Denktankoverleg van afgelopen donderdag dien ik bij deze dan ook graag formeel een RFC-verzoek in voor implementatie van het bron-format, zoals besproken. | |||||||
294 | BM24 02 00212 | Alhoewel we de BHP-API v2 zeker van harte verwelkomen (met weliswaar ook daarbij nog een openstaand verzoek tot ‘Change’), blijft het zo dat ons inziens de situatie bij bronhouders die gebruik maken van ontzorgende partijen niet wenselijk is. Dergelijke ontzorgende partijen moeten nu noodgedwongen een token van de bronhouder zelf gebruiken, met alle ongewenste gevolgen van dien. RWS is daarnaast als organisatie zo groot, dat het werken met één token dat noodgedwongen binnen en buiten de organisatie gedeeld wordt, al gauw onveilig te noemen is. | |||||||
293 | BM24 04 00157 | Als dataleverancier wil ik de leveringstatus op kunnen vragen, ook wanneer de machtiging gesloten is. Als een bronhouder de levering geaccordeerd heeft dan kan deze de machtiging in principe sluiten. | |||||||
292 | BM24 03 00383 | ⒈Het gaat hier om: | |||||||
291 | BM24 04 00167 | Verzoek RVO
Gezien het feit dat voor offshore deze methode veelal gebruikt wordt en binnen de norm is toegestaan! | |||||||
290 | BM24 04 00166 | Verzoek RVO
Gezien het feit dat deze methode een steeds vakere en veel toegepaste en goedkopere methode betreft | |||||||
289 | BM24 04 00112 |
| |||||||
288 | BM24 04 00092 | Graag zou ik de nieuwe versie van het QC-protocol van provincies en het RIVM voor GAR-gegevens willen aanmelden bij de BRO. Bijgevoegd is de documentatie ervan. | |||||||
287 | BM24 04 00061 | Bij deze wil ik graag een wijzigingsverzoek indienen. Met de nieuwe versie van DINOloket is het niet meer mogelijk om een url van de helpfunctie te gebruiken (voor verwijzingen etc). | |||||||
286 | BM24 03 00354 | Het zou handzaam zijn om binnen het Portaal - menu 'Bekijken' - tabbladen 'Registratieobjecten' en 'Transacties', een kolom 'Levering-ID' op te nemen. Onder tab 'Transacties' kan nu gezocht worden op 'Transactie-ID'; het zou dan prettig zijn om tevens te kunnen zoeken op 'Levering-ID'. | |||||||
285 | BM24 03 00188 | Bij het zoeken op ID's in het bronhouderportaal zou het mooi zijn als niet een geheel BRO-ID ingevuld hoeft te worden, maar bijvoorbeeld alleen de nummers aan het eind van de reeks die het object uniek maakt. In het BRO'tje van vandaag is het voorbeeld '70033' gebruikt om te zoeken, wat niet werkte omdat er geen 'wildcard' functionaliteit lijkt te zijn. | |||||||
284 | BM24 03 00187 | In het BRO Bronhouderportaal bij 'Bekijken' -> 'Registratieobjecten' de functionaliteit toevoegen dat je een dropdown menu krijgt bij de kolom 'Dataleveranciers'. | |||||||
283 | BM24 03 00186 | In het BRO Bronhouderportaal bij 'Bekijken' -> 'Transacties' de tekst bovenin toevoegen: ' Hier wordt bijgehouden wat er wordt aangeleverd aan de Landelijke Voorziening BRO.' | |||||||
282 | BM24 03 00185 | In het BRO Bronhouderportaal bij 'Bekijken' -> 'Registratieobjecten' boven 'objecttype' de verschillende registratie 'Domeinen' toevoegen (zoals: Grondwatergebruik, grondwatermonitoring, ...). Op deze manier zou je kunnen filteren per domein. Waarna alleen de objecttype(n) per domein zichtbaar worden. | |||||||
280 - 281 | Voor de migratie van DINO – BRO m.b.t. GLD heb ik een aantal verzoeken.
Concluderend
| ||||||||
279 | BM24 02 00153 | Voor onze projecten maken wij veel gebruik van tijdreeksen van grondwaterstanden. Deze ontleenden we in het verleden aan het DINO-loket of werden door meetnetbeheerders direct aan ons verstrekt. Nu proberen wij de tijdreeksen aan de BRO te ontlenen. Daarbij lopen wij echter tegen het volgende aan: | |||||||
278 | BM24 02 00345 | Als gemandateerd bronhouder wil ik bij de korrelgrootte verdeling zowel bij de “Standaard verdeling fractie 63tot2000um” als bij de “Uitgebreide verdeling fractie 63tot2000um” de “fractie 105tot210um” onder verdeelt hebben in “fractie 105tot150um” en “fractie 150tot210” | |||||||
277 | BM24 02 00260 | Het BRO programma heeft in November 2023 besloten om geen Bulkdownload ( geopackage) met alle grondwaterstanden (GLD) via PDOK ter beschikking te stellen; de omvang van de GLD dataset is daarvoor te groot; | |||||||
276 | BM24 02 00203 | Hoe vaak verwacht het BRO programma / CAB Updates van Waardelijsten nodig | |||||||
275 | BM24 02 00174 | Op basis van de huidige service voor ‘uitgifte van grondwater in samenhang’ kun je alleen resultaten opvragen o.b.v. de GMW BroId, zie: | |||||||
274 | BM24 02 00173 | Er zijn afgelopen jaar behoorlijk wat verbeteringen aangebracht bij de fysische analyses van BHR-P en SFR. En we hebben dan nu ook bijna alles compleet om te kunnen leveren. Dank daarvoor. | |||||||
273 | BM23 11 00050 | Via Dinoloket kan ik GMW en GLD files downloaden als XML-files. Is het mogelijk om de levering van deze bestanden uit te breiden met een bestand waarin de relatie tussen de GWM filters en de GLD-codes wordt gegeven? Ik weet dan welk GLD-file ik moet inlezen om de reeks van een gegeven putfilter te krijgen. | |||||||
272 | BM23 12 15761 | Zoals de titel van de mail al aangeeft zou ik graag een wijzigingsverzoek willen indienen, om ervoor te zorgen dat de BROServices REST API */bro-ids endPoint(s) alleen BRO-IDs uitgeeft (van de aangegeven bronhouder) die niet uit registratie zijn genomen. Zoals te zien viel me dit nu op bij de BROServices REST API van GMW, maar dezelfde */bro-ids endPoint komt ook bij alle andere registratieobjecten voor, en ik neem aan dat de implementatie daar hetzelfde is. Het lijkt me derhalve handig om deze wijziging (bij inwilligen), bij alle registratieobjecten door te voeren. | |||||||
271 | BM23 11 00277 | ||||||||
270 | BM23 12 00011 | ||||||||
269 | BM23 11 00410 | Wat betreft software / functioneel:
De huidige situatie leid tot onnodig veel complexiteit en beheer. Bijvoorbeeld: op dit moment wordt de registerbeheerapplicatie her-ontwikkeld. De registerbeheerder moet zo dadelijk voor elke partijen, individueel elke rol voor elk registratie-object toekennen.
| |||||||
268 | BM23 11 00321 | Wij hebben hier een Triaxiaal test welke water uitperst maar ook opneemt. | |||||||
267 | BM23 11 00354 | Daarnaast heb ik de volgende vraag: Waarom kan ik geen meetwaarden aanleveren als een object in onderzoek is? Dat is niet handig. De hele levering 848 stukjes meetwaarden worden niet geaccepteerd als het ene object in onderzoek is!!! | |||||||
266 | BM23 10 00511 | In ‘Details van de levering’ zijn ‘Labels’ en ‘Externe referentie leverancier’ aan te passen. Ik ben erg geholpen met de mogelijkheid om deze 2 attributen in 1 keer te kunnen invullen per project | |||||||
265 | BM23 11 00404 | De indicatie “onder voorrecht” wordt alleen bij GMW gebruikt. Het doel was om de controle op met name begin- en einddatum bij een put dmv een database veld en dmv een (optionele) indicatie in de transactiegegevens af te zwakken. Hiermee werd het mogelijk om ook de datumformaten: onbekend, JJJJ en JJJJ-MM voor deze gegevens te gebruiken. BZK heeft besloten (reeds enige tijd geleden) dit recht aan eenieder toe te kennen. Daarmee is het nut (uit kunnen zetten) verdwenen. Het veld levert (nog steeds) de nodige verwarring op en heeft de nodige verwarring opgeleverd. Voorstel:
| |||||||
264 | BM23 11 00256 | Als bronhouder kun je geen overzicht van projecten opvragen via de volgende BHP API endpoint: | |||||||
263 | BM23 11 00189 | Voorstel om naast de grootte van het zip-bestand ook de grootte van het uitgepakte zip-bestand te vermelden op de bestelpagina van BROloket. | |||||||
262 | BM23 10 00507 | In tabblad 'Bekijken' graag bij zowel 'Registratieobjecten' en 'Transacties' het project 'ID/kenmerk' en 'Kolommen selecteren'. Ook graag onder 'Transacties' de mogelijkheid om te kunnen filteren op 'Objecttype', zoals al kan in 'Registratieobjecten'. Ook onder 'Transacties' kunnen filteren op ‘Levering-ID’ is wenselijk | |||||||
261 | BM23 10 00507 | In tabblad 'Bekijken' graag bij zowel 'Registratieobjecten' en 'Transacties' het project 'ID/kenmerk' en 'Kolommen selecteren'. Ook graag onder 'Transacties' de mogelijkheid om te kunnen filteren op 'Objecttype', zoals al kan in 'Registratieobjecten'. Ook onder 'Transacties' kunnen filteren op ‘Levering-ID’ is wenselijk | |||||||
260 | BM23 11 00050 | Via Dinoloket kan ik GMW en GLD files downloaden als XML-files. Is het mogelijk om de levering van deze bestanden uit te breiden met een bestand waarin de relatie tussen de GWM filters en de GLD-codes wordt gegeven? Ik weet dan welk GLD-file ik moet inlezen om de reeks van een gegeven putfilter te krijgen. | |||||||
259 | BM23 11 00018 | Als de gebruikers op het BROloket de detail info willen ophalen van een GUF of GPD krijgen zij een email met een link naar XML bestanden. | |||||||
258 | BM23 10 00509 | Mogelijkheid om onder tabblad ‘Aanleveren’ onder ‘Projectgegevens‘ ook “Object-ID Bronhouder” te tonen, én het ook mogelijk te maken om deze na een aanlevering aan te kunnen passen door de bronhouder | |||||||
257 | BM23 10 00508 | De tijdsduur van automatisch uitloggen uit het BHP (waarna je dus weer opnieuw moet inloggen) graag verlengen! Moet nu om de haverklap opnieuw inloggen. Het uitloggen gebeurt zelfs wanneer je in het BHP aan het werken bent, zou niet moeten | |||||||
256 | BM23 10 00198 | Als dataleverancier wil ik ook kunnen zien voor welke projecten leveringen nog niet zijn doorgeleverd door de bronhouder. Zodat ik erop kan toezien dat leveringen worden afgerond voordat ze voorlopen. | |||||||
255 | BM23 09 00370 | wij lopen tegen het probleem aan dat complexe geotechnische laboratoriumproeven in leveringen aan de BRO niet controleerbaar zijn en daardoor blijven openstaan na levering. Hier hebben we eerder contact overgehad. De beperkte visualisatiemogelijkheden en ruwe data in de XML zijn inderdaad het probleem. | |||||||
254 | BM23 09 00362 | Graag NEN-EN-ISO 17892-7 (UCS) opnenen als proef in BHR-GT | |||||||
253 | BM23 09 00361 | NEN-ISO 13320:2009 geïmplementeerd in BHR-GT terwijl de 2020 reeds een paar jaar beschikbaar is. Graag deze tevens opnemen in de waardenlijst. | |||||||
252 | BM23 09 00360 | Je bericht: | |||||||
251 | BM23 08 00472 | In de tekst wordt voor de doorlatendheid van zwelklei meermaals aangegeven: "een doorlatendheid die kleiner is dan 10 - 9 m/s". Maar dat kan niet kloppen, want dat is een doorlatendheid die hoort bij zeer grof zand of fijn grind 😉 Zie ook: doorlatendheid grondsoorten (grondwaterformules.nl). Waarschijnlijk wordt er een doorlatendheid bedoeld van 10-9 m/s wat overeenkomt met ongeveer 0.9 mm/d! Excuus. Ik zie dat het getal in mijn mail helaas ook automatisch was veranderd naar 10-9. Wat ik bedoel is dat de tekst zou moeten worden veranderd naar: "een doorlatendheid die kleiner is dan 10^- 9 m/s". | |||||||
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. | |||||||
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. | |||||||
244 | BM23 06 00380 | We hebben een vraag over het waardebereik van het attribuut “vervormingssnelheid” van de entiteit “Belastingfase”. | |||||||
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. | |||||||
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: 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" | |||||||
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. | |||||||
239 | BM23 07 00029 | BHR-GT: in omschrijving waarde ISO17892d12v2018 jaartal toevoegen | |||||||
238 | BM23 07 00028 | Bevinding vanuit BRO Standaarden in BHR-G en BHR-GT catalogi. | |||||||
237 | BM23 07 00027 | We hebben een bevinding vanuit BRO Standaarden voor de BHR-G en BHR-GT catalogi: | |||||||
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. | |||||||
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: | |||||||
229 | BM23 05 00435 | Vanuit 2 richtingen is de behoefte geuit voor een ‘ handreiking/handleiding gebruik van BRO geopackages/atomfeeds’ | |||||||
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, 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. | |||||||
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. | |||||||
225 | BM23 05 00216 | Vorm doorlatendheidscurve | |||||||
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. | |||||||
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 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. | |||||||
213 | BM23 02 00180 | Beste servicedesk, | |||||||
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? | |||||||
211 | BM23 02 00046 | Ik maak gebruik van REST API om een grondwaterstandendossier (GLD) op te vragen: | |||||||
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: | |||||||
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’). | |||||||
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? | |||||||
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. | |||||||
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. | |||||||
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).
| |||||||
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. Wil nogmaals benadrukken dat de OpenDAP server een onmisbare uitgiftebon is voor de grondmodellen (REGIS, GEOTOP). | |||||||
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 | |||||||
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. | |||||||
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 | |||||||
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 | |||||||
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. | |||||||
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) | |||||||
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. | |||||||
155 | BM22 03 00269 | Hoe kan ik grondwaterstanden uit het BRO-loket lezen / bewerken / analyseren? 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: | |||||||
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. | |||||||
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). | |||||||
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: | |||||||
140 | BM22 01 00420 | Zie vorige verzoek: Nog een ander issue hieraan gerelateerd: | |||||||
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:
| ||||||||
137 | BM22 01 00385 | Als admin van het Bronhouderportaal Voorbeelden selectiecriteria:
| |||||||
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). | |||||||
133 | BM22 01 00178 | Ik zie verschillende leveringen die de status doorgeleverd/afgekeurd_LVBRO hebben. | |||||||
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? | |||||||
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). Informatie door de BRO Servicedesk toegestuurd: De organisaties die geregistreerd (kunnen) worden bij een grondwatermonitoringput zijn: | |||||||
129 | BM22 01 00108 | Als gebruiker van het bronhouderportaal | |||||||
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. | |||||||
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? | |||||||
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. | |||||||
122 | BM21 12 00258 | Als registratiebeheerder 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 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: | |||||||
119 | BM21 11 00443 | US acceptatiecriteria | |||||||
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. | |||||||
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. | |||||||
115 | BM21 11 00186 | Als beheerder voor ontwikkeling en realisatie van de BRO; | |||||||
114 | BM21 11 00185 | Als gebruiker van de BRO; | |||||||
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. | |||||||
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). | |||||||
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: | |||||||
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. | |||||||
108 | BM21 09 00328 | Deze “automatisch ingestelde schaalverdeling” geeft een vertekend beeld en grafieken komen niet overeen met de aangeleverde sondeerresultaten. | |||||||
107 | BM21 06 00490 | - GAR issues (GitHUB) | |||||||
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. | |||||||
104 | BM21 09 00316 | - Definitieve standen corrigeren wanneer er toch fouten blijken te zijn in de waterstanden is dat mogelijk en zo ja hoe. | |||||||
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. | |||||||
100 | BM21 08 00255 BM21 09 00364 | Uitgifte van leveringen en dataleveranciers – Het huidige bronhouderportaal is al 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 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) 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 | |||||||
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): | |||||||
91 | BM21 06 00443 | Graag zouden wij de waardenlijst willen uitbreiden met de waarde: “Validatieprotocol Evides Waterbedrijf”. | |||||||
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. | |||||||
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 | |||||||
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. | |||||||
85 | BM21 06 00469 | https://www.bro-productomgeving.nl/bpo/latest/grondwatermonitoring/grondwaterstandonderzoek-gld/gld-berichtencatalogus-uitgiftewebservice | |||||||
84 | BM21 06 00460 | In de catalogus "20190507_catalogus_bodemkundig_wandonderzoek_1.pdf", pagina 123, paragraaf 3.49 Bepaling waterretentiestapsgewijs | |||||||
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 | |||||||
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. | |||||||
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. | |||||||
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. Oplossingsrichting: Associatie relatie van/naar Observatie vervangen door een associatie relatie van Observatie naar Observatiecontext (ObservationContext) en vandaar met een associatierelatie naar Observatie. Met betrekking tot 3.6 en 3.7 Definieer een gegevensgroeptype BenoemdeWaarden (NamedValues). 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. 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. | |||||||
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. | |||||||
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. | |||||||
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. | |||||||
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: | |||||||
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. | |||||||
72 | BM21 05 00168 | In de catalogus "20190507_catalogus_bodemkundig_wandonderzoek_1.pdf", pagina 59, paragraaf 3.16.14 rijpingsklasse | |||||||
71 | BM21 05 00167 | In de catalogus "20190507_catalogus_bodemkundig_wandonderzoek_1.pdf", pagina 14, entiteit 58 Modellering van hydrofysische karakteristieken: | |||||||
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 | |||||||
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 | |||||||
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. | |||||||
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. 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. | |||||||
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. 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? | |||||||
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. | |||||||
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.
| |||||||
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). | |||||||
51 | BM20 11 00009 | Deel van oorspronkelijk wijzigingsverzoek volgnr. 16. Er zijn twee concrete gegevensinhoudelijke wijzigingsverzoeken op de huidige GMW gegevensinhoud: 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. | |||||||
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. 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. | |||||||
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: 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? | |||||||
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. | |||||||
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. | |||||||
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. | |||||||
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: | |||||||
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. | |||||||
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). | |||||||
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? | |||||||
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 | |||||||
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).
| |||||||
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? | |||||||
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. | |||||||
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. | |||||||
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: 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. | |||||||
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 | 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. | |||||||
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:
| |||||||
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. |