Också en approach jag funderat över är att börja med alla stora vägar (highway=tertiary och högre) först, och sen de mindre istället för att ta det rent på geografiskt område (som jag gjort hittils). Då blir det tydligare för en själv när man behöver kolla noggrant (när man lägger in de små vägarna då de mer ofta är felaktiga i geometri eller taggning), plus att man får naturliga geografiska sektioner att jobba med för de små vägarna.
Det var ett bra tips, kände inte till det (är som sagt ganska ny även till JOSM). Skulle nog vara en bra sak att lägga till i instruktionerna!
Ibland gör jag så också. Ibland har jag ingen struktur alls, utan väljer på måfo de vägar jag råkar se. Och sedan flyttar mig runt i hela området. Men oftast brukar jag börja i en sida området och göra klart från den sidan till den andra. Validatorn visar ju var felen finns.
När det gäller storlek på arbetsområde, så ger ett liten sådan snabbare uppladdning, men ger samtidigt fler skarvar till gamla ej uppdaterade vägar. Sådana fel bör lagas innan uppladdning.
Om man väljer ett större område att göra klart innan uppladdning, ökar risken för konflikter (dvs. osm-konflikter). Att någon annan under tiden har laddat upp ändringar i samma område. Risken är större för detta i städer, än för landsbygd. Att lösa eventuella sådana kan var riktigt besvärligt. Speciellt om den andra personen inte är samarbetsvillig, och inte vill pausa sina uppladdningar temporärt. Jag har vi något tillfälle t.o.m. varit tvungen att slänga det jag gjort, då det blev för många problem.
Ett tips är att innan man börjar med en kommun, man kollar lite om det finns någon aktiv karterare i samma område, och meddelar den personen sina avsikter. Kan göra att man undviker framtida problem.
Numera gör jag ganska många små uppladdningar, även om det medför många skarvar att laga. Efter varje uppladdning rekommenderar jag att man kollar det med OSMOSE eller OSMI, men det tar någon dag innan de visar eventuella fel.
En fortsättning på denna, när man gjort en utsökning och då fått alla matchande element selekterade, finns det något sätt att hoppa igenom den listan, editera vissa och ta bort vissa, utan att behöva göra om sökningen (och glömma vart man var i listan) efter varje ändring?
Annan reflektion/fundering: Har jag tidigare kört lite blandat ansluta markyta till väg eller inte beroende på situation och humör, men nu vid NVDB-importen är det ju jävligt drygt att hålla på och koppla om markytor. Finns det något bra plugin/verktyg till JOSM som gör det enkelt att lägga till en “korridor” i markytan? D.v.s. jag markerar en (del av en) way/väg, väljer en bredd och så skapar den en buffer runt vilken den “tränger/tar bort” markytor så att det blir en markyte-fri korridor för vägområdet.
Jag har testat den, men använder den inte längre. Så länge som man inte stänger ned JOSM finns listan, och är kanske är till nytta för någon. Beroende vilken arbetsmetod man har. Tyvärr kan inte listan sparas och återläsas. Vilket för mig gör funktionen ointressant.
Som redan sagts kan man med en lämplig search-fråga få lista på det man specifikt söker. Tyvärr är funktionen inte så smidig, om man vill gå igenom en sökresultatlista en och en. Listan “försvinner”, om man väljer något ur listan, och man måste exekvera frågan igen.
En annan möjlighet är att vid uppladdningen visas en lista på alla ändringar, adderingar och raderingar. Genom att dubbelklicka på något av dessa (förutom raderingar) så flyttas kartan dit där markerat objekt finns. Tyvärr verkar det som att objekten inte markeras, så det kan var lite svårt att veta var i kartan den finns. Kanske har jag missat något med detta, men jag använder aldrig själv den här funktionen.
Ett sidospår:
Tanken att man efteråt ska gå igenom sina ändringar systematisk, låter som en bra idé för att höja kvalitén. Jag har dock aldrig tillämpat ett sådant arbetssätt. I stället försöker jag göra ett så bra arbetet vid varje enskilt utbyte av vägar, göra bedömning av vägklass (vilket kan vara knepigt), kolla att geometrin blir bra mm. Tiden att göra klart en mindre kommun, med kanske 2000-3000 ways, tar redan lång tid. Att höja kvalitén något, med en efterkontroll, skulle innebär många timmars jobb ytterligare.
Vad är det du tycker man ska förbättra och kontrollera? Jag har tidigare tillämpat det, men jag ser inte några större fördelar med det. Eventuella fel i nvdb-datat, och som hamnar i utbyt väg, kan fixas i samband med utbytet.
Exempel:
Om man har en bakgrund, så ser man ibland att nvdb-vägens geometri inte alltid är ok. Det gäller främst mindre vägar. Sådant kan lika enkelt justera efter att utbytet är klart.
Vid genereringen skapas ibland automatiska fixme, där översättningen inte lyckats skapa taggar. Sådant kan man kanske fixa i innan utbyte, men jag ser inte heller här att man vinner speciellt mycket. Motsvarande gammal data kan mycket väl visa på en lösning av fixme.
Frågan om nvdb:s datakvalité är ju annan fråga. Jag litar i huvudsak på nvdb. I annat fall blir ju hela nvdb-importen meningslös. I vissa fall har jag dock lagt ned ytterligare tid för att verifiera det. Speciellt om gammal data motsäger vad nvdb säger.
Det är mycket lättare att göra all korrektion innan man slår ihop data. Då vet man att man har använt källdatan OCH gjord OSM-mässiga förbättringar. Då kan man fokusera helt på merge-arbetet. Blir mycket bättre flyt i arbetet. Med få undantag så vet man att allt man importerar är bättre eller lika bra som det som finns i OSM. Om man påträffar nåt i OSM som ändå måste värderas så är det ändå bara i undantag.
Mitt workflow för vägimport:
Steg 1: gör datan importvärdig och ta så många val som möjligt
Steg 2: gör det mekaniska arbetet utan att behöva tänka så mycket
Jag använder dem, även när jag inte direkt har NVDB-import som huvud-fokus. Jag använder dem när jag karterar ett område i mer detalj, då blir det första steget att jämka ihop befintliga vägar med NVDB.
Jag är ytterst tacksam för tjänsten!
Om man endast uppdaterar vissa vägar från en kommuns genererad nvdb-osmfil, medför detta extra arbete för den som senare gör en fullständig uppdatering. Det tidigare uppdaterade vägarna skapar dubbletter som är besvärliga att hantera.
Det behöver du nu förklara närmare. På vilket sätt spelar der någon roll om en väg ursprungligen kommer från NVDB eller inte när du senare gör en import?
Om en väg har skapats med nvdb som underlag, där geometrin har bibehållts och laddats upp på osm, så kommer en efterföljande nedladdning av samma väg från nvdb, lägga sig exakt “ovanpå” den tidigare uppladdade nvdb-vägen. (Förutsatt att nvdb-geometrin inte har ändrats under tiden).
i JOSM får man dublicate way error på sådant. Vilket bland annat gör det svårt att selektera dessa två. Om en väg inte är en tidigare nvdb-väg, så är det alltid en liten positionsdifferans mellan en nvdb-väg och den andra vägen. Vilket gör det enkelt att välja den ena eller andra.
Ofta har man också i först omgången delat upp nvdb-vägen i flera delar innan uppladdning. Andra gången samma nvdb-väg används, kan den då täcka in flera segment på tidigare uppladdad väg. Vilket gör selektering ännu jobbigare.
Om det enbart skulle vara problem med någon enstaka väg, vore det inte så mycket att tala om, men ofta är det flera 10-tal och ibland 100 eller mer.
För att förstå de praktiska problemen som uppstår med dessa dubbletter, behöver man ha råkat ut för dem och blivit tvungen att lösa dem.
