System for lagring av data for transportmodeller/analyser og etterprøvingsverktøy

Transkript

1 SINTEF A6076 Åpen RAPPORT System for lagring av data for transportmodeller/analyser og etterprøvingsverktøy Snorre Ness SINTEF Teknologi og samfunn Veg- og transportplanlegging September 2008

2

3

4

5

6

7 1 INNHOLDSFORTEGNELSE 1 Innledning og bakgrunn Mål Behovskartlegging Arbeidet med analyser og lagringsbehov Regional transportmodell RTM region Datatyper - modellverktøy Datalagring - modellverktøy Datalagring - inndata Datatyper analyser Metadata Forhold som bør vurderes av systemeier knyttet til fagapplikasjonen Godstransportmodell Nasjonal transportmodell - NTM5b Strategiske transportmodeller TASS Fredrik/Emma Contram Datatyper Datalagring Metadata EFFEKT Datatyper Datalagring Metadata Forhold som bør vurderes av systemeier knyttet til fagapplikasjonen VSTØY/VLUFT Datatyper Datalagring Metadata Forhold som bør vurderes av systemeier knyttet til fagapplikasjonen NorStøy Datatyper Datalagring Metadata Forhold som bør vurderes av systemeier knyttet til fagapplikasjonen PDB Excel TAV Lagringsløsning Om EMC Documentum eroom Konsept Brukerroller Arbeidsflyt og godkjenningsprosedyrer Metadata i eroom...24

8 2 16 Forholdet til MIME Konklusjoner og anbefalinger...26

9 3 1 Innledning og bakgrunn Statens vegvesen gjennomfører hvert år mange utredninger og analyser av tiltak som beslutningsgrunnlag inn i sentrale prioriteringsprosesser. Analysene gjennomføres av Statens vegvesen selv, eller av konsulenter. I dag er det liten kontroll med lagring av datagrunnlag og resultater, og derfor er det vanskelig å kvalitetssikre eller etterprøve analyser som gjennomføres. Statens vegvesen har satt fokus på dette området, og behovene for lagring av grunnlagsdata, forutsetninger og resultater er omtalt i denne prosjektrapporten. Gjennom bl.a. arbeidet med Nasjonal transportplan arbeider Statens vegvesen aktivt med utvikling av verktøy for transportanalyse, og med hyppige oppdateringer og stadig nye filversjoner, er det også her et behov for et system som kan hjelpe til med å holde orden på versjoner av filer og modeller. Dette gjelder særlig transportmodellene, da disse har en mer integrert struktur mellom programmer, metodikk, dataflyt og grunnlagsdata enn andre fagapplikasjoner som benyttes. Transportmodellene er den fagapplikasjonen som har kortest historie, og er således fortsatt under utvikling. Denne rapporten er strukturert som følger: Kapittel 5-14 går gjennom den enkelte fagapplikasjon og skisserer data som bør lagres Kapittel 15 foreslår lagringsløsning 2 Mål Prosjektets mål er å foreslå løsninger for systematisk lagring av data fra transportmodeller, transportanalyser, støy- og luftberegningsverktøy, nyttekostnadsberegninger m.m.. Disse programmene er i denne rapporten omtalt som fagapplikasjoner. Systematisk lagring er en forutsetning for å forenkle samhandling i selve analysearbeidet, for å sikre at de seneste og mest oppdaterte modellversjonene benyttes og for å sikre analysegrunnlaget, slik at etterprøving av vegprosjekter er mulig. Det er en forutsetning fra oppdragsgivers side at løsningen som skisseres skal være basert på teknologi som finnes i samhandlingsløsningen EMC Documentum eroom. Denne løsningen er i bruk i Statens vegvesen, og brukerne som arbeider med fagapplikasjoner for transportanalyser i dag er i stor grad kjent med grensesnitt og funksjoner i eroom. Det er også synliggjort et mål om at arbeidet skal forberede overgangen til Statens vegvesens nye system for lagring av ustrukturert informasjon, MIME.

10 4 3 Behovskartlegging Det har vært gjennomført en workshop i prosjektet, der representanter for brukermiljøene for de ulike fagapplikasjonene fikk presentere behovet for lagring av data i det kommende forvaltningsssystemet. Workshopen ble avholdt 19. oktober 2007 ved Statens vegvesen Vegdirektoratet i Trondheim. Følgende personer var tilstede under workshopen: Tabell 1 Deltakere på prosjektets workshop Navn Organisasjon Tema Ali Taheri Statens vegvesen Region midt Anne Kjerkreit Statens vegvesen Vegdirektoratet Før- og etterundersøkelser Bjørn Sandelien Statens vegvesen Vegdirektoratet Prosjektdatabanken og TAV Elisabeth Herstad Statens vegvesen Region sør Før- og etterundersøkelser, transportmodeller og EFFEKT Erik Ørbeck Kystverket Transportmodeller og tverretatlige behov Ina Abrahamsen Statens vegvesen Vegdirektoratet RTM og NTM5 Nebojsa Doder Statens vegvesen Region sør TASS, Contram og simuleringsmodeller Oskar Kleven NTP Transportanalyser Godstransportmodeller Roar Norvik SINTEF Teknologi og samfunn Snorre Ness SINTEF Teknologi og samfunn Stig Nyland Andersen Statens vegvesen Region vest Brukererfaringer og -behov Tomas Levin SINTEF Teknologi og samfunn CONTRAM Torunn Moltumyr Statens vegvesen Vegdirektoratet VSTØY/VLUFT, NorStøy og andre miljøberegningsverktøy Workshopen ga en oversikt over lagringsbehovet til de ulike fagapplikasjonene, uten at denne ble oppfattet som komplett. SINTEF har derfor behandlet innspillene fra workshopen sammen med egen kunnskap om bruken av fagapplikasjonene. Det har også vært gjennomført egne avklaringsmøter med systemeiere eller superbrukere og utviklermiljøer, for å avklare behov og mulighetene for lagring av data. Dette har gitt en viss oversikt, uten at denne kan sies å være komplett. Ved et eventuelt videre arbeid med utforming av lagringsstruktur fra de ulike verktøyene vil det være behov for en diskusjon med systemeierne for de ulike fagapplikasjonene. Under workshopen ble det også diskutert behov for en overordnet identifisering og oversikt over de tiltakene Statens vegvesen har analysert, analyserer eller planlegger å analysere. En overordnet katalogisering vil kunne gjøre det enklere å relatere data, analyser, rapporter og annet relevant materiale til riktig prosjekt eller tiltak. En unik identifikator kunne ha gjort det enkelt å søke etter informasjon som er relatert til prosjektet dersom regler for hvordan denne skulle brukes hadde vært publisert. Disse må gjøres gjeldende innenfor Statens vegvesen og gjennom kontrakter med de som arbeider for Statens vegvesen som konsulenter. SINTEF anbefaler at man ser videre på dette innspillet, også i forhold til senere planer om lagring i MIME. Oppsummering av workshopens resultater relatert til den enkelte fagapplikasjon er inkludert som en del av forslagene til applikasjonsspesifikke løsninger, i kapitlene 4 til og med 14.

11 5 4 Arbeidet med analyser og lagringsbehov Det har vært stort fokus på de ulike fagapplikasjonene i prosjektet. Dette er sikkert riktig, men vi mener at man heller ikke må glemme det praktiske arbeidet med analyser der man benytter applikasjonene. Det er behov for minst to lagringsnivåer som bør skilles fra hverandre i dette prosjektet: Nivå 1: Struktur for vedlikehold av modeller og offisielle datasett Nivå 2: Struktur for samhandling, lagring og arkivering av gjennomførte analyser Nivå 1 vil være for å kunne distribuere felles programversjoner, modellversjoner, forutsetninger og informasjon til de som gjennomfører analysene, mens nivå 2 vil være en arbeidsflate og lagringsløsning for selve analysene. Dette er ytterligere beskrevet og eksemplifisert i kapittel 15.

12 6 5 Regional transportmodell RTM region RTM Persontransportmodeller er regionalt oppdelte modeller som beregner personreiser under 100 km. Hver av de regionale modellene har et regionalt eierskap. Det er etablert en fast kontaktperson som per i dag sørger for en manuell forvaltning. De regionale transportmodellene er det programsystemet som har det mest kompliserte behovet for lagring av data. Det er behov for mange forskjellige datatyper som inngangsdata til modellene, og det er ikke etablert installasjonsprogrammer for installasjon av fagapplikasjonen på brukernes datamaskiner. Modellene er under kontinuerlig utvikling/oppdatering, parallelt med at modellsystemet også har vært benyttet til mange analyser. Dette kompliserer dataforvaltningen ytterligere da det ofte er gjennom praktisk bruk at datagrunnlaget forbedres. Det er derfor svært krevende å holde oversikt over gjeldende versjoner av filene som benyttes i modellsystemet. I tillegg til det arbeidet som pågår med utvikling av modellverktøyet, er det også en del bruk av verktøyet til analyser, noe som stiller litt andre krav til lagringssystemet. Man ønsker derfor å skille mellom administrasjon av fagapplikasjonen/modellen og data som tilhører basisscenariene til modellverktøyet og data som tilhører de analysene som gjennomføres. 5.1 Datatyper - modellverktøy Modellverktøyet inneholder en modellstruktur, noen programmoduler og enkelte modellfiler som inneholder styringsparametere og nasjonale inngangsdata. Disse bør behandles som integrerte deler av modellverktøyet, siden de ikke forutsettes endret av brukere av modellen. Disse filene er like for alle brukere av modellsystemet, og det er viktig at det finnes et opplegg for versjonsstyring og vedlikehold av filer i modellen. Det viktigste momentet er imidlertid at de siste offisielle versjoner av filene er tilgjengeligjort på et lagringssted som alle brukerne av modellen kan få tilgang til. Datatyper som bør lagres er vist i tabellen under, Tabell 2. Tabell 2 Datatyper som bør lagres for RTM Persontransportmodell - modellverktøyet Datatyper Innhold Filtyper Kommentar Modellfiler Katalogfil med tilhørende moduler Katalogfil (*.cat) Programmoduler i modellstrukturen f.eks. Tramod.exe, RTM.exe Programfiler (*.exe) Felles for alle regioner. Parameterfiler og definisjonsfiler Parametre som kalibrerer på rammetallnivå, Tekstfiler Spesifikke filer for hver region. reisemiddelfordeling og reisehensiktsfordeling. Sonedata Inneholder sonedata for *.txt En fil for hele Kopling mot NTM5b nettverk hele landet. Definerer hvor trafikken fra NTM5b skal påkobles RTM nettverket. *.dat landet. Spesifikk for hver region. Det vil være viktig å lagre de forskjellige modellversjonene på eroom, slik at man kan bruke eldre modellversjoner dersom man ønsker å kontrollere beregninger som er gjennomført på et

13 7 tidligere stadium. Det kan tenkes at det eksisterer bindinger mellom versjoner av den implementerte transportmodellen og modelleringsverktøyet, Cube. Dette vil i så fall medføre hindringer i forhold til bruk av gamle modellversjoner dersom ikke lagring av både modelleringsapplikasjonen Cube og modellversjoner lagres. Modellstrukturen er gjenstand for stadige oppdateringer, ikke minst knyttet til programmodulene og de ulike filene som styrer beregningene. Rutiner for ajourhold av disse behandles ikke i dette prosjektet, men det er angitt forslag til hvordan man bør versjonsstyre filene i kapittel 5.6. Modellstrukturen er under revisjon når dette prosjektet rapporteres. Det forventes at modellstrukturen blir endret i noen grad som følge av overgang fra TRIPS- til Cube Voyagerrutiner for beregninger. Systemeier bør i den grad det er mulig sørge for at system for versjonering av programfiler etableres når modellen nå revideres. 5.2 Datalagring - modellverktøy Lagring og distribusjon av modellversjoner bør gjøres slik at det distribueres fulle versjoner av modellen uten grunnlagsdata, hver gang man gjør endringer. I dag distribueres modellene i pakkede filer med kataloginformasjon som legges ut på eroom, og dette er det grunn til å videreføre. Dette sikrer at alle brukerne har tilgang til offisielle versjoner av modellsystemet. Manuell oppdatering og plassering av filversjoner i modellstrukturen er en usikker måte å distribuere filer på, siden det krever vesentlig brukerinteraksjon og bør derfor følges opp med installasjonsveiledninger. Det må lages en lagringsstruktur der det er enkelt å finne fram til offisielle godkjente versjoner av modellsystemet, samt muligheter for å se endringslogger over hvilke endringer som er gjort mellom de ulike versjonene. Det bør også være muligheter for nedlasting av tidligere versjoner av modellene, men ikke editering/utskiftning av disse. 5.3 Datalagring - inndata Det er god grunn til å separere modellversjonene fra de regionale scenariospesifikke inndataene, både på grunn av datalagringsmessige årsaker og eierskap til datafiler. Lagring av offisielle og godkjente basis- og prognoseår gjøres på lignende måte som for modellsystemet, men i egne katalogstrukturer. For at modellen skal fungere, må man ha spesifikke inndata for hver region og hvert scenario. Nedenfor er et sammendrag av hvilke filer som må være tilstede for at beregningene kan gjennomføres. Inndata for modellen: - definisjonsfiler for hvor NTM trafikken skal komme inn i regionen Inndata for ett scenario, 25 filer der - 4 filer har låst filnavn i forhold til scenariet (nettverk og rutebeskrivelser) - 1 fil er fartsdata fra effekt og må tilrettelegges for hvert prosjekt (valgfritt) - 1 fil er en fast matrise (gods) - 5 filer for ferger (overfart, vent, kost fører, kost passasjer, antall) - 2 filer for direkte kostnader (bom fører, bom passasjer) - 9 andre filer (5 buffer, 2 internavstand, 1 telling, 1 sving) Vi anbefaler at filene for hvert basisscenario (dagens situasjon evt. prognosesituasjoner) pakkes sammen (zappes) slik at de enkelt kan lastes ned. Zip-filen gis et hensiktsmessig navn som

14 8 inneholder datoen de var oppdatert for. 5.4 Datatyper analyser Regionale modeller for persontransport er i ferd med å tas i bruk til tiltaksvurderinger over hele landet, som grunnlag for prioriteringer inn i Nasjonal Transportplan(NTP). Modellene tas i bruk av brukere både innenfor og utenfor transportetatene, og det er viktig å få på plass et system for hvordan data fra analysene skal lagres. Det er to hovedhensyn som bør ivaretas med hensyn til bruk av modellene til analyser: Å gi brukere av transportmodellene en arena for samhandling, slik at man har kontroll på filer og modellversjoner mens modellene er i bruk. Å gi brukere og regionale koordinatorer et sted å lagre transportmodellberegninger ved prioriteringstidspunktet, slik at de bevares med hensyn til etterprøvingsformål. Det er først og fremst det siste behovet som krever struktur og sikkerhet mot endring, men behovene vil bli håndtert noenlunde likt i forslaget til implementert løsning. Lagring av analysescenarier skjer i en egen katalogstruktur, der brukerne skal ha muligheter til å benytte deler av katalogstrukturen som arbeidsflate for pågående analyser og beregninger. En separat del av denne katalogstrukturen vil være låst for endring, og her skal offisielle versjoner av modellkjøringer som har vært grunnlag for EFFEKT-beregninger og prioriteringer i NTP, lagres. Det er mange filer som må lagres etter utførte analyser med transportmodeller, og det er grunnlag for å se på om prosessen med samling av de filene som må lagres kan automatiseres. Det vil være en grei utviklingsjobb å lage et pilotskript i Cube som kopierer de filene man trenger å ta vare på etter fullført beregning til en egen scenariokatalog, basert på informasjon om filene fra scenariodefinisjonen. Disse filene kan så pakkes med et komprimeringsprogram og lastes opp på eroom av brukeren. Automatisering av denne arbeidsoppgaven er et vesentlig bidrag til kvalitetssikring av arbeidet det er å ta vare på de riktige og nødvendige filene for dokumentasjon av en transportmodellberegning.

15 9 Tabell 3 Datatyper som bør lagres for RTM Persontransportmodell - analyser Datatyper Innhold Filtyper Kommentar Inndatafiler Tekstfiler Transportnett Tekstfiler (*.dat) Kollektivrutebeskrivelser Tekstfiler (*.dat) Ferge- og bomfiler Tekstfiler (*.dat) Fartsdata fra EFFEKT Tekstfil (*.eff) Sonedatafiler Tekstfiler (*.txt) Definisjonsfil for Tekstfiler (*.dat) påkobling av NTMtrafikk til RTM Inndatafiler - Matriser Godsmatrise fast Matrisefil Tilbringertrafikk Matrisefil flytransport Skolematrise Buffermatriser Matrisefiler Inndatafiler Shapefiler Transportnett Shapefiler Kollektivrutebeskrivelser Shapefiler Resultatfiler Lenketrafikk til EFFEKT Tekstfil (*.dat) Resultater fra Tekstfil (*.dat) trafikantnyttemodul til EFFEKT Resultater fra Tekstfil (*.dat) kollektivmodul til EFFEKT Reisemiddelfordeling Rapport Reisehensiktsfordeling Rapport Nettverksfil Nettverksfil Resultatfiler fra nettfordeling for bilfører, bilpassasjer og kollektiv Scenariodefinisjonsfil Tekstfil 5.5 Metadata Metadata relatert til versjoner av modellverktøyet, er per i dag knyttet til et versjonsnummer av katalogfila, og denne gjenspeiles i katalogfilas navn. Dette er en enkel og grei måte å gjøre det på, som gjør det mulig å se hvilken modellversjon man benytter. Metadata relatert til analyser er per i dag knyttet til Cube-rapporten scenariodefinisjon. Denne dokumenterer sentrale forutsetninger for beregningene, som for eksempel dato og tid for beregningen, samt hvilke inndatafiler som er benyttet til analysen. Forklaring av denne rapporten finnes i brukerveiledningen til RTM. Det er god grunn til å gå nærmere inn på versjoner av filer internt i modellen, da disse ikke har noe eget versjonsnummer pr. i dag. Man bør vurdere å innføre versjonsnumre av egenutviklede programmoduler, slik at man har kontroll på hvilke programversjoner som er benyttet i

16 10 beregningene. Det må stilles krav om dette til dem som utvikler programmene, eksempelvis SINTEF og Møreforsking Molde. Versjonsinformasjon legges inn ved utvikling av programmene, og denne kan også leses av programmatisk for produksjon av metadata om en transportmodellberegning. For de filtypene som har fast filnavn, og ikke er kompilerte filer, bør det vurderes å innføre krav om innlegging av kommentarer i filene. Filkommentarer kan legges inn fra programmene som benyttes for redigering, for eksempel Cube eller ArcGIS. 5.6 Forhold som bør vurderes av systemeier knyttet til fagapplikasjonen Momentene under bør betraktes som forbedringsforslag basert på et mål om enklere og sikrere lagring av data fra dataprogrammet, og er mer utførlig beskrevet i foregående kapitler: Innføring av versjonsinformasjon i egenutviklede programfiler oppfølging av krav mot utviklingsmiljøer. Innføring av headerinformasjon i vanlige filer. Utvikling av pilotskript for samling av filer som er nødvendige å lagre som dokumentasjon for å tilfredsstille kravet som stilles i forhold til etterprøving.

17 11 6 Godstransportmodell Modellene for person- og godstransport som er utviklet i regi av NTP, er grovt sett like hva angår inngangsdata. Transportnettet skal i hovedsak være likt ved at nettverket fra regional persontransportmodell er det samme nettverk i nasjonal godsmodell. Terminaler for gods er kodet inn i transportmodellen som soner som gir tilknytning/omlasting mellom de ulike transportformene. Godsmodellen er basert på modellsystemet Cube, som for de regionale modellene for persontransport. En forskjell mellom person- og godsmodellene, er at transportnettet for godsmodellene er lagret i en felles nettverksfil. Det eksisterer altså ikke regionalt delte inngangsdata for denne modellen. Som grunnlag for å se nærmere på lagringsbehov for den regionale godstransportmodellen, har SINTEF fått tilgang til en beskrivelse av modellstrukturen i logistikkmodulen, utformet av Anne Madslien, TØI. Denne sier ikke mye om hvordan man ser for seg bruken av modellsystemet i forholdet til behovet for ajourhold og lagring av modellversjoner. Under workshopen i prosjektet ble den nasjonale godstransportmodellen presentert. Oversikten fra den gangen viser at man hittil ikke har tenkt spesielt på versjonering av filer gjennom navngiving. Vi forutsetter at scenariohåndteringen vil bli noenlunde lik som i persontransportmodellene, all den tid begge modellene er basert på Cube. I så fall vil mange av prinsippene fra persontransportmodellene også kunne benyttes for godsmodellene. I samråd med Statens vegvesen Vegdirektoratet, foreslår SINTEF at forvaltningsansvaret for godstransportmodellen underlegges sentrale ressurser i Statens vegevesen Vegdirektoratet. 7 Nasjonal transportmodell - NTM5b NTM5b er en transportmodell som beregner personreiser over 100 km. NTM5b har et grensesnitt mot RTM ved at man overfører matriser fra NTM til RTM modellsystemet, konverterer dem og nettfordeler dem på det regionale transportnettet. Dette gir en betydelig bedre beskrivelse av totalt antall reiser, og gir også bedre presentasjonsmuligheter. I tilfeller der man studerer tiltak som forventes å påvirke lange reiser, kjøres også analyser i NTM5b for å kunne studere andre virkninger enn de som skyldes omfordeling av trafikk i transportnettet. På mange måter er NTM5b en ekspertmodell, og den er derfor ikke i bruk på samme måte som de regionale modellene for persontransport. Imidlertid foreslår vi etablering av en enkel struktur for lagring av modellverktøyet, samt en struktur som kan brukes som arbeidsflate for analyser og lagring av ferdigkjørte analyser. NTM5b er bygget over transportmodelleringsverktøyet EMME/2 fra INRO. I NTM lagres alle inn- og utdata i en databank, som egentlig er en databasestruktur. Denne kan i sin helhet tas vare på og lagres i eroom, men bør som for øvrige datasett ryddes i slik at man ikke tar vare på unødvendig store datamengder. Prosjektet har ikke gått inn i hvilke deler av databanken som bør ryddes opp i før en lagring finner sted.

18 12 8 Strategiske transportmodeller 8.1 TASS TASS 1 -modellene er bymodeller for strategiske studier, og har store likheter med RTM Persontransportmodeller hva gjelder behov for lagring av data for dokumentasjon og etterprøving av analyser. TASS-modellene er bygd på Cube, og scenariohåndteringen benyttes på samme måte i de to modelltypene. TASS er derimot ikke fullt like moden som RTM Persontransportmodeller når det gjelder tanker rundt forvaltning av data, brukergrensesnitt og tilrettelegging for standardiserte resultatuttak. Vi anbefaler at lagringsstrukturen for TASS-modellene settes opp på samme måte som for RTM Persontransportmodeller, da disse har likheter i strukturering. Det er satt i gang arbeider for ytterligere å tilpasse datalagringsstrukturene i TASS til RTMs måte å organisere data på. Forslag til systemeier på aksjoner for tilpasninger til et forvaltningssystem som angitt for RTM Persontransportmodeller, er også gyldige for TASS-modellene. 8.2 Fredrik/Emma Fredrik/Emma-modellen for Oslo og Akershus er i likhet med TASS-modellene en strategisk modell for transportanalyser. Transportmodellen er basert på transportmodelleringsverktøyet EMME/2 fra INRO. Datastrukturen i Fredrik/Emma vil ligne datastrukturen i NTM5b, som beskrevet i foregående kapittel. Data og resultater lagres i en databank, der data som er viktige for den beregningen, må tas vare på og arkiveres. 1 Transportmodell for Strategiske Studier

19 13 9 Contram Contram har en begrenset geografisk utbredelse i Norge, spesielt om man sammenligner med strategiske bymodeller eller regionale modeller. Contram har et enkelt design av inn- og utfiler for en modell, og en lagringsløsning basert på eroom vil derfor være tilsvarende oversiktlig. 9.1 Datatyper Datatyper som bør lagres er vist i tabellen under, Tabell 4. Tabell 4 Datatyper som bør lagres for Contram, inn- og utdata Datatyper Innhold Filtyper Kommentar 1 Vegnettsfil Informasjon om nodelenkestrukturen (*.net) og egenskaper i transportnettet 2 Matriser fra etterspørselsmodellering Matrisefiler (*.dem) 3 Modellparametere 4 Data som er grunnlag for etablering av vegnett/transportsystem Fra-til-matriser fra etterspørselsmodellering eller registreringer Beskrivelse av vegnett/transportsystem, spesielt aktuelt dersom transportnett er basert på andre modellkilder 5 Resultatfiler Vegnettsfiler med resultater fra modellkjøring Div Tekstfiler 9.2 Datalagring For Contram trengs en enkel katalogstruktur som gjør det mulig for brukere å lagre offisielle versjoner av modeller og modellanalyser. I de tilfeller der Contram-modeller er benyttet som grunnlag for EFFEKT-beregninger, må resultatfiler til EFFEKT lagres. 9.3 Metadata Metadata for CONTRAM bør lagres i filer som benyttes i dataprogrammet. SINTEF er kjent med at det til dels benyttes filkommentarer til dokumentasjon av forutsetninger for beregninger. Dette er imidlertid en praksis som varierer noe, og forsøk på standardisering bør etterstrebes. Dokumentasjonsansvar og ansvar for produksjon av metadata må tillegges miljøer som utvikler modeller for Statens vegvesen, all den tid informasjonen vil være knyttet til grunnlagsdata og forutsetninger for anvendelse av implementerte modeller. Metadata bør inneholde informasjon om modellberegningen, som for eksempel: Hvilket område/prosjekt beregningen gjelder for Informasjon om hvilke etterspørselsmatriser fra hvilke modellversjoner som er benyttet. Viktig også med dokumentasjon om det er manipulert med matrisene, og hvilke forutsetninger som ligger til grunn for dette. Hvem som har utført beregningen Når beregningene er gjennomført

20 14 10 EFFEKT EFFEKT er Statens vegvesens etatsstandard verktøy for beregning og sammenstilling av kostnader og virkninger av tiltaksanalyser. Analyser med EFFEKT danner grunnlaget for videre arbeider knyttet til rangering og prioritering av prosjekter inn mot Statens vegvesens handlingsprogram i NTP. For beskrivelse av funksjonalitet og virkemåte for EFFEKT, se Statens vegvesens Håndbok 140 Konsekvensanalyser eller egen brukerveileder for EFFEKT Datatyper EFFEKT kan benyttes på flere ulike måter, avhengig av kompleksitet i prosjektene som skal analyseres. I sin enkleste form legges all informasjon direkte inn i EFFEKT av brukeren og fra NVDB, mens for mer komplekse analyser hentes store deler av grunnlaget fra eksterne transportmodeller, trafikantnytteberegninger og kollektivberegninger. Vi vil i hovedsak beskrive krav knyttet til de mest kompliserte beregningene, da kravene også dekker behovet til enklere beregninger. Det er behov for lagring av både inndata og databaser som brukes i EFFEKT. Det er viktig å ta vare på mer enn bare selve EFFEKT-databasen. Det er flere filer som trengs for å reetablere en EFFEKT-database komplett med alle inngangsdata. Dersom tidligere versjoner av EFFEKT-programmet skal være tilgjengelige ved etterprøving, må også installasjonsfiler lagres i lagringsløsningen og sikres mot sletting og endring. Dette bør gjøres ved at utviklermiljøets installasjonsfiler lagres før spesielle installasjonspakker til bruk i Statens vegvesen produseres. Datatyper som må lagres er vist i tabellen under, Tabell 5.

21 15 Tabell 5 Datatyper som bør lagres for EFFEKT Datatyper Innhold Filtyper Kommentar 1 Databasefil Alle EFFEKT-data som benyttes i beregning Microsoft Access (*.mdb) 2 Filer med trafikkdata Trafikkdata/Lenkevolumer som benyttes til innlesing fra transportmodeller Tekstfil (*.dat) En fil for hvert scenario og beregningsår 3 Filer med resultater fra trafikantnyttemodul 4 Filer med resultater fra kollektivmodul Nyttekomponenter, tidsog kjøretøykostnader Kostnader og inntekter i kollektivsystemet 5 Filer med kurvatur Filer som beskriver horisontal- og vertikalkurvatur for planlagte veger 6 Filer med vegidenter fra transportmodeller Filer som beskriver sammenhengen mellom transportmodellens nodelenkesystem og vegidenter 7 Lokalt lagrede NVDB-data Data som bestilles fra EFFEKT og lagres lokalt før innlesing til EFFEKTdatabasen Tekstfil (*.dat) Tekstfil (*.dat) Tekstfil (*.tit, *.nyl) Tekstfil (*.eff) Vegnettsdata (*.mdb) Ulykkesdata (Quadri-filer) En fil for hvert sammenligningsscenario og beregningsår En fil for hvert scenario og beregningsår En fil for hvert scenario Quadri-filer som lagres lokalt på disk overskrives hver gang det hentes ulykkesdata til EFFEKT fra NVDB. Det er usikkert om det er nødvendig å ta vare på data fra NVDB, all den tid NVDB lagrer historiske data. Dersom vegnettsdatoen er kjent for data som er lest inn til EFFEKT, bør det være mulig å rekonstruere disse dataene ved en ny innlesing fra NVDB for samme dato. Usikkerheten rundt håndtering av dette i EFFEKT og NVDB gjør at det anbefales at disse dataene lagres Datalagring EFFEKT-prosjekter som er ferdig beregnede og har gått videre til prioritering må lagres slik at det ikke er mulig å endre inndata, database eller resultater. Den offisielle datalagringsplassen til de opprinnelige beregningene blir dermed eroom. Dette medfører at det vil være mulig å gjenskape resultater fra de opprinnelige beregningene forutsatt at programversjonen som ble brukt til beregning også kan finnes. En kompliserende faktor for lagring av data knyttet til EFFEKT-beregninger, er at det ikke finnes noen organisatorisk struktur som har et permanent eierforhold til beregningene. Det er derfor vanskelig å kommunisere behovet for lagring på andre måter enn ved at Strategistab i hver enkelt region sørger for at dette datagrunnlaget blir lagret i henhold til eksisterende rutiner. Prinsippet må gjelde uavhengig av om det er Statens vegvesen selv eller konsulenter som gjennomfører analysene.

22 Metadata Det vil ikke være så stort behov for metadata knyttet til EFFEKT-beregninger, da mye av metadataene ligger i selve beregningsdatabasen. eroom kan ikke benytte denne informasjonen direkte, da det ikke finnes funksjonalitet for å bruke informasjon som ligger i databasefiler. Metadata om beregningene kan finnes ved å åpne databasen i Microsoft Access. Det bør undersøkes om plattformen som er valgt for MIME kan indeksere innhold i databasefiler, dersom dette er ønskelig. På det tidspunktet denne prosjektrapporten skrives, finnes det ikke detaljert informasjon om dette tilgjengelig for prosjektet Forhold som bør vurderes av systemeier knyttet til fagapplikasjonen Momentene under bør betraktes som forbedringsforslag basert på et mål om enklere og sikrere lagring av data fra fagapplikasjonen: EFFEKT lagrer kun data som benyttes til beregninger, og tar således ikke direkte vare på innleste data i den formen de ble innlest. Det bør kunne vurderes om EFFEKT også kan ta vare på originalfiler av innleste data som objekter i databasen, slik at alle data som er inngangsdata til EFFEKT lagres i samme database uten omregning eller bearbeiding. Dette gjelder spesielt innleste data fra transportmodeller. EFFEKT kan lagre mange prosjekter i en og samme database, dette er det opp til brukeren å bestemme. Dette medfører at det er vanskelig å få oversikt over hvilke prosjekter databasen inneholder eller å skaffe seg oversikt over forutsetninger uten å åpne databasefila i Microsoft Access eller i EFFEKT. Det bør vurderes om det kan produseres en metadatafil som beskriver sentrale forutsetninger og innholdet i databasen ved avslutning av EFFEKT-programmet. EFFEKT kan lagre mange prosjekter i en og samme database, og dette gjør dataadministrasjonen komplisert. Dersom man ønsker en prosjektbasert tilnærming til lagring av data, bør det enten vurderes å etablere funksjonalitet for å kopiere prosjekter mellom EFFEKT-databaser, eller kun å tillate ett prosjekt per databasefil. Ett prosjekt per databasefil kompliserer ajourhold av globale forutsetninger i EFFEKT, men sikrer både oversiktlighet i lagring og sprer risiko i forbindelse med databaseødeleggelser eller andre former for tap av data.

23 17 11 VSTØY/VLUFT VSTØY/VLUFT har mye av den samme strukturen og funksjonaliteten som EFFEKT, og lagrer også alle inndata og resultater i en Microsoft Access-database. VSTØY/VLUFT er mye nærmere knyttet til VDB/NVDB på inngangsdatasiden enn tilfellet er med EFFEKT. For VSTØY/VLUFT er det utviklet et kartbasert grensesnitt (ArcGIS) for etablering og ajourhold av inngangsdata og analyse og presentasjon av beregningsresultater. Disse kartdokumentene bør også lagres tilknyttet en VSTØY/VLUFT-database, dersom man skal kunne få oversikt over inngangsdata til dataprogrammet. VSTØY/VLUFT har også et grensesnitt mot EFFEKT og mot transportmodeller. Grensesnittet mot EFFEKT er en del i bruk, mens grensesnittet mot transportmodeller brukes svært sjelden Datatyper Datatyper som bør lagres er vist i tabellen under, Tabell 6. Tabell 6 Datatyper som bør lagres for VSTØY/VLUFT Datatyper Innhold Filtyper Kommentar 1 Databasefil Alle VSTØY/VLUFTdata som benyttes i beregning Microsoft Access (*.mdb) 2 Kartdokument Kartbasert informasjon som benyttes for etablering og ajourhold av inndata til VSTØY/VLUFT ESRI ArcMap MapDocument (*.mxd), samt geodatabaser og shapefiler 11.2 Datalagring Som for EFFEKT, er det ikke behov for et veldig komplisert lagringssystem for datafiler knyttet til VSTØY/VLUFT-beregninger. Det er i all hovedsak de ovennevnte datatypene som må lagres. Det er kjent at det eksisterer store modeller for VSTØY/VLUFT, ofte modeller som dekker fylkesområder. Disse ajourholdes med jevne mellomrom, og det er behov for et system som kan holde tak i versjonsinformasjon om disse databasene med tilhørende GIS-data Metadata Som for EFFEKT, ligger også her en del metadata i databasen som ikke eksponeres utad uten å åpne databasen i VSTØY/VLUFT eller i Microsoft Access direkte. Det bør undersøkes om plattformen som er valgt for MIME kan indeksere innhold i databasefiler, dersom dette er ønskelig Forhold som bør vurderes av systemeier knyttet til fagapplikasjonen Momentene under bør betraktes som forbedringsforslag basert på et mål om enklere og sikrere lagring av data fra dataprogrammet: En tettere binding mellom databasefilen som benyttes til VSTØY/VLUFT-beregninger og kartdokumentet som genererer grunnlagsdata. Dette kan løses gjennom å legge filsti/filreferanse til kartdatadokumentet i ArcGIS inn i VSTØY/VLUFT. Dette vil dokumentere adressen til grunnlagsdata.

24 18 Det bør vurderes om det kan produseres en metadatafil som beskriver sentrale forutsetninger og innholdet i databasen ved avslutning av VSTØY/VLUFT-programmet. 12 NorStøy NorStøy er et dataprogram for beregning av støy fra vegtrafikk som benyttes til kartleggingsformål i Statens vegvesen, basert på beregningsmetoden Nord2000. NordStøy har langt på vei et eget opplegg for lagring og administrasjon av data ved gjennomføring av analyser. NorStøy er sterkt knyttet til sentrale datakilder, og lite av analysearbeidet er tenkt utført manuelt i dataprogrammet. NorStøy henter data fra NVDB via TNE 2, fra lagrede diskområder med geografiske kartdata, og fra GAB. Supplerende informasjon og dokumentasjon kan finnes i "NorStøy brukerveiledning" (Statens vegvesen Vegdirektoratet). Versjon 0.3 av dette dokumentet har vært grunnlaget for arbeidet med NorStøy i dette prosjektet. Per i dag er NorStøy i bruk kun for kartleggingsformål, og datagrunnlaget som trengs for kjøring av slike modeller er geografisk sett omfattende. Dette fører til lagring av store datamengder og lange beregningstider. Behovet for lagring av data vil trolig endre seg noe når NorStøy videreutvikles til å brukes til tiltaksvurderinger, dvs. analyser av støymessige konsekvenser som følge av endringer i transportsystemer eller skjermingstiltak. Det forventes også at behovet for forvaltning og lagring vil øke når flere personer tar verktøyet i bruk Datatyper NorStøy lagrer den informasjonen som trengs til beregning av et prosjekt i en såkalt Oppdragskatalog. Denne inneholder flere typer filer, for eksempel kartdatafiler, databaser, rapportmaler og xml-filer. Etter avklaringer med brukermiljøet, må hele denne tas vare på for å kunne kjøre beregningen på nytt med like forutsetninger Datalagring Det forutsettes at NorStøy-prosjektet har etablert lagringsområder for kartleggingsprosessen EUkartlegging, som er gjennomført og avsluttet. Datalagring for disse analysene vil derfor være mindre aktuelle å lagre på eroom. For framtiden vil analyser med NorStøy gjennomføres som del av et transportanalyseprosjekt, og forutsetninger og resultater vil derfor praktisk sett bli lagret sammen med øvrige data fra analyseprosjektet Det må også påregnes at NorStøy for framtiden får datautveksling med andre analyseverktøy, for eksempel EFFEKT, og at det etableres andre overføringsfiler som må lagres for framtiden Metadata Metadata om beregningsoppdragene i NorStøy lagres i personlige geodatabaser i Oppdragskatalogen. Disse vil bli lagret sammen med resten av grunnlagsdata- og resultatfilene, men vil kun være tilgjengelig gjennom å åpne geodatabasene i ArcGIS eller i Microsoft Access. Denne informasjonen kan skrives til en tekstfil, for eksempel basert på data i tabellen SVV_Project i den personlige geodatabasen i Oppdragskatalogen. 2 Transport Network Engine

25 Forhold som bør vurderes av systemeier knyttet til fagapplikasjonen Momentene under bør betraktes som forbedringsforslag basert på et mål om enklere og sikrere lagring av data fra dataprogrammet: Det bør sees ytterligere på om det er behov for å lagre hele Oppdragskatalogen etter beregninger i NorStøy. Data fra offisielle kilder som NVDB og GAB bør kunne hentes fra kildene, dersom man tar vare på referanser til uttaksdato/vegnettsdato og kriterier for segmentering av vegnettet. Geografiske data bør også kunne hentes fra kilden på nytt, basert på at det finnes referanser til grunnlagsdatafilene, og at det finnes et system for lagring av versjoner av disse. Det bør sees nærmere på hvordan den faktiske dataflyten blir ved gjennomføring av tiltaksanalyser, da dette vil stille krav til at andre data lagres i grensesnittet mellom NorStøy og øvrige analyseverktøy. 13 PDB Excel Prosjektdatabanken er lagret på felles nettverksdrev i Statens vegvesen i dag. PDB er lagt om en del fra tidligere versjoner, og er i dag et dataprogram som tar imot og sammenstiller data fra EFFEKT. Det lages ingen nye data i PDB Excel. Behovet for felles lagring i eroom vurderes derfor å være så marginalt at det ikke inkluderes i denne prosjektrapporten. 14 TAV TAV (TilstandsAnalyse av Vegnett) er ennå ikke flyttet over fra VDB til NVDB-plattform, men utviklingsprosessen skal være igangsatt. TAV var i forrige versjon basert på ArcGIS, og benyttet geodatabaser med vegfagdata fra VDB til å beregne standard på vegnettet. Informasjon om lagringsbehovet for det reviderte dataprogrammet har ikke vært tilgjengelig for SINTEF i prosjektperioden, og behovene er derfor ikke vurdert videre.

26 20 15 Lagringsløsning Forslaget til datalagringsstruktur er implementert på Oppdragsgivers eroom-løsning, driftet for Statens vegvesen av Joint Collaboration AS. Pilottesten er en del av dette prosjektet, men den implementerte løsningen skal kun være en demonstrator for hva som anbefales å gjøre i eroom, og ikke et komplett lagringssystem Om EMC Documentum eroom eroom er en samhandlingsløsning som er meget godt egnet til prosjektarbeid, der man inkluderer interne og eksterne medarbeidere i en felles forvaltnings- og lagringsløsning. Selve løsningen er etablert på en webserver der kommunikasjon mellom klient og server er kryptert. Dette fører til at løsningen har god sikkerhet, og kan benyttes av alle medlemmene i et prosjekt uavhengig av tilgang til Statens vegvesens IT-systemer. Det eneste som kreves er tilgang til internett og brukernavn og passord til løsningen. I sin enkleste form kan eroom fungere som et felles sted for lagring, der prosjektledere og koordinatorer kan styre strukturering, tilgang og versjonering av informasjon. eroom benyttes av flere store og små prosjekter i Statens vegvesen i dag, og er et de facto standardverktøy for samhandlingsprosjekter i etaten. Det er et mål for Statens vegvesen å erstatte funksjonaliteten i eroom med egne løsninger for samarbeid og deling av informasjon gjennom MIME-prosjektet Konsept eroom-løsningen bygges opp som et datalager med kataloger basert på porteføljen av fagapplikasjoner som skal støttes. Det er viktig at den ferdig implementerte eroom-løsningen blir et eget eroom, slik at det er enkelt å identifisere hvor data finnes. Som beskrevet i kapittel 4, ser vi for oss to prinsipielle nivåer som lagringsløsningen bør struktureres i. Det finnes et uttrykt behov for lagring av modell- og programversjoner for etterprøving, dette vil i så fall håndteres i lagringsområdene for hver enkelt fagapplikasjon. Det bør stilles krav om dette fra Statens vegvesen til miljøene som utvikler hver fagapplikasjon. Dette kan for eksempel gjøres gjennom krav i utviklingskontraktene. Utviklingsmiljøene lager som en regel fulle installasjonsprosedyrer for hver programversjon, og det er disse som må lagres, ikke de pakkene som lages for utrulling av programvare i Statens vegvesen. Lagringskonseptet tar ikke høyde for at det kan finnes grenser for datalagringskapasitet. De tekniske og økonomiske begrensningene må vurderes av Oppdragsgiver i forhold til de avtaler som eksisterer med driftsleverandør for eroom-tjenesten. Diskkapasitet bør ikke være begrensende for hva som lagres all den tid data som lagres er viktige data for Statens vegvesen. I figurene under er det foreslått en lagringsstruktur som understøtter de oppgavene og behovene som er beskrevet i rapporten. Hierarkiet er et forslag, og et grunnlag å gå videre med i ferdigstilling av lagringsløsningen.

27 21 På toppnivået foreslås det en firedeling, mellom de tre sentrale gruppene av fagapplikasjoner og analysenivået, som begrunnet i rapporten. Under Transportmodeller foreslås inndeling i de ulike modelltypene som det skal tilbys lagring for Legg inn en katalog for offisielle versjoner av modelleringsverktøyet. Under RTM Persontransportmodell skilles det mellom modellsystemet som sådan, og offisielle kjøringer for basisår og prognoseår for hver region. Det er et viktig skille mellom modellstruktur og programmoduler og de felles forutsetningene som ligger i de predefinerte datasettene for de ulike årene. Ikke minst knyttet til hvem som skal ha muligheter til å endre innholdet i katalogene. Under Miljøberegninger er det en enkel toppstruktur som skiller de ulike fagapplikasjonene fra hverandre. Under Programsystem foreslås lagring av versjoner av dataprogrammene for etterprøvingsformål. Under kartleggingskatalogene kan man tenke seg offisielle datasett som benyttes til rapportering i forhold til målstyringssystem eller spesielle lovpålagte kartleggingsrunder.

28 22 Under Nyttekostnadsanalyser skilles det mellom Programsystem, som kan holde på tidligere og nåværende versjoner av programmet for etterprøvingsformål. Det har vært diskutert å etablere felle databaser for 0-situasjonen, de kan i så fall plasseres under Regionale databaser. Det siste nivået foreslås å være et eget nivå for Prosjektanalyser. Dette området inndeles i tre hoveddeler; analyser under arbeid, ferdige analyser og prioriterte analyser. Det første nivået vil fungere som en samhandlingsarena, det andre som et grunnlag for prioritering dvs. analyser som er ferdigstilte, mens det siste vil ta vare på data fra de prosjektene som er prioriterte, og som kan bli gjenstand for etteranalyser. Det er gunstig å skille disse tre områdene i forskjellige kataloger, siden det vil være forskjellige brukerroller som får muligheter til å legge til data her. Vi mener at strukturen slik den er lagt opp er såpass fleksibel og modulær at det ikke er store problemer med tilpasning som følge av noe endrede behov. En pilot på strukturen er implementert på Statens vegvesens eroom-løsning, men uten brukerroller.

29 Brukerroller Innenfor et eroom bør man strukturere medlemmene i roller, slik at det er greit å foreta en oversiktlig tilgangsstyring. En bør strukturere medlemmene ut fra hvilken tilgang til informasjon de skal ha. Rollestyring vil også kunne segmentere brukermassen i forhold til endringsstyring relatert til det regionale nivået eller knyttet til fagapplikasjonene. Pilotprosjektet tar ikke endelig stilling til hvilke tilgangsgrupper som skal etableres, men gir et forslag ut fra hvordan det er logisk å strukturere tilgangen. Under er det angitt to eksempler på hvordan man kan strukturere tilgang. Case 1: Regionale modeller for persontransport Rolle Beskrivelse Nasjonal RTM koordinator Koordinerer tilgang til modellsystem/dataprogram/programmoduler, nasjonale datakilder, godkjenner og tilgjengeliggjør nye modellversjoner, administrerer hvilke brukere som hører til hvilke roller, styrer katalogstruktur. Rollen kan innehas av flere brukere, men ansvaret bør deles på få personer. Nasjonal etatskoordinator Koordinerer tilgang til etatsspesifikke verktøy og tilpasninger. Nasjonal utviklingspartner Ansvar for brukerstøtte, tilrettelegging og ajourhold av modellene/programmodulene, inkludert opplasting av disse. Regional koordinator Ansvar for tilrettelegging og ajourhold av data og programmoduler som er regionale. Ansvar for tilrettelegging av regional katalogstruktur. Ansvarlig for tilgjengeliggjøring av kvalitetskontrollerte datasett. Regional bruker Bruker av transportmodellene. Ansvar for innmelding og oppdatering av grunnlagsdata og opplasting av ferdig beregnede datasett for godkjenning. Regional konsulent Bruker av transportmodellene. Ansvar for opplasting av ferdig beregnede datasett i predefinert katalogstruktur. Case 2: EFFEKT Rolle Nasjonal EFFEKT koordinator Nasjonal konsulent Regional koordinator Regional bruker Regional konsulent Beskrivelse Administrerer hvilke brukere som hører til hvilke roller, styrer katalogstruktur. Rollen kan innehas av flere brukere, men ansvaret bør deles på få personer. Ansvar for brukerstøtte. Ansvar for tilrettelegging av regional katalogstruktur. Ansvarlig for tilgjengeliggjøring av godkjente datasett. Bruker av EFFEKT. Ansvar for opplasting av ferdig beregnede modeller for godkjenning. Bruker av EFFEKT. Ansvar for opplasting av ferdig beregnede datasett i predefinert katalogstruktur.

30 Arbeidsflyt og godkjenningsprosedyrer Det er mulig via eroom å lage godkjenningsprosedyrer for ulike filtyper som skal lastes opp. Dette er sannsynligvis mest aktuelt for transportmodellene, der det finnes mange personer som jobber med de samme datasettene, og der det kreves et visst regime for å holde kontroll på offisielle versjoner av inngangsdata. Etter å ha testet hva som er mulig å få til med standardfunksjoner i eroom, vil vi anbefale å ikke implementere dette i lagringsløsningen. Det synes ikke å være noen grunn til å gjøre godkjenningen av filene unødvendig komplisert, og heller styre hvilke filer som er godkjent ved at koordinatorene flytter filer og holder versjonsinformasjonen ved like Metadata i eroom Med metadata menes data som beskriver data, og vi må skille mellom metadata som genereres av eroom og metadata som kommer fra analyseverktøyene. Metadata fra eroom er data om filene som legges inn i eroom, og beskriver i liten grad innholdet i filene. Eksempler på metadata fra eroom: Eier, hvem som har lagt inn fila Filtype Filstørrelse Dato Versjon og versjonsinformasjon Dette er metadata som er interessante, men ikke egentlig viktige rent faglig sett. Faglige metadata, dvs. metadata som beskriver innhold av fagdata må legges inn som egne metadatafiler. Dette kan være tekst- eller xml-filer som kan åpnes direkte fra eroom, og som følger datafilene ved kopiering eller nedlasting. Faglige metadata må produseres av fagapplikasjonene, som beskrevet i kapitlene foran som beskriver løsninger for hver enkelt fagapplikasjon.

31 25 16 Forholdet til MIME MIME er et prosjekt som er iverksatt i Statens vegvesen på bakgrunn av en vedtatt strategi for helhetlig informasjonsforvaltning i etaten. SINTEF har fått innsyn i forprosjektrapporten om Saks- og dokumentforvaltning (Statens vegvesen Vegdirektoratet, dato ). Relasjonen mellom MIME og dette prosjektet, er at begge forsøker å systematisere modeller og data relatert til overordnet transportplanlegging. MIME-prosjektet går betydelig lengre, da det skal dekke alle behov for saks- og dokumentforvaltning i Statens vegvesen. MIME skal også dekke behovene for samhandling mellom Statens vegvesen og samarbeidende etater og konsulenter. I dette prosjektet har vi utfordringer med å forholde oss til MIME, da den informasjonen vi har fått tilgang på om MIME ligger på et nivå som ikke tilsvarer det vi må befinne oss på dersom vi skal foreslå et konkret system som vil hjelpe transportetatene til å holde orden på alle data som er relatert til overordnet transportplanlegging. Arbeider som iverksettes for å forvalte data før MIME er i drift, vil kunne videreføres inn i MIME-løsningen. Dette forutsetter at fagmiljøene som skal benytte MIME sørger for innspill til lagringsløsningen. Spesielt vil dette gjelde relasjonen mellom datafiler og metadata, og at man sørger for at denne koblingen gjør det mulig å lese metadata inn til MIME sammen med datafiler i en initiell fylling av MIME-databasen. SINTEF ønsker derfor å presisere at forslag til implementering fra vår side primært er basert på vår kjennskap til behovene slik de er ytret gjennom workshop og samtaler med Oppdragsgiver og de begrensningene vi kjenner gjennom flere års bruk av eroom, og ikke overordnede funksjonelle beskrivelser fra MIME-prosjektet.

32 26 17 Konklusjoner og anbefalinger Prosjektet har vist at det er mange ønsker og behov knyttet til forvaltning av fagapplikasjoner, modeller og datasett relatert til den overordnede planleggingsprosessen. SINTEF mener at prosjektet har lyttet til de ønsker som har blitt reist underveis i prosjektet, og forsøkt å foreslå et så komplett system som mulig. Prosjektet er startet med en visshet om at det foreslåtte systemet ikke kommer til å bli en permanent løsning, behovene kommer til å bli avløst av en sentral løsning for helhetlig informasjonsforvaltning i Statens vegvesen. Samtidig er det en erkjennelse at det hele tiden går viktige data tapt fordi man i dag ikke har rutiner for å ta vare på data, og heller ingen lagringsløsning som kan lagre data på en enkel og oversiktlig måte. Det er derfor viktig å få etablert en løsning så snart som mulig som kan holde på fagapplikasjoner og data inntil en permanent løsning er på plass. Vi håper også at systemeierne for de ulike fagapplikasjonene er villige til å se på de behovene og anbefalingene som er gjengitt basert på et ønske om å lette måten data fra fagapplikasjonene kan lagres i forvaltningssystemet. Vi tror ikke selv det beste forvaltningssystemet kan fungere uten at de som arbeider med dataprogrammene og analysene begynner å arbeide på en måte som understøtter lagringsløsningen. Dette er en utfordring som bør løses gjennom opplærings- og bevisstgjøringstiltak overfor de som har eierskap til de analysene som gjennomføres.