In het IMOW wordt veel gesproken over het OWobject, maar het een definitie van het object en de eigenschappen van dat object zijn niet te vinden.

Voorstel: opnemen uitleg over OWObject toevoegen aan IMOW.

Graag onderstaande nieuwe validatieregels indienen om opgenomen te worden in de Validatiematrix.

De volgende validaties zijn toegevoegd, en van toepassing op leveringen met meerdere regelingen. De validaties volgen uit het principe dat van ieder OwObject herleidbaar moet zijn bij welke combinatie van regeling en doel deze hoort (audittrail).

OZON4006 Een levering mag niet meerdere regelingen bevatten met het zelfde regelingId en doel.

OZON4007 Bij een levering met meerdere regelingen, mag ieder owBestand maar in één regeling gebruikt worden.
OZON4008 Bij een levering met meerdere regelingen, mag ieder owObject maar in één regeling gebruikt worden.
OZON4009 Bij een levering met meerdere regelingen, mag iedere geo maar in één regeling gebruikt worden.
OZON4010 Intrekken-vervangen (scenario 0) wordt niet ondersteund in combinatie met meerdere regelingen.

Ter info: deze validatieregels zijn reeds geïmplementeerd.

Daarnaast wil ik de volgende nieuwe validatieregel indienen. Uit CIMOW volgt dat er verschillende, afzonderlijke objecttypes zijn die de abstracte gegeneraliseerde klasse ‘Gebiedsaanwijzing’ hebben; bijvoorbeeld ‘Functie’, of ‘Bouw’. Uit CIMOW volgt dus ook, dat een Gebiedsaanwijzing niet door middel van mutatie van het ene naar het andere type kan veranderen; het zijn tenslotte afzonderlijke objecttypes. Omdat dit in IMOW theoretisch gezien wel mogelijk is stel ik de volgende nieuwe validatieregel voor:

OZON0201 Een gebiedsaanwijzing mag niet wijzigen van type.

Ter info: deze validatieregel is nog niet geïmplementeerd.

In TPOD AMvB en MR is het gebruik van de Gebiedsaanwijzing van het type Beperkingengebied uitgesloten. Er is sprake van gewijzigd inzicht. Men wil het Beperkingengebied wel kunnen toepassen.

Voorstel:

• Wijziging van TPOD AMvB en MR: het toevoegen van het type Beperkingengebied aan de toegelaten typen Gebiedsaanwijzing

• Bijbehorende wijziging van de validatiematrix (validatieregel om beperkingengebied wel toe te laten bij AMvB MR)

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.

In de schema’s van IMOW v2.0.0 staat nog gerelateerdeRegeltekst.
Er is aangekondigd dat deze zouden vervallen, daarnaast staat deze ook niet meer opgenomen in de documentatie.

De vraag is of deze in een willekeurige volgende versie uit de IMOW-schema’s gehaald kunnen worden.
Bij het het Kadaster is 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.