(3 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 1:
Regel 1:
{{Cocreatie
{{Publicatie
|Cocreatiepublicatie=Cocreatie
|Paginastatus=publiceren
|Redactiestatus=Actueel
|Redactiestatus=Actueel
|GEMMAOnlinebeheerder=Beheerder Omgevingswet
|Wikibeheerder=Beheerder Omgevingswet
}}
}}
[[Category:Omgevingswet]]
{{RapportInhoud|Pagina={{PAGENAME}}}} __NOTOC__
{{RapportInhoud|Pagina={{PAGENAME}}}} __NOTOC__
===Introductie===
===Introductie===
'''Op deze pagina bieden we in tabelvorm en ter download de requirements (specificaties) aan voor de omgevingsbeleidsoftware per 2023. 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.'''
'''Op deze pagina bieden we in tabelvorm en ter download de requirements (specificaties) aan voor de omgevingsbeleidsoftware per 2024. 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.'''
Regel 54:
Regel 55:
<br>
<br>
{{ToonView
{{ToonViewGEMMA
|viewid=57d11f8b-4f3a-4faf-9850-7b7b134469a0
|viewid=57d11f8b-4f3a-4faf-9850-7b7b134469a0
|modelid=589f8860-a772-46f4-8c50-03980a8f0295
|modelid=589f8860-a772-46f4-8c50-03980a8f0295
Regel 66:
Regel 67:
Onderstaande tabellen tonen de requirements per applicatiefunctie.
Onderstaande tabellen tonen de requirements per applicatiefunctie.
{{ToonView
{{ToonViewGEMMA
|viewid=8d6336b8-ec1a-46b3-996e-f7c4ec9261ee
|viewid=8d6336b8-ec1a-46b3-996e-f7c4ec9261ee
|modelid=589f8860-a772-46f4-8c50-03980a8f0295
|modelid=589f8860-a772-46f4-8c50-03980a8f0295
Regel 73:
Regel 74:
De opgenomen requirements kunnen per applicatiefunctie als CSV bestand worden gedownload. Deze bestanden kunt u gebruiken bij het opstellen van een Programma van Eisen.
De opgenomen requirements kunnen per applicatiefunctie als CSV bestand worden gedownload. Deze bestanden kunt u gebruiken bij het opstellen van een Programma van Eisen.
*{{ToonLinkNaarElementID|id=743e0b6f-1f3d-4a6e-9cd1-16802e238d1b|modelid=589f8860-a772-46f4-8c50-03980a8f0295|toonals=Ondersteunen van generieke OB-functionaliteit}} (download als {{Download als CSV|id=743e0b6f-1f3d-4a6e-9cd1-16802e238d1b}})
*{{ToonLinkNaarElementGEMMA|id=743e0b6f-1f3d-4a6e-9cd1-16802e238d1b|modelid=589f8860-a772-46f4-8c50-03980a8f0295|toonals=Ondersteunen van generieke OB-functionaliteit}} (download als {{Download als CSV|id=743e0b6f-1f3d-4a6e-9cd1-16802e238d1b}})
*{{ToonLinkNaarElementID|id=8d83f048-82df-4bd9-8b80-436719291cf6|modelid=589f8860-a772-46f4-8c50-03980a8f0295|toonals=Beheren van regelingen}} (download als {{Download als CSV|id=8d83f048-82df-4bd9-8b80-436719291cf6}})
*{{ToonLinkNaarElementGEMMA|id=8d83f048-82df-4bd9-8b80-436719291cf6|modelid=589f8860-a772-46f4-8c50-03980a8f0295|toonals=Beheren van regelingen}} (download als {{Download als CSV|id=8d83f048-82df-4bd9-8b80-436719291cf6}})
*{{ToonLinkNaarElementID|id=f9dd8671-f11d-4f49-ba1b-5a0ab26b92c0|modelid=589f8860-a772-46f4-8c50-03980a8f0295|toonals=Aanleveren van besluiten en documenten}} (download als {{Download als CSV|id=f9dd8671-f11d-4f49-ba1b-5a0ab26b92c0}})
*{{ToonLinkNaarElementGEMMA|id=f9dd8671-f11d-4f49-ba1b-5a0ab26b92c0|modelid=589f8860-a772-46f4-8c50-03980a8f0295|toonals=Aanleveren van besluiten en documenten}} (download als {{Download als CSV|id=f9dd8671-f11d-4f49-ba1b-5a0ab26b92c0}})
*{{ToonLinkNaarElementID|id=66262b32-6ee0-4dfb-826b-2d76544085d4|modelid=589f8860-a772-46f4-8c50-03980a8f0295|toonals=Inzien van regelingen}} (download als {{Download als CSV|id=66262b32-6ee0-4dfb-826b-2d76544085d4}})
*{{ToonLinkNaarElementGEMMA|id=66262b32-6ee0-4dfb-826b-2d76544085d4|modelid=589f8860-a772-46f4-8c50-03980a8f0295|toonals=Inzien van regelingen}} (download als {{Download als CSV|id=66262b32-6ee0-4dfb-826b-2d76544085d4}})
*{{ToonLinkNaarElementID|id=f36a136f-a4d3-43e3-932a-97fcdeeb4d37|modelid=589f8860-a772-46f4-8c50-03980a8f0295|toonals=Samenwerken aan besluiten}} (download als {{Download als CSV|id=f36a136f-a4d3-43e3-932a-97fcdeeb4d37}})
*{{ToonLinkNaarElementGEMMA|id=f36a136f-a4d3-43e3-932a-97fcdeeb4d37|modelid=589f8860-a772-46f4-8c50-03980a8f0295|toonals=Samenwerken aan besluiten}} (download als {{Download als CSV|id=f36a136f-a4d3-43e3-932a-97fcdeeb4d37}})
Op deze pagina bieden we in tabelvorm en ter download de requirements (specificaties) aan voor de omgevingsbeleidsoftware per 2024. 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.5.1 versie
De requirements worden met input van gemeenten en softwareleveranciers iteratief opgesteld. De onderstaande versie betreft de 1.5.1 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).
Per versie worden er releasenotes als ODS-bestand ter download beschikbaar gesteld, waarin de verschillen tussen de vorige versie en de nieuwe versie naast elkaar worden weergegeven. Lees vooraf het tabblad waarop de instructies staan.
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 in 2023 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.
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 Omgevingsbeleidcomponent
De Omgevingsbeleidcomponent bevat applicatiefuncties die benodigd zijn voor het opstellen van beleid voor de Omgevingswet. Denk hierbij aan het wijzigen van het omgevingsplan of het maken van een omgevingsvisie.
Modulaire opzet: De omgevingsbeleidcomponent bestaat uit een component met functies gericht op omgevingsbeleid en een component gericht op viewer functionaliteit. De viewercomponent kan onderdeel zijn van de omgevingsbeleidcomponent, maar kan ook als los component ingezet worden. Het is aan de gemeente om te kiezen op welke manier zij de componenten willen aanschaffen.
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 viewercomponent. Waarbij een gemeente die haar plannen zelf maakt, de gehele omgevingsbeleidcomponent en mogelijk ook de viewercomponent zal gebruiken.
De requirements per applicatiefunctie
Onderstaande tabellen tonen de requirements per applicatiefunctie.
De opgenomen requirements kunnen per applicatiefunctie als CSV bestand worden gedownload. Deze bestanden kunt u gebruiken bij het opstellen van een Programma van Eisen.
In onderstaande tabellen wordt onderscheid gemaakt in welke requirements verplicht zijn bij de inwerkingtreding (MUST), welk requirements door VNG worden geadviseerd (SHOULD) en welke requirements aanvullende functionaliteit bieden (ONBEPAALD).
Requirements met categorie MUST
Onderstaande tabel toont alle requirements die gelden voor de Omgevingsbeleidcomponent met de categorie MUST. De Omgevingsbeleidcomponent moet bij de inwerkingtreding van de Omgevingswet voldoen aan onderstaande requirements.
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.
Het opnemen van een instructie ten behoeve van de 'pons' valt ook onder Release A.
Het kunnen ophalen van geometrie uit de Basisregistratie Grootschalige Topografie (BGT), Basisregistratie Adressen en Gebouwen (BAG) en Basisregistratie Kadaster (BRK) en gemeentelijke Kernregistraties.
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.
Wijzigingen kunnen geselecteerd worden tot één wijzigingsbesluit.
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.
De was/wordt instructie wordt gebruikt ten behoeve van de aanlevering aan de raad en college en aan de landelijke voorziening.
Aangepast in versie 1.5: toevoeging 'ten behoeve van publicatie' verwijderd.
Aangepast in versie 1.4.1: In requirementnaam ‘van’ toegevoegd
Was: Kunnen genereren van was/wordt instructies. Is in versie 1.4 geworden: Kunnen genereren van was/wordt instructies ten behoeve publicatie
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.
Requirementnaam aangepast in versie 1.5: Was: Kunnen valideren van wijzigingsbesluit ten behoeve van publicatie. Is geworden: Kunnen valideren ten behoeve van aanlevering
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.
Kunnen overnemen, in de lopende regelingversie, van wijzigingen in een (door bijvoorbeeld een stedenbouwkundig 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.
Aangepast in versie 1.4.1: Typefouten uit toelichting verwijderd
Nieuw requirement in versie 1.4, heeft betrekking op de zgn. plan-plan-keten
Het kunnen uitvoeren van regeling- en besluitannotaties, 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, locatie, gebiedsaanwijzing, thema, regeltype, idealisatie en activiteitkwalificatie.
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).
Kunnen tonen van iedere status (concept, ontwerp, vastgesteld) van de regeling (omgevingsvisie, omgevingsplan, programma, voorbereidingsbesluit) op een kaart op basis van STOP-TPOD presentatiemodel;
Kunnen tonen van wijzigingen in regeling op een kaart op basis van STOP-TPOD presentatiemodel.
Kunnen tonen van wijzigingen voor één wijzigingsbesluit op basis van STOP-TPOD presentatiemodel.
Toelichting:
Toelichting aangepast in versie 1.5
Aangepast in versie 1.4.1: Typefoutren uit toelichting verwijderd
Tekst aangepast in versie 1.4
Requirementnaam aangepast van 'omgevingsbeleid' naar 'regelingen en wijzigingen' in versie 1.4
Kunnen tonen van iedere status (concept, ontwerp, vastgesteld) van de regeling (omgevingsvisie, omgevingsplan, programma, voorbereidingsbesluit) 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
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.
Kunnen ondersteunen van separate processen voor verschillende tegelijkertijd onderhanden wijzigingen in omgevingsdocumenten (visie, progamma, plan, voorbereidingsbesluit)
Toelichting:
Denk hierbij aan de volgende functionaliteiten:
Kunnen ondersteunen van separate processen voor verschillende tegelijkertijd onderhanden wijzigingen
Aangepast in versie 1.5: Nieuw requirement n.a.v. de functionele set
Must
Requirements met categorie SHOULD
Onderstaande tabel toont alle requirements die gelden voor de Omgevingsbeleidcomponent met de categorie SHOULD. VNG hecht grote waarde aan het voldoen van de Omgevingsbeleidcomponent aan onderstaande requirements, maar deze requirements zijn niet verplicht tijdens de inwerkingtreding van de Omgevingswet. Als gemeente kunt u deze requirements uitvragen aan een leverancier als toevoeging op uw Programma van Eisen (PvE). Mogelijk dat een leverancier deze requirements nog niet heeft gerealiseerd in zijn oplossing.
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.
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:
Aangepast in versie 1.4.1: Categorie aangepast van Onbepaald naar Should ivm standaardisatie API door VNG
Aangepaste requirement in versie 1.4: API verwijzing opgenomen
Aangepaste requirement in versie 1.3: scherper verwoord dat het om informatie-uitwisseling gaat
Tijdens het opstellen de tekst en geometrie valideren op zaken als: verplichte velden ingevuld, gesloten zijn van geometrie, eventuele verplichte annotaties etc.
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'
Aangepast in versie 1.5: Categorie van MUST naar SHOULD
Nieuw requirement in versie 1.4
Should
Requirements met categorie ONBEPAALD
Onderstaande tabel toont alle requirements die gelden voor de Omgevingsbeleidcomponent met de categorie ONBEPAALD. VNG onderkent een aantal requirements die op dit moment van toepassing kunnen zijn op de Omgevingsbeleidcomponent. VNG heeft hier echter geen waarde aan toegekend. Als gemeente kunt u eventueel deze requirements uitvragen aan een leverancier als toevoeging op uw Programma van Eisen (PvE). Bepaal dan wel vooraf de categorie die u hieraan zelf toekent: MUST of SHOULD. Mogelijk dat een leverancier deze requirements nog niet heeft gerealiseerd in zijn oplossing.
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).
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.
Aangepast in versie 1.4.1: Tekstuele aanpassing in toelichting van 1.4
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 organisaties.
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.5: Toelichting aangepast
Aangepoast in versie 1.4.1: Typefouten uit toelichting verwijderd
Aangepast in versie 1.3: Tekst aangescherpt. Van categorie "could" naar categorie "onbepaald" waarmee de gemeente zelf het belang kan aangeven.
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.4.1: Typefouten uit toelichting verwijderd
Aangepast in versie 1.4: Was: Kunnen leggen van relatie tussen eigen omgevingsdocument en ander omgevingsdocument. Wordt: Kunnen leggen van relatie tussen regelingen.
Aangepast in versie 1.1: van could naar "categorie onbepaald" waarmee de gemeente zelf het belang kan aangeven.
Kunnen genereren van een regeling met wijzigingen, op een eerder gepubliceerde versie van die regeling, door bijvoorbeeld een stedenbouwkundig adviesbureau ten behoeve van organisaties die het maken van hun omgevingsplan uitbesteden.
Toelichting:
Het gegenereerde bestand is conform het uitwisselpakket zoals dat beschreven is op de website van KOOP.
Aangepast in versie 1.5: Exportformaat opgenomen in toelichting
Aangepast in versie 1.4.1: Typefoutren uit toelichting verwijderd
Nieuw requirement in versie 1.4, heeft betrekking op de zgn. plan-plan-keten.
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.
Het kunnen ondersteunen van integraal/samenhangend werken voor het samenbrengen van diverse activiteiten en thema's in de lopende regeling binnen de eigen organisatie.
Toelichting:
Aangepaste toelichting in versie 1.4
Deze requirement heeft geen relatie met Zaakgericht werken.
Een systeem waarbinnen organisaties via afspraken, standaarden en/of voorzieningen samenwerken om bepaalde functionaliteit te realiseren.
Een document met erkende afspraken, specificaties of criteria over een product, een dienst of een methode.
Een eis die geldt voor een specifiek informatiesysteem of onderdeel daarvan binnen de architectuur.
Betekenisvolle gegevens.
Een eis die geldt voor een specifiek informatiesysteem of onderdeel daarvan binnen de architectuur.
Een door de overheid officieel aangewezen registratie met daarin gegevens van hoogwaardige kwaliteit, die door alle overheidsinstellingen verplicht en zonder nader onderzoek, worden gebruikt bij de uitvoering van publiekrechtelijke taken.
Groepering van services die aan afnemers worden aangeboden, met als doel het bevorderen van uniformiteit en efficiëntie binnen de overheid.
Iedere persoon, organisatie of functionele eenheid die gebruik maakt van een informatiesysteem.
Een afgebakende prestatie van een persoon of organisatie (de dienstverlener), die voorziet in een behoefte van haar omgeving (de dienstafnemer(s)).
Een door een applicatie geleverde dienst (te gebruiken via applicatieinterfaces).
Gestructureerde beschrijving van de structuur, semantiek en de eigenschappen van informatie over dingen in de werkelijkheid.
Het opleggen van een bepaalde norm of standaard voor het ontwerp, de constructie, het testen of gebruiken van een product of proces.
Deze pagina is het laatst bewerkt op 5 mei 2024 om 14:00.
Voor vragen over de GEMMAreferentiearchitectuur, stuur een bericht naar gemmaonline@vng.nl of stel direct een vraag in de groep Regie op ICT op het forum van VNG.
De GEMeentelijke ModelArchitectuur met een verzameling samenhangende kaders, richtlijnen, referentiemodellen en standaarden die gemeenten helpt bij het inrichten van hun IT-omgeving en processen.
Sjabloonoplossing voor de architectuur van een bepaald domein.
Object met gegevens die door de bron is bedoeld voor ontvangst door een of meer ontvangende actoren of systemen.