Meldingen geo-standaarden

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.

Wijzigen 'Aanhef' wordt 'Lijstaanhef'' verplicht in Tpod met artikelstructuur

STOP kent tussenkop als een van de inhoud-elementen. De 1.0-versies van de TPOD’s noemen enkele voorbeelden van inhoud-elementen en verwijzen naar STOP voor het volledige overzicht. Gebruik van Tussenkop als element voor Inhoud in instrumenten met artikelstructuur is echter niet gewenst. Daarom in de volgende versies van de TPOD’s het gebruik van Tussenkop bij instrumenten met artikelstructuur uitsluiten. Bij instrumenten met vrijetekststructuur is het gebruik van Tussenkop wel toegestaan.

1. Corrigeren tekst in TPOD’s over gebruik van Noemer bij GIO’s.
2. Onderzoeken of het feit dat TPOD Noemer kent en STOP niet (meer) een probleem is.