U bevindt zich hier:

Valideren instructie

Valideren

Voor de verwerking van de digitale registratie, publicatie en ontsluiting van omgevingsdocumenten dienen deze te voldoen aan diverse technische en functionele eisen. De validatieregels die hiervoor zijn opgesteld vinden hun oorsprong in de documentatie van de STOP/TPOD-standaard en zijn expliciet geïdentificeerd om de validator van LVBB en OZON te kunnen ontwikkelen. Daarnaast hebben bevoegde gezagen en hun softwareontwikkelaars behoefte aan inzicht in de eisen waaraan hun omgevingsdocumenten moeten voldoen om straks succesvol te worden gevalideerd en ontsloten op LVBB en DSO-LV.

De uitwerking van het registratie- en publicatieproces en het daarmee verbonden validatieproces is nog in ontwikkeling. Een en ander kan leiden tot aanpassing van de reeds uitgegeven validatieregels. Het meest actuele overzicht is te vinden in de validatiematrix. Hierin staan alle validatieregels voor TPOD, LVBB en DSO-LV (met service OZON).

Het is de bedoeling om in een latere fase ook de processen in de keten van ‘Idee tot Indiening’ (vergunningenproces) die betrekking hebben op gegevens die rechtstreeks worden aangeleverd aan Toepasbare Regels toe te voegen.

Registratie- en publicatieproces

De omvang van het validatieproces betreft de validaties die worden uitgevoerd binnen de processen richting het bronhouderkoppelvlak, de LVBB en OZON (DSO-LV).

Het bronhouderkoppelvlak is een interface die als aanlever- en terugleverpunt fungeert voor (de plansoftware van) de bevoegde gezagen. Er komt ook nog een component bij welke verantwoordelijk zal zijn voor het bewerkstelligen van het totale validatieproces. De opsplitsing betreft alleen het onderscheid tussen het deel van de LVBB dat over orkestratie gaat en het deel dat de inhoud valideert, publiceert en consolideert.

Er vindt ook synchronisatie plaats van activiteiten. Deze worden door Ozon ingewonnen en worden vervolgens door Toepasbare Regels gebruikt bij het opbouwen van de functionele structuur. De validatieregels die nodig zijn om een geldige functionele structuur te krijgen, zijn in de maak.

Registratie en publicatie van een omgevingsdocument

Dit proces betreft de primaire transacties die plaatsvinden bij een instellingsbesluit of wijzigingsbesluit over een regeling die een (deel van een) omgevingsdocument betreft. Het betreft het geheel aan gegevens, dus zowel STOP-deel als IMOW-deel.

Op conceptueel niveau verloopt het proces als volgt

Validatieproces bij registratie en publicatie omgevingswetbesluit

In bovenstaande figuur wordt het begrip ‘besluit’ gehanteerd dat in brede context moet worden geplaatst. Het betreft in elk geval alle initiële besluiten, wijzigingsbesluiten, niet-consoliderende besluiten, rectificaties en directe mutaties.

Bij alle stappen in dit proces kan uitval voorkomen, zowel in de (ongenummerde) transmissie als in de (genummerde) inhoudelijke verwerking. De validatieregels in de bijgevoegde validatiematrix gaan alleen in op de laatste categorie: op welke stap in het proces wordt een validatieregel uitgevoerd en welk gedrag is er nodig bij afkeur van gegevens.

Korte toelichting per stap:

  1. Validatie van de opdracht door LVBB bronhouderkoppelvlak: Als een bevoegd gezag een besluit of mutatie verstuurt aan het LVBB Bronhouderkoppelvlak, dan vinden in het bronhouderkoppelvlak technische validaties plaats op het niveau van het berichtenverkeer die zich richten op de vraag of de ontvangen opdracht te begrijpen is (zoals: is het een valide ZIP, zijn alle bestanden aanwezig, zijn er geen onverwachte bestanden?).

  2. Validatie van STOP-besluit door LVBB Publicatiecomponent: Een juridisch besluit met betrekking tot een omgevingsdocument wordt gevalideerd door het LVBB Publicatiecomponent.

  3. Validatie van geometrie door Kadaster: De geometrie van het besluit wordt gevalideerd, zoals bijvoorbeeld vastgelegd in een geo-informatieobject (GIO).

  4. Validatie van domeingegevens door DSO-LV OZON: De OZON-component van DSO-LV valideert de bij het besluit aangeleverde domeingegevens.

  5. Evaluatie door LVBB Bronhouderkoppelvlak: Door het LVBB Bronhouderkoppelvlak wordt bepaald of een aangeleverd besluit voldoet aan alle eisen voor LVBB Publicatiecomponent en DSO-LV. Hier wordt een evaluatie gedaan van resultaten bij de stappen 2 t/m 4.

  6. Publicatie van besluit door LVBB Publicatiecomponent: Het besluit wordt middels publicatie door LVBB Publicatiecomponent officieel bekendgemaakt.

  7. Consolidatie van besluit naar regelingversie door LVBB Publicatiecomponent: Het besluit wordt geconsolideerd in de huidige regeling, zodat een nieuwe regelingversie ontstaat. Bij ontwerp-besluiten wordt een ‘toekomstige regelingversie’ gemaakt, dit is geen feitelijke consolidatie van regelgeving. Bij nietconsoliderende besluiten, rectificaties en directe mutaties heeft deze stap wellicht een iets andere betekenis dan een echte consolidatie.

  8. Objectvorming bij DSO-LV OZON: Op basis van de ontstane regelingversie en domeingegevens worden informatieobjecten gemaakt voor de objectgerichte ontsluiting binnen DSO-LV.

Classificatie van validatieregels nader bekeken

Op basis van het eerder beschreven validatieproces wordt een vaste classificatie van validatieregels gehanteerd, als informatie over of documentatie van de validatieregel. Het geharmoniseerde overzicht met validatie-en conformiteitsregels zijn opgenomen in eenseparaat aangeleverde validatiematrix. De classificaties die zijn aangegeven met (*) worden teruggekoppeld aan het systeem van bevoegd gezag bij het verzenden van de resultaatmeldingen aan het eind van het proces.

ID (*) Iedere validatieregel heeft een uniek identificatienummer. Deze nummering wordt toegekend door de beheerders van de respectievelijke validatieregels. De opbouw van dit ID is 4 letters en 4 cijfers. Toekenning van ID’s wordt in overleg gedaan door de partij die ook de validatieregel zelf beheert.

Beschrijving (*) Iedere validatieregel wordt in een beknopte, leesbare tekst beschreven. In de documentatie is een uitgebreidere beschrijving mogelijk waar dit nodig is.

Type Het gaat om verschillende typen validatieregels.

Er bestaan 3 soorten validatieregels:

  • Validatie: Het bestand zelf wordt op validiteit gecontroleerd;

  • Verificatie: Het bestand wordt vergeleken en getoetst met reeds in het systeem aanwezige informatie en/of meegeleverde informatie in een ander bestand.

  • Richtlijn: Er wordt gecontroleerd of een bepaald aspect van de informatie conform die hiervoor geldende standaard is ingezet.

Bron (*) Iedere validatieregel heeft een referentie, bron, grondslag of herkomst.

Geldige bronnen zijn op dit moment:

  • PKI-Overheid

  • Digikoppeling

  • STOP

  • TPOD

  • IMOW

  • GML 3.2.1 SF2

  • ETRS89 - RD

  • DSO-LV

  • Werkafspraak *)
    *)Met een perfecte standaard is dit een lege verzameling. Het komt echter voor dat een standaard ongewenste vrijheidsgraden of fouten heeft die tot implementatieproblemen leiden. In dat geval kan een tijdelijke werkafspraak worden gemaakt met het werkveld, vooruitlopend op de aanpassing van de standaard.

Subject Op welk gegeven of bestand wordt de validatieregel uitgevoerd.

Geldige waarden:

  • Leveringsverzoek

  • Opdracht

  • STOP bestand

  • GML bestand

  • IMOW bestand

  • Besluit

  • Officiële Publicatie

  • Regelingversie

  • Toestand

Ernst (*) Iedere validatieregel is geclassificeerd met een foutcode.

Geldige waarden:

  • Blokkerend: als niet aan deze regel wordt voldaan, dan treedt uitval op conform bovenstaande beschrijvingen;

  • Waarschuwing: als niet aan deze regel wordt voldaan dan treedt er geen uitval op, maar wordt er een waarschuwing gegenereerd door het validerende systeem;

  • Richtlijn: als niet aan deze regel wordt voldaan, dan wordt er een inhoudelijke fout gemaakt. Echter, deze validatieregel wordt nergens technisch afgedwongen en leidt niet tot uitval;

  • Info: De validatieregel leidt tot neutrale informatieve meldingen.

Melding aan Iedere validatieregel leidt tot een mogelijke melding. Dit is de beoogde ontvanger van deze melding.

Geldige waarden:

  • BG: systeem van bevoegd gezag dat de gegevens heeft aangeleverd.

  • Intern: het systeem dat de melding heeft geconstateerd. De meldingen van deze validatieregels gaan dus niet terug in de resultaatmeldingen naar het systeem van bevoegd gezag.

Validator Dit veld geeft aan welke component de validatie uitvoert.

Geldige waarden:

  • LVBB-BHK: het bronhouderkoppelvlak van de LVBB

  • LVBB-PUB: het publicatiecomponent van de LVBB

  • DSOLV-OZON: het OZON-component van DSO-LV

  • Kadaster: generieke geo-validatiecomponent van het Kadaster

Regelingtype Er zijn validatieregels die niet voor alle typen regelingen of besluiten van regelingen van toepassing zijn. Geldige waarden zijn de labels van de waarden in de domeinwaardelijst met regelingtypen (/join/id/stop/soortregeling), zijn mogelijk voor:

  • AMvB - Ministeriële Regeling

  • Omgevingsplan

  • Omgevingsverordening

  • Waterschapsverordening

  • Omgevingsvisie

  • Projectbesluit

Validatievoorbeeldbestanden

Er worden validatievoorbeeldbestanden gemaakt die dienen om de validaties te controleren. Dit is de implementatie-test van de validaties. De validaties zelf zijn geschreven afhankelijk van de positie van waar de validatie plaatsvindt en wat de validatie inhoudt. Ze bevinden zich dus in een code-complex en kunnen uit verschillende technieken bestaan. Bijvoorbeeld een validatie over de welformd-heid van een XML document kan middels schematron en/of XML-schema geschieden. Echter een validatie van een ID zal dan weer  een API gebruiken of een database-query uitvoeren.