Blauw gebouw

Meldingen geo-standaarden

Op deze pagina vind je een overzicht van meldingen die zijn gedaan over standaarden die Geonovum beheert. Door in het zoekveld een standaard te selecteren, kan je de status van meldingen bekijken. Heb je zelf een melding gedaan, dan kan je ook zoeken op het ID-nummer van jouw melding.
Wil je juist een melding doorgeven aan ons? Ga dan naar onze helpdesk

  • WELT-228
  • Status
    Wachten op Support

datum geldigheid, toevoegen van een timestamp

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.

Voorstel oplossing
Timestamp toevoegen aan attribuut begingeldigheid
  • WELT-227
  • Status
    IN BEHANDELING
  • geaccepteerde wijziging voor versie 1.3

toevoegen restcategorie voor activiteiten die in het RRGS zitten, maar niet in het REV passen

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

Voorstel oplossing
Restcategorie van EVActiviteiten toevoegen.
CAB datum
  • WELT-226
  • Status
    IN BEHANDELING
  • geaccepteerde wijziging voor versie 1.3

Meerdere KVK nummers mogelijk maken bij SEVESO inrichtingen - REV-246 - 001

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.

Voorstel oplossing
De kardinaliteit van kvkNummerExploitant van de LocatieActiviteit wordt [0..*].
CAB datum
  • WELT-225
  • Status
    IN BEHANDELING
  • geaccepteerde wijziging voor versie 1.3

Buisleidingen: Statusveld opnemen

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

Voorstel oplossing
De status van een buisleiding opnemen in het model. Het zou dan een extra attribuut worden van BuisleidingReferentie met een enumeratie van de verschillende stadia.
CAB datum
  • WELT-224
  • Status
    IN BEHANDELING
  • geaccepteerde wijziging voor versie 1.3

Toevoegen referentie-objecten voor VII-E activiteiten

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

Voorstel oplossing
Gevraagde types referentie-objecten voor bepaalde VII-E activiteiten op nemen in het model.
CAB datum
  • WELT-223
  • Status
    IN BEHANDELING
  • geaccepteerde wijziging voor versie 1.3

Excel met ActiviteitenIMEV-Referentiepunten publiceren

Voorstel oplossing
Tabellen los publiceren op : Technisch register voor geo-standaarden in Nederland.
CAB datum
  • WELT-222
  • Status
    IN BEHANDELING
  • geaccepteerde wijziging voor versie 1.3

Adres conform BAG toepassen

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.

Voorstel oplossing
Er wordt een optioneel attribuut adres_BAGid toegevoegd.
Voor adres_BAGid wordt de waarde van de BAG:nummeraanduiding ingevuld.
CAB datum
  • WELT-221
  • Status
    IN BEHANDELING
  • geaccepteerde wijziging voor versie 1.3

Optioneel veld bij evActiviteit voor mba (kern-mba of foa) conform BAL

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.

Voorstel oplossing
Optioneel veld bij EvActiviteit voor MBA (kern-mba of foa) conform BAL
CAB datum
  • WELT-220
  • Status
    IN BEHANDELING
  • geaccepteerde wijziging voor versie 1.3

Lokaal ID voor koppeling met bronhoudersysteem

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.

Voorstel oplossing
locaal_id aan EVobject toevoegen als optioneel attribuut.
CAB datum
  • WELT-219
  • Status
    IN BEHANDELING
  • geaccepteerde wijziging voor versie 1.3

Optioneel/verplicht veld bij referentieEVContour om de BKL/EV-subcategorie te kunnen invullen.

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

Voorstel oplossing
Een optioneel/verplicht veld bij referentieEVContour voor BKL/EV-subcategorie en/of omschrijving
CAB datum

Geen updates meer missen?

Automatisch op de hoogte blijven? Meld je aan voor één van onze nieuwsbrieven.