Geodatasett og geodatatjenester som oppfyller kravene i § 5, § 6 og § 7 kan etter avtale med Kartverket kobles til geoportalen. I slike tilfeller gjelder § 9 til § 14 tilsvarende.
156
Autentiseringsmekanismene som brukes i dag, har ofte dårlig sikkerhet og kan være ukrypterte. Det finnes også et utall forskjellige måter å løse autentisering på og mange av de er benyttet her. Det bør benyttes nasjonale løsninger som IdPorten og Maskinporten for autentisering. Disse er laget på gode standarder og har høy sikkerhet. Andre løsninger bør en ha gode argument for å velge.
153
Det anbefales å sette opp en tilgangstjeneste i organisasjonen der brukeren er ansatt. Dette kan tilbys som ADFS tjeneste (Active Directory Federation Services), Azure AD eller andre autentiseringstjenester som støtter OpenID connect og Oauth2.
152
Systemer som har egen innlogging eller bruker ansatt pålogging, bør bruke Maskinporten.
151
For brukerinitiert autentisering mot applikasjon over usikre nettverk bør en bruke id-porten/Maskinporten med OpenID connect og Oauth2. Merknad: OpenID Connect og Oauth2 er protokoller som er laget for autentisering og autorisasjon over usikre nettverk. Dette er protokollene ID-Porten, Difi og Altinn legger opp til å bruke. Derfor ser vi det som lite lurt å legge seg på noe annet. Dette er veletablerte protokoller som har god støtte i de fleste språk og plattformer. Facebook og Google bruker disse for deres fødererte påloggingsløsninger. Det er også lett å få tak i kompetanse rundt dette siden de er så utbredt. Vår anbefaling vil være å basere alle nye API og protokoller på Maskinporten/IDPorten med OpenID Connect og Oauth2. Da vil alle forholde seg til det samme, og usikre halvveis gode metoder vil forsvinne.
150
Del løsningen din i utgangspunktet åpent og forklar eventuelle beslutninger om ikke å dele.
143
Øke synligheten og troverdigheten til IT-løsninger.
142
Øke synligheten og troverdigheten til IT-løsninger.
141
Forbedre IT-løsningens tekniske anvendbarhet.
140
Dokumentere, dele og gjenbruke komponenter.
139
Anskaffe IT-løsninger på en transparent og åpen måte.
138
Fremme juridisk sikkerhet.
137
Vedta forretningsmodeller som letter deling og gjenbruk.
136
Samarbeide for å identifisere vanlige behov.
135
Forbedre samarbeid på tvers av organisasjonene. Dette betyr at offentlige virksomheter bør ta ansvar for å etablere samarbeidsfora på tvers av organisasjonene.
134
Offentlig virksomhet bør ha eierskap til felles programvarekomponenter for å sikre fremtidig vedlikehold.
132
De bør forefinnes som OpenSource.
131
Offentlig virksomhet bør ha eierskap til OpenSource-prosjektet for å sikre fremtidig vedlikehold.
128
De bør forefinnes som OpenSource.
127
Det anbefales å følge krav og anbefalinger i det tekniske retningslinjedokumentet.
120
I de tilfeller der en ønsker å implementere omforming som en tjeneste anbefales det å følge krav og anbefalinger angitt i vedlegg F til rammeverket.
117
Det anbefales å følge krav og anbefalinger angitt i vedlegg E til teknologisk rammeverk – Tekniske retningslinjedokumenter for nedlastingstjenester.
114
Det anbefales å følge krav og anbefalinger angitt i vedlegg D til teknologisk rammeverk – Tekniske retninglinjedokumenter for visningstjenester.
107
Det anbefales å følge krav og anbefalinger angitt i vedlegg C til teknologisk rammeverk – Tekniske retninglinjedokumenter for søketjenester.
97
For dokumentasjon av REST-API’er anbefaler vi (som Digitaliseringsdirektoratet) å bruke OpenAPI Specification.
88
Data skal være tilgjengelig i maskinlesbare formater. I tillegg bør formatene være standardiserte. Dette sikrer god samhandlingsevne med annen informasjon (interoperabilitet) og legger ikke unødvendige begrensninger på hva informasjonen kan brukes til i fremtiden. Eksempler på maskinlesbare og standardiserte formater er CSV, XML, JSON og RDF-serialiseringer som RDF/XML, JSON-LD og Turtle a. Merknad: De formater som er nevnt her er bare eksempler. Ikke alle eksemplene her egner seg for geodata. Rammeverksdokumentet har egne krav til koding og formater av geodata.
84
Bruke åpne standardlisenser som Creative Commons 4.0 eller Norsk lisens for offentlige data (NLOD).
83
Tjenester bør spesifiseres som OpenAPI documents for REST.
82
Ofte brukte analyser av høy samfunnsmessig betydning bør implementeres som tjenester og dokumenteres i Geonorge, slik at en unngår å måtte laste ned hele databaser samt sikre at en bruker oppdaterte data som utgangspunkt for analyser. Dataeier bør tilby analysetjenester (WPS) som f.eks om tiltak berører eller er i nærheten av data som inngår i de datasett som kommunen har bekreftet inngår i DOK. Det er dataeier som har best kunnskap om sine data og bruken av disse i tjenestene Eksempler på analyse: - Avstand til kvikkleire - Avstand fra 50 års flom/100 års flom - Avstand fra kulturminner - Berører antikvariske bygg
81
Det anbefales at registre som beskriver et hierarki skal være konforme med ISO 19135-1 Prosedyrer for registrering av geografiske elementer”, konformitetsklasse “Hierarchical register” som er minimumskrav for etablering, vedlikehold og publisering registre.
77
Det anbefales å benytte mapping mellom kravene til metadata og ISO 19115 Metadata og ISO 19119 Tjenester (metadata) som er beskrevet i "Technical Guidelines for metadata - based on EN ISO 19115 and EN ISO 19119", samt andre anbefalinger som fremkommer her.
75
Ulike konformitetsklasser for datasett som er beskrevet i Technical Guidelines for metadata - based on EN ISO 19115 and EN ISO 19119 og tjenester er beskrevet i form av: ○ Baseline metadata for dataset og dataset serier ○ Interoperability metadata for datasett og data serier ○ Baseline metadata for “Spatial Data Services” ○ Metadata for “Network Services” ○ Metadata for “Invocable Spatial Data Services” ○ Metadata for “Interoperable Spatial Data Services” ○ Metadata for “Harmonised Spatial Data Services” Disse anbefalingen knytter seg til angivelse av metadata for data og ulike typer tjenester.
74
Kvaliteten på virksomhetens data påvirker hvor egnet de er til andre formål enn de først ble skapt for. Dokumentering av datakvalitet er til stor hjelp i prosessen med å vurdere om virksomhetens datasett er egnet til andre formål, og øker sjansen for bruk. Datakvaliteten bør derfor være dokumentert, og kjente utfordringer bør eksplisitt omtales i beskrivelsene www.regjeringen.no/id2536870/#punkt_fem
71
For at potensielle brukere av offentlige data enkelt skal kunne finne data, bør beskrivelser av datasett være tilgjengelig på data.norge.no, som er en katalog med beskrivelser av åpne datasett fra det offentlige. Digitaliseringsdirektoratet gir anbefalinger om formater for dette formålet i dokumentet Standard for beskrivelser av datasett og datakataloger. Virksomheten bør vurdere å tilby beskrivelser på engelsk i tillegg til norsk www.regjeringen.no/id2536870/#punkt_sju
70
Virksomhetene bør dokumentere datasettene slik at det blir enkelt å ta datasettene i bruk både for mennesker og maskiner. Med dokumentasjon mener vi beskrivelser som gjør det mulig for andre å oppdage, forstå og bruke dine data. www.regjeringen.no/id2536870/#punkt_fire
69
Registreringsskjemaene til de nasjonale datakatalogene (data.norge.no, Felles datakatalog og Geonorge.no) støtter alle gjeldende anbefalinger og krav knyttet til datakataloger for offentlige virksomheter. Dersom du velger å etablere en egen/lokal datakatalog for din virksomhet, må du sikre at gjeldende standarder støttes, slik at de nasjonale katalogene kan høste datasettbeskrivelser fra din løsning.
68
Standard for beskrivelse av datasett og datakataloger (DCAT-AP-NO) er en anbefalt standard i Referansekatalogen. Standarden er anbefalt brukt for å beskrive datasett og datakataloger i offentlig sektor.
67
Den enkelte virksomhet bør enkelt kunne angi om datasett i Geonorge også skal tilgjengeliggjøres i Felles datakatalog og på data.norge.no. Virksomheten bør sørge for at data skal kunne gjøres tilgjengelig i et langtidsperspektiv, med opprettholdt integritet, autentisitet, anvendbarhet og pålitelighet.
66
Det anbefales å benytte Veileder for SOSI-produktspesifikasjoner (pdf).
57
Alle datasett bør ha maskinlesbare tegneregler i henhold til SLD.
56
Der det finnes registreringsinstruks/metodebeskrivelse bør disse gjøres tilgjengelig i infrastrukturen, se https://register.geonorge.no/nasjonale-standarder-og-veiledere/kartleggingsinstrukser
55
For bedre interoperabilitet bør CRS som er spesifisert i koordinatsystemregisteret i Geonorge benyttes. Merknad: Alle CRS som er spesifisert i Geodataloven og gjennomføringsbestemmelsene som er aktuelle for Norge er beskrevet i Geonorge. Referanse: https://register.Geonorge.no/epsg-koder
54
En oppsummering av en produktspesifikasjon bør også publiseres i en produktspesifikasjon og i et produktark.
53
SOSI del 2 - Generell objektkatalog anbefales som et utgangspunkt for å lage produktspesifikasjoner.
27
På områder som ikke dekkes av de obligatoriske standardene, bør virksomheten benytte de anbefalte standardene. Referansekatalogen gir en oversikt over anbefalte og obligatoriske IT-standarder i offentlig sektor.
24
Data som virksomhetene er i stand til å dele med andre bør synliggjøres i Felles datakatalog og på data.norge.no.
23
Det anbefales å bruke tjenestedesign og andre metoder for brukerinvolvering og brukertesting for å sikre at tjenestene oppfyller brukernes behov. Merknad 1: Informasjon om tjenestedesign finnes blant annet på https://www.ks.no/fagomrader/innovasjon/innovasjonsledelse/veikart-for-tjenesteinnovasjon/tjenestedesign/ Merknad 2: Eksempler på dette er use case diagrammer og ulike maler for å spesifisere brukerkrav slik dette foreligger i SOSI del 1 - Regler for UML modellering.
22
Inntil vi har et omforent modelleringsrammeverk for offentlige data generelt anbefales det ved stedfesting av alle typer offentlige data å benytte modelleringsrammeverket i SOSI, og ikke ved å ta i bruk “Stedfesting ved bruk av ISA Core Location Vocabulary”.
11
Legg til rette bruken av offentlige geodata for andre aktører enn offentlige etater for å stimulere til inovasjon i produkter og tjenester som igjen vil bidra til økt vekst og nye arbeidsplasser.
10
Anbefaling 13: Geodata bør forvaltes ved å knytte dette opp mot strategier, retningslinjer og organisatoriske målsettinger ved å ansvarliggjøre næringsliv og brukere. Definer hva "Fit for purpose" betyr og innebærer.
9