Import/Catalogue/Sweden highway import/Import guidelines

From OpenStreetMap Wiki
Jump to navigation Jump to search

Introduktion

Det här är en praktisk handledning på hur man importerar vägdata från Trafikverkets nationella vägdatabas (NVDB) till OSM. Filerna i NVDB har shape-format och måste konverteras till OSM:s XML-format innan de kan importeras. Konvertering görs med skriptet nvdb2osm. Färdigkonverterade filer per kommun finns att ladda ner från sida: Genererade osm-filer.

Syftet NVDB-importen är att höja kvalitetsnivån av OSM:s vägnät i Sverige. Lägga till vägar som saknas, förbättra geometrin (hur det är ritade) och lägga till mer information som vägnamn, hastighetsgränser, vägbeläggningar, trafikförbud m.m. I uppdateringsarbetet ingår även att korrigera positionsfel på omgivande naturpolygoner och byggnader, så att dessa inte korsar vägar.

NVDB är dock inte helt perfekt. Alla vägar finns inte med och detaljnivån i städer kan vara förenklad. Dessutom klassificerar inte NVDB vägar på samma sätt som OSM vilket försvårar konverteringen mellan NVDB och OSM. Man kan alltså inte blint ersätter OSM-vägar med NVDB-vägar. Man måste i varje enskilt fall bedöma resultatet av en uppdatering. Det gör att importarbetet är tidsödande och tar lång tid. En genomsnittlig landsortskommun kan ta i storleksordningen 40 timmar att importera, och kommuner med stora städer tar betydligt längre tid.

NVDB uppdateras hela tiden med ny information från kommuner och privatpersoner. Efter en import så kommer det därför efter en tid finnas skillnader mellan NVDB och OSM. Största delen av vägnätet är dock tämligen statiskt. Genom import av NVDB får OSM en generellt bättre kvalité på vägnätet, vilket i sin tur förenklar det framtida underhållet.

Uppdatera hel kommun eller bara delar?

Uppdatering av vägar sker per kommun. Det varierar hur väl kartlagt Sverige är på olika ställen i landet, men grovt kan man säga att så mycket som 80 - 90% av alla vägar finns redan i någon form. Oftast saknas det mer ju längre från bebyggelse man kommer. Det beror också på var det finns/funnits aktiva kartläggare, då de flesta kartlägger mest där de bor. Att en väg finns betyder emellertid inte att den har all eller rätt information om hastighetsgränser, broar, vägunderlag, vägnamn och så vidare. Tvärtom saknas det ofta viss information. Exempelvis är det ofta fel på hastighetsgränser, som ändras ganska ofta.

Vägar som kartlagts för flera år sedan har också ofta en markant sämre precision i geometrin (hur det är positionerade) än det som kartlagts senaste åren. Anledningen är att äldre ortofoton (geometriskt korrigerad flygbild) hade sämre precision än idag, och NVDB- och lantmäteriets ortofoton fanns då inte tillgängliga som referens.

Eftersom de flesta kartläggare fokuserar på att lägga till nytt snarare än att uppdatera gammalt så är det inte helt ovanligt med ganska stora fel på medelstora vägar, medan små nyligen tillagda vägar intill har bättre precision. Eftersom de har har kartlagts senare.

Mycket talar alltså för att man ska gå igenom och uppdatera alla vägar, även de som är kartlagda sedan tidigare. Det innebär dock att det tar lång tid att gå igenom en kommun.

När man gör validering finns det oftast många fel och varningar på annat än vägar. Välj själv om du även vill rätta sådant. Inte nödvändigt, men bra om du känner för det.

JOSM

Arbetsmetoden som beskrivs här, förutsätter att man använder JOSM. Den har många funktioner, vilket också göra att den har en inlärningströskel att komma över. Man behöver därför ha vana att arbeta med JOSM, innan man börjar med import av NVDB.

Installation

Hämta och installera JOSM från länken ovan.

Ställ in följande under Edit/Preferences:

  • Kryssa i "Expert Mode" längst ned till vänster.
  • Under "Language" "English" då de flesta hjälptexter är skrivna på engelska.
  • Under "Display" markera "Show object ID in selection lists".
  • Under "OSM Data" markera: Draw boundaries of downloaded data.
  • Under "Plugins" installera "utilsplugin2".

Validator

JOSM har en validator, med vilket man kan kontrollera det lager man arbetar med. Validatorn är ett viktigt verktyg i importprocessen.

Validatorn används för kontroll av:

  1. Nedladdad NVDB-osmfil före sammanfogning med tidigare osm-data.
  2. Pågående arbetet under sammanfogningen.
  3. Resultatet av sammanfogningen innan uppladdning till OSM.

Validatorn visar två typer av problem: Varningar och fel.

  • Varningar visas med en gul markering. Varningar kan man i vissa fall ignorera, om de inte har orsakats av nvdb-importen.
  • Fel visa med en röd markering. Fel måste man normalt alltid rätta.

Vanliga fel är:

  • Barrier=yes is unspecific:
    • Begränsad NVDB-information. Kanske kan du förbättra genom flygfoto.
  • Crossing highways:
    • Beror ofta fel/begränsningar i NVDB:s bro- och tunneldata, ibland saknas broar helt och hållet osv.
  • Missing tag - street with odd number of lanes:
    • På dubbelriktad väg med fler än två filer innehåller inte NVDB någon information om hur många filer som går i vardera riktning. Det går i regel lista ut från flygfoto.
  • Stub end:
    • Skriptet städar upp stumpar genom att länka ihop segment så långt som möjligt och ta bort små glapp, så de som ändå blir kvar bör man i regel lämna orörda.
  • Way end node near other highway:
    • Handlar ofta om hållplatser som rätteligen slutar nära en annan väg. Lägg gärna till noexit=yes på sista noden om det är lämpligt.
  • Overlapping highways / highway duplicated nodes / highways with same position:
    • I sällsynta fall har NVDB vägar med unika identifierare ("RLID" i NVDB-termer) som ligger ovanpå varandra. Det är så sällsynt så dessa fel korrigeras inte.
  • Suspicious roundabout direction:
    • Vissa rondeller är inte helt runda och då kan JOSM:s validator tro att de har felaktigt taggats som rondeller. Denna varning kan man i regel ignorera. Observera dock vägen i rondellen alltid ska var enkelriktad och gå i vänstervarv.

Arbetsflöde

Importarbetet består av följande steg:

  1. Välj kommun du vill uppdatera och markera den på progressidan.
  2. Ladda ned, läsa in och rätta NVDB-osmfil för kommun.
  3. Sammanfoga gamla osm-vägar med nya nvdb-vägar.
  4. Ladda upp sammanfogade vägar till OSM.
  5. Markera på progress-sidan att kommunen är färdigställd.
  6. Kontrollera kommunen på webben.

Det stora jobbet är att sammanfoga gamla och nya vägar. Det kan göras på två olika sätt:

  • Med "traditionella metoder" som copy/paste av taggdata, flytt av noder etc.
  • Med "Replace geometry". Vilket också är den rekommenderade arbetsmetoden som beskrivs i detta dokument.

Det finns ett par saker att tänka på:

  • Radera inte gamla vägar! Det gör också att historiken för vägen raderas. Dessutom kan det finnas tagg-info på gamla vägen som ska föras över till den nya vägen.
  • NVDB-lagret är inte alltid 100% rätt. Den kan innehålla fel eller inte är uppdaterad med ändringar gjorda i verkligheten. Felen finns oftast på mindre vägar, cykel/gångvägar med avseende på placering och ytskikt.

Välj kommun och markera på progressidan

På progress-sidan registrerar man kommunen man tänker uppdatera. Kontrollera så att kommunen inte redan är uppdaterad eller att någon annan redan har börjat med den.

Arbetstiden för att uppdatera en kommun beror på hur stor kommunen är (antalet vägar) och hur van man är att göra uppdateringar. Räkna med att det tar runt 40 timmar för en mindre landsortskommun. Större kommuner tar betydligt mer tid. Om man tycker att det är ett för stort åtaganden, finns vissa kommuner uppdelade i mindre delar. Arbetstiden dessa mindre delar ligger i storleksordningen på 5-10 timmar. Men även här beror det mycket på de specifika fallet och vanan att göra uppdateringar. Dessa mindre arbetspaket finns endast framtaget för vissa kommuner. Om man vill arbete med en kommun som inte är uppdelad (vilket kan ses på nedladdningssidan), meddela via epost (marsip at telia punkt com) vilken kommun du vill jobba med, så får du ett sådant paket skickat till dig.

Rekommendationen är att man som första kommun väljer en liten landsortskommun. Gärna någon i din närhet som du känner till. Vänta med större kommuner tills du blir van vid arbetssättet.

Ladda ned, läs in och rätta NVDB-osmfil för kommun

Ladda ned fil för önskad kommun från NVDB-osmfiler. Vissa kommuner finns uppdelade i delavsnitt. I dessa fall ladda ned både huvudfil och delavsnittsfiler.

  • Öppna huvud-osmfilen för kommunen i JOSM och gör en manuell validering.
  • Om fel finns, kan vissa av dessa behöva rättas i detta skede, men oftast kan det vänta tills sammanfogningen.
  • Markera allt (ctrl+A) och kontrollera vilka taggar som finns i "objects"-fönstret (som visar totalen för alla taggar).
    • Ibland finns det fixme-taggar skapade vid konvertering från nvdb-format till osm-format. Dessa kan orsakas av att det finns konflikter eller om NVDB inte har tillräckligt med information för konverteringen. För att hitta vilka vägar som har dessa fixme-taggar, använd JOSM:s sökfunktion och sök på fixme=*. Kontrollera vilken text som anges för fixme, och bestäm om rättning behöver göras direkt eller kan vänta till senare.
    • Kontrollera om det finns taggar som verkar vara ovanliga eller felaktiga. En del av dessa kan ha skapats vid konverteringen. Bedöm om dessa taggar är "skräp" och kan raderas, eller om de måste åtgärdas direkt eller senare.
  • Om delavsnittsfiler ska användas, utför även kontroll och rättning av dessa.
  • Om nvdb-filer har ändrats, spara lokala kopior av dessa.
  • Sätt skrivskydd på alla filer och gör gärna även säkerhetskopior.

Sammanfoga gamla osm-vägar med nya nvdb-vägar

Allt arbete med sammanfogning görs i ett arbetslager som innehåller:

  • Vägar från nvdb-huvudkommunfilen eller från någon av nvdb-delkommunfilerna.
  • Nedladdad data från osm för område som nvdb-filen täcker.

Arbetssteg

  • Skapa ett nytt arbetslager i JOSM i vilket allt arbete med sammanfogningen ska göras.
  • Om delkommunfiler används:
    • Kopiera hela delkommunfilen till arbetslagret.
    • Markera alla filer (ctrl+a).
    • Ladda ned från osm område som täcker alla markerade vägar. Beroende på hur stort området är, kan nedladdning behöva göras i flera omgångar.
    • Spara arbetslagret i en lokal fil.
    • Utför sammanfogning i arbetslagret.
    • Ladda upp till osm.
  • Om inte delkommuner används:
    • Kopiera hela nvdb-huvudfilen till ett nytt lager kallat nvdb-arbetslager.
    • Från nvdb-arbetslagret markera med "lasso"-verktyg en "lagom" mängd vägar. Kopiera så det blir få anslutande vägar in i området.
    • Kopiera de markerade vägar till arbetslagret (se första arbetssteget ovan) med "Edit-Paste at source position" (ctrl+alt+v). OBS! Menyalternativet visas endast om "Expert mode" (View-Expert Mode) är aktiverad.
    • Markera alla filer i arbetslagret.
    • Ladda ned från osm område som täcker alla markerade vägar. Beroende på hur stort området är, kan nedladdning behöva göras i flera omgångar.
    • Spara arbetslagret i en lokal fil.
    • I nvdb-arbetslagret radera alla markerade vägar (de som kopierades till arbetslagret) och spar resten i en lokal fil.
    • Utför sammanfogning i arbetslagret.
    • Upprepa ovanstående tills alla vägar i nvdb-arbetslagret är överflyttade och sammanfogade. Innehållet i nvdb-arbetslagret läses in från den lokala filen med sparat nvdb-arbetslager.

Oavsett vilken metod man arbetar efter (med eller utan delkommunfiler) gäller det att hålla reda på alla lokala filers innehåll och status. Det är lätt att göra misstag. Spara därför hela tiden säkerhetskopior på de olika lagren, och namnge dessa så att det är enkelt att gå tillbaka till en viss tidpunkt i sammanfogningen.

Vilken av ovanstående metoder man föredrar är en smaksak. I båda fallen får man dock problemet att koppla ihop gamla och nya vägar i "kanterna" på det område man arbetar med. Om man arbetar med delavsnitt, är delområden valda så att antalet "skarvar" mellan gammalt och nytt är minimerat.

Skriv- och uppladdningsskydd på nvdb-osmfiler

Om man av misstag laddar upp en nvdbfil till osm eller laddar upp ett lager där sammanfogning inte är klar, får man problem. Alla nvdb-osmfiler innehåller därför en spärr mot uppladdning. Denna spärr kan tas bort genom att öppna osm-filen i en editor och på 2:a raden ta bort texten "upload='never'", och sedan spara filen igen. Man bör inte ta bort spärren innan man är helt klar sammanfogningen. För att man inte av misstag ska ladda upp arbetskopian, innan sammanfogningen är klar, kan man i dess lokala fil addera liknande spärr.

Revert - Återställning av uppladdning

Om man av misstag laddar upp något till OSM kan man återställa/back uppladdning på två sätt:

Använda Replace geometry

Genom att installera plugin utilsplugin2 får man verktyget Replace geometry. Med vilket man utför sammanfogning av NVDB-vägar och gamla OSM-vägar.

Grundprincipen är att markera önskade segement på gamla och nya vägen, och exekvera Replace Geometry. Information (taggar) från gamla vägen flyttas över till nya vägen, varefter gamla vägen raderas.

Mer i detalj händer följande:

  • Historiken från gamla vägen, kopieras till nya vägens historik. Till nya vägens historik adderas en ny post som motsvarar uppdateringen. Detta gör att historik på vägsegmentet behålls, vilket är viktigt för att kunna spåra ändringar. Om gamla vägen har delats upp, hamnar historiken dock bara på en av de två delarna/segmenten. Även om historiken inte kommer med i alla segment, så ser "Replace geometry" till att så många noder som möjligt förs över från OSM-vägen till nya vägen.
  • Taggar och deras värden jämförs mellan gamla och nya vägen. Om samma taggar finns, men värden är olika, visas ett fönster i vilket man får man välja vilka taggar och vilka värden man vill att den nya vägen ska ha. Om någon tagg på gamla vägen inte finns på nya vägen, kopieras automatiskt den gamla taggen och dess värde till den nya vägen. Detta är något man får vara observant på, då den gamla taggens information kanske inte längre gäller.
  • Efter att kopiering av historik och taggar har utförts, raderas den gamla vägen.

För att kunna göra uppdatering måste man först markera vilka segment på gamla och nya vägen som ska påverkas. Om man har tur är antalet segment lika många och är ungefär lika långa, men så är det inte alltid.

Om antalet segment är lika och längden på dessa är ungefär lika långa

Markera motsvarande segment på gamla och nya vägen. Exakt passning är inte nödvändigt. Om längden på skiljer mycket mellan segmenten, bör det längre segmentet delas upp. Delning av gammal väg kan dock bara göras på en befintlig nod.

Om gamla vägen har färre segment än den nya vägen

Detta är mycket vanligt, då de nya NVDB-vägarna oftast har mer information än de gamla vägar, och att informationen är uppdelad på fler segment än tidigare. I dessa fall ska gamla vägen delas upp i motsvarande antal segment som finns på NVDB-vägen. Markera önskad delningsnod på gamla vägen och välja "Split way". Ibland finnas ingen lämplig nod där man kan göra brytningen. I dessa fall får man acceptera att vissa segment på den nya vägens segment inte blir uppdaterade från gamla vägen, utan man för vara nöjd med den info som följer med från NVDB.

Om gamla vägen har fler segment än den nya vägen

Detta är inte så vanligt, men eftersom den nya vägen kan manipuleras fritt utan att Replace Geometry klagar, så är detta oftast enkelt att hantera.

Innan man går vidare bör man undersöka varför den gamla vägen har fler segment än den nya. I vissa fall har intilliggande segment samma taggar och dessa kan därför slås ihop med "Combine Way". Om det inte fungerar, kan det bero på att segmenten inte är hopkopplade. Prova då först att göra "Merge" på den gemensamma noden för segmenten.

På nya vägen är det fritt att skapa nya noder för att få segment som matchar gamla segment. Nya noder skapas med "Draw nodes".

Allmänna synpunkter

  • Segment på gammal och ny väg bör vara på ungefär samma avstånd från vägens början (eller slut), så att platsinformation på gamla vägen förs över till den nya vägen på rätt plats. I vissa fall är det inte möjligt av tekniska skäl, utan man får kompromissa.
  • Gör gärna "Combine way" på intilliggande segment om taggarna är lika i båda segmenten.
  • Brytning av gammal väg behöver ibland göras på en specifik nod för att behålla en vägrelation som finns på anslutande väg. Var uppmärksam på relationsinformationen som visas i fönstret "Tags/Membership".
  • Större vägar har oftast också en relation, dessa ska behållas och visas i dialogfönstret som kommer upp vid uppdateringen.

Problem vid uppdatering

  • Om gamla vägen innehåller noder med objekt eller taggar, som exempelvis övergångsställe eller vändplan, så fungerar inte "Replace geometry" rakt av. Detta kan lösa på olika sätt. Exempelvis genom att först markera gamla noden och sedan en närliggande nod på nya vägen, därefter utföra "Merge Nodes". Om nod saknas på lämpligt ställe på nya vägen, kan en sådan skapas med funktionen "Draw Nodes".
  • Ibland grenar den gamla vägen iväg åt ett annat håll än den nya vägen. Då får man klippa isär vägarna och göra sammanfogning av delavsnitt. Klipp hellre isär nya vägen än gamla vägen. Vid generering av NVDB-vägar strävar man efter att sätta ihop så långa segment som möjligt. Där vägar grenar sig, föredras att följa den del som svänger minst. Det saknas dock information om kvalitén på vägen. Exempelvis i skogsvägar blir det ibland konstigt när en väg av god kvalitet gör en tvär sväng och fortsätter på en väg med låg kvalitet. Det är då lämpligt att klippa om vägen, så det blir mer logiskt med hur det ser ut i verkligheten.
  • Ett problem med "Replace geometry" är att den nya sammanfogade vägen inte blir kopplade med vägar som tidigare var anslutna till den gamla vägen. Om dessa nu löst hängande vägar även har en motsvarande ny NVDB-väg, ansluts de igen så småningom. I annat fall måste hopkoppling göras på följande sätt:
    • Korsa båda vägarna genom att flytta ändnoden för "lös" väg över andra vägen.
    • Använd funktion "Add nodes at intersection" (ctrl+).
    • Radera överskjutande del skapad på tidigare lös väg.

Övriga tips

  • Ha den nedladdade NVDB-osmfilen för kommunen inläst i ett eget lager. På så sätt är det enkelt att jämföra den med arbetslagret och exempelvis se vilka vägar som kommer från nvdb och vilka som kommer från osm.
  • Tidigare kartläggning kan innehålla utdaterade taggar som man bör plocka bort. Exempelvis source=* (source-tagg används inte längre, istället sätts source på själva changesetet).
  • Översättningsskriptet skapar inga relationsobjekt. Busslinjer, olika rutter mm. finns ofta redan inlagda som relationer. Se till att behålla dessa och att de kopplas ihop korrekt. Genom att använda "Replace geometry" så sköts mycket av detta automatiskt, men räkna med att relationer med många medlemmar (segment) kommer att innehålla fel orsakade av att nya segment tillkommer. Alla relationer behöver gås igenom innan uppladdning.
  • Vägar som fortsätter utanför nedladdat område kan bli avhuggna längs kanterna på området man jobbar med. Det kan vara frestande att låta dem vara okopplade och rätta det senare, men för att inte hamna i en situation med en trasig karta uppladdat till OSM, se till att koppla ihop vägarna längs kanterna med existerande vägar (om de finns). Justera de existerande vägarna istället för NVDB-vägarna, så när man tar in nästa del, passar de ihop
  • Jobbar man med stora mängder data finns det risk att något fel slinker igenom. På nätet finns flera webbsidor där man kan kontrollera sina uppladdningar exempelvis OSM Inspector och OSMOSE. Man behöver inte göra detta hela tiden, utan det räcker oftast att göra det en gång, några dagar efter man jobbat färdigt med en kommun.
  • Man får titta på lantmäteriets färska flygfoton.
    • Som nämns här länk är det okej att titta på lantmäteriets webbtjänst och flygfotona för att exempelvis se om en väg finns eller ej, eller avgöra andra saker som är otydliga på de bilder som finns förladdade i JOSM. Till exempel, att kontrollera nya skogsvägar på lantmäteriets flygfoton, innan man lägger till dessa i osm. Fotona kan också vara till hjälp för att se på vägmarkeringar för flerfiliga vägar. Eftersom Lantmäteriets flygfoton inte har CC0-licens, kan man dock inte sätta i system att kopiera från dem, men det är tillåtet att titta på hur något ser ut i detalj.
    • Lantmäteriets rasterkarta fanns tillgänglig direkt i JOSM hade när detta projekt startades som en extra zoomnivå: första nivån av "fastighetskartan" där man dels ser individuella byggnader, fler stigar och viktigast kartan har inte någon (signifikant) kartografisk generalisering, dvs att vägarnas position och form stämmer överens med verkligheten och är inte förenklad för att vara enklare att läsa i en karta. Det var dock aldrig meningen att denna zoomnivå skulle släppas fri under CC0-licens, så den togs bort hösten 2021. I skrivande stund (sommaren 2022) kan man alltså inte använda inbyggda rasterkartan som en pålitlig källa för positionering längre (är man osäker på position av NVDB-data och/eller flygfoto så är Strava heatmap ett mycket bra verktyg). Den fulla rasterkartan finns emellertid tillgänglig via lantmäteriets webbtjänst, och liksom ortofotona är det tillåtet att använda den för att ta reda på information, men inte systematiskt kalkera av.
  • Om du har en mus med flera extraknappar konfigurera gärna dessa till de vanligaste operationerna som "Replace Geometry" och "History".
  • Använd hjälptexter som visas med tangent F1 (windows). Om man har markerat en tagg för valt objekt/väg öppnas motsvarande hjälpavsnitt i osm-wiki. I annat fall visas hjälptexter för JOSM.

Det här arbetsmetoden kan verka svårt och komplicerad i början, men är efter ett tag inte svår att följa. Lär dig och använd kortkommandon så mycket som möjligt, det lönar sig i långa loppet.

Ladda upp sammanfogat lager till OSM

När man gör uppladdning till OSM, så gör JOSM en validering på sammanfogat lager, och visar eventuella fel och varningar. Normalt ska man inte ladda upp om det finns fel, utan dessa fel bör/ska rättas! Varningar kan man i vissa fall ignorera om de orsakas av något som inte beror på nvdb-importen. Om man har tid och lust, bör man även rätta varningar.

Vanlig fel:

  • Crossing highways
    • Uppstår ofta när man glömt kvar en dubblett eftersom den gamla och nya vägen nästan alltid korsar varandra på något ställe
  • Way end near other highway
    • Uppstår ofta när man glömt att koppla ihop vägar, eller när man glömt kvar en dubblett.

Vid uppladdning kan det bli konflikter, orsakade av att andra har laddat upp ändringar som berör de område man har arbetat med. Dessa konflikter måste åtgärdas och det går inte att göra en uppladdning innan alla konflikter är åtgärdade. Sök vidare på osm-wiki för anvisningar hur man åtgärdar konflikter.

Följande kommentarer ska anges för changeset vid uppladdningen: 

   description=Manual merge with NVDB data for <kommun>
   source=Trafikverket NVDB

För 'source' bör man ange alla källor man använt förutom NVDB.

När uppladdning har gjorts, bör man igen ladda ned hela området man arbetat med, och göra en ny valideringen. Om det finns fel eller varningar, kontrollera om dessa är inom området man uppdaterade. Om så är fallet och dessa beror på vägimporten, behöver de rättas. Var speciellt uppmärksam på eventuella avbrott på vägar som går över gränsen för uppdaterat område.

Efter en man är klar med en kommun, markera att den är klar på progress-sidan.

Kontrollera kommunen på webben

Efter några dagar utför kontroll av kommunen med med exempelvis OSMOSE och OSM Inspector. Om det finns några fel orsakade av vägimporten, ladda ned avsnitt som har fel, rätta fel och ladda upp igen.

Saker att tänka på vid sammanfogningen

Typiska fel i NVDB-datat

NVDB-datat har mycket hög grad av korrekthet, men det är inte 100% perfekt. Detta är några fel som observerats:

  • Bro-databasen har mycket fel, broarna kan vara 100 meter felplacerade eller för korta för att nå över älven. Broar kan saknas, särskilt för cykelvägar. Ungefär hälften av broarna behöver någon slags positions- och/eller längdkorrigering.
  • Där en bäck går under vägen i en stor vägtrumma kan ibland NVDB lägga in en mycket kort bro, fastän det inte är en brokonstruktion. Här är det bättre att ta bort bron och använda en kulvert för bäcken.
  • Broar som korsar andra vägar kan vara hopkopplade felaktigt i korsningen (JOSM Validator varnar)
  • Nya vägar kan ha preliminär geometri som inte är korrekt, händer relativt ofta i skogsbilvägsnätet t ex. Ofta har lantmäteriets rasterkarta hunnit få rätt geometri, och ibland har även flygfotona den nya vägen.
  • Gatunamn är i hög grad korrekt, men storleksordningen 1 av 1000 kan vara felstavat eller liknande, för skogsbilväg mer än så. Hur man hanterar vägnamn är dokumenterat separat.
  • I enstaka fall har anpassning av geometrin gjorts i NVDB för att ge utrymme i kartan, till exempel när cykelvägar går bredvid vägen inne i en stad kan referenslinjen för vägen vara lagd några meter åt sidan om vägens verkliga centerlinje.
  • I sällsynta fall (storleksordningen 1-2 ställen per kommun) kan en väg ha en liten parallelförlyttning med sväng där det egentligen ska vara en perfekt raksträcka.
    • Mer ofta kan landsvägars geometri vara lätt "vågig" när flera vägar ansluter i närheten av varandra, vid behov kan man snygga till det. Tertiära vägar brukar vara mest påverkade.
  • Enskild väg som är belagd kan vara markerad som grus
  • Vägar i små samhällen kan vara markerad som belagd även om det är en grusväg.
  • Original-datat har en hel del småglapp här och var (till exempel några meter längs en landsväg som saknar hastighetsgräns, eller en väg som inte går riktigt ända fram i en korsning). Skriptet klarar av att automatiskt reparera dessa fel för det mesta. I enstaka fall slinker fel igenom, och då kan exempelvis en skogsväg sakna sitt vägnamn över 50 meter eller så. Dessa upptäcker man normalt under sammanfogningsprocessen så man kan manuellt korrigera dem.
  • Dubbletter av parking=layby efter enstaka landsvägar, verkar kunna vara att gamla parkeringar blivit kvar efter vägen fått nya efter ett större underhåll.

Utöver rena fel så finns inte tillräcklig information i NVDB för att göra 100% korrekt översättning av highway-typen. Highway-typ handlar också i viss mån om personlig bedömning och i vissa fall är det "korrekt" med flera alternativ, vilket gör att en perfekt match hade inte varit att förvänta även om NVDB hade fullständig information. Därför ska highway-typ som skriptet valt bara ses som ett förslag eller gissning och det finns alltid behov av att ändra highway-typ på ett flertal vägar.

Det är också värt att notera att NVDB:s geometri är uppklippt i mycket korta segement. Skriptet sätter automatiskt ihop vägarna i så långa segment som möjligt för att göra geometrin lättare att jobba med. Segmenten bryts endast när informationstaggar byts. Oftast leder det till logiskt resultat, men ibland när exempelvis namnlösa vägar grenar sig kan det hända att skriptet väljer att följa "fel" gren. Om flera vägar har samma informationstaggar kan skriptet inte avgöra vilken gren som hör ihop med vägen som följs. Det väljer den gren som leder till minst sväng, vilket oftast men inte alltid är rätt. Ibland kan man alltså behöva klippa om dessa. Det är dock ingen katastrof om man missar det, eftersom det inte gör någon skillnad i routingen när taggarna är samma, men "rätt" kartlagt ska ett segment följa samma väg så långt det går, inte byta till en annan väg mitt i.

Highway-typ

NVDB har fältet "funktionell vägklass" som rangordnar vägar på en skala 0 till 9, där 0 är de största vägarna och 9 de minsta. Vid första anblick kan det verka som att det skulle gå att direkt översätta till OSM:s highway-typer, men i praktiken blir det endast en approximation. Det stämmer ofta, men inte alltid. Skriptet använder några ytterligare datalager från NVDB för att förbättra träffen, men i slutänden måste ändå typen ändras manuellt i storleksordningen 20% av fallen. Skriptet har svårast att göra rätt i "semi-urbana miljöer", det vill säga utanför städerna men inte direkt glesbygd.

Hur man väljer highway-typ i svenska förhållanden finns dokumenterat här: Sv:Map_Features. I det här avsnittet beskrivs lite mer detalj vilka typer av förändringar man i regel behöver göra och hur man kan tänka för att välja rätt typ.

Man kan ibland bli osäker om det ska vara den ena eller andra highway-typen. Det går inte komma ifrån att det finns knepiga fall där där olika personer kan göra olika bedömningar. Det viktiga är att man har en god avsikt och gör så gott man kan efter förmåga. Att det kanske hade blivit lite annorlunda med en annan kartläggare är okej. Det vi däremot inte vill se är att man blint behåller det skriptet gissat bara för att det är bekvämast.

Stora vägar

För vägtyperna trunk, primary, secondary och tertiary behöver man i stort sett aldrig ta ett beslut eftersom de vägarna redan är kartlagda, så man väljer helt enkelt samma typ som användes innan. Bland de stora vägarna finns det två undantag där man kan lita på NVDB, och det är motorväg (highway=motorway) samt motortrafikled (tilläggstaggen motorroad=yes), dessa är inte subjektiva rangordning som funktionell vägklass utan en skyltad vägtyp.

Om NVDB-lagret gissat fel vägtyp så är det en god idé att markera hela vägen i JOSM (filtrera på highway=xxx) och ändra till rätt typ innan man börjar köra replace geometry-arbetsflödet, det blir nämligen väldigt många extra klick i konflikt-dialogen om man behöver ändra highway-typ för varenda delsegment, och de stora vägarna har ofta många segment pga varierande hastighetsgränser, ändrad vägbredd, broar mm.

Städer, samhällen och byar

Vägar i "tätbebyggt område" pekas ut i NVDB och sätts till highway=residential av skriptet. Det blir sällan för många residential-vägar i översättningen, men däremot för få. Större byar som inte anses vara tätbebyggt område i NVDB ska fortfarande i regel ha residential-vägar i OSM. Gränsen när man använder residential istället för unclassified i en by eller samhälle är lite flytande och det är upp till egen bedömning. Residential-vägar förväntas i regel ha namn, och om de inte har det indikerar man det med noname=yes. Är man osäker om det ska vara residential eller service/unclassified kan man välja det senare om namn på vägen saknas.

Om husen står tätt liksom i en stad så är det en kandidat för residential. Vitt utspridda lantbruksbyar använder man unclassified för gemensamt brukade vägar, service för uppfarter till bostäder, och track för övriga grusvägar och traktorspår. Vissa byar kan ha en gles lantbruksdel och ett tätare byggt område, då kan det vara aktuellt att använda residential på endast de vägar som är i det täta området, man behöver alltså inte ha residential i hela byn bara för att man har det på ett ställe.

Större vägar i städer ska ibland vara tertiary eller högre istället för residential. Denna översättning missas ofta i NVDB-lagret eftersom nivåerna i NVDB stämmer dåligt överens med OSM-tradition. Eftersom städer i regel är väl kartlagda i det avseendet är det nästan alltid bäst att använda den vägtyp som finns sedan tidigare.

I OSM i Sverige är det ganska vanligt att vägar i städers industriområden satts till unclassified istället för residential, medan i NVDB-lagret översätts de till residential. Hur man ska göra där har inte varit så väl dokumenterat och det har förekommit olika traditioner parallellt. Efter diskussioner med flera svenska kartläggare har vi kommit fram till att det är att föredra som NVDB gör, vägar som tydligt hör ihop med själva stan ska vara residential även om det är i ett industriområde där det inte finns bostäder, så i det här fallet kan man behöva ändra typen som var satt innan. Inne i ett större samhälle och städer där gatunamn används på alla gator kan residential användas även på kortare stumpar som kanske varit service i en by, så länge de har gatunamn och är ansluten till övriga residential-vägnätet.

Små vägar

Vägtyperna unclassified, track och service är de knepigaste för skriptet att avgöra. Det beror på att de typerna inte mappar direkt mot en nivå som funktionell vägklass, utan det handlar till stor del om hur vägen används, och NVDB har inte den typen av information på små vägar. Genom att kombinera flera olika taggar ur NVDB-lagret och analysera geometrin kan skriptet göra en ganska okej gissning, men det finns garanterat behov av manuella justeringar. Hur mycket beror på lite hur geometrin ser ut, vissa områden är svårare för skriptet att avgöra än andra, men storleksordningen 20% fel får man räkna med.

Unclassified ska användas för vägar som leder någonstans, till en by eller som kopplar ihop andra större vägar, eller vägar som är mer allmänt använda än service och viktigare än track. Unclassified fungerar ungefär som residential i små eller glesa byar. Inte alla sammankopplande vägar ska vara unclassified, det måste vara rimlig bilväg som faktiskt används nu och då, så åtminstone motsvarande track tracktype grade3 eller bättre (oftast grade2 eller asfalt). Skriptet kommer i vissa fall gissa fel och göra dessa som track, eller göra vissa som borde var track till unclassified.

Track används lite speciellt i svensk kartläggningstradition. På många ställen i världen används track i stort sett bara till det namnet antyder, nämligen traktorspår där man inte gärna kör bil överhuvudtaget. I Sverige med vårt enorma grusvägsnät (som ofta hör ihop med skogsindustrin) används emellertid track även till "mindre viktiga grusvägar", och vill man ange kvalitet så använder man förslagsvis tracktype grade1 - grade5. Skriptet sätter inte ut grade, eftersom den informationen inte finns i NVDB. Vill man sätta ut grade rekommenderar vi detta:

  • Grade1: belagd väg, används nästan aldrig. Kan vara aktuell för gammal övergiven asfalterad väg. Internationella wikin ger exempel på asfalterad skogsbilväg som inte förekommer alls i Sverige.
  • Grade2: vanlig grusväg i gott skick, inga problem att köra 70 km/h med vanlig bil.
  • Grade3: grönsträngad grusväg, går i regel köra 70 km/h med vanlig bil, men med mer försiktighet.
  • Grade4: äldre mer eller mindre övergiven grusväg i dåligt skick eller traktorspår i lantbruket, går att köra SUV i lägre fart. Åkermarksvägar är typiskt framkomligare än skogsvägar med denna gradering.
  • Grade5: ännu sämre, troligen ej framkomlig med bil, traktor krävs. Används även för traktorspår i lantbruket som inte är anlagd väg utan går direkt över jordbruksmark, de är i regel framkomliga för bilar. Ser helt gröna ut på sommartidsflygfoto.

Om man inte anger kvalitet på sina track bör de vara grade3 eller bättre, alltså helt okej att köra en vanlig bil på. NVDB innehåller i regel bara sånt som motsvarar grade3 och bättre, men det finns undantag. Lantmäteriets rasterkarta har även grade4 och grade5-vägar, samt viss information om vägens kvalitet vilket man kan se på de olika typerna av sträckning i kartan. Använd dock helst flygfoto för att avgöra kvalitet, på de riktigt små enskilda vägarna har även lantmäteriets karta ofta fel i fråga om vägars kvalitet. Nyanlagda skogsbilvägar är lite knepiga då kan flygfotona ligga efter, och även NVDB. Rasterkartan brukar ha den senaste informationen.

Service ska användas för vägar som leder till ett hus, en strand, en camping, osv. Även här är internationella OSM-wikin lite luddig så man får titta på svensk OSM-tradition som komplement. Vanligast i fråga om NVDB är korta snuttar som går fram till enskilda bostadshus. Vill man vara extra duktig kan man lägga till taggen service=driveway på uppfarter, men försök då bara ta den del som går på tomten, och service-vägen är lite längre ska delen utanför tomten inte vara driveway.

Det finns ingen information i NVDB om vilka vägar som leder till bostäder så skriptet får gissa och gör en del fel, så vissa av vägarna blir kvar som track och behöver manuellt uppgraderas. Där kartläggning redan gjorts är det vanligt med flertalet kartlagda service-vägar som inte finns i NVDB, till exempel uppfarter och vägar inne i gårdar på industriområden och på stora parkeringar. De måste man koppla på igen när man uppgraderar geometrin för anslutande väg (glömmer man så varnar validatorn, så var inte orolig). Dessa vägar som inte finns någon motsvarighet för i NVDB ligger ofta fel i position och kan ha jämförelsevis grovhuggen geometri, ett resultat av manuell kartläggning efter äldre flygfoton med sämre position. Tänk på att uppgiften är att höja kvalitén på alla vägar, så lägg gärna ned lite tid på att justera position och detaljera geometrin vid behov.

Var extra misstänksam mot långa service-vägar. En väg som går till en telemast kan ansen vara en service-väg, men de kartläggs ofta mer lämpligt som generell grusväg ändå (track) eftersom många andra använder vägen bara för att komma åt landskapet runtomkring. Ibland kan det vara lämpligt att låta största delen av vägen vara track/unclassified och sista biten service. Vindkraftparker brukar få ett ganska omfattande nätverk av lite längre service-vägar, men utöver det är det sällan servicevägar är mer än kortare stumpar.

I glesbygden kan det finnas korta vägstumpar ute i ingenstans som används till att sätta i båtar mm. Dessa brukar lämnas som track eftersom de inte har en frekvent och tydlig användning. Inne i byar sätts dessa typer av vägar lämpligen till service. Något som också är vanligt ute i glesbygdens vidsträckta grusvägsnät är grustag, som ofta använts i samband med att vägen byggdes och vid underhåll. Om grustaget inte är aktivt, oftast enkelt att avgöra från flygfoto, bör vägen dit vara track, inte service.

I lite större byar kan skriptet tro att alla vägar ska vara service (eller track), fast det egentligen är lämpligare med en kombination av unclassified och service, och om byn är tätare byggd, residential. I lantbruksbyar är det vanligt att en service-väg till ett hus därefter ska övergå till track (kanske grade4 eller 5) när vägen leder vidare in i lantbruket. Detta är något skriptet nästan alltid missar.

Service-vägar är oftast ansluten till unclassified eller annan större väg, men det händer ibland att de är anslutna till track. Det kan handla om en enskild stuga långt ute i ingenstans där det är orimligt att göra vägen dit till unclassified för bara en stuga, men stugan är ändå mer än en rastkoja och tillräckligt prominent för att anslutande vägstump ska vara service.

Namn på vägar

NVDB har skiftade kvalitet på vägnamn. Namn i städer har i regel god kvalité, men i storleksordningen 1 av 1000 kan det vara felstavat eller liknande, så det är bra att vara på sin vakt ändå.

Om man råkar missa något så anser vi att det är bättre att ta in namnen oförändrade även med mindre fel som NVDB har, än att lämna vägarna utan namn, men vi vill ändå gärna att man har ambitionen att förbättra NVDB:s namndata och inte bara blint kopiera det.

I vissa städer ges cykelvägarna samma namn som gatan intill, skriptet rensar bort dessa för enligt OSM-tradition ska cykelvägarna inte ha egna namn då. Har cykelvägen ett unikt namn behålls det. I vissa fall har namnen rapporterats in till NVDB med endast versaler. Skripet konverterar dessa efter bästa förmåga.

Förkortningar förekommer i vägnamnen. Norra, Södra osv förkortas ofta till en bokstav. Vi rekommenderar att man ändrar det och skriver ut fulla namnet om man vet vad det är. Vissa förkortningar kan man dock behålla, som Cpl för cirkulationsplats, grv. och stv. för grenväg och stickväg.

Vissa mindre vägar (oftast de med stadsbidrag) har namn som endast säger vilken sträckning det är, exempel "Juktån (45) - Nedre Lomfors" (väg mellan E45 vid Juktån och byn Nedre Lomfors). Dessa namn är av teknisk karaktär och används inte av lokalbefolkningen så de kan man plocka bort. Längs landsvägar sätts ibland namnet på byn den går igenom på den delen av vägen. De kan man också plocka bort, byn finns ju just intill.

Skogbilvägsnätet har mindre bra kvalitet på vägnamnen. Dels är det ganska vanligt med felstavningar, och dels är det vanligt med "lat" namngiving typ "Granträskvägen med grenvägar". Vi rekommenderar följande strategi:

  • Korrigera stavfel
  • Ganska ofta kan namn anges med och utan 's', exempel"Storlidsvägen" eller "Storlidvägen". Om man inte har mer information, välj alternativet som känns mer naturligt att säga, (gärna i lokal dialekt) för det är i regel det namnet som används.
  • Svenska namn ska vara rikssvenska, om namnet inte är specifik känt för dialektstavningen. Dvs om även en person som inte talar dialekten använder dialektnamnet så ska dialektstavningen användas.
  • Vägnät som namngetts i grupp med samma namn typ "X med grenvägar" delas helst upp så att huvudvägen heter bara X, och grenvägarna heter "X grv." Skogsbilvägar förlängs ofta i omgångar så ibland är det inte uppenbart vilken som är huvudväg och inte, i så fall kan det vara säkrast att namnge alla med samma namn, alltså bara med "X", och lägg inte på "med grenvägar". I många fall har NVDB redan den typen av namnsättning, då kan man välja behålla den eller förfina genom att peka ut vilka som är grenvägar genom att lägga på "grv.".
  • Var uppmärksam på glapp, dvs att det kan vara ett par hundra meter utan namn och sen fortsätter det med samma namn, i de flesta fall är detta ett fel i NVDB och vägen ska ha samma namn även i glappet.
  • Då vägen nyligen förlängts kan sista delen vara utan namn. Det är då säkrast att lämna den utan namn istället för att använda samma namn som innan, eftersom det är ganska vanligt att förlängningen även om den bygger vidare och inte är en tydlig gren ändå får ett nytt namn.

OSM har en tradition av att använda en del icke-officiella lokala namn. Så ibland när man sammanfogar stöter man på ställen där namnet på vägen kan vara ett helt annat än det som är i NVDB. Där är det upp till din egna bedömning vad bästa alternativet är. Ofta är det att behålla OSM-namnet som det är, och lägga in NVDB-namnet på alt_name. Eller tvärtom.

Inne i städer är det vanligt att OSM och NVDB har olika positioner på exakt var namnet på en väg börjar och slutar. NVDB har oftast bra kvalitet på sin namnplacering i de kommunala vägnäten. Det är upp till din egen bedömning hur du gör när skillnader uppstår.

Justering av tidigare positionsfel

Mycket av den kartläggning av Sverige som gjorts hittills gjordes medan kvalitén på ortofotona var mycket mer begränsade än idag, både i fråga om upplösning och positionering. Särskilt i bergig terräng är det vanligt att kartlagda vägar, natur och byggnader ligger ett tiotal meter fel eller ännu mer. Då man uppgraderar vägen med ny importerad geometri flyttas de förstås automatiskt till sin rätta plats, men allt som inte ligger i NVDB, dvs byggnader, skogar, sjöar och åkrar mm ligger fortfarande kvar med sitt positionsfel. Ibland är felet tillräckligt litet så man kan låta det vara. I vissa fall händer det att hus och åkrar ligger så fel att vägarna går tvärs över dem. Då måste man korrigera.

I vissa kommuner kan det visa sig att arbetet med att korrigera gamla positionsfel blir större än att faktiskt ta in vägarna, men kom ihåg att även det är viktigt arbete. När man markerar en kommun som färdigställd i listan förväntar vi oss att även stora positionfel i närheten av vägarna har korrigerats.

Att korrigera positionsfel i ett område som kartlagts med hög detaljnivå kan vara lite knepigt. Ett grundproblem är att positionsfelen varierar i regel mycket över ytan, om något ligger 10 meter fel i position A kan det ligga 20 meter fel i position B bara hundratalet meter längre bort. Anledningen till detta är att flygfotona måste korrigeras efter terrängen, och är det höjdskillnader i terrängen som inte korrigerats så kommer felet variera såsom höjden i terrängen varierar. Det innebär att man kan i regel inte flytta flera kvadratkilometrar åt gången, utan bara små områden i taget. Detta går bra med byggnader, men för exempelvis större sjöar och skogsområden kan polygonerna sträcka sig flera mil, och vissa delar av dem kan ligga i bra position medan andra ligger fel, i olika grad. En metod som är användbar i dessa fall är att klippa upp polygonernas linjer så man kan flytta en del i taget, och sen fästa ihop dem igen.

Tycker man att detta verkar svårt kan man innan man börjar importera en kommun kolla hur bra positioneringen är innan man börjar jobba. Är terrängen platt så är positionsfelen troligen mindre, och om de finns är de lättare att korrigera. Saknar kommunen kartlagd natur eller om den är väldigt begränsad råkar man sällan ut för några svåra utmaningar i fråga om positionskorrigering.

Kopplade naturpolygoner

Ibland är naturpolygonerna fästa till vägarna. Vissa kartläggare väljer att exempelvis lägga kanten på en skogspolygon direkt på en väg och dela dess noder, medan andra håller naturpolygonerna frikopplade från vägar. Båda sätten är giltiga. Vi rekommenderar dock det senare. Uppdaterar man en väg med ny geometri som sedan tidigare är kopplad till en naturpolygon kommer den kopplas loss, och då rekommenderar vi alltså att man låter den vara frikopplad och inte limmar tillbaka den. Justera polygonens position och form vid behov.

Flerfiliga vägar

NVDB har information om antal körfält och även antal bussfält, men inte vilket fält som är vilket. NVDB saknar även information om vilka fält som är till för att svänga, så turn:lanes-taggning måste man göra själv. Ofta går det se på flygfotot vilka pilar som finns i de olika körfälten, och om inte är turn:lanes ofta kartlagt sedan tidigare så man kan behålla det som var.

Ibland är en flerfilig väg kartlagd som en way, ibland som två och båda sätten är korrekt (förutsatt att taggarna är rätt satta). Ibland har NVDB och tidigare kartläggning i OSM gjort olika val. Det är upp till din egen bedömning vad som är lämpligt i det fallet, att antingen behålla som det är i OSM, eller det som är i NVDB. Oftast är det vettigast att ta alternativet med fler ways eftersom vägen i dessa fall har stor utbredning.

Stora och flerfiliga vägar ingår ofta i route-relationer, dessa måste man se till att de är korrekta efter man uppdaterat geometrin. När man använder replace geometry-verktyget och matchar segment mot segment så sköts det automatiskt. När man gör om geometrin så att den kanske går från en way till två, måste man manuellt uppdatera rutterna.

Stora vägar som europavägar är ofta redan väldigt detaljerat kartlagda i OSM. De kan ha mer detaljer än vad som finns i NVDB. När antal körfält byter från 2 till 1 så har NVDB en skarp gräns, medan OSM har turn:lanes och merge_to_right/merge_to_left. I OSM har man också mer detaljerade avfarter med fler ways än NVDB använder. Man kan tycka att OSM har onödigt mycket detalj i vissa lägen (till exempel rita mycket korta och tvära avfarter som separata ways istället för att göra en enkel T-korsning), men traditionen är vida spridd så att byta är inte lämpligt. I detta läge är det bäst att låta OSM-kartläggningen styra och använda NVDB-datat för att förbättra geometrin där det går samt föra över de taggar som NVDB har men OSM saknar. Man kan använda replace geometry när det finns motsvarande geometri, men man behöver ofta klippa upp NVDB-vägarna i kortare segment så de matchar det som finns i OSM.

Cykelvägar bredvid bilvägar

NVDB kartlägger alltid cykelvägar separerade från bilvägar, även om det är i form av en breddad trottoar. i OSM kan/ska cykelvägar ritas på olika sätt, beroende på hur cykelvägen är separerad från bilvägen.

Om cykelvägen är åtskild från bilvägen med endast en målad linje, rekommenderar osm-wiki att cykelvägen ska anges som en tagg på bilvägen med: "cycleway=lane".

Om cykelvägen är fysiskt skild från bilvägen med kantsten, gräsyta etc. så bör cykelvägen ritas separat.

Det finns dock många exempel i OSM där cykelvägar är ritad på ett sätt som inte följer osm-wiki. Vissa tycker att cykelvägar alltid ska ritas separat, oavsett separationen från bilvägen. Vissa anser att man bör göra som det står i osm-wiki. Gör som du tycker är lämpligt, men var beredd på att någon annan kan ändra på taggning.

Se vidare: Key:cycleway.

Trottoarer

Trottoarer kartläggs ofta (men inte alltid) separat i NVDB. Metoden är i regel samma för en hel stad men kan skilja mellan städer. Om trottoarerna inte är kartlagda separat så saknar NVDB helt information om trottoarerna. I OSM är det mindre vanligt att kartlägga trottoarer separat men det är en giltig metod. Alternativet är taggen sidewalk=left/right/both på vägen. Om både vägen och trottoaren är smal i verkligheten kommer en separat kartlagt trottoar i NVDB i regel ligga lite fel eftersom de inte lägger linjerna allt för nära för att behålla tydlighet i kartan. Inne i städer kan det innebära att trottoaren kan överlappa med kartlagda hus. Gör en egen bedömning på bästa sätt att lösa problemet: ta bort trottoargeometrin och använd taggar på vägen, eller justera trottoargeometrin, eller om felet är litet kanske flytta husväggarna så det ryms.

Vägbeläggning

För mindre väg specar NVDB endast "belagd" eller "grus". "Grus" är ett antagande och hamnar även på jordvägar mm, därför sätter skriptet "surface=unpaved" för dessa vägar. För belagda vägar är sannolikheten hög att det är någon form av asfalt och på dessa sätter skriptet "surface=asphalt". För andra typer av belagda vägar, som kullersten mm., får man således ändra manuellt.

I OSM i Sverige är "surface=gravel" vanlig på grusvägar, men enligt OSM-wiki avser det knytnävsstora stenar, liknande det som finns under järnvägsspår. På statlig grusväg sätter därför skriptet "surface=fine_gravel", liknande "gravel", men med mindre stenar. Dessutom är gruset är löst. Ett bättre alternativ kan vara "surface=compacted", grusvägar som efter ett tag blir relativt släta och hårda. Läs på osm-wiki om dessa typer för grusvägar.

Vändplaner

NVDB saknar vändplaner i skogsbilvägsnätet, så de måste man lägga till manuellt. De syns på Lantmäteriets rasterkarta.

Vändplaner på lite större vägar finns ofta i NVDB men är så dåligt placerade att de importeras inte av skriptet (de kartläggs i NVDB som "vändmöjlighet" och är alltså inte en exakt specifikation var vändplanen i fråga faktiskt ligger). Så titta gärna på flygfoton inne byar mm där vändplaner kan förväntas finnas och lägg till vid behov. Dessa vändplaner finns i regel inte i rasterkartan heller.

Återvändsgränder med vändplan i städer är inte heller kartlagda i NVDB (ej heller i rasterkartan), så de får man lägga till manuellt.

Vägar som slutar med återvändsgränd eller vändplan ritas i NVDB oftast lite väl långt, till slutet av vändplanen medan OSM-tradition är att sluta vägen mitt på vändplanen. Är man noggrann bör man matcha positionen mot (positionsjusterat) flygfoto och det innebär i flesta fall kan man korta av vägen något för att matcha OSM-tradition.

Tänk på att kartlagda vändplaner ska vara sådana som är till för allmänt användande. Med andra ord bör man inte lägga in vändplaner på privata gårdsplaner.

Parkeringar

NVDB har inga areor, så parkering när de är kartlagda är som punkter. För parkeringsfickor, parking=layby, rekommenderar vi starkt att man gör det som skriptet gör, dvs endast en punkt med parking=layby bredvid vägen. I vissa fall kan det tidigare vara kartlagt med en area, eller en punkt med en service-vägsnutt. Om det inte är en väldigt speciell parkeringsficka (till exempel en som dubblerar som busshållplats) så rekommenderar vi att man förenklar till en punkt.

För andra typer av parkeringar är dock areor att rekommendera, och dessa måste alltså kartläggas manuellt. NVDB-skripet lägger in en nod för större rastplatser längs landsvägarna, men dessa består i verkligheten ofta av flera parkeringar och kanske byggnader, och är oftast redan kartlagda. Kontrollera så att all information som NVDB-noden tillhandahåller finns i rastplatskartläggningen, och plocka sedan bort NVDB-noden helt om parkeringen är kartlagd som en area.

Tänk på att ansluta parkeringsareor till vägnätet. Lägg till highway=service och service=parking_aisle. Se vidare Tag:service=parking aisle

Vägbommar

Bommar som NVDB markerat med "låst grind eller bom" sätts till barrier=gate med access=permissive. Det betyder att bommen är generellt sett öppen, men den kanske inte är det. Om man vet att bommen är i regel låst kan man ändra taggen till access=private (det finns också locked=yes, men den taggen är mindre använd). Ruttverktyg som använder OSM-data tillåter i regel ruttning via access=permissive, men inte via access=private.

Ofta(st) är bom-typen av typen "lift_gate", men den mer generella taggen "gate" används för säkerhets skull. Tyvärr har inte OSM en officiell hierarki av taggar från mer generella till mer specifika beroende på tillgänglig informationsnivå, så vilka taggar som anses mer generella än andra är något som avgjorts informellt. Har man kännedom om exakt typ av vägbom kan man ändra typen manuellt.

Järnvägskorsningar

NVDB innehåller järnvägskorsningar, men de är dåligt positionerade. Skriptet läser in järnvägsgeometrin separat och flyttar dem till verklig korsning, om den ligger i närheten. I enstaka fall kan korsningen vara så avlägset felplacerad att skriptet inte hittar en korsning, och då läggs en fixme-tagg till.

I fallet en väg korsar flera spår innehåller NVDB oftast bara en korsningspunkt och istället antal spår den korsar. Skriptet duplicerar korsningarna vid behov för att matcha. Ibland anges felaktigt antal spår eller så saknas korsning helt och hållet (alltid(?) för cykelväg), och då får man lägga till manuellt. Validatorn varnar om en väg korsar en järnväg utan korsningsnod.

Själva järnvägen läggs inte till av skriptet eftersom den av tradition kartläggs separat från vägar av kartläggare som specialiserar sig på just järnväg.

NVDB:s järnvägsgeometri har ibland mindre positionsfel, om en järnvägskorsning verkar skumt placerad jämför med Lantmäteriets rasterkarta som är mer att lita på då det gäller positionering.

Nedlagda järnvägar

Generellt gäller att OSM inte ska användas för att spara objekt som inte längre finns kvar. OSM är inte historikdatabas.

Nedlagda och borttagna järnvägsspår finns trotts det ofta kvar i OSM. I dessa fall ska dock de märkas tagg som visar på aktuell status. I vilket skicka gamla spåret är eller om det har tagits bort helt.

Det är ofta vanligt att den gamla banvallen har gjorts om till en bil- eller cykelväg. I dessa fall kan vägen märkas med exempelvis "was:railway=rail". I dagsläget (2022) är det dock ofta att sådan vägar har märkts med "abandoned" vilket är fel, då det innebär att järnvägsslipers eller järnvägsräls finns kvar.

Se vidare Lifecycle prefix.

Noexit

Om en väg slutar väldigt nära en annan väg kan man lägga till noexit=yes på sista noden så att kvalitetsverktyg (som OSMI) förstår att vägen faktiskt slutar där och inte är tänkt att sitta ihop med intilliggande väg. Detta är ganska vanligt förekommande längs landsvägar när korta stumpar av gammal väg finns kvar efter vägen rätats ut. Det är inte jätteviktigt, för om man inte gör det kommer ruttningen funka ändå, det är bara det att exempelvis OSMI kommer ge en varning.

I vissa fall har noexit använts felaktigt och satts på själva vägen för att den inte leder någonstans, men det är inte så den ska användas. Ta i så fall bort noexit-taggen. Noexit ska inte heller användas om vägen fortsätter med en stig/cykelväg/gångväg.

Överlapp längs kommungränserna

Kommunpaketen överlappar litegranna med varandra, dvs vägsegment som ligger i kanterna av kommunerna går in lite i nästa, så när man laddar in grannkommunen finns samma väg representerad där igen. Det är inget större problem men kan vara bra att känna till. Det är lite svårt att se att man har dubletter då för de kommer ligga exakt ovanpå varandra eftersom de har exakt samma geometri. Ibland kan det hjälpa att ladda in grannkommunen i JOSM bara för att se exakt var överlappen slutar, det kan vara lite bökigt att leta inne i själva OSM-kartan.

Passa på lägga till annat

Passa gärna på lägga till namnen på småbyar som passeras (place=hamlet, place=isolated_dwelling), de saknas ganska ofta och är mycket lite arbete att lägga in eftersom det bara är en punkt.

Ibland ser man en ny skogsväg på rasterkartan som inte finns med i NVDB. De kan man gärna passa på och lägga in manuellt. Dubbelkolla på flygfoton, det är som beskrivs här okej att använda Lantmäteriets webbtjänst om förladdade fotona i JOSM är för gamla för att se om vägen finns.

Rasterkartan har nedgångna skogsbilvägar, stigar och även en del cykel- och gångväg i stadsmiljö som NVDB inte har. Det kan bli väl så övermäktigt att lägga till alla dem, men om man vill så kan man lägga till åtminstone de viktigaste. Tänk på att rasterkartan kan ha fel, ibland borde en nedgången väg (taggas typiskt med tracktype grade4 eller grade5) vara stig eller rentav inte vara med alls, eller så är det inte alls så nedgången, så dubbelkolla med flygfoto på dessa.

Kartlägger man stigar och gamla vägar som inte finns i NVDB är det mycket användbart att ha Strava som ett kartlager. Där kan man se att ganska ofta har även lantmäteriets rasterkarta små fel om stigars sträckning.

Tips för nybörjare

Arbetsmetoden för uppdatering av vägar från NVDB är komplicerad, och du behöver ha vana att arbeta med JOSM innan du börjar med detta.

Kommentar på arbetsmetod och varför den används

För en nybörjare kan den beskrivna arbetsmetoden kännas onödigt komplicerad, genom att använda funktionen "Replace Geometry".

Varför inte bara använda NVDB-lagret som en mall, justera positioner för de gamla vägarna enligt mallen och sedan flytta över och slå ihop taggar från gammalt och nytt? Det fungerar också, men med långa vägar, med många olika segment blir en sådan hantering väldigt tidskrävande. Med "Replace Geometry" gör man en uppdatering av en lång väg lika snabbt som en kort.

Varning för oavsiktlig uppladdning av allt NVDB-data!

Var ytterst försiktig så att du inte av misstag laddar upp hela det förbehandlade NVDB-lagret!

För att minska risken för felaktig uppladdning, finns inlagt i alla generade osm-filer en spärr mot uppladdning. För att ta bort denna spärr, öppna osm-filen i exempelvis Notepad, och radera texten "upload=never" i början av filen, och spara sedan filen.

I JOSM kan man också förhindra uppladdninngen genom att högerklicka på lagernamnet i lagerpanel och markera "Discourage upload".

Om olyckan är framme och du gör en icke önskvärd uppladdning, kan den backas med plugin "reverter".

Hålla reda på vad man har gjort

Uppdatering av vägarna är ett stort arbete, även för en mindre kommun, och arbetet behöver delas upp på flera sittningar. Man behöver därför på något sätt veta vad som är gjort, och vad som återstår. Ett sätt är att skapa ett rutnät i vilket man markerar vad som är gjort. Det rekommenderade sättet att dela upp arbetet är dock att använda den uppdelning av kommun som redan är gjord (för vissa kommuner). Där varje kommundel kan uppdateras och laddas upp var för sig.

I fall man använda ett rutnät kan det skapas på följande sätt:

  • Skapa nytt lager med: (File->New Layer).
  • I det nya lagret rita linjer så att de bildar ett rutnät. Sätt önskad "preset" på linjerna så att de syns bättre. Exempelvis för motorväg. Storleken på rutnätet väljs så att ett "lagom" antal vägar innesluts. Exempelvis 3x3 km. I städer kan rutnätet behöva vara tätare. Man behöver inte rita fyrkantiga rutor, utan man kan med i stället följa naturliga gränser som större väggar etc. om hellre vill det.
  • När en ruta är klar gör en markering i den. Exempelvis genom att rita ett kryss med linjer, och sätta önskad Preset-typ på dessa linjer.
  • Spara rutnätet i en egen osm-fil som kan läsas in vid behov. Gör även en kopia på det för säkerhets skull.

Spara session

I arbetet behöver man ha flera lager samtidigt och vissa av dessa vill man alltid ha aktiverade. I längden är det tråkigt att varje gång man startar JOSM, behöva aktivera dessa samma lager. För att slippa göra det, kan man spara aktuell session med "File->Save Session As". Alla då öppna lager sparas, och återställs med "File->Open" eller i Windows genom att dubbelklicka på sessions-filen i Utforskaren. Om du väljer det senare, skapa en genväg till sessionsfilen och lagra den på skrivbordet.

Fungerar det med annat är JOSM som ID eller Potlatch?

Nej! Hela den här arbetsbeskrivningen förutsätter att du använder editor JOSM. Som nybörjare kanske du är van att använda den webbaserade varianten ID, men som sagt, det går inte.

Det finns också en editor Potlatch, men den går inte heller att använda.

Problemlösning och avancerad editering

På Wiki finns en sida om avancerad editering.

Hantera överlappande segment

Väldigt ofta får man error:s på överlappande segement. Dessa kan ligga precis över varandra, och man försöker särskilja dessa genom att dra i en nod följer båda med. Ett sätt att lösa detta genom att endast marker en av dessa, är att klicka flera gånger på gemensamt segment. Selektionen växlar då mellan de överlappande segmenten. När önskat segement är markerat, dra i en nod, och förhoppningsvis särskiljs segmenten.

Använda Replace Geometry

Ofta fungera utbyte utan problem. Detta är beskrivet tidigare på den här sidan.

Den nya vägen kan flyttas och ändras innan utbyte. Exempelvis för att särskilja och se gammal och ny väg tydligare.

Den gamla vägen får dock inte ändras så mycket. Det går att dela upp den i segment med Split Way, vid befintliga noder för att bättre passa in uppdelning för nya vägen. Det är också möjligt att slå ihop flera segement på gamla vägen.

Problem med Replace Geometry

Om gammal väg har objekt placerade på någon av sina noder, som väggupp, trafikmärke mm. så kommer inte utbyte att fungera. I dessa fall måste först göra en "merge". av noder från gammal till ny väg.

Utför merge på följande sätt:

  • Om nod inte finns på nya vägen i önskad position, skapa noden i "draw mode" eller dra en befintlig nod till önskad position.
  • Markera objektet i gamla vägen först och markera sedan den noden på nya vägen.
  • Utför "Merge nodes".
  • Nu bör Replace Geometry fungera. Förutsatt att det inte finns ytterligare objekt som behöver hanteras.

För att slippa utföra merge kan prova att göra "unglue" på objektet på gamla vägen, slå ihop vägar, och sedan klistra tillbaka objeket på ihopslagen väg.

Om inte Replace Geometry fungerar

Ibland fungerar inte utbytet, trotts uppdelning på lämpliga noder, merge av objekt mm. Det som då återstår att göra manuell uppdatering.

  • Dela upp gamla vägen i segment som motsvarar den nya NVDB-vägen.
  • För varje segment kopiera över alla taggar från nya till gamla.
  • Aktivera hela NVDB-lagret (det som du laddade ned) i eget lager.
  • Justera visning av lagren så vägar från NVDB-lagret visas, när nya vägen dras åt sidan i aktuellt lager (i vilket du gör uppdatering).
  • Justera geometrin för gamla vägen så att den följer geometrin där den nya vägen tidigare var placerad.

Hjälp gärna till att övervaka arbetet

Genom projektets öppenhet har vi ingen möjlighet att i förväg stoppa någon från att ta ett av våra översatta NVDB-lager och vårdslöst importera det utan att följa processen här. Däremot kan vi hjälpas åt att hålla ett öga på topplistan för Sverige och agera enligt instruktionen som finns på wikin:s vandalism-sida om man upptäcker misstänkt aktivitet.

Tips om hur man använder olika verktyg för att kolla vad som försiggår i kartan finns i detta foruminlägg: länk

Översättningsskriptets funktion

Översättningsskriptet nvdb2osm är flera tusen rader långt och behandlar och sammanfogar för varje kommun över 40 olika datalager ur NVDB. Den största delen av översättningarna är statiska regler, dvs ett datafält i NVDB översätts till motsvarande fält i OSM. Vissa egenskaper måste dock skriptet räkna ut genom att titta på flera datafält samtidigt och kanske titta på omgivande geometri. Summa summarum är översättningen för komplicerad för att beskrivas här i en enkel tabell. Är man intresserad av exakt hur det fungerar får man gå till skriptets hemsida, och kika i koden. På hemsidan kan man också lämna buggrapporter om man upptäcker fel, eller lämna förslag på förändringar eller förbättringar.

Under utvecklingen har skriptet testats och översättningarna justerats flera gånger efter testresultat och kommentarer. Det har bland annat lett till att inte all information ur NVDB översätts och vissa förenklingar av datat görs. Till exempel behålls fältet vägbredd (width) endast på de större vägarna, och cykelvägskornsningar konverteras från en linje till en nod för att göra geometrin lite mindre komplicerad och mindre uppbruten.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Import/Catalogue/Sweden_highway_import/Import_guidelines&oldid=2475484"