Meldingen geo-standaarden

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

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