Informatiemodel Omgevingswet (IMOW) 3.2-rc

Wanneer het bevoegd gezag een Regeling vaststelt of wijzigt gebeurt dit via een besluit dat het bevoegd gezag digitaal aan de Landelijke Voorziening Bekendmaken en Beschikbaar stellen (LVBB) aan moet leveren. Het IMOW is onderdeel van de standaard die regels voor een aanlevering vastlegt. Hieronder staat een lijst met documenten en opmerkingen die relevant zijn vanuit het perspectief van IMOW:

• Een aanlevering heeft het formaat van een ZIP-bestand dat je aanbiedt aan de LVBB. Het LVBB bronhouderkoppelvlak [LVBBBHKV13] schrijft de structuur van het ZIP-bestand voor.
• De Standaard Officiële Publicaties (STOP) legt de documentstructuur van de tekst van het besluit en regeling van de aanlevering vast. Ook legt STOP metadata voor de verwerking van het besluit vast en beschrijft STOP hoe geografische informatieobjecten (GIO's) moeten worden aangeleverd.
• De IMOW.xsd's leggen het XML-formaat vast waarmee de OW-objecten moeten worden uitgewisseld.
• Toepassingsprofielen omgevingsdocumenten (TPOD’s). Een TPOD legt voor een type omgevingsdocument vast welke van de mogelijkheden van STOP en IMOW moeten c.q. mogen worden gebruikt en op welke wijze. Er zijn toepassingsprofielen voor onder meer het omgevingsplan, de omgevingsverordening, de omgevingsvisie en het projectbesluit.
• De validatiematrix beschrijft regels waaraan aanleveringen dienen te voldoen. Dit document is zelf geen standaard maar is een opsomming van regels die in de standaarden beschreven staan. Op veel van de regels in de validatiematrix gebeurt een automatische controle, zodat een aanlevering die niet aan de regels voldoet wordt afgekeurd. Echter, automatische controle is niet altijd mogelijk of geïmplementeerd. In die gevallen is het de verantwoordelijkheid van het bevoegd gezag om aan de regel te voldoen.
• Het Conceptuele Model Omgevingswet [CIMOW] en het Conceptuele Model Officiële Publicaties [CIMOP] leggen de conceptuele basis voor het IMOW.
• Waardelijsten geven aan wat de toegestane waardes zijn bij attributen van IMOW die aan een waardelijst gekoppeld zijn. Waardelijsten worden in de Stelselcatalogus gepubliceerd.
• Het IMOW maakt gebruik van de [NEN3610_2022] standaard.
• Voorbeeldbestanden van correcte aanleveringen geven inzicht hoe STOP en IMOW technisch toegepast kunnen worden om een nieuw omgevingsdocument aan te leveren.

Het toepassingsgebied van IMOW is het machineleesbaar maken van teksten en locaties van regelingen binnen de Omgevingswet.

Het IMOW schrijft voor hoe je de tekst van een Regeling (zoals beschreven in STOP) machineleesbaar kunt maken door de tekst te verrijken met annotaties in de vorm van een collectie OW-objecten en hoe je die kunt toevoegen aan een aanlevering. De annotaties representeren de kern van de juridische inhoud van de regel of beleidstekst. Door het annoteren kan een viewer locaties en andere gegevens op een kaart en bij een tekst weergeven. Het annoteren zorgt er ook voor dat een omgevingsdocument op bepaalde kenmerken doorzoekbaar is. In het geval van omgevingsdocumenten met artikelstructuur waarin regels over activiteiten worden gesteld, helpt het annoteren ook bij het verbinden van toepasbare regels, oftewel vragenbomen, aan regels met locaties. Activiteiten spelen een belangrijke rol in het DSO en deze worden verrijkt met duiding op de kaart, de naam van de activiteit en de activiteitregelkwalificatie. Ook gebieden worden geduid. De gegevens die aangeleverd worden vanuit het IMOW helpen de buitenwereld met het op een kaart terugvinden van Omgevingswet-informatie.

Deze OW-objecten worden tegelijk met een Besluit aan de LVBB aangeleverd. De koppeling gebeurt door OW-objecten te laten verwijzen naar onderdelen van de STOP tekst via de identificatie van die onderdelen, het wId. OW-objecten zelf kunnen weer gekoppeld zijn aan andere OW-objecten waardoor er naast de tekst ook een gestructureerde collectie objecten bij een regeling ontstaat. Deze structuur kan bijvoorbeeld gebruikt worden om de inhoud van de regeling via een kaart te ontsluiten.

STOP beschrijft twee soorten tekststructuren voor omgevingsdocumenten: de artikelstructuur en de vrijetekststructuur. De artikelstructuur moet worden gebruikt voor regelingen die zijn opgebouwd uit één of meer artikelen die regels bevatten. De vrijetekststructuur wordt gebruikt voor regelingen met een vrijere opzet waarin geen artikelen en regels voorkomen. Per tekststructuur is een set OW-objecten beschikbaar. Voor beide typen tekststructuren is een diagram toegevoegd met hierin de toegelaten objecttypen, attributen en relaties.

De volgende begrippen worden gebruikt in dit document:

Besluit: Een tekst die de vaststelling of wijziging van (de geldigheid van) een regeling of informatieobject beschrijft. Met andere woorden: Een besluit beschrijft precies hoe een BG een nieuwe regeling vaststelt, wijzigingen op een regeling doorvoert of de inwerkingtreding van een regeling of regelingversie bepaalt. (bron: [STOP])

Bronhouderkoppelvlak: Het bronhouderkoppelvlak (BHKV) is een technische voorziening tussen de LVBB en (software van) een bevoegd gezag. In dat koppelvlak worden technische en inhoudelijke standaarden toegepast, waardoor inhoudelijke, proces- of foutinformatie tussen de systemen kan worden uitgewisseld. (bron: [STOP])

GIO: Geografisch Informatie Object (bron: [STOP])

LVBB: Landelijke Voorziening Bekendmaken en Beschikbaar stellen.

Regeling: De regeling van een omgevingsdocument bevat de volledige set regels of beleidsteksten die gelden in de fysieke leefomgeving, dan wel de beschrijving van wat er wordt gerealiseerd in de fysieke leefomgeving.

De volgende uitgangspunten zijn gehanteerd bij het opstellen van het IMOW:

• Conformiteit met Metamodel voor informatiemodellering, MIM 1.2 [MIM12].
• Het IMOW is opgesteld als een UML model uitgedrukt in klassediagrammen. Voor algemene uitleg over UML klassediagram zie wikipedia: UML klassediagram.
• Het model is een implementatie van het CIM-OW waarbij bij implementatie niet altijd gekozen is voor de structurering zoals beschreven in het CIM-OW [CIMOW].

In hoofdstuk 2 van het IMOW staan de gegevensdefinities. Dit hoofdstuk bevat UML diagrammen waarin de objecttypen beschreven zijn. In de diagrammen zijn de objecttypen aan te klikken en wordt er gelinkt naar de definitie en attributen van dat objecttype in de objectcatalogus. De in de catalogus benoemde metagegevens zoals bijvoorbeeld Naam, Definitie, Indicatie abstract object zijn termen uit het Metamodel Informatiemodellering [MIM12]. Door te klikken op de attribuutnaam kom je bij de definitie van dat attribuut met enkele metagegevens van dat attribuut volgens MIM.

Noot: De kenmerken 'Indicatie materiële historie' en 'Mogelijk geen waarde' die in de catalogus vermeld staan zijn defaultwaarden uit het MIM. Ze worden automatisch toegevoegd aan de catalogus, ze hebben echter geen betekenis in het IMOW.

In hoofdstuk 2 zijn de UML diagrammen van het IMOW opgenomen. Er is een onderverdeling naar verschillende domeinen gemaakt:

• Aanlevering
• OW-object
• Artikelstructuur
• Vrijetekststructuur
• Locatie
• Kaart

Dit document is als volgt opgebouwd: hoofdstuk 2 bevat de gegevensdefinities van OW-objecten. Hoofdstuk 3 bevat een overzicht van de gebruikte waardelijsten. Hoofdstuk 4 beschrijft hoe het IMOW technisch geïmplementeerd moet worden en gaat gedetailleerd in op hoe de OW-bestanden er uit dienen te zien en geeft een XML-beschrijving van de aan te leveren bestanden. Hoofdstuk 5 schrijft voor hoe een OW-aanlevering bij het bronhouderkoppelvlak van de LVBB moet worden aangeleverd. Hoofdstuk 6 beschrijft enkele aspecten uit STOP die relevant zijn voor het IMOW. Bijlage A bevat de versiegeschiedenis van dit document. Bijlage B bevat de referenties.

Een aanlevering aan de LVBB bevat altijd een OW-manifest. Dit is het bestand met de naam naam manifest-ow.xml. Daarnaast bevat de OW-aanlevering 0 of meer bestanden met OW-objecten, deze zijn opgesomd in het OW-manifest. Het OW-manifest bevat niet de opsomming van de GML-bestanden; deze staan in het (OP-)manifest.

Constraint: Het manifest-ow.xml in een OW-aanlevering moet voldoen aan het xml-schema in bestanden-ow/generiek/manifest-ow.xsd. (TPOD1162)

Constraint: Het xml-attribuut schemaversie in het root element van het manifest-ow.xml bestand bevat het versienummer van het gebruikte xsd. (TPOD1160)

Zie paragraaf 2.1 voor een uitleg van de XML elementen in deze bestanden.

Bij het aanleveren gelden regels over de volgende aspecten:

• Identificatie van objecten
• Waardelijsten
• Toekennen van OW-objecten aan regeling
• Verwijzen tussen verschillende OW-objecten.
• Behoud functionele structuur
• Tijdelijk regelingdelen.

4.2.5 Tophaken en de bovenliggendeActiviteit

De activiteiten in het stelsel vormen samen de ‘functionele structuur’. Deze boomstructuur bevat alle Activiteit-objecten in de regelingen en de hiërarchie wordt bepaald door de bovenliggendeActiviteit relatie van de OW-Objecten van het type Activiteit. In Figuur 10 is het bovenste deel van functionele structuur getekend. Met Placeholder-Regeling wordt bedoeld de regeling die, met het opschrift Omgevingswet, in het stelsel is ingebracht met uitsluitend het doel om beschikbaar te stellen de bovenste Activiteiten van de functionele structuur zoals ‘Activiteit met gevolgen voor de fysieke leefomgeving’ en ‘Activiteit gereguleerd in het omgevingsplan’, de Activiteiten die zijn genoemd in artikel 5.1 Ow en enkele Activiteiten van de AMvB’s en de Omgevingsregeling. De regels in deze paragaaf zorgen ervoor dat de hiërarchie van de functionele structuur behouden blijft bij wijzigingen.

De volgende regel schrijft de naam en aanwezigheid van een tophaak Activiteit in regelingen voor:

Constraint: (TPOD1951) Met uitzondering van AMvB en ministeriële regeling moet in iedere Regeling waarin één of meer Activiteiten zijn geannoteerd één zogenaamde tophaak voorkomen:

• voor de omgevingsverordening is dat de meest bovenliggende Activiteit van die Regeling; de naam van deze Activiteit moet zijn ‘Activiteit gereguleerd in de omgevingsverordening <naam provincie>’;
• voor de waterschapsverordening is dat de meest bovenliggende Activiteit van die Regeling; de naam van deze Activiteit moet zijn ‘Activiteit gereguleerd in de waterschapsverordening <naam waterschap>’;
• voor het omgevingsplan is dat de meest bovenliggende Activiteit van die Regeling; de naam van deze Activiteit moet zijn ‘Activiteit gereguleerd in het omgevingsplan gemeente <naam gemeente>’.

Voor de relatie bovenliggendeActiviteit moet gelden de volgende regels:

Constraint: Voor omgevingsverordening, waterschapsverordening en omgevingsplan geldt, in afwijking van het bepaalde in regel TPOD1950, dat de relatie bovenliggendeActiviteit van een Activiteit niet zijnde de tophaak uitsluitend mag verwijzen naar een andere Activiteit die hoort bij dezelfde Regeling. (TPOD1952)

Constraint: (TPOD1953) Voor de relatie bovenliggendeActiviteit van de tophaken geldt, in afwijking van het bepaalde in paragraaf TPOD1950, het volgende:

• in de omgevingsverordening moet de relatie bovenliggendeActiviteit van de tophaak verwijzen naar de 'Activiteit gereguleerd in de omgevingsverordening' in de Placeholder-Regeling;
• in de waterschapsverordening moet de relatie bovenliggendeActiviteit van de tophaak moet verwijzen naar de 'Activiteit gereguleerd in de waterschapsverordening' in de Placeholder-Regeling;
• in het omgevingsplan moet de relatie bovenliggendeActiviteit van de tophaak moet verwijzen naar de 'Activiteit gereguleerd in het omgevingsplan' in de Placeholder-Regeling;
• in AMvB en ministeriële regeling mag de relatie bovenliggendeActiviteit van een Activiteit uitsluitend verwijzen naar de ‘Activiteit gereguleerd bij AMvB’ of naar een andere Activiteit die hoort bij de Placeholder-Regeling, bij een AMvB of bij een ministeriële regeling.

In [STOP] zijn vier soorten van aanleveringen die kunnen resulteren in een nieuwe regelingversie. Dit zijn: besluit, revisie, rectificatie en mededeling. In alle gevallen waarin deze aanlevering resulteert in een nieuwe regelingversie is aan die aanlevering een OW-aanlevering gekoppeld die zorgt voor de OW-objecten behorend bij de nieuwe regelingversie.

Bij het specificeren van het bronhouderkoppelvlak van de LVBB zal aan iedere wijziging van een regeling een OW-aanlevering gekoppeld worden.

Wanneer bijvoorbeeld in STOP samenloop van twee besluiten wordt opgelost door het aanleveren van een revisie die de mutaties van beide besluiten verwerkt is er aan die aanlevering een OW-aanlevering gekoppeld die zorgt voor de mutaties van de OW-objecten van beide besluiten.

Het aanmaken of wijzigen van de collectie OW-objecten behorend bij een Regeling gebeurt met een OW-aanlevering. De OW-aanlevering bevat wijziginstructies die beschrijven hoe de oorspronkelijke collectie OW-objecten getransformeerd moet worden tot de resultaatcollectie. Een OW-aanlevering is gekoppeld aan een OP-aanlevering waarbij het STOP-deel de tekst van de regeling en of de bijbehorende GIO's wijzigt en de OW-aanlevering de bij de regeling behorende OW-objecten wijzigt. Een initieel besluit is een speciaal geval omdat deze een Regeling aanmaakt en niet wijzigt, de bijbehorende OW-aanlevering zal dus ook alleen OW-objecten aanmaken. Ook als bij een STOP wijziging geen OW-objecten worden gewijzigd moet een OW-aanlevering gedaan te worden.

Een OW-aanlevering heeft zelf de vorm van een collectie OW-objecten. De aanlevering van een OW-object resulteert in (1) een nieuw OW-object, (2) een gewijzigd OW-object of (3) een beëindigd OW-object. Deze drie situaties zijn in de volgende paragrafen beschreven:

Als een OP-aanlevering een regeling instelt, wijzigt of intrekt moet daaraan een OW-aanlevering gekoppeld zijn om de OW-objecten behorend bij die regeling te maken, wijzigen of beëindigen. Het IMOW volgt de verschillende typen OP-aanlevering en legt alleen vast hoe je aan de OP-aanlevering een OW-aanlevering kunt koppelen die de wijzigingen van OW-objecten regelt.

In de volgende paragrafen is voor de verschillende typen OP-aanleveringen beschreven hoe dat gaat.

In het STOP-deel van de aanlevering wordt ConsolidatieInformatie meegeleverd. De ConsolidatieInformatie bepaalt de tijdlijn van de regelingen en informatieobjecten die ontstaan uit een Besluit. Diezelfde tijdlijn geldt voor alle OW-objecten in de aanlevering

Figuur 11 toont de klasse 'Consolidatie-informatie' van het CIM-OP. Deze bevat de informatie die noodzakelijk is om de aanlevering te consolideren tot een Regeling. Voor IMOW zijn de volgende aspecten van belang:

• De klasse 'Beoogde regeling' bevat de identificatie van de te wijzigen Regeling. Deze identificatie en workIDRegeling in de OW-aanlevering moeten overeenkomen.
• De relatie 'doel' verwijst naar het doelId in de OW-aanlevering.
• Uit de klasse 'Tijdstempel' worden de geldigheidsgegevens van de OW-objecten afgeleid.

Bij het aanleveren van een besluit volgens STOP worden geografische objecten aangeleverd als GIO’s (geografische informatieobjecten). Dit is één van de twee soorten informatieobjecten die in STOP kunnen worden meegeleverd (de andere zijn PDF-documenten). Figuur 12 bevat het UML diagram van de 'GIO versie' uit het CIM-OP. Voor IMOW zijn de volgende aspecten van belang:

• Een 'GIO vaststelling' stelt een versie van een GIO vast. Hierin heeft iedere Geometrie een id attribuut in de vorm van een UUID. Wanneer in IMOW middels GeometrieRef naar een Geometrie wordt verwezen wordt deze UUID gebruikt.
• Sommige GIO's bevatten informatie over normen.
• Een 'GIO vaststelling' bevat 'Geografische context' die informatie bevat over de context ten opzichte waarvan het GIO is vastgesteld.
• FRBRWork en FRBRExpression bevatten de identificatie van het GIO.
• Een GIO bevat één of meer Locatie objecten. Deze Locaties komen niet overeen met OW-Locatie. Ook de naam van de locatie is niet rechtstreeks gekoppeld.
• Wanneer in aanlevering van GIO's meerdere keren exact dezelfde geometrie wordt gebruikt kan je in beide gevallen dezelfde UUID gebruiken. Het DSO zorgt er dan voor de geometrie slechts één keer wordt doorgeleverd.
• Indien er gebruik gemaakt wordt van GIO-delen, dan dient ieder GIO-deel een symbolisatie te hebben (dit wordt vastgelegd in het vaststellingsdeel).
• Bij Norm-GIO's dienen aanvullende gegevens vastgelegd te worden.

Indien er normen vastgelegd worden aan de OW-kant, dan bevat het GIO 'Norm informatie' en de Locaties van het GIO bevatten een 'Normwaarde'. Hiervoor geldt:

• Bij een kwantitatieve normwaarde bevat 'Eenheid ID' de eenheid van de normwaarde. Hier moet een URI ingevuld worden uit de waardelijst ‘Eenheid’.
• 'Eenheid label' bevat dan het label dat getoond dient te worden bij de eenheid.
• 'Norm ID': De URI uit de IMOW-waardelijst 'TypeNorm'.
• De naam van de Norm aan de OW-kant.
• De attributen 'Kwalitatief' en 'Kwantitatief' moeten overeenkomen met de gelijknamige kenmerken in OW.
• Hoewel de Geometrie gedeeld wordt tussen STOP en OW-objecten geldt dit niet voor de norm-gegevens. Deze worden dus twee keer uitgewisseld maar moeten wel met elkaar overeenkomen.
• Het is toegestaan om een geometrie die gebruikt wordt voor een Norm ook te gebruiken bij andere OW-objecten.
• Iedere normwaarde dient een symbolisatie te hebben, dit wordt vastgelegd in het vaststellingsdeel van het GIO.

GIO's en OW-objecten worden in verschillende (bijna afzonderdelijke) modellen aangeleverd. In veel gevallen is het wenselijk te weten hoe de GIO's en de OW-objecten aan elkaar gerelateerd zijn. Hiervoor kan JuridischeBorgingVan element bij een GIO gebrukt worden.

De volgende regels leggen vast hoe het STOP element JuridischeBorgingVan in de context an IMOW gebruikt moet worden:

Constraint: Het veld JuridischBorgingVan behorend bij een GIO heeft maximaal één kenmerk JuridischeBorgVan met domein = http://www.geostandaarden.nl/imow/. De waarde van domeinObjectID in dit kenmerk is de idenficatie van een actief OW-object behorend bij de Regeling die de betreffende GIO als geboorteregeling heeft en die geometrisch exact overeenkomt. (TPOD2600)

Constraint: De geometrische afbakening van de GIO en van het juridisch geborgde OW-object komen overeen. (TPOD2601)

Constraint: Een OW-object heeft maximaal 1 GIO die daarnaar verwijst. (TPOD2602)

Een verwijzing met een GIO gebeurt op het niveau waar de juridische context om vraagt. Dit is vaak op het 'hoogste' niveau:

Constraint: Als er verschillende OW-objecten zijn die geometrisch equivalent zijn met de GIO dan verwijst JuridischeBorgingVan in volgorde van vookeur naar: Norm, Gebiedsaanwijzing, ActiviteitLocatieAanduiding, Locatiegroep, Locatie. (TPOD2603)

Het gebruik van JuridischeBorgingVan is essentieel om wijzigmarkeringen van GIO-mutaties te kunnen relateren aan OW-objecten. Hiervoor is de volgende constraint:

Constraint: Bij een GIO met de verschijningsvorm GIO-mutatie moet JuridischeBorgingVan onderdeel zijn van het GIO. (TPOD2604)

Door het gebruik van JuridischeBorgingVan leg je van een aantal OW-objecten vast dat ze 1-1 tegenhanger zijn van een GIO, zodat wijzigmarkeringen van de GIO ook gelden zijn voor die OW-objecten. Met logische regels is het aantal OW-objecten waarvan je weet wat de relatie tot de GIO is uit te breiden:

• ALS je van Gebiedsaanwijzing weet hoe deze zich tot een GIO is verhoudt en die Gebiedsaanwijzing verwijst naar één Locatie DAN geldt diezelfde verhouding ook voor die Locatie.
• ALS je van een Locatiegroep weet hoe deze zich verhoudt tot een GIO is en die Locatiegroep verwijst naar één Locatie DAN geldt diezelfde verhouding ook voor die Locatie.
• ALS je van een ActiviteitLocatieAanduiding weet hoe deze zich verhoudt tot een GIO is en die ActiviteitLocatieAanduiding verwijst naar één Locatie DAN geldt diezelfde verhouding ook voor die Locatie.
• ALS alle locatieaanduidingen van een JuridischeRegel, Normwaarde, Gebiedsaanwijzing of ActiviteitenLocatieaanduiding verwijzen naar Locaties waarvan je weet hoe deze zich tot een GIO verhoudt dan weet je hoe dat betreffende object zich tot een GIO verhoudt.

Met deze regels kan van veel OW-objecten (maar mogelijk niet alle) vastgesteld worden hoe ze zich verhouden tot een GIO waardoor de wijzigmarkeringen van GIO-mutaties behorend bij de GIO mutatie ook als wijzmarkering gelden voor het corresponderende OW-object.

OW Geometrie objecten worden aangeleverd via het GIO in GML. Voor de aangeleverde GML gelden de volgende regels:

• De GML-specificaties volgen de regels van de standaard Basisgeometrie [Basisgeometrie].
• Het bijbehorende GML applicatieschema Basisgeometrie.xsd is gepubliceerd op: https://register.geostandaarden.nl/gmlapplicatieschema/basisgeometrie/1.0.0/
• Voor aanlevering van het GML wordt gebruik gemaakt van GML 3.2.2 met Simple features profile 0.
• Coördinaatreferentiestelsel: Het is verplicht om de srsName in te vullen op het hoogste niveau van een geometrie. Dat betekent dat van een samengestelde geometrie, een multi-geometrie, alleen op het niveau van de samenstelling de srsName verplicht is ingevuld. Invul-instructie:
  • RD stelsel (2D): srsName="urn:ogc:def:crs:EPSG::28992"
  • ETRS89 (2D): srsName="urn:ogc:def:crs:EPSG::4258"
• Voor implementatie in GML zijn er aanvullende specificaties als het gaat om het invullen van een gml:id attribuut. Dit gml:id attribuut heeft geen informatiewaarde maar is nodig om interne en externe referenties te realiseren voor gebruik binnen het gml formaat. Voor de GML 3.2.1 was dit een verplicht element maar voor GML 3.2.2 is dit optioneel. Indien de optionele gml:id wordt toegepast dient deze globaal uniek te zijn en mag de waarde conform de gml specificaties alleen met een letter of een underscore beginnen.
• Coördinaten opgenomen bij een geometrie worden standaard uitgewisseld met een nauwkeurigheid van 1 mm of het equivalent daarvan in graden. Voor RD, NAP en ETRS89 komt dat overeen met de volgende nauwkeurigheden:
  • RD in meters 3 decimalen (1 mm);
  • NAP-hoogte in meters 3 decimalen (1 mm);
  • ETRS89-breedte in graden 8 decimalen (1,1 mm)
  • ETRS89-lengte in graden 8 decimalen (0,7 mm)
  • ETRS89-hoogte in meters 3 decimalen (1 mm)

Het functioneren van de landelijke voorziening wordt gewaarborgd door geometrie die ver buiten Nederland en exclusieve economische zone ligt te weigeren.

Constraint: Alle geometrieën in een omgevingsdocument moeten liggen binnen de geometrie van Nederland met inbegrip van de exclusieve economische zone (EEZ). (TPOD2700)