Meldingen geo-standaarden

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

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.

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

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

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.

Aanleiding

Achtergrond

• 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.

In het RRGS werd dit probleem opgelost door het oppervlak van de deuropening (dat wel wordt geregisteerd) om te rekenen naar de breedte van een deuropening door middel van een aantal impliciete aannames:

Waarbij maxOppervlakteDeuropeningCat / breedteDeuropeningCat = 2.5m (constante waarde).

Wat is het probleem?

1. 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);
2. De redelijkheid van de aannames voor het bepalen van het bovengenoemde explosieAandachtsgebied zoals voor het RRGS is gedaan is niet vast te stellen;
3. De aannames bij de berekening voor het RRGS zijn impliciet, verborgen in code (niet zichtbaar of openbaar);
4. 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.

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

• 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

middel

Aanleiding wijziging

Het object 'OpslagtankPropaanPropeenVasteAfstand_GeenVergunningplicht (A7) heeft een 'Vulpunt' en/of een 'OpstelplaatsVoertuig'.
Bij het object 'OpslagtankPropaanPropeenVasteAfstand_GeenVergunningplicht' ontbreekt naar mijn idee het attribuut 'inhoud'.

Beschouw het volgende:

• Voor de activiteit A7 met referentieEvContouren 'OpstelplaatsVoertuig'/ 'Vulpunt' worden de afstanden voor de EV contouren bepaald door tabel 4.899 uit het BAL;
• Een van de attributen die deze afstanden bepaalt is in deze tabel: 'inhoud opslagtank';
• 'Inhoud' is een attribuut van een 'OpslagReferentie' (opslagtank), maar niet van een 'Vulpunt' of 'OpstelplaatsVoertuig';
• Het is niet logisch om de waarde van een attribuut (inhoud) van de ene referentieEvContour (opslagreferentie) toe te passen voor de bepaling van de afstanden voor de EV contour van een andere referentie ('sibling': Vulpunt, OpstelplaatsVoertuig);
• Het is niet handig om het attribuut 'inhoud' toe te voegen aan een 'OpstelplaatsVoertuig' of 'Vulpunt'. Dit werkt namelijk niet voor alle EV activiteiten.

Voeg het attribuut 'inhoud' in het IMEV toe aan 'OpslagtankPropaanPropeenVasteAfstand_GeenVergunningplicht'.

https://user-images.githubusercontent.com/80040145/234587855-c1e15825-f10c-411c-ad19-cd2718e4cf6b.png

• 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

middel