Skip to content

Verslag gebruikersoverleg BRMO 20 02 2018

Chris van Lith edited this page Mar 22, 2018 · 21 revisions

Aanwezig

• René wassink (databasebeheer, BI)
• Martjan Hendriks (BI BRMO)
• Arne Peters (GEO regisseur)
• Guust Vriends (GEO ICT Informatievoorziening) 
• Dennis Flikweert (GGO GEO cluster, hosting BRMO server B3)
• Johan Pruim 
• Maaike Bos (databasebeheer)
• Reinier van den Anker (proj leider salarisadm)
• Youri Soemers (Gegevensmanagement, BRMO)
• Hein Peeters (databasebeheer)
• Jos Bakkes 
• Mark Wolters 
• Herwin Kloosterman (B3Partners)
• Chris van Lith (B3Partners)
• Ab Tuyp (B3Partners)

Afwezig

• Dick Vastenhoud (Wetterskip Fryslan) 
• Reinder Hoekstra (Provincie Overijssel) 
• Margot Quist (Gemeente Gouda) 
• Marieke de Jong (Provincie Flevoland) 
• Ed van der Linden (Gemeente Vlaardingen) 

1. Opening

Chris heet aanwezigen welkom en dankt iedereen voor de opkomst. Het is de eerste keer dat dit overleg op de lokatie van B3Partners plaatsvindt.

a. Vaststellen agenda

De agenda wordt vastgesteld.

b. Verslag vorig overleg

Stond op Github. Geen opmerkingen.

2. Views en services op BRMO database

Platform voor communicatie tussen B3 en klanten.
Het geheel is nog voor verbetering vatbaar.
Het overleg van vandaag is o.m. bedoeld voor feedback.

Algemene introductie GIThub

Chris geeft een korte demo op televisiescherm.

Afbeelding

GIThub is openbaar
Iedereen kan publiceren op GIThub na aanmaak van een useraccount.
Reactie van een gebruiker: publiceren gaat niet makkelijk en moet goedgekeurd worden door B3Partners. Op een vraag aan aanwezigen of Github al eens geraadpleegd was, wordt door enkelen bevestigend geantwoord; als naslag.

Afbeelding

Afbeelding

Voorstellen m.b.t. gebruik Github:

  • Is het mogelijk om de Wiki als enige informatiebron te gebruiken, dus niet werken met extra PDF's? B3Partners stelt specifieke handleidingen beschikbaar voor klanten. Wiki's moeten worden gezien als openbare informatie.
  • Graag een duidelijk verschil aanbrengen tussen GIThub-contributies afkomstig van B3Partners en die van anderen.

Github onderdelen belicht

Issues (menubalk Github)
Hier kan iedereen meldingen plaatsen, ook mensen die geen onderhoudscontract hebben met B3Partners; dit betreft het Open Source gedeelte. Voor klanten van B3Partners geldt: verwerking en inplanning issues werkt sneller via B3Partners Support.

Wiki (menubalk Github)
Wikipagina's bevatten teksten en documentatie. Tekst ziet u links, een navigatiemenu ziet u rechts. De huidige inhoud is organisch gegroeid. Het verbeteren van de paginastructuur en daarmee ook de zoekmogelijkheden, is een taak van B3Partners (Ab Tuyp). B3Partners stuurt binnenkort een voorstel per mail rond, met verzoek om beoordeling van de te volgen werkwijze.

Releases (onder GH menu: <> Code)
Instanties die geen onderhoudscontract hebben met B3Partners, kunnen hier nieuwe versies ophalen en zelf installeren.
Laatste release = groen schildje.
Draft = nog niet formeel gereleased.

Views in map Datamodel bij de code op GitHub

Doel hiervan was om eindgebruikers data te presenteren uit een ingewikkeld datamodel. Een soort tussenlaag met gebruiksvriendelijke views. Het geheel is echter een eigen leven gaan leiden. Prov Zeeland is momenteel bezig met optimalisatieslag en zal hier het volgende overleg inzicht in geven.

Provinciale views
P8 views zijn beetje uit controle gegroeid, bevatten doublures.

Opbouw van RSGB datamodel
Mapje unsupported?

Afbeelding

Per klant mapje met aangeleverde gegevens.
Bevat doublures die soms per provincie kleine verschillen bevatten.
Moet gestroomlijnd worden.

Voorstel nieuwe structuur views

Subjecten/personen
Scheiding wel/niet privacy gevoelig.
Eén grote join van maken: complete subject view AVG (=dik).

  • subjectid: identificatie
  • type: natuurlijk of niet-natuurlijk subject
  • generieke_naam: algemene naam voor (niet)-natuurlijk subject
  • niet_natuurlijk_subject_kvk: KvK nummer
  • niet_natuurlijk_subject_bedrijfsnaam: bedrijfsnaam
  • niet_natuurlijk_subject_plaats: bedrijfsplaats
  • niet_natuurlijk_subject_rechtsvorm: rechtsvorm
  • natuurlijk_subject_voornaam: voornaam
  • natuurlijk_subject_tussenvoegsel: tussenvoegsel
  • natuurlijk_subject_achternaam: achternaam
  • natuurlijk_subject_geslacht: geslacht
  • natuurlijk_subject_geboorte_datum: geboortedatum
  • natuurlijk_subject_geboorteplaats: geboorteplaats
  • natuurlijk_subject_geboorte_land: geboorteland
  • natuurlijk_subject_overlijdens_datum: overlijdensdatum
  • generiek_adres: volledig adres op één regel
  • postcode: postcode (meestal leeg)
  • adres: straat en nummer (meestal leeg)
  • woonplaats: woonplaats

BAG

Bevat veel joins.
Voorstel: ook hier normaliseren.

  • Adres zonder locatie (nummeraand.)
  • identificatie
  • gemeente
  • woonplaats
  • straatnaam
  • huisnummer
  • huisletter
  • huisnummer toevoeging
  • postcode
  • Adres met locatie door koppeling met:
  • Verblijfsobject
  • Ligplaats
  • Standplaats

Kadaster

Appartementsrechten hebben geen geografie. Gebeurt nu op veel verschillende plekken.
Voorstel: basisview.

Eigendomskaart is nu heel complex. P8 views kunnen ook veel simpeler. Kadastraal objecten (optelling van percelen en appartementsrechten)

  • Identificatie, aard cultuur onbebouwd, aard bedrag, bedrag, koopjaar, meer onroerend goed, valutasoort, locatie omschrijving (kadastraal object)

  • aanduiding soort grootte (alleen perceel)

  • grootte perceel (alleen perceel)

  • gemeentecode

  • sectie

  • perceelnummer

  • appartementsindex (alleen appartement)

  • vereniging van eigenaars (alleen appartement)

  • aanduiding (gemeentecode+sectie+perceelnummer)

  • begrenzing perceel (bij appartement: grondperceel)

  • Zakelijk recht

  • aandeel: teller/noemer

  • aard recht

  • eigenaar: (niet-)natuurlijk subject

Discussie voorstel nieuwe views

Vragen en antwoorden.

V: Waarom zijn al die views nodig?
A: Een verschil in gebruik door provincies en gemeenten, is dat de laatst groep wat meer zelf doet.
Belangrijk is dat geen privacygevoelige gegevens worden vastgelegd.

V: Komt er ook een standaard voor NHR?
A: Chris komt langs, in Assen.

V: Er is behoefte aan zoekveld per adres. Is daar een mogelijkheid voor?
A: Bekeken moet worden wat officiële instanties daarvan vinden?

V: Kan de zoekfunctie tweeledig worden gemaakt? Enerzijds: kaart, anderzijds: administratief?
A: Dit moet in Flamingo geconfigureerd worden.

V: Zijn er nog andere basisviews te bedenken?
A: Waterverbruik. Datamodel is open.

V: Is er verschil tussen authentieke en actuele gegevens..?
A: Dit zal getest moeten worden op acceptabele snelheid. Vlaardingen heeft bij alle views doc nr (bv notariële akte) toegevoegd en getoond aan eindgebruikers. Dit houdt in: extra join om dit op te halen.
Ongeveer de helft van aanwezigen ondersteunt dit verzoek – ook met oog op wetgeving.
Er komen één op één gesprekken ter verwerking van info en verkenning van de wensen.

V: Hoe zit het met AVG compliance?
A: Chris geeft toelichting mbt Soap, ESB en meer. B3Partners heeft een expert aangetrokken op gebied van AVG: Jos Koper. Voorstel: kennissessie door Jos Koper?

3. Laden van foutieve gegevens uit LV's en omgang hiermee

Opnemen in BRMO database? Foutieve datum begin geldigheid ver in de toekomst Staging OK

Afhankelijk object ontbreekt: • RSGB_NOK of RSGB_BAG_NOK in staging database

Discussiepunt: landelijke gegevens

Er zijn fouten in landelijke gegevens. Hoe gaan we hiermee om? Werking nu: object (bv pand) wordt pas geplaatst na verkrijging datum. Door tikfout komt een pand niet voor 2207 in BRMO.

Wat in de discussie voorbij komt: eigenlijk zou terugmelding verplicht moeten zijn. Martjan vertelt verhaal m.b.t. correspondentie met kadaster. B3P heeft een extra vlag toegevoegd, waarmee herstel stuk makkelijker wordt. Automatisch registreren van (alle) fouten heeft risico’s in zich. Keuze: automatisch registreren bij meer dan 2-3 gebeurtenissen per maand. Problemen met kadaster zijn kennelijk talrijk, maar er zijn ook verbeteringen waarneembaar.
BRMO kent geen koppeling met kadaster mbt foutmeldingen(?).
Voor terugmeldrol (?) zou B3P module kunnen bouwen.
B3P maakt voorstel.
V: worden dan straks issues teruggemeld aan prov en niet aan gemeenten? A: Verwachting is van niet.

4. Informatie over (aankomende) releases

1.5.2 release bevat BAG fout/oplossing?

1.5.3 is in ontwikkling.

Tomcat 6 wordt niet meer ondersteund.
Library updates etc.

1.5.2:
TOPNL bug fixes en database schema aanpassingen en nieuwe parser voor Top250NL
Nieuwe bericht status code "RSGB_BAG_NOK" als transformeren van een BAG bericht niet lukt vanwege een foreign key constraint violation

1.5.3 (draft):
Ondersteuning voor Tomcat 8.5.x, Tomcat 7.0.x is met ingang van deze release de minimaal benodigde versie Library updates
Update van de gemeente, wijk en buurt tabellen
Let op, deze data updates dienen apart te worden uitgevoerd en zijn geen onderdeel van de reguliere upgrade procedure.
In de pipeline:

  • T&T koppeling

5. Voortgang/aandachtspunten implementatie

Voortgangsrondje stand van zaken BRMO Marc: Bezig met voertuigen

Martjan: bezinning. Roadmap voor toekomst. Afgeketst: WOZ, HR. Kwestie van optimaliseren Guust: afscheid Neuron appl, start met BRMO.
Views zullen voor GEO heel welkom zijn.
Dennis: Voor W3 ? BRMO gevuld, bezig basisregistraties vullen en bijhouden.
Dame(?): heeft nog pas recent inloggegevens. Nog weinig mee gewerkt.
Prov Flevoland: pas Fl geupdated, nog issues, bezig aanvullende views maken mbt om aankoopdata.

Maaike: BRK in productie, BAG in test mbt dagelijkse mutaties, BGT behoefte aan mutaties, Drente ingevoerd, Groning nog niet. Draaien gehele info proces = 17 uur.
Youri: nieuwste versie, BRK functioneert nog steeds goed, Oracle, Jenlo? Gaat via ESB, adapture?
Chris vraagt mbt soap interface of hij daarover iets kan melden. In principe koppeling P8? Afgerond. Deels via SOAP, deels via views opgelost. Mag van P8 dingen (?) delen. Kan B3p als basis gebruiken.
Hein: beetje als Jouri, PostGRE, BGT implementatie nog niet, met data : via WMS of WFS. Raakvlakken BRMO. Capaciteit technisch is te beperkt. Moet aandacht verdelen over meerdere disciplines. Men mist functioneel applicatiebeheerders als linking pins, die ook enige technische kennis hebben.

6. Gebruikersoverleg Flamingo en relatie met BRMO overleg

Opiniepeiling: is er behoefte aan gescheiden overleg voor de onderwerpen Flamingo en BRMO? Chris vraagt aanwezigen hun gedachten hierover. De vergadering reageert positief.
Keuze mogelijk maken tussen BRMO of Flamingo? Ja.
Men wil dan beide bijeenkomsten volgen en iemand meenemen ter ondersteuning.

V: Is er dan onderscheid Flamingo / BrMO of prov/gemeenten?
A: Ovl is voor iedereen toegankelijk; onderwerp is het product Fl / BRMO.
Twee dagdelen wordt wat veel gevonden. Voorstel: 2 x 2 uur.

7. Rondvraag

Martjan:
Er bestaat tegenwoordig NHR dig-id, een nieuwe koppeling met KvK. Is er iemand die daar behoefte aan heeft? Youri vertelt van Kofax, bedrijf dat scanning NHR informatie verzorgt. Er was behoefte aan vastlegging NHR bulk met indexering erop.

Maaike:
BGT. Bug waardoor niet meer gebied kan worden opgevraagd, maar losse gridnrs opgegeven moeten worden. Tooltje voor gevonden. Iets voor B3P support? Maaike stuurt een mail.

Hein:
Voornemen prov Zeeland m.b.t. geoptimaliseerde provinciale views. Chris maakt afspraak.

Jos:
Spreekt vertrouwen uit in dit overleg.

Clone this wiki locally