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.

In het informatiemodel IMG versie 2.1.0 staan 57 regels opgeschreven.
Het is gewenst dat deze regels allemaal logisch, leesbaar en eenduidig zijn. Het blijkt echter dat deze regels dat nog lang niet allemaal zijn. Zeker wanneer de richtlijn van Rulespeak hierover gevolgd wordt.
De regels zijn geïnventariseerd. Waar ze eenduidig waren maar nog niet conform Rulespeak, zijn verbeterde regels voorgesteld.
Waar ze niet eenduidig waren is aan RIVM gevraagd de regels zodanig aan te passen dat ze wel eenduidig zijn.
Sommige regels bleken geen regel, overbodig of eerder een toelichting te zijn.

Alle regels waar nodig aanpassen zodanig dat ze logisch, leesbaar en eenduidig worden.

-Wie gaat er wat van merken? Gebruikers van het model krijgen regels aangeboden die logischer, leesbaarder en eenduidiger zijn. Aangenomen wordt dat de software die de regels nu toepast voor het inlezen van de data niet aangepast hoeft te worden, tenzij deze software de verkeerde betekenis heeft geïnterpreteerd bij niet eenduidige regels, maar daar wordt nog niet van uitgegaan.
-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 omgevingsregeling? Nee
-Is het een X, Y, of Z wijziging? Z, maar wel veel werk

Aanleiding wijziging
Bij het aanleveren van een Monitorresultaat van een geluidbron industrieterrein moet in de huidige standaard een object van het type Industrieterrein worden meegeleverd. Dit was niet de bedoeling. Het was de bedoeling dat in de aanlevering van het Monitorrresultaat een xlink zou zitten naar het Industrieterrein zoals aangeleverd in de vaststelling. Dit wijzigingsverzoek beschrijft een wijzing die het Terrein in plaats van het Industrieterrein zelf een link ernaar kan worden opgenomen,

Voorgestelde wijziging
In plaats van dat een Geluidgegevenscollectie het terrein opneemt als GeluidgegevenscollectieElement krijgt de klasse Geluidgegevenscollectie een optionele relatie naar een Terrein. In alle geval dat een collectie over een terrein gaat moet deze relatie gebruikt worden. Als het gaat om een Monitoringresultaat over een Terrein dan moet een link naar het eerder aangelverde terrein worden opgenomen. In andere gevallen het terrein zelf.

https://user-images.githubusercontent.com/2814052/230328798-99b164b6-13b0-474f-b4f3-ea8f9accb560.png

Impactanalyse
Deze wijziging heeft impact op iedereen die iets met Terreinen doet omdat de plaats van Terrein in het model verandert.
Ook het XML-schema verandert dus data providers en softwareleveranciers zullen hun software moeten aanpassen.
De verandering leidt niet tot nieuw in te winnen gegevens.
De wijziging heeft vooral impact op de aanlevering van monitoringresultaten die met het huidige schema nog niet mogelijk zit. Er hoeft dus iet opnieuw aangeleverd te worden.
Als je een monitoringresultaat gaat indienen zullen die er anders uitzien dus is het een x-wijziging.

Aanleiding wijziging
De relatie tussen Geluidproductieplafondobject en Terrein is alleen nodig voor industrieterreinen. Door de relatie te verplaatsen naar de subtypes Industrieterrein en GeluidproductieplafondobjectIndustrie wordt dit duidelijker en is hiervoor ook geen extra regel nodig die er overigens nog niet was.

Voorgestelde wijziging
Relatie tussen Geluidproductieplafondobject en Terrein verplaatsen naar subtypen voor industrie.
Het wordt een verplichte relatie van GeluidproductieplafondobjectIndustrie naar Industrieterrein:

https://user-images.githubusercontent.com/80040145/220091971-7b1879fe-46b1-49d8-9473-50c94cc82318.png

Impactanalyse

Wie gaat er wat van merken? Softwareleveranciers die het xml-schema gebruiken
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 xml-schema? Ja
Is het backward compatible in de zin van validatie op het schema? Ja
Is er een herlevering nodig naar de CVGG? Als de CVGG in productie was zou een herlevering nodig zijn wanneer er relaties zouden bestaan van subtypen die geen industrie subtype zijn, maar dat zou eigenlijk al niet de bedoeling zijn.
Heeft het impact op de regels in IMG? Nee
Heeft het impact op de omgevingsregeling? Nee
Is het een X, Y, of Z wijziging? vermoedelijk Y

Aanleiding wijziging
In IMGeluid is momenteel geen regel opgenomen dat aanleveringen van het type 'monitoringresultaat' of ' brongegevens monitoring' betrekking moeten hebben op jaren die in het verleden liggen. Het is nu mogelijk om een jaar in toekomst op te geven. Dat is niet wenselijk en kan leiden tot het niet goed verwerken van de gegevens in de CVGG.

Voorgestelde wijziging
Toevoegen van volgende regel bij Geluidgegevenscollectie.jaar

Geluidgegevenscollectie.jaar moet in het verleden liggen als Geluidgegevenscollectie.type = "monitoringresultaat" of "brongegevens monitoring".

Impactanalyse
-Wie gaat er wat van merken? Data providers, validatiesoftware-bouwer
-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 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 omgevingsregeling? Nee
-X,Y, Z-wijziging: Z

Het aanleveren van twee gegevensgroepen voor intensiteit en snelheid bij SpoordeelGPP en SpoordeelBGE was toegespitst op aanleveringen van Prorail, maar niet handig voor andere leveranciers. Niet alle gegevens zijn relevant en er zit overlap in voor wat betreft snelheid.

Het samenvoegen van de 2 gegevensgroepen IntensiteitgegevensSpoor en SnelheidgegegevensSpoor tot 1 groep IntensiteitgegevensSpoor met de volgende attributen:

<img:intensiteit>
  <img:intensiteit>0</img:intensiteit>
  <img:profieltypeSnelheid>doorgaand</img:profieltypeSnelheid>
  <img:spoorvoertuigcategorie>2</img:spoorvoertuigcategorie>
  <img:dagdeel>nacht</img:dagdeel>
  <img:snelheid>67</img:snelheid>
  <img:remindicatie>false</img:remindicatie>
  <img:treintype>reizigers</img:treintype>
  <img:rijrichting>oplopend</img:rijrichting>
  <img:materieelnaam>MAT64</img:materieelnaam>
</img:intensiteit>

De laatste 3 zijn optioneel en krijgen dus kardinaliteit

.

• Wie gaat er wat van merken? Data providers, software leveranciers, de API, gebruikers
• Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Niet echt, behalve dat de gegevensgroep intensiteit meer omvattend wordt.
• Heeft het impact op het xml-schema? Ja
• Is het backward compatible in de zin van validatie op het schema? Nee, want er verdwijnt een gegevensgroep.
• Heeft het impact op de regels in IMG? Nee
• Heeft het impact op de omgevingsregeling? Ja
• X,Y,Z-wijziging: X

Niet meer toestaan van wijzigingsmethode Intrekken & vervangen als alternatief voor renvooi.

Er zijn twee aanleidingen voor dit voorstel: 1. Uitgangspunt van de STOP/TPOD-standaard is dat voor het wijzigen van tekst gebruik gemaakt wordt van de wijzigingsmethode renvooi. Als tijdelijke alternatieve maatregel was het toegestaan om als alternatief daarvoor gebruik te maken van de wijzigingsmethode Intrekken & vervangen, met de boodschap dat deze mogelijkheid op enig moment zou vervallen. Inmiddels hebben we een verbeterd alternatief, Integrale tekstvervanging. Alle plansoftware is inmiddels overgegaan op Integrale tekstvervanging of op renvooi. Intrekken & vervangen als (tijdelijke) alternatieve wijzigingsmethode is daarom niet meer nodig. 2. Het niet meer gebruiken van Intrekken & vervangen als alternatieve wijzigingsmethode is een vereiste voor het invoeren van functionaliteit die OW-objecten aan Regelingen toekent.

Omgevingsdocumenten hebben de vorm van een regeling die in de loop van de tijd met wijzigingsbesluiten gewijzigd wordt. Uitgangspunt van de STOP/TPOD-standaard is dat de wijzigingsbesluiten voor het wijzigen van tekst gebruik maken van de wijzigingsmethode renvooi: een wijzigingsmethode waarbij in het besluit alleen de onderdelen staan die gewijzigd worden, waarin de verwijderde, gewijzigde en toegevoegde tekst wordt gemarkeerd. De STOP/TPOD-standaard kent daarnaast Intrekken & vervangen, als reguliere methode wanneer een bestuursorgaan een bestaande regeling helemaal wil intrekken en die regeling wil vervangen door een nieuwe regeling. Er is dan zowel juridisch als technisch sprake van intrekken en vervangen. Een voorbeeld is de provincie die de omgevingsvisie Mooi Provincieland intrekt en vervangt door de omgevingsvisie Gaaf Provincieland, waarin geheel nieuw beleid is vastgelegd. Door gebruik te maken van de (reguliere) wijzigingsmethode Intrekken & vervangen (in plaats van de oorspronkelijke regeling in te trekken en geheel separaat de nieuwe regeling te publiceren) wordt benadrukt dat weliswaar sprake is van een geheel nieuwe regeling, maar dat er wel een relatie bestaat tussen de oude en de nieuwe regeling.
Renvooi bleek voor plansoftware erg complex. Daarom hebben we toegestaan dat gebruik gemaakt wordt van Intrekken & vervangen als alternatieve wijzigingsmethode wanneer het toepassen van renvooi technisch nog niet mogelijk is. Met deze methode wordt de juridische wijziging technisch uitgevoerd met Intrekken & vervangen. Deze mogelijkheid is, o.a. in de TPOD's, duidelijk gepresenteerd als tijdelijke alternatieve maatregel, waarvan de toepassing vanaf invoering van Release B niet meer zou zijn toegestaan.
In STOP is Intrekken & vervangen als alternatief voor renvooi niet anders dan regulier Intrekken & vervangen: de aanlevering bestaat uit een intrekking van de oude regeling (waarbij automatisch alle GIO's worden ingetrokken) en een nieuwe regeling waarin de opvolgingsrelatie wordt aangegeven. In IMOW werkt Intrekken & vervangen als alternatief voor renvooi wel anders dan regulier Intrekken & vervangen. Bij regulier Intrekken & vervangen moet het bevoegd gezag alle OW-objecten van de in te trekken regeling beëindigen; de nieuwe regeling krijgt geheel eigen OW-objecten. Bij Intrekken & vervangen als alternatief voor renvooi moeten de OW-objecten die direct met de regeling verbonden zijn (Regeltekst, Divisie, Divisietekst, Pons, Regelingsgebied) voor zover ze in de nieuwe regeling blijven bestaan wel opnieuw aangeleverd worden, maar ze hoeven niet beëindigd te worden. Dit is een uitzondering op de uitgangspunten voor het wijzigen van objecten in IMOW. Door deze uitzondering is het niet mogelijk om OW-objecten aan regelingen toe te kennen, er is dan onduidelijkheid of de OW-objecten bij de oude of bij de nieuwe regeling horen.

Al snel bleek dat Intrekken & vervangen (als alternatieve toepassing) nadelen heeft, met name wanneer bij de regeling een of meer tijdelijk regelingdelen behoren; dan is Intrekken & vervangen niet mogelijk. Daarom hebben we een verbeterd alternatief ontwikkeld, de wijzigingsmethode Integrale tekstvervanging. Aan de STOP-kant wordt bij deze methode niet de regeling maar de regelingversie ingetrokken en vervangen door een nieuwe regelingversie. Aan de IMOW-kant worden bij Integrale tekstvervanging alle uitgangspunten voor renvooi-wijzigen onverkort toegepast; de uitzonderingen die bij Intrekken & vervangen worden gemaakt voor Regeltekst, Divisie, Divisietekst, Pons en Regelingsgebied zijn hierbij niet van toepassing. Integrale tekstvervanging is wel mogelijk als bij de regeling een of meer tijdelijk regelingdelen behoren.

Alle plansoftware is inmiddels overgegaan op Integrale tekstvervanging of op renvooi. Intrekken & vervangen als (tijdelijke) alternatieve wijzigingsmethode is daardoor niet meer nodig. Daarom kunnen we overgaan tot het niet meer toestaan van Intrekken & vervangen als (tijdelijke) alternatieve wijzigingsmethode.
Het gebruik van Intrekken & vervangen als regulier mechanisme om een regeling in te trekken en te vervangen door een nieuwe regeling blijft uiteraard wel toegestaan.

Aanleiding wijziging
Het attribuut bronobjectID is vooral bedoeld om REV-json datasets te kunnen koppelen met locaties/inrichtingen in een bronsysteem. Aangezien een REV-json dataset bij wijzigingen compleet aangeleverd moet worden, ligt het voor de hand dat voor verschillende onderdelen van deze dataset hetzelfde bronobjectID aanhouden. In het bronsysteem van onze omgevingsdienst (OpenWave van de ODR) zal waarschijnlijk het inrichting nummer gekozen worden als het te gebruiken bronobjectID. Dit is alleen relevant voor de locatie. Door de ingevulde waarde in het veld 'bronobjectID' automatisch over te nemen, is bij raadplegen van elk EV-object (locatie, EV-activiteit, referentie of EV-contour) duidelijk bij welk bronobjectID (locatie of inrichting) dit hoort. Eventueel zou het optionele veld 'bronobjectID' uit EV-objecten EV-activiteit, referentieEVContour en EVContour verwijderd kunnen worden, tenzij bronsysteem leveranciers het gewenst vinden dat dit toch zo blijft staan in het IMEV. Verwachting is dat bronhouders het niet nodig vinden om verschillende bronobjectID's per niveau in te vullen.

Voorgestelde wijziging
Attribuut bronobjectID verplaatsen van ExterneVeiligheidsObject naar LocatieEVActiviteit.

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
De adviesgroep heeft besloten het niet te doen. Het attribuut is nog maar net toegevoegd en heeft zijn nut nog niet kunnen bewijzen in de praktijk.

Zie ook https://github.com/Geonovum/imev-werkomgeving/issues/95#issuecomment-1462087255 en opmerkingen daarna.