• In de TPOD’s staat in het onderdeel Norm en in de Toelichting van de verschijningsvormen van Locatie dat voor het attribuut hoogte altijd de eenheid meter gekozen moet worden. Het is wenselijk om hoogte ook te kunnen gebruiken om een bepaalde bouwlaag aan te geven. De specificatie moet dus worden aangepast, hoe precies moeten we nog bepalen.
• Aan de waardelijst voor eenheid moet de waarde bouwlaag worden toegevoegd
• Uit het normstellende deel van de TPOD-paragraaf over het objecttype Locatie en uit de validatieregels wordt geschrapt de beperking dat voor het attribuut hoogte bij Locatie alleen gekozen kan worden voor (de waarde van de waardelijst Eenheid) meter. Dat geeft de mogelijkheid om bij hoogte gebruik te maken van de eenheid bouwlaag. Die mogelijkheid wordt aan de toelichting op de norm toegevoegd met een voorbeeld.

Inmiddels is gebleken dat de opmaak van tekst, waaronder de koppen, door de publicatiebladen wordt bepaald en verzorgd. Het bevoegd gezag heeft daar dus geen invloed op. De aangehaalde passage zullen in de volgende versie van de toepassingsprofielen worden verwijderd.

In CIMOW, IMOW en de normstellende paragraaf 6.4.2.4 van TPOD omgevingsplan staat in de tekst en/of de diagrammen de constraint: één type Juridische regel per Regeltekst
In paragraaf 6.4.2.5 van TPOD omgevingsplan is daarop de toelichting gegeven: “Deze constraint geldt op het niveau van Artikel: alle Juridische regels in een Artikel en alle Juridische regels in alle Leden van een Artikel moeten van hetzelfde type zijn.”
Dit is niet consistent tussen de verschillende onderdelen van de standaard. Dit moet in een volgende versie consistent gemaakt worden. Uitgangspunt daarbij is dat de toevoeging in TPOD omgevingsplan, dat dit op het niveau van artikel geldt, correct is.

Wijzigingsverzoek voor het OW-deel van de standaarden – met alle waarschijnlijkheid CIM-OW. De bron van dit wijzigingsverzoek zijn de ketenwerksessies rond bruidsschat en OD-Rijk. Kort samengevat komt het neer op het volgende:

• Kadaster heeft een bestuurlijke grenzen database, daarvoor is ook een API gebouwd. Hiermee kunnen de bestuurlijke grenzen door DSO-LV worden opgehaald uit de database.

• Deze API wordt nu gebruikt voor de afleiding van het bevoegd gezag voor vergunningen en meldingen. Het is de wens om de API breder te gaan bevragen binnen DSO-LV.

• Meer in concreto: we willen de bestuurlijke grenzen uit de database van het Kadaster via de API kunnen gebruiken als werkingsgebied c.q. regelingsgebied voor omgevingsdocumenten. Het idee is dat je dan bij levering kan aangeven dat het werkingsgebied en/of het regelingsgebied gelijk zijn aan je ambtsgebied, en dat dan via de API het ambtsgebied opgevraagd wordt en als grens wordt gebruikt. E.e.a is uitgewerkt in een Memo (Red: zie interne notitie)

• De STOP-standaard maakt de gewenste manier van werken al mogelijk, die hoeft niet te worden aangepast. Het OW-deel van de standaarden moet hiervoor wel aangepast worden. Het memo bevat een voorgestelde eindoplossing (aanpassing in CIM-OW) en een tijdelijke werkafspraak die in de tussentijd gebruikt kan worden (opnemen van een string in het veld werkingsgebied / regelingsgebied).

• Qua planning: Kadaster bouwt dit PI de API af zodat hij ook gebruikt kan worden in de STOP-TPOD-keten. Het zou heel fijn zijn als het bevragen hiervan eind dit jaar / begin volgend jaar technisch mogelijk zou zijn – de oplossing met de string wordt door iedereen die er verstand van heeft als uitermate lelijk ervaren, die willen we in productie zeker liever niet gebruiken en bij het oefenen liefst zo tijdig mogelijk.

OZON0094 en OZON0096 zijn duplicaten. Waarschijnlijk destijds bedoeld was om (in aanvulling op de Tekstdeel à Hoofdlijn) een validatieregel te maken die ook controleert dat een gerelateerdeHoofdlijn ook verwijst naar een Hoofdlijn die bestaat. OZON0096 moet vervallen.

Als OZON zegt dat het zinvol is om te controleren of een gerelateerdeHoofdlijn bestaat, dan zal daar een nieuwe ID voor toegewezen moeten worden.

Omtrent OZON0022 en OZON0088: het klopt dat deze tegenstrijdig zijn, maar de validatieregels dienen gelezen te worden t.a.v. het toepassingsprofiel waar ze voor gelden.

OZON0022 geldt voor de toepassingsprofielen die regelstructuur bevatten (zie ook kolom L t/m U, waar “Ja” staat).

OZON0088 geldt voor de toepassingsprofielen die vrijetekststructuur bevatten (zie ook kolom V t/m Y, waar “Ja” staat).
Hiertoe beter OZON0088 niet laten vervallen en dit juist valideren dat een Gebiedsaanwijzing aangeleverd vanuit een omgevingsdocument met vrijetekststructuur wel verwezen wordt vanuit een Tekstdeel.

Tekstuele fout in CIMOW versie 1.0.2 par 3.2.3 laatste stukje van de zin mist.

3.2.3 Procedurestatus.

De procedurestatus kan gebruikt worden om aan te geven dat een bepaald OW-object een specifieke procedurestatus heeft.

In de “Waardelijsten IMOW.xml” v1.0.3 (maar ook eerdere versies) komt geen eenheid voor voor hoek. Booggraden, radialen en/of gon lijken mij een welkome aanvulling voor als je iets met dakhellingen wilt regelen.

Ter aanvulling op dit issue is er een verzoek binnengekomen voor:
de volgende waarden uit de eenheden tabel zijn geen eenheden, maar beschrijvingen van hoe een bepaalde meting tot stand is gekomen. In alle gevallen zou echter als eenheid decibel moeten staan:

• decibel met a-weging
• gemiddeld geluidsniveau over het etmaal
• a-gewogen gemiddelde geluidsniveau
• a-gewogen gemiddelde geluidsniveau nachtperiode
• a-gewogen gemiddelde geluidsniveau dagperiode
• a-gewogen gemiddelde geluidsniveau avondperiodeOnde

Onderzoeken en mogelijke aanpassingen verwerken in de waardelijst ‘Eenheid’

Verzoek voor een aanpassing In IMOW v1.0.2, hieraan staat een GML-voorbeeld wat niet klopt. Dit zou verbeterd moeten worden in de volgende versie van het IMOW.

Verzoek om in de tekst van het IMOW op te nemen dat gebruik van kleine letters in de identificatie van OWobjecten noodzakelijk is omdat deze anders niet door de validator komen. Dit omdat CBS codes van bevoegde gezagen met hoofdletters worden gepubliceerd door het CBS.

Verzoek aanpassing waardelijst ‘Thema’ In het kader van het Annoteren bij het Rijk van de AMvB’s is er de behoefte om aan jullie huidige waardelijst nog twee thema’s toe te voegen:

1. Bouwwerken- duurzaamheid

2. Afvalwater waarbij we graag dit thema willen toevoegen onder zowel MilieuAlgemeenEnOverigeMileuaspecten als onder WaterEnWatersystemen.