Meldingen geo-standaarden

Aanleiding wijziging
Het attribuut bronobjectID is vooral bedoeld om REV-json datasets te kunnen koppelen met locaties/inrichtingen in een bronsysteem. Aangezien een REV-json dataset bij wijzigingen compleet aangeleverd moet worden, ligt het voor de hand dat voor verschillende onderdelen van deze dataset hetzelfde bronobjectID aanhouden. In het bronsysteem van onze omgevingsdienst (OpenWave van de ODR) zal waarschijnlijk het inrichting nummer gekozen worden als het te gebruiken bronobjectID. Dit is alleen relevant voor de locatie. Door de ingevulde waarde in het veld 'bronobjectID' automatisch over te nemen, is bij raadplegen van elk EV-object (locatie, EV-activiteit, referentie of EV-contour) duidelijk bij welk bronobjectID (locatie of inrichting) dit hoort. Eventueel zou het optionele veld 'bronobjectID' uit EV-objecten EV-activiteit, referentieEVContour en EVContour verwijderd kunnen worden, tenzij bronsysteem leveranciers het gewenst vinden dat dit toch zo blijft staan in het IMEV. Verwachting is dat bronhouders het niet nodig vinden om verschillende bronobjectID's per niveau in te vullen.

Er zijn ook tegenargumenten:
https://github.com/Geonovum/imev-werkomgeving/issues/95#issuecomment-1462087255

Voorgestelde wijziging
Attribuut bronobjectID verplaatsen naar LocatieEVActiviteit.

https://user-images.githubusercontent.com/80040145/223688675-795e67fe-f4bb-4e51-a2ab-51058c44646d.png

Impactanalyse

• Wie gaat er wat van merken? Dataleveranciers, 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? Ja
• Is het backwardscompatibel? Nee
• X-, Y- of Z-wijziging: X

Prioriteit
midden
De wijziging is niet noodzakelijk, omdat het geen verplicht attribuut is, maar wel gewenst om onnodige vulling te voorkomen.

Toelichting
Er zou ook overwogen kunnen worden het te verplaatsen naar naar subtype LocatieActiviteit van LocatieEVActiviteit. In dat geval zou het dan niet gelden voor andere subtypes als Buisleidingstelsel en LocatieBasisnet.

Beschrijving

Aanleiding wijziging
Het gaat om het attribuut ‘hoeveelheidVuurwerk’ op de volgende twee activiteiten:

· VIII-A Explosieaandachtsgebied vuurwerk voor opslag van categorie F4 – detail
· VIII-B Explosieaandachtsgebied vuurwerk voor opslag van categorie F1, F2, F3, of pyrotechnische artikelen voor theatergebruik van categorie T1 of T2 - detail

Het attribuut ‘hoeveelheidVuurwerk’ wordt uitgevraagd op activiteit niveau. Als gebruiker geef je hier als het ware een totale hoeveelheid vuurwerk van alle bewaarplaatsen, bufferbewaarplaatsen en/of bewerkingsruimten op één locatieactiviteit. Dit is voor de gebruiker van de Invoer Module niet gewenst.

Bijvoorbeeld: Het is mogelijk dat er 2 buffers staan op 1 locatieactiviteit. 1 buffer bevat 500 kg vuurwerk en 1 buffer bevat 1000 kg vuurwerk. Op dit moment moet je het getal 1500 invoeren op activiteitniveau. Als gebruiker wil je deze aantallen opvoeren per buffer.

Voorgestelde wijziging
Attribuut hoeveelheidVuurwerk verplaatsen van subtypes voor opslag van vuurwerk van het abstracte type BKLActiviteit naar (nieuwe) subtypes van ReferentieEVContour. In geval van Bewaarplaats en SamengesteldeReferentie moeten het nieuwe referentie types worden, want de oude worden ook voor andere activiteiten dan vuurwerkopslag gebruikt. Bufferbewaarplaats en Bewerkingsruimte kunnen hetzelfde objecttype blijven omdat die volgens de definitie specifiek voor vuurwerkopslag zijn.

https://user-images.githubusercontent.com/80040145/223678826-58042588-0614-44d5-b4c7-1d3a0c83b8ca.png

Impactanalyse

• Wie gaat er wat van merken? Dataleveranciers, Softwareleveranciers
• Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Ja
• Heeft het impact op het json-schema? Ja
• Is het backwardscompatibel? Nee
• X-, Y- of Z-wijziging: X

De waardes in de enumeraties voor hoeveelheden en grootheden zijn niet consistent.

Voordruk

• < 420 kPa
• ≥ 420 kPa

Categorie aantal bevoorradingen

• ≤ 5
• > 5

reactietijdNoodstop

• ≤ 5 s
• > 5 s

hoeveelheidsklasse stikstofgehalte

• [N2] < 5%
• 5% ≤ [N2] ≤ 10%
• [N2] > 10%

• Wie gaat er wat van merken? Dataleveranciers, 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? Ja, want enumeraties worden aangepast
• Is het backwardscompatibel? Nee
• X-, Y- of Z-wijziging: Y

Aanleiding wijziging
Het gewenste proces voor het bijwerken van kwetsbare gebouwen en locaties (KGL) in het REV is niet helemaal in lijn met het IMEV.

https://user-images.githubusercontent.com/80040145/220386405-9b24e2d1-8beb-4f88-969e-57d03af34339.png

Voorgestelde wijziging
Informatie die al in de BAG zit moet uit het IMEV gehaald worden, behalve de ID's waarmee een koppeling gelegd kan worden naar de BAG-objecten. Dat betekent verwijderen van de volgende attributen bij het object KwetsbaarGebouw:

• geometrie
• gebruiksdoeleinden
• oppervlakte

En toevoegen:

• pandidentificatie: IdentificatieBAG {0..1}
  * gebruiksdoeleindenInDetail: CharacterString {0..*}
  
  Het attribuut adresseebaarObjectIdentificatie kan blijven want dat gaat over het adres en niet over het pand. Een pand kan meerdere adresseerbare objecten bevatten. De kardinaliteit moet daarom naar {0..*}. Als een kinderdagverblijf in een pand zit waar ook andere adressen in zitten wil je wel weten welk adres bij dit specifieke kwetsbare object hoort. Omdat onbekend is waar in het pand dit kinderdagverblijf zit, is ook de geometrie van het pand nodig. Die kan dan gevonden worden met het BAGPandID.
  Volgens de definitie van een KwetsbaarGebouw in het BKL kan het ook om een woonwagen of woonschip gaan. In dat geval is er geen sprake van een BAG-pand en daarom is de kardinaliteit {0..1}

  .
  Het attribuut "gebruiksdoeleindenInDetail" wordt toegevoegd omdat de gebruiksdoeleinden in de BAG ontoereikend zijn om de kwetsbaarheid aan te geven.

https://user-images.githubusercontent.com/80040145/226675568-c6facf3c-2446-4b55-83dd-69c89108f19d.png

Impactanalyse

• Wie gaat er wat van merken? Dataleveranciers, 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? Ja
• Is het backwardscompatibel? Nee
• X-, Y- of Z-wijziging: X

Aanleiding wijziging
In het IMEV 1.3 bestaan o.a. de volgende objecttypen:

OpslagVuurwerkF4 (VIII-A Explosieaandachtsgebied vuurwerk voor opslag van categorie F4);
OpslagVuurwerkF1F2F3T1T2 (VIII-B Explosieaandachtsgebied vuurwerk voor opslag van categorie F1, F2, F3, of pyrotechnische artikelen voor theatergebruik van categorie T1 of T2).
Beide objecten hebben de enumeratie ' CategorieVuurwerk' met de waarden:

T1;
T2;
F1;
F2;
F3;
F4;
gegevenInTransitie.
Als gevolg hiervan is het bijvoorbeeld toegestaan om in het REV de 'OpslagVuurwerkF4' met elke waarde uit de enumeratie 'CategorieVuurwerk' op te voeren, zoals 'T1'.
Dit is onjuist en komt de kwaliteit van de REV data niet ten goede.

Voorgestelde wijziging
Neem een aparte enumeratie op in het IMEV voor 'Opslag-Vuurwerk-F4': ' CategorieVuurwerkF4' met cardinaliteit 0..1 en de waarde:
F4.
gegevenInTransitie
Neem een aparte enumeratie op in het IMEV voor 'Opslag-Vuurwerk-F1F2F3T1T2': 'CategorieVuurwerkF1F2F3T1T2' met cardinaliteit 0 .. * en de waarden:
F1;
F2;
F3;
T1;
T2;
gegevenInTransitie.
Laat de enumeratie ' CategorieVuurwerk' vervallen.
Impactanalyse
Wie gaat er wat van merken? Dataleveranciers van buisleidingen, 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? Ja
Is het backwardscompatibel? Alleen niet als oude aanlever bestanden waarden gekozen hebben die hier niet aan voldoen
X-, Y- of Z-wijziging: Y

Aanleiding wijziging
Aanpassingen zoals gedaan aan LocatieEVActiviteit in v1.3 zijn niet doorgevoerd op Buisleidingstelsel.
Dat is niet consequent.

Voorgestelde wijziging
Dezelfde aanpassingen aan LocatieEVActiviteit in v1.3 ook doorvoeren op Buisleidingstelsel.
Het betreft toevoegen locatieomschrijving en aanpassen kardinaliteit kvkNummerExploitant van 1..1 naar 1..*

Impactanalyse

• Wie gaat er wat van merken? *Dataleverancier en 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? *Ja*
• Is het backwardscompatibel? *Ja*
• X-, Y- of Z-wijziging *Y*

Bij deze de bijgewerkte validatiematrix (bijlage). Hierbij het verzoek deze bij te werken.

In de huidige versies van TPOD voorbereidingsbesluit en TPOD projectbesluit is in het hoofdstuk over het annoteren van het tijdelijk regelingdeel met OW-objecten verwezen naar TPOD omgevingsplan en TPOD omgevingsverordening. Daarmee wordt de indruk gewekt dat alle OW-objecten die in omgevingsplan respectievelijk omgevingsverordening gebruikt kunnen worden, ook voor een voorbereidingsbesluit en het tijdelijk regelingdeel van het projectbesluit gebruikt kunnen worden. Inmiddels is gebleken dat er OW-objecten zijn waarmee een voorbereidingsbesluit c.q. projectbesluit niet geannoteerd kan worden, gezien de bepalingen van de Omgevingswet over de inhoud van die instrumenten. Daarom is het wenselijk om in deze TPOD’s niet meer te verwijzen naar andere TPOD’s, maar in de TPOD’s te specificeren welke OW-objecten mogen worden gebruikt.

In STOP is in zowel de BesluitMetadata als in de RegelingMetadata het gegeven Citeertitel een optioneel gegeven. Dat is in de TPOD’s overgenomen. In de TPOD’s wordt t.a.v. Citeertitel in de RegelingMetadata aanbevolen om dat gegeven te gebruiken; t.a.v. Citeertitel in de BesluitMetadata wordt aanbevolen om dat gegeven niet te gebruiken.

Inmiddels is gebleken dat de Citeertitel van Regeling én van Besluit voor de DSO-viewer een heel bruikbaar gegeven is om regelingversies van elkaar te kunnen onderscheiden en voor diverse zoekfuncties. Het is wenselijk om in de TPOD-standaard het gegeven Citeertitel in BesluitMetadata en RegelingMetadata verplicht te stellen.