Standardisering af kommuneplandata (kommuneplankataloget jf. planlovens 11 a PlanDK3 ) - registreringsbehov og begrebsdefinitioner. Version 4.0.

Standardisering af kommuneplandata (kommuneplankataloget jf. planlovens 11 a PlanDK3 ) - registreringsbehov og begrebsdefinitioner Version 4.0.3 Miljøministeriet, Naturstyrelsen 2014 1

1 Revisionshistorik Her vil ændringer i dokumentets forskellige versioner fremgå. Visionsnummereringen følger følgende regler: A) Mindre rettelser af fejl og mangler, herunder stavefejl og mindre tilføjelser af forklarende tekst. a. Rettelserne har ingen betydning for registreringsbehov og begrebsnavngivning. b. Foretages løbende. c. Kommunikeres via www.plansystem.dk d. Udgivelseskode 0.0.1 B) Større uddybende og præciserende tilføjelser og rettelser. a. Ændringerne har ingen betydning for registreringsbehov og begrebsnavngivning. b. Foretages efter behov. c. Kommunikeres via www.plansystem.dk d. Udgivelseskode 0.1.0 C) Ændringer og / eller tilføjelser af registreringsbehov, begreber og navngivning. a. Rettelserne har betydning for registreringsbehov, begrebsnavngivning mm. Ændringerne berører derfor PlansystemDK s database-setup og PlansystemDK s snitflader. b. Foretages kun efter aftale mellem KL og NST (Naturstyrelsen). Ændringer vil blive varslet. c. Kommunikeres via www.plansystem.dk d. Udgivelseskode 1.0.0 Versionsnummer Dato Beskrivelse af ændringer 1.0.0 3. april 1. version, udkast 2009 1.0.0 22. juni 1. version, endelig 2009 2.0.0 31. maj 2. version 2010 3.0.0 24. juni 3. version, udkast 2011 3.0.1 2. august Uddybende beskrivelser. Rettet feltnavne i tabel i afsnit 7.19 2011 3.1.1 30. april Tilføjelse af Fælles Biogas Anlæg under Tekniske anlæg. 2013 4.0.0 21.januar 2014 Revideret i forhold til reglerne i det opdaterede cirkulære nummer XX af DD.MM.2013 vedrørende Det digitale planregister PlansystemDK og om kommunalbestyrelsens indsendelse af planer og planforslag m.v. med tilhørende planoplysninger til registret. Nummereringen af retningslinjerne er ændret i overensstemmelse med Planloven. Retningslinjernes koder (temanumre) i PlanDK3 er dog så vidt muligt bevaret. For de enkelte retningslinjer er der indføjede specifikke registreringsvejledninger. Ændringer af kravene til registrering omfatter retningslinjerne: Detalhandelsstruktur: Ny valgmulighed Enkeltstående butikker er tilføjet kodelisten til feltet type1103. Muligheden har nummer 6 i kodelisten. Se side 22 til 26. Værdiområdet for feltet max_stor er ændret. Se side 22. Trafikanlæg eksisterende: Skal ikke indberettes. Nye objekter og kategorier baseret på FOT. Se side 27. Trafikanlæg planlagte: Nye objekter og kategorier baseret på FOT. Se 2

side 30. Tekniske anlæg deles i to: Tekniske anlæg - eksisterende: Skal ikke indberettes. Nye objekter og kategorier baseret på FOT. Se side 34 Tekniske anlæg planlagte: Nye objekter og kategorier baseret på FOT. Se side 38 Store husdyrbrug: Nyt tema. Se side 49. Bevaringsværdige landskaber deles i 2: Bevaringsværdige landskaber: Se side 66. Større sammenhængende landskaber: Nyt tema. Se side 68. Anvendelse af vandløb, søer og kystvande: Nye objekter baseret på FOT. Kategorier ændres ikke. Se side 73. Endvidere er der sket en kvalificering af beskrivelser og forklaringer. 4.0.1 18. februar 2014 4.0.2 1. april 2014 4.0.3 25. juni 2014 Mindre rettelser af forklarende tekst og stavefejl. Vær opmærksom på, at cirkulærets nummer først indsættes ved ikrafttrædelse, se side 2, 6 og 19. Rettelse af beskrivelserne i registreringsvejledning for eksisterende og planlagte trafikanlæg. Selve datamodellen er ikke rettet: Felterne eksisterendetrafikanlaegkode og planlagtrafikanlaegkode skal klassificeres således: 1 = Vej 2 = Jernbane 3 = Togstation / rangéranlæg 4 = Sti og stisystem 5 = Havn 6 = Lufthavn 7 = Parkeringsplads 8 = Transportkorridor Endvidere er tabellerne gen-nummererede ift afsnitsnummereringen. Side 11 og 12: Feltet objekt_id er farvet rødt, hvilket indikerer at det bliver udfyldt automatisk. Side 13: datoforl rettet til datoforsl Side 22: max-udvalg rettet til max_udvalg Endvidere er der foretaget mindre layout rettelser. 3

2 Indholdsfortegnelse 1 Revisionshistorik... 2 2 Indholdsfortegnelse... 4 3 Indledning... 6 4 Datamodel for Planlovens 11a-retningslinjer (PlanDK3)... 8 4.1 Lange og korte feltnavne... 8 4.2 Metadata... 9 5 Generelle registreringer... 10 5.1 Fælles PlanDK3 registreringer... 13 5.2 Geografisk registrering... 15 6 Kodelister... 15 6.1.1 Temakoder... 15 6.1.2 Oprindelseskoder... 17 6.1.3 Statuskode... 17 6.1.4 Ansvarlig myndighed (CVR kode/cvr_navn)... 18 7 Specifikke registreringer... 19 7.1 Planloven: 11a, 1: Planlagt byzone og sommerhusområder... 20 7.1.1 Specifikke retningslinjer for Planlagt byzone og sommerhusområder... 20 7.1.2 Registreringsvejledning Planlagt byzone og sommerhusområder... 21 7.2 Planloven: 11a, 2: Byformål... 22 7.3 Planloven: 11a, 3: Detailhandelsstruktur... 22 7.3.1 Specifikke retningslinjer for Detailhandelsstruktur... 22 7.3.2 Registreringsvejledning for Detailhandelsstruktur... 23 7.4 Planloven: 11a, 4: Trafikanlæg... 27 7.4.1 De eksisterende trafikanlæg... 27 7.4.2 Specifikke retningslinjer for Eksisterende trafikanlæg... 28 7.4.3 Registreringsvejledning for Eksisterende trafik anlæg... 29 7.4.4 De planlagte trafikanlæg... 30 7.4.5 Specifikke retningslinjer for Planlagte trafikanlæg... 31 7.4.6 Registreringsvejledning for Planlagte trafikanlæg... 32 7.5 Planloven: 11a, 5: Tekniske anlæg... 34 7.5.1 Eksisterende tekniske anlæg... 34 7.5.2 Specifikke retningslinjer for Eksisterende tekniske anlæg... 35 7.5.3 Registreringsvejledning for Eksisterende tekniske anlæg... 36 7.5.4 De planlagte tekniske anlæg... 38 7.5.5 Specifikke retningslinjer for Planlagte tekniske anlæg... 38 7.5.6 Registreringsvejledning for Planlagte tekniske anlæg... 39 7.6 Planloven: 11a, 6: Områder til virksomheder med særlige beliggenhedskrav... 41 7.6.1 Specifikke retningslinjer for Områder til virksomheder med særlige beliggenhedskrav, specifikke registreringsbehov... 41 7.6.2 Registreringsvejledning Områder til virksomheder med særlige beliggenhedskrav, specifikke registreringsbehov... 41 7.7 Planloven: 11a, 7: Anlæg omfattet VVM -pligt... 43 7.8 Planloven: 11a, 8: Støjbelastede arealer... 44 7.8.1 Specifikke retningslinjer for Støjbelastede arealer... 44 7.8.2 Registreringsvejledning Støjbelastede arealer... 44 7.9 Planloven: 11a, 9: Fritidsformål... 46 7.10 Planloven: 11a, 10: Særlig værdifulde landbrugsområder... 47 7.10.1 Specifikke retningslinjer for Særlig værdifulde landbrugsområder... 47 7.10.2 Registreringsvejledning Særlig værdifulde landbrugsområder... 47 7.11 Planloven: 11a, 11: Store husdyrbrug... 49 7.11.1 Specifikke retningslinjer for Store husdyrbrug... 49 7.11.2 Registreringsvejledning Store husdyrbrug... 49 7.12 Planloven: 11a, 12: Skovrejsningsområder... 52 4

7.12.1 Specifikke retningslinjer for Skovrejsningsområder... 52 7.12.2 Registreringsvejledning Skovrejsningsområder... 52 7.13 Planloven: 11a, 13: Lavbundsarealer... 54 7.13.1 Specifikke retningslinjer for Lavbundsarealer... 54 7.13.2 Registreringsvejledning Lavbundsarealer... 54 7.14 Planloven: 11a, 14: Naturbeskyttelsesområder og Økologiske forbindelser... 56 7.14.1 Specifikke retningslinjer for Naturbeskyttelsesområder... 56 7.14.2 Registreringsvejledning Naturbeskyttelsesområder... 56 7.14.3 Specifikke retningslinjer for Økologiske forbindelser... 57 7.14.4 Registreringsvejledning Økologiske forbindelser... 58 7.15 Planloven: 11a, 15: Kulturhistoriske bevaringsværdier og værdifulde kulturmiljøer... 60 7.15.1 Specifikke retningslinjer for Kulturhistoriske bevaringsværdier... 61 7.15.2 Registreringsvejledning Kulturhistoriske bevaringsværdier... 62 7.15.3 Specifikke retningslinjer for Værdifulde kulturmiljøer... 63 7.15.4 Registreringsvejledning Værdifulde kulturmiljøer... 64 7.16 Planloven: 11a, 16: Bevaringsværdige landskaber og større, sammenhængende landskaber... 66 7.16.1 Specifikke retningslinjer for Bevaringsværdige landskaber... 66 7.16.2 Registreringsvejledning Bevaringsværdige landskaber... 67 7.16.3 Specifikke retningslinjer for Større, sammenhængende landskaber... 68 7.16.4 Registreringsvejledning Større, sammenhængende landskaber... 68 7.17 Planloven: 11a, 17: Geologiske bevaringsværdier... 70 7.17.1 Specifikke retningslinjer for Geologiske bevaringsværdier... 70 7.17.2 Registreringsvejledning Geologiske bevaringsværdier... 70 7.18 Planloven: 11 a, 18: Oversvømmelsesarealer... 72 7.19 Planloven: 11a, 19: Anvendelse af vandløb, søer og kystvande... 73 7.19.1 Anvendelse af vandløb, søer og kystvande... 73 7.19.2 Specifikke retningslinjer for Anvendelse af vandløb, søer og kystvande... 73 7.19.3 Registreringsvejledning Anvendelse af vandløb, søer og kystvande... 74 7.20 Planloven: 11a, 20: Arealanvendelse i kystnærhedszone... 76 7.21 Planloven: 11a, 21: Landsplanmæssige interesser og Kommuneplanlægningen af Hovedstadsområdet... 77 7.21.1 Planloven: 3: Landsplandirektiver... 77 7.21.1 Planloven: 3: Kommuneplanlægningen i Hovedstadsområdet... 77 7.22 Planloven: 5a, stk. 3: Kystnærhedszonen... 79 8 BILAG 1: Planlovens 11a... 80 9 BILAG 2: Konverterings tabel PlansystemDK... 81 5

3 Indledning Dette er 4. version af datamodellen PlanDK3 og dermed en revideret udgave af det dokument, der samler registreringsbehov og begrebsdefinitioner af data, der vedrører Planlovens 11a. I forbindelse med kommunalreformen 2006 / 2007og den tilknyttede revision af planloven overtog kommunerne ansvaret for planlægningen af det åbne land. I planlovens 11a er der indarbejdet en liste eller et katalog over de retningslinjer, som i de kommende generationer af kommuneplaner skal afløse bestemmelserne i regionplanerne 1. For at sikre et fælles overblik over arealplanlægningen i Danmark, er det aftalt, at de kommende kommuneplaner skal indberettes i PlansystemDK. I praksis vil det betyde, at de kommuneplanretningslinjer, som er knyttet til planlovens 11a, skal indberettes sammen med kommuneplanen. Kommunernes forpligtigelse til at indberette retningslinjerne til PlansystemDK fremgår af Cirkulære nummer XX af DD.MM.2014 det digitale planregister PlansystemDK og om kommunalbestyrelsens indsendelse af planer og planforslag m.v. med tilhørende planoplysninger til registret En forudsætning for, at de nye kommuneplanretningslinjer kan indberettes i PlansystemDK og i det hele taget bidrage til fremtidens digitale forvaltning er, at de er standardiserede. Det vil sige, at der er lavet datamodeller for de enkelte kommuneplanretningslinjer, hvor registreringsbehov, begreber og sammenhænge er defineret. Når dette notat omtaler en datamodel for kommuneplanretningslinjerne menes udelukkende registreringsbehov og begrebsdefinitioner og ikke en detaljeret beskrivelse af den samlede datamodel for kommuneplanretningslinjerne og de tekniske spidsfindigheder forbundet med standardiseringen. Datamodellen er udarbejdet i et samarbejde mellem NST, KL og udvalgte kommuner. Endvidere er en række vigtige interessenter blevet hørt i processen. Der er gennemført en offentlig høring, hvor det har været muligt at kommentere modellen. Datamodelarbejdet er koordineret med tilsvarende modelarbejde i Danmarks Miljøportal. Samarbejdet med Miljøportalen sigter mod i fællesskab at udarbejde en skabelon for standardisering af arealrelaterede miljødata. Konkret betyder det, at en række generelle registreringer er de samme uanset hvilken retningslinje, der arbejdes med. Det drejer sig fx om registrering af ansvarlig myndighed, en række datoer m.v., som på denne måde registreres ens, hvad enten data gemmes i Miljøportalen eller i PlansystemDK. Udover sådanne generelle registreringer indeholder datamodellen specifikke men stadig obligatoriske registreringer for de enkelte kommuneplanretningslinjer. Notatet er derfor bygget op således, at de generelle registreringsbehov som altså er obligatoriske og ens for alle kommuneplanretningslinjerne - beskrives først. Derefter beskrives de specifikke registreringsbehov for de enkelte kommuneplanretningslinjer sorteret efter nummereringen i planlovens 11a. Det skal understreges, at det er tilstræbt at gøre datamodellen så dynamisk som muligt. Det vil sige, at kommunerne (eller andre) i egen database kan registrere flere oplysninger end modellen kræver og via modellens unikke nøgler (forskellig entydig nummerering af temaer og objekter) få disse oplysninger til at spille sammen med oplysningerne, der er indberettet til PlansystemDK. Endvidere er det tilstræbt kun at medtage de registreringer, som er nødvendige for at opfylde fælles, generelle behov. Det betyder for det første, at helt specifikke oplysninger vedrørende de enkelte retningslinjer, som kun er relevant for en enkelt institution, ikke medtages. For det andet er det kun de overordnede retningslinjer, som reguleres i planloven, der er standardiserede, og som skal indberettes til PlansystemDK. 1 Amternes regionplanretningslinjer er i forbindelse med kommunalreformen blevet tillagt retsvirkninger som et landsplandirektiv. Dette vil være gældende, indtil der via de nye generationer af kommuneplaner er vedtaget nye retningslinjer. 6

Ud over disse retningslinjer kan en kommuneplan bestå af en række andre detaljerede og for kommunen specifikke temaer, som ikke nødvendigvis kan sammenstilles med temaer i andre kommuner. Der kan både være tale om detaljeringer af de overordnede retningslinjer eller helt andre temaer, som den enkelte kommune har valgt at indarbejde i kommuneplanen. Datamodellen for kommuneplanretningslinjerne har arbejdstitlen PlanDK3. Modellen supplerer datamodellen PlanDK2, som omfatter lokalplaner, kommuneplaner, kommuneplanstrategier, -rammer, - tillæg og zonekort m.fl.. Se www.plansystemdk.dk. Ud over 11a er det fundet hensigtsmæssigt at standardisere visse temaer defineret i planloven, som er afgørende forudsætninger for realisering af kommuneplanretningslinjerne under 11a. Det drejer sig om planlovens 3 vedrørende de såkaldte Landsplandirektiver samt 5a, stk. 3 vedrørende Kystnærhedszonen. Naturstyrelsen har ansvaret for disse temaer. Datamodellen PlanDK3 er indarbejdet i PlansystemDK 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 kommunikere med PlansystemDK via systemets åbne snitflader. Datamodellen vil løbende blive vurderet og nødvendige ændringer blive gennemført, når behovet er til stede. Ændringer vil dog kræve aftaler mellem kommunerne og staten, og fremtidige revisioner af PlanDK3 og PlansystemDK vil blive varslet i forvejen. 7

4 Datamodel for Planlovens 11a-retningslinjer (PlanDK3) Dette dokument beskriver den såkaldte konceptuelle (indholdsmæssige) datamodel. Den fysiske datamodel (den tekniske opbygning) findes på PlansystemDK s hjemmeside: Plansystemdk.dk. I det nedenstående beskrives, hvordan datamodellen PlanDK3 opbygget. For hver kommuneplanretningslinje omfatter datamodellen dels en generel del, dels en del der er fælles for alle kommuneplanretningslinjerne og endelig en dataspecifik del. Dette er skitseret nedenfor. DATAMODEL Generel: -gælder for de fleste data i PlansystemDK og DAI Fælles PlanDK3: -gælder for alle Planlovens 11a-retningslinier Kapitel 5 Fælles for alle PlanDK3 temaer Specifik: -gælder udelukkende for specifikke temaer (datasæt) Kapitel 7 For hver retningslinje er beskrevet en registreringsvejledning, som definerer hvordan de forskellige oplysninger og geografi skal registreres. Registreringsvejledningen er teknisk funderet, men indeholder også planlovens krav til hvad der skal registreres. Formålet med disse registreringsvejledninger er, at data på tværs af administrative skel bliver ensartede. 4.1 Lange og korte feltnavne Navngivning af tabeller og felter er OIO- standardiseret 2. For at sikre dataudveksling mellem PlansystemDK og gængse GIS- programmer, har det været nødvendigt, at supplere feltnavnene med kortere udvekslingsnavne, da der er konstateret problemer med navne længere end 10 karakterer i visse GISprodukter. Ved upload til og download fra PlansystemDK benyttes de korte udvekslingsnavne. De lange feltnavne benyttes i de GML- filer, der benyttes til at kommunikere med PlansystemDK s SOAPservice. Bemærk endvidere at det i tab- og shp- filer kun er muligt at have tekstfelter med maksimalt 256 tegn. 2 Vedrørende OIO- regler for navngivning se: http://www.digst.dk/arkitektur-og-standarder/standardisering/datastandardisering/saadan-laver-du- OIOXML/Overhold-reglerne-NDR 8

De Lange og korte navne beskrives nærmere i de følgende afsnit, hvor de specifikke registreringer gennemgås. Se endvidere konverteringsliste for lange/korte navne i bilag 2 side 81. 4.2 Metadata Det skal understreges, at også kommuneplanretningslinjerne ligesom alle andre miljødata er omfattet af de krav, som INSPIRE stiller til registrering af metadata. Disse oplysninger er fælles for alle objekter i den enkelte retningslinje og skal derfor indberettes som metadata i den fælles metadatabase www.geodatainfo.dk og ikke medtages derfor ved indberetning til PlansystemDK. Registrering af kommuneplanretningslinjernes metadata i Geodatainfo.dk sker fælles for landsdækkende temaer af Miljøministeriet. Kommunerne skal således ikke registrere og vedligeholde metadata for kommuneplanretningslinjer i PlansystemDK. 9

5 Generelle registreringer Den generelle del indeholder de fælles elementer for hvert datasæt. Konkret betyder det, at en række generelle registreringer er de samme, uanset hvilket kommuneplanretningslinje, der arbejdes med. Det drejer sig f.eks. om registrering af ansvarlig myndighed og en række datoer m.v., som på denne måde registreres ens. Den generelle del er udarbejdet i samarbejde med Danmarks Miljøportal (DMP), hvor den samme datamodel gælder for Danmarks Arealinformation. Kommunernes Landsforening (KL) og kommunerne har ligeledes udarbejdet datamodeller for en række temaer, hvor den samme opbygning med generelle og specifikke registreringer er benyttet. Tabel 5.0.1 viser den generelle datamodel for kommuneplanretningslinjerne. Teknisk taler man om hvilke attributter, som er knyttet til det enkelte tema (retningslinje). Definitionen af disse generelle attributter er koordineret med DMP. DMP arbejder dog med flere felter. Det drejer sig om felterne Offentligkode og Offentlig, som skal angive hvorvidt data er til rådighed for alle eller kun for producenten. I PlansystemDK er alle planer med tilhørende attributter offentlige som følge af lovreglerne (undtaget planer med status kladde ). Derfor er felterne ikke nødvendige. Felterne, der er markeret med rød skrift, udfyldes automatisk af PlansystemDK. Det drejer sig blandt andet om oplysninger, som sikrer historikken, således at det til enhver tid er muligt at oplyse, hvad der var gældende på et bestemt tidspunkt. Alle disse røde felter skal kommunerne således ikke udfylde. De felter, der er markeret med blåt, skal heller ikke udfyldes, idet de kan findes vha. opslagstabeller, som indeholder oversættelser af fx koder til navne. De røde og blå felter skal således ikke uploades, og heller ikke indtastes via indberetningssiden (de tilføjes dog automatisk af systemet i forbindelse med download og visning af data på PlansystemDK). På denne måde er det tilstræbt, at så få oplysninger, som muligt skal indberettes. 10

temakode temakode Kode for temanavn/retningslinje 4 cifret heltal 1000-9999 O 1103 temanavn temanavn Temanavn/retningslinje Tekststreng 0-128 tegn O Detailhandelsstruktur objektidentifikator objekt_id Unik ID for objektet. 9-cifret heltal Entydig databasenøgle. 100000000-999999999 O 123456789 unikidentifikator uuid Unik databasenøgle over tid startdatotid systid_fra Start systemtid ISO dato/tid slutdatotid systid_til Slut systemtid ISO dato/tid initieretdatotid oprettet Systemtid for objektets oprettelse 128 bit 16 bytes O ISO dato/tid 2006-12-31T23:59:00.000+01:00 2999-12-31T23:59:00.000+01:00 2006-12-31T23:59:00.000+01:00 2999-12-31T23:59:00.000+01:00 (NULL = stadig gældende) (Udfyldt = historisk) 2006-12-31T23:59:00.000+01:00 2999-12-31T23:59:00.000+01:00 O O O Tabel 5.0.1: Generelle registreringer. Felterne svarer til den nye datamodel hos Danmarks Miljøportal (røde felter udfyldes automatisk, blå felter hentes fra andre tabeller, og skal derfor ikke udfyldes) Udvekslingsnavn Obligatorisk / Feltnavn Formål Datatype Værdiområde Eksempel frit {E6AB20EA-67E4-4C11- A051-B50A084788A3} 2006-12- 31T23:59:00.000+01:00 2006-12- 31T23:59:00.000+01:00 2006-12- 31T23:59:00.000+01:00 oprindelseskode oprindkode Kode for oprindelse for objekt 1 cifret heltal 0-6 O 4 oprindelsestekst oprindelse Oprindelse for objekt Tekststreng 0-30 O FOT/Tekniske kort statuskode statuskode Kode for gældende status 1 cifret heltal 1-4 O 1 statustekst status Gældende status Tekststreng 0-30 O kladde CVR-kode på ansvarlig cvrnumberidentifier cvr_kode 8 cifret heltal 10000000-99999999 O 55133018 myndighed legalunitname brugeridentifikator cvrname bruger_id CVR-navn på ansvarlig myndighed Brugernavn ved opdatering Tekststreng 0-128 tegn O Skov- og naturstyrelsen Tekststreng 0-128 tegn O Viborg1752 webadresseidentifikator link URL-link Tekststreng 0-1024 F http://www.link.dk/123 Shape shape Geometrisk beskrivelse af objekt Shape (2D) Punkt, linje, flade Se forklaring i nedenstående O Se forklaring i nedenstående 11

Forklaring til felter i liste 1, generelle registreringer (røde felter udfyldes automatisk, blå felter hentes fra andre tabeller, og skal derfor ikke udfyldes) Feltnavn Udvekslingsnavn Forklaring Bemærkning temakode temakode Feltet benyttes til at identificere datasættet via en kode. Se tabel 6.1.1 side 15 temanavn temanavn Feltet benyttes til at identificere datasættet via et temanavn. Do. objektidentifikator unikidentifikator startdatotid slutdatotid initieretdatotid oprindelseskode objekt_id uuid systid_fra systid_til oprettet oprindkode Entydigt ID for et objekt i et tema. Hvis objekter er opdaterede har de historiske objekter samme Objekt_id som det gældende, men forskellige UUID er (alle har forskellige UUID er, se neden for). Objekt_id en anvendes som generel reference til et objekt i et tema. Bemærk at Objekt_id ikke er unik på tværs af temaer. Et generelt unikt ID for objektet fås ved at sammensætte Tema_kode med Objekt_id. Instansobjekt ID. Unikt objekt ID for den pågældende version af objektet på tværs af datasæt og over tid. Mens et objekt bevarer samme Objekt_id fra fødsel til død, vil UUID ændres ved enhver opdatering af objektet. Dato og tidspunkt for start af objektets systemmæssige gyldighed. Sættes af systemet ved oprettelse af nye objekter, eller ved ændringer, hvor der samtidig oprettes et historisk objekt. Dato og tidspunkt genereres af systemet ved indlægning i databasen. Systemgyldighed må ikke forveksles med forvaltningsmæssig gyldighed se felterne nedenfor angående datoer for offentlighedsperiode. Dato og tidspunkt for slut af objektets systemmæssige gyldighed. Sættes af systemet ved sletning af objekter, eller ved ændringer, hvor der oprettes et historisk objekt. Dato og tidspunkt genereres af systemet ved sletning eller ændring i databasen. Systemgyldighed, må ikke skal forveksles med forvaltningsmæssig gyldighed se felterne nedenfor angående datoer for offentlighedsperiode. Dato og tidspunkt for objektets systemmæssige oprettelse. Svarer til første Systid_fra registreret på et Objekt_id, hvorved oprettelsestidspunktet altid fremgår, uanset hvor mange ændringer et objekt har gennemgået. Dato og tidspunkt genereres af systemet ved indlægning i databasen. Feltet benyttes til at angive en oprindelse (registreringsgrundlag geografisk reference) via en kode. Det er her muligt at registrere hvilken reference, der er blevet brugt ved digitaliseringen af objektet, fx. matrikelkort, 4-cm kort eller anden. Herved fås en angivelse af temaets geografiske nøjagtighed. Genereres automatisk af systemet første gang retningslinjen indberettes. Ønsker man at rette retningslinien/objektet indberettes objekt_id. Svarer til PlanID. Skal ikke indberettes. Genereres automatisk af systemet. Skal ikke indberettes. Genereres automatisk af systemet. Skal ikke indberettes. Genereres automatisk af systemet. Skal ikke indberettes. Genereres automatisk af systemet. Se tabellen i afsnit 6.1.2 side 17 oprindelsestekst oprindelse Feltet benyttes til at angive en oprindelse (registreringsgrundlag) for objektet. Se oven for. Do. statuskode statuskode Feltet benyttes til at angive en status via en kode. Se tabellen i afsnit 6.1.3 side 17 statustekst status Feltet benyttes til at angive en status for objektet. Do. cvrnumberidentifier cvr_kode Feltet benyttes til at angive CVR-koden for objektets ansvarlige myndighed. Se tabellen i afsnit 6.1.4 side 18 legalunitname cvrname Feltet benyttes til at angive navnet på objektets ansvarlige myndighed. Do. brugeridentifikator webadresseidentifik ator Shape bruger_id link shape Brugeridentifikation fra PlansystemDKs Administrationssystem. Registreres automatisk ved oprettelse eller opdatering af objekter. Er der tale om brugeridentifikation af den medarbejder, der via systemets administrations- og brugerstyringssystem har fået tildelt rettigheder til at redigere i data, registreres brugeren automatisk. URL-adresse, der kan anvendes til opslag på objektniveau. Skal være offentlig tilgængelig. PlansystemDK tager en kopi af planen og lægger den i PlansystemDK. Geometrisk registrering af objekt styres af database Koordinatpræcision defineret til 0,001 (millimeter) Skal ikke indberettes. Genereres automatisk af systemet. Link til planen, fx. kommunens hjemmeside. Planens geografi se registreringsvejledning. 12

5.1 Fælles PlanDK3 registreringer Ud over de generelle registreringer (Tabel 5.0.1) er der specielt for kommuneplanretningslinjerne en række registreringer, som er ens for alle (Tabel 5.1.1): Tabel 5.1.1: Registreringer som er ens for alle kommuneplanretningslinjer (røde felter udfyldes automatisk, nedarves fra kommuneplan eller - tillæg) Feltnavn Udvekslingsnavn Formål Datatype Værdiområde Obligatorisk / frit Eksempel lovgivningsbeskrivelsestekst lovgivning Angivelse af lovparagraf som stiller krav om registrering kommuneplanidentifikator komplan_id Angivelse af PlanID for overordnet kommuneplan kommuneplantillaegidentifikator komtil_id Angivelse af PlanID for overordnet kommuneplantillæg Tekststreng 0-128 O Planloven 11a, pkt. 1 9-cifret heltal 100000000-999999999 9-cifret heltal 100000000-999999999 O (afhængig af om temaet er knyttet til en kommuneplan eller kommuneplantillæg) O (afhængig af om temaet er knyttet til en kommuneplan eller kommuneplantillæg) plannr Plannr Plannummer Tekststreng 0-30 tegn O E33 plangrundlagtekst plangrund Angivelse af plangrundlag, kommuneplan eller kommuneplantillæg. forslagdato datoforsl Dato for planforslagets vedtagelse startdate datostart Dato for start af offentlighedsperiode enddate datoslut Dato for afslutning af offentlighedsperiode vedtagetdato datovedt Dato for den endelige plans vedtagelse ikrafttraedelsedato datoikraft Dato for planens ikrafttrædelse aflystdato datoaflyst Dato for planens aflysning specifikaflystdato Sp_datoafl Dato for aflysning af det specifikke objekt bemaerkningtekst Bem Bemærkning / Valgfri tekst Tekststreng 0-128 tegn O 8- cifret heltal 00000000-99999999 8- cifret heltal 00000000-99999999 8- cifret heltal 00000000-99999999 8- cifret heltal 00000000-99999999 8- cifret heltal 00000000-99999999 8- cifret heltal 00000000-99999999 8- cifret heltal 00000000-99999999 Tekststreng 0-254 tegn F O (afhængig af status) O (afhængig af status) O (afhængig af status) O (afhængig af status) O (afhængig af status) O (afhængig af status) O (afhængig af status) 123456789 123456790 Kommuneplan for Århus Kommune 2009 til 2021 20080110 20080110 20080413 20080601 20080601 20130701 20130801 Fri tekst 13

Tabel 5.1.2, Forklaring til tabel 5.1.1: Registreringer som er ens for alle kommuneplanretningslinjer (røde felter udfyldes automatisk) Feltnavn Udvekslingsnavn Forklaring Bemærkning lovgivningbeskrivelsestekst lovgivning Feltet benyttes til at identificere datasættet Udfyldes automatisk på baggrund af valg af tema ved indberetning/upload. kommuneplanidentifikator komplan_id PlanID for overordnet kommuneplan kommuneplantillaegidentifikator komtil_id PlanID for overordnet kommuneplantillæg plannr plannr Entydigt plannummer for et objekt i et tema plangrundlagtekst plangrund Navn på overordnet plan, dvs. PlanNavn for kommuneplan eller kommuneplantillæg. Udfyldes automatisk på baggrund af oplysninger hentet fra overordnet kommuneplan eller kommuneplantillæg. forslagdato datoforl Dato for byrådets vedtagelse af planen. Udfyldes automatisk på baggrund af oplysninger hentet fra overordnet kommuneplan eller kommuneplantillæg. startdate datostart Dato for starten af offentlighedsperioden. Udfyldes automatisk på baggrund af oplysninger hentet fra overordnet kommuneplan eller kommuneplantillæg. enddate datoslut Dato for afslutningen af offentlighedsperioden. Udfyldes automatisk på baggrund af oplysninger hentet fra overordnet kommuneplan eller kommuneplantillæg. vedtagetdato datovedt Dato for byrådets vedtagelse af planen. Udfyldes automatisk på baggrund af oplysninger hentet fra overordnet kommuneplan eller kommuneplantillæg. ikrafttraedelsedato datoikraft Dato for planens ikrafttrædelse. Udfyldes automatisk på baggrund af oplysninger hentet fra overordnet kommuneplan eller kommuneplantillæg. aflystdato datoaflyst Dato for byrådets beslutning om planens aflysning. Udfyldes automatisk på baggrund af oplysninger hentet fra overordnet kommuneplan eller kommuneplantillæg. specifikaflystdato Sp_datoafl Dato for byrådets beslutning om det specifikke objekts aflysning. bemaerkningtekst bem Bemærkning / Valgfri tekst 14

5.2 Geografisk registrering Udover almindelige attributter består en kommuneplanretningslinje af den geografiske registrering (digitalisering foretaget i et GIS-program). Den geografiske digitalisering skal ske efter GST s anvisninger i ét landsdækkende koordinatsystem for de geografiske digitaliseringer (UTM zone 32, Euref89). Digitaliseringerne af de geografiske objekter i de enkelte retningslinjer er beskrevet i feltet shape i tabel 1. Det er kun muligt for en kommune at registrere polygoner, der ligger inden for kommunens geografiske afgrænsning. Endvidere er kun medtaget oplysninger, som ikke kan hentes ad anden vej. For eksempel kan en del oplysninger genereres i databasen eller i GIS-system på baggrund af allerede tilgængelige oplysninger. Således vil fx de enkelte objekters arealer og omkreds altid kunne udregnes ved simpel GIS-analyse. 6 Kodelister Værdier i Tema_kode fra 1000 til 1999 er forbeholdt PlansystemDK. Værdier i Tema_kode fra 2000 til 2999 er forbeholdt Danmarks Arealinformation. Koderne 1000 til 1100 er reserveret til en fremtidig omlægning af PlanDK2. PlanDK3 starter således med 1101. 6.1.1 Temakoder Tema-kode Tematekst Planloven 1101 Planlagte byzoner og sommerhusområder Planloven: 11a, 1 1102 Byformål Planloven: 11a, 2 1103 Detailhandelsstruktur Planloven: 11a, 3 1104 Eksisterende Trafikanlæg Planloven: 11a, 4 1105 Planlagte Trafikanlæg Planloven: 11a, 4 1106 (se 1144) Planlagte Tekniske anlæg, herunder fælles biogasanlæg Planloven: 11a, 5 1107 Områder til virksomheder med særlige beliggenhedskrav Planloven: 11a, 6 1108 Anlæg omfattet af VVM- og SMV-pligt Planloven: 11a, 7 1109 Støjbelastede arealer Planloven: 11a, 8 1110 Fritidsformål Planloven: 11a, 9 1111 Særlig værdifulde landbrugsområder Planloven: 11a, 10 1112 Skovrejsningsområder Planloven: 11a, 12 1113 Lavbundsarealer Planloven: 11a, 13 1114 Naturbeskyttelsesområder Planloven: 11a, 14 1115 Økologiske forbindelser Planloven: 11a, 14 1116 Kulturhistoriske bevaringsværdier Planloven: 11a, 15 1117 Værdifulde kulturmiljøer Planloven: 11a, 15 1118 (se 1145) Bevaringsværdige landskaber Planloven: 11a, 16 1119 Geologiske bevaringsværdier Planloven: 11a, 17 1120 Anvendelse af vandløb, søer og kystvande Planloven: 11a 19 1121 Arealanvendelse i kystnærhedszone Planloven: 11a, 120 1122-39 Hovedstadsområdet Planloven: 11a, 21 1140 Landsplandirektiver Planloven: 3 1141 Kystnærhedszonen Planloven: 5a, stk. 3 1142 Store Husdyrbrug Planloven: 11a, stk. 11 1143 Oversvømmelsesarealer Planloven: 11a, stk. 18 1144 (se 1106) Eksisterende Tekniske anlæg, herunder fælles Planloven: 11a, 5 biogasanlæg 1145 (se 1118) Større sammenhængende landskaber Planloven: 11a, 16 Andre PlanDK3 temaer, som ikke er knyttet til Planloven (er beskrevet i selvstændige dokumenter): 1201 Kloakopland 15

1202 Renseklasse 1203 Forsyningområde 1204 TilslutningspligtOmraade 1205 Forsyningsforbudområde 1206 Udtræden af spildevandsforsyning mulig 16

6.1.2 Oprindelseskoder Oprindelseskode Reference type Bemærkning 0 Ikke udfyldt 1 Ortofoto Der skelnes ikke mellem forskellige producenter og forskellige årgange. 2 Matrikelkort Matrikelkort fra KMS (København og Frederiksberg). Det forudsættes, at der benyttes opdaterede matrikelkort for datoen for planens indberetning 3 Opmåling Kan være med GPS, andet instrument el. lign. Det er ikke et udtryk for præcision, men at det er udført i marken. 4 FOT / Tekniske kort FOT, DTK, Danmarks Topografiske kortværk eller andre raster kort samt kommunernes tekniske kort eller andre vektorkort. Indtil FOT er landsdækkende benyttes kort10 (jf. overgangsregler for FOT) 5 Modelberegning GIS analyser eller modellering 6 Tegning Indscannet papirtegning 6.1.3 Statuskode Status-kode Statustekst 1 Kladde 2 Forslag 3 Vedtaget 4 Aflyst 17

6.1.4 Ansvarlig myndighed (CVR kode/cvr_navn) CVR kode CVR navn CVR kode CVR navn CVR kode CVR navn 66137112 Albertslund Kommune 29189447 Holbæk Kommune 29190658 Region Sjælland 60183112 Allerød Kommune 29189927 Holstebro Kommune 29190909 Region Syddanmark 29189692 Assens Kommune 29189889 Horsens Kommune 29189609 Ringkøbing-Skjern Kommune 58271713 Ballerup Kommune 55606617 Hvidovre Kommune 18957981 Ringsted Kommune 29189765 Billund Kommune 19501817 Høje-Taastrup Kommune 29189404 Roskilde Kommune 26696348 Bornholms RegionsKommune 70960516 Hørsholm Kommune 29188378 Rudersdal Kommune 65113015 Brøndby Kommune 29189617 Ikast-Brande Kommune 65307316 Rødovre Kommune 29189501 Brønderslev Kommune 11931316 Ishøj Kommune 23795515 Samsø Kommune 10859387 Danmarks Miljøundersøgelser 29189439 Jammerbugt Kommune 29189641 Silkeborg Kommune 55145016 GEUS 29189595 Kalundborg Kommune 29189633 Skanderborg Kommune 57607556 Det Jordbrugsvidenskabelige Fakultet 29189706 Kerteminde Kommune 29189579 Skive Kommune 12881517 Dragør Kommune 29189897 Kolding Kommune 29188505 Slagelse Kommune 29188386 Egedal Kommune 62965916 Kort- og Matrikelstyrelsen 68534917 Solrød Kommune 29189803 Esbjerg Kommune 26489865 Kulturarvsstyrelsen 29189994 Sorø Kommune 31210917 Fanø Kommune 64942212 Københavns Kommune 29208654 Stevns Kommune 29189714 Favrskov Kommune 29189374 Køge Kommune 29189951 Struer Kommune 29188475 Faxe Kommune 29188955 Langeland Kommune 29189730 Svendborg Kommune 29188335 Fredensborg Kommune 29188548 Lejre Kommune 29189978 Syddjurs Kommune 69116418 Fredericia Kommune 29189935 Lemvig Kommune 29189773 Sønderborg Kommune 11259979 Frederiksberg Kommune 29188572 Lolland Kommune 29189560 Thisted Kommune 29189498 Frederikshavn Kommune 11715311 Lyngby-Taarbæk Kommune 29189781 Tønder Kommune 29189129 Frederikssund Kommune 45973328 Læsø Kommune 20310413 Tårnby Kommune 29188327 Furesø Kommune 29189455 Mariagerfjord Kommune 19583910 Vallensbæk Kommune 20814616 FødevareErhverv 29189684 Middelfart Kommune 29189811 Varde Kommune 29188645 Faaborg-Midtfyn Kommune 25798376 Miljøstyrelsen 29189838 Vejen Kommune 19438414 Gentofte Kommune 41333014 Morsø Kommune 29189900 Vejle Kommune 62761113 Gladsaxe Kommune 33157274 Naturstyrelsen 29189471 Vesthimmerlands Kommune 65120119 Glostrup Kommune 29189986 Norddjurs Kommune 29189846 Viborg Kommune 44023911 Greve Kommune 29188947 Nordfyns Kommune 29189676 Vordingborg Kommune 29188440 Gribskov Kommune 29189722 Nyborg Kommune 28856075 Ærø Kommune 29188599 Guldborgsund Kommune 29189625 Næstved Kommune 29189854 Aabenraa Kommune 29189757 Haderslev Kommune 32264328 Odder Kommune 29189420 Aalborg Kommune 29188416 Halsnæs Kommune 35209115 Odense Kommune 55133018 Aarhus Kommune 29189587 Hedensted Kommune 29188459 Odsherred Kommune 64502018 Helsingør Kommune 29189668 Randers Kommune 63640719 Herlev Kommune 29189463 Rebild Kommune 29189919 Herning Kommune 29190623 Region Hovedstaden 29189366 Hillerød Kommune 29190925 Region Midtjylland 29189382 Hjørring Kommune 29190941 Region Nordjylland 18

7 Specifikke registreringer I det følgende beskrives de registreringer (obligatoriske og frivillige), som er specifikke for de enkelte retningslinjer. Der mindes om, at den enkelte kommune eller andre til enhver tid kan registrere flere faglige oplysninger til de enkelte objekter og gemme disse oplysninger i egne lokale databaser. Ved hjælp af de generelle felter Tema_id og Objekt_id kan sammensættes en unik ID for det enkelte objekt og de lokale oplysninger kan via denne ID sammenkædes med de obligatoriske felter i PlansystemDK. Som det vil fremgå i det følgende er nogle retningslinjer som fastsættes i planlovens 11 a ikke forbundet med krav om specifikke registreringer. Dette hænger sammen med, at lovens krav om, at kommuneplanen skal indeholde retningslinjer for de pågældende punkter kan opfyldes på baggrund af andre krævede registreringer. Fx vil nogle retningslinjer kunne beskrives umiddelbart på baggrund af de rammer for lokalplanerne, som kommunen i forvejen skal indberette til PlansystemDK efter lovens 11b samt cirkulære nr. XX af DD. MM 2014. Også på denne måde er det forsøgt at sikre, at kun de nødvendige registreringer bliver indberettet, samt at kommunerne ikke belastes af dobbeltregistreringer. Det skal understreges, at det følgende kun omhandler de registreringer og de tilknyttede begreber, som er nødvendige for indberetning til PlansystemDK. Vedrørende det planfaglige indhold af de enkelte retningslinjer henvises til Oversigt over statslige interesser i kommuneplanlægningen 2013, Miljøministeriet 2011 med tilhørende tilføjelser, se.: http://www.naturstyrelsen.dk/planlaegning/landsplanlaegning/oversigt_over_statslige_interesser/ Ud over de obligatoriske registreringer beskrives også en registreringsvejledning for hver kommuneplanretningslinje. Disse er beskrevet, således at de kan læse separat for hver retningslinje en del gentagelser på tværs af retningslinjerne kan derfor forekomme. 19

7.1 Planloven: 11a, 1: Planlagt byzone og sommerhusområder Lovtekst: Udlægning af arealer til byzoner og sommerhusområder. Temakode: 1101 Retningslinjen efter planlovens 11 a nr. 1 angiver afgrænsning af hvilke landzonearealer, der kan overføres til byzone eller sommerhusområde. Retningslinjen har sammenhæng med de fremtidige zonebestemmelser, der er registreres i kommuneplanernes rammer for lokalplanlægningen, også kaldet kommuneplanrammerne. Retningslinjen omhandler kommuneplanlagte byzoner og sommerhusområder. De eksisterende afgrænsninger af byzone og sommerhusområde indberettes til PlansystemDK efter datamodellen PlanDK2 (se www.plansystem.dk). 7.1.1 Specifikke retningslinjer for Planlagt byzone og sommerhusområder Tabel 7.1.1.1 Byzone og sommerhusområder, specifikke registreringsbehov: Feltnavn *) Formål Eksempel type1101 Kode for fremtidig planlagt zonestatus: 1 = fremtidig byzone inden for kommuneplanperioden 2 = potentielt fremtidigt område til byzone 3 = fremtidigt sommerhusområde inden for kommuneplanperioden 4 = potentielt fremtidigt sommerhusområde 5 = fremtidig tilbageførelse af byzone til landzone 6 = fremtidig tilbageførelse af sommerhusområde til landzone Obligatoris k/ Frit Datatype Værdiområde Bemærkning 1 O Heltal 1-6 Kommunerne kan kun udlægge nye sommerhusområder uden for kystnærhedszonen. Dog udpeges i landsplandirektiv fra 2005 specielle arealer inden for kystnærhedszonen, hvor visse kommuner ved hjælp af lokalplan kan udlægge sommerhusområder. Vaerdi1101 Tekst for planlagt zonestatus. Læsevenlig udgave af ovenstående. = fremtidig byzone inden for kommunep lanperiode n O Tekst 100 tegn *) Vær opmærksom på lange og korte feltnavne, se afsnit 4.1: Langt feltnavn Kort feltnavn zonestatuskode type1101 Skal ikke indberettes, genereres automatisk af systemet. På baggrund af ovenstående er følgende begreber defineret: Tabel 7.1.1.2 Byzone og sommerhusområder, begrebsspecifikationer: Begreb Fremtidig byzone Potentielt fremtidigt område til byzone Fremtidigt sommerhusområde Begrebsdefinition Områder som planlægges overført til byzone ved lokalplan inden for kommuneplanperioden Områder som på længere sigt (ud over kommuneplanperioden) kan komme i spil som byzone Områder som planlægges overført til sommerhusområde inden for kommuneplanperioden 20

Potentielt fremtidigt sommerhusområde Fremtidig tilbageførelse fra byzone til landzone Fremtidig tilbageførelse fra sommerhusområde til landzone Områder som på længere sigt (ud over kommuneplanperioden) kan komme i spil som sommerhusområder Områder som planlægges tilbageført fra byzone til landzone inden for kommuneplanperioden Områder som planlægges tilbageført fra sommerhusområde til landzone inden for kommuneplanperioden 7.1.2 Registreringsvejledning Planlagt byzone og sommerhusområder Tabel 7.1.2.1 Emne Registreringsvejledning Beskrivelse Udlægning af arealer til kommuneplanlagte byzoner og sommerhusområder skal ske efter retningslinjerne beskrevet i lovbemærkningerne (bemærkninger til L587, 11a, stk. 1) samt i Oversigt over statslige interesser i kommuneplanlægningen, afsnit 3.1. Datafelter / attributter Feltet zonestatuskode benyttes til at anføre koden for fremtidig planlagt zonestatus (se under Klassificering / tematisering ) Datatypen er heltal. Der skal angives et heltal mellem 1 og 6. Feltet kan fx bruges ved søgning til at udpege områder med bestemt planlagt zonestatus. Feltet er obligatorisk! Tomt felt (værdien null ) accepteres ikke. Klassificering / tematisering Ajourføring Objekterne klassificeres således: 1 = fremtidig byzone inden for kommuneplanperioden 2 = potentielt fremtidigt område til byzone 3 = fremtidigt sommerhusområde inden for kommuneplanperioden 4 = potentielt fremtidigt sommerhusområde 5 = fremtidig tilbageførelse af byzone til landzone 6 = fremtidig tilbageførelse af sommerhusområde til landzone Retningslinjen ajourføres efter reglerne i planloven. Den samlede retningslinje ajourføres i forbindelse med vedtagelse af den samlede kommuneplan (fx ved den løbende firårige revision af kommuneplanen). Enkeltområder kan revurderes, opdateres eller suppleres efter planlovens bestemmelser om kommuneplantillæg. Ajourføring af retningslinjen omfatter opdatering af data i PlansystemDK, hvilket kan betyde både geometriske og attributmæssige ændringer. Lovgivning Temaet / retningslinjen er reguleret i Lov nr. 587 af 27.5 2013, 11 a, nr. 1). Minimum areal for objekter Objekttype Entydige objekter mellem objekter Der en ingen specifikke krav til objekternes størrelse. Det er dog hensigten, at der udpeges større, sammenhængende områder. Alle objekter skal være flader. Punkter og linjer accepteres ikke. Det er tilladt at bruge multipartobjekter / multipolygoner (adskilte men grupperede områder), når delområder har samme klassificering. Der må ikke være overlap eller huller mellem tilstødende objekter. Der etableres sammenfaldende grænser (fælles geometri) mellem tilstødende objekter ved brug af snapfunktioner eller lignende. Områder, der støder op til hinanden og har samme klassificering, skal sammenlægges til ét område. Efter den gældende datamodel, PlanDK2, skal såvel nuværende som fremtidig zonestatus registreres i lokalplanerne og kommuneplanrammerne. Retningslinjens geografiske udstrækning vil derfor ofte følge kommuneplanrammerne. Zoneregistreringerne i kommuneplanrammerne indeholder dog ikke altid entydige zoneudpegninger, men ofte en kombination af fx by- og landzone. Derfor vil retningslinjernes registreringer undertiden skære rammerne over. Har retningslinjerne imidlertid et geometrisk sammenfald med kommuneplanrammernes yder grænse (periferi) skal retningslinjernes polygoner være snappet til kommuneplanrammernes geografi. med objekter i andre datasæt Objekternes afgrænsning vil ofte følge grænser fra objekter i fx FOT, matrikelkort eller andet teknisk grundkort. Den primære geografiske reference er FOT. 21

Undertiden vil områderne også følge / støde op til andre plan- og miljøtemaer, fx afgrænsningen af andre kommuneplanretningslinjer. Objekter må ikke overlappe med kommunegrænsen, men kan overlappe med andre tematiske temaer, herunder andre kommuneretningslinjer. 7.2 Planloven: 11a, 2: Byformål Lovtekst: beliggenheden af områder til forskellige byformål, f.eks. boligformål, erhvervsformål, blandede byfunktioner, beliggenheden af offentlige institutioner, serviceformål, byomdannelsesområder m.v. Temakode: 1102 11a, nr..2 indeholder ikke nye registreringer, da byformål registreres i forbindelse med kommuneplanrammerne - som er standardiseret i forbindelse med PlansystemDK (PlanDK2). 7.3 Planloven: 11a, 3: Detailhandelsstruktur Lovtekst: den kommunale detailhandelsstruktur, herunder afgrænsning af bymidter, bydelscentre, lokalcentre, områder til særlig pladskrævende varer og eventuelle aflastningsområder samt fastsættelse af det maksimale bruttoetageareal til butiksformål for det enkelte område og maksimale bruttoetagearealer for de enkelte butikker i de enkelte områder, herunder også for enkeltstående butikker, jf. Planlovens, jf. 5 l- 5 r. Temakode: 1103 7.3.1 Specifikke retningslinjer for Detailhandelsstruktur Tabel 7.3.1.1 Detailhandelsstruktur, specifikke registreringsbehov: Feltnavn** Formål Eksempel Obligatorisk/ Frit Datatype Værdiområde Bemærkning type1103 Kode for detailhandelskategorier: 1 = bymidter 2 = bydelscentre 3 = aflastningsområder 4 = lokalcentre 5 = områder til butikker med særlig pladskrævende varegrupper 6 = enkeltstående butikker 1 O Tal 1 tegn 1-6 Se planlovens kapitel 2 d. vaerdi1103 Tekst for detailhandelskategorier. Læsevenlig udgave af ovenstående. bymidter O Tekst 100 tegn Skal ikke indberettes, genereres automatisk af systemet. max_daglig* max_udvalg* max_plads* Angivelse af den maksimal tilladelige butiksstørrelse (etagemeter) for butikker med dagligvarer. Angivelse af den maksimal tilladelige butiksstørrelse (etagemeter) for butikker med udvalgsvarer. Angivelse af den maksimal tilladelige butiksstørrelse (etagemeter) for butikker med særligt pladskrævende varegrupper. 2.500 O* Tal 4 tegn 0 3.500 Se planlovens kapitel 2 d. 500 O* Tal 4 tegn 0 2.000 Se planlovens kapitel 2 d. 20.000 O* Tal 6 tegn 0 999.999 Se planlovens kapitel 2 d. 22

max_stor* max_areal Angivelse af den maksimal tilladelige butiksstørrelse (etagemeter) for butikker for store udvalgsvarebutikker over 2.000 m2. Angivelse af det samlede tilladelige butiksareal inden for området 4.000 O* Tal 6 tegn 2.000 999.999 50.000 O Tal 7 tegn 0 9.999.999 Se planlovens kapitel 2 d. Se planlovens kapitel 2 d. *) Den maksimal tilladelige butiksstørrelse skal angives for alle butikstyper, der planlægges for. Der kan forekomme flere butikstyper i samme område. Mindst ét af felterne mærket med * skal være udfyldt. **) Vær opmærksom på lange og korte feltnavne, se afsnit 4.1: Langt feltnavn Kort feltnavn detailhandelkode type1103 detailhandeltekst vaerdi1103 dagligmaximummeasure max_daglig udvalgmaximummeasure max_udvalg pladsmaximummeasure max_plads stormaximummeasure max_stor arealmaximummeasure max_areal På baggrund af ovenstående er følgende begreber defineret: Tabel 7.3.1.2 Detailhandelsstruktur, begrebsspecifikationer: Begreb Detailhandelsstruktur Begrebsdefinition Strukturen for afgrænsning af detailhandelsområder opdelt efter 5 kategorier: bymidter, bydelscentre, områder til særlig pladskrævende varer, lokalcentre og områder til butikker med særlig pladskrævende varegrupper. bymidter Den centrale del af en by, jf. planlovens 5 m, stk. 1. bydelscentre aflastningsområder lokalcentre områder til butikker med særlig pladskrævende varegrupper Enkeltstående butikker max_daglig max_udvalg max_plads max_stor max_areal Den centrale del af en bydel uden for bymidten i byer med 20.000 indbyggere og derover, jf. planlovens 5 m, stk. 1. Områder til aflastning af bymidter og bydelscentre Den centrale del af en mindre bydel Områder til butikker med særlig pladskrævende varegrupper, jf. planlovens 5 n stk. 1 nr. 3 Område til enkeltstående butikker Den maksimal tilladelige butiksstørrelse for butikker med dagligvarer inden for området angivet i etagemeter (m2) Den maksimal tilladelige butiksstørrelse for butikker med udvalgsvarer inden for området angivet i etagemeter (m2) Den maksimal tilladelige butiksstørrelse for butikker med pladskrævende varegrupper for området angivet i etagemeter (m2) Den maksimal tilladelige butiksstørrelse for butikker med store udvalgsvarebutikker over 2.000 m2 inden for området angivet i etagemeter (m2) Det maksimalt tilladelige samlede butiksareal inden for hvert område angivet i etagemeter (m2) 7.3.2 Registreringsvejledning for Detailhandelsstruktur Tabel 7.3.2.1 Registreringsvejledning Emne Beskrivelse Registreringsvejledning Efter planloven skal kommunerne registrere afgrænsninger, som omfatter områdetyperne: bymidter, bydelscentre og aflastningsområder samt lokalcentre og områder til butikker med særlig pladskrævende varer. Områdeafgrænsningerne til detailhandel kan således bestå af de 5 nævnte kategorier. For hvert område skal endvidere oplyses den maksimalt tilladelige butiksstørrelse og det samlede maksimale butiksareal i området. Afgrænsningerne skal ske efter reglerne i planlovens kapitel 2 d og 11 a, stk. 1, nr. 3, 23

11 b, stk. 1, nr. 7 samt 11 e, stk. 4 til 6. Ønsker kommunen at udvide afgrænsningen af bymidter og bydelscentre, som er over 5000 m², skal dette ske efter en statistisk metode, jf. planlovens 5 m, stk. 2, som udmøntet i bekendtgørelse om afgrænsning af bymidter og bydelscentre nr. 1093 af 11. september 2007. Afgrænsningen skal fremgå af hovedstrukturen jf. 11 a stk. 1, nr. 3. Kommunen skal herudover fastsætte det maksimale butiksareal for enkeltstående butikker uden for center-strukturen (de ovennævnte 5 kategorier). Registreringerne skal ske efter retningslinjerne beskrevet i lovbemærkningerne (bemærkninger til L587, 11a, nr. 3) samt i Oversigt over statslige interesser i kommuneplanlægningen, afsnit 3.3. Datafelter / attributter Feltet detailhandelkode (type1103) benyttes til at anføre koden for detailhandelskategorier. Datatypen er heltal. Der skal angives et heltal mellem 1 og 5 (se Klassificering / tematisering nedenfor. Feltet kan fx bruges ved søgning til at udpege områder med bestemt planlagt detailhandelskategori. Feltet er obligatorisk! Tomt felt (værdien null ) accepteres ikke. Feltet max_areal benyttes til at angive det maksimalt tilladelige samlede butiksareal inden for hvert område angivet i etagemeter. Datatypen er heltal som angiver butiksarealet som etagemater målt i m 2. Der skal angives et heltal med op til 7 cifre. Feltet kan fx bruges ved søgning til at udpege detailhandelskategorier med en bestemt størrelse. Feltet er obligatorisk! Tomt felt (værdien null ) accepteres ikke. Felterne max_daglig, max_udvalg, max_plads, max_stor benyttes til at angive den maksimalt tilladelige butiksstørrelse for butikker med henholdsvis dagligvarer, udvalgsvarer, pladskrævende varegrupper, store udvalgsvarebutikker. Datatypen for alle 4 typer er heltal som angiver butiksarealet som bruttoetageareal målt i m 2. For max_daglig angives et heltal op til 3.500 (grænse jf. planlovens 5 q og 5 r). For max_udvalg angives et heltal op til 2.000 (grænse jf. planlovens 5 q og 5 r). For max_plads, angives et heltal med op til 6 cifre. For max_stor angives et heltal >= 2000 med op til 6 cifre Felterne kan fx bruges ved søgning til at udpege detailhandelskategorier med en bestemt størrelse. Mindst ét af felterne skal være udfyldt. (værdien null i alle 4 felter accepteres ikke). Klassificering / tematisering Ajourføring Feltet detailhandelkode klassificeres således: 1 = bymidter 2 = bydelscentre 3 = aflastningsområder 4 = lokalcentre 5 = områder til butikker med særlig pladskrævende varegrupper 6 = Enkeltstående butikker Retningslinjen ajourføres efter reglerne i planloven. Den samlede retningslinje ajourføres i forbindelse med vedtagelse af den samlede kommuneplan (fx ved den løbende firårige revision af kommuneplanen). Enkeltområder kan revurderes, opdateres eller suppleres efter planlovens bestemmelser om kommuneplantillæg. Ajourføring af retningslinjen omfatter opdatering af data i PlansystemDK, hvilket kan betyde både geometriske og attributmæssige ændringer. Lovgivning Temaet / retningslinjen er reguleret i Lov nr. 587 af 27.5 2013, 11 a, pkt. 3). Minimum areal for objekter Objekttype Entydige objekter mellem objekter Der en ingen specifikke krav til objekternes størrelse. Det er dog hensigten, at der udpeges sammenhængende områder. Alle objekter skal være flader. punkter og linjer accepteres ikke. Det er tilladt at bruge multipartobjekter / multipolygoner (adskilte men grupperede områder) når delområder har samme klassificering). Der må ikke være overlap eller huller mellem tilstødende objekter. Der etableres sammenfaldende grænser (fælles geometri) mellem tilstødende objekter ved brug af snap-funktioner eller lignende. Områder, der støder op til hinanden og har samme klassificering skal sammenlægges til 24