Meldingen geo-standaarden

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

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.

Voorgestelde wijziging

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

https://user-images.githubusercontent.com/80040145/234587855-c1e15825-f10c-411c-ad19-cd2718e4cf6b.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

• Een 'pandIdentificatie' is een attribuut van een 'LocatieActiviteit' in het IMEV 1.3;
• De definitie is: 'De unieke aanduiding van een pand middels de BAGid' (6.1.50.22. tabel 'overzicht attributen);
• Het heeft een kardinaliteit [0 .. 1].

Het is in het IMEV niet duidelijk van welk pand het BAGid geregistreerd mag worden. Er zijn meerdere mogelijkheden:

1. Het pand / de panden waarbinnen zich een of meerdere EV activiteiten (referentieEVContouren) bevinden;
2. Het pand / de panden waarbinnen zich een of meerdere BAG verblijfsobjecten (dus met o.a. nummeraanduiding) bevinden;
3. Het pand / de panden die voldoen aan een ander criterium dat nog niet gedefinieerd is.

Aangezien het hier om externe veiligheidsrisico's gaat, lijkt optie 1 mij het meest waarschijnlijk. Maar omdat een EV activiteit geen geometrie heeft, is het waarschijnlijk beter om een pand te relateren aan een 'referentieEVContour'.

1. Neem in 6.1.50.22 in de tabel 'overzicht attributen' in de definitie op van welk pand het id moet worden opgenomen. Bijvoorbeeld (aangenomen dat het om panden met referentieEVContouren gaat):

'De unieke aanduiding van een pand waarbinnen zich een of meerdere referentieEVContouren bevinden, middels de BAGid'

1. Pas evt de kardinaliteit van [0 .. 1] aan naar [0 .. *]. Reden:

• Geen, een of meerdere panden kunnen bestaan met (of zonder) een of meerdere referentieEVContouren;
• Geen, een of meerdere panden kunnen bestaan met (of zonder) een of meerdere verblijfsobjecten;
• Geen, een of meerdere panden kunnen bestaan met (of zonder) een of meerdere 'ander criterium' .

1. Verplaats het attribuut 'pandIdentificatie' van het objecttype 'LocatieActiviteit' naar het objecttype 'ReferentieEVContour ' (alleen als de 'pandIdentificatie' gerelateerd is aan (een) referentieEVContour).
2. Pas in 6.1.50.19 in de tabel 'overzicht attributen' de definitie aan van de geometrie:
   De tweedimensionale geometrische representatie van een kwetsbare gebouw, bestaand uit de geometrie van een of meer BAG panden. Maar dit hoor eigenlijk bij KwetsbaarGebouw aanpassen aan BAG  #92

• Wie gaat er wat van merken? Dataprovider, en softwareleveranciers als kardinaliteit ook aangepast wordt of als het attribuut verplaatst wordt.
• 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, als kardinaliteit ook aangepast wordt of als het attribuut verplaatst wordt.

midden

De voorgestelde wijziging zorgt voor meer duidelijkheid bij bronhouders over wat ze aan moeten leveren. Ook maakt het mogelijk volledigere data van een hogere kwaliteit aan te leveren.

NB:
Voor andere BAG attributen ('adresseerbaar object', 'adres', 'oppervlakte', 'gebruiksdoeleinden') zouden de definities, kardinaliteit en parent objecttype op een analoge manier verbeterd moeten worden, op basis van analoge argumenten (definitie 'adres' is ook niet geupdatet nav BAGid wijziging);

In het IMEV 1.3 bestaan de volgende REV attributen met een link naar de BAG:

• adres;
• adresExploitant;
• adresseerbaarObjectIdentificatie;
• pandIdentificatie;
• gebruiksdoeleinden;
• oppervlakte;
• verwijzingBAG;
• identificatieBAG.

Vooral in het geval van 'adres' en 'adresExploitant' dekt de naam van het REV attribuut onvoldoende de inhoud. Dit leidt in de praktijk tot tot onduidelijkheid.

Ik stel hierbij daarom voor de naamgeving van deze REV attributen op een consistente manier aan te passen zodat deze de inhoud beter dekt:

• adres -> idNummeraanduidingBAG;
• adresExploitant -> idNummeraanduidingBAGExploitant;
• adresseerbaarObjectIdentificatie -> idAdresseerbaarobjectBAG;
• pandIdentificatie -> idPandBAG;
• gebruiksdoeleinden -> gebruiksdoelenVerblijfsobjectBAG (indien gehandhaafd en de definitie ongewijzigd blijft);
• oppervlakte -> oppervlakteVerblijfsobjectBAG (indien gehandhaafd);
• verwijzingBAG (ongewijzigd);
• identificatieBAG -> idBAG.

Verder:

• Is in de BAG sprake van 'gebruiksdoelen' ipv 'gebruiksdoeleinden' (REV). Hier is in het bovenstaande voorstel rekening mee gehouden;
• Wordt in de BAG alleen van 'Verblijfsobjecten' het oppervlak geregisteerd. De definitie van 'oppervlakte' in het REV ('Het oppervlakte van het gebouw zoals geregisteerd in de BAG' is dus onjuist. Dit zou moeten zijn: 'De gebruiksoppervlakte van een verblijfsobject in gehele vierkante meters zoals geregisteerd in de BAG'

Geef hier een indicatie van de impact van de wijziging:

• Wie gaat er wat van merken? Softwareleveranciers en dataproviders
• 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 er veranderen attributen van naam.
• Is het een X,Y of Z-wijziging: X, want attribuutnamen veranderen

midden

De voorgestelde naamgeving is consistent:

• Eerst wordt aangegeven welk BAG attribuut het betreft (identificatie / gebruiksdoelen / oppervlakte / verwijzing). Identificatiecode wordt hierbij consequent afgekort tot 'id' om eea kort te houden zonder dat het minder duidelijk wordt;
• Vervolgens wordt, als relevant, het overkoepelende BAG object vermeld (Nummeraanduiding / AdresseerbaarObject / Verblijfsobject);
• Daarna wordt 'BAG' genoemd, de overkoepelende basisregistratie;
• Als laatste, als relevant, wordt een 'REV specifieke' toelichting bijgevoegd.

Verder is het bovenstaande voorstel zoveel mogelijk lowerCamelCase (uitzondering: BAG. In het IMEV worden afkortingen in hoofdletters geschreven, dit heb ik in dit voorstel gehandhaafd).

In het IMEV 1.3 is een aantal identificatienummers opgenomen, o.a.

• BAGid;
• KvK nummer;
• CAS nummer;
• UN nummer;
• ....

Het bestaande pattern is niet specifiek genoeg voor data validatie en dus kwaliteit. Dit kan specifieker:

• een BAGid bestaat altijd uit 16 cijfers (muv dat voor een 'Woonplaats', maar die hoeft niet vastgelegd te worden in het REV). Zie voor een nog specifiekere beschrijving de Catalogus BAG, 2018, paragraaf 3.7.1;
• KvK-nummer bestaat uit 8 cijfers (zie 'De nummers van het handelsregister, p.5);
• CAS nummer voldoet ook aan vaste eisen (o.a. max 10 cijfers, zie wikipedia: 'CAS-nummer en 'Controlegetal');
• UN nummer bestaat uit 4 cijfers, beginnend vanaf 0004 (0000 tm 0003 zijn buiten gebruik, zie 'Range' bij 'UN number' op de Engelstalige Wikipedia pagina)

Een striktere beschrijving (specifieker pattern) moet in het IMEV worden opgenomen, zodat in de API van het REV hier beter op gevalideerd kan worden. Dit komt de datakwaliteit in het REV ten goede.

Geef hier een indicatie van de impact van de wijziging:

• Wie gaat er wat van merken? - Softwareleveranciers, gebruikers
• 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? Nee
• Kan leiden tot een opschoon actie om foutieve data te corrigeren.

laag

Een striktere beschrijving vergemakkelijkt de validatie van gegevens en komt de kwaliteit van de gegevens in het REV ten goede.
Gerelateerd aan #33

Er zit een inconsistentie tussen de volgende attributen:

https://docs.geostandaarden.nl/imev/imev/#detail_class_IMEVBasis_BevoorradingCategorieOfExactAantal
https://docs.geostandaarden.nl/imev/imev/#detail_attribute_BKLActiviteiten_TankenLNGVoertuigWerktuig_reactietijdNoodstop
https://docs.geostandaarden.nl/imev/imev/#detail_attribute_BKLActiviteiten_TankenLNGVoertuigWerktuig_voordruk

Voor 'aantalBevoorradingen' is in IMEV 1.3 gekozen voor de volgende oplossing:
#39

Voor reactieTijdNoodstop en Voordruk is (op mijn verzoek) gekozen om het datatype te veranderen van 'integer' naar 'boolean':
#78
(note: Bij issue 39 is terecht door de expertgroep is gewezen op het aandachtspunt dat extra conversie evt nodig zou zijn. Dat is bij issue 78 ook het geval maar niet ondervangen)

Dit zijn verschillende implementaties in de standaard van hetzelfde 'probleem' waarbij een keuze gemaakt moet worden tussen een categorie of exact aantal.

Voordelen van de gesuggereerde oplossing:

1. Consistent;
2. Geen conversie nodig, beperking risico.

De oplossing waar voor gekozen is in issue 39 (waarde ofwel een keuze uit een enumeratie, ofwel een integer) zou ook moeten worden toegepast voor reactieTijdNoodstop en Voordruk. Tevens moet worden uitgezocht of deze inconsistentie zich ook voordoet bij andere waarden in de standaard. De voorgestelde wijziging heeft volgend effect op model:

Was:

Wordt:

Wie gaat er wat van merken? Dataleveranciers en software leveranciers
Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Ja t.o.v. situatie 1.3 en Nee t.o.v. situatie 1.2
Heeft het impact op het json-schema? Ja, want er wordt voorgesteld datatypen te veranderen en keuzes in te bouwen.

In versie 1.3 van IMEV is de het attribuut LocatieActiviteit.kvkNummerExploitant voidable geworden. Dit kvk-nummer is nodig voor INSPIRE om de NACE-code in het handelsregister te koppelen. Voor de meeste activiteiten is het niet zo erg als die ontbreekt, want dan is er wel nog een tabel waarin de meest voorkomende NACE-code per BKL-activiteit is opgenomen. Voor de SevesoInrichting is dat alleen niet mogelijk, omdat daar veel verschillende NACE-codes voor kunnen komen. Dan kan het dus voorkomen dat daar gaan NACE-code aan gekoppeld kan worden.

Het voorstel is om een constraint op te nemen dat in geval van een SevesoInrichting er geen kvkNummerExploitant mag ontbreken bij de bijbehorende LocatieActiviteit.

Geef hier een indicatie van de impact van de wijziging:

• Wie gaat er wat van merken? Dataleveranciers van SevesoInrichtingen en de verantwoordelijke organisatie voor het inbouwen van validaties.
• 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, indien constraints onderdeel worden van het json-schema.
• Er zal er voor gezorgd moeten worden dat alle Sevesoinrichtingen die er nu in zitten ook een correct KvK-nummer hebben. Die blijken nu nog dummy-waarden te bevatten.

hoog