Verslag gebruikersoverleg BRMO 24 5 2016
Aanwezig:
- Hein Peeters (Provincie Zeeland)
- Maaike Bos (Provincie Drenthe)
- Marco Soetens (Provincie Zuid-Holland)
- Niels van Rijn (Provincie Zuid-Holland)
- Carel Stortelder (Provincie Gelderland)
- Dini Scheffer (Provincie Gelderland)
- Dick Vastenhoud (Wetterskip Fryslan)
- Jacques Zeguers (Provincie Limburg)
- Reinier van den Anker (Provincie Overijssel)
- Corné Hogerheijde (Provincie Drenthe)
- Chris van Lith (B3Partners)
Afwezig:
- Aart Allemekinders (Provincie Zeeland)
- Robin Wevers (Provincie Zuid-Holland)
- Marieke de Jong (Provincie Flevoland)
- Harrie van Dijk (Provincie Gelderland)
- Wim van Deijzen (Provincie Gelderland)
- Hans Pettinga (Provincie Drenthe)
- Wim Wispelweij (Provincie Gelderland)
- Jan Haasnoot (Provincie Overijssel)
- Corné de Zwart (Veiligheidsregio Hollands Midden)
- Mario van Wanrooij (Veiligheidsregio Limburg-Noord)
- Mark Wolters (Veiligheidsregio Limburg-Noord)
Chris opent de vergadering en heet de aanwezigen welkom in het bijzonder Dini Scheffer en Jacques Zeguers die voor het eerst deel nemen aan het BRMO overleg.
Aangezien Robin Wevers (PZH) afwezig is, zal alleen Chris in grote lijnen terugkoppeling geven;zie agendapunt 2. Bij de volgende vergadering zal dit onderwerp uitgebreid worden besproken.
Het verslag van vorige keer wordt goedgekeurd.
Robin Wevers (BAG expert bij PZH) heeft een document opgesteld “Aanvullingen handleiding BRMO” (zie wiki )
Chris geeft hier korte uitleg over: Inactieve gegevens: In de BAG komen soms mutaties voor met ingangsdatum in de toekomst, deze moeten nog niet worden opgenomen in de huidige tabellen. Hier is een oplossing voor bedacht. Deze mutaties worden 'geparkeerd' in de staging-database, en later op het juiste tijdstip alsnog toegevoegd aan de huidige tabellen.
Inactieve gegevens ontstaan ook bij synchronisaties tussen de BAG in een gemeente en de BAG Landelijke Voorziening. Hier is nog geen oplossing voor bedacht. Moeten deze gegevens later wel toegevoegd/gecorrigeerd worden? Bij de volgende vergadering zal hierover gediscussieerd worden/wordt beslissing genomen.
Robin heeft alle relaties tussen BAG tabellen in BRMO opgeschreven. (zie tabel handleiding) De begrippenlijst moet gesynchroniseerd worden (dit volgt na volgend overleg)
In een BAG-stand kan ook de historie worden opgegenomen. De BRMO negeert deze historie en haalt alleen de huidige stand uit de standlevering. Dit is om de verschillende basisregistraties op de zelfde manier te behandelen. De vraag is: Wordt dit vaak gebruikt? Soms wel bv. om te zien hoe de steden groeien. Op dit moment wordt de historie niet opgebouwd, technisch gezien is dit wel mogelijk.
Opmerking Gelderland mbt BAG; SKP gaat BAG mutaties leveren. Dit is technisch OK maar er zal wel een behoorlijk achterstand moeten worden ingehaald. SKP gebruikt Digilevering hiervoor en dan worden mutaties van heel NL doorgestuurd. Op zich is voor de BRMO geen probleem, maar de mutaties buiten het oorspronkelijke gebied wordt wel gewoon toegevoegd (geen filter hierop). Het is ook mogelijk een mutatie abonnement (per maand of dag) aan te schaffen bij Kadaster? Via B3P worden de maandmutaties gratis aangeboden.
Tot slot dient gekeken worden naar het puntobject van de verblijfsobjecten in een pand. Dit is vooral van belang bij appartementen. Als een selectie op basis van locatie gedaan wordt dan moet men zich realiseren dat het verblijfsobject op een willekeurige plaats in het pand geplaatst kan zijn. Ook de views moeten hierop nagekeken worden.
Sommige object ID's die gebruikt worden zijn niet geschikt voor ArcGIS. (je moet een uniek nummer hebben) Wens: object ID toevoegen aan alle views. B3P gaat dit uitvoeren.
Men wil weten hoe actueel een object is. Aan de datum van een object kun je niet zien of het onlangs gecontroleerd is of er een update is geweest (ofwel er was geen update gedaan ofwel het object is niet veranderd). Info is wel beschikbaar in staging-database, maar dan zou je een join moeten maken met alle datatabellen: complex en traag. Een soap service kan info geven over de datum van de laatste mutatie, beter zou zijn om zo'n service in staging database te hebben. Metadata zou hierbij de mooiste oplossing zijn. (view waarbij datum steeds uit staging database wordt opgehaald). B3P gaat nog hierover nadenken (beslissing bij de volgende vergadering)? Er is ook twijfel in hoeverre dit gebruikt gaat worden.
De burgelijke gemeente en de kadastrale gemeente zijn niet een-op-een gelijk. Er is wel behoefte aan de vulling van de tabel van de kadastrale gemeente met een geometrie. B3P zal een voorstel doen om die tabel eenmalig te genereren.
B3P geeft aan dat er geen big bang overgang naar RSGB 3.0 komt. Per basisregistratie wordt de update geleidelijk gedaan. Iedereen is het daarmee eens.
Aan de BRMO zijn NHR en BGT modules toegevoegd. Corné (Prov. Drenthe) is aan het testen. Het NHR schema is complex. Tot nu toe gaat het goed. Corne legt uit hoe NHR berichten in de BRMO komen. Via HR services (soap koppeling) worden mutaties opgehaald en deze worden in de BRMO geladen. Via een pilot (1 juni?) worden eenmalig alle bedrijven als set opgehaald. Vervolgens komen de mutaties via digilevering. Bij Noord Brabant wordt een keer per jaar LISA gebruikt om de NHR gegevens op te halen en te actualiseren. Een nadeel is dat de gegevens niet up-to-date zijn.
Bij BGT worden tegels bv. 2x2km opgehaald en in de database geplaatst. Deze kun je periodiek laten lopen (kun je zelf opgeven:1x per maand?). De oude tegels worden verwijderen en de nieuwe neergezet.
Marco: plan van PZH is BGT in BRMO op te nemen. Carel: beheer wordt al gedaan door provincie in andere applicatie. BGT wordt meer gebruikt bij de gemeentes (monitoring) dan bij de provincies.
B3P loopt achter door tijdgebrek. Maaike heeft P8 views van Drenthe omgezet naar Oracle. Ze zal deze op github plaatsen. Rechten: zakelijke rechten komen altijd mee, P8 views gebruiken geen filters (alle rechten worden opgehaald) Soms is de oplossing: de juiste filter toepassen. (zie email Dick) Hein: snelheid P8 views checken bij de andere provincies; zoeken in database- wanneer index niet wordt gebruikt gaat dit traag)
B3P zal views van Sven vergelijken met de algemene views; er zitten mogelijk doublures in.
Dick (Wetterskip Fryslan) : niet verder gekomen ivm verhuizing. Postgres database draait op dit moment bij B3P maar ze willen deze intern hebben draaien (ivm authorisatie, beveiliging persoons- gegevens)
Jacques (Prv. Limburg): sinds een maand zijn ze bezig met het inladen van de data, eerst BRK berichten daarna BAG en misschien BGT
Hein (Zeeland): BRK – berichten soms te groot, gaat niet automatisch via SKP, de laatste mutaties van 23 april! BGT- apart traject Bezig met ESRI – BRMO – capaciteit problemen – ze hebben meer mensen nodig
Dini (Prov. Gelderland): sinds 2 maanden bezig met BR, vooral uitzoeken wat wel/niet loopt Laatste berichten van BRK van 5 april! Ze lopen achter. Bij PDOK recente data ophalen – stand van zaken in beeld brengen
Carel (Prov. Gelderland): test Kadaster van 2 gemeentes– 0 levering BAG – 49 regels niet correct -geen geometrie. Volgens Chris komt dit regelmatig voor. Software is geüpdatet standlevering BAG BRK wordt gebruikt (proces B3P loopt goed) De aangeleverde gegevens van Kadaster zijn niet altijd correct. Problemen van Kadaster verzamelen – vanuit provincies (via werkgroep content; zie ook verslag vorige vergadering). Actie: Carel zal contact opnemen met Peter vd Zwaan.
Corné (Prov. Drenthe) : BRK is in productie –een aantal RSGB_NOK berichten in de de staging database: foutmelding 28992? Kees-Jan (van B3P) is ermee bezig. Geometrie ?aantal records zonder referentie? Mogelijke oplossing: Kadaster moet de gegevens opnieuw versturen. NHR koppeling wordt getest BAG laden – heel NL was te groot, nu alleen Drenthe en Groningen
Reinier (Prov. Overijssel): de aangeleverde berichten van Kadaster waren een paar keer niet correct!
Niels/Marco (PZH): ze gaan BAG en BRK inladen Eerst hebben ze zelf BAG ingeladen, maar dat gaf veel fouten. Vervolgens bij B3P. Uiteindelijk is het gelukt ; initieel geladen In BRK – standlevering – ontbreken objecten, via SKP- op BRMO server – datums ontbreken, al bij aanlevering van Kadaster Daarnaast Problemen met de certificaten Kadaster, en contracten Digilevering: hierdoor duurt het langer dan verwacht
P8view Drenthe is klaar (Maaike heeft deze aangepast op Oracle) Jacques vraagt zich af waarom SKP alleen op vrijdag (1dag) open is! Gebruikers willen soms weten wat de status van de informatie van de kolom is: authentiek of comfort. Deze info staat nu in een aparte tabel waarover een join gelegd kan worden. Op die manier kan de gebruiker geinformeerd worden.
De nieuwe vergadering zal plaatsvinden op 14 september 2016 (bij BIJ12, vergaderruimte In het Bos)
Dit werk valt onder een Creative Commons Naamsvermelding-GelijkDelen 2.0 Nederland-licentie.
