Aanleiding wijziging
Het verzoek is om bij featuretype EVActiviteit de mogelijkheid toe te voegen om aan te geven onder welke milieubelastende activiteit die in het BAL wordt genoemd, de activiteit valt.

Voorgestelde wijziging
Optioneel veld bij EvActiviteit voor MBA (kern-mba of foa) conform BAL

Locatie in UML

Impactanalyse
Wie gaat er wat van merken? dataprovider en gebruiker REV en Softwareleveranciers
Verandert de semantiek van de objecten? Nee
Heeft het impact op het json-schema? Ja

Toelichting
Er kunnen meerdere BAL-activiteiten bij een BKL-activiteit horen.
zie https://github.com/Geonovum/imev-werkomgeving/blob/main/docs/20220923_IMEV_match_activiteit_referenties_contouren_met_mba_indeling.xlsx
Als dat altijd dezelfde zijn per BKL-activiteit, dan is het beter om dit in een aparte tabel bij te houden dan in het REV en dus ook niet in het IMEV. Als het per instantie kan verschillen hoort het wel in het REV en dus ook in het IMEV.

Aanleiding wijziging
Er is behoefte aan een lokaal-ID om in de conversie het id van het object in het bronhoudersysteem te behouden of te kunnen relateren aan het ID in het REV.

Voorgestelde wijziging
locaal_id aan EVobject toevoegen als optioneel attribuut.

Locatie in UML

Impactanalyse
Wie gaat er wat van merken? dataprovider REV en Softwareleveranciers
Verandert de semantiek van de objecten? Nee
Heeft het impact op het json-schema? Ja

Toelichting
Gaat erom dat in de conversie het id van het object in het bronhoudersysteem te behouden of te kunnen relateren aan het id in het REV. Dat zou met LokaalID moeten kunnen lijkt het. Moet in de conversie opgelost worden.
Of bronhouders moeten een eigen registratie, koppeltabel, maken hoe de eigen objectid relateert aan de rev objectid.
2 software leveranciers vinden het niet nodig en 1 wel.

Aanleiding wijziging
De lijst met subcategorie-indeling is vooral bedoeld als een hulpmiddel om (snel, eenvoudig en weinig fout gevoelig) de juiste EV-contouren aan een referentie (waarbij vastgestelde afstanden gelden tot contouren) toe te voegen. De meest actuele, definitieve tabel zou op de IMEV-website geplaatst kunnen worden, zodat bronhouders en VTH-leveranciers hiervan gebruik kunnen maken.
Daarnaast lijkt het gewenst dat een bronhouder de subcategorie omschrijving kan toevoegen als optioneel veld "omschrijving" aan elk referentie-object. Op dit moment bevat alleen "SamengesteldeReferentie", "SevesoReferentie" en "AnderInsluitsysteem" een veld "omschrijving". Dit veld kan ook worden gebruikt om een nadere duiding te geven aan het referentie- object.

Voorgestelde wijziging
Een optioneel/verplicht veld bij referentieEVContour voor BKL/EV-subcategorie en/of omschrijving

Impactanalyse
Wie gaat er wat van merken? dataprovider en gebruiker REV en Softwareleveranciers
Verandert de semantiek van de objecten? Nee
Heeft het impact op het json-schema? Ja

Aanleiding wijziging
Bij welke EVActiviteiten en referentieEVContouren dit zinvol is en waarom, moet nog vastgesteld worden.

Voorgestelde wijziging
Het wijzigingsverzoek is om optionele velden bij evActviteit(en) zoveel mogelijk naar referentieEVContouren te verplaatsen.

Locatie in UML

Impactanalyse
Wie gaat er wat van merken? dataprovider en gebruiker REV en Softwareleveranciers
Verandert de semantiek van de objecten? Nee
Heeft het impact op het json-schema? Ja, groot. Dit betekent veel werk voor software leveranciers. De data die al geconverteerd is, zal omgezet moeten worden in het REV.

Aanleiding wijziging
De aanleiding is dat er minder fouten worden gemaakt wanneer er categorieën gebruikt worden.

Voorgestelde wijziging
Het voorstel is om op de plek waar nu Real staat de al bestaande enumeratie DoorzetCategorie te gebruiken bij de EVActiviteiten: TankenLPG en Opslagtank­Propeen_Vaste­Afstand­Vergunningplicht.

Locatie in UML

Impactanalyse
Wie gaat er wat van merken? dataprovider en gebruiker REV en Softwareleveranciers
Verandert de semantiek van de objecten? Nee
Heeft het impact op het json-schema? Ja

Toelichting

Adviesgroep 13-9-2023 heeft besloten deze wijziging niet door te voeren. Zie ook:

https://github.com/Geonovum/imev-werkomgeving/issues/40#issuecomment-1723081803

Aanleiding wijziging
De aanleiding is dat er minder fouten worden gemaakt wanneer er categorieën gebruikt worden.

Locatie in UML

Voorgestelde wijziging
Het voorstel is om op de plek waar nu "Integer" staat de enumeratie CategorieAantalBevoorradingen, en dat verwijst dan naar een enumeratie met de 2 waarden "<= 5" en "> 5".

Impactanalyse

Wie gaat er wat van merken? dataprovider en gebruiker REV en Softwareleveranciers
Verandert de semantiek van de objecten? Nee
Heeft het impact op het json-schema? Ja

Aanleiding wijziging
In IMEV staat bij numerieke waarden alleen aangegeven of de waarde een Integer (geheel getal) of een Real (decimaal getal) is. Er staan geen andere invulvoorschriften (of constraints) voor numerieke waarden. Zoals bijvoorbeeld minimumwaarde, maximumwaarde, aantal cijfers achter de komma. Er kan dus op dit moment niet gevalideerd worden op deze invulvoorschriften.

Voorgestelde wijziging
Neem bij de kenmerken waar dat nodig is invulvoorschriften op in de vorm van constraints als minimum, maximum, aantal decimalen etc.

Er zijn zo'n 6 integer en 40 real waarden in IMEV. Ze komen voor bij typische kenmerken als afstand, oppervlakte, inhoud, aantal, lengte, massa etc.

Impactanalyse

• Wie gaat er wat van merken? dataprovider, REV, 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? Nog niet bekend. Waarschijnlijk niet. De invulvoorschriften kunnen met validatieregels gecontroleerd worden

Expertgroep 28-09-2022:
Wat levert het op: datakwaliteit.
Geen harde noodzaak, maar wel wenselijk.
Vooral de eenheden zijn belangrijk.
Voorstel: niet voor versie 1.3, maar voorbereiden voor een daaropvolgende versie, want inventarisatie door experts is eerst nodig.

De objecten “LijnbronIndustrie” en “VlakbronIndustrie” zijn niet in de geluidgegevenscollectie opgenomen, omdat deze geen specialisatie zijn van “GeluidgegevenscollectieElement”.
Melder vindt dat een fout omdat “VlakbronIndustrie” een eigenschap heeft welke essentieel is om berekende waarden te kunnen reproduceren, namelijk “negeerOverdrachtsobjecten”.
Je hebt in de berekening dan namelijk de geometrie van de vlakbron nodig om te kunnen achterhalen of een gebouw of scherm op deze vlakbron staat en je de bijbehorende reflectie en afscherming moet negeren.
Je kunt dus niet volstaan met alleen het inlezen van gegevens uit de GeluidgegevensCollectie en ik dacht dat dit de bedoeling was van de GeluidGegevensCollectie.
Aangezien een geluidgegevenscollectie nu geen vlakbronnen meer kan bevatten, is het niet meer mogelijk om op basis van de collectie de berekende resultaten te reproduceren.

In de toelichtingen van objecten die volgens het model geen subtype van geluidgegevenscollectieElement zijn, duidelijk maken dat alle objecten in het GML bestand belangrijk zijn en dus ook degenen die niet rechtstreeks in de geluidgegevenscollectie zitten.

Geef hier een indicatie van de impact van de wijziging:

• Wie gaat er wat van merken? De gebruikers van het model
• 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
• X, Y of Z-wijziging: Z

Aanleiding wijziging
Er is behoefte aan een nieuw objecttype voor geluidschermdelen met een diffractor. Dit punt komt voort uit een wijziging in de reken- en meetvoorschriften.

Voorgestelde wijziging

https://user-images.githubusercontent.com/80040145/209111384-3a161954-29b9-4763-be9b-387ae8d486af.png

• Nieuw objecttype “DiffractorOpGeluidschermdeel” met dezelfde velden welke een “ Geluidschermdeel ” nu heeft: bovenkantScherm, onderkantScherm, reflectiefactorLinks, reflectiefactorRechts, hellingshoek en statusZwevend, maar zonder profietype en schermtype. Het schermtype is altijd diffractor op scherm en hoeft dus niet apart opgegeven te worden.
• Het nieuwe objecttype heeft daarnaast als extra veld "diffractoreffect" van het type “ WaardePerOctaafband ”.
• Dit objecttype is een specialisatie van “Geluidoverdrachtobject ”.

Impactanalyse

• Wat betekent het voor de software van de CVGG, softwareleveranciers en bronhouders? Alle software dient hierop aangepast te worden. Ook de validatieregels in de CVGG moeten bijgewerkt worden.
• Wie gaat er wat van merken? Diegene die een diffractor op een geluidscherm wil aanleveren of gebruiken.
• 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 xml-schema? Ja
• Wat gaat er mis als we de wijziging niet doorvoeren? Het IMG ondersteunt dan niet het reken- en meetvoorschrift en daardoor kunnen bronhouders dan geen diffractors op geluidschermen aanleveren aan de CVGG, conform IMG.
• X,Y,Z-wijziging: Y, want er wordt alleen iets toegevoegd.

De validatieregels TPOD0410 t/m TPOD1070 gaan over de tekstuele inhoud van label, opschrift en nummer in de koppen van tekstelementen zoals hoofdstuk, afdeling en paragraaf en de nummering van leden en lijsten. Dit zijn moeilijk te implementeren validatieregels met beperkte opbrengst.

Het is gewenst om nieuwe validatieregels toe te voegen die valideren op soortRegeling in combinatie met het verantwoordelijk bevoegd gezag en validatieregels die valideren op soortRegeling en te gebruiken STOP-model voor Besluit en Regeling. Deze validatieregels zorgen er voor dat een bevoegd gezag alleen die omgevingsdocumenten kan aanleveren waartoe het juridisch bevoegd is. Het betreft validatieregels van deze typen:

• Als soortRegeling = 'Omgevingsplan' dan MOET de eindverantwoordelijke van het besluit een waarde uit waardelijst 'Gemeente' zijn
• Als soortRegeling = 'Omgevingsplan' dan MOET STOP model {BesluitCompact en RegelingCompact}

  of

  {BesluitCompact en RegelingMutatie}

  worden gebruikt