Functioneel ontwerp Berichtenverkeer StUF-Geo IMGeo voor horizontaal en verticaal koppelvlak

Transcriptie

1 Functioneel ontwerp Berichtenverkeer StUF-Geo IMGeo voor horizontaal en verticaal koppelvlak Geonovum datum 4 april 2013 versie v1.0 status definitief 1

2 Colofon Auteurs: Beheer: Arnoud de Boer Geonovum BGT-programma Ministerie van Infrastructuur en Milieu Portefeuille Ruimte Directie Nationale Ruimtelijke Ordening Beleid GEO informatie/bgt Rijnstraat 8 Postbus EZ Den Haag Interne postcode postbus.bgt@minvrom.nl 2

3 Inhoudsopgave 1 Inleiding Inleiding Horizontaal en verticaal berichtenverkeer Doel Leeswijzer 6 2 Uitgangspunten Initiële levering en mutaties Verwerking per transactie Controle tegen richtlijnen IMBGT/IMGeo Controle tegen versie in registratie Bevestiging van ontvangst Volgorde van verwerking in verticale keten Logistieke en functionele identificaties Geen berichtverkeer bronhouders onderling 9 3 Scenario s horizontaal Actoren Geo BOR Mutatie Exploratieverzoek 13 4 Scenario s verticaal Actoren Bronhouder Rakende bronhouder Samenwerkingsverband van Bronhouders BGT (SVB-BGT) Landelijke Voorziening BGT (LV-BGT) Afnemer Initiële levering Aanleveren Assembleren en goedkeuren Registreren Mutatie optioneel: Vooraankondiging Aanleveren conditioneel: Goedkeuren Registreren 30 3

4 5 Berichten Berichtsoorten Mutatiebericht(mtbDi01) Mutatierespons (mtbdu01) Mutatieverzoek(mtvDi01) weigerbericht (mtvweigerdu01) mutatieoproep (mtodi01) mutatieoproeprespons (mtodi01) Exploratieverzoek (expdi01) Exploratierespons (expdu01) Vooraankondigingsverzoek (vavdi01) VooraankondigingsRepons (vavdu01) Ophaalverzoek (opvdi01) Bevestiging van ontvangst (Bv03) Gebruik Berichteninhoud StUF-Stuurgegevens Entiteittypen Mutatiebericht (MTB) Mutatieverzoek (MTV) MutatieOproep (MTO) Weigerbericht (WGB) Exploratieverzoek (EXP) Vooraankondiging (VAV) Ophaalverzoek (OPV) Kennisgevingen Extra elementen en domeinwaarden <beheerder> <documentverwijzing> <geometrie> <idexploratieverzoek> <idmutatiebericht> <idmutatieverzoek> <idvooraankondiging> <laatsteverwerkingsactie> <lv-publicatiedatum> <mutatieverzoek> <muterendebronhouder> <resultaat> <sleutelverzendend> en <sleutelontvangend> voor <object> <statusverwerkingsactie> <toelichting> <verslagverwerkingurl> Bijlage 1 Overzicht uitgangspunten Bijlage 2 Extra objecttypen: <Leiding> en <Leidingelement> 46 Bijlage 3 Procesplaten SVB Fout! Bladwijzer niet gedefinieerd. 4

5 Hoofdstuk 1 Inleiding Dit hoofdstuk geeft een inleiding op het horizontale en verticale berichtenverkeer. 1.1 Inleiding 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 BOR 1 -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

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 In Gebruik 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

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 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 voorkomen 2. 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 7

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-BGT 4 ) 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-BGT 5 ) 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 overgeslagen 6, 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 vooraankondiging 7 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

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. 9

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 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 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 wijziging 8 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 BOR 9 ) 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

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. 11

12 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 exploratieverzoek 11, 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 exploratierespons 12 afmelden bij BOR. 11 In FO Geo-BOR: redlinverzoek 12 in FO Geo-BOR: afhandelingsbericht 13

14 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 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 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 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 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 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

16 Schakels in de verticale BGT keten 16

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 Aanleveren Op het moment dat Bronhouder een BGT 13 -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 ophaalverzoek 14 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 topologie 15. 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 wacht 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. 17

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 18

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 naadloos 17 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 ophaalverzoek 18. 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 19

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. 20

21 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. 22

23 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 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 ophaalverzoek 19. 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

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. 25

26 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 ophaalverzoek 20. 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 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 ophaalverzoek 21. 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

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 Registreren in LV. 30

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 Mutatiebericht(mtbDi01) Asynchroon vrij bericht voor de aanlevering van mutaties op één of meer IMGeo-objecten Mutatierespons (mtbdu01) Asynchroon vrij bericht als respons op een mutatiebericht met daarin het resultaat van de functionele controle Mutatieverzoek(mtvDi01) Asynchroon vrij bericht met het verzoek om een mutatie op aangeleverde objecten door te voeren in de registratie van het ontvangende systeem 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 mutatieoproep (mtodi01) Asynchroon vrij bericht met de oproep om een mutatie op objecten door te voeren in de registratie van het ontvangende systeem 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 Exploratieverzoek (expdi01) Asynchroon vrij bericht met een verzoek om verkennend onderzoek uit te voeren in een bepaald gebied Exploratierespons (expdu01) Asynchroon vrij bericht als respons op een exploratieverzoek met de kennisgeving van de afhandeling van het exploratieverzoek Vooraankondigingsverzoek (vavdi01) Asynchroon vrij bericht met het verzoek om 1 of meer IMGeo-objecten te reserveren ( locken ) voor mutatie door zendende systeem VooraankondigingsRepons (vavdu01) Asynchroon vrij bericht als respons op een vooraankondiging met daarin het resultaat van de reservering/locking. 31

32 Ophaalverzoek (opvdi01) Asynchroon vrij bericht met het verzoek om een bericht of bestand op te halen vanaf locatie (URL) van zendende systeem 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 32

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 33

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. 34

35 5.5 Entiteittypen 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 0-1 StUF:sleutel mutatiebericht <toelichting> Tekstuele toelichting 0-1 String <documentverwijzing> 22 Verwijzing naar documentatie 0-1 String <idmutatieverzoek> 22 Identificatie van het 0-1 String gerelateerde mutatieverzoek Entiteit-gegevens MTB-respons Omschrijving Occ Type <idmutatiebericht> Identificatie van het 0-1 String gerelateerde mutatiebericht <respons> 1-1 <laatsteverwerkingsactie> Naam van verwerkingsactie 1-1 GML: codelist <statuslaatsteverwerkingsactie> Status van verwerkingsactie 1-1 String <urlverwerkingsverslag> Locatie (URL) van 0-1 URL verwerkingsverslag <toelichting> Tekstuele toelichting 0-1 String <LV-publicatiedatum> Datum van registreren 0-1 datetime objecten mutatiebericht in LV 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 1-1 StUF:sleutel mutatieverzoek <toelichting> Tekstuele toelichting 0-1 String <documentverwijzing> 22 Verwijzing naar documentatie 0-1 String <idmutatiebericht> 23 Identificatie van het 0-1 String gerelateerde mutatiebericht Entiteit-gegevens MTV-respons Omschrijving Occ Type <idmutatieverzoek> Identificatie van het 0-1 String gerelateerde mutatieverzoek <respons> <toelichting> Tekstuele toelichting 0-1 String 22 Alleen horizontaal 23 Alleen verticaal 35

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 1-1 StUF:sleutel mutatieoproep <toelichting> Tekstuele toelichting 0-1 String <idmutatiebericht> 24 Identificatie van het 0-1 String gerelateerde mutatiebericht Entiteit-gegevens MTO-respons Omschrijving Occ Type <idmutatieoproep> Identificatie van het 1-1 String gerelateerde mutatieverzoek <resultaat> Resultaat na beoordeling 1-1 String mutatie-oproep: Goedgekeurd of Afgekeurd <toelichting> Tekstuele toelichting 0-1 String 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 1-1 StUF:Sleutel mutatieverzoek <afgekeurdobject> 1-1 <idimgeo> IMGeo-identificatie van het 1-1 IMGeo:NEN3610 afgekeurde object <idbor> BOR-identificatie van het 1-1 String afgekeurde object <toelichting> Tekstuele toelichting 0-1 String <documentverwijzing> Verwijzing naar 0-1 String documentatie 24 Alleen verticaal 36

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 1-1 StUF:Sleutel exploratieverzoek <geometrie> Locatiemarkering van het te 1-1 Geometrie t.w. verkennend onderzoeken GML:Point, of gebied d.m.v. punt, lijn of vlakgeometrie 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 1-1 StUF:Sleutel exploratieverzoek <respons> 1-1 <toelichting> Tekstuele toelichting 0-1 String <documentverwijzing> Tekstuele toelichting 0-1 String 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 1-1 StUF:Sleutel vooraankondiginsverzoek <geometrie> Buitencontour van het te 1-1 GML:Surface muteren gebied <muterendebronhouder> Identificatie van muterende 1-1 String bronhouder Entiteit-gegevens VAV-respons Omschrijving Occ Type <idvooraankondiging> Identificatie van gerelateerde 1-1 String vooraankondiginsverzoek <respons> 1-1 <resultaat> Resultaat op 1-1 String: vooraankondigingsverzoek {afgekeurd, goedgekeurd} <nietgelocktobject> 0..* <idimgeo> Identificatie van IMGeo-object 1-1 IMGeo:NEN

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 1-1 StUF:Sleutel ophaalverzoek <stuurgegevens> Stuurgegevens van op te StUF:Stuurgegevens halen bericht <gb:digikoppeling> 1-1 <data-reference> 1-* <lifetime> Begin- en vervaldatum 1-1 Zie DGB <content> Bestandnaam en 1-1 Zie DGB checksum <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 bak begroeid terreindeel bord buurt functioneel gebied gebouwinstallatie installatie kast kunstwerkdeel mast onbegroeid terreindeel ondersteunend waterdeel ondersteunend wegdeel ongeclassificeerd object openbare ruimte openbare ruimte label overbruggingsdeel overig bouwwerk overige scheiding paal Afkorting BAK BTD BRD BRT FUG GBI INS KST KWD MST OTD OWT OWG OCO OPR ORL OBD OBW OSH PAL 38

39 Naam objecttype pand plaatsbepalingspunt put scheiding sensor spoor stadsdeel straatmeubilair tunneldeel vegetatieobject waterdeel waterinrichtingselement waterschap wegdeel weginrichtingselement wijk Afkorting PND PBP PUT SHD SNS SPR STD STM TND VGO WTD WTI WSP WGD WGI 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) <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 39

40 Het hoeft geen multi-attribuut te zijn, maar het is eenvoudiger een permutatie van meerdere domeinwaarden toe te staan in één attribuutveld <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 <geometrie> Punt, lijn of vlakgeometrie (GML-geometrie); voor vooraankondigingsverzoek: alleen GML:Surface <idexploratieverzoek> Uniek referentienummer (identificatie) welke wordt toegekend aan een exploratieverzoek <idmutatiebericht> Identificerend nummer van mutatiebericht <idmutatieverzoek> Identificerend nummer van mutatieverzoek <idvooraankondiging> Identificerend nummer van een vooraankondigingsverzoek <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) <lv-publicatiedatum> Datum en tijdstip waarop objecten in Centrale Registratie LV zijn geregistreerd <mutatieverzoek> Entiteittype t.b.v. (respons op) mutatieverzoek <muterendebronhouder> Identificatie van de Bronhouder die een vooraankondiging indient <resultaat> Resultaat na beoordeling van een mutatieverzoek of vooraankondigingsverzoek <sleutelverzendend> en <sleutelontvangend> voor <object> Deze gegevens worden als optioneel attribuut aan <object> toegevoegd, conform StUF <statusverwerkingsactie> Status van de laatste verwerkingsactie. 40