Blauw gebouw

Meldingen

Op deze pagina vind je een overzicht van meldingen die zijn gedaan over de standaarden voor de Omgevingswet die Geonovum beheert.
Zelf een melding doorgeven 
Heb je een voorstel voor een oplossing, geef die dan ook door. Wij nemen je suggestie graag mee!

  • WELT-196
  • Status
    Wachten op Support

Schrappen regels over bestandsgrootte uit IMOW

Standaard
IMOW

In het IMOW staat nog een stuk over de bestandsgrootte staat. Daar is nu een los document voor gekomen en dit moet eruit gehaald worden.

  • WELT-195
  • Status
    Wachten op Support

Waardelijsten: waardelijst typenorm screenen op juiste niveau

Standaard
IMOW

Naar aanleiding van een vraag over de toepassing van Omgevingsnorm bij woningtypen, en dan met name het attribuut typenorm, in het omgevingsplan is geconstateerd dat ten minste een aantal van de waarden van de waardelijst Typenorm een niveau te diep zijn gekozen. Bij het gebruik van het objecttype Omgevingsnorm moet voor het attribuut type een waarde uit de waardelijst Typenorm gekozen worden. Het attribuut type is bedoeld als generalisatie zijn, een overkoepelende term voor meerdere omgevingsnormen van eenzelfde type. Na het kiezen van het juiste type norm moet nog de normwaarde ingevuld worden, en dat zijn de waarden die op verschillende locaties gelden. Wanneer je in een omgevingsplan in een regel een norm wilt stellen over het woningtype dat op allerlei verschillende plekken in de gemeente toegestaan is, zijn de enige relevante waarden uit de waardelijst Typenorm vrijstaand, aaneengebouwd, tweeaaneen en gestapeld. Dat zijn juist de normwaarden die op de verschillende locaties verschillend gelden als waarde voor de norm. Voor dit onderwerp zijn de waarden van de waardelijst Typenorm een niveau te diep hebben gekozen: in deze waardelijst hadden niet vrijstaand, aaneengebouwd, tweeaaneen en gestapeld moeten staan, maar woningtype. Geconstateerd is dat dit voor meer onderwerpen het geval is.

Voorstel oplossing
Onderzocht moet worden:
- welke rol type(Norm) en de bijbehorende waardelijst in STOP spelen
- wat OZON en de DSO-viewer met type(Norm) en de bijbehorende waardelijst doen
- wat de GIO-viewer (in bekendmaking en geconsoliderde regeling) met type(Norm) en de bijbehorende waardelijst doen
- welke waarden van de waardelijst vervangen moeten worden door een waarde van een hoger niveau
- of het op dit moment mogelijk is zo’n vrij fundamentele wijziging van de waardelijst te doen

Vervolgens moet dit onderwerp besproken worden in het leveranciersoverleg en moet een wijzigingsvoorstel aan de CAB worden voorgelegd.
In ieder gevalm moet de waarde woningtype toegevoegd worden aan de waardelijst Typenorm en de waarden vrijstaand, aaneengebouwd, tweeaaneen en gestapeld verwijderen.
  • WELT-194
  • Status
    Wachten op Support

Wijziging validatieregels voor ActiviteitLocatieaanduiding

Standaard
IMOW
TPOD AMvB en MR
TPOD Omgevingsplan
TPOD Omgevingsverordening
TPOD Waterschapsverordening
Validatieregels

Geconstateerd is dat wanneer je een omgevingsdocument dat is geannoteerd met Activiteit en ActiviteitLocatieaanduiding in verschillende viewers bekeek, die verschillende viewers bij de selectie van dezelfde Activiteit niet exact dezelfde Locaties als resultaat weergaven. Het OW-objecttype ActiviteitLocatieaanduiding is een speciaal objecttype dat van een Juridische regel die is geannoteerd met Activiteit vertelt waar die regel geldt (locatieaanduiding) en wat voor soort regel het is (activiteitregelkwalificatie, zoals verbod en vergunningplicht).

Het probleem bleek veroorzaakt te worden doordat de definitie van het objecttype ActiviteitLocatieaanduiding verschillend werd geïnterpreteerd. De verschillen tussen de viewers zijn inmiddels opgelost, maar het mogelijke verschil in interpretatie kan in de toekomst nog steeds tot problemen leiden bij een wijziging van een ActiviteitLocatieaanduiding.

In de praktijk komt het nu namelijk voor dat er in een omgevingsdocument meerdere Juridische regels zijn die met dezelfde Activiteit zijn geannoteerd met precies dezelfde combinatie van locatieaanduiding en activiteitregelkwalificatie. In een aantal gevallen werd dan in de uitwisseling de ActiviteitLocatieaanduiding hergebruikt door bij al die Juridische regels een verwijzing naar dezelfde (identificatie van) ActiviteitLocatieaanduiding op te nemen. Zolang je deze objecten niet muteert gaat dit goed. Als je echter voor één (of een deel) van de Juridische regels met de gedeelde ActiviteitLocatieaanduiding de locatie wilt wijzigen, wijzig je door het hergebruik van die ActiviteitLocatieaanduiding ook de locatie van de andere Juridische regels. Om dit probleem te voorkomen willen we het, door het toevoegen van de voorgestelde validatieregels, onmogelijk maken dat een ActiviteitLocatieaanduiding wordt hergebruikt. Door het toepassen van deze validatieregels voldoet de data aan de semantiek zoals beschreven in het UML-model waarin het objecttype ActiviteitLocatieaanduiding een associatieklasse is.

Voorstel oplossing
• Toevoegen van de volgende validatieregels aan de validatiematrix:
- Een ActiviteitLocatieaanduiding hoort bij precies één combinatie van een Activiteit en Juridische regel.
- Bij één combinatie van een Activiteit en Juridische regel hoort precies één ActiviteitLocatieaanduiding.
• Verwijderen van de volgende validatieregel uit de validatiematrix:
- OZON0348: Een regel voor iedereen mag niet twee keer verwijzen naar de zelfde ActiviteitLocatieaanduiding.
• Aanvullen van het IMOW-document met een expliciete beschrijving van de juiste interpretatie van het objecttype ActiviteitLocatieaanduiding.
  • WELT-193
  • Status
    Wachten op Support

GerelateerdeRegeltekst in het IMOW

Standaard
IMOW

Onlangs zag ik in de schema’s van IMOW v2.0.0 gerelateerdeRegeltekst nog staan.
(Nu hadden we aangekondigd dat we deze zouden laten vervallen, daarnaast staat deze ook niet meer opgenomen in de documentatie.)

Zouden jullie deze in een willekeurige volgende versie uit de IMOW-schema’s kunnen halen?
(We hebben bij het Kadaster o.b.v. de documentatie deze wel weggehaald, maar hij staat nog wel in de IMOW-schema’s.)

Voorstel oplossing
gerelateerdeRegeltekst uit IMOW-schema's halen
  • WELT-192
  • Status
    Wachten op Support

CIMOW: Toevoegen geometrie-identificatie aan objecttypen Gebied, Lijn en Punt

In het IMOW-document zijn regels gesteld over het muteren van IMOW-objecten. Een van die regels is dat een object alleen wordt aangeleverd als het gewijzigd is t.o.v. de gegevens die bekend zijn bij het Stelsel. Softwareleveranciers meldden dat het aanleveren van een gewijzigd IMOW-Geometrie-object soms leidt tot een onverwachte foutmelding. Dat is het geval als een mutatie van een IMOW-Geometrie-object wordt aangeleverd met een nieuw id maar exact dezelfde coördinaten. Dat dit leidt tot een foutmelding komt doordat OZON de IMOW-objecten eerst converteert naar CIMOW-objecten en daarna valideert op de genoemde regel. Doordat in CIMOW de objecttypen Gebied, Lijn en Punt geen id-attribuut hebben bij de geometrie vergelijkt OZON alleen de coördinaten en niet de id. OZON constateert dan dat het object niet gewijzigd is en keurt de aanlevering af.

In het algemeen is het niet wenselijk om dezelfde geometrie aan te leveren met een andere geometrie-identificatie, maar er zijn gevallen waarin dit om juridische of procedurele redenen wel terecht is. Door in CIMOW aan de objecttypen Gebied, Lijn en Punt het attribuut id van het IMOW-objecttype Geometrie toe te voegen, zal iedere wijziging in een IMOW-Geometrie-object door OZON herkend worden en wordt een wijziging alleen afgewezen als de geometrie én de identificatie ongewijzigd zijn.

In de praktijk wordt door deze wijziging de betreffende (validatie)regel soepeler toegepast. Dit maakt het mogelijk om bij het bevoegd gezag geen boekhouding bij te houden van eerder aangeboden Geometrie-objecten en ze in plaats daarvan telkens met een nieuw id als nieuw object aan te bieden. Dit kan tot een ongewenste belasting van de OZON-servers leiden. Daarom zal tevens in de documentatie duidelijk beschrijven dat het uitgangspunt is dat er alleen een nieuwe id wordt gebruikt als er daadwerkelijk sprake is van een nieuwe geometrie en dat het aanleveren van een wijziging van een Geometrie-object die alleen bestaat uit een wijziging van de id slechts voor uitzonderingsgevallen is bedoeld.

Voorstel oplossing
Semantisch afstemmen van CIMOW op IMOW zodat iedere wijziging in een IMOW-Geometrie-object door OZON wordt herkend, door in CIMOW aan de objecttypen Gebied, Lijn en Punt het attribuut id van het IMOW-objecttype Geometrie toe te voegen.
  • WELT-191
  • Status
    IN BEHANDELING
  • Wordt verwerkt in volgende release van IMOW, alle TPOD's en de validatieregels

IMOW, CIMOW en TPOD’s: Toevoegen MultiCurve en MultiPoint als toegestane geometrieën voor Lijn en Punt

Standaard
CIMOW
IMOW
TPOD-Artikelstructuur
TPOD-Vrijetekststructuur

In IMOW, CIMOW en de TPOD's worden, voor zover hier relevant, drie verschijningsvormen van Locatie onderscheiden: Gebied, Lijn en Punt.

De Geometrie van een Gebied mag een Surface of MultiSurface zijn. MultiSurface wordt gebruikt als een Gebied logisch gezien bij elkaar hoort maar toch uit losse vlakken bestaat. In de huidige versie van de TPOD-standaard zijn de multi-varianten van Lijn en Punt niet toegestaan. Vanuit de oorspronkelijke terughoudendheid ten aanzien van lijnen en punten is dat verklaarbaar. Voortschrijdend inzicht leert echter dat ook bij Lijn en Punt de multi-varianten wenselijk zijn. Voorbeelden daarvan zijn een rooilijn die de situering van een bebouwingswand langs een straat aangeeft die wordt doorsneden door zijstraten en de collectie van punten die het werkingsgebied vormen van een geluidproductieplafond-omgevingswaarde rondom een bedrijventerrein.

Gebleken is dat er in gepubliceerde omgevingsdocumenten al gebruik is gemaakt van de multi-varianten van Lijn en Punt. De huidige validatieregels keuren dat ten onrechte niet af.

Voorgesteld wordt nu om de multi-varianten van Lijn en Punt toe te staan.

Oplossingsrichting:

Toestaan dat ook de geometrievormen MultiCurve en MultiPoint worden gebruikt, door:

  1. In IMOW de constraint bij Locatie::Lijn te vervangen door: self.geometrie.geometrie.oclIsKindOf(GM_Curve) or self.geometrie.geometrie.oclIsKindOf(GM_MultiCurve) [is in huidige versie self.geometrie.geometrie.oclIsKindOf(GM_Curve)]
  2. In IMOW de constraint bij Locatie::Punt te vervangen door: self.geometrie.geometrie.oclIsKindOf(GM_Point) or self.geometrie.geometrie.oclIsKindOf(GM_MultiPoint) [is in huidige versie self.geometrie.geometrie.oclIsKindOf(GM_Point)]
  3. CIMOW op vergelijkbare wijze aan te passen.
  4. Deze constraints toe te voegen aan de beschrijvingen van de verschijningsvormen van Locatie in alle TPOD's.

Aanvullend wordt voorgesteld om de validatieregels in de validatiematrix zo aan te scherpen dat hierop correct wordt gecontroleerd:

  • Validatieregel TPOD1960 wijzigen in: Iedere verwijzing naar een gmlObject vanuit een Lijn moet verwijzen naar een object van type GM_LineString of GM_MultiLinestring
  • Validatieregel TPOD1970 wijzigen in: Iedere verwijzing naar een gmlObject vanuit een Punt moet verwijzen naar een object van type GM_Point of GM_MultiPoint
  • Validatieregel TPOD1980 wijzigen in: Iedere verwijzing naar een gmlObject vanuit een Gebied moet verwijzen naar een object van type GM_Surface of GM_MultiSurface
CAB datum
  • WELT-187
  • Status
    IN BEHANDELING

Ontwerp regelingen

Standaard
STOP
TPOD-Artikelstructuur
TPOD-Vrijetekststructuur

Ontwerp regelingen worden aangeleverd en vastgelegd door Ozon, maar ontwerp regelingen hebben geen historie.

Consequentie:

  • Naarmate de tijd vordert, zijn er steeds meer ontwerp objecten in de ozon database. Dit groeit alleen maar.
    Dat geldt ook voor de ontwerp_locaties met bijbehorende geometrieën.
  • Het geometrisch bevragen van ontwerp documenten wordt dan door de steeds groeiende geometrieën steeds moeizamer, aangezien er op geen enkele manier onderscheid gemaakt kan worden tussen
    geometrieën die wel/niet relevant zijn voor bevragingen.
  • Na verloop van tijd gaat dit performance problemen opleveren.

Is het mogelijk om als onderdeel van de standaard op te nemen, dat ontwerpen:

  • Na een bepaalde tijd functioneel beëindigd moeten worden, zodat er bij bevragingen van een filtering gebruik gemaakt kan worden, om hierdoor een betere performance te kunnen krijgen
  • Er een manier is om bevoegd gezagen te informeren over ontwerp regelingen die een bepaalde ‘houdbaarheids’ datum overschreden hebben, zodat bevoegd gezag zelf aan kan geven dat het desbetreffende ontwerp niet meer van toepassing is.

In het kader van Consultatie termijnen overleg met bevoegd gezagen geweest is. En dat er diverse opties over wel/niet beëindigen van een ontwerp benoemd zijn, maar niet echt een besluit genomen is.

Voorstel oplossing
Wordt een wijziging in STOP en beschreven in de TPOD's
  • WELT-184
  • Status
    Wachten op Support

IMOW: verzoek om verduidelijking beschrijving Integrale tekstvervanging

Standaard
IMOW

Bijgevoegd het reviewcommentaar op de definitieve versie van de A’’’-release van het TPOD-deel van de STOP/TPOD-standaard vanuit Ozon.

In IMOW v2.0.1.pdf, pagina 48, staat het volgende:
Er is een aangepaste variant van intrekken en vervangen ontwikkeld, deze heet integrale tekstvervanging. In deze variant wordt een Vervang gedaan van het Lichaam van de Regeling. Dit scenario werkt zoals een reguliere mutatie werkt aangezien er geen nieuw (Work)ID van de Regeling hoeft te worden gemaakt. Kortom, bij een integrale tekstvervanging:
• Hoeven bestaande Regeltekst-objecten niet opgestuurd te worden.
• Hoeft het Regelingsgebied niet opgestuurd te worden.

Wij zouden hier graag een verduidelijking zien. Het klopt wat hier staat - onder de aanname dat alle verwijzingen vanuit Regelteksten naar (het workId van) Artikelen na Integrale Tekstvervanging behouden blijven. Het klopt dus dat bestaande Regeltekst-objecten niet opgestuurd hoeven te worden, maar er moet wel degelijk rekening gehouden worden met bestaande Regeltekst-objecten. De manier waarop dit nu opgeschreven is laat ruimte voor andere interpretaties.

  • WELT-183
  • Status
    GESLOTEN
  • De validatiematrix v1.4 is op 7-1-2022 gepubliceerd

Validatiematrix versie 1.4

Standaard
Validatieregels

Ieder PI wordt een nieuwe, actuele versie van de Validatiematrix voor de keten Van plan tot publicatie gepubliceerd. In de Validatiematrix zijn alle validatieregels vanuit de STOP/TPOD-standaard en van BHKV, LVBB en OZON bij elkaar gebracht. Per validatieregel is een beschrijving opgenomen en is aangegeven wat de ernst is, of deze is geïmplementeerd en wat de meldingstekst is c.q. of er nog een meldingstekst moet komen. Gecoördineerd door Geonovum is de 1.4-versie tot stand gekomen met input van KOOP, RWS, Kadaster en Geonovum. Dit keer is extra kritisch gekeken naar de actualiteit van de validatieregels en naar de samenhang. In het verleden bedachte validatieregels die nooit geïmplementeerd zijn en overbodig zijn gebleken zijn geschrapt. Validatieregels vanuit verschillende componenten die hetzelfde valideerden zijn samengevoegd.

Voorstel oplossing
Publiceren van versie 1.4 van de Validatiematrix
  • WELT-182
  • Status
    GESLOTEN
  • De CAB heeft op 25-11-2021 ingestemd met het voorstel

TPOD omgevingsplan en IMOW: Definitieve uitwerking van de Pons vastleggen

Standaard
IMOW
TPOD Omgevingsplan

In TPOD omgevingsplan en IMOW is niet eenduidig beschreven of het Pons-GIO bij het Besluit of de Regeling hoort. Ook is niet duidelijk of er 1 Pons is of dat er meer zijn en in welke gevallen en hoe Pons moet worden toegepast.

Voorstel oplossing
In IMOW (voor zover relevant) en in TPOD omgevingsplan beschrijven dat:

* het Pons-GIO bij het Besluit hoort;
* er in het Besluit naar het Pons-GIO verwezen moet worden;
* er 1 Pons-GIO en 1 OW-Pons is, dat met opvolgende wijzigingsbesluiten gewijzigd wordt;
* in welke gevallen Pons moet worden toegepast.
CAB datum