Indledning
Med den politiske aftale ”Opfølgning på evaluering af planloven m.v.” (Juni 2022) blev det besluttet, at der skal ske en digitalisering af kommuneplanen. Det fremgår bl.a. af aftalen, at: ”Kommunerne får mulighed for at aflevere en digital kommuneplan i Plandata.dk, og Plandata.dk udbygges, så det bliver muligt at registrere og udstille en digital kommuneplan i Plandata.dk.”
Plandata.dk har de seneste år derfor arbejdet på et projekt, der skal muliggøre afleveringen og udstillingen af fuldt digitale kommuneplaner og kommuneplantillæg til Plandata.dk, således Plandata.dk kan modtage de kommuneplaner, som mange kommuner allerede i dag udarbejder fuldt digitalt.
Konkret betyder det,
- at Plandata.dk har udarbejdet en standard for indberetning af digitale kommuneplaner til Plandata.dk
- at Plandata.dk har udviklet en brugergrænseflade for indberetningen af digitale kommuneplaner
- at Plandata.dk har udviklet brugergrænseflade for udstillingen af digitale kommuneplaner
Projektet gennemføres i tre faser med hver deres leverance. De tre faser er nærmere beskrevet nedenfor.

Projektets 3 faser
Fase 1 - Datamodel og services
I projektets første fase er datamodellen for digitale kommuneplaner og kommuneplantillæg afgrænset, beskrevet og implementeret i Plandata.dk. Samtidig er der udviklet et REST API, så indberetningen af digitale kommuneplaner kan ske via system-til-system-løsninger.
Datamodellen er udviklet med input fra udvalgte kommuner, der allerede laver digitale kommuneplaner, samt NIRAS som repræsentant for de tredjepartsleverandører, der understøtter kommunernes indberetning af flere plantyper til Plandata.dk.
Projektets første fase er afsluttet og implementeret i systemet, så det er muligt at benytte datamodellen for digitale kommuneplaner og digitale kommuneplantillæg gennem REST API.
Fase 2 - Indberetning
I projektets anden fase udvikles en brugerflade for indberetningen af digitale kommuneplaner og kommuneplantillæg til Plandata.dk.
Brugerfladen kommer til at ligge i det eksisterende indberet.plandata.dk-setup. Brugerfladen skal understøtte indberetningen af digitale kommuneplaner direkte i Plandata.dk, og den vil være tilgængelig for alle kommuner. En række kommuner er inddraget i denne del af projektet, så de kommunale behov og idéer til en god indberetningsproces bedst muligt understøttes i den kommende løsning.
Projektets anden fase er implementeret i slutningen af 2024.
Fase 3 - Udstilling
I projektet tredje fase udvikles en ny, offentlig visningsflade for digitale kommuneplaner og kommuneplantillæg med retlige digitale kort og tekster. Visningsfladen er udviklet, og der er lavet en løsning, hvor det er let og intuitivt at
-
fremsøge, hvad der gælder for et område, på tværs af kommuneplanens indhold
-
navigere mellem de forskellige sektioner i en kommuneplan
-
fremsøge indhold, der vedrører bestemte retningslinjer eller tematikker i kommuneplanen
Projektets tredje fase er afsluttet i juni 2025.
En ny version af plandatabekendtgørelsen er trådt i kraft den 19. juni 2025. Den gør det muligt at aflevere fuldt retligt gældende kommuneplaner til Plandata.dk.
Et fælles fundament for digitale kommuneplaner
Løsningen for digitale kommuneplaner er udviklet i tre faser for at sikre en blød landing af projektet, hvor der er plads til mindre justeringer undervejs. Derfor er der først bygget et fællesfundament for indberetningen af digitale planer i Plandata.dk i form af en datamodel, der er gjort tilgængelig via en række eksterne services. Vi er startet med datamodellen og eksterne services for at sikre, at de kommuner, der allerede i dag udarbejder digitale kommuneplaner, og de virksomheder, der understøtter kommunerne i at udarbejde digitale kommuneplaner tidligt, har haft mulighed for at teste, anvende og komme med tilbagemeldinger på datamodellen og de services, der skal understøtte indberetningen.
Herefter har vi haft fokus på at udvikle en egentlig indberetningsflade på indberet.plandata.dk, hvorfra alle kommuner har mulighed for at indberette digitale kommuneplaner. Sidst men ikke mindst udvikler Plandata.dk en fælles udstillingsløsning for digitale kommuneplaner. Udstillingsplatformen har til formål at udstille de digitale kommuneplaner i deres helhed, både som tekst og kort, og i sammenhæng med digitale kommuneplantillæg. Udstillingsløsningen er blevet lanceret den 19. juni 2025.
Det er vigtigt at understrege, at de nye indberetnings- og udstillingsflader, som Plandata.dk stiller til rådighed, for digitale kommuneplaner ikke forhindrer kommunerne i at udvikle og tilpasse egne løsninger for digitale kommuneplaner. Dette kan fortsat gøre ved at anvende de services, som Plandata.dk stiller til rådighed.

PlanDK4 – datamodellen for digitale kommuneplaner
Baggrund for ny datamodel
Med den politiske aftale ”Opfølgning på evaluering af planloven m.v.” (Juni 2022) blev det besluttet, at der skal ske en digitalisering af kommuneplanen. Det fremgår bl.a. af aftalen, at: ”Kommunerne får mulighed for at aflevere en digital kommuneplan i Plandata.dk, og Plandata.dk udbygges, så det bliver muligt at registrere og udstille en digital kommuneplan i Plandata.dk.”
For at muliggøre indberetning af digitale kommuneplaner og kommuneplantillæg udvides Plandata.dk med en ny datamodel samt en ny indberetningsflade og udstillingsløsning. I det følgende beskrives datamodellen PlanDK4, der er gældende for digitale kommuneplaner og kommuneplantillæg i Plandata.dk.
PlanDK4 giver mulighed for at indberette kommuneplanens indhold som tekst og billeder samt at foretage en strukturering af indholdet. Datamodellen integrerer de eksisterende principper for indberetning af kommuneplanrammer efter PlanDK2+, og den bygger videre på principperne for indberetning af retningslinjekataloget efter PlanDK3, så retningslinjerne både udpeges og beskrives.
Datamodellen er udarbejdet af PLST i dialog med udvalgte kommuner og NIRAS A/S som repræsentant for de tredjepartsløsninger, som flere kommuner allerede i dag anvender til udvikling af digitale kommuneplaner.
Det skal understreges, at det er tilstræbt at gøre datamodellen dynamisk og så rummelig som muligt, således at kommuneplanerne, som vi kender dem i dag, kan indberettes i deres helhed. Samtidig giver datamodellen mulighed for, at kommunerne (eller andre) i egen database kan registrere flere oplysninger end modellen kræver. Datamodellen giver også mulighed for at få disse oplysninger til at spille sammen med oplysningerne, der er indberettet til Plandata.dk, via modellens unikke ”nøgler” (forskellig entydig nummerering af temaer og objekter).
PlanDK4 er et nybrud i forståelsen af datamodeller, da modellen i høj grad sigter efter, at kommunerne har de nødvendige frihedsgrader til at udarbejde deres kommuneplaner digitalt i Plandata.dk. Datamodellen byder derfor ikke på mange nye dataregistreringsforpligtelser, men giver derimod en generel ramme for at skrive en digital kommuneplan direkte i Plandata.dk efter en bestemt struktur og udfolde planens bestemmelser i tekst og billeder suppleret af geografiske udpegninger.
Datamodellen PlanDK4 er indarbejdet i Plandata.dk's kernesystem og vil således være en fast standard de kommende år. På denne måde vil der være mulighed og sikkerhed for at ”tale” med Plandata.dk via systemets åbne snitflader.
Datamodellen vil løbende blive vurderet, og nødvendige ændringer bliver gennemført, når behovet er til stede.
Introduktion til PlanDK4
I det indledende arbejde med skitseringen af datamodellen for digitale kommuneplaner blev der set nærmere på en lang række eksisterende kommuneplaner og kommuneplantillæg samt planlovens krav til kommuneplanlægning. Det skete med henblik på at identificere de begreber og strukturer, der udgør kommuneplanerne og kommuneplantillæggene.
Dette indledende arbejde resulterede i nedenstående simplificerede begrebsmodel, der forklarer kommuneplanen og kommuneplantillæg. Begrebsmodellen beskriver kommuneplanen som bestående af:
-
en redegørelse for planens forudsætninger
-
en hovedstruktur for udviklingen af arealanvendelsen
-
retningslinjer for arealanvendelse
-
rammer for lokalplanlægningen og
-
i praksis også af alt muligt andet.
Typisk organiseres disse begreber i en række emner eller tematikker, og noget indhold udpeges som områder på et kort. Det kan virke banalt med en denne simplificerede udlægning af kommuneplanen, men begreberne har været centrale for at lave en datamodel, der kan rumme den forskellighed, som kommuneplaner og kommuneplantillæg har.

Datamodellens objekter
Ud fra fra begrebsmodellen er der lavet en informationsmodel, der har givet anledning til en strukturering af datamodellen for digitale kommuneplaner og kommuneplantillæg i seks forskellige objekttyper i datamodellen.
Strukturen for indberetning af indholdet af kommuneplanen er hierarkisk for plan-, emne-, indholds- og område-objektet.
-
Det første niveau er plan-objektet, som indeholder de overordnede informationer om planen.
-
Det andet niveau er emne-objektet, der organiserer indholdet af kommuneplanen. Det består af tekst, billeder mm.
-
Det tredje niveau er indhold-objektet, som er selve indholdet af emnerne. Der består af tekst, billeder mm., som er mulige at relatere til bestemte §§ i planloven, og kan eventuelt få tilknyttet geografiske områder.
-
Det fjerde niveau er område-objektet, der er det eller de udpegede geografiske områder, som et indholds-objekt gælder for.

Forholdet mellem to forskellige niveauer er "1 til mange". For eksempel kan et emne-objekt indeholde flere indholds-objekter, som kan indeholde flere område-objekter. Dette gør det muligt at sammensætte kommuneplanerne på forskellig vis. Forholdet mellem plan-, emne- indholds-, og område-objekterne er illustreret nedenfor, og beskrives yderligere i det følgende afsnit.

Plan-objektet
Datamodellen for digitale kommuneplaner og kommuneplantillæg indeholder et plan-objekt med de overordnede oplysninger om planen samt en række metadata.
I plan-objektet registreres planens navn, høringsdatoer og politiske vedtagelsesdatoer, og det er ligeledes muligt at vedhæfte et plandokument (Bemærk at det ikke er obligatorisk at vedhæfte pdf'er for digitale kommuneplaner)
Plan-objektet er det overliggende objekt, som emner, rammer, bilag og kommuneplantillæg refererer til, og har ophæng i.
Emne-objektet
Kommuneplaner er typisk struktureret i emner eller tematikker. Strukturen kan være tematiseret fx i planfaglige emner som Detailhandel, Byudvikling og natur, Miljø og landskab eller omkring hovedbegreberne i kommuneplanen: Hovedstruktur, Planredegørelse, Rammer for lokalplanlægning og Retningslinjer.
En kommuneplan kan også være struktureret i en sammenblanding mellem hovedbegreberne og de planfaglige emner.
For en digital kommuneplan er det muligt at indberette emner, der består af titel og et tekstfelt samt angive i hvilken læseorden emnet skal læses i relation til de øvrige emner.
Titelfeltet for emnet er et fritekst felt, hvor navngivningen af emnet angives.
Tekst-feltet for emnet er et fritekst felt, hvor kommunen kan give en kortere introduktion til emnet. Det er ikke hensigten af kommunen skal skrive længere redegørelser eller retningslinjebestemmelser til emnet i emnebeskrivelsen. Det er ikke obligatorisk at udfylde tekst-feltet.
Indholdet af “Tekst-feltet” for emne-objektet er muligt at formatere, således at teksten kan skrives og vises på den måde, som det er tiltænkt. Det er også muligt at indlejre billeder og tabeller i “Tekst-feltet”, så statiske kort og billeder fortsat kan være en del af kommuneplanen.
Læseorden styrer emnernes indbyrdes hierarki for at sikre, at der findes en læseorden af planen. Hierarkiet angives numerisk med en stigende talrække, hvor 1 læses før 2 og så fremdeles.
Den nærmere datamodel for emne-objektet findes her.
Indholds-objekt
Substansen i emnerne udgøres af indholds-objekter. Indholds-objekterne har til formål at indeholde og strukturere den information, og de bestemmelser, der er gældende inden for det enkelte emne.
For indholds-objekterne er det på samme måde som for emne-objekterne muligt at registrere både en titel og et tekstfelt, samt angive i hvilken læseorden indholds-objekterne skal læses i. Dertil er det muligt at registrerer en §-henvisning til Planloven.
Titelfeltet for indholds-objektet er en fritekst felt, hvor titlen af indholdet kan angives. Titelfeltet kan bruges til at underopdele indholdet inden for et emne, og vil kunne fremgå af en indholdsfortegnelse eller som en undertitel på en side for den digitale kommuneplan.
Tekst-feltet for indholds-objekter et fritekst felt, hvor kommunen kan skrive det nærmere indhold for hele eller dele af emnet. Det er hensigten, at hovedbestanddelen af indholdet skrives i dette felt.
Indholdet af “Tekst-feltet” for indholds-objektet er muligt at formatere, således at teksten kan skrives og vises på den måde, som det er tiltænkt. Det er også muligt at indlejre billeder og tabeller i “Tekst-feltet”, så statiske kort og billeder fortsat kan være en del af kommuneplanen.
Læseorden skal angives for indholds-objekter. Det skyldes, at datamodellen dikterer en relation mellem indholds-objekter og emne-objekter, hvor et indholds-objekt skal tilknyttes et emne. Flere indholds-objekter kan godt tilknyttes til det samme emne. I tilfælde af at et emne-objekt tilknyttes flere indholds-objekter, skal den indbyrdes læseorden mellem indholds-objekterne registreres. Hierarkiet angives numerisk med en stigende talrække, hvor 1 læses før 2 og så frem deles.
§-henvisning er en henvisning til planloven for det enkelte indholds-objekt. §-henvisningen skal det gøre det lettere for borgere, virksomheder og myndigheder at finde relevant indhold i kommuneplanen, og sikre overholdelsen af planlovens krav til kommuneplanen. Det giver også fleksibilitet ift. kortudstilling af arealudpegninger med ophæng i planloven.
Registreringen skal benyttes til at opmærke tekst, der vedrører og omhandler et specifikt krav eller mulighed for planloven. Det kan fx være en opmærkning af et indholds-objekt, der vedrører detailhandelsstrukturer og bydelscentre med en §-henvisning til planlovens § 11 a, stk. 1, nr. 3. Derved er det muligt at fremsøge og vise indholdet af denne retningslinje for arealanvendelsen særskilt.
Det er muligt at angive §-henvisninger for paragraffer, der fremgår af listen over understøttede §-henvisninger, og der er ligeledes oprettet en kode for “har ikke ophæng i planloven”. Plandata.dk sørger for at opdatere listen over §-henvisninger i takt med at planloven revideres og udvikles.
Område-objekt
De dele af kommuneplanen der gælder for bestemte områder af kommuneplanen, kan udpeges ved at registrere et område-objekt på indholdet. Område-objekterne muliggør således en rumlig fremsøgning og visning af kommuneplanen.
For område-objekterne er det, på samme måde som for emne-objekter og indholds-objekter, muligt at registrere både en titel og et tekstfelt. Dertil er det muligt at registrere en områdekode, der kan bruges til at kategorisere visningen af området, hvis det har ophæng i et indholds-objekt med en §-henvisning.
Titelfeltet for område-objektet er et fritekst felt, hvor området kan navngives.
Tekst-feltet for område-objektet er et fritekst felt, hvor kommunen kan angive en tekst, der er specifik for det udpegede område. Det kan fx være de bestemmelser, der er gældende for det pågældende område.
Indholdet af “Tekst-feltet” for område-objektet er muligt at formatere, således at teksten kan skrives og vises på den måde, som det er tiltænkt. Det er ikke muligt at indlejre billeder og tabeller i “Tekst-feltet” for område-objekter.
Geografi for område-objekter skal udpeges på kort som enten polygoner eller multipolygoner. Det er ikke muligt at indberette punkter, linjer eller andre geometri-typer.
Områdekode for område-objekter er en kode, der kategoriserer området. Områdekoderne har sammenhæng til de retningslinjer, det er muligt at angive for traditionelle kommuneplaner, så det også for den digitale kommuneplan er muligt at lave en differentieret visning af områderne. Områdekoderne gør det fx muligt at lave en differentieret visning af detailhandelsstrukturer, så det er muligt at adskille bydelscentre, centerområder, aflastningsområder m.v.
Eksempel på sammensætning af objekter

Datamodeller for objekter i PlanDK4
Datamodellen beskriver de oplysninger, der findes i de enkelte objekter i kommuneplanen, men kan også bruges til forståelse af, hvordan planen er bygget op generelt. Dette gøres, da der en del oplysninger, som er tilgængelige via hent-kald, men som ikke kan ændres via opdatering eller oprettelse. Indberetningen af rammer og dertilhørende felter er den mest komplicerede og hertil hører også flere underliggende datamodeller. Disse datamodeller vil typisk være henvist til i den overliggende datamodel i kolonnen "Feltnavn" og markeret som datamodel i kolonnen type. De underliggende felter til disse underliggende datamodeller angives derfor ikke. Desuden linker datamodellen til overblikket over kodelister, hvor det er relevant.
For hver datamodel er der opstillet et skema. Skemaet indeholder:
- oplysningernes navn
- en beskrivelse af dem
- feltets navn i REST API'et
- datatypen for feltet
- et eksempel på en udfyldt værdi
- krav til feltets indhold.
Skemaet kan bruges som et opslagsværk, der kan forklare betydningen af felterne bl.a. i en planmæssig kontekst. Datamodellen skal ses i sammenhæng med vores Swagger dokumentation, som kan bruges til at navigere i REST API. Her kan det ses, hvilke oplysninger der kan tilgås og redigeres i via de forskellige kald.
Datatyper
De følgende datamodeller indeholder en række datatyper, som angiver, hvilke typen på det felt, som indberettes til REST-API'et.
|
Datatype |
Beskrivelse |
|---|---|
| Streng |
Et almindeligt tekstfelt, typisk med en angiven længde. |
| Streng - kodeliste |
Et tekstfelt, som skal udfyldes med værdier fra en fastsat liste. En kodeliste er angivet. |
| Dato | Et tekstfelt, som skal udfyldes med dato yyyy-mm-dd. |
| Timestamp | Præcist tidspunkt, der typisk sættes af systemet. |
|
Heltal |
Heltal, hvor der ofte angives en længde. |
| Decimal |
Decimaltal, hvor der ofte er begrænsninger. |
| Boolean |
Felt, som kan angives med true/false. |
| Liste |
En kommasepareret liste. |
| Datamodel |
Felt, der indeholder andre felter. F.eks. en liste med rammer på en kommuneplan. |
Kommuneplanobjektet og Kommuneplantillæg-objektet
Datamodellen for digitale kommuneplaner og kommuneplantillæg indeholder et plan-objekt med de overordnede oplysninger om planen samt en række metadata.
Datamodellen følger i store træk PlanDK2, med de få ændringer der er opstået over tid. En ændring der er værd at hæfte sig ved er feltet plantype som (fuldstændigt) erstatter objektkode som en samlet liste over plantyper.
I plan-objektet registreres planens navn, høringsdatoer og politiske vedtagelsesdatoer, og det er ligeledes muligt at vedhæfte et plandokument. Plandokumentet kan være en pdf genereret
Plan-objektet er det overliggende objekt, som emner, rammer, bilag og kommuneplantillæg refererer til, og har ophæng i.
|
Felt |
Beskrivelse |
Feltnavn i REST |
Datatype |
Eksempel |
Bemærkninger vedrørende indberetning |
|---|---|---|---|---|---|
|
Plannavn |
Navnet på kommuneplanen eller kommuneplantillægget |
Plannavn |
Streng |
“Plannavn for denne plan” |
Maks.130 tegn |
|
Planid |
Unikt id for planen, som automatisk tildeles af systemet når man opretter en plan. |
planId |
Heltal |
11447612 |
Ved indberetning af en ny plan genereres PLANID |
|
Plantype |
Angivelse af hvilken plantype der er tale om. Der kan indberettes værdien kommuneplan eller kommuneplantillæg fra en kodeliste (se kodelister) |
plantype |
Streng - kodeliste |
“KOMMUNEPLAN” |
Se Plantype |
|
Planstatus |
Viser planens planlægningsmæssige status, F.eks. Vedtaget eller Aflyst. Der kan indberettes værdier fra en kodeliste (se kodelister) |
planstatus |
Streng - kodeliste |
“FORSLAG” |
Se Status |
|
Kommunekode |
Det trecifrede kommunenummer for den kommune, som planen tilhører. |
kommunekode |
Heltal |
851 |
|
|
Plandokument |
Link til plandokumentet, som automatisk genereres af systemet |
dokumentUrl |
Streng |
Feltet opdateres automatisk i systemet |
|
|
Aflysningsdato |
Dato for planens aflysning. |
aflysningsdato |
Dato |
“2026-04-25” |
format: yyyy-mm-dd |
|
Ikrafttrædelsesdato |
Dato for planens ikrafttrædelse. |
ikrafttraedelsesdato |
Dato |
“2026-04-25” |
format: yyyy-mm-dd |
|
Gyldighedsdato fra |
Startdatoen for gyldighedsperioden for den aktuelle version af planen. |
gyldighedsdatoFra |
Dato |
“2026-04-25” |
format: yyyy-mm-dd |
|
Gyldighedsdato til |
Slutdatoen for gyldighedsperioden for den aktuelle version af planen. |
gyldighedsdatoTil |
Dato |
“2026-04-25” |
format: yyyy-mm-dd |
|
Opdateringstidspunkt |
tidspunkt for sidste opdatering |
opdateringstidspunkt |
“2024-04-25T10:32:39.171” |
“2024-04-25T10:32:39.171” |
Feltet opdateres automatisk i systemet |
|
Kun Kommuneplantillæg: versionsnr. |
Kommuneplantillæg kan have flere versioner. Tildeles automatisk. |
versionsnr |
Heltal |
1 |
Feltet opdateres automatisk i systemet |
|
Datoer |
Datoer indeholder en række datofelter som er relevante for planer, omkring høringsperiode, indberetning, forslag og vedtagelse. |
datoer |
Datamodel |
|
|
|
Aktuel |
Angiver om planen er den aktuelle plan, baseret på bl.a. versionsnr. |
aktuel |
Boolean |
true |
Feltet opdateres automatisk i systemet |
|
Rammer |
Rammer indeholder info om planens rammer |
rammer |
Datamodel |
|
|
|
Kun Kommuneplantillæg: Relation til kommuneplan |
Planid for den kommuneplan som kommuneplantillægget er tilknyttet |
kommuneplanId |
Heltal |
11447612 |
null, eller valid planid |
Emneobjektet
Kommuneplaner er typisk struktureret i emner eller tematikker. Strukturen kan enten være tematiseret fx i planfaglige emner som Detailhandel, Byudvikling og natur, Miljø og landskab eller omkring hovedbegreberne i kommuneplanen: Hovedstruktur, Planredegørelse, Rammer for lokalplanlægning og Retningslinjer. En kommuneplan kan også være struktureret i en sammenblanding mellem hovedbegreberne og de planfaglige emner.
For en digital kommuneplan er det muligt at indberette emner, der består af titel og et tekstfelt samt angive i hvilken læseorden emnet skal læses i relation til de øvrige emner.
Titelfeltet for emnet er et fritekst felt, hvor navngivningen af emnet angives.
Tekst-feltet for emnet er et fritekst felt, hvor kommunen kan give en kortere introduktion til emnet. Det er ikke hensigten af kommunen skal skrive længere redegørelser eller retningslinjebestemmelser til emnet i emnebeskrivelsen. Det er ikke obligatorisk at udfylde tekst-feltet. Indholdet af “Tekst-feltet” for emne-objektet er muligt at formatere, således at teksten kan skrives og vises på den måde, som det er tiltænkt. Det er også muligt at indlejre billeder og tabeller i “Tekst-feltet”, så statiske kort og billeder fortsat kan være en del af kommuneplanen.
Læseorden styrer emnernes indbyrdes hierarki for at sikre, at der findes en læseorden af planen. Hierarkiet angives numeriske med en stigende talrække, hvor 1 læses før 2 og så fremdeles.
|
Felt |
Beskrivelse |
Feltnavn i REST |
Datatype |
Eksempel |
Bemærkninger vedrørende indberetning |
|---|---|---|---|---|---|
|
Element-id/Planid |
Unikt id for planen, som automatisk tildeles af systemet når man opretter en plan. |
planId |
Heltal |
11447612 |
Kan ikke ændres |
|
Plantype |
Angivelse af hvilken plantype der er tale om. I Plandata er Emneobjektet en Plantype og feltet skal i denne sammenhæng derfor altid være udfyldt med EMNE |
plantype |
Streng - kodeliste |
“EMNE” |
Se Plantype |
|
Planstatus |
Viser objektets planlægningsmæssige status, F.eks. Vedtaget eller Aflyst. Der kan indberettes værdier fra en kodeliste (se kodelister) |
planstatus |
Streng - kodeliste |
“FORSLAG” |
Se Status |
|
Kommunekode |
Det trecifrede kommunenummer for den kommune som planen tilhører |
kommunekode |
Heltal |
851 |
|
|
Aflysningsdato |
Dato hvor emneobjektet er blevet aflyst |
aflysningsdato |
Dato |
“2026-04-25”, null |
format: yyyy-mm-dd |
|
Opdateringstidspunkt |
Tidspunkt for sidste opdatering af emneobjektet |
opdateringstidspunkt |
Timestamp |
“2024-04-25T10:32:39.171” |
Kan ikke ændres |
|
Versionsnummer |
I tilfælde hvor der er oprettet en ny version af planen eller emneobjektet vil det fremgå her, hvilken version der er tale om. |
versionsnr |
Heltal |
1 |
Kan ikke ændres |
|
Kommuneplan - relation |
Planid for den kommuneplan som emneobjektet er en del af. Hvis Emneobjektet er en del af et Kommuneplantillæg vil feltet være null |
kommuneplanID |
Heltal |
null |
null, eller valid planid |
|
Kommuneplantillæg - relation |
Planid for den kommuneplantillæg som emneobjektet er en del af. Hvis Emneobjektet er en del af et Kommuneplan vil feltet være null |
kommuneplantillaegID |
Heltal |
11388877 |
null, eller valid planid |
|
Indberetningsdato |
Dato for emnets indberetning |
indberetningsdato |
Timestamp |
“2024-04-25T10:32:39.171” |
format: yyyy-mm-dd |
|
Id for overordnet Element/Plan |
Id for det objekt som emnet er underordnet. For Emneobjekter vil dette være tilsvarende ID den Kommuneplan eller det kommuneplantillæg som det er en del af |
parentId |
Heltal |
11388877 |
null, eller valid planid |
|
Overskrift |
Tekstfelt med overskrift |
overskrift |
Streng |
“Overskriften” |
Maks. 30 tegn |
|
Tekst |
Tekstfelt til indholdet af emneobjektet |
tekst |
Streng |
“Her er en indholdstekst” |
|
|
Læseorden/Indeks |
Felt der viser hvilken rækkefølge emneobjektet skal vises |
indeks |
Heltal |
1 |
|
|
Indhold |
Indhold indeholder indholdsobjekter knyttet til emne |
indhold |
Datamodel |
|
|
|
Valideringsstatus |
Validering indeholder to felter: Valideringsstatus som viser om objektet er valideret, og regelsæt som viser en liste af valideringsfejl hvis relevant. |
validering |
Datamodel |
|
Indholdsobjektet
Substansen i emnerne udgøres af indholds-objekter. Indholds-objekterne har til formål at indeholde og strukturere den information, og de bestemmelser, der er gældende inden for det enkelte emne.
For indholds-objekterne er det på samme måde som for emne-objekterne muligt at registrere både en titel og et tekstfelt, samt angive i hvilken læseorden indholds-objekterne skal læses i. Dertil er det muligt at registrere en §-henvisning til Planloven.
Titelfeltet for indhold-objektet er en fritekst felt, hvor titlen af indholdet kan angives. Titelfeltet kan bruges til at underopdele indholdet inden for et emne, og vil kunne fremgå af en indholdsfortegnelse eller som en undertitel på en side for den digitale kommuneplan.
Tekst-feltet for indholds-objekter et fritekst felt, hvor kommunen kan skrivere det nærmere indhold for hele eller dele af emnet. Det er hensigten, at hovedbestanddelen af indholdet skrives i dette felt.
Indholdet af “Tekst-feltet” for indholds-objektet er muligt at formatere, således at teksten kan skrives og vises på den måde, som det er tiltænkt. Det er også muligt at indlejre billeder og tabeller i “Tekst-feltet”, så statiske kort og billeder fortsat kan være en del af kommuneplanen.
Læseorden skal angives for indholds-objekter. Det skyldes, at datamodellen dikterer en relation mellem indholds-objekter og emne-objekter, hvor et indholds-objekt skal tilknyttes et emne. Flere indholdsobjekter kan godt tilknyttes til det samme emne. I tilfælde af at et emne-objekt tilknyttes flere indholds-objekter, skal den indbyrdes læseorden mellem indholds-objekterne registreres. Hierarkiet angives numerisk med en stigende talrække, hvor 1 læses før 2 og så frem deles.
§-henvisning er en henvisning til planloven for det enkelte indholdselement. §-henvisningen skal det gøre det lettere for borgere, virksomheder og myndigheder at finde relevant indhold i kommuneplanen, og sikre overholdelsens af planlovens krav til kommuneplanen. Det giver også fleksibilitet ift. kortudstilling af arealudpegninger med ophæng i planloven.
Registreringen skal benyttes til at opmærke tekst, der vedrører og omhandler et specifikt krav eller mulighed for planloven. Det kan fx være en opmærkning af et indholdselement der vedrører detailhandelsstrukturer og bydelscentre med en §-henvisning til planlovens § 11 a pkt. 3. Derved er det muligt at fremsøge og vise indholdet af denne retningslinje for arealanvendelsen særskilt.
Det er muligt at angive §-henvisninger for retningslinjekataloget - alternativt ikke vælge en værdi, hvis indholdet ikke er en retningslinje efter retningslinjekataloget. Plandata.dk sørger for at opdatere listen over §-henvisninger i takt med at planloven revideres og udvikles.
|
Felt |
Beskrivelse |
Feltnavn i REST |
Datatype |
Eksempel |
Bemærkninger vedrørende indberetning |
|---|---|---|---|---|---|
|
Element-id/Planid |
Unikt id for planen, som automatisk tildeles af systemet når man opretter en plan. |
planId |
Heltal |
11447612 |
Kan ikke ændres |
|
Plantype |
Angivelse af hvilken plantype der er tale om. I Plandata er indholdsobjektet en Plantype og feltet skal i denne sammenhæng derfor altid være udfyldt med INDHOLD |
plantype |
Streng - kodeliste |
“INDHOLD” |
Se Plantype |
|
Planstatus |
Viser objektets planlægningsmæssige status, F.eks. Vedtaget eller Aflyst. Der kan indberettes værdier fra en kodeliste (se kodelister) |
planstatus |
Streng - kodeliste |
“FORSLAG” |
Se Status |
|
Kommunekode |
Det trecifrede kommunenummer for den kommune som planen tilhører. |
kommunekode |
Heltal |
851 |
|
|
Aflysningsdato |
Dato hvor emneobjektet er blevet aflyst. |
aflysningsdato |
Dato |
“2026-04-25”, null |
format: yyyy-mm-dd |
|
Opdateringstidspunkt |
tidspunkt for sidste opdatering af indholdsobjektet |
opdateringstidspunkt |
Timestamp |
“2024-04-25T10:32:39.171” |
Kan ikke ændres |
|
Versionsnummer |
I tilfælde hvor der er oprettet en ny version af planen eller emneobjektet vil det fremgå her hvilken version der er tale om. |
versionsnr |
Heltal |
1 |
Kan ikke ændres |
|
Kommuneplan - relation |
Planid for den kommuneplan som indholdsobjektet er en del af. Hvis indholdsobjektet er en del af et Kommuneplantillæg vil feltet være null |
kommuneplanID |
Heltal |
null |
null, eller valid planid |
|
Kommuneplantillæg - relation |
Planid for den kommuneplantillæg som indholdsobjektet er en del af. Hvis indholdobjektet er en del af et Kommuneplan vil feltet være null |
kommuneplantillaegID |
Heltal |
11388877 |
null, eller valid planid |
|
Indberetningsdato |
Dato for indholdsobjektets indberetning |
indberetningsdato |
Timestamp |
“2024-04-25” |
format: yyyy-mm-dd |
|
Id for overordnet Element/Plan |
Planid for det emneobjekt som indholdet er tilknyttet |
parentId |
Heltal |
11388877 |
null, eller valid planid |
|
Overskrift |
Tekstfelt med overskrift |
overskrift |
Streng |
“Overskriften” |
maks. 30 tegn |
|
Tekst |
Tekstfelt til indholdet af indholdsobjektet |
tekst |
Streng |
“Her er en indholdstekst” |
|
|
Læseorden/Indeks |
Felt der viser hvilken rækkefølge indholdsobjektet skal læses i. Dette har betydning for hvordan det bliver vist i pdf’en |
indeks |
Heltal |
1 |
|
|
Paragrafhenvisning |
Element, der indholder to felter: en kode, som henviser til en paragraf, og et tekstfelt, som indeholder en beskrivelse af den givne kode. |
paragraf |
Datamodel |
|
Se Nedenfor |
|
Område |
Område indeholder områdeobjekter knyttet til indholdsobjektet |
omraade |
Datamodel |
|
|
|
Valideringstatus |
Valideringsinfo indeholder to felter: Valideringsstatus som viser om objektet er valideret, og regelsæt som viser en liste af valideringsfejl hvis relevant. |
validering |
Datamodel |
|
|
| Paragrafhenvisning | |||||
| Paragrafkode | En kode der repræsenterer en specifik pragrafkode. | kode | Heltal | "1120" | Se Paragrafhenvisninger |
| Paragraftekst | indeholder en tekst der beskriver den specifikke paragrafkode | tekst | Streng |
Områdeobjektet
De dele af kommuneplanen der gælder for bestemte områder, kan udpeges ved at registrere et område-objekt på indholdet. Område-objekterne muliggør således en rumlig fremsøgning og visning af kommuneplanen. Dog angives kommuneplanens rammer stadig i et objekt for sig.
For område-objekterne er det, på samme måde som for emne-objekter og indholds-objekter, muligt at registrere både en titel og et tekstfelt. Dertil er det muligt at registrere en områdekode, der kan bruges til at kategorisere visningen af området, hvis det har ophæng i et indholds-objekt med en §-henvisning.
Titelfeltet for område-objektet er et fritekst felt, hvor området kan navngives.
Tekst-feltet for område-objektet er et fritekst felt, hvor kommunen kan angive en tekst, der er specifik for det udpegede område. Det kan fx være de bestemmelser, der er gældende for det pågældende område.
Indholdet af “Tekst-feltet” for område-objektet er muligt at formatere, således at teksten kan skrives og vises på den måde, som det er tiltænkt. Det er ikke muligt at indlejre billeder og tabeller i “Tekst-feltet” for område-objekter.
Geografi for område-objekter skal udpeges på kort som enten polygoner eller multipolygoner. Det er ikke muligt at indberette punkter, linjer eller andre geometri-typer.
Områdekode for område-objekter er en kode, der kategoriserer området. Områdekoderne har sammenhæng til de retningslinjer, det er muligt at angive for traditionelle kommuneplaner, så det også for den digitale kommuneplan er muligt at lave en differentieret visning af områderne. Områdekoderne gør det fx muligt at lave en differentieret visning af detailhandelsstrukturer, så det er muligt at adskille bydelscentre, centerområder, aflastningsområder m.v.
|
Felt |
Beskrivelse |
Feltnavn i REST |
Datatype |
Eksempel |
Bemærkninger vedrørende indberetning |
|---|---|---|---|---|---|
|
Element-id/Planid |
Unikt id for planen, som automatisk tildeles af systemet når man opretter en plan. |
planId |
Heltal |
11447612 |
Kan ikke ændres |
|
Plantype |
Angivelse af, hvilken plantype der er tale om. I Plandata er områdeobjektet en Plantype og feltet skal i denne sammenhæng derfor altid være udfyldt med OMRAADE |
plantype |
Streng - Kodeliste |
“OMRAADE” |
Se Plantype |
|
Planstatus |
Viser objektets planlægningsmæssige status, F.eks. Vedtaget eller Aflyst. Der kan indberettes værdier fra en kodeliste (se kodelister) |
planstatus |
Streng - Kodeliste |
“FORSLAG” |
Se Status |
|
Kommunekode |
Det trecifrede kommunenummer for den kommune som planen tilhører. |
kommunekode |
Heltal |
851 |
|
|
Geometri |
Der kan tilføjes en geometri til et områdefelt |
geometri |
Streng |
|
|
|
Aflysningsdato |
Dato hvor emneobjektet er blevet aflyst. |
aflysningsdato |
Dato |
“2026-04-25”, null |
format: yyyy-mm-dd |
|
Opdateringstidspunkt |
tidspunkt for sidste opdatering |
opdateringstidspunkt |
Timestamp |
“2024-04-25T10:32:39.171” |
Kan ikke ændres |
|
Versionsnummer |
I tilfælde hvor der er oprettet en ny version af planen eller emneobjektet vil det fremgå her hvilken version der er tale om. |
versionnr |
Heltal |
1 |
Kan ikke ændres |
|
Kommuneplan - relation |
Planid for den kommuneplan som områdeobjektet er en del af. Hvis områdeobjektet er en del af et Kommuneplantillæg vil feltet være null |
kommuneplanID |
Heltal |
null |
null, eller valid planid |
|
Kommuneplantillæg - relation |
Planid for den kommuneplantillæg som områdeobjektet er en del af. Hvis områdeobjektet er en del af et Kommuneplan vil feltet være null |
kommuneplantillaegID |
Heltal |
11388877 |
null, eller valid planid |
|
Indberetningsdato |
Dato for områdets indberetning |
indberetningsdato |
Timestamp |
“2024-04-25T10:32:39.171” |
Kan ikke ændres |
|
Id for overordnet Element/Plan |
Planid for det indholdsobjekt som området er tilknyttet |
parentId |
Heltal |
11388877 |
null, eller valid planid |
|
Overskrift |
Tekstfelt med overskrift |
overskrift |
Streng |
“Overskriften” |
Maks. 30 tegn |
|
Tekst |
Tekstfelt til indholdet af områdeobjektet |
tekst |
Streng |
“Her er en indholdstekst” |
|
|
Læseorden/Indeks |
Felt der viser hvilken rækkefølge områdeobjekterne skal vises |
indeks |
Heltal |
1 |
|
|
Område - element |
Element, der indeholder to felter: en kode, som henviser til en undertemakode, og et tekstfelt, som indeholder en beskrivelse af den givne kode. |
omraade |
Datamodel |
Der kan kun tilknyttes koder, der ligge indenfor den overordnede paragrafkode. |
Se Områdekoder |
|
Paragrafhenvisning |
Element, der indeholder to felter: en kode, som henviser til en paragraf, og et tekstfelt, som indeholder en beskrivelse af den givne kode. Den tilknyttede kode er svarende det overordnede indholdsobjekt. |
paragraf |
Datamodel |
|
Se under Indhold |
|
Valideringsstatus |
Valideringsinfo indeholder to felter: Valideringsstatus som viser om objektet er valideret, og regelsæt som viser en liste af valideringsfejl hvis relevant. |
validering |
Datamodel |
|
|
| Område | |||||
| områdekode | Kode der svarer til en bestemt type områder | kode | Heltal | "110201" | Se Områdekoder |
| områdetekst | En tekst der svarer til angivne områdekode | tekst | Streng | Kan ikke ændres |
Rammeobjektet
Kommuneplanens rammer følger PlanDK2 med de ændringer og tilføjelser der er blevet lavet til denne over tid. Der kan således indberettes de samme oplysninger som der kunne i PlanDK2. Ved indberetning af rammer gennem Upload/Download ændres indberetningen ikke.
I REST'en indberettes planens regulerende bestemmelser efter nedenstående mønster. Der er ikke forskel på hvad der kan indberettes men især omfangs og udstykningsbestemmelser følger et andet mønster end PlanDK2. Indberetningen i REST API'et følger i højere grad strukturen fra indberetningsfladen.
|
Felt |
Beskrivelse |
Feltnavn i REST |
Datatype |
Eksempel |
Bemærkninger vedrørende indberetning |
|---|---|---|---|---|---|
|
Plannavn |
Rammens navn. |
plannavn |
Streng |
|
|
|
Element-id/Planid |
Unikt id for planen, som automatisk tildeles af systemet, når man opretter en plan. |
planId |
Heltal |
11447612 |
Kan ikke ændres |
|
Plantype |
Angivelse af hvilken plantype der er tale om. I Plandata er bilagsobjektet en Plantype og feltet skal i denne sammenhæng derfor altid være udfyldt med BILAG |
plantype |
Streng - Kodeliste |
“KOMMUNEPLANRAMME” |
Se Plantype |
|
Planstatus |
Viser objektets planlægningsmæssige status, F.eks. Vedtaget eller Aflyst. Der kan indberettes værdier fra en kodeliste (se kodelister) |
planstatus |
Streng - Kodeliste |
“FORSLAG” |
Se Status |
|
Plannummer |
Rammenummer tilknyttet planen. |
plannummer |
Streng |
|
|
|
Kommunekode |
Det trecifrede kommunenummer for den kommune som planen tilhører. |
kommunekode |
Heltal |
851 |
|
|
Geometri |
Der kan tilføjes en geometri til et områdefelt |
geometri |
Streng |
|
|
|
Projektion |
angivelse af den projektion rammen er angivet i |
projection |
Streng |
|
Kan ikke ændres |
|
Aflysningsdato |
Dato for planens aflysning |
aflysningsdato |
Dato |
“2026-04-25” |
format: yyyy-mm-dd |
|
Ikrafttrædelsesdato |
Dato for planens ikrafttrædelse |
ikrafttraedelsesdato |
Dato |
“2026-04-25” |
format: yyyy-mm-dd |
|
Gyldighedsdato fra |
Startdatoen for gyldighedsperioden for den aktuelle version af planen. |
gyldighedsdatoFra |
Dato |
“2026-04-25” |
format: yyyy-mm-dd |
|
Gyldighedsdato til |
Slutdatoen for gyldighedsperioden for den aktuelle version af planen. |
gyldighedsdatoTil |
Dato |
“2026-04-25” |
format: yyyy-mm-dd |
|
Opdateringstidspunkt |
tidspunkt for sidste opdatering |
opdateringstidspunkt |
Timestamp |
“2024-04-25T10:32:39.171” |
Kan ikke ændres |
|
Versionsnummer |
I tilfælde hvor der er oprettet en ny version af planen eller emneobjektet vil det fremgå her hvilken version der er tale om. |
versionsnr |
Heltal |
1 |
Kan ikke ændres |
|
Aktuel |
Angiver om planen er den aktuelle plan, baseret på bl.a. versionsnr. |
aktuel |
boolean |
true |
Kan ikke ændres |
|
Kommuneplan - relation |
Planid for den kommuneplan, som emneobjektet er en del af. Hvis bilagsobjektet er en del af et Kommuneplantillæg, vil feltet være null. |
kommuneplanID |
Heltal |
null |
null, eller valid planid |
|
Kommuneplantillæg - relation |
Planid for den kommuneplantillæg, som emneobjektet er en del af. Hvis bilagsobjektet er en del af et Kommuneplan, vil feltet være null. |
kommuneplantillaegID |
Heltal |
11388877 |
null, eller valid planid |
|
Plandistrikt |
Plandistriktets navn |
plandistrikt |
Streng |
"Et plandistrikt" |
|
|
Valideringstatus |
Valideringsinfo indeholder to felter: valideringsstatus, som viser om objektet er valideret, og regelsæt, som viser en liste af valideringsfejl hvis relevant. |
validering |
Datamodel |
|
|
|
Reguleringsbestemmelser |
I Regulering ligger de oplysninger som findes i rammen om anvendelse, bebyggelsesomfang, udstykning osv. |
regulering |
Datamodel |
|
|
Bilags-objektet
Kommuneplanen følges ofte af en lang række bilag som kan tilføjes i et separat objekt.
Titelfeltet for Bilags-objektet er et fritekst felt, hvor området kan navngives.
Bilagsdokument er en mulighed for at tilføje en pdf med det ønskede dokument.
|
Felt |
Beskrivelse |
Feltnavn i REST |
Datatype |
Eksempel |
Bemærkninger vedrørende indberetning |
|---|---|---|---|---|---|
|
Element-id/Planid |
Unikt id for planen, som automatisk tildeles af systemet, når man opretter en plan. |
planId |
Heltal |
11447612 |
Kan ikke ændres |
|
Plantype |
Angivelse af hvilken plantype der er tale om. I Plandata er bilagsobjektet en Plantype og feltet skal i denne sammenhæng derfor altid være udfyldt med BILAG |
plantype |
Streng - Kodeliste |
“BILAG” |
Se Plantype |
|
Planstatus |
Viser objektets planlægningsmæssige status, F.eks. Vedtaget eller Aflyst. Der kan indberettes værdier fra en kodeliste (se kodelister) |
planstatus |
Streng - Kodeliste |
“FORSLAG” |
Se Status |
|
Kommunekode |
Det trecifrede kommunenummer for den kommune som planen tilhører. |
kommunekode |
Heltal |
851 |
Kommunekodeliste (udelad det foranstillede 0) |
|
Bilagsdokument |
Link til bilagsdokumentet, som automatisk genereres af systemet |
dokumentUrl |
Streng |
Kan ikke ændres |
|
|
Opdateringstidspunkt |
Tidspunkt for sidste opdatering |
opdateringstidspunkt |
Timestamp |
“2024-04-25T10:32:39.171” |
Kan ikke ændres |
|
Versionsnummer |
I tilfælde, hvor der er oprettet en ny version af planen eller emneobjektet, vil det fremgå her, hvilken version der er tale om. |
versionsnr |
Heltal |
1 |
Kan ikke ændres |
|
Kommuneplan - relation |
Planid for den kommuneplan som emneobjektet er en del af. Hvis bilagsobjektet er en del af et Kommuneplantillæg, vil feltet være null. |
kommuneplanID |
Heltal |
null |
null, eller valid planid |
|
Kommuneplantillæg - relation |
Planid for den kommuneplantillæg som emneobjektet er en del af. Hvis bilagsobjektet er en del af et Kommuneplan, vil feltet være null. |
kommuneplantillaegID |
Heltal |
11388877 |
null, eller valid planid |
|
maxVersion |
Feltet viser, om områdeobjektet er den seneste version (den, der gælder), vises ikke. |
maxVersion |
boolean |
true |
Kan ikke ændres |
|
maxSubversion |
Feltet viser, om områdeobjektet er den seneste subversion (den, der gælder), vises ikke. |
maxSubversion |
boolean |
true |
Kan ikke ændres |
|
Indberetningsdato |
Dato for områdets indberetning. |
indberetningsdato |
Timestamp |
“2024-04-25T10:32:39.171” |
Kan ikke ændres |
|
Overskrift |
Tekstfelt med overskrift. |
overskrift |
Streng |
“Overskriften” |
Maks. 30 tegn |
|
Læseorden/Indeks |
Felt, der viser hvilken rækkefølge bilags-objekterne skal vises. |
indeks |
Heltal |
1 |
|
|
Valideringsstatus |
Validering indeholder to felter: valideringsstatus, som viser om objektet er valideret, og regelsæt, som viser en liste af valideringsfejl hvis relevant. |
validering |
Datamodel |
|
Reguleringsbestemmelser
I denne findes oplysninger om regulering for rammen. en del af oplysningerne findes som datamodeller, f.eks. omfangsbestemmelser og notatfelter. Datamodeller for disse er også beskrevet nedenfor.
|
Felt |
Beskrivelse |
Feltnavn i REST |
Datatype |
Eksempel |
Bemærkninger vedrørende indberetning |
|---|---|---|---|---|---|
|
Fremtidig zone for rammen |
Angivelse af rammens fremtidige zonestatus. |
zone |
Streng - kodeliste |
“BYZONE” |
Der skal vælges en værdi fra Zonestatus. |
|
Generel Anvendelseskategori |
Kode for planens generelle anvendelse. |
generelAnvendelseskategori |
Streng - kodeliste |
“BOLIGOMRAADE” |
Der skal vælges en værdi fra Generel Anvendelse. |
|
Specifik anvendelseskategori |
Angivelse af specifik anvendelse. |
specifikOmfangAnvendelser |
Liste |
[1110, 1120, 3150] |
Der skal vælges en værdi fra Oversigt over specifikke anvendelseskategorier. |
|
Min. tilladt miljøklasse |
Den min. tilladte miljøklasse. |
minTilladtMiljoeklasse |
Heltal |
1 |
Talværdi fra 1-7. |
|
Max. tilladt miljøklasse |
Den max. tilladte miljøklasse. |
maxTilladtMiljoeklasse |
Heltal |
3 |
Talværdi fra 1-7. |
|
Særlige Forhold |
Supplerende oplysninger om planens anvendelses-, omfangs- eller udstykningsbestemmelser, som ikke kan indberettes retvisende gennem de øvrige indberetningsmuligheder. |
saerligeForhold |
string |
“en tekst om et særligt forhold” |
|
|
Angivelse af om særlige forhold påvirker nedbrydningen |
Angives som 'true', hvis de særlige forhold medfører et behov for, at bestemmelser korrigeres på deljordstykkeniveau. Angives som 'false', hvis de særlige forhold ikke medfører et behov for, at bestemmelser korrigeres på deljordstykkeniveau. |
saerligeForholdPaavirkerNedbrydning |
boolean |
false |
|
|
Omfangsbestemmelser |
Omfangsbestemmelse angiver, hvilke omfangsbestemmelser omkring f.eks. etageareal, boligenheder, m.m., der er gældende for rammen. |
omfangsbestemmelser |
Datamodel |
|
|
|
Omfangsbestemmelser reguleres ikke. |
Angives som 'true', hvis rammen ikke regulerer bebyggelsesomfang. |
omfangsbestemmelserReguleresIkke |
boolean |
true |
Enten skal denne være 'true', eller også skal der findes omfangsbestemmelser. |
|
Udstykningsbestemmelser |
Udstykning angiver, hvilke udstykningsbestemmelser omkring f.eks. min. udstykning, der gælder for rammen. |
udstykning |
Datamodel |
|
|
|
Udstykning reguleres ikke |
Angives som 'true', hvis rammen ikke regulerer udstykning. |
udstykningReguleresIkke |
boolean |
false |
Enten skal denne være 'true' eller også skal der findes udstykningsbestemmelser. |
|
Notater |
Notat er en Datamodel, der indeholder tekstfelter til beskrivelse af rammen. |
notat |
Datamodel |
|
|
Datoer
|
Felt |
Beskrivelse |
Feltnavn i REST |
Datatype |
Eksempel |
Bemærkninger vedrørende indberetning |
|---|---|---|---|---|---|
|
Forslagsdato |
Denne dato angiver, hvornår planen er oprettet som forslag. |
forslagsDato |
Dato |
“2025-04-25” |
Skal være efter indberetningsdato. |
| Høringsperiode start |
Denne dato angiver, hvornår planens høringsperiode starter. |
hoeringsperiodeStartDato |
Dato |
“2026-04-25” |
Angives før skift til status 'Forslag' og skal være efter forslagsDato. |
|
Høringsperiode slut |
Denne dato angiver, hvornår planens høringsperiode slutter. |
hoeringsperiodeSlutDato |
Dato |
“2026-04-25” |
Angives før skift til status 'Forslag' og skal for kommuneplaner være 8 uger efter hoeringsperiodeStartDato. |
| Oprindelig høringsperiode slut |
Denne dato angiver, hvornår planens høringsperiode oprindeligt var sat til at slutte. Denne er ens med hoeringsperiodeSlutDato, med mindre høringsperioden er blevet forlænget. |
oprindeligHoeringsperiodeSlutDato |
Dato |
“2026-04-25” |
Kan ikke ændres |
|
Vedtagelsesdato |
Denne dato angiver, hvornår planen vedtages i byrådet. Kan være forskellig fra planens ikraftrædelsesdato. |
vedtagelsesdato |
Dato |
“2026-04-25” |
Skal være efter hoeringsperiodeSlutDato. |
|
Indberetningsdato |
Denne dato angiver, hvornår planen først er indberettet/oprettet. Sættes automatisk, når planen bliver oprettet. |
indberetningsdato |
Timestamp |
“2024-04-25T10:32:39.171” |
Kan ikke ændres. |
Omfangsbestemmelser
|
Felt |
Beskrivelse |
Feltnavn i REST |
Datatype |
Eksempel |
Bemærkninger vedrørende indberetning |
|---|---|---|---|---|---|
|
Angivelse af specifik anvendelse |
Angivelse af, hvilken specifik anvendelse bestemmelserne gælder for. 'null' tolkes som værende generel for planen, delområdet etc. |
specifikAnvendelse |
Heltal |
2110 |
|
|
Type af omfangsbestemmelse |
Dette felt angiver, hvilken type af omfangsbestemmelse der er tale om. |
type |
Streng - Kodeliste |
“BEBYGGELSES_PROCENT” |
Se Omfangsbestemmelser, Hvilke typer der er tilladte, kan variere fra plantype til plantype. |
|
Værdi for bestemmelsen |
Dette felt angiver værdien for omfangsbestemmelsen, f.eks. antallet af etager eller boligenheder. |
value |
Heltal, Decimal, Boolean |
125 |
Mulige værdier varierer fra type til type. |
|
Enhed for bestemmelsen |
Dette felt angiver enheden for omfangsbestemmelsen. Det kan f.eks. være, at bestemmelsen gælder for området som helhed eller for hver ejendom. |
enhed |
string (Enum) |
“DEN_ENKELTE_EJENDOM” |
Der skal vælges en værdi fra Bygberegnaf Hvilke enheder, der er tilladte, varierer fra type til type. |
Udstykningsbestemmelser
|
Felt |
Beskrivelse |
Feltnavn i REST |
Datatype |
Eksempel |
Bemærkninger vedrørende indberetning |
|---|---|---|---|---|---|
|
Angivelse af specifik anvendelse |
Angivelse af, hvilken specifik anvendelse bestemmelserne gælder for. 'null' tolkes som værende generel for planen, delområdet etc. |
specifikAnvendelse |
Heltal |
2110 |
|
|
Type af udstykningsbestemmelse |
Dette felt angiver, hvilken type af udstykningsbestemmelse der er tale om. |
type |
Streng - kodeliste |
“MIN_UDSTYKNING” |
Se Udstykningsbestemmelser, Hvilke typer der er tilladte varierer fra plantype til plantype. |
|
Værdi for bestemmelsen |
Dette felt angiver værdien for udstykningsbestemmelsen, f.eks. m2 ifht min. udstykningsstørrelse eller 'null' hvis der er tale om et udstykningsforbud (ingen værdi). |
value |
Decimal, Heltal, Boolean |
125 |
mulige værdier varierer fra type til type |
Notatfelter
|
Felt |
Beskrivelse |
Feltnavn i REST |
Datatype |
Eksempel |
Bemærkninger vedrørende indberetning |
|---|---|---|---|---|---|
|
Rammetekst: Generelle anvendelsesbestemmelser |
Rammetekst om generelle anvendelsesbestemmelser. |
generelleanvendelsesbestemmelser |
Streng |
“En notattekst” |
Fritekstfelt |
|
Rammetekst: Områdets Anvendelse |
Rammetekst om områdets anvendelse. |
omraadetsAnvendelse |
Streng |
“En notattekst” |
Fritekstfelt |
|
Rammetekst: Bebyggelsesomfang og -udformning |
Rammetekst om bebyggelsesomfang og -udformning. |
bebyggelsensOmfangOgUdformning |
Streng |
“En notattekst” |
Fritekstfelt |
|
Rammetekst: Opholds- og Fritidsarealer |
Rammetekst om opholds- og fritidsarealer. |
opholdsOgFriarealer |
Streng |
“En notattekst” |
Fritekstfelt |
|
Rammetekst: Miljøforhold |
Rammetekst om miljøforhold. |
miljoeforhold |
Streng |
“En notattekst” |
Fritekstfelt |
|
Rammetekst: Infrastruktur |
Rammetekst om infrastruktur. |
infrastruktur |
Streng |
“En notattekst” |
Fritekstfelt |
|
Rammetekst: Zonestatus |
Rammetekst om zonestatus. |
zonenotat |
Streng |
“En notattekst” |
Fritekstfelt |
|
Rammetekst: Lokalplaner m.m. indenfor rammen |
Rammetekst om lokalplaner m.m. indenfor rammen. |
lokalplanermmIndenforrammen |
Streng |
“En notattekst” |
Fritekstfelt |
|
Rammetekst: Generelt |
Generelt notatfelt. |
notatgenerelt |
Streng |
“En notattekst” |
Fritekstfelt |
Kodelister til digital kommuneplan
Kodelisterne angiver de værdier, det er muligt for det givne felt at have. Nogle værdier er fælles for alle planer, mens andre er specifikke for den fuldt digitale kommuneplan. Du finder de opdaterede kodelister her.
Indberetning af digitale kommuneplaner
Den tidligere version af Plandatabekendtgørelsen (BEK nr. 1191 af 24/09/2018) krævede, at kommuneplanen skulle afleveres som et plandokument i form af en OCR-læsbar PDF-fil. Derudover skulle der foretages en digital indberetning af udvalgte planbestemmelser i henhold til datamodellerne PlanDK2+ og PlanDK3.
Med ændringen af Plandatabekendtgørelsen er det være muligt at indberette en fuldt digital retligt gældende kommuneplan efter datamodellen PlanDK4 uden upload af et PDF-dokument. Se vejledningen for hjælp til indberetning af en fuldt digital kommuneplan. Vejledningen opdateres løbende.
Det vil fortsat være muligt at indberette kommuneplaner efter det hidtidige proces på indberet.plandata.dk, hvor man uploader retningslinjer, rammer og en PDF (datamodellerne PlanDK2+ og PlanDK3).
Ændringen af Plandatabekendtgørelsen træder i kraft den 19. juni 2025.
Hvordan vises digitale kommuneplaner?
Digitale kommuneplaner indberettet efter den PlanDK4 datamodellen vises som andre kommuneplaner på kort.plandata.dk, søgelisten og planerne udstilles på Plandata.dks WFS, WMS, WMTS og REST services.
Plandata.dk har udviklet en ny fælles udstillingsplatform for digitale kommuneplaner, så kommuneplanerne udstilles i deres fulde digitale format.
Du kan finde udstillingsplatformen for digitale kommuneplaner her: kommuneplaner.plandata.dk
