2 subtypes voor Monitoringswaarde (SDIMG-xxx, WELT-yyy)

[PB-GNM]

Aanleiding wijziging

Bij het aanleveren van een Monitoringresultaat moet er bij een BGE een verschil waarde t.o.v. de vorige keer worden aangeleverd en en bij een GPP is het een absolute waarde. Dit betekent dat de waardes voor Monitoringresultaat twee verschillende types waarden bevat die ook anders verwerkt en geïnterpreteerd moeten worden. Zo mag een monitoringwaarde voor een BGT wel negatief zijn maar die voor een GPP niet. De huidige modellering waarbij beide types Monitoringresultaat in dezelfde klasses terechtkomen leidt tot misverstanden.

Voorgestelde wijziging

• 2 subtypen monitoringsresultaat maken:
  • MonitoringresultaatBGE met verplicht attribuut verschilMonitoringwaarde met waarde tussen -199.9 en +199.9.
  • MonitoringresultaatGPP met verplicht attribuut absoluteMonitoringwaarde met waarde tussen 0 en 199.9
• MonitoringresulttaatIndustrie wordt subklasse van MonitoringresultaatGPP met attribuut absoluteMonitoringwaardeLnight.
• Uitleg toevoegen dat een lege waarde voor verschilMonitoringwaarde betekent dat het verslagMonitoring een kwantitatieve onderbouwing moet bevatten.

In het volgende plaatje is de oude situatie getekend, waarin afhankelijk van het subtype van GemonitordObject het Monitoringresultaat een absolute- of een relatieve waarde bevat:

In de voorgestelde situatie zijn er twee types Monitoringresultaat die elk naar het juiste type object verwijzen waardoor ook de tussenklasse GemonitordObject niet meer nodig is.

Impactanalyse

Geef hier een indicatie van de impact van de wijziging:
-Wie gaat er wat van merken? Data providers, softwareleveranciers, CVGG
-Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Ja
-Is er een herlevering nodig naar de CVGG? Nee, want nieuwe data is herleidbaar zolang er nog geen BGE monitoring heeft plaatsgevonden.
-Heeft het impact op het xml-schema? Ja
-Is het backward compatible in de zin van validatie op het schema? Nee
-Heeft het impact op de regels in IMG? Indirect: regels over de invulling van monitoringwaarden die nu niet expliciet in het model staan kunnen worden uitgeschreven.
-Heeft het impact op de validatieregels voor de CVGG? Ja, er kan beter op ingevulde waardes gevalideerd omdat er nu niet meer één klasse is waarin soms een verschilwaarde kan zitten (die negatief kan zijn) en soms een meetwaarde (die altijd positief is)
-Heeft het impact op de omgevingsregeling? Nee
-Is het een X, Y, of Z wijziging? X, want niet backwards compatible voor de software

Toelichting

Dit issue is voortgekomen uit #203
Het zou ook opgelost kunnen worden door een keuze attribuut in te voeren tussen BGE-monitoringswaarden en GPP-monitoringswaarden, maar dan moet er wel een regel bij dat die overeenkomt met het subtype van GemonitordObject.

[GosseBakker]

Het toevoegen van twee sub-typen lijkt me in principe een prima oplossing.
Wel heb ik wat opmerkingen:

• De naamgeving vind ik niet erg duidelijk: MonitoringWaarde en MonitoringVerschil. Het verschil is ook een waarde, waarmee 'MonitoringWaarde' niet specifiek genoeg is. Ik zou eerder gaan voor iets als AbsoluutMonitoringresultaat en VerschilMonitoringresultaat.
• Hoe werkt deze wijziging door in MonitoringresultaatIndustrie? Het lijkt me, dat dat dan een subtype wordt van wat in het voorstel subtype 'MonitoringWaarde' heet. Het lijkt me, dat ook dat in dit voorstel beschreven moet worden.
• Het lijkt me mooi om in de xsd voor het attribuut waar de absolute of verschilwaarde in komt, aparte Simple Types te definiëren. Het Simple Type voor de absolute waarde kan dan zowel voor het attribuut met de gewone monitoringwaarde (gpp) als voor het attribuut monitoringwaardeLnight worden gebruikt.

[PB-GNM]

Adviesgroep 12-3-2024: RWS opperde nog een wijzigingsverzoek die met monitoringsresultaat te maken heeft. Voorstel is daar op te wachten en deze dan gecombineerd te behandelen als de tijd daarvoor rijp is.

[skornsekj]

Is al bekend welk wijzgingsverzoek dat precies was? Wie is hiervoor in de lead? Hoelang gaan we hierop wachten? Nu is onbekend wat de relaties precies is, en in hoeverre het 'onbekende' wijzigingsverzoek gerelateerd is aan dit verzoek.

[PB-GNM]

Tijdens het overleg tussen Geonovum em RIVM van 24-9 is nog het volgende besproken:

• Omdat de naamgeving niet erg duidelijk is worden 2 andere namen voorgesteld voor MonitoringWaarde en MonitoringVerschil.
  Voorgesteld is 'GPP-Monitoringresultaat'' en 'BGE-Monitoringresultaat' i.p.v. respectivelijk 'MonitoringWaarde' en 'MonitoringVerschil'.

• Het antwoord op de vraag "Hoe werkt deze wijziging door in MonitoringresultaatIndustrie?", is dat dat dan een subtype wordt van wat in het oorspronkelijke voorstel subtype 'MonitoringWaarde' heet en nu dus 'GPP-Monitoringresultaat' wordt.

[GosseBakker]

• Voorgesteld is 'GPP-Monitoringresultaat'' en 'BGE-Monitoringresultaat': Ik vraag me af of er streepjes in deze feature-namen mogen staan. We hebben nu ook al 'MonitoringresultaatIndustrie', ik vind het netter als we dat stramien van naamgeving aanhouden. Dan zouden de feature-namen 'MonitoringresultaatGPP' en 'MonitoringresultaatBGE' worden.
• De attribuutwaarden zou ik ook aanpassen. In het oorspronkelijke voorstel heten deze 'verschilwaarde' en 'monitoringwaarde'. Dat vind ik niet consequent, dan zie je niet dat 'verschilwaarde' een monitoringwaarde betreft en je ziet niet dat 'monitoringwaarde' een absolute waarde betreft. Ik zou ze daarom iets als 'absoluteMonitoringwaarde' en 'verschilmonitoringwaarde' noemen.
• De naam van het feature 'MonitoringresultaatIndustrie' mag van mij zo blijven. De superklasse ervan wordt dan wel gewijzigd in 'MonitoringresultaatGPP' of hoe dat feature ook mag gaan heten. Het attribuut 'monitoringwaardeLnight' zou ik volgens hetzelfde stramien hernoemen als het monitoringwaarde-attribuut in het feature 'MonitoringresultaatGPP'. Dat zou dan zoiets als 'absoluteMonitoringwaardeLnight' worden.

[JO-RIVM]

Wijzigingsverzoek die met monitoringsresultaat te maken heeft:
Thijs Ruiter RWS: Het gaat om een extra veld bij de monitoring namelijk ook de delta zodat de geluidsruimte/overschrijding weer gegeven kan worden in de CVGG tussen de vergunde ruimte en het monitoringsresultaat.
Dorien Lolkema RIVM Product Owner CVGG: Eenduidigheid van gegevens vraagt dat gegevens maar een keer aangeleverd worden. Het verschil tussen plafondwaarde en monitoringswaarde moet daarom NIET aangeleverd worden. Immers, dit verschil volgt al uit de plafondwaarde en de monitoringswaarde. Voor het tonen van dit verschil (de geluidruimte/overschrijding) in de CVGG kan een verzoek ingediend worden welke de CVGG graag oppakt

[PB-GNM]

• Voorgesteld is 'GPP-Monitoringresultaat'' en 'BGE-Monitoringresultaat': Ik vraag me af of er streepjes in deze feature-namen mogen staan. We hebben nu ook al 'MonitoringresultaatIndustrie', ik vind het netter als we dat stramien van naamgeving aanhouden. Dan zouden de feature-namen 'MonitoringresultaatGPP' en 'MonitoringresultaatBGE' worden.
• De attribuutwaarden zou ik ook aanpassen. In het oorspronkelijke voorstel heten deze 'verschilwaarde' en 'monitoringwaarde'. Dat vind ik niet consequent, dan zie je niet dat 'verschilwaarde' een monitoringwaarde betreft en je ziet niet dat 'monitoringwaarde' een absolute waarde betreft. Ik zou ze daarom iets als 'absoluteMonitoringwaarde' en 'verschilmonitoringwaarde' noemen.
• De naam van het feature 'MonitoringresultaatIndustrie' mag van mij zo blijven. De superklasse ervan wordt dan wel gewijzigd in 'MonitoringresultaatGPP' of hoe dat feature ook mag gaan heten. Het attribuut 'monitoringwaardeLnight' zou ik volgens hetzelfde stramien hernoemen als het monitoringwaarde-attribuut in het feature 'MonitoringresultaatGPP'. Dat zou dan zoiets als 'absoluteMonitoringwaardeLnight' worden.

PB-GNM: Eens met alle opmerkingen. Deze worden verwerkt in het bovenste comment.

[PB-GNM]

Wijzigingsverzoek die met monitoringsresultaat te maken heeft: Thijs Ruiter RWS: Het gaat om een extra veld bij de monitoring namelijk ook de delta zodat de geluidsruimte/overschrijding weer gegeven kan worden in de CVGG tussen de vergunde ruimte en het monitoringsresultaat. Dorien Lolkema RIVM Product Owner CVGG: Eenduidigheid van gegevens vraagt dat gegevens maar een keer aangeleverd worden. Het verschil tussen plafondwaarde en monitoringswaarde moet daarom NIET aangeleverd worden. Immers, dit verschil volgt al uit de plafondwaarde en de monitoringswaarde. Voor het tonen van dit verschil (de geluidruimte/overschrijding) in de CVGG kan een verzoek ingediend worden welke de CVGG graag oppakt

PB-GNM: Het leidt dus niet tot een aanpassing op dit wijzigingsverzoek, maar zou een nieuw wijzigingsverzoek moeten worden. Zie #229.

[wilkoquak]

Door het aangeven van een minimum- en maximumwaarde voor verschilMonitoringwaarde en absoluteMonitoringwaarde ontstaan automatische simple types. Wat moeten die minima en maxima worden?

[skornsekj]

@wilkoquak
De huidige min en max waarde zijn: -199.9 en 199.9.

• Voor de GPP monioring geldt dat ie niet negatief kan zijn. Dus voor de absoluteMonitoringwaarde geldt dan 0 t/m 199.9.
• Voor de BGE monitoring geldt dat ie wel negatief kan zijn. Dus voor verschilMonitoringwaarde geldt dan bijv. -99.9 t/m 99.9 of -199.9 tm 199.9

[skornsekj]

@wilkoquak
Nog volgende:

• (GPP) absoluteMonitoringwaarde heeft m.i. een kardinaliteit van 1 heeft ipv 0..1. Ik kan geen reden bedenken dat deze niet verplicht geleverd zou moeten worden.
• (BGE) verschilMonitoringwaarde moet volgens mij ook altijd een kardinaliteit van 1.

@GerdadeVries23
Vraag. Volgens artikel 11.47 BKL moet het verschil tussen de geluidemissie in Lden en de BGE in het geluidregister worden opgenomen. Dat kan begreep ik eerder ook 0 zijn. Het verschil kan berekent of geschat zijn.

1. Betekent dit dat gemeenten altijd voor elke BGE een 'BGE monitoringwaarde' moeten aanleveren aan de CVGG. Ook als de gemeente dat 'alleen' kwalitatief onderbouwd heeft.
2. in geval van een kwalitatieve onderbouwing is het verschil tussen de geluidemissie in Lden en de BGE dan '0'.

Als gemeenten altijd iets moeten aanleveren dat is het voorgestelde attribuut verschilMonitoringwaarde (voor de BGE) namelijk verplicht.

[wilkoquak]

Uit issue #167 maak ik op dat als je een BGE niet invult er een kwalitatieve onderbouwing moet zijn waaruit ik opmaakt dat verschilMonitoringwaarde leeg mag zijn. Bij GPP ga ik hem nu verplicht maken in het wijzigvoorstel. Ik wil ook de uitleg bij BGE verbeteren.

[GerdadeVries23]

@GerdadeVries23 Vraag. Volgens artikel 11.47 BKL moet het verschil tussen de geluidemissie in Lden en de BGE in het geluidregister worden opgenomen. Dat kan begreep ik eerder ook 0 zijn. Het verschil kan berekent of geschat zijn.

1. Betekent dit dat gemeenten altijd voor elke BGE een 'BGE monitoringwaarde' moeten aanleveren aan de CVGG. Ook als de gemeente dat 'alleen' kwalitatief onderbouwd heeft.
2. in geval van een kwalitatieve onderbouwing is het verschil tussen de geluidemissie in Lden en de BGE dan '0'.

Als gemeenten altijd iets moeten aanleveren dat is het voorgestelde attribuut verschilMonitoringwaarde (voor de BGE) namelijk verplicht.

Gemeenten moeten inderdaad voor elke BGE een 'BGE monitoringwaarde' aanleveren aan de CVGG. Ook als de gemeente dat 'alleen' kwalitatief onderbouwd heeft. De schatting kan bijvoorbeeld zijn dat er geen verandering is van de geluidemissie, dus dat het verschil 0 is. De gemeente kan ook een schatting maken van de verkeersintensiteiten, bijvoorbeeld een percentage hoger, en daaruit de geluidemissie en het verschil berekenen.

[skornsekj]

@wilkoquak zie reactie van Gerda. Ik leid daaruit af dat het nieuwe attribuut 'MonitoringresultaatBGE' niet optioneel maar verplicht moet zijn.