Blauw gebouw

Meldingen geo-standaarden

Op deze pagina vind je een overzicht van meldingen die zijn gedaan over standaarden die Geonovum beheert. Door in het zoekveld een standaard te selecteren, kan je de status van meldingen bekijken. Heb je zelf een melding gedaan, dan kan je ook zoeken op het ID-nummer van jouw melding.

  • WELT-265
  • Status
    OPGELOST
  • Opgelost in v3.1.

Wijzigingsverzoek SpoordeelGPP.maaiveld (spoordeelhoogte)

Aanleiding wijziging
Het blijkt dat het attribuut SpoordeelGPP.maaiveld (voorheen SpoordeelGPP.spoordeelhoogte) niet nodig is.
Bij WegdeelGPP is hetzelfde attribuut verwijderd uit het model.

Voorgestelde wijziging
Het verzoek om het attribuut SpoordeelGPP.maaiveld te schrappen uit het IMG. Prorail is hiermee akkoord.

Impactanalyse
Geef hier een indicatie van de impact van de wijziging:
-Wie gaat er wat van merken? Data providers, softwareleveranciers
-Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
-Is er een herlevering nodig naar de CVGG? Nee
-Heeft het impact op het xml-schema? Ja
-Is het backward compatible in de zin van validatie op het schema? Ja, want dit attribuut is niet gebruikt.
-Heeft het impact op de regels in IMG? Ja. 1 regel minder
-Heeft het impact op de validatieregels voor de CVGG? waarschijnlijk niet
-Heeft het impact op de omgevingsregeling? Nee
-Is het een X, Y, of Z wijziging? Y

Toelichting
Bij overgang naar IMG v3.0 is het attribuut SpoordeelGPP.spoordeelhoogte vervangen door SpoordeelGPP.maaiveld.
Zie ook Github issue 183

  • WELT-264
  • Status
    IN BEHANDELING

HTTPS ondersteuning verplicht ook door STRI

Met de inwerkingtreding van de Wet digitale overheid per 1 juli 2023 worden overheden o.a. verplicht hun publiek toegankelijke websites en webapplicaties te beveiligen met de open standaarden HTTPS en HSTS.

 Het “Besluit beveiligde verbinding met overheidswebsites en ‑webapplicaties” verplicht overheidsorganisaties om hun publiek toegankelijke websites te beveiligen met de open standaarden HTTPS. In aanvulling op HTTPS moeten overheidsorganisaties ook de HSTS-standaard gebruiken. Dat zorgt ervoor dat browsers na een eerste websitebezoek direct via HTTPS verbinden met de website. Daarnaast moet de HTTPS-configuratie voldoen aan de TLS-richtlijnen en Webapplicatie-richtlijnen van het Nationaal Cyber Security Centrum (NCSC). Deze wet heeft gevolgen voor de RO Standaarden en specifiek voor het STRI2012.

In het STRI2012 staat in hoofdstuk 5.1 ‘Eisen aan de beschikbaarstelling’ en in hoofdstuk 7 ‘Toegankelijkheid en raadpleegbaarheid’ het volgende: “Het gebruik van een beveiligde HTTPS verbinding via TLS of SSL is optioneel.” Hierin ligt sinds 1 juli 2023 een probleem omdat sinds 1 juli het gebruik van HTTPS niet meer optioneel is.

Voorstel oplossing
Omdat we, als gevolg van de WCAG verplichting, de RO standaarden gaan omzetten in HTML en de werkafspraken die niet gerelateerd zijn aan TAM gaan integreren in de tekst lijkt het me verstandig om de tekst van de STRI2012 op het gebruik van HTTPS aan te passen in:
“Het gebruik van een beveiligde HTTPS verbinding via TLS of SSL is verplicht”.

Daar waar in de STRI nog wordt gesproken over het gebruik van het HTTP protocol dient de tekst aangepast of verwijdert te worden.
Gecontroleerd moet worden of dergelijke verwijzingen ook in andere documenten voorkomen zoals werkafspraken, praktijkrichtlijnen enz.
  • WELT-263
  • Status
    OPGELOST

wijzigingsverzoek TPOD voorbereidingsbesluit

Hierbij dient Roxit een verzoek in om te verwijderen uit de TPOD Voorbereidingsbesluit:

  • de beschreven werkwijze voor het door de gemeente laten beëindigen of wijzigen van voorbeschermingsregels in een tijdelijk regelingdeel die door het Rijk of de Provincie zijn ingesteld middels een voorbereidingsbesluit.

Deze werkwijzes zijn beschreven in:
https://docs.geostandaarden.nl/tpod/def-st-TPOD-VB-20230407/#10D8BC72
https://docs.geostandaarden.nl/tpod/def-st-TPOD-VB-20230407/#44610DA2

In het kort komt mijn bezwaar er op neer dat hier middels een omweg eenzelfde complexiteit geïntroduceerd wordt, als die van het meervoudig bronhouderschap. De reden dat het tijdelijk regeling deel überhaupt bestaat.

Ik ben me er van bewust dat in de TPOD nu ook zinnen staan die het mogelijk maken om dit voorlopig niet te ondersteunen, zodat wij als plansoftware-leverancier deze mogelijkheid voorlopig zouden kunnen negeren. Om 2 redenen pleit ik toch voor op zo kort mogelijke termijn verwijderen:

  1. als het in de TPOD staat, verwachten klanten dat het kan. Als dat niet nu is, dan hoort men graag wanneer wel
  2. De werkwijze zoals nu beschreven is volgens mij niet goed en moet anders. Hoe eerder deze route wordt afgesneden, hoe minder kans er is dat mensen werk gaan doen om de huidige route toch te ondersteunen.

Toelichting
De werking
Als een andere bestuurslaag door middel van een tijdelijk regelingdeel wijzigingen aanbrengt op het Omgevingsplan, dan zijn die regels juridisch vervolgens van de gemeente en wel omdat ze het Omgevingsplan wijzigen. (Dit geldt overigens niet voor het Projectbesluit: hiervoor is bij wet vastgelegd dat de gemeente daar 3 jaar niet aan mag komen).

De gemeente zou dan zelf het tijdelijk regelingdeel moeten downloaden en intrekken en/of aanpassen indien gewenst.

In de afgelopen dagen is mij pas duidelijk geworden hoe deze functionaliteit zou moeten werken. Juridisch werkt dit volledig anders dan ik vanuit techniek zou verwachten. En bovendien (technisch) inconsistent, want afwijkend gedrag tussen voorbereidingsbesluit en projectbesluit.

Mijn bezwaren
De beschreven werkwijze gaat volledig in tegen mijn verwachtingen. Ik zie de volgende probleempunten, zonder er heel diep in te duiken.

  1. De werkwijze gaat in tegen het principe: hij die plaatst, kan ook wijzigen en verwijderen (en anderen dus niet). Dat is een heilig principe dat overbleef na de discussies over meervoudig bronhouderschap
  2. Identificaties. Alle identificaties die gebruikt worden zijn gebaseerd op de CBS code van degene die het voorbereidingsbesluit neemt, niet de ontvanger van het tijdelijk regelingdeel. Als de ontvanger de eigenaar wordt is dat raar/fout?
  3. De eindverantwoordelijke voor het tijdelijk regelingdeel is degene die het instelt, niet de ontvanger. Als de ontvanger de eigenaar wordt is dat raar/fout?
  4. De werkwijze is inconsistent met de werkwijze rond de bruidsschat. Die is ingesteld door het ministerie (<maker>/tooi/id/ministerie/mnre1034</maker>) , maar de eindverantwoordelijke is de ontvangende gemeente (<eindverantwoordelijke>/tooi/id/gemeente/gm0828</eindverantwoordelijke>). Ook alle identificaties zijn op basis van CBScode ontvangende gemeente.
  5. De veronderstelde functionaliteit en van downloaden, importeren en op basis daarvan een wijziging/intrekking vervaardigen is nog lang niet "foolproof". Zeker omdat voor intrekken de exacte vorm van ooit geleverde objecten nodig is, biedt dit voorlopig nog wel flinke uitdagingen als software van de maker van het tijdelijk regelingdeel en de gemeente van elkaar verschillen .
Voorstel oplossing
Verwerkt in TPOD voorbereidingsbesluit, TPOD reactieve interventie en TPOD projectbesluit: tijdelijk regelingdeel wordt in alle gevallen ingetrokken door bevoegd gezag dat het tijdelijk regelingdeel heeft ingesteld
  • WELT-262
  • Status
    OPGELOST
  • Validatiematrix v4.0 gepubliceerd op 29-09-2023

Bij KOOP gewijzigde validatieregels aanpassen in validatiematrix

Verzoek van KOOP om de validatiematrix aan te passen.

Verwijderen: LVBB4602 LVBB4603

Nieuw: LVBB1042 LVBB4740 LVBB4763

Gewijzigd: LVBB1041 LVBB1555 LVBB1556 LVBB1557 LVBB4711 LVBB4762 LVBB5013

Voorstel oplossing
Validatiematrix aanpassen met gewijzigde validatieregels KOOP
  • WELT-260
  • Status
    Geannuleerd
  • Deze wijziging is eerder door de expertgroep beperkt tot het opnemen in de definitie.
    zie #31 (comment) en #31 (comment).

    Daarna is het opnieuw aangekaart door Geodan, maar vervolgens is door de advies geadviseerd het te laten bij een beschrijving van de eenheid in de definitie. zie Wijzigingsverzoek eenheden toevoegen (SDIMEV-35 en 81) · Issue #31 · Geonovum/imev-werkomgeving

Eenheden in IMEV toevoegen als attribuut

Aanleiding wijziging
Het alleen melden van de eenheden in de definitie is foutgevoelig. Softwareleveranciers kunnen het hierdoor niet automatisch opnemen in hun software.

Voorgestelde wijziging
Opnemen van eenheden als apart attribuut heroverwegen.

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

Toelichting
Deze wijziging is eerder door de expertgroep beperkt tot het opnemen in de definitie.
zie #31 (comment) en #31 (comment).

Daarna is het opnieuw aangekaart door Geodan, maar vervolgens is door de advies geadviseerd het te laten bij een beschrijving van de eenheid in de definitie. zie https://github.com/Geonovum/imev-werkomgeving/issues/31#issuecomment-1551580597

  • WELT-259
  • Status
    OPGELOST
  • Opgelost in v3.0.

Zorgen dat een Monitoringresultaat altijd bij Geluidproductieplafond of Basisgeluidemissie hoort

Aanleiding wijziging

Monitoringresultaat objecten moeten altijd naar 1 Geluidproductieplafond of naar 1 Basisgeluidemissie object verwijzen. Dit staat momenteel niet duidelijk in de standaard.

Voorgestelde wijziging

De standaard zodanig aanpassen dat een Monitoringresultaat altijd de juiste verwijzing heeft door een nieuwe subklasse GemonitordObject toe te voegen voor Geluidproductieplafondobject of Basisgeluidemissieobject.

Het UML ziet er dan als volgt uit:
https://user-images.githubusercontent.com/2814052/231695841-5886df6d-8ee3-4af1-9b90-758fa56e0e64.png.

Impactanalyse
  • Inhoudelijk verandert de standaard niet: dezelfde gegevens moeten worden aangeleverd.
  • In de uitwisseling zullen de twee optionele verwijzingen die nu in Monitoringresultaat zitten (te weten: geluidproductieplafondobject en basisgeluidemissieobject) anders gaan heten (namelijk: gemonitordObject). Hiervoor moet de lees- en schrijffunctionaliteit voor het object Monitoringresultaat in software aangepast worden. Daarom is het een X-wijziging.
  • WELT-258
  • Status
    OPGELOST
  • Opgelost in v3.0.

Aanpassen regels n.a.v. kwaliteitstoets

Aanleiding wijziging

In het informatiemodel IMG versie 2.1.0 staan 57 regels opgeschreven.
Het is gewenst dat deze regels allemaal logisch, leesbaar en eenduidig zijn. Het blijkt echter dat deze regels dat nog lang niet allemaal zijn. Zeker wanneer de richtlijn van Rulespeak hierover gevolgd wordt.
De regels zijn geïnventariseerd. Waar ze eenduidig waren maar nog niet conform Rulespeak, zijn verbeterde regels voorgesteld.
Waar ze niet eenduidig waren is aan RIVM gevraagd de regels zodanig aan te passen dat ze wel eenduidig zijn.
Sommige regels bleken geen regel, overbodig of eerder een toelichting te zijn.

Voorgestelde wijziging

Alle regels waar nodig aanpassen zodanig dat ze logisch, leesbaar en eenduidig worden.

Impactanalyse

-Wie gaat er wat van merken? Gebruikers van het model krijgen regels aangeboden die logischer, leesbaarder en eenduidiger zijn. Aangenomen wordt dat de software die de regels nu toepast voor het inlezen van de data niet aangepast hoeft te worden, tenzij deze software de verkeerde betekenis heeft geïnterpreteerd bij niet eenduidige regels, maar daar wordt nog niet van uitgegaan.
-Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
-Is er een herlevering nodig naar de CVGG? Nee
-Heeft het impact op het xml-schema? Nee
-Is het backward compatible in de zin van validatie op het schema? Ja
-Heeft het impact op de regels in IMG? Ja
-Heeft het impact op de omgevingsregeling? Nee
-Is het een X, Y, of Z wijziging? Z, maar wel veel werk

  • WELT-257
  • Status
    OPGELOST
  • Opgelost in v3.0.

Verwijzing naar Terrein in een aanlevering van een Monitoringresultaat

Aanleiding wijziging
Bij het aanleveren van een Monitorresultaat van een geluidbron industrieterrein moet in de huidige standaard een object van het type Industrieterrein worden meegeleverd. Dit was niet de bedoeling. Het was de bedoeling dat in de aanlevering van het Monitorrresultaat een xlink zou zitten naar het Industrieterrein zoals aangeleverd in de vaststelling. Dit wijzigingsverzoek beschrijft een wijzing die het Terrein in plaats van het Industrieterrein zelf een link ernaar kan worden opgenomen,

Voorgestelde wijziging
In plaats van dat een Geluidgegevenscollectie het terrein opneemt als GeluidgegevenscollectieElement krijgt de klasse Geluidgegevenscollectie een optionele relatie naar een Terrein. In alle geval dat een collectie over een terrein gaat moet deze relatie gebruikt worden. Als het gaat om een Monitoringresultaat over een Terrein dan moet een link naar het eerder aangelverde terrein worden opgenomen. In andere gevallen het terrein zelf.

https://user-images.githubusercontent.com/2814052/230328798-99b164b6-13b0-474f-b4f3-ea8f9accb560.png

Impactanalyse
Deze wijziging heeft impact op iedereen die iets met Terreinen doet omdat de plaats van Terrein in het model verandert.
Ook het XML-schema verandert dus data providers en softwareleveranciers zullen hun software moeten aanpassen.
De verandering leidt niet tot nieuw in te winnen gegevens.
De wijziging heeft vooral impact op de aanlevering van monitoringresultaten die met het huidige schema nog niet mogelijk zit. Er hoeft dus iet opnieuw aangeleverd te worden.
Als je een monitoringresultaat gaat indienen zullen die er anders uitzien dus is het een x-wijziging.

  • WELT-256
  • Status
    OPGELOST
  • Opgelost in v3.0.

Relatie tussen Geluidproductieplafondobject en Terrein verplaatsen naar subtypen voor industrie

Aanleiding wijziging
De relatie tussen Geluidproductieplafondobject en Terrein is alleen nodig voor industrieterreinen. Door de relatie te verplaatsen naar de subtypes Industrieterrein en GeluidproductieplafondobjectIndustrie wordt dit duidelijker en is hiervoor ook geen extra regel nodig die er overigens nog niet was.

Voorgestelde wijziging
Relatie tussen Geluidproductieplafondobject en Terrein verplaatsen naar subtypen voor industrie.
Het wordt een verplichte relatie van GeluidproductieplafondobjectIndustrie naar Industrieterrein:

https://user-images.githubusercontent.com/80040145/220091971-7b1879fe-46b1-49d8-9473-50c94cc82318.png

Impactanalyse

Wie gaat er wat van merken? Softwareleveranciers die het xml-schema gebruiken
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? Ja
Is het backward compatible in de zin van validatie op het schema? Ja
Is er een herlevering nodig naar de CVGG? Als de CVGG in productie was zou een herlevering nodig zijn wanneer er relaties zouden bestaan van subtypen die geen industrie subtype zijn, maar dat zou eigenlijk al niet de bedoeling zijn.
Heeft het impact op de regels in IMG? Nee
Heeft het impact op de omgevingsregeling? Nee
Is het een X, Y, of Z wijziging? vermoedelijk Y

  • WELT-255
  • Status
    OPGELOST
  • Opgelost in v3.0.

Regel toevoegen bij Geluidgegevenscollectie.jaar

Aanleiding wijziging
In IMGeluid is momenteel geen regel opgenomen dat aanleveringen van het type 'monitoringresultaat' of ' brongegevens monitoring' betrekking moeten hebben op jaren die in het verleden liggen. Het is nu mogelijk om een jaar in toekomst op te geven. Dat is niet wenselijk en kan leiden tot het niet goed verwerken van de gegevens in de CVGG.

Voorgestelde wijziging
Toevoegen van volgende regel bij Geluidgegevenscollectie.jaar

Geluidgegevenscollectie.jaar moet in het verleden liggen als Geluidgegevenscollectie.type = "monitoringresultaat" of "brongegevens monitoring".

Impactanalyse
-Wie gaat er wat van merken? Data providers, validatiesoftware-bouwer
-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
-Is het backward compatible in de zin van validatie op het schema? Ja
-Heeft het impact op de regels in IMG? Ja
-Heeft het impact op de omgevingsregeling? Nee
-X,Y, Z-wijziging: Z

Voorstel oplossing
Hij is in versie 3.0 toegevoegd.

Geen updates meer missen?

Automatisch op de hoogte blijven? Meld je aan voor één van onze nieuwsbrieven.