Voortgang ketentest bij verschillende consortia

Transcriptie

1 Verslag Tussenevaluatie Ketentest GMW 18 januari 2017 Inleiding Dit verslag van de tussenevaluatie Ketentest GMW bestaat uit drie onderdelen. Allereerst is er een korte weergave van de voortgang van de Ketentest GMW bij de verschillende consortia. Vervolgens komen de vragen en bevindingen van de groepsopdracht van die middag aan bod. Deze vragen en bevindingen zijn ingedeeld naar de thema s van de groepsopdrachten, te weten gegevensinhoud, techniek en organisatie/proces. Ook zijn daar de vragen ondergebracht die die middag nog niet waren beantwoord, maar onder dat thema vallen. Tot slot bevat het laatste onderdeel van dit verslag de resterende vragen met bijbehorende antwoorden. Aan de antwoorden kunnen geen rechten worden ontleend. Wel hebben we getracht om middels dit verslag alle ingebrachte vragen zo goed mogelijk te beantwoorden om daarmee alle ketentestdeelnemers verder op weg te helpen en inzicht te geven in het hoe en waarom van het BRO-systeem. Bij een enkele vraag wordt voor een antwoord verwezen naar IenM, aangezien het wettelijke aspecten van de BRO raakt. Dit valt buiten scope van de organisatie van deze ketentest. Mochten naar aanleiding van dit verslag en de antwoorden nog onduidelijkheden zijn, dan horen we het graag. Voortgang ketentest bij verschillende consortia FEWS: De webservice koppeling aan de innamekant is tot stand gebracht en het registreren van een put lukt. Momenteel is FEWS bezig met aanvullingen en is er behoefte aan concrete voorbeeldberichten. In december zijn tijdens een overleg een aantal gegevensinhoudelijk vragen beantwoordt. Met betrekking tot de gegevensinhoud zijn er momenteel geen problemen. DAWACO: Geen recente update, maar op basis van overleg dat medio december heeft plaatsgevonden, is geconcludeerd dat de webservice-techniek geen probleem is en dat de gegevensinhoud (inclusief de aanvullingen) past bij de huidige werkprocessen. Het DAWACO systeem wordt daarop aangepast. Hydromonitor: Er is een ander spoor gevolgd door Java client te incorporeren. Dit bleek echter niet zo bruikbaar in productie. De gebruikte techniek van de voorbeeldclient sluit niet aan op de huidige software implementatie van Hydromonitor. De uitgifteservice werkt inmiddels. Momenteel bezig met de innameservices en analyse van gegevensinhoudelijke aspecten. Waterlabs: De uitgifteservice werkt. Op dit moment wordt gewerkt aan de analyse op gegevensinhoud (catalogus): beoordeling of alle uitgiftemogelijkheden (zoeken op kenmerken) benut zijn.

2 GeoLinQ: De uitgifteservice werkt. Er is gerapporteerd aan de provincie Overijssel. Op dit moment is er behoefte aan meer testputten. Verder is IntellinQ aan het kijken naar de mogelijke vertaling/integratie met andere basisregistraties o.b.v. behoefte bij de provincie. Er is behoefte aan interviews met meer partijen en mogelijkheden. WWD/Munisense: De innameservice werkt. Nu wordt gewerkt aan de analyse en mapping tussen het eigen WWD systeem en de BRO. Nog niet bezig met de uitgifteservice. Wel aandacht voor synchronisatie van aanvullingen en correcties tussen WWD en BRO. Tijdens het overleg in december is de documentatie besproken en zijn een aantal aanbevelingen opgehaald. Eijkelkamp: De innameservice werkt. Nu aandacht voor mapping van het eigen systeem (impact). Aanvullingen worden opgestart, evenals de uitgifteservice. AGEL: De documentatie is beoordeeld en de rapportage is opgeleverd aan TNO. Tijdens het overleg in december is de documentatie besproken en een aantal aanbevelingen opgehaald.

3 Vragen en bevindingen per thema Gegevensinhoud Ingebracht vragen/bevindingen die aan bod zijn gekomen bij de groepsopdracht 1. Welke kenmerken zijn absoluut verplicht en welke optioneel? De huidige uitgangspunten voor definitie van de gegeven van de BRO-principes zijn toegelicht (zie ook Catalogus GMW v0.7): Een gegeven in de BRO is in beginsel verplicht (authentiek). Er wordt dus geen onderscheid gemaakt in optionele en verplichte kenmerken, omdat dit in het proces van standaardisatie geen voordeel biedt. Er moet nog een formeel besluit genomen worden of een gegeven opgenomen wordt in de BRO. Daarnaast moet een formeel besluit genomen worden m.b.t. de opname van optionele gegevens in de BRO. Optionele velden kunnen verwarring scheppen aan de gebruikerskant, omdat onduidelijk is of het gegeven er niet is of dat niet is aangeleverd aan de BRO. Dit laatste schept ook verwarring voor het proces van terugmelden op authentieke gegevens. Een gegeven wordt onderdeel van de BRO als het voor het werkveld (meer)waarde heeft voor hergebruik en eenduidig aangeleverd kan worden. Het moet bij de put gaan om gegevens die van zichzelf waarde hebben en niet om gegevens die alleen gebruikt worden om validatie/controles uit te kunnen voeren op andere gegevens in de BRO. Een voorbeeld: het type beschermconstructie kan gebruikt worden als verklaring van afwijkingen in een grondwaterreeks (een put met een straatpot kan makkelijker vollopen bij zware neerslag). De BRO gaat er echter vanuit dat een bronhouder alleen valide grondwaterstandsreeksen in de BRO registreert en dat zo n validatie door gebruikers van de BRO niet gedaan hoeft worden. Vanuit die optiek is het registreren van de beschermconstructie in de BRO niet nodig. De huidige gegevensinhoud is (dus) de uitkomst van behoeftes zoals die in de expertgroep zijn bediscussieerd. Wel moet hierbij worden opgemerkt dat twijfelgevallen (bijvoorbeeld bovengenoemde beschermconstructie) in de Catalogus v0.7 geïnventariseerd zijn, zodat bij een nieuwe release opnieuw bekeken kan worden of eerdere besluiten herzien moeten worden. 2. Waarom is ervoor gekozen om WGS84 niet te ondersteunen? De BRO ondersteunt slechts een beperkt aan referentiestelsels: RD op land omdat dit in het werkveld het meest gebruikt wordt. Voor gegevens op zee is ook WGS84 een valide referentiestelsel. Daarnaast wordt ETRS89 ondersteund, omdat dit een afspraak is bij de overheid t.a.v. de gegevensuitwisseling binnen het stelsel van Basisregistraties (zie ook Catalogus GMW v0.7 pag 14/15). 3. Hoe is de identificatie van putten geborgd met een unieke identificatie? En is hierbij een koppeling gemaakt met de BGT? Bij doorvraag en discussie in de sessie werd deze vraag algemener: gaat de BRO koppelingen leggen met andere basisregistraties en hoe worden deze onderhouden (bijvoorbeeld voor het KvK-nummer)?

4 Er is toegelicht dat de BRO vooralsnog niet verder gaat dan vastleggen dat deze koppelingen er in de toekomst moeten komen (inclusief de voordelen t.a.v. onderhoud). De koppeling met het NHR (voor KvK-nummers) bleek bijvoorbeeld nu nog niet gelegd te kunnen worden, maar het streven is dat dit zeker realiteit gaat worden. 4. In hoeverre bevat de data-inhoud van de ketentest ook historie van een put? Gegevensinhoud is integraal onderdeel van de ketentest; opmerkingen daarover worden in de bevindingen meegenomen. In de fase na de ketentest wordt door IenM besloten welke gegevensinhoudelijke bevindingen wel of niet worden gehonoreerd/opgepakt voor de productiefase (v1.0). Het minder stringente IMBRO/A informatiemodel (zie ook Catalogus GMW v0.7 par 2.4 pag 11/12) is bedoeld om zorgen dat ook historische putgegevens in de BRO geregistreerd kunnen worden. Voor het registreren van historische data gaat een transitieperiode gelden. Uit een rondvraag tijdens de sessie blijkt dat door huidige dataleveranciers en bronhouders nog niet wordt geanticipeerd op het kunnen aanleveren van historische data aan de BRO. Bij TNO loopt momenteel wel het voorbereidingstraject voor de conversie van put-data uit DINO naar de BRO. Dit is mogelijk relevant voor de desbetreffende puteigenaren/bronhouders om te weten. Plenaire terugkoppeling Uit de antwoordsessie komt de conclusie dat de huidige GMW gegevensinhoud voldoet en past bij de huidige werkprocessen. BRO GMW gegevens die momenteel in de praktijk (nog niet altijd) worden geregistreerd, zijn in de toekomst makkelijk vast te leggen. Wel zijn er nog wensen, zoals bijvoorbeeld het registreren van de beschermconstructie. Naar aanleiding van deze reactie wijst Ria Volkers van IenM de aanwezigen op de marktconsultatie voor de gegevens inhoud van CPT en GMW die momenteel loopt. Zie voor meer informatie: Overige ingebrachte vragen/bevindingen 5. Wordt er voldoende rekening gehouden met de koppeling tussen BRO en de (systemen van) diverse bronhouders, wat betreft de identificatie van putten? Dit punt is al eerder opgemerkt en heeft ertoe geleid dat recent een voorstel is gedaan tot aanpassing van de GMW gegevensinhoud m.b.t. een additioneel gebruikers-id. Dit voorstel is in behandeling bij Marcel Reuvers, Programmabureau BRO, dat verantwoordelijk voor de BRO standaardisatie. 6. Worden sensorgegevens opgenomen in de BRO? Zo ja: bij put of bij reeks? Stel iemand heeft een bepaald type sensor gebruikt en van dat type worden afwijking bekend, dan is het handig dat dat geregistreerd is. Sensorgegevens horen niet bij het registratieobject put (GMW), maar hoort mogelijk wel bij het meetpunt (onderdeel van Grondwatermonitoringnet, zie Catalogus GMW v0.7 pag 19/20/21) of bij het registratieobject Grondwaterstandsonderzoek (de grondwaterstandsreeks). Als wordt onderkend dat het type sensor hergebruikswaarde heeft (bijvoorbeeld als indicatie voor de kwaliteit van de meetgegevens), kan dat reden

5 zijn om het sensortype te registreren in de BRO. Het standaardisatietraject voor deze registratieobjecten moet nog plaatsvinden. 7. Hoe gaat de BRO om met dubbele functies van een put? Bijvoorbeeld monitoring van zowel onttrekking als stijghoogte? Bij de put (GMW) wordt uitsluitend vastgelegd wat de initiële functie van een put is, ofwel de functie waarvoor de put oorspronkelijk is neergezet. Deze functie kan anders zijn dan waar de put op een gegeven moment voor wordt gebruikt. Zo kan een brandput tegenwoordig gebruikt worden voor grondwaterkwaliteitsonderzoek. In dat geval wordt de huidige functie (grondwaterkwaliteitsonderzoek) in de BRO vastgelegd bij het grondwatermonitoringnet waar de betreffende put deel van uitmaakt. De initiële functie blijft echter brandput. Dit aspect van initiële functies van putten zijn in de expertbijeenkomsten besproken, hoewel het genoemde voorbeeld destijds niet voorbijgekomen is. 8. Hoe wordt omgegaan met verschillende kwaliteitsregimes van geleverde data? Is er de mogelijkheid voor minimale attributen en extra gegevens? Is er marge of kwaliteit van attribuut (afwijking sensor o.i.d.)? Zie voor het antwoord op de vraag over minimale attributen en extra gegevens vraag 1 en 4. Wat betreft de kwaliteit van een attribuut stelt de BRO zelf geen eisen. Wel is het de bedoeling om de gehanteerde norm en/of methode van een meting (bijvoorbeeld het type meetinstrument) vast te leggen. Hiermee heeft de gebruiker inzicht in de nauwkeurigheid (zie ook Catalogus GMW par 2.9 v0.7 pag 17). Techniek Ingebrachte vragen/bevindingen die aan bod zijn gekomen bij de groepsopdracht 1. Biedt de uitvraagservice naast SOAP ook de mogelijkheid voor harvesten van GMW via initiele loading en mutatieberichten? Als gekozen wordt voor lokale opslag van data kan de data in sync blijven door het harvesten van data binnen het eigen softwaresysteem. Daarbij moet dan wel rekening worden gehouden met de updatefrequentie. In deel query s kan dan de data opgehaald worden; er is immer een restrictie op het tegelijkertijd opvragen in een selectieset. Bij de officiële livegang van de BRO zal het overigens mogelijk worden om gebruik te maken van Digilevering, waarbij een abonnement genomen kan worden op een interessegebied. Op die manier krijgt men automatisch een melding bij mutaties. 2. Aanvullende data afnemers uit de praktijk gezocht voor test en interviews. Initieel zijn er consortia opgezet waarbij bronhouder/leverancier/software ontwikkeling zijn ondergebracht. Maar hoe zit het met de gebruikers van die data? In sommige consortia zijn die immers niet vertegenwoordigd. Voor deze situaties geldt dat die eventuele praktijkvragen in sommige consortia nu niet meegenomen zijn. 3. Hoe juiste informatie krijgen voor een doelgroep? Voorbeeldberichten dan wel leesbaar document met specificatie voor software-ontwikkeling.

6 De documentatie zoals die nu is opgeleverd bevat veel tekst en herhalingen. In de periode tot 1 juli is wordt gewerkt aan de ontwikkeling van uniforme documentatie. Daarbij wordt meegenomen dat documentatie ook specifiek op een gebruikersgroep gericht moet zijn (bijvoorbeeld inhoudelijk versus softwareontwikkeling). De voorbeeldenberichten gaan daar ook onderdeel van uitmaken. Deze ketentest draagt eraan bij hoe de documentatie eruit moet komen te zien. 4. Hoe kunnen grootschalige analyses worden uitgevoerd zonder datadubbeling? Het is op dit moment niet voorzien dat de webservices analysefunctionaliteit krijgt. De functionaliteit is gericht op authentieke registratie. Als dit later bij de grondwaterstanden een issue is, kan dit mogelijk via PDOK worden oplost. Doormiddel van een download voorziening van grote berichten. Plenaire terugkoppeling Wat betreft de handleidingen: wat moet anders vanuit gebruikers- en ontwikkelperspectief? De nadruk moet liggen op minder en meer gestructureerde documentatie voor een specifieke gebruikersgroep. Voorbeeldberichten moeten daar onderdeel van uitmaken. Vanuit de software-ontwikkelaars komt de opmerking dat er ook tooling is waarmee API frameworks kunnen worden ontsloten waarbij ook de benodigde documenten zijn meegenomen. Dit hoeft dan niet per se met een soap interface. Waar wordt een programmeur blij van? REST en JSON, Swagger (gestructureerd framework voor API) in plaats van API in Word. Wat betreft de analysefunctionaliteiten: moet dat juist wel of niet in de BRO zitten? De meningen zijn hierover verdeeld. In de huidige aanpak zijn analysefunctionaliteiten niet opgenomen. De BRO is een register voor de brongegevens. Om echter grootschalige analyses uit te kunnen voeren moeten er potentieel grote hoeveelheden data worden opgevraagd bij de BRO. Vanuit IenM komt hierop de reactie dat er mogelijkheden worden verkend om Publieke Dienstverlening Op de Kaart (PDOK) te betrekken om tegemoet te kunnen komen aan deze wensen. Net als andere basisregistraties gaat het bij de BRO immers ook om open data, die waarschijnlijk ook beschikbaar komen via het geoknooppunt (PDOK). PDOK heeft daar een aantal opties voor. Oplossingsrichting: bulk download of als service (data services of files?). Als een nieuw registratieobject in de BRO zit, komt dat op die manier ook stapsgewijs bij PDOK beschikbaar. Uiteindelijk gaat het erom gegevenstoegang zo makkelijk mogelijk en zo snel mogelijk te maken. Vanuit architectuur zijn dan twee aspecten belangrijk: het moet gaan om open data en API s moeten makkelijk beschrijven zijn. Overige vragen/bevindingen 1. Voor dataleveranciers is ook lokale opslag in lokale database van belang. Is het mogelijk om generieke DDL-scripts te leveren en/of te delen voor toepassing in het eigen systeem?

7 Afgelopen najaar is tijdens de bezoeken van TNO aan de consortia met name gesproken over hoe de huidige software van aanleverende partijen aansluit op de BRO. De concepten zijn gedeeld en TNO is blij dat er partijen zijn die de ontwerpkeuzes onderkennen en overnemen in de eigen ontwikkelingen. De BRO bevat slecht dat deel van de putgegevens dat voor hergebruik belangrijk is. Hierdoor is echter niet het complete werkpakket afgedekt voor een bronhouder/ontzorgende partij. 2. Het is prettig als gezocht kan worden op kenmerken om een BRO-ID van een put te verkrijgen. Hoe ziet de historie van putkenmerken eruit ofwel is er een voorbeeldbericht van RPP(?)- Request met antwoord? Deze request zijn er en kunnen via de SelfServiceDesk worden aangevraagd. Bij de livegang van het BRO-systeem voor het registratieobject GMW zullen deze ook beschikbaar komen via de site BROinfo. Proces en Organisatie Ingebrachte vragen/bevindingen die aan bod zijn gekomen bij de groepsopdracht 1. Stelling: als bronhouder worden we door de dataleverancier volledig ontzorgd! Deze stelling zorgt voor een levendige discussie, waarbij ook andere ingediende vragen aan bod komen: 2a. Testen we bij de ketentest de techniek van de koppelvlakken (webservices) of juist het proces van inwinnen, doorleveren en bevragen van de putgegevens? Inclusief het terugmelden en corrigeren? 2b. Hoe plaatsen we de ketentest in de context van de praktijk, denk daarbij aan mutaties in een put en bijbehorende benodigde faciliteiten? 2c. Ik heb zorgen over de onafhankelijkheid van leverancier als je als bronhouder ontzorgd wilt worden wat betreft het aanleveren van gegevens aan de BRO. 2d. Hoe gaat de BRO de taak en rol van bronhouders veranderen, met name voor die zaken die niet tot de kerntaken van bronhouders behoren. Het grootste deel van de aanwezige bronhouders beaamt de stelling dat ze door bronhouders volledig ontzorgd worden. Toch zijn er ook bronhouders die in hun eigen systeem een inhoudelijke controle willen doen, voordat de gegevens in de BRO geregistreerd worden. Het beeld is dat bij provincies wel de daarvoor benodigde inhoudelijke kennis aanwezig is, maar bij (kleine) gemeentes bijvoorbeeld minder. Er wordt in dat kader gewezen op de verantwoordelijkheid die een bronhouder heeft voor de in de BRO aanwezige gegevens als de BRO in productie is. Tijdens de ketentest kan hierop al worden geanticipeerd door als bronhouder actief mee te kijken en te beoordelen hoe je als bronhouder straks zicht/controle houdt op de registratie van jouw gegevens. Het is belangrijk voor bronhouders om te beoordelen of het werkproces werkbaar is. De ketentest is dus meer dan alleen het testen van de techniek van gegevensuitwisseling. Al worden nog niet alle facetten van de verantwoordelijkheden in de ketentest getest. Zo valt het terugmelden buiten deze ketentest. Wel is het corrigeren van gegevens onderdeel van de ketentest.

8 Er is in het kader van het ontzorgen mogelijk behoefte aan een soort certificering van BRO dataleveranciers. Anderzijds wordt gezegd dat dit de onafhankelijkheid van marktpartijen en keuzevrijheid tijdens aanbestedingstrajecten niet in de weg mag staan. Een directe oplossing is er niet. Bronhouders zien de BRO voornamelijk als systeem om hun eigen gegevens te registreren. De meerwaarde van de BRO voor hergebruik van in de BRO aanwezige gegevens die afkomstig zijn van andere bronhouders, wordt betwijfeld. Gesteld wordt dat de BRO voor bronhouders geen extra werk of verantwoordelijkheid moet geven. De BRO-wet moet het leven makkelijker maken, niet moeilijker. Ten slotte wordt gesproken over het verschil tussen DINO en DINOloket, dat niet bij iedereen duidelijk is. DINO is de database van TNO, waarin momenteel de gegevens geregistreerd zijn. Gegevens uit DINO die voldoen aan de BRO-eisen worden geconverteerd naar de BRO. DINOloket is het interactieve uitgifteportaal. DINOloket vertrekt gegevens uit DINO en waar al van toepassing komen deze gegevens uit de BRO. DINOloket blijft ook in de toekomst een portaal om BRO-gegevens op te vragen en is daarmee dus een alternatief voor het gebruik van webservices. Overige vragen/bevindingen 1. Een compliment voor de kwaliteit en het moment van de ketentest GMW Waarvan akte. 2. Is het aanleveren van productiedata of productie-like data onderdeel van de ketentest? Het registreren van feitelijke putgegevens tijdens de ketentest mag. De ketentest wordt echter niet strikt gezien als performance (load)test. Eventuele bevindingen hierover zijn te zien als bijvangst. Het is daarbij belangrijk om te realiseren dat na afloop van de ketentest de inhoud van de testomgeving niet wordt overgezet naar de productie omgeving en dus niet al geregistreerd is in de BRO. 3. Wat houdt gedelegeerd bronhouderschap in? Waarom wordt (juridisch) hiervoor gekozen? Beoordeling van juridische implicaties mbt gedelegeerd bronhouderschap valt buiten de scope van TNO-GDN en vragen daarover moeten aan het Ministerie van I&M worden gericht. 4. Tijdens de gegevensinname wordt bijvoorbeeld niet gecontroleerd of meerdere malen dezelfde put wordt geregistreerd. Hoe zou je dit soort checks kunnen toevoegen en bij wie ligt die verantwoordelijkheid? Bij de innameverzoeken worden diverse automatische controles en validaties uitgevoerd op feitelijke fouten t. a.v. de gegevensinhoud van het aangeleverde innameverzoek. Er wordt gecheckt op volledigheid, op logische businessregels en de inhoud van domeinwaarden (zie Catalogus GMW v0.7). De leverancier krijgt bij een afwijzing door de BRO in het antwoordbericht te zien wat er fout is aan de inhoud van de brondocumenten. De BRO checkt/waarschuwt niet op waarschijnlijke of vermoedelijke fouten, zoals bijvoorbeeld dubbele putten omdat de beoordeling van

9 zo n vermoedelijke fout niet aan de BRO is. Dit valt onder de verantwoordelijkheid van de bronhouder. 5. Wie is verantwoordelijk voor de kwaliteit (aansprakelijkheid)? Hoe vindt terugmelding van fouten/onvolkomenheden plaats? Bronhouders zijn zelf verantwoordelijk voor de kwaliteit van de inhoud van de BRO. Er zijn een aantal instrumenten om de kwaliteit van de inhoud te borgen: De in de catalogus vastgestelde, eenduidige gegevensinhoud van een registratieobject en de controle daarop tijdens het registratieproces. Door de aangeleverde brondocumenten vast te leggen in een apart register, zodat. de bron van de geregistreerde gegevens altijd raadpleegbaar is. Door het terugmeldprincipe: bestuursorganen zijn verplicht om bij twijfel aan de juistheid of het ontbreken van authentieke gegevens een terugmelding te doen aan de registratiebeheerder. De registratiebeheerder legt de terugmelding ter beoordeling bij de bronhouder neer. De BRO verkrijgt daarmee een zelfreinigende werking. Beoordeling van juridische implicaties mbt aansprakelijkheid valt buiten de scope van TNO-GDN; vragen daarover moeten aan het Ministerie van I&M worden gericht. 6. Wanneer stuur je gegevens in? Wat en wanneer kan gecorrigeerd worden? De bronhouder dient binnen 20 dagen na ontvangst (en controle) een gegeven aan te leveren aan de BRO of te laten aanleveren door dataleverancier die namens hem daartoe het leverantierecht heeft gekregen. Nadat een gegeven is geregistreerd, kan de bronhouder op elk gewenst moment een correctieverzoek indienen bij de BRO. Er zijn vier soorten correctieverzoeken: het vervangen van een waarde (herstel van een geregistreerde foute waarde), het invoegen van een aanvulling (herstel van een vergeten aanvulling), het verplaatsen van een aanvulling (herstel van de datum van een aanvulling) en het verwijderen van een gegeven (herstel van een onterecht geregistreerd gegeven of aanvulling). De laatste twee soorten correctieverzoeken vallen buiten scope van deze ketentest. 7. Hoe vindt de transitie plaats van info van DINO naar de BRO? Voorafgaand aan het in productie nemen van een registratieobject doorloopt TNO een transitietraject voor de betreffende gegevens in DINO. Het doel is zoveel als mogelijk gegevens te converteren van DINO naar de BRO. Voorafgaand aan de daadwerkelijke conversie wordt daarom een kwaliteitsverbeterings- en verrijkingsproces doorlopen, waarbij gegevens in DINO worden verbeterd, aangevuld (o.a. door ontbrekende gegevens op te vragen bij huidige dataleveranciers/bronhouders en zo mogelijk ook door gegevens af te leiden uit andere gegevens in DINO). Waar van toepassing wordt dit traject afgestemd met de beoogde bronhouders. 8. Wanneer komen de boorbeschrijvingen in de BRO beschikbaar? Boorbeschrijvingen vallen onder het registratieobject Booronderzoek. Dit valt onder tranche 2. Het BRO programmabureau van IenM heeft het standaardisatietraject van de registratieobjecten in tranche 2 gepland in de periode april-december Voor de bouw/test en implementatiefase is door het Programmabureau nog geen tijdlijn gegeven.

10 9. In welke mate worden analyses binnen de BRO uitgevoerd en is het mogelijk om lokaal te analyseren op selecties uit de BRO en deze terug te leveren aan de BRO? In de BRO worden, met uitzondering van de bodem- en ondergrondmodellen, in beginsel alleen niet geïnterpreteerde data geregistreerd waarvan de kwaliteit door de bronhouders wordt geborgd. Wel is in het domein grondwatermonitoring in de dialoog met inhoudelijke experts de behoefte onderkend om het resultaat van door de bronhouder uitgevoerde beoordelingen van grondwaterstand- en grondwatersamenstellingsreeksen te registreren in de BRO. Deze synthese registratieobjecten zijn nog niet voldoende gedefinieerd. Dit wordt in de komende standaardisatietrajecten uitgewerkt.