wiki.met.no

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Flere trafikklys på yr! ======


===== Formål =====

Gi brukerne mer informasjon om kvaliteten på varslene Et varsel er i denne sammenhengen det automatisk genererte varselet som brukerne først møter etter å ha valgt sted. Dette viser i dag de seneste observasjonene av temperatur, nedbør, vind og skydekke (hvis alt er tilgjengelig). Videre vises min.- og maks.-temperaturer fra de siste 30 døgn.


===== Bakgrunn =====

Vi har merket at ettersom utbredelsen av tjenesten (yr) griper om seg, blir publikums oppmerksomhet i stigende grad rettet mot kvaliteten av varslene. Det finnes ingen snarvei til å bringe fram noen betydelig forbedring av varselkvaliteten. Hvis vi er villig til å erkjenne begrensningene i hvor godt vi kan varsle, tror jeg vi langt på vei kan imøtekomme kritikken ved å dokumentere hvor gode (eller dårlige!) våre varsler har vært. Det blir vanskeligere å kritisere oss når vi dokumenterer og blottstiller kvaliteten. (Noen vil alltid påstå at det er en selvfølge at varslene er presise hele tiden, den gruppen må nok vente lenge på å bli fornøyd!)

Jeg tror dette vil kreve nyutvikling, fordi eksisterende validering ("verifikasjonsrapporter") trolig ikke egnet for dette formålet (for lite publikumsvennlig). Mitt forslag er at vi bygger videre på dagens bruk av trafikklys for forventet presisjon av langtidsvarslene.


===== Nytt produkt: Trafikklys basert på validering =====

I dag kommer det opp tidsserier med observasjoner fra en eller flere (nærliggende?) stasjoner når varselet vises for valgt sted. Det nye produktet er et eller flere trafikklys basert på validering av tidligere varsler for stedet der observasjonene blir gjort. Best er det kanskje å ha ett trafikklys for hver stasjon i "stasjonsboksen", og en link til side med utfyllende trafikklys.

Trafikklysene kan utarbeides for ulike varslingstider (f.eks. et lys for kvaliteten av varselet for de nærmeste 24 timer, et annet for varselet 24-48 timer fram i tid osv.), utarbeidet fra resultater og observasjoner for en fastsatt periode (f.eks. siste 30 døgn). Dette kan også suppleres med "trafikklyshistorikk" som for eksempel kan vise hvor godt været blir varslet for hver sesong, eller hver måned. Det hadde jo også vært spennende å kunne vise fram hvordan varselkvaliteten endrer seg over tid, men dette krever oppbygging av en database over automatiske yr-varsler for observasjonspunkter som dekker flere år. (En slik database finnes vel ikke i dag?)

Ideelt skulle man naturligvis hatt et trafikklys for stedsvalget, men et slikt produkt må bygge på observasjoner, og en interpolasjon vha. statistiske sammenhenger el.likn. kan gi unøyaktigheter som gir nytt grunnlag for kritikk. Ved å begrense valideringen til faktiske observasjoner vil trafikklysene gi en informasjon om reell varslingspresisjon når det er god kvalitet på observasjonene (er denne kvaliteten dårlig bør stasjonen kuttes ut fra yr).

Utfordringen med å utvikle dette produktet vil være å velge fornuftige terskler for overgangen mellom grønt og gult lys, og mellom gult og rødt lys. Det er mange mulige veier til en løsning, her er noen:
  * standardavviket til tidsserier for størrelsen
  * avvik fra persistens
  * inndeling av varsler og observasjoner i grupper (f.eks. ut fra grenseverdier for ikke nedbør-lite nedbør-moderat nedbør-mye nedbør-ekstremnedbør, evt. delt opp mellom regn og snø)

Det aller beste hadde vært å overlate til publikum å definere grensene. yr har tidligere benyttet paneler av brukere for å få innsikt i hvordan tjenesten bør utvikles. Noe slikt kan kanskje benyttes, men en forskjell vil nok være at man har behov for tilbakemelding over tid; kanskje for et helt år (eller flere år!) fordi toleransen for f.eks. temperaturavvik kan være ulike i ulike sesonger. Man kan jo også utvikle dette produktet over tid, ved å begynne med egen-definerte grenser for etterhvert å bytte ut disse med bruker-definerte grenser.

Et annet element som bør vurderes, er hvorvidt det er hensiktsmessig med ulike grenser for ulike trafikklys. Problemstillingen rundt sesonger som ble skissert over, er et eksempel på dette. Et annet eksempel er om man skal ha ulike grenser for ulike varslingsperioeder: kanskje brukernes forventninger til et langtidsvarsel er lavere, og at "snillere" grenser bør anvendes? eller kanskje det er bedre med "homogene" trafikklys gjennom varslingsperiode. Jeg vet ikke.

Det er naturlig å tenke seg at det er varslene for temperatur og nedbør som i første omgang angir kvaliteten på, fordi dette er variable som det blir gjort mange observasjoner av, og fordi dette vil dekke mye av publikumsinteressen. Det er klart at det også er interesse for f.eks. skydekke og vind, men her er kanskje observasjonsgrunnlaget litt spedt? (Kanskje trykktendens kan brukes for å validerere vindstyrke?)
 
Man kan selvfølgelig tenke seg at andre symboler enn trafikklys blir brukt til dette formålet, f.eks. en serie med stjerner som fylles ettersom hvor godt punktvarselet validerer, eller kanskje en mer tabloid variant: terningkast.

Jeg er klar over at det fra met.no sin side er ønskelig at brukerne skal legge mer vekt på tekstvarselet enn på den automatiserte grafiske framstillingen av varselet. Jeg foreslår likevel at vi ikke tar sikte på å validere tekstvarselet. Det er to grunner til dette: (1) tekstvarselet er utformet altfor omtrentlig til at det lar seg validere kvantitativt (en kvalitativ validering vil fort ende opp med at bukken passer havresekken); (2) vi må vel erkjenne at det er den grafiske framstlilingen som det store flertallet av brukerne forholder seg til.

I forlengelsen av et slikt produkt kan man tenke seg en mer interaktiv tjeneste. Databasen vår er stor, men kanskje vi kan lagre temperaturvarselene for alle punkter (evt. en fornuftig gruppering av punktene) i en offentlig database. Man vil da kunne se for seg at det utvikles applikasjoner der brukere med digitaliserte observasjoner fra egen "værstasjon" kan validere varslene for sitt punkt. Dette kan om ønskelig kombineres med at kundeobservasjonene lastes opp i vår database for bruk ved met.no.