Meldingen geo-standaarden

Aanleiding
Volgens Geodan slaan zij alleen de datum begingeldigheid op en niet het tijdstip. Hierdoor ontstaan veel fouten mbt begingeldigheid. Als het tijdstip van laatste wijziging wordt toegevoegd en hierop de check wordt uitgevoerd verdwijnt in veel gevallen de foutmelding dat de nieuwe begingeldigheid op hetzelfde moment ligt als de vorige.

Aanleiding wijziging
Er is behoefte aan een restcategorie voor Activiteiten die in het RRGS zitten, maar niet in het REV passen.

Voorgestelde wijziging
Restcategorie van EVActiviteiten toevoegen.

Impactanalyse
Wie gaat er wat van merken? Softwareleveranciers, dataproviders van de restcategorieën, gebruikers
Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Ja er komt een heel diagram bij het IMEV
Heeft het impact op het json-schema? Ja

Toelichting
zie https://github.com/Geonovum/imev-werkomgeving/issues/73

Aanleiding wijziging
Het is nu niet mogelijk om meerdere KvK nummers te koppelen aan één seveso-inrichting, terwijl dit wel voorkomt.

Voorgestelde wijziging
Het wijzigingsverzoek is om meerdere KvK nummers op te kunnen nemen bij een LocatieActiviteit van een Seveso-inrichting.

Locatie in UML

Impactanalyse
Geef hier een indicatie van de impact van de wijziging:

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
Heeft geen invloed op INSPIRE verplichting, behalve dat koppeling met Handelsregister iets lastiger wordt. Die moet dan voor elk opgegeven KvK-nummer plaatsvinden.

Aanleiding wijziging
De status van een buisleiding is een relevant gegeven voor de gebruiker van het REV. Dit gegeven zit nu niet in het model.

Voorgestelde wijziging
Het wijzigingsverzoek is om de status van een buisleiding op te nemen in het model. Het zou dan een extra attribuut worden van BuisleidingReferentie met een enumeratie van de verschillende stadia.

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
In IMKL worden de volgende waarden gebruikt voor het attribuut CurrentStatus

buiten gebruik
functioneel
geprojecteerd
https://definities.geostandaarden.nl/imkl2wl/nl/page/?uri=http%3A%2F%2Fdefinities.geostandaarden.nl%2Fimkl2015%2Fid%2Fwaardelijst%2FConditionOfFacilityIMKLValue

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