Geonovum / imev-werkomgeving

Informatiemodel Externe Veiligheid IMEV. Folder voor het ontwikkelen van IMEV gerelateerde onderdelen en documentatie
https://docs.geostandaarden.nl/imev/imev/
1 stars 0 forks source link

SDIMEV-31: Historie model Geo-object vs administratiefobject #25

Closed PB-GNM closed 2 years ago

PB-GNM commented 3 years ago

Hallo,

Samen met Geodan zijn we bezig met het uitwerken van validaties die we kunnen doen van de aangeleverde gegevens en het goed toepassen van de tijdslijnen geldigheid door de bronhouders.

Wat we nu zien is dat de geo-objecten conform NEN3610 zijn voorzien van de gewenste tijdlijnen (geldigheid en registratie)

Maar dat het adminstratieve object EvActiviteit zijn eigen historie-implementatie heeft.

(met datum vergunning/melding en datum laatste wijziging)

Dit levert de vraag op hoe verhouden deze datumvelden zicht t.o.v de datumgeldigheid van de Geo-ojecten?

Andere vraag is hoe we velden datum moeten interpreteren (de datumlaatstewijziging)

Hoe beëindig je hiermee het object? Ik heb het idee dat ik een status veld mis (bv beindigen vergunning)

wat de datum laatste wijziging eigenlijk toevoegt, daar er volgens mij niet iets is wat er dan van het object te wijzigen valt. (bv voor activiteit TankenLPG is alleen doorzetperjaar iets wat aangepast kan worden waar de datum naar verwijst)

Ander punt die ik hierbij heb is dat voor de samenhangendobjectregistratie de voorwaarde staat dat voor historie

• gebruikt een eenduidig model. Dat wil zeggen voor alle attributen binnen de Samenhangende objectenregistratie hetzelfde model en dus geen onderscheid tussen geometrie en administratieve gegevens;

In het IMEV maken we wel onderscheid, is dat erg? Of zouden we dat moeten aanpassen?.

Is het een idee om een kort overleg samen met Geodan hierover in te plannen?

Mvg

Arno de Ruijter

PB-GNM commented 3 years ago

De vraag bestaat eigenlijk uit 5 deelvragen, die ik hieronder genummerd heb met deels eigen woorden.

1) Hoe verhouden de 2 datumvelden van EvActiviteit zicht t.o.v de datumgeldigheid van de Geo-ojecten?

2) Hoe beëindig je een EVactiviteit object en zou hiervoor een datum en/of status veld toegevoegd moeten worden?

3) Wat voegt de datum laatste wijziging eigenlijk toe?

4) Hoe erg is het dat dit model zich niet houdt aan de SOR richtlijn “voor alle attributen binnen de Samenhangende objectenregistratie hetzelfde model en dus geen onderscheid tussen geometrie en administratieve gegevens”?

5) Is een overleg over deze punten met Geodan mogelijk?

Samen met Paul Janssen ben ik tot de volgende antwoorden gekomen.

Antwoord op deelvraag 1: In het huidige IMEV is er onderscheid gemaakt tussen materiele geo-objecten en het administratieve object BKLActiviteit. Voor de geo-objecten is dezelfde aanpak gekozen als in Nen3610 met beginGeldigheid en eindGeldigheid. Voor de BKLActiviteit is er gekozen voor een tijdsaanduiding die iets meer bij de terminologie van het objecttype past. Wat betreft NEN 3610 was het niet nodig geweest om materiele historie (begin/eindgeldigheid) alleen voor de fysieke objecten te gebruiken maar kan het net zo goed voor de administratieve. Het kan dan wel zijn dat daarnaast een attribuut ‘datumVergunnigOfMelding” nog steeds nodig is, omdat het bijvoorbeeld verwijst naar een specifieke uitleg van het BAL of nodig is om begrijpelijk dit gegeven uit te wisselen.

Antwoord op deelvraag 2: Op dit moment is eigenlijk niet aan te geven of een BKLActiviteit object beëindigd is. Er is behoefte aan een statusveld of een attribuut dat aangeeft of de vergunning/melding nog geldig of van toepassing is of niet. In feite kan dat met begin/eindgeldigheid. Het geeft de periode aan waarin gegevens (een versie van het object) corresponderen met de situatie in de werkelijkheid. Als de laatste versie van het object wel een eindgeldigheid heeft en er daarna geen nieuwe versie met een begingeldigheid is, dan is het object beëindigd.

Antwoord op deelvraag 3: Wat het veld “datumlaatsteWijziging” toevoegt is inderdaad discutabel, omdat als er iets wijzigt, dan is er sprake van een nieuwe versie van het object. Dat kan je met eindGeldigheid opnemen. En in mindere mate met het attribuut ‘eindRegistratie’ dat geërfd wordt van ExterneVeiligheidsObject. Dat gaat immers over het moment dat het in de registratie is opgenomen.

Antwoord op deelvraag 4: Als we zoals ook voorgesteld binnen de SOR administratieve objecten gelijk behandelen als Materiele Geo-objecten, dan kunnen we de velden beginGeldigheid en eindGeldigheid ook voor de EV/BKLActiviteit gebruiken. Objecttype ExterneVeiligheidsObjectMaterieel kan dan komen te vervallen en zijn attributen kunnen dan naar de generalisatie erboven: ExterneVeiligheidsObject. Dat zou ook meteen de problemen uit de 2 deelvragen hierboven oplossen (2 en 3). Ook de attributen “datumVergunningOfMelding” en “datumlaatsteWijziging” vervallen dan, omdat beginGeldigheid en eindGeldigheid dan gebruikt kunnen worden. De status blijkt dan uit de vraag of het veld eindGeldigheid is ingevuld (en er geen nieuwe versie is aangemaakt)

Antwoord op deelvraag 5: Gezien het antwoord op vraag 4 zullen we dit als wijzigingsvoorstel op Github zetten. Op een nog nader te bepalen moment zullen alle issues die ook een wijzigingsvoorstel zijn besproken worden met experts zoals Geodan en dus ook dit issue.

Met vriendelijke groet,

Pieter Bresters

fzantea commented 3 years ago

Er moet in deze discussie wel onderscheid gemaakt worden tussen de BKLActiviteit die wordt uitgevoerd en de vergunning die daarbij hoort. een BKLActiviteit is geen vergunning. De datum velden in BKLActiviteit slaan op de vergunning/melding niet op de BKLActiviteit zelf. In een vergunning kan veel meer staan dan alleen deze BKLActiviteit. gr Frank Zwiers

PalmJanssen commented 2 years ago

Goed punt van Frank. Ik zou daarom de attributen datumVergunningOfMelding en datumLaatsteWijziging (van de vergunning) laten staan. Dit zijn duidelijke door het werkveld begrepen attributen.

Wel zou ik het historische model voor geo-objecten inderdaad ook van toepassing maken op de EVActiviteit. Een EVActiviteit krijgt daarmee een begindatum en optioneel een einddatum.

PB-GNM commented 2 years ago

Gesloten, omdat het verwerkt is in versie 1.1 en omdat die versie goedgekeurd is.