Pilotsystem for felles ekom situasjonsforståelse (FEKOMS II)

Transkript

1 Kravspesifikasjon Pilotsystem for felles ekom situasjonsforståelse (FEKOMS II) 14. desember 2012 PT-ref.: olb

2 INNHALD 1. INNLEIING OVERORDNA SKILDRING SYSTEM OG GRENSESNITT BRUKARAR RAPPORTERINGSPLIKTIGE DATA SYSTEMKRAV LAGRING AV DATA TILGANGSKONTROLL FUNKSJONELLE KRAV INNLOGGING OG UTLOGGING HOVUDRAMME ADMINISTRASJONSSIDE KARTSIDE RAPPORTERINGSSIDE VARSLING TEKNISKE KRAV VEDLEGG 1 KARTSIDE VEDLEGG 2 VISNINGSREGLAR FOR GEOGRAFISK OMFANG

3 1. INNLEIING PT gjennomførte i 2011 forprosjektet FEKOMS I Felles ekom situasjonsforståing. Forprosjektets formål var å greie ut behovet og moglegheitene for eit felles system som raskt kan gi beredskapsaktørar i ekomsektoren og andre sektorar eit overordna bilete av tilstanden i ekomnett- og tenester for å bidra til meir effektiv krisehandtering. Forprosjektet FEKOMS I, og reelle krise-/beredskapshendingar det siste året, har vist at både regionale og sentrale beredskapsmyndigheiter kan ha nytte av ei betra situasjonsoversikt over tilstanden i ekomnett og -tenester. For å møte behovet har PT eit mål om at det blir utvikla eit datasystem som mottar kartbasert informasjon om utfall frå ulike tilbydarar og presenterer dette på ein heilskapleg og oversiktlig måte i ein webportal. Aktuelle beredskapsaktørar kan få tilgang til webportalen for bruk i handtering av krise- og beredskapssituasjonar. FEKOMS II er eit prosjekt som har som formål å utvikle og evaluere ein pilot på eit slikt system. Pilotsystemet skal vere avgrensa i talet på tilbydarar som skal rapportere til systemet, i talet på brukarar av systemet, og på kva funksjonar systemet skal ha. Formålet med pilotsystemet er å evaluere konseptet i ein liten skala og til ein forholdsvis lav kostnad. Dette dokumentet er kravspesifikasjon på pilotsystemet. 2. OVERORDNA SKILDRING Dette kapittelet gir ei overordna skildring av pilotsystemet for felles ekom situasjonsforståing (heretter kalla systemet) System og grensesnitt Nedanfor skisserast systemet saman med grensesnitta. 3

4 Tilbydar 1 Tilbydar 2 Tilbydar n Rapporteringsside Administrasjonsside Web E post Systemet Web Post og teletilsynet Web E post Kartside Brukar 1 Brukar 2 Brukar n Data som systemet skal prosessere er utfallsinformasjon som finnast hos dei ulike tilbydarane. Systemet skal ha eit webgrensesnitt for å ta imot slik utfallsinformasjon frå eit utval av tilbydarar (rapporteringsside), og eit e-postgrensesnitt for kvittering. Systemet skal sette saman og behandle informasjonen frå dei ulike tilbydarane. Prosessert informasjon skal gjerast tilgjengeleg i form av eit kartbasert webgrensesnitt til brukarane (kartside). Brukarane skal også få e-postvarsel dersom det skjer utfall i eit førehandsdefinert geografisk område og omfang. Systemet skal gi Post- og teletilsynet eit webgrensesnitt til brukaradministrasjon (administrasjonsside) Brukarar Typiske brukarar av systemet er, utanom Post- og teletilsynet, typisk strategisk og beredskapsfagleg leiing hos departement, etatar og direktorat, tilbydarar, Fylkesmannen og kommunar. Ein skal ikkje føresette at brukarane har særskilt dataeller teleteknisk kompetanse. Systemet skal ta imot utfallsinformasjon frå 3-7 teletilbydarar som skal tilgjengeleggjerast for eit titals samtidige brukarar. 4

5 3. RAPPORTERINGSPLIKTIGE DATA Tilbydarane vil som ledd i øvingar bli pålagt å rapportere utfallsinformasjon til systemet. Tabellen nedanfor viser informasjonskategori, ei nærmare skildring av innhaldet innanfor kvar kategori, og informasjonen si datatype. Med datatype meinast her om informasjonen er: Tal, dato, klokkeslett Fri tekst Førehandsdefinerte verdiar Namn Datatype Skildring Obligatorisk /Valfritt Hendings-ID Tal Tilbydar sin interne «ticket-id» for O hendinga. Modus Førehandsdefinerte verdiar: Knapp for å merke om rapporterte data er O <Normal>, <Øvelse> reelle (normal) eller som ledd i ei beredskapsøving (øvelse). Oppsto Dato og klokkeslett Tidspunkt for når hendinga oppsto O Normalisert Dato og klokkeslett Tidspunkt for når hendinga forventast O normalisert, ev. vart normalisert Status Fri tekst Status for hendingshandteringa. O Teneste Fri tekst Kva ekomteneste(r) som er råka i hendinga O Teknisk omfang/ kundeomfang Fri tekst Korleis ekomtenestene er råka (t.d. fullstendig eller delvis utfall, ustabilt, eventuelt kundeomfang osv.) Geografisk omfang Førehandsdefinerte verdiar Kva fylker er råka. O Nærmare geografisk Fri tekst Eventuell nærmare skildring av geografisk V skildring avgrensing (t.d. innanfor fylka) Samfunnskritiske Fri tekst Eventuelle samfunnskritiske brukarar som V brukerar er råka av hendinga Årsak Fri tekst Faktisk årsak, antatt årsak til hendinga, O eller oppgi at årsak er ukjent E-post Fri tekst E-postadresse som kvittering for registrering/oppdatering av hending kan sendast til. V O 4. SYSTEMKRAV 4.1. Lagring av data Trafikklogg Systemet skal registrere brukarnamn og tidspunkt for innlogging og utlogging til den som loggar seg på systemet Systemet skal ikkje slette registreringar i trafikkloggen. Hendingsdatabase Systemet skal lagre og vedlikehalde rapporterte hendingar i ein database. For kvar hending skal dette lagrast: - Tilbydar (brukarnamn til den som er innlogga) - Tilstand («aktiv» eller «avslutta») - Hendings-ID (jf. rapporteringsskjema kap 3.) - Modus (jf. rapporteringsskjema) - Oppsto (jf. rapporteringsskjema) - Normalisert (jf. rapporteringsskjema) - Status (jf. rapporteringsskjema) - Teneste (jf. rapporteringsskjema) - Teknisk omfang/ kundeomfang (jf. rapporteringsskjema) 5

6 - Geografisk omfang (jf. rapporteringsskjema) - Ev. nærmare geografisk skildring (jf. rapporteringsskjema). - Samfunnskritiske brukerar (jf. rapporteringsskjema) - Årsak jf. (rapporteringsskjema) (Merk: Hendings-ID-en er den som tilbydar sjølv skriv inn, i praksis den same som intern «troubleticket-id». Sjå også krav [ ] Merk: Ved oppdatering av ei hending skal gammal informasjon skrivast over, jf. Krav [ ]) Data som er eldre enn eitt år skal ikkje vere tilgjengeleg for visning i Systemet. Integrering med arkivsystem Systemet skal ha integrering mot PT sitt arkivsystem. Ei ny hending skal generere ei ny sak. Kvar oppdatering av hendinga skal generere eit dokument i saka. I tillegg til data nemnt i krav [4.1.3] skal dokumentet òg innehalde tidspunktet for rapportering Systemet skal berre aktivere arkiveringsfunksjonen i krav [4.1.5] dersom hendinga har Modus «Normal» (jf. rapporteringsskjema) Tilgangskontroll Tilgang til systemet skal styrast av brukarnamn og passord. (Merk: Det er administrator som administrerer brukarnamn og passord. Fyrste gongs formidling av brukarnamn og passord skjer utanfor systemet, dvs. manuelt. Systemet treng difor ikkje leggje til rette for at brukarane skal administrere eigen brukarkonto) Systemet skal ha fire tilgangsnivå: - «Tilbyder» (tilbydarane) - «Bruker» (beredskapsaktørar) - «Superbruker» (PT, SD) - «Admin» (PT) Dei ulike tilgangsnivå skal gi tilgang som vist i matrisa under: Tilbyder Bruker Superbruker Admin Rapporteringsside X Kartside X X X X Funksjonen «Eksporter X X situasjonsrapport» på kartside, jf. krav [ ] «Kritiske brukere» og X X «Årsak» i kartside, jf. krav [ ] Administrasjonsside X Redigere, legge til og endre tekst, jf. krav [ ] og [ ] X 6

7 5. FUNKSJONELLE KRAV 5.1. Innlogging og utlogging Grensesnitt Krav Grensesnitt for innlogging skal ha - felt for å skrive inn brukarnamn og passord og logge seg på - felt for å skrive inn e-postadresse for å få tilsendt gløymd brukarnamn/passord på e-post Funksjonar Systemet skal føre brukaren til kartsida dersom brukarnamn og passord er godkjent (førehandsregistrert i systemet) Systemet skal gi brukaren tilgangsrettar, jf krav [4.2.2]. Systemet skal, dersom brukar vil ha tilsendt brukarnamn/passord på ny, sende brukarnamn/passord på oppgitt e-postadresse dersom oppgitt e-postadresse er registrert i systemet Systemet skal logge ut brukaren dersom han aktivt loggar av eller er inaktiv i 20 minutt. Utlogga brukar skal førast til nettsida for innlogging Hovudramme Grensesnitt Systemet skal ha ei hovudramme med felt for: (1) PT-logo (2) Lenke til (3) Lenker til tekst om «Kontaktinformasjon», «Om tjenesten» og «Hjelp» (4) Oversikt over kven som er logga inn og moglegheit for å logge ut (5) Hovudfelt for visning av kartside, administrasjonsside og rapporteringsside Felt, sider og funksjonar som ein brukar ikkje har tilgang til, jf. tilgangsmatrise i krav [4.2.2], skal vere utilgjengeleg («gråa ut» eller usynleg) for brukaren Funksjonar Lenke til Når brukaren nyttar lenka skal systemet opne nytt vindauge/ny fane i nettlesaren med PT si heimeside. Lenker til «Kontaktinformasjon», «Om tjenesten» og «Hjelp» Når brukaren nyttar lenkene «Kontaktinformasjon», «Om tjenesten» og «Hjelp» skal systemet vise informasjonstekst. Informasjonsteksta skal kunne leggast inn og redigerast av brukarar med rette tilgangsrettar, jf. krav [4.2.2]. 7

8 5.3. Administrasjonsside Grensesnitt Administrasjonssida skal ha eit felt for å administrere (legge til, redigere og slette) brukar, og eit felt for administratorfunksjonar Funksjonar Felt for å administrere brukarar Systemet skal ha moglegheit for å legge til, endre og slette brukarar Systemet skal på førehand ha registrert ein nærmare bestemt administratorbrukar (PT) Systemet skal registrere følgjande atributtar for kvar brukar: Brukarnamn (tekst) Passord (tekst) Organisasjon (tekst) Rolle («Admin», «Bruker», «Superbruker», eller «Tilbyder»), jf. krav [4.2.2] E-post (e-postadresse) Varslingsvilkår Tid (tal som representerer eit timetal) Varslingsvilkår Fylke (liste over ingen, eit eller fleire fylke) Varslingsvilkår Tilbyder (liste over ingen, ein eller fleire tilbydarar (brukarnamnet til brukarar som har rolle «Tilbyder») Systemet skal gi dei ulike brukarane tilgangsrettar, jf. krav [4.2.2], på bakgrunn av kva rolle dei blir tildelt ved registrering. Felt for andre administratorverktøy Systemet skal ha følgjande administratorfunksjonar: «Eksporter database», «Eksporter trafikklogg» og «Sett visningstid for avsluttede hendelser» Når brukaren aktiverer funksjonen «Eksporter database», skal systemet generere ei CSV-fil med alle registrerte hendingar (både aktive og avslutta), jf. krav [4.1.4], og sende fila til e- postadressa til brukaren som er logga inn. Systemet skal gi tilbakemelding til brukar om at data har blitt sendt til brukaren si e-postadresse Når brukaren aktiverer funksjonen «Eksporter trafikklogg», skal systemet generere ei CSV-fil med påloggingsinformasjon, jf. krav [4.1.1], og sende fila til e-postadressa til brukaren som er logga inn. Systemet skal gi tilbakemelding til brukar om at data har blitt sendt til brukaren si e-postadresse Når brukaren aktiverer funksjonen «Sett visningstid for avsluttede hendelser», skal brukaren kunne taste inn eit timetal som systemet skal registrere og bruke som visningstid jf. krav [ ]. Førehandsregistrert (default) timetal skal vere 1 time. 8

9 5.4. Kartside Grensesnitt Kartsida skal ha eit felt for å vise informasjonstekst og knappen «Eksporter situasjonsrapport», og eit felt for sjølve kartet Informasjonsfeltet skal ha ei enkel hjelpetekst om korleis navigere i kartet og lese informasjon. For brukarar med rolle «Admin» og «Superbruker» jf. krav [4.2.2] skal i tillegg funksjonen «Eksporter situasjonsrapport» vere tilgjengeleg Kartfeltet skal bestå av navigerbart kart tilsvarande kartet på Funksjonar Felt for informasjonstekst Informasjonsteksta skal kunne leggast inn og redigerast av brukarar med rette tilgangsrettar, jf. krav [4.2.2] Når brukar som har tilgang, jf. krav [4.2.2], trykker på «Eksporter situasjonsrapport», skal systemet generere eit PDFdokument som viser gjeldande kartutsnitt med ID-markørar, med tilhøyrande hendingsinformasjon og sende dette til e- postadressa til brukaren som er innlogga. Felt for kart: Navigering Systemet skal ha navigeringsfunksjonalitet (panorering, zoom) tilsvarande kartet på Systemet skal ha muligheit til å bytte mellom modusane kart, foto og hybrid, jf. Felt for kart: Informasjon om aktuelle hendingar Systemet skal til ein kvar tid vise ein ID-markør, som i kartet plasserast sentralt i fylket som det er registrert hendingar i. Dersom ei hending spenner over fleire fylke skal ein ID-markør visast i alle fylka som er synlege i det gjeldande kartutsnittet. Dersom ein zoomar inn i eitt fylke skal ID-markør(ane) følgje med i gjeldande kartutsnitt (dynamisk plassering) Dersom det i eit fylke er fleire hendingar, skal Systemet plassere dei ulike ID-markørane ved sidan av kvarandre ID-markøren skal vere raud dersom hendinga er aktiv. Når hendinga er avslutta skal ID-markøren vere grøn inntil den skal forsvinne frå kartet etter x timar, der x er timetalet som er registrert jf. krav [ ] Nummeret på ID-markøren skal vere eit dynamisk tal som skal gi ein unik ID til hendingane som til ein kvar tid visast i kartet 1. Nummeret på ID-markøren skal ikkje vere den same, eller vere tilknytt, hendings-id-en (jf. rapporteringsskjemaet i kap. 3) Systemet skal vise informasjon om hendingar i eit 1 Dette har som hensikt å gjere det muleg å skilje mellom hendingane som til ein kvar tid er synlege i kartet. Døme: gitt at ein har tre samtidige aktive hendingar i kartet med ID markørar 1, 2 og 3. Deretter avsluttast hendingane med ID markør 1 og 2 medan hending med ID markør 3 framleis er aktiv. Dersom det skulle kome til nye hendingar før hending med ID markør 3 er avslutta, kan ID markør 1 og 2 brukast på nytt. 9

10 informasjonsvindauge som dukkar opp i kartutsnittet når brukaren held musepeikaren over ein ID-markør, jf. informasjonsvindauga på finnsenderen.no Informasjonsvindauget skal ha «grein» til gjeldande ID-markør for å markere kva for ID-markør informasjonsvindauget er knytt til. Dersom det er fleire ID-markørar for same hendinga i kartutsnittet (jf. krav [ ]) skal informasjonsvindauget også ha greiner til desse. Illustrasjonen i vedlegg 1 viser døme på dette Informasjonsvindauget skal vise informasjon om: - «Når» (oppsto, jf. rapporteringsskjema kap 3) - «Hvem» (brukarnamnet til tilbydaren som har registrert hendinga) - «Hva» (teneste, jf. rapporteringsskjema) - «Hvordan» (teknisk omfang/kundeomfang jf. - rapporteringsskjema) - «Hvor» (geografisk omfang (fylke) samt ev. nærmare geografisk skildring, jf. rapporteringsskjema). - «Status» (status, jf. rapporteringsskjema) - «Normalisert» (normalisert, jf. rapporteringsskjema) Dersom hendinga er aktiv (ID-markør raud) skal det i feltet «Normalisert» stå «Forventet [dato/klokkeslett]». Dersom hendinga er avslutta (ID-markør grøn) skal det berre stå «[dato/klokkeslett]». Feltet «Hvor» skal ha dette formatet: «[Fylkesoversikt/landsdeloversikt]. [Ev. nærmare geografisk skildring].» (jf. rapporteringsskjema). Sjå vedlegg 2 om korleis [fylkesoversikt/landsoversikt] skal listast opp. For brukarar med rette tilgangsrettar, jf. krav [4.2.2], skal òg desse felta visast: «Kritiske brukere» (samfunnskritiske brukere, jf. rapporteringsskjema) «Årsak» (årsak, jf. rapporteringsskjema) Informasjonsvindauget skal nedst vise dato/klokkeslett for når informasjonen vart sist oppdatert Systemet skal lukke informasjonsvindauget når brukaren tar bort musepeikaren frå ID-markøren Rapporteringsside Grensesnitt Rapporteringssida skal ha eit rapporteringsskjema for å registrere informasjon om hendingar, jf. kap I rapporteringsskjemaet skal det kome klart fram kva som er primærinformasjon (tilgjengeleggjerast på kart til alle) og tilleggsinformasjon (tilgjengeleggjerast på kart til superbrukarar). Primærinformasjon er «Oppsto», «Normalisert», «Status», 10

11 «Teneste», «Teknisk omfang/kundeomfang», «geografisk omfang» og «Nærmare geografisk skildring». Tilleggsinformasjon er «Samfunnskritiske brukarar» og «Årsak» Funksjonar Systemet skal på førehand fylle ut ein rullegardinmenyen eller liknande med hendings-id-en til tilbydaren sine aktive hendingar (som allereie er registrert i systemet) Brukaren skal kunne skrive inn ny hendings-id for å etablere ny hending 2, velje ei aktiv hending i rullegardinmenyen for å oppdatere ei aktiv hending, eller skrive inn hendings-id-en til ei avslutta hending (som framleis er registrert i systemet) for å reaktivere ho Ved valt hendings-id visast hendings-id-en i skjemaet, saman med følgjande tekst: Ved ny hending: «Etablering av ny hendelse» Ved aktiv hending: «Oppdatering av aktiv hendelse» Ved tidlegare avslutta hending: «Reaktivering av avsluttet hendelse» Ved registrering av «Når» og «Normalisert» skal brukeren kunne opne klikkbar kalender som kan fylle ut datofeltet (i tillegg til å kunne skrive inn dato manuelt) Ved registrering av «Geografisk omfang» skal brukaren kunne velje i ei fylkesoversikt kva fylker som hendinga omfattar (liste eller kart). Valte fylker skal visast i skjemaet. Sjå vedlegg 2 om korleis dette skal listast opp Dersom valte hending er registrert i systemet, skal felta i skjemaet fyllast ut automatisk «E-postadresse for kvittering» skal førehandsutfyllast ut med varslings-e-postadressa som er registrert på brukaren. Brukaren skal ha moglegheit til å endre e-postadressa Påkravde felt skal markerast med stjerne. Systemet skal gi tilbakemelding til brukaren når: - Påkravde felt ikkje er fylt ut - Dato/tidsformat ikkje er registrert på korrekt måte Systemet skal gi tydelig tilbakemelding på kva felt dette gjeld Når ei ny hending blir etablert skal informasjonen lagrast i databasen, jf. krav [4.1.3] Når ei eksisterande hending blir oppdatert, skal tilknytt 2 Det leggast opp til at tilbydarane kan nytte sin interne «troubleticket ID» som hendings ID, for å lette tilbydaren si administrering av hendingar internt og mot FEKOMS systemet. 11

12 informasjon skrive over den gamle informasjonen i databasen (det er berre siste registrerte status som skal verte lagra) Systemet skal be om stadfesting før brukaren kan oppdatere ei hending Varsling Grensesnitt Grensesnitt for varsling er e-post. Brukarar mottek e-postvarsel om hendingar på bakgrunn av varslingsoppsett, jf. krav [ ] og [ ] Funksjonar Systemet skal ved kvar registrering og oppdatering av hending sjekke om dei ulike brukarane sine varslingsvilkår jf. krav [ ], er innfridd: Når det ikkje er sett varslingsvilkår, skal det ikkje varslast. Når det er sett eitt varslingsvilkår (tid, fylke eller tilbydar), skal det berre varslast dersom dette vilkåret er innfridd. Når det er sett fleire varslingsvilkår skal det berre varslast dersom alle desse varslingsvilkåra er innfridd. Systemet skal sjekke følgjande for dei ulike varslingsvilkåra: (Normalisert-Oppsto) > Tid Fylke == (Fylke A eller Fylke B eller ) Tilbydar == (Tilbydar A eller Tilbydar B eller ) Administrator sett varslingsvilkåra for kvar brukar Systemet skal sende e-postvarsel til brukaren dersom brukaren sine varslingsvilkår er innfridd. Innhaldet i e-posten skal vere: «FEKOMS har registrert en ekomhendelse den [Dato/tid]. For situasjonsoversikt se [URL]. Det er satt følgende varslingsvilkår for din bruker: [list opp varslingsvilkår]. Kontakt [administrator(ane) sin e- post] dersom du ønsker å endre varslingsvilkårene.» 12

13 6. TEKNISKE KRAV 6.1 Systemet skal utviklast i Java Enterprise Edition (EE). 6.2 Systemet skal nytta seg av Richfaces som rammeverk for brukargrensesnitt. 6.3 Spring skal nyttast som modell/rammeverk. 6.4 Hibernate skal nyttast for å persistere data. 6.5 Systemet skal være database uavhengig. 6.6 Integrasjon mot PTs arkivløysing skal nytte web-tenester som er utvikla av PT. Brukar interaksjon og annan kode som skal nytta web-tenestene må utviklast. 6.7 Mule (mulesoft) skal nyttast ved behov for ESB funksjonalitet. 6.8 Systemet skal loggføra hensiktsmessige hendingar. 6.9 Systemet skal nytta Glassfish som applikasjons server Det er naudsynt å ha ei løysing som sikrar at data som vert overførde til PTs arkivsystem faktisk kjem fram. Systemet må kunne handtera at arkivsystemet ikkje alltid er tilgjengelig utan at data som skal arkiverast vert borte Konfigurasjonsdata skal leggast inn i ein eigen databasetabell i databasen. 13

14 VEDLEGG 1 KARTSIDE Hendelses-ID: 1 Oppsto kl. 22:45 Hvem Telenor Hva Tale og SMS (2G) Hvordan Problemer med samtaleoppsett Hvor Møre og Romsdal, Sør-Trøndelag. Nordmøre og nordover Status Feilsøking pågår, sammen med leverandør Normalisert Forventet kl. 10:00 Sist oppdatert kl

15 VEDLEGG 2 VISNINGSREGLAR FOR GEOGRAFISK OMFANG Visningsreglar for geografisk omfang: 1. Hovudregel: [fylkesoversikt/landsdeloversikt] = «[Fylke x], [Fylke y], [ ].» 2. Dersom alle landets fylke er merka: [fylkesoversikt/landsdeloversikt] = «Hele landet.» 3. Dersom fylka Østfold og Akershus og Oslo og Hedmark og Oppland og Buskerud og Vestfold og Telemark er merka skal desse erstattast med «Østlandet» 4. Dersom fylka Aust-Agder og Vest-Agder er merka skal desse erstattast med «Sørlandet» 5. Dersom fylka Rogaland og Hordaland og Sogn og Fjordane og Møre og Romsdal er merka skal desse erstattast med «Vestlandet» 6. Dersom fylka Sør-Trøndelag og Nord-Trøndelag er merka skal desse erstattast med «Trøndelag» 7. Dersom fylka Nordland og Troms og Finnmark er merka skal desse erstattast med «Nord- Norge» 8. Dersom alle fylka frå og med Nord-Trøndelag og sørover er merka skal desse erstattast med «Sør-Norge» Døme: Møre og Romsdal og Sør-Trøndelag er merka: [fylkesoversikt/landsoversikt] = «Møre og Romsdal, Sør-Trøndelag» Telemark, Aust-Agder og Vest-Agder er merka: [fylkesoversikt/landsoversikt] = «Telemark, Sørlandet.» Alle fylker bortsett frå Troms og Finnmark er merka: [fylkesoversikt/landsoversikt] = «Sør-Norge, Nordland» Alle fylker bortsett frå Troms, Finnmark og Østfold er merka: [fylkesoversikt/landsoversikt] = «Akershus, Oslo, Hedmark, Oppland, Buskerud, Vestfold, Telemark, Sørlandet, Vestlandet, Trøndelag, Nordland.» 15