Meldingen geo-standaarden

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

Toe te voegen validatieregels aan de validatiematrix:

|OZON0375|Blokkerend|Een kaart mag niet twee keer verwijzen naar dezelfde kaartlaag.|

|OZON0376|Blokkerend|Een kaartlaag mag niet twee keer verwijzen naar dezelfde activiteitlocatieaanduiding.|

|OZON0377|Blokkerend|Een kaartlaag mag niet twee keer verwijzen naar dezelfde omgevingsnorm.|

|OZON0378|Blokkerend|Een kaartlaag mag niet wee keer verwijzen naar dezelfde gebiedsaanwijzing.|

|OZON0379|Blokkerend|Een regelvooriedereen mag niet twee keer verwijzen naar hetzelfde thema.|

|OZON0380|Blokkerend|Een instructieregel mag niet twee keer verwijzen naar hetzelfde thema.|

|OZON0381|Blokkerend|Een omgevingswaarderegel mag niet twee keer verwijzen naar hetzelfde thema.|

|OZON0382|Blokkerend|Een instructieregel mag niet twee keer verwijzen naar hetzelfde instrument.|

|OZON0383|Blokkerend|Een instructieregel mag niet twee keer verwijzen naar dezelfde taakuitoefening. |

|OZON0384|Blokkerend|Een norm mag niet twee keer verwijzen naar dezelfde normwaarde.|

|OZON0385|Blokkerend|Een normwaarde mag niet twee keer verwijzen naar dezelfde locatie.|

|OZON1021|Blokkerend|Alle regelingen (behalve intrekkingen) moeten een AnnotatieBijToestand bevatten.|

|OZON1037|Blokkerend|Een regeling die een tijdelijk deel is, mag zelf geen pons hebben.|

|OZON1039|Blokkerend|Een ontwerpregeling moet procedurestappen hebben die voorkomen in de waardelijst procedurestappen_ontwerp|

|OZON5001|Blokkerend|(TPOD1890) Het objecttype in de identificatie van het OwObject moet overeenkomen met het objecttype van het OwObject|

|OZON5002|Blokkerend|(TPOD2080) Een instructieregel moet ofwel een 'InstructieregelInstrument', ofwel een 'InstructieregelTaakuitoefening' hebben|

|OZON5003|Blokkerend|(TPOD2090) De normwaarden binnen een norm moeten hetzelfde type hebben.|

|OZON5004|Blokkerend|(TPOD2100) Als een norm een Eenheid heeft, dan moeten de normwaarden van het type kwantitatief zijn.|

|OZON5005|Blokkerend|(TPOD2110) Een Tekstdeel met een locatie moet ook een idealisatie hebben.|

Samengestelde referenties mogen niet voorkomen bij vastgestelde afstanden bij activiteiten.
Dit staat niet goed in het IMEV.

Constraint toevoegen: SamengesteldeReferentie mag niet voorkomen als Aandachtsgebied.categorieAandachtsgebied="vastgesteld"

Geef hier een indicatie van de impact van de wijziging:

• Wie gaat er wat van merken? dataproviders en de softwareleveranciers die deze validatie moeten inbouwen
• 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? Waarschijnlijk niet
• De bestaande data in het REV moet hier dan wel met terugwerkende kracht op gecontroleerd worden.
• X-, Y- of Z-wijziging: Z
• Er zal nog wel in de bestaande data gecontroleerd moeten worden in hoeverre daar aan deze constraint voldaan wordt.

midden

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

De kennisgeving van de verleende omgevingsvergunning voor de buitenplanse omgevingsplanactiviteit levert een bevoegd gezag met DROP aan, samen met een GML van de locatie waarvoor de omgevingsvergunning is verleend. Vijf jaar na het onherroepelijk worden ervan wordt het omgevingsplan met die omgevingsvergunning in overeenstemming gebracht. Vanaf dat moment moet (de locatie van) de kennisgeving niet meer zichtbaar zijn in DSO-LV. Uitgewerkt moet worden hoe zo’n contour verwijderd moet worden.

In de nieuwe TPOD omgevingsplan zie ik iets wat voor verwarring zorgt, namelijk dat de artikelsgewijze toelichting bij de regeling zal gaan vervallen. Dit geldt alleen voor de artikelsgewijze toelichting als "hoofdelement", maar niet voor artikelsgewijze toelichting binnen Toelichting.
Dit is veel mensen niet in eerste lezing duidelijk, zorg voor verwarring en ongeloof (geen artikelsgewijze toelichting meer

Is het mogelijk om de tekst te verduidelijken?

ArtikelgewijzeToelichting
STOP-element dat de artikelsgewijze toelichting, oftewel de toelichting op de artikelen in de Regeling, bevat. Optioneel element. Komt 0 of 1 keer voor. Mogelijkheid die STOP biedt voor een toelichting die uitsluitend een toelichting op de artikelen in de regeling is. Dit element zal in een toekomstige versie van de standaard vervallen; gebruik daarvan wordt daarom nu afgeraden.. Indien toch gebruikt gelden voor deze ArtikelgewijzeToelichting dezelfde eisen als voor de ArtikelgewijzeToelichting binnen het element Toelichting onder 4.

Bij het definiëren van een omgevingsnorm “maximum aantal standplaatsen voor ambulante handel” voor het omgevingsplan van Gemeente Nieuwegein, menen wij dat een geschikte waarde ontbreekt in de waardelijst “Type norm”:

De waarde die het dichtst in de buurt komt is “maximum aantal winkels”. Echter, wij stellen de regels voor ambulante handel onder meer om te voorkomen dat het functioneren van reguliere winkels niet wordt aangetast. Om ze dan te zien als winkel is wat ongelukkig.

Bovendien geeft de definitie in de Stelselcatalogus aan dat deze waarde dient te worden gebruikt in combinatie met waarde “maatvoering bouwen” van waardelijst Omgevingsnormgroep, terwijl wij menen dat “maatvoering gebruik” in dit geval passend is.

Daarom doen ik namens Gemeente Nieuwegein hierbij het verzoek een waarde “maximum aantal standplaatsen” of “maximum aantal standplaatsen voor ambulante handel” toe te voegen aan de waardelijst

Voorlopig gebruiken we hierbij voor “Type norm” de waarde “nog toe te voegen|https://stelselcatalogus.omgevingswet.overheid.nl/begrippen/detail?doc=http:%2F%2Fstandaarden.omgevingswet.overheid.nl%2Ftypenorm%2Fdoc%2F20220614000000%2Fconcept%2FNogToeTeVoegen]”;

Aanleiding wijziging
Gebruik van doublelists wordt gezien als inconsistentie in het model nu het voor het geluidscherm is vervangen door een 2e geometrie (bovenkantscherm).

Voorgestelde wijziging
Voor andere objecten die nog wel een doublelist gebruiken moet een vergelijkbare oplossing gekozen worden als voor geluidscherm. Zie https://github.com/Geonovum/IMG/issues/72 . Het betreft nu dan dus WegdeelGPP, SpoordeelGPP, Bouwwerk, Vegetatiegebied en Procesinstallatiegebied. Zie ook https://github.com/Geonovum/IMG/issues/183

Impactanalyse
Deze wijziging heeft alleen impact op partijen die bovengenoemde objecten aanleveren.
Deze wijziging heeft geen impact op de semantiek van het model
De wijziging resulteert wel in niet backwards-compatible wijziging in het xml-schema als de attributen waar de doublelists in stonden ook echt verwijderd worden, maar dat kan eventueel ook later, want het veld is niet verplicht. In dat laatste geval is het wel backwards-compatible.

Het betreft een X-wijziging omdat reeds aangemaakte data als input voor de CVGG aangepast zal moeten worden.