FKG. Kravspecifikation for kommunalt webbaseret geodatasystem. FKG Fælleskommunalt geodatasamarbejde



Relaterede dokumenter
Strategi Danmarks Miljøportal

GIS-strategiplan Helsingør Kommune. GIS-strategiplan 2008

Fælles udbud af webgis til sagsbehandling

Faktaark for Byg og Miljø

KL-geodataimplementeringsprojekt

Kalundborg Kommunes Strategi for Geodataområdet - et fundament for digitalisering

Business case for projekt Fælleskommunalt Geodatasamarbejde

It-principper. Bilag 1 til It- og Digitaliseringsstrategi for Sønderborg Kommune

uddybende beskrivelse af processen i forbindelse med fremsøgning af sagsakter?

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

DEN FÆLLESKOMMUNALE RAMMEARKITEKTUR

Den fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering

IT-ARKITEKTURPRINCIPPER 2018

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

Serviceplatformen informationsmateriale. Leverandørmøde 7. februar 2013

Informationsmøde vedrørende Proof of concept for en integrationsplatform

Bilag 3 - Løsningsbeskrivelse. over kravopfyldelse. Undervisningsministeriets udbud - Fremme af evalueringskulturen. 28. juni 2005

PLAN OG UDVIKLING GIS-STRATEGI

Julemøde i Vest. 6. december 2012 Lars Klindt Mogensen lkm@lifa.dk

Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer)

OIS - Applikationskatalog

FKG datamodellen Version ArcGIS integration Sidste revisionsdato: 23. maj 2014

SDI NUUK den 23. november 2010 Tema: Hvad er grundlaget for SDI? Erfaringer fra Danmark

Indhold. Grundmodul. Tillægsmoduler. Teknologisk opbygning og indhold. Mulighed for udbygning. Forretningsmæssig funktionalitet

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade København Ø

Klik her for at angive tekst.

Effektiv sagsbehandling og hurtig borgerservice

GIS-handlingsplan 2015 NOVEMBER 2015

Guide til integration med NemLog-in / Brugeradministration

HRKS Samarbejde om geodata. Philip Hartmann By- og Miljødirektør i Gladsaxe Kommune

Arkitekturrapport: MDB Min Digitale Byggesag

BBR - Kontekstdiagram

FællesKommunalt Geodatasamarbejde

Introduktion til UNI-Login for udbydere

Krav og vejledning til kommunernes fremtidige it-udbud

De fællesoffentlige samarbejder inden for geodataområdet. Kåre Clemmesen, KMS 10. maj 2011

Vilkår for brug af Støttesystemet Sags- og Dokumentindeks

Geodatastyrelsens strategi

Programbeskrivelse. 5.5 Kommunal implementering af grunddata. 1. Formål og baggrund. Juni 2016

Version 1.0. Vejledning til brug af Støttesystemet Organisation

Folkekirkens It s arkitekturprincipper

SAPAs forretningsmæssige behov i relation til Dialogintegration. SAPAs behov for Dialogintegration. Fordele ved brug af dialogintegration i SAPA

Digital Kommuneplan. Hvad er en digital kommuneplan? Oplæg til fælles definition af begrebet. landinspektør Martin Høgh

Fremtidens digitale forvaltning. Opsamling og perspektivering Inge Flensted

Digital kommuneplan. 28. aug Nils Bo Wille-Jørgensen, GIS &IT

BILAG 7. Dokumentation

Datafordeleren - status, muligheder, udvikling

Løsningsbeskrivelse. Den fælleskommunale Serviceplatform

Digitaliseringsstrategi

Præsentation af Danmarks Miljøportal v/ Kaja A. Hansen

Kulturministeriets it-arkitekturpolitik

Bilag 3 FODS 8.2, Fuldt Digital Lokalplaner Kravspecifikation.

Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer

Støttesystemerne. Det er tid til

KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen.

Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks

NÆSTVED KOMMUNES GIS-STRATEGI

Velkommen. Philip Hartmann By- og Miljødirektør Gladsaxe Kommune

Faktaark for DAR 1.0

Velfærd gennem digitalisering

Principper for digitalisering og ny teknologi i Brønderslev Kommune

Socialt Frikort Brugervejledning for Sagsbehandlere

Digitaliseringsstrategi

Ejendomsdataprogrammet - Matriklen Løsningsarkitektur

Solrød Kommunes supplerende kravspecifikation, som uddyber og præciserer kraven

Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunal støttesystemer

Projekt 5.3 Digitale Vandløbsregulativer

Geodata standardisering

Web-baseret metadata redigeringsmodul

KANAL- OG DIGITALISERINGSSTRATEGI Januar 2011

Roadmap for VERA Q Q Q Q Rettighed. Klassifikation. Organisation. Beskedfordeler. Serviceplatform

Datafordeleren - status, muligheder, udvikling

Underbilag 2Q Vilkår for integration til støttesystemet Klassifikation

NOTAT. Brugerportalsinitiativet

Peter Thrane Enterprisearkitekt KL+KOMBIT. Den fælleskommunale Rammearkitektur - Inspiration

It-arkitekturprincipper. Version 1.0, april 2009

GeoMidt temadag 9/

Bilag 1 Tidsplan Version

IT- og Telestyrelsen 21. august 2007 Sagsnr

WSLA for webservices under Danmarks Miljøportal. Version 2.2

Klik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks

WHITEPAPER DokumentBroker

BILAG 0 TIL KONTRAKT OM EOJ-SYSTEM DEFINITIONER

F remtidens Digital Post

Ejerfortegnelse Løsningsarkitektur Bilag C Processer Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi

Balancen mellem de interne nødvendigheder og de eksterne påvirkninger reguleres i kommunens it-strategi som præsenteres herunder.

GIS-OIS INTEGRATION BRUGERMANUAL, VERSION 2 I G I S

Fællesskabet der vil noget mere

RAMMEAFTALEBILAG A - KRAVSPECIFIKATION

Vejledning om avanceret afhentning. i Digital Post på Virk.dk.

It arkitektur- og sikkerhedskrav Løn og personalesystemsudbud. Region Midtjylland 2010.

Møde med leverandører om vejledning til anvendelse af kommende fælleskommunale støttesystemer. KL-huset, tirsdag d. 4. juni 2013

DHUV (Digitalisering af Handicap og Udsatte-Voksne)

Danmarks Miljøportal

Guide til integration med NemLog-in / Signering

Hillerød Kommunes Kanalstrategi

Introduktion til Digital Post. Februar 2016

Administrationsmodul, Adgangsstyring for systemer og Adgangsstyring for brugere

vejman.dk Brugerdokumentation - kortmodul 14. marts 2012 Version 1.9

Annoncering vedr. Autoritativt organisations- og klassifikationskomponent

Transkript:

FKG Kravspecifikation for kommunalt webbaseret geodatasystem FKG Fælleskommunalt geodatasamarbejde 22. december 2010

Indholdsfortegnelse 1. Indledning... 4 1.1. Baggrund... 4 1.2. Målet for webbaseret geodatasystem... 5 1.2.1. Løsningsmål... 5 1.2.2. Målgrupper for løsningen... 6 1.2.3. Løsningskoncept... 6 1.3. Forudsætninger... 10 1.3.1. Den Fælleskommunale Digitaliseringsstrategi... 10 1.3.2. OGF principper som pejlemærke... 11 1.3.3. Basere sig på afprøvede teknologier og standarder... 12 1.4. Afgrænsning af løsning... 13 1.5. Læsevejledning til kravspecifikationen... 15 1.5.1. Kategorier af krav... 16 1.6. Definitioner... 17 2. Brugere, processer, aktører og samspil med andre systemer... 18 2.1. Brugere... 18 2.2. Arbejdsgange og processer som løsningen skal understøtte... 21 2.3. Aktører - systemer og datakilder på området... 23 2.3.1. De kommunale aktører... 23 2.3.2. De eksterne aktører... 24 2.4. Integration og samspil med datakilder og systemer... 24 2.4.1. Integration til IT-systemer i kommunen... 25 2.4.2. Integration til eksterne datakilder og systemer... 26 3. Overordnede forventninger og krav til Leverancen... 27 3.1. Overordnede forventninger til leverancen... 27 3.1.1. Leveranceliste... 28 3.2. Overordnede krav til leverancen... 31 4. Funktionelle krav til Løsningen... 34 4.1. Krav til datagrundlag... 34 4.1.1. FKG Datamodel... 34 4.1.2. Mapning til eksterne standarder... 36 4.1.3. Kodelister... 37 4.1.4. Metadata... 37 4.2. Krav til Løsningens webservices... 39 4.3. Krav til brugergrænsefladen... 41 4.3.1. Browservalg og Plug-ins... 42 4.3.2. Design af brugergrænseflade... 43 4.3.3. Kortvisning... 46 4.3.4. Navigation... 47 4.3.5. Søgninger... 52 4.3.6. Print fra kortvisningskomponent... 54 4.3.7. Redliningværktøj... 56 4.3.8. Hjælpeinformation... 57 # 1 2 6 6 9 4 2

4.3.9. Eksport og import af data... 58 4.3.10. Metadata i brugergrænsefladen... 59 4.4. Krav til redigering af løsningens og eksterne systemers data... 60 4.4.1. Redigering af data i Løsningens egen geodatabase... 60 4.4.2. Redigering i fællesoffentlige geodatabaser... 62 4.5. Krav til visning af data fra andre systemer... 63 4.5.1. Visning af data fra eksterne systemer... 63 4.5.2. Visning af data fra kommunale systemer... 64 4.6. Krav til specialmoduler... 65 4.6.1. Konfliktsøgning... 65 4.6.2. Høringslister og ejeroplysninger... 67 4.6.3. Kortbutik... 68 4.6.4. Ruteberegning og Find nærmeste... 69 4.7. Krav til administratormodul... 70 4.7.1. Ændring af brugergrænsefladen... 71 4.7.2. Dynamisk teksthåndtering... 73 4.7.3. Administration af meta- og attributdata... 74 4.7.4. Administration af kodelister... 75 4.7.5. Opsætning af snap funktionalitet... 75 4.7.6. Opsætning af indlejrede kort... 76 4.7.7. Opsætning af brugerprofiler og dataadgang... 78 4.7.8. Dynamisk opsætning af guidede søgninger... 79 4.7.9. Administration af konfliktsøgninger... 79 4.7.10. Administration af høringsprofiler... 80 4.7.11. Administration af avanceret printfunktionalitet... 81 4.7.12. Overvågning af transaktioner... 82 4.8. Krav til integration med kommunale it-systemer... 83 4.8.1. ESDH-GIS integration... 83 5. Tekniske krav til Løsningen... 85 5.1. Overordnede tekniske krav... 85 5.2. Løsningsarkitektur og arkitekturprincipper... 85 5.2.1. Krav til arkitektur... 88 5.2.2. Afledte krav til dataudveksling... 91 5.2.3. Afledte krav til data... 92 5.3. Krav til løsningsteknologier... 93 5.3.1. Geodatabasen... 93 5.3.2. Anvendelse af tiling/caching... 94 5.4. Krav til grænseflader... 95 5.4.1. Grænseflader til kommunale it-systemer... 95 5.4.2. Grænseflader til eksterne systemer... 96 5.5. Krav til specifikationer og standarder for data og webservice... 97 5.5.1. Standarder og formater for udveksling af data... 97 5.5.2. Standarder og formater for metadata... 100 5.5.3. Generelle standarder for webservice... 100 5.5.4. Offentlige Data i Spil (ODIS)... 101 5.5.5. OIOREST... 101 5.6. Krav til brugerstyring, sikkerhed og logning... 101 5.6.1. Brugerstyring og sikkerhedsløsning... 102 5.6.2. Sikkerhed... 104 5.6.3. Datasikkerhed... 105 # 1 2 6 6 9 4 2

5.6.4. Logning... 106 5.7. Krav til svartider... 107 5.8. Krav til skalerbarhed... 109 5.9. Krav til transaktioner og brugere... 110 5.10. Krav til teknisk miljø... 112 6. Øvrige krav... 115 6.1. Kommunens it-miljø... 115 6.1.1. Indgå i kommunens it-miljø... 115 6.1.2. Installationsmiljø... 115 6.2. Drift... 116 6.3. Datakonvertering... 117 6.4. Test og prøver... 117 6.4.1. Overtagelse af leverancen, funktionsprøven... 118 6.4.2. Driftsprøve... 120 6.5. Support... 121 6.6. Dokumentation... 121 6.6.1. Overordnede dokumentationskrav... 122 6.6.2. Krav til Systemdokumentation... 122 6.6.3. Krav til manualer... 123 6.7. Huskeliste inden udbud... 124 Bilag 1. Ordforklaring... 125 Bilag 2. OGF principper... 127 Bilag 3. Beskrivelse af kommunale og eksterne it-systemer... 132 Bilag 4. FKG datamodel... 135 Bilag 5. Servicebeskrivelse af webservice... 142 Bilag 6. Snitfladebeskrivelse til andre it-systemer... 144 Bilag 7. Modeller for drift af Løsningen... 146 Bilag 8. Kravliste... 151 # 1 2 6 6 9 4 3

1. Indledning Denne kravspecifikation er resultatet af et projekt i regi af Fælleskommunalt geodatasamarbejde (FKG), om at udarbejde en fælleskommunal kravspecifikation for webbaseret geodatasystem. I projektet har deltaget 28 kommuner, der er geografisk fordelt over hele landet, og som omfatter både store og mindre kommuner. Kravspecifikationen er en fælleskommunal opgørelse af behov og krav til et kommunalt webbaseret geodatasystem. Kravspecifikationen kan i den nuværende version anvendes af kommuner som grundlag for anskaffelse enkeltvis eller i fællesskab. Inden dette sker, er der dele af kravspecifikationen, der skal færdiggøres helt, ligesom den skal tilpasses den eller de konkrete kommuner, der vælger at anvende den. Kapitel 6 indeholder emner og krav, som skal færdiggøres og indarbejdes i aftalebilag i forbindelse med et udbud og aftale med en leverandør. Kravspecifikationen er udarbejdet af en arbejdsgruppe med deltagere fra Halsnæs, Holbæk og Vejle kommuner, Hovedstadsregionens Kortsamarbejde og med bistand fra Devoteam Consulting. Kravspecifikationen er behandlet på workshop med deltagerkommunerne primo november og december 2010. FKG vil takke Silkeborg Kommune for, at de stillede deres kravspecifikation for webbaseret GIS til rådighed for dette projekt, så det har været muligt at bygge videre på en eksisterende kommunal kravspecifikation. 1.1. Baggrund I første halvår af 2010 gennemførte KL projekt omkostningseffektivt geografisk forvaltningsgrundlag (OGF) sammen med 37 kommuner. Det overordnede resultat fra projektet er formuleret i fire hovedsynspunkter: 1. Kommunerne bør sikre en udtalt standardisering af geodata og anvende standardiserede geodatasystemer. 2. Kommunerne skal agere, så der sikres den størst mulige omkostningseffektivitet. 3. Det kommunale samarbejde på geodataområdet bør intensiveres. 4. Geodata skal udbredes til anvendelse i hele kommunen. Baggrunden for det første og andet punkt er, at geodataområdet i kommunerne er præget af leverandørsystemer, der fastholder kommunerne på proprietære plat- # 1 2 6 6 9 4 4

forme med hver deres specielle opsætning. Dette giver høje tilpasningsudgifter og resurseanvendelse ifm. datatilpasning, platformsskift, vedligehold og drift af systemer og data. Efter afslutning af OGF projektet blev der fra KL s side taget initiativ til dannelsen af en ny fælleskommunal organisation - FKG (Fælleskommunalt geodatasamarbejde). FKG organisationens bestyrelse tæller de kommunale medlemmer af bestyrelsen for FOTdanmark, samt 3 udpegede medlemmer. FKG organisationens første opgave er at videreføre det store arbejde, der er blevet lavet i OGF projektet, og nu udarbejde og skabe tilslutning til en fælleskommunal kravspecifikation for et webbaseret geodatasystem. Den kan efterfølgende indgå i et fælleskommunalt udbud af et webbaseret geodatasystem, samt give kommunerne mulighed for at konkurrenceudsætte indkøb af yderligere funktionalitet. 1.2. Målet for webbaseret geodatasystem 1.2.1. Løsningsmål Målet med at implementere et webbaseret geodatasystem, som er omfattet af denne kravspecifikation er, at kommunerne kan: Øge udbredelsen af geodata og GIS i kommunen Velfungerende GIS webklient, der kan anvendes af mange brugere, både internt og eksternt Udstille geodata på en standardiseret måde til andre applikationer Øge omkostningseffektiviteten Reducere antallet af desktop GIS klienter Billigere specialapplikationer og integrationer via fælles indkøb Mulighed for fælles drift Implementere en standardiseret datamodel for kommunale geodata Give kommunerne standardiserede geodatasystemer, der er velfungerende, og som dækker fælles og ensartede behov, samt er fleksible med hensyn til at udvide med ny funktionalitet og udvidelse af antal brugere Tilbyde en GIS webklient med stærk funktionalitet, der kan erstatte desktop GIS Give uafhængighed af databaseplatform Give større leverandøruafhængighed Valg af geodatasystem uafhængig af databaseplatform # 1 2 6 6 9 4 5

Mulighed for at skifte geodatasystem som følge af fælles og standardiseret datamodel Muliggøre fælles drift FKG har en forventning om, at der bliver minimum to og gerne flere leverandører af en løsning til webbaseret geodatasystem, der opfylder denne kravspecifikation. Disse løsninger får betegnelse FKG webbaseret geodatasystem. 1.2.2. Målgrupper for løsningen Det kommende FKG webbaseret geodatasystem skal tilbyde løsninger og data, der er tilgængelige for både interne bruger i kommunen og eksterne brugere, der har behov for geografisk relateret information og service som f.eks. lokalplangrænser, byggelinjer, antal børn i skoledistriktet, hvad gælder for ejendommen og kort over kommunen. De interne kommunale brugere er fx sagsbehandlere, planlæggere og driftsmedarbejdere i udførende enheder og institutioner, som har behov for geografisk relateret information og service i enten webklient til GIS, på intranet eller i et fagsystem. Sagsbehandlere og planlæggere inden for teknik- og miljøområdet anvender i dag GIS og geografiske data i stor grad og er derfor en del af målgruppen, som er vigtig at understøtte. Løsningen skal samtidig kunne danne grundlag for at understøtte andre grupper af kommunale medarbejdere med geografiske data som en del af den information, de anvender for at løse opgaver og informere borgere og virksomheder. De eksterne brugere er fx borgere, virksomheder, rådgivere, interesseorganisationer og uddannelsessøgende, som har behov for geografisk relateret information og service i webklient til GIS eller integreret med andre informationer på kommunens hjemmeside. Brugerne af en webklient til GIS kan ikke forventes at have en dybtgående viden om GIS og geografiske data, hvorfor løsningen skal være udformet således, at den fungerer intuitivt for en almindelig bruger, der er vant til at navigere i webbaserede systemer. 1.2.3. Løsningskoncept Løsningen skal udstille kommunens geografiske datagrundlag, andre kommunale data, fælles offentlige geografiske data og samtidig give mulighed for indsamling og vedligeholdelse af geografisk relateret data. Dette skal kunne ske via en web- # 1 2 6 6 9 4 6

baseret brugergrænseflade, og via tekniske integrationer til andre it-systemer i kommunen skal det være muligt at anvende geografisk relateret information i kommunens arbejdsprocesser. Det kan fx være i portaler, fagsystemer og ESDH. Løsningen skal være den primære værktøjskasse (serviceudbyder) og datakilde, som sagsbehandlere og andre kommunale medarbejdere anvender til at søge stedfæstede oplysninger og geografisk relateret information eksempelvis via kort, adresser, distrikter og matrikeloplysninger. Løsningen skal ligeledes indeholde værktøjer til at etablere og vedligeholde kommunens geodata i både egne geodatabaser og i fællesoffentlige løsninger. Løsningen skal give eksterne brugere adgang til geografisk relateret information, der er integreret med kommunes øvrige eksterne digitale information og services og dels via en webklient til GIS, som kan målrettes forskellig informationskontekst. Løsningskonceptet fremgår af illustrationen på Figur 1 og Figur 2 og af nedenstående beskrivelse. Portal Skole Natur Byg Dtp GIS Kortforsyningen Ejendomsdata Børn og Unge FOT Plan DAI DB Byg Miljø ESDH Fællesoffentlige geodata Kommunale geodata Kommunale data Figur 1 Løsningskoncept for FKG webbaseret geodatasystem til kommunerne vist som den blå boks i midten. Alle løsninger til FKG webbaseret geodatasystem skal kunne skrive i de tre gængse geodatabaser til spatial lagring, der bliver anvendt i de danske kommuner (MS SQL, Oracle, PostgreSQL). Dette kan enten ske direkte via snitflade i data- # 1 2 6 6 9 4 7

baseapplikationen eller via et mellemlag ( middelware ) - baseret på Open Source eller proprietære teknologier. Geodatabasen i de kommuner, der i fremtiden anvender FKG webbaseret geodatasystem, vil have en standardiseret datamodel, der er ens og fælles for kommunerne. Det skal give kommunerne en markedsfrihed, i og med at en kommune kan beholde sin nuværende geodatabase og alligevel skifte leverandør af geodatasystem. FKG webbaseret geodatasystem skal indeholde en velfungerende webklient med den basale og udbredte funktionalitet, som kan anvendes af de primære brugere og standardiserede webservices. Webklienten skal være umiddelbart tilgængelig for alle i kommunen, og sigtet er, at kommunen derudover kun har behov for meget få desktop GIS klienter. Som udgangspunkt vil det kun være til dataadministration i kommunens geodatafunktion og funktionalitet, som det ikke er rationelt at implementere i en webklient. Visning Søgning Redigering Grundmodul ESDH Miljø Specialmodul Konfliktsøgning Høring Webklient Kommune FKG OGC Webservice Serverapplikation Database MS SQL Database Oracle Database PostGres Figur 2 Princip for opbygning af FKG webbaseret geodatasystem med webservices og serverapplikation, der kan fungere sammen med tre forskellige databaseplatforme med spatial lagring og understøtte både en webklient og udstille services. Løsningen skal i væsentlig grad gøre brug af webservices til at få data ud og ind af databasen, og til at udstille data og funktionalitet til webklienten og til andre systemer, der anvender geografisk information og services. Løsningen forventes at have tre overordnede typer af services: # 1 2 6 6 9 4 8

- OGC standardiserede services til at få data ind og ud, og som gør det muligt at anvende kommunens geografiske data og services i andre itsystemer, herunder også systemer på mobile enheder. - FKG standardiserede services med funktionalitet til visning/søgning, redigering, konfliktsøgning og høringsliste. - Kommunespecifikke services, der understøtter dataudveksling med individuelle kommunale it-systemer. FKG webbaseret geodatasystem skal kunne anvende andre eksterne og interne datakilder med geodata og andre kommunale data, som er relevant at stedfæste, fx byggesager, miljøoplysninger, ejendomsdata og skolebørn. Løsningen skal både kunne læse fra og skrive til fællesoffentlige databaser med geodata som fx PlansystemDK, Danmarks Arealinformation (DAI), FOT 1 og læse data fra Kortforsyningen. Løsningsplatformen til FKG webbaseret geodatasystem skal muliggøre, at flere kommuner kan være i driftsfællesskab og have forskellige geodatasystemer, der anvender samme geodatabase. Det er et vigtigt mål for løsningen, at den kan tilbyde hurtige svartider hos slutbrugeren på gængse og ofte anvendte funktioner. Derfor skal leverandøren tilbyde et driftsmiljø, der er umiddelbart skalerbart (det vil sige uden behov for konsulentassistance) med hensyn til svartider og kapacitet af data og brugere. FKG webbaseret geodatasystem skal give mulighed for at 3. parts leverandører kan levere specielle GIS moduler til fx byggesag, skole eller egentlige fagmoduler, der understøtter bestemte arbejdsprocesser. Det er hensigten, at disse moduler skriver til og læser fra geodatabasen via webservices i FKG webbaseret geodatasystem. Standardfunktionalitet i FKG webbaseret geodatasystem omfatter: Visning/søgning Redigering Print Konfliktsøgning og høringsmodul Læse og skrive i fællesoffentlige geodata Integration til ejendomsdata 2, persondata og virksomhedsdata 1 Arbejdsgruppen har undersøgt muligheden for udveksling af data med FOT og det kan ikke umiddelbart afklares om det er en teknisk mulighed. 2 Data om ejendomme og bygninger fra ESR og BBR # 1 2 6 6 9 4 9

Som option til FKG webbaseret geodatasystem skal det være muligt for kommunen at vælge: Integration til miljø-, byggesags-, vej- og ESDH-systemer På sigt skal der udvikles flere integrationer fra FKG webbaseret geodatasystem til andre systemer. 1.3. Forudsætninger 1.3.1. Den Fælleskommunale Digitaliseringsstrategi Den Fælleskommunale Digitaliseringsstrategi (2010 2015) er vedtaget i KL s bestyrelse i november 2010. Den indeholder strategiske målsætninger og en række indsatsområder, som et fælleskommunalt samarbejde om webbaseret geodatasystem skal være med til at understøtte. Endvidere indeholder strategien en række arkitekturmål, der er en del af strategien. Løsningsmålet for webbaseret geodatasystem om at øge omkostningseffektiviteten skal bidrage til den strategiske målsætning om at skabe (økonomisk) råderum for kommunerne gennem effektivisering 3. Geodataområdet er nævnt som et specifikt indsatsområde inden for Teknik- og miljøområdet og omfatter udvikling til ensartet grundlag for alle forvaltningssystemer, der anvender geodata. Udbredelse af standarder og andre effektiviserende tiltag, der udvikles i aktuelt geodata implementeringsprojekt med 37 kommuner. Mål: Kvalitetsløft og effektivisering i samtlige kommuner. 4 Arkitekturmålene i digitaliseringsstrategien udgør en del af rammen for et fælleskommunalt samarbejde om webbaseret geodatasystem og særligt følgende punkter er væsentlige at forfølge: Kommunens borgere (og medarbejdere) mødes ikke med behovet for genindtastning af data, som allerede er kendte af andre systemer. Systemerne har en datasammenhæng og en dataudvekslingsarkitektur, som skaber sammenhæng mellem it-løsningerne. En kommune skal ikke betale fuld pris for den samme funktionalitet to gange, da det skal være let for it-løsninger at benytte og genbruge funktioner eller data i andre (kommuners) it-løsninger. En større del af den fremtidige kommunale system-portefølje modulopbygges af fælleskomponenter. 3 Side 12 i Den Fælleskommunale Digitaliseringsstrategi (2010 2015) 4 Side 54 i Den Fælleskommunale Digitaliseringsstrategi (2010 2015), høringsversion # 1 2 6 6 9 4 1 0

Samtidig skal der sikres en incitamentsstruktur, der gør det attraktivt for leverandørerne at udvikle genbrugelig funktionalitet. Når kommunen baserer sine løsninger på åbne standarder og udskiftelige komponenter, kan de skifte leverandører uden tekniske barrierer. Kommunens it-løsninger er driftsstabile, pålidelige, attraktive og sikre, så borgere og medarbejdere kan have tillid til og vil tilslutte sig den digitale opgaveløsning. 5 1.3.2. OGF principper som pejlemærke I forbindelse med gennemførelse af OGF-projektet besluttede styregruppen for OGF i juni 2010 følgende tre principper for et omkostningseffektivt geografisk forvaltningsgrundlag. De tre OGF-principper er: 1. Geodata er et forvaltningsgrundlag for hele kommunen. Opgavebeskrivelsen og det interne ledelsesmæssige ansvar for de medarbejdere, der tværgående arbejder med udvikling og understøttelse af geodataanvendelsen, bør afspejle dette. 2. Kommunale geodata lagres iht. en fælleskommunalt specificeret datamodel. Der er adgang til data via en fælles brugerstyring og services, der er specificeret fælleskommunalt. Der er adgang til kommunale geodata på tværs af myndighederne via en fællesoffentlig brugerstyring. 3. En kommune indkøber kun fagapplikationer med geodataindhold, som kan anvendes uden modifikationer i andre kommuner, som har implementeret OGF-standarderne. Principperne er beskrevet nærmere i Bilag 2. Når en kommune implementerer et FKG webbaseret geodatasystem, vil den samtidig tage et væsentligt og vigtigt første trin i retning af at efterleve OGFprincipperne, hvilket fremgår af Figur 3. 5 Side 16-17 i Den Fælleskommunale Digitaliseringsstrategi (2010 2015) # 1 2 6 6 9 4 1 1

Nu-situation Hver kommune har individuel GIS platform hvor webgis og desktop GIS er tæt forbundet med geodatabasen. Desktop anvendes af mange brugere til redigering af data. Databasen har egen datamodel. Trin 1 om 1-2 år På vej mod at efterleve nogle af OGF-principperne. Kommunerne kan vælge webbaseret geodatasystem uafhængig af geodatabase og desktop GIS. Desktop anvendes af få brugere. Webklient anvendes af mange og til redigering af data. Databasen har fælles kommunal datamodel. Fremtid OGF-principperne bliver efterlevet helt. Kommunes webklient og andre applikationer kommunikerer med geodatabasen via kommunal standard servicesnitflade. Databasen har fælles kommunal datamodel. Kommune 1 Kommune 2 Kommune 3 Kommune 1 Kommune 2 Kommune 3 Kommune 1 Kommune 2 Kommune 3 Figur 3 Implementering af FKG webbaseret geodatasystem er første væsentlige trin på vej mod OGF- principperne. De farvede firkanter viser webklienten og som i trin 1 bliver suppleret med standardiserede service (grå firkant). Romberne er desktopgis som i trin 1 og efterfølgende minimeres i antal. I trin 1 bliver databaserne, der er vist som tønder, standardiseret med fælles datamodel (indhold og struktur). FKG webbaseret geodatasystem er karakteriseret ved, at det bygger på kendte teknologier og løsningsvalg, og tager et væsentligt (men realiserbart) skridt i retning af serviceorienteret distribution af geodatafunktionalitet til kommunale sagsbehandlere. Sammen med uafhængighed af den underliggende database, mulighed for at redigere de fællesoffentlige databaser og kommunernes overgang til en fælles standardiseret datamodel gør dette, at kommunen tager et væsentligt skridt mod at realisere de mål, der er nævnt i afsnit 1.2.1. 1.3.3. Basere sig på afprøvede teknologier og standarder FKG har som mål, at løsningen til webbaseret geodatasystem i størst muligt omfang baserer sig på afprøvede teknologier til lagring og behandling af geografisk information og afprøvede standarder for lagring og dataudveksling af geografisk information. Formålet er at mindske udviklingsomkostninger ved at tage udgangspunkt i teknologer, der har været anvendt tidligere og minimere usikkerhed for manglede modenhed i teknologier og standarder. # 1 2 6 6 9 4 1 2

1.4. Afgrænsning af løsning Løsningen til FKG webbaseret geodatasystem skal indeholde en række komponenter, som tilsammen rummer de funktioner, der dækker de behov, som løsningens målgrupper har for geografisk relateret information og service. FKG webbaseret geodatasystem benævnes i det følgende Løsningen. Figur 4 viser de overordnede komponenter, som løsningen skal indeholde. Derefter er komponenterne beskrevet. Figur 4 Med stiplet linje er vist afgrænsning af Løsningen til FKG webbaseret geodatasystem, som omfatter integrationskomponenter, der er rettet mod kommunale systemer og eksterne systemer. Der findes andre kommunale og eksterne systemer end dem som er vist, som Løsningen på sigt skal kunne integrere til. # 1 2 6 6 9 4 1 3

Brugergrænseflade Brugergrænsefladen til løsningen skal kunne målrettes til både interne og eksterne brugere og bestå af en webklient. Komponenterne til webklienten skal samtidig kunne fungere som indlejrede kort, der kan integreres i andre portaler og andre løsninger med udvalgt indhold og funktionalitet. Brugergrænsefladen skal give adgang til funktionalitet til søgning, visning, redigering, print og specialmoduler som fx konfliktsøgning og høringslister. Til løsningen skal der være et administrationsmodul med brugergrænseflader, der giver en systemadministrator adgang til opsætning af data og løsning, samt vedligeholdelse af metadata. I en del af administrationsmodulet skal andre brugergrupper, fx webredaktører, kunne administrere indlejrede kort på kommunens hjemmeside eller intranet. Applikationslag med webservices Løsningen skal som udgangspunkt være baseret på webservices, der læser data fra geodatabasen og udstiller data og funktionalitet til en webklient og andre interne og eksterne systemer. Som udgangspunkt skal funktionalitet være implementeret som webservices, og det skal være muligt på sigt at udvide med yderligere funktionalitet til specialmoduler. Applikationslaget kan indeholde middleware, der styrer læsning og skrivning til geodatabasen og evt. udstiller funktionalitet til brugergrænsefladen. Geodatabase Geodatabasen indeholder kommunens egne geodata og udgør datagrundlaget for løsningen sammen med data fra kommunale systemer og eksterne systemer. Metadata kan være lageret i geodatabasen til løsningen eller i en ekstern metadatabase, der er fælles for flere myndigheder. Integration Løsningen skal indeholde integration til et antal kommunale systemer. Dette omfatter også klienter til desktop-gis, der skal kunne læse og redigere i geodatabasen. # 1 2 6 6 9 4 1 4

Løsningen omfatter den del af integrationskomponenterne, der gør løsningen i stand til at læse data fra kommunale systemer, udstille data og funktionalitet til kommunale systemer. Integrationen kan ske via webservices eller ved at læse direkte i databaser til de kommunale systemer. Integrationskomponenter til selve de kommunale systemer, der gør dem i stand til at kommunikere med Løsningen, er ikke omfattet af denne kravspecifikation. Løsningen skal ligeledes indeholde integration til et antal eksterne systemer, der indeholder fælles offentlige geodata. Integrationen skal i størst muligt omfang være baseret på standardiserede snitflader. Løsningen omfatter den del af integrationen, der gør løsningen i stand til at læse data fra eksterne systemer og redigere i eksterne systemer. Integrationen skal ske via standardiserede webservices, der overholder snitfladerne og servicebeskrivelserne for de eksterne systemer. 1.5. Læsevejledning til kravspecifikationen Dokumentet indeholder udover nærværende indledning med mål, baggrund og forudsætning følgende: Kapitel 2, der beskriver de brugere, processer, aktører, systemer og datakilder, der skal interagere med løsningen. Kapitel 3, der beskriver de overordnede forventninger og krav, som FKG har til løsningen, og som typisk er ufravigelige krav. Kapitel 4 beskriver de funktionelle krav til løsningen med udgangspunkt i de forretningsmæssige behov, som kommunerne har til løsningen, og dermed de arbejdsprocesser og informationsbehov, som løsningen skal understøtte. Kapitel 5 beskriver de tekniske krav, som FKG har til den tekniske opbygning af løsningen, fx med hensyn til it-arkitektur, it- og datastandarder samt sikkerhed. Kapitel 6 indeholder øvrige krav til de ydelser fra leverandøren, som FKG ønsker tilbud på, som fx datakonvertering, drift og videreudvikling. Afhængig af udbuds- og aftaleform bliver det typisk indarbejdet i forskellige aftaledokumenter. Kapitlet indeholder afslutningsvis en huskeliste til opgaver, der skal gennemføres inden eller i forbindelse med et udbud. Bilag der beskriver og uddyber forskellige aspekter af kravspecifikationen. Her findes også bilag med en oversigt over alle krav, optioner og infokrav. Dokumentet indeholder en række steder regibemærkninger til læser. Disse er angiver med kantet parentes og i [kursiv]. # 1 2 6 6 9 4 1 5

1.5.1. Kategorier af krav FKG s behov er klassificeret i fire kategorier, benævnt som følger: Ufravigelige krav Krav Option Infokrav Alle behov er i denne kravspecifikation givet et fortløbende nummer, og ordet Krav eller Option i venstre margen. Ufravigelige krav er angivet i parentes før kravoverskriften. Infokrav er ligesom krav og option angivet ved et forløbende nummer og ordet Info i venstre margen. Udover kravoverskriften er selve kravteksten markeret ved en lodret streg i venstre side. Det er kun kravteksten, der udgør selve FKG s behov. Supplerende tekst uden lodret streg i venstre side er supplerende oplysninger. Et eksempel på et ufravigeligt krav er givet i det følgende: Krav #.# (Ufravigeligt krav) Dette er kravoverskriften Dette er selve teksten. Dette er supplerende tekst. Ufravigelige krav Behov formuleret som Ufravigelige krav er krav, som er ufravigelige for FKG og som skal opfyldes af Leverandør. Krav Behov anført som krav er krav, som kan opfyldes af Leverandør og vil fremstå som et konkurrenceparameter i den senere tilbudsvurdering. Opfyldes et krav ikke, vil dette indgå i den samlede bedømmelse af Leverandørs tilbud i overensstemmelse med det anførte i tildelingskriterierne i Udbudsbetingelserne. Option Behov anført som option er krav, hvor FKG ønsker, at Kunden har en frihed til at vælge, særskilt prissætning af krav, samt krav, der er individuelle for hver Kunde. Optioner kan tilbydes af Leverandør og vil fremstå som et konkurrenceparameter i den senere tilbudsvurdering. Tilbydes en option ikke, vil dette indgå i den sam- # 1 2 6 6 9 4 1 6

lede bedømmelse af Leverandørens tilbud i overensstemmelse med det anførte i tildelingskriterierne i Udbudsbetingelserne. Infokrav Behov formuleret som et infokrav angiver krav, som skal besvares af Leverandør. 1.6. Definitioner I Bilag 1 er en række væsentlige akronymer og ord i forbindelse med kravspecifikationen defineret. # 1 2 6 6 9 4 1 7

2. Brugere, processer, aktører og samspil med andre systemer 2.1. Brugere Brugerne, som skal anvende Løsningen, kan opdeles i tre primære grupper: 1) Interne brugere, 2) Eksterne brugere og 3) Administratorer. 1) De interne brugere er ansat i kommunen og har behov for adgang til mange forskellige data og forskellig funktionalitet i Løsningen, hvilket også vil kræve login/ autentificering, da brugeren kan have behov for at tilgå data, som andre medarbejdere ikke må se. 2) De eksterne brugere er borgere, virksomheder og andre, som ønsker at benytte Løsningen via kommunens hjemmeside og/eller de udstillede webservices. a. På hjemmesiden vil brugeren forvente en brugergrænseflade med de mest gængse navigations- og funktionalitetsmuligheder. Der vil ikke være behov for login/autentificering. Det kan også være ansatte i kommunen, der indgår i denne gruppe. b. Som webservices vil brugeren forvente at finde funktionalitet og information, som kan integreres direkte i brugerens interne itsystem. 3) Løsningen skal også håndtere de brugere, som skal administrere Løsningen. Det drejer sig overvejende om GIS administration ved opsætning af temaer, tematisering af lag, rettighedsstyring m.v. Dernæst er der behov for, at webredaktører kan redigere og opsætte indlejrede kort, eventuelt via samme eller separat brugergrænseflade. Her følger en mere detaljeret beskrivelse af eksempler på de enkelte brugertyper og deres behov. Interne brugere: En miljømedarbejder, som benytter Løsningen via kommunens intranet. Brugeren autentificeres via det almindelige login til kommunens netværk ved adgang til Løsningen. Her henter brugeren kort fra geodatabasen, og eksterne korttjenester, til visning i egen webklient til GIS. Brugeren udfører konfliktsøgning og henter ejendomsinformationer fra kommunens ejendomsdatasystem på baggrund af valgte data i Løsningen. # 1 2 6 6 9 4 1 8

En GIS medarbejder, som benytter Løsningen via kommunens intranet. Brugeren autentificeres ved adgang til Løsningen. Brugeren tilgår Løsningen, henter geometrier fra eksterne korttjeneste og fra Løsningens geodatabase. Brugeren zoomer ind på et område og vælger som dataansvarlig at oprette et nyt objekt i et temalag. Brugeren benytter løsningens digitaliseringsværktøj til at tegne nye objekter og skal samtidig udfylde de nødvendige attributdata til det/de nye objekter. Når brugeren gemmer objektet, sørger Løsningen for at objektet gemmes i geodatabasen eller eventuelt i eksterne systemer, hvis temaet opbevares der. En GIS medarbejder arbejder i egen GIS applikation i kommunen (DesktopGIS). GIS-applikationen er integreret til Løsningen, hvor brugeren autentificeres ved adgang til Løsningen. Brugeren udfører bl.a. følgende funktioner/rutiner: a. Henter og viser kort fra Løsningen. b. Digitaliserer nye objekter som gemmes i Løsningen. c. Ændrer på attributter på eksisterende lag. d. Udfører komplicerede SQL forespørgsler til Løsningens geodatabase jf. de funktioner, som er til rådighed i GIS applikationen. e. Udfører konfliktsøgninger ved anvendelse af den service, som Løsningen tilbyder. En byggesagsbehandler modtager ansøgning om dispensation til at opføre carport inden for byggelinjen i et ældre villaområde. I forbindelse med sagsforberedelsen vælger medarbejderen, der arbejder i ESDH, at foretage en geografisk udsøgning via adgang til webklienten for at undersøge, om der findes andre dispensationssager inden for villaområdet. En konsulent på fritidsområdet skal i forbindelse med planlægning af nye fritidstilbud undersøge hvor mange 10-18 årige, der bor i udvalgte bydele. Konsulenten har adgang til en særlig brugerprofil i Løsningen, der giver adgang til et høringsmodul, som også kan foretage optælling af personer i en given aldersgruppe. Eksterne brugere: En borger som tilgår Løsningen på kommunens hjemmeside. Brugeren vælger relevante temaer i kortet, foretager en adressesøgning for at se sit hus og dettes beliggenhed i forhold til matrikelskel. # 1 2 6 6 9 4 1 9