Informatiemodel Omgevingswet (IMOW)

Geonovum Standaard
Vastgestelde versie

Deze versie:
https://docs.geostandaarden.nl/ow/def-st-InformatiemodelOmgevingswetImow-20211015/
Laatst gepubliceerde versie:
https://docs.geostandaarden.nl/ow/InformatiemodelOmgevingswetImow/
Laatste werkversie:
https://Geonovum.github.io/ow-InformatiemodelOmgevingswetImow
Redacteur:
Gerard Wolbers, Geonovum
Auteur:
Richard de Graaf, Geonovum
Doe mee:
GitHub Geonovum/ow-InformatiemodelOmgevingswetImow
Dien een melding in
Revisiehistorie
Pull requests
Rechtenbeleid:

1. Inleiding

Dit document beschrijft het informatiemodel Omgevingswet (IMOW) dat gebruikt wordt in de keten van plan tot publicatie. Het informatiemodel vormt op zijn beurt een belangrijk onderdeel van de standaard. Het IMOW is gebaseerd op het CIMOW. CIMOW is het conceptuele model waarop informatiemodellen in de ketens van het Digitaal Stelsel Omgevingswet (DSO) gebaseerd worden. IMOW biedt meer context omtrent het implementeren van het CIMOW.

Het IMOW is relevant voor het aanleveren richting het DSO. Het CIMOW is meer gericht op de uitwisseling van gegevens binnen de DSO-keten.

In paragraaf 1.1 wordt een context geboden van de standaard. Vervolgens wordt in paragraaf 1.2 een context geboden van de aanwezige documentatie en waar je wat kunt vinden. In paragraaf 1.3 wordt de verdere inhoud van dit document toegelicht.

1.1 Context standaard

Als je een omgevingsdocument wilt aanleveren dien je bij de aanlevering hiervan deze te conformeren aan de standaard. De standaard bestaat uit twee standaarden, namelijk het informatiemodel Omgevingswet (IMOW) en het informatiemodel officiële publicaties (IMOP).

Het IMOW en IMOP zijn deels complementair en deels overlappend. Het IMOP is het juridisch deel voor het aanleveren van een omgevingsdocument. Het IMOP beschrijft de tekst die gezamenlijk een regeling of besluit vormt. Verder worden alle geografische informatieobjecten (GIO’s) ook in het IMOP opgeslagen en meegeleverd. Deze informatie vormt gezamenlijk de inhoud van de regeling.

Het IMOW is bedoeld voor het realiseren van functionaliteit ten behoeve van het bevragen van een regeling in DSO-verband. Data zijn hiervoor bezien van uit geografisch perspectief. Bij een IMOW-aanlevering kun je denken aan het duiden van specifieke activiteiten op de kaart of het meeleveren van functies of beperkingengebieden. In principe zorgen de gegevens die aangeleverd worden vanuit het IMOW dat de buitenwereld in staat is om de Omgevingswet-informatie op een kaart terug te vinden. IMOW geeft hiermee een plek aan de domeinspecifieke en geografische kant van de Omgevingswetinformatie. Dit is informatie die niet generiek is voor officiële publicaties (OP) en daarom ook niet wordt opgenomen in OP.

media/image2.png

Figuur 1 De standaard

Een aanlevering bestaat uit zowel IMOP- als IMOW-bestanden. Hoe IMOP exact werkt wordt beschreven in de standaard officiële publicaties (STOP). Het IMOW wordt wel in dit document beschreven.

1.2 Documentatie

Er worden veel documenten opgeleverd bij het publiceren van een nieuwe versie van de standaard. In deze paragraaf wordt ieder opgeleverd document kort toegelicht zodat het duidelijk is waar welke informatie te vinden is.

IMOW – plan tot publicatie

Dit document. Hierin staat voornamelijk beschreven hoe het informatiemodel geïmplementeerd dient te worden en hoe je aanlevert conform de set van IMOW.xsd’s. Deze XSD’s worden gebruikt voor de beschrijving van XML-gebaseerde gegevensuitwisseling in het DSO.

CIMOW – plan tot publicatie

Het conceptueel informatiemodel, hierin staat beschreven welke objecttypen het CIMOW kent en hoe deze zich tot elkaar verhouden. Het CIMOW is het leidende informatiemodel voor informatie-uitwisseling binnen het DSO. CIMOW is de bron van welke objecttypen inclusief definities. In het IMOW wordt de vertaling van CIMOW naar IMOW beschreven en de vertaling terug van IMOW naar CIMOW.

STOP

De standaard officiële publicaties, hierin staat beschreven hoe je een omgevingsdocument aanlevert conform de schema’s behorend bij de STOP-standaard.

TPOD

Toepassingsprofielen voor omgevingsdocumenten (TPOD’s) beschrijven de juridische en informatiekundige context voor de specifieke omgevingsdocumenten. In de 1.0-versie van de TPOD-standaard worden de volgende omgevingsdocumenten ondersteund:

Validatie- en conformiteitsregels

Dit is een document waarin beschreven wordt welke functionele validaties (dienen te) worden uitgevoerd door het Digitaal Stelsel Omgevingswet (DSO).

Voorbeeldbestanden (Implementatiebestanden)

Dit zijn voorbeelden van hoe de bestanden van een aanlevering er uitzien. Deze geven inzicht hoe IMOP en IMOW technisch toegepast moeten worden om een nieuw omgevingsdocument aan te leveren.

Waardelijsten

Dit document geeft aan welke waarden er gekozen kunnen worden bij aan de waardelijsten gekoppelde attributen van IMOW. Waardelijsten worden in de Stelselcatalogus[1] https://stelselcatalogus.omgevingswet.overheid.nl/waardelijstenpagina
gepubliceerd en maken dus geen onderdeel uit van de XML-schema’s.

1.3 Leeswijzer

Hoofdstuk 2 gaat over het informatiemodel en waar het informatiemodel uit bestaat. Verder wordt het informatiemodel in de context geplaatst van de standaard voor officiële publicaties.

Hoofdstuk 3 bespreekt de technische implementatie en geeft hierbij aan welke bestanden er verwacht worden en welke randvoorwaarden er zijn voor het aanleveren.

Hoofdstuk 4 gaat gedetailleerd in op hoe de OW-bestanden er uit dienen te zien en geeft een XML-beschrijving van ieder bestand dat aangeleverd kan worden.

Hoofdstuk 5 geeft weer waar het CIMOW en IMOW afwijken, en hoe deze verschillen er uitzien. Hoofdstuk 6 bekijkt enkele aspecten uit STOP die relevant zijn voor de werking van OW en geeft enkele richtlijnen over de wijze waarop OW zich verhoudt tot STOP.

Hoofdstuk 7 gaat in op hoe het werkt als OW-objecten aangepast worden.

2. Informatiemodel Omgevingswet

In dit hoofdstuk wordt gekeken naar het informatiemodel Omgevingswet. Paragraaf 2.1 geeft een toelichting over het IMOW, vervolgens wordt er in paragraaf 2.2 gekeken hoe het IMOW eruitziet bij vrijetekststructuur en in paragraaf 2.3 wordt de artikelsgewijze structuur toegelicht. Als laatst wordt de verhouding tussen de informatiemodellen van OP en OW behandeld in paragraaf 2.4.

2.1 Context IMOW

Een aanlevering kan voor omgevingsdocumenten met twee typen tekststructuren zijn, namelijk de omgevingsdocumenten opgebouwd met artikelsgewijze structuur en omgevingsdocumenten opgebouwd met vrijetekststructuur. De inhoud van de OW-aanlevering verschilt op basis van het aangeleverde type omgevingsdocument.

Voor beide typen omgevingsdocumenten is een diagram toegevoegd met hierin de aanwezige objecttypen, attributen en relaties. De donkerblauwe kleur geeft aan dat het OW-objecten zijn die hun oorsprong kennen in STOP. De lichtblauwe kleur geeft aan dat het tekstgeoriënteerde OW-objecten zijn. De lichtgroene kleur geeft aan dat het locatie-gebonden OW-objecten zijn. De roze kleur geeft aan dat het concrete locaties zijn. De paarse kleur geeft aan dat het een geometrie is (die in zowel OW als OP gebruikt wordt).

De UML-afbeeldingen worden gebruikt om de IMOW-schema’s mee te genereren. Kortom, de UML-afbeeldingen zijn een directe weergave van de wijze waarop OW-bestanden gestructureerd moeten worden.

2.2 Vrijetekststructuur

De onderstaande afbeelding geeft aan hoe het UML-diagram voor vrijetekststructuur eruitziet.

media/image4.svg

Figuur 2 UML-diagram vrijetekststructuur

Binnen de vrijetekststructuur is het zo dat de Divisie een OP-object is. Dit betekent dat de inhoudelijke tekstgegevens worden aangeleverd in het IMOP-gedeelte en dat je vanuit OW verwijst naar deze Divisie. Vanuit OW kun je een of meerdere tekstdelen aangeven bij de Divisie. Een tekstdeel kan optioneel nog één of meerdere hoofdlijnen, gebiedsaanwijzingen, en/of locaties bevatten. Tevens kan er een locatie direct gekoppeld zijn aan het tekstdeel of kan de locatie via de gebiedsaanwijzing gekoppeld zijn aan het tekstdeel. De locatie is een supertype van ofwel een lijn, punt, gebied of een groep van lijnen, punten of gebieden. Uiteindelijk heeft ieder subtype van locatie een geometrie die als los GML-bestand wordt meegeleverd.

2.3 Artikelstructuur

De onderstaande afbeelding geeft aan hoe het UML-diagram voor artikelsgewijze structuur eruitziet.

media/image6.svg

Figuur 3 UML-diagram Artikelstructuur

Net zoals bij vrijetekststructuur begint artikelsgewijze structuur met een OW-object dat zijn oorsprong kent uit OP, namelijk de Regeltekst. Deze bevat een verwijzing naar het ID dat vanuit OP hoort bij een artikel of een lid (zie 3.1.2). Vervolgens kunnen er een of meerdere Juridische regels zijn die verbonden zijn aan de regeltekst. Een juridische regel heeft drie subtypen (RegelVoorIedereen, Instructieregel, Omgevingswaarderegel) die allen afzonderlijke relaties hebben met de verschillende OW-objecten. Deze OW-objecten zijn: Gebiedsaanwijzing, Activiteit, Omgevingswaarde en Omgevingsnorm. Een Omgevingsnorm of Omgevingswaarde hebben altijd een Normwaarde, dit kan zijn een kwalitatieve of kwantitatieve waarde. Vervolgens hebben Normwaarde, Activiteit en Gebiedsaanwijzing nog een relatie met een Locatie. De locatie is een supertype van ofwel een lijn, punt, gebied of een groep van lijnen, punten of gebieden. Uiteindelijk heeft ieder subtype van locatie een geometrie die als los GML-bestand wordt meegeleverd (zie 3.1.4). Aanvullend hierop heeft de artikelstructuur een Pons-object die alleen gebruikt kan worden bij het omgevingsplan, dit is een losstaand objecttype dat een relatie heeft met een Locatie (zie 3.4.1).

2.4 Verhouding OP en OW

Tussen de twee standaarden zijn er drie objecttypen die de samenhang tussen het OP- en het OW-deel vormgeven, dit zijn: Regeltekst, Divisie en Geometrie. OP maakt ook onderscheid tussen de vrijetekststructuur en artikelsgewijze structuur.

2.4.1 Vrijetekststructuur in OP

OP bouwt vrijetekststructuur op door te duiden dat het mogelijk is om twee elementtypen te gebruiken bij vrijetekst, namelijk: Divisie en Divisietekst. Het hoogste niveau is altijd een Divisie, deze mag onderliggende Divisies bevatten waar uiteindelijk ook een Divisietekst met Inhoud in moet zitten. De Inhoud bevat alleen inhoudelijke tekst. Dit betekent dat Divisie gebruikt wordt om de tekst te structureren in bijvoorbeeld verschillende hoofdstukken of paragrafen.

Binnen OW is Divisie een subtype van OP-object. Dit betekent dat er vanuit Divisie een verwijzing is naar de identificatie vanuit OP ofwel de wId van de Divisie in OP en naar de identificatie van de regeling vanuit OP, de work-id van de regeling. Zo zorgt het OW dat er op het diepste inhoudelijke niveau een verwijzing is naar het OP-deel.

2.4.2 Artikelsgewijze structuur in OP

OP bouwt artikelsgewijze structuur op door te benoemen welke elementen binnen een ander element mogen vallen. Zo heeft bijvoorbeeld binnen een Regeling een Hoofdstuk de mogelijkheid om meerdere Paragrafen te bevatten of meerdere Artikelen, een Paragraaf kan op zijn beurt weer meerdere Artikelen of Subparagrafen bevatten. Zodoende kom je uiteindelijk uit op het diepste niveau, namelijk Artikel waarbinnen Inhoud moet zitten, hier staat de inhoudelijke tekst van het artikel in.

Binnen OW is Regeltekst een subtype van OP-object, dit betekent dat er vanuit Regeltekst een verwijzing is naar de identificatie vanuit OP ofwel de wId van het artikel en naar de identificatie van de regeling vanuit OP, de WorkID van de regeling. Zo zorgt het OW ook bij artikelsgewijze structuur dat er op het diepste inhoudelijke niveau een verwijzing is naar het OP-deel.

2.4.3 Geometrie in OP

In OP wordt gebruik gemaakt van een andere modelconstructie om tekst en data aan geometrie te koppelen dan de constructie in OW. Het element dat vanuit OP gebruikt wordt om naar geometrieën te verwijzen heet een geografisch informatieobject (GIO). Het OP krijgt altijd een GIO indien er een geometrie wordt aangeleverd. Een GIO zorgt voor de koppeling in OP tussen een inhoudelijk deel van het besluit en een geometrie (ofwel het werkingsgebied van de regel).

In OW worden geen GIO’s aangeleverd, maar juist locaties, zoals toegelicht in 2.2 en 2.3. Uiteindelijk verwijst zowel OW als OP naar hetzelfde geometrie-bestand, maar op een andere manier (OP via GIO’s en OW via Locaties).

3. Technische implementatie IMOW

Dit hoofdstuk beschrijft hoe het IMOW technisch ingevuld dient te worden. Het start in paragraaf 3.1 met het toelichten van OW-bestanden. In paragraaf 3.2 staan randvoorwaarden benoemd bij het aanleveren.

3.1 OW-bestanden

Een OW-aanlevering bestaat uit de volgende bestanden:

3.1.1 OW-manifest

De OW bestanden zijn opgesomd in het ow specifieke manifest. Hierin plaats je de versie van de regeling waar de aanlevering bij hoort. Vervolgens specificeer je in dit bestand de OW-specifieke annotaties die je meelevert. Hierdoor staat per OW-bestand alleen dezelfde soort objecten gedefinieerd. Per 1.0 is het niet meer mogelijk om in het OW-manifest GML-bestanden mee te geven, dit gebeurt in het (OP-)manifest.

Zie de opgeleverde voorbeeldbestanden voor een concreet voorbeeld van een manifest.

3.1.2 Regeltekst

In het regeltekst-bestand leg je de koppeling tussen de gegevens vanuit het IMOP en het IMOW. Dit gebeurt middels het OwObject van Regeltekst. Deze Regeltekst bevat twee attributen die verwijzen naar het IMOP, dit zijn wId en wIdRegeling.

wId verwijst naar het ID van het artikel of lid uit IMOP.

wIdRegeling verwijst naar het ID van de regeling uit IMOP.

Regeltekst heeft zelf ook nog een identificatie, hier wordt naar verwezen vanuit OwObjecten.

In het document van Regeltekst dien je ook Juridische Regels te definiëren. Een juridische regel maakt het mogelijk om te duiden welke OwObjecten worden aangemerkt in een bepaald artikel of lid. Juridische Regel is een abstract objecttype dat drie subtypen heeft, namelijk: RegelVoorIedereen, Instructieregel en Omgevingswaarderegel.

De Juridische regels hebben sinds 1.0 een identificatie, dit is toegevoegd om te zorgen dat deze te muteren zijn. Tevens hebben ze een attribuut genaamd: ‘artikelOfLid’, welke verwijst naar de OW-Regeltekst. Vul hierin dezelfde waarde van identificatie in als de waarde die is opgenomen in de OW-Regeltekst.identificatie.

Verder kennen OwObjecten ook onderlinge relaties. Zo heeft een Juridische regel een relatie naar o.a. een Activiteit, Omgevingsnorm, Gebiedsaanwijzing en andere objecten. De XSD’s kennen hiervoor een Ref element, zoals ActiviteitenRef. Vul hierin de identificatie in van het gerelateerde objecttype, oftewel de waarde die staat in het element identificatie van het desbetreffende object.

3.1.3 OW-specifieke annotaties

Naast Regeltekst zijn er meerdere OwObjecten die meegeleverd kunnen worden in het IMOW.

Zo heeft een Activiteit een relatie naar een Locatie. De XSD’s kennen hiervoor een Referentie-element, zoals LocatieRef. Vul hierin de identificatie in van het gerelateerde objecttype, dit is de waarde die staat in het element identificatie van het desbetreffende object.

Het is de bedoeling dat de identificaties van OW-objecten in de OW-bestanden geschikt moeten zijn voor het bevoegd gezag (BG) zelf en voor gebruik/afname vanuit de landelijke voorziening digitaal stelsel Omgevingswet (DSO-LV) door het DSO, de BG en derden.

De identificatie van een OW-object, zoals een Locatie, krijgt daarom bij BG een lokale identificatie die bepaald wordt door BG zelf. Deze lokale identificatie komt vervolgens in alle ketens herkenbaar beschikbaar en moet daarom globaal uniek zijn, of gemaakt (kunnen) worden, zodat deze geschikt is voor gebruik in de LVBB en DSO-LV en afnemers daarvan.

Onderstaande beschrijft de specificatie hiervoor.

De lokale identificatie vormt de basis voor de keten van BG naar DSO en weer terug naar BG of derden.

  • Bij uitwisseling van informatie in ketens met andere partijen, dan wordt deze lokale identificatie globaal uniek gemaakt, via vaste afspraken (zie 3.2.1).

  • Keten van plan tot publicatie, opname in OP bestanden: zie OP specificatie.

  • Keten van plan tot publicatie, opname in OW bestanden: zie hieronder.

Als er sprake is van informatie die én in OW-bestanden zit én in OP-bestanden zit, dan is de lokale identificatie het verbindende gegeven.

3.1.4 GML-bestanden

De GML-specificaties volgen de regels van de standaard Basisgeometrie (de versie die is vastgesteld op 30 september 2020): https://docs.geostandaarden.nl/nen3610/def-st-basisgeometrie-20200930/

Het bijbehorende GML applicatieschema Basisgeometrie.xsd is gepubliceerd op: https://register.geostandaarden.nl/gmlapplicatieschema/basisgeometrie/

Voor de zelfstandig leesbaarheid van IMOW-standaard is de inhoud van de genoemde standaard Basisgeometrie en het schema ook opgenomen in IMOW.

GML-versie en profiel: GML 3.2.2 – SF-0.
Simple features profile 0 is gekozen omdat de inhoud van dit model geen constructies heeft die complexer zijn dan SF-0. Voor geometrietypen is er tussen SF-0, SF-1 en SF-2 geen verschil. Over de data gekoppeld aan dit geometriemodel wordt niets gezegd. Die hebben hun eigen complexiteitseisen.

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"

De beschrijving van de respectievelijke EPSG codes zijn te vinden onder de url's met het format: "http://www.opengis.net/def/crs/EPSG/0/""epsgcode".
Momenteel worden in het DSO de 3D-coördinatenreferentiestelsels nog niet ondersteund (EPSG:4937, EPSG:7415, EPSG:7423).

Bijvoorbeeld: http://www.opengis.net/def/crs/EPSG/0/28992

gml:id: 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.

Nauwkeurigheid van coördinaten: Coördinaten opgenomen bij een geometrie worden standaard uitgewisseld met een getalsnauwkeurigheid 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).

Alles wat nauwkeuriger is wordt afgerond op deze nauwkeurigheid van 3 of 8 decimalen. Afronding is volgens de volgende regel:
0.0015 -> 0.002;
0.0014 -> 0.001.

3.2 Randvoorwaarden bij aanleveren

Bij het aanleveren dient er rekening gehouden te worden met verschillende aspecten. In 3.2.1 wordt beschreven hoe de identificatie van de objecten er uit dient te zien. In 3.2.2 wordt de maximale bestandsgrootte toegelicht. In 3.2.3 wordt toegelicht hoe de XSD’s er uitzien en waar deze te vinden zijn.

3.2.1 Identificatie van OwObjecten

De wijze van het identificeren van objecten in het IMOW volgt de NEN3610-standaard. De identificatie volgt de volgende reguliere expressie:

nl\.imow-(gm|pv|ws|mn|mnre)[0-9]{1,6}\. (regeltekst|gebied|gebiedengroep|lijn|lijnengroep|punt|puntengroep|activiteit|gebiedsaanwijzing|omgevingswaarde|omgevingsnorm|pons|kaart|tekstdeel|hoofdlijn|divisie|kaartlaag|juridischeregel|activiteitlocatieaanduiding|normwaarde|regelingsgebied|ambtsgebied|divisietekst)\.[A-Za-z0-9]{1,32}

Toelichting:

Onderdeel van reg. exp.

Betekenis

nl.imow-

Alle gegevens die worden aangeleverd vanuit het IMOW dienen te starten met nl.imow-

(gm|pv|ws|mn|mnre)

keuze voor een code voor de bestuurslaag* van de bronhouder: gm voor gemeente, pv voor provincie, ws voor waterschap of mnre voor ministerie

[0-9]{1,6}

de overheidscode van de bronhouder, maximaal 6 cijfers

\.

een punt

(regeltekst|gebied|gebiedengroep|lijn|lijnengroep|punt|puntengroep|activiteit|gebiedsaanwijzing|omgevingswaarde|omgevingsnorm|pons|kaart|tekstdeel|hoofdlijn|divisie|kaartlaag|juridischeregel|activiteitlocatieaanduiding|normwaarde|regelingsgebied|ambtsgebied**|divisietekst)

keuze voor de naam van het IMOW objecttype van het object waar de identificatie betrekking op heeft

\.

een punt

[A-Za-z0-9]{1,32}

Een codereeks van minimaal 1 en maximaal 32 alfanumerieke tekens, te bepalen door de bronhouder

De lokale identificatie als geheel wordt dan bijvoorbeeld: nl.imow-gm0200.gebied.2019000001

* In de code van de bestuurslagen mogen de bestuurslagen geen hoofdletters bevatten.

** de uitzondering voor ambtsgebied-identificaties is er uitgehaald, dit betekent dat een ambtsgebied-ID zich op de reguliere wijze verhoudt tot andere OW-objecten.

Het bestuurlijkeGrenzenID

Voor Ambtsgebieden is een extra identificatie nodig die verwijst naar de bestuurlijkeGrenzen-voorziening[2] https://brk.basisregistraties.overheid.nl/bestuurlijke-grenzen-api
. Deze identificatie is de bestuurlijkeGrenzenID en ziet als volgt uit:

Onderdeel van reg. exp.

Betekenis

(GM|PV|WS|LND)

keuze voor een code voor de bestuurslaag* van de bronhouder: GM voor gemeente, PV voor provincie, WS voor waterschap of LND voor het Rijk**

[A-Z0-9.]{1,7}

de overheidscode van het bevoegd gezag i.r.t. het bestuurlijk gebied zoals bekend in de bestuurlijkeGrenzen-voorziening. Dit bestaat uit hoofdletters, punten en cijfers, met een maximum van 7 tekens.

De lokale identificatie als geheel is dan bijvoorbeeld: GM0297 of LND6030.A

3.2.2 Status

De status is bedoeld om in aan te geven dat het OW-object een specifieke status heeft.

In de huidige versie is het alleen mogelijk om hier de status: ‘beëindigen’ in aan te geven. De implementatie hiervan wordt toegelicht in hoofdstuk 4.

Met de waarde ‘beëindigen’ wordt aangegeven dat een bepaald OW-object beëindigd moet worden. Het stelsel zal vervolgens het object op inactief zetten, en het zal alleen nog maar getoond worden als iemand een tijdreis-vraag stelt.
(Een voorbeeld van een tijdreis-vraag is: ‘welke regel was een jaar geleden geldig op deze locatie?’)

3.2.3 Procedurestatus

De procedurestatus kan gebruikt worden om aan te geven dat een bepaald OW-object een specifieke procedurestatus heeft. In de huidige versie is het alleen mogelijk om hier de status: ‘ontwerp’ in aan te geven.

De status ‘ontwerp’ staat voor ontwerpbesluit. Hiermee geef je aan dat een bepaald OW-object alleen als ontwerp getoond moet worden. Het stelsel zal vervolgens bij dit OW-object aangeven dat dit iets is wat specifiek geldt voor het ontwerpbesluit (en daarmee nog niet behoort bij vastgestelde regelgeving).

Indien er geen procedurestatus ‘ontwerp’ is aangegeven dan wordt het OW-object beschouwd als behorend bij vastgestelde regelgeving.

3.2.4 Bestandsgrootte

Een aanlevering wordt afgekeurd indien deze groter is dan 1000MB. Per bestand geldt dat deze niet groter mag zijn dan 100MB. De volgende kanttekening is hierbij van toepassing:

  • Binnen een GIO mag iedere afzonderlijke locatie (GML binnen de GIO) niet groter zijn dan 10MB.*


*De definitieve bestandsgrootten dienen nog vastgesteld te worden in overeenstemming met de betrokken ketenpartners.

3.2.5 XSD-bestanden

De validaties die in dit bestand omschreven zijn komen overeen met de validaties die uitgevoerd worden in de XSD-bestanden. In principe is het zo dat als je aanlevert conform de XSD dat je dan een technisch valide bestand hebt aangeleverd. (De functionele validaties staan beschreven in het validatie- en conformiteitsregels-document.)

De XSD’s zijn gepubliceerd op https://register.geostandaarden.nl/xmlschema/tpod/ de schema’s kennen een eigen versiebeheer, wat betekent dat er verwezen moet worden naar een specifieke versie van de schema’s (bijvoorbeeld 1.0.3). Bij het publiceren van dit document worden ook de schema’s gepubliceerd.

Om te zien hoe het schema exact werkt zie de voorbeeldbestanden.

3.2.6 Waardelijsten

In CIMOW is te vinden welke attributen als datatype een waardelijst hebben. Bijvoorbeeld, een activiteit heeft een attribuut groep, waarvan de waarde uit de waardelijst ActiviteitenGroep moet komen. In hoofdstuk 4 is te zien dat een waarde correspondeert met een waardelijst als dit is aangegeven in de toelichting of bij het datatype URI.

(http|https)://(wetgeving|standaarden|regelgeving)\.omgevingswet\.overheid\.nl/.*

Bij het valideren van de waarden wordt binnen het OW de volgende reguliere expressie gehanteerd:

Vervolgens controleert het DSO of de waarde voorkomt in de stelselcatalogus.

De stelselcatalogus is publiekelijk beschikbaar.

4. XML-omschrijving

In paragraaf 4.1 wordt beschreven hoe het manifest er uit moet zien. Paragraaf 4.2 gaat in op hoe alle OW-bestanden gestructureerd moeten zijn. In paragraaf 4.3 wordt getoond hoe de specifieke OW-objecten vanuit Artikelstructuur er uitzien. In paragraaf 4.4 wordt getoond hoe OW-aanleveringen van Vrijetekststructuur er uitzien. Paragraaf 4.5 gaat in op het regelingsgebied. Bij het type is tussen de haakjes het maximum aantal karakters voor het veld toegevoegd.

4.1 Manifest

Het manifest beschrijft de inhoud van de aanleveringen.

Element

M(ultipliciteit)

Type

Toelichting

Aanleveringen

[1..1]

domein

[1..1]

String(80)

Omschrijving van de dataset

IMOWversie*

[0..1]

String

De IMOW-versie waarmee is aangeleverd

Aanlevering

[1..*]

WorkIDRegeling

[1..1]

String(255)

Het ID van de Regeling (aan de OP-kant)

DoelID

[1..1]

String(255)

Het ID van het Doel (aan de OP-kant)

Bestand

[1..*]

Een afzonderlijk bestand dat opgenomen is in de aanlevering

Naam

[1..1]

String(255)

De naam van het bestand

objectType

[1..*]

String(80)

Het specifieke objecttype dat voorkomt in het bestand

*toegevoegd in IMOW v2.0.0.

4.2 owBestand

Het owBestand is hetgeen dat alle inhoud van een specifiek bestand bevat, alle OW-aanleveringen maken hier gebruik van.

Element

M(ultipliciteit)

Type

Toelichting

owBestand

[1..1]

standBestand

[1..1]

dataset

[1..1]

String

Omschrijving van de dataset

inhoud

[1..1]

gebied

[1..1]

String(80)

Naam van het gebied

leveringsId

[1..1]

String(255)

Een identificatie van de levering

objectTypen

[1..1]

De objecttypen die in dit specifieke bestand worden meegeleverd

objectType

[1..*]

String(80)

Het specifieke objecttype dat voorkomt in het bestand

stand

[1..*]

Aanlevering van een specifiek OW-object.

owObject

[1..1]

Het specifieke OW-object.
Zie verdere paragrafen voor invulling per OW-object.

4.3 Artikelstructuur

De objecten uit deze paragraaf kunnen worden aangeleverd bij een omgevingsdocument dat gestructureerd wordt door middel van artikelen.

4.3.1 Regeltekst

Doel van het objecttype Regeltekst is het leggen van de verbinding tussen de Juridische regel uit het Omgevingswet-domein en het artikel of lid uit STOP.

Element

M(ultipliciteit)

Type

Toelichting

owObject

[1..1]

Container van het specifieke OW-object.

Regeltekst

[1..1]

Element bedoeld voor koppeling tussen artikel/lid en juridische regel.

[@wId]

[1..1]

String(255)

Identificatie van artikel of lid uit OP-bestand.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610
(80)

Identificatie van OW-object, zie 3.2.1.

4.3.2 Juridische regel

Een Juridische regel is een abstract objecttype dat drie verschijningsvormen heeft, de juridische regel is om verschillende inhoudelijke annotaties te kunnen doen. Bij het gebruik van de juridische regel is het verplicht om hetzelfde type Juridische Regel te hanteren per Regeltekst.

4.3.2.1 RegelVoorIedereen

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

RegelVoorIedereen

[1..1]

Juridische regel die voor iedereen bedoeld is.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610(80)

Identificatie van OW-object, zie 3.2.1.

idealisatie

[1..1]

String
(255)

Waarde uit de waardelijst ‘idealisatie’.

artikelOfLid

[1..1]

Het artikel of lid waar de Juridische regel bij hoort.

[@RegeltekstRef]

[1..1]

xlink(80)

Verwijzing naar de identificatie van de Regeltekst waar de Juridische regel bij hoort.

thema

[0..*]

URI(255)

Waarde uit de waardelijst ‘Thema’.

locatieaanduiding

[1..1]

De Locatie waar de Juridische regel van kracht is.

[@LocatieRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Locatie waar de Juridische regel van kracht is.

gebiedsaanwijzing

[0..1]

De aanwijzing van een specifiek gebied.

[@GebiedsaanwijzingRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Gebieden die worden aangewezen in de Juridische regel.

kaartaanduiding

[0..1]

Specifieke kaart die geduid wordt

[@KaartRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Kaarten die worden geduid in de Juridische regel.

activiteitaanduiding

[0..*]

De activiteit die gereguleerd wordt in de Juridische regel.

[@ActiviteitRef]

[1..1]

xlink(80)

Verwijzing naar de identificatie van de Activiteit.

ActiviteitLocatieaanduiding*

[1..1]

De locatie waar de activiteit gereguleerd wordt.

identificatie

[1..1]

NEN3610(80)

Identificatie van OW-object zie 3.2.1.

activiteitregelkwalificatie

[1..1]

String
(255)

Waarde uit de waardelijst ‘activiteitregelkwalificatie’.

Locatieaanduiding

[1..1]

De locatie die gekwalificeerd wordt door de activiteit.

[@LocatieRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de locatie die gekwalificeerd wordt(/worden) door de activiteit.

omgevingsnormaanduiding

[0..*]

De omgevingsnorm die gesteld wordt.

[@OmgevingsnormRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de omgevingsnorm die gesteld wordt.

*ActiviteitLocatieaanduiding komt even vaak voor als de ActiviteitRef

4.3.2.2 Instructieregel

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Instructieregel

[1..1]

Juridische regel die bedoeld is voor een ander bevoegd gezag.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

idealisatie

[1..1]

String
(255)

Waarde uit de waardelijst ‘idealisatie’.

artikelOfLid

[1..1]

Het artikel of lid waar de Juridische regel bij hoort.

[@RegeltekstRef]

[1..1]

xlink(80)

Verwijzing naar de identificatie van de Regeltekst waar de Juridische regel bij hoort.

thema

[0..*]

String(255)

Waarde uit de waardelijst ‘Thema’.

locatieaanduiding

[1..1]

De Locatie waar de Juridische regel van kracht is.

[@LocatieRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Locatie waar de Juridische regel van kracht is.

gebiedsaanwijzing

[0..1]

De aanwijzing van een specifiek gebied.

[@GebiedsaanwijzingRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Gebieden die worden aangewezen in de Juridische regel.

kaartaanduiding

[0..1]

Specifieke kaart die geduid wordt

[@KaartRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Kaarten die worden geduid in de Juridische regel.

instructieregelInstrument

[0..*]

String (255)

Waarde uit waardelijst ‘instrument’.*

instructieregelTaakuitoefening

[0..*]

String (255)

Waarde uit waardelijst ‘adressaat’.*

omgevingsnormaanduiding

[0..1]

De omgevingsnorm die gesteld wordt.

[@OmgevingsnormRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de omgevingsnorm(en) die gesteld wordt(/worden).

*De waarde voor instructieregelInstrument en instructieregelTaakuitoefening mogen niet in dezelfde Juridische regel voorkomen.

4.3.2.3 Omgevingswaarderegel

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Omgevingswaarderegel

[1..1]

Juridische regel die bedoeld is voor het eigen bevoegd gezag.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

idealisatie

[1..1]

String(255)

Waarde uit de waardelijst ‘idealisatie’.

artikelOfLid

[1..1]

Het artikel of lid waar de Juridische regel bij hoort.

[@RegeltekstRef]

[1..1]

xlink(80)

Verwijzing naar de identificatie van de Regeltekst waar de Juridische regel bij hoort.

thema

[0..*]

String(255)

Waarde uit de waardelijst ‘Thema’.

locatieaanduiding

[1..1]

De Locatie waar de Juridische regel van kracht is.

[@LocatieRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Locatie waar de Juridische regel van kracht is.

gebiedsaanwijzing

[0..1]

De aanwijzing van een specifiek gebied.

[@GebiedsaanwijzingRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Gebieden die worden aangewezen in de Juridische regel.

kaartaanduiding

[0..1]

Specifieke kaart die geduid wordt

[@KaartRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Kaarten die worden geduid in de Juridische regel.

omgevingswaardeaanduiding

[0..1]

De omgevingswaarde die gesteld wordt.

[@OmgevingswaardeRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Omgevingswaarde(n) die wordt(/worden) gesteld.

4.3.3 Activiteit

Een activiteit heeft als doel het stellen van regels over het menselijk handelen of nalaten met effect op de fysieke leefomgeving.

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Activiteit

[1..1]

Het menselijk handelen of nalaten dat gereguleerd wordt in de regeling.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610
(80)

Identificatie van OW-object, zie 3.2.1.

naam

[1..1]

String(255)

Hoe de Activiteit genoemd wordt.

groep

[1..1]

String(255)

Waarde uit de waardelijst ‘Activiteitengroep’.

gerelateerdeActiviteit

[0..1]

Een Activiteit die gerelateerd is aan de activiteit.*

[@ActiviteitRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie van de Activiteit.

bovenliggendeActiviteit

[1..1]

De activiteit die hiërarchisch boven de Activiteit ligt.**

[@ActiviteitRef]

[1..1]

xlink(80)

Verwijzing naar de identificatie van de Activiteit.

4.3.4 Gebiedsaanwijzing

Een gebiedsaanwijzing is het aanwijzen van een specifiek gebied. De Gebiedsaanwijzing kan zowel bij Juridische regels (artikelstructuur) als bij Tekstdelen (vrijetekststructuur) voorkomen.

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Gebiedsaanwijzing

[1..1]

Een duiding van een specifiek gebied.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610
(80)

Identificatie van OW-object, zie 3.2.1.

type

[1..1]

String(255)

Waarde uit de waardelijst ‘TypeGebiedsaanwijzing’.

naam

[1..1]

String(255)

Hoe het aangewezen gebied genoemd wordt.

groep

[1..1]

String(255)

Waarde uit de waardelijst ‘gebiedsaanwijzinggroep’.*

locatieaanduiding

[1..1]

De Locatie die wordt aangewezen.

[@LocatieRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Locatie waar een specifiek gebied wordt aangewezen.

* De waarde die gekozen kan worden uit de waardelijst gebiedsaanwijzinggroep is afhankelijk van de waarde die gekozen wordt uit ‘typegebiedsaanwijzing’.

4.3.5 Omgevingsnorm

Een omgevingsnorm is het vastleggen van normwaarden als referentiepunt ten behoeve van het handelen in de fysieke leefomgeving.

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Omgevingsnorm

[1..1]

De norm die gesteld wordt vanuit een regel.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

naam

[1..1]

String(255)

Hoe de norm door het bevoegd gezag genoemd wordt.

type

[1..1]

String(255)

Waarde uit waardelijst ‘TypeNorm’.

eenheid

[0..1]

String(255)

Waarde uit waardelijst ‘Eenheid’.*

groep

[1..1]

String(255)

Waarde uit waardelijst ‘Omgevingsnormgroep’.

normwaarde

[1..1]

Een specifiek referentiepunt (waarde) van de norm.

Normwaarde

[1..*]

Een specifiek referentiepunt (waarde) van de norm.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

kwantitatieveWaarde**

[0..1]

Decimal
(80)

In getallen uit te drukken waarde van de norm.

kwalitatieveWaarde**

[0..1]

String(255)

In tekst uit te drukken waarde van de norm.

waardeInRegeltekst**

[0..1]

String(80)

Om aan te geven dat de norm in de tekst van het artikel/lid geduid wordt. Moet verplicht gevuld worden met: ‘waarde staat in regeltekst’.

locatieaanduiding

[1..1]

De Locatie waar de normwaarde geldt.

[@LocatieRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Locatie waar een specifieke normwaarde geldt.

*Eenheid is alleen te gebruiken bij kwantitatieve normwaarden.

** Er moet gekozen worden tussen de drie verschillende typen normwaarden.

4.3.6 Omgevingswaarde

Een omgevingswaarde is het vastleggen van normwaarden die voor de fysieke leefomgeving de gewenste staat of kwaliteit als beleidsdoel vastleggen.

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Omgevingswaarde

[1..1]

De norm over de gewenste staat of kwaliteit van een gebied.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

naam

[1..1]

String(255)

Hoe de norm door het bevoegd gezag genoemd wordt.

type

[1..1]

String(255)

Waarde uit waardelijst ‘Typenorm’.

eenheid

[0..1]

String(255)

Waarde uit waardelijst ‘Eenheid’.*

groep

[1..1]

String(255)

Waarde uit waardelijst ‘Omgevingswaardegroep’.

normwaarde

[1..1]

Een specifiek referentiepunt (waarde) van de norm.

Normwaarde

[1..*]

Een specifiek referentiepunt (waarde) van de norm.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

kwantitatieveWaarde**

[0..1]

Decimal (80)

In getallen uit te drukken waarde van de norm.

kwalitatieveWaarde**

[0..1]

String(255)

In tekst uit te drukken waarde van de norm.

waardeInRegeltekst**

[0..1]

String(80)

Om aan te geven dat de norm in de tekst van het artikel/lid geduid wordt. Moet verplicht gevuld worden met: ‘waarde staat in regeltekst’.

locatieaanduiding

[1..1]

De Locatie waar de normwaarde geldt.

[@LocatieRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Locatie waar een specifieke normwaarde geldt.

*Eenheid kan alleen gebruikt worden bij kwantitatieve normwaarden.

** Er moet gekozen worden tussen de drie verschillende typen normwaarden.

4.3.7 Locatie

De locatie legt informatie vast over waar een annotatie van toepassing is.

4.3.7.1 Gebied-/Lijn-/Puntengroep

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Gebiedengroep*

[1..1]

Groep van locaties van het type gebied.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

noemer

[0..1]

String(255)

De naam die een Locatie krijgt in een bepaalde regel.

groepselement

[1..1]

De groep van Locaties.

[@GebiedRef]**

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van het Gebied* dat in deze groep is opgenomen.

*Dit kan ook lijnengroep of puntengroep zijn.

** Dit kan ook gelijk zijn aan LijnRef of PuntRef (in het geval van respectievelijk lijnengroep of puntengroep).

4.3.7.2 Gebied/Lijn/Punt

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Gebied*

[1..1]

Een verwijzing naar een vlak- of multivlak-geometrie.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

noemer

[0..1]

String (255)

De naam die een locatie krijgt in een bepaalde regel.

hoogte

[0..1]

De hoogte die hoort bij de Locatie.

waarde

[1..1]

Decimal (80)

De numerieke waarde van de hoogte.

eenheid

[1..1]

String (255)

De waarde uit de waardelijst ‘Eenheid’.

geometrie

[1..1]

Het object waar de coördinaten zijn vastgelegd. Dit valt binnen een GIO in de OP-aanlevering.

[@GeometrieRef]

[1..1]

xlink(80)

Verwijzing naar de identificatie van de Geometrie.

*Dit kan ook lijn of punt zijn.

4.3.7.3 Ambtsgebied

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Ambtsgebied

[1..1]

Bijzondere vorm van Gebied die samenvalt met het ambtsgebied van een bepaald bevoegd gezag: het gebied waarover dat bevoegd gezag de bevoegdheid tot regeling en bestuur heeft.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

noemer

[0..1]

String(255)

De naam die een locatie krijgt in een bepaalde regel.

bestuurlijkeGrenzenVerwijzing

[1..1]

Verwijzing naar bestuurlijkeGrenzen-voorziening

BestuurlijkeGrenzenVerwijzing

[1..1]

Verwijzing naar bestuurlijkeGrenzen-voorziening

bestuurlijkeGrenzenID*

[1..1]

Identificatie van bestuurlijk gebied uit bestuurlijkeGrenzen-voorziening, hier geldt de toelichting op bestuurlijkeGrenzenID vanuit 3.2.1.

domein

[1..1]

String(80)

Het domein van dit object, altijd gelijk aan: ‘NL.BI.BestuurlijkGebied’.

geldigOp

[1..1]

Date

Datum waarop het ambtsgebied geldig was. Indien niet meegegeven dan wordt de huidige datum gebruikt. Zo zullen de regels dan ook meebewegen met het ambtsgebied. Indien wel meegegeven, dan een statische verwijzing naar het ambtsgebied van die datum.

*toegevoegd in IMOW v2.0-rc.

4.3.8 Pons

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Pons

[1..1]

Het object dat een gebied duidt waar de oude regeling niet meer getoond hoeft te worden.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

locatieaanduiding

[1..1]

De Locatie waar de oude regeling niet meer getoond hoeft te worden.

[@LocatieRef]

[1..1]

xlink(80)

Verwijzing naar de identificatie(s) van de Locatie waar een de oude regeling niet meer getoond hoeft te worden.

4.3.9 Kaart

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Kaart

[1..1]

Een object waarmee je een specifieke kaart kunt duiden en meegeven.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

Identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

naam

[1..1]

String(255)

Hoe de kaart genoemd wordt.

nummer

[0..1]

String(80)

Nummer van de kaart.
(Er zijn bevoegde gezagen die geven kaarten bepaalde nummers en willen dit als zodanig aanleveren.)

uitsnede

[1..1]

De uitsnede die de randen van de kaart duidt.

Kaartextent

[1..1]

De mapextent.

minX

[1..1]

Decimal (20)

de laagste X-coördinaat, de linkergrens van de kaart.

minY

[1..1]

Decimal (20)

de laagste Y-coördinaat, de ondergrens van de kaart

maxX

[1..1]

Decimal (20)

de hoogste X-coördinaat, de rechtergrens van de kaart

maxY

[1..1]

Decimal (20)

de hoogste Y-coördinaat, de bovengrens van de kaart

kaartlagen

[1..1]

De kaartlagen waarmee de kaart wordt opgebouwd.

Kaartlaag

[1..*]

Een specifiek onderdeel van een kaart.

Identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

Naam

[0..1]

String(255)

Naam van de kaartlaag

Niveau

[1..1]

Integer(80)

Niveau waarop de kaartlaag gestapeld wordt bij het opbouwen van de kaart. (1 is het onderste niveau)

activiteitlocatieweergave

[0..1]

De locatie waar de activiteit gereguleerd wordt.

[@ActiviteitLocatieaanduidingRef]

[1..*]

xlink(80)

Verwijzing naar de activiteitlocatieaanduiding(en) die getoond moet(en) worden op de kaart.

normweergave

[0..1]

De norm die gesteld wordt.

[@OmgevingsnormRef]

[1..*]

xlink(80)

De omgevingsnorm die getoond moet worden.*

Gebiedsaanwijzingweergave

[0..1]

Het gebied dat aangewezen wordt.

[@GebiedsaanwijzingRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Gebiedsaanwijzingen die getoond moet(en) worden op de kaart.

* Dit mag ook een Omgevingswaarde(Ref) of een generieke NormRef zijn.

4.4 Vrijetekststructuur

De objecten uit deze paragraaf kunnen worden aangeleverd bij een omgevingsdocument dat een vrije tekststructuur heeft.

4.4.1 Divisie

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Divisie

[1..1]

Element bedoeld voor de koppeling met de divisie aan de OP-kant.

[@wId]

[1..1]

String(80)

Identificatie van artikel of lid uit OP-bestand.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

4.4.2 Divisietekst

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Divisietekst

[1..1]

Element bedoeld voor de koppeling met de Divisietekst aan de OP-kant.

[@wId]

[1..1]

String(80)

Identificatie van artikel of lid uit OP-bestand.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

4.4.3 Tekstdeel

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Divisie

[1..1]

Het gebied waar de oude regeling niet meer getoond hoeft te worden.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

Idealisatie

[0..1]

String(255)

Waarde uit de waardelijst ‘idealisatie’.

thema

[0..*]

String(255)

Waarde uit de waardelijst ‘thema’.

divisieaanduiding

[1..1]

De divisie waar het tekstdeel onder valt.

DivisieRef

[0..1]

xlink(80)

De divisie waar het tekstdeel onder valt.

DivisieTekstRef

[0..1]*

xlink(80)

De divisietekst waar het tekstdeel onder valt.

hoofdlijnaanduiding

[0..1]

De hoofdlijn die aangeduid wordt in dit tekstdeel.

HoofdlijnRef

[1..*]

xlink(80)

De identificatie(s) van de hoofdlijn(en) die geduid worden.

kaartaanduiding

[0..1]

De kaart die aangeduid wordt in dit tekstdeel.

KaartRef

[1..*]

xlink(80)

De identificatie(s) van de kaart(en) die geduid wordt/ worden.

locatieaanduiding

[0..1]

De locatie die aangeduid wordt in dit tekstdeel.

LocatieRef

[1..*]

xlink(80)

De identificatie(s) van de locatie(s) die geduid wordt/worden.

gebiedsaanwijzing

[0..1]

De aanwijzing van een specifiek gebied.

[@GebiedsaanwijzingRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Gebieden die worden aangewezen in de Juridische regel.

4.4.4 Hoofdlijn

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Hoofdlijn

[1..1]

Een vrij in te vullen object waarmee een relevant beleidsonderdeel kan worden geduid.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

naam

[1..1]

String(255)

Hoe de hoofdlijn genoemd wordt door het bevoegd gezag.

soort

[1..1]

String(80)

Zelf te bepalen soort van Hoofdlijn.
(Bijvoorbeeld: ambitie, perspectief, etc.)

gerelateerdeHoofdlijn

[0..1]

Verwijzing naar een ander hoofdlijn.

HoofdlijnRef

[1..*]

Xlink(80)

Identificatie(s) van de hoofdlijn(en) waar naar verwezen wordt.

4.4.5 Gebiedsaanwijzing

Zie 4.3.4.

4.4.6 Kaart

Zie 4.3.9.

4.5 Regelingsgebied

Het Regelingsgebied is het totale oppervlakte dat gereguleerd wordt in een bepaalde regeling.

4.5.1 Regelingsgebied

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

Regelingsgebied

[1..1]

Het gebied waar de regeling over gaat.

status

[0..1]

String(80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String(80)

Procedurestatus van het OW-object, zie 3.2.3.

identificatie

[1..1]

NEN3610 (80)

Identificatie van OW-object, zie 3.2.1.

locatieaanduiding

[1..1]

Verwijzing naar de locatie waar de regeling over gaat.

[@LocatieRef]

[1..1]

xlink(80)

Verwijzing naar de identificatie van de Locatie waar de Regeling over gaat.

4.6 SymbolisatieItem

4.6.1 SymbolisatieItem

Element

M(ultipliciteit)

Type

Omschrijving

owObject

[1..1]

Container van het specifieke OW-object.

SymbolisatieItem

[1..1]

Juridische regel die bedoeld is voor het eigen bevoegd gezag.

status

[0..1]

String (80)

Status van het OW-object, zie 3.2.2.

procedurestatus

[0..1]

String (80)

Procedurestatus van het OW-object zie 3.2.3.

symboolcode

[1..1]

String (20)

Een symboolcode overeenkomstig met de symbolenbibliotheek.

activiteitLocatieaanduidingSymbolisatie

[0..1]

De locatie waar de activiteit gereguleerd wordt.

[@ActiviteitLocatieaanduidingRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Locatie(s) die met de stijl van de symboolcode moeten worden verbeeld..

gebiedsaanwijzing

[0..1]

De aanwijzing van een specifiek gebied.

[@GebiedsaanwijzingRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Locatie(s) die met de stijl van de symboolcode moeten worden verbeeld..

normwaardeSymbolisatie

[0..1]

Een specifiek referentiepunt (waarde) van de norm.

[@NormwaardeRef]

[1..*]

xlink(80)

Verwijzing naar de identificatie(s) van de Locatie(s) die met de stijl van de symboolcode moeten worden verbeeld..

Voor meer toelichting op de werking van het SymbolisatieItem, zie presentatiemodel TPOD.

5. Verschillen tussen IMOW en CIMOW

De verschillen tussen het IMOW en CIMOW worden geduid in twee verschillende subparagrafen, namelijk de delen van het CIMOW die niet in het IMOW zitten (5.1) en de delen van het IMOW die het CIMOW niet bevat (5.2).

5.1 CIMOW-aspecten niet in IMOW

Niet alle gegevens uit het CIMOW zijn ondergebracht in het IMOW-deel. Namelijk de informatie die in CIMOW is aangeduid met ‘herkomst: OP’. Dit zijn gegevens die de applicatie van het DSO (OZON) ophaalt uit het IMOP-deel en niet worden aangeleverd door het IMOW, zoals:

5.2 IMOW-aspecten niet in CIMOW

Het IMOW kent de volgende verschillen ten opzichte van het CIMOW:

OWobject en OPobject

Alle objecttypen uit CIMOW krijgen supertypen (OWobject en OPobject). Dit wordt gedaan voor alle objecttypes uit CIMOW en hiermee kan de koppeling naar OP afgeleid worden evenals generieke attributen die voor alle aangeleverde objecten gelden (zoals status en procedurestatus).

Gebiedsaanwijzing

Gebiedsaanwijzing is meer generiek opgezet in IMOW dan in CIMOW. De Functie en het Beperkingengebied zijn zo opgezet dat er andere typen Gebiedsaanwijzingen toegevoegd kunnen worden, zonder impact op de XSD’s. De type gebiedsaanwijzingen kunnen worden meegegeven door het attribuut ‘TypeGebiedsaanwijzing’. De groepen die je kunt selecteren volgen vervolgens uit de verschillende waardelijsten van de specifieke ‘gebiedsaanwijzingstypen’.

Relaties

In IMOW staan de rolnamen centraal in plaats van de naam van de relatiesoort. Voorbeelden hiervan zijn locatieaanduiding, omgevingsnormaanduiding. Deze rolnamen worden ook geïmplementeerd in de XSD’s.

Regelingsgebied

In het IMOW wordt er een specifiek object benoemd dat Regelingsgebied heet. In het CIMOW is dit op een andere manier vormgegeven. Een regelingsgebied in IMOW koppelt een Locatie aan een Omgevingsdocument, zodat deze Locatie het regelingsgebied van een Omgevingsdocument wordt. Het regelingsgebied uit IMOW wordt in DSO-LV niet tot een OW-object gevormd. In DSO-LV is een regelingsgebied een relatie tussen een Omgevingsdocument en een Locatie, conform CIMOW.

ActiviteitLocatieaanduiding

In CIMOW is er per v1.0.3 voor gekozen om dit te modelleren als gegevensgroep, terwijl dit in IMOW nog een relatieklasse is. Er wordt onderzocht of deze modelleringswijze ook in IMOW gewijzigd dient te worden.

Geometrie en GIO

In het IMOW wordt het attribuut Geometrie als apart objecttype getoond. Conceptueel (CIMOW) is een geometrie een attribuut van een locatie, maar in de implementatie (IMOW) wordt het gezien als een gerefereerd objecttype. Dit objecttype Geometrie is geen zelfstandig objecttype, het hoort altijd als gerefereerde eigenschap bij een Locatie. Een Geometrie kan niet zelfstandig gemuteerd worden en historie opbouwen, maar een Locatie kan dat wel.

Geometrie wordt door zowel IMOW als IMOP gebruikt. Het BG hoeft daardoor Geometrie maar één keer aan te leveren. Vanwege dat gezamenlijk gebruik is Geometrie in een zelfstandig bestand geplaatst waar vanuit zowel een GIO als de informatieobjecten uit IMOW apart naar wordt verwezen. Verschil in 1.0 is wel dat het GML-bestand normwaarden dient te bevatten indien deze bij de geometrie horen. Deze worden middels het GIO-schema geduid, en vallen niet onder het IMOW.

Onderstaand diagram toont het IMOW model voor geometrie en locatie.

media/image7.png

Figuur 4 UML-diagram bij Locatie

Deze geometrie constructie leidt tot de volgende IMOW-attributen:

Het objecttype Geometrie heeft hierin het algemene ISO-19107 geometrietype GM_Object. In de Locatie-objecten wordt middels een constraint aangegeven wat de beperking op dit algemene type is.

6. OP-aspecten relevant voor IMOW

In dit hoofdstuk wordt gekeken naar aspecten uit het IMOP die relevant zijn voor het IMOW. In de vorige versies van het IMOW-document werden deze genegeerd, aangezien dit buiten scope is van het IMOW. In de huidige versie worden er enkele dingen toegelicht vanuit OW-perspectief, omdat de samenhang met de OP-standaard relevant is. Er zijn drie OP-onderwerpen die relevant zijn vanuit OW-objectperspectief, dit zijn:

  1. De Regeling en diens Artikelen/Leden/Divisies

  2. De ConsolidatieInformatie uit de Regeling

  3. De GIO’s behorend bij de Regeling

Dit hoofdstuk is op geen enkele manier een vervanging van de OP-documentatie, maar probeert de OP-aspecten die voor IMOW van belang zijn toe te lichten.

6.1 De Regeling en diens Artikelen/Leden/Divisies

Alle OW-objecten horen bij een bepaald artikel/lid/Divisie uit een Regeling (die opgesteld is conform de OP-standaard). Vanuit het manifest-ow (4.1) wordt middels het attribuut WorkIDRegeling aangegeven bij iedere aanlevering bij welke Regeling de OW-objecten horen.

In iedere Regeltekst (4.3.1) of Divisie (4.4.1) zit het wId-attribuut, hierin staat de identificatie van het artikel/lid of de divisie aan de OP-kant. Zodoende zijn alle OW-objecten die gekoppeld zijn aan een bepaalde Regeltekst of Divisie terug te vinden in een bepaald deel van een Regeling.

6.2 ConsolidatieInformatie

De ConsolidatieInformatie wordt meegegeven aan de OP-kant, maar bepaalt hoe de OW-objecten geversioneerd worden in het DSO. De daadwerkelijke documentatie van ConsolidatieInformatie is te vinden in de bijbehorende OP-documentatie, dit is een extract.
Hieronder een korte opbouw van de structuur van de ConsolidatieInformatie:

Element

M(ultipliciteit)

Type

Omschrijving

ConsolidatieInformatie

[1..1]

De informatie die noodzakelijk is om de aanlevering te consolideren tot een Regeling.

BeoogdeRegelgeving

[1..1]

De beoogde regelgeving die aangeleverd wordt.

BeoogdeRegeling

[0..1]

De Regeling waarvoor informatie aangeleverd wordt.

doelen

[0..1]

de afzonderlijke doelen (c.q. aanleverID’s).

doel

[1..1]

String

de identificatie van het doel waarmee aangeleverd wordt.

instrumentversie

[0..1]

String

de expression-id van de RegelingVersie

eId

[0..1]

String

de eId van het artikel in het besluit dat de regeling instelt.

BeoogdInformatieobject

[0..*]

Een PDF- of GIO die hoort bij de Regeling.

doelen

[1..1]

de afzonderlijke doelen (c.q. aanleverID’s).

doel

[1..1]

String

de identificatie van het doel waarmee aangeleverd wordt.

instrumentVersie

[0..1]

String

de expression-id van het informatieobject

eId

[0..1]

String

de componentnaam (van de regeling) + # + het eId van de ExtIoRef (van het informatieobject)

Tijdstempels

[0..1]

Tijdstempels geven aan wat voor tijdsinformatie er bij de aanlevering hoort.

Tijdstempel

[1..*]

Een individuele tijdstempel.

doel

[1..1]

String

de identificatie van het doel waarmee aangeleverd wordt.

soortTijdstempel

[1..1]

String

het type tijdstempel, dit kan zijn: juridischWerkendVanaf en geldigVanaf

datum

[1..1]

Date

De datum van de tijdstempel.

eId

[1..1]

String

De eId van het artikel uit het Besluit waar deze tijdstempel genoemd wordt.

Het Doel is een gegeven dat ook aanwezig is bij de aanlevering van de OW-informatie, zie manifest-ow (4.1). OW-objecten krijgen de tijdsinformatie van de tijdstempels die horen bij de aanlevering.

Kortom, als er OW-objecten worden aangeleverd bij een besluit dat juridisch werkend is vanaf 1 januari 2022, dan zullen deze OW-objecten ook juridisch werkend zijn vanaf 1 januari 2022.
(Het DSO legt drie type tijdstempels vast, namelijk juridischWerkendVanaf, geldigVanaf, en beschikbaarOp, met name beschikbaarOp wordt geregistreerd in het DSO op het moment dat informatie aangeleverd is.)

6.3 OP-informatieobjecten

Er zijn twee soorten informatieobjecten die aangeleverd kunnen worden in de OP-standaard, namelijk PDF-documenten en geografische informatieobjecten (GIO’s). In deze en de volgende paragrafen wordt voornamelijk ingegaan op de GIO’s, omdat hier veel vragen over gesteld worden en de samenhang met OW-objecten complex is.

De voornaamste samenhang tussen een GIO en OW is dat de OW-Locaties van het type Gebied/Lijn/Punt (4.3.7.2) een attribuut GeometrieRef hebben dat verwijst naar de identificatie van de Geometrie die te vinden is in de GIO. Kortom, het DSO ontvangt geometrieën doordat de LVBB de geometrie uit de GIO doorstuurt.

6.4 GIO’s

Een GIO bestaat uit twee bestanden, namelijk een geografisch vaststellingsdeel (GML) en een service-deel (XML). In dit document wordt alleen het geografisch vaststellingsdeel behandeld, omdat het service-deel niet van belang is voor de OW-objecten. De identificatie van de Geometrie is te vinden in het geografisch deel van de GIO, dit is van belang voor de OW-Locatie (4.3.7.2).

Er zijn twee type GIO’s, namelijk: GIO’s inclusief informatie over normen (Norm-GIO’s) en GIO’s exclusief informatie over normen (GIO’s).

Hieronder informatie over de opbouw (van het geografisch deel) van een GIO:

Element

M(ultipliciteit)

Type

Omschrijving

GeoInformatieObjectVaststelling

[1..1]

De geometrische aanduiding die vastgesteld wordt.

context

[1..1]

De context ten opzichte waarvan de GIO is vastgesteld.

GeografischeContext

[0..1]

De geografische context ten opzichte waarvan de GIO is vastgesteld.

achtergrondVerwijzing

[0..1]

Een verwijzing naar de achtergrondkaart waarop de GIO is gebaseerd.

achtergrondActualiteit

[1..1]

Date

Datum waarop de achtergrond is vastgesteld.

vastgesteldeVersie

[0..1]

De vastgestelde versie van de GIO.

GeoInformatieObjectVersie

[1..1]

Een versie van de GIO.

FRBRWork

[1..1]

identificatie van de GIO (waar deze versie bij hoort)

FRBRExpression

[1..1]

expressie-identificatie van de GIO-versie

groepen

[0..1]

Lijst van groep-elementen die gebruikt worden.

groepID

[1..*]

String

De identificatie van een groep locaties.

label

[1..*]

String

Het label (de naam) die gebruikt wordt om de groep te duiden.

locaties

[1..1]

De locaties die bij deze GIO horen.

Locatie

[1..*]

Een individuele locatie uit de GIO.

naam

[0..1]

De naam van een specifieke locatie zoals te tonen op een kaart.
[OW-gegeven noemer bij Gebied/Lijn/Punt 4.3.7.2]

geometrie

[1..1]

Geometrie behorende bij de locatie.

Geometrie

[1..1]

Geometrie behorende bij de locatie.

id

[1..1]

UUID

De identificatie van de geometrie.
[OW-gegeven [@GeometrieRef] bij Gebied/Lijn/Punt 4.3.7.2]

geometrie

[1..1]

de inhoud van de geometrie.

gml()

[1..1]

GML

Dit volgt de GML-standaard (SF2). Dit wordt niet verder toegelicht.

Hierbij zijn enkele punten van belang om te weten:

Het is verder aan te raden om de noemer van de OW-Locatiegroepen (4.3.7.1) overeen te laten komen met de label van de bijbehorende GIO-groep.

6.5 Norm-GIO’s

Indien er normen vastgelegd worden aan de OW-kant, dan ziet de GIO er anders uit dan bij OW-Locaties waar geen norm over is vastgelegd.

Hieronder staan de elementen uit de Norm-GIO die overeenkomen met de gewone GIO grijs gemarkeerd:

Element

M(ultipliciteit)

Type

Omschrijving

GeoInformatieObjectVaststelling

[1..1]

De geometrische aanduiding die vastgesteld wordt.

context

[1..1]

De context ten opzichte waarvan de GIO is vastgesteld.

GeografischeContext

[0..1]

De geografische context ten opzichte waarvan de GIO is vastgesteld.

[GW]achtergrondVerwijzing

[0..1]

Een verwijzing naar de achtergrondkaart waarop de GIO is gebaseerd.

achtergrondActualiteit

[1..1]

Date

Datum waarop de achtergrond is vastgesteld.

vastgesteldeVersie

[0..1]

De vastgestelde versie van de GIO.

GeoInformatieObjectVersie

[1..1]

Een versie van de GIO.

FRBRWork

[1..1]

identificatie van de GIO (waar deze versie bij hoort)

FRBRExpression

[1..1]

expressie-identificatie van de GIO-versie

eenheidid

[0..1]

URI

De URI uit waardelijst ‘Eenheid’ (alleen van toepassing bij de kwantitatieve waarde)
[OW-gegeven: eenheid van omgevingsnorm (4.3.5 ) /omgevingswaarde (4.3.6)]

eenheidlabel

[0..1]

String

De label (naam) die getoond dient te worden bij eenheid.

normid

[1..1]

URI

De URI uit waardelijst ‘TypeNorm’ .
[OW-gegeven: type van omgevingsnorm (4.3.5 ) /omgevingswaarde (4.3.6)]

normlabel

[1..1]

String

De naam van de Norm aan de OW-kant.
[OW-gegeven: naam van omgevingsnorm (4.3.5 ) /omgevingswaarde (4.3.6)]

locaties

[1..1]

De locaties die bij deze GIO horen.

Locatie

[1..*]

Een individuele locatie uit de GIO.

naam

[0..1]

De naam van een specifieke locatie.

geometrie

[1..1]

Geometrie behorende bij de locatie.

Geometrie

[1..1]

Geometrie behorende bij de locatie.

id

[1..1]

UUID

De identificatie van de geometrie. (Hier wordt naar verwezen vanuit een OW-Locatie[@GeometrieRef].)

geometrie

[1..1]

de inhoud van de geometrie.

gml()

[1..1]

GML

Dit volgt de GML-standaard (SF2). Dit wordt niet verder toegelicht.

kwantitatieveNormwaarde

[0..1]

Decimal

In getallen uit te drukken waarde van de norm.

kwalitatieveNormwaarde

[0..1]

String

In tekst uit te drukken waarde van de norm.


Hierbij zijn nog enkele punten relevant:

6.6 Richtlijn voor het maken van GIO’s o.b.v. OW-objecten

In deze paragraaf wordt toegelicht welke richtlijnen er zijn voor het maken van GIO’s vanuit OW-objecten. Dit zijn richtlijnen en deze worden niet hard gevalideerd door het DSO. Deze richtlijnen zijn gemaakt n.a.v. de expliciete vraag om te werken naar hoe je vanuit OW naar GIO’s toe kunt werken.

De richtlijn is als volgt:

media/image8.png

Figuur 5 Richtlijn voor OW-objecten i.r.t. GIO’s

media/image9.png

Figuur 6 Richtlijn voor Normen i.r.t. Norm-GIO’s

Dit heeft de volgende consequenties:

7. Muteren met het IMOW

In dit hoofdstuk wordt belicht hoe het werkt als je OW-objecten wilt muteren. Paragraaf 7.1 gaat in op de uitgangspunten die relevant zijn voor het muteren. Vervolgens gaat 7.2 over reguliere wijzigingsbesluiten. Paragraaf 7.3 over het backup-scenario ‘Intrekken en vervangen’. Paragraaf 7.4 gaat over directe mutaties, dit zijn mutaties waar geen wijzigingsbesluit bij wordt aangeleverd. Paragraaf 7.5 kijkt naar ontwerp-objecten en hoe deze werken i.r.t. muteren.

7.1 Uitgangspunten relevant voor muteren

Bij het muteren zijn de volgende drie uitgangspunten van belang:

Deze uitgangspunten gelden voor zowel de OP- als de OW-standaard.

7.1.1 Stuur alleen gegevens op die gewijzigd zijn

Dit uitgangspunt geeft aan dat bij zowel gegevens vanuit de OP-standaard (zoals Besluiten, GIO’s, etc.) als de OW-standaard (Activiteiten, Gebiedsaanwijzingen, etc.) het de bedoeling is om alleen gegevens op te sturen als deze gewijzigd zijn t.o.v. de gegevens die bekend zijn bij het Stelsel.

Bij de OP-standaard zorgt het opsturen van gegevens die al bekend zijn bij het Stelsel niet per se tot een fout, maar het zorgt wel voor een vertroebelde juridische situatie. Bij de OW-standaard zorgt het sturen van een OW-object dat inhoudelijk niet gewijzigd is voor een foutmelding.

(OZON0108 “Het aanleveren van een OW-object mag alleen indien de gegevens aangepast zijn t.o.v. de vorige versie van het OW-object.”)

Kortom, het is van belang om te weten welke gegevens er gewijzigd zijn ten opzichte van een vorige aanlevering bij het DSO-LV om zodoende te zorgen dat alleen de gegevens worden gestuurd die verschillen van de vorige aanlevering (in de praktijk de gegevens die nu in het DSO-LV zitten).

7.1.2 Verwijder expliciet gegevens die niet meer gebruikt worden

Dit uitgangspunt geeft aan dat bij zowel gegevens uit de OP-standaard (zoals GIO’s, Regelingen, etc.) als bij de OW-standaard (Activiteiten, Gebiedsaanwijzingen, etc.) het de bedoeling is om expliciet gegevens te verwijderen die niet meer gebruikt worden.

Aan de OP-kant gebeurt dit middels intrekkingen van de instrumentVersies.

Aan de OW-kant gebeurt dit middels de status ‘beëindigen’ mee te geven.

7.1.3 Een wijziging van een object zorgt voor een nieuwe versie van het object

Dit uitgangspunt geeft aan dat het wijzigen van een object er altijd voor zorgt dat de vorige versie van het object nog steeds bestaat. Hierdoor is het altijd zo dat je kunt tijdreizen in het DSO, wat betekent dat je kunt kijken hoe de toestand er op een bepaalde datum uitzag. Kortom, het beëindigen van een object zorgt er alleen voor het deactiveren van een object, aangezien het object nog steeds bestaat in het DSO.

De tijdstempels vanuit de ConsolidatieInformatie van het Besluit bepalen wanneer bepaalde OW-informatie juridisch werkend is.

7.2 (reguliere) wijzigingsbesluiten

Bij een wijzigingsbesluit hoort doorgaans een RegelingMutatie met hierin allerlei mutatieacties. Deze staan beschreven op de documentatiepagina over renvooieren en muteren van tekst van de OP-standaard.

Voor OW-objecten betekent het aanleveren van een object:

7.2.1 Nieuw object

media/image10.png

Figuur 7

Om te constateren of iets een nieuw object is wordt er gekeken naar de identificatie.

Is de identificatie van het object onbekend bij het DSO, dan wordt het object gezien als nieuw object.

Voor het opvoeren van een nieuw object gelden een aantal regels, namelijk:

  • De eerste keer dat een nieuw object wordt aangeleverd mag deze niet de status beëindigd hebben (OZON0104).

  • Als er verwezen wordt naar andere OW-objecten, dan moeten deze bestaan (OZON0109)
    dit betekent dat de OW-objecten waar naar verwezen wordt ofwel aangeleverd moeten worden ofwel al aangeleverd moeten zijn.

7.2.2 Wijziging van een object

media/image11.png

Figuur 8

Om te constateren of een object gewijzigd wordt, wordt gekeken naar de identificatie van een object. Is de identificatie van een object al bekend in het DSO, dan wordt gekeken of de inhoud veranderd is.

Voor het wijzigen van objecten gelden een aantal regels, namelijk:

  • Het aanleveren van een OW-object mag alleen indien de gegevens zijn aangepast t.o.v. de vorige versie van het OW-object (OZON0108). Hierbij wordt een nieuwe relatie bij een OW-object ook gezien als een gegeven.

  • Het aanleveren van een OW-object mag alleen gerelateerd zijn aan een Doel met tijdstempels die niet in het verleden ligt t.o.v. de meest recente wijziging (OZON0105 en OZON0106). Dit speelt vooral bij directeMutaties (7.4).
    Dit betekent dat ik als ik in 2021 een aantal wijzigingsbesluiten heb gemaakt, ik niet nog eens een wijziging van OW-objecten kan doen n.a.v. een wijzigingsbesluit uit 2019.

  • Door het wijzigen van een object mogen er geen wees-objecten, dat zijn objecten waar niet meer naar verwezen wordt, ontstaan (OZON0350 t/m OZON0367).

  • De volgende IMOW-elementen zijn geen objecten en kunnen derhalve niet direct gewijzigd worden:

    • ActiviteitLocatieaanduiding – deze moet altijd gewijzigd worden vanuit een RegelVoorIedereen.

    • Normwaarde – deze moet altijd gewijzigd worden vanuit een Omgevingsnorm of Omgevingswaarde.

    • Kaartlaag – deze moet altijd gewijzigd worden vanuit een Kaart.

7.2.3 Beëindigen van object

media/image12.png

Figuur 9

Bij het beëindigen van een object wordt gekeken naar de identificatie om te bepalen welk object beëindigd moet worden.

Voor het beëindigen van objecten gelden een aantal regels, namelijk:

  • Het beëindigen van een object mag alleen als de inhoud exact overeenkomt met de laatst aangeleverde OW-informatie (OZON0107).

  • Door het wijzigen van een object mogen er geen wees-objecten, dat zijn objecten waar niet meer naar verwezen wordt, ontstaan.

7.3 Intrekken en vervangen

Intrekken en vervangen is het eerste wijzigingsscenario dat is uitgewerkt in de DSO-keten. Dit scenario is eigenaardig omdat het niet volledig conform het eerste uitgangspunt is (‘Stuur alleen gegevens op die gewijzigd zijn’).

Wat er gebeurt bij intrekken en vervangen van regelstructuur-omgevingsdocumenten (zoals omgevingsplannen en omgevingsverordeningen) is het volgende:

Bij vrijetekststructuur-omgevingsdocumenten (zoals omgevingsvisies en projectbesluiten) geldt

hetzelfde, maar daar waar Regeltekst-objecten staat, moet Divisie/Divisietekst-objecten komen te staan.

Kortom, voor de OW-objecten bij het intrekken en vervangen geldt:

Aspecten van belang voor de OP-standaard i.r.t. intrekken en vervangen:

Disclaimer: Intrekken en vervangen kan alleen als er geen tijdelijkDeel bij de Regeling hoort.

(“OZON1033 Intrekken/Vervangen van een RegelingVersie is niet toegestaan wanneer er een Tijdelijk Deel naar verwijst”)

Hiertoe is intrekken en vervangen een legitiem scenario dat werkt zo lang er geen tijdelijkDelen gebruikt zijn. (De tijdelijke delen zijn bedoeld voor Reactieve interventies en Voorbeschermingsregels/Voorbereidingsbesluiten, die alleen tijdelijk een deel uitmaken van een ander omgevingsdocument.)

7.4 Directe mutaties

Het is mogelijk dat er een wijziging nodig is van OW-objecten zonder dat hier expliciet een besluit over genomen is. Dit kan middels een directe mutatie (directeMutatieOpdracht).

Bij een directeMutatieOpdracht hoort geen publicatie of bekendmakingsdatum.

Dit maakt het mogelijk om achteraf additionele annotaties aan te vullen zonder een besluit te hoeven nemen.

Vanuit het manifest-OW wordt verwezen naar het Doel van een vorige aanlevering.

De tijdslijnen van de nieuwe versie van de OW-objecten horen bij de tijdstempels van dat vorige doel. Kortom, het wijzigen middels een directeMutatieOpdracht maakt dat OW-objecten met terugwerkende kracht gewijzigd worden.

Er zijn OW-objecten waarvan het onlogisch is dat deze gewijzigd worden met een directe mutatie, dit zijn:

7.5 Ontwerp-objecten

In OW is het mogelijk om ontwerp-objecten op te nemen, dit kan middels het attribuut procedurestatus, zoals beschreven in Paragraaf 3.2.3. Een OW-object dat de procedurestatus ontwerp heeft wordt anders behandeld dan OW-objecten die dat niet hebben.

Aan de STOP-kant betekent een ontwerp het volgende:

OW-objecten met de procedurestatus ‘ontwerp’ kunnen niet gemuteerd worden. Deze ontwerp-OW-objecten worden gezien als een nieuwe versie van een OW-object die niet hoort bij vastgestelde regelgeving. Dit is ook omdat ontwerpbesluiten niet gemuteerd kunnen worden, maar een losstaande status hebben t.o.v. vastgestelde regelgeving. Er zijn twee soorten aanleveringen die ontwerp-objecten kunnen bevatten, namelijk:

7.5.1 Initieel ontwerpbesluit

Bij een initieel ontwerpbesluit wordt verwacht dat alle OW-objecten in de procedurestatus ontwerp worden aangeleverd. Echter, bij een ontwerpwijzigingsbesluit hoeven alleen de annotaties die zijn gewijzigd ten opzichte van de vastgestelde regeling te worden aangeleverd.

Bijvoorbeeld: Een initieel voorbereidingsbesluit met slechts één artikel in de regeling waarmee het slopen van karakteristieke panden verboden wordt.

Bij deze Regeling hier een activiteit (slopen van karakteristieke panden) met de procedurestatus ontwerp. Daarnaast wordt ook verwacht dat een juridische regel (regel voor iedereen, incl. activiteitlocatieaanduiding) en een regeltekst-object, beiden met de procedurestatus ontwerp, worden aangeboden.

Iedere annotatie behorend bij het initieel ontwerpbesluit zal met de procedurestatus ontwerp moeten worden aangeleverd.

Ontwerp-activiteiten zullen niet verschijnen in de registratie van toepasbare regels, dus er kunnen geen vragenbomen op ontwerp-activiteiten gemaakt worden.

7.5.2 Ontwerpwijzigingsbesluit

Net zoals bij een ‘regulier’ wijzigingsbesluit worden bij een ontwerpwijzigingsbesluit alleen annotaties die wijzigen ten opzichte van de vastgestelde regelgeving aangeleverd. Het is bij een ontwerpwijzigingsbesluit wel mogelijk om te verwijzen naar annotaties uit de vastgestelde regelgeving.

Voorbeeld: Artikel 1: Het is verboden om te zwemmen in het centrumgebied.

Gaat gewijzigd worden op de volgende manier:
Artikel 1: Het is verboden om te zwemmen in het centrumgebied en in het stiltegebied.

In dit geval hoeft het Regeltekst-object niet te worden aangeleverd, deze bestaat immers al.

Er is wel noodzaak voor een ontwerpversie van de juridische regel, aangezien de locatie waar deze regel over gaat wordt uitgebreid.

Er is ook noodzaak voor een nieuwe OW-locatie in ontwerp, aangezien er een stiltegebied-GIO wordt toegevoegd in dit ontwerpwijzigingsbesluit.

Voorbeeld: Artikel 1: Het is verboden om te zwemmen in het centrumgebied en in het stiltegebied.

Gaat gewijzigd worden op de volgende manier:

Artikel 1: Het is verboden om te zwemmen in het centrumgebied en in het stiltegebied.

Artikel 2: Er geldt een meldingsplicht omtrent het zwemmen in het stiltegebied.

Voor Artikel 1 wordt de juridische regel die verwijst naar het stiltegebied in ontwerp gewijzigd t.o.v. de vastgestelde versie van de juridische regel. Voor Artikel 2 wordt wel een ontwerp-Regeltekst-object aangeleverd inclusief bijbehorende ontwerp-OW-annotaties. De OW-Locatie stiltegebied en de OW-activiteit zwemmen hoeven niet te worden aangeleverd aangezien deze al bestonden in vastgestelde regelgeving.

Ontwerp-OW-objecten mogen verwijzen naar vastgestelde regelgeving, maar andersom is niet het geval. Vastgestelde regelgeving mag niet verwijzen naar ontwerp-objecten.