*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*

1 Het voorstel is om bij 'OpslagVuurwerkF1F2F3T1T2 het volgende 'Inrichtingselement' toe te voegen 'Objecttype': Verkoopruimte

2a Om een 'Bewaarplaats' bij 'OpslagVuurwerkF4' te hernoemen naar een 'BewaarplaatsF4' (ivm afwijkend attribuut: 'hoeveelheidNEMBewaarplaats', zie onder)

2b Om een 'SamengesteldeReferentie' bij 'OpslagVuurwerkF4' te hernoemen naar een 'SamengesteldeReferentieF4' (ivm afwijkend attribuut: 'hoeveelheidNEMBewaarplaats', zie onder)

2c Om een 'Bewaarplaats' bij 'OpslagVuurwerkF1F2F3T1T2' te hernoemen naar een 'BewaarplaatsF1F2F3T1T2' (ivm afwijkend attribuut: 'hoeveelheidVuurwerkBewaarplaats', zie onder)

2d Om een 'SamengesteldeReferentie' bij 'OpslagVuurwerkF1F2F3T1T2' te hernoemen naar een 'SamengesteldeReferentieF1F2F3T1T2' (ivm afwijkend attribuut: 'hoeveelheidVuurwerkBewaarplaats', zie onder)

3a. om het attribuut 'hoeveelheidVuurwerk': Niet te verplaatsen maar te behouden bij: OpslagVuurwerkF4; Het voor OpslagVuurwerkF4 te hernoemen naar: 'hoeveelheidNEMLocatie'; De definitie aan te passen van 'Hoeveelheid vuurwerk (als Netto Explosieve Massa in kg)' naar 'hoeveelheid Netto Explosieve Massa (NEM) in de inrichting: sommatie van de aanwezige hoeveelheid NEM in de bewaarplaats en de bewerkingsruimte, uitgedrukt in kilogrammen' .

3b. - Niet te verplaatsen maar te behouden bij: OpslagVuurwerkF1F2F3T1T2; Het voor OpslagVuurwerkF1F2F3T1T2 te hernoemen naar: 'hoeveelheidVuurwerkLocatie' De definitie aan te passen van 'Hoeveelheid vuurwerk (als Netto Explosieve Massa in kg)' naar 'hoeveelheid consumentenvuurwerk in de inrichting: sommatie van de aanwezige hoeveelheid consumentenvuurwerk in de bewaarplaats, de bufferbewaarplaats en de verkoopruimte, uitgedrukt in kilogrammen' .

4a. om het attribuut 'hoeveelheidNEMBewaarplaats': Op te nemen in het IMEV bij een 'BewaarplaatsF4', een 'SamengesteldeReferentieF4 en een 'Bewerkingsruimte' (zodat de som uitgerekend kan worden); Te voorzien van de definitie: Toegestane hoeveelheid Netto Explosieve Massa (NEM) in vuurwerk van categorie F4 in de bewaarplaats of bewerkingsruimte in kg

4b. om het attribuut 'hoeveelheidVuurwerkBewaarplaats': Op te nemen in het IMEV bij een 'Bufferbewaarplaats', een 'BewaarplaatsF1F2F3T1T2' en een 'Verkoopruimte', (zodat de som uitgerekend kan worden); Te voorzien van de definitie: Toegestane hoeveelheid vuurwerk van categorie F1, F2 of F3 en pyrotechnische artikelen voor theatergebruik in de (buffer)bewaarplaats of verkoopruimte in kg [*https://user-images.githubusercontent.com/80040145/234599412-a5368711-78c5-4643-90ba-e2e88d456fbe.png] Unable to render embedded object: File (*[*https://user-images.githubusercontent.com/80040145/234599412-a5368711-78c5-4643-90ba-e2e88d456fbe.png) not found. [*https://user-images.githubusercontent.com/80040145/234599530-f78ece73-7786-4dc6-84a1-346c79823389.png] ![*https://user-images.githubusercontent.com/80040145/234599530-f78ece73-7786-4dc6-84a1-346c79823389.png|alt="image"*|https://user-images.githubusercontent.com/80040145/234599530-f78ece73-7786-4dc6-84a1-346c79823389.png|alt="image"]

**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 Voor bestaande data moet bedacht worden hoe de hoeveelheden verdeeld worden over meerdere bewaarplaatsen.

Toelichting

Er speelt een fundamentele vraag net als in #41 en #89: a) Is het IMEV bedoeld om de gegevens van de EV contouren te delen inclusief een aantal gegevens die nodig zijn als basisgegeven bij de EV contour? b) Is het IMEV bedoeld om de gegevens van de EV contouren te delen inclusief alle gegevens die nodig zijn om de contour te berekenen? Het uitgangspunt voor het IMEV is altijd het BKL. Dus alleen gegevens die voor het REV gevraagd worden in het BKL horen thuis in het IMEV. Dit zal dus eerst per geval bekeken moeten worden.

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: X

laag

Een volledige inventarisatie waar dit voorkomt is nog niet uitgevoerd

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

WAS: https://user-images.githubusercontent.com/9932784/231439229-d4be9fa6-7e63-434b-ad9f-bc295f87b87d.png

WORDT: https://user-images.githubusercontent.com/9932784/231439535-bc2a7cb2-ec0e-4f0d-afd9-9b3dff635908.png

Met een / wordt in bovenstaande figuur aangegeven dat het attribuut afgeleid is uit andere gegevens en dat het door bronhouders dus niet hoeft worden aangeleverd. In de toelichting van het attribuut wordt opgenomen hoe het wordt afgeleid, of waar het vandaan komt. In dit geval gaat het om gegevens uit de BAG die via de pandIdentificatie zijn op te vragen. Met als tekst bij bijvoorbeeld '/gebruiksdoeleinden': Definitie: Het vergunde gebruiksdoel of de vergunde gebruiksdoelen zoals geregistreerd in de BAG. Toelichting: Dit gegeven wordt niet door de bronhouder aangeleverd maar wordt door het REV gegenereerd op basis van de pandIdentificatie. Daarnaast wordt het attribuut “gebruiksdoeleindenDetail“ toegevoegd, omdat de gebruiksdoleinden zoals in de BAG staan niet toereikend zijn.

• 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

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

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

Was: https://user-images.githubusercontent.com/9932784/231506330-9dd49f59-7a2c-4cab-9fea-301e3c353b15.png

Wordt: https://user-images.githubusercontent.com/9932784/231508009-fb1e848e-d2f6-40f6-85df-5d4a6ab7172f.png

Zie ook #52 en #68.

Geef hier een indicatie van de impact van de wijziging:

• 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

midden

Ruimte voor extra toelichting. Bijvoorbeeld alternatieven die je overwogen hebt.

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.

Aanleiding wijziging
In het IMEV 1.3 kan een 'Bewaarplaats' onderdeel zijn van een 'OpslagVuurwerkF1F2F3T1T2';

Bij een 'Bewaarplaats' is in het 'overzicht attributen' het attribuut 'oppervlakteDeuropening' opgenomen (in m2). Zie bv tabel 6.1.50.5 en 6.1.54.1.5. In bijlage VII B bij artikel 5.23 van het BKL staat beschreven hoe een explosieAandachtsgebied vuurwerk voor opslag van vuurwerk van categorie F1, F2 of F3 of pyrotechnische artikelen voor theatergebruik van categorie T1 of T2 bepaald moet worden. In de bijbehorende figuur worden een aantal parameters gegeven (a, b, c). De breedte van de deur van de opslag ontbreekt hier, maar is wel nodig voor de berekening van het explosieAandachtsgebied.

[https://user-images.githubusercontent.com/115161221/218746906-38fbf0c7-a05e-40cd-bb20-3fac521a9b32.png|alt="image"|https://user-images.githubusercontent.com/115161221/218746906-38fbf0c7-a05e-40cd-bb20-3fac521a9b32.png|alt="image"]

In het RRGS werd dit probleem opgelost door het oppervlak van de deuropening (dat wel wordt geregistreerd) om te rekenen naar de breedte van een deuropening door middel van een aantal impliciete aannames: ||Categorie||Oppervlakte deuropening (m2)||Breedte deuropening (m)|| |Categorie 1|0-4|1.6| |Categorie 2|4-6|2.4| |Categorie 3|6-8|3.2| Waarbij maxOppervlakteDeuropeningCat / breedteDeuropeningCat = 2.5m (constante waarde). Wat is het probleem? # Omdat de breedte van de deur niet is opgenomen in het BKL en IMEV, is het niet mogelijk om zonder impliciete aannames het explosieAandachtsgebied te berekenen zoals beschreven in het BKL (zie hierboven); # De redelijkheid van de aannames voor het bepalen van het bovengenoemde explosieAandachtsgebied zoals voor het RRGS is gedaan is niet vast te stellen; # De aannames bij de berekening voor het RRGS zijn impliciet, verborgen in code (niet zichtbaar of openbaar); # Er is geen richting van de breedte van de deuropening (geometrie) beschikbaar. Samengevat: Het IMEV 1.3 bevat onvoldoende gegevens om een ExplosieAandachtsgebied 'OpslagVuurwerkF1F2F3T1T2' te berekenen zonder impliciete en mogelijk onjuiste aannames.

Voorgestelde wijziging

Om het explosieAandachtsgebied zonder impliciete aannames te kunnen berekenen, is het goed om de volgende attributen toe te voegen aan de BufferBewaarplaats: * richtingVoorwaarts: Real (graden) * afstandVoorwaarts: Real (m) * afstandZijwaarts: Real (m) * afstandAchterwaarts: Real (m) * deurbreedte: Real (m) Hierbij komen de 3 afstanden overeen met de paramaters a, b en c (zie bijgevoegde figuur). Deze attributen zouden verplicht moeten zijn. De situatie was: [https://user-images.githubusercontent.com/80040145/231479664-95239281-ac55-4703-96d4-45133c2b8f34.png] Wordt: [https://user-images.githubusercontent.com/80040145/231758688-955569d3-07f1-4702-9e59-a88649c84614.png]

Impactanalyse

• Wie gaat er wat van merken? Dataleveranciers 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, want extra attribuut

Prioriteit

middel