Informatiemodel Omgevingswet (IMOW)

1.2.1 IMOW – plan tot publicatie (dit document)

Dit document beschrijfthoe annotaties bij een besluit aangeleverd dienen te worden en hoe je aanlevert conform de set van IMOW.xsd’s. Deze XSD’s (XML-schema’s) worden gebruikt voor de beschrijving van XML-gebaseerde gegevensuitwisseling in het DSO. Het IMOW implementeert de objecten beschreven in het CIM-OW.

1.2.2 CIM-OW – plan tot publicatie

Het conceptueel informatiemodel, hierin staat beschreven welke objecttypen het CIM-OW kent en hoe deze zich tot elkaar verhouden. Het CIM-OW is het leidende informatiemodel voor informatie-uitwisseling binnen het DSO.

1.2.3 STOP

De Standaard Officiële Publicaties beschrijft hoe je een omgevingsdocument moet structureren.

1.2.4 TPOD

Toepassingsprofielen voor omgevingsdocumenten (TPOD’s) beschrijven de juridische en informatiekundige context voor de specifieke omgevingsdocumenten. Zie de publicatie van de standaard voor de actuele lijst toepassingsprofielen:

• Omgevingsplan (het omgevingsdocument dat gemeenten aanleveren, het voormalige bestemmingsplan)

• Omgevingsverordening (het omgevingsdocument dat provincies aanleveren, de voormalige provinciale verordening)

• Waterschapsverordening (het omgevingsdocument dat waterschappen aanleveren)

• Algemene maatregelen van bestuur/ ministeriële regeling (AMvB/MR, de omgevingsdocumenten die worden aangeleverd vanuit het rijk)

• Projectbesluit (het omgevingsdocument waarmee een specifiek project mogelijk wordt gemaakt)

• Omgevingsvisie (het omgevingsdocument waarmee het bevoegd gezag een visie kan maken)

1.2.5 De validatiematrix

Dit document beschrijft validatieregels waaraan aanleveringen dienen te voldoen. Dit document is zelf geen standaard maar is een opsomming van regels die in de standaarden beschreven staan en waar tegen gevalideerd kan worden

1.2.6 Voorbeeldbestanden (Implementatiebestanden)

Dit zijn voorbeelden van correcte aanleveringen. Deze geven inzicht hoe IMOP en IMOW technisch toegepast moeten worden om een nieuw omgevingsdocument aan te leveren.

1.2.7 Waardelijsten

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

2.4.1 OW-object

In de lopende tekst wordt gesproken over OW-object. In de uitwisseling (en dus in het UML) wordt OWobject gebruikt. Instanties van de in dit diagram genoemde klasses (en subklasses) kunnen voorkomen in het IMOW deel van een aanlevering.

2.4.2 OP-object

OP-objecten zijn binnen de context van IMOW OW-objecten die een rechtstreekse verwijzing bevatten naar een geïdentificeerd onderdeel van de STOP tekst. Deze verwijzing is opgenomen in het wId attribuut.

In de lopende tekst wordt gesproken over OP-object. In de uitwisseling (en dus in het UML) wordt OPobject gebruikt.

2.4.3 Activiteit

2.4.4 Locatie

Locatie modelleert de locatie die aan OW-objecten wordt toegekend. Het is een apart object dat locatie specificeert in punt, lijn, gebied en samengestelde groepen daarvan. Met een verwijzing naar Geometrie worden de coördinaten opgenomen. De Geometrie objecten worden uitgewisseld in een apart geometrie-bestand.

2.4.5 Kaart en Kaartlaag

Het model kaart modelleert de onderdelen die nodig zijn om een kaart te benoemen en kaartlagen samen te stellen uit locatie en inhoudelijke informatie van andere OW-objecten.

2.4.6 SymbolisatieItem

Met SymbolisatieItem wordt met een symbolisatiecode de kleur en patroon weergave van onderdelen op een kaart gespecificeerd.

2.5.1 Vrijetekststructuur in OP

Vrijetekststructuur in OP bouwt gebruikt twee elementtypen, 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. De Divisie wordt gebruikt om de tekst te structureren in bijvoorbeeld verschillende hoofdstukken of paragrafen.

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

2.5.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 in 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.5.3 Geometrie in OP

In OP wordt gebruik gemaakt van een andere modelconstructie om tekst en data aan geometrie te koppelen dan in OW. Het element dat vanuit OP gebruikt wordt om naar geometrieën te verwijzen is 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.1.1 OW-manifest

De OW bestanden zijn opgesomd in het OWmanifest. 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. Het OW-manifest bevat niet de GML-bestanden; deze staan 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 OW-object 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 OW-objecten.

In het document van Regeltekst dien je ook Juridische Regels te definiëren. Een juridische regel maakt het mogelijk om te duiden welke OW-objecten 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 een identificatie,. 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 OW-objecten 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 object, oftewel de waarde die staat in het element identificatie .

3.1.3 OW-specifieke annotaties

Naast Regeltekst zijn er meerdere OW-objecten 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.

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". Bijvoorbeeld voor EPSG 28992 is dat: https://www.opengis.net/def/crs/EPSG/0/28992

Momenteel worden in het DSO de 3D-coördinatenreferentiestelsels nog niet ondersteund (EPSG:4937, EPSG:7415, EPSG:7423).

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.1 Identificatie van OW-objecten

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

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

Het bestuurlijkeGrenzenID

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

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

3.2.2 Status

Het status veld in een OW-object heeft de volgende betekenis:

• Als het veld status geen waarde heeft wordt aangegeven dat het om een actieve versie van een OW-object gaat.

• Als het veld status de waarde ‘B’ heeft wordt aangegeven dat dat 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.

3.2.3 Procedurestatus

Het veld procedurestatus in een OW-object kan de volgende waarden hebben:

• Als het veld procedurestatus geen waarde heeft dan wordt het OW-object beschouwd als behorend bij vastgestelde regelgeving.

• Als het veld procedurestatus de waarde ‘ontwerp’ hoor het een OW-object bij een ontwerpbesluit en moet het als ontwerp getoond moet worden. Het object hoort niet bij vastgestelde regelgeving.

3.2.4 XSD-bestanden

OW-objecten moeten worden aangeleverd in XML bestanden. Een aanlevering met XML-bestanden moet valide zijn volgens de XML-schema bestanden uit https://register.geostandaarden.nl/xmlschema/tpod/v2.0.0/ .

Naast deze technische validatie moeten de OW-objecten ook voldoen aan de functionele eisen zoals gespecificeerd in dit document.

3.2.5 Waardelijsten

In CIM-OW 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.

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.

3.2.6 Toekennen van OW-objecten aan regelingen

Een OW-object hoort bij een regeling. Als een besluit een regeling wijzigt horen de OW-objecten die in dat besluit ontstaan bij die regeling. Je kunt OW-objecten alleen wijzigen in wijzigbesluiten die die betreffende regeling wijzigen. Dit is vastgelegd in de volgende regels:

Regel: Het WorkIDRegeling van de OW-Aanlevering waarin een OW-object ontstaat bepaalt bij welke regeling een OW-object hoort.

Regel (TPOD1200): Een OW-object mag alleen gewijzigd worden in een OW-aanlevering die hoort bij een besluit dat de regeling wijzigt waar het OW-object bij hoort.

3.2.7 Verwijzingen tussen OW-objecten

In OZON mag een actief OW-object niet verwijzen naar een beëindigd OW-object. Daarom moet een besluit dat een OW-object beëindigt ook alle verwijzingen naar dat OW-object beëindigen. Dit kan alleen als het bevoegd gezag die verwijzingen kan wijzigen, hiertoe introduceren we een regel die verwijzingen naar OW-objecten van andere bevoegd gezagen inperkt:

Regel (TPOD1950):

• Een OW-object behorend bij een regeling niet zijnde een tijdelijk regelingdeel mag alleen verwijzen naar een OW-object behorend bij een regeling van hetzelfde bevoegd gezag, met uitzondering van de relatie bovenliggendeActiviteit van het OW-object Activiteit, waarvoor de specifieke regels van paragraaf 3.2.8 gelden;

• een OW-object behorend bij een regeling niet zijnde een tijdelijk regelingdeel mag niet verwijzen naar een OW-object behorend bij een tijdelijk regelingdeel;

• een OW-object behorend bij een tijdelijk regelingdeel mag alleen verwijzen naar een OW-object behorend bij hetzelfde tijdelijk regelingdeel, met uitzondering van de relatie bovenliggendeActiviteit van de tophaak-Activiteit van het tijdelijk regelingdeel, waarvoor de specifieke regels van paragraaf 3.2.9 gelden.

3.2.8 De functionele structuur

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 11 is de 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:

Regel (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>’.

De volgende regels schrjven voor hoe de relatie bovenliggendeActiviteit moet worden ingevuld:

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

Regel (TPOD1953): Voor de relatie bovenliggendeActiviteit van de tophaken geldt, in afwijking van het bepaalde in paragraaf 3.2.7, 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.

3.2.9 Tijdelijk regelingdelen

Tijdelijk regelingdelen, zoals beschreven in de STOP standaard kunnen door een ander bevoegd gezag worden ingetrokken dan het bevoegd gezag waardoor het is aangemaakt. Voor een tijdelijk regelingdeel geldt de volgende regel:

Regel (TPOD1954):

• in een tijdelijk regelingdeel waarin één of meer Activiteiten zijn geannoteerd moet één zogenaamde tophaak voorkomen;

• de tophaak is de meest bovenliggende Activiteit van het tijdelijk regelingdeel;

• de naam van de tophaak annex de meest bovenliggende Activiteit moet zijn ‘Activiteit gereguleerd in <citeertitel tijdelijk regelingdeel>’;

• voor een tijdelijk regelingdeel geldt dat de relatie bovenliggendeActiviteit van de tophaak moet verwijzen naar de tophaak van de regeling waaraan het tijdelijk regelingdeel door middel van het element isTijdelijkdeelVan gekoppeld is.

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.

4.3.2 Juridische regel

Een Juridische regel is een abstract objecttype dat drie verschijningsvormen heeft: RegelVoorIedereen, Instructieregel en Omgevingswaarderegel. De juridische regel is nodig om verschillende inhoudelijke annotaties te kunnen specificeren. Bij het gebruik van de juridische regel is het verplicht om hetzelfde type Juridische Regel te hanteren per Regeltekst.

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.

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.

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

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

*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 de geografische locatie waar een annotatie van toepassing is.

4.3.8 Pons

4.3.9 Kaart

4.4.1 Divisie

4.4.2 Divisietekst

4.4.3 Tekstdeel

4.4.4 Hoofdlijn

4.4.5 Gebiedsaanwijzing

Zie 4.3.4.

4.4.6 Kaart

Zie 4.3.9.

4.5.1 Regelingsgebied

4.6.1 SymbolisatieItem

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

5.2.1 OWobject en OPobject

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

5.2.2 Gebiedsaanwijzing

Gebiedsaanwijzing is meer generiek opgezet in IMOW dan in CIM-OW. 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’.

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

5.2.4 Regelingsgebied

In het IMOW wordt er een specifiek object benoemd dat Regelingsgebied heet. In het CIM-OW 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 CIM-OW.

5.2.5 ActiviteitLocatieaanduiding

In CIM-OW 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.

5.2.6 Geometrie en GIO

In het IMOW wordt het attribuut Geometrie als apart objecttype getoond. Conceptueel (CIM-OW) 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. Hiertoe is het niet toegestaan om twee Locaties naar dezelfde Geometrie te laten verwijzen (noot: inmiddels is gebleken dat er geen probleem is als er twee Locaties naar dezelfde Geometrie verwijzen, daarom wordt er niet op deze regel gevalideerd in de keten en in een volgende versie van de standaard zal deze regel verwijderd worden.) Een Geometrie kan niet zelfstandig gemuteerd worden en historie opbouwen, maar een Locatie kan dat wel.

Geometrie wordt door zowel STOP 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 van waaruit 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.

Zie paragraaf 2.4.3 voor het IMOW model voor geometrie en locatie.

Deze geometrie constructie leidt tot de volgende IMOW-attributen:

• (Gebied, Lijn, Punt).geometrie: Een verwijzing vanuit Locatie (Gebied, Lijn of Punt) naar een bijbehorende Geometrie.

• Geometrie.id: UUID identificatie van de Geometrie

• Geometrie.geometrie: Vastleggen van een geometrie middels coördinaten.

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.

7.1.1 Stuur alleen gegevens op die gewijzigd zijn

Bij een wijzig-besluit dat de tekst van een regeling wijzigt wil je ook de OW-objecten behorend bij die regeling kunnen wijzigen. Hiervoor stuur je bij een aanlevering alleen de gewijzigde OW-objecten mee.

Het sturen van een OW-object dat inhoudelijk niet gewijzigd leidt tot 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.”). Het is bij een het aanleveren van een wijzig-besluit dus van belang te weten welke OW-objecten onderdeel waren van vorige versie van de regeling zodat je weet wat je moet wijzigen.

7.1.2 Verwijder expliciet gegevens die niet meer gebruikt worden

Voor OW-objecten geldt dat het verplicht is om expliciet OW-objecten te verwijderen die niet meer gebruikt worden.

Dit gebeurt door de status ‘B’ ( van 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 kun jetijdreizen 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 van de ConsolidatieInformatie van het Besluit bepalen wanneer bepaalde OW-informatie juridisch werkend is.

7.2.1 Nieuw object

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 een nieuw object geldt een aantal regels:

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

Regel: 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

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

• Je mag het type van een OW-object niet wijzigen. RegelVoorIedereen, Instructieregel en Omgevingswaarderegel zijn verschillende types.

• 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 die direct of indirect gekoppeld zijn aan een OW-object dat een bestaand documentfragment annoteert (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

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:

1. 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.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 omgevingsdocument met o.a. een artikel in de regeling waarmee het slopen van karakteristieke panden verboden wordt.

Deze Regeling bevat 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.

Kortom, 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.

Bij het aanleveren van Ontwerp-OW-objecten is het zeer aan te bevelen dat de identificaties identiek blijven aan de OW-objecten die horen bij vastgestelde regelingen. De voorziening zorgt ervoor dat er geen validatieconflicten zijn, omdat ontwerp-objecten in aparte tabellen gepersisteerd worden.