Functioneel ontwerp Berichtenverkeer StUF-Geo IMGeo voor ...

1

Functioneel ontwerp

Berichtenverkeer StUF-Geo IMGeo

voor horizontaal en verticaal koppelvlak

versie

v1.0

status

definitief

datum

4 april 2013

Geonovum

2

Colofon

Auteurs: Arnoud de Boer

Beheer: Geonovum

BGT-programma Ministerie van Infrastructuur en Milieu

Portefeuille Ruimte

Directie Nationale Ruimtelijke Ordening

Beleid GEO informatie/BGT

Rijnstraat 8

Postbus 20951

2500 EZ Den Haag

Interne postcode 350

E-mail: [email protected]

3

Inhoudsopgave 1 Inleiding 5

1.1 Inleiding 5 1.1.1 Horizontaal en verticaal berichtenverkeer 5 1.1.2 Doel 6

1.2 Leeswijzer 6 2 Uitgangspunten 7

2.1 Initiële levering en mutaties 7 2.2 Verwerking per transactie 7 2.3 Controle tegen richtlijnen IMBGT/IMGeo 8 2.4 Controle tegen versie in registratie 8 2.5 Bevestiging van ontvangst 8 2.6 Volgorde van verwerking in verticale keten 9 2.7 Logistieke en functionele identificaties 9 2.8 Geen berichtverkeer bronhouders onderling 9

3 Scenario’s horizontaal 10 3.1 Actoren 10

3.1.1 Geo 10 3.1.2 BOR 10

3.2 Mutatie 10 3.3 Exploratieverzoek 13

4 Scenario’s verticaal 15 4.1 Actoren 15

4.1.1 Bronhouder 15 4.1.2 Rakende bronhouder 15 4.1.3 Samenwerkingsverband van Bronhouders BGT (SVB-BGT) 15 4.1.4 Landelijke Voorziening BGT (LV-BGT) 15 4.1.5 Afnemer 15

4.2 Initiële levering 17 4.2.1 Aanleveren 17 4.2.2 Assembleren en goedkeuren 19 4.2.3 Registreren 22

4.3 Mutatie 24 4.3.1 optioneel: Vooraankondiging 24 4.3.2 Aanleveren 27 4.3.3 conditioneel: Goedkeuren 29 4.3.4 Registreren 30

4

5 Berichten 31 5.1 Berichtsoorten 31

5.1.1 Mutatiebericht(mtbDi01) 31 5.1.2 Mutatierespons (mtbDu01) 31 5.1.3 Mutatieverzoek(mtvDi01) 31 5.1.4 weigerbericht (mtvWeigerDu01) 31 5.1.5 mutatieOproep (mtoDi01) 31 5.1.6 mutatieOproepRespons (mtoDi01) 31 5.1.7 Exploratieverzoek (expDi01) 31 5.1.8 Exploratierespons (expDu01) 31 5.1.9 Vooraankondigingsverzoek (vavDi01) 31 5.1.10 VooraankondigingsRepons (vavDu01) 31 5.1.11 Ophaalverzoek (opvDi01) 32 5.1.12 Bevestiging van ontvangst (Bv03) 32

5.2 Gebruik 32 5.3 Berichteninhoud 33 5.4 StUF-Stuurgegevens 34 5.5 Entiteittypen 35

5.5.1 Mutatiebericht (MTB) 35 5.5.2 Mutatieverzoek (MTV) 35 5.5.3 MutatieOproep (MTO) 36 5.5.4 Weigerbericht (WGB) 36 5.5.5 Exploratieverzoek (EXP) 37 5.5.6 Vooraankondiging (VAV) 37 5.5.7 Ophaalverzoek (OPV) 38

5.6 Kennisgevingen 38 5.7 Extra elementen en domeinwaarden 39

5.7.1 <beheerder> 39 5.7.2 <documentverwijzing> 40 5.7.3 <geometrie> 40 5.7.4 <idExploratieverzoek> 40 5.7.5 <idMutatiebericht> 40 5.7.6 <idMutatieverzoek> 40 5.7.7 <idVooraankondiging> 40 5.7.8 <laatsteVerwerkingsActie> 40 5.7.9 <lv-publicatiedatum> 40 5.7.10 <mutatieVerzoek> 40 5.7.11 <muterendeBronhouder> 40 5.7.12 <resultaat> 40 5.7.13 <sleutelVerzendend> en <sleutelOntvangend> voor <object> 40 5.7.14 <statusVerwerkingsActie> 40 5.7.15 <toelichting> 41 5.7.16 <verslagVerwerkingURL> 41

Bijlage 1 Overzicht uitgangspunten 42

Bijlage 2 Extra objecttypen: <Leiding> en <Leidingelement> 46

Bijlage 3 Procesplaten SVB Fout! Bladwijzer niet gedefinieerd.

5

Hoofdstuk 1

Inleiding

Dit hoofdstuk geeft een inleiding op het horizontale en verticale berichtenverkeer.

1.1 Inleiding

1.1.1 Horizontaal en verticaal berichtenverkeer

Dit document bevat de functionele uitwerking van het berichtenverkeer rond de uitwisseling van

BGT/IMGeo-gegevens in de horizontale en verticale keten.

Het horizontale berichtenverkeer bestaat uit de communicatie voor uitwisseling van IMGeo-gegevens

tussen Geo-applicatie en BOR1-applicatie binnen een Bronhouder.

Het verticale berichtenverkeer bestaat uit de communicatie voor uitwisseling van IMGeo-gegevens van

Bronhouder via SVB en LV-BGT tot Afnemer.

In dit document wordt als uitgangspunt gehanteerd dat StUF-Geo IMGeo in de hele keten wordt toegepast.

Figuur 1: Berichtenverkeer in horizontale en verticale keten.

1 Beheer Openbare Ruimte, met onderliggende systemen voor o.a. Groen, Wegen en/of Water.

6

1.1.2 Doel

Doel van dit document is het komen tot één koppelvlakstandaard voor uitwisseling van BGT/IMGeo via

StUF-berichtenverkeer in horizontale en verticale keten. Een gedeelde standaard voor beide ketens heeft

als voordelen dat beide ketens goed op elkaar aansluiten, en lagere implementatiekosten in software voor

beheer en gebruik van BGT/ IMGeo-gegevens (Geo-BOR). Door de horizontale en verticale keten onder te

brengen in aparte sectormodellen binnen de StUF-Geo IMGeo berichtenstandaard wordt eenvoudig beheer

van de standaard voor beide ketens gegarandeerd.

1.2 Leeswijzer

In dit document worden de functionele specificaties beschreven van het horizontale en verticale

berichtenverkeer rond de uitwisseling van BGT/IMGeo-gegevens. Het is gebaseerd op het functioneel

ontwerp Geo-BOR opgesteld door softwareleveranciers, de eerste verkenning van het berichtenverkeer in

de verticale keten van zomer 2012, en gesprekken en werksessies met verschillende schakels in de

ketens. Op dit document is de technische implementatie van de StUF-Geo IMGeo berichtenschema’s

gebaseerd.

Het horizontale en verticale berichtenverkeer is beschreven aan de hand van scenario’s. Deze versie van

de berichtenstandaard beperkt zich tot de volgende scenario’s:

Mutatielevering en -verzoek in de horizontale keten

Exploratieverzoek in de horizontale keten

Initiële levering in de verticale keten

Mutaties in de verticale keten

In een volgende versie van de berichtenstandaard zullen de volgende scenario’s nader worden uitgewerkt:

Levering aan Afnemers in de verticale keten.

Terugmelding in de verticale keten

Synchronisatie in de verticale keten

De scenario’s zijn uitgewerkt in sequentiediagrammen. Een sequentiediagram geeft de interacties weer

tussen verschillende objecten die een bepaalde functionaliteit (of een deel ervan) implementeren. De

tijdsvolgorde staat centraal in het sequentiediagram.

Voor dit functioneel ontwerp zijn de volgende documenten geraadpleegd.

Tabel 1 Geraadpleegde documentatie

Document Versie Datum

Publiek testen GeoStUF Berichtenstandaard v1.0 juni 2012

Berichtenverkeer geoStUF IMGeo v0.2 juli 2012

StUF 03.01 In Gebruik 03.01

Handreiking GeoStUF IMGeo 1.0 juli 2012

Gegevenscatalogus BGT 1.1 december 2012

Gegevenscatalogus IMGeo 2.1 december 2012

Functioneel ontwerp koppeling Geo-BOR 1.0 december 2012

Processenhandboek BAG juli 2009

Memo Uitwerking werkprocessen &

gevraagde functionaliteiten en ICT-

componenten SVB

januari 2013

7

Hoofdstuk 2

Uitgangspunten

Dit hoofdstuk beschrijft een toelichting op de uitgangspunten welke met name gelden voor het

berichtenverkeer in de verticale keten. Voor een overzicht van alle uitgangspunten voor ook het

horizontale berichtenverkeer wordt verwezen naar bijlage 1.

2.1 Initiële levering en mutaties

In het verticale berichtenverkeer wordt onderscheid gemaakt tussen initiële levering en mutaties.

Bronhouders zullen in de periode tot 1 januari 2016 een eerste aanlevering, ofwel initiële levering, van een

objectgericht BGT/IMGeo-bestand doen aan de Centrale Registratie van de LV BGT. Na verwerking van de

initiële levering in de LV BGT zal Bronhouder voor dit gebied geen GBKN meer bijhouden en volledig

overgaan op BGT/IMGeo. Een wijziging op een reeds aangeleverd object wordt aangeleverd in een

mutatielevering aan de Centrale Registratie van de LV BGT.

Het onderscheid tussen een initiële levering en mutatie wordt in het bericht gemaakt door het soort

kennisgeving, resp. toevoegings- of wijzigingskennisgeving. In een initiële levering mogen alleen

toevoegingskennisgevingen voorkomen; in een mutatielevering mag een geldige combinatie van

toevoegings- en wijzigingskennisgevingen voorkomen2.

Bij wijziging van een object worden alle kenmerken van de actuele stand (WAS) en de gewijzigde stand

(WORDT) in de wijzigingskennisgeving meegeleverd. Een wijzigingskennisgeving bevat daarom exact 2

maal de gegevens van het object (WAS en WORDT), en een toevoegingskennisgeving exact een maal

(alleen WORDT).

2.2 Verwerking per transactie

Een mutatiebericht, mutatieverzoek en mutatie-oproep bevatten één of meer transacties. Een transactie

bestaat uit een aantal samenhangende wijzigingen op één of meer IMGeo-objecten, waarbij het van

belang is dat deze wijzigingen ofwel allemaal plaatsvinden, ofwel geen van alle. Een transactie wordt dus

altijd of geheel goedgekeurd of geheel afgekeurd. D.w.z. indien één mutatie in dit bericht niet juist wordt

bevonden, wordt het hele bericht afgekeurd.

In het algemeen geldt dus dat in de verticale keten een transactie in een mutatiebericht of mutatie-oproep

in zijn geheel goedgekeurd of afgekeurd wordt. Voor een mutatieverzoek in de horizontale keten geldt dit

niet. Er kunnen meerdere transacties in een mutatieverzoek hebben gezeten waarvan voor enkele de

mutatie niet wordt doorgevoerd. Indien één mutatie op een object in een mutatieverzoek niet wordt

overgenomen, wordt op de mutatie van dit object een weigerbericht teruggegeven. Per object wordt een

weigerbericht aangemaakt, waarin naast het <idMutatieverzoek>3 ook gegevens van het object worden

teruggestuurd. Er kunnen dus meerdere weigerberichten zijn op hetzelfde mutatieverzoek.

2 Let wel; er hoeft geen wijzigingskennisgeving in een mutatielevering voor te komen, bijvoorbeeld bij toevoeging van een

verzameling inrichtingselementen. Wel is een geldige combinatie van toevoegings- en wijzigingskennisgevingen in een

mutatielevering noodzakelijk voor objecten die meedoen in de topologische structuur, ofwel vlakobjecten op

maaiveldniveau. 3 Functionele identificatie van het mutatieverzoek

8

2.3 Controle tegen richtlijnen IMBGT/IMGeo

Een mutatie op een object dient te voldoen aan richtlijnen van IMBGT/IMGeo. De houder van de centrale

registratie van IMGeo-objecten (horizontaal: Geo, verticaal: LV-BGT4 ) zal een mutatie op één of meer

objecten controleren tegen deze richtlijnen, o.a. op de aanwezigheid van geldige domeinwaarden, valide

geometrie en of aan de eisen van de topologische structuur (geen gaten/overlap) wordt voldaan.

Indien een mutatie niet voldoet aan deze richtlijnen, zal deze te allen tijde worden afgekeurd en niet voor

verdere verwerking in de registratie worden aangeboden.

2.4 Controle tegen versie in registratie

Een mutatie op een object dient altijd te gebeuren op de laatst aangeleverde versie van een object. De

houder van de centrale registratie van IMGeo-objecten (horizontaal: Geo, verticaal: LV-BGT5 ) zal een

mutatie controleren tegen de actuele versie van een object in de registratie. Daarbij worden alle gegevens

(geometrie en attributen) van het object in het mutatiebericht gecontroleerd tegen de gegevens van het

object in de registratie van het ontvangende systeem (WAS=WAS-controle).

Uitzondering hierop is het element <lv-publicatiedatum> in een mutatiebericht in het verticale koppelvlak.

Een LV-publicatiedatum wordt uitgegeven door de LV en teruggegeven aan Bronhouder na succesvolle van

een mutatiebericht. Met een LV-publicatiedatum kan Bronhouder bewijzen dat aan de wettelijk taak om

BGT-gegevens in LV te registreren is voldaan; Bronhouder hoeft dit gegeven niet mee te leveren in een

mutatiebericht aangeleverd aan SVB en LV.

Deze controle wordt met name uitgevoerd omdat Bronhouder niet verplicht is tot het aanleveren van elke

versie van een object uit zijn registratie aan de Centrale Registratie van de LV-BGT. Een Bronhouder kan

mutaties opsparen en op een tijdstip overgaan tot aanleveren van de laatste versie van dit object aan de

LV-BGT. Omdat in de Centrale Registratie van de LV-BGT geen versies van objecten mogen worden

overgeslagen6, dient Bronhouder altijd de gegevens van de laatst aangeleverde versie (ORIGINEEL / WAS)

van het object samen met de gewijzigde versie aan te leveren aan SVB-BGT en LV-BGT. Zo kan de LV-BGT

controleren of Bronhouder de actuele stand aan het bewerken is.

Bij een vooraankondiging7 van Bronhouder zal SVB-BGT -na goedkeuring- ter informatie een levering van

de actuele stand op deze objecten uit de registratie van SVB-BGT aan Bronhouder doen. Bronhouder kan

hierop zelf zijn registratie bijwerken, en op de actuele stand muteren.

2.5 Bevestiging van ontvangst

Het bericht Bevestiging van ontvangst wordt altijd aan het zendende systeem verstuurd na ontvangst door

ontvangende systeem van een bericht of verzoek. Indien zendende systeem geen bevestiging van

ontvangst krijgt, is het de verantwoordelijk van zendende systeem om het bericht of verzoek nogmaals

aan te leveren.

Een bevestiging van ontvangst wordt teruggegeven omdat ontvangende systeem binnen een bepaalde

periode een verzoek afgehandeld dient te hebben. Het bericht bevat een cross-referentienummer (ofwel:

het referentienummer van het bericht/verzoek), en tijdstip van ontvangst. Dit tijdstip van ontvangst

4 Ook SVB-BGT. 5 Ook SVB-BGT. 6 Ofwel: er mogen geen gaten tussen objectversies ontstaan. 7 Een verzoek van Bronhouder tot een voorgenomen mutatie op een object, waarop SVB-BGT het object reserveert

(locked) voor bewerking door Bronhouder.

9

bepaalt de begintijd van de termijn voor de verwerking van het bericht of verzoek door ontvangende

systeem.

2.6 Volgorde van verwerking in verticale keten

SVB en LV verwerken de aanleveringen in volgorde van binnenkomst en op volgnummer per Bronhouder.

Aan Bronhouder wordt het resultaat op een succesvolle verwerking van een aanlevering in de LV pas terug

gemeld wanneer deze is geaccepteerd in de centrale registratie van de LV. In de stuurgegevens van een

bericht is een referentienummer opgenomen welke bestaat uit een unieke prefix ter identificatie van het

zendende systeem en een volgnummer voor het zendende systeem (zie 2.7).

Bij ophaalverzoek wordt de volgorde van verwerking bepaald o.b.v. referentienummer in ophaalverzoek,

en niet o.b.v. het referentienummer van het opgehaalde bestand. Aanleveraar is zelf verantwoordelijk dat

de op te halen bestanden in juiste volgorde worden aangeleverd / opgehaald via het ophaalverzoek.

N.B. In de horizontale keten hoeven berichten niet in volgorde van binnenkomst te worden verwerkt.

2.7 Logistieke en functionele identificaties

In de berichtenstandaard wordt onderscheidt gemaakt tussen logistieke en functionele identificaties.

De logistieke identificatie is het <StUF:referentienummer> en vormt samen met <StUF:zender> een

unieke combinatie. De functionele identificaties worden gebruikt gebruikt om de koppeling tussen

berichten (verzoeken en responses) te kunnen maken. De zender van het bericht bepaalt binnen de eisen

aan het element (max. 40 karakters) zelf de opmaak van het <StUF:referentienummer>, maar dient te

zorgen dat deze uniek is voor de ontvanger.

In het entiteittype van het verzoek of respons (bijv. mutatiebericht-verzoek of mutatiebericht-respons)

wordt de functionele identificatie opgenomen (bijv. <idMutatiebericht). De functionele identificatie bestaat

uit een vaste prefix van 5 karakters toegepast, gevolgd door een punt (.) en een uniek volgnummer (max.

72 karakters) van het zendende systeem. Het uitgangspunt hierbij is dat de prefix bestaat uit de

bronhoudercodes, zoals uitgedeeld en gepubliceerd door de LV. Hier wordt een eigen unieke code voor

SVB aan toegevoegd.

De logistieke en functionele identificaties dienen uniek per zendend systeem te worden gegenereerd. Het

is de verantwoordelijkheid van de zender om unieke identificaties uit te delen.

2.8 Geen berichtverkeer bronhouders onderling

Het uitgangspunt is dat bronhouders niet onderling communiceren via berichtenverkeer. Bronhouder en

Rakende bronhouder communiceren naar en via SVB. Ook berichten over objecten van naburige

bronhouders worden enkel via de SVB uitgewisseld.

10

Hoofdstuk 3

Scenario’s horizontaal

Dit hoofdstuk beschrijft de scenario’s in de horizontale keten.

3.1 Actoren

Het horizontale berichtenverkeer kent de volgende actoren.

3.1.1 Geo

De (beheerder van de) Geo-applicatie is bronhouder van IMGeo-objecten en als zodanig verantwoordelijk

voor het bijhouden van de geometrie en attributen van IMGeo-objecten en het leveren van IMGeo-

gegevens aan het SVB.

3.1.2 BOR

De (beheerder van de) BOR-applicatie is afnemer van IMGeo-gegevens en alszodanig verplicht tot het

doen van terugmeldingen op de BGT / IMGeo-gegevens.

3.2 Mutatie

Op het moment dat BOR een wijziging8 wil doorvoeren in de gegevens in de actuele stand van IMGeo-

objecten in de registratie van Geo, en van een IMGeo-object specifiek kan aangeven hoe deze gewijzigd

dient te worden, kan BOR een mutatieverzoek doen aan Geo. Dit mutatieverzoek bevat de actuele stand

van een IMGeo-object in de registratie van Geo (en dus ook BOR9) en de nieuwe situatie voor het IMGeo-

object zoals verondersteld door BOR dat dit object gewijzigd moet worden.

Geo bevestigt de ontvangst en beoordeelt dit mutatieverzoek, maar is niet verplicht tot het overnemen

van dit verzoek. Indien het mutatieverzoek volledig wordt overgenomen door Geo, werkt Geo de objecten

in registratie bij. Er volgt geen één-op-één terugkoppeling op de afhandeling van het mutatieverzoek aan

BOR. Indien een toevoeging, wijziging of verwijdering van een object niet wordt overgenomen door Geo10,

volgt per kennisgeving op een object een weigerbericht aan BOR. BOR zal hierop de mutatie in de eigen

8 Aanleiding van deze wijziging kan ook zijn het constateren van een onjuistheid in de actuele stand van

IMGeo-objecten in de registratie van Geo. 9 Uitgangpunt is dat de registratie van BOR en Geo gelijk zijn. 10 Dit is alleen indien verzoek onjuiste inhoud bevat. Bijv. BOR doet een mutatieverzoek niet conform

inwinningsregels, object wordt buiten niet geconstateerd, of object is van ander IMGeo-type.

11

registratie terugdraaien. Indien een rollback niet meer mogelijk is, dan zijn andere compensating

transactions niet vereist.

Indien Geo een mutatieverzoek van BOR heeft overgenomen of Geo op eigen initiatief de registratie heeft

bijgewerkt, volgt middels een mutatiebericht een uitlevering van de actuele stand van IMGeo-objecten

naar BOR. Dit mutatiebericht bevat de vorige stand van het IMGeo-object in de registratie van Geo (en

dus ook BOR) en de nieuwe actuele situatie voor het IMGeo-object zoals bijgewerkt in de registratie van

Geo, en ter bijwerking wordt aangeboden aan BOR. BOR bevestigt de ontvangst van het mutatiebericht en

is vervolgens verplicht tot het overnemen van de gegevens in de registratie van BOR.

13

3.3 Exploratieverzoek

Op het moment dat BOR voor een gebied constateert dat de actuele stand van de registratie van Geo niet

overeenkomt met de fysieke werkelijkheid, maar niet voor elke object specifiek kan/wil aangeven hoe de

gegevens van de objecten gewijzigd moeten worden, kan BOR een verzoek doen aan Geo tot het doen van

verkennend onderzoek in dit gebied.

Daartoe verstuurt BOR aan Geo een exploratieverzoek11, waarin het te verkennen gebied gemarkeerd

wordt middels een punt-, lijn- of vlakgeometrie met evt. aanvullende tekstuele opmerkingen. Geo zal na

ontvangstbevestiging van BOR het verzoek in behandeling nemen. Indien de registratie van Geo wijzigt

n.a.v. het exploratieverzoek, zal Geo één of meer mutatieberichten aan BOR sturen om de mutaties in

de registratie BOR te verwerken.

Na volledige verkenning en bijwerking van het gebied zal Geo het exploratieverzoek middels een

exploratieRespons12 afmelden bij BOR.

11 In FO Geo-BOR: redlinverzoek 12 in FO Geo-BOR: afhandelingsbericht

15

Hoofdstuk 4

Scenario’s verticaal

Dit hoofdstuk beschrijft de scenario’s in de verticale keten.

4.1 Actoren

Het verticale berichtenverkeer kent de volgende actoren

4.1.1 Bronhouder

Bronhouder is een bestuursorgaan van de Nederlandse Overheid en heeft als wettelijke taak het

gegevensbeheer. Onder het gegevensbeheer wordt verstaan het inwinnen van de authentieke BGT

objecten conform specificaties van de catalogus BGT voor die objecten waarvoor de bronhouder

verantwoordelijk is. Bronhouder of gemachtigde namens Bronhouder is alleen bevoegd tot het doen van

mutaties op eigen IMGeo-objecten.

4.1.2 Rakende bronhouder

Een Rakende bronhouder komt voor indien een verzoek tot voorgenomen mutatie of een mutatiebericht

van Bronhouder een in mutatie-zijnd object of een mutatie op een object van een andere bronhouder

bevat. In dat geval is het bericht van Bronhouder van invloed op de registratie van Rakende bronhouder

en wordt Rakende bronhouder hierin gekend.

4.1.3 Samenwerkingsverband van Bronhouders BGT (SVB-BGT)

Het SVB BGT is een vorm van samenwerking van bronhouders, mogelijk met regionale ondersteuning. Het

SVB BGT zorgt voor het bestandsbeheer van de BGT en beheert de productiedatabase waarop

bewerkingen worden uitgevoerd. Het SVB-BGT coördineert bij een mutatiebericht aan rakende

bronhouders het assemblageproces.

4.1.4 Landelijke Voorziening BGT (LV-BGT)

De LV-BGT is verantwoordelijk voor het overnemen van gegevens (na geaccepteerde controle) in de BGT

die worden aangeleverd door de bronhouders. De LV is verantwoordelijk voor de integriteit van gegevens

van de IMGeo-objecten in de registratie van LV, en voert daartoe de noodzakelijke controles uit.

De gegevens worden verwerkt in de Centrale Registratie.

De Distributie van LV BGT is verantwoordelijk voor het verstrekken van BGT-gegevens aan afnemers via

Distributie. Als distributeur van de BGT wordt Publieke Dienstverlening op de Kaart (PDOK) voorzien.

Daarnaast is de LV BGT verantwoordelijk voor het doorgeven van terugmeldingen die worden gedaan door

afnemers naar de bronhouders.

4.1.5 Afnemer

Een Afnemer (of Gebruiker) neemt IMGeo-gegevens van Distributie LV BGT af. Bepaalde Afnemers zijn

wettelijk verplicht tot het gebruik van BGT / IMGeo-gegevens en hebben de wettelijke taak tot het doen

van terugmeldingen bij redelijke twijfel van juistheid van de gegevens in LV.

N.B. Afnemer komt in deze versie van de berichtenstandaard niet terug in de scenario’s.

16

Schakels in de verticale BGT keten

17

4.2 Initiële levering

Het proces van initiële levering is onder te verdelen in de volgende stappen:

1. Aanleveren van initiële leveringen door bronhouders

2. Assembleren en uitleveren resultaat aan bronhouders

3. Registreren van geassembleerd bestand in de LV

4.2.1 Aanleveren

Op het moment dat Bronhouder een BGT13-voorbereid bestand heeft gerealiseerd, zal Bronhouder een

initiële levering van dit BGT-bestand doen aan SVB. Bronhouder zal hiertoe een mutatiebericht

aanmaken voor aanlevering aan SVB.

Uitgangspunt:

Tussen SVB en Bronhouders zal indien een mutatiebericht groter is dan 40MB altijd een ophaalverzoek

worden toegepast voor het ophalen van het mutatiebericht. Een mutatiebericht kleiner dan 40MB wordt

direct verstuurd; zonder ophaalverzoek.

Indien het mutatiebericht groter is dan 40MB zal het mutatiebericht voorafgegaan worden door een

ophaalverzoek14 van Bronhouder aan SVB. SVB bevestigt de ontvangst en haalt het mutatiebericht op

een later moment op vanaf een bestandslocatie (URL) van Bronhouder.

Indien het mutatiebericht kleiner is dan 40MB zal Bronhouder het mutatiebericht direct naar SVB

versturen. SVB bevestigt de ontvangst en gaat over tot verwerking van dit mutatiebericht.

Uitgangspunt:

Tussen SVB en LV zal altijd een ophaalverzoek worden toegepast voor het ophalen van een

mutatiebericht.

Uitgangspunt:

SVB maakt gebruik van de controle-service van de LV om een mutatiebericht te valideren.

SVB stuurt het mutatiebericht voorafgaand door een ophaalverzoek ter controle door naar de LV. De LV

voert technische en functionele controles uit op het mutatiebericht, o.a. valide geometrie, geldige

domeinwaarden en topologie15. LV geeft het resultaat van de controles terug in een mutatierespons.

Indien LV het mutatiebericht goedkeurt, stuurt LV een mutatierespons met verwerkingsactie “validatie

bestand” en status “succes” aan SVB. SVB stuurt het mutatierespons aan Bronhouder door en plaatst

hierop het mutatiebericht van Bronhouder tot assemblage in de wacht16.

13 Het BGT-voorbereide bestand mag ook objecten uit het optionele deel van IMGeo bevatten. 14 conform Digikoppeling Grote Berichten 15 Initieel: controle of in bestand er geen overlap tussen objecten voorkomt.

18

Indien LV het mutatiebericht afkeurt, stuurt LV een mutatierespons met verwerkingsactie “validatie

bestand” en status ”fout” aan SVB. SVB stuurt het mutatierespons aan Bronhouder door. Bronhouder dient

hierop het mutatiebericht te corrigeren en opnieuw aan te leveren aan SVB.

16 Mutatiebericht blijft in wacht tot andere rakende bronhouders voor dit gebied hebben aangeleverd

19

4.2.2 Assembleren en goedkeuren

Uitgangspunt:

Assemblage is alleen van toepassing tijdens de transitiefase op de initiële levering van twee of meer

bronhouders. Voor mutaties zal een verzameling van objecten van één of meer bronhouders worden

gemuteerd, zodanig dat de buitencontour van de actuele (WAS) en gewijzigde (WORDT) situatie in het

mutatiebericht ongewijzigd blijft.

Op het moment dat SVB van meerdere bronhouders in een gebied een mutatiebericht met initiële levering

heeft ontvangen, gecontroleerd, en in de wacht geplaatst, zal SVB overgaan tot de assemblage. Tijdens de

assemblage worden de objecten in de mutatieberichten van de bronhouders zodanig geometrisch

aangepast dat een gebiedsdekkend bestand ontstaat waarin objecten naadloos17 op elkaar aansluiten. Aan

ongeclassificeerde objecten zal SVB –indien niet aanwezig- een bronhouder toekennen.

Uitgangspunt:

Tijdens de assemblage kunnen objecten van Bronhouder(s) zowel in geometrie als attributen wijziging.

Ook kunnen objecten ontstaan of worden verwijderd. Bronhouder(s) krijgt na assemblage het resultaat

ter goedkeuring voorgelegd van SVB.

Als gevolg van de assemblage zullen de objecten uit het mutatiebericht van Bronhouder wijzigen. Hiertoe

stuurt SVB na het realiseren van een valide geassembleerd bestand een mutatie-oproep, waarin de de

wijzigingen aan Bronhouder ter goedkeuring worden voorgelegd.

Indien de mutatie-oproep groter is dan 40MB zal de mutatie-oproep voorafgegaan worden door een ophaalverzoek18. Rakende bronhouder bevestigt de ontvangst en haalt de mutatie-oproep op een later moment op vanaf een bestandslocatie (URL) van SVB. Indien de mutatie-oproep kleiner is dan 40MB zal SVB de mutatie-oproep direct naar Rakende bronhouder versturen. Rakende bronhouder bevestigt de ontvangst en gaat over tot beoordeling (controle) van deze mutatie-oproep.

Indien Bronhouder en Rakende bronhouder de mutaties van SVB in de mutatie-oproep goedkeurt, sturen

Bronhouder en Rakende bronhouder een mutatieOproepRespons met het resultaat “goedgekeurd” aan

SVB. SVB stuurt een mutatieRespons -als respons het het initiële mutatiebericht van Bronhouder en

Rakende bronhouder- met verwerkingsactie “assemablage intiële levering” en status “succes” en verdere

verwerking (registreren) van het mutatiebericht door SVB volgt.

Indien Bronhouder en/of Rakende bronhouder de mutaties in de mutatie-oproep afkeurt, stuurt

Bronhouder en/of Rakende bronhouder een mutatieOproepRespons met resultaat “afgekeurd” aan SVB.

SVB zal hierop in samenwerking met Bronhouder en/of Rakende bronhouder een nieuwe geassembleerd

bestand realiseren.

17 Naadloos: geen gaten en overlap tussen de objecten. 18 conform Digikoppeling Grote Berichten

20

Uitgangspunt:

Na afkeuring van een mutatie-oproep door Bronhouder en/of Rakende Bronhouder zal SVB in

samenwerking met beide bronhouders een nieuwe assemblage starten. Het mutatiebericht met initiële

levering van Bronhouder en/of Rakende bronhouder wordt hiermee niet afgekeurd, maar pas na het

bereiken van een gevalideerd geassembleerd bestand ter registratie aan LV aangeboden.

22

4.2.3 Registreren

Op het moment dat SVB een geassembleerd bestand voor initiële levering heeft gerealiseerd, maakt SVB

een mutatiebericht van het geassembleerde bestand aan en stuurt dit mutatiebericht, voorafgegaan door

een ophaalverzoek, ter registratie aan LV.

LV bevestigt de ontvangst en haalt het mutatiebericht op een later moment op vanaf een bestandslocatie

(URL) van SVB. Vervolgens controleert LV het mutatiebericht met geassembleerde initiële levering van

SVB intern en tegen de registratie van de LV.

Indien LV na controle van het mutatiebericht geen fouten constateert, keurt LV het mutatiebericht goed en

registreert het gegevens van de objecten in de centrale registratie van LV. LV stuurt een mutatierespons

aan SVB met verwerkingsactie “registratie in LV” en status ”succes” en een LV-publicatiedatum met het

tijdstip waarop de objecten in de centrale registratie van LV zijn geregistreerd. SVB filtert het

mutatierespons op gegevens voor (Rakende) Bronhouder(s) en stuurt een mutatierespons aan (Rakende)

Bronhouder(s). (Rakende) Bronhouder neemt de LV-publicatiedatum uit het mutatierespons op bij de

objecten in de eigen registratie.

Indien LV na controle van het mutatiebericht wel fouten constateert, keurt LV het mutatiebericht af en

stuurt een mutatierepons aan SVB met verwerkingsactie “registratie in LV” en status “fout”. SVB zal hierop

het mutatiebericht corrigeren en opnieuw aanleveren aan LV.

Uitgangspunt:

Gevalideerd geassembleerd bestand van SVB kan in principe niet worden afgekeurd door LV. SVB

controleert hiertoe tijdens het assemblageproces continue en vooraf het geassembleerde bestand

(mutatiebericht) tegen de controle-service van de LV. Alleen een volledig goedgekeurd (door LV) en

geassembleerd bestand zal als mutatiebericht door SVB ter registratie aan LV worden aangeboden.

24

4.3 Mutatie

Het proces van mutatie bestaat uit de volgende stappen

1. optioneel: Vooraankondiging door muterende Bronhouder

2. Aanleveren van een mutatiebericht door muterende Bronhouder

3. conditioneel: Goedkeuren van mutatiebericht door Rakende bronhouder

4. Registreren in de LV.

4.3.1 optioneel: Vooraankondiging

Op het moment dat een Bronhouder voornemens is om (objecten in) een gebied te muteren, kan

Bronhouder overgaan tot het doen van een vooraankondiging van deze mutaties aan SVB. Hiertoe stuurt

Bronhouder aan SVB een vooraankondigingsVerzoek met daarin de geometrie (polygoon) van het te

muteren gebied. SVB bevestigt de ontvangst en beoordeelt het verzoek. SVB voert hiertoe een ruimtelijke

selectie met de geometrie op de registratie van SVB uit om de betreffende objecten te identificeren.

Uitgangspunt:

Een vooraankondiging door Bronhouder op objecten van een Rakende bronhouder wordt niet ter

goedkeuring aan Rakende bronhouder voorgelegd. Indien op deze objecten van Rakende bronhouder

geen vooraankondigingslock gevestigd is, worden de objecten ter mutatie voor Bronhouder gelocked.

Indien SVB constateert dat op betreffende objecten geen vooraankondiging door een Rakende bronhouder

is gedaan, keurt SVB het verzoek goed en krijgen de betreffende objecten een vooraankondigingslock voor

muterende Bronhouder. SVB stuurt aan Bronhouder een vooraankondigingsRespons met daarin het

resultaat “goedgekeurd” van de beoordeling en de actuele stand van de betreffende objecten in de

registratie van SVB.

Uitgangspunt:

SVB stelt een (map) service beschikbaar met een overzicht van objecten waar een

vooraankondigingslock op is gevestigd. Deze service kan door Bronhouder worden geraadpleegd bij het

doen van een vooraankondigingsverzoek of na een afkeuring van een vooraankondigingsverzoek.

Indien het vooraankondigingsRespons groter is dan 40MB zal het vooraankondigingsRepons voorafgegaan

worden door een ophaalverzoek19. Bronhouder bevestigt de ontvangst en haalt het

vooraankondigingRespons op een later moment op vanaf een bestandslocatie (URL) van SVB.

Indien het vooraankondigingsRespons kleiner is dan 40MB zal SVB het vooraankondigingRespons direct

naar Bronhouder versturen. Bronhouder bevestigt de ontvangst en gaat over tot verwerking van dit

vooraankondigingsRespons.

Indien SVB een vooraankondigingslock op één of meer van de betreffende objecten constateert, keurt SVB

het verzoek af. SVB stuurt Bronhouder een vooraankondigingsRespons met daarin het resultaat

“afgekeurd” en reden van afkeuring per object. De Rakende bronhouder(s) die op de betreffende objecten

een vooraankondigingslock heeft, ontvangt van SVB het vooraankondigingsVerzoek van Bronhouder.

19 conform Digikoppeling Grote Berichten

25

Hierop kunnen Bronhouder en Rakende bronhouder(s) contact met elkaar zoeken om samen het gebied op

te werken.

Uitgangspunt:

Een vooraankondigingslock wordt opgeheven door een mutatiebericht of door het verstrijken van een

bepaalde tijdsperiode. Één mutatiebericht heft een vooraankondigingsverzoek op. Dus van alle objecten

in een vooraankondigingsverzoek wordt vooraankondigingslock opgeheven indien een mutatiebericht

tenminste één mutatie op een object uit dit vooraankondigingsverzoek bevat.

27

4.3.2 Aanleveren

Op het moment dat een muterende Bronhouder (objecten in) een gebied gemuteerd heeft, zal Bronhouder

overgaan tot het aanleveren van deze mutaties. Hiertoe stuurt Bronhouder aan SVB een mutatiebericht.

Indien het mutatiebericht groter is dan 40MB zal het mutatiebericht voorafgegaan worden door een

ophaalverzoek20. SVB bevestigt de ontvangst en haalt het mutatiebericht op een later moment op vanaf

een bestandslocatie (URL) van Bronhouder.

Indien het mutatiebericht kleiner is dan 40MB zal Bronhouder het mutatiebericht direct naar SVB

versturen. SVB bevestigt de ontvangst en gaat over tot beoordeling (controle) van dit mutatiebericht.

SVB stuurt daarop het mutatiebericht voorafgaand door een ophaalverzoek ter controle door naar de LV.

De LV voert technische en functionele controles uit op het mutatiebericht. LV geeft het resultaat van de

controles terug in een mutatieRespons.

Indien LV het mutatiebericht goedkeurt, stuurt LV een mutatierespons met verwerkingsactie “validatie

tegen LV” en status “succesvol” aan SVB en volgt verdere verwerking van het mutatiebericht door SVB.

Indien LV het mutatiebericht afkeurt, stuurt LV een mutatierespons met verwerkingsactie “validatie tegen

LV” en status “fout” aan SVB. SVB stuurt het mutatierespons van LV aan Bronhouder door; Bronhouder

dient hierop het mutatiebericht te corrigeren en opnieuw aan te leveren aan SVB.

SVB controleert vervolgens of het mutatiebericht van Bronhouder mutaties bevat op de actuele stand van

de betreffende objecten in de registratie van SVB. Indien SVB constateert dat op deze actuele stand is

gemuteerd, keurt SVB het mutatiebericht goed en volgt verdere verwerking van het mutatiebericht door

SVB.

Indien SVB constateert dat niet op deze actuele stand is gemuteerd, keurt SVB het mutatiebericht af en

stuurt een mutatierespons met verwerkingsactie “validatie tegen SVB” en status ”fout” aan Bronhouder.

Bronhouder dient hierop het mutatiebericht te corrigeren en opnieuw aan te leveren aan SVB.


29

4.3.3 conditioneel: Goedkeuren

Op het moment dat SVB een mutatiebericht van Bronhouder heeft goedgekeurd na de controle tegen de

actuele stand van de registratie van SVB, beoordeelt SVB of in het mutatiebericht van Bronhouder

objecten muteren van een (andere) Rakende bronhouder.

Uitgangspunt: Bronhouder mag in een mutatiebericht mutaties op objecten van een Rakende bronhouder aanleveren aan SVB. SVB legt de mutaties aan Rakende bronhouder ter goedkeuring voor.

Indien SVB geen Rakende Bronhouder constateert, stuurt SVB een mutatierespons met verwerkingsactie

“validatie tegen SVB” en status “succes” aan Bronhouder en volgt verdere verwerking (registreren) van

het mutatiebericht door SVB.

Indien SVB wel mutaties op objecten van Rakende bronhouder constateert, stuurt SVB een

mutatieOproep ter goedkeuring aan Rakende bronhouder.

Indien de mutatie-oproep groter is dan 40MB zal de mutatie-oproep voorafgegaan worden door een ophaalverzoek21. Rakende bronhouder bevestigt de ontvangst en haalt de mutatie-oproep op een later moment op vanaf een bestandslocatie (URL) van SVB. Indien de mutatie-oproep kleiner is dan 40MB zal SVB de mutatie-oproep direct naar Rakende bronhouder versturen. Rakende bronhouder bevestigt de ontvangst en gaat over tot beoordeling (controle) van deze mutatie-oproep.

Indien Rakende bronhouder de mutaties van Bronhouder in de mutatie-oproep goedkeurt, stuurt Rakende

bronhouder een mutatieOproepRespons met het resultaat “goedgekeurd” aan SVB. SVB stuurt een

mutatieRespons met verwerkingsactie “goedkeuring door Rakende bronhouder” en status “succes” en

verdere verwerking (registreren) van het mutatiebericht door SVB volgt.

Indien Rakende bronhouder de mutaties in de mutatie-oproep afkeurt, stuurt Rakende bronhouder een

mutatieOproepRespons met resultaat “afgekeurd” aan SVB. SVB stuurt een mutatieRespons met

verwerkingsactie “goedkeuring door Rakende bronhouder” en status “fout” en gaat over tot bemiddeling

tussen Bronhouder en Rakende bronhouder.

Uitgangspunt:

Na afkeuring van een mutatie-oproep door Rakende Bronhouder op mutaties van Bronhouder zal SVB

bemiddeling opstarten. Het mutatiebericht van Bronhouder is hiermee afgekeurd en zal niet ter

registratie aan LV worden aangeboden.

In het algemeen zal gelden dat na bemiddeling door SVB, Bronhouder een nieuw mutatiebericht

aanlevert aan SVB, waarop Rakende bronhouder de mutaties in de daaruitvolgende mutatie-oproep

van SVB wel goedkeurt.


30

4.3.4 Registreren

Op het moment dat mutatiebericht door SVB (en Rakende bronhouder) is goedgekeurd, zal SVB het mutatiebericht ter registratie aan LV aanleveren. Zie 4.1.3 Registreren in LV.

31

Hoofdstuk 5

Berichten

Dit hoofdstuk beschrijft de berichten voor horizontale en verticale koppelvlak. Bepaalde

berichten komen voor in beide koppelvlakken.

5.1 Berichtsoorten

De volgende berichtsoorten worden onderkend.

5.1.1 Mutatiebericht(mtbDi01)

Asynchroon vrij bericht voor de aanlevering van mutaties op één of meer IMGeo-objecten.

5.1.2 Mutatierespons (mtbDu01)

Asynchroon vrij bericht als respons op een mutatiebericht met daarin het resultaat van de functionele

controle.

5.1.3 Mutatieverzoek(mtvDi01)

Asynchroon vrij bericht met het verzoek om een mutatie op aangeleverde objecten door te voeren in de

registratie van het ontvangende systeem.

5.1.4 weigerbericht (mtvWeigerDu01)

Asynchroon vrij bericht als respons op een mutatieverzoek indien één specifiek object niet wordt

doorgevoerd in de registratie van ontvangende systeem. Let op: per geweigerd object wordt een

weigerbericht verstuurd.

5.1.5 mutatieOproep (mtoDi01)

Asynchroon vrij bericht met de oproep om een mutatie op objecten door te voeren in de registratie van

het ontvangende systeem.

5.1.6 mutatieOproepRespons (mtoDi01)

Asynchroon vrij bericht als respons op een mutatie-oproep met daarin het resultaat van de beoordeling

van de mutatie-oproep door ontvangende systeem.

5.1.7 Exploratieverzoek (expDi01)

Asynchroon vrij bericht met een verzoek om verkennend onderzoek uit te voeren in een bepaald gebied.

5.1.8 Exploratierespons (expDu01)

Asynchroon vrij bericht als respons op een exploratieverzoek met de kennisgeving van de afhandeling van

het exploratieverzoek.

5.1.9 Vooraankondigingsverzoek (vavDi01)

Asynchroon vrij bericht met het verzoek om 1 of meer IMGeo-objecten te reserveren (‘locken’) voor

mutatie door zendende systeem.

5.1.10 VooraankondigingsRepons (vavDu01)

Asynchroon vrij bericht als respons op een vooraankondiging met daarin het resultaat van de

reservering/locking.

32

5.1.11 Ophaalverzoek (opvDi01)

Asynchroon vrij bericht met het verzoek om een bericht of bestand op te halen vanaf locatie (URL) van zendende systeem.

5.1.12 Bevestiging van ontvangst (Bv03)

Standaard StUF bevestigingsbericht

5.2 Gebruik

De toepassing van deze berichten is als volgt:

Bericht Geo BOR RBH BH SVB LV

mutatieBericht (mtbDi01) Z O Z/O Z/O Z/O O

mutatieRespons (mtbDu01) O O Z/O Z

mutatieVerzoek (mtvDi01) O Z

weigerBericht (mtvWeigerDu01) Z O

mutatieOproep (mtoDu01) O O Z

mutatieOproepRespons (mtoDu01) Z Z O

exploratieVerzoek (expDi01) O Z

exploratieRespons (afhDi01) Z O

vooraankondigingVerzoek (vrkDi01) O Z O

vooraankondigingRepons (vrkDu01) O Z

ophaalVerzoek (ophDi01) Z/O Z/O Z/O O

bevestigingOntvangst (Bv03) Z/O Z/O Z/O Z/O Z/O Z/O

RBH = Rakende bronhouder

BH = Bronhouder

Z = Zenden

O = Ontvangen

33

5.3 Berichteninhoud

Bericht Stuurgegevens Entiteittype Inhoud

mutatieBericht (mtbDi01) Standaard MTB-verzoek 1..* van :

<xxxLk01T>

<xxxLk01W>

mutatieRespons (mtbDu01) Respons MTB-respons -

mutatieVerzoek (mtvDi01) Standaard MTV-verzoek 1..* van :

<xxxLk01T>

<xxxLk01W>

weigerBericht (mtvWeigerDu01) Respons WGB-respons -

mutatieOproep (mtoDi01) respons MTO-verzoek 1..* van :

<xxxLk01T>

<xxxLk01W>

mutatieOproepRespons (mtoDu01) respons MTO-respons -

exploratieVerzoek (expDi01) Standaard EXP-verzoek -

exploratieRespons (expDu01) Respons EXP-respons -

vooraankondigingVerzoek (vavDi01) Standaard VAV-verzoek -

vooraankondigingRepons (vavDu01) respons VAV-respons 1..* van :

<object>

ophaalVerzoek (opvDi01) standaard OPV-verzoek

bevestigingOntvangst (Bv03) Standaard StUF-bericht

34

5.4 StUF-Stuurgegevens

Een StUF bericht begint altijd met een aantal stuurgegevens, die in deze paragraaf kort worden toegelicht.

Zie de StUF standaard voor een uitgebreide bespreking hiervan.

<berichtcode>

Geeft aan om wat voor soort bericht het gaat, bijv. “mtbLVDi01” voor een mutatiebericht van SVB aan LV.

<zender>

De verzender van het bericht. In ieder geval moet hier de organisatie, applicatie en gebruiker van de

verzendende organisatie worden opgenomen.

<ontvanger>

De ontvanger van het bericht; ook hier moet de applicatie worden opgenomen, nu van de ontvangende

organisatie.

<referentienummer>

Identificerend nummer van het bericht bij de verzender. In dit nummer is een volgnummer verwerkt; dit

bepaalt de volgorde waarin berichten verwerkt worden en dient ter controle dat er geen berichten

ontbreken c.q. niet ontvangen zijn (zie ook 2.7)

<tijdstipBericht>

Tijdstip waarop het bericht is aangemaakt.

<functie>

Alleen in het bgtDi01 en bgtBronDi01 bericht is dit stuurgegeven opgenomen. Omdat dit een vrij bericht is

kan niet worden aangegeven over welk objecttype het bericht gaat (dit zullen er immers meestal

verschillende zijn). Het stuurgegeven <entiteittype> is daarom niet opgenomen. In plaats daarvan wordt

in dit element met een vaste waarde aangegeven wat de functie van het bericht is:

‘MeervoudigeTransactie’ danwel ‘MeervoudigeTransactieBron’.

<cross-referentienummer>

Identificerend nummer van het bericht waarop een respons wordt gegeven.

Versie StUF

Welke StUF versie wordt gehanteerd, is te zien aan de StUF namespace declaratie in het bericht. Voor

deze versie van het koppelvlak wordt “0301” ondersteund.

35

5.5 Entiteittypen

5.5.1 Mutatiebericht (MTB)

Entiteittype Mutatiebericht voorziet in een functionele identificatie van en respons op het mutatiebericht.

Entiteit-gegevens MTB-verzoek Omschrijving Occ Type

<idMutatiebericht> Identificatie van het

mutatiebericht

0-1 StUF:sleutel

<toelichting> Tekstuele toelichting 0-1 String

<documentVerwijzing>22 Verwijzing naar documentatie 0-1 String

<idMutatieverzoek>22 Identificatie van het

gerelateerde mutatieverzoek

0-1 String

Entiteit-gegevens MTB-respons Omschrijving Occ Type

<idMutatiebericht> Identificatie van het

gerelateerde mutatiebericht

0-1 String

<respons> 1-1

<laatsteVerwerkingsActie> Naam van verwerkingsactie 1-1 GML:

codelist

<statusLaatsteVerwerkingsActie> Status van verwerkingsactie 1-1 String

<urlVerwerkingsverslag> Locatie (URL) van

verwerkingsverslag

0-1 URL


<LV-publicatiedatum> Datum van registreren

objecten mutatiebericht in LV

0-1 dateTime

5.5.2 Mutatieverzoek (MTV)

Entiteittype Mutatieverzoek voorziet in een functionele identificatie van en respons op het mutatieverzoek.

Entiteit-gegevens MTV-verzoek Omschrijving Occ Type

<idMutatieverzoek> Identificatie van het

mutatieverzoek

1-1 StUF:sleutel


<documentVerwijzing>22 Verwijzing naar documentatie 0-1 String

<idMutatiebericht>23 Identificatie van het


0-1 String

Entiteit-gegevens MTV-respons Omschrijving Occ Type



0-1 String

<respons>


22 Alleen horizontaal 23 Alleen verticaal

36

5.5.3 MutatieOproep (MTO)

Entiteittype MutatieOproep voorziet in een functionele identificatie van en respons op de mutatie-oproep.

Entiteit-gegevens MTO-verzoek Omschrijving Occ Type

<idMutatieOproep> Identificatie van de

mutatieOproep

1-1 StUF:sleutel


<idMutatiebericht>24 Identificatie van het


0-1 String

Entiteit-gegevens MTO-respons Omschrijving Occ Type

<idMutatieOproep> Identificatie van het


1-1 String

<resultaat> Resultaat na beoordeling

mutatie-oproep:

“Goedgekeurd” of “Afgekeurd”

1-1 String


5.5.4 Weigerbericht (WGB)

Entiteittype Weigerbericht voorziet in een functionele respons op het mutatieverzoek als weigerbericht,

indien een kennisgeving uit het verzoek niet wordt overgenomen (geweigerd) in de registratie van

ontvanger.

Entiteit-gegevens WGB-Respons Omschrijving Occ Type

<isWeigeringop> 1-1


mutatieverzoek

1-1 StUF:Sleutel

<afgekeurdObject> 1-1

<idIMGeo> IMGeo-identificatie van het

afgekeurde object

1-1 IMGeo:NEN3610

<idBOR> BOR-identificatie van het

afgekeurde object

1-1 String


<documentVerwijzing> Verwijzing naar

documentatie

0-1 String

24 Alleen verticaal

37

5.5.5 Exploratieverzoek (EXP)

Entiteittype Exploratieverzoek voorziet in een functionele identificatie van en respons op het

exploratieverzoek.

Entiteit-gegevens EXP-verzoek Omschrijving Occ Type

<idExploratie> Identificatie van

exploratieverzoek

1-1 StUF:Sleutel

<geometrie> Locatiemarkering van het te

verkennend onderzoeken

gebied d.m.v. punt, lijn of

vlakgeometrie

1-1 Geometrie t.w.

GML:Point, of

GML:Linestring, of

GML:Surface

<toelichting> Tekstuele toelichting 0-1 string

<documentVerwijziging> Verwijzing naar documentatie 0-1 string

Entiteit-gegevens EXP-Respons Omschrijving Occ Type

<idExploratie> Identificatie van gerelateerde

exploratieverzoek

1-1 StUF:Sleutel

<respons> 1-1


<documentVerwijzing> Tekstuele toelichting 0-1 String

5.5.6 Vooraankondiging (VAV)

Entiteittype Vooraankondiging voorziet in een functionele identificatie van en respons op een

vooraankondigingsVerzoek.

Entiteit-gegevens VAV-verzoek Omschrijving Occ Type

<idVooraankondiging> Identificatie van

vooraankondiginsverzoek

1-1 StUF:Sleutel

<geometrie> Buitencontour van het te

muteren gebied

1-1 GML:Surface

<muterendeBronhouder> Identificatie van muterende

bronhouder

1-1 String

Entiteit-gegevens VAV-respons Omschrijving Occ Type

<idVooraankondiging> Identificatie van gerelateerde

vooraankondiginsverzoek

1-1 String

<respons> 1-1

<resultaat> Resultaat op

vooraankondigingsverzoek

1-1 String:

{afgekeurd,

goedgekeurd}

<nietGelocktObject> 0..*

<idIMGeo> Identificatie van IMGeo-object 1-1 IMGeo:NEN3610

38

5.5.7 Ophaalverzoek (OPV)

Entiteittype Ophaalverzoek voorziet in een functionele identificatie van een op te halen bericht conform

Digikoppeling Grote Berichten.

Entiteit-gegevens OPV-verzoek Omschrijving Occ Type

<idOphaalverzoek> Identificatie van

ophaalverzoek

1-1 StUF:Sleutel

<stuurgegevens> Stuurgegevens van op te

halen bericht

StUF:Stuurgegevens

<gb:digikoppeling> 1-1

<data-reference> 1-*

<lifetime> Begin- en vervaldatum 1-1 Zie DGB

<content> Bestandnaam en

checksum

1-1 Zie DGB

<transport> Locatie (URL) 1-1 Zie DGB

N.B. in afwijking van Digikoppeling Grote Berichten geldt voor uitwisseling in de BGT keten dat een

ophaalverzoek minimaal en maximaal 1 verwijzing <data-reference> naar een op te halen bestand mag

bevatten.

5.6 Kennisgevingen

Naast procesinformatie in het entiteittype van het bericht, bevat een mutatiebericht, mutatieverzoek en

mutatie-oproep als inhoud een of meer kennisgevingen over het toevoegen of verwijderen (resp. xxxLk01T

en xxxLk01W) van een objecttype.

Voor elk objecttype (of in StUF terminologie: entiteittype) wordt in het StUF bericht een drieletterige

afkorting gehanteerd. Hieronder staat de lijst met afkortingen:

Naam objecttype Afkorting

bak BAK

begroeid terreindeel BTD

bord BRD

buurt BRT

functioneel gebied FUG

gebouwinstallatie GBI

installatie INS

kast KST

kunstwerkdeel KWD

mast MST

onbegroeid terreindeel OTD

ondersteunend waterdeel OWT

ondersteunend wegdeel OWG

ongeclassificeerd object OCO

openbare ruimte OPR

openbare ruimte label ORL

overbruggingsdeel OBD

overig bouwwerk OBW

overige scheiding OSH

paal PAL

39

Naam objecttype Afkorting

pand PND

plaatsbepalingspunt PBP

put PUT

scheiding SHD

sensor SNS

spoor SPR

stadsdeel STD

straatmeubilair STM

tunneldeel TND

vegetatieobject VGO

waterdeel WTD

waterinrichtingselement WTI

waterschap WSP

wegdeel WGD

weginrichtingselement WGI

wijk WYK

5.7 Extra elementen en domeinwaarden

De volgende extra elementen zijn opgenomen in de berichten. Daarnaast worden twee extra

(kennisgevingen voor) objecttypen Leiding en Leidingelement opgenomen (zie bijlage 2).

5.7.1 <beheerder>

Definitie attribuuttype: het organisatieonderdeel van de betreffende bronhouder dat het feitelijke beheer

over het object voert.

Toelichting: De bronhouder is verantwoordelijk voor de bijhouding van het BGT/IMGeo object in de BGT

registratie. Het feitelijke beheer ervan kan bij een bepaald organisatieonderdeel liggen. In sommige

gevallen is het – ook in het berichtenverkeer - zinvol om te weten wie het feitelijke beheer uitvoert. En

sommige objecten hebben meerdere beheerders: bv een lantaarnpaal met verkeersbord. Het moet dus

mogelijk zijn om per object meerdere beheerders via het koppelvlak uit te wisselen.

Domeinwaarden:

GE= Gemeentelijk eigendom

GR= Groenbeheer

KU= Kunstwerkbeheer

RI= Rioolbeheer

SP= Speelwerktuigenbeheer OP= Openbare Verlichting

WE= Wegbeheer WA=Waterbeheer BA= BAG

KL= K&L

VE= Verkeersborden

BO= Bomen

PA=Particulier/Privaat

O1= Overig 1

O2= Overig 2

O3= Overig 3

ON= Onbekend

40

Het hoeft geen multi-attribuut te zijn, maar het is eenvoudiger een permutatie van meerdere

domeinwaarden toe te staan in één attribuutveld.

5.7.2 <documentverwijzing>

Definitie attribuuttype: een verwijzing naar een fysiek document of plan in een analoog archief, danwel

een digitale versie hiervan in een Document Informatie Voorziening (DIV) waarin is vastgelegd wat de

aanleiding is voor de betreffende mutatie(s) in het BGT/IMGeo bestand. Domein: vrij tekstveld, 80

characters.

5.7.3 <geometrie>

Punt, lijn of vlakgeometrie (GML-geometrie); voor vooraankondigingsverzoek: alleen GML:Surface.

5.7.4 <idExploratieverzoek>

Uniek referentienummer (identificatie) welke wordt toegekend aan een exploratieverzoek.

5.7.5 <idMutatiebericht>

Identificerend nummer van mutatiebericht.

5.7.6 <idMutatieverzoek>

Identificerend nummer van mutatieverzoek.

5.7.7 <idVooraankondiging>

Identificerend nummer van een vooraankondigingsverzoek

5.7.8 <laatsteVerwerkingsActie>

De laatste verwerkingsActie die in de functionele controle van een mutatiebericht, mutatieverzoek,

vooraankondiging of exploratieverzoek is doorlopen.

De domeinwaarden zijn niet als enumeratie in de berichtenstandaard opgenomen, maar worden als externe codelist gepubliceerd.

Validatie XML (VALXML) Validatie bestand (VALBES) Validatie tegen LV (VALLV) Validatie tegen SVB (VALSVB)

Goedkeuring door Rakende Bronhouder (GKRBH) Registratie LV (REGLV)

5.7.9 <lv-publicatiedatum>

Datum en tijdstip waarop objecten in Centrale Registratie LV zijn geregistreerd.

5.7.10 <mutatieVerzoek>

Entiteittype t.b.v. (respons op) mutatieverzoek

5.7.11 <muterendeBronhouder>

Identificatie van de Bronhouder die een vooraankondiging indient.

5.7.12 <resultaat>

Resultaat na beoordeling van een mutatieverzoek of vooraankondigingsverzoek.

5.7.13 <sleutelVerzendend> en <sleutelOntvangend> voor <object>

Deze gegevens worden als optioneel attribuut aan <object> toegevoegd, conform StUF.

5.7.14 <statusVerwerkingsActie>

Status van de laatste verwerkingsActie.

41

Domein: succes (S), fout (F), in uitvoering (U) of niet uitgevoerd (N).

5.7.15 <toelichting>

Begeleidende vrije tekst. Domein: text(500).

5.7.16 <verslagVerwerkingURL>

Locatie (URL) vanaf waar een verwerkingsverslag gedownload kan worden. Domein: varchar(300).

42

Bijlage 1 Overzicht uitgangspunten

Hieronder staat een bewerking van de uitgangspunten uit het FO Koppeling Geo-BOR, met daarin een

vertaling naar de algemene uitgangspunten voor beide ketens, en specifieke uitgangspunten voor

horizontale en verticale keten.

Algemeen: systeem en applicatie

Het ontvangende en zendende systeem zijn in staat om bij de klant aanwezige Geo en BOR

applicatie kan IMGeo objecten verwerken.

Algemeen: berichtenverkeer

Het berichtenverkeer verloopt via een internet/intranet (HTTP) verbinding. Aanwezigheid van een

ESB (Enterprise Service Bus) o.i.d. is niet vereist.

Het ontvangende en zendende systeem wisselen middels webservices StUF-Geo IMGeo

kennisgevingsberichten en procesberichten uit.

De stroom van gegevensuitwisseling vanuit beide omgevingen is éénrichtingsverkeer (push

mechanisme)

Het ontvangende systeem stuurt middels een synchrone respons een bevestiging van ontvangst

aan het zendende systeem. De afhandeling van het berichtenverkeer bij het niet verkrijgen van

een ontvangstbevestiging is conform de generieke StUF afspraken.

De verwerking van de kennisgevingsberichten in het ontvangende systeem is a-synchroon.

Bij uitwisseling van berichten tussen meerdere organisaties is een referentienummer in de

afhandeling bij de ontvanger niet meer uniek. De oplossing hiervoor – in de afhandeling - is het

gebruik van de combinatie <zender> en <referentienummer> van het bericht. In de

stuurgegevens kunnen voor <zender> de volgende adresgegevens worden opgenomen:

<organisatie>, <applicatie>, <gebruiker> en <administratie>. Minimaal moeten dan de volgende

gegevens worden opgenomen: <organisatie>, <applicatie> en <gebruiker>.

Elementen in berichten die geen waarde hebben zijn wel aanwezig en krijgen waarde

“WaardeOnbekend”.

Alle was/wordt attributen van een object in een StUF bericht worden ingevuld meegestuurd. Dus

niet alleen die attributen die gemuteerd zijn.

Alle mutaties die in één transactie bij GEO zijn verwerkt worden in één bericht naar BOR

verstuurd.

Specifiek horizontaal: Procedureel

De (beheerder van de ) Geo-applicatie is bronhouder van IMGeo-objecten en als zodanig

verantwoordelijk voor het bijhouden van de geometrie en attributen van IMGeo-objecten en het

leveren van BGT/IMGeo-gegevens aan het SVB-BGT.

De (beheerder van de ) BOR-applicatie is afnemer van IMGeo-gegevens en alszodanig verplicht

tot het doen van terugmeldingen op de BGT / IMGeo-gegevens.

De (beheerder van de ) BOR-applicatie is verplicht tot het overnemen van de gegevens uit een

mutatiebericht afkomstig van de Geo-applicatie.

De (beheerder van de ) BOR-applicatie mag geen IMGeo-objecten toevoegen aan of verwijderen

uit de BOR-registratie en mag geen aan IMGEO gerelateerde attributen wijzigen, waaronder de

geometrie . Het toevoegen, wijzigen of verwijderen van een IMGeo-object uit de BOR-registratie

gaat middels een mutatieverzoek aan de Geo-applicatie.

De (beheerder van de ) GEO-applicatie is niet verplicht tot het doorvoeren van een

mutatieverzoek. Indien het mutatieverzoek niet wordt gevolgd, stuurt de Geo-applicatie een

terugmelding d.m.v. een specifiek procesbericht naar de BOR-applicatie.

Een mutatiebericht ontstaat op het initiatief vanuit de Geo-applicatie of in reactie op een

mutatieverzoek of exploratieverzoek van de BOR-applicatie.

43

Specifiek verticaal: Procedureel

(Rakende) Bronhouder is bronhouder van IMGeo-objecten en als zodanig verantwoordelijk voor

het bijhouden van de geometrie en attributen van IMGeo-objecten en het leveren van

BGT/IMGeo-gegevens aan het SVB-BGT.

LV-BGT is houder van de centrale registratie van IMGeo-objecten en als zodanig verantwoordelijk

voor de integriteit van de gegevens in de registratie van LV-BGT

Afnemer of gebruiker is afnemer van IMGeo-gegevens en alszodanig verplicht tot het doen van

terugmeldingen op de BGT / IMGeo-gegevens.

Specifiek verticaal: Procedureel

SVB-BGT en LV-BGT zijn verplicht tot het overnemen van de gegevens uit een mutatiebericht

afkomstig van de Bronhouder of Rakende Bronhouder.

SVB-BGT en LV-BGT mag geen IMGeo-objecten toevoegen of wijzigen in de registratie van

Bronhouder. Het toevoegen of wijzigen van een IMGeo-object gaat middels een mutatieverzoek

aan Bronhouder.

Bronhouder mag voor een Rakende bronhouder een mutatie op een object aanleveren aan SVB.

SVB-BGT zal aan Rakende bronhouder een mutatie-oproep ter goedkeuring voorleggen.

Bronhouder is niet verplicht tot het doorvoeren van een mutatie-oproep. Indien e mutatie-oproep

niet wordt gevolgd, stuurt de Bronhouder een respons met afkeuring naar SVB-BGT.

Afnemer of gebruiker is afnemer van IMGeo-gegevens en alszodanig verplicht tot het doen van

terugmeldingen op de BGT / IMGeo-gegevens.

Exclusief specifiek horizontaal: Procedureel

Indien de (beheerder van de ) BOR-applicatie een fout constateert in een mutatiebericht van de

Geo-applicatie, moet de BOR-applicatie de gegevens allereerst overnemen in de BOR-registratie

en vervolgens de geconstateerde onjuistheden middels een mutatie-of redlineverzoek

terugmelden aan de Geo-applicatie.

Bij het versturen van een samengesteld mutatiebericht van Geo naar BOR, met daarin

verschillende soorten objecten, zal het volledige bericht naar al deze BOR-systemen worden

verstuurd. Dus inclusief de objecten die niet voor het ontvangende systeem interessant zijn. Het

ontvangende en/of verzendende systeem kan desgewenst worden geconfigureerd om niet van

belang zijnde objecten uit het bericht filteren.

Bij meerdere BOR-afnemers binnen een organisatie krijgt degene die een nieuw object gemeld

heeft het BOR-ID terug, anderen ontvangen een leeg veld. En indien bij het versturen van uit Geo

één van de BOR-applicaties een foutbericht oplevert krijgt alleen deze opnieuw het mutatiebericht

(=standaard StUF protocol).

Tussentijdse synchronisatie van Geo en BOR wordt niet via het GeoStUF berichtenverkeer

verzorgd. Iedere leverancier ontwikkelt daar zelf controletools voor. Mogelijk dat in een latere

versie van het koppelvlak uitgebreid wordt met het vraag/antwoord principe van StUF om de

verschillen tussen Geo en BOR te constateren.

Algemeen: Mutatiebericht en mutatieverzoek

In een mutatiebericht, mutatie-oproep en mutatieverzoek worden middels een samengestelde

transactie één of meerdere toevoegings(T)- en wijzigingskennisgevingen (W) voor objecten

verstuurd. Dus zowel voor een mutatie van één object of meerdere objecten dient een

mutatiebericht gebruikt te worden.

Het verwijderen van een object wordt gezien via een wijzigingskennisgeving (W) waarbij de

status van het IMGEO-object wijzigt in historie en een einddatum is ingevuld.

Een mutatie-oproep, mutatieverzoek en mutatiebericht hebben altijd

“MeervoudigeTransactieBron” voor het element <Functie>.

44

Algemeen: Mutatieverzoek

Een mutatieverzoek betreft een verzoek voor het toevoegen van een nieuw object of het wijzigen

van een bestaand object.

Een mutatieverzoek heeft altijd waarde “I” (informatief) voor element <indicator Overname>.

Als reactie op het niet doorvoeren van wijzigingen of toevoegingen van één, meerdere of alle

objecten uit een mutatieverzoek wordt per object een weigerbericht verstuurd. Dit weigerbericht

bevat in vrije tekstveld de reden van weigering (mogelijk in een 2e versie van het koppelvlak een

landelijke domeinwaardenlijst hiervoor opstellen), het referentienummer en IMGEO-id (specifiek

horizontaal: bij nieuw object het BOR-id).

Specifiek horizontaal: Mutatieverzoek

Een mutatieverzoek bevat de gegevens van een potentieel IMGEO-object, aangevuld met

stuurgegevens waaronder BOR-ID.

Algemeen: Exploratieverzoek

Een exploratieverzoek betreft een verzoek tot het inwinnen of aanpassen van objecten in een

bepaald gebied. Een exploratieverzoek bevat dus wel geometrie, maar geen IMGEO-objecten.

Het resultaat van verwerking op een exploratieverzoek geeft aan dat alle mutatieberichten die

een gevolg zijn van het redlineverzoek zijn verstuurd en daarmee dat het redlineverzoek is

afgehandeld. Mee terugsturen: het referentienummer.

Een exploratieverzoek heeft altijd waarde “AanmaakExploratieverzoek” voor het element

<Functie>.

Algemeen: Mutatiebericht

Een mutatiebericht heeft altijd waarde “V” (verplichte overname) voor element

<indicatorOvername>.

Algemeen: Weigerbericht

Een weigerbericht heeft waarde “NietDoorgevoerdeWijziging” voor het element <Functie> bij een

niet doorgevoerd wijzigingsbericht (W) en waarde “NietDoorgevoerdeToevoeging” bij een niet

doorgevoerd toevoegingsbericht (T).

Specifiek horizontaal: Technische specificaties

Het FO Koppeling Geo-BOR stelt dat qua geometrie gelden de volgende uitgangspunten voor Geo

en BOR: een 2D IMGeo geometrie en optioneel een Lod0 (waar de Z-Coördinaat in zit). Validatie

volgens Oracle regels met tolerantie van 0.0005m.

Algemeen: Systeemsleutels en het IMGeo-ID

Nieuwe IMGeo-identificaties (een GUID) ontstaan alleen bij Geo / Bronhouder. Bronhouder

bepaalt of er nieuwe IMGeo objecten ontstaan of nieuwe versies van bestaande objecten (zoals

de BGT/IMGeo catalogus voorschrijft).

De IMGeo sleutel wordt – indien bekend - altijd meegestuurd. Het staat de verzendende systeem

vrij om de overige sleutels – indien die bekend zijn - mee te sturen.

De systeemsleutels worden in het StUF bericht middels “sleutelVerzender” / ”sleutelOntvanger”

verstuurd, het IMGeo-id middels namespace (NL.IMGEO) en lokaalID.

De characterstring van deze StUFsleutels moet alfanumerieke tekens kunnen bevatten en een

zodanig lengte hebben dat deze het aantal characters van de BOR en IMGEO-ID’s kunnen

bevatten.

De unieke identificatie van een (versie van) een object wordt gedaan op basis van lokaal-id

(IMGEO GUID) in combinatie met tijdstipRegistratie.

45

Specifiek horizontaal: Systeemsleutels en het IMGeo-ID

Naast het IMGeo-id kunnen in de BOR- en GEO- applicaties interne ID’s zijn gekoppeld (de zgn

systeem- of databasesleutels).

Een mutatiebericht of mutatieverzoek bevat minimaal één identificerende sleutel van de Geo- of

BOR-applicatie (IMGeo_ID en/of BOR_ID).

Indien er een nieuw object aan BOR zijde ontstaat dient in het mutatieverzoek het BOR-ID (=

database sleutel van BOR) mee naar Geo verstuurd te worden en moet deze door GEO in het

mutatiebericht mee teruggestuurd naar BOR aan de verzender van het mutatieverzoek.

Als er aan BOR zijde geen IMGEO sleutel bekend is, dan dient “WaardeOnbekend” ingevuld te

worden.

Bij een mutatieverzoek vanuit BOR betreffende een nieuw object krijgen het Lokaal-id (=

IMGEO-identificatie), sleutel-ontvanger, creationDate en tijdstipRegistratie niet de waarde

‘waardeOnbekend’ krijgen maar ‘geenWaarde’ omdat ze daadwerkelijk (nog) geen waarde

hebben.

Als het systeem de waarde niet weet, zoals in een situatie dat Geo op eigen initiatief een

mutatiebericht verstuurt (BOR-ID/sleutel-ontvanger is niet bekend) dan wordt gebruik gemaakt

van ‘waardeOnbekend’. Dit betekent, er is wel een waarde ergens aanwezig, maar deze is niet

bekend bij de versturende partij.

Een exploratieverzoek en resultaat van verwerking hierop bevatten geen identificerende sleutels

van IMGeo-objecten.

Specifiek horizontaal: functionaliteit en uitwisseling

De BOR applicatie heeft minimale functionaliteit t.a.v. schetsen van geometrie voor objecten door

middel van redlining.

De BOR applicatie creëert geen plaatsbepalingspunten en krijgt deze ook niet toegestuurd vanuit

Geo.

De BOR applicatie moet kunnen omgaan met multi-vlakken. Een multi-vlak bevat meerdere

vlakken waar één object-ID aangehangen is. Voor IMGEO betreft dit alleen de objecten pand en

overig bouwwerk.

Bij Geo heeft de BGT-applicatie functionaliteit ten aanzien van:

- Accuraat intekenen van geometrie

- Waarborging van eisen rond opdelendheid en nauwkeurigheid van de BGT

- Uitgeven van IMGeo-ID’s en versiebeheer van IMGeo-objecten

- Distributie van IMGEO objecten naar het SVB-BGT

- Afhandeling van terugmeldingen van SVB-BGT.

Er worden terugmeldingen25 door Geo aan BOR gedaan bij:

- Afhandeling complete exploratieverzoek na versturen van het laatste mutatiebericht.

- Mutatieverzoek dat niet wordt doorgevoerd.

Tussen Geo- en BOR-applicatie wordt niet het IMGeo-object “Plaatsbepalingspunt” uitgewisseld.

Het attribuut <LV_publicatiedatum> wordt niet uitgewisseld tussen Geo- en BOR-applicatie. De

wijziging van attribuut <LV_publicatiedatum> van een IMGeo-object in de Geo-applicatie leidt

niet tot een mutatiebericht naar de BOR-applicatie.

In het GEO-BOR berichtenverkeer kan voor veel verplichte IMGeo attributen niet voldaan worden

aan de huidige tabel met kardinaliteiten uit GeoStUF. Verplichte IMGEO-attributen mogen in een

mutatieverzoek en weigerbericht leeg zijn. De elementen zijn wel aanwezig in het bericht maar

krijgen als waarde “WaardeOnbekend” .

25 Procesbericht resultaat van verwerking

46

Bijlage 2 Extra objecttypen: <Leiding> en <Leidingelement>

Klasse Type leiding Plus Type

Leiding Kabel Aarddraad

Mantelbuis

HDPEbuis

Buis Buisleiding

Kabelbed

Klasse Functie Functie Plus

Leiding Riolering Vrij verval

Onder druk

Drainage

Huisaansluiting

Water Drinkwater

Bluswater

Gas Hoge druk

Midden druk

Lage druk

Elektriciteit Landelijk hoogspanningsnet

Hoog

Midden

Laag

47

Openbare verlichting

Warmtenet

Datatransport Telecom

CAI

Verkeersregeling

Gladheidsmeldingen (GMS)

Tellingen

Gevaarlijke inhoud Petro

Chemie

Wees

Overig

48

Leidingelement

TypeLeidingelement

Mof

Verloopstuk

T-stuk

Verdeelstuk

Afsluiter

Kraan

Put (ondergronds)

Tappunt

Ontluchter

Inlaat

Aansluitpunt

Uitlaat/lozingswerk

Rioolvoorziening

Functioneel ontwerp Berichtenverkeer StUF-Geo IMGeo voor ...

Documents

Transcript of Functioneel ontwerp Berichtenverkeer StUF-Geo IMGeo voor ...