Meldingen geo-standaarden

Aanleiding wijziging
Bij welke EVActiviteiten en referentieEVContouren dit zinvol is en waarom, moet nog vastgesteld worden.

Voorgestelde wijziging
Het wijzigingsverzoek is om optionele velden bij evActviteit(en) zoveel mogelijk naar referentieEVContouren te verplaatsen.

Locatie in UML

Impactanalyse
Wie gaat er wat van merken? dataprovider en gebruiker REV en Softwareleveranciers
Verandert de semantiek van de objecten? Nee
Heeft het impact op het json-schema? Ja, groot. Dit betekent veel werk voor software leveranciers. De data die al geconverteerd is, zal omgezet moeten worden in het REV.

Aanleiding wijziging
De aanleiding is dat er minder fouten worden gemaakt wanneer er categorieën gebruikt worden.

Voorgestelde wijziging
Het voorstel is om op de plek waar nu Real staat de al bestaande enumeratie DoorzetCategorie te gebruiken bij de EVActiviteiten: TankenLPG en Opslagtank­Propeen_Vaste­Afstand­Vergunningplicht.

Locatie in UML

Impactanalyse
Wie gaat er wat van merken? dataprovider en gebruiker REV en Softwareleveranciers
Verandert de semantiek van de objecten? Nee
Heeft het impact op het json-schema? Ja

Toelichting

Adviesgroep 13-9-2023 heeft besloten deze wijziging niet door te voeren. Zie ook:

https://github.com/Geonovum/imev-werkomgeving/issues/40#issuecomment-1723081803

Aanleiding wijziging
De aanleiding is dat er minder fouten worden gemaakt wanneer er categorieën gebruikt worden.

Locatie in UML

Voorgestelde wijziging
Het voorstel is om op de plek waar nu "Integer" staat de enumeratie CategorieAantalBevoorradingen, en dat verwijst dan naar een enumeratie met de 2 waarden "<= 5" en "> 5".

Impactanalyse

Wie gaat er wat van merken? dataprovider en gebruiker REV en Softwareleveranciers
Verandert de semantiek van de objecten? Nee
Heeft het impact op het json-schema? Ja

Aanleiding wijziging
In IMEV staat bij numerieke waarden alleen aangegeven of de waarde een Integer (geheel getal) of een Real (decimaal getal) is. Er staan geen andere invulvoorschriften (of constraints) voor numerieke waarden. Zoals bijvoorbeeld minimumwaarde, maximumwaarde, aantal cijfers achter de komma. Er kan dus op dit moment niet gevalideerd worden op deze invulvoorschriften.

Voorgestelde wijziging
Neem bij de kenmerken waar dat nodig is invulvoorschriften op in de vorm van constraints als minimum, maximum, aantal decimalen etc.

Er zijn zo'n 6 integer en 40 real waarden in IMEV. Ze komen voor bij typische kenmerken als afstand, oppervlakte, inhoud, aantal, lengte, massa etc.

Impactanalyse

• Wie gaat er wat van merken? dataprovider, REV, 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? Nog niet bekend. Waarschijnlijk niet. De invulvoorschriften kunnen met validatieregels gecontroleerd worden

Expertgroep 28-09-2022:
Wat levert het op: datakwaliteit.
Geen harde noodzaak, maar wel wenselijk.
Vooral de eenheden zijn belangrijk.
Voorstel: niet voor versie 1.3, maar voorbereiden voor een daaropvolgende versie, want inventarisatie door experts is eerst nodig.

De objecten “LijnbronIndustrie” en “VlakbronIndustrie” zijn niet in de geluidgegevenscollectie opgenomen, omdat deze geen specialisatie zijn van “GeluidgegevenscollectieElement”.
Melder vindt dat een fout omdat “VlakbronIndustrie” een eigenschap heeft welke essentieel is om berekende waarden te kunnen reproduceren, namelijk “negeerOverdrachtsobjecten”.
Je hebt in de berekening dan namelijk de geometrie van de vlakbron nodig om te kunnen achterhalen of een gebouw of scherm op deze vlakbron staat en je de bijbehorende reflectie en afscherming moet negeren.
Je kunt dus niet volstaan met alleen het inlezen van gegevens uit de GeluidgegevensCollectie en ik dacht dat dit de bedoeling was van de GeluidGegevensCollectie.
Aangezien een geluidgegevenscollectie nu geen vlakbronnen meer kan bevatten, is het niet meer mogelijk om op basis van de collectie de berekende resultaten te reproduceren.

In de toelichtingen van objecten die volgens het model geen subtype van geluidgegevenscollectieElement zijn, duidelijk maken dat alle objecten in het GML bestand belangrijk zijn en dus ook degenen die niet rechtstreeks in de geluidgegevenscollectie zitten.

Geef hier een indicatie van de impact van de wijziging:

• Wie gaat er wat van merken? De gebruikers van het model
• 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 xml-schema? Nee
• X, Y of Z-wijziging: Z

Aanleiding wijziging
Er is behoefte aan een nieuw objecttype voor geluidschermdelen met een diffractor. Dit punt komt voort uit een wijziging in de reken- en meetvoorschriften.

Voorgestelde wijziging

https://user-images.githubusercontent.com/80040145/209111384-3a161954-29b9-4763-be9b-387ae8d486af.png

• Nieuw objecttype “DiffractorOpGeluidschermdeel” met dezelfde velden welke een “ Geluidschermdeel ” nu heeft: bovenkantScherm, onderkantScherm, reflectiefactorLinks, reflectiefactorRechts, hellingshoek en statusZwevend, maar zonder profietype en schermtype. Het schermtype is altijd diffractor op scherm en hoeft dus niet apart opgegeven te worden.
• Het nieuwe objecttype heeft daarnaast als extra veld "diffractoreffect" van het type “ WaardePerOctaafband ”.
• Dit objecttype is een specialisatie van “Geluidoverdrachtobject ”.

Impactanalyse

• Wat betekent het voor de software van de CVGG, softwareleveranciers en bronhouders? Alle software dient hierop aangepast te worden. Ook de validatieregels in de CVGG moeten bijgewerkt worden.
• Wie gaat er wat van merken? Diegene die een diffractor op een geluidscherm wil aanleveren of gebruiken.
• 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 xml-schema? Ja
• Wat gaat er mis als we de wijziging niet doorvoeren? Het IMG ondersteunt dan niet het reken- en meetvoorschrift en daardoor kunnen bronhouders dan geen diffractors op geluidschermen aanleveren aan de CVGG, conform IMG.
• X,Y,Z-wijziging: Y, want er wordt alleen iets toegevoegd.

De validatieregels TPOD0410 t/m TPOD1070 gaan over de tekstuele inhoud van label, opschrift en nummer in de koppen van tekstelementen zoals hoofdstuk, afdeling en paragraaf en de nummering van leden en lijsten. Dit zijn moeilijk te implementeren validatieregels met beperkte opbrengst.

Het is gewenst om nieuwe validatieregels toe te voegen die valideren op soortRegeling in combinatie met het verantwoordelijk bevoegd gezag en validatieregels die valideren op soortRegeling en te gebruiken STOP-model voor Besluit en Regeling. Deze validatieregels zorgen er voor dat een bevoegd gezag alleen die omgevingsdocumenten kan aanleveren waartoe het juridisch bevoegd is. Het betreft validatieregels van deze typen:

• Als soortRegeling = 'Omgevingsplan' dan MOET de eindverantwoordelijke van het besluit een waarde uit waardelijst 'Gemeente' zijn
• Als soortRegeling = 'Omgevingsplan' dan MOET STOP model {BesluitCompact en RegelingCompact}

  of

  {BesluitCompact en RegelingMutatie}

  worden gebruikt

De discrepanties tussen de ‘interne’ Ozon Validatiematrix en de Validatiematrix in de Geonovum github[https://github.com/Geonovum/dso-validatiematrix] zijn nagelopen en daaruit komt de volgende lijst met wijzigingen.

Nieuwe regels, die nog niet in de Validatiematrix staan:

OZON0129 - (TPOD1960) Iedere verwijzing naar een geometrie vanuit een Lijn moet een lijn-geometrie zijn.

OZON0130 - (TPOD1970) Iedere verwijzing naar een geometrie vanuit een Punt moet een punt-geometrie zijn.

OZON0131 - (TPOD1980) Iedere verwijzing naar een geometrie vanuit een Gebied moet een gebied-geometrie zijn.

OZON0206 - (RTRG0019) Maximaal één activiteit van een gemeente mag verwijzen naar een bovenliggende activiteit niet van een gemeente

OZON0207 - (RTRG0020) Maximaal één activiteit van een provincie mag verwijzen naar een bovenliggende activiteit niet van een provincie

OZON0208 - (RTRG0021) Maximaal één activiteit van een waterschap mag verwijzen naar een bovenliggende activiteit niet van een waterschap

OZON0213 - (RTRG0013) Als een activiteit van een gemeente verwijst naar een bovenliggende activiteit ook van een gemeente dan moet dit dezelfde gemeente zijn

OZON0214 - (RTRG0014) Als een activiteit van een provincie verwijst naar een bovenliggende activiteit ook van een provincie dan moet dit dezelfde provincie zijn

OZON0215 - (RTRG0015) Als een activiteit van een waterschap verwijst naar een bovenliggende activiteit ook van een waterschap dan moet dit hetzelfde waterschap zijn

OZON1042 - Een intrekking van een Regeling moet ook bijbehorend regelingsgebied, regelteksten, divisies/divisieteksten, en ponsen beëindigen.

OZON5001 - (TPOD1890) De identificatie van ieder OwObject moet overeenkomen met het type OwObject.

OZON5002 - (TPOD2080) Een instructieregel moet ofwel een "InstructieregelInstrument", ofwel een "InstructieregelTaakuitoefening" hebben.

OZON5003 - (TPOD2090) Binnen een Omgevingsnorm of Omgevingswaarde moeten alle normwaarden van hetzelfde type zijn: kwalitatief, kwantitatief, of waardeInRegeltekst

OZON5004 - (TPOD2100) Als een Omgevingsnorm of Omgevingswaarde een Eenheid heeft, dan moeten alle normwaarden van het type kwantitatief zijn.

OZON5005 - (TPOD2110) Ieder Tekstdeel met een locatie moet een idealisatie hebben.

Gewijzigd:

OZON0347 - Een SymbolisatieItem moet naar een Activiteitlocatieaanduiding, Gebiedsaanwijzing of Normwaarde verwijzen die bestaat.

Verwijderd:

OZON0021: is komen te vervallen omdat de bijbehorende TPOD-regel niet meer geldt

OZON0105: volgt logisch uit andere validatieregel OZON4000, en kan daarom komen te vervallen

OZON0106: volgt logisch uit andere validatieregel OZON4000, en kan daarom komen te vervallen

OZON0205: volgt logisch uit andere validatieregels rondom verwezing en beeindiging, en kan daarom komen te vervallen

Er is een vraag binnen gekomen over het gebruik van objecten in de IMOW standaard. Het antwoord op deze vraag staat niet in IMOW standaard, maar in de NEN3610 standaard waarnaar wordt verwezen vanuit de IMOW standaard. Het probleem is echter dat er in de IMOW standaard niet staat welke versie van NEN3610 er gebruikt moet worden en in dit geval is dat nu juist van belang.

Normaal gesproken heeft een standaard een paragraaf normatieve referenties waarin precies geduid wordt op welke versie deze standaard gebouwd is. Dat hoofstuk ontbreekt en moet worden toegevoegd.

Wijzigen validatiematrix m.b.t. STOP/LVBB/BHKV validaties in de door KOOP aangeleverde Excelsheet.