Meldingen geo-standaarden

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.

*Aanleiding wijziging*

Het gaat om het attribuut ‘hoeveelheidVuurwerk’ op de volgende twee activiteiten: · VIII-A Explosieaandachtsgebied vuurwerk voor opslag van categorie F4 – detail · VIII-B Explosieaandachtsgebied vuurwerk voor opslag van categorie F1, F2, F3, of pyrotechnische artikelen voor theatergebruik van categorie T1 of T2 - detail Het attribuut ‘hoeveelheidVuurwerk’ wordt uitgevraagd op activiteit niveau. Als gebruiker geef je hier als het ware een totale hoeveelheid vuurwerk van alle bewaarplaatsen, bufferbewaarplaatsen en/of bewerkingsruimten op één locatieactiviteit. Dit is voor de gebruiker van de Invoer Module niet gewenst. Bijvoorbeeld: Het is mogelijk dat er 2 buffers staan op 1 locatieactiviteit. 1 buffer bevat 500 kg vuurwerk en 1 buffer bevat 1000 kg vuurwerk. Op dit moment moet je het getal 1500 invoeren op activiteitniveau. Als gebruiker wil je deze aantallen opvoeren per buffer.

*Voorgestelde wijziging*

1 Het voorstel is om bij 'OpslagVuurwerkF1F2F3T1T2 het volgende 'Inrichtingselement' toe te voegen 'Objecttype': Verkoopruimte

2a Om een 'Bewaarplaats' bij 'OpslagVuurwerkF4' te hernoemen naar een 'BewaarplaatsF4' (ivm afwijkend attribuut: 'hoeveelheidNEMBewaarplaats', zie onder)

2b Om een 'SamengesteldeReferentie' bij 'OpslagVuurwerkF4' te hernoemen naar een 'SamengesteldeReferentieF4' (ivm afwijkend attribuut: 'hoeveelheidNEMBewaarplaats', zie onder)

2c Om een 'Bewaarplaats' bij 'OpslagVuurwerkF1F2F3T1T2' te hernoemen naar een 'BewaarplaatsF1F2F3T1T2' (ivm afwijkend attribuut: 'hoeveelheidVuurwerkBewaarplaats', zie onder)

2d Om een 'SamengesteldeReferentie' bij 'OpslagVuurwerkF1F2F3T1T2' te hernoemen naar een 'SamengesteldeReferentieF1F2F3T1T2' (ivm afwijkend attribuut: 'hoeveelheidVuurwerkBewaarplaats', zie onder)

3a. om het attribuut 'hoeveelheidVuurwerk': Niet te verplaatsen maar te behouden bij: OpslagVuurwerkF4; Het voor OpslagVuurwerkF4 te hernoemen naar: 'hoeveelheidNEMLocatie'; De definitie aan te passen van 'Hoeveelheid vuurwerk (als Netto Explosieve Massa in kg)' naar 'hoeveelheid Netto Explosieve Massa (NEM) in de inrichting: sommatie van de aanwezige hoeveelheid NEM in de bewaarplaats en de bewerkingsruimte, uitgedrukt in kilogrammen' .

3b. - Niet te verplaatsen maar te behouden bij: OpslagVuurwerkF1F2F3T1T2; Het voor OpslagVuurwerkF1F2F3T1T2 te hernoemen naar: 'hoeveelheidVuurwerkLocatie' De definitie aan te passen van 'Hoeveelheid vuurwerk (als Netto Explosieve Massa in kg)' naar 'hoeveelheid consumentenvuurwerk in de inrichting: sommatie van de aanwezige hoeveelheid consumentenvuurwerk in de bewaarplaats, de bufferbewaarplaats en de verkoopruimte, uitgedrukt in kilogrammen' .

4a. om het attribuut 'hoeveelheidNEMBewaarplaats': Op te nemen in het IMEV bij een 'BewaarplaatsF4', een 'SamengesteldeReferentieF4 en een 'Bewerkingsruimte' (zodat de som uitgerekend kan worden); Te voorzien van de definitie: Toegestane hoeveelheid Netto Explosieve Massa (NEM) in vuurwerk van categorie F4 in de bewaarplaats of bewerkingsruimte in kg

4b. om het attribuut 'hoeveelheidVuurwerkBewaarplaats': Op te nemen in het IMEV bij een 'Bufferbewaarplaats', een 'BewaarplaatsF1F2F3T1T2' en een 'Verkoopruimte', (zodat de som uitgerekend kan worden); Te voorzien van de definitie: Toegestane hoeveelheid vuurwerk van categorie F1, F2 of F3 en pyrotechnische artikelen voor theatergebruik in de (buffer)bewaarplaats of verkoopruimte in kg [*https://user-images.githubusercontent.com/80040145/234599412-a5368711-78c5-4643-90ba-e2e88d456fbe.png] Unable to render embedded object: File (*[*https://user-images.githubusercontent.com/80040145/234599412-a5368711-78c5-4643-90ba-e2e88d456fbe.png) not found. [*https://user-images.githubusercontent.com/80040145/234599530-f78ece73-7786-4dc6-84a1-346c79823389.png] ![*https://user-images.githubusercontent.com/80040145/234599530-f78ece73-7786-4dc6-84a1-346c79823389.png|alt="image"*|https://user-images.githubusercontent.com/80040145/234599530-f78ece73-7786-4dc6-84a1-346c79823389.png|alt="image"]

**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? Ja
• Heeft het impact op het json-schema? Ja
• Is het backwardscompatibel? Nee
• X-, Y- of Z-wijziging: X Voor bestaande data moet bedacht worden hoe de hoeveelheden verdeeld worden over meerdere bewaarplaatsen.

Toelichting

Er speelt een fundamentele vraag net als in #41 en #89: a) Is het IMEV bedoeld om de gegevens van de EV contouren te delen inclusief een aantal gegevens die nodig zijn als basisgegeven bij de EV contour? b) Is het IMEV bedoeld om de gegevens van de EV contouren te delen inclusief alle gegevens die nodig zijn om de contour te berekenen? Het uitgangspunt voor het IMEV is altijd het BKL. Dus alleen gegevens die voor het REV gevraagd worden in het BKL horen thuis in het IMEV. Dit zal dus eerst per geval bekeken moeten worden.

De waardes in de enumeraties voor hoeveelheden en grootheden zijn niet consistent.

Voordruk

• < 420 kPa
• ≥ 420 kPa

Categorie aantal bevoorradingen

• ≤ 5
• > 5

reactietijdNoodstop

• ≤ 5 s
• > 5 s

hoeveelheidsklasse stikstofgehalte

• [N2] < 5%
• 5% ≤ [N2] ≤ 10%
• [N2] > 10%

• 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, want enumeraties worden aangepast
• Is het backwardscompatibel? Nee
• X-, Y- of Z-wijziging: X

laag

Een volledige inventarisatie waar dit voorkomt is nog niet uitgevoerd

Het gewenste proces voor het bijwerken van kwetsbare gebouwen en locaties (KGL) in het REV is niet helemaal in lijn met het IMEV.

https://user-images.githubusercontent.com/80040145/220386405-9b24e2d1-8beb-4f88-969e-57d03af34339.png

WAS: https://user-images.githubusercontent.com/9932784/231439229-d4be9fa6-7e63-434b-ad9f-bc295f87b87d.png

WORDT: https://user-images.githubusercontent.com/9932784/231439535-bc2a7cb2-ec0e-4f0d-afd9-9b3dff635908.png

Met een / wordt in bovenstaande figuur aangegeven dat het attribuut afgeleid is uit andere gegevens en dat het door bronhouders dus niet hoeft worden aangeleverd. In de toelichting van het attribuut wordt opgenomen hoe het wordt afgeleid, of waar het vandaan komt. In dit geval gaat het om gegevens uit de BAG die via de pandIdentificatie zijn op te vragen. Met als tekst bij bijvoorbeeld '/gebruiksdoeleinden': Definitie: Het vergunde gebruiksdoel of de vergunde gebruiksdoelen zoals geregistreerd in de BAG. Toelichting: Dit gegeven wordt niet door de bronhouder aangeleverd maar wordt door het REV gegenereerd op basis van de pandIdentificatie. Daarnaast wordt het attribuut “gebruiksdoeleindenDetail“ toegevoegd, omdat de gebruiksdoleinden zoals in de BAG staan niet toereikend zijn.

• 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