De aanleiding voor deze wijziging is de wens om voor de Omgevingswet in LVBB en DSO nieuwe functionaliteiten te realiseren. De onderhavige wijziging biedt de OW-component die hoort bij STOP 1.4.

Het doel voor het wijzigen van de standaard is het mogelijk maken van nieuwe (release B) functionaliteiten in het DSO. Het gaat om wat er nodig is aan de TPOD/IMOW-kant voor:

• Nieuwe consolidatiescenario’s (zoals inhaalbesluiten, gelijktijdige inwerkingtreding van besluiten en besluiten met terugwerkende kracht)
• Rectificatie
• Mededeling uitspraak rechter

Ook zijn er enkele wijzigingen om het DSO beter te laten werken respectievelijk om het werken voor bevoegde gezagen te vereenvoudigen.

Idealisatie is een verplicht attribuut van Juridische regel en Tekstdeel, dat vastlegt hoe het bevoegd gezag de begrenzing van de Locatie voor deze Juridische regel/dit Tekstdeel heeft bedoeld: exact of indicatief. Een Regeltekst (artikel of lid) kan 1 of meer Juridische regels hebben. Juridische regel is een abstract concept: in een artikel of lid kan je de individuele Juridische regels niet onderscheiden. Binnen een Regeltekst kan de idealisatie van de ene Juridische regel exact zijn en van de andere indicatief. De Juridische regels kunnen verschillende Locaties hebben, maar ook dezelfde Locatie. Een viewer kan niet laten zien bij welk stuk van de tekst de Locatie indicatief bedoeld is en bij welk stuk tekst exact. Datzelfde geldt voor de idealisatie van Tekstdeel (stuk vrije tekst). Vanuit de inhoud geredeneerd is het onwenselijk om exact bedoelde en indicatief bedoelde begrenzingen in één artikel, lid of stuk vrije tekst door elkaar te mengen.

In 2023 hebben deze onvolkomenheid in de TPOD-standaard ontdekt. Het oplossen van die onvolkomenheden leidt tot niet-backwards compatible wijzigingen. We hadden toen, vanwege het bevroren moeten zijn van de standaard, niet de mogelijkheid om niet-backwards compatible wijzigingen in de standaard te doen. Daarom hebben we aan de TPOD’s bij Juridische regel en Tekstdeel werkafspraken toegevoegd over de toepassing van idealisatie. Nu, na inwerkingtreden van de Omgevingswet, is er wel ruimte voor niet-backwards compatible wijzigingen.

1 In IMOW was geen voorschrift opgenomen over de toepassing van de verschijningsvormen van Locatie (gebied resp. gebiedengroep) en van geometrie (multigeometrie). Daarom worden ze door elkaar gebruikt. Bij Omgevingsnorm en Omgevingswaarde is dat wel relevant: is de betekenis van een waarde voor een gebiedengroep anders dan voor een multivlak? IMOP en IMOW kennen geen kenmerk om aan te geven dat een waarde een gezamenlijke waarde is voor meerdere geometrieën. Door deze beide omstandigheden kan een viewer niet anders dan waarden weergeven bij iedere individuele geometrie.

2 STOP stelt regels om de correcte weergave van GIO’s af te dwingen opdat alle inhoud van een besluit voor het menselijk oog kan worden weergegeven zonder dat daarvoor hulpmiddelen (zoals klikken in een kaart) nodig zijn. Ook de waarden van Normen moeten direct leesbaar zijn. Een GIO met meerdere waarden op dezelfde locatie en een GIO met Locaties die elkaar geheel/gedeeltelijk overlappen wordt om die reden afgekeurd.

In 2023 hebben deze onvolkomenheid in de TPOD-standaard ontdekt. Het oplossen van die onvolkomenheden leidt tot niet-backwards compatible wijzigingen. We hadden toen, vanwege het bevroren moeten zijn van de standaard, niet de mogelijkheid om niet-backwards compatible wijzigingen in de standaard te doen. Daarom hebben we in de TPOD’s een aantal werkafspraken toegevoegd over een Normwaarde die bedoeld is als gezamenlijke waarde voor meerdere geometrieën en over het aantal waarden van een Norm op 1 Locatie.

Nu, na inwerkingtreden van de Omgevingswet, is er wel ruimte voor niet-backwards compatible wijzigingen.

In de TPOD-standaard is hoogte een optioneel attribuut van Locatie, waarmee de hoogte kan worden aangegeven waarop de Locatie ligt. Het is bedoeld als een (zeer beperkte) benadering van 3D. STOP kent hoogte niet, het is geen kenmerk van het GIO of de OP-Locatie. Hoogte, dat bedoeld is juridische betekenis te hebben, kan daardoor niet rechtsgeldig bekend gemaakt worden.

In 2023 hebben deze onvolkomenheid in de TPOD-standaard ontdekt. Het oplossen van die onvolkomenheden leidt tot niet-backwards compatible wijzigingen. We hadden toen, vanwege het bevroren moeten zijn van de standaard, niet de mogelijkheid om niet-backwards compatible wijzigingen in de standaard te doen. Daarom hebben we aan de TPOD’s de werkafspraak ‘gebruik het attribuut hoogte niet’ toegevoegd. Nu, na inwerkingtreden van de Omgevingswet, is er wel ruimte voor niet-backwards compatible wijzigingen.

Bij deze een wijzigingsverzoek voor nieuwe validatiematrix van LVBB/STOP in de bijlage.

Aanpassingen aan de validatiematrix die het Kadaster voorstelt:

Wijzigingen
• OZON0022    Er moet een RegelVoorIedereen, Instructieregel of Tekstdeel zijn die verwijst naar de Gebiedsaanwijzing
Deze regel valideert bij ons ook of er een Omgevingswaarderegel wijst naar de Gebiedsaanwijzing. Ik stel voor de tekst te wijzigen naar: Er moet een RegelVoorIedereen, Omgevingswaarderegel, Instructieregel of Tekstdeel zijn die verwijst naar de Gebiedsaanwijzing.

• OZON0069    (TPOD940) Als een Locatie uit meer dan één geometrie bestaat, dan moeten de geometrieën volgens dezelfde coordinate reference system (crs) zijn opgebouwd.
Ik kan geen referentie terugvinden naar TPOD940 dus ik stel voor de verwijzing daarnaar te laten vervallen.

• OZON0090    Iedere Divisie moet verwijzen naar een of meerdere Tekstdelen.
Geldt ook voor Divisietekst. Ik stel voor 'Iedere Divisie(tekst) moet verijzen naar een of meerdere Tekstdelen.

• OZON0098    (TPOD1850) Een Regeltekst die verwijst naar een RegelVoorIedereen, mag niet naar een Instructieregel of Omgevingswaarderegel verwijzen.
• OZON0099    (TPOD1850) Een Regeltekst die verwijst naar een RegelVoorIedereen, mag niet naar een Instructieregel of Omgevingswaarderegel verwijzen.
• OZON0100    (TPOD1850) Een Regeltekst die verwijst naar een RegelVoorIedereen, mag niet naar een Instructieregel of Omgevingswaarderegel verwijzen.
Hier staat drie keer hetzelfde. Hier zou moeten staan:
• OZON0098    (TPOD1850) Een Regeltekst die verwijst naar een RegelVoorIedereen, mag niet naar een Instructieregel of Omgevingswaarderegel verwijzen.
• OZON0099    (TPOD1850) Een Regeltekst die verwijst naar een Omgevingswaarderegel , mag niet naar een Instructieregel of RegelVoorIedereen verwijzen.
• OZON0100    (TPOD1850) Een Regeltekst die verwijst naar een Instructieregel , mag niet naar een RegelVoorIedereen of Omgevingswaarderegel verwijzen.

OZON0132 tekst graag aanpassen naar "Een aanlevering met een Geometrie waarvan de 'id' gelijk is aan die van een eerder aangeleverde Geometrie, maar met een andere geometrie, wordt afgekeurd."

• OZON0218/OZON0219: wij valideren dit ook voor Juridische Regels resp. Tekstdelen. Dat graag toevoegen in de tekst.
Toevoegingen
Toevoegen van de volgende validatieregel:
• OZON1037 Een regeling die een tijdelijk deel is, mag zelf geen pons hebben.
Kan komen te vervallen

Samenvoegen/ontdubbelen
We hebben een tijd terug besloten om de 'dubbelingen' tussen TPOD en OZON regels te laten vervallen, en alleen de TPOD regels te handhaven. De OZON regels zijn dan implementaties daarvan (met duidelijke verwijzing naar de TPOD regel) maar hoeven niet apart daarvan in de Validatiematrix. Het lijkt me daarom prima om de volgende OZON-regels uit de Validatiematrix te halen: OZON0097, OZON0129, OZON0130, OZON0131, OZON2000 (verwijst naar TPOD2000), OZON2040, OZON2060, OZON2140, OZON2150, OZON2210, OZON5001, OZON5002, OZON5003, OZON5004

Verwijzingen naar TPOD-regels
Er wordt vanuit de OZON-regels verwezen naar TPOD940, TPOD1850, TPOD2180. Waar kan ik deze (de oorspronkelijke TPOD-regels) terugvinden? Als de verwijzingen hier gecorrigeerd zijn, dan kunnen ook hier de afzonderlijke OZON-regels samengevoegd/ontdubbeld worden.

Interne validaties
De volgende validaties kunnen wat mij betreft komen te vervallen uit de Validatiematrix, aangezien het interne validaties betreft (d.w.z. fouten in de interne planketen, dus tussen de LV's). Het bevoegd gezag en/of de plansoftwareleverancier krijgt van ons in deze gevallen wel een melding, maar kan deze zelf niet verhelpen. Dat geldt voor de volgende regels: OZON0220, OZON1019, OZON1020, OZON1021, OZON1024, OZON1026, OZON1027, OZON1028, OZON1029, OZON1031, OZON1032, OZON1036, OZON1038, OZON1039, OZON1040.

Momenteel dwingen standaard en planketen niet af dat geometrie binnen de landsgrenzen van Nederland moet liggen. Om technische problemen te voorkomen is het wenselijk dat geometrische informatie die verwerkt wordt binnen de planketen en aangeleverd wordt aan de Landelijke Voorzieningen, binnen de Nederlandse landsgrenzen liggen:

• DSO-LV maakt een set Vector Tiles van de aangeleverde geometrie. Wanneer de aangeleverde geometrie niet binnen (of in de buurt van) Nederland ligt, dan wordt deze set onbeheersbaar groot.
• Het is nodig om te controleren dat de aangeleverde geometrie betekenisvol geïnterpreteerd kan worden binnen een bepaald coördinatenstelsel. Als een aanleverende partij bijvoorbeeld RD-geometrie aanlevert, maar dit per ongeluk markeert als ETRS-89 geometrie (of andersom) is het wenselijk dat OZON dat detecteert en de aanleverende partij op de hoogte stelt van de fout. Dit kan nu niet, aangezien OZON nu, wegens het ontbreken van een verplichting in de TPOD-standaard, geen inhoudelijke controle kan doen op het bereik van de coördinaten. Valideren op geometrische extent is een manier om dit mogelijk te maken.
• Bij transformatie van RD naar ETRS89 en andersom wordt het transformatie-algoritme RDNAPTRANS2018 gebruikt. Onderdeel hiervan is een rechthoekig correctiegrid dat heel Nederland afdekt. De transformatie is alleen gedefinieerd binnen de grenzen van dit correctiegrid. Geometrie daarbuiten kan dus niet betekenisvol getransformeerd worden , en is daarmee binnen de Landelijke Voorziening niet bruikbaar.

Om deze redenen wordt voorgesteld om aan IMOW een regel toe te voegen die het verbiedt om bij (besluiten tot instelling of wijziging van) omgevingsdocumenten geometrie aan te leveren die ligt buiten de boundingBox

(RD) respectievelijk

(ETRS89). Aan de validatiematrix wordt een corresponderende validatieregel toegevoegd.

Dit leidt tot een technische validatie. Doel van deze validatie is om het naar behoren functioneren van de landelijke voorziening te beschermen. Deze technische validatie moet snel en efficiënt uitgevoerd kunnen worden. Daarom is gekozen voor validatie aan de hand van een bounding box rondom de geometrie van Nederland + exclusieve economische zone, die aan alle zijden naar buiten toe is afgerond op de eerste gehele kilometer om afrondingsfouten te voorkomen en om bruikbare getallen te hebben. Zie de bijlage voor een afbeelding van deze bounding box, waarin de RD- en ETRS-bounding boxes zijn geprojecteerd op een kaart van Nederland (de trapeziumvormige veelhoek is RD, de rechthoek is ETRS89). Valideren met een bounding box is sneller en efficiënter dan met een gedetailleerde geometrie.

Deze validatie zorgt ervoor dat de technische problemen niet optreden:

• De bounding box, waarmee het gebied is vastgelegd waarbinnen de geometrie van omgevingsdocumenten moet liggen, is kleiner dan het Vector Tile grid dat DSO-LV hanteert. Daardoor wordt de set Vector Tiles niet onbeheersbaar groot.
• De bounding box is kleiner dan het RDNAPTRANS2018 correctiegrid dat wordt gebruikt voor de transformatie van RD naar ETRS89 en omgekeerd. Betekenisvolle transformatie is daardoor altijd mogelijk.
• Juridisch gezien kunnen omgevingsdocumenten geen regels en beleid stellen voor het gebied dat buiten Nederland + exclusieve economische zone valt. Daarom is aangeleverde Geometrie die buiten de bounding box ligt onjuist en is het terecht dat het aanleverende bevoegd gezag van deze fout op de hoogte wordt gesteld door middel van een blokkerende foutmelding bij de validatie.

Het is een Z-wijziging omdat het het expliciet vastleggen van een al geldende regel betreft. In de Omgevingswet is expliciet bepaald dat deze wet geldt binnen Nederland en de exclusieve economische zone. Juridisch gezien kunnen bevoegde gezagen in omgevingsdocumenten geen regels en beleid stellen buiten dat gebied. In IMOW is nu al vastgelegd dat RD of ETRS89 gebruikt moet worden. Buiten de extent van de nu voorgestelde bounding box is RD niet zinvol gedefinieerd.

Met directe mutaties kunnen alle OW-objecten gewijzigd worden. Onder wijzigen vallen het veranderen van een of meer attributen van een OW-object en het beëindigen van een OW-object. De OW-objecten Regeltekst, Juridische regel, Divisie, Divisietekst, Tekstdeel, Locatie en Normwaarde zijn onlosmakelijk verbonden met de teksten en GIO's van de bekendmaking en de geconsolideerde regeling op http://overheid.nl . Een directe mutatie van die objecten kan leiden tot verschillen tussen de regeling op http://overheid.nl en de regeling in het DSO. Dit levert een groot juridisch risico op. Daarbij komt dat directe mutaties zelf geen tijdgegevens hebben. Directe mutaties worden daarom gekoppeld aan het Doel en daarmee aan de tijdslijnen van het oorspronkelijke besluit. Daarmee hebben directe mutaties terugwerkende kracht en zijn de wijzigingen niet te traceren: er is geen juridisch verantwoordingsspoor. We merken dat het bestaan van de mogelijkheid van directe mutaties leidt tot twijfel aan de juridische betrouwbaarheid van omgevingsdocumenten in het DSO. Door met een directe mutatie en dus met terugwerkende kracht een Activiteit te beëindigen verdwijnen de toepasbare regels bij die Activiteit. Daardoor is er geen aanvraagformulier meer, leidt de Vergunningcheck tot een andere uitkomst en kan een gedane vergunningaanvraag niet meer aangevuld worden. Conclusie is dat directe mutaties onwenselijk zijn.

Directe mutaties waren ooit gedacht voor foutherstel en vooral voor het achteraf annoteren: stapsgewijs komen van minimum tot rijk geannoteerde regelingen. In de praktijk zien we dat het annoteren onlosmakelijk verbonden is met het schrijven van teksten in de plansoftware: je doet het tegelijk. Bij de Aanleiding Wijziging Standaard is al aangegeven dat directe mutaties onwenselijk zijn omdat ze leiden tot het juridische risico dat er verschillen ontstaan tussen de regeling op http://overheid.nl en de regeling in de DSO-viewer, verminderde betrouwbaarheidsperceptie van de regeling in de DSO-viewer en tot problemen bij de Vergunningcheck en het aanvragen van vergunningen en doen van meldingen. Iemand die een regeling voor én na een directe mutatie bekijkt, krijgt beide keren iets verschillends te zien. Door de terugwerkende kracht van directe mutaties hebben krijgt deze persoon bij een tijdreis terug naar de eerste raadpleegdatum iets anders te zien dan toen hij/zij op die datum de regeling bekeek. Het met een directe mutatie beëindigen van een Activiteit leidt er toe dat de vergunningcheck voorafgaand aan de directe mutatie een andere uitkomst heeft dan daarna, zonder dat dat inziichtelijk is. Een ingediende vergunningaanvraag kan na de directe mutatie niet meer aangevuld worden. We hebben database-onderzoek gedaan. Daaruit hebben we geconcludeerd dat directe mutaties de laatste maanden nagenoeg niet meer worden aangeleverd door bevoegde gezagen en dat ze alleen nog (beperkt) worden ingezet door de beheerders van het stelsel om problemen met vastzittende regelingen op te lossen. Deze constateringen hebben geleid tot het wijzigingsvoorstel. Dat heeft deze onderdelen: 1. De beschrijving van directe mutaties in IMOW wordt zodanig aangepast dat duidelijk is dat directe mutaties niet door bevoegde gezagen aan het BHKV aangeleverd mogen worden Dit is een wijziging die niet backwards compatible is. Daarom is het een X-wijziging 2. In de CPA's van alle bevoegde gezagen wordt niet de mogelijkheid opgenomen om directe mutaties van OW-objecten aan te leveren De CPA is de Collaboration Protocol Agreement. Dit is het digitale contract met het bevoegd gezag voor gegevensuitwisseling op Digikoppeling van Logius. In de CPA wordt bepaald welke opdrachten een bevoegd gezag mag aanleveren (en met welke software). 3. Directe mutaties van OW-objecten die nodig zijn voor het oplossen van problemen met een vastzittende regeling kunnen alleen worden uitgevoerd door beheerders van het stelsel, op aanvraag van het bevoegd gezag Als een regeling helemaal vastzit door problemen met OW-objecten, kan het bevoegd gezag bij LVBB/OZON assistentie aanvragen. De beheerders kunnen dan met directe mutaties het probleem oplossen. Het bevoegd gezag kan vervolgens met de downloadservice de aangepaste bestandenset van de regeling downloaden en in de eigen software importeren.

In het operationeel overleg met de leveranciers is er instemming bereikt over nieuwe validatieregels en tevens besproken met alle andere betrokken partijen:

1. Er mag hoogstens één Regeltekst-object naar een Artikel/Lid verwijzen.

1. Er mag hoogstens één OW Divisie-object naar een OP Divisie verwijzen.

1. Er mag hoogstens één OW Divisietekst-object naar een OP Divisietekst verwijzen.

Eerst de impliciete mutatie validaties . LVBB5002 en LVBB5010 vervallen en worden vervangen door LVBB5023 t/m LVBB5030

LVBB5023

Rule: De RegelingMutatie MAG GEEN toe te voegen wId's bevatten die reeds voorkomen in de was-versie

Melding: In de RegelingMutatie komen de volgende toe te voegen wIds reeds voor in de was-versie: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

LVBB5024

Rule: In de RegelingMutatie komen de volgende toe te voegen wIds reeds voor in de was-versie: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

Melding: In de RegelingMutatie komen de volgende te verwijderen wIds niet voor in de was-versie: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

LVBB5025

Rule: De RegelingMutatie MAG GEEN impliciet toegevoegde wId's in de vervang-mutatie bevatten

Melding: Bij verwerking van de RegelingMutatie komen de volgende impliciet toegevoegde wIds voor in de wordt-versie: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

LVBB5026

Rule: De RegelingMutatie MAG GEEN impliciet verwijderde wId's in de vervang-mutatie of verwijder-mutatie bevatten

Melding: Bij verwerking van de RegelingMutatie komen de volgende impliciet verwijderde wIds voor in de wordt-versie: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

LVBB5027

Rule: De @context in de RegelingMutatie MOET bestaan in de wordt-versie

Melding: In de RegelingMutatie worden de volgende wIds als context gebruikt, maar komen niet voor in de was-versie en worden ook niet toegevoegd: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

LVBB5028

Rule: De RegelingMutatie MAG GEEN kind-elementen in de vervang-mutatie of verwijder-mutatie gebruiken die niet voorkomen in de was-versie

Melding: Binnen RegelingMutatie heeft de verwijder / vervang mutatie
voor wId %1 de volgende wIds die niet als child voor deze wId in de was-versie voorkomen: %2. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

*LVBB5029*

Er is nog een interne diiscussie over de precieze regel. Ik zou dit voorlopig even leeglaten.

LVBB5030

Rule: Elk expliciet toegevoegd element MOET uiteindelijk in de wordt-versie terecht komen.

Melding: In de RegelingMutatie hebben de volgende toe te voegen wIds
geen parent in de wordt-versie: %1. Hierdoor kan/kunnen de mutatie(s) niet worden uitgevoerd.

=========

Hieronder staan nog meer validaties die in andere stories toegevoegd worden/zijn.

LVBB1579
Regel: Publicatieopdracht MAG NIET worden afgebroken als de wetstechnische informatie, die voortkomt uit deze opdracht, al gepubliceerd is

Foutmelding: De opdracht kan niet worden afgebroken. De wetstechnische informatie, die voortkomt uit de opdracht met oin %1 en idlevering %2, is al gepubliceerd.

LVBB1575

Rule: Het manifest.xml MOET unieke bestanden bevatten

Melding: Een bestand in het manifest.xml is niet uniek en dat is niet toegestaan.

LVBB1576

Rule: Besluit dat afgebroken moet worden mag geen regeling intrekken waarvan de intrekking al gepubliceerd is.

Melding: De opdracht kan niet worden afgebroken. Intrekking van regeling met akn %1 is al gepubliceerd.

LVBB1577

Rule: Besluit dat afgebroken moet worden mag geen informatieobject intrekken waarvan de intrekking al gepubliceerd is.

Melding: De opdracht kan niet worden afgebroken. Intrekking van informatieobject met join %1 is al gepubliceerd.

LVBB4046

Rule: De volgende elementen binnen RegelingMetadata MOGEN NIET worden gewijzigd:

• Eindverantwoordelijke
• Opvolging
• SoortRegeling
• Maker

Melding: Element %1 in de RegelingMetadata is gewijzigd. Dat mag niet.

LVBB4047

De volgende elementen binnen InformatieobjectMetadata MOGEN NIET worden gewijzigd:

• Eindverantwoordelijke
• FormaatInformatieobject
• Opvolging
• Publicatieinstructie
• Maker

Melding: Element %1 in de InformatieobjectMetadata is gewijzigd. Dat mag niet.

*LVBB4500*

regel: Terugtrekkingen in de consolidatieinformatie MOGEN NIET gebruikt worden.

melding: Het is niet toegestaan terugtrekkingen in de consolidatieinformatie te gebruiken.

*LVBB5022*

Rule: Een definitief besluit met een RegelingTijdelijkdeel MAG NIET een tijdelijk deel zijn van een ontwerpregeling

Melding: Het is niet mogelijk om een RegelingTijdelijkdeel aan te maken die een tijdelijk deel is van een ontwerpregeling. Regeling %1 is een ontwerpregeling.

LVBB5031

Rule: Een tekst:Vervang met @revisie=1 in een RegelingMutatie MAG GEEN renvooi-elementen of @context bevatten

Melding: In de RegelingMutatie bevat de Vervang met @revisie=1 van wid/wat %1 renvooi elementen en/of een @context. Dit is niet toegestaan.

*LVBB5900*

Rule: Een directe mutatie MAG NIET worden gedaan op een ontwerpregeling

Melding: Het is niet mogelijk om een directe mutatie te doen op een ontwerpregeling.

Met vriendelijke groet,

*Brigitte Meijer*

*Informatieanalist LVBB*

........................................................................

Logius

Ministerie van Binnenlandse Zaken en Koninkrijksrelaties

........................................................................

06 – 380 567 20

www.logius.nl| https://koop.overheid.nl

brigitte.meijer@koop.overheid.nl

........................................................................

Sinds 1 januari 2023 is KOOP onderdeel van Logius

Logius is continu op zoek naar nieuwe collega’s: bekijk alle vacatures op onze website.

Samen zorgen we voor een digitale overheid die werkt voor iedereen!