applicatie architectuur svb-bgt - webtradersv2.sparqcms.com/dir_upload/site/e9226f146a2797acf... ·...

rapport

In opdracht van:

Samenwerkingsverband Bronhouders

Applicatie architectuur SVB -BGT

Datum 18 mei 2012 Auteurs Victor van Katwijk / Reinold Pasterkamp Versie 1.0 Status Vertrouwelijk Kenmerk ITP11378

Geodan b.v.

President Kennedylaan 1

1079 MB Amsterdam (NL)

Tel. +31 (0)20 - 5711 311

Fax +31 (0)20 - 5711 333

E-mail [email protected]

Website www.geodan.nl

Rapport Applicatie architectuur SVB-BGT

Kenmerk ITP11378

Datum 18-5-2012 2 / 38 Versie 1.0 Status Vertrouwelijk

Inhoudsopgave

1 Inleiding ......................................... ............................................................................... 4

1.1 Aanleiding ...................................................................................................................... 4 1.2 Doel ................................................................................................................................ 4 1.3 Leeswijzer ...................................................................................................................... 5

2 Visie op de applicatie architectuur................ ............................................................. 6

2.1 Hoofdtaken ICT ondersteuning ...................................................................................... 6 2.1.1 Coördineren van de transitie ........................................................... 6 2.1.2 Opbouw en bijhouding IMGeo/BGT ................................................ 6 2.1.3 Terugmeldingen .............................................................................. 6

2.2 Uitgangspunten en spelregels ....................................................................................... 7 2.3 Richtlijnen en standaarden ............................................................................................ 9

2.3.1 Richtlijnen........................................................................................ 9 2.3.2 Standaarden ................................................................................... 9

2.4 SVB in de keten ............................................................................................................. 9

3 Proces beschrijvingen ............................. .................................................................. 11

3.1 Verwerking mutatieberichten ....................................................................................... 11 3.1.1 Mutatie verwerken tot mutatiebericht ............................................ 12 3.1.2 Valideren en completeren van het mutatiebericht ........................ 14 3.1.3 Assembleren ................................................................................. 15 3.1.4 Filteren IMGeo tot IMBGT ............................................................. 16 3.1.5 Accorderen mutatiebericht ............................................................ 16 3.1.6 Doorleveren aan de landelijke voorziening ................................... 16

3.2 Verwerking van terugmeldingen .................................................................................. 16 3.3 Coördinatie van de transitie ......................................................................................... 18

4 Applicatie landschap .............................. ................................................................... 19

4.1 Legenda ....................................................................................................................... 19 4.2 Analyse van de business laag ..................................................................................... 19

4.2.1 Organisatie .................................................................................... 19 4.2.2 Business services en producten ................................................... 21

4.3 Analyse van de applicatielaag ..................................................................................... 27 4.3.1 Services endpoint ......................................................................... 28 4.3.2 SVB-BGT Portaal .......................................................................... 29 4.3.3 Authenticatie en autorisatie........................................................... 30 4.3.4 Validatie systeem .......................................................................... 30 4.3.5 Automatische assemblage ............................................................ 31 4.3.6 Administratie ................................................................................. 31 4.3.7 Rapportage component ................................................................ 32 4.3.8 Terugmelding analyse ................................................................... 32 4.3.9 BGT Repository ............................................................................ 32 4.3.10 Enterprise service bus .................................................................. 32

5 Niet functionele eisen ............................ .................................................................... 34

5.1 Beveiliging .................................................................................................................... 34


Kenmerk ITP11378


5.2 Backup ......................................................................................................................... 34 5.3 Beschikbaarheid ........................................................................................................... 34 5.4 Schaalbaarheid ............................................................................................................ 34

6 Roadmap ........................................... .......................................................................... 35

6.1 Planning van de ICT voorzieningen community .......................................................... 35

Bijlage 1, begrippenlijst ......................... ........................................................................................ 37


Kenmerk ITP11378


1 Inleiding Dit document betreft de applicatie architectuur voor de ICT voorzieningen van het SVB-BGT.

1.1 Aanleiding

Het SVB-BGT is van en voor bronhouders en in het leven geroepen om gezamenlijk een landsdekkende objectgerichte basiskaart grootschalige topografie (BGT) te maken en te onderhouden. De stichting wordt in het eerste kwartaal van 2012 opgericht en gaat vervolgens direct aan de slag met het ondersteunen en begeleiden van de bronhouders. De hoofdtaken van het SVB-BGT bestaan uit:

1) Het regisseren van de transitie naar de BGT. 2) Het afstemmen en assembleren van de basiskaart, inclusief kwaliteitscontrole,

terugmeldingen verwerken en levering aan de landelijke voorziening BGT (LV BGT). 3) Het faciliteren van de bronhouders bij aanvullende diensten en producten zoals de

inwinning en bijhouding van de BGT. Bij de uitvoering van deze taken is een ICT ondersteuning nodig. In dit rapport is de applicatie architectuur ten behoeve van de rol van het SVB-BGT bij de opbouw en bijhouding van de basiskaart uitgewerkt. Het zwaartepunt bij de ICT component ligt op hoofdtaak 2, de afstemming en assemblage van de BGT. De administratieve ondersteuning van bijvoorbeeld de facility taken vallen buiten de scope van deze applicatie architectuur. Het SVB-BGT heeft besloten om naast BGT ook de optionele IMGeo objecten en attributen te ondersteunen. De bronhouders mogen daartoe zowel IMGeo als BGT aanleveren. Als in dit document over de basiskaart wordt gesproken is dit minimaal BGT en maximaal IMGeo. De ondersteuning van 3D volgt later in het groeimodel. In eerste instantie wordt nog geen 3D ondersteund. Wel wordt de hoogte van een object als onderdeel van de coördinaat (GM_point) van het plaatsbepalingspunt ondersteund.

1.2 Doel

De applicatie architectuur beschrijft de processen en functionele applicatie componenten voor de ICT ondersteuning van bovengenoemde taken. De applicatie architectuur dient als uitgangspunt voor de realisatie en implementatie van de applicatie architectuur.


Kenmerk ITP11378


1.3 Leeswijzer

De applicatie architectuur is niet de beschrijving van de architectuur van één applicatie, maar beschrijft welke applicaties nodig zijn om de benodigde business processen te implementeren en hoe die applicaties samenwerken. Er wordt ook wel gesproken over een applicatie landschap, enterprise architectuur of solution architectuur. De interne werking van applicaties wordt hier niet besproken. De beoogde infrastructuur valt buiten de scope van een applicatie architectuur. Met de infrastructuur wordt de hardware en systeem software bedoeld waarop de applicaties draaien. Dit moet in een later stadium worden uitgewerkt en is afhankelijk van implementatie keuzes en niet functionele eisen m.b.t. schaalbaarheid en beschikbaarheid. In het volgende hoofdstuk (2) wordt de visie gegeven op de applicatie architectuur, de uitgangspunten en spelregels. In hoofdstuk 3 is het proces uitgewerkt. In hoofdstuk 4 is de applicatie architectuur zelf beschreven. In hoofdstuk 5 staan de niet functionele eisen gevold door een begrippenlijst in de bijlage.


Kenmerk ITP11378


2 Visie op de applicatie architectuur De applicatie architectuur beschrijft de ICT voorzieningen van het SVB-BGT. De ICT voorzieningen van het SVB-BGT ondersteunen het SVB-BGT bij de uitvoering van haar taken. Meer specifiek; de ICT voorzieningen in deze applicatie architectuur ondersteunen het SVB-BGT bij de volgende taken:

1. Coördineren van de transitie; 2. Opbouw en bijhouding van de landelijke basiskaart IMGeo/BGT tot een landsdekkende

objectenkaart in de periode tot 1 januari 2016; 3. Afhandelen van terugmeldingen;

In dit hoofdstuk zijn deze onderdelen kort beschreven. In de hoofdstukken daarna volgt de applicatie architectuur per onderdeel.

2.1 Hoofdtaken ICT ondersteuning

2.1.1 Coördineren van de transitie Ten behoeve van de coördinatie van de transitie is inzicht in de status en ambities van de transitieprojecten, de bronhouders en de transitiegebieden noodzakelijk. De applicatie architectuur bevat een voorziening waarmee zowel bronhouders als regisseurs de status en ambities op een centrale plek kunnen bijhouden en toegang hebben tot die informatie. Een kaartoverzicht van de voortgang behoort tot de voorzieningen.

2.1.2 Opbouw en bijhouding IMGeo/BGT De opbouw en bijhouding van IMGeo/BGT is het hoofddeel van de applicatie architectuur. Hierbij wordt de verwerking van de initiele opbouw en van de bijhouding van de gegevens geregeld. De belangrijkste onderdelen hierbij zijn:

1. Besturing en afhandeling van het berichtenverkeer in een elektronische service bus. 2. Validatie van mutatie berichten 3. Assembleren van de mutaties (automatisch en waar nodig ook handmatig) 4. Accorderen van de verwerkte mutaties 5. Doorleveren van complete mutatieberichten aan de landelijke voorziening (LV) 6. Toegang bieden tot de centrale productiedatabase voor synchronisatie en afstemming.

2.1.3 Terugmeldingen De basisregistratie grootschalige topografie voorziet in een terugmeldingen loket als onderdeel van de landelijke voorziening. De terugmeldingen zullen door het SVB-BGT verwerkt worden. Het SVB-BGT doet een filtering op de terugmeldingen en routeert deze naar de betrokken bronhouders. Om dubbele meldingen te voorkomen worden terugmeldingen getoetst op het gepland zijn van een mutatiemelding of een project. Hiertoe voorziet de applicatie architectuur in een portaal om projecten te registreren en registreert het de locatie van geplande en in bewerking zijnde mutatieberichten.


Kenmerk ITP11378


2.2 Uitgangspunten en spelregels

De volgende uitgangspunten gelden voor de applicatie architectuur: 1) Het SVB-BGT is van en voor bronhouders. 2) Het SVB-BGT verzorgt de afstemming en assemblage van IMGeo/BGT objecten, doet

de kwaliteitscontrole en levert aan de landelijke voorziening BGT (LV BGT). 3) De bronhouders stemmen zelf hun bedrijfsprocessen af op de IMGeo/BGT basiskaart. 4) Bronhouders kunnen naar keuze een niet geassembleerd-, een gedeeltelijk- of een

compleet geassembleerd mutatiebericht aanleveren. Dit wordt ook wel het cafetariamodel genoemd. Vanuit de facility van het SVB-BGT kan een bronhouder er ook nog voor kiezen om de gehele inwinning en bijhouding door het SVB-BGT te laten verzorgen.

5) Het SVB-BGT faciliteer het proces van terugmeldingen uit de LV BGT, de bronhouders handelen de doorgezette meldingen zelf af, tenzij het SVB-BGT hiervoor opdracht heeft gekregen van de betreffende bronhouder.

6) Het SVB-BGT registreert waar mutaties worden uitgevoerd aan de basiskaart en waar en wanneer projecten worden uitgevoerd die leiden tot mutaties in de basiskaart. Om dubbel werk te voorkomen moeten organisaties doorgeven waar projecten worden uitgevoerd die objecten van andere bronhouders raken. Dit is ook van belang voor de afhandeling van terugmeldingen en relevant voor andere bronhouders om te bepalen hoe om te gaan met mutaties in een projectgebied en werk op elkaar af te stemmen.

7) Het SVB-BGT verwerkt zowel de wettelijke BGT als ook aanvullende IMGeo informatie.

8) In eerste instantie ondersteunt het SVB-BGT in de community alleen 2D informatie (inclusief eventueel de hoogte van een object als onderdeel van de coördinaat (GM_point) van het plaatsbepalingspunt).

9) Voor bronhouders die IMGeo aanleveren zal een filtering worden uitgevoerd op de IMGeo informatie tot het BGT niveau om een landsdekkende IMBGT te kunnen leveren. De inrichtende elementen en attributen die niet bij BGT horen worden uitgefilterd. De objecten met gelijke BGT attributen worden niet samengevoegd.

10) Het SVB-BGT bouwt ten behoeve van de assemblage en doorlevering aan de LV een landelijke productie- en mutatiedatabase op. De productiedatabase is in principe gelijk aan de LV. In de mutatiedatabase worden de mutaties verwerkt. Als een mutatie door alle bronhouders is geaccordeerd wordt deze doorgezet naar de productiedatabase en de LV. Bij verwerking door de landelijke voorziening wordt de registratiedatum vastgelegd, hierop wordt niet gecontroleerd bij aanlevering van was-wordt.

11) De landelijke SVB-BGT productiedatabase bevat de meest actuele door de gezamenlijke bronhouders geassembleerde en geaccordeerde informatie.

Naast bovenstaande uitgangspunten gelden de volgende spelregels:

A. Alle digitale communicatie met het SVB-BGT verloopt middels berichtenverkeer en webservices. Daarnaast wordt de mogelijkheid geboden om via een uploadportaal mutatieberichten aan te leveren.

B. Het berichtenverkeer is gebaseerd op de IMGeo/BGT berichtenstandaard (Stuf/GML).

C. Het SVB-BGT biedt inzicht in de afhandeling van berichten, de bronhouders kunnen te allen tijde de status van hun mutatieberichten opvragen en bekijken.


Kenmerk ITP11378


D. Mutatieberichten bevatten de wijzigingen in de objecten (was-wordt). De bronhouder moet er zelf voor zorgen dat de ‘was’ overeenkomt met de actuele informatie in de productiedatabase.1

E. Bronhouders kunnen mutaties vooraf melden als een zogenaamde vooraankondiging. Als er overlap is met andere vooraankondigingen ontvangen beide bronhouders een waarschuwing en het verzoek om contact op te nemen met de andere bronhouder.

F. Als een mutatiebericht wordt aangeleverd worden de objecten vergrendeld en ontvangt de aanleverende bronhouder een uniek mutatiebericht_ID. Als er een vooraankondiging gedaan is op hetzelfde gebied door een andere bronhouder zullen beide bronhouders een waarschuwing ontvangen. Hetzelfde geldt voor projectgebieden.

G. Er kan maar één bronhouder tegelijk aan de mutaties van een object werken; er kunnen geen mutaties worden doorgevoerd op objecten die zijn vergrendeld.

H. Het SVB-BGT houdt bij waar welke mutaties worden uitgevoerd, deze informatie zal ook voor bronhouders beschikbaar worden gesteld.

I. Een aangeleverde mutatie zal in maximaal 5 werkdagen worden geassembleerd, vervolgens is er maximaal 5 werkdagen voor het accorderen van het mutatiebericht. Na 5 werkdagen is de ‘bezwaarperiode’ voorbij en worden nog niet geaccordeerde berichten akkoord bevonden. Als na 5 dagen blijkt dat er toch een fout in de verwerking zit, kan een melding worden gedaan via de terugmeldvoorziening.

J. Een vergrendeld object (mutatie) wordt pas weer vrijgegeven als deze is aangeleverd aan de LV BGT. De bronhouder ontvangt een bevestiging van de verwerking door de LV BGT.

K. Als een mutatiebericht afgekeurd wordt gedurende het proces van assemblage en accordering wordt het mutatiebericht teruggezonden naar de aanleverende bronhouder en worden de vergrendelde objecten na 5 dagen vrijgegeven. De bronhouder moet het mutatiebericht opnieuw aanmelden en aanleveren.

L. De assemblage van een mutatiebericht zal waar mogelijk automatisch-, en voor een deel handmatig moeten worden gedaan. Dit leidt tot een compleet mutatiebericht.

M. Een compleet mutatiebericht bevat de wijzigingen in een object plus alle aangrenzende gewijzigde objecten. Daarmee is de buitenpolygoon van een mutatiebericht ongewijzigd ten opzichte van de buitenpolygoon in de productiedatabase en kan als een puzzelstuk worden vervangen. Een mutatiebericht mag geen gaten hebben en betreft een aaneengesloten gebied.

N. Alle bronhouders van de objecten in een mutatiebericht moeten een mutatieverwerking goedkeuren voordat deze doorgezet kan worden naar de LV BGT. De goedkeuring vindt plaats in een portaal van het SVB-BGT. Een

1 Op het moment van schrijven (18 mei 2012) is de exacte inhoud van de mutatieberichten nog niet vastgesteld.


Kenmerk ITP11378


bronhouder heeft 5 werkdagen om een mutatie goed te keuren. O. Terugmeldingen (mutatiesignaleringen) uit de LV BGT worden na een eerste

filtering doorgezet naar de betreffende bronhouders. De bronhouders moeten binnen 5 werkdagen reageren op een terugmelding. De verwerking kan afhankelijk van de melding binnen gestelde termijnen worden gedaan. De termijnen en gradaties moeten nog worden bepaald.

2.3 Richtlijnen en standaarden

2.3.1 Richtlijnen De volgende richtlijn geldt voor de ICT voorzieningen van het SVB-BGT:

• Webrichtlijnen overheid (http://versie2.webrichtlijnen.nl/) • OSOSS • NORA

2.3.2 Standaarden De volgende standaarden gelden:

• Informatiemodel IMGeo 2.0 met daarin opgenomen het informatiemodel voor de BGT. • Berichtenstandaard Stuf/GML, concept versie overgaand in definitieve versie (verwachting

juni 2012). • De W3C webservice standaarden.

2.4 SVB in de keten

In onderstaand schema zijn de rol en de plaats van het SVB-BGT in de keten weergegeven.


Kenmerk ITP11378


Figuur 1, de rol van het SVB-BGT in de keten.

Directie productie & beheer

Bronhouder of ontzorgd SVB

Assemblage

Terugmeldingen BGT

(berichtenverkeer)

Themabeheer grijs/groen/blauw

Levering aan LV BGT

Bronhouder SVB-BGT LV BGT

PLUS

IMGEO

facility

community

IMBGT

Mutatie signalering

Inwinning bronhouder of ontzorgd SVB

Externegebruikers

IMGEO

IMBGT IMBGT

IMGEO


Kenmerk ITP11378


3 Proces beschrijvingen Voor een goed begrip van de gewenste ICT voorzieningen is inzicht in de beoogde werkprocessen essentieel. In dit hoofdstuk zijn de processen opgenomen voor:

- De verwerking van mutatieberichten. - De verwerking van terugmeldingen. - De coördinatie van de transitie opgenomen.

3.1 Verwerking mutatieberichten

De verwerking van de mutatieberichten bestaat uit een aantal stappen. Het hoofdproces ziet er als volgt uit:

Figuur 2, business proces model: verwerking mutatieberichten Een proces wordt geïnitieerd door een mutatie signalering. Dit triggert processtap 1; het opstellen van een mutatiebericht. De bronhouder van de betreffende objecten is verantwoordelijk voor het bijhouden van zijn objecten en zal een mutatiebericht op (laten) stellen. Als het mutatiebericht is opgestuurd en ontvangen door het SVB-BGT volgt proces stap 2; het completeren en valideren van het mutatiebericht. Deze processtap kent een aantal substappen waarvan het assembleren en filteren apart zijn uitgewerkt. Na afronding van processtap 2 volgt processtap 3; het accorderen van het complete mutatiebericht. Na een succesvolle accordering zal het complete mutatiebericht aan de LV geleverd worden. De processtappen in bovenstaand stroomschema zijn ieder verder uitgewerkt in de volgende paragrafen.


Kenmerk ITP11378


3.1.1 Mutatie verwerken tot mutatiebericht Het verwerken van een mutatie tot een mutatiebericht is de verantwoordelijkheid van de bronhouders. Daarbij worden 3 manieren voorzien:

1. De bronhouder beschikt over zijn eigen software voor het maken van een mutatiebericht en werkt daarbij in een ‘eigen’ kopie van de IMGeo/BGT gegevens;

2. De bronhouder beschikt over zijn eigen software voor het maken van een mutatiebericht en werkt daarbij rechtstreeks op de IMGeo/BGT gegevens van het SVB-BGT;

3. De bronhouder maakt gebruik van de online edit mogelijkheid van het SVB-BGT om kleine wijzigingen door te voeren.

Optie 1: In onderstaand business proces model staan de stappen voor het aanmaken van een mutatiebericht conform optie 1.

Figuur 3, business proces model optie 1 mutatie verwerken tot mutatiebericht De activiteit wordt geïnitieerd door een mutatie signalering. Als eerste stap kan de bronhouder een voorgenomen mutatie aankondigen bij het SVB-BGT, deze stap is optioneel. De stappen zijn vervolgens:

- Aankondigen van een mutatiebericht. De bronhouder geeft het gebied aan waarvoor een mutatiebericht gaat worden opgesteld, tevens een indicatie van de verwachte ‘datumgereed’ van het mutatiebericht. Als er reeds mutatieberichten aangemeld zijn in het gebied dan krijgt de bronhouder daarvan een melding met vermelding van de kenmerken van dat bericht (bronhouder(s), datums, etc.);

- Verzamelen van gegevens, geometrie en kenmerken (attribuutwaarden) van de gewijzigde objecten;

- Het mutatiebericht moet voorzien worden van de ‘was’ situatie, deze dient overeen te komen met de meest actuele gegevens in de productiedatabase van het SVB-BGT.

- Als alle gegevens compleet zijn moet het mutatiebericht samengesteld worden en verpakt in het juiste Stuf/GML formaat.

- Het bericht wordt aangeleverd aan het SVB-BGT, de bronhouder krijgt een ontvangstbevestiging met het unieke mutatiebericht-ID. Als er op hetzelfde gebied andere mutatieberichten in bewerking zijn wordt het bericht afgekeurd. Als er een vooraankondiging gedaan is op hetzelfde gebied ontvangen de aanleverende bronhouder en de bronhouder die de aankondiging heeft gedaan een waarschuwing en het verzoek contact op te nemen. Het bericht wordt na bevestiging door de bronhouder wel in bewerking genomen.

Optie 2: Het business proces model voor optie 2 is als volgt:


Kenmerk ITP11378


Figuur 4, business proces model optie 2 mutatie verwerken tot mutatiebericht De activiteit ‘actualiseren van de betreffende objecten’ is vervallen omdat direct op de actuele gegevens gewerkt wordt. Optie 3 Het business proces model voor optie 3 is als volgt:

Figuur 5, business proces model optie 3 mutatie verwerken tot mutatiebericht Omdat rechtstreeks in de omgeving van het SVB-BGT gewerkt wordt zal de vergrendeling automatisch gebeuren en zal eveneens online een mutatiebericht worden samengesteld dat vervolgens verwerkt wordt zoals de berichten bij opties 1 en 2. De opties 2 en 3 zullen naar verwachting pas in een later stadium gerealiseerd worden als voldoende daar behoefte aan is (een business case voor is). De optie 3 is een eenvoudige voorziening voor kleinere aanpassingen.


Kenmerk ITP11378


3.1.2 Valideren en completeren van het mutatieberic ht Het business proces model voor deze activiteit ziet er als volgt uit:

Figuur 6, business proces model voor het completeren van mutatieberichten Als een mutatiebericht is binnengekomen bij het SVB-BGT wordt een validatie gedaan. In het volgende hoofdstuk wordt dit verder beschreven. Een afgekeurd validatiebericht krijgt de status afgekeurd met een beschrijving van de reden van afkeuring. Een e-mail statusbericht wordt verstuurd naar de afzender. Een goedgekeurd bericht wordt op 2 manieren verwerkt:

- Als het een initiële vulling betreft wordt het bericht dan zijn de validaties op de aansluiting


Kenmerk ITP11378


van opdelende objecten anders. Bij de assemblage krijgt de operator een lijst van gaten die ontstaan na het assembleren van het complete mutatiebericht, dan mogen er gaten ontstaan.

- Als het een regulier mutatiebericht betreft wordt een strengere validatie gedaan op het ontstaan van gaten, deze zijn dan niet meer toegestaan. Een speciaal aandachtspunt hierbij is de assemblage van objecten aan de buitengrens van Nederland. Hiertoe zal een buitenpolygoon van Nederland worden gedefinieerd. De grenzen van objecten die onderdeel uitmaken van de buitenpolygoon hebben andere validatieregels dan de binnengrenzen van opdelende objecten.

3.1.3 Assembleren Het assembleren is onderdeel van ‘valideren en completeren’. Het business proces model voor assembleren is weergegeven in bijgaande figuur. Het assembleren kent de volgende stappen:

- Het bepalen van de bronhouders van te muteren objecten om van het mutatiebericht een compleet mutatiebericht te maken. Een compleet mutatiebericht bevat een ongewijzigde buitenpolygoon.

- Voor objecten die niet door het SVB-BGT gewijzigd mogen worden wordt contact opgenomen met de bronhouders.

- De te muteren objecten worden eerst zoveel mogelijk automatisch geassembleerd.

- Als het mutatiebericht nog niet compleet is dan wordt een handmatige assemblage gedaan tot het object compleet is.

- Complete IMGeo mutatieberichten worden gefilterd om een IMBGT visualisatie te kunnen doen.

Figuur 7, business proces model voor het assembleren


Kenmerk ITP11378


3.1.4 Filteren IMGeo tot IMBGT Het filteren is onderdeel van ‘valideren en completeren’. Gegevens die als IMGeo worden aangeleverd kunnen gefilterd worden weergegeven op IMBGT niveau. Bij de accordering wordt het IMGeo en het IMBGT kaartbeeld getoond. Het business proces model voor filteren is als volgt:

Figuur 8, business proces model voor het filteren.

3.1.5 Accorderen mutatiebericht Het business proces model voor accorderen is als volgt:

Figuur 9, business proces model voor het accorderen. Gevalideerde complete mutatieberichten moeten nog geaccordeerd worden. De bronhouders moeten een akkoord geven op de verwerking van het mutatiebericht tot een nieuwe IMBGT en IMGeo.

3.1.6 Doorleveren aan de landelijke voorziening Een geaccordeerd mutatiebericht wordt doorgeleverd aan de landelijke voorziening. Na het accepteren en verwerken door de landelijke voorziening ontvangt het SVB-BGT een ontvangstbevestiging met de datum/tijd van verwerking in de landelijke voorziening en daarmee de starttijd van de objecten als basisregistratie. De datum/tijd wordt in de productiedatabase opgenomen, hierop wordt geen validatie gedaan. De bronhouder is niet verplicht de datum/tijd van de LV BGT op te nemen in de mutatieberichten.

3.2 Verwerking van terugmeldingen

Het business proces model voor de verwerking van terugmeldingen is als volgt:


Kenmerk ITP11378


Figuur 10, business proces model verwerken terugmeldingen


Kenmerk ITP11378


Het SVB-BGT voorziet in een eerste afhandeling van de terugmeldingen. De terugmeldingen worden in 3 stappen beoordeeld voordat ze doorgezet worden naar de betreffende bronhouders:

1) Is het een geldige en complete terugmelding, de minimale inhoud van een terugmelding moet nog bepaald worden.

2) Is er reeds een terugmelding betreffende hetzelfde object in behandeling? 3) Is het een terugmelding betreffende een object dat in een gebied ligt waar projecten in

uitvoering zijn, de terugmelding wordt wel doorgezet maar met de mededeling dat deze in een projectgebied ligt.

De overgebleven mutatiemeldingen worden per e-mail doorgestuurd naar de bronhouders, of de partijen waardoor de bronhouders ontzorgd zijn. Afgehandelde terugmeldingen en statuswijzigingen in de terugmeldingen worden doorgegeven aan de landelijke voorziening.

3.3 Coördinatie van de transitie

De coördinatie van de transitie bevat geen proces diagram. De uitwerking hiervan is opgenomen in hoofdstuk 4.


Kenmerk ITP11378


4 Applicatie landschap In dit hoofdstuk is het applicatie landschap uitgewerkt.

4.1 Legenda

Figuur 11, legenda van de meest gebruikte archimate elementen in dit document

4.2 Analyse van de business laag

4.2.1 Organisatie In de organisatie kunnen de volgende rollen kunnen onderscheiden worden:

• bronhouder - dit is de unieke ‘eigenaar’ van een BGT object, hieronder vallen

o Gemeentes o Waterschappen o Ministerie van Defensie o Ministerie van Economische Zaken, Landbouw en Innovatie


Kenmerk ITP11378


• stroken bronhouder - dit is een speciaal soort bronhouder die ‘stroken’ beheert (langgerekte objecten), hieronder vallen

o Rijkswaterstaat o Provincies o Prorail o Waterschappen (zijn soms ook strokenhouder).

Daarnaast kan er een onderscheid gemaakt worden in

• zelf-assemblerende bronhouders (ZAB) • gefaciliteerde bronhouder (GB) • zelfregistrerende bronhouder (ZRB)

en is het mogelijk dat bronhouders samenwerken zodat deze als één bronhouder naar buiten treden, de zogenaamde samenwerkende bronhouder (SB). Vooruitlopend op de producten en services kan het verschil tussen de verschillende type-bronhouders als volgt geschematiseerd worden (bron: tabel 6.2 in Rapportage pilot en beheer): type bronhouder loket LV assemblage ontzorging

SB ja nee nee

ZAB ja nee nee

ZRB ja ja nee

GB ja ja ja

De taken van de SVB-BGT zullen zoveel mogelijk geautomatiseerd worden. In sommige gevallen is handmatige (na-)bewerking in het assemblage proces noodzakelijk. Hiervoor is de rol assemblage specialist opgenomen. Deze rol kan ingevuld worden door een GIS medewerker bij een zelf assemblerende bronhouder, of door een SVB (aangestelde) medewerker in het geval van een gefaciliteerde of zelfregistrerende bronhouder.


Kenmerk ITP11378


Figuur 12, organisatie

4.2.2 Business services en producten Er wordt gesproken over twee producten, facility en community waaronder de volgende diensten (=services) vallen

• community product o mutatie service - het aanbieden van mutaties via een berichten interface o assemblage service - ondersteunende service voor het (geautomatiseerd)

afstemmen en assembleren van objecten van betrokken bronhouders. o terugmeld service o transitie ondersteuning o BGT bevraging

• facility product o productie ondersteuning


Kenmerk ITP11378


o beheer ondersteuning

De ICT voorzieningen voor de facility producten vallen buiten scope van deze applicatie architectuur. Dit betreft financiële software en software voor administratieve en projectondersteuning.

Figuur 13, producten en diensten De verschillende services worden hieronder op hoofdlijnen uitgewerkt.

4.2.2.1 Mutatie service Dit is de belangrijkste dienst van het SVB-BGT en wordt aan alle bronhouders aangeboden (community product). In theorie is het (wettelijk) mogelijk dat bronhouders mutaties ook direct aan de LV aanbieden, maar er wordt hier vanuit gegaan dat dit in de praktijk niet zal gebeuren. De LV fungeert alleen als proxy en stuurt de mutatieberichten door naar het SVB-BGT voor de assemblage.


Kenmerk ITP11378


In de meeste gevallen zullen de volgende proces-stappen afgewerkt

1. Mutatie signaleren - binnen dit proces vallen meerdere processen en activiteiten die leiden tot het signaleren van een (toekomstige) mutatie; bijvoorbeeld aanvraag van bouwvergunning, het periodiek inmeten op basis van orthofoto’s, etc. Per bronhouder zal dit kunnen verschillen. Mutatiedetectie kan voor de bronhouder ontzorgd worden door het SVB.

2. Inmeten & productie - Na signalering zal de meest actuele informatie opnieuw moeten worden ingewonnen (attributen en/of plaatsbepalingspunten en geometrieën). Dit proces zal wederom per bronhouder verschillen en kan door het SVB-BGT ontzorgd worden.

3. Samenstellen mutatiebericht - Dit betreft het verwerken van de ingewonnen gegevens tot een mutatiebericht dat kan worden aangeboden aan de SVB. Het mutatiebericht moet zowel de complete originele BGT objecten omvatten als de nieuwe BGT objecten. Het originele BGT object moet volledig (inclusief alle attributen) conform het meest actuele BGT object in de SVB database zijn. Optioneel kan een voornemen van mutatie vooraf aangemeld worden bij het SVB. Hiermee kan worden voorkomen dat tijdens het voorbereiden van een mutatie de actualiteit in de SVB BGT wijzigt wat het proces van bij de bronhouder kan frustreren. In principe is het samenstellen van het mutatiebericht de verantwoordelijkheid van de bronhouder. In de toekomst moet het ook mogelijk zijn om met software direct in te prikken op een dienst waarbij de SVB het samenstellen van het mutatiebericht verzorgt. Hiervoor zijn verschillende mogelijkheden te bedenken:

a. in het portaal kunnen direct BGT objecten gewijzigd worden, waarna deze met een druk op de knop als mutatiebericht doorgestuurd worden en het ‘normale’ mutatie proces ingaan

b. in het portaal kan een mutatiegebied aangegeven worden. Alle objecten in dit gebied worden vergrendeld en er wordt een kopie klaargezet in een beschermd deel van de mutatiedatabase. Externe software kan, b.v. d.m.v. een databasekoppeling, vervolgens deze objecten muteren, waarna in het portal wederom de mutatie als bericht het ‘normale’ proces wordt ingeschoten.


Kenmerk ITP11378


c. in het portaal kan een mutatiegebied aangegeven worden. Alle objecten in dit gebied worden vergrendeld en de objecten kunnen vervolgens in een bepaald formaat (b.v. IMGEO berichtenstandaard) gedownload en geopend worden in een extern systeem waar deze bewerkt kunnen worden. Het gewijzigde bestand kan dan vervolgens weer geupdate worden.

Registreer mutatie - Dit proces omvat alle stappen na ontvangst van het mutatiebericht door de SVB voorafgaand aan assemblage, te weten:

a) administratieve vastlegging van de mutatie en teruggave van een mutatie-id voor verdere (automatische) correspondentie, en daarmee opname van de mutatie in het mutatie-werkproces bij de SVG

b) technische validatie van de mutatie zelf, o.a. i. berichtenstandaard (IMGEO) ii. 2d/3d iii. valide domeinwaardes iv. valide en complete attributen v. valide geometrieën vi. ‘was’ consistent met ‘wordt’ (puzzelstuk)

c) controle van vergrendeling d) inhoudelijke validatie van de mutatie e) actualiteit van ‘was’

Assembleren mutatie - assemblage houdt in dat de mutatie verwerkt wordt tot ‘complete’ mutatie. Een ‘complete’ mutatie kan -na goedkeuring van alle betrokken bronhouders- geleverd worden aan de LV. Assemblage en het concept van een ‘complete’ mutatie worden hieronder verder uitgewerkt.

4.2.2.2 Compleet mutatiebericht Een compleet mutatiebericht (complete mutatie) moet aan de volgende voorwaarden voldoen (bovenop de validatie eisen)

• de omhullende geometrie van de ‘was’ situatie moet exact overeenkomen met de omhullende geometrie van de ‘wordt’ situatie, inclusief plaatsbepalingspunten.

binnen deze omhullende geometrie mogen geen gaten vallen.


Kenmerk ITP11378


Figuur 14, Voorbeeld van complete mutatie bij toevoegen van erf en pand, alle objecten binnen het gestippelde mutatiegebied zijn betrokken: boven de ‘was’ situatie, onder de ‘wordt’ situatie. De begroeide berm moet ook worden meegenomen, ondanks dat de geometrie verder niet gewijzigd is.

4.2.2.3 Assemblage Voor de assemblage kunnen bronhouders mutatieberichten aanleveren. Hiertoe wordt een webservice beschikbaar gesteld, de gebruiker ontvangt een bevestiging van de ontvangst en het resultaat van de eerste validatie, alsmede een hyperlink om de status van het bericht te volgen. Tevens wordt er een uploadportaal beschikbaar gesteld voor bronhouders die niet over de mogelijkheid beschikken geautomatiseerd mutatieberichten aan te leveren. Voor een beschrijving van de assemblage wordt verwezen naar hoofdstuk 3.


Kenmerk ITP11378


4.2.2.4 Terugmeld service Terugmeldingen van een afnemer worden ontvangen door de Landelijke Voorziening via een digimelding of een daarvoor nog in te richten terugmeldingen portaal. Deze service valt buiten de scope van het SVB-BGT. De LV zal de terugmelding doorzetten naar de terugmeld service van de SVB-BGT, waarna deze binnen de SVB-BGT wordt opgenomen in een terugmeld proces. Hierin kunnen de volgende stappen ondernomen worden

1. In onderzoek nemen - in deze stap wordt de terugmelding onderzocht op a. technische validiteit b. duplicatie (is er al een terugmelding of mutatie actief) c. (optioneel) projectgebied (loopt er voor dit object een project waardoor verwacht

kan worden dat het object binnenkort opnieuw wordt ingemeten) 2. Verwerken (muteren) - indien de terugmelding in behandeling kan worden genomen

worden a. de betrokken bronhouders vastgesteld en b. wordt het mutatie proces getriggerd

3. Rapporteren aan melder - het resultaat van de terugmelding wordt geautomatiseerd gerapporteerd aan de melder. Het is onduidelijk of dit via de LV moet lopen of dat er een email gestuurd moet worden.

Figuur 15, Uitwerking van de terugmeldservice.


Kenmerk ITP11378


4.2.2.5 BGT bevraging Door middel van de BGT bevraging kunnen bronhouders de huidige inhoud van BGT objecten bij het SVB bevragen. Het doel hiervan is de bronhouders, indien nodig, de mogelijkheid te geven hun eigen BGT objecten te actualiseren wanneer deze, bijvoorbeeld tijdens een assemblage proces, door een bronhouder van aangrenzende objecten is gewijzigd. Het zal mogelijk zijn de bevraging te kunnen filteren. De exacte filter mogelijkheden moeten nader worden uitgewerkt, maar voor de hand liggende filters zijn bronhouder en mutatie datum. Het uitlever formaat zal volgens het gebruikelijke IMGeo model plaatsvinden, echter de exacte interface en de definitie van de filters daarin moet nog bepaald worden. Deze service is alleen bedoeld voor het bevragen ten bate van actualisatie van de eigen BGT brongegevens, en is niet bedoeld als algemene dienst voor het bevragen van de BGT, hiervoor dienen de diensten van de LV gebruikt te worden (PDOK).

4.3 Analyse van de applicatielaag

Om de verschillende producten en diensten te realiseren kunnen de volgende applicaties onderscheiden worden. Het onderscheid is gebaseerd op het groeperen van vergelijkbare functionaliteit die op zichzelf staand kan opereren en vervangbaar is. De afzonderlijke applicaties zijn hiermee dus niet onlosmakelijk met elkaar geïntegreerd.


Kenmerk ITP11378


Figuur 16, Overzicht van applicaties en applicatie services

Er zijn slechts twee applicaties voorzien die extern (voor de bronhouders) zichtbaar zijn, namelijk de services endpoint applicatie en het SVB-BGT Portaal, daarnaast wordt er voorzien in een single-sign oplossing om het inloggen te vergemakkelijken.

4.3.1 Services endpoint Deze applicatie implementeert de verschillende berichtenstandaarden en operaties voor het:

• verwerken van terugmeldingen • het leveren van geassembleerde, goedgekeurde mutaties aan de LV


Kenmerk ITP11378


• verwerken van mutatieberichten • bevragen van de BGT.

Na ontvangst van een bericht zullen eerst enkele basale technische controles worden uitgevoerd, waarna het bericht wordt getransformeerd en opgeslagen in de mutatie database en waarbij de betrokken objecten worden vergrendeld.

4.3.2 SVB-BGT Portaal Het SVB-BGT Portaal groepeert verschillende functies, waarvan sommige essentieel zijn voor het mutatieverwerkingsproces en sommige ondersteunend of informatief.

4.3.2.1 CMS Het content management systeem kan als aparte applicatie ingezet worden, maar uit het oogpunt van beheer (o.a. gebruikersrechten etc.) en integratie met de overige functionaliteiten is het raadzaam dit te combineren in één portaal.

4.3.2.2 Beheer projectgebieden Met deze functie kunnen projectgebieden bekeken aangemaakt, bijgehouden of afgesloten worden. De projectgebieden worden getekend in een (PDOK) Top10, BGT of IMGEO achtergrond kaartlaag. Een gebruiker kan alle projectgebieden zien, zodat duidelijk wordt of er niet gelijktijdig in hetzelfde gebied aan de BGT inwinning gewerkt wordt. Daarnaast worden deze projectgebieden gebruikt bij de beoordeling van terugmeldingen.

4.3.2.3 Beheer transitiegebieden Deze functionaliteit wordt gebruikt voor administratieve ondersteuning van de transitie. In deze tool moet de status van de transitie kunnen worden bijgehouden door de bronhouders zelf en door SVB. Een statusoverzicht (op kaart) moet in de SVB website kunnen worden getoond. De tool moet informatie beheren van bronhouders, transitiegebieden en projectgebieden.

4.3.2.4 Visualisatie mutatie Mutaties moeten zichtbaar gemaakt kunnen worden in het systeem, gebruikmakende van de stijlen uit de handreiking visualisatie. Daarnaast moet er onderscheid gemaakt kunnen worden tussen de ‘was’ en de ‘wordt’, en moet kunnen worden aangegeven welke segmenten en plaatsbepalingspunten tot stand gekomen zijn in het originele mutatiebericht, in de automatische assemblage en in de handmatige assemblage. Ten slotte moeten problemen in de assemblage geïdentificeerd kunnen worden zodat duidelijk wordt welke acties nog vereist zijn om de mutatie ‘compleet’ te maken. Deze visualisatie component wordt gebruikt door de functies beheer mutatie, handmatige assemblage en goedkeuring assemblage.

4.3.2.5 Beheer mutatie Bronhouders moeten de mogelijkheid hebben om de status, afhandeling en details van openstaande en afgesloten mutaties te bekijken. Hiermee kan inzicht verkregen worden welke mutaties in welk stadium van de processing zitten en welke acties nog vereist zijn om de mutatie succesvol te verwerken. De bronhouder moet kunnen zien welke mutaties zijn goedgekeurd of met welke reden zijn afgekeurd. Ook kan mutatie(-bericht) historie opgevraagd worden. Bronhouders moeten tevens de mogelijkheid hebben een voornemen tot een mutatie te melden.


Kenmerk ITP11378


Hierbij wordt inzicht gegeven in de projectgebieden en andere voornemens tot mutaties en in behandeling zijnde mutaties.

4.3.2.6 Handmatige assemblage Bij complexe of onvolledige mutaties kan handmatige verwerking noodzakelijk zijn. Hierbij moeten dan handmatige IMGeo objecten worden aangepast, toegevoegd of verwijderd, net zolang tot een compleet mutatiebericht is verkregen. Om dit te bewerkstelligen zijn mogelijk complexe GIS operaties nodig. Op termijn zal het portaal dit ‘online’ ondersteunen en de mogelijkheid bieden het - voor de mutatie vergrendelde gedeelte - in GIS formaat te downloaden, waarna deze offline door een GIS medewerker bewerkt kan worden. Deze kan vervolgens de mutatie weer uploaden waarna de wijzigingen in het portaal verwerkt worden. Nadere specificaties hiervoor moeten nog opgesteld worden.

4.3.2.7 Goedkeuring mutatie Nadat een mutatie na (eventueel) assemblage ‘compleet’ is moet deze eerst door de betrokken bronhouders (i.e. alle bronhouders die eigenaar zijn van minimaal één object in de ‘was’ of ‘wordt’ situatie) goedgekeurd worden. Elke bronhouder moet in het portaal kunnen zien welke mutaties goedkeuring vereisen, en moet de mutatie kunnen visualiseren om hierover een beslissing te kunnen nemen. De bronhouder moet bij een afkeuring de mogelijkheid hebben om een reden op te geven. De bronhouder die de mutatie heeft geleverd krijgt in het portaal bericht over de goedkeuring of afkeuring (met reden).

4.3.2.8 Functioneel beheer De functioneel beheerder moet toegang hebben tot b.v. gebruikersbeheer, configuratie van bepaalde componenten (b.v. CMS) en het maken van rapportages.

4.3.3 Authenticatie en autorisatie Binnen de SVB moeten de rechten en rollen centraal beheerd kunnen worden. Hierbij geldt het principe van rol gebaseerde authenticatie: rechten worden niet direct aan personen toegekend, maar aan rollen. Welke rechten en rollen in eerste instantie onderscheiden worden moet nog nader worden uitgewerkt. Denk hierbij aan de business rollen (gefaciliteerde bronhouder, zelf-assemblerende bronhouder, etc.), maar bijvoorbeeld ook aan mandatering van personen of organisaties voor het goedkeuren van mutaties. Om met een enkele gebruikersnaam en wachtwoord eenmalig te kunnen inloggen op de verschillende systemen van het SVB is er voorzien in een single-sign-on service, maar dit kan eventueel in een later stadium gerealiseerd worden.

4.3.4 Validatie systeem Het validatie systeem is een op zichzelf staande applicatie module die de validatie van aangeleverde mutaties uitvoert. Binnen deze validatie kunnen verschillende functionaliteiten onderscheiden worden

• topologie validatie • actualiteit validatie

Een mutatie hoeft niet noodzakelijkerwijs afgekeurd te worden als een validatie faalt. Wanneer er bijvoorbeeld een overlap ontstaat in opdelende elementen zullen deze eerst geassembleerd moeten worden. Daarom is het ook belangrijk dat de verschillende validatie stappen nauwkeurig de


Kenmerk ITP11378


validatieproblemen vastleggen zodat latere proces-stappen hierop gebaseerd kunnen worden (b.v. in bovenstaand voorbeeld het uitvoeren van het assemblage proces) en problemen gevisualiseerd kunnen worden. Validatie zal dan ook op verschillende momenten in de mutatieverwerking worden uitgevoerd.

4.3.4.1 Topologie validatie De topologie validatie controleert de mutatie objecten op de voor de BGT en IMGEO relevante topologische regels (zie ImGeo 2.0 en ImBGT 1.0 gegevenscatalogus). Denk hierbij aan

• validatie van afzonderlijke geometrieën, b.v. zichzelf kruisende lijnen, aanwezigheid van gaten en eilanden, dubbele punten

• validatie van de ‘was’ versus de ‘wordt’, b.v. o zijn alle vormpunten gekoppeld aan plaatsbepalingspunten o zijn er geen objecten die wel aanwezig zijn in de ‘was’ en niet in de ‘wordt’ maar

die niet expliciet verwijderd worden • geeft de ‘wordt’ een volledige vlakvulling van opdelende elementen op maaiveldniveau • etc.

4.3.4.2 Actualiteit validatie Deze validatie controleert dat alle objecten in de ‘was’ situatie exact overeenkomen met de actuele waardes in de SVB-BGT database. Dit geldt niet voor de LV-publicatiedatum, aangezien dit een attribuut is dat door de LV zelf wordt aangemaakt en daarom niet altijd bekend zal zijn in de SVB-BGT database.

4.3.5 Automatische assemblage Om de hoeveelheid handmatige assemblage te beperken zal een mutatie eerst automatisch geassembleerd worden. Eenvoudige topologische problemen kunnen hierbij worden opgelost (het resultaat van de assemblage zal echter altijd nog handmatig moeten worden goedgekeurd). Er zijn verschillende algoritmes en implementatie denkbaar om dit te kunnen uitvoeren. Er gelden wel enkele randvoorwaarden

• alle vormpunten moeten gebaseerd zijn op plaatsbepalingspunten. Daardoor mag zo’n algoritme niet zelf punten aanmaken om de topologie te repareren.

• de implementatie moet automatisch, zonder handmatige tussenkomst in een processtap kunnen worden aangeroepen

• performance moet goed genoeg zijn om binnen redelijke termijn transitiegebieden te kunnen valideren.

Er wordt nog onderzocht welke algoritmes hiervoor in aanmerking komen.

4.3.6 Administratie De administratie component implementeert verschillende ondersteunende functionaliteiten voor het SVB-BGT mutatie proces. Hieronder vallen tenminste de BGT object vergrendeling, en accounting


Kenmerk ITP11378


4.3.6.1 BGT Vergrendeling Hieronder valt het vergrendelen (lock) of het registeren van een voornemen tot mutaties van IMGeo en/of IMBGT. Zoals eerder beschreven heeft dit tot doel om te voorkomen dat verschillende bronhouders op hetzelfde moment dezelfde objecten proberen bij te werken wat de integriteit van de database (bij gelijktijdige verwerking) of kosten efficiëntie (bij gelijktijdige inwinning) compromitteert.

4.3.6.2 Accounting Onder deze vrij algemene functionaliteit valt de noodzaak om vast te leggen wie wat op welk moment heeft uitgevoerd en wat daarvan het resultaat was. Deze informatie kan gebruikt worden voor verrekening van de door de SVB-BGT geleverde diensten aan de bronhouders en voor het traceren van wijzigingen in de BGT.

4.3.7 Rapportage component De rapportage component is verantwoordelijk voor het inzichtelijk presenteren van allerhande (interne of externe) informatie, zoals aantal verwerkte berichten, per tijdseenheid en per bronhouder, etc. De specifieke rapportages moeten redelijk eenvoudig configurabel zijn en exporteerbaar in een algemeen leesbaar formaat, b.v. PDF.

4.3.8 Terugmelding analyse Hieronder vallen alle functionaliteiten voor het analyseren en beoordelen van door de LV aangeleverde terugmeldingen. Hieronder vallen

• bepalen betrokken bronhouders • controle van vergrendeling • controle van projectgebied

Wanneer na alle controles de terugmelding relevant blijkt zal deze worden doorgestuurd (b.v. per email) naar de betrokken bronhouders. Het verwerken van de terugmelding tot een mutatie kan voor de bronhouder door het SVB-BGT ontzorgd worden, maar valt buiten de scope van deze applicatie architectuur.

4.3.9 BGT Repository De BGT Repository is een technische component die toegang tot de BGT database en mutatie database mogelijk maakt, en afdwingt. Al het gegevens/objecten verkeer van en naar de databases verloopt via deze component. In deze component implementeert

• bewaken van integriteit (afdwingen dat overige applicatie componenten geen ongeeigende operaties proberen uit te voeren)

• transactie afhandeling • auditing (eventueel) • logging (van errors, performance)

4.3.10 Enterprise service bus De enterprise service bus (ESB) is verantwoordelijk voor het controleren en uitvoeren van de berichten flow door het systeem, en het op transparante en flexibele manier koppelen van services.


Kenmerk ITP11378


Ook integreert de ESB de toegang en beheer van de berichten queues. Idealiter is de workflow en de koppeling van services realtime door een technisch of functioneel beheerder te visualiseren en wijzigen, maar dit is geen vereiste aangezien de berichtenflow, wanneer deze getest is en goed functioneert, waarschijnlijk zeer zelden gewijzigd hoeft te worden. De ESB en de opslag van de berichten moet zeer robuust zijn uitgevoerd zodat bij uitval van het hele systeem of een deelcomponent in geen geval (lopende) mutaties verloren mogen gaan of de integriteit van de SVB-BGT database in gevaar komt.


Kenmerk ITP11378


5 Niet functionele eisen

5.1 Beveiliging

De gebruikers moeten geauthentiseerd en geautoriseerd worden. Hierbij moeten minimaal de volgende profielen ondersteund worden:

- landelijke bronhouders - bronhouders - beheerders - administrator

Voor de interface met de landelijke voorziening zal een door de landelijke voorziening ondersteund beveiliging certificaat (PKIoverheid) moeten worden gehanteerd. Berichtenuitwisseling zal op basis van de Digikoppeling verlopen. De interface voor het berichtenverkeer met bronhouders moet eveneens versleuteld worden (op basis van PKIoverheid) en op basis van de Digikoppeling standaarden.

5.2 Backup

De gegevens dienen op minimaal 2 fysieke locaties opgeslagen te worden. De mutatieberichten die verwerkt worden moeten ook minimaal op 2 locaties opgeslagen zijn (bijvoorbeeld ook op de failover omgeving) en dagelijks dient een incremental backup gedaan te worden met wekelijks een full backup. De dataopslag dient op een RAID1 omgeving te gebeuren.

5.3 Beschikbaarheid

De mutatieberichten verwerking service kent de volgende minimale beschikbaarheid:

Beschikbaarheid Kantooruren (7 – 18u) Avonden (18u – 23u) Nacht (23u – 7u)

Transitie Fase tot 2016

95% 90% 80%

Consolidatie fase tot 2019

99% 95% 90%

Beheer fase na 2019

99% 99% 95%

5.4 Schaalbaarheid

De oplossing dient de berichtenflow van mutatieberichten aan te kunnen en dient de opslag van een landelijke IMGeo aan te kunnen met op termijn ondersteuning van 3D en bijbehorende data volumes. Rekenintensieve processen moeten zodanig geïmplementeerd worden dat deze opgeschaald kunnen worden, er dient echter rekening gehouden te worden met grote hoeveelheden gegevens. Het aantal mutaties en de complexiteit van de mutatieberichtenverwerkingen is nog onbekend.


Kenmerk ITP11378


6 Roadmap

6.1 Planning van de ICT voorzieningen community

Dit betreft een concept roadmap, deze kan nog veranderen.

Onderdeel Realisatie in 2012 Realisatie in 2013 Realisatie na 2013

Berichten interface – SVB webservice voor het geautomatiseerd aanleveren van mutatieberichten (4.2.2.3)

Volledig

Berichten interface - upload portaal (4.2.2.3)

Volledig

Berichten interface – Terugmeld service – functionaliteit waarmee terugmeldingen afgehandeld worden door het SVB-BGT (4.3.8)

- Planning nader te bepalen in overleg met de landelijke voorziening. Afhankelijk van de oplevering van de terugmeld-voorziening

Proces sturing – ESB, controle en uitvoeren van de berichten flow (4.3.9)

De basis werkt volledig Uitbreiding van regels en proces sturing

Validatie(4.3.4) Basis validatie voor assemblage. Topologie- en actualiteitsvalidatie. Validatie afgestemd op fase 1 regels: niet afkeuren op onvolledigheid

Aanpassingen op basis van voortschrijdend inzicht.

Aanpassing voor volledige BGT validatie gereed 1/1/2016

Automatisch assembleren (4.3.5) Beperkt geautomatiseerde assemblage.

Regels groeien mee met voortschrijdend inzicht in mogelijkheden automatische assemblage.

Handmatig assembleren (4.3.2.6) Voorziening om handmatig aanpassingen te maken t.b.v. de assemblage.

Update software. Jaarlijkse update

Handmatig assembleren (4.3.2.6) - online edit mogelijkheden

- Beperkt tot eenvoudige bewerkingen.

Nader te bepalen

Handmatig assembleren (4.3.2.6) - muteren direct op SVB-BGT database mbv ‘eigen’ software

- Nader te bepalen

Portaal – CMS (4.3.2.1) CMS op basis van standaard software


Kenmerk ITP11378


Onderdeel Realisatie in 2012 Realisatie in 2013 Realisatie na 2013

Registreren, aanmelden & beheer authenticatie/autorisatie(4.3.3)

Volledig

Beheer mutatieberichten, inzien status van mutatieberichten (4.3.2.5)

Ja, read-only Uitbreiding? Afhankelijk van functionele wensen

Portaal – vooraankondiging van mutaties aanmelden (4.3.2.5)

- Ja

Portaal – visualiseren mutaties (4.3.2.4) Beperkt, op eenvoudige wijze

Volledig

Portaal – beheer transitie gebieden (4.3.2.3)

Volledig (1 / 6 / 12) Mogelijkheid statusinformatie te delen met anderen (e-overheid)

Portaal – Accordering (4.3.2.7) Goedkeuring op basis van kaartbeelden (was-wordt) en beperkte rapportage

Uitbreiding voorzieningen

Functioneel beheer (4.3.2.8) Beperkt, gebruikers beheer

Volledig: rapportages, CMS beheer

Projecten registratie(4.3.2.2) Handmatig inbrengen in projecten database

On-line invoer mogelijkheid

Administratie (4.3.6) Alleen het opslaan en bewaren (registreren) van de afhandeling van mutatieberichten en terugmeldingen.

Functionaliteit voor rapportages, overzichten en accounting.


Kenmerk ITP11378


Bijlage 1, begrippenlijst Om een eenduidig gebruik van de kernbegrippen te verkrijgen zijn in onderstaande tabel de definities van die begrippen opgenomen. Begrip Omschrijving

Mutatiemelding Een mutatiemelding is een beschrijving van een verandering die heeft plaats gevonden

aan een object in de werkelijkheid. Een mutatiemelding moet leiden tot aanpassing van

één of meerdere objecten in de registratie.

Een mutatiemelding kan komen van een beheerder van de openbare ruimte. Vanuit de

BAG kunnen ook mutatiemeldingen worden gedaan. (Bijvoorbeeld melding: 'bouw

gereed').

Mutatiebericht Een Stuf GML bericht (GeoStUF) waarmee een mutatie in IMGeo doorgegeven wordt

aan het SVB en de LV.

Compleet mutatiebericht Een compleet mutatiebericht is een bericht van een mutatie in IMGeo/BGT wat voldoet

aan IMGeo, de minimale BGT gegevens bevat én waarbij de buitenste polygoon

(inclusief bijbehorende plaatsbepaldingspunten) van de aangeleverde objecten

ongewijzigd is ten opzichte van de actuele polygoon in de productie database van het

SVB. Een compleet mutatiebericht kan zonder verdere assemblage verwerkt worden in

de mutatiedatabase van het SVB BGT.

Terugmelding Een melding van een gebruiker over een fout in IMGeo/BGT

Aggregatie Het samenvoegen van IMGeo objecten tot BGT objecten waarbij alleen de BGT

kenmerken worden meegenomen. De samenvoeging kan al dan niet fysiek worden

uitgevoerd (filteren) met het samenvoegen van objecten (polygonen).

Assemblage Het afstemmen en doorvoeren van wijzigingen in IMGeo/BGT zodanig dat de mutatie in

objecten van de aansluitende objecten in lijn zijn met de objecten die gewijzigd zijn en

er weer een consistente landelijke database ontstaat. De aansluitende objecten kunnen

zowel ‘eigen’ objecten als objecten van andere bronhouders betreffen.

Transitie De opbouw van IMGeo/BGT objecten uit een diversiteit van bronnen waaronder de

GBKN. Bij de opbouw worden de bronhouders van objecten eenduidig bepaald.

Gefaciliteerde bronhouder (GB) Alle taken op het gebied van de BGT zijn opgedragen aan het SVB-BGT (Facility). De

processen mutatiesignalering, inwinning, verwerking, assemblage, afhandelen van

terugmeldingen worden uitgevoerd door het SVB-BGT op basis van IMBGT. De

bronhouder beschikt zelf over raadpleeg voorzieningen. De kosten worden door het

SVB-BGT doorberekend aan de bronhouder.

Zelf registrerende bronhouder (ZRB De processen mutatiesignalering, inwinning, verwerking, afhandelen van

terugmeldingen worden uitgevoerd door de bronhouder. Het betreft alleen de objecten

waarvoor de bronhouder verantwoordelijk is. Afhankelijk van de ambitie kan dit op

basis van IMGEO worden gedaan. De bronhouder beschikt zelf over voorzieningen om

deze taken uit te kunnen voeren. De assemblage wordt gedaan door het SVB-BGT

(Community). De bronhouder zorgt voor de afhandeling van berichten uit het

assemblage proces. De kosten voor de bijhouding worden door de bronhouder zelf

gedragen.

Zelf assemblerende bronhouder (ZAB) De processen mutatiesignalering, inwinning, verwerking, afhandelen van

terugmeldingen worden uitgevoerd door de bronhouder. De bronhouder zorgt ook

voor de assemblage van de eigen objecten met die van andere bronhouders binnen een

bepaald gebied. Afhankelijk van de ambitie kan dit op basis van IMGEO worden gedaan.

De zelf assemblerende bronhouder kan ook werkzaamheden uitvoeren voor andere

bronhouders in een bepaald gebied. Data wordt geleverd aan het SVB-BGT.

Samenwerkende bronhouders (SB) Deze bronhouder werkt voor een aantal onderdelen uit het bijhoudingsproces, samen

met andere bronhouders (ZAB of ZRB) binnen een bepaald gebied. De mate van

ontzorging wordt onderling geregeld. Verrekening van kosten vindt onderling plaats.

Binnen dit bronhouderprofiel zijn meerdere varianten mogelijk. Eén of meerdere

producten/diensten kunnen ook van het SVB-BGT worden afgenomen.


Kenmerk ITP11378


AAN register Topografisch referentie register Agrarisch Areaal Nederland, een basisbestand voor de

BGT. Dit register wordt door Dienst Regelingen van het ministerie van EL&I

onderhouden en bevat de meeste agrarische terreinen van Nederland.

NUP Het NUP is een actieplan tussen rijksoverheid en decentrale overheden, waarin 19

punten rond ICT worden geregeld.

ESB Enterprise Service Bus, een architecturele softwareconstructie (pattern) waarmee de

communicatie tussen de afnemers van diensten (“service”) en aanbieders hiervan,

vereenvoudigd wordt (bron: wikipedia).

applicatie architectuur svb-bgt - webtradersv2.sparqcms.com/dir_upload/site/e9226f146a2797acf... ·...

Documents