Transcript Nätredigeringsutredning

RAPPORT
Nätredigeringsutredning
Borlänge, Dalarnas län
2013-01-24
Projektnummer: [Projektnummer]
Innehåll
Projektmål .......................................................................................................... 4
Metod ................................................................................................................. 4
Work shop .......................................................................................................... 5
De intervjuade .................................................................................................... 6
Påpekande .......................................................................................................... 7
Tack till alla medverkande! ................................................................................ 7
Sammanfattning externa ledtider, beskrivning och lösningsförslag .................8
1. Upplevd begränsad nytta med NVDB .........................................................8
2. Svår teknik stoppar upp och försvårar .......................................................8
3. Begränsat incitament för vägentreprenörer att rapportera in vägdata ......8
4. Dataleverantörers avdelningar osynkroniserade ....................................... 9
Sammanfattning interna ledtider, beskrivning och lösningsförslag ............... 10
1. Stort antal inrapporteringsvägar och format ............................................ 10
2. Varierande underlagskvalitet ................................................................... 10
3. Indatavolymer fluktuerar kraftigt ............................................................ 10
4. Komplex produktionskedja med flera huvudmän .....................................11
Sammanfattning kvalitetsproblem, beskrivning och lösningsförslag ............. 12
1. Vad är master och vad är slav – Analysera en alternativ IT-arkitektur.... 12
2. Svårt hantverk .......................................................................................... 12
3. Begränsat systemstöd i egna applikationerna .......................................... 12
4.( Skillnader på fokus och tidsperspektiv med vägredigeringsarbetet) ...... 12
5. (Synen på företeelser skiljer sig år) .......................................................... 12
Förslag på de fem viktigaste åtgärderna .......................................................... 13
1. Vad är master och vad är slav – Analysera en alternativ IT-arkitektur.... 13
2. Öka incitamenten för att aktivt jobba med NVDB – Ny betalningsmodell
...................................................................................................................... 13
3. Begränsa och styr upp överföringsmöjligheterna .................................... 13
4. Aktiv stöttning av sällananvändare (”Fullservicetjänst”)......................... 14
5. Motverka den förändringskänsliga miljön ............................................... 14
Beskrivning problem externa ledtider samt lösningsförslag ........................... 16
1. Upplevd begränsad nytta med NVDB ....................................................... 16
2. Svår teknik stoppar upp och försvårar ......................................................... 19
3. Begränsat incitament för vägentreprenörer att rapportera in vägdata .... 23
4. Dataleverantörers avdelningar osynkroniserade ..................................... 25
5. Fler orsaker till långa externa ledtider enl de intervjuade ....................... 26
Beskrivning problem interna ledtider samt lösningsförslag ...........................28
1. Stort antal inrapporteringsvägar och format ............................................28
2. Varierande underlagskvalitet .................................................................. 30
3. Indatavolymer fluktuerar kraftigt ............................................................ 31
4. Komplex produktionskedja med flera huvudmän .................................... 32
5. Fler orsaker till långa interna ledtider enl de intervjuade........................ 33
Beskrivning kvalitetsproblem samt lösningsförslag ........................................ 34
1. Vad är master och vad är slav – Förslag på en alternativ IT-arkitektur ... 34
2 Svårt hantverk ........................................................................................... 36
3. Begränsat systemstöd i egna applikationerna ..........................................38
4. (Skillnader på fokus och tidsperspektiv med vägredigeringsarbetet) ...... 39
5. (Företeelser skiljer sig åt) ......................................................................... 39
6. Fler orsaker till kvalitetsproblem enl de intervjuade .............................. 40
Frågor och svar – Systemleverantörer ............................................................. 63
Frågor och svar – Dataleverantörer (kommuner/skogsnäring) ...................... 75
Bakgrund
Alla Sveriges kommuner har avtal att leverera information om vägnätet till
NVDB. Leverans sker antingen via ett IT-system hos kommunen eller genom att
skicka ett underlag t ex i form av en shape-fil. Det är viktigt att leveranserna till
NVDB håller hög kvalitet, dels för att informationen ska bli korrekt i databasen,
dels för att korta ned ledtiderna vid hanteringen.
Idag finns problem med bristande kvalitet i leveranserna av vägnätsdata vilket
ofta leder till långa ledtider, samt att leveranserna till NVDB ofta sker för långt
efter det att den verkliga vägen byggts eller förändrats.
Trafikverket har därför tagit initiativ till detta projekt med syftet att kartlägga
problem i anslutning till arbete med uppdateringar av information i NVDB. Det
gäller dels de ibland långa ledtiderna, dels de ibland förekommande
kvalitetsproblemen. Projektet är ett försök att tillsammans med de viktigaste
aktörerna kring NVDB (se punktlista nedan) via en nulägesanalys baserad på
telefonintervjuer komma fram till åtgärdsförslag. Trafikverket betonar att detta
är ett samarbetsförsök!
Projektet har fokuserat på organisation, handhavande och ansvarsfördelning.
Det har inte i första hand varit ett teknikprojekt!
Projektmål
Målet med projektet har varit att skapa en rapport innehållande den
problembild kring ledtider och kvalitetsproblem som framkommit i dialog med
representanter för




kommuner,
skogsnäring,
externa systemleverantörer,
anställda och konsulter på Trafikverket.
Rapporten innehåller också förslag på lösningar på de beskrivna problemen.
Metod
Projektet har genomförts via intervjuer av representanter för de fyra olika
intressentgrupperna, totalt 28 st. Intervjuerna har normalt genomförts som
telefonmöten och tagit mellan 50 och 90 minuter. Några få intervjuer har gjorts
”live”. Baserat på samtliga intervjusvar har jag försökt dra generella slutsatser. I
samband med intervjuerna kom också många övriga åsikter in av varierande
dignitet och även dessa har jag dokumenterat för att kunna utnyttjas av
Trafikverket för förbättringar. Dessa återfinns i kapitlet Intervjuer i Appendix i
slutet av rapporten.
Intervjuformulär med öppna frågor har använts vid samtliga intervjuer.
Formulären har varit snarlika, men då det finns frågeställningar som är unika
för en enskild intressentgrupp, alt. helt irrelevant för någon intressentgrupp, har
anpassningar skett, se kapitlen med intervjusvar. Jag gjorde innan intervjuerna
klart för alla intervjuade bakgrunden till hur genomförandet skulle göras och
hur slutrapporten kommer att hanteras (anonymitet för individer utlovades
osv).
Trafikverket valde vilka som skulle intervjuas och nästan alla kunde ställa upp.
Vid intervjuer av representanter för Trafikverket har jag ensam genomfört dessa
och dokumenterat. Vid merparten av övriga intervjuer har en representant från
Trafikverket suttit med för att vid behov bistå.
Vid samtliga intervjuer tog jag minnesanteckningar. Dessa renskrevs och
skickades till de intervjuade för påseende och möjlighet till uppdatering och
korrigering. Där bisittare fanns har också de fått läsa mina minnesanteckningar
och kunnat uppdatera dessa varpå minnesanteckningarna efter finputsning gick
vidare till den intervjuade för remisshantering, därpå åter till mig.
Work shop
130117 genomfördes en work shop där ett antal CGI-konsulter samt
beslutsfattare inom Trafikverket kring NVDB deltog. Syftet var att diskutera ett
antal extra intressanta frågeställningar.
Vi inledde med att diskutera hur man kan höja dataleverantörernas incitament
och motivation för att jobba med NVDB, dvs att motverka dagens i många fall
vanliga uppfattning att det kostar mer än det smakar. Detta är absolut en av
nyckelfrågorna som Trafikverket bör fundera kring. Det finns indikationer på att
Lantmäteriets modell med ersättning för inrapporterade uppdateringar och
avgift för uttag fungerar bättre för mindre resursstarka dataleverantörer som
ofta endast har ett begränsat behov av NVDB-utdata i sina dagliga uppgifter.
Trafikverket påpekade att situationen ser olika ut för olika dataleverantörer då
några skulle ekonomiskt tjäna på Lantmäteriets modell och andra förlora
beroende på hur mycket man rapporterar in resp. hämtar ut.
I samband med denna diskussion kom också upp tankar kring ett utökat
samarbete med Lantmäteriet på andra områden. Kan Trafikverket via
granskning av Lantmäteriets foton få in uppdateringar som annars riskerar att
inte alls rapporteras, alt. rapporteras väldigt sent? Idag måste dataleverantörer
också leverera vägnätsuppdateringar till flera olika mottagare. Finns det
möjligheter att samordna här och minska ned på inrapporteringsvolymerna och
utnyttja samma information i olika sammanhang? Kan Lantmäteriet ta över
ansvaret för inrapporteringen, åtminstone valda delar, och Trafikverket får ta
del av deras insamlade material? Jämför med dagens hantering av LTF:er som
rapporteras till Transportstyrelsen och som sedan därifrån exporteras till NVDB.
Nästa diskussionspunkt var frågan kring master – slav. Vem äger ”originalet”
resp. ”kopior” i informationsmodellen med lokala system i en relation till det
centrala NVDB? I praktiken styrs åsikterna om detta av var man befinner sig,
vad man ansvarar för. Dataleverantörerna har förstås sitt fokus på sina egna
system. På samma sätt ser Trafikverket NVDB som det nav kring vilket deras
arbete och ansvar cirkulerar kring. Trots olika utgångslägen för de olika
parterna så måste vi hitta en modell som fungerar över tiden. Olika typer av
autonoma system med meddelandehantering diskuterades. I en ideal värld så är
alla system helt oberoende av vararandra. Nätverket/”samverkan” hålls istället
samman av en hårt definierad meddelandehantering. Var och en ansvarar
enbart för sitt eget system och helheten upprätthålls via meddelandena och
deras regelverk. Dagens tekniska lösning med vägnätsinformation som inte är
lagrad i skikt utan i samma nät med gemensam topologi underlättar dock inte
införandet av ovan nämnda modell.
Vi diskuterade Trafikverkets problem att hantera de fluktuerande
indatavolymerna. När en batch anländer med under en längre tid insamlade
redigeringar från en dataleverantör så kan det bli stockning i produktionsleden
vid NVDB med interna ledtider som följd. Att uppdateringarna har legat på hög
ute hos dataleverantören har dessutom orsakat externa ledtider, åtminstone för
de äldre uppdateringarna. Det påtalades dock att det i vissa lägen faktiskt är
rationellt att jobba ”batchvis” då det medför ett praktiskt flöde av
arbetsuppgifter. Detta måste också vägas in i en ev. åtgärdslistan.
Problematiken kring s k optimistisk ansats berördes. Trafikverket menar att det
idag egentligen inte är något större problem. Visst förekommer krockar då och
då, men inte speciellt ofta. Det finns också ett ärendesystem där ändringar ska
reserveras i förväg, men alla parter läser inte systemet.
De intervjuade
Totalt har intervjuats:


12 medarbetare på Trafikverket
Representanter för följande kommuner och Stockholms läns geodataråd:
- Huddinge
- Växjö
- Hässleholm
- Göteborg
- Söderhamn
- Kalmar
- Piteå
- Bollnäs
- Stockholms läns geodataråd
 Representanter för följande systemleverantörer:
- Astando
- ESRI
- Tekis
- Triona
 Representanter för skogsnäringen:
- VMF Qbera
- VMF Nord
- VMF Syd
Intervjuerna genomfördes under oktober – december 2012.
Påpekande
Alla generella slutsatser, förutom de som kom upp på work shopen 130117, har
dragits av undertecknad, PN, och är baserade på ett trots allt begränsat
intervjumaterial under en begränsad tid. Det finns alltså ett stort mått av
personliga synpunkter och tolkningar här. Det är ingen precis och exakt teknisk
utredning utan ett försök att med breda penseldrag peka på nuläge samt föreslå
olika alternativ för hur de inblandade aktörerna tillsammans kan gå vidare för
att förbättra kedjan av aktiviteter som måste hänga ihop.
Det kan också vara värt att påpeka att jag som skrivit denna rapport tidigare inte
har någon erfarenhet av NVDB, men samtidigt har jag ingen ”ryggsäck” från
denna världen. Detta har medfört att jag har hållit mig på en lite högre nivå.
Syftet med utredningen har varit att tänka fritt, att anlägga ett
helikopterperspektiv på frågeställningar och processer.
Min förhoppning är att allt övrigt material som har framkommit vid de 28
intervjuerna i form av råd, förslag, kritik mm kommer till nytta i det fortsatta
förbättringsarbetet. Jag tror att vi med dessa intervjuer har satt lite idéer och
tankar i rörelse och att det finns goda möjligheter att i en närtid fortsätta ett
förbättringsarbete.
Trafikverket har fått samtliga renskrivna intervjuunderlag som förstås är mer
detaljerade än denna rapport som är en sammansmältning av många åsikter
samt mina personliga tankar.
Tack till alla medverkande!
Jag vill passa på och tacka alla medverkande i intervjuer, rapportskrivning,
seminarium osv! Trots att alla har mycket att göra så har ni bokat tid, svarat på
mina frågor och hjälpt till när jag har fastnat. Stort tack!
Peter Nordqvist, CGI
Sammanfattning
Nedan hittar ni sammanfattningar av kapitlen som följer längre bak i rapporten.
Inom ramen för denna undersökning har vi koncentrerat oss på problem med
ledtider samt kvalitetsproblem vid leveranser av vägnätsdata till NVDB. Jag vill
dock påpeka att problemen med ledtider och kvalitet ofta hänger ihop. Åtgärdar
man några av ledtidsproblemen så kommer några kvalitetsproblem att också
minska, och vice versa.
Ledtider som visar sig ute bland dataleverantörerna innan underlag har skickats
till Trafikverket kallas här för Externa ledtider. Interna ledtider visar sig i
Trafikverkets interna produktionskedja (indata, beredning, registrering,
verkställande). Mitt emellan extern- och intern ledtid i flödet av uppdateringar
så finns ”överföringssteget” (som är en stor källa till problem).
Sammanfattning externa ledtider, beskrivning och lösningsförslag
De externa ledtiderna orsakar generellt väl så långa ledtider som de interna, i
många fall betydligt längre. Ur Trafikverkets perspektiv är detta extra
bekymmersamt då man inte har samma möjligheter att påverka dessa som de
”egna”, interna. Huvudanledningar, och förslag till lösningar, till externa
ledtider beskrivs nedan, men betydligt fler finns:
1. Upplevd begränsad nytta med NVDB
A. Öka incitamenten, motivationen för dataleverantörer att aktivt jobba
med NVDB
B. Överväg en annan betalningsmodell
2. Svår teknik stoppar upp och försvårar
A. Aktiv stöttning av sällananvändare (”Fullservicetjänst”)
B. Analysera om en speglad separat utvecklingsmiljö kan ”kompensera”
optimistisk ansats
C. Dialog med systemleverantörerna kring vägnätsredigerare som inte
levererar företeelser
D. Motverka den förändringskänsliga miljön
E. (Lokala vägnätsredigeringssystem optimerade för andra uppgifter)
3. Begränsat incitament för vägentreprenörer att rapportera in vägdata
Dataleverantörer:
A. Arbeta in rapporteringsklausuler i avtalen med vägentreprenörerna
B. Uppdatera vägbyggnadsprocesserna med återkommande möten och
inrapportering
C. Informera och dela ut blankett/länk inrapporteringsformulär till
vägentreprenörer
Trafikverket:
A. Ta fram tydlig policy kring registrering av projekteringsinformation
kontra avvakta
B. Ta fram färdiga blanketter, alt. länk till webformulär, att ge till
vägentreprenörerna
4. Dataleverantörers avdelningar osynkroniserade
A. Dataleverantörerna går igenom organisation och tar fram nya rutiner.
Stäm av regelbundet.
B. Definiera en enskild funktion som tar totalansvaret för dataleverantörens
NVDB-leveranser
Sammanfattning interna ledtider, beskrivning och lösningsförslag
Följande källor till ledtider internt har uppmärksammats (men fler finns):
1. Stort antal inrapporteringsvägar och format
Begränsa antalet möjliga inrapporteringsvägar till fyra alternativ:
A. Helautomatisk webtjänst import/export av NVDB-uppdateringar, sk hel
leverans
B. Halvautomatisk webtjänst import/export av NVDB-uppdateringar, sk
delvis leverans
C. Komplett inmatning via NVDB på web 2012
D. Fullservicetjänst
2. Varierande underlagskvalitet
Dataleverantörer:
A. Sällananvändare undersöker möjlighet till samarbete med andra
kommuner/organisationer
B. Hyr in en konsult, själv eller via en sammanslutning som ovan.
C. Gå igenom Trafikverkets dokumentation och e-learningkurser på
NVDB.se!
Trafikverket:
A. Utveckla NVDB-dokumentationen, NVDB-utbildningarna och NVDB.se
website.
B. Styr upp de olika tillåtna inrapporteringsvägarna.
Systemleverantörer:
A. Fortsätt utveckla systemens användargränssnitt. Valideringar,
rullgardinsval, rimlighetstester
B. Lägg till syntaxkontroll typ Portvakten.
3. Indatavolymer fluktuerar kraftigt
Dataleverantörer:
A. Försök att jobba ”bort” NVDB-uppdateringar så fort de uppkommer
B. Förvarna Trafikverket i god tid när en större batch är på ingående så att
Trafikverket hinner allokera resurser
C. Sällanarbete med få repetitioner försvårar inlärningen av NVDBrelaterade arbetsuppgifter
Trafikverket:
A. Öka incitamenten för kontinuerlig inmatning av förändringar. Jobba
med avtal.
B. Ny pris-/ersättningmodell med stigande kostnad/avtagande ersättning
vid eftersläpning
C. Skapa en rutin för förvarning från dataleverantörer när de vet att en
större batch kommer
4. Komplex produktionskedja med flera huvudmän
A. Kan något steg tas bort/slås ihop om kvaliteten förbättras el
inlämningsalternativ begränsas?
B. Samla så många enheter som möjligt i samma organisation under
samma ledning
Sammanfattning kvalitetsproblem, beskrivning och lösningsförslag
Problemen med kvalitet och ledtider hänger ihop såtillvida att lägre kvalitet på
indata genererar uppföljningsjobb i steget beredning inne i Produktion hos
Trafikverket NVDB. Med kvalitet avses här i rapporten i första hand hur väl
uppdateringar och underlag är ifyllda, dvs hur mycket/lite extrajobb som
genereras hos Trafikverkets produktionskedja för att få in korrekt data i NVDB.
1. Vad är master och vad är slav – Analysera en alternativ IT-arkitektur
Analysera ny informationsmodell, t ex autonoma delsystem och definierad
meddelandehantering.
2. Svårt hantverk
Trafikverket utvecklar NVDB-dokumentationen, NVDB-utbildningarna och
NVDB.se website.
3. Begränsat systemstöd i egna applikationerna
Utveckla systemstöden så att de innehåller information och stöttning i
inmatningsformulär, valideringar på fältnivå, möjliga alternativ i rullgardinsval,
rimlighetskontroller, kontroller att värde är inmatat osv.
4.( Skillnader på fokus och tidsperspektiv med vägredigeringsarbetet)
5. (Synen på företeelser skiljer sig år)
Förslag på de fem viktigaste åtgärderna
För de av er som har ont om tid så har jag här samlat korta beskrivningar på de
som jag anser fem viktigaste förslagen på åtgärder oavsett om de i första hand
påverkar extern-, intern ledtid eller kvalitet. Ytterligare beskrivning av dessa
förslag samt andra finns i de kommande kapitlen.
1. Vad är master och vad är slav – Analysera en alternativ IT-arkitektur
Om man ser på NVDB och de omkringliggande lokala vägnätsredigerarna som
autonoma system som endast hänger ihop via hårt definierad
meddelandehantering så blir helheten stabilare och ansvarsgränsdragningarna
klara. Var och en ansvarar för sitt data och sin applikation, men samtliga måste
noggrant följa reglerna för meddelandehanteringen. Trafikverkets master är
NVDB, den lokala dataleverantörens master är deras eget system, osv.
2. Öka incitamenten för att aktivt jobba med NVDB – Ny betalningsmodell
Förenklat så är dagens betalningsmodell för dataleverantörerna till NVDB
(kommuner, skognäring) att de ansvarar för ajourhållning av respektive ”eget”
geografiskt/funktionellt område och som motprestation får man ladda hem all
NVDB-data för sitt eget område plus för kommuner, geografiskt angränsande
kommuners NVDB-data. För många dataleverantörer uppväger inte detta
kostnaderna i form av resursåtgång, tidsåtgång, krångel mm. Detta undergräver
allvarligt deras vilja att jobba med NVDB och utveckla överföringar mm. I
förlängningen går detta ut över uppdateringsarbetet.
LMV sitter i en snarlik situation med behov av externa uppgiftslämnare till sin
databas. De har valt en modell där dataleverantörerna får betalt för
uppdateringar, men istället får man betala för att hämta ned information från
LMV:s databaser. Det tycks som om LMV:s modell fungerar bra, inte minst ute
bland svagare mindre kommuner där varje intäkt är värdefull. Motivationen för
att jobba med uppdateringar borde öka när det finns en ersättning att inhämta.
3. Begränsa och styr upp överföringsmöjligheterna
Min uppfattning är att det är en fördel om Trafikverket nu begränsar antalet
accepterade överföringsmöjligheter till ett fåtal väl definierade metoder. Dagens
intention av Trafikverket att acceptera många olika överföringstekniker är god,
men är samtidigt lite ”hämmande”. Det är svårare för systemleverantörerna att
helhjärtat koncentrera sig på att utveckla och supporta olika lösningar. Det är
samtidigt lite ”förvirrande” för vissa dataleverantörer. Vad ska man satsa på?
Vad ska man utbilda sig på, osv.
När Trafikverket, efter remissomgång med övriga NVDB-parter, väl har
definierat upp vilka alternativ som ska finnas så måste man hålla fast vid detta
och inte ändra förutsättningarna då det hämmar all utveckling. Jag föreslår en
lösning med 4 olika överföringsalternativ från helautomatisk tjänst till
”manuell” fullservicetjänst:
1. Helautomatisk tjänst import/export av NVDB-uppdateringar, sk hel
leverans
2. Halvautomatisk tjänst import/export av NVDB-uppdateringar, sk delvis
leverans
3. Inmatning via NVDB på web 2012
4. Fullservicetjänst
4. Aktiv stöttning av sällananvändare (”Fullservicetjänst”)
Eftersom så många användare påtalar hur svår överföringstekniken är när det
gäller att lämna och hämta hem NVDB-uppdateringar så anser jag att en
utvecklad definierad fullservicetjänst från Trafikverket ska erbjudas de som så
önskar. Det är nog inte troligt att de ”svagaste” dataleverantörerna kommer att
orka med att lära sig allt som behövs kring NVDB.
Trafikverket bör paketera ett begränsat antal alternativ baserade på olika
minikrav på underlagen och sen erbjuda professionellt stöd som tar vid och
slutför underlagsbearbetningen genom hela produktionsberedningen fram till
registrering i NVDB. Förslag på alternativ att erbjuda:
1. Minikrav på indataunderlagens kvalitet i NVDB på web. Trafikverket
kompletterar och slutför ända in till registrering i NVDB.
2. Minikrav på ”manuella” indataunderlagens kvalitet. Trafikverket
kompletterar och slutför ända in till registrering i NVDB.
3. Hjälp och stöttning vid hämtning av NVDB-data där så behövs.
5. Motverka den förändringskänsliga miljön
Förslagen på förändringar nedan är allmängiltiga och bör underlätta för alla
vägnätsredigerare att få till kompletta leveranser via eget system:
1. Styr upp, och så gott det går, begränsa förändringarna i NVDB.
2. Jobba med framförhållning och förvarna om kommande förändringar i
god tid.
3. Alla förändringar ska göras i på förhand schemalagda och informerade
servicefönster.
4. Ändringsstopp kring stora helger och semestrar.
5. Viktigt att kommunikationen och förtroendet mellan myndighet och
systemleverantörer/dataleverantörer är bra och kontinuerlig.
6. Jobba ordentligt igenom förändringar/uppdateringar i
informationsmodellen med sedvanliga Change Managementrutiner:
A All utveckling görs i en separat utvecklingsmiljö
B Funktionstest i utvecklingsmiljön
C Testinstallation i en testmiljö, så lik produktionsmiljön som
möjligt.
D Integrationstest i testmiljön
D Först när alla konsekvenser av de nyutvecklade/förändrade
funktionerna samt installationen (även för omgivande
miljö) är identifierade och ev åtgärdade så installeras
uppdateringarna i den skarpa miljön i ett servicefönster.
Beskrivning av de största problemen samt
lösningsförslag
NVDB har idag ibland problem med långa ledtider från det att ett vägbygge har
avslutats tills dess att aktuell och korrekt vägdata är registrerat i NVDB och
tillgänglig för NVDB:s användare. Parallellt med de ibland förekommande långa
ledtiderna så upplever Trafikverket att kvaliteten på indata från
dataleverantörerna emellanåt är dålig med resurskrävande handläggning på
Trafikverket som följd för att få upp kvaliteten till acceptabel NVDB-nivå.
Notera att i praktiken så hänger många problem ihop över gränsdragningen
mellan ledtider och kvalitet. Ta t ex problemet med ”Upplevd begränsad nytta
för dataleverantörer med NVDB” som förstås genererar både längre externa
ledtider samt kvalitetsproblem. Nu står just detta problem under externa
ledtider. Jag ser ett behov av att dela upp rapporten i mindre ”greppbara” delar,
därav indelningen i ledtider och kvalitet.
Extern och intern ledtid
Jag har också delat upp ledtidsbegreppet i två olika delar. Ledtider som visar sig
ute bland dataleverantörerna innan underlag har skickats till Trafikverket kallas
här för Externa ledtider. Interna ledtider är ledtider som visar sig inom ramen
för Trafikverkets interna produktionskedja (”logistikkedja”) som består av
produktionsstegen indata, beredning, registrering och verkställande.
Trafikverket har rimligen svårare att påverka externa ledtider. Indirekt kan man
hjälpa dataleverantörerna via stöd till utbildning, information,
överföringsalternativ osv. På samma sätt har dataleverantörerna små
möjligheter att påverka de interna ledtiderna mer än att försöka i god tid skicka
så korrekta underlag som möjligt.
Mitt emellan extern- och intern ledtid i flödet av uppdateringar så finns
”överföringssteget” (som är en stor källa till problem). Problem i detta steg kan
väl sägas vara både externa och interna. För en slutanvändare av NVDB så är det
summan av ledtiderna som spelar roll, inte var de uppstår.
Beskrivning problem externa ledtider samt lösningsförslag
Man kan nog anta att de externa ledtiderna generellt orsakar längre ledtider än
de interna, åtminstone i ”extremfallen”. Det finns ett antal orsaker till de externa
ledtiderna. De viktigaste som vi har stött på i denna undersökning är listade
nedan i den ordning jag uppfattar deras inverkan och betydelse:
1. Upplevd begränsad nytta med NVDB
Många dataleverantörer anser att nyttan med tillgång till en uppdaterad NVDB
för den egna organisationen (samt för kommuner också de kringliggande
kommunerna) inte uppväger kostnaden för att regelbundet lägga resurser på
detta och skicka in uppdateringar. ”Det kostar mer än det smakar” är ett uttryck
som har återkommit flera gånger i intervjuerna och det gäller både kommuner
och skogsnäring. NVDB-arbetet blir då lätt nedprioriterat. Detta är ett
fundamentalt problem som kraftigt motverkar engagemang, egna initiativ,
nyfikenhet och viljan att gå framåt och att utveckla NVDB-arbetet. Det måste
åtgärdas!
Lösningsförslag
A. Öka incitamenten, motivationen för dataleverantörer att aktivt jobba med
NVDB
Jag anser att det första man bör göra är att analysera och förbättra
dataleverantörernas incitament för att jobba mer aktivt med NVDB. För att
uppdatering av NVDB ska fungera smidigt så måste alla berörda parter dra åt
samma håll. Detta är inte självklart här då varje part har sina egna
förutsättningar och mål med sitt arbete:



Trafikverket är en statlig myndighet med uppdrag att underhålla och
driva NVDB ur ett nationellt perspektiv
Dataleverantörer ska via avtal leverera vägnätsuppdateringar för ”sitt”
område till NVDB, men deras primära fokus är den egna organisationens
dagliga och framtida mål
Systemleverantörerna är kommersiella bolag som ska generera vinster
och nytta till ägare, anställda och kunder
Om man accepterar dessa fundamentala skillnader i grundläggande fokus men
trots det inriktar sig på att hitta gemensamma mål och metoder för att få alla att
dra mot samma mål så är mycket vunnet. Det finns vinster för alla parter om
NVDB-arbetet går enkelt och smärtfritt.
Kommunala dataleverantörer:
1. Analysera vad de kommunala dataleverantörerna mest av allt vill ha ut
av NVDB och satsa sedan på detta. Cykelvägar, och i framtiden
gångvägar, är nya områden som många kommuner är intresserade av.
Traktorvägar ytterligare ett annat intressant NVDB-område. Ett annat
exempel på kommunal nytta med NVDB är optimerade ruttplaneringar
med NVDB-data i botten för kommunala verksamheter som direkt bör ge
ekonomiska besparingar, osv. Här bör Trafikverket underlätta för
dataleverantörerna att få ut önskad information.
2. Förenkla möjligheterna att selektera NVDB-utdata. Egna kommunen
plus kranskommuner räcker inte. De kommunala ekonomierna är
alltmer ansträngda och i många av våra kommuner så pågår olika
rationaliseringsåtgärder. En är att samarbeta över kommungränserna
om resurser i cluster och då skapas nya konstellationer av kommuner (jfr
t ex Södertörnsgruppen, Skånegrupperingen m fl) där inte alla
medlemmar gränsar till varandra. När det gäller t ex projekt kring
turistvägar, cykelvägar etc. kan det också skapa önskemål om
sammanhållen gemensam NVDB-data från vitt skilda kommuner där
inte alla gränsar till varandra.
Det är möjligt att det redan idag finns tekniska och kommersiella
möjligheter att förhandla fram sådana här gränsöverskridande lösningar
men i så fall behöver detta paketeras, informeras om och föras ut som en
enkel och möjlig lösning!
Skogliga dataleverantörer:
Situationen för några av de skogliga dataleverantörerna kanske ännu mer
indikerar en begränsad nytta med NVDB-utdata i dess nuvarande form. De
flesta intervjuade skogsliga intressenterna tar idag knappt ut någon utdata från
NVDB, de tittar emellanåt.
Här kan dock NVDB dra nytta av den skogliga applikationen Krönt vägval som
är en ”motståndsinställning i SNVDB som utifrån kända och tillgängliga data
beräknar det ur kostnads- och miljösynpunkt effektivaste vägvalet från
upplastningsplats till mottagningsplats för ett transportfordon med last. Till
exempel har smala vägar med låg maxhastighet ett högt motstånd. Medan breda
landsvägar har ett lågt” (citat från ”Gör rätt val med Krönt Vägval” som hittas på
www.sdc.se).
Skoglig Nationell Vägdatabas (SNVDB) är en kopia av den Nationella
Vägdatabasen (NVDB) anpassad för skogsnäringen. En uppdateringstjänst
håller SNVDB uppdaterad med färsk data från NVDB fem dagar i veckan (se
www.sdc.se). SDC är skogsnäringens IT-företag och har tillsammans med
Skogforsk tagit fram standarden till Krönt vägval.
Med detta som bakgrund så inser vi att för att Krönt vägval ska fungera optimalt
så måste alla skogsbilvägar finnas registrerade med korrekta företeelser, annars
räknar applikationen fel med ibland kostsamma följder. Vetskapen om
skogsbranschens problematik och behov av korrekt NVDB/SNVDB-information
kan vara en ingång till ökat samarbete.
1. Samarbeta så långt det går med skogsnäringen kring SNVDB/NVDB.
Här finns ett gemensamt intresse där dataleverantörerna har ett starkt
ekonomiskt incitament att börja jobba med indata och ledtider!
2. Önskemål om tillgång till satellitfoton i NVDB 2012 har nämnts som ett
viktigt utvecklingssteg. Satellitfoton uppdateras oftast årligen medan
ortofoton endast var 3:e till 5:e år i Norrland (enl uppgift). Detta är en
viktig skillnad då en stor del av skogsnäringens inflöde av förändringar
till NVDB kommer via granskningar av foton som stäms av mot inkomna
anmälningar om förändringar av skogsbilvägar
B. Överväg en annan betalningsmodell
Förenklat så är dagens betalningsmodell för dataleverantörerna till NVDB
(kommuner, skognäring) att de ansvarar för ajourhållning av respektive ”eget”
geografiskt/funktionellt område och som motprestation får man ladda hem all
NVDB-data för sitt eget område plus för kommuner, geografiskt angränsande
kommuners NVDB-data.
LMV sitter i en snarlik situation med behov av externa uppgiftslämnare till sin
databas. De har valt en modell där dataleverantörerna får betalt för
uppdateringar, men istället får betala för att hämta ned information från LMV:s
databaser. Det tycks som om LMV:s modell fungerar bra, inte minst ute bland
svagare mindre kommuner där varje intäkt är värdefull. Motivationen för att
jobba med uppdateringar borde öka när det finns en ersättning att inhämta.
Trafikverket bör snarast analysera LMV-modellen och ev. testa på några
pilotkommuner med olika förutsättningar.
2. Svår teknik stoppar upp och försvårar
Många är de dataleverantörer som säger sig ha problem med tekniken och de får
medhåll av både systemleverantörer och trafikverksanställda. Hela processen
med att lämna vägnätsuppdateringar till NVDB och hämta hem NVDB-data är
för många en stor tröskel, såväl fysiskt och mentalt som resursmässigt.
Jag tror att de flesta av er som läser denna rapport kan mer om detta än
undertecknad (även efter intervjuerna) så jag begränsar mig till att peka på de
problem som jag har noterat.
Lösningsförslag
A. Aktiv stöttning av sällananvändare (”Fullservicetjänst”)
Eftersom så många användare påtalar hur svår överföringstekniken är när det
gäller att lämna och hämta hem NVDB-uppdateringar så anser jag att en
utvecklad definierad fullservicetjänst från Trafikverket ska erbjudas de som så
önskar. Det är nog inte troligt att de ”svagaste” dataleverantörerna kommer att
orka med att lära sig allt som behövs kring NVDB för att få till en smidig
process. Med denna service får denna kundgrupp ett ordentligt stöd samtidigt
som Trafikverket får en god insyn i deras situation.
Trafikverket bör paketera ett begränsat antal alternativ baserade på olika
minikrav på underlagen och sen erbjuda professionellt stöd som tar vid och
slutför underlagsbearbetningen genom hela produktionsberedningen tills
uppdateringarna ligger registrerade i NVDB.
Förslag på varianter:
1. Minikrav på indataunderlagens kvalitet i NVDB på web. Trafikverket
kompletterar och slutför ända in till registrering i NVDB.
2. Minikrav på ”manuella” indataunderlagens kvalitet. Trafikverket
kompletterar och slutför ända in till registrering i NVDB.
3. Hjälp och stöttning vid hämtning av NVDB-data där så behövs
Fördelarna med en egen trafikverksorganisation som jobbar dedikerat mot
inmatning/hämtning av dataleverantörers vägnätsuppdateringar är:
1. En fokuserad och professionell trafikverksgruppering som enbart jobbar
med att hjälpa dataleverantörerna att skicka in/bereda/registrera och
hämta vägnätsuppdateringar. Denna personal kommer över tiden att bli
väldigt specialiserad och strömlinjeformad för just dessa uppgifter.
2. NVDB skulle uppdateras mycket snabbare än idag för dessa kunder.
3. Trafikverket skulle få in kund- och marknadsinformation på ett naturligt
sätt. Återkommande problem, synpunkter, läget i stort och smått bland
dataanvändarna, mm skulle enkelt kanaliseras in i Trafikverket.
4. Återkommande teknik-/hanteringsproblem skulle snabbt upptäckas
bland Trafikverkets fullservicepersonal vilket ger en enklare/rakare
dialog med systemleverantörerna.
5. Kunderna kan släppa problematiken med besvärliga NVDBuppdateringar som stjäl tid och resurser från de vardagliga uppgifterna.
Nackdelar:
1. Någon typ av prissättning måste till. Är det möjligt att bygga upp denna
organisation genom omfördelning av nuvarande resurser, eller måste
nyanställningar till? Kostnaderna måste ställa mot vinsterna med
snabbare och korrektare uppdateringar av NVDB.
2. Kompetensen stannar inom Trafikverket och sprids inte naturligt inom
dataleverantörernas organisationer.
3. Är erbjudandet alltför ”förmånligt” så tar man bort incitament för att
dataleverantörerna ska fortsätta och utvecklas samt satsa på mer
automatiska överföringar vilket även drabbar systemleverantörerna i
form av minskad försäljning.
OBS! Tanken är att denna organisation inte ska bli alltför stor. Den ska i princip
stötta de svagaste dataleverantörerna samtidigt som majoriteten av
dataleverantörerna fortsätter att utveckla sina NVDB-processer.
B. Analysera om en speglad separat utvecklingsmiljö kan ”kompensera”
optimistisk ansats i NVDB
Ett problem är den s k optimistiska ansatsen som man har antagit i NVDB. När
en användare checkar ut ett område ur NVDB för att göra uppdateringar så låses
inte detta område för utcheckning av andra användare. Problem uppstår när
användare nr två ska checka in sina uppdateringar vilka då stoppas av systemet.
Risken är överhängande att dessa problem ökar allteftersom fler
dataleverantörer går över till automatiska/semiautomatiska lösningar som
kräver in-/utcheckningar. Dessa dataleverantörer har inga möjligheter se
varandras utcheckningar.
Huvudanledning (?) till den optimistiska ansatsen är att när större
uppdateringsjobb inkommer till Trafikverket/NVDB så tar det kalendertid för
Trafikverkets logistikkedja att redigera och registrera dem. För stora
dataleverantörer, t ex större stadskommuner, så fungerar inte deras ordinarie
verksamhet med nödvändiga dagliga uppdateringar fullt ut om Trafikverket har
checkat ut geografiska områden och därmed försvårar samtidiga incheckningar
av nya redigeringar i samma område under en längre tid.
Mitt förslag är att Trafikverket utreder möjligheterna att stödja en speglad
separat NVDB-utvecklingsmiljö där Trafikverket ensamt kan jobba med större
uppdateringar samtidigt som den skarpa NVDB-produktionsmiljön är öppen för
dataleverantörerna. Utvecklingsmiljön måste förstås synkas kontinuerligt med
den skarpa NVDB-produktionsmiljön, alternativt uppdateras till skarp ”NVDBnivå”.
C. Dialog med systemleverantörerna kring vägnätsredigerare som inte levererar
företeelser
Från några av vägnätsredigerarna kan man idag inte leverera uppdaterade
företeelser direkt. Då haltar logistiken och den förväntade vinsten med
investeringen i vägnätsredigeraren urholkas kraftigt. Dataleverantörer med svag
ekonomi vill absolut inte dubbelarbeta. Det leder förstås också till merjobb för
Trafikverket som måste redigera och översätta underlag innan de kan registreras
i NVDB. Systemleverantörerna får ökad support till sina kunder. Fungerande
automatiska överföringar är föga överraskande av godo för alla parter.
Trafikverket bör sätta sig ned och ta en förnyad dialog med
systemleverantörerna och representanter för dataleverantörerna kring den
tekniska problematiken med företeelser:
1. Ta fram en långsiktig teknisk IT-arkitektur som parterna är nöjda med.
Långsiktighet är viktigt för att systemleverantörerna ska kunna räkna
hem ev investeringar. Några systemleverantörer har explicit sagt att man
inväntar ev förändringar i NVDB-hanteringen.
2. ”Begränsa och styr upp överföringsmöjligheterna”. Definiera exakt vilka
överföringsalternativ som ska finnas kvar under överskådlig framtid,
inga fler inga mindre.
3. Det bör vara så ekonomiskt fördelaktigt i form av minskad resurstillgång
hos Trafikverkets logistikkedja att få automatiska s k hela leveranser
(både vägnät och företeelser via eget system) att fungera att man bör
räkna på möjligheterna att stötta ev investeringar hos
systemleverantörerna om detta är nödvändigt för att få fram fungerande
tekniska lösningar.
D. Motverka den förändringskänsliga miljön
En av de större vägredigeringsprodukterna som är ganska spridd har en
arkitektur som bygger på att informationsmodellen hos de lokala systemen i
princip är identisk med NVDB:s. Detta fungerar bra så länge man inte ändrar
förutsättningarna. Däremot så fort ändringar förs in (inte alla men många), t ex
att Trafikverket ändrar en viss företeelse i NVDB, så får man problem med
haltande system.
Denna systemlösning passar bäst för stora dataleverantörer som jobbar dagligen
med uppdateringar i sina lokala system. Modellen är som sagt känslig för
förändringar men när den väl är uppe så tycks den fungera bra. Förslagen på
förändringar nedan är allmängiltiga och bör underlätta för alla
vägnätsredigerare att få till kompletta leveranser via eget system:
1. Styr upp, och så gott det går, begränsa förändringarna i NVDB.
2. Jobba med framförhållning och förvarna om kommande förändringar i
god tid (ett önskemål från en systemleverantör pekar på ett behov av
framförhållning om ca nio månader).
3. Alla förändringar ska göras i på förhand schemalagda och informerade
servicefönster. Ändringsstopp kring stora helger och semestrar. Viktigt
att kommunikationen och förtroendet mellan myndighet och
systemleverantörer/dataleverantörer är bra och kontinuerlig.
4. Jobba igenom förändringar/uppdateringar i informationsmodellen
ordentligt med sedvanliga Change Managementrutiner:
A All utveckling görs i en separat utvecklingsmiljö
B Funktionstest i utvecklingsmiljön
C Testinstallation i en testmiljö, så lik produktionsmiljön som
möjligt.
D Integrationstest i testmiljön
E Först när alla konsekvenser av de nyutvecklade/förändrade
funktionerna samt installationen, inklusive för omgivande
miljö, är identifierade och ev åtgärdade så installeras
uppdateringarna i den skarpa miljön i ett definierat
servicefönster.
E. (Lokala vägnätsredigeringssystem optimerade för andra uppgifter)
Det är viktigt att komma ihåg att vägnätsredigeringssystemen är optimerade för
andra uppgifter än att uppdatera NVDB, dvs i första hand för att stötta
dataleverantörerna i deras övriga dagliga arbete. Systemstödet för NVDBuppdateringar är därför ibland begränsat och emellanåt kanske mindre
prioriterat. När stödet är begränsat så får dataleverantörerna kompensera med
mer manuellt arbete för att få ihop korrekta filer/underlag, något som försvårar
för fattiga dataleverantörer.
Trafikverket:
1. Utbilda dataleverantörerna inför upphandlingar med generell
rådgivning. Många av de mindre dataleverantörerna behöver generell
stöttning och goda råd.
Dataleverantörer:
1. Inte så mycket att göra något åt mer än att vara medveten om dessa
skillnader och ta höjd för dem. Vid kommande upphandlingar av
vägnätsredigeringssystem bör förstås kommunikationsmöjligheter med
NVDB tas med som en parameter att kontrollera och diskutera.
2. Gå samman med fler dataleverantörer vid upphandlingar och få på så vis
mer tyngd och kompetens.
3. Diskutera även med Trafikverket för goda råd och hjälp vid
upphandlingar.
4. Ställ krav på era leverantörer
Systemleverantörer:
1. Om möjligt, vidareutveckla produkterna så att NVDB-uppdateringar går
smidigare.
3. Begränsat incitament för vägentreprenörer att rapportera in vägdata
Det är vanligt att kommuner och skogsnäring lägger ut vägarbeten på
entreprenad. För att kunna rapportera in nya vägdata till NVDB så är de då
beroende av att entreprenörerna lämnar in underlag för vidarebefordran. Att
rapportera in ny vägdata kostar dock pengar och resurser för
vägentreprenörerna som har annat fokus. Det är inte ovanligt att
inrapporteringen kommer upp först vid slutlig inmätning och godkännande av
vägentreprenad. Då kan det hända att entreprenörens projektledning redan
jobbar med nästa projekt och har sitt fokus där varför inrapporteringen blir än
mer avlägsen.
Läget för skogsnäringen är likartad. Där tvingas man ofta att samla in
uppdateringar för NVDB i efterhand via satellitfoton eller ortofoton som man
granskar och jämför med inrapporterade vägbyggen. Satellitfoton uppdateras en
gång per år, ortofoton var 3:e till 5:e så redan där har vi en betydande extern
ledtid mellan fysiskt vägarbete och inrapportering till NVDB.
Ofta är kompetensen kring NVDB-företeelser dessutom mycket begränsad hos
entreprenörerna.
Lösningsförslag
Dataleverantörer:
1. Arbeta in klausuler i avtalen med vägentreprenörerna rörande när och
vad dessa ska leverera för information till uppdragsgivarna för
vidareförmedling till NVDB.
Ev komplettera med viten om det inte fungerar?
2. Uppdatera vägbyggnadsprocesserna mellan kommuner/skogsnäring och
vägentreprenörer så att återkommande möten och/eller inrapportering
av vägnätsuppdateringar schemaläggs redan från ett tidigt skede och
verkligen blir av. Det ger också ett visst spelrum om ni inte får in all
nödvändig information i god tid i förhållande till det pågående
vägbygget.
3. Informera och dela ut blankett/länk till inrapporteringsformulär för
vägentreprenörer, se Trafikverket: punkt 2 nedan.
Trafikverket:
1. Ta fram tydlig policy/mål kring vad som ska gälla för registrering av
projekteringsinformation kontra att avvakta med registrering tills allt är
uppmätt och godkänt. Fördelen med att leverera
projekteringsinformation, ställa Färdigtidpunkt till beräknat
färdigdatum och senare komplettera med inmätt slutgiltigt data och
öppna för användande är att det går snabbt för Trafikverket att finjustera
sena ändringar då det mesta då finns inlagt. NVDB kommer snabbt att
vara uppdaterad med korrekt information om det nya vägbygget, alltså ”i
fas”. Nackdelen är att dataleverantören och Trafikverket måste hålla
kontroll på Färdigtidpunkter samt ibland gå in och uppdatera den
registrerade entreprenörsinformationen.
2. Ta fram färdiga blanketter, alternativt länk webformulär, med
fördefinierade fält med möjliga indata och pedagogiska exempel som
dataleverantörerna kan ge till entreprenörerna. Detta underlättar
kommunikationen med ”NVDB-ovana” entreprenörer.
4. Dataleverantörers avdelningar osynkroniserade
Ibland är kommunikationen mellan en dataleverantörs vid vägbyggen
involverade olika avdelningar inte synkroniserad och ärenden/information faller
mellan stolarna. Vanligt är också att geometrier kommer från avdelning 1 och
kompletterande företeelser från avdelning 2. Då måste dessa data synkroniseras
och kopplas ihop, antingen via en gemensam dataleverantörskontakt alternativt
på Trafikverket /NVDB. Denna bristande synkronisering skapar osäkerhet och
frågetecken.
Lösningsförslag
1. Dataleverantörerna måste gå igenom dagens organisation och arbeta
fram rutiner och fördelning av uppgifter och ansvar mellan berörda
avdelningar. Stäm av regelbundet.
2. Försök definiera en enskild funktion/roll som tar det totala ansvaret för
dataleverantörens leveranser av all vägnätsinformation, dvs både
företeelser och geometrier osv. till NVDB. Om informationen föds på
olika avdelningar så ska funktionen ta ansvar för att samla ihop
leveranserna.
5. Fler orsaker till långa externa ledtider enl de intervjuade
I intervjuerna har många fler orsaker till långa externa ledtider framkommit.
Samtliga dokumenterade kommentarer och intressanta synpunkter från
intervjuerna finns i kapitlet Intervjuer längre bak i Appendix. Kommentarerna
och synpunkterna är där indelade efter intervjufrågor (intervjuformulären) och
svarsgrupp (Trafikverket, dataleverantör el systemleverantör), men är f ö
anonyma. Nedan ser ni ett urval av alla dessa synpunkter.
1. Överväg möjligheterna att göra det enklare för dataleverantörer att
skicka in underlag så länge de är tolkningsbara. Mindre krav på syntax
och samband, mer fokus på förståelse av innehållet. Sen kan experter på
Trafikverket översätta till fungerande indata. (Trafikverket)
2. Det saknas kompletta instruktioner, ev mallar, med info om (framförallt
obligatoriska) företeelser. (2 st)
3. Om det fanns möjligheter att vid utcheckning välja mindre geografiska
områden för att få ned filstorlekarna skulle det underlätta för
dataleverantörerna.
4. Öppna upp för direkt inmatning I NVDB av ”ofarliga företeelser” via en
ordnad rapportering för dataleverantörer med rätt rättigheter.
(Trafikverket)
5. LMV har ett gott fungerande samarbete med dataleverantörerna. Här
borde finnas öppningar för ett ökat samarbete mellan NVDB/
Trafikverket och LMV. Skulle NVDB kunna utnyttja också LMV:s data,
åtminstone i fall där NVDB inte får in information (i tid)? Framförallt
skulle LMV:s fotobaserade vägnät, geometrin, kunna importeras till
NVDB där detta saknas. Här kan NVDB t ex snabbt få in information om
bil-, cykel- och gångvägar! (Trafikverket)
6. En variant som ger långa ledtider är kommunerna som använder LMV:s
ortofoton som underlag. Dessa foton har själva i regel 1 – 2 års ledtid
vilket medför att redan när dataleverantören börjar arbeta med
uppdateringsdata så är man kraftigt försenad jämfört med det fysiskt
utförda arbetet. (Trafikverket)
-----------------------------------------------------------------------------------7. ” Trafikverket har ställt alltför höga krav på kommunerna när det gäller
företeelser vid leveranser av vägnätsförändringar. Kommunerna får inte
ihop det med företeelser och de vill inte lägga pengar på funktionalitet
för uppdateringar av NVDB-företeelser då nyttan av dessa, än så länge,
anses som begränsad.” (Systlev)
8. Systemleverantörerna kan lägga in ytterligare systemstöd i resp. produkt.
Rullgardinsval, valideringar, rimlighetskontroller mm, men det är en
prioritering av intäkter, nytta och kostnader. Då skulle man kunna få ned
antalet fel i senare produktionsled och därmed kortare ledtider. (Systlev)
9. ”Kommunerna uppfattar ibland att Trafikverket ställer högre krav på
fullständighet än på kvalitet på indatat. Om detta stämmer så bör
Trafikverket överväga att ändra prioriteringen så att kvalitet på viktigt
indata kommer först och fullständighet för mindre viktiga företeelser
tonas ned. Ett exempel kan vara att Trafikverket via avtal tillåter enklare
generaliseringar för enskilda kommuner: ”Följande attribut gäller alltid
för dessa objekt i denna kommun”, osv.” (Systlev)
-----------------------------------------------------------------------------------10. Det finns en osäkerhet kring leveransavtalens dataleveransbilagor då
Trafikverket har varit otydlig. Finns det ett nytt leveransavtal kring
NVDB? För ca ett år sedan genomförde Trafikverket och LMV ett möte
kring ev nya leveransavtal, men vad har hänt sedan dess? Detta är
intressant då bättre anpassade och tydliga avtal bör medföra bättre
inflöde av information till NVDB från kommunerna. (Datalev)
11. Incitamenten för att dra igång inrapportering av vägnätsuppdateringar
via vägnätsredigeraren upplevs som alltför små. Vägnätsredigeraren
levererar inte heller företeelser så lösningen är ännu inte komplett. Om
volymerna ökar och tekniken blir stabilare så kan denna funktion bli mer
intressant. (Datalev)
12. ”I takt med att det blir vanligare med samarbete mellan kommuner i
NVDB-frågor så borde Trafikverket vara lite proaktiva och komma dessa
kluster till mötes i olika frågor: ”Om ni går ihop i denna fråga så har vi en
lösning för det ...”” (Datalev)
13. Om en del av dokumentationen var skoglig och innehöll de företeelser
som är aktuella på skogsbilvägar (vilket är en delmängd av det totala
antalet olika företeelser som finns) skulle det uppskattas. Internt inom
skogsbranschen så diskuterar man också med Skogforsk om att ta fram
en variant på kravspec. med skogliga företeelser. (Datalev)
14. Den stora ledtiden uppstår för skogsnäringen då man inte har något
fungerande rapporteringssystem för vägnätsförändringar från
chaufförer, virkesköpare, skogsägare m fl. Det är ett strukturellt problem
då inrapportering inte ingår i deras arbetsbeskrivningar och det inte
heller finns något större incitament för att inrapportera. (Datalev)
15. Trafikverket borde ta fram pedagogiska broschyrer att ge till
entreprenörer som beskriver varför och hur NVDB-data ska redovisas.
Om kommunerna i god tid kan ge dessa broschyrer till anlitade
entreprenörer/projektledare så skulle informationsinsamlingen gå
lättare och snabbare! (Datalev)
16. Vi är kritiska till att Trafikverket i den senaste
informationsmodellremissen har avvikit från den SIS-standard för väg
och järnvägsstandard som finns sedan tidigare. Betydelsen av lojalitet
gentemot etablerade standarders är ovärderlig. (Datalev)
Beskrivning problem interna ledtider samt lösningsförslag
Vi har även interna ledtider. Dessa har ibland sitt ursprung i tidigare led, ibland
inom Trafikverket, men de påverkar alla Trafikverkets arbete med NVDBuppdateringar. nedanstående källor till ledtider internt har identifierats:
1. Stort antal inrapporteringsvägar och format
Idag tillåter Trafikverket ett antal olika inrapporteringsvägar/-sätt, allt från
ganska automatiserad överföring till enkla ”handskrivna” underlag med
geometrier och företeelser. Motivet till denna generösa inställning är


dels insikten att dataleverantörernas möjligheter att leverera är så olika
från sällananvändare med knappa resurser till större
kommuner/branschorganisationer som jobbar regelbundet med NVDBrelaterade uppdateringar,
dels att motivationen för inrapporteringsarbete ibland är begränsad. Är
Trafikverket alltför rigid och
t ex kräver en viss ”nivå” på indata så finns risk att man helt enkelt inte
får in de nödvändiga uppdateringarna för att NVDB ska fungera som
tänkt.
Ett antal trafikverksmedarbetare/-konsulter påpekar att inrapporteringsvägarna
bör styras upp för att underlätta inflödet av ärenden genom beredning in till
registrering i NVDB. Det har även lyfts fram ekonomiska aspekter från
Trafikverkets sida för den generösa inställningen. Det kostar helt enkelt pengar
att tillåta alltför många alternativ.
En synpunkt som har kommit upp några gånger är att Trafikverkets tillåtande
inställning till olika inrapporteringsvägar gör att regelverket blir luddigt, lite
svårgreppbart för en sällananvändare. Det blir svårare att ta beslut om vilken
metod som man ska satsa på. Liknande tankegångar har noterats från några
systemleverantörer. Jag tror att Trafikverket tjänar på att nu sätta ned foten och
erbjuda ett begränsat antal väldefinierade lösningar. Föreslagna lösningar
remissas till systemleverantörer och några dataleverantörer av olika storlek och
typ.
Lösningsförslag
Begränsa valmöjligheterna till fyra hårt uppstyrda alternativ. För in i avtalen
med resp. dataleverantör vilket/vilka alternativ som man ska använda sig av i
den kommande avtalsperioden. Andemeningen är att låta dataleverantörerna ta
ansvar för datainnehållet och Trafikverket tar ansvar för interface och
syntaxkrav.
Mina förslag på möjliga överföringsvägar:
1. Helautomatisk tjänst import/export av NVDB-uppdateringar (s k hel
leverans):
Helt automatisk dygnsvis import/export av uppdateringar av geometrier
och företeelser mellan NVDB och lokala vägnätsredigerare via NVDB:s
webtjänst (nattlig överföring av inkrementella uppdateringar)
2. Halvautomatisk tjänst import/export av NVDB-uppdateringar: (s k
delvis leverans):
Semiautomatisk dygnsvis import/export av uppdateringar av geometrier
mellan NVDB och lokala vägnätsredigerare via NVDB:s webtjänst.
Företeelser skickas via NVDB på web 2012.
3. Komplett inmatning via NVDB på web 2012:
Fortsätt utveckla NVDB på web 2012 så att inmatningsformulär för
geometrier och företeelser har maximalt med användarstöd och gör den
till ”officiell inmatningskanal för manuell uppdatering”. Stödet ska
(minst) bestå av
- avancerat grafiskt användargränssnitt
- förklarande rubriker och hjälptexter
- validering inmatning och inmatat värde på fältnivå
- rullgardinsval överallt där det är möjligt
- bemannad support på Trafikverket åtminstone på kontorstid
Målet bör vara att när en uppdatering har godkänts av
inmatningsformuläret så är all syntax korrekt, inga obligatoriska fält
saknas och inga orimliga värden finnas. Nödvändiga beredningsresurser
bör kunna minskas om indatat håller denna mininivå på kvaliteten.
För dataleverantörerna är detta en tids- och platsoberoende lösning. De
kan när de vill lägga in uppdateringar via webformuläret. Omedelbar
valideringskontroll snabbar på processen och Trafikverket får indata som
man vill ha det och på plats i egna system. Underhåll på webformulär är
ofta enkelt i jämförelse med andra tekniker vilket borde spara resurser åt
Trafikverket.
4. Fullservicetjänst:
Trafikverket erbjuder mot ersättning standardiserade servicetjänster åt
de dataleverantörer som själva inte har möjlighet, eller vill, underhålla
NVDB-uppdateringarna. Två varianter föreslås:
A. Ställ minikrav på indataunderlagens kvalitet i NVDB på web.
Trafikverket kompletterar.
B. Ställ minikrav på ”manuella” indataunderlagens kvalitet.
Trafikverket kompletterar och registrerar
För mer information kring detta lösningsförslag se punkten B. Aktiv
stöttning av sällananvändare (”Fullservicetjänst”) i kapitlet Beskrivning
problem externa ledtider samt lösningsförslag.
2. Varierande underlagskvalitet
När undermåliga underlag inkommer vidtar ett omfattande analysarbete med
frågor, svar, schablonvärden mm innan indatat håller acceptabel kvalitet för att
importeras i NVDB. Allt detta redigeringsarbete resulterar i att kalendertid går
innan korrekta vägnätsredigeringar finns inlagda i NVDB och tillgänglig för
andra. Nedan tas ett urval av alla förslag som inkommit upp.
Lösningsförslag
Dataleverantörer:
1. Små dataleverantörer, sällananvändare, som inte själva orkar
upprätthålla en tillräckligt hög kompetens kring inmatning av
filer/underlag för geometrier och företeelser kan undersöka
möjligheterna till samarbete med andra
kommuner/branschorganisationer och på så sätt dela på resurser med
tillräcklig kompetens. Jämför Södertörnsgrupperingen,
Skånekommunerna m fl.
2. En annan lösning är att regelbundet hyra in en konsult, själv eller via en
sammanslutning som ovan. Det går förmodligen snabbt och med bra
resultat. Nackdelarna då är att kompetensen kring NVDB stannar hos
konsulten samt att risken för ”batchinlämning” ökar.
3. Gå igenom Trafikverkets dokumentation och e-learningkurser på
NVDB.se!
Trafikverket:
1. Jobba betydligt mer aktivt och utveckla NVDB-dokumentationen,
NVDB-utbildningarna och NVDB.se website (Se Beskrivning
kvalitetsproblem och lösningsförslag ”Svårt hantverk”).
2. Om Trafikverket styr upp de olika tillåtna inrapporteringsvägarna och
formaten så bör kvaliteten höjas rejält. (Se lösningsförslag till ”Stort
antal inrapporteringsvägar och format”).
Systemleverantörer:
1. Fortsätt att utveckla vägredigeringssystemens användargränssnitt. Lägg
till valideringar på fältnivå, rullgardinsval, rimlighetstester mm, allt för
att styra upp inmatningen av korrekt indata.
2. Lägg till syntaxkontroll typ Portvakten.
3. Indatavolymer fluktuerar kraftigt
Många dataleverantörer är små och uppdaterar sällan NVDB. Då dessa också
ofta har begränsat med resurser och relativt få väguppdateringar så tenderar de
att samla ihop sina uppdateringar och skicka en batch någon el. några gånger
per år. Då går det förstås först kalendertid mellan slutfört vägarbete fram till
inrapportering av underlag/fil (extern ledtid) och sedan uppstår även interna
ledtider på Trafikverket då indatavolymen blir alltför stor för produktionen.
NVDB-organisationen har inte resurser för att ständigt på kort tid avverka
toppar.
Även skogsnäringen har ibland likartade problem. Vissa skogliga organisationer,
bl a i norr, jobbar ofta med NVDB på vintern. De viktiga årliga nya
satellitbilderna släpps i dec/jan. Då tillbringar man mycket tid med att jämföra
fotona med inkomna anmälningar. Vid konstaterad vägbyggnation (genom
fotogranskning) så skickas utskick till markägarna, normalt kring mars varpå
svaren droppar in fram till sommaren. Där så behövs kompletteras/justeras
inregistrerade värden kommande vinter.
Lösningsförslag
Dataleverantörer:
Försök att jobba ”bort” NVDB-uppdateringar så fort de uppkommer. Att samla
på hög och skicka till Trafikverket förlänger ledtiderna då detta skapar
flaskhalsar i NVDB-beredningen.
Förvarna Trafikverket i god tid när en större batch av uppdateringar är på
ingående till Trafikverket så att de hinner allokera resurser.
Sällanarbete med få repetitioner över tiden försvårar inlärningen av hanteringen
av NVDB-relaterade arbetsuppgifter.
Trafikverket:
1. Öka incitamenten för kontinuerlig inmatning av förändringar. Jobba
med avtal.
2. Introducera en pris-/ersättningsmodell med stigande kostnad/avtagande
ersättning vid ökande eftersläpning av uppdateringar.
3. Skapa en rutin för förvarning från dataleverantörer när de vet att en
större batch kommer att skickas. Komplettera ev med återkommande
korta möten.
4. Komplex produktionskedja med flera huvudmän
Många av de intervjuade anser att NVDB:s produktionskedja är alltför komplex
med många steg samt olika huvudmän. Detta får till följd att när antalet ärenden
lagras upp vid ett steg, t ex Beredning, så är det svårt att flytta resurser från t ex
Registrering med följd att flödet optimeras inte. Bakgrund interna NVDBkedjan:
Indata
Beredning
Registrering
Verkställande
Indata/mottagn
Ansvarar för kontakten mot dataleverantörerna.
Indatafunktionen bemannas av
Trafikverksmedarbetare.
Beredning
Många inleveranser av vägnätsredigering kräver
genomgång, rättning och anpassning innan det går att
korrekt importera uppdateringarna i NVDB. Här görs
det arbetet.
Beredarna är inhyrda konsulter.
Registrering
I steget Registrering så genomförs ett antal kontroller
av obligatoriska fält samt översätter indatafilen till ett
formaliserat utseende på shape-filer.
Verkställande
Konverterar till sk NVD-format, klistrar på vägnätet
samt importerar till NVDB
Lösningsförslag
1. Gå igenom de fyra stegen. Kanske kan något steg tas bort alt. slås ihop
med annat om kvaliteten på underlagen förbättras (punkt 2 ovan) och
antalet inlämningsalternativ begränsas (punkt 3 ovan)? Ökar dessutom
andelen helautomatiska överföringar så bör rimligen produktionskedjans
belastning också minska.
2. Trafikverket bör samla så många enheter som möjligt i samma
organisatoriska enhet under samma ledning. Detta underlättar när man
måste flytta resurser mellan de olika stegen. Även flödet av information
mellan de olika stegen förbättras då.
5. Fler orsaker till långa interna ledtider enl de intervjuade
I intervjuerna har många fler orsaker till långa interna ledtider framkommit.
Samtliga dokumenterade kommentarer och intressanta synpunkter från
intervjuerna finns i kapitlet Intervjuer längre bak i Appendix. Kommentarerna
och synpunkterna är där indelade efter intervjufrågor (intervjuformulären) och
svarsgrupp (Trafikverket, dataleverantör el systemleverantör), men är f ö
anonyma. Nedan ser ni ett urval av alla dessa synpunkter:
1. Nuvarande organisationen har något försvårat kontrollen för kommun/skogskontakter. De hamnar ibland på mellanhand då
dataleverantörerna har flera inrapporteringsmöjligheter varav några ”går
förbi” kontakten. Den tidigare organisationen med ”alla kontakter med
dataleverantörer”, inrapportering i Slussen och förändringsfil till LMV
som kontrollerade och importerade till NVDB var tydligare för gruppen.
(Trafikverket)
2. Ibland skickar dataleverantörerna in indata/uppdateringar till fel
maildress (2 st). (Trafikverket)
3. Det finns ibland skilda åsikter om hur underlagen ska tolkas mellan
framförallt Beredning och Indata/Produktion vilket stoppar upp flödet.
(Trafikverket)
4. Dokumentation och hantering av skogs- och enskilda vägar är luddigt,
oklart (trots det stora antalet mil väg av denna typ). (Trafikverket)
5. De verktyg som används i beredningen skapar inte alltid ett underlag
som passar som input till registreringen. (Trafikverket)
6. Våra verktyg för registrering används inte alltid på mest effektiva sätt.
(Trafikverket)
7. Vi har även ett internt snitt mellan Beredning och Produktion där det
ibland fastnar ärenden och skapas returer (Trafikverket)
8. Ett problem är förekomsten i NVDB av vissa företeelser som inte
används ute hos dataleverantörerna och därför ibland ”tappas bort” i
uppdateringarna. Dessa skulle kunna ligga som systemstöd i en
portal/hub. (2 st) (Trafikverket)
9. Enskilda vägar o skogsbilvägnätet har oklart regelverk med otydliga
definitioner, regler. (Trafikverket)
-----------------------------------------------------------------------------------10. En automatisering hos NVDB där de leveranser som kommer från en
certifierad lösning slipper hanteras på manuellt sätt. (Systlev)
11. Skapa ett teknikråd där information om problem, nyheter, förslag etc
presenteras och diskuteras. (Systlev)
-----------------------------------------------------------------------------------12. Den stora personalomsättningen och de många omorganisationerna på
delar av Trafikverket/NVDB vilket främjar inte personliga kontakter och
”trygghet”. (Datalev)
Beskrivning kvalitetsproblem samt lösningsförslag
Nedan följer en genomgång av de orsaker till kvalitetsproblem som har
framkommit i intervjuerna:
1. Vad är master och vad är slav – Förslag på en alternativ IT-arkitektur
En källa till oenighet, eller åtminstone hur man uppfattar NVDB:s relation till
omvärlden, är den skilda synen på master och slav i uppdateringsprocessen.
Trafikverket ser NVDB som naturlig master medan dataleverantörerna ofta
tvärtom ser sina lokala system som master som uppdaterar NVDB.
Lösningsförslag
Om man istället ser på NVDB och de omkringliggande lokala
vägnätsredigerarna som autonoma system som endast hänger ihop via hårt
definierad meddelandehantering så blir helheten stabilare. Var och en ansvarar
för sitt data och sin applikation samt att man noggrant följer reglerna för
meddelandehantering. Då blir gränsdragningar och ansvarsfördelning klara.
Ett stort skogsbolag hade tidigare för sina OLF-system på de olika produktionsoch säljenheterna inom en division en IT-arkitektur benämnd Autonoma
delsystem. Här var problematiken hur man snabbt fasar in/ut olika
produktionsenheter eller säljkontor utan att störa övriga system. En annan
utmaning var att garantera produktionskapacitet även om en produktionsenhet
föll ifrån. Lösningen blev just fristående autonoma delsystem som hängde ihop i
ett nätverk via definierad meddelandehantering. Varje meddelande var
specificerat till innehåll, adresser och regelverk. Varje produktionsenhets/
säljkontors OLF-system, inklusive databaser, var fristående från övriga. Såldes t
ex ett pappersbruk var det bara att ”dra ur sladden” (lite förenklat), övriga
enheter var ju fristående och meddelandehanteringen mellan dessa fortsatte att
gå. Gick en produktionsenhets IT- system ned kunde man lägga order hos ett
annat bruk, osv.
Gör vi tankeexperimentet att flytta över ansatsen Autonoma delsystem till
NVDB och omkringliggande lokala vägnätsredigerare så finns ett antal fördelar:
1. För Trafikverket får NVDB vara ”master” och för resp. dataleverantör får
dess lokala system vara dess ”master”. Just detta att man ”bara” har
ansvar för data i sitt eget system samt att man noggrant följer reglerna
för meddelandehantering är fundamentalt viktigt för fokus och
ansvarsfördelning.
2. Resp. IT-system ska ju här verkligen vara autonomt och oberoende av
övriga, såväl kommunala vägnätsredigerare, skogliga applikationer som
NVDB.
3. Hårt definierad meddelandehantering mellan lokala vägnätsredigerare
och NVDB är ju precis vad vi behöver för att överföra och hämta ned
vägnätsredigeringar mellan NVDB och lokala system.
4. Dubbellagring av data är inget problem, varken för NVDB eller de lokala
kommunala/skogliga systemen.
5. Från Trafikverkets horisont borde man vara nöjd så länge
meddelandehanteringen löper för då vet man att NVDB får korrekt
information uppdaterad. Hur de lokala systemen ser ut, eller hur data
lagras där, spelar inte Trafikverket någon större roll.
6. Från en lokal dataleverantörs horisont borde det vara likartat. Så länge
meddelandehanteringen löper så får man den information man har
kommit överens om. Hur NVDB ser ut bakom fasaden eller hur data
lagras ska inte egentligen spela dem någon.
Nackdelarna med Autonoma delsystem är bl a:
1. Vid problem med dataöverföringen så haltar systemen och
detektivarbete får göras kring vilken information som är korrekt, vad
som har överförts, vad som blev ”kvar”.
2. Det blir många meddelanden som ska definieras, byggas, underhållas,
övervakas och sändas.
2 Svårt hantverk
Väldigt många medger att det är svårt att helt korrekt rapportera geometrier,
topologier och tidsangivelser. Många dataleverantörer är sällananvändare då
vägbyggnadsaktiviteten är begränsad i kommunen/skogsavsnittet. Berörd
personal hinner inte lära sig, har svårt att komma ihåg detaljer och hur ev
systemstöd, överföringar mm fungerar.
Lösningsförslag
Trafikverket har tre parametrar redan idag som jag tycker är undermåligt
utnyttjade och där det finns potential att utöka och förbättra innehållet. Dessa är



NVDB-dokumentationen
NVDB-utbildningarna
NVDB.se website
NVDB-dokumentationen
Påfallande många intervjuade svarar ungefär att ”Det mesta finns men det kan
vara svårt att hitta. Vi saknar lite mer länkar, index mm”. Ett annat klagomål
berör svårigheterna att hitta senaste versioner. Många tittar mer eller mindre
aldrig i dokumentationen vilket är synd. Här har Trafikverket en kanal som man
styr över och man borde lägga mer resurser på den.
1. Se över strukturen med index och länkar.
2. Ett återkommande påpekande är svårigheterna att se vilken information
som är yngst, senast uppdaterad. Detta skapar osäkerhet om man ska
ladda ned, vilken som är den senaste versionen osv. Trafikverket bör gå
igenom och märka upp filer med tidsmarkeringar samt flytta gammalt
material till ”Arkiv”.
3. Informera tydligare om nyheter och förändringar.
4. Skicka inte utdrag och texter från dokumentation som ni refererar till
utan skicka länkar så att användarna blir bekanta med allt som finns här.
5. När Trafikverket har fräschat upp dokumentationen och strukturen så
gör en liten kampanj kring detta så att det slår igenom.
NVDB-utbildningarna
NVDB-utbildningarna påminner lite om NVDB-dokumentationen. Många har
aldrig tittat på kurserna. De som har kört dessa säger att de är bra och
pedagogiska men att det saknas fortsättningskurser. Dagens kurser verkar passa
bra till nyanställda men avancerade fortsättningskurser finns inte. Även här har
Trafikverket en användbar kanal för att föra ut information och goda råd:
1. Trafikverket är på rätt spår med utformning, pedagogik osv men fortsätt
med kurser för mer drivna vägredigerare.
2. Gör mer reklam för kurserna.
3. Utöka samarbetet med systemleverantörerna för att få in Trafikverkets
kurser i deras produktutbildningar. ”Ju mer slutanvändarna kan, desto
färre ofullständiga underlag kommer till Beredningen” senare i
underhållsarbetet.
4. Gör en kampanj kring kurserna för att sprida kunskapen om dessa.
NVDB.se website
Idag tycks NVDB.se ofta fungera ungefär som ett något statiskt bibliotek där
man hittar dokumentation, kurser osv. Jag vill att Trafikverket ska se NVDB.se
som den portal kring vilken nyheter, information, utbildningar, dokumentation
mm roterar. Det ska vara navet i NVDB-världen. Om Trafikverket kan få
dataleverantörer, systemleverantörer och trafikverksmedarbetare att
regelbundet gå in och titta på nyheter, söka information, ställa frågor, svara på
frågor, uppdatera med händelser, beskriva success stories etc så kan man öka
gemenskapen kring NVDB och de lösningar och problem som finns.
Förslag på åtgärder:
1. Gör ett lyft av web siten. Den ska vara modern, uppdaterad, lättillgänglig
och intressant.
2. Gå igenom länkar, strukturer, index mm så att den blir lättanvänd.
3. Bjud in trafikverksmedarbetare, systemleverantörer och användare att
bidra med information, nyheter, success stories etc.
4. Rensa bort gammalt material, eller lagra i tydligt markerade mappar
”Arkiv”.
5. Skapa specifika flikar som riktar sig direkt till kommuner, skogsnäring
och systemleverantörer med riktad information om nyheter,
dokumentation, releaser etc som direkt berör den enskilda gruppen.
Både vissa kommuner och skogsnäring har uttryckt att man saknar en
tydlig ”kommun-/skogsnäringsinformationsdel” som enkelt och tydligt
riktar sig till dem med anpassad och riktad information. Även
systemleverantörer har uttryckt liknande tankegångar.
3. Begränsat systemstöd i egna applikationerna
Långt ifrån alla dataleverantörer har ett avancerat systemstöd med
automatiska/ semiautomatiska överföringar till NVDB. Förutsättningarna
verkar skilja sig åt ganska mycket.
Lösningsförslag
Systemleverantörer, Trafikverket
Utveckla systemstöden så att de innehåller information och stöttning i
inmatningsformulär, valideringar på fältnivå, möjliga alternativ i rullgardinsval,
rimlighetskontroller, kontroller att värde är inmatat osv. Har man inte detta i
sitt eget system (t ex vägnätsredigerare med koppling till NVDB) så blir det
förstås svårare och fler fel.
4. (Skillnader på fokus och tidsperspektiv med vägredigeringsarbetet)
Dataleverantörerna har ofta en annan syn, ett annat fokus, med sitt
vägredigeringsarbete än vad Trafikverket har. Dataleverantörerna är i hög grad
inriktade på vägkartan som den ser ut just nu, hur vägar ligger och hur de
hänger ihop med omgivningen plus några för dem viktiga företeelser (delvis med
andra företeelser än NVDB vilket också försvårar inmatning av de för NVDB
relevanta företeelserna). De har konkreta aktuella kommunala/ skogliga
uppgifter som måsta lösas ”nu” medan Trafikverket som statlig myndighet med
NVDB har ett nationellt uppdrag över tiden och över alla kommungränser och
skogsbilvägar.
Ska vi lyckas samordna Trafikverkets och dataleverantörernas arbete med
uppdatering av NVDB så måste en bättre samsyn på NVDB:s syfte, uppbyggnad
och underhåll gemensamt definieras och ”erkännas”.
Lösningsförslag
Här gäller det att vara medveten om skillnaderna och diskutera ihop sig.
Trafikverket måste hela tiden informera om t ex vikten att tidsparametrar fylls i
korrekt även om det inte är något som den lokale dataleverantören jobbar med.
5. (Företeelser skiljer sig åt)
Synen på företeelser och attribut skiljer sig också åt. Dels så finns det ofta olika
företeelser för vägar och objekt mellan kommunala system och NVDB, dels så är
antalet relaterade företeelser ibland olika. Att företeelserna inte är identiska
mellan många dataleverantörers lokala system och NVDB försvårar förstås att
rapportera dessa korrekt. Detta sammantaget skapar problem för
sällananvändare att korrekt skapa underlag för vägnätsredigeringar i NVDB.
Lösningsförslag
Var medveten om skillnaderna. Här krävs gemensamma insatser. Någon typ av
överföringstabell/-dokumentation kan kanske tas fram? Minimikravet är
dokumentation över problemet och minimalt med ”dubbletter” i de olika
miljöerna.
6. Fler orsaker till kvalitetsproblem enl de intervjuade
I intervjuerna har många fler orsaker till kvalitetsproblem framkommit.
Samtliga dokumenterade kommentarer och intressanta synpunkter från
intervjuerna finns i kapitlet Intervjuer längre bak i Appendix. Kommentarerna
och synpunkterna är där indelade efter intervjufrågor (intervjuformulären) och
svarsgrupp (Trafikverket, dataleverantör el systemleverantör), men är f ö
anonyma. Nedan ser ni ett urval av alla dessa synpunkter.
1. Trafikverket bör ha som riktlinje att minst en gång/år träffa samtliga
kommuner. Går det inte med fysiska möten så fungerar live
meeting/telefon. (Trafikverket)
2. Någon typ av pedagogisk flödeskarta med länkar /pilar vid de olika
”indatastegen” till relevanta dokument, alltså en bild som visar
kopplingar mellan aktuella dokument och steg i indataflödet.
(Trafikverket)
3. Försök få igång ”Portvakten-funktionaliteten” och användningen av
denna. (Trafikverket)
4. Underlätta för kommunkontakterna genom att förse dem med
statusuppdateringar, och färdigprognos, var ”deras” ärenden befinner sig
i berednings-/produktionsledet. (Trafikverket)
5. Ett uppstyrt internt regelverk bör kunna styra upp en otydlighet som
finns mellan den interna logistikkedjan för indata. (Trafikverket)
6. Minst en dataleverantörskontakt per år då man stämmer av ordentligt.
(Trafikverket)
-----------------------------------------------------------------------------------7. Förslag: etablera ett tekniskt råd där systemleverantörer, och gärna
större skogsnäringsorganisationer, erbjuds plats. (Motsvarande
Kommunforum). (systlev)
8. Man har startat upp avstämningsmöten (2 st hittills) och dessa har varit
bra. Man hoppas mycket på framtida gott samarbete. (systlev)
9. Trafikverket har ända sedan NVDB:s tillkomst missat när det gäller
kommunernas behov och förutsättningar. Deras behov är inte
förankrade. (Systlev)
10. Motiveringen att kommunernas behov bevakas av SKL i Rådet håller inte
då SKL inte har full insyn i kommunernas dagliga arbete och behov kring
vägnätsunderhåll o redigering. (systlev)
11. Terminologin är ett bekymmer då det finns ett stort glapp mellan
dataleverantörernas vardag och Trafikverket. Detta glapp skapar en
tröskel hos dataleverantörerna för att jobba med regelbundna
vägnätsredigeringar till NVDB. (systlev)
-----------------------------------------------------------------------------------12. Kommunen vill få mer information om nya, eller utfasade, företeelser
där både Trafikverket, kommunrepresentanter och systemleverantörer
deltar. Idag händer det att företeelse-förändringar genomförs i NVDB
utan att kommunerna blir informerade. (datalev)
13. Ett enkelt forum där nyheter presenteras på ett pedagogiskt sätt
efterfrågas, t ex återkommande möten, handledningar el länkar till
websida med nyheter. (datalev)
14. Kommunen efterfrågar en utvecklad samling tjänster (standardfrågor,
listor, rapporter etc., jfr LMV:s nya tjänster), alt. stöd för egna frågor mot
NVDB-databasen (liknande SQL-frågor). Fördelen blir att slippa lagra
data lokalt och att de kan användas direkt från applikationer. (datalev)
15. Man skulle vilja få in s k traktorvägar, åtminstone som ett stödskikt i
tillämpningen. (datalev)
16. Kommunen vill få blanketter och stöd för företeelserapportering från
Trafikverket. Blanketterna ska dels användas av kommunen själv vid
inmatning av underlag, dels ska man kunna ge dem till entreprenörer för
att tydligt peka ut vilken information man behöver få av dessa för
vidareförmedling till NVDB. (datalev)
Appendix
Sammanställning intervjusvar
Frågor och svar - Trafikverksanställda/konsulter
Generella frågor om NVDB
Hur fungerar det idag och vilka är de viktigaste ev. förändringarna ni skulle vilja
se?
1a Generellt, vad fungerar bra med att lämna/hämta data till/från NVDB
idag?
(Vad behöver inte ändras, möjligen kopieras?)
Trafikverket
1
2
3
4
5
6
7
8
9
10
1b
Positivt för dataleverantörer att Trafikverket accepterar många olika
format/varianter av indata (3 st)
Trafikverkets system är ganska stabila. Det gäller hantering av formatet
nvd. Lämna/hämta med XML är nytt och inte lika stabilt.
Nya NVDB på Web 2012 känns bra!
Samarbetet med kommunerna fungerar i stort bra, ”ett gott
samarbetsklimat”.
Tycker att det generella tankesättet är rätt (2 st).
Statliga uppdateringar fungerar mycket bra.
Så länge Trafikverket/NVDB får in korrekta underlag i ”rätt” mängd så
går hanteringen snabbt o bra (2 st).
Slussen fungerar bra. Leverantören fick snabbt upp ett fungerande
system. Jobbar inte så mycket med utdata men tror att det fungerar väl.
Vi har ett fungerande flöde som rullar och går.
Fungerar tekniskt bra.
Generellt, vad fungerar mindre bra med att lämna/hämta data till/från
NVDB?
(Vad borde förändras?)
Trafikverket
1 Negativt för Trafikverket är de många olika formaten/varianter av indata
som accepteras och vidarebehandlas för slutlig lagring i NVDB. Detta tar
resurser att hantera (4 st).
2 Barnsjukdomar och mycket jobb kring systemen som levererar XMLfiler direkt in till Verkställaren. Även vissa problem med att hämta data
med XML. Sakta blir det dock bättre.
3 Det kan vara svårt att få kommunerna att leverera uppdateringar i tid
när någon väg etc har byggts/förändrats. Dessa eftersläpningar
genererar problem med fullständigheten i NVDB.
4 Nuvarande organisationen har något försvårat kontrollen för kommun/skogskontakter. De hamnar ibland på mellanhand då
dataleverantörerna har flera inrapporteringsmöjligheter varav några ”går
förbi” kontakten. Den tidigare organisationen med ”alla kontakter med
dataleverantörer”, inrapportering i Slussen och förändringsfil till LMV
som kontrollerade och importerade till NVDB var tydligare för gruppen.
5 Trafikverket får mindre och mindre resurser för kommunkontakter (idag
5 st på 290 kommuner)
6 Dataleverantörerna är alltför sena att skicka in underlag om pågående
vägarbeten vilket ger alltför långa ledtider.
7 De tekniska transaktionerna mellan lokala databaser och NVDB krånglar
regelbundet. Vid förändringar av datamodellerna så slutar det ofta att
fungera.
8 Ibland skickar dataleverantörerna in indata/uppdateringar till fel
maildress (2 st).
9 Kvaliteten på inrapporterat indatamaterial är ojämn.(3 st)
10 En leverantörs dispens att inte leverera företeelser tillsammans med
vägnät från sin produkt. Schablonvärden läggs på istället, oklart hur
mycket som granskas av dessa värden i efterhand. Detta skapar merjobb
och osäkerhet för Trafikverket
1c
Generellt, vilka är de största problemen idag i arbetet med att
lämna/hämta data till/från NVDB?
Trafikverket
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Det är alltför skiftande kvalitet på indatat. En hel del tar lång tid att
arbeta igenom till nödvändig form/kvalitet. (4 st)
För dataleverantörerna är det största problemet att många XML-filer
som checkas ut blir mycket stora och otympliga.
Det finns ibland skilda åsikter om hur underlagen ska tolkas mellan
framförallt Beredning och Indata/Produktion vilket stoppar upp flödet
När dataleverantörer skickar in stora uppdateringsvolymer så får
Trafikverket problem att hinna med.
Vissa dataleverantörer måste man påminna för att få in korrigeringar
Ett generellt problem är att få in underlag/ uppdateringar från
dataleverantörer så fort som vägnät har byggts ut el förändrats, inte
långt efter. (2 st)
Inmatning av data upplevs ibland som krångligt oavsett
inrapporteringssätt.
NVDB-arbete är ofta inte en prioriterad uppgift hos de små
kommunerna. Sällan förekommande uppdateringar kombinerat med
omfattande regelverk för indata gör det tungarbetat för dessa.
Alla olika system kombinerat med ojämn utbildning hos användarna
skapar ojämn indatakvalitet. 290 kommuner med skiftande bakgrund
och förutsättningar bidrar till kvalitetsskillnader.
Att få XML-in-/utdataleveranserna att fungera felfritt
Det är ett ganska omfattande merjobb som Trafikverket tar på sig för
att få allt att fungera, för att få in data.
”Manuella” sällananvändare har betydligt större behov av stöd och
hjälp
Dimensionen tid/historik saknas ofta hos dataleverantörerna och
skapar frågetecken.
Dokumentation och hantering av skogs- och enskilda vägar är luddigt,
oklart (trots det stora antalet mil väg av denna typ)
Intressanta enskilda synpunkter:
”Vi har fel fokus. Målsättningen borde vara att när en (fysisk) väg är
klar/förändrad så ska informationen om detta vara uppdaterat i NVDB.
Man skall t.ex. ej mäta ett ärendes ledtid i totala vägdatakedjan. Det som är
intressant är tiden från objektet är färdigbyggt till det är uppdaterat. Detta
är det som kunden har användning av.”
”Den höga komplexiteten i rapportering av vägnätsförändringar från lokala
system via förändringstransaktioner, vilket ofta dessutom sker ganska
sällan och i kombination med begränsat lokalt systemstöd, för många
dataleverantörer genererar mycket extraarbete både hos dataleverantörer
och hos Trafikverket. (Jfr t ex problem med tidsparameter).”
”Idag finns det en tröghet och otydlighet i samspelet mellan Trafikverket,
systemleverantörerna och dataleverantörerna. Dataleverantörer och
Trafikverket kan ha en egen dialog kring systemleveransfrågor som inte
systemleverantörerna deltar i. Om Trafikverket genomför en viktig
justering vars användning underlättas om det finns systemstöd så dröjer
det i alla fall tills systemleverantören får en formell beställning från
någon/några dataleverantörer om att bygga in denna förändring innan
denna uppgradering realiseras.”
”Det är lätt hänt att systemleverantörerna hamnar mitt mellan Trafikverket
och dataleverantörerna. Systemleverantörerna har också ett annat mer
finansiellt fokus kring NVDB än övriga två parter”
” Trafikverket har en svag förhandlingssits och måste acceptera ”ofärdigt”
indata för att ibland överhuvud taget få in svar från fattiga/inaktiva
dataleverantörer. Då måste Trafikverket göra delar av deras arbete för att få
in korrekt data och i korrekt form till NVDB, vilket förstås också belastar
resurserna.”
1d
Vilka är de viktigaste ev. förändringarna i arbetet med att lämna/hämta
data till/från NVDB som ni skulle vilja få till?
Trafikverket
1
2
3
4
5
6
7
8
9
10
11
12
13
Reducera de tillåtna/supportade formaten/varianterna på indata.
Trafikverket behöver styra upp tillåtna format för att bättre kunna
strömlinjeforma hanteringen och därmed spara resurser och ledtid.
Överväg möjligheterna att göra det enklare för dataleverantörer att
skicka in underlag så länge de är tolkningsbara. Mindre krav på syntax
och samband, mer fokus på förståelse av innehållet. Sen kan experter
på Trafikverket översätta till fungerande indata.
Det saknas kompletta instruktioner, ev mallar, med info om
(framförallt obligatoriska) företeelser. (2 st)
Om det fanns möjligheter att vid utcheckning välja mindre geografiska
områden för att få ned filstorlekarna skulle det underlätta för
dataleverantörerna.
Att få XML-in-/utdataleveranser att fungera felfritt.
Så många som möjligt borde börja rapportera in uppdateringar via
NVDB på Web 2012 istället för olika underlag via mail till olika
mailboxar.
Se över den interna organisationen. Problematiskt att alla led inte jämt
kommer överens kring hur och vad som ska göras.
Tycks som om Trafikverket lägger ut tekniska uppgifter och behåller
branschkunnandet. Bättre då att renodla ansvarskedjan till färre aktörer.
Viktigt dock att minst två personer tittar på indata innan import till
NVDB.
Stärk ytterligare samarbetet mellan de olika aktörerna då alla drar nytta
av det.
Information om nya regler och förändringar måste ut snabbt till
dataleverantörerna
Stötta kommunerna i deras försök att hitta rätt folk på NVDB-jobben
Stötta kommunerna att ge högre prioritet åt arbetet med NVDBuppdateringar/underhåll
Någon typ av användarprogram med utbyggt användarstöd och bra
gränssnitt. Försök utveckla geometrianvisningar t ex ”rita på karta” etc.
Lägg datakatalog i verktyget. Validera redan vid inmatning.
14 Ett arbete med att minska antalet obligatoriska företeelser vid indata
har redan gjorts och med positivt resultat! Det saknas dock kompletta
instruktioner, ev mall, med info om (framförallt obligatoriska)
företeelser.
15 Hur kan Trafikverket erbjuda olika inmatningsalternativ utan att
resursbehov och kostnader ökar?
16 Idealet är dataleverantörer som levererar indata som är klart för
verkställighet/import till NVDB. De som kör egna system kan ibland
klara delar (några få allt) av detta.
Intressanta enskilda synpunkter:
”Om inte dataleverantörerna kan förmås att mycket tidigare i sin fysiska
produktionsprocess självmant leverera indata till NVDB så bör
Trafikverket själv via aktiv insamling få in dessa uppdateringar parallellt
med att det fysiska jobbet genomförs, dvs inget slack mellan fysiskt
vägjobb och motsvarande uppdatering av NVDB.”
”Den röda tråden för att få bättre flyt i indata-logistikkedjan är kompetens
hos de som jobbar med detta.”
”En viktig källa till oenighet är den skilda synen på master och slav i
uppdateringsprocessen. Trafikverket ser NVDB som naturlig master
medan dataleverantörerna ofta tvärtom ser sina lokala system som master
som uppdaterar NVDB. För att synka ihop denna otydlighet så har idag en
av de lokala vägnätsredigerarna utrustats med en identisk datamodell som
NVDB ned på tidsversion. Detta skarpa krav orsakar problem på båda
sidor så fort en ändring ska införas.”
”En lösning på detta plan kan vara att istället för dagens dubbelriktade
”likvärdiga” information så inför man två enkelriktade flöden. En där
NVDB är master för sitt data och dataleverantörerna får hämta ned vad de
vill på NVDB:s villkor. På samma sätt finns det lokala mastrar där NVDB
får hämta sina uppdateringar som de vill. Med denna lösning blir ansvaret
annorlunda. Trafikverket som nationell myndighet tar fullt ansvar för
NVDB och dataleverantörerna (t ex kommuner) tar fullt ansvar för sina
lokala system.”
”Om möjligt ta fram ett enhetligt indatasystem, en NVDB-förvaltning och
ett (NVDB-)underhåll.
Förenkla och styr upp”.
1e
Vad fungerar riktigt bra i samarbetet mellan Trafikverket /NVDB,
kommuner/skogsnäring och systemleverantörer?
(Vad behöver inte ändras, möjligen kopieras?)
Trafikverket
1
När dataleverantörerna lämnar bra underlag i lagom stora portioner
(dvs inte samlar på sig uppdateringar under lång tid) så går det fort i
den följande behandlingen.
2 Trafikverket har mycket kontakt med en systemleverantör och det
fungerar bra, både formellt och informellt. Andra systemleverantörer är
lite mer ”tysta”.
3 Det är i grunden ett gott samarbete mellan aktörerna. (2 st)
4 Kommunikationen med systemleverantörerna har förbättrats på sistone.
6
7
8
9
10
1f
Tidigare hade Trafikverket dålig info kring de enskilda
dataleverantörernas systemstöd och uppgraderingar av produkter,
versioner etc. Numera mailar t ex en av systemleverantörerna till
Trafikverket alla nya systembeställningar från dataleverantörer. Detta är
viktig info för Trafikverket då systemstödet styr hur uppdateringar till
NVDB inlevereras (t ex tekniker vid in-/utcheckning).
De kommersiella, avtalsmässiga kontakterna mellan alla parter
fungerar utmärkt. Att få besked vid frågeställningar är inga problem
Det mesta fungera bra. Det är bara några få procent som behöver
mycket hjälp. Trafikverket har bytt kommunkontakter och detta har
inte helt satt sig ännu. Det samma sker på kommunernas sida.
Också skogsnäringen är aktiv och det är ett gott samarbete även där! De
är aktiva användare och skickar ibland synpunkter. Vi har bra kontakt
med skogen.
Trafikverket har varit mycket öppna i samarbetet med
systemleverantörerna. Parterna informerar varandra i förväg vid
kommande förändringar.
Kontakterna med skogsnäringen fungerar bra. De har en direkt
ekonomisk vinning av NVDB och är motiverade att satsa på det.
Vad är de viktigaste ev. förändringarna i samarbetet mellan Trafikverket
/NVDB, kommuner/skogsnäring och systemleverantörer?
Trafikverket
1
2
3
4
5
6
7
8
En förbättring kan skönjas i dataleverantörernas syn på ledtider och
vikten av att de snabbare rapporterar in genomförda vägarbeten. Det
går lite snabbare med inrapportering idag.
Trafikverket får rätta sig alltför mycket efter systemleverantörerna…
Man måste se över den sårbara överföringen av data mellan de
identiska datamodellerna. Det är alltför sårbart som det är idag.
Trafikverket bör ha som riktlinje att minst en gång/år träffa samtliga
kommuner. Går det inte med fysiska möten så fungerar live
meeting/telefon.
En lösning kan vara att Trafikverket tar kostnader för att uppgradera ev
systemstöd som uppkommer pga ändringar hos NVDB.
En annan lösning är att satsa ordentligt på en webapplikation som alla
dataleverantörer kan utnyttja.
Ett standardiserat arbetssätt bl a baserat på ett väl utbyggt systemstöd.
”Kommunforum” är nu uppstartat och ger ensamma kommuner stöd i
deras utveckling samt i kontakterna med systemleverantörerna.
Intressanta enskilda synpunkter:
”Man borde se över avtalsmodellen mellan Trafikverket/NVDB och
dataleverantörerna. Det kan vara så att LMV:s modell med betalning för
indata och avgift för utnyttjande, fungerar bättre för att få in uppdateringar
än NVDB:s ”gratismodell” som används idag.”
”Idag finns det en tröghet och otydlighet i samspelet mellan Trafikverket,
systemleverantörerna och dataleverantörerna. Dataleverantörer och
Trafikverket kan ha en egen dialog kring systemleveransfrågor som inte
systemleverantörerna deltar i. Om Trafikverket genomför en viktig
justering vars användning underlättas om det finns systemstöd så dröjer
det i alla fall tills systemleverantören får en formell beställning från
någon/några dataleverantörer om att bygga in denna förändring innan
denna uppgradering realiseras.”
”Det är lätt hänt att systemleverantörerna hamnar mitt mellan Trafikverket
och dataleverantörerna. Systemleverantörerna har också ett annat mer
finansiellt fokus kring NVDB än övriga två parter”
”En radikal men kanske föga trolig utveckling vore att Trafikverket endast
hanterar samarbete och frågor med dataleverantörerna.
Dataleverantörerna får sen ”sköta sig själva” i kontakterna med
systemleverantörerna.”
Dokumentation/utbildning/NVDB.se
2a
1. Hur fungerar NVDB-dokumentationen?
(För kommuner/skogsnäring och systemleverantörer (Trafikverket?))
(Täcker den behovet?)
2. Hur borde den ev förändras/kompletteras?
Trafikverket
1a Ganska bra men bör kompletteras med mer regler och information. Idag
använder datalev. mest NVDB-specifikationer och dessa är kortfattade
och lite ”magra”.
1b Det finns mycket information på NVDB.se, men lite oklart hur mycket
som används.
1c Fungerar i stort bra! Dokumentationen kring dataleveranser är dock
omfattande och ibland svår att överblicka. Det finns också luckor och
otydligheter i regelverket. Olika dokument överlappar ibland varandra.
1d Dokumenten kring specifikationer fungerar bra. Det har blivit utökat
med bättre förklaringar, speciellt kring företeelser. Detta är ett ständigt
pågående jobb med nya företeelser som tillkommer och några som fasas
ut.
1e Idag pågår ett arbete med att uppdatera en handledning som delvis är en
kopia av regelverket. Problemet är att när regelverket uppdateras så
hänger inte handledningen med, plus att handledningen blir väldigt stor!
1f. Problem med olika begrepp hos kommuner/skog och Trafikverket.
1f Det finns ett omfattande material som ibland kan vara krångligt att hitta
runt i , men området i sig är komplext och ganska omfattande. Det krävs
förkunskaper bland användarna. (2 st)
1g Kan förbättras. Är ibland svårt att hitta i – förtydliga!
1f Bra och tillgänglig för alla. Det är lätt att hitta startsidan, men ovana
besökare kan ibland missa att hitta viktiga bakomliggande sidor. (2 st)
1g Bra, ev finns alltför mycket? Om alla som jobbar med vägdata hade rätt
kompetens och följde specifikationerna så skulle det inte vara så stora
brister/problem.
1h Blir ibland lite ”mastigt”, tungt
1i Bra
2a Det finns en intern Trafikverks-handledning som innehåller mycket
matnyttigt som borde kunna föras vidare till dataleverantörerna.
2b Trafikverket skulle kunna behöva lite mer feed back från användarna.
Vi vet inte vad dom externa tycker om dokumentationen. Upplever
ibland att samma dokumentation finns på flera ställen. Finns nog
dokumentation internt som även externa kunde ha nytta av.
2c Förenkla genom att hjälpa nybörjare att hitta bland all dokumentation.
Skapa exempel på vilka, samt turordning, dokument man bör läsa.
NVDB är omfattande och det finns inga lätta genvägar.
2d Den nya DPS, Dataproduktspecifikationen, som är en sammanslagning
av den interna handledningen och ett nuvarande
specifikationsdokument kommer att spridas till kommuner och
skogsnäring. (2 st)
2e Skilj på handledning och regelverk då det inte är samma fokus för dessa
dokument. Många ser idag handledningen som en instruktion (och de
läser ej specifikationerna överhuvudtaget) vilken den inte är, samtidigt
som den inte är komplett! T ex är beskrivningar av samband inte
kompletta (vilket kan vara svårt att upptäcka).
2f. Vissa dataleverantörer vill ha enklare dokument.
2g Någon typ av pedagogisk flödeskarta med länkar /pilar vid de olika
”indatastegen” till relevanta dokument, alltså en bild som visar
kopplingar mellan aktuella dokument och steg i indataflödet.
2h Försök samla ihop dokumentationen.
2i Lägg till fler direktlänkar.
2j Det fungerar ganska bra och nytt material publiceras kontinuerligt.
2k Ett arbete pågår där Trafikverket kompletterar rena specifikationer
med data från handledningar. Den nya produkten kommer att få olika
beskrivningsnivåer så att användare enkelt kan hitta sin lämpliga
information. Den kommer att vara fylligare och innehålla något mindre
fackspråk.
2l Lathundar efterfrågas ofta. Att tänka på är att all dokumentation ska
passa för hela användargruppen, bl a ca 290 individuella kommuner,
som var och en har sina styrkor och svagheter.
Intressanta enskilda synpunkter:
”Idag utgår också handledningen från de enskilda företeelserna. Den
borde istället utgå från de aktuella ”uppdateringstyperna”, t ex ”ett vägnät
av typen X har följande möjliga/obligatoriska/ förbjudna företeelser”
varpå man utvecklar hur företeelserna ska hanteras just här. Obs,
dokumentet ska inte innehålla regler/ specifikationer då detta görs i
regelverksdokumentet. Dock kan en handledning ej vara en komplett
checklista och ersätta kompetens/kunskaper. Vilket många i dagsläget
tror.”
”Det finns önskemål om att lägga ut dataproduktkatalog med
specifikationer i aktuella webapplikationer så att felen minimeras redan
vid ”källan”. Även systemleverantörerna ska ha fått tillgång till aktuella
specifikationer så att de kan jobba in denna information i sina produkter.”
2b
1. Hur fungerar utbildningsmöjligheterna?
(För kommuner/skogsnäring och systemleverantörer (Trafikverket?))
(Täcker de behovet?)
2. Hur borde de ev. förändras/kompletteras?
Trafikverket
1a Det påbörjade utbildningspaketet på NVDB.se är bra men är inte färdigt,
behöver kompletteras! (4 st)
1b Bra för nybörjare, men hör inte så mycket. Lite feedback från
användarna skulle även här kanske peka ut områden att prioritera. (3 st)
1c Webutbildningarna är bra, alltid tillgängliga och går ju att köra var som
helst med internetuppkoppling.
1d. Räcker de till för behovet?
1e Det finns en tydlig koppling mellan bättre utbildning och mindre krångel
med indata så det är väl värt att satsa på.
1f Lite osäkert hur det fungerar för dataleverantörerna. Kurserna på
NVDB.se är bra, pedagogiska och med möjligheter att köra när man kan
och göra uppehåll när så behövs. Kurserna borde vara speciellt bra för
nybörjare! (2 st)
1g NVDB-skolan är bra. En leverantör får ta del av Trafikverkets
utbildningspaket och integrerar detta material i sina utbildningar kring
sin produkt.
2a Slutför utbildningspaketen på NVDB.se. (2)
2b (En systemleverantör använder redan idag trafikverksmaterial i sina
utbildningar.)
2c Ställ krav på dataleverantörer som använder inkrementell uppdatering
att de går definierade kurser. (2 st)
2d Den bästa utbildningen är att ha kompetenta kollegor bredvid sig som
man kan fråga när man kör fast.
2e Ställ krav på att användarna går en miniminivå av definierade kurser.
2f Vidareutveckla och lägg resurser på detta!
2g Utöka kursmöjligheterna. Lägg ut mer instruktionsfiler via NVDB.se.
Trafikverket/NVDB måste bredda sig.
2h Det finns önskemål om möjligheter att sortera nyheter efter användare.
Kanske att kontakter behöver uppdateras oftare(?).
2g En önskad utbildning om cykelvägnät ska ljudsättas, sen är den också
klar.
Intressanta enskilda synpunkter:
”Vissa saker är bra, men är inte nöjd med helheten och vissa utbildningar
saknas. Det gör att Trafikverket måste kompensera för saknad kompetens
hos dataleverantörerna med egna resurser som hjälper till att få allt att
fungera.”
”Det pågår ett kontinuerligt arbete med att utveckla websiten samt att
informera om den. Trafikverket har tagit till sig synpunkter från
användare.”
2c
1. Hur fungerar NVDB.se i stort?
(för kommuner/skogsnäring och systemleverantörer (Trafikverket?))
(Täcker den behovet av dokumentation, information utbildning osv?
Volym/innehåll/frekvens)
2. Hur borde den ev. förändras/kompletteras?
Trafikverket
1a. Är bra men skulle kunna användas mycket mer. (2 st)
1b. Det kan vara svårt att hitta regler, information, specifikationer mm för
indataleverantörer och ajourhållare. Det finns dokument på NVDB.se
som känns tveksamma, irrelevanta.
1c. Funkar hyfsat som nav för kommunikation, utbildning och
dokumentation.
1d I stort fungerar det bra. (2 st)
1e Bra men lite ”statisk”.
2a. Uppdatera informationen och arbeta bort påtalade brister. Ta bort
gamla nyheter och gammal info. (3 st)
2b. Önskemål om sammanfattning och riktlinjer för hur en användare bör
närma sig detta stora NVDB-material (se motsvarande önskemål om
NVDB-dokumentationen).
2c. Borde vara lite mer levande och omfattande. Idag är det många som
endast hämtar information om specifikationer samt utnyttjar de länkar
som finns på websiten. (2 st)
2d. Vissa kommuner har uttryckt att man saknar en tydlig
”kommuninformationsdel” som enkelt och tydligt med anpassad och
riktad information vänder sig till kommuner.
2e. Strukturera upp siten, lägg till länkar och flikar. (2 st)
2f Den behöver bli mer levande, innehålla mer nyheter och aktuell
information. T ex kan kommande stora händelser informeras om i
förhand via NVDB.se, osv. (2 st)
Intressanta enskilda synpunkter:
”Den behöver moderniseras och vitaliseras, bli mer levande. Vi vill ha den
som ett nav för information, dokumentation, länkar och utbildning.”
” Borde vara lite mer levande och omfattande. Idag är det många som
endast hämtar information om specifikationer samt utnyttjar de länkar som
finns på websiten.
”Höj statusen på websiten!”
Applikations-/systemstöd och arbetet med in-/utdata och NVDB?
Avser applikationerna
- ”NVDB:s webapplikation för hämta filer”
(in-/utcheckning),
- ”NVDB:s webtjänst”
(genererar dygnsuppdaterade filer fr FTP-server),
- ”NVDB på web” (karta på web,
rapportera fel/saknad info, nuvarande version)
3a Vilka är de största ev. generella problemen idag med NVDB:s applikations/systemstöd?
(i samband med att lämna/hämta data till/från NVDB)
Trafikverket
1 Överföringen av XML-filer.
2 Det finns många olika indatavägar med snarlika namn som för en ovan
indataleverantör är förvirrande.
3 Teknikfrågor, indatakvalitet, kompetens
4 De många tillåtna indatametoderna innebär att ledtiderna för att checka
in data ökar och blir dyra att hantera för Trafikverket.
5 Det mesta fungerar bra. Problemet är snarare de externa systemen
6 Verkar fungera ganska bra, har inte fått någon negativ feed back. Stora
valmöjligheter och stöd av kommunkontakterna gör att
dataleverantörerna fungerar bra
7 Det mesta fungerar ganska bra. Nuvarande version av NVDB på web är
ganska långsam, men den nya 2012-versionen som är på väg in känns
betydligt piggare
8 De äldre anvisningarna var väldigt tekniska och ibland svårlästa. Nu
finns en uppdaterad enklare handledning att tillgå
9 Problemet i NVDB:s webapplikation med att utcheckade XML-filer ofta
blir väldigt stora och otympliga samt dess ”krockproblematik” när två
användare har checkat ut samma område och båda har lokalt gjort
anpassningar.
3b
Vilka är de viktigaste ev. generella förändringarna med NVDB:s
applikations-/systemstöd som ni skulle vilja få till?
(i samband med att lämna/hämta data till/från NVDB)
Trafikverket
1 Tydligare namnsättning.
2 För att öka inflödet/snabba upp uppdateringar, borde Trafikverket
tillåta viss förenkling av inmatning vägnätet via webgränssnitt så länge
man får in korrekt information om vägnätet uttryckt i geometri,
kopplingar mm, plus de allra viktigaste företeelserna (väghållare,
fråndatum mm).
3 Öppna upp för direkt inmatning I NVDB av ”ofarliga företeelser” via en
ordnad rapportering för dataleverantörer med rätt rättigheter.
4 Det har hänt att fel koordinatsystem har använts jämfört med vad
dataleverantören efterfrågar, men då är det oftast någon
informationsmiss om byte.
5 Omfördela ansvaret så att dataleverantörerna tar huvudansvar för
datainnehåll och Trafikverket ansvarar för inmatningsinterface, syntax,
lagring. Visst tolkningsansvar måste ligga kvar på Trafikverket.
6 Enklare handledningar.
Intressanta enskilda synpunkter:
”Vill gärna se någon typ av ”Indata hub” som samlar alla ingångar för
inmatning av underlag och uppdateringar i en portal/hub. Här kan NVDB
på web vara en potentiell plattform att bygga vidare på. Att utnyttja
webformulär på en website är tilltalande med tanke på tillgänglighet,
enkelt underhåll samt möjligheter att skapa standardiserade gränssnitt
med systemstöd till nytta för ovana användare (rullgardinsval, direkt
validering/ styrning på fältnivå, rimlighetskontroller mm, till stora delar
baserat på NVDB:s datakatalog). Andemeningen är att låta
dataleverantörerna ta ansvar för datainnehållet och Trafikverket /NVDB ta
ansvar för interface och syntaxkrav.”
3c
1. Hur mycket används ”NVDB:s webapplikation” för hämta nvd-/XMLfiler?
2. Hur väl fungerar ”NVDB:s webapplikation”?
3. Hur borde den ev förändras?
Trafikverket
1a Oklart om volymerna
2a Fungerar bra (Används för initiala utcheckningar i XML-format samt
för ut/incheckning av nvd-format). (4 st)
2b Utcheckade XML-filer blir ofta stora och otympliga. För att motverka
detta kan man stycka upp filerna, men det ger lite extrajobb. (3 st)
2c Fungerar bra för den vane/invigde användaren men är ”oklar” för
sällananvändare. (2 st)
2d Upplever inte att det är några större problem mer än visst stöd lite då
och då. Skapar nollfiler (tomma) ibland när någon checkar ut vägnät
och företeelser men det är inget stort problem.
2e När ett jobb checkas ut via en av vägnätsredigerarna så låses systemet
för andra användare för incheckning. Om inte denna låsning går att
programmera bort borde man styra utcheckningar till nattetid (går att
manuellt sätta starttider).
2f Bra användarfunktioner.
2g Hör inte så mycket om den, ett gott tecken? Tidigare fanns tekniska
problem men nu verkar applikationen stabilare.
2h Utcheckade XML-filer tenderar att bli väldigt stora och otympliga. (2 st)
2g Krockproblematik finns när två användare har checkat ut samma
område och båda har lokalt gjort anpassningar.
3a Utöka selekteringsmöjligheterna för att kunna variera filstorlekarna. (2
st)
3b ”Portvaktenfunktionalitet” finns men används inte (tekniska problem
hos lokal vägnätsredigerare) vilket medför att fel upptäcks först hos
Verkställaren.
3c En tung körning kan låsa en lina vilket ställer till problem för
produktionen som då inte kan checka in uppdateringar.
3d En lokal vägnätsredigerare kan inte rapportera in företeelser vilka
därför måste komma en annan väg.
3e Problem med kartverktyg och samtidiga lokala uppdateringar. Om två
dataleverantörer checkar ut samma avsnitt ovetandes om varandra,
uppdaterar respektive kopia lokalt så kommer nr två som checkar in
inte att få in sina uppdateringar, det tar stopp. (2 st)
3f Sällananvändare måste läsa på hur det fungerar.
Intressanta enskilda synpunkter:
”Idag kan trafikverksmedarbetare manuellt stämma av ev (inchecknings-)
krockar genom att studera NDBV:s ärendelogg, men denna möjlighet har
inte kommuner som checkar ut/in geografiska områden. Detta problem
kommer förmodligen att växa i takt med att fler dataleverantörer jobbar
med denna applikation.”
3d
1. Hur ofta tankar kommuner/skogsnäringen ned filer från ”NVDB:s
webtjänst”?
2. Hur väl fungerar ”NVDB:s webtjänst”?
3. Hur borde den ev förändras?
Trafikverket
1a. En systemleverantör har anpassat sin produkt till NVDB:s webtjänst
men de har inte implementerat ’Portvakten’ vilket vore önskvärt.
1b Verkar fungera väl. En smidig lösning.
1c Tror att den används en hel del.
1d Även här hörs väldigt lite vilket är positivt(?)
1e Ingen direkt erfarenhet av funktionen men tror att den fungerar bra.
1f Ett 40-tal kommuner kör applikationen regelbundet.
2a Bra
3a Kl 17:30 drar 41 jobb igång och slöar ned systemet vilket påverkar
andra användare. Senarelägg batchkörningarna.
Intressanta enskilda synpunkter:
”NVDB:s webtjänst används inte för att ’tanka hem filer’. Den används för
att bygga in övrig funktionalitet i NVDB:s webbapplikation i externt
system.”
3e
1. Hur mycket används ”NVDB på web”?
2. Hur väl fungerar ”NVDB på web”?
3. Hur borde den ev förändras?
(ev. funktioner läggas till/ändras i ver 2012)
1
Trafikverket
Vi uppskattar att det finns ett trettiotal användare (?) av vers. 2012.
2a Den nuvarande NVDB på Web är långsam och fungerar inte riktigt fullt
ut. Dåligt användargränssnitt.
2b Nya versionen NVDB på web 2012 ska driftsättas snart. Den fungerar
mycket bättre än nuvarande, även om den äldre varianten också gör sitt
jobb. Snabbare, mer användarvänlig och mer systemstöd. (8 st)
2c Man saknar även viss bakgrundsinfo som t ex ortofoto. Den är
ursprungligen gjord för delvis andra syften och har sedan anpassats till
sitt nuvarande syfte.
2d När det gäller vers 2012 så är reaktionerna mestadels positiva, bra.
Ännu är inte all info med då man har fokuserat mot skog och
kommuner. Trafikföreskrifter t ex kommer senare. Den fyller sitt syfte
och kommer att kunna nå en bredare publik!
2e Använd NVDB på web som ev. bas för en portal/hub för all inmatning.
Här kan man samla allt från stöd för manuell inmatning av underlag,
stöd för skapande av korrekta inmatningsfiler till inkoppling av lokala
vägredigeringssystem och ”färdig” filöverföringar med inkrementella
uppdateringar
2f Nuvarande (”äldre”) versionen fungerar bra och löser sina uppgifter,
men är lite långsam
3a Utveckla så att samtliga företeelser kan hanteras (gäller också vers.
2012).
3b Fortsätt att utveckla funktionalitet och stöd. (3 st)
3c (Vers 2012 är strippad och därmed lite snabbare).
Intressanta enskilda synpunkter:
”Det enkla förfarandet vid uppdateringar med version 2012 har dock fått
till följd att det som förut administrativt var ett ändringsärende
innehållande 20 aktiviteter/poster, ibland idag kommer som 20 enskilda
ärenden vilket är svårt att administrativt hålla samman. Här krävs ev lite
användarutbildning.”
Inmatning av geometri, topologi, tid mm
Många inom kommuner/skogsnäring upplever det svårt att generera korrekta
underlag för inmatning i NVDB. Håller du med? Ev. förslag på förändringar?
4a Vilka är de största ev. generella problemen ni ser idag med generering av
underlag avseende
1. geometri
2. topologi
3. företeelsetyper?
Trafikverket
1 – 3a. Stämmer att det är svårt att skapa korrekta underlag, speciellt för
inaktiva dataleverantörer. (9 st)
b Kommunerna har också ofta fokus på ”karta i nutid” och inte
”datalagring kring vägar/geometri över tiden”. (2 st)
c Många kommuner är lite motsträviga, trots avtal, och kanske bör styras
d
e
f
g
h
i
j
k
upp hårdare. Undermåliga underlag genererar mycket extrajobb för
Beredning och Produktion
Dessutom är det nog så att det brister i kunskapen om hur man
registrerar framförallt geometrier.
Typiska fel är avsaknad av höjder och hantering av tid. Det datum som
förändringen/vägbygget är klart skall alltid rapporteras.
För företeelser gäller att de är så många att det är svårt att greppa alla.
Dessutom tillkommer kontinuerligt fler nya än vad som fasas ut. Detta
leder till en väldigt om fattande informationsmängd.
Mindre dataleverantörer har det tungt när det går alltför lång tid
emellan uppdateringar.
Hittills har inte Trafikverket krävt att allt är perfekt, tvärtom hjälper
Trafikverket ofta till med att få igenom filerna. Trafikverket”utbildar”
kundkontakterna kontinuerligt
För topologi så ser man ibland felaktiga generaliseringar vilket beror på
kompetensbrist.
Det finns nog inget system som hjälper hela vägen. Framförallt är det
olika komplexa samband som det är svårt att hitta systemstöd för.
Geometri och topologi är normalt lite ”farligare”, företeelser oftast lite
enklare.
Ibland problem med osynkade format mellan NVDB och de lokala
kommunala systemen
Intressanta enskilda synpunkter:
”Kanske Trafikverket måste acceptera att inaktiva användare får jobba med
uppdateringar via enklare underlag, och att Beredningen hos Trafikverket
styr upp, kompletterar och kontrollerar innan produktion och
verkställning? En balansgång – alltför hårda regler medför förmodligen
mindre inlämnade uppdateringar.”
”Ser egentligen ingen lösning på detta. Små kommuner kommer alltid ha
det jobbigt att skapa korrekta underlag om de inte jobbar kontinuerligt
med detta. De kommer nog även i fortsättningen att vilja leverera
underlag. NVDB2012 är ett steg i rätt riktning.”
”Vänta på exakt och komplett indata eller få in topologi och komplettera
med schablonvärden är en svår fråga.”
4b
Vilka är de viktigaste ev. generella förändringarna av arbetet med
inmatning av
1. geometri
2. topologi
3. företeelsetyper?
Trafikverket
1-3a Styr upp reglerna och rutinerna kring indataleveranser.
b En lösning för små dataleverantörer är att dela på resurser. T ex kan
mindre grannkommuner dela på en trafikingenjör som då får jobba mer
med NVDB och på så vis kan höja kompetensen. (2 st)
c Hyr in en konsult vid de få tillfällen per år som ny/uppdaterad data ska
in.
d Släpp intentionerna på att indata ska vara komplett och rätt kopplat
enligt alla olika sambandskrav och regelverk. Erbjud istället inaktiva
kunder tillgång till utbildade experter på Trafikverket som via info från
dataleverantörerna snabbt och korrekt kopplar ihop indatat. Sedan
skickas det strukturerade underlaget vidare för import i NVDB.
e Fokusera på att få in info så snabbt som möjligt från dataleverantörerna
när någon vägförändring har skett, inte månader el år efter bygget!
f Satsa på att bygga ut vägnätshanteringen i vers 2012.
Företeelsehanteringen fungerar idag. Man borde kunna enkelt koppla
ihop nyritad väg (i Trafikverkets ”frihandssystem”) med nödvändiga
företeelser.
g Nytt verktyg med enklare gränssnitt och ordentligt systemstöd.
h Stötta datalev. i deras försök att utvecklas och förbättra sig.
Intressanta enskilda synpunkter:
”LMV har ett gott fungerande samarbete med dataleverantörerna. Här
borde finnas öppningar för ett ökat samarbete mellan NVDB/Trafikverket
och LMV. Skulle NVDB kunna utnyttja också LMV:s data, åtminstone i fall
där NVDB inte får in information (i tid)? Framförallt skulle LMV:s
fotobaserade vägnät, geometrin, kunna importeras till NVDB där detta
saknas. Här kan NVDB t ex snabbt få in information om bil-, cykel- och
gångvägar!”
”Hittills har inte Trafikverket krävt att allt är perfekt, tvärtom hjälper
Trafikverket ofta till med att få igenom filerna. Trafikverket” utbildar”
också kundkontakterna kontinuerligt.”
”Det finns två huvudalternativ att lösa detta:
a. Ha en utvecklad beredningstjänst som på Trafikverket översätter
manuella/”enklare” underlag till hanterbar korrekt indata till NVDB
b. Utveckla verktyg som ute hos slutanvändarna effektivt stöder dem i
arbetet med indata till NVDB. Det borde gå att utveckla systemstöd
också för de viktigaste sambanden.”
”Stora delar av skogsnäringen har idag strukturerade shapeleveranser och
levererar direkt till Registrering utan att behöva gå via Beredning.”
Leverans av ny indata/uppdateringar via underlag
Fortfarande lämnar en majoritet av kommuner/skogsnäring in uppdateringar av
vägnät och företeelser i form av underlag, dvs. utan eget systemstöd.
5a 1. Vilka är de största generella problemen med denna typ av inmatning av
indata?
2. För uppdateringar/ny data till NVDB om vägnät via underlag?
3. För uppdateringar/ny data till NVDB om företeelser via underlag?
Trafikverket
1a Ofullständig och bristande kvalitet beror på att Trafikverket inte har
specificerat hur man vill att leveranserna ska se ut. I och med det måste
Trafikverket hantera en mängd olika typer av underlag (3 st)
1b Ojämna indatavolymer över tiden skapar svårhanterliga volymtoppar
hos Trafikverket/NVDB. (2 st)
1c Många små kommuner saknar egen hantering av sina vägdata (de
beställer underlag fr anlitade konsulter t ex LM/Metria) Viktigt då är att
de vet/kan beskriva vilket underlag de ska beställa.
1d Det är inte uppstyrt hur en leverans från en kommun till vår beredning
ska se ut. De kan skicka vad som helst. Blir mycket jobb för
beredningen att reda ut hur det skall vara. (2 st)
1e De verktyg som används i beredningen skapar inte alltid ett underlag
som passar som input till registreringen.
1f Verkar också saknas bra regelverk/dokumentation för beredarna. Blir
väldigt många returer från registreringen. Saknas det kompetens eller
är deras systemstöd inte bra?? Det pratas också om att det bereds
onödigt mycket.
1g Våra verktyg för registrering används inte alltid på mest effektiva sätt.
1h Vi har även ett internt snitt mellan Beredning och Produktion där det
ibland fastnar ärenden och skapas returer
1i Vissa företeelser är mindre allvarliga om de saknas än t ex geometrier
varför ibland schablonvärden tillfälligt fylls i (tittar på omgivning och
gissar kvalificerat).
1j Trafikverket kräver inte att allt är digitalt. Man kommer långt bara
underlagen är kompletta och korrekta.
1k Ett problem är förekomsten i NVDB av vissa företeelser som inte
används ute hos dataleverantörerna och därför ibland ”tappas bort” i
uppdateringarna. Dessa skulle kunna ligga som systemstöd i en
portal/hub. (2 st)
1l Den ojämna indatakvaliteten är det största problemet. Det genererar
längre ledtider pga återkommande frågor/svar (3 st).
1m Den sena inrapporteringen av vägnätsförändringar är problematisk.
1n Det fungerar ganska bra. Viktigt att underlagen är kompletta. De
kommuner som fortfarande levererar uppdateringar via underlag gör
det med god kvalitet. F ö är kommunkontakten ofta tillgänglig för
telefonsamtal
1o All beredning av indata via underlag är resurskrävande för Trafikverket.
Detta ett avancerat jobb där det tar lång tid innan nya resurser blir
varma i kläderna och effektiva (ibland upp till 4 år innan de är riktigt
vassa och erfarna).
1p Enskilda vägar och skogsbilvägnätet har oklart regelverk med otydliga
definitioner och regler.
2-3a Är nog ingen större skillnad vad gäller vägnät och företeelser.
b Vissa företeelser är mindre allvarliga om de saknas än t ex geometrier
varför ibland schablonvärden tillfälligt fylls i (tittar på omgivning och
gissar kvalificerat).
c Det är ofta återkommande problem med höjdvärden och
tidsparametrar. Tidsparametrar avser här datum då vägen har öppnat
för trafik, s.k. ÖFT-datum. Denna uppgift saknas ofta i leveransen.
d Att små kommuner saknar egen hantering av sina vägdata (de beställer
underlag fr anlitade konsulter) Viktigt att de då vet/kan beskriva vilket
underlag de ska beställa.
Intressanta enskilda synpunkter:
”Balansgång mellan att ställa frågor om indata och riskera långa ledtider,
eller lägga in kvalificerade schablonvärden och påtala behovet av kontroll
av inmatat data i NVDB, men riskera att kontrollen inte görs.”
”Även systemstödet bör utvecklas, t ex en utvecklad NVDB på web med
avancerat användarstöd. Detta skulle spara mycket på beredningssidan.”
”Värt att notera är att skogsnäreringen fungerar väl. De kan ofta via ett
webverktyg för skog leverera shapefiler med god kvalitet direkt till
Registrering.”
5b
1. Vilka är de viktigaste ev. generella förändringarna ni skulle vilja få till
med denna typ av inmatning av indata?
2. För uppdateringar/ny data till NVDB om vägnät via underlag?
3. För uppdateringar/ny data till NVDB om företeelser via underlag?
Trafikverket
1a Trafikverket måste specificera bättre vad som krävs av inleveranserna
till NVDB. (4 st)
1b Ta fram belysande exempel.
1c Ta fram mer handledning, fler textmallar och utnyttja NVDB.se.
1d Föreskrifter måste efterlevas bättre, t ex har man svårt att synka dels
vägnätsleveransen från stadsbyggnad dels företeelserna från gatusidan.
(2 st)
1e Stöd utveckling av systemstöd med direkt validering på fältnivå redan
vid inmatning.
1f Prova att införa NVDB på webb 2012 för att se vad det kan ge.
Arbetssätt: Ta bort onödig beredning, i vissa ärenden tillför inte
beredningen något förädlingsvärde i kedjan, dvs. lika lätt att registera
utan beredning, bara kontroll att alla rådata finns med är det som
behövs. Fördelen är sparade skattemedel, utan för den skull sämre
kvalité.
1g Se över beredarnas regelverk, dokumentation och systemstöd.
1h Verktygen för registrering kan nog användas effektivare.
2-3a Det är alltför ofta återkommande problem med höjdvärden och
tidsparametrar. Tidsparametrar avser här datum då vägen har öppnat
för trafik, s.k. ÖFT-datum. Denna uppgift saknas ofta i leveransen
b Stöd utveckling av systemstöd med direkt validering på fältnivå redan
vid inmatning.
c NVDB på Web 2012 kommer förhoppningsvis att ge en snabbare
uppdatering.
Intressanta enskilda synpunkter:
”Jobba för att dataleverantörerna skickar med korrekta företeelser som
”fritext i mail” hellre än inget alls om de inte kan digitalisera dessa.
Produktion/Verkställaren lägger där det går in schablonvärden om det
saknas indata. Samtidigt är det oklart hur många dataleverantörer som
verkligen går tillbaka och kontrollerar/rättar upp nyinlagt (schablon-) data
i NVDB. Detta enkla förfarande används ofta av skogsnäringen och det
fungerar bra.”
” Om en dataleverantör är så liten att man inte har något bra digitalt
systemstöd/verksamhet med påföljande begränsade nytta av NVDB kan
man i stället rikta sig mot de kommunsamarbeten (cluster) som ofta
förekommer, t.ex. länskartesamarbeten etc.”
”Fler dataleverantörer som är lika avancerade som skogen, dvs kan
leverera filer av god kvalitet ända till Registrering utan att behöva gå via
Beredning.”
Leverans av ny indata/uppdateringar via eget system
(Tekis LV-systemet, ESRI Geosecma, Triona TNE)
6a 1. Vilka är de största generella problemen med denna typ av inmatning av
indata?
2. För uppdateringar/ny data till NVDB om vägnät via systemstöd?
3. För uppdateringar/ny data till NVDB om företeelser via systemstöd?
Trafikverket
1a Att systemstöd för inmatning av företeelser saknas hos flera
vägnätsredigerare. Något system kan inte leverera varken vägnät eller
företeelser. (2 st)
1a Trafikverket kompletterar med schablonvärden på vissa företeelser som
saknas varpå detta importeras till skarp NVDB. Kommunerna måste
sedan remissläsa och ev rätta upp. (3 st)
1b Att en alltför stor andel av XML-filerna returneras (50 – 60 %) vilket
skapar längre ledtider.
1c Att flera kommunsystem inte har implementerat portvakten. (2 st)
1d De identiska datamodellerna hos vissa kommuners vägnätsredigerare
och NVDB skapar ofta tekniska problem.
1e Bristande kvalitet på indatafiler vilket leder till handpåläggning
(”hörsägen”)
1f Trafikverket har en aktiv dialog med en leverantör och ett ok
samarbete. Har haft problem med inleveranser från deras produkt. En
annan leverantör ung som o n. Har varit ”osynliga” ett tag men tycks nu
vara på väg tillbaka. Den tredje verkar satsa mer på skogssidan idag.
Den tekniska plattformen är idag ganska komplicerad och större
anpassningar av produkter där är sannolikt dyra.
1g Det finns både bra och dåliga användare av denna metod. Endast ett
system kan automatiskt inleverera både vägnät och företeelser. Ett
annat system måste komplettera automatinrapporterade vägnät med
underlag för företeelserna vilket ger merarbete. Det tredje systemet har
ev en ny produkt på gång som kan inrapportera både vägnät och
företeelser automatiskt.
Intressanta enskilda synpunkter:
”I förlängningen vill vi se system som kan leverera både geometrier och
företeelser digitalt (så långt in i NVDB:s logistikkedja som möjligt, helst till
Verkställaren). Detta kräver dock att handläggaren som använder systemet
har rätt/hög kompetens annars går felaktigheter automatiskt in i NVDB.”
6b
1. Vilka är de viktigaste ev. generella förändringarna ni skulle vilja få till
med denna typ av inmatning av indata?
2. För uppdateringar/ny data till NVDB om vägnät via systemstöd?
3. För uppdateringar/ny data till NVDB om företeelser via systemstöd?
Trafikverket
1a Komplettera med systemstöd för företeelseindata. (3 st)
1b Styr upp XML-filerna in till NVDB.
1c Försök få igång ”Portvakten-funktionaliteten” och användningen av
denna. (2 st)
1d Det finns en handledning innehållande olika varningar. Ju tidigare fel
upptäcks, desto mindre kostnader och kortare ledtider.
1e Eftersom de bara kan leverera vägnätet vore det bättre att de skickade
både vägnät och företeelser till oss istället (som underlag).
1f Om möjligt borde man utveckla NVDB 2012 och efter avklarade
kontroller få filerna att med automatik gå direkt till Slussen
2 (Ibland har vägnätsredigerarna lite bättre kunskap och systemstöd som
de har fått via sina systemleverantörer)
3 Att kommunerna försöker påverka systemleverantörerna att
komplettera sina produkter med stöd för företeelser.
Ledtiderna från leverans av kommuner/skogsnäring tills inlagt i
NVDB
7a
Hur upplever ni att ledtiderna är för inleveranser från
kommuner/skogsnäring fram tills att data ligger i NVDB?
Trafikverket
1 Vid mindre basleveranser så fungerar det bra. (4 st)
2 Vid större leveranser, vid specialleveranser eller vid teknikproblem så
tar det ibland lång tid. (5 st)
3 Vi uppfyller inte ledtiderna när det gäller XML-filer från kommunerna.
Detta skulle förkortas om man styrde upp XML-filerna, införde
Portvakten och delade ut handledning med instruktioner och varningar.
4 En viss prioritering av basärenden har varit fallet vilket fått
specialärendena att dra ut på tiden.
5 Det ojämna inflödet är också en försvårande faktor. En del kommuner
samlar ihop senaste ”halvårets” uppdateringar och skickar iväg i en
klump. Då blir det svårt för Trafikverket att hålla jämna steg. (3 st)
6 När det gäller ”externa” ledtider så beror dessa oftast på
- ojämn kompetens ute hos dataleverantörerna
- delvis annat fokus kring vägdata ute på kommunerna jämfört med
Trafikverket
- avsaknad klausuler om inmatning data till NVDB (ofta äldre statliga)
vägarbetsupphandling
7 De ”interna” ledtiderna beror oftast på olika tolkningar av
specifikationer mm vilket orsakar diskussioner.
8 En variant som ger långa ledtider är kommunerna som använder LMV:s
ortofoton som underlag. Dessa foton har själva i regel 1 – 2 års ledtid
vilket medför att redan när dataleverantören börjar arbeta med
uppdateringsdata så är man kraftigt försenad jämfört med det fysiskt
utförda arbetet.
9 Det verkar vara lite resursbrist i berednings- och produktionsleden hos
Trafikverket?
10 Framförallt är det sen inrapportering från vägprojekt o liknande.
Trafikverket måste ofta jaga in information. (2 st))
11 Dataleverantörerna har andra fokus än Trafikverket.
12 När det gäller interna ledtider så har ibland Trafikverket/NVDB:s
många logistiksteg orsakat fördröjningar .( Ärenden har blivit liggande i
fångst/beredning)
13 De olika interna produktionsstegen har olika huvudmän vilket försvårar
kommunikation och samordning.
14 Vissa dataleverantörer har dålig kontroll på kvaliteten vilket medför
längre ledtider pga dialog kring frågor och svar.
Intressanta enskilda synpunkter:
”Viktiga förändringar går dock oftast snabbt att få in i NVDB! Beträffande
de interna ledtiderna så jobbar man med detta.”
”Fullständiga leveranser går ganska snabbt, ofullständiga tar förstås längre
tid. Det finns ca 290 kommuner med mycket skiftande förutsättningar så
det är inte helt lätt att standardisera överallt. Detta i kombination med
ojämn indatavolym gör det svårt att alltid ha balans mellan resurser och
uppgifter.”
7b
1. Vad kan göras av Trafikverket/NVDB för att om möjligt korta
ledtiderna?
2. Vad kan göras av kommuner/skogsnäring för att om möjligt korta
ledtiderna?
3. Kan systemleverantörerna göra något?
Trafikverket
1a Kartlägg acceptabla ledtider och anpassa resurserna därefter. (4 st)
1b Förenkla arbetsgången och arbeta för att få in bättre underlag. (2 st)
1c Ställ krav på systemleverantörerna att stödja även inmatning av
företeelser.
1d Styr upp indatakraven mot dataleverantörerna.
1e Bättre underlag, utbildning och regelverk (2 st)
1f Implementera Portvakten. Utbilda sig. Se till att dom får ett bra system
så att dom kan göra rätt och kontrollera sin fil innan leverans.
1g Stötta dataleverantörerna så att de får utbildning samt bättre lokala
systemstöd
1h Kräv kontinuerliga överföringar av uppdateringar, inte enskilda
”batchöverföringar”.
1i Trafikverket/NVDB:s många produktionssteg orsakat emellanåt
fördröjningar. En bidragande orsak till detta kan vara att de olika
stegen har (haft?) olika huvudmän. (2 st)
1j Gå över till en huvudperson för samtliga logistiksteg från
datamottagning av indata till incheckning. Då går det snabbare att flytta
resurser mellan t ex Produktion och Beredning om det är vid Beredning
det uppstår köer osv.
1k Försök minska antalet steg i logistikkedjan. Allt behöver nog inte
beredas i separat GIS-miljö?
1l Underlätta för kommunkontakterna genom att förse dem med
statusuppdateringar, och färdigprognos, var ”deras” ärenden befinner
sig i berednings-/produktionsledet
1m Ett uppstyrt internt regelverk bör kunna styra upp en otydlighet som
finns mellan den interna logistikkedjan för indata.
1n Minst en dataleverantörskontakt per år då man stämmer av ordentligt.
1o Ge någon instans tolkningsföreträde med krav på
informationsspridning
1p Få in kravet på leverans av företeelser i rutinerna för NVDBuppdateringar
1q Trafikverket får ansätta en ambitionsnivå och anslå resurser för att
uppnå detta. Trafikverket kan också ställa krav på att
dataleverantörerna går ett visst minimiantal kurser.
2a Ibland så är det olika personal hos kommunerna som registrerar vägnät
och företeelser. Kommunikationen mellan dessa grupper är inte alltid
perfekt och kan förbättras.
2b Snabba upp inleveranser från vägarbeten.
2c Arbeta på att få upp kvaliteten på indata.
2d Lösningen är dialog och förvarning från dataleverantörerna. Kan detta
genomföras kan Trafikverket upphandla nödvändiga resurser externt i
tid och synkroniserat med inkommande volymförändringar
3a Få med överföring av företeelser i inkrementell uppdatering.
3b Om kvalitetsproblem med vägnätsredigerare kvarstår trots
utbildningsinsatser, se till att”skrota” dessa och ersätt med enklare
lösningar, kanske kan en vidareutvecklad NVDB på webb 2012 vara en
sådan ersättare?? Bör utredas!
3c Systemleverantörerna kan utbilda och göra sina system bättre.
3d Nej, de kan nog inte påverka mycket här
Intressanta enskilda synpunkter:
”Internt har Trafikverket haft stark fokusering på en höjning av kvaliteten
på NVDB. Detta har medfört att ledtiderna istället har dragit iväg
(historiska kvalitetsproblem som var nödvändiga att åtgärda). Nu har
kvaliteten förbättrats och det är dags att förbättra ledtiderna också.”
”Ett sätt kan vara att flytta resurser från erkänt duktiga dataleverantörer
till problemleverantörer”.
Avslutning, rekommendationer, övrigt
Har du några avslutande funderingar på förändringar/förbättringar?
8a Något mer att tillägga till kommentarerna ovan kring
1. stödet från Trafikverket?
2. ev teknikstöd?
3. dokumentationen?
4. utbildningsmöjligheter?
5. övrigt?
Trafikverket
1a Trafikverket ska vara tydligare mot dataleverantörer vad gäller
indataregler/tider/former.
1b Mer information ut
2
3 Ett sammanfattande dokument som enklare beskriver vad/hur indata
ska levereras saknas.
4a Önskemål om mer intern utbildning rent generellt. Exempel på
utbildningsbehov är information om förkortningar, hantering av
ledningsärenden, mm
4b Kompetensen kring cykelnät behöver ökas.
4c Det jobbas också med nya produktkataloger
5 ”Som en sista utväg för att få in uppdateringar från dataleverantörer
kan NDBV denna väg också få in geografiska uppdateringar via LMV:s
ortofoton. NVDB/Trafikverket får komplettera med vägdata för statligt
nät samt sådana data som inte kan hanteras av LM (t.ex.
trafikföreskrifter och funktionell vägklass)”.
Intressanta enskilda synpunkter:
”Sammanfattning:
- Arbeta bort ev dubbelarbete i logistikkedjan på Trafikverket/NVDB.
- Satsa på teknikstöd tidigt i logistikkedjan.
- NVDB2012 ett steg i helt rätt riktning. Bör utvecklas så att geometrier
går att leverera genom enkelt gränssnitt, typ ”markering på skärm.”
8b
Några avslutande rekommendationer, tankar?
1
2
3
4
5
Trafikverket
Satsa tid och resurser på att fortsätta vidareutveckla NVDB på web
2012.
Jobba med kontinuerlig kompetenshöjning hos alla involverade
Jobba kontinuerligt med indata (använd ej ortofoton eller
batchinlämning)
Inse att det inte är lätt. Sällananvändare bör överväga möjligheterna till
samarbete i cluster alternativt hyra in konsult när det är dags för
uppdateringar.
Trafikverket borde titta lite på hur man gör i andra branscher i
likartade situationer
Intressanta enskilda synpunkter:
”En radikal lösning/diskussionsunderlag är att på sikt låta LMV ansvara
för den kommunala/ skogliga indata-hanteringen då de har en fungerande
modell avtalsmässigt och verksamhetsmässigt. Det skulle också underlätta
för dataleverantörerna att ha färre mottagare/kravställare på
uppdateringar av vägnätsdata - endast en kanal till staten (t ex finns f.n.
krav på indata till både LMV och Trafikverket om gatunamn).”
Frågor och svar – Systemleverantörer
Generella frågor om NVDB rörande uppdateringar av vägnätet
1a
Vilka är de största problemen idag i arbetet med att lämna/hämta data
till/från NVDB?
Syst.lev.
1
2
3
4
5
6
7
8
9
10
11
12
De långa ledtiderna från det att en kommun skickar över redigerat
material tills dess att det är inlagt i NVDB.
Otydlighet och bristande kontinuitet i Trafikverkets NVDBorganisation – vem ansvarar för vad?
Planering och framförhållning är många gånger bristfällig avseende
förändringar i lösningar och/eller dataproduktspecifikationer.
Vägnäts- och företeelsemodellerna är komplexa, och
dataleverantörerna saknar ofta nödvändig kompetens för att på ett
fackmannamässigt sätt, baserat på dessa specifikationer, genomföra
förändringar/rättningar och leverera dessa till Trafikverket.
Svårt för Trafikverket att ställa krav på indataleverantörer.
Formkrav kring förändringshanteringen är tekniskt svåra att
implementera, t ex hantering av portnumrering,
datakatalogförändringar, val av strukturerade attribut. Ger instabilt
gränssnitt. Datautbytet mellan de lokala systemen och NVDB är alltför
tekniskt komplicerat!
Just nu är det största akuta problemet att toleransen för glapp i NVDB
är för liten. Stockholm har ett stort antal förskjutningar på upp till 2.1
mm i sitt nät vilket försvårar leverans. Finns inte verksamhetsmässig
krav på nivå av noggrannhet vid skärmdigitalisering.
Hålklippningsrutin som lämnat ett ”arv” av väldigt stor ”historik”
(Trafikverkets uppfattning om historik) som topologiskt hänger
samman med bef nätet.
Problem med kvalitet i NVDB:s data, måste ha en ”feltolerant”
mottagningsrutin. Blandning mellan 2d och 3d-data. Uppstår ev i
initialladdningar. Trafikverket jobbar dock på detta och det blir bättre.
Byte av kommunal driftleverantör har lett till längre ledtider för
installationer etc
Våra kunder upplever att de ofta har tekniska problem när de ska
hämta data. Ibland beror det nog också på bristande kompetens och att
de inte alltid följer instruktionerna.
Användarna har problem med hämtade filer eftersom de inte zippas
(komprimeras) automatiskt. Om man glömmer att zippa filer blir
hämtade filer oanvändbara. (vilket står i handledningen). Men, som det
verkar, alla dataleverantörer har inte läst denna. Informationen bör
förtydligas på hämtsida eller ändras till att XML filen komprimeras
med automatik
Intressanta enskilda synpunkter:
”(Vi tror att) när Trafikverket checkar ut ett område för en omfattande
vägnätsredigering så vill man inte checka in området innan allt är på plats.
Under denna tid kan inte kommunala uppdateringar för samma område
checkas in i NVDB med långa ledtider för de kommunala uppdateringarna
som följd. Denna arbetsfördelning stämmer inte med tidigare utlovad
prioritering där leveranser från tekniska lösningar skall ha förtur i
processen just för att det stoppar upp kommunernas möjlighet till
myndighetsutövning (NVDB:s målsättning är max 2 dygn för
standardjobb)!”
”Det begränsar kommunernas arbete samt försvagar förtroendet för vår
tekniska lösning.”
”Det går ju inte fortare, trots att de lovat det”.
”Trafikverket har ställt alltför höga krav på kommunerna när det gäller
företeelser vid leveranser av vägnätsförändringar. Kommunerna får inte
ihop det med företeelser och de vill inte lägga pengar på funktionalitet för
uppdateringar av NVDB-företeelser då nyttan av dessa, än så länge, anses
som begränsad.”
1b
Vilka är de viktigaste ev. förändringarna i arbetet med att lämna/hämta
data till/från NVDB som ni skulle vilja få till?
Syst.lev.
1
2
3
4
5
6
7
8
9
10
11
12
13
1c
En automatisering hos NVDB där de leveranser som kommer från en
certifierad lösning slipper hanteras på manuellt sätt.
Tydliggjord organisation för NVDB hos Trafikverket.
God framförhållning och noggrann avstämning med avtalspartners
inför förändringar i lösningar och/eller dataproduktspecifikationer. Jfr
t.ex. Google Maps
På sikt så är en enklare modell för informations-utbyte det viktigaste att
realisera. En ny informationsmodell har tagits fram av Trafikverket
under hösten och den borde få påverka informationsutbytes modellen.
Sluta ställa krav som beror på tekniska begränsningar i NVDB på
externa dataleverantörer.
På kort sikt så vill kommunerna införa gångnät så Trafikverket bör ta
hänsyn till detta i utbytet.
Öka dagens toleranskrav. 2 mm alltför snävt för digitalisering på
frihand
Ett önskemål är att försöka krympa filstorlekarna, t ex genom att dela
på vägnät och företeelser vid hämtning, och att dom zippas
automatiskt.
Utcheckningsprocessen ska bli enklare, att behöva lägga nio olika
beställningar för att checka ut en kommun samt dess kranskommuner
(geometrier och alla företeelser) är omständigt. Önskan om att ha
möjlighet att beställa och hämta större filer finns.
Tydligare instruktioner på webb, bland annat:
Det är ologiskt att det på hämtsidan (status) står att beställda ärenden
är ”klara för hämtning” om det är nödvändigt att komprimera
filen/filerna (xml) innan hämtning för att de skall vara brukbara.
Om möjligt borde komprimeringen av XML-filer automatiseras.
På statussidan står det ”Status på NVD-filer” även om man har
definierat och beställt XML
Vad fungerar riktigt bra i samarbetet mellan Trafikverket/NVDB och er?
Syst.lev.
1
Samarbetet i stort fungerar mycket bra. Vi har lätt att prata med
varandra. (2 st)
2 Trafikverket har blivit mer tillmötesgående att hitta alternativa
lösningar utifrån kommunernas perspektiv och behov, mindre strikt.
3 Trafikverket är hjälpsamma i testarbete och snabba på att åtgärda
eventuella brister i NVDB-data.
4 NVDB:s tekniska lösning är mycket stabil, och uppdateringsfiler
genereras som de ska
5 Man har startat upp avstämningsmöten (2 st hittills) och dessa har varit
bra.
Intressanta enskilda synpunkter:
”Trafikverket besitter en stor kompetens kring modellen, tyvärr något
mindre för kommunernas förutsättningar och behov.”
1d
Vilka är de viktigaste ev. förändringarna i samarbetet mellan
systemleverantörer och NVDB/Trafikverket som skulle kunna göras?
Systlev.
1
2
3
4
5
6
7
8
9
10
11
Systemleverantörerna, och kommunerna, behöver bättre ledtider vid
förändringar. Vi (systemleverantörer) kräver minst nio månaders
förvarning vid förändringar på NVDB-sidan för att hinna med att
åtgärda. Förändringar i modellen slår även på nästa led, ute hos dataleverantörerna som också behöver kalendertid för att lära/anpassa sig
till nyheter. De kommunala it-avdelningarna behöver också tid för
hantering och godkännande.
Är en förändring nödvändig så bör en interimslösning undersökas. Kan
förändringen implementeras på ett eget system för att sedan lyftas in i
NVDB när alla är synkade?
Idag släpper Trafikverket ev. förändringar/nya releaser varje halv- och
helårsskifte. Kalendermässigt är detta ingen bra lösning då personal
både hos kommuner och systemleverantörer till stor del har ledigt eller
är underbemannade. Försök hitta andra datum.
Tydliggjord organisation.
Långsiktighet och tydlighet i planering och god kommunikation om
kommande förändringar – såväl tekniska som verksamhetsmässiga.
Involvera i större utsträckning systemleverantörer och dataleverantörer
i detta arbete.
Förslag: etablera ett tekniskt råd där systemleverantörer, och gärna
större skogsnäringsorganisationer, erbjuds plats. (Motsvarande
Kommunforum).
Tydliggör för dataleverantörerna att de har möjligheten att leverera
uppdateringsförslag i Shape-format snarare än hela leveranser. Som jag
ser det saknar Trafikverket mandat att ställa krav på
dataleverantörerna att de ska göra hela leveranser
Styr inte kravställningar utifrån Trafikverkets interna
systemförutsättningar.
Kraven på kommunerna är ibland väldigt höga
Fortsätt att utveckla avstämningsmötena, se ovan.
Systemleverantörerna vill ha tydligare hemsida där det klart framgår
vad som är ny information. Tydligare indelning så att man hittar ”allt”
som hör till ett speciellt område samlat på ett ställe.
Intressanta enskilda synpunkter:
”Vi efterfrågar en ökad förståelse hos Trafikverket för att
systemleverantörerna också talar för sina kunders behov och att de väl
känner sina kunders behov.”
”Trafikverket måste lyssna mer på kommunernas krav, även då dessa
framförs via systemleverantörer. Förståelsen för kommunernas) är inte
alltid klar för Trafikverket fokus (egna kommunala verksamheten är nr 1).”
”Ge systemleverantörerna information och tid för förändringsarbete när
nyheter ska introduceras. (I viss mån kan man skilja på förändringar som
påverkar teknik och överföringar med automatik och således är extra
känsliga, och andra som mer implicit förändrar något). Både vi, och våra
kunder/användare, behöver tidiga avstämningar och kalendertid för att
hinna med att agera vid förändringar/nyheter.)”
Leveranser, samarbete, dokumentation, utbildning, NVDB.se?
2a
Vad fungerar bra med att lämna/hämta data till/från NVDB idag?
(Vad behöver inte ändras, möjligen kopieras?)
Syst.lev.
1. Med hel leverans (både vägnät o företeelser via eget system) till NVDB?
2. Med delvis leverans (vägnät via eget system och företeelser via underlag)
till NVDB?
3. Med att hämta data?
Syst.lev.
1a Inte aktuellt
1b Fungerar bra.
1c Just nu stöder vårt system hämtning men inte lämna uppdateringar till
NVDB via automatisk webbtjänst
2a Applikationerna fungerar tekniskt bra när omgivningen är stabil.
2b NVDB på webb 2012 är riktigt bra och har potential också för att kunna
fungera effektivt som systemstöd för inmatning av underlag.
2c Fungerar bra (om man med delvis leverans avser leverans av
uppdateringsförslag i Shape-format).
2d Det är enkelt och går snabbt att beställa och få vägnät och företeelser
levererade via NVDB Webbapplikation
2e Alla deras kunder levererar vägnätsuppdateringar via Shapefiler. En
dialog förs med Trafikverket och dataleverantörer, om mer
automatiserade överföringar till Trafikverket/NVDB men då
förändringar pågår av NVDB så har man tagit ett strategiskt beslut om
att ligga lågt tills man vet hur lösningen kommer att se ut.
3a Det FTP-fillager med uppdaterade NVDB-data för hela Sverige i ett
kompakt binärt format som uppdateras dygnsvis fungerar ypperligt för
att hålla synkroniserade distribuerade databaser ajour.
2b
Generellt, vad fungerar mindre bra med att lämna/hämta data till/från
NVDB?
(Vad borde förändras?)
1. Med hel leverans (både vägnät och företeelser via eget system) till
NVDB?
2. Med delvis leverans (vägnät via eget system och företeelser via underlag)
till NVDB?
3. Med att hämta data?
Syst.lev.
1a Vi har idag endast en kund med verktyg för vägnätsredigering för hel
leverans till NVDB.
2a En automatisering hos NVDB där de leveranser som kommer från en
Syst.lev.
certifierad lösning slipper hanteras på manuellt sätt. När det gäller
underlag för företeelser så anser jag att ”NVDB på webb” borde
användas för det.
2b Inga problem. Det skulle möjligtvis vara att marknaden för verktyg för
hela leveranser (1) påverkas av att man erbjuder möjligheten med delvis
leverans/shape.
3a Ibland upphör synkroniseringen pga att det saknas obligatorisk
information i NVDB. Även när Trafikverket har infört nya attribut som
vi inte hunnit få ut till kundernas databaser kan synkroniseringen
upphöra.
3b De organisatoriska otydligheterna har ibland medfört att datauttag
(hela Sverige) tagit oskäligt lång tid. Senaste leveransen till SDC tog
över tre månader. (Att få svar varifrån och hur data ska hämtas – mail
konversation som gick runt inom Trafikverket)
Några tekniska synpunkter:
1 Hopbuntning av successiva förändringar
2 Ej kontinuerliga synken igång
3 Mellanliggande versioner fås inte med
4 Följdeffekter vid redigering som leder till att länks geometri leds in i
Stockholm
5 Följdeffekter vid ändrade kommungränser
2c
1. Hur fungerar samarbetet med Trafikverket när ni har frågor/problem?
2. Hur borde samarbetet ev. förändras?
Syst.lev.
1a Oftast bra med snabb respons när det kommer till teknik- och ev.
problemlösningar.
1b Har varit en del långa ledtider senaste halvåret pga stor
arbetsbelastning hos vissa resurser på Trafikverket
1c Otydligheter i organisationen gör att det kan ta onödigt lång tid att
komma till rätt person. När man väl kommit dit fungerar det dock bra.
1d Man har startat upp avstämningsmöten (2 st hittills) och dessa har varit
bra. Man hoppas mycket på framtida gott samarbete.
2a Det vore intressant att få tillgång till det ärendehanteringssystem som
Trafikverket använder för vägdataavvikelser
Intressanta enskilda synpunkter:
”Bara bra erfarenheter vid problem och support. Mindre bra vid
förändringar och anpassningar.”
2d
1. Hur fungerar NVDB-dokumentationen för er?
(Täcker den ert behov av dokumentation, information utbildning osv?
volym/innehåll/frekvens)?
2. Hur borde den ev förändras/kompletteras?
Syst.lev.
1a Den täcker de behov vi har. (2 st)
1b Bra, det finns mycket dokumentation.
2a Ändringar i dokumentet ”Förändringar från föregående version” är
svåra att tyda. Bör göras på ett bättre och mer pedagogiskt sätt.
2b Kommunerna har idag svårt att namnsätta cykelvägar och nuvarande
dokumentation är otillräcklig, framför allt i gaturummet
Syst.lev.
2c Bra, men efterfrågar större framförhållning och närmare samarbete
med systemleverantörer och avtalspartners
2d Problematiskt att se vad som är de senaste uppdateringarna.
Dokumentera tydligt vad som är senaste version. Äldre versioner kan
lagras i egen mapp med tydlig märkning ”Arkiv”.
2e Ta fram enkla dokumentationsinstruktioner.
2f Skulle också gärna se mer av information – arbete med trafikregler på
NVDB.se. Här är NVDB beroende av samarbete med
Transportstyrelsens och den databas där uppgifter om trafikregler
kommer att lagras i.
2g I Förslag till handledning/lathund: Förklara varför flera företeelsetyper
blir valda när enstaka tillgängliga företeelsetyper väljs. Frågan gäller
inte företeelsetillkomst, utan varför väghållare och vägtrafiknät följer
med automatiskt.
2h Förslag till handledning/lathund (Användning Betrakta): Att
informationen under hjälp på webbsidan (sida 2 Beställning av fil-allt,
till vänster om Företeelsetyper) förs in i handledningen: Val av samtliga
(>>) endast inbegriper giltiga företeelsetyper.
2i (Handledning, sidan 13 (26): Använd erhållet uppdateringsärendeid…
Denna mening skulle kunna förklaras tydligare.)
2j (Handledningen, sidan 18 (26): …följande filformat: shape, XML
(SS637004)… SS637004 är kopplar till ISO 19100 väg- och järnvägsnät
Applikationsschema, men utan att ge mer information finns det risk för
missförstånd. Kan man använda både ver. 2.0 och 3.1, linjärt och
geometriskt?)
Intressanta enskilda synpunkter:
”Möjligen göra två separata handledningar för NVD XML?”
2e
1. Hur fungerar utbildningsmöjligheterna för NVDB?
(Täcker den ert behov av utbildning (volym/innehåll/frekvens)?
2. Hur borde den ev. förändras/kompletteras?
Syst.lev.
1a Materialet är förträffligt! Trafikverkets material används t o m i
systemleverantörersutbildningar.
1b Har begränsad egen erfarenhet. Bra för nybörjare, otillräckligt för mer
erfarna användare
1c Inte så många åsikter om detta…
2a Vi väntar på utbildning om cykelnätet vilket ska komma ”inom kort”,
men inget händer…
2b Tycker dock att Trafikverket måste vara mer proaktiva mot
dataleverantörer och kommuner som genomför förändringar själva i
sina miljöer.
2c Mer utbildning krig generaliseringar
2d En grundteoriutbildning från Trafikverket för berörda kunde ev vara
bra. (Möte om utbildningar kommer i januari)
2f
1. Hur fungerar NVDB.se?
(Täcker den ert behov av dokumentation, information utbildning osv?
volym/innehåll/frekvens)?
2. Hur borde den ev. förändras/kompletteras?
Syst.lev.
1a Den fungerar bra.
1b Inte så mycket erfarenhet. Hitta vi inte informationen vi söker på
NVDB.se så har vi kontakter på Trafikverket som vi kan fråga.
1c Det saknas återigen datummärkning på olika dokument, se ovan. Inte
heller versions-märkningen är konsistent.
2a Vi saknar dock kopplingarna till NVDB 2012 (men den kanske inte är
officiellt släppt ännu?)
2b Liten erfarenhet, men besöker den emellanåt. Skulle denna kunna
kompletteras med en e-postlista för publicering av nyheter?
2c Styr upp datum- och versionsmärkningen på alla dokument.
Applikations-/systemstöd och arbetet med in-/utdata och NVDB?
Avser applikationerna
- ”NVDB:s webapplikation för hämta filer”
(in-/utcheckning),
- ”NVDB:s webtjänst”
(dygnsuppdaterade filer fr FTP-server)
3a
Vilka är de största ev. problemen idag med NVDB:s applikationsstöd (i
samband med att lämna/hämta data till/från NVDB)?
Syst.lev.
1
Vi upplever inga speciella problem utöver
synkroniseringsproblematiken, se 2b.
2 Ser inga stora problem, men Trafikverket borde tydligare separera de
externa och interna datamängderna. Ibland händer det att
avtalspartners vid initialdataladdning får med sig GVT-data ut, vilket
ökar datamängder och är helt onödigt.
3 De applikationer som finns fungerar bra
3b
Vilka är de viktigaste ev. förändringarna med NVDB:s applikationsstöd
som ni skulle vilja få till (i samband med att lämna/hämta data till/från
NVDB)?
Syst.lev.
1
3c
Ser inga problem
1. Hur väl fungerar NVDB:s webapplikation för hämta nvd-/XML-filer?
2. Hur borde den ev förändras?
Syst.lev
1a Fungerar bra
1b Mycket liten erfarenhet av denna, men den har fungerat i de fall vi
använt den
2a Ingen speciell förändring är nödvändig.
2b Beställningar borde kunna delas upp i separata filer för nät och
enskilda företeelsetyper. Det är ofta vi vill hämta NVDB-data, nät och
företeelser, uppdelade på flera filer. En fil för nät, och en fil per
företeelsetyp. Det gör filerna mindre och mer lätthanterliga än om allt
ligger i samma fil. I dagsläget betyder det att vi måste gå igenom
webbapplikationens gränssnitt en gång per fil, en tidskrävande process
med stor risk för felklick. En trevlig förbättring vore om det i
gränssnittet fanns möjlighet att välja att få beställningen uppdelad i
dessa filer. Alltså - göra en beställning, men få svaret uppdelat per nät
och enskilda företeelsetyper
2c När man väljer en företeelsetyp så ”hjälper” gränssnittet till och väljer
tre andra som man inte är intresserad av. Speciellt frustrerande när
man vill göra en beställning med separata företeelsetypsfiler. Det går
inte att backa om man har valt ”Företeelseurval”. Det är inte helt tydligt
vad den funktionen gör heller. Tydligen kan sätta val på andra
företeelsetyper än de man valt i tidigare steg
2d Kvittens för vad man har beställt skulle kunna vara mer detaljerad. Det
händer ibland att man gör fel i gränssnittet (man väljer fel företeelsetyp
t.ex.), men man kan inte se det i beställningskvittensen. Eventuellt
skulle även bekräftelseruta på vad man har beställt komma upp innan
man klickar beställ.
2e Att filerna zippas automatisk, så att användaren inte behöver tänka på
det, annars lätt att glömma bort.
3d
1. Hur väl fungerar NVDB:s webtjänst
2. Hur borde den ev förändras?
Syst.lev
1a Även webtjänsten fungerar bra. (2 st)
1b Fungerar bra
2a Ta bort alla å, ä, ö för user och password samt i katalognamn på FTPn.
2b Det finns ett problem hos Trafikverket vid leverans av förändringar där
hela kommunens område låses. Förbättring önskas.
2c Ingen åsikt. Avvaktar tills ev förändringar blir klara.
Samspelet mellan dataleverantörerna/systemleverantörerna/NVDB Trafikverket
Leverera och hämta data till/från NVDB är en logistikkedja. Hänger det ihop?
4a Beskriv hur samarbetet/samverkan mellan
systemleverantörerna/kunderna och NVDB/Trafikverket fungerar
1
2
3
4
5
6
Trafikverket har ända sedan NVDB:s tillkomst missat när det gäller
kommunernas behov och förutsättningar. Deras behov är inte
förankrade.
Motiveringen att kommunernas behov bevakas av SKL i Rådet håller
inte då SKL inte har full insyn i kommunernas dagliga arbete och behov
kring vägnätsunderhåll och redigering.
Inte tillräckligt, här finns klar förbättringspotential
Dåligt. Kommunernas krav är inte representerade i NVDB-rådet, eller
kommer inte fram dit.
Systemkrav, förutsättning och processer styrs helt utifrån Trafikverkets
behov, tekniska lösningar och begränsningar, jämför t ex:
Portars relativa läge
Blandade 2d- och 3d-data
Portars stabilitet och numrering
Anslutning och användning av gångvägnät
Stabilt vägnät och de processer på kommunen där denna
information uppstår
Data-, systemleverantörer och Trafikverket har en bra samverkan nu
sedan en tid. ”Har hittat vägen.” Tycker att det finns en kommunikation
mellan oss och Trafikverket idag.
Syst.lev
4b
Förslag på ev. förbättringar i samverkan?
Syst.lev
1
Gällande systemleverantörer så har jag tidigare efterfrågat ett samråd
när det kommer till att ta fram tekniska lösningar. Vissa träffar har
genomförts men då mer av informativ karaktär. ”Vi kommer att göra så
här…….. för att det funkar för oss.”
2 Skapa någon typ av förvaltningsråd med representanter från
kommunerna.
3 Samarbetet mellan NVDB:s tekniska och verksamhetsmässiga
förvaltning och systemleverantörerna bör fördjupas. Föreslår etablering
av ett tekniskt råd där man kan ha en dialog om t.ex. planering och
genomförande av förändringar i specifikationer och lösningar.
4 Vi har löst det genom att ha direktkontakt med NVDB centralt.
Intressanta enskilda synpunkter:
”Vill man att NVDB-data skall användas ute hos kommunerna så måste
man veta vad det är som de behöver”.
”Information kommer lite sent ibland. Försök styr upp så att system- och
dataleverantörer hinner agera systematiskt.”
Regelverk för inmatning av geometri, topologi, tid mm
5a
Vilka är de största ev. generella problemen ni ser idag med inmatning av
1. geometri
2. topologi
3. företeelsetyper?
Syst.lev.
1-3a Håller med om att det är komplext.
b Kräver mycket goda kunskaper i vägnäts- och företeelsemodellen
(svaret avser företeelser/företeelseinstanser snarare än företeelsetyper)
c Kravställningen är otillräcklig!
d System till systemkommunikationen är inte bra, har ofta driftstopp pga
alltför komplext regelverk.
e Toleransen för glapp i xy-led är för liten. Topologimodellen och
regelverket kring detta är för svårt att leva upp till
f Blandade 2d/3d-hanteringen
g Företeelsetypsvalideringen rapporterar fel om att t.ex. riktning finns
fast det inte borde finnas. Detta borde endast vara en varning.
Intressanta enskilda synpunkter:
”Alla passar inte att jobba med denna typ av uppgifter.”
”Övergripande synpunkt är att NVDB-leveranser inte får störa
vardagsuppgifterna för dataleverantörerna. Om jag jobbar på ett
(datalevarantörs-) kontor som ska lämna in uppdateringar till NVDB så får
detta inte störa de ordinarie arbetsuppgifterna. NVDB är ganska tekniskt
avancerat med en terminologi, lösningar etc som normalt inte ingår i t ex
ett gatukontors vardag.”
5b
Vilka är de viktigaste ev. generella förändringarna av arbetet med
inmatning av
1. geometri
2. topologi
3. företeelsetyper?
Syst.lev.
1-3a Systemleverantörerna kan lägga in ytterligare systemstöd i resp.
produkt. Rullgardinsval, valideringar, rimlighetskontroller mm, men
det är en prioritering av intäkter, nytta och kostnader. Då skulle man
kunna få ned antalet fel i senare produktionsled och därmed kortare
ledtider.
b ”Vi planerar för att göra det lättare att i nätredigeraren hitta ev. fel i ett
nätredigeringsjobb så att kunden kan åtgärda dem själv.”
c Överlåt topologiredigering till experter. Rekommendera väghållare
(avtalspartners/ dataleverantörer) att leverera uppdateringsförslag
snarare än hela leveranser (svaret avser företeelser/företeelseinstanser
snarare än företeelsetyper).
d Få med gångvägnätet
e Förenkla topologimodellen
f Trafikverket vill ha in underlag från byggentreprenörer i et tidigt skede.
Detta ställer till det då många upphandlingar drar ut på tiden och detta
krav kommer inte med/”glöms bort”. Målsättningen måste vara att
underlagen är klara när vägen är klar
g Terminologin är ett bekymmer då det finns ett stort glapp mellan
dataleverantörernas vardag och Trafikverket. Detta glapp skapar en
tröskel hos dataleverantörerna för att jobba med regelbundna
vägnätsredigeringar till NVDB.
Intressanta enskilda synpunkter:
”Dataleverantörer som har investerat i lokala systemstöd måste kunna lita
på Trafikverkets utlovade ledtider.”
”Ur systemleverantörsperspektiv så är det inte optimalt att Trafikverket
”erbjuder” avancerad beredning gratis. Vissa kommuner investerar då inte
i systemstöd utan fortsätter istället att skicka enkla underlag till
Trafikverket som får bereda dessa.”
”Vissa kommuner upplever att Trafikverket har ibland förändrat
uppdateringsvärden jämfört med originalet.”
”En produktionscentral med professionella vägdataredigerare ger
sannolikt kortare ledtider (lättare att göra och skicka iväg
uppdateringsförslagen) och bättre kvalitet i NVDB-data (proffs som gör
slutredigeringen)”
” För att få det att löpa smidigt ute hos dataleverantörerna med
regelbunden inrapportering av vägnätsredigeringar så får det inte finnas
trösklar i form av krånglig terminologi, krånglig teknik och inte minst egna
lokala verktyg som inte primärt är skapade för NVDB-uppdateringar och
därför är svårarbetade för dessa uppgifter.”
Ledtiderna från leverans av indata tills inlagt i NVDB?
6a
Hur upplever ni att ledtiderna är för dataleverantörernas inleveranser fram
tills att data ligger i NVDB?
Syst.lev.
1 Alldeles för långa! Ett stort problem. (2 st)
2 Ingen uppfattning. Vi vet att de större skogsbolagen, som numera
levererar uppdateringsförslag från Vägförvaltningssystemet, gått från
ledtider på i vissa fall flera år till betydligt blygsammare ledtider.
3 Granskningsprocessen hos Trafikverket/NVDB borde kunna förenklas.
4 Den komplicerad tekniska lösningen med många avbrott/förseningar
genererar också ledtider
6b
1 Kan något göras av er organisation för att korta ledtiderna?
2 Vad kan göras av Trafikverket/NVDB för att om möjligt korta
ledtiderna?
Syst.lev.
1a I de fall det är tillämpligt skulle det sannolikt korta ledtiderna avsevärt
om vägprojektören eller beställaren ålades att leverera ett detaljerat
uppdateringsunderlag för uppdatering av den nationella vägdatabasen i
samband med upprustnings- och nybyggnationsprojekt.
1b Vi måste få utbytet vid nätredigeringen att fungera bättre, dvs jobba
bort tekniska problem.
1c Vi har inte utvecklat automatisk kommunikation ännu vilket om det
kommer förkortar ledtiderna något.
2a Automatisera processen när det kommer leveranser från certifierade
system.
2b Använd/utveckla NVDB på web 2012 för enkel och stabil inmatning av
företeelser.
2c Skapa ett teknikråd där information om problem, nyheter, förslag etc
presenteras och diskuteras.
2d Arbeta med att få tillräckliga underlag från entreprenörer i tid.
2e Kravställningar är otillräckliga idag.
2f Tror att utbildning är mycket viktigt här, dvs att få en förståelse för
hela processen. Förtydliga regelverket. Ska t ex en dataleverantör
rapportera in projekteringsinfo och sedan uppdatera vid slutgiltig
inmätning, eller ska han/hon vänta med alla leveranser tills
slutinmätning när all data som ska levereras finns på plats?
Intressanta enskilda synpunkter:
”Håll det man utlovat gällande att jobb som kommer från ett certifierat
system skall prioriteras av NVDB.”
Syst.lev.
Avslutning, rekommendationer, övrigt
Har du några avslutande funderingar på förändringar/förbättringar? Syst.lev.
”Det finns skillnader mellan kommunala (vägnäts-) företeelser och NVDB:s
företeelser. Många gånger använder inte kommunerna NVDB:s företeelser i sina
verksamhetssystem på gatusidan, och vice versa, varför kunskapen blir lidande.
Ibland räcker inte NVDB:s företeelser till för kommunerna i deras dagliga arbete
vilket minskar förståelsen för Trafikverkets krav hårda krav på inrapportering av
sina företeelser (jämför exemplet NVDB-företeelsen Slityta med två (belagd,
grus) val och kommun-företeelsen Beläggning med ett tjugotal). Liknande
skillnader påverkar den kommunala nyttan/användningen av NVDB-företeelser
inom vissa verksamheter, samt bidrar till oklarheter och nedprioritering av
NVDB-relaterade uppgifter.”
”För kommunerna är det NVDB:s stöd till transportplanering och ruttdata
(geometri och vägnät) som är prio ett och som måste vara synkade med NVDB.
Relaterade företeelser är inte lika viktigt för kommunerna.”
”Överväg att minska kommunernas ansvar för inmatning av företeelser. Ofta
borde Trafikverket t ex genom att analysera aktuellt geografiskt område kunna
få fram olika företeelsers värden (jämför exemplet ny cirkulationsplats vars
företeelsers värden kan härledas ur existerande omgivande objekts företeelser,
osv).”
”Kommunerna uppfattar ibland att Trafikverket ställer högre krav på
fullständighet än på kvalitet på indatat. Om detta stämmer så bör Trafikverket
överväga att ändra prioriteringen så att kvalitet på viktigt indata kommer först
och fullständighet för mindre viktiga företeelser tonas ned. Ett exempel kan vara
att Trafikverket via avtal tillåter enklare generaliseringar för enskilda
kommuner: ”Följande attribut gäller alltid för dessa objekt i denna kommun”,
osv.”
”Trafikverket borde lyssna mer på kommunernas krav.”
”Inse att kommunernas primära fokus är sina egna kommunala system och
behov. Ett stabilt vägnät är i första hand centralt för kommunens egna behov – i
andra hand leverera data till NVDB!”
”Möjlighet att prenumerera på nyheter från NVDB RSS- flöde eller e-postlista.”
Frågor och svar – Dataleverantörer (kommuner/skogsnäring)
Generella frågor för NVDB rörande uppdateringar av vägnätet
1a
Generellt, vad fungerar bra med att lämna/hämta vägnätsdata till/från
NVDB?
datalev.
1 Goda personliga kontakter in i NVDB-organisationen. Dessa hjälper till
efter bästa förmåga. (3 st)
2 Själva processen fungerar väl. (6 st)
3 Trafikverkets service att godta underlag via mail, granska, komplettera
och slutligen registrera passar kommunen bra.
4 Inrapportering av geometrier och företeelser via mail fungerar bra o
passar kommunen. (3 st)
5 Det finns möjligheter att skicka in enkla shape-filer för snabb indata.
6 Kontakterna med Trafikverket fungerar bra.
7 Själva processen fungerar bra idag och ärendena processas ganska
snabbt på Trafikverket/NVDB. För oss är det numera mest
ajourhållning (tidigare användes Slussen som upplevdes tung). Idag kör
man NVDB på webb 2012 med gott resultat.
Intressanta enskilda synpunkter:
”Lagom nivå, bra kontakt med Trafikverket. Det rullar och går.”
1b
Generellt, vilka är de största problemen idag i arbetet med att
lämna/hämta vägnätsdata till/från NDBV?
1
2
3
4
5
6
datalev.
Det är en hel del som inte fungerar bra! Sammantaget så tar
uppdateringar alltför lång tid vilket stoppar upp det dagliga kommunala
arbetet. De långa ledtiderna har flera orsaker, både internt inom
kommunen, med programleverantör samt inom Trafikverket.
NVDB vill ha in uppdateringar så snart som möjligt, gärna innan
byggnationerna är klara. Kommunen får motsvarande data från
entreprenören först när vägen/gatan är körbar. Då ska informationen
importeras i vägnätsredigeraren varpå arbete där påbörjas. Data skickas
sen till NVDB som granskar, ev komplettering, godkänner varpå NVDB
uppdateras. Kommunen kan inte göra något mer med vägen förrän den
är godkänd i NVDB vilket kan dröja mer än 1 vecka. Sen kan
uppdaterad info från NVDB exporteras tillbaka till vägnätsredigeraren.
Det enskilt största problemet är ändå vägredigeraren som är svår och
krånglig. Kan t ex inte ångra förändringar, samt mycket
specialhantering. Lång väntan på svar från supporten men ändå kan de
inte alltid svara.
Skillnaderna mellan det egna nätet, där vägnamnen är sökbara attribut
på väglänken (motsvarande referenslänk i NVDB) och NVDB är så stora
att kommunen måste underhålla två nät via dubbelarbete.
Kommunen känner sig utlämnad till systemleverantör och Trafikverket.
Idag har man problem med att tillbakahämtade uppdaterade XML-filer
från NVDB innehåller skräptecken i slutet av filerna. Dessa måste
redigeras innan filerna kan importeras i det lokala systemet. Ibland går
det, ibland inte. Både systemleverantör och Trafikverket är
informerade, men tiden går och problemet består.
Svårigheterna internt att synkronisera involverade kommunavdelningar
är det största problemet. De interna rutinerna inom kommunen
behöver förbättras för att en komplett leverans ska kunna levereras i
rimlig tid. (Detta ska nu ses över.) (2 st)
7 Det kan vara svårt att få in data från vägentreprenörerna. Ofta vill de
dessutom bara lämna data en gång, alltså inte både vid projektering och
senare justeringar efter inmätning.
8 Det finns en osäkerhet kring leveransavtalens dataleveransbilagor då
Trafikverket har varit otydlig. Finns det ett nytt leveransavtal kring
NVDB? För ca ett år sedan genomförde Trafikverket och LMV ett möte
kring ev nya leveransavtal, men vad har hänt sedan dess? Detta är
intressant då bättre anpassade och tydliga avtal bör medföra bättre
inflöde av information till NVDB från kommunerna.
9 Att vi inte kan skicka varken geometrier eller företeelser direkt från
vägnätredigeraren till NVDB (synkroniseringsproblem) beroende på fel
i programvaran för ajourhållning. Man har sedan 2006 försökt få detta
att fungera men det krävs fortfarande handpåläggning för att få igenom
allt.
10 Systemet för inmatning av varje geometris attribut på ett enskilt blad
har upplevts knöligt då inleverans idag skett genom shape-filer med
tillhörande attribut på ett separat formulär för varje geometri.
11 Just idag har kommunen ett stort problem med att tillbakahämtade
uppdaterade XML-filer från NVDB innehåller skräptecken i slutet av
filerna. Detta måste redigeras innan filerna kan importeras i det lokala
systemet. Ibland går detta, ibland inte. Här är man utlämnad till
systemleverantör och Trafikverket som båda är informerade, men tiden
går och problemet består!
12 Kommunen har aldrig kommit ingång med uppdateringar av NVDB.
Tekniska problem gör att man varken vill överföra uppdateringar till
NVDB eller tanka hem data till vägnätsredigeraren. Det är
synkningstabeller mellan NVDB och vägnätsredigeraren som inte
fungerar. Just nu törs man inte röra något varför NVDB inte uppdateras
och kommunens vägnätsredigerare står still.
13 (Även rapportgeneratorn fungerar dåligt och har haft problem att
hantera stora volymer, men det ska vara löst nu.)
14 Kommunen har tekniska problem med Lastkajen och får just nu inte ut
några filer. Troligen behörighetsfråga.
15 Det finns en otydlighet i svaren från Trafikverket/NVDB. Om man t ex
lämnar in 5 ärenden så innehåller inte Trafikverkets svar referenser till
dessa 5 ärenden utan istället en länk som är svår att hantera
Intressanta enskilda synpunkter:
”Det kan också vara svårt att få in data från vägentreprenörerna. Vi
kommer i upphandlingar av vägbygge ha krav på inrapportering av
vägdata.”
”Idag finns cykelvägsinformation i NVDB men inga standardavtal för
kommunerna hur cykelvägsdata ska hanteras och uppdateras. Istället kan
detta regleras från kommun till kommun.”
”Idag är det olika leveransbilagor till avtalen och det är helt i sin ordning.
Det som skapar osäkerhet är när Trafikverkets repr. säger att alla ska få
nya, likadana avtal. Vad menas med det?”
1c
Generellt, vilka är de viktigaste förändringarna i arbetet med att
lämna/hämta vägnätsdata till/från NVDB som ni ev. skulle vilja få till?
datalev.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Det måste bli enklare att göra förändringar i vägnätsredigeraren och
sedan exportera dessa till NVDB. Kommunen är expansiv och det
händer mycket hela tiden. Förändringarna är ofta också komplexa, dvs
allt detta tar tid. När sedan NVDB och egna nätet inte är ”synkade” så
blir det dubbeljobb.
Om kommunen fick lite snabbare feedback från Trafikverket på
inrapporterade NVDB-uppdateringar så skulle det underlätta i det
fortsatta arbetet.
Fungerar ganska bra på stora hela. Enklare uppdateringar löper
smärtfritt. Mer komplexa förändringar kan ibland vara problematiska.
Att få ordning på den interna synkroniseringen mellan kommunens
olika avdelningar har högsta prioritet. (2 st)
Incitamenten för att dra igång inrapportering av vägnätsuppdateringar
via vägnätsredigeraren upplevs som alltför små. Vägnätsredigeraren
levererar inte heller företeelser så lösningen är ännu inte komplett. Om
volymerna ökar och tekniken blir stabilare så kan denna funktion bli
mer intressant.
Tydliggör standardavtalen och vad som gäller kring olika valmöjligheter
för olika kommuner.
Tydliggör vad som gäller för cykelvägnät och förbered för kommande
gångvägnät.
Trafikverket bör försöka snabba upp den interna ledtiden för NVDBuppdateringar då långa ledtider stoppar upp de lokala kommunala
uppdateringarna. ”Kommunerna vill ha flyt i sitt arbete.”
Att få kommunikationen med XML-filer att fungera med
vägnätsredigeraren.
Att förenkla hanteringen av företeelser.
Man är nu på väg över till NVDB på web 2012 vilket blir en stor
förändring till det bättre.
Man efterfrågar ”ett inmatningssystem som ser till att allt har kommit
in”!
Ett annat önskemål är systemstöd för tillgång till satellitbilder i NVDB
på web 2012. Skogsstyrelsen jobbar mycket med avstämning av
anmälningar om nya/förändrade skogsbilvägar och verkligt utfall via
foton. Nya satellitbilder tas ca en gång per år, ortofoton ibland endast
var 5:e år i Norrland.
Ursprungsmålet står kvar, dvs att kunna skicka upp förändringar från
vägnätsredigeraren till NVDB med automatik, och hämta ned
registrerad NVDB-data också med automatik. I förlängningen vill man
även kunna rapportera företeelser samma väg. Systemleverantören
jobbar på att lösa problemet.
Just nu inga större problem. När frågor uppstår så kontaktar vi
Trafikverket och får hjälp omgående
Slussen är nu utbytt mot NVDB på web 2012. Man har stora
förhoppningar på vers. 2012 och den bör motsvara förväntningarna då
man har deltagit i specifikationsarbetet samt beta-testerna.
1d
Beskriv hur samarbetet/samverkan mellan dataleverantörerna,
systemleverantörerna och NVDB/Trafikverket fungerar
datalev.
1
God personlig kontakt med medarbetare hos både systemleverantör och
Trafikverket.
2 Vägnätsredigeraren upplevs som tung varför de personliga kontakterna
ibland inte riktigt räcker till… Vissa svårigheter att få bra kontakt med
deras support.
3 På Trafikverket är det istället de långs svarstiderna som kan vara
bekymmersamma. Tycker dock att deras kontaktpersoner gör så gott de
kan och försöker ställa upp.
4 Samarbetet mellan systemleverantörer och Trafikverket kan bli bättre.
5 När man behöver stöd så får man det. Det räcker för dagens behov.
6 Samarbetet med Trafikverket är gott. Finns det frågetecken så löses
dessa snabbt. (2 st)
7 Efter ett informationsmötet för ett år sedan var stämningen i botten.
Efter NVDB-rådets möte och diskussion i Huddinge den 31 maj i år blev
det mycket bättre
8 Dataleverantörer – ingen samverkan
Trafikverket – fungerar bra med kontaktperson
Systemleverantör – Är trevliga men löser inte problemen. Leverantören
verkar inte prioritera kommunen.
9 Samverkan med Trafikverket är bra. Man deltar också aktivt i
samrådsmöten 2 ggr/år tillsammans med skogsindustrier, Skogforsk,
VMF-föreningarna, Trafikverket och SDC.
10 Samarbetet är gott. Man deltar i samrådsmöten 2 gånger per år (VMFföretag, Skogforsk, Trafikverket, skogsbolag) och man har månatliga
möten med VMF-kollegor där även NVDB-frågor ibland tas upp. Man
vet vem man ska kontakta vid problem, vid leveransfrågor osv
11 Vi har en bra process och det känns som om vi ska kunna leverera när vi
vill, det borde fungera. Kommunen tycker att systemleverantören
prioriterar lite konstigt, men förstår att upphandlingen nog (hittills) har
blivit en förlustaffär för systemleverantören pga av allt krångel.
Samarbetet med Trafikverket är fortsatt gott.
12 Man har inte mycket samarbete med någon systemleverantör då man
nästan bara rapporterar in data (Slussen och nu NVDB på web) och
endast tittar på data i NVDB. Några synpunkter finns dock. Det tar
väldigt lång tid och många möten att få till förändringar. Utvecklingen
av NVDB på web 2012 har verkligen dragit ut på tiden!
13 Den stora personalomsättningen och de många omorganisationerna på
delar av Trafikverket/NVDB vilket främjar inte personliga kontakter
och ”trygghet”.
Intressanta enskilda synpunkter:
”Kommunen tycker att spelreglerna har förändrats. Enl reglerna ska
kommunen leverera via systemlösning. Nu har reglerna ändrats så att även
det gamla sättet med leverans av shape-filer godkänns. Det är förstås bra
för att få in data till NVDB, men det skyndar inte på utvecklingen av
vägnätsredigeraren!”
1e
Förslag på ev. förbättringar i samverkan?
1
2
3
4
5
6
7
8
datalev.
Kommunforum och Södertörns samverkan är goda initiativ för
kommunalt samarbete. Sällan-användare/små kommuner måste nog gå
ihop och dela på resurser och kompetenser för att få allt att hänga ihop
bra. (2 st)
Kommunen vill få mer information om nya, eller utfasade, företeelser
där både Trafikverket, kommunrepresentanter och systemleverantörer
deltar. Idag händer det att företeelse-förändringar genomförs i NVDB
utan att kommunerna blir informerade.
Ett enkelt forum där nyheter presenteras på ett pedagogiskt sätt
efterfrågas, t ex återkommande möten, handledningar eller länkar till
websida där nyheterna presenteras.
Att NVDB-rådet åkte ut till en aktiv dataleverantör (NVDB-rådsmötet
120531 hölls i Huddinge) upplevdes mycket positivt och är något som
rådet borde göra återkommande. Välj t ex årsvis ut en ur NVDBsynpunkt intressant kommun och förlägg det återkommande mötet där,
gärna med fler kommuner inbjudna. Just detta att komma ut på fältet
och möta användarna är mycket viktigt och positivt.
Kommunerna borde kunna få hjälp av Trafikverket att trycka på
systemleverantörerna att jobba fram lösningar som hjälper
dataleverantörerna i deras arbete. Jfr problemet med synkronisering
som medför att varken geometrier eller företeelser kan registreras via
vägnätsredigeraren (se 1b). Som det är nu gör både kommun och
Trafikverket samma jobb två gånger
Inget speciellt. Just nu är man ganska nöjd. (3 st)
Kommunen har funderingar kring systemleverantörens
informationsmodell som känns låst till NVDB:s modell. Kommunen vill
snarare använda kartan som arbetsmodell och hänga information på
den, när vägnätsredigeraren istället utnyttjar mittlinje som
informationsreferens. Systemet är suveränt för rutthantering osv men
svagare på ythantering, något som kommunen gärna vill jobba med.
Har inga direkta synpunkter. Däremot så berättade man om problem
med gammal felaktig NVDB-information inom kommunens geografiska
ansvarsområde som kommunen själv inte har registrerat. Nu råder
osäkerhet om vem som granskar kommunens kartinfo och rättar upp
det som är felaktigt
Intressanta enskilda synpunkter:
”I takt med att det blir vanligare med samarbete mellan kommuner i
NVDB-frågor så borde Trafikverket vara lite proaktiva och komma dessa
kluster till mötes i olika frågor: ”Om ni går ihop i denna fråga så har vi en
lösning för det ...””
Dokumentation/utbildning/NVDB.se
2a
1. Hur fungerar NVDB-dokumentationen?
2. Hur borde den ev förändras/kompletteras?
datalev.
1a NVDB-dokumentationen är som mina ”biblar”. Får läsa flera gånger för
att förstå ibland.
1b Används ofta för att läsa om förändringar.
1c Man använder dokumentationen ganska lite, men vid behov så fungerar
den. Bl a så används den till att söka information om företeelser (3 st)
1d Länge nu sedan man tittade i dessa. (2 st)
1e Man har inte tittat speciellt mycket på den. Skogsbilvägarnas regler
kring geometrier och företeelser förändras inte ofta. Jobbar man
någorlunda ofta så lär man sig vad som ingår.
1f Den fungerar bra. Regelbunden uppdatering, begriplig.
1g Den är tydlig
2a Dokumentationen är omfattande. Ta fram ett dokument som visar
förändringar istället!
2b Om en del av dokumentationen var skoglig och innehöll de företeelser
som är aktuella på skogsbilvägar (vilket är en delmängd av det totala
antalet olika företeelser som finns) skulle det uppskattas. Internt inom
skogsbranschen så diskuterar man också med Skogforsk om att ta fram
en variant på kravspec. med skogliga företeelser.
2c Den håller en lagom nivå.
2d Dokumentationen är stor vilket medför att ibland uppstår olika
tolkningar hos olika dataleverantörer om t ex beskrivningar av
företeelser. Det är olyckligt då det försvårar arbete ”över gränserna”.
Intressanta enskilda synpunkter:
”Synd att så mycket ligger som statiska pdf-filer. Det borde var html och on
line istället för enkel och omedelbar uppdatering. Förenkla, gör mer
sökbart och modernisera webbsiten!”
2b
1. Hur fungerar utbildningsmöjligheterna?
2. Hur borde de ev. förändras/kompletteras?
datalev.
1a Gå igenom behovet av utbildningar på det efterfrågade
”samrådsmötet”, (återkommande möte, en handledning eller en länk
till en websida där nyheter presenteras)
1b Det har fungerat bra de (få) gånger man har gått någon kurs.
1c Det var länge sedan vi gick någon kurs. Vid nyanställningar så använder
vi oss av dem.
1d Inte tittat så mycket. Nyttan är mer påtaglig för kommuner än för
skogsbranschen.
1e Nej, man har inte gått några kurser. (5 st)
1f Inte tittat på hittills. Generellt så fokuserar vi på utbildning i första
hand för våra specialister och då räcker nog inte Trafikverkets
utbildningar till. Ska emellertid nu titta på, och utvärdera, om dessa
kan användas t ex för nyanställda.
2a Saknar inget speciellt.
2c
1. Hur fungerar NVDB.se?
2. Hur borde den ev. förändras/kompletteras?
datalev.
1a Använder den för att hämta dokumentation som används. F ö används
den inte mycket.
1b Endast sparsamt utnyttjande. (3 st)
1c Det kan var svårt att hitta det man söker.
1d Så där. Är inne ibland och hittar då det jag återkommande söker efter.
(3 st)
1e Använder den inte.
1f Bl a för att hitta lite info kring nya NVDB på web 2012 så har man sökt
runt på websiten. Dessa gånger har den fungerat OK och man har hittat
det man sökte. Ser bra ut!
1g Använder den ibland.
1h Gammal information kan ligga kvar vilket är förvirrande.
1i Inte utnyttjat speciellt. Ser inget specifikt behov
2a Lite oöverskådlig och svårt att orientera sig. Styr upp den lite. (4 st)
2b Ta bort gammal information.
2c Svårt att leta efter ny information. Siten känns stel och den behöver
något som lockar till besök. Den behöver uppdateras oftare, hända mer.
2d En variant med skoglig inriktning skulle uppskattas, t ex med speciell
betoning på skogliga företeelser. Nuvarande kurser kan med fördel
användas för nyanställda som introduktion.
Intressanta enskilda synpunkter:
”Det borde finnas en lättillgänglig flik där NVDB-specifikationer på ett
enkelt och pedagogsikt sätt beskriver hur inmätningar av väglänkar ska
göras korrekt. Kommunen hänvisar i anbudsförfrågningar etc. till NVDB.se
för instruktioner till underleverantörer. Dessa måste därför lätt,
överskådligt och pedagogiskt kunna hitta och utnyttja instruktionerna.
Den dokumentation som finns idag är för krånglig och svår att hitta.”
Hur jobbar ni med lämna/hämta vägnätsdata från NVDB?
3a
Hur jobbar ni idag med att lämna/ (hämta) vägnätsdata till/från NVDB?
(underlag eller via system)?
datalev.
1
2
3
4
5
Huvudsakligen via NVDB:s webtjänst med inkrementella
uppdateringar varje natt av geometrier. Jag ansvarar för att leverera
vägnätet och gatunamn. Övriga företeelser inrapporteras av
kommunens gatukontor, dvs av en annan avdelning.
a. I vägnätsredigeraren uppdateras kartan med t ex en ny gatas
mittlinje.
b. Skapar fil att exporteras till NVDB.
c. Ett excelblad fylls i med aktuella företeelser
d. De två filerna skickas in tillsammans m h a NVDB på web 2012.
e. Vid behov kompletteras filerna med en kartbild och anteckningar i
NVDB på web 2012
f. Mail när det är inlagt kommer tillbaka
g. Kommunen går in i NVDB 2012 och kontrollerar
h. Om ok så görs ett nytt uttag från Slussen och en ny fil importeras till
vägnätsredigeraren.
i. Frisläppning av den nedladdade filen i vägnätsredigeraren för andra
kommunaltjänstemän
Informationen som ska till Trafikverket/NVDB kommer från olika
förvaltningar men samordnas och skickas från stadsbyggnadskontoret.
Automatisk nattlig ”tillbakahämtning” av i NVDB inmatade
förändringar fungerar bra.
Skickar shape-filer som underlag till nya och förändrade geometrier och
företeelser via mail. Via Lastkajen hämtar man hem det material man
vill ha.
Vår avdelning svarar för insamling och rapportering av geometrier och
Gatunamn. Vi levererar även resten av företeelserna. Vid vägbyggen så
tar vi reda på vem som bygger och jagar sedan in nödvändiga
företeelser. De får fylla i en blankett. Informationen lägger vi in i vårt
lokala system. Vi tar sedan ut en shapefil ur systemet, bifogar den i ett
mail och skickar till Trafikverket.
För att hämta tillbaka uppdaterat NVDB-data till det lokala systemet så
används en webbtjänst som nattetid samlar ihop kommunens alla
NVDB-uppdateringar och för över dessa till det lokala systemet. Det
fungerar bra!
(Kommunen har ett system för LTF vilket också borde uppdateras
automatiskt nattetid precis som TNE. Detta fungerar dock inte alls. Vid
varje import av uppdateringar till systemet måste ett tiotal filer hämtas
och hanteras manuellt vilket är både krångligt och kostsamt.)
6 Man är i skarven för att börja köra NVDB på web 2012 skarpt.
Man levererade tidigare shapefiler till Trafikverket. I Slussen checkades
vägnät ut/in, men användes enbart som underlag för att skapa separata
shapefiler (och dokument (innehållande företeelser), vilka skickades till
Trafikverket för inläggning i NVDB. Trafikverket beredde och
registrerade. Modellen kändes inte rationell. In-/utcheckningsproblem
med Slussen förekom också.
7 Via Lastkajen hämtar man hem shapefiler från NVDB. Dessa, eller
andra nya filer, redigeras i lokalt GIS-system. Färdigredigerade
shapefiler hämtas ur GIS-systemet och bifogas ett mail. Mailet
kompletteras med fil med företeelser varpå det skickas till Trafikverket
för beredning och registrering
8 Just idag fungerar inte vägnätsredigeraren och NVDB tillsammans men
målet är att både geometrier och företeelser ska uppdateras lokalt och
med automatik överföras till NVDB. När det är godkänt och inlagt där
så ska återrapportering till vägnätsredigeraren ske med automatik, via
NVDB:s webtjänst, som nattetid överför inkrementella uppdateringar.
9 Kommunen använder produkten Movits Gata i det kommunala arbetet.
Movits kan plocka ut utdrag och lista inventarier. Dessa listor kan sen
importeras till vägnätsredigeraren och ev förändringar ska sedan
skickas upp till NVDB för registrering där (och sen återrapportering
tillbaka till vägnätsredigeraren).
10 Via mail så lämnar kommunen in geometriunderlag . Ett antal
företeelser kan också skickas med. Om det saknas företeelser så
återkopplar Trafikverket och frågar, alternativt listar ut värdena via
omgivande värden. Kommunen hämtar tillbaka NVDB-data via
Lastkajen
11 Geometrier lämnas som bilagda filer i ett mail. Företeelser lämnas med
automatik via webtjänst som nattetid hämtar uppdateringar i den
lokala vägnätsredigeraren och laddas upp till Trafikverket/NVDB (sköts
av annan avdelning. LTF:er rapporteras till Transportstyrelse varifrån
Trafikverket hämtar informationen och lägger in i NVDB.)
12 Tidigare inrapportering av både geometrier och företeelser via Slussen
men numera via NVDB på web 2012. Hämtar i princip inte ut data
(tittar bara i NVDB).
3b
Vad fungerar bra med er(a) metod(er) att lämna/hämta vägnätsdata
till/från NVDB idag?
datalev.
1 Det mesta fungerar bra
2 Ambitionsnivån är (idag) lagom för kommunen. (3 st)
3 Det är enkelt och lättanvänt
4 Skicka in enkla shape-filer. Hämta hem NVDB-uppdateringar med
automatik via webbtjänst
5 Nu ser man fram emot att jobba aktivt med NVDB på web 2012. (2 st)
6 Fungerar bra för oss. Samma medarbetare jobbar vintertid regelbundet
med vägnätsredigeringar så de har god insikt i hur man ska rapportera
våra vanligast förekommande geometrier och företeelser.
3c
Vad fungerar mindre bra med er(a) metod(er) att lämna/hämta
vägnätsdata till/från NVDB idag?
1
2
3
4
5
6
7
datalev.
Det är ett omfattande jobb för kommunen att översätta geometrier från
deras kommunala nätverk till NVDB. Kommunen anser att det är
nödvändigt att använda en egen Oracle databas parallellt med
vägnätsredigeraren idag. Problemet med NVDB datat är att
utbredningen av vägnamnsgeometrierna inte överensstämmer med
referenslänkarna hos NVDB. I Oracle db är allt data kopplat på
väglänken, vilket gör att de kan göra sökningar på vägnamn.
Just nu är det problem med skräptecken i XML-filerna, se 1b ovan.
Kommunen behöver internt styra upp synkning och uppgifter. Ärenden
har ramlat mellan stolarna. Problemet är identifierat och möten ska
hållas kring arbetet med NVDB-underhåll. (2 st)
Kommunen känner sig lite osäker kring tidsmarkering på inrapporterat
data. Kommunen vill ha kontinuitet i uppdateringen av systemen.
Ibland har man problem att avgöra vilken information som är yngst,
den i de lokala systemen eller den i NVDB.
Att vi inte kan skicka varken geometrier eller företeelser direkt från
vägnätredigeraren till NVDB (synkroniseringsproblem). Att få igenom
en export till NVDB kräver handpåläggning och då ”kostar det mer än
det smakar” så kommunen använder metoden med shape-filer i mail
istället.
Organisatoriskt har man problem inom kommunen då inte alla jobbar
enligt de regler som har tagits fram. Olika kommunala avdelningar
synkar inte. Man uppskattar att av ett hundratal större ombyggnader så
inrapporteras ca 50…. Problemen ligger nog inte hos entreprenörerna
som gör som de blir tillsagda. Snarare är det byggledare i kommunen
som inte är på hugget utan låter tiden gå innan ev inrapportering av
underlag för vidare överföring till NVDB görs.
Ibland kanske kommunen kunde vara snabbare med att få in
projekteringsinformation. Man är lite underbemannad också.
Intressanta enskilda synpunkter:
”Idag finns inte någon kommunal samordning av leveranser till NVDB. Jag
levererar vägnät och gatunamn men har ingen kontroll om och hur
Gatukontoret levererar övriga företeelser.”
”Efter möte med vår tekniska avdelning så kommer stadsbyggnadskontoret
att samordna information som skall till Trafikverket/NVDB.”
”Vi kommer att ha krav i upphandling av vägbygge att inrapportera
mätdata till stadsbyggnadskontoret för uppdatering av kommunens
primärkarta.”
3d
Förslag på förbättringar när det gäller er(a) metoder att lämna/hämta
vägnätsdata till/från NVDB?
datalev.
1
2
3
4
5
Vägnätsredigeraren och hanteringen med överföring av
vägnätsredigeringar måste bli enklare och mer strömlinjeformad.
Målsättningen är att både (standard-) geometrier och företeelser ska
kunna uppdateras och levereras med automatik från lokal applikation
via NVDB:s webtjänst exporteras till NVDB.
Kommunen efterfrågar en utvecklad samling tjänster (standardfrågor,
listor, rapporter etc., jmfr LMV:s nya tjänster), alt. stöd för egna frågor
mot NVDB-databasen (liknande SQL-frågor). Fördelen blir att slippa
lagra data lokalt och att de kan användas direkt från applikationer
Önskemålet är automatisk export och import av vägnätsuppdateringar
till/från NVDB
Man har för avsikt att gå över till att använda NVDB på web 2012 då
den har funktioner som bör underlätta för dem att registrera. Det är
viktigt att finns olika typer av hjälp i systemet som minskar
felaktiga/saknade/ orimliga inmatningar
Applikations-/systemstöd och arbetet med in-/utdata och NVDB?
Avser applikationerna
- ”NVDB:s webapplikation för hämta filer”
(in-/utcheckning),
- ”NVDB på web” (karta på web, rapportera
fel/saknad info, nuvarande version)
4a Vilka är de största ev. generella problemen idag med NVDB:s applikations/systemstöd (i samband med att lämna/hämta vägnätsdata till/från
NVDB)?
datalev.
1 Problem med vägnätsredigeraren.
2 Problem med skräptecken i XML-filer från NVDB.
3 Att vald vägnätsredigerare inte stöder automatisk inrapportering också
av uppdaterade företeelser. Det är en orsak till att incitament för
automatisk inrapportering via den inte väger upp investeringen.
4 Kommunen upplever inga större problem att rapportera in geometrier
och företeelser. Man använder Lastkajen för att hämta filer från NVDB.
5 Att synkningstabeller mellan NVDB och vägnätsredigeraren inte
fungerar. Just nu törs man inte röra något varför NVDB inte
uppdateras och kommunens vägnätsredigerare står still.
6 Inget speciellt. Det fungerar bra för kommunen.
4b
Vilka är de viktigaste ev. förändringarna med NVDB:s applikations/systemstöd som ni skulle vilja få till (i samband med att lämna/hämta
vägnätsdata till/från NVDB)?
datalev.
1
Vid hämtning av vägnätsdata från NVDB vore det bra om man kunde
selektera hämtning på olika parametrar. T ex tycker kommunen att det
borde finnas fler områden att välja på. Idag kan man bara välja egen
kommun eller egen kommun + alla kranskommuner. Varför kan man
inte välja egen kommun och bara en av kranskommunerna t ex?
2 Kommunen känner sig lite osäker kring tidsmarkering på inrapporterat
data. Kommunen vill ha kontinuitet i uppdateringen av systemen.
Ibland har man problem att avgöra vilken information som är yngst,
den i de lokala systemen eller den i NVDB.
4c
1. Använder ni NVDB:s webapplikation för hämta nvd-/XML-filer?
2. Hur ofta ungefär?
3. Hur väl fungerar NVDB:s webapplikation?
4. Hur borde den ev förändras?
datalev.
1-2a Används inte ofta. (2 st)
b Innan man fick igång den dagliga nedladdningen av förändringar så
användes NVDB:s webapplikation, men idag är det sällan.
c Används ibland. Ca 2 ggr/år för att hämta filer till ena systemet. Ibland
gör kommunen en total ”nystart” av NVDB-datat i vägnätsredigeraren
och då används också denna funktion.
d Används inte. (2 st)
3a Den gör sitt jobb.
3b Hämtningen till vägnätsredigeraren fungerar bra.
3c När man körde applikationen hade man problem med bl a samtidiga
utcheckningar av samma område med påföljande låsningar vid export
av uppdateringar (för den som checkar in som nummer två).
4 Kommunen efterfrågar en samling tjänster (standardfrågor, listor etc.),
alternativt stöd för egna frågor mot NVDB-databasen).
4 Det kan vara svårt att veta vilken version av XML som man ska hämta.
Felmarkering av version har också förekommit. Hämtning av XML-filer
kräver uppdelning av materialet då de är så stora. Detta borde systemet
med automatik klara av att göra!
5 (Använder Slussen)
4d
1. Använder ni NVDB på webb (karta på web)?
2. Om ja, nuvarande version eller version 2012?
3. Hur ofta ungefär?
4. Hur fungerar NVDB på webb?
5. Hur borde den ev förändras?
datalev.
1a
1b
1c
1d
1e
1f
Har precis börjat jobba med den.
Ibland (3 st)
Har inte använt NVDB på web hittills men ska testa 2012, låter bra.
Används för att titta på ändringar.
Ja. (3 st)
Har kört både nuvarande och äldre versionen och de fungerar bra. Vi är
nöjda.
1g Ja vi kör 2012 regelbundet idag.
2a
2b
2c
2d
Den nuvarande, äldre versionen. (4 st)
NVDB på Web 2012. (4 st)
De har även testat betaversionen av 2012 varianten.
Man kör vers 2012, men har även använt den äldre versionen då och då.
Även den har fungerat men har varit lite ”knölig”.
2e Båda, fast mest den äldre.
3a
3b
3c
3d
Enstaka gånger hittills (namnsätta gator).
Några gånger per vecka.
Då och då.
Vet inte dagsläget- Målet är att version 2012 ska ut på fältet för ”all”
daglig registrering istället för dagens blanketter.
3e Man jobbar ofta med NVDB på vintern. De viktiga årliga nya
satellitbilderna släpps i dec/jan. Då tillbringar man mycket tid med att
jämföra fotona med inkomna anmälningar.
3f Någon gång i månaden.
3g ca 10 ggr/år.
3h ca ett ärende per dag.
4a Bra hittills (7 st)
4b NVDB på Web 2012 fungerar alldeles utmärkt. Den är jättebra när man
kör på en läsplatta ute på fältet. När man hittar fel ute på uppdrag så är
det väldigt enkelt att registrera dessa, kommentera och skicka in till
Trafikverket. Kartbilden i vers 2012 underlättar mycket.
4c Den äldre versionen upplevdes som långsam.
4d Nöjd med den gamla varianten, men 2012 är spännande då omtalade
förbättringar av användargränssnitt, snabbhet mm gör den intressant.
4e Har prövat den nuvarande äldre versionen av NVDB på web några
gånger. Den fungerar bra men är lite långsam vid uppdateringar.
5a Det enda som ev. saknas (för 2012) är stöd för summering av
väglängder för väghållare.
5b (En detalj man vill ändra på är den röda färgen som lyser upp när man
tänder upp en väg i NVDB 2012. Den är väldigt svår att se varför en
annan färg vore bra. Ett annat önskemål är att kunna markera flera
länkar samtidigt och lägga in samma uppsättning företeelser på dessa,
”massregistrering”).
5c Den bör stödja användande av satellitbilder.
5d (Är intresserad av nya vers 2012 och kommer att testa den när det blir
möjligt).
5e Ska testa vers 2012 först. Låter intressant och förhoppningsvis kan den
fungera bra för kommunens behov. (2 st)
Regelverk för leverans av geometri, topologi, tid mm
5a
Vilka är de största ev. generella problemen ni ser idag med leverans av
1. geometri
2. topologi, eller via system
datalev.
1-2A Det är ett svårt hantverk. Enda sättet att komma in i det är att nöta
på. (4 st)
b Förenkla om möjligt regelverket.
c För nybörjare är det nog enklast att försöka jobba med NVDB på Web
2012. Där har man stöd för den viktigaste indatahanteringen.
d Ett visst stöd kan man få från det sedan många år etablerade
samarbetet med övriga grannkommuner i NVDB-frågor.
e Har fungerat bra hittills. Problemen är snarare att få in indata.
f Det är väldigt svårt att få till allt korrekt. Speciellt vid ny leverans då
det ofta blir fel både i geometrier och företeelser. Detta beror på att
hanteringen görs alltför sällan så man hinner glömma.
g Idag jobbar man mycket med satellitbilder där skogsvägar syns som
streck i kartan som man då kan skapa geometrier kring. Tidigare hade
man problem med förskjutningar i sidled men dagens satellitbilder har
minimerat dessa effekter.
h Skogen har färre företeelser att hantera än t ex kommuner, samtidigt
som de inte förändras mycket över tiden. Det gör att det är enklare att
underhålla dessa värden.
Det krävs att man följer reglerna.
Det är svårt för mindre kommuner/sällananvändare att hålla sig ajour
med alla regler och instruktioner. En lösning är att köpa in en konsult
vid de få tillfällen per år det gäller, alternativt att gå samman i cluster.
k En lösning för t ex mindre kommuner kan vara att gå samman i cluster
som stöttar varandra kompetensmässigt och med resurser vid t ex drift
och upphandlingar. I denna kommun är XX ofta ensam och måste själv
hitta information och lösningar, något som tar tid och energi.
l Det fungerar ganska bra för kommunen. Man klarar av det som behövs.
Inget speciellt organiserat samarbete med andra kommuner, men det
finns ett nätverk av kommuntjänstemän i regionen som bl a jobbar med
geometrier. De träffas då och då och diskuterar bl a NVDB-frågor.
M Det rullar på ganska bra med inrapportering av både geometrier och
företeelser. När man har frågor eller problem så får man alltid hjälp av
Trafikverket så processen stannar inte av.
i
j
Intressanta enskilda synpunkter:
”När man nu alltmer går över till att registrera uppdateringar i NVDB på
web 2012 så kommer ett antal skarpa indatakontroller att saknas. Det är
nu möjligt t ex att skicka fritextsträngar i många inmatningsfält även om
meningen är att fritext endast ska användas till generell information. Vi får
se om detta blir ett problem.”
”Kommunen ser inget behov av vägnätsredigeraren och den kostnad det
medför då Trafikverket fortfarande kan ta emot underlag och skapa
geometrier till NVDB.”
”Kostar tid, pengar och resurser att bygga upp organisation och
verksamhet för att få bättre interna rutiner och leveranser. Inte alltid lätt
att motivera arbetet.”
5b
Vilka är de viktigaste ev. generella förändringarna av arbetet med leverans
av
1. geometri
2. topologi, eller via system?
datalev.
1-2a Ett stort generellt problem är kommunernas begränsade motivation
för detta arbete. Kommunerna har ett jämförbart förhållande till LMV
där uppdateringar ska skickas in, men där det fungerar det bättre. Vi
tror att detta beror på LMV:s annorlunda betalningsmodell. Att hämta
hem information från NVDB om den egna kommunen samt
kringkommuner är gratis. Som motprestation ska kommunerna i god
tid gratis uppdatera NVDB med alla vägförändringar som görs i
kommunen. Moroten i detta upplägg räcker inte till för att
kommunerna ska prioritera upp detta uppdateringsarbete och lägga
resurser där.
b Nyckeln till att förenkla arbetet är ett enkelt verktyg att hantera!
c Att grupper av kommuner slår sig samman i kluster kommer nog att bli
allt vanligare. Medlemskommunerna kan då samarbeta kring
standards, stötta och samarbeta i NVDB-frågor, upphandlingar mm
(jämför Södertörngruppen).
d Man efterlyser utökade möjligheter till selektering av utdata.
Defaultvärdet att man kan hämta ned NVDB-data om egna kommunen
plus angränsande kommuner är alltför snävt. Speciellt i fall där en
e
c
d
e
f
g
h
grupp av kommuner har gått samman så vill man förstås kunna få ut
information från alla ingående kommuner. Data kring t ex ett
cykelvägnät som går över flera kommungränser bör man kunna få ut
som en helhet även om alla kommuner inte gränsar till varandra.
Tekniken borde kunna vara enklare. Systemen skulle kunna vara
smartare då det finns regler att förhålla sig till. Detta borde kunna
utnyttjas.
Man skulle vilja få in s k traktorvägar, åtminstone som ett stödskikt i
tillämpningen.
Man tror mycket på NVDB på web 2012 och vill att den får kraftfulla
valideringar på fältnivå så att ifyllt formulär är så korrekt som möjligt,
allt för att minimera återkoppling med frågor osv.
Kommunen ser den interna hanteringen av NVDB-relaterade frågor
som den mest akuta att komma till rätta med, framförallt då
synkroniseringen kring vem som gör vad.
Kommunen vill få blanketter och stöd för företeelserapportering från
Trafikverket. Blanketterna ska dels användas av kommunen själv vid
inmatning av underlag, dels ska man kunna ge dem till entreprenörer
för att tydligt peka ut vilken information man behöver få av dessa för
vidareförmedling till NVDB.
Trafikverket har tidigare distribuerat (?) Dataspecifikationen (vägnät
och företeelsetyper) med information sorterat per typfall, t ex refug
eller rondell som dokument. Detta var mycket uppskattat, informativt
och lättanvänt. Kommunen ser gärna att dessa dokument underhålls.
Man är mycket känslig för fel i NVDB kring framförallt vägmätningar.
Ett tag fanns det kvalitetsproblem kring vissa områden, däribland
Funktionell vägklass.
Intressanta enskilda synpunkter:
”LMV:s modell är istället att kommunerna får betalt för uppdateringar,
men får då också betala för att hämta ned information från LMV:s
databaser. Tydligen fungerar det bättre.”
”Trafikverket borde ta fram enkla checklistor på vad man ska tänka på vid
uppdateringar av olika objekttyper: Vid en ny rondell ska företeelserna
XXX beskrivas samt kompletteras med kartbild. För ny gata gäller YYY,
osv.”
”Kostar tid, pengar och resurser att bygga upp organisation och
verksamhet för att få bättre interna rutiner och leveranser. Inte alltid lätt
att motivera arbetet.”
Ledtiderna från leverans av er tills inlagt i NVDB?
6a
Hur upplever ni att ledtiderna är för era inleveranser fram tills att data
ligger i NVDB?
datalev.
1 De är definitivt alltför långa.
2 För standardfall så går det ganska bra. Trafikverket håller utlovade
tider. Det är när det uppstår komplikationer som det drar ut på tiden.
3 Lite oklart hur läget är här. När det gäller indata från entreprenörer så
förekommer det nog att de ibland är sena.
4 I och med att man inte använder NVDB-data i egna system så är man
mindre känslig för ev ledtider i NVDB-hanteringen.
5 Det går tillräckligt snabbt. (2 st)
6 Inga problem. Dels går det hyfsat snabbt, dels har man inte den
känsligheten att data måste väldigt snabbt in på plats. (3 st)
7 Kommunen vill rapportera in projekteringsinfo för geometrier så att
LTF kan uppdateras i god tid. Ibland får dock kommunen inte in
relationshandlingar till kommande byggen i tid varför detta hackar lite.
Intressanta enskilda synpunkter:
”När man redigerar i det gamla vägnätet kan det krångla. Nya enskilda
gator går smärtfritt.”
”Incitamenten för andra avdelningar på kommunen att jaga in information
till NVDB är ibland begränsad. Det krävs konkret nytta ibland för att få
igång arbetet. Ett exempel på detta är att trafikingenjörerna på kommunen
som använder vägnätsredigerarens LTF modul för att skapa sina LTFer.
Till kommunens vägnätsredigerare tankas varje natt ner nytt förändrat
vägnät från NVDB. Om inte vägen finns i NVDBs vägnät kan de inte
registrera någon LTF i vägnätsredigerarens LTF modul för den
vägsträckan.”
”Det finns tudelade uppfattningar om värdet av att lägga in preliminära
projekteringsdata i NVDB och jobba med färdigtidpunkter. Om dessa
preliminära data glöms bort att korrigeras när slutliga exakta värdena är
satta så kommer NVDB också att halta.”
6b
1. Vad kan göras av er för att om möjligt korta ledtiderna?
2. Vad kan göras av Trafikverket/NVDB för att om möjligt korta
ledtiderna?
datalev.
1a Kommunen kan försöka att få in projekteringslinjer snabbare istället
för att vänta på inmätta relationsdata. (2 st)
1b Så långt det är möjligt kan kommunen ligga före den fysiska
implementeringen med uppdateringar i NVDB. Kommunen kan idag ta
del av primärkartan från stadsbyggnads-kontoret och komplettera med
prognosticerat färdigdatum från entreprenörer vilket möjliggör
uppdatering av NVDB i förväg.
1c Kommunen måste ligga på och jaga in data från entreprenörer och
projektledare. Kommunen försöker undvika att samla på hög och skicka
in hela ”batcher”.
1d Kommunen har problem att få in information från entreprenörer som
gör vägarbeten. Också i de fall då de försöker rapportera in data så
förstår de ofta inte hur företeelser ska registreras så att det passar i
NVDB. Ibland har också kommunens egna projektledare som är
involverade i vägbyggen svårt att förstå hur datat ska fyllas i. Vi borde
därför försöka förbättra rutiner och information till entreprenörer.
1e Den stora ledtiden uppstår för skogsnäringen då man inte har något
fungerande rapporteringssystem för vägnätsförändringar från
chaufförer, virkesköpare, skogsägare mfl. Det är ett strukturellt
problem då inrapportering inte ingår i deras arbetsbeskrivningar och
det inte heller finns något större incitament för att inrapportera.
1f En möjlighet är att kommunen, och Trafikverket, jobbar med
projekteringsdata ”i förväg”. Man använder då projekteringsfiler för att
registrera det i NVDB. När öppningsdatumet sedan närmar sig så
kontrolleras om man fått nytt material som kan jämföras med det som
blivit registrerat i NVDB som framtida nät och vid behov görs
uppdateringar.
1g Försöka få in underlag snabbare, t ex genom att systematiskt använda
blanketter som delas ut till entreprenörer.
1h Man anlitar ofta entreprenörer för byggnad av skogsbilvägar. De saknar
kunskaper om NVDB - företeelser så man har tagit fram lathundar . Om
informationen ändå inte kommer fram så får man jaga på. Man vill
helst lägga alla egna uppdateringar själv. Detta insamlingsarbete kan
förstås alltid snabbas på.
2a Trafikverket måste jobba på att få ner de interna ledtiderna så att
uppdateringar kommer tillbaka ASAP, gärna nästa dag. (2 st)
2b Bättre info om förändringar.
2c Bättre kommunikation med systemleverantörer.
2d Nytt enkelt webgränssnitt för indata.
2e Trafikverket borde ta fram pedagogiska broschyrer att ge till
entreprenörer som beskriver varför och hur NVDB-data ska redovisas.
Om kommunerna i god tid kan ge dessa broschyrer till anlitade
entreprenörer/projektledare så skulle informationsinsamlingen gå
lättare och snabbare!
2f Man jobbar oftast med tunga NVDB-uppdateringar på vintern. De
viktiga årliga nya satellitbilderna släpps i dec/jan. Då tillbringar man
mycket tid med att jämföra foton med inkomna anmälningar. Vid
konstaterad vägbyggnation genom fotogranskning så skickas utskick till
markägarna, normalt kring mars varpå svaren droppar in fram till
sommaren. Där så behövs kompletteras/justeras inregistrerade värden
kommande vinter när vädret gör att det är svårt att jobba ute på fältet.
Skulle man jobba hela året med registreringar skulle vissa
nya/förändrade vägar upptäckas snabbare och då kunna inrapporteras
till NVDB.
Intressanta enskilda synpunkter:
”Incitamenten för att gå vidare till inrapportering av geometrier via
vägnätsredigeraren och automatisk inrapportering till NVDB inte är
tillräckliga, trots att detta skulle snabba upp processen.”
”Resurser för dessa aktiviteter är begränsade vilket också begränsar
svängrummet.”
”Vi måste få skogsbranschen att inse att alla skogliga aktörer (inte minst
virkesköpare) måste rapportera in nya vägar/vägförändringar. Detta är
viktigt inte minst för att applikationen Krönt vägval ska fungera. Den
bygger på SNVDB som i sin tur bygger på NVDB. Applikationen används
till transportplanering samt olika ersättnings-/kostnadsberäkningar. Om
data om skogsbilvägar saknas i NVDB/SNVDB så missar Krönt vägval
olika annars möjliga lösningar och beräkningar alt. missar viktiga
begränsningar med ibland mycket kostsamma följde.”
”Man hoppas att produkten Krönt vägval ska skynda på inrapporteringen.
Den bygger på SNVDB, som i sin tur bygger på NVDB, och syftar till att
optimera virkeskörningar/rutter, beräkna ersättningar mm. Om inte
skogsbilvägar finns registrerade i NVDB/SNVDB så fungerar den sämre
varpå ersättningar, vägval också fungerar sämre, eller inte alls osv.
Framförallt virkesköpare har ett intresse av att få systemstöd för vägar och
vägval så att de kan hämta ut virket på ett ekonomiskt sätt samt
betala/erhålla korrekta ersättningar. I Norrland har Krönt vägval ännu inte
slagit igenom överallt, utan andra äldre system används som inte på
samma sätt stöder inrapportering av nya/förändrade skogsbilvägar till
NVDB/SNVDB.”
Avslutning, rekommendationer, övrigt
Några avslutande funderingar på förändringar/förbättringar?
7a Något mer att tillägga till kommentarerna ovan kring
1. stödet från Trafikverket?
2. ev teknikstöd?
3. dokumentationen?
4. utbildningsmöjligheter?
5. övrigt?
datalev.
1a I takt med att det blir vanligare med samarbete mellan kommuner i
NVDB-frågor så borde Trafikverket vara lite proaktiva och komma
dessa kluster till mötes i olika frågor: ”Om ni går ihop i denna fråga så
har vi en lösning för det.”
1b För det mesta fungerar kontakterna med Trafikverket bra och enkelt!
1c Man är nöjd. De har t ex deltagit som pilot i uttestandet av NVDB 2012.
Man upplever att Trafikverket har tagit till sig de synpunkter man haft.
När man har problem så får man stöd.
1d Samarbetet med NVDB/Trafikverket har varit bra. Det rullar på.
2a Hög prioritet att få till tekniken så att så mycket som möjligt kan gå med
automatik typ NVDB:s webtjänst.
2b Det är snarare teknikstödet som hackar
3a Vi vill ha bättre dokumentation kring vägnätsredigeraren samt mer
stöd.
4a -5a Behov av kontinuerlig samordning mellan dataleverantörer,
systemleverantörer och Trafikverkets NVDB-organisation. Det kan vara
återkommande träffar, gemensamma aktiviteter etc.
5b Vi önskar att NVDB skulle tillhandahålla ett vägnät som är anpassat för
ruttning i andra system. Som det är nu måste man göra en massa
manuella justeringar för att kunna använda vägnätet. Detta är något
som görs på flera olika håll. Ex Cartesia gör detta för att kunna använda
NVDB i skolskjutssystemet som de levererar. Det borde vara
samhällsekonomiskt att göra det på ett ställe.
5c Kommunernas engagemang i NVDB-arbetet beror helt på hur lätt det är
att jobba med NVDB, både beträffande informationsinnehåll och
teknik, och vad man får ut för reell nytta av NVDB-utdata i den
kommunala verksamheten. Överväger inte nyttan avtar direkt
engagemanget. ”Ju lättare, desto mer!”
5d Vi är kritiska till att Trafikverket i den senaste
informationsmodellremissen har avvikit från den SIS-standard för väg
och järnvägsstandard som finns sedan tidigare. Betydelsen av lojalitet
gentemot etablerade standarders är ovärderlig.
5e Önskvärt om systemleverantörerna agerade lite snabbare när så
behövs!
Intressanta enskilda synpunkter:
”Man betonar att Trafikverket nu inte får slå sig till ro utan att man
kontinuerligt vidareutvecklar applikationerna, inte minst NVDB på web
2012. Det händer så mycket på olika håll inom GIS-världen att det är
viktigt att hänga med, inte minst när det gäller användargränssnitt så att
användare känner igen sig när de kommer in i applikationen.”