Import/Catalogue/Sweden highway import/Import guidelines

From OpenStreetMap Wiki
Jump to navigation Jump to search

Introduktion

Detta är en praktisk handledning om hur man importerar vägdata från Trafikverkets nationella vägdatabas (NVDB), genom att använda filer från översättningsskriptet nvdb2osm som översätter NVDB:s shape-filer till OSM:s XML-format. Dessa filer finns också att ladda ner förgenererat per kommun så man behöver inte köra skriptet själv. Sammanfogningen måste man däremot göra själv och den här handledningen handlar om hur man går till väga. Programmet som används är JOSM.

OSM har redan idag ganska god generell täckning i Sverige, så man kommer troligen inte stöta på ett större område som inte är kartlagt alls. Däremot är det vanligt med att vissa mindre vägar saknas, att vägar har geometri med låg detaljnivå och ibland stora positionsfel, samt att basinformation som namn, hastighetsgränser, trafikförbud med mera saknas eller är utdaterade.

Syftet med att ta in data från NVDB är att höja kvalitetsnivån av OSM:s vägdata i Sverige. Dels fylla i de luckor som finns här och var, dels förbättra precisionen på väg-geometrin där vägar redan är kartlagda, samt lägga till mer information om bland annat vägnamn, hastighetsgränser, vägbeläggningar, trafikförbud med mera, sådant som NVDB är bra på. Ett viktigt sidosyfte, som i vissa kommuner kommer utgöra större arbetsinsats än att komplettera vägnätet, är att korrigera positionsfel i omgivande naturpolygoner och byggnader så att de korrekt positionerade vägarna passar in.

NVDB har emellertid inte alla småvägar och stigar, förenklar ofta detaljnivån inne i städer, och har inte samma sätt att klassificera vägar som OSM har. NVDB är alltså i detta sammanhang ett komplement, som hjälper till att bygga upp en bas som traditionell manuell kartläggning kan bygga vidare på. Importarbetet är också till stor del en manuell process där importören får göra mycket bedömningar och justeringar av NVDB-informationen, så det rör sig absolut inte om en snabb och "dum" import där man blint ersätter med automatik, utan en varsam sammanfogning där vart och ett vägsegment ges en bedömning. De höga kraven på varsam sammanfogning och manuella bedömningar gör att en genomsnittlig kommun kan ta i storleksordningen 40 timmars manuellt arbete att importera, så ju fler kartläggare som hjälper till desto bättre.

NVDB är en levande databas och uppdateras hela tiden. Hur ska OSM hållas synkroniserad med detta? Största delen av vägnätet är tämligen statiskt så även om NVDB-import görs endast en gång så kommer OSM vara i en bättre situation än innan och enklare att hålla den i fas genom traditionell kartläggning. Dessutom när väl vägarna har hög precision på geometri och positionering kommer det vara mycket enklare att bygga verktyg som jämför OSM och NVDB och pekar ut skillnader där man kan göra en mindre import senare.

Arbetsflöde

Översikt

På en översiktlig nivå går importen till så här:

  1. Välj ut kommun du vill uppdatera, se progress-sidan så du inte krockar med någon annans arbete. Där registrerar du också att du påbörjat import.
  2. Ladda ner NVDB-datat för din kommun som översatts av skriptet till OSM:s XML-format. (Om du vill kan du även använda nvdb2osm-skriptet och översätta direkt från NVDB:s shape-filer, men det är alltså inte nödvändigt. Men att själv generera kommundata inte är något nybörjarprojekt! Speciellt inte om du inte har någon erfarenhet av programmering, då generering kräver att du har eller installerar en utvecklingsmiljö för språket python).
  3. Ladda in det NVDB-lagret som ett eget lager i JOSM.
  4. Rätta eventuella fel i NVDB-datat.
  5. Ladda ner existerande OSM-karta för motsvarande område till eget lager i JOSM
  6. Sammanfoga lagren varsamt med modify-operationer och lös eventuella konflikter och positionsfel
  7. Kör validatorn och rätta fel.(Validering gör man kontinuerligt i samband med sammanfogningen).
  8. Ladda upp.
  9. Uppdatera progress-sidan för att markera att kommunen är färdigställd.
  10. Några dagar efter uppladdning, kontrollera kommunen med exempelvis OSMOSE och OSM Inspector.

Det stora jobbet är att sammanfoga lagren och det görs manuellt enligt ett visst arbetsflöde som beskrivs i mer detalj i följande avsnitt. Det är inte rimligt att sammanfoga en hel kommun i ett enda svep, utan man gör det med 100 - 200 vägsegment åt gången, vilket innebär att en typisk kommun leder till 50 - 200 changesets innan man är klar. Vissa kommuner är också uppdelade i mindre delar. Uppdatering av en sådan del kräver betydligt mindre tid än för en hel kommun.

Viktigt att förstå är att "import" av detta slag är en arbetsintensiv och tidskrävande manuell process med dels justering av indatat (NVDB-lagret är inte 100% korrekt eller komplett rakt ur skriptet) och dels spårbar modifiering av nuvarande OSM-data. Det handlar alltså inte om att kasta bort det som finns inne nu och blint ersätta det med NVDB-lagret.

Det finns två huvudregler man måste följa när man importerar data:

  • När man ersätter existerande vägar måste man använda modify-operationer, antingen manuellt eller med hjälp av verktyget "replace geometry" (rekommenderat). Det är inte tillåtet att göra delete på det gamla. Anledningen till denna regel är att OSM loggar redigeringshistoria på varje objekt, och gör man delete så förstör man den. Dessutom är det en stor risk att man gör fel och tappar tidigare taggar och relationer om man inte använder modify. Det händer ju faktiskt att OSM har både mer och annorlunda information än NVDB har.
  • NVDB-lagret ska inte ses som "facit", det måste alltid förbehandlas, särskilt highway-typer är inte 100% rätt. Men även geometri inne i trånga situationer i städer kan det finnas olika kreativa lösningar för och NVDB har inte alltid den bästa.

(Geometri = Hur information är ritad i OSM. I detta fall hur vägar är dragna/ritade).

Slutresultatets kvalitet hänger lika mycket kartläggaren som på NVDB och översättningsskriptet. Är man en nybörjare som kanske bara använt webbeditorn hittills och aldrig ens startat JOSM kan allt detta verka svårt, och man kan vara rädd för att göra fel. JOSM har en viss inlärningströskel, och att sammanfoga lager kommer kännas lite rörigt när man är nybörjare, men om man bara tar det lugnt i början och låter det ta tid så kommer man så småningom igång och får upp farten.

Stora och små arbetspaket

Arbetstiden för att uppdatera en hel kommun beror på hur stor kommunen är och hur van du är att göra uppdateringar. Generellt kan man räkna med heltid under en vecka för en mindre landsortskommun. Kommuner med större städer, tar betydligt mer tid. För många kan det vara ett för stort åtaganden, och därför finns möjlighet att göra mindre delar av en kommun. Arbetstiden för sådana mindre delar är betydligt mindre och ligger i storleksordningen på 5-10 timmar. Men även här beror det mycket på de specifika fallet och din vana att göra uppdateringar. Dessa mindre arbetspaket skapas i dagsläget endast då någon önskar få sådana. 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.

Uppdatera all geometri, eller bara delar?

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 information om hastighetsgränser, broar, vägunderlag, vägnamn och så vidare. Tvärtom saknas det ofta, och i fallet hastighetsgränser är de ganska ofta fel.

Vägar som kartlagts för flera år sedan har ofta markant sämre precision i geometrin än det som kartlagts senaste åren, anledningen är att äldre ortofoton hade sämre precision än idag, och NVDB- och lantmäteriets rasterlager fanns 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 i medelstora vägar, medan små skogsbilvägar just intill ligger rätt, för att de helt enkelt kartlagts senare.

Mycket talar alltså för att man ska gå igenom och uppdatera alla vägar, även de som är kartlagda. Det är också vad vi rekommenderar. Det innebär dock att det tar lång tid att gå igenom en kommun, har man bara en halvtimme per dag att lägga så kan det ta flera månader. Det är okej att låta det ta lång tid, men om man är mer intresserad av att nå så mycket täckning som möjligt på kortast tid, och är mindre intresserad av att de som finns har så bra kvalitet som möjligt i fråga om geometri och information, så kan man istället filtrera bort existerande vägar ur råa NVDB-lagret och bara jobba igenom kvarvarande. Ett skript som hjälper till med denna filtrering är highway_merge. Hur du väljer att jobba är upp till dig.

Tips för att sammanfoga med existerande data

Förbehandla NVDB-lagret

Förbehandla översatt rått NVDB-lager först, justera highway-typer särskilt för service/track/unclassified/residential. Gå igenom alla fixme-taggar och kör JOSM-validatorn. Tips om detta finns under separat rubrik. Det är en smaksak om man väljer att jobba igenom hela NVDB-lagret innan man börjar med sammanfogningen, eller om man plockar ut en mindre del (100 - 200 vägsegment) och kör igenom hela arbetsflödet till uppladdat changeset innan man fortsätter med nästa.

Vi rekommenderar att man plockar ut en mindre del i taget och förbehandlar den istället för att arbeta igenom hela lagret på en gång. Det är nämligen lite enklare att hålla reda på vad man har gått igenom och inte om man jobbar med små bitar i taget.

Välj ut en lagom stor area och sammanfoga

En hel kommun i taget blir för mycket att jobba med på en gång, då det oftast innebär minst en veckas heltid att gå igenom. Man får dela upp lagret i JOSM, genom lite copy/paste mellan lager.

Gör (till exempel) så här:

  • Välj en lagom stor ruta (50-200 vägar) och gör select (Håll inne vänster musknapp + Alt-tangetn och dra över område som ska kopieras. Alt-knappen gör att hela väg-segment blir markerade som berörs).
  • Det lönar sig att kopiera smart så det blir relativt få anslutande vägar in i området.

När du har markerat önskade vägar gör följande:

  • Kopiera (ctrl-V).
  • Skapa nytt lager (File-New Layer).
  • Klistra in till det nya lagret: Edit-"Paste at source position" (ctrl-alt-V). OBS! Menyalternativet visas endast om "Expert mode" (View-Expert Mode) aktiverad.
  • I det nya lagrat finns nu liten del av NVDB-lagret, det som du valde i första arbetssteget.
  • Det kan vara bra att göra en kopia av det nya lagret så en referens om man blandar ihop vad som är nytt och gammalt, när man håller på och sammanfogar:
    • Markera lagret för det överflyttade NVDB-vägarna i lagerpanelen.
    • Högerklicka och välj "Dublicate".
  • Spara båda dessa lager till varsin fil så att de kan återställas på enkelt sätt.
  • Ladda ned tillräckligt stort område från OSM så att hela det nya lagret blir täckt.
    • För att göra det enklare att se området som behöver laddas ned, är ett knep att markera allt i dellagret före du börjar ladda ner.
    • För att göra det enklare att komma ihåg var gränserna går utan att behöva titta på lager-kopian så kan det vara bra att ladda ner flera mindre rutor och följa kanterna på lagret någorlunda istället för att ladda ner onödigt mycket data runtomkring.

Det man nu har efter nedladdning är en enda röra, två kartlager på varandra, det som finns i OSM-databasen nu, plus NVDB-lagret. Ju mer man jobbar desto duktigare blir man på se skillnad mellan gammal och ny geometri och det blir mindre förvirrande att jobba, men i början kan det kännas lite stökigt, det är normalt. Låt det ta tid i början. Om man har det fullständiga NVDB-datat i ett eget lager man man växla mellan detta och aktuellt lager, för att se vad som är vad. Ett annat tips är att se vilka osm-id:en vägar har. Nya vägar har alltid id=0, medans vägar hämtade från osm har id>0.

JOSM har en mycket bra validator som upptäcker om man har vägar som ligger ovanpå eller nästan ovanpå varandra. Det gör att det är mycket låg risk att man glömmer jobba igenom och sammanfoga över hela kartan. Tvärtom är det knepigare om vägar inte fanns innan, då kan man glömma bort att justera highway-typ eftersom man inte har någon tidigare väg att jämföra med och validatorn ger ingen varning om man glömmer titta på den. Så var uppmärksam i förbehandlingssteget och jobba igenom kartan metodiskt!

Använd replace geometry för att uppdatera geometri

Om du inte redan installerat utilsplugin2 i JOSM så gör det, för att få verktyget replace geometry. Med det uppdaterar man nya NVDB-vägar med historik och annan information från gammal väg.

Gör så här:

  • Grundprincipen är att alla segment i NVDB-vägen ska ersättas med ett motsvarande segment från gamla vägen. Om inte gör det, riskerar man att bli av med taggar som fanns i gamla vägen för vissa segment. I de flesta fall har gamla vägen färre segment (saknas broar, färre taggar osv), och då måste man dela upp gamla vägen i motsvarande segment.
  1. Markera NVDB-vägen och se hur långt segmentet är och markera motsvarande segment i gamla vägen.
  2. Om den gamla vägen har ett mycket längre segment (perfekt passning inte nödvändigt), klipp upp den (markera nod, Tools->Split Way). OBS: klipp av på existerande noder! Om man lägger man till en ny nod fungerar inte "replace geometry".
    • Var uppmärksam när du närmar dig slutet av vägen så inte segment i gamla vägen tar slut innan du gjort replace geometry med alla NVDB-segment.
    • Om den gamla vägen istället har fler segment, dela upp NVDB-vägen på motsvarande vis. Om möjligt gör "join" på vägarna efter replace geometry gjorts (dvs om taggarna är samma i båda segmenten).
    • I nya NVDB-vägen kan man lägga till nya noder utan att replace geometry trilskas. Den kan och bör delas på exakt samma ställe som den gamla vägen är, eftersom om gamla vägen byter taggar där, måste den nya göra det på samma ställe.
  3. Gör replace geometry, och lös eventuella tag-konflikter i dialogen som kommer upp.
    • Ibland har gamla vägen en relation (större vägar har oftast det), dessa ska behållas (visas i dialogen som kommer upp)
  4. Upprepa segment för segment tills hela vägen är ersatt.

"Replace geometry" gör att ersättningen av den gamla geometrin görs med modify-operationer (dvs det ser ut som man manuellt flyttat och lagt till noder i den gamla vägen så att den exakt matchar den nya). Detta gör att historik på vägsegmentet behålls, vilket är viktigt för att kunna spåra förändringar, och visar respekt mot de kartläggare som ritat vägen innan. Historiken hamnar dock bara på ett av segmenten, när vägen behöver delas upp, men det är så OSM:s databas fungerar. Men även om inte det kommer med en historik i alla segment, så ser replace geometry till att så många noder som möjligt förs över från gamla till nya vägen, så det blir ett tydligt changeset.

Om vägen man ersätter innehåller noder med taggar, som till exempel övergångsställen och vändplaner med mera, så går det inte göra replace geometry rakt av. Man måste då först kopiera över dessa nodtaggar. Därefter går det att göra replace geometry som vanligt. Ofta finns noderna redan representerade i NVDB-vägen, om det är övergångsställen till exempel, men då det gäller exempelvis vändplaner (highway=turning_circle) saknas de ofta i NVDB. Istället för att kopiera över taggarna kan det gå snabbare att flytta noden och göra merge med motsvarande nod på nya vägen. Alternativ att man gör merge av gammal nod till en motsvarande nod på nya vägen. Skapa en sådan nod om sådan inte finns.

Ibland grenar den gamla vägen iväg åt ett annat håll än den nya. Då far man klippa isär och sätta ihop segment så de motsvarar varandra. Klipp isär nya vägen hellre än gamla om det går, ibland ändrar den nya vägen taggar (tex byter namn) som gör att den måste delas upp där. På andra ställen har nvdb-data namnlösa vägsegment på ett annat sätt än det som existerar i OSM. Vid generering av nvdb-datat 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 skogsbilvägsnätet blir det ibland lite konstigt när en väg av god kvalitet gör en tvär sväng och i kurvan fortsätter en ny väg med låg kvalitet rakt fram. Då är det förstås lämpligt att klippa om vägen så det blir mer logiskt med hur det ser ut i verkligheten.

Ett problem med replace geometry-verktyget är sidoeffekten att nya vägar inte blir ihopkopplade med anslutande vägar till gamla vägen. Ofta uppgraderas ju även anslutande vägar och blir då anslutna igen, men längs kanterna på området man jobbar med eller vägar som inte finns i NVDB, kommer man behöva koppla ihop igen manuellt. Lyckligtvis varnar JOSM validatorn för sådant och det är liten risk att man missar sådant, bara man kommer ihåg att köra validatorn och går igenom varningarna ordentligt. Observera att validatorn inte alltid hittar alla fel, utan man behöver göra en kontroll av uppdaterat område, efter uppladdning, men OSMI eller OSMOSE.

Det här arbetsflödet kan verka svårt och komplext, men efter ett tag får man upp farten och det känns naturligt. Lär dig och använd kortkommandon så mycket som möjligt, det lönar sig i långa loppet, det blir tillräckligt många musklick ändå.

Övriga tips

  • Var uppmärksam på tidigare taggar och relationer!
    • I vissa fall kan det vara så att tidigare kartläggning har en högre detaljnivå på taggningen än vad importerade data har. Red ut dessa efter eget omdöme, ibland kan man behöva behålla det som redan finns, och kanske dela upp NVDB-data i fler segment för att matcha. Genom att följa replace-geometry-metoden går man automatiskt igenom alla segment.
    • 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-arbetsflödet 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, för att kontrollera att dessa är kompletta.
  • Justera smart längs områdets kanter!
    • När man konverterar en del i taget så kommer förstås vägar längs kanterna på området man jobbar med vara avhuggna. Det kan vara frestande att låta dem vara okopplade eftersom man snart ska ta in nästa del, 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.
  • Var uppmärksam på nödvändiga förändringar och kompletteringar i NVDB-lagret och hur de samspelar med existerande data!
    • Läs nog igenom alla tips på den här sidan så du blir medveten om vad i NVDB-data som kan behöva justeras och hur man gör det.
  • Validatorn i JOSM är din vän!
    • Det är nästan helt omöjligt att göra en korrekt sammanfogning utan hjälp av validatorn. Tips om hur man använder den finns under separat rubrik.
  • Använd OSMI (OSM inspector) eller OSMOSE efteråt!
    • Jobbar man med stora mängder data är det validatorn till trots, ändå viss risk att något fel slinker igenom. När leverantören Geofabrik uppdaterat sin databas (de är ganska snabba) är en bra sak att gå igenom området man uppdaterat med deras OSM Inspector då kan man hitta fel som man kanske missade med validatorn. Routing view Islands och Unconnected roads är det som är vettigast att gå igenom. Notera att den varnar även för sånt som inte är verkliga fel.
    • 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 så man är säker OSMI är uppdaterad.
  • 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 där för att se om en väg finns eller ej, eller avgöra andra saker som kan vara otydliga på de foton som finns förladdade i JOSM. Till exempel, när nya skogsvägar poppat upp och finns endast i rasterkartan kan det vara vettigt att dubbelkolla på lantmäteriets färska flygfoton innan man kalkerar av från rasterkartan. Fotona kan också vara till hjälp för att avgöra vilka filer som är vilka i flerfiliga vägar, där information saknas i NVDB. Eftersom Lantmäteriets färska flygfoton inte har CC0-licens som rasterkartan och äldre flygfotona som finns förladdade i JOSM, kan man dock inte sätta i system att kalkera av från dem förstås, men lära sig egenskaper om vägar etc från dem är helt ok.
  • När man är klar, bör man ladda ned hela kommunen igen och göra en ny valideringen. Var uppmärksam på ifall eventuella fel är inom kommunen man uppdaterade eller inte. Om felen är in närliggande kommun, kan man naturligtvis rätta sådana fel om man känner för det. Var speciellt uppmärksam på vägar över kommungränsen så att det inte är avbrott på dessa.

JOSM Validator

JOSM Validator är ett mycket viktigt verktyg i importprocessen. Den används i tre sammanhang:

  1. Kör manuellt en gång på det råa NVDB-lagret före sammanfogning för att upptäcka vissa typer av fel som kan finnas i NVDB-datat som kräver manuell korrigering.
  2. Efter man sammanfogat körs den automatiskt på datat man modifierat när man försöker ladda upp. Ladda inte upp förrän du korrigerat felen, och kört manuellt enligt nästa punkt.
  3. Validatorn måste även köras manuellt på allt data efter färdig sammanfogning och den går igenom punkt 2, eftersom validatorn annars kan missa vissa vägar som kopplats loss. I denna sista körning kommer man få ett flertal varningar som inte hör ihop med ens egna förändringar utan hör till data som var kartlagt sedan tidigare. Är man på gott humör kan man förstås korrigera problem även i det datat, men det är inget krav.

Validator-körning på råa NVDB-lagret

Skriptet lägger till fixme-taggar där det inte klarar av att lösa en konflikt eller där NVDB inte ger tillräckligt med information. Dessa måste man gå igenom och lösa manuellt. Använd JOSM:s sökfunktion och sök på fixme=* för att få fram all geometri som är taggad.

Man måste använda JOSM Validator på OSM-filen för att se vilka problem den upptäcker, och åtgärda manuellt vid behov. I stadsmiljöer kan det vara ganska mycket som behöver manuell justering, på landsbyggden ibland ingenting. Bro- och tunneldatat i NVDB har en del begränsningar och precisionsproblem, kanske saknas en cykelbro osv. Städer med mycket broar får således mycket varningar relaterat till detta.

Vanliga Validator-varningar, med kommentarer:

  • 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å skripet har ingen korrigering för det, om det uppstår får man laga det manuellt.
  • 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.

Validator-körning efter sammanfogning

Varningarna att hålla mest utkik efter är de som rör korsande vägsegment och löskopplade vägar. Normalt ska man ha noll varningar i JOSM-körningen som körs automatiskt när man trycker på "ladda upp"-knappen, medan JOSM-körningen som körs manuellt på allt data man har i lagret kan innehålla varningar som rör gammalt data, och man behöver inte laga till alla de problemen (även om det inte skadar förstås).

  • 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. Obs: dubbletter ska förstås inte tas bort (delete) utan uppgraderas (modify) till den nya geometrin (se arbetsflödet) så att spårbarheten behålls.

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 av 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 i anslutning till gator

NVDB kartlägger cykelväg alltid separat, även om det är i form av en breddad trottoar. Det är också det vanligaste sättet i OSM, men ibland så taggas cykelvägen direkt på den stora vägen. Var uppmärksam på detta och justera vid behov. Det är upp till din egen bedömning vilken kartläggningsmetod som ska användas. Finns plats är det i regel bättre med cykelvägen separat.

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 "belagd" är sannolikheten så hög att det är någon form av asfalt att surface=asphalt används. För kullersten mm får man således ändra manuellt.

I OSM i Sverige idag är "surface=gravel" vanlig som på grusvägar, men enligt OSM-wiki avser det knytnävsstora stenar, så egentligen inte rätt. Bättre är då "surface=fine_gravel", vilket används av skriptet på statlig grusväg, där mer detaljerad information om vägbeläggningen finns. Där finns även mer tekniskt korrekta namn på de olika bitumenbundna vägbeläggningarna som används, men i OSM samlas alla dessa under lekmannatermen asfalt, surface=asphalt.

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.

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.

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 verka vara onödigt komplicerad, med att använda funktionen "Replace Geometry". Varför inte bara använda NVDB-lagret som en mall och justera positioner för de gamla vägarna? Och sedan till dessa kopiera taggar från NVDB-vägarna. På korta "vägstumpar" kan det fungera, men på långa vägar, med många olika segment blir en sådan hantering tidsödande. Det blir alltså ganska tidsödande att justera en lång väg, medans Replace Geometry, fixar det med en knapptryckning.

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!

Exempelvis om din avsikt är att ladda upp justerad OSM-data, samtidigt NVDB-lagret är aktivt. Var därför mycket noggran att kontroller vilket lager du laddar upp.

För att minska risken för felaktig uppladdning kan risken för detta minska genom att inte hela NVDB-lagret inläst hela tiden, eller om det är inläst högerklicka på lagernamnen i lagerpanel och markera "Discourage upload". Man kan kan också i osm-filen för ett lager marker att lagret inte ska laddas upp (Se vidare hjälptext i JOSM).

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

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 som man överlagrar en kommun och i det markar vilka delar vad som är gjort och är kvar att göra.

Ett enkelt rutnät kan 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 sätt Preset 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ätt ö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.

Ett annat sätt är att föra anteckningar om vilka vägar, stadsdelar etc. man har gjort klart. Speciellt stora vägar, kan vara bra att ta för sig, då de ofta även innehåller rutt-relationer som behöver hanteras.

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 speciellt 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å tillåtet att göra 'merge' av en nod på gamla vägen och en på den nya.

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 utan att först göra "merge". Hantering av detta problem är redan beskrivet tidigare på den här sidan.

Ett alternativt sätt att åtgärda detta är att:

  • Skapa en ny nod i nya vägen på motsvarande postion som objektet i gamla vägen.
  • Markera objektet i gamla vägen först och sedan den nya noden i nya vägen.
  • Utför Merge av dessa noder.
  • Nu bör Replace Geometry fungera. Förutsatt att det inte finns ytterligare objekt som behöver hanteras.

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.