Meldingen geo-standaarden

Aanleiding wijziging
Er komen in de praktijk meer types referentie-objecten voor bepaalde VII-E activiteiten voor in de praktijk dan er nu in het model passen.

Voorgestelde wijziging
Het wijzigingsverzoek is om meer types referentie-objecten voor bepaalde VII-E activiteiten op te nemen in het model.

Locatie in UML

Impactanalyse
Wie gaat er wat van merken? dataprovider en gebruiker REV en Softwareleveranciers als het ook een ingebouwde regel wordt dat bepaalde types maar mogen voorkomen
Verandert de semantiek van de objecten? Ja, want nieuwe objecttypes
Heeft het impact op het json-schema? Niet als het referentie-objecten zijn die al bij andere EV-activiteiten voorkomen

Toelichting
De groene vakjes in onderstaande figuur zijn de referenties per EV-activitiet die extra gewenst zijn.
tabel met nieuwe referentieobjecten

Expertgroep 28-9-22:
Tabel graag los publiceren op : https://register.geostandaarden.nl/.
Geldt ook voor andere tabellen.
Het gaat vooral om: https://github.com/Geonovum/imev-werkomgeving/blob/main/docs/20220923_IMEV_match_activiteit_referenties_contouren_met_mba_indeling.xlsx
maar ook om: https://github.com/Geonovum/imev-werkomgeving/blob/main/docs/lijst%20met%20REV-subcategorieen%20_%20versie%201%20september%202022.xlsx

Aanleiding wijziging
Adres in IMEV is opgenomen als CharacterString. Een adres conform de BAG bestaat uit een aantal benoemde velden en/of een BAGid.

Voorgestelde wijziging
Er wordt een optioneel attribuut adres_BAGid toegevoegd.
Voor adres_BAGid wordt de waarde van de BAG:nummeraanduiding ingevuld.

Locatie in UML

Impactanalyse
Wie gaat er wat van merken? dataprovider, REV en Softwareleveranciers
Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee, de informatie betekenis blijft gelijk.
Heeft het impact op het json-schema? Ja.

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.