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

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 .

Verzoek van KOOP om de validatiematrix aan te passen.

Verwijderen: LVBB4602 LVBB4603

Nieuw: LVBB1042 LVBB4740 LVBB4763

Gewijzigd: LVBB1041 LVBB1555 LVBB1556 LVBB1557 LVBB4711 LVBB4762 LVBB5013

Aanleiding wijziging
Het alleen melden van de eenheden in de definitie is foutgevoelig. Softwareleveranciers kunnen het hierdoor niet automatisch opnemen in hun software.

Voorgestelde wijziging
Opnemen van eenheden als apart attribuut heroverwegen.

Impactanalyse
Wie gaat er wat van merken? Dataleveranciers, Softwareleveranciers
Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
Heeft het impact op het json-schema? Ja
Is het backwardscompatibel? Nee
X-, Y- of Z-wijziging: X

Toelichting
Deze wijziging is eerder door de expertgroep beperkt tot het opnemen in de definitie.
zie #31 (comment) en #31 (comment).

Daarna is het opnieuw aangekaart door Geodan, maar vervolgens is door de advies geadviseerd het te laten bij een beschrijving van de eenheid in de definitie. zie https://github.com/Geonovum/imev-werkomgeving/issues/31#issuecomment-1551580597

Monitoringresultaat objecten moeten altijd naar 1 Geluidproductieplafond of naar 1 Basisgeluidemissie object verwijzen. Dit staat momenteel niet duidelijk in de standaard.

De standaard zodanig aanpassen dat een Monitoringresultaat altijd de juiste verwijzing heeft door een nieuwe subklasse GemonitordObject toe te voegen voor Geluidproductieplafondobject of Basisgeluidemissieobject.

Het UML ziet er dan als volgt uit:
https://user-images.githubusercontent.com/2814052/231695841-5886df6d-8ee3-4af1-9b90-758fa56e0e64.png.

• Inhoudelijk verandert de standaard niet: dezelfde gegevens moeten worden aangeleverd.
• In de uitwisseling zullen de twee optionele verwijzingen die nu in Monitoringresultaat zitten (te weten: geluidproductieplafondobject en basisgeluidemissieobject) anders gaan heten (namelijk: gemonitordObject). Hiervoor moet de lees- en schrijffunctionaliteit voor het object Monitoringresultaat in software aangepast worden. Daarom is het een X-wijziging.