IMOW 3.2 is de IMOW-versie die hoort bij STOP 1.5. Aanleiding voor STOP 1.5 is de interbestuurlijke business wens om wijzigingen in geometrie net zoals wijzigingen in tekst inzichtelijk te kunnen maken in plaats van een nieuwe versie van de volledige geometrie vast te stellen en de wijzigingen in de tekst te moeten omschrijven. STOP introduceert hiervoor het GIO-muteren, waarmee de wijzigingen in GIO’s op http://officielebekendmakingen.nl bekendgemaakt kunnen worden. Het is wenselijk dat de door het bestuursorgaan vastgestelde geometriewijzigingen ook op andere plekken gebruikt kunnen worden, waaronder door ze in de DSO-viewer Regels op de kaart te laten zien. Om dat te kunnen doen moet bekend zijn welk(e) OW-object(en) bij welk GIO horen. In de huidige versies van beiden standaarden is dat niet per definitie het geval.

In IMOW 3.0 (en voorgaande versies) is het verplicht om in ieder owBestand het leveringsId in te vullen. Voor aanleverende plansoftware is dat onhandig, omdat eerst de owBestanden worden samengesteld en pas in het proces daarna het leveringsId ontstaat. Om dat te kunnen toevoegen moet daarna de bestandenset weer geopend worden om het leveringsId toe te voegen. Met name wanneer de aanlevering niet goed gaat en er meerdere aanleveringen nodig zijn om het geheel valide te krijgen, waarbij iedere keer een nieuw leveringsId ontstaat, moet dat proces van openen en toevoegen een aantal keren opnieuw gedaan worden.

LVBB en DSO doen niets met het leveringsId in de owBestanden. Verwijderen van het leveringsId levert echter een niet-backwards compatible wijziging op en dat is ongewenst.

De aanleiding voor deze wijziging is de wens om voor de Omgevingswet in LVBB en DSO nieuwe functionaliteiten te realiseren. De onderhavige wijziging biedt de OW-component die hoort bij STOP 1.4.

Het doel voor het wijzigen van de standaard is het mogelijk maken van nieuwe (release B) functionaliteiten in het DSO. Het gaat om wat er nodig is aan de TPOD/IMOW-kant voor:

• Nieuwe consolidatiescenario’s (zoals inhaalbesluiten, gelijktijdige inwerkingtreding van besluiten en besluiten met terugwerkende kracht)
• Rectificatie
• Mededeling uitspraak rechter

Ook zijn er enkele wijzigingen om het DSO beter te laten werken respectievelijk om het werken voor bevoegde gezagen te vereenvoudigen.

Idealisatie is een verplicht attribuut van Juridische regel en Tekstdeel, dat vastlegt hoe het bevoegd gezag de begrenzing van de Locatie voor deze Juridische regel/dit Tekstdeel heeft bedoeld: exact of indicatief. Een Regeltekst (artikel of lid) kan 1 of meer Juridische regels hebben. Juridische regel is een abstract concept: in een artikel of lid kan je de individuele Juridische regels niet onderscheiden. Binnen een Regeltekst kan de idealisatie van de ene Juridische regel exact zijn en van de andere indicatief. De Juridische regels kunnen verschillende Locaties hebben, maar ook dezelfde Locatie. Een viewer kan niet laten zien bij welk stuk van de tekst de Locatie indicatief bedoeld is en bij welk stuk tekst exact. Datzelfde geldt voor de idealisatie van Tekstdeel (stuk vrije tekst). Vanuit de inhoud geredeneerd is het onwenselijk om exact bedoelde en indicatief bedoelde begrenzingen in één artikel, lid of stuk vrije tekst door elkaar te mengen.

In 2023 hebben deze onvolkomenheid in de TPOD-standaard ontdekt. Het oplossen van die onvolkomenheden leidt tot niet-backwards compatible wijzigingen. We hadden toen, vanwege het bevroren moeten zijn van de standaard, niet de mogelijkheid om niet-backwards compatible wijzigingen in de standaard te doen. Daarom hebben we aan de TPOD’s bij Juridische regel en Tekstdeel werkafspraken toegevoegd over de toepassing van idealisatie. Nu, na inwerkingtreden van de Omgevingswet, is er wel ruimte voor niet-backwards compatible wijzigingen.

1 In IMOW was geen voorschrift opgenomen over de toepassing van de verschijningsvormen van Locatie (gebied resp. gebiedengroep) en van geometrie (multigeometrie). Daarom worden ze door elkaar gebruikt. Bij Omgevingsnorm en Omgevingswaarde is dat wel relevant: is de betekenis van een waarde voor een gebiedengroep anders dan voor een multivlak? IMOP en IMOW kennen geen kenmerk om aan te geven dat een waarde een gezamenlijke waarde is voor meerdere geometrieën. Door deze beide omstandigheden kan een viewer niet anders dan waarden weergeven bij iedere individuele geometrie.

2 STOP stelt regels om de correcte weergave van GIO’s af te dwingen opdat alle inhoud van een besluit voor het menselijk oog kan worden weergegeven zonder dat daarvoor hulpmiddelen (zoals klikken in een kaart) nodig zijn. Ook de waarden van Normen moeten direct leesbaar zijn. Een GIO met meerdere waarden op dezelfde locatie en een GIO met Locaties die elkaar geheel/gedeeltelijk overlappen wordt om die reden afgekeurd.

In 2023 hebben deze onvolkomenheid in de TPOD-standaard ontdekt. Het oplossen van die onvolkomenheden leidt tot niet-backwards compatible wijzigingen. We hadden toen, vanwege het bevroren moeten zijn van de standaard, niet de mogelijkheid om niet-backwards compatible wijzigingen in de standaard te doen. Daarom hebben we in de TPOD’s een aantal werkafspraken toegevoegd over een Normwaarde die bedoeld is als gezamenlijke waarde voor meerdere geometrieën en over het aantal waarden van een Norm op 1 Locatie.

Nu, na inwerkingtreden van de Omgevingswet, is er wel ruimte voor niet-backwards compatible wijzigingen.

In de TPOD-standaard is hoogte een optioneel attribuut van Locatie, waarmee de hoogte kan worden aangegeven waarop de Locatie ligt. Het is bedoeld als een (zeer beperkte) benadering van 3D. STOP kent hoogte niet, het is geen kenmerk van het GIO of de OP-Locatie. Hoogte, dat bedoeld is juridische betekenis te hebben, kan daardoor niet rechtsgeldig bekend gemaakt worden.

In 2023 hebben deze onvolkomenheid in de TPOD-standaard ontdekt. Het oplossen van die onvolkomenheden leidt tot niet-backwards compatible wijzigingen. We hadden toen, vanwege het bevroren moeten zijn van de standaard, niet de mogelijkheid om niet-backwards compatible wijzigingen in de standaard te doen. Daarom hebben we aan de TPOD’s de werkafspraak ‘gebruik het attribuut hoogte niet’ toegevoegd. Nu, na inwerkingtreden van de Omgevingswet, is er wel ruimte voor niet-backwards compatible wijzigingen.

LVBB3000 moet geschrapt uit de validatiematrix. Dat wordt een nieuwe versie van de validatiematrix (v5.1) zonder regel LVBB3000.

Bij deze een wijzigingsverzoek voor nieuwe validatiematrix van LVBB/STOP in de bijlage.

Aanpassingen aan de validatiematrix die het Kadaster voorstelt:

Wijzigingen
• OZON0022    Er moet een RegelVoorIedereen, Instructieregel of Tekstdeel zijn die verwijst naar de Gebiedsaanwijzing
Deze regel valideert bij ons ook of er een Omgevingswaarderegel wijst naar de Gebiedsaanwijzing. Ik stel voor de tekst te wijzigen naar: Er moet een RegelVoorIedereen, Omgevingswaarderegel, Instructieregel of Tekstdeel zijn die verwijst naar de Gebiedsaanwijzing.

• OZON0069    (TPOD940) Als een Locatie uit meer dan één geometrie bestaat, dan moeten de geometrieën volgens dezelfde coordinate reference system (crs) zijn opgebouwd.
Ik kan geen referentie terugvinden naar TPOD940 dus ik stel voor de verwijzing daarnaar te laten vervallen.

• OZON0090    Iedere Divisie moet verwijzen naar een of meerdere Tekstdelen.
Geldt ook voor Divisietekst. Ik stel voor 'Iedere Divisie(tekst) moet verijzen naar een of meerdere Tekstdelen.

• OZON0098    (TPOD1850) Een Regeltekst die verwijst naar een RegelVoorIedereen, mag niet naar een Instructieregel of Omgevingswaarderegel verwijzen.
• OZON0099    (TPOD1850) Een Regeltekst die verwijst naar een RegelVoorIedereen, mag niet naar een Instructieregel of Omgevingswaarderegel verwijzen.
• OZON0100    (TPOD1850) Een Regeltekst die verwijst naar een RegelVoorIedereen, mag niet naar een Instructieregel of Omgevingswaarderegel verwijzen.
Hier staat drie keer hetzelfde. Hier zou moeten staan:
• OZON0098    (TPOD1850) Een Regeltekst die verwijst naar een RegelVoorIedereen, mag niet naar een Instructieregel of Omgevingswaarderegel verwijzen.
• OZON0099    (TPOD1850) Een Regeltekst die verwijst naar een Omgevingswaarderegel , mag niet naar een Instructieregel of RegelVoorIedereen verwijzen.
• OZON0100    (TPOD1850) Een Regeltekst die verwijst naar een Instructieregel , mag niet naar een RegelVoorIedereen of Omgevingswaarderegel verwijzen.

OZON0132 tekst graag aanpassen naar "Een aanlevering met een Geometrie waarvan de 'id' gelijk is aan die van een eerder aangeleverde Geometrie, maar met een andere geometrie, wordt afgekeurd."

• OZON0218/OZON0219: wij valideren dit ook voor Juridische Regels resp. Tekstdelen. Dat graag toevoegen in de tekst.
Toevoegingen
Toevoegen van de volgende validatieregel:
• OZON1037 Een regeling die een tijdelijk deel is, mag zelf geen pons hebben.
Kan komen te vervallen

Samenvoegen/ontdubbelen
We hebben een tijd terug besloten om de 'dubbelingen' tussen TPOD en OZON regels te laten vervallen, en alleen de TPOD regels te handhaven. De OZON regels zijn dan implementaties daarvan (met duidelijke verwijzing naar de TPOD regel) maar hoeven niet apart daarvan in de Validatiematrix. Het lijkt me daarom prima om de volgende OZON-regels uit de Validatiematrix te halen: OZON0097, OZON0129, OZON0130, OZON0131, OZON2000 (verwijst naar TPOD2000), OZON2040, OZON2060, OZON2140, OZON2150, OZON2210, OZON5001, OZON5002, OZON5003, OZON5004

Verwijzingen naar TPOD-regels
Er wordt vanuit de OZON-regels verwezen naar TPOD940, TPOD1850, TPOD2180. Waar kan ik deze (de oorspronkelijke TPOD-regels) terugvinden? Als de verwijzingen hier gecorrigeerd zijn, dan kunnen ook hier de afzonderlijke OZON-regels samengevoegd/ontdubbeld worden.

Interne validaties
De volgende validaties kunnen wat mij betreft komen te vervallen uit de Validatiematrix, aangezien het interne validaties betreft (d.w.z. fouten in de interne planketen, dus tussen de LV's). Het bevoegd gezag en/of de plansoftwareleverancier krijgt van ons in deze gevallen wel een melding, maar kan deze zelf niet verhelpen. Dat geldt voor de volgende regels: OZON0220, OZON1019, OZON1020, OZON1021, OZON1024, OZON1026, OZON1027, OZON1028, OZON1029, OZON1031, OZON1032, OZON1036, OZON1038, OZON1039, OZON1040.

Momenteel dwingen standaard en planketen niet af dat geometrie binnen de landsgrenzen van Nederland moet liggen. Om technische problemen te voorkomen is het wenselijk dat geometrische informatie die verwerkt wordt binnen de planketen en aangeleverd wordt aan de Landelijke Voorzieningen, binnen de Nederlandse landsgrenzen liggen:

• DSO-LV maakt een set Vector Tiles van de aangeleverde geometrie. Wanneer de aangeleverde geometrie niet binnen (of in de buurt van) Nederland ligt, dan wordt deze set onbeheersbaar groot.
• Het is nodig om te controleren dat de aangeleverde geometrie betekenisvol geïnterpreteerd kan worden binnen een bepaald coördinatenstelsel. Als een aanleverende partij bijvoorbeeld RD-geometrie aanlevert, maar dit per ongeluk markeert als ETRS-89 geometrie (of andersom) is het wenselijk dat OZON dat detecteert en de aanleverende partij op de hoogte stelt van de fout. Dit kan nu niet, aangezien OZON nu, wegens het ontbreken van een verplichting in de TPOD-standaard, geen inhoudelijke controle kan doen op het bereik van de coördinaten. Valideren op geometrische extent is een manier om dit mogelijk te maken.
• Bij transformatie van RD naar ETRS89 en andersom wordt het transformatie-algoritme RDNAPTRANS2018 gebruikt. Onderdeel hiervan is een rechthoekig correctiegrid dat heel Nederland afdekt. De transformatie is alleen gedefinieerd binnen de grenzen van dit correctiegrid. Geometrie daarbuiten kan dus niet betekenisvol getransformeerd worden , en is daarmee binnen de Landelijke Voorziening niet bruikbaar.

Om deze redenen wordt voorgesteld om aan IMOW een regel toe te voegen die het verbiedt om bij (besluiten tot instelling of wijziging van) omgevingsdocumenten geometrie aan te leveren die ligt buiten de boundingBox

(RD) respectievelijk

(ETRS89). Aan de validatiematrix wordt een corresponderende validatieregel toegevoegd.

Dit leidt tot een technische validatie. Doel van deze validatie is om het naar behoren functioneren van de landelijke voorziening te beschermen. Deze technische validatie moet snel en efficiënt uitgevoerd kunnen worden. Daarom is gekozen voor validatie aan de hand van een bounding box rondom de geometrie van Nederland + exclusieve economische zone, die aan alle zijden naar buiten toe is afgerond op de eerste gehele kilometer om afrondingsfouten te voorkomen en om bruikbare getallen te hebben. Zie de bijlage voor een afbeelding van deze bounding box, waarin de RD- en ETRS-bounding boxes zijn geprojecteerd op een kaart van Nederland (de trapeziumvormige veelhoek is RD, de rechthoek is ETRS89). Valideren met een bounding box is sneller en efficiënter dan met een gedetailleerde geometrie.

Deze validatie zorgt ervoor dat de technische problemen niet optreden:

• De bounding box, waarmee het gebied is vastgelegd waarbinnen de geometrie van omgevingsdocumenten moet liggen, is kleiner dan het Vector Tile grid dat DSO-LV hanteert. Daardoor wordt de set Vector Tiles niet onbeheersbaar groot.
• De bounding box is kleiner dan het RDNAPTRANS2018 correctiegrid dat wordt gebruikt voor de transformatie van RD naar ETRS89 en omgekeerd. Betekenisvolle transformatie is daardoor altijd mogelijk.
• Juridisch gezien kunnen omgevingsdocumenten geen regels en beleid stellen voor het gebied dat buiten Nederland + exclusieve economische zone valt. Daarom is aangeleverde Geometrie die buiten de bounding box ligt onjuist en is het terecht dat het aanleverende bevoegd gezag van deze fout op de hoogte wordt gesteld door middel van een blokkerende foutmelding bij de validatie.

Het is een Z-wijziging omdat het het expliciet vastleggen van een al geldende regel betreft. In de Omgevingswet is expliciet bepaald dat deze wet geldt binnen Nederland en de exclusieve economische zone. Juridisch gezien kunnen bevoegde gezagen in omgevingsdocumenten geen regels en beleid stellen buiten dat gebied. In IMOW is nu al vastgelegd dat RD of ETRS89 gebruikt moet worden. Buiten de extent van de nu voorgestelde bounding box is RD niet zinvol gedefinieerd.