Met directe mutaties kunnen alle OW-objecten gewijzigd worden. Onder wijzigen vallen het veranderen van een of meer attributen van een OW-object en het beëindigen van een OW-object. De OW-objecten Regeltekst, Juridische regel, Divisie, Divisietekst, Tekstdeel, Locatie en Normwaarde zijn onlosmakelijk verbonden met de teksten en GIO's van de bekendmaking en de geconsolideerde regeling op http://overheid.nl . Een directe mutatie van die objecten kan leiden tot verschillen tussen de regeling op http://overheid.nl en de regeling in het DSO. Dit levert een groot juridisch risico op. Daarbij komt dat directe mutaties zelf geen tijdgegevens hebben. Directe mutaties worden daarom gekoppeld aan het Doel en daarmee aan de tijdslijnen van het oorspronkelijke besluit. Daarmee hebben directe mutaties terugwerkende kracht en zijn de wijzigingen niet te traceren: er is geen juridisch verantwoordingsspoor. We merken dat het bestaan van de mogelijkheid van directe mutaties leidt tot twijfel aan de juridische betrouwbaarheid van omgevingsdocumenten in het DSO. Door met een directe mutatie en dus met terugwerkende kracht een Activiteit te beëindigen verdwijnen de toepasbare regels bij die Activiteit. Daardoor is er geen aanvraagformulier meer, leidt de Vergunningcheck tot een andere uitkomst en kan een gedane vergunningaanvraag niet meer aangevuld worden. Conclusie is dat directe mutaties onwenselijk zijn.

Directe mutaties waren ooit gedacht voor foutherstel en vooral voor het achteraf annoteren: stapsgewijs komen van minimum tot rijk geannoteerde regelingen. In de praktijk zien we dat het annoteren onlosmakelijk verbonden is met het schrijven van teksten in de plansoftware: je doet het tegelijk. Bij de Aanleiding Wijziging Standaard is al aangegeven dat directe mutaties onwenselijk zijn omdat ze leiden tot het juridische risico dat er verschillen ontstaan tussen de regeling op http://overheid.nl en de regeling in de DSO-viewer, verminderde betrouwbaarheidsperceptie van de regeling in de DSO-viewer en tot problemen bij de Vergunningcheck en het aanvragen van vergunningen en doen van meldingen. Iemand die een regeling voor én na een directe mutatie bekijkt, krijgt beide keren iets verschillends te zien. Door de terugwerkende kracht van directe mutaties hebben krijgt deze persoon bij een tijdreis terug naar de eerste raadpleegdatum iets anders te zien dan toen hij/zij op die datum de regeling bekeek. Het met een directe mutatie beëindigen van een Activiteit leidt er toe dat de vergunningcheck voorafgaand aan de directe mutatie een andere uitkomst heeft dan daarna, zonder dat dat inziichtelijk is. Een ingediende vergunningaanvraag kan na de directe mutatie niet meer aangevuld worden. We hebben database-onderzoek gedaan. Daaruit hebben we geconcludeerd dat directe mutaties de laatste maanden nagenoeg niet meer worden aangeleverd door bevoegde gezagen en dat ze alleen nog (beperkt) worden ingezet door de beheerders van het stelsel om problemen met vastzittende regelingen op te lossen. Deze constateringen hebben geleid tot het wijzigingsvoorstel. Dat heeft deze onderdelen: 1. De beschrijving van directe mutaties in IMOW wordt zodanig aangepast dat duidelijk is dat directe mutaties niet door bevoegde gezagen aan het BHKV aangeleverd mogen worden Dit is een wijziging die niet backwards compatible is. Daarom is het een X-wijziging 2. In de CPA's van alle bevoegde gezagen wordt niet de mogelijkheid opgenomen om directe mutaties van OW-objecten aan te leveren De CPA is de Collaboration Protocol Agreement. Dit is het digitale contract met het bevoegd gezag voor gegevensuitwisseling op Digikoppeling van Logius. In de CPA wordt bepaald welke opdrachten een bevoegd gezag mag aanleveren (en met welke software). 3. Directe mutaties van OW-objecten die nodig zijn voor het oplossen van problemen met een vastzittende regeling kunnen alleen worden uitgevoerd door beheerders van het stelsel, op aanvraag van het bevoegd gezag Als een regeling helemaal vastzit door problemen met OW-objecten, kan het bevoegd gezag bij LVBB/OZON assistentie aanvragen. De beheerders kunnen dan met directe mutaties het probleem oplossen. Het bevoegd gezag kan vervolgens met de downloadservice de aangepaste bestandenset van de regeling downloaden en in de eigen software importeren.

In het operationeel overleg met de leveranciers is er instemming bereikt over nieuwe validatieregels en tevens besproken met alle andere betrokken partijen:

1. Er mag hoogstens één Regeltekst-object naar een Artikel/Lid verwijzen.

1. Er mag hoogstens één OW Divisie-object naar een OP Divisie verwijzen.

1. Er mag hoogstens één OW Divisietekst-object naar een OP Divisietekst verwijzen.

Aanleiding

Bij OZON zijn we bezig met werkzaamheden om te zorgen dat geometrieën zodanig opgeslagen worden dat GIO’s ontvangen kunnen worden ( hierbij worden geometrieën los opgeslagen van de OW-locatie-versies). N.a.v. deze werkzaamheden zijn we erachter gekomen dat het gebeurt dat er geometrie-identificaties andere geometrieën bevatten.

Validatie
We willen afkeuren dat dit gebeurt, want het zorgt voor vervelende situaties, zoals onzekerheid of het DSO en de LVBB dezelfde coördinaten tonen. (Zo hebben twee gemeenten nu afwijkende coördinaten, maar dezelfde identificatie, waardoor in principe bij het muteren er gekke situaties kunnen ontstaan.)

Volgens ons is het mogelijk om een validatie die al blijkt uit de standaarden aan te bieden bij het CAB (LINK).

Bron
In STOP staat: “ Indien de geo:id (de GUID, zie Basisgeometrie) van twee geometrieen gelijk is, moet de daadwerkelijke geometrie ook dezelfde zijn.” (LINK)

In IMOW staat: “ Altijd moet de geometrie behorende bij ‘d0993715-c485-4e63-b35d-8f68c3cbee3b’ inhoudelijk dezelfde zijn ” (LINK)

Validatie voor kennisname bij CAB

Kortom, gezien de bovenstaande claims uit de standaarden wilden we de volgende validatie ter kennisname aanbieden bij het CAB:

OZON0132: Een aanlevering met een Geometrie waarvan de ‘id’ gelijk is aan een id met een andere geometrie mag niet.

Aanleiding wijziging

• Het object monitoringresulaat wordt zowel gebruikt voor een GPP als een BGE. In het geval van een BGE bevat de monitoringswaarde het verschil tussen de geluidemissie in Lden en de basisgeluidemissie, in het geval van een GPP bevat de monitoringwaarde de berekende geluidwaarde. Dat staat weliswaar beschreven in de toelichting, maar is niet duidelijk beschreven in de definitie van het attribuut monitoringwaarde ansich. Graag duidelijk beschrijven in de definitie, zodat dit eenduidig is voor de gebruiker.
• De monitoringwaarde van een BGE bevat een verschil. Dat betekent dat de monitoringwaarde ook negatief kan zijn. In de xsd wordt echter afgedwongen dat de waarde 0 of groter moet dan. Dat klopt niet en moet worden aangepast.

Voorgestelde wijziging

• De regel "Een gemeente of waterschap mag de basisgeluidsemissie (BGE) ook schriftelijk onderbouwen. In dat geval hoeft geen monitoringswaarde opgegeven te worden." verwijderen bij het objecttype Monitoringresultaat.
• De definitie bij Monitoringresultaat en bij het attribuut Monitoringresultaat.monitoringwaarde aanpassen Zoals aangegeven door RIVM.
• De minimum- en maximumwaardeBij het attribuut Monitoringresultaat.monitoringwaarde aangepassen naar -199.9 en 199.9.

Impactanalyse
-Wie gaat er wat van merken? Data providers, softwareleveranciers
-Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
-Is er een herlevering nodig naar de CVGG? Nee
-Heeft het impact op het xml-schema? Ja
-Is het backward compatible in de zin van validatie op het schema? Ja
-Heeft het impact op de regels in IMG? Ja
-Heeft het impact op de validatieregels voor de CVGG? Ja
-Heeft het impact op de omgevingsregeling? Ja/Nee
-Is het een X, Y, of Z wijziging? Y

Aanleiding wijziging
Er zitten in IMG 3.0 drie regels die niet werkbaar zijn in de praktijk.

Voorgestelde wijziging
Het verzoek is de volgende regels te verwijderen:

• Bij GeluidbronIndustrie.brontype: "Geluidbron­Industrie.brontype mag niet gelijk zijn aan "normale puntbron" als er sprake is van een relatie met een Vlakbron­Industrie of Lijnbron­Industrie."
• Bij VlakbronIndustrie.geometrie: "Alle z-coördinaten in VlakbronIndustrie.geometrie moeten dezelfde waarde hebben."
• Bij Brug.geometrie: "Alle z-coördinaten in VlakbronIndustrie.geometrie moeten dezelfde waarde hebben."

Impactanalyse
-Wie gaat er wat van merken? Data providers, softwareleveranciers
-Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
-Is er een herlevering nodig naar de CVGG? Nee.
-Heeft het impact op het xml-schema? Nee
-Is het backward compatible in de zin van validatie op het schema? Ja
-Heeft het impact op de regels in IMG? Ja
-Heeft het impact op de validatieregels voor de CVGG? Ja
-Heeft het impact op de omgevingsregeling? Nee
-Is het een X, Y, of Z wijziging? Z

Bevoegde gezagen leveren besluiten met daarbij OW-objecten aan aan de LVBB. De LVBB levert deze OW-objecten door aan OZON. OZON beheert de OW-objecten. In OZON zijn de OW-objecten niet toegekend aan een specifieke regeling. Daardoor is OZON nu in feite één grote registratie van OW-objecten. Deze situatie is om een aantal redenen onwenselijk:

• Het bevoegd gezag moet bij het intrekken van een regeling alle bij die regeling behorende OW-objecten expliciet beëindigen. OZON kan nu echter niet controleren of daadwerkelijk alle objecten zijn beëindigd omdat OZON niet weet welke OW-objecten bij die regeling horen. Daardoor is het mogelijk dat er OW-objecten in OZON aanwezig blijven waarvan de juridische basis is vervallen.
• Bij eventuele migratietrajecten in de toekomst die door het stelsel uitgevoerd moeten worden is het zeer wenselijk om OW-objecten per Regeling te migreren, maar zonder kennis van welke OW-objecten bij welke regeling horen is dit niet mogelijk.

Het is nu mogelijk om met een besluit dat een regeling wijzigt elk willekeurig OW-object in OZON te wijzigen, dus ook OW-objecten van een andere regeling en/of een ander bevoegd gezag. Als een OW-object (per abuis) gewijzigd wordt door een ander bevoegd gezag kan dit grote impact hebben op de werking van het stelsel:

• Het kan gebeuren dat objecten in de viewer opeens niet meer getoond worden.
• Wijziging van een Activiteit werkt door in de functionele structuur van de RTR. Zulke wijzigingen kunnen onverwachte impact hebben op toepasbare regels.

Het is nu mogelijk om vanuit een regeling te verwijzen naar een OW-object in een andere regeling. Dat kan een regeling zijn van hetzelfde bevoegd gezag, maar ook van een ander bevoegd gezag. Als na het invoeren van het toekennen van OW-objecten aan Regelingen het bevoegd gezag de regeling waarnaar wordt verwezen wil wijzigen door een GIO te verwijderen en de bijbehorende OW-Locatie te beëindigen, of de volledige andere regeling wil intrekken, kan dat niet. Het is dan namelijk niet toegestaan om OW-objecten te beëindigen waarnaar verwezen wordt. Dat is omdat OZON niet kan omgaan met dode links. OZON zal in dat geval de beëindiging van de OW-Locatie (of, in het geval van intrekken van de regeling: alle OW-objecten) weigeren. Doordat er naar verwezen wordt, is de regeling waarnaar verwezen wordt als het ware vastgepind in het stelsel. Daarom is het wenselijk om beperkingen te stellen aan het kunnen verwijzen naar OW-objecten in andere Regelingen.

Aanleiding wijziging
De regel dat Geluidproductieplafondobject.eindVrijstelling in het verleden moet liggen, is op juistheid daarvan in de praktijk nog eens nagevraagd. De geformuleerde regel blijkt te strak, en in de praktijk tot problemen te leiden. De regel zal moeten vervallen.

Voorgestelde wijziging
Verwijder de regel dat Geluidproductieplafondobject.eindVrijstelling in het verleden moet liggen.

Impactanalyse
Geef hier een indicatie van de impact van de wijziging:
-Wie gaat er wat van merken? Data providers, softwareleveranciers
-Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
-Is er een herlevering nodig naar de CVGG? Nee.
-Heeft het impact op het xml-schema? Nee
-Is het backward compatible in de zin van validatie op het schema? Ja
-Heeft het impact op de regels in IMG? Ja
-Heeft het impact op de validatieregels voor de CVGG? Ja
-Heeft het impact op de omgevingsregeling? Nee
-Is het een X, Y, of Z wijziging? Z

Aanleiding wijziging
Het blijkt dat het attribuut SpoordeelGPP.maaiveld (voorheen SpoordeelGPP.spoordeelhoogte) niet nodig is.
Bij WegdeelGPP is hetzelfde attribuut verwijderd uit het model.

Voorgestelde wijziging
Het verzoek om het attribuut SpoordeelGPP.maaiveld te schrappen uit het IMG. Prorail is hiermee akkoord.

Impactanalyse
Geef hier een indicatie van de impact van de wijziging:
-Wie gaat er wat van merken? Data providers, softwareleveranciers
-Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
-Is er een herlevering nodig naar de CVGG? Nee
-Heeft het impact op het xml-schema? Ja
-Is het backward compatible in de zin van validatie op het schema? Ja, want dit attribuut is niet gebruikt.
-Heeft het impact op de regels in IMG? Ja. 1 regel minder
-Heeft het impact op de validatieregels voor de CVGG? waarschijnlijk niet
-Heeft het impact op de omgevingsregeling? Nee
-Is het een X, Y, of Z wijziging? Y

Toelichting
Bij overgang naar IMG v3.0 is het attribuut SpoordeelGPP.spoordeelhoogte vervangen door SpoordeelGPP.maaiveld.
Zie ook Github issue 183

Met de inwerkingtreding van de Wet digitale overheid per 1 juli 2023 worden overheden o.a. verplicht hun publiek toegankelijke websites en webapplicaties te beveiligen met de open standaarden HTTPS en HSTS.

 Het “Besluit beveiligde verbinding met overheidswebsites en ‑webapplicaties” verplicht overheidsorganisaties om hun publiek toegankelijke websites te beveiligen met de open standaarden HTTPS. In aanvulling op HTTPS moeten overheidsorganisaties ook de HSTS-standaard gebruiken. Dat zorgt ervoor dat browsers na een eerste websitebezoek direct via HTTPS verbinden met de website. Daarnaast moet de HTTPS-configuratie voldoen aan de TLS-richtlijnen en Webapplicatie-richtlijnen van het Nationaal Cyber Security Centrum (NCSC). Deze wet heeft gevolgen voor de RO Standaarden en specifiek voor het STRI2012.

In het STRI2012 staat in hoofdstuk 5.1 ‘Eisen aan de beschikbaarstelling’ en in hoofdstuk 7 ‘Toegankelijkheid en raadpleegbaarheid’ het volgende: “Het gebruik van een beveiligde HTTPS verbinding via TLS of SSL is optioneel.” Hierin ligt sinds 1 juli 2023 een probleem omdat sinds 1 juli het gebruik van HTTPS niet meer optioneel is.

Hierbij dient Roxit een verzoek in om te verwijderen uit de TPOD Voorbereidingsbesluit:

• de beschreven werkwijze voor het door de gemeente laten beëindigen of wijzigen van voorbeschermingsregels in een tijdelijk regelingdeel die door het Rijk of de Provincie zijn ingesteld middels een voorbereidingsbesluit.

Deze werkwijzes zijn beschreven in:
https://docs.geostandaarden.nl/tpod/def-st-TPOD-VB-20230407/#10D8BC72
https://docs.geostandaarden.nl/tpod/def-st-TPOD-VB-20230407/#44610DA2

In het kort komt mijn bezwaar er op neer dat hier middels een omweg eenzelfde complexiteit geïntroduceerd wordt, als die van het meervoudig bronhouderschap. De reden dat het tijdelijk regeling deel überhaupt bestaat.

Ik ben me er van bewust dat in de TPOD nu ook zinnen staan die het mogelijk maken om dit voorlopig niet te ondersteunen, zodat wij als plansoftware-leverancier deze mogelijkheid voorlopig zouden kunnen negeren. Om 2 redenen pleit ik toch voor op zo kort mogelijke termijn verwijderen:

1. als het in de TPOD staat, verwachten klanten dat het kan. Als dat niet nu is, dan hoort men graag wanneer wel
2. De werkwijze zoals nu beschreven is volgens mij niet goed en moet anders. Hoe eerder deze route wordt afgesneden, hoe minder kans er is dat mensen werk gaan doen om de huidige route toch te ondersteunen.

Toelichting
De werking
Als een andere bestuurslaag door middel van een tijdelijk regelingdeel wijzigingen aanbrengt op het Omgevingsplan, dan zijn die regels juridisch vervolgens van de gemeente en wel omdat ze het Omgevingsplan wijzigen. (Dit geldt overigens niet voor het Projectbesluit: hiervoor is bij wet vastgelegd dat de gemeente daar 3 jaar niet aan mag komen).

De gemeente zou dan zelf het tijdelijk regelingdeel moeten downloaden en intrekken en/of aanpassen indien gewenst.

In de afgelopen dagen is mij pas duidelijk geworden hoe deze functionaliteit zou moeten werken. Juridisch werkt dit volledig anders dan ik vanuit techniek zou verwachten. En bovendien (technisch) inconsistent, want afwijkend gedrag tussen voorbereidingsbesluit en projectbesluit.

Mijn bezwaren
De beschreven werkwijze gaat volledig in tegen mijn verwachtingen. Ik zie de volgende probleempunten, zonder er heel diep in te duiken.

1. De werkwijze gaat in tegen het principe: hij die plaatst, kan ook wijzigen en verwijderen (en anderen dus niet). Dat is een heilig principe dat overbleef na de discussies over meervoudig bronhouderschap
2. Identificaties. Alle identificaties die gebruikt worden zijn gebaseerd op de CBS code van degene die het voorbereidingsbesluit neemt, niet de ontvanger van het tijdelijk regelingdeel. Als de ontvanger de eigenaar wordt is dat raar/fout?
3. De eindverantwoordelijke voor het tijdelijk regelingdeel is degene die het instelt, niet de ontvanger. Als de ontvanger de eigenaar wordt is dat raar/fout?
4. De werkwijze is inconsistent met de werkwijze rond de bruidsschat. Die is ingesteld door het ministerie (<maker>/tooi/id/ministerie/mnre1034</maker>) , maar de eindverantwoordelijke is de ontvangende gemeente (<eindverantwoordelijke>/tooi/id/gemeente/gm0828</eindverantwoordelijke>). Ook alle identificaties zijn op basis van CBScode ontvangende gemeente.
5. De veronderstelde functionaliteit en van downloaden, importeren en op basis daarvan een wijziging/intrekking vervaardigen is nog lang niet "foolproof". Zeker omdat voor intrekken de exacte vorm van ooit geleverde objecten nodig is, biedt dit voorlopig nog wel flinke uitdagingen als software van de maker van het tijdelijk regelingdeel en de gemeente van elkaar verschillen .