GEMMA Online

Beste bezoeker,

op dit moment wordt er een nieuwe release doorgevoerd op GEMMA Online. Hierdoor is de omgeving tijdelijk niet beschikbaar.

Vragen? Stuur een e-mail naar gemmaonline@vng.nl

Met vriendelijke groet, Kenniscentrum Architectuur VNG Realisatie

Gemeentelijke Applicatiearchitectuur Omgevingswet

Laatst bewerkt: 11 november 2021, 21:15:05
Requirements Omgevingsbeleidscomponenten

Introductie

Op deze pagina 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. De requirements zijn bedoeld voor gemeenten die zich oriënteren op nieuwe software voor omgevingsbeleid dan wel een aanbesteding gaan doen. Ze helpen de inhoudelijk specialisten (o.a. juristen, regelanalisten en vergunningverleners), medewerkers van ICT (functioneel beheerders en informatiemanagers) en specialisten van inkoop en aanbesteding om gezamenlijk een beeld te vormen van de aan te besteden software.

Iteratief: Nu een 1.4 versie

De requirements worden met input van gemeenten en softwareleveranciers iteratief opgesteld. De onderstaande versie betreft de 1.4 versie. Dit is een stabiele versie die een gemeente kan gebruiken bij het selecteren van software voor omgevingsbeleid. 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 de standaard voor publiceren (STOP) en het Toepassingsprofiel Omgevingsdocumenten (TPOD).

Er is een releasenotes (ODS format) als download beschikbaar waarin de verschillen tussen de vorige versie en de nieuwe versie naast elkaar worden weergegeven. Tip: lees vooraf het tabblad waarop de instructies staan.

Requirements en aanbesteding

Wil een gemeente starten met een aanbesteding, 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? VNG heeft een Handreiking Aanbesteden.

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 ook 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 leveranciersvragen biedt VNG aan gemeenten een uniforme manier van uitvragen van de software voor toepasbare regels. Een uniforme manier van uitvragen is essentieel om komende periode van implementatie succesvol te laten verlopen. Softwareleveranciers staan al onder druk om op 1 juli 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.

Categorieën voor requirements

We hanteren de volgende categorieën voor de requirements, die meer in lijn liggen met de ‘Minimale acties Omgevingswet’. De requirements zijn onderverdeeld in drie categorieën:

  • 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’.


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’. Ga na welke softwarerequirement voor u van toepassing is en ga na of de hier aangegeven categorie ook bij u van toepassing is.

Voor requirements waarvoor de specificaties vanuit DSO-LV nog niet beschikbaar zijn hanteren we de categorie "Nader te bepalen". Zodra de specificaties voldoende stabiel zijn zullen we de juiste categorie aangeven. Requirements die niet meer gelden, zijn uit de lijst weggehaald. In de Releasenotes die horen bij deze versie is terug te vinden welke requirements nieuw zijn, welke requirements zijn aangepast en welke requirements zijn vervallen.

Doorontwikkeling applicaties: Na de inwerkingtreding van de Omgevingswet zal de software voor omgevingsbeleid 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.

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.

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 (voorbereidingsbesluiten). (ApplicationComponent) Omgevingsbeleidcomponent Component voor het opstellen van regelingen met tekst, werkingsgebied en annotaties. Onderdeel van Omgevingsbeleidcomponent (ApplicationComponent) Regelingcomponent 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.. (ApplicationComponent) Geometriecomponent 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.. (ApplicationComponent) Tekst-en- annotatiecomponent 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. (ApplicationComponent) Werkprocescomponent 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. (ApplicationComponent) Publicatiecomponent 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. (ApplicationComponent) Viewercomponent Deze svg is op 11-11-2021 21:15:02 CET gegenereerd door ArchiMedes™ © 2016-2021 ArchiXL. ArchiMedes 11-11-2021 21:15:02 CET


Overzicht Omgevingsbeleidcomponenten (uit model: Omgevingswet) - Toon SVG


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 uitbesteedt, zal vermoedelijk voldoende hebben aan de publicatie- en viewer component. Waarbij een gemeente die haar plannen zelf maakt, de gehele omgevingsbeleidcomponent zal gebruiken.

Onderstaande geeft een overzicht van de component. Van iedere component kunnen de requirements als CSV worden gedownload.

Omgevingsbeleidcomponent (download als CSV) waarbinnen vallen de:

De requirements

Onderstaande tabellen tonen de requirements per (sub-)component. We starten met de hoofdcomponent, de omgevingsbeleidcomponent.

Omgevingsbeleidcomponent

Omschrijving: 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 (voorbereidingsbesluiten)., 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 Omgevingsbeleidcomponent en overerven daarmee dus de generieke functies.

Functionele requirements
Aantal: 4
Requirement Toelichting Categorie
OB02 Component kent een modulaire opzet Toelichting modulaire opzet:
  • Iedere subcomponent is of een module binnen een grotere softwaresuite of een apart aan te schaffen applicatie.
  • De gemeente kan kiezen welke module(s) ze aanschaft.
  • Daarbij zijn de volgende combinaties mogelijk:
  • viewercomponent
  • viewer- en publicatiecomponent
  • viewer-, publicatie- en maakcomponent
  • viewer-, publicatie-, maak- en werkprocescomponent
  • Nieuwe requirement in versie 1.3


 Must
OB03 Kunnen onderhouden van regelingen conform STOP-TPOD - Release A Releases worden volgens Parallele Versionering uitgebracht. De specificatie van STOP-TPOD - Release A is te vinden via

Toelichting:

  • Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB waardoor de specificaties van de release nog kunnen wijzigen tot de datum van inwerkingtreding.
  • Nieuw requirement in versie 1.4


 Must
OB04 Kunnen onderhouden van regelingen conform STOP-TPOD - Release B Releases worden volgens Parallele Versionering uitgebracht. De specificatie van STOP-TPOD - Release B is te vinden via

Toelichting:

  • Let op: deze requirement heeft een sterke relatie met de ontwikkelingen binnen DSO-LV en LVBB waardoor de specificaties van de release nog kunnen wijzigen tot de datum van inwerkingtreding.
  • Nieuw requirement in versie 1.4


 Should
OB05 Kunnen borgen van duurzame toegankelijkheid Hieronder wordt verstaan:
  • Kunnen borgen van duurzame toegankelijkheid van informatie over de procesgang
  • Kunnen borgen van duurzame toegankelijkheid van de regelingen

Toelichting: De regelingen worden conform STOP/TPOD duurzaam toegankelijk ontsloten

  • Nieuw requirement in versie 1.4


 Must
  • Download als CSV


Regelingcomponent

Omschrijving: Component voor het opstellen van regelingen met tekst, werkingsgebied en annotaties. Onderdeel van Omgevingsbeleidcomponent

Functionele requirements
Aantal: 12
Requirement Toelichting Categorie
OBR01 Kunnen beschikbaar stellen van informatie over activiteiten aan de toepasbare regel component (lokaal) Hieronder wordt verstaan:
  • Kunnen beschikbaar stellen van informatie over activiteiten (en gerelateerde informatie zoals locaties en regels) aan de toepasbare regelcomponent conform de specificaties van de API Regels bij activiteiten zoals gepubliceerd op https://github.com/VNG-Realisatie/Regels-bij-activiteiten.

Toelichting:

  • Aangepaste requirement in versie 1.4: API verwijzing opgenomen
  • Aangepaste requirement in versie 1.3: scherper verwoord dat het om informatie-uitwisseling gaat


 Onbepaald
OBR02 Kunnen tijdreizen in regelingversies Hieronder wordt verstaan:
  • Kunnen inzien van oude, huidige en nieuwe regelingversies.
  • 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.
  • Tekst in toelichting aangepast in versie 1.4


 Must
OBR04a Kunnen ondersteunen van tegelijk werken aan (lopende) regeling Hieronder wordt verstaan:
  • Kunnen ondersteunen van voorkomen van fouten door wijzigen van zelfde artikel door verschillende medewerkers (interne samenloop).
  • Kunnen bieden van inzicht aan gebruiker van elkaars werkzaamheden.
  • Kunnen samenvoegen van wijzigingen.

Toelichting:

  • Requirement geupdate in versie 1.2: van should naar must
  • Tekst aangepast in versie 1.4. Was: Kunnen ondersteunen van tegelijk werken aan plan binnen organisatie. Is geworden: Kunnen ondersteunen van tegelijk werken aan (lopende) regeling.


 Must
OBR04b Kunnen ondersteunen van tegelijk werken aan (lopende) regeling tussen organisaties Hieronder wordt verstaan:
  • Kunnen bieden van inzicht aan gebruikers van de delen van de regeling waaraan gewerkt wordt.

Toelichting:

  • Het betreft het vastleggen van de afspraken tussen organisaties over welke onderdelen van de regeling bij wie onderhanden zijn.
  • Requirement geupdate in versie 1.2.
  • Tekst aangepast in versie 1.4. Was: Kunnen ondersteunen van tegelijk werken aan plan binnen organisatie. Is geworden: Kunnen ondersteunen van tegelijk werken aan (lopende) regeling tussen organsiaties.


 Onbepaald
OBR05 Kunnen ondersteunen bij samenloop Hieronder wordt verstaan:
  • 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.


 Onbepaald
OBR06 Kunnen bieden van kwaliteitsbewaking Hieronder wordt verstaan:
  • Tijdens het opstellen de tekst en geometrie valideren op zaken als: verplichte velden ingevuld, gesloten zijn van geometrie, eventuele verplichte annotaties etc.
  • Gebruik van validatiesregels conform standaard STOP-TPOD Release A zoals gepubliceerd op de website van Geonovum: https://www.geonovum.nl/geo-standaarden/omgevingswet/STOPTPOD
  • Toelichting aangepast in versie 1.4


 Must
OBR07 Kunnen bieden van inzicht in inhoud van regeling Hieronder verstaan we:
  • 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.


 Onbepaald
OBR09 Kunnen leggen van relatie tussen regelingen Hieronder wordt verstaan:
  • Kunnen vastleggen van de relatie tussen de regels in het omgevingsplan en tekst uit programma of visie.

Toelichting

  • Intern kunnen toetsen van de impact van de samenhang van de regels tussen deze onderdelen (visie, programma, plan, voorbereidingsbesluit).
  • Aangepast in versie 1.1: van could naar "categorie onbepaald" waarmee de gemeente zelft het belang kan aangeven.
  • Aangepast in versie 1.4: Was: Kunnen leggen van relatie tussen eigen omgevingsdocument en ander omgevingsdocument. Wordt: Kunnnen leggen van relatie tussen regelingen.


 Onbepaald
OBR10 Kunnen verwerken van een aangeboden regelingversie Hieronder wordt verstaan:
  • Kunnen overnemen, in de lopende regelingversie, van wijzigingen in een (door bijvoorbeeld een stedebouwkundig adviesbureau), in STOP/TPOD, aangeboden regeling door organisaties die het maken van hun omgevingsplan uitbesteden.
  • Kunnen ondersteunen van het voorkomen van fouten door wijzigingen, in de aangeboden regelingversie, die conflicteren met de lopende regelingversie.
  • Nieuw requirement in versie 1.4, betreft de zgn. plan-plan-koppeling.


 Must
OBR11 Kunnen ophalen van geconsolieerde regeling uit het bronhouderkoppelvlak van de LVBB Hieronder wordt verstaan:
  • Kunnen ophalen en verwerken van regelingen (omgevingsvisie, programma, omgevingsplan, voorbereidingsbesluit) conform STOP-TPOD.
  • Het gaat om het 'downloaden' voor een aantal uitzonderlijke gevallen:
    • ten einde uitvalsituaties te voorkomen,
    • gebieds- of themagewijs het omgevingsplan door stedenbouwkundige bureaus te laten wijzigen,
    • als 'backup' bij wijziging van softwareleverancier.
  • Deze 'downloadfunctie' is beschikbaar als service op het Bronhouderkoppelvlak van de LVBB.
  • Nieuw requirement in versie 1.4


 Must
OBR12 Kunnen valideren van regelingversie op consistentie van de structuur Hieronder wordt verstaan:
  • Het valideren tegen de landelijke validatieservice via het Stelselknooppunt
  • Het valideren van regelingversies op consistentie van de structuur
  • Het kunnen verstrekken van een validatieopdracht
  • Het kunnen ophalen van een validatierapport
  • Nieuw requirement in versie 1.4


 Should
OBR13 Kunnen aanbieden van een regelingversie aan een andere organisatie (waaronder een gemeente). Hieronder wordt verstaan:
  • Kunnen genereren van een regeling met wijzigingen, op een eerder gepubliceerde versie van die regeling, door bijvoorbeeld een stedebouwkundig adviesbureau ten behoeve van organisaties die het maken van hun omgevingsplan uitbesteden.

Toelichting:

  • Nieuw requirement in versie 1.4, betreft de zgn. plan-plan-koppeling.
  • De gebruikte gepubliceerde versie van die regeling is de geconsolideerde versie die op het moment van starten van het wijzigen opgehaald is uit de LVBB. Bij het aanbieden van de regeling met wijzigingen kan de geconsolideerde regeling in de LVBB inmiddels aangepast zijn.
  • Een MUST voor stedebouwkunige bureaus.


 Onbepaald
  • Download als CSV


Tekst-en-annotatiecomponent

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..

Functionele requirements
Aantal: 5
Requirement Toelichting Categorie
OBT01 Kunnen opstellen, wijzigen en intrekken van juridische regels en waarden Hieronder wordt verstaan:
  • Kunnen toepassen van de mutatiescenario's zoals genoemd in de standaard STOP-TPOD - release A

Toelichting:

  • Tekst aangepast in versie 1.4


 Must
OBT05 Kunnen leggen van een relatie met geometrie Hieronder wordt verstaan:
  • kunnen leggen van relatie van tekst naar geometrie via het geometriecomponent of zoals is overgenomen uit een ander geometrische bron.
  • De relatie met de andere geometrische bron is duurzaam vastgelegd en herleidbaar.

Toelichting:

  • Toelichting aangepast in versie 1.4


 Must
OBT08 Kunnen navigeren in tekst Hieronder wordt verstaan:
  • Op een vlotte manier kunnen navigeren door regels. Bijvoorbeeld door een navigatie menu met artikelen.

Toelichting:

  • Nieuwe requirement in versie 1.1.


 Should
OBT09 Kunnen afnemen van (meta)gegevens uit de Stelselcatalogus Hieronder wordt verstaan:
  • Kunnen toepassen van (meta)gegevens tijdens het opstellen, wijzigen en annoteren van juridische regels van een omgevingsbeleiddocument
  • Het toepassen omvat het zoeken, het overnemen van de verwijzing, en visualiseren van de functionele structuur in relatie tot beoogde annotaties van juridische regels.

Toelichting:

  • Het gaat om de toepassing van verwijzingen naar concepten, juridische termen en objecten (waaronder waardenlijsten) in een omgevingsbeleidsdocument
  • De (meta)gegevens worden verkregen door het aanroepen van de DSO-LV Stelselcatalogus API 'Catalogus opvragen'
  • Nieuw requirement in versie 1.4


 Must
OBT10 Kunnen annoteren van juridische regels Hieronder wordt verstaan:
  • Het kunnen uitvoeren van regeling- en besluitsannotaties, bijvoorbeeld de naam van het bevoegd gezag dat het omgevingsplan heeft vastgesteld en de datum waarop de versie van het omgevingsplan is gepubliceerd
  • het kunnen uitvoeren van tekststructuurannotaties, bijvoorbeeld het nummer en de

titel van het structuurdeel (hoofdstukken, afdelingen en paragrafen)

  • het kunnen uitvoeren van artikelen-, leden- en regeltekstannotaties, bijvoorbeeld het

nummer en de titel van het artikel, het lidnummer en inhoudelijke annotaties van de tekst van artikel en lid, zoals werkingsgebied

  • het kunnen annoteren van inhoudelijke regeltekstannotaties, bijvoorbeeld activiteit, norm, normwaarde, lokatie, gebiedsaanwijzing, thema, regeltype, idealisatie en activitietkwalificatie.

Toelichting:

  • Onder annoteren wordt verstaan het toevoegen van gegevens aan (onderdelen van) besluiten en regelingen, gegevens die die besluiten en regelingen machineleesbaar maken.
  • Annoteren is afgebakend tot de kenmerken genoemd in het Informatiemodel Officiële Publicaties (IMOP) en in het Informatiemodel Omgevingswet (IMOW).
  • Het annoteren is toegelicht in de VNG handreiking Annoteren Omgevingsplan (https://vng.nl/sites/default/files/2021-06/2021-03-vng-handreiking-annoteren-omgevingsplan-v4.pdf).
  • Nieuw requirement in versie 1.4


 Must
  • Download als CSV


Geometriecomponent

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..

Functionele requirements
Aantal: 4
Requirement Toelichting Categorie
OBG01 Kunnen onderhouden van geometrie Hieronder wordt verstaan:
  • Kunnen karteren van een geometrie.
  • Kunnen aanpassen van geometrie.

Toelichting:

  • De geometrie wordt toegepast bij annoteren van de juridisch regels
  • Aangepaste requirement in versie 1.1
  • Requirement aangepast in versie 1.4 van 'karteren en wijzigen' naar 'onderhouden' en tekst in toelichting toegevoegd


 Must
OBG02 Kunnen importeren van geometrie Hieronder wordt verstaan:
  • Het kunnen ophalen van geometrie 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 geldende regeling.
  • Let op: Toelichting in versie 1.4 aangepast


 Must
OBG05 Kunnen ondersteunen van 3D Hieronder wordt verstaan:
  • Kunnen ondersteunen van 3D.

Toelichting:

  • Aangepast in versie 1.1: van could naar "categorie onbepaald" waarmee de gemeente zelft het belang kan aangeven.


 Onbepaald
OBG06 Kunnen annoteren vanuit geometrie Hieronder wordt verstaan:
  • Kunnen annoteren van locatie met bijvoorbeeld bijbehorende juridische regels, waarden of activiteiten.

Toelichting:

  • Onder annoteren wordt verstaan het toevoegen van gegevens aan (onderdelen van) besluiten en regelingen, gegevens die die besluiten en regelingen machineleesbaar maken.
  • Annoteren is afgebakend tot de kenmerken genoemd in het Informatiemodel Officiële Publicaties (IMOP) en in het Informatiemodel Omgevingswet (IMOW).
  • Het annoteren is toegelicht in de VNG handreiking Annoteren Omgevingsplan (https://vng.nl/sites/default/files/2021-06/2021-03-vng-handreiking-annoteren-omgevingsplan-v4.pdf).
  • Let op: Requirement toegevoegd in versie 1.2.
  • Tekst aangepast in versie 1.4


 Onbepaald
  • Download als CSV


Werkprocescomponent

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.

Functionele requirements
Aantal: 4
Requirement Toelichting Categorie
OBWP01 Kunnen besturen van gehele werkproces Kunnen besturen van werkproces voor het opstellen van omgevingsdocumenten (visie, progamma, plan, voorbereidingsbesluit).

Toelichting: Denk hierbij aan de volgende functionaliteiten:

  • Kunnen monitoren van statussen
  • Kunnen instellen en bijhouden van doorlooptijden gedurende het wijzigingsproces
  • Kunnen doen van termijnbewaking zoals gedefinieerd volgens de wet
  • Kunnen doen van termijnbewaking conform eigen service termijn
  • Kunnen ondersteunen van separate processen voor verschillende tegelijkertijd onderhanden wijzigingen
  • Aangepast in versie 1.1: van could naar "categorie onbepaald" waarmee de gemeente zelft het belang kan aangeven.
  • Tekst in toelichting aangepast in versie 1.4


 Onbepaald
OBWP05 Kunnen ondersteunen van samenwerking Hieronder wordt verstaan:
  • Kunnen interacteren met DSO-LV samenwerkingsfunctionaliteit.

Toelichting:

  • Nieuwe requirement in versie 1.1.
  • Samenwerking op gebied van planvorming valt onder de uitbouw van DSO-LV en zal pas na 1-7-2022 worden gerealiseerd. Op dat moment zal deze requirements worden geupdate.


 Onbepaald
OBWP06 Werkproces kunnen aanpassen Hieronder wordt verstaan:
  • Kunnen aanpassen van het werkproces.
  • Nieuwe requirement in versie 1.2


 Onbepaald
OBWP07 Zaakgericht kunnen uitvoeren van het proces voor het wijzigen van het omgevingsplan Hieronder wordt verstaan:
  • Het zaakgericht kunnen verwerken van buitenplanse omgevingsplanactiviteiten (BOPA)
  • Het zaakgericht kunnen verwerken van nieuwe initiatieven
  • Het zaakgericht kunnen verwerken van aanpassingen n.a.v. bezwaar of beroep
  • Het zaakgericht kunnen verwerken van aanwijzingen, instructies en projectbesluiten

Toelichting:

  • Aangepaste toelichting in versie 1.4
  • Nieuwe requirement in versie 1.3.
  • Status: in onderzoek bij gemeenten en leveranciers


 Onbepaald
  • Download als CSV


Publicatiecomponent

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.

Functionele requirements
Aantal: 2
Requirement Toelichting Categorie
OBP01 Kunnen genereren van was/wordt instructies ten behoeve publicatie Hieronder wordt verstaan:
  • Kunnen detecteren van de verschillen (op basis van de STOP-TPOD) tussen oude en nieuwe versies van de lopende regeling (tekst, annotaties en geometrie) (was-wordt).
  • Kunnen genereren van een was/wordt instructie welke aan het wijzigingsbesluit 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.
  • Was: Kunnen genereren van was/wordt instructies. Is in versie 1.4 geworden: Kunnen genereren van was/wordt instructies ten behoeve publicatie
  • Tekst in toelichting aangepast in versie 1.4


 Must
OBP05 Kunnen valideren van wijzigingsbesluit ten behoeve van publicatie Hieronder wordt verstaan:
  • Kunnen valideren van wijzigingsbesluit via het LVBB Bronhouderkoppelvlak aan de vereisten uit STOP-TPOD release A.

Toelichting:

  • Tekst aangepast in versie 1.3. Was kunnen valideren van besluit. Is geworden: kunnen valideren van regeling.
  • Tekst aangepast in versie 1.4. Was kunnen valideren van regeling. Is geworden: Kunnen valideren van wijzigingsbesluit ten behoeve van publicatie


 Must
  • Download als CSV


Viewercomponent

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.

Functionele requirements
Aantal: 4
Requirement Toelichting Categorie
OBV01 Kunnen tonen van regelingen en wijzigingen op een kaart Hieronder wordt verstaan:
  • Kunnen tonen van iedere status (concept, ontwerp, vastgesteld) van de regeling (omgevingsvisie, omgevingsplan, programma, voorbereindingsbesluit) op een kaart op basis van STOP-TPOD presentatiemodel;
  • Kunnen tonen van wijzigingen in regeling op een kaart op basis van STOP-TPOD presentatiemodel.

Toelichting:

  • Tekst aangepast in versie 1.4
  • Requirementnaam aangepast van 'omgevingsbeleid' naar 'regelingen en wijzigingen' in versie 1.4


 Must
OBV02 Kunnen tonen van regelingen en wijzigingen als tekst Hieronder wordt verstaan:
  • Kunnen tonen van iedere status (concept, ontwerp, vastgesteld) van de regeling (omgevingsvisie, omgevingsplan, programma, voorbereindingsbesluit) als tekst op basis van STOP-TPOD presentatiemodel;
  • Kunnen tonen van wijzigingen in regeling als tekst op basis van STOP-TPOD presentatiemodel.

Toelichting:

  • Tekst aangepast in versie 1.4
  • Requirementnaam aangepast van 'omgevingsbeleid' naar 'regelingen en wijzigingen' in versie 1.4


 Must
OBV03 Kunnen tijdreizen in regeling Hieronder wordt verstaan:
  • 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 regelingcomponent, 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.


 Must
OBV04 Kunnen plaatsen van opmerkingen bij tekst dan wel kaart Hieronder wordt verstaan:
  • Kunnen plaatsen van opmerkingen bij tekst of kaart welke door andere gebruikers kan worden gezien.

Toelichting:

  • Aangepast in versie 1.1: van could naar "categorie onbepaald" waarmee de gemeente zelft het belang kan aangeven.


 Onbepaald
  • Download als CSV



Overgenomen van "https://www.gemmaonline.nl/index.php?title=GAO_-_Omgevingsbeleidscomponenten&oldid=824195"