Op deze bladzijde bieden we in tabelvorm en ter download de requirements (specificaties) aan voor de omgevingsbeleidsoftware per 2022. Requirements geven inzicht in de wensen en eisen die we stellen aan software. Het betreft hier de software die nodig is voor het maken en wijzigen van omgevingsvisie, programma en omgevingsplan.
De requirements zijn bedoeld voor gemeenten die zich oriënteren op nieuwe software voor planvorming dan wel een verwerving gaan starten. Ze helpen de inhoudelijk specialisten (o.a. plan juristen) , medewerkers van ICT (functioneelbeheerders en informatiemanagers) en specialisten van inkoop en aanbesteding om gezamenlijk een beeld te vormen van de aan te verwerven software. Binnen de Gemeentelijke Model Architectuur (GEMMA) wordt deze groep componenten (applicaties) ook wel omgevingsbeleidcomponenten genoemd, of te wel de applicaties die het maken van beleid voor de Omgevingswet ondersteunen. Deze omgevingsbeleidcomponenten zijn modulair opgezet waardoor een gemeente afhankelijk van haar specifieke wensen meer of minder componenten kan gebruiken: zie voor meer informatie modulaire opzet.
Iteratief: Nu een 1.3 versie, straks een 1.4 versie
De requirements worden met input van gemeenten en softwareleveranciers iteratief opgesteld. De onderstaande versie betreft de 1.3 versie (september 2020). Het betreft hier nadrukkelijk niet de definitieve versie van de requirements. Gezien de ontwikkelingen binnen het Digitaal Stelsel Omgevingswet, weten we dat de eisen die we aan de software stellen nog worden aangepast. Denk hierbij aan de ontwikkeling van STOP-TPOD of de samenwerkingsruimte. Beide onderwerpen zijn nog in beweging en gaan zorgen voor aanpassingen in de requirements.
Versies
Versie
Datum
Toelichting
1.0
Juni 2019
Requirements akkoord bevonden door gemeenten en software leveranciers (n.a.v. VNG markttoets) en officieel vastgesteld.
1.1
November 2019
De uitleg van veel requirements bijgewerkt. Twee requirements zijn vervallen en zijn er twee requirements toegevoegd.
1.2
Maart 2020
Enkele requirements tekstueel bijgewerkt
1.3
September 2020
Nieuwe versie met o.a. aandacht voor nieuwe rol van de stelselcatalogus en het koppelvlak tussen juridische- en toepasbasbare regels. Zie onderstaande tabel voor wijzigingen.
Nieuw in versie 1.3
Requirement
Toelichting
OB01
Toegevoegd dat voor de realisatie van deze requirement de nog niet beschikbare download service benodigd is.
OB02
Nieuwe requirement. Modulaire opzet van de software. Reacties gewenst!
OBR01
Scherper verwoord dat het om het uitwisselen van informatie gaat. Tevens naar categorie onbepaald.
OBR02
Toegevoegd - Kunnen inzien van de geldende regels op een te kiezen datum.
OBR07
Tekst aangescherpt. Van categorie "could" naar categorie "onbepaald" waarmee de gemeente zelf het belang kan aangeven.
OBT02:
Toegevoegd dat ook begrippen moeten kunnen worden geannoteerd. Dit vanwege nieuwe werkwijze van de stelselcatalogus.
OBT06:
Toegevoegd dat het ook om importeren van waardelijsten gaat
OBT07
Met nieuwe werking van de DSO Stelselcatalogus de requirement smaller gemaakt naar alleen het kunnen inzien en overnemen van begrippen. Opvoeren van nieuwe begrippen is hiermee komen te vervallen en gebeurt voortaan met de publicatie van een omgevingsplan.
OBWP07
Nieuwe requirement. Hiermee wordt zaakgericht werken geïntroduceerd in de keten van plan tot publicatie. Requirement gaat dan enkele OBWP requirements vervangen. Reacties gewenst!
OBP05
Tekst aangepast. Was: kunnen valideren van besluit. Is geworden: kunnen valideren van regeling.
OBV03
Toegevoegd: Kunnen inzien van de geldende regels op een te kiezen datum
Requirements en aanbesteding
Wil een gemeente software verwerven, dan bieden deze requirements een goede basis voor die aanbesteding. Wil je meer weten over de verschillende manieren van aanbesteden en op welke wijze je de daarbij requirements gebruikt? Volg dan de Masterclass verwerven van Omgevingswet software en lees de Handreiking Verwerking.
Naar verwachting zullen de meeste leveranciers aan de belangrijkste requirements gaan voldoen (zie ook onderstaande indeling in categorieën). Dit zorgt er voor dat je qua functionaliteit als gemeente niet snel een "foute" keuze kan maken. Toch zullen de leveranciers op onderdelen gaan verschillen. Om hier inzicht in te verkrijgen zullen op deze site en in de handreiking verwerving ook open vragen verschijnen waarmee een gemeente die inzicht kan verkrijgen. Denk hierbij aan vragen als: Op welke manier zal de leverancier de workflow voor het opstellen van een omgevingsplan ondersteunen? Of op welke manier gaat de leverancier ondersteuning bieden aan het koppelen van juridische en toepasbare regels?
Uniforme manier van uitvragen
Met de requirements en de open vragen in de handreiking biedt VNG aan gemeenten een uniforme manier van uitvragen van de plansoftware. Een uniforme manier van uitvragen is essentieel om komende periode van implementatie succesvol te laten verlopen. Softwareleveranciers op gebied van planvorming staan al onder druk om op 1 januari 2022 werkende software te kunnen leveren. Als iedere gemeente op haar eigen manier met eigen requirements de software gaat aanbesteden, levert dit voor de softwareleveranciers veel werk op. De tijd die ze daarmee besteden aan het meedoen met de aanbesteding, kunnen ze niet gebruiken om de software te ontwikkelen. Door op een als gemeenten op een uniforme wijze aan besteden, zorgen we er voor dat leveranciers kunnen focussen de ontwikkeling van software.
Doorontwikkeling applicaties: Na 1 januari 2022 zal de software voor planvorming zich verder ontwikkelen. Gemeenten hebben hierbij aangegeven dat ze graag zien dat de software gaat voldoen aan Common Ground en dat de gehele beleidscyclus (van visie, naar plan, vergunning verlening, toezicht, handhaving en evaluatie) wordt ondersteund met integrale software. Komende periode zal deze doorontwikkeling verder in beeld worden gebracht.
Soorten requirements
Wat is nu echt softwarefunctionaliteit die een gemeente per 1 januari 2022 nodig heeft? Welke is nodig, maar kan ook eventueel na 1 januari? En welke functionaliteit is niet essentieel en kan iedere gemeente voor zich zelf besluiten of ze deze functionaliteit wil gebruiken. Hiervoor hanteren we de onderstaande drie categorieën. Per requirement is aangegeven welke categorie het betreft.
Must Have: Deze functionaliteiten zijn noodzakelijk om de wet uit te kunnen voeren op het moment dat de wet in werking treedt. Het gaat om functionaliteiten om aan te kunnen sluiten op DSO-LV en andere verplichte landelijke voorzieningen en om functionaliteiten om essentiële processtappen uit te kunnen voeren. Functionaliteiten in deze categorie zijn in alle gevallen ‘Must Have’. Voorbeelden hiervan zijn, het kunnen produceren van een omgevingsplan in STOP-formaat en het kunnen publiceren van dit plan naar LVBB, het kunnen ophalen van een vergunningaanvraag in STAM-formaat en het kunnen verlenen van een omgevingsvergunning.
Should Have: Deze functionaliteiten zijn gezien vanuit het wettelijke minimum niet noodzakelijk om de wet uit te kunnen voeren, maar volgens VNG wel essentieel voor een adequate uitvoering. Deze functionaliteiten zijn volgens VNG minimaal ’Should Have’. U kunt besluiten om enkele van deze functionaliteiten als ‘Must Have’ te bestempelen als u ze voor uw eigen situatie noodzakelijk acht. Een voorbeeld van een functionaliteit in deze categorie is functionaliteit voor het aansluiten op de samenwerkingsfunctionaliteit van DSO-LV. Deze aansluiting is niet verplicht, maar wel essentieel om binnen de wettelijke termijn een vergunningaanvraag in samenwerking met andere partijen af te kunnen handelen.
Onbepaald: Deze functionaliteiten zijn niet noodzakelijk vanuit het wettelijke minimum of essentieel voor een adequate uitvoering. VNG kan daarom aan deze functionaliteiten geen belang toekennen. U dient zelf te bepalen hoe gewenst deze functionaliteiten voor situatie is. VNG raadt aan om deze softwarerequirements te internaliseren voordat u ze gebruikt bij het definiëren van een PvE voor uw software door uw lokale situatie te vertalen in ‘must haves’, ‘should haves’, ‘could haves’ en ‘won’t haves’.
Overzicht Omgevingsbeleidcomponenten
De Omgevingsbeleidcomponenten vormen gezamenlijk de software die benodigd is voor het opstellen van beleid voor de Omgevingswet. Denk hierbij aan het wijzigen van het omgevingsplan of het maken van een omgevingsvisie. Onder de Omgevingsbeleidcomponent vallen een aantal subcomponenten.
Modulaire opzet: De omgevingsbeleidcomponent is modulair opgezet. Iedere subcomponent is of een module binnen een grotere softwaresuite of een apart aan te schaffen applicatie. Het is aan de gemeente om te kiezen op welke manier zij de applicaties willen aanschaffen. Zie ook requirement OB02.
Omgevingsplan uitbesteed aan een bureau? Met de modulaire opzet ondersteunen de requirements zowel gemeenten die zelf hun omgevingsplan gaan onderhouden, als gemeenten die deze taak uitbesteden aan een bureau. Een gemeente die het wijzigen van haar plan uitbesteed zal vermoedelijk voldoende hebben aan de publicatie- en viewer component. Waarbij een gemeente die haar plannen zelf maakt de gehele omgevingsbeleidcomponent zal gebruiken. Momenteel (september 2020) onderzoekt de VNG op welke manier gemeenten en stedenbouwkundige bureaus's digitaal samen kunnen werken onder de Omgevingswet.
Onderstaande geeft een overzicht van de component met sub-componenten. Van iedere component kunnen de requirements als CSV worden gedownload.
Onderstaande tabellen tonen de requirements per (sub-)component. We starten met de hoofdcomponent, de omgevingsbeleidcomponent.
Omgevingsbeleidcomponent
Omschrijving: Toekomstige component voor het ontwikkelen, beheren en digitaal beschikbaar stellen van omgevingsdocumenten (omgevingsplan, omgevingsvisie en programma) conform de Omgevingswet standaarden. Hiermee is de Omgevingsbeleid component de opvolger van de GEMMA WRO-component. De Omgevingsbeleidcomponent bevat diverse functionalteiten voor omgevingswetbesluiten., Toekomstige component voor het ontwikkelen, beheren en digitaal beschikbaar stellen van omgevingsdocumenten (omgevingsplan, omgevingsvisie en programma) conform de Omgevingswet standaarden. Hiermee is de Omgevingsbeleid component de opvolger van de GEMMA WRO-component. De Omgevingsbeleidcomponent bevat diverse functionalteiten voor omgevingswetbesluiten.
Hieronder staan de generieke requirements die voor alle omgevingsbeleidcomponenten (visie, programma en plan) gelden. De drie componenten zijn specialisaties van de Omgevingsbeleid- en regelbeheercomponent en overerven daarmee dus de generieke functies.
Kunnen onderhouden van regelingen (Omgevingsvisie, programma en omgevingsplan) conform de vigerende versie van STOP-TPOD.
Voor eisen verwijzen we in algemene zin naar de documentatie bij de standaard.
Een aantal specifieke eisen is opgenomen in de requirements.
Toelichting:
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Kunnen ophalen van regelingen (omgevingsvisie, programma, omgevingsplan) uit LVBB dan wel DSO-LV OZON conform STOP-TPOD.
Hiervoor wordt gebruikt gemaakt van de synchronisatie service van de landelijke voorziening.
Toelichting:
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Kunnen beschikbaar stellen van informatie over activiteiten (en gerelateerde informatie zoals locaties en regels) aan de toepasbare regelcomponent conform de specificaties van het koppelvlak
Toelichting:
Aangepaste requirement in versie 1.3: scherper verwoord dat het om informatie-uitwisseling gaat
Deze requirement betreft het kunnen relateren van juridische en toepasbare regels bij het bevoegd gezag zelf (vandaar 'lokaal' in de titel), bijvoorbeeld als omgevingsplan en de bijbehorende toepasbare regels nog in bewerking zijn en de wijziging van het omgevingsplan nog niet bekend is gemaakt.
Let op: Voor het 'lokaal' kunnen relateren van juridische en toepasbare regels werken leveranciers en VNG aan een uitwisselingsstandaard uit (update: augustus 2020).
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Kunnen inzien van oude, huidige en nieuwe regelingen.
Kunnen inzien van de geldende regels op een te kiezen datum
Kunnen zien van verschillen (wijzigingen) in regelingen tussen alle vorige versies van de regeling.
Toelichting:
Geupdate in versie 1.1: Van could naar must. Hiermee is OBR08 vervallen.
Geupdate in versie 1.3. Toegevoegd: Kunnen inzien van de geldende regels op een te kiezen datum.
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Kunnen ondersteunen van voorkomen van fouten door wijzigen van zelfde artikel door verschillende medewerkers van verschillende organisaties (bijvoorbeeld in geval van uitbesteding van het omgevingsplan aan een extern bureau)
Kunnen bieden van inzicht aan gebruiker van elkaars werkzaamheden.
Onder samenloop wordt de situatie verstaan waarin een tekstuele afhankelijkheid tussen twee (of meer) wetsvoorstellen (of met betrekking tot een wet die nog niet in werking is getreden) bestaat terwijl de procedures van totstandkoming in de tijd onafhankelijk van elkaar verlopen.
Toelichting:
Requirement wordt in een volgende versie verder gespecificeerd.
Aangepast in versie 1.1: van must naar "categorie onbepaald" waarmee de gemeente zelft het belang kan aangeven.
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Tijdens het opstellen de tekst en geometrie valideren op zaken als: verplichte velden ingevuld, gesloten zijn van geometrie, eventuele verplichte annotaties etc.
Kunnen bevragen van de dataset behorende bij de regeling.
Kunnen doorzoeken, selecteren, c.q. automatisch presenteren van de informatie in het omgevingsplan op basis van wat relevant is voor het gebruik op dat moment.
Toelichting:
Kunnen tonen van een locatie in combinatie met een waarde
Kunnen tonen van alle juridische regels, die voldoen aan bepaalde (zoek)criteria, op een bepaalde locatie
Aangepast in versie 1.3: Tekst aangescherpt. Van categorie "could" naar categorie "onbepaald" waarmee de gemeente zelf het belang kan aangeven.
Omschrijving: Component voor het opstellen en wijzigen van tekst in een regeling. Bedoeld voor wijzigen van omgevingsdocumenten: omgevingsvisie, programma en omgevingsplan. Deze component is onderdeel van de regelingencomponent..
Kunnen opstellen, wijzigen en intrekken (verwijderen) van regels en waarden.
Toelichting:
Onder regels wordt het volgende verstaan. In de systematiek van de toepassingsprofielen voor OW-besluiten bestaan regels uit de volgende onderdelen:
De juridische regeltekst
Juridische annotaties: de structuur van de regeling, de coördinaten die de werkingsgebieden van regels begrenzen en de waarden die de normen uit de juridische regeltekst ter plaatse van de verschillende werkingsgebieden hebben;
Service annotaties: elementen waarmee betekenis aan regeltekst en informatie-objecten wordt toegevoegd. Zij maken het OW-besluit machine-leesbaar en maken het mogelijk maken om regeltekst, werkingsgebieden en normwaarden betekenisvol en leesbaar weer te geven, waar nodig op een kaart.
Aangepast in versie 1.1: geupdate naar nieuwste versie van STOP.
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Kunnen annoteren van juridische- en beleidsregels v.w.b. tekststructuur, normwaarden, begrippen en werkingsgebieden. (In LVBB het juridisch spoor genoemd.)
Toelichting:
Onder annoteren verstaan we het toevoegen van gegevens aan (onderdelen van) besluiten en regelingen die tekst machine-leesbaar maken en/of het mogelijk maken dat bepaalde gegevens op een kaart weergegeven worden.
Deze requirement is een verdieping op OBT01.
Toevoeging versie 1.3: begrippen als te kunnen annoteren toegevoegd.
Kunnen toevoegen van metadata aan regeling zoals gedefinieerd in STOP (IMOP). Waaronder: Concept, Ontwerp, Vastgesteld, Inwerkingtreding, Onherroepelijk en ook naam.
Kunnen importeren/synchroniseren van waardelijst via DSO API.
Kunnen toepassen van waardelijsten zoals gedefinieerd binnen STOP-TPOD en voor het omgevingsplan uitgewerkt in document 17 van de standaard, bij het onderhouden van annotaties.
Toelichting:
Requirement geupdate in versie 1.3: importeren/synchroniseren van waardelijst opgenomen
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Kunnen inzien van begrippen en definities uit de DSO Stelselcatalogus tijdens het maken van een omgevingsplan
Kunnen overnemen van begrippen en definities uit de DSO Stelselcatalogus tijdens het maken van een omgevingsplan
Toelichting:
Aangepast in versie 1.1: van could naar should.
Aangepast in versie 1.3: met nieuwe werking van de DSO Stelselcatalogus de requirement smaller gemaakt naar alleen het kunnen inzien en overnemen van begrippen.
Opvoeren van nieuwe begrippen is hiermee komen te vervallen en gebeurt voortaan met de publicatie van een omgevingsplan.
Omschrijving: Component voor het karteren en wijzigen van geometrieen van regels en annotaties in omgevingsdocumenten: omgevingsvisie, programma en omgevingsplan. Deze component is onderdeel van de regelingencomponent..
OF kunnen importeren van geometrie vanuit extern bestand
OF kunnen overnemen van geometrie via GEO JSON koppeling
Toelichting:
Kunnen ophalen en overnemen van geometrie en ID uit (basis)registraties
Het kunnen ophalen van objecten en gegevens uit de Basisregistratie Grootschalige Topografie (BGT), Basisregistratie Adressen en Gebouwen (BAG) en Basisregistratie Kadaster (BRK) en gemeentelijke Kernregistraties.
Kunnen ophalen van ambtsgebied.
Kunnen ophalen van werkingsgebied (uit IMRO plan).
Let op: requirement aangepast in versie 1.2 OBG02 en OBG04 samengevoegd.
Kunnen annoteren van locatie met bijvoorbeeld bijbehorende juridische regels, waarden of activiteiten.
Toelichting:
Onder annoteren verstaan we het toevoegen van gegevens aan (onderdelen van) besluiten en regelingen die tekst machine-leesbaar maken en/of het mogelijk maken dat bepaalde gegevens op een kaart weergegeven worden.
Omschrijving: Component voor het ondersteunen van het werkproces voor het opstellen van omgevingsbeleid (visie, programma en plan). Deze component is onderdeel van Omgevingsbeleidcomponent, maar kan ook als individuele component door een organisatie worden verworven.
Kunnen interacteren met DSO-LV samenwerkingsfunctionaliteit.
Toelichting:
Nieuwe requirement in versie 1.1.
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Samenwerking op gebied van planvorming valt onder de uitbouw van DSO-LV en zal pas na 1-1 2022 worden gerealiseerd. Op dat moment zal deze requirements worden geupdate.
Kunnen bevragen en wijzigen van gegevens in de Zaakregistratiecomponent of het Zakenregister
Kunnen bevragen van gegevens in de Zaaktypecataloguscomponent of het Catalogusregister
Kunnen bewaken van de status van een zaak
Kunnen koppelen op basis van de Standaard Zaak- en Documenten Services
Kunnen koppelen op basis van de Standaard Zaakgericht Werken API (ZGW API)
Kunnen koppelen van documenten aan een Zaak in de Zaakregistratiecomponent of in het Zakenregister
Kunnen agenderen van een nieuwe (gerelateerde) zaak
Kunnen registeren van een zaak
Kunnen relateren van een zaak aan één of meer andere gerelateerde zaken
Kunnen werken op basis van de interbestuurlijke ZTC-Omgevingswet
Toelichting:
Nieuwe requirement in versie 1.3.
Status: in onderzoek bij gemeenten en leveranciers
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Omschrijving: Component voor het publiceren en archiveren van regelingen (Omgevingsvisie, programma en omgevingsplan). Deze component is onderdeel van de omgevingsbeleidcomponent, maar kan ook als individuele component door een organisatie worden verworven.
Kunnen ophalen van regelingen (omgevingsvisie, programma, omgevingsplan) uit LVBB dan wel DSO-LV OZON conform STOP-TPOD.
Hiervoor wordt gebruikt gemaakt van de synchronisatie service van de landelijke voorziening.
Toelichting:
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Kunnen detecteren van de verschillen (op basis van de STOP) tussen oude en nieuwe versies van de regeling (tekst, annotaties en geometrie ) (was-wordt).
Kunnen genereren van een was/wordt instructie welke aan het (wijzigings)besluit wordt toegevoegd.
Toelichting:
Met deze instructie wordt in de landelijke voorziening het verschil tussen de huidige en nieuwe versie duidelijk gemaakt waardoor de landelijke voorziening een geconsolideerde versie kan maken.
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Het kunnen tonen van de geconsolideerde regeling op elk moment in tijd op basis van (ontvangen) was/wordt instructies.
Toelichting:
Bijvoorbeeld nodig op het moment dat de organisatie haar omgevingsplan heeft uitbesteed aan een extern bureau. Dit bureau levert de wijzigingen in het plan terug aan de gemeente waarna de gemeente het geheel consolideerd.
Let op: wijze van gegevensuitwisseling tussen gemeente en bureau is in onderzoek (augustus 2020)
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Kunnen aanleveren van initiele versie van omgevingsvisie en programma.
Toelichting:
De eerste omgevingsvisie zal geen wijziging zijn van de huidige visie, maar een eerste versie waarna over de tijd wijziging zullen worden doorgegeven. Het is daarom van belang om de gehele eerste versie te kunnen publiceren.
Het programma zal veelal een initiele versie zijn.
Kunnen aanleveren van wijzigingsbesluit (incl. was/wordt instructies) naar de LVBB volgens STOP-TPOD om besluit beschikbaar te stellen en bekend te maken.
Kunnen gebruiken van digikoppeling (via CORV) voor aanlevering aan LVBB.
OF Kunnen archiveren van bestandenset conform STOP/TPOD inclusief benodigde procesinformatie die inzicht geeft in waarom een besluit op deze manier tot stand is gekomen.
OF Kunnen aanleveren van bestandenset conform archiefregistratiecomponent
Toelichting:
Let op: De gemeente is zelf verantwoordelijk voor het conform wettelijke normen archiveren van haar besluiten. De LVBB vervult deze functie niet.
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Kunnen importeren van wijzigingen (was/wordt) in regeling (in STOP-TPOD) via bestandsimport of via koppeling (API).
Toelichting:
Bijvoorbeeld ten behoeve van organisaties die het wijzigen van hun omgevingsplan uitbesteden.
Let op: wijze van gegevensuitwisseling tussen gemeente en bureau is in onderzoek (augustus 2020)
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Omschrijving: Component voor het weergeven van omgevingsbeleid (omgevingsplan, omgevingsvisie en programma) in tekst en kaart onder andere bedoeld voor het ondersteunen van besluitvorming. Deze component is onderdeel van omgevingsbeleidcomponent, maar kan ook als individuele component door een organisatie worden verworven.
Kunnen tonen van iedere status (concept, ontwerp, vastgesteld) van het omgevingsbeleid (omgevingsvisie, omgevingsplan, programma) op een kaart op basis van STOP-TPOD presentatieweergave;
Kunnen tonen van wijzigingen in regeling op een kaart op basis van STOP-TPOD presentatieweergave.
Toelichting:
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.
Kunnen inzien van oude, huidige en nieuwe regelingen.
Kunnen inzien van de geldende regels op een te kiezen datum.
Kunnen zien van verschillen (wijzigingen) in regelingen tussen alle vorige versies van de regeling.
Toelichting:
Zelfde requirement als OBR02, maar dan voor de viewercomponent. Hier opgenomen zodat een organisatie die haar plan uitbesteed voldoende heeft aan alleen een publicatie- en viewercomponent.
requirments geupdate in versie 1.1.
Geupdate in versie 1.3. Toegevoegd: Kunnen inzien van de geldende regels op een te kiezen datum.
Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB. Voor de realisatie van de requirement is de leverancier van de omgevingsbeleidcomponent (plansoftware) afhankelijk van deze ontwikkelingen. Het is daardoor mogelijk dat de leverancier deze requirement op dit moment nog niet (geheel) heeft kunnen realiseren.