Meldingen

In de TPOD’s voor omgevingsdocumenten met artikelstructuur staan voorschriften over het gebruik van het tekstelement Titel. Deze komen er op neer dat als na onderverdeling t/m het niveau van Subsubparagraaf behoefte is aan nog verder gaande onderverdeling, gebruik gemaakt kan worden van het tekstelement Titel en dat Titel alleen het onderliggende tekstelement Afdeling mag bevatten. Deze voorschriften leiden er toe dat Titel alleen kan worden gebruikt als in iedere Titel in een Hoofdstuk alle onderliggende tekstelementen (Afdeling t/m Subsubparagraaf) voorkomen. Gebleken is dat dat het gebruiken van Titel nagenoeg onmogelijk maakt.

Aanvankelijk was de verwachting dat er geen behoefte zou zijn aan specifieke symbolisatiemogelijkheden voor regels over het situeren van bouwwerken. In de praktijk is gebleken dat die behoefte wel bestaat. IMOW, TPOD omgevingsplan en Waardelijsten IMOW bieden daar nu geen mogelijkheden voor.

Bij de ketenwerksessie Ontwerpen is er e.e.a. afgesproken waar Ozon zich op baseert, en DSO en de DSO viewer ook. Deze afspraken kan ik niet terugvinden in de IMOW documentatie. Deze zouden we graag wel terugzien in de IMOW documentatie en in voorbeelden/uitleg aan software leveranciers.

Zouden jullie dit op willen pakken?

Het gaat om afspraken over identificatie, waarbij de meest essentiële is: als een annotatie/OW-informatie bij een ontwerp en bij een werkende regeling dezelfde identificatie heeft, dan gaat het functioneel om hetzelfde ding.

Anders kunnen we in de data en dus t.b.v. de DSO Viewer:

• niet ontdekken vanuit de data welk ontwerp-object hoort bij welk vastgesteld object
• niet ontdekken vanuit de data welk vastgesteld OD hoort bij welke ontwerp OD, op document niveau. Dit gegeven krijgen we niet expliciet aangeleverd via de STOP standaard. Het is wel af te leiden, mits we ons kunnen baseren op de cursieve tekst.

Locatie heeft 3 (hoofd)verschijningsvormen: Vlak, Lijn en Punt. Voor alle waarden van de waardlijsten voor attributen die zorgen voor weergave op de kaart zijn symboolcodes ontwikkeld. Voor iedere waarde zijn er symboolcodes voor Vlak, Lijn en Punt. De symboolcodes en de bijbehorende weergave staan in de symbolenbibliotheek. In de Waardelijsten IMOW (zowel de versie in de Stelselcatalogus die onderdeel is van de standaard als de serviceversie die in diverse bestandsformaten wordt aangeboden) staan alleen de symboolcodes voor Vlak. Daardoor beschikken Stelselcatalogus en daarmee Ozon en de DSO-viewer alleen over de symbolisatie voor vlakken en krijgt de DSO-viewer een vlaksymbool om een lijn of punt weer te geven. Geconstateerd is dat daardoor de viewer punten en lijnen niet kan weergeven.

In CIMOW is geometrie een attribuut van Locatie. Hiertoe wordt geometrie vanuit het CIMOW niet erkend als afzonderlijk object, en is het dus ook niet iets waarvan je bij het wijzigen van één geometrie twee Locaties kunt updaten.
Op bladzijde 34 van het IMOW staat hier een toelichting over (dat dit een verschil is tussen IMOW en CIMOW).

We kunnen hieraan een expliciete zin toevoegen in de trant van: “Hiertoe is het niet toegestaan om twee Locaties naar dezelfde geometrie te laten verwijzen”.

In https://geonovum.github.io/TPOD/CIMOW/IMOW_v2.0.0.pdf staan veel verwijzingen naar “0”. Wat is dat ik kan het niet vinden in de inhoudsopgave van het document.

Matuatiescenario intrekken en vervangen

Er staat nu in IMOW:

• (OW) De OW-objecten van de oude regeling blijven bestaan, en hoeven niet gewijzigd te worden, met uitzondering van de Regeltekst-objecten en het Regelingsgebied.
  • Kortom, de juridische regels, activiteiten, gebiedsaanwijzingen, kaarten, omgevingsnormen, omgevingswaarden en symbolisatieItems blijven hetzelfde.
• (OW) De Regeltekst-objecten en het Regelingsgebied moeten wel aangeleverd worden.
  • De Regeltekst-objecten worden aangeleverd zodat het DSO weet aan welke wId’s deze Regeltekst-objecten gekoppeld moeten worden. De Regeltekstobjecten Ook al zijn de wId’s in principe ongewijzigd, ze horen nu bij een andere Regeling. Het DSO moet hiertoe de oude versies van de Regeltekst-objecten muteren c.q. vervangen voor versies die wijzen naar een andere Regeling.
  • Het Regelingsgebied moet worden aangeleverd zodat het DSO weet op welk gebied een bepaalde regeling van kracht is. (Dit zal in veel gevallen het Ambtsgebied zijn, maar niet per se bij ieder omgevingsdocumenttype.)

En

Bij vrijetekststructuur-omgevingsdocumenten (zoals omgevingsvisies en projectbesluiten) geldt hetzelfde, maar daar waar Regeltekst-objecten staat, moet Divisie/Divisietekst-objecten komen te staan. Kortom, voor de OW-objecten bij het intrekken en vervangen geldt:

• De OW-objecten die een koppeling maken naar de Regeling (Regelingsgebied, Regeltekst, Divisietekst en Divisie) moeten worden aangeleverd.
• De overige OW-objecten moeten alleen worden aangeleverd als deze gemuteerd worden t.o.v. de vorige regeling.

Het voorstel voor wijziging is:
Voor de OW objecten gelden dezelfde regels als voor het muteren met uitzondering van

• Regeltekst (of Divisie/DivisieTekst in vrijetekst-structuur).
• Regelingsgebied

Deze objecten zijn direct verbonden met de Regeling en moeten daarom altijd opnieuw worden aangeleverd. Ze hoeven bij intrekken en vervangen niet beëindigd en opnieuw aangeleverd te worden. De beëindiging gebeurt immers op Regeling-niveau.

MAAR: als een regeltekst niet meer bestaat, moet het OW object WEL worden beëindigd.

Gebleken is dat door de manier waarop het objecttype Ambtsgebied is gemodelleerd, het niet mogelijk is om in meerdere regelingen naar het Ambtsgebied te verwijzen. Het heeft namelijk steeds dezelfde identificatie, waardoor Ozon het afkeurt omdat die identificatie al bestaat. Dit gebeurt zowel wanneer in de verschillende regelingen het Ambtsgebied dezelfde geldigOp-datum heeft als wanneer verschillende geldigOp-data worden gebruikt. Het probleem doet zich voor wanneer een bevoegd gezag in verschillende omgevingsdocumenten wil verwijzen naar het Ambtsgebied en ook wanneer verschillende bevoegde gezagen in hun omgevingsdocumenten naar hetzelfde Ambtsgebied willen verwijzen. Een voorbeeld van het eerste is een provincie die in de omgevingsverordening én in de omgevingsvisie naar het eigen Ambtsgebied wil verwijzen. Een voorbeeld van het tweede is de situatie waarin een provincie in de omgevingsverordening een instructieregel stelt voor een bepaalde gemeente en daarvoor wil verwijzen naar het Ambtsgebied van die gemeente terwijl die gemeente in het omgevingsplan al naar dat Ambtsgebied heeft verwezen. Daarnaast is in de praktijk gebleken dat het voor gebruikers van de standaard niet duidelijk is dat het Ambtsgebied een verschijningsvorm van Locatie is waaraan annotaties met andere OW-objecten kunnen worden gekoppeld.

In het TPOD Omgevingsverordening zijn voorschriften gesteld aan de opsommingstekens die bij een lijst gebruikt mogen worden. Voor een lijst van het tweede niveau moet gebruik gemaakt worden van Arabische cijfers. De indiener wil de vrijheid hebben om achter dat cijfer een o in superscript te zetten en verzoekt om aanpassing van het toepassingsprofiel om dit mogelijk te maken c.q. de beperking op te heffen. De indiener wil dit om voor gebruikers verwarring met leden te voorkomen.

Melding indiener: In IMOW 1.0.3, die volgens jullie informatie tot STOP/TPOD 1.0.4 hoort, staat over het element 'Eenheid' van de Omgevingsnorm: "*Eenheid mag alleen gebruikt worden bij kwantitatieve normwaarden.". Aangezien hier 'mag' staat lijkt met mij (taalkundig) dat het niet verplicht is bij een kwantitatieve normwaarde Oftewel het mag ook dan leeg gelaten worden.

Indiener stelt voor om de tekst "Eenheid mag alleen gebruikt worden bij kwantitatieve normwaarden." in IMOW, CIMOW en indien nodig in de TPOD’s te wijzigen in "Eenheid is verplicht bij kwantitatieve normwaarden en mag niet gebruikt worden bij andere typen normwaarden."