SDIMEV-42: REV-helpdesk 22 02 0069: Voeg toe: verplicht veld voor locatie_id aan LocatieActiviteit

[PB-GNM]

Kenmerk 22 02 0069

Het wijzigingsverzoek is: Voeg toe: verplicht veld voor locatie_id aan LocatieActiviteit om te kunnen filteren op LocatieActiviteit met alle bijbehorende evActiviteiten, referentieEVContouren en evContouren

Eerste reactie Arno de Ruijter (ministerie IenW); Dit is een vraag die hoort bij het “bevragen van de REV”, dat je alle activiteiten wilt zien voor een bepaalde locatie. Daarvoor hoeft er geen IMEV aanpassingen te zijn. Is een applicatie-vraagstuk. Zou evt bij uitleveren van gegevens ook de verwijzende id’s mee kunnen geven. Maar ook daarvoor geld dat het IMEV bedoelt is voor aanleveren van gegevens. Die hoeft hierop niet te worden aangepast. Lijkt op issue #16 Waarom hebben de verschillende objecten geen verwijzende sleutels? · Issue #16 · Geonovum/imev-werkomgeving · GitHub

[PB-GNM]

Maar de LocatieActiviteit heeft toch al een verplicht id via supertype ExterneVeiligheidsobject?

[PalmJanssen]

Er is al een identificatie van LocatieActiviteit:

[PalmJanssen]

Werkgroep:

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.

Vraag is of de VTH leveranciers hier mee uit de voeten kunnen.

Voor nu geen IMEV onderwerp.

[PB-GNM]

Reacties VTH leveranciers:

1. niet nodig
2. Bij het invoeren van nieuwe locaties in het REV middels de invoermodule wordt al de mogelijkheid geboden om een lokaal id op te geven. Standaard is dit een vrij invulveld, maar deze kan ook worden gegenereerd. Wat ons betreft is hier dus geen verdere IMEV-wijziging voor nodig.
3. Het toevoegen van een lokaal ID in het IMEV om te kunnen refereren naar een id van de objecten in het bronhoudersysteem (= onze VTH-software) lijkt ons een goed idee. De impact is zeer klein. De wens aan onze kant is dan echter wel om ook gegevens vanuit het REV op te kunnen vragen op basis van dat Lokaal ID. Dat maakt het ‘eenmalig’ koppelen/synchroniseren van de gegevens die in het REV staan met de gegevens die al in het bronhoudersysteem staan een stuk eenvoudiger

[PB-GNM]

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.

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

Prioriteit

Middel

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.

[PB-GNM]

Expertgroep: Nen3610id bevat ook een deel met lokaal-id, maar dat is al gevuld met RRGS-id. Dus wel doen.

[PB-GNM]

Verwerkt:

[PB-GNM]

Omdat "lokaal_id" te veel lijkt op het "lokaalID" in het NEN3610ID, is er uiteindelijk voor de naam "bronobjectID" gekozen. Daarmee is ook duidelijker dat dit bedoeld is voor ID's zoals de bronhouder die intern heeft gebruikt.

[PB-GNM]

Opgelost in versie 1.3.