Formell importprocess för NVDB

Hej,

vi håller på att jobba på att formalisera en import-process för NVDB vägdata. NVDB har ju funnits publikt tillgängligt sedan några år, och enskilda kartläggare har redan använt det för att snabba upp sin egen kartläggning.

Nu vill vi formalisera detta och göra det mer tillgängligt till fler kartläggare, genom att dela med oss av ett färdigt skript och detaljerade instruktioner för hur man gör en seriös och varsam import. Det kommer också finnas färdiga filer för varje kommun att ladda ner så man behöver inte sätta upp en miljö för att kunna köra skriptet själv. Det räcker om man har JOSM så kan man hjälpa till.

Det handlar alltså om att manuellt sammanfoga översatt lager, samtidigt som man justerar highway-typer och liknande (som NVDB inte ger tillräcklig information för). Endast modify-operationer används när gamla vägar uppdateras för att säkerställa att spårbarheten i historiken behålls, samt att se till att existerande informationstaggar och relationer kommer med.

Det gör det mycket arbetsintensivt och man kan räkna med att en kommun av genomsnittstorlek utanför storstäderna tar cirka 80 timmar arbetstid att gå igenom helt. Det handlar alltså inte om någon snabb dum bulkimport, utan ett lågintensivt arbete som väntas pågå under flera års tid. Vi kommer styra arbetet mot att göra insatser där det ger mest, dvs där OSM:s vägdata är mest eftersatt. I storstäderna ser det ganska bra ut, och i vissa mindre städer där det finns ett starkt lokalt OSM-intresse, men i många andra kommuner finns fortfarande flera luckor i vägnätet och gammal lågupplöst geometri med stora positionsfel.

Ett utkast för granskning för själva import-processen med den nödvändiga informationen finns här:
https://wiki.openstreetmap.org/wiki/Import/Catalogue/Sweden_highway_import

Och detaljerad arbetsflödesbeskrivning finns här:
https://wiki.openstreetmap.org/wiki/Import/Catalogue/Sweden_highway_import/Import_guidelines

Själva skriptet som används finns här:
https://github.com/atorger/nvdb2osm/

Denna information har förutom detta forum gått ut till talk-se-mejlinglistan, internationella imports-mejllistan, samt osmsweden-facebook-gruppen. Mesta diskussionerna under utvecklandet av översättningsskript och importprocess har skett i facebook-gruppen samt på github i issue-rapporterna på skriptet.

/Anders

Crossposting from OSM Sweden mail list: https://lists.openstreetmap.org/pipermail/talk-se/2021-March/003954.html

Draft import files per municipality: https://nvdb-osm-map-data.s3.eu-north-1.amazonaws.com/index.html

Hej,
Det låter spännande. Hur går förfarandet till med det med filer för nerladdning utan att behöva rigga miljön förutom att installera JOSM?

Jag har mest jobbat i iD och det är mest Ängelholm jag är ute efter då jag flyttat hit och börjat inse att kartan ligger efter här.
Först trodde jag att det bara var cykelbanor som var helt borta, sen så började jag se att det saknas några vägstumpar och formen kändes udda på något ställe. Så här finns att göra. Det kanske inte är en prioterad stad för att det redan finns ett ok underlag.

Arbetet görs som sagt enbart med JOSM! Så ID går inte att använda! Åtminstone inte som arbetsprocessen är tänkt att fundera.

Arbetsprocessen är beskriven i: https://wiki.openstreetmap.org/wiki/Import/Catalogue/Sweden_highway_import/Import_guidelines

Viktigt att känna till är man uppdaterar ALLA vägar i en kommun (eller del av kommun) innan man gör upload! Man uppdaterar alltså INTE en eller några vägar i taget. Det innebär att det är svårt, med en beskrivna arbetsprocessen, att bara göra en del av vägarna. Om man inte orkar göra klart det man börjat med, måste någon annan slutföra jobbet. Tekniskt är det möjligt, men inte helt enkelt.

Så kontentan är: Om du börjar med något, slutför det!

(Och det finns möjlighet att ta en mindre del av en kommuns vägar, för att minska den mängd man måste slutföra innan upload).

Förutom att lära sig hur man arbetar med JOSM, download/upload så är det stora jobbet mycket mekaniskt jobb utan att man behöver tänka så mycket. Samma sak som man upprepar gång efter gång.

När man har lärt sig grunderna är arbetet inte svårt. Viktigast är att man är kvalitetsmedveten, är uthållig och försöker göra ett så bra jobb som möjligt. Arbetet passar inte slarvputtar som snabbt vill få ett resultat.

Arbetet med en kommun är ganska omfattande. Räkna med en veckas heltid för en mindre landsortskommun. Det är mycket tid om man har arbete eller skola. För den som tycker det är för mycket, finns möjlighet att ta en mindre del av en kommun. Ett sådant arbetspaket tar typisk kanske runt 10 timmar beroende på vana.

Som jag skrev i mitt förra inlägg är uppdateringar av vägar en stort jobb, men viktig!

Jag ser vägnätet som ett skelettet för hela OSM.

Om du också tycker så, är du mycket välkommen i projektet!

Om du har frågor eller har har kört fast finns de som kan hjälpa till.

Frågor och inlägg om projektet finns även på Facebook: https://www.facebook.com/groups/osmsweden

Tack,
Jag laddade in det för att ta en titt. Ängelholm var mycket landsbygd ser jag. Intressant.
Bra instruktioner i den handledningen.

Jag fastnade dock direkt på ett antal vägar.

  • Det ser rätt annorlunda ut med exempelvis rondellerna där är ett antal v formade ingångar i Osm som inte är i NVDB. Vad är att föredra?
  • Stavning av gator och stor/liten bokstav. Hur tänker man där?

Man hamnar man ofta i situationer där man själv avgör hur man gör. Det är så OSM utvecklas. Det finns inga fasta regler, utan endast rekommendationer. (Men om man inte följer dessa kommer andra att reagera!)

När det gäller rondeller och även större korsningar med många filer, finns flera olika sätt att rita dessa. Det är hela tiden en konflikt mellan att rita som det ser ut på ett flygfoto, med osm-vägar för varje fil eller logisk variant, med EN osm-väg, som har taggar på valda segment som anger antal filer, hur dessa svänger, om det är tillåtet att byta fil etc. Du får själv bestämma vilken variant du väljer. Exempelvis har ju en “vanlig” väg 2 filer, en i varsin riktning, men den ritas som 1 osm-väg. Redan här ser man konflikten mellan verklighet och ritsätt.

Specifikt om rondeller har jag sett båda varianterna: “1 streck” som ansluter till rondell och 2 V-formade anslutningar. Inget av dessa är mera “rätt”. Välj det som känns mest logiskt för dig.

En huvudregel som du bör följa är att rita separata osm-vägar, om det i verkligheten är fysiskt hinder mellan filer (vajerräcken, terräng, refug). Titta på hur det är gjort på större vägar. Exempelvis runt Arboga-Köping-Kungsör där jag har karterat. (Jag själv har vacklat lite mellan olika metoder, så det ser lite olika ut beroende på när jag gjorde det). Använd flygfoton från Lantmäteriet för att se hur det är (på webben Lantmäteriets “Min karta”).

Läs även på osm-wiki: Lanes, Key:turn, Key:lanes, Key:change, Placement.

När det gäller stavning följer jag hur det är gjort i NVDB, och som det normalt skrivs. Stor inledande bokstav, och små på efterföljande namndelar.

Återkom gärna med följdfrågor.

Ytterligare en sak att tänka på är att hanterar ruttrelationer (väg-, buss-,vandringsleder).

När nya (väg)segment adderas, så är det nästan oundvikligt att inte rutter (route) påverkas eller blir “trasig”. I JOSM finns en relationseditor, med vilket man kan fixa dessa problem, men som nybörjare är den inte så enkel att förstå. Åtminstone hade jag problem, och jag hade också svårt att hitta några bra instruktioner.

Till att börja med ska man välja en rutt i tagg-fönstret eller i relationspanelen. Sedan adderar och raderar man “Members”. Dvs. vägsegment. Viktigt att känna till är de ikoner som visas efter varje member/segment. Om någon av dessa är rödmarkerade indikerar det ofta, men inte alltid, att någon problem finns. Prova att sortera listan, men om det inte hjälper, saknas något segment eller något segment ska tas bort ur member-listan.

Jag tänker inte här skriva en fullständig manual på detta, utan de intresserade får återkomma med frågor.

Tack för tipsen om rondellerna. Jag gör lite avvägningar.

Fastnar i sånt som du nämner här med busslinjer eller andra taggningar och få rätt på dem. Det har fungerat att bryta ner vägarna och sen para ihop dem. Då ser jag att jag kan behålla alla egenskaper.

Men jag har nu kommit till två som vägar som verkligen inte vill bli vänner hur mycket jag än har tagit ner dem till sina beståndsdelar.
Den ena har en busstation och den andra är en tågkorsning.

Det var inte lätt det här och inte lätt heller att beskriva.

Troligtvis har du fått problem med att det finns objekt placerade på noder på gamla vägen. Exempelvis järnvägskorsning, busstopp, cykelövergång e.dyl.

För att den gamla vägen/segmentet ska kunna flyttas över med Replace-funktionen, måste den vara helt “ren” på andra objket. Dvs. ingen nod på den får innehålla något annat en tom nod. Om det finns en eller flera objekt på gamla vägens noder, måste de hanteras. Jag gör på följande sätt:

  • I jämnhöjd med objektet på gamla vägen, på nya vägen skapa en nod. Antingen med nodverktyget i JOSM (snabbvaltangent A), dra en befintlig nod på nya vägen eller dra ett “kryss” på nya vägen, så att en nod skapas.
  • Markera/klicka på objektet på gamla vägen.
  • Håll ner skift och markera noden på nya vägen, så att både nod och objekt är markerade.
  • Välj funktion “Merge” (snabbval M).
  • Objektet flyttas, “merge:as”, med noden på nya vägen. Dvs. gammal och ny väg sitter ihop i en och samma nod.
  • Nu ska replace-fungera, FÖRUTSATT att inga fler objekt finns på gamla vägen, annars upprepas ovanstående för de andra objekten.

Ibland kan segmentet/vägen som ska bytas ut vara väldigt lång, och man har svårt att hitta alla objekt på gamla vägen, och replace vägras. Ett knep är att dela upp vägarna i flera delar med “Split way, snabbval P”. Observera att man inte får skapa nya noder på gamla vägen, utan split på gamla vägen måste göras på befintliga noder. Däremot är det ok att skapa noder på nya vägen. Glöm inte att sätt ihop isärtagna segment efteråt med “Combine Way”.

Ibland kan det vara svårt att se vilken av vägarna som är gammal och ny. Markera då vägen/segmentet och välj funktion “History”. Gamla vägen har historik, men inte den nya. (I vissa fall fungerar dock inte detta, att historik inte visas för gamla vägen).

Om du aktiverar visning av ID för objekt (finns under settings), så har alltid gamla vägar/objekt ett id-nr större än noll. Nya vägar/objekt har alltid id=0.

Jag rekommenderar att du kopplar de mest använda kommandona till något som är enkelt att utföra på med tangentbord eller musknapp.

Jag har en mus med flera extraknappar, och till en av dessa har jag kopplat “Replace Geometry” och till en annan knapp “History”.
I normala enkla fall, består utbytet av tre 3 musklickar:

  1. Markera gammal vägsegment.
  2. Shift och markera nytt vägsegment.
  3. Klicka på Replace-geometry.

Det tar några sekunder, även för långa vägar, förutsatt att dessa inte innehåller objekt på gamla vägen. Man får dock först kolla så att vägsegment “matchar” i längd. Annars behöver man först göra split på gammal eller ny väg.

Hur hanteras felaktiga data i NVDB? Tex i närheten har en väg importerats från NVDB som inte existeras i verkligheten. Jag har tagit bort den, men den kommer tillbaka igen.

Finns det något sätt att göra “override” på data från NVDB?

Jag känner inte till någon “override”.

Om det är fel i NVDB, bör man felrapportera det via deras webbgränssnitt. Jag har själv gjort det flera gånger, men det tar lite tid innan det åtgärdas.

Och detta gäller alla felaktigheter i NVDB. Vi använder ju NVDB som facit, och om facit är fel, så blir det slutresultatet också fel. Om man inte inte råkar känna till vad som gäller i verkligheten.

(Jag har själv blivit “påhoppad” för att lägga in felaktiga vägnamn i osm, men som är enligt NVDB. Som sagt, om man känner till fel i NVDB, rapportera det! Så blir det rätt vid nästa NVDB-import).

Jo, det är felrapporterat. Men varför används NVDB som facit? Jag trodde verkligheten var facit, eller skall OSM bara var ett konglomerat av andra källor?

Det borde finnas ett sätt att markera data som felaktigt, så den inte läggs in igen. Känns lite märkligt att man skall uppdatera inte bara OSM utan alla andra källor som NVDB, Lantmäteriet, och vad allt man kan tänkas importera från.

Men den här diskussionen måste ju ha förts förut, var kan jag hitta den?

Ja, verkligheten är facit. Att kunna kontrollera på plats är oftast den bästa metoden, men om du inte kan göra det?

När det gäller vägnätet, är enligt mig NVDB den bästa fria landstäckande källan. Om man inte vill använda den eller någon annan källa på nätet, pga. risken för att lägga in fel i i osm, så är det en val man får göra.

Om vi tar det konkreta projektet, så ser jag ingen bättre metod än den som används. Även med den långsamma takten som vi nu håller (eftersom så få deltar) kommer det ta många år innan hela landets vägnät är uppdaterat.


När det gäller synpunkten att kunna markera att ett data inte ska ändras av andra, att uppgiften är absolut sann, kommer det att leda till andra problem.

För det första känner jag inte till att någon sådan funktion finns i osm. Du kan ju alltid skriva en “note” i tagg-uppgifter för exempelvis en väg. Och förhoppningsvis läses den av det någon som tänker göra ändringar. Men man kan aldrig vara säker.

För det andra vet man inte hur länge en note-uppgift är giltig. Om ändring lades in för många år sedan och en källa på nätet (NVDB, Lantmäteriet etc.) visar att det är fel, ska man då inte göra ändring? Vissa anser det, och att man personligen ska verifiera ändring, innan det är ok att ändra i osm.

Förklara vad du menar med “att den kommer tillbaka”. Om du använder NVDB-data och gör “replace” enligt metodbeskrivningen, så kommer ju eventuella fel i nvdb med i ditt modifierade data. Gör du “replace” flera gånger i rad?

(Jag själv gör ständigt små justeringar på vägar som inte stämmer i nvdb och lägger in dessa ändringar i osm. Men jag har inte rapporterat om dessa små ändringar till nvdb, och risken finns därför att mina ändring raderas vid en ytterligare uppdatering från nvdb av någon annan.)

Nej, det är en användare (“archie”) som lägger in NVDB-data och när jag upptäcker att en väg som inte finns kommer med, så tar jag bort den i JOSM. Sedan lägger samma användare in den igen några minuter senare. Om och om igen. Vet inte om det är en robot som går igenom och kollar, och skriver över hela tiden.

Förstår att man vill automatisera för det är ju rätt i >95% av fallen, men man måste väl ha något system för att rätta importerade uppgifter när man har en sådant här stort projekt som NVDB-import?

Alla mina ändringar i OSM är från det jag ser när jag är i skog och mark.

Det är inte ok av “archie” att radera dina ändringar.

Första stege är att kontakta Archie och få en förklaring.

Om han vägrar svara dig eller om du inte är nöjd, se vidare på:
https://forum.openstreetmap.org/viewtopic.php?id=71348

Kontakta archie här:
https://www.openstreetmap.org/user/archie