Meldingen geo-standaarden

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.

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.

Eerst de impliciete mutatie validaties . LVBB5002 en LVBB5010 vervallen en worden vervangen door LVBB5023 t/m LVBB5030

LVBB5023

Rule: De RegelingMutatie MAG GEEN toe te voegen wId's bevatten die reeds voorkomen in de was-versie

Melding: In de RegelingMutatie komen de volgende toe te voegen wIds reeds voor in de was-versie: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

LVBB5024

Rule: In de RegelingMutatie komen de volgende toe te voegen wIds reeds voor in de was-versie: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

Melding: In de RegelingMutatie komen de volgende te verwijderen wIds niet voor in de was-versie: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

LVBB5025

Rule: De RegelingMutatie MAG GEEN impliciet toegevoegde wId's in de vervang-mutatie bevatten

Melding: Bij verwerking van de RegelingMutatie komen de volgende impliciet toegevoegde wIds voor in de wordt-versie: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

LVBB5026

Rule: De RegelingMutatie MAG GEEN impliciet verwijderde wId's in de vervang-mutatie of verwijder-mutatie bevatten

Melding: Bij verwerking van de RegelingMutatie komen de volgende impliciet verwijderde wIds voor in de wordt-versie: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

LVBB5027

Rule: De @context in de RegelingMutatie MOET bestaan in de wordt-versie

Melding: In de RegelingMutatie worden de volgende wIds als context gebruikt, maar komen niet voor in de was-versie en worden ook niet toegevoegd: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

LVBB5028

Rule: De RegelingMutatie MAG GEEN kind-elementen in de vervang-mutatie of verwijder-mutatie gebruiken die niet voorkomen in de was-versie

Melding: Binnen RegelingMutatie heeft de verwijder / vervang mutatie
voor wId %1 de volgende wIds die niet als child voor deze wId in de was-versie voorkomen: %2. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

*LVBB5029*

Er is nog een interne diiscussie over de precieze regel. Ik zou dit voorlopig even leeglaten.

LVBB5030

Rule: Elk expliciet toegevoegd element MOET uiteindelijk in de wordt-versie terecht komen.

Melding: In de RegelingMutatie hebben de volgende toe te voegen wIds
geen parent in de wordt-versie: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

=========

Hieronder staan nog meer validaties die in andere stories toegevoegd worden/zijn.

LVBB1579
Regel: Publicatieopdracht MAG NIET worden afgebroken als de wetstechnische informatie, die voortkomt uit deze opdracht, al gepubliceerd is

Foutmelding: De opdracht kan niet worden afgebroken. De wetstechnische informatie, die voortkomt uit de opdracht met oin %1 en idlevering %2, is al gepubliceerd.

LVBB1575

Rule: Het manifest.xml MOET unieke bestanden bevatten

Melding: Een bestand in het manifest.xml is niet uniek en dat is niet toegestaan.

LVBB1576

Rule: Besluit dat afgebroken moet worden mag geen regeling intrekken waarvan de intrekking al gepubliceerd is.

Melding: De opdracht kan niet worden afgebroken. Intrekking van regeling met akn %1 is al gepubliceerd.

LVBB1577

Rule: Besluit dat afgebroken moet worden mag geen informatieobject intrekken waarvan de intrekking al gepubliceerd is.

Melding: De opdracht kan niet worden afgebroken. Intrekking van informatieobject met join %1 is al gepubliceerd.

LVBB4046

Rule: De volgende elementen binnen RegelingMetadata MOGEN NIET worden gewijzigd:

• Eindverantwoordelijke
• Opvolging
• SoortRegeling
• Maker

Melding: Element %1 in de RegelingMetadata is gewijzigd. Dat mag niet.

LVBB4047

De volgende elementen binnen InformatieobjectMetadata MOGEN NIET worden gewijzigd:

• Eindverantwoordelijke
• FormaatInformatieobject
• Opvolging
• Publicatieinstructie
• Maker

Melding: Element %1 in de InformatieobjectMetadata is gewijzigd. Dat mag niet.

*LVBB4500*

regel: Terugtrekkingen in de consolidatieinformatie MOGEN NIET gebruikt worden.

melding: Het is niet toegestaan terugtrekkingen in de consolidatieinformatie te gebruiken.

*LVBB5022*

Rule: Een definitief besluit met een RegelingTijdelijkdeel MAG NIET een tijdelijk deel zijn van een ontwerpregeling

Melding: Het is niet mogelijk om een RegelingTijdelijkdeel aan te maken die een tijdelijk deel is van een ontwerpregeling. Regeling %1 is een ontwerpregeling.

LVBB5031

Rule: Een tekst:Vervang met @revisie=1 in een RegelingMutatie MAG GEEN renvooi-elementen of @context bevatten

Melding: In de RegelingMutatie bevat de Vervang met @revisie=1 van wid/wat %1 renvooi elementen en/of een @context. Dit is niet toegestaan.

*LVBB5900*

Rule: Een directe mutatie MAG NIET worden gedaan op een ontwerpregeling

Melding: Het is niet mogelijk om een directe mutatie te doen op een ontwerpregeling.

Met vriendelijke groet,

*Brigitte Meijer*

*Informatieanalist LVBB*

........................................................................

Logius

Ministerie van Binnenlandse Zaken en Koninkrijksrelaties

........................................................................

06 – 380 567 20

www.logius.nl| https://koop.overheid.nl

brigitte.meijer@koop.overheid.nl

........................................................................

Sinds 1 januari 2023 is KOOP onderdeel van Logius

Logius is continu op zoek naar nieuwe collega’s: bekijk alle vacatures op onze website.

Samen zorgen we voor een digitale overheid die werkt voor iedereen!

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

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