Upload
dinhduong
View
235
Download
5
Embed Size (px)
Citation preview
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.
12
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
14
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.
21
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.
23
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.
26
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.
20 conform Digikoppeling Grote Berichten
28
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.
21 conform Digikoppeling Grote Berichten
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
<toelichting> Tekstuele toelichting 0-1 String
<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
<toelichting> Tekstuele toelichting 0-1 String
<documentVerwijzing>22 Verwijzing naar documentatie 0-1 String
<idMutatiebericht>23 Identificatie van het
gerelateerde mutatiebericht
0-1 String
Entiteit-gegevens MTV-respons Omschrijving Occ Type
<idMutatieverzoek> Identificatie van het
gerelateerde mutatieverzoek
0-1 String
<respons>
<toelichting> Tekstuele toelichting 0-1 String
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
<toelichting> Tekstuele toelichting 0-1 String
<idMutatiebericht>24 Identificatie van het
gerelateerde mutatiebericht
0-1 String
Entiteit-gegevens MTO-respons Omschrijving Occ Type
<idMutatieOproep> Identificatie van het
gerelateerde mutatieverzoek
1-1 String
<resultaat> Resultaat na beoordeling
mutatie-oproep:
“Goedgekeurd” of “Afgekeurd”
1-1 String
<toelichting> Tekstuele toelichting 0-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
<idMutatieverzoek> Identificatie van het
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
<toelichting> Tekstuele toelichting 0-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
<toelichting> Tekstuele toelichting 0-1 String
<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