Verslag gebruikersoverleg BRMO 1 3 2016

Aanwezig:

• Hein Peters (Provincie Zeeland)
• Aart Allemekinders (Provincie Zeeland)
• Maaike Bos (Provincie Drenthe)
• Marco Soetens (Provincie Zuid-Holland)
• Niels van Rijn (Provincie Zuid-Holland)
• Robin Wevers (Provincie Zuid-Holland)
• Carel Stortelder (Provincie Gelderland)
• Marieke de Jong (Provincie Flevoland)
• Harrie van Dijk (Provincie Gelderland)
• Wim van Deijzen (Provincie Gelderland)
• Dick Vastenhoud (Watterskip Fryslan)
• Reinier van den Anker (Provincie Overijssel)
• Chris van Lith (B3Partners)

Afwezig:

• Corné Hogerheijde (Provincie Drenthe)
• Hans Pettinga (Provincie Drenthe)
• Wim Wispelweij (Provincie Gelderland)
• Jan Haasnoot (Provincie Overijssel)
• Corné de Zwart (Veiligheidsregio Hollands Midden)
• Veiligheidsregio Utrecht

#1 Opening Chris opent vergadering om 10:30u, Robin Wevers, nieuw vanuit Zuid-Holland, introduceert zich: meegewerkt aan totstandkoming van de BAG.

##1a vaststellen agenda De agenda wordt ongewijzigd vastgesteld.

##1b verslag vorig overleg (zie Github) Punt 4 moet gecorrigeerd worden. Wetterskip Fryslân gebruikt de SOAP service voor schouwen (en niet voor belastingzaken)

#2 Kwaliteit van de data ##2a BRK

• Data van Gelderland is opgeleverd en ingeladen bij B3P. Er zijn afwijkingen geconstateerd (dubbele berichten). Daarom is door b3p een Rapport opgesteld. Er waren ook eigendomsproblemen maar dit is inmiddels grotendeels opgelost. Gelderland heeft een testbestand aangevraagd bij Kadaster (van een klein gebied) om de berichten te kunnen controleren. Wim meldt dat er nog geen vebeteringen zijn en dat klopt omdat de nieuwe dump nog niet is ingelezen. Chris raadt aan de opnieuw getransformeerde dump bij Gelderland in te lezen; deze is al beschikbaar in Gelderland.
• Initiële stand Flevoland was niet in orde, bij Kadaster klopt het al niet: gaten in stand. Voor Flevoland wordt ook een Rapport (analyse) opgesteld. Opmerking Marieke: waarom vindt B3P het inladen van een nieuwe stand uiterste optie? Eerst moet je weten wat er precies aan de hand is:
  – berichten fixen
  – eigendomsrechten (was fout in code, is inmiddels gefixed)
  – en volgorde berichten (mogelijk verwijderberichten gemist in het verleden)
• BRK heeft ook geen volgnummers van berichten, daarom weet je helaas niet of je een bericht mist.
• B3P heeft geometrie query's opgesteld; hierdoor is gebleken dat er gaten in de data zijn en percelen centimeters afwijken. Snippers van centimeters. Is Kadaster daar wel van op de hoogte? Formeel zou dit aan Kadaster gemeld moeten worden.

Is er een Gebruikersraad Kadaster met vertegenwoordiger van provincies? Peter vd Zaan (PZH) was vertegenwoordiger maar raad is opgeheven. Provincies gaan punten verzamelen – na analyse door B3P – doorspelen naar contactpersoon BRK van de Content werk groep. Chris overlegt met Carel en Reinier en koppelt terug via de mailinglijst.

Gelderland vraagt of de koppeling BRP wordt gerealiseerd. Hiervoor is Autorisatie vereist!
Drenthe: autorisatie model opstellen?
Actie: Gezamenlijk oppakken

##2b BAG ###mapping PZH heeft BAG ingeladen. Robin heeft een document (analyse) opgesteld. Hij gaat samen met Chris de punten doorlopen en daarna terugkoppelen aan de groep. ###meerdere gebruiksdoelen Dit is een bug en moet gecorrigeerd worden. ###actualiteitvan gemeente, buurt, wijk en woonplaats Eind van de maand moet update script draaien en daarna periodiek 1x per jaar. ###filter van BAG objecten op status, geldigheid e.a. Bij het inlezen van een nieuwe stand kan een filter gebruikt worden (bijvoorbeeld “geen historie”). Bij PZH is BAG nog wel met historie ingeladen. In actuele situatie is begin- en eindgeldigheid van bijvoorbeeld een pand opgenomen. Stel nu komt er een mutatie bericht na eind geldigheid binnen; hoe om te gaan met toekomstmutaties? Robin en Chris gaan hierover overleggen en vervolgens terugkoppelen aan de groep. ###woonplaats vanuit openbare ruimte of nummeraanduiding Nummeraanduiding zit in datamodel. Chris en Robin gaan dit verder uitzoeken en terugkoppelen. Bij Zeeland is BAG via ETL tool ingelezen; dit gaf afwijkende aantallen, bij PZH via BRMO lader en dit is goed gegaan (geen afwijkende aantallen). ###inactieve records meenemen of niet Graag wel meenemen. ###VBO zonder PAND Fout bij Kadaster: Pand al gesloopt. B3P heeft heel NL ingeladen, hierin zaten 148 fouten (relatief weinig). Dit moet wel gemeld worden aan Kadaster (apart voor BAG en BRK) ###in onderzoek Bij de provincies wordt niet gebruikt, bij de gemeentes wordt deze bijgehouden. ###authentiek vs comfort B3P moet een ander woord vinden voor Authentiek, bv registratie-eigen en comfort. ###terugmeldfaciliteit Een email sturen is niet voldoende, dit moet volgens de DIGI melding gebeuren. #3 Snelheid/betrouwbaarheid van verwerking berichten Het inladen van BAG gaat erg traag. Het zijn grote database tabellen. B3P heeft een oplossing bedacht. Ze maken een kopie van tabel en de status wordt teruggeschreven in de originele tabel. De snelheid loopt nu op tot 300000 records per uur. Betrouwbaarheid: een niet geldig bericht wordt wel opgeslagen ##3a Stand Bij PZH is momenteel de snelheid bij het inlezen van BRK 10 000 records per uur. B3P heeft de BAG van heel NL ingelezen in 5 dagen. Dit moet nog wel getest worden! Begin volgende week beschikbaar. ##3b Mutaties Mutaties gaan nu ook sneller, maar is hiervoor minder relevant. Wens van PZH is het testen met de versie waarmee ze ook live gaan. #4 Voortgang/aandachtspunten implementatie Actie programmeurs: bij het aanmaken van een issue graag wat meer omschrijving (ook voor niet techneut moet dit begrijpelijk zijn). Graag ook vermelden door welke klant/provincie dit issue aangemeld is.
De eerste versie van de provinciale views staan op Github. Door Hein (PZ) is commentaar aan de views toegevoegd: https://github.com/B3Partners/brmo/tree/master/datamodel/utility_scripts/postgresql (300 scripts).
De documentatie is ook op github te vinden: https://github.com/B3Partners/brmo/tree/master/docs/utility_scripts

Voor SQL Server en Oracle moeten de provinciale views nog omgezet worden.

Gelderland heeft views aangepast/verbeterd. Carel vraagt Sven om deze "as is" op te sturen, verbeteren kan later. Ook de P8 views worden graag ontvangen zodat ze op Github gezet kunnen worden.

Bij de volgende vergadering worden de praktische voorbeelden gepresenteerd (met versie 1.0 van de provinciale views wordt in de database gekeken).

#5 Allerlei ##5a beheer via commandline Bij afwezigheid van Gert-Jan niet in detail besproken. PZH heeft mogelijk interesse.

##5b RSGB 3.0 De tabellenstructuur van de BRMO wordt voor de nieuwe registraties geent op RSGB 3.0. Voor de BAG en BRK wordt later overgegaan op 3.0.

##5c NHR en BGT NHR en BGT wordt nu aangepakt.

#6 WVTTK Hein (Zeeland):
de laatste versie van BRMO moet nog geïnstalleerd worden. Het werkt wel. De mutaties komen binnen, ze zijn wel erg groot en de server capaciteit is beperkt. Daarom moeten ze de bestanden zippen. SKP levert helaas de berichten ongezipt. Request SKP: gezipte berichten sturen!

Maaike (Drenthe): de mutaties van BRK lopen. Dat gaat goed.
scripts views Drenthe wil graag stand per 1 januari van BRK. Hiervoor moet een complexe view gemaakt worden die per datum het juiste record opzoekt ofwel in de huidige tabellen ofwel in de archief tabellen. Dit is een stevige klus; B3P zal meekijken.
BAG: ze zijn bezig met het inladen (heel NL)
opschoonfunctie voor staging zou mooie feature zijn, echter volgens B3P heb je van elk object het meest recent record nodig voor het verwerken van mutaties.

Marco (PZH):
BAG is initieel geladen. BRK is klaar en is in acceptatie omgeving. Aangezien het laden erg lang duurt maken ze hier een back up van en dit gaat naar de productie.
Voor BAG mutaties is digi levering nodig.
Niels: Views sql server klopt niet (aantallen)?
Het openen in ArcGIS lukt meestal niet zonder object_id. Op wiki zetten hoe dit moet!

Gelderland:
BAG is initieel geladen. BRK is in productie.

Marieke (Flevoland):
Er zijn veel fouten ontdekt in BRK. Dit moet uitgezocht worden. Er wordt een Rapport (analyse) opgesteld.
kwaliteits test: kwaliteit gegevens door onjuiste query
Kadaster online wordt vaak gebruikt ter controle gegevens.
BRK mutaties lopen rechtstreeks via Kadaster (niet via SKP)

Er wordt afgesproken de kwaliteitsrapporten onderling te delen.

Reinier (Overijssel):
BRK is ingelezen via SKP. Dat ging goed.
fase mutaties lezen - contact opnemen met Kadaster
(maand vertraging)

aart (Zeeland):
opdracht gegeven voor Imro harvester, deze komt in apart schema naast rsgb.

#7 Sluiting