Functioneel ontwerp Berichtenverkeer StUF-Geo IMGeo voor horizontaal en verticaal koppelvlak
Geonovum
datum 4 april 2013
versie v1.0 status definitief
1
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]
2
Inhoudsopgave 1
2
3
4
Inleiding 1.1 Inleiding 1.1.1 Horizontaal en verticaal berichtenverkeer 1.1.2 Doel 1.2 Leeswijzer Uitgangspunten 2.1 Initiële levering en mutaties 2.2 Verwerking per transactie 2.3 Controle tegen richtlijnen IMBGT/IMGeo 2.4 Controle tegen versie in registratie 2.5 Bevestiging van ontvangst 2.6 Volgorde van verwerking in verticale keten 2.7 Logistieke en functionele identificaties 2.8 Geen berichtverkeer bronhouders onderling Scenario’s horizontaal 3.1 Actoren 3.1.1 Geo 3.1.2 BOR 3.2 Mutatie 3.3 Exploratieverzoek Scenario’s verticaal 4.1 Actoren 4.1.1 Bronhouder 4.1.2 Rakende bronhouder 4.1.3 Samenwerkingsverband van Bronhouders BGT (SVB-BGT) 4.1.4 Landelijke Voorziening BGT (LV-BGT) 4.1.5 Afnemer 4.2 Initiële levering 4.2.1 Aanleveren 4.2.2 Assembleren en goedkeuren 4.2.3 Registreren 4.3 Mutatie 4.3.1 optioneel: Vooraankondiging 4.3.2 Aanleveren 4.3.3 conditioneel: Goedkeuren 4.3.4 Registreren
5 5 5 6 6 7 7 7 8 8 8 9 9 9 10 10 10 10 10 13 15 15 15 15 15 15 15 17 17 19 22 24 24 27 29 30
3
5
Berichten 5.1 Berichtsoorten 5.1.1 Mutatiebericht(mtbDi01) 5.1.2 Mutatierespons (mtbDu01) 5.1.3 Mutatieverzoek(mtvDi01) 5.1.4 weigerbericht (mtvWeigerDu01) 5.1.5 mutatieOproep (mtoDi01) 5.1.6 mutatieOproepRespons (mtoDi01) 5.1.7 Exploratieverzoek (expDi01) 5.1.8 Exploratierespons (expDu01) 5.1.9 Vooraankondigingsverzoek (vavDi01) 5.1.10 VooraankondigingsRepons (vavDu01) 5.1.11 Ophaalverzoek (opvDi01) 5.1.12 Bevestiging van ontvangst (Bv03) 5.2 Gebruik 5.3 Berichteninhoud 5.4 StUF-Stuurgegevens 5.5 Entiteittypen 5.5.1 Mutatiebericht (MTB) 5.5.2 Mutatieverzoek (MTV) 5.5.3 MutatieOproep (MTO) 5.5.4 Weigerbericht (WGB) 5.5.5 Exploratieverzoek (EXP) 5.5.6 Vooraankondiging (VAV) 5.5.7 Ophaalverzoek (OPV) 5.6 Kennisgevingen 5.7 Extra elementen en domeinwaarden 5.7.1
5.7.2 <documentverwijzing> 5.7.3 5.7.4 5.7.5 5.7.6 5.7.7 5.7.8 5.7.9 5.7.10 <mutatieVerzoek> 5.7.11 <muterendeBronhouder> 5.7.12 5.7.13 <sleutelVerzendend> en <sleutelOntvangend> voor 5.7.14 <statusVerwerkingsActie> 5.7.15 5.7.16 Bijlage 1 Overzicht uitgangspunten
31 31 31 31 31 31 31 31 31 31 31 31 32 32 32 33 34 35 35 35 36 36 37 37 38 38 39 39 40 40 40 40 40 40 40 40 40 40 40 40 40 41 41 42
Bijlage 2 Extra objecttypen: en
46
Bijlage 3 Procesplaten SVB
Fout! Bladwijzer niet gedefinieerd.
4
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.
5
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 Berichtenverkeer geoStUF IMGeo
v1.0
juni 2012
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 ICTcomponenten SVB
januari 2013
6
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 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
7
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 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.
8
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.
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.
9
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 IMGeogegevens 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 IMGeoobjecten 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 IMGeoobject 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 Geo 10, 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.
10
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.
11
12
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
13
14
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.
15
Schakels in de verticale BGT keten
16
4.2
Initiële levering
Het proces van initiële levering is onder te verdelen in de volgende stappen: 1. 2. 3.
Aanleveren van initiële leveringen door bronhouders Assembleren en uitleveren resultaat aan bronhouders 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 14 15
Het BGT-voorbereide bestand mag ook objecten uit het optionele deel van IMGeo bevatten. conform Digikoppeling Grote Berichten Initieel: controle of in bestand er geen overlap tussen objecten voorkomt.
17
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
18
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 18
Naadloos: geen gaten en overlap tussen de objecten. conform Digikoppeling Grote Berichten
19
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.
20
21
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.
22
23
4.3
Mutatie
Het proces van mutatie bestaat uit de volgende stappen 1. 2. 3. 4.
optioneel: Vooraankondiging door muterende Bronhouder Aanleveren van een mutatiebericht door muterende Bronhouder conditioneel: Goedkeuren van mutatiebericht door Rakende bronhouder 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
24
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.
25
26
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
27
28
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 mutatieOproep ter goedkeuring aan Rakende bronhouder.
bronhouder
constateert,
stuurt
SVB
een
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
29
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.
30
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.
31
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
O
O
Z/O
Z
mutatieOproep (mtoDu01)
O
O
Z
mutatieOproepRespons (mtoDu01)
Z
Z
O
O
Z
O
O
Z
Z/O
Z/O
Z/O
O
Z/O
Z/O
Z/O
Z/O
mutatieRespons (mtbDu01) mutatieVerzoek (mtvDi01)
O
Z
weigerBericht (mtvWeigerDu01)
Z
O
exploratieVerzoek (expDi01)
O
Z
exploratieRespons (afhDi01)
Z
O
vooraankondigingVerzoek (vrkDi01) vooraankondigingRepons (vrkDu01) ophaalVerzoek (ophDi01) bevestigingOntvangst (Bv03) RBH = Rakende bronhouder BH = Bronhouder
Z/O
Z/O
Z = Zenden O = Ontvangen
32
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 :
ophaalVerzoek (opvDi01)
standaard
OPV-verzoek
bevestigingOntvangst (Bv03)
Standaard StUF-bericht
33
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. Geeft aan om wat voor soort bericht het gaat, bijv. “mtbLVDi01” voor een mutatiebericht van SVB aan LV. De verzender van het bericht. In ieder geval moet hier de organisatie, applicatie en gebruiker van de verzendende organisatie worden opgenomen. De ontvanger van het bericht; ook hier moet de applicatie worden opgenomen, nu van de ontvangende organisatie. 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) Tijdstip waarop het bericht is aangemaakt. 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’. 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.
34
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
Identificatie mutatiebericht
<documentVerwijzing>22
22
Occ
Type
0-1
StUF:sleutel
Tekstuele toelichting
0-1
String
Verwijzing naar documentatie
0-1
String
Identificatie van het gerelateerde mutatieverzoek
0-1
String
van
het
Entiteit-gegevens MTB-respons
Omschrijving
Occ
Type
Identificatie van het gerelateerde mutatiebericht
0-1
String
1-1
Naam van verwerkingsactie
1-1
GML: codelist
<statusLaatsteVerwerkingsActie>
Status van verwerkingsactie
1-1
String
Locatie (URL) verwerkingsverslag
0-1
URL
Tekstuele toelichting
0-1
String
Datum van registreren objecten mutatiebericht in LV
0-1
dateTime
van
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
Identificatie mutatieverzoek
1-1
StUF:sleutel
<documentVerwijzing>22
Tekstuele toelichting
0-1
String
Verwijzing naar documentatie
0-1
String
23
Identificatie van het gerelateerde mutatiebericht
0-1
String
Entiteit-gegevens MTV-respons
Omschrijving
Occ
Type
Identificatie van het gerelateerde mutatieverzoek
0-1
String
Tekstuele toelichting
0-1
String
van
het
22 23
Alleen horizontaal Alleen verticaal
35
5.5.3 MutatieOproep (MTO) Entiteittype MutatieOproep voorziet in een functionele identificatie van en respons op de mutatie-oproep. Entiteit-gegevens MTO-verzoek
Omschrijving
Identificatie mutatieOproep
Occ
Type
1-1
StUF:sleutel
24
Tekstuele toelichting
0-1
String
Identificatie van het gerelateerde mutatiebericht
0-1
String
Entiteit-gegevens MTO-respons
Omschrijving
Occ
Type
Identificatie van het gerelateerde mutatieverzoek
1-1
String
Resultaat na beoordeling mutatie-oproep: “Goedgekeurd” of “Afgekeurd”
1-1
String
Tekstuele toelichting
0-1
String
van
de
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
Identificatie van mutatieverzoek
het
24
Type
1-1 1-1
StUF:Sleutel
1-1
IMGeo-identificatie van het afgekeurde object
1-1
IMGeo:NEN3610
BOR-identificatie van afgekeurde object
1-1
String
Tekstuele toelichting
0-1
String
<documentVerwijzing>
Verwijzing documentatie
0-1
String
het
naar
Alleen verticaal
36
5.5.5 Exploratieverzoek (EXP) Entiteittype Exploratieverzoek voorziet exploratieverzoek.
in
een
functionele
identificatie
van
en
respons
Entiteit-gegevens EXP-verzoek
Omschrijving
Occ
Type
Identificatie exploratieverzoek
van
1-1
StUF:Sleutel
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
Tekstuele toelichting
0-1
string
<documentVerwijziging>
Verwijzing naar documentatie
0-1
string
Entiteit-gegevens EXP-Respons
Omschrijving
Occ
Type
Identificatie van gerelateerde exploratieverzoek
1-1
StUF:Sleutel
Tekstuele toelichting
0-1
String
<documentVerwijzing>
Tekstuele toelichting
0-1
String
5.5.6 Vooraankondiging (VAV) Entiteittype Vooraankondiging voorziet vooraankondigingsVerzoek.
in
een
functionele
Entiteit-gegevens VAV-verzoek
Omschrijving
Identificatie vooraankondiginsverzoek
Buitencontour van muteren gebied
<muterendeBronhouder>
Identificatie bronhouder
van
identificatie
van
en respons
Occ
Type
van
1-1
StUF:Sleutel
te
1-1
GML:Surface
muterende
1-1
String
het
Entiteit-gegevens VAV-respons
Omschrijving
Occ
Type
Identificatie van gerelateerde vooraankondiginsverzoek
1-1
String
op
een
1-1 Resultaat vooraankondigingsverzoek
op
het
1-1
op
1-1
String: {afgekeurd, goedgekeurd}
0..* Identificatie van IMGeo-object
1-1
IMGeo:NEN3610
37
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
Identificatie ophaalverzoek
<stuurgegevens>
Stuurgegevens van op te halen bericht
van
Occ
Type
1-1
StUF:Sleutel StUF:Stuurgegevens
1-1
1-*
Begin- en vervaldatum
Bestandnaam checksum
Locatie (URL)
en
1-1
Zie DGB
1-1
Zie DGB
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 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
38
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 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
39
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 Punt, lijn of vlakgeometrie (GML-geometrie); voor vooraankondigingsverzoek: alleen GML:Surface. 5.7.4 Uniek referentienummer (identificatie) welke wordt toegekend aan een exploratieverzoek. 5.7.5 Identificerend nummer van mutatiebericht. 5.7.6 Identificerend nummer van mutatieverzoek. 5.7.7 Identificerend nummer van een vooraankondigingsverzoek 5.7.8 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 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 na beoordeling van een mutatieverzoek of vooraankondigingsverzoek. 5.7.13 <sleutelVerzendend> en <sleutelOntvangend> voor Deze gegevens worden als optioneel attribuut aan toegevoegd, conform StUF. 5.7.14 <statusVerwerkingsActie> Status van de laatste verwerkingsActie.
40
Domein: succes (S), fout (F), in uitvoering (U) of niet uitgevoerd (N). 5.7.15 Begeleidende vrije tekst. Domein: text(500). 5.7.16 Locatie (URL) vanaf waar een verwerkingsverslag gedownload kan worden. Domein: varchar(300).
41
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 en van het bericht. In de stuurgegevens kunnen voor de volgende adresgegevens worden opgenomen: , , en . Minimaal moeten dan de volgende gegevens worden opgenomen: , en . 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.
42
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 .
43
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 . 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 . Algemeen: Mutatiebericht Een mutatiebericht heeft .
altijd
waarde
“V”
(verplichte
overname)
voor
element
Algemeen: Weigerbericht Een weigerbericht heeft waarde “NietDoorgevoerdeWijziging” voor het element 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.
44
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 wordt niet uitgewisseld tussen Geo- en BOR-applicatie. De wijziging van attribuut 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
45
Bijlage 2 Extra objecttypen: en
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
46
Openbare verlichting Warmtenet Datatransport
Telecom CAI Verkeersregeling Gladheidsmeldingen (GMS) Tellingen
Gevaarlijke inhoud
Petro Chemie
Wees Overig
47
Leidingelement
TypeLeidingelement Mof Verloopstuk T-stuk Verdeelstuk Afsluiter Kraan Put (ondergronds) Tappunt Ontluchter Inlaat Aansluitpunt Uitlaat/lozingswerk Rioolvoorziening
48