Meldingen

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.

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.

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.

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

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.

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

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.

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.

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.

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.