Jag hade egentligen bestämt mig för att jag inte skulle ge mig in i det, och istället fokusera på annat (BJK etc.). Men såklart vandrade mina fingrar sedan iväg på tangentbordet och nu har jag påbörjat NVDB-importen för Tierps kommun…
Jag har inte varit med i de här sammanhangen så jättelänge så visa saker har säkert tagits upp och diskuterats tidigare.
Det allra första, och lite det som höll mig från att ge mig på detta: Det är betydligt enklare än jag hade väntat mig. Nu har jag visserligen hållit mig ute “i skogen” än så länge, så inga relationer och närliggande gator att hålla isär ännu, men själva processen är ganska enkel, även för någon med extremt liten JOSM-förkunskap. Så har man funderat på att börja jobba med sin kommun men inte riktigt vågat: Gör det!
Däremot finns det fortfarande mycket som skulle kunna förbättras och förtydligas kring instruktionerna. De känns just nu som de råa noteringarna från den/de som tagit fram processen på hur de gått tillväga, inte instruktioner som är tänkta att ge vägledning åt en nykomling till importen. Mer bilder hade också varit önskvärt!
Jag har tidigare nämnt att något som avskräckt mig är åtagandet att importera en hel kommun. Vi får se hur långt jag tar mig med Tierp nu, men bättre möjligheter att dela upp kommuner hade varit önskvärt (jag vet att jag någon gång läst om hur man får till uppdelade kommunfiler, men inte ens det hittade jag nu). T.ex. ett verktyg som styckar upp kommunfilen i delar med kanske 20-30 vägar vardera enligt någon logisk algoritm (t.ex. en större väg med alla avstickare från den eller ett bostadsområde) hade varit jättebra!
Verktygsstödet i JOSM är för det mesta okej (speciellt Replace Geometry gör ju jobbet bra mycket enklare än utan det verktyget), men det finns fortfarande förbättringspotential. T.ex. en MapCSS-overlay-stil som visar vilka vägar som kommer från NVDB, eller att Replace Geometry hade lite mer smarthet vad gäller konflikter i taggar (om ett objekt har surface=paved och en surface=asphalt borde den automatiskt kunna välja surface=asphalt).
Jag vet att vi diskuterade att skapa en youtube tutorial i början men det blev aldrig av…
en fråga till er som håller på med importen just nu.
Jag skapar de import-filerna här: NVDB2OSM – OSM files for download använder ni filerna? eller skripet direkt med NVDB nedladdningar? (om filerna inte använda, så behöver jag inte betala för AWS varje månad )
Intressant att de ändå finns ett intresse för import av NVDB. Skulle tro att jag är den som över tiden har varit och är mest aktiv i detta projekt. User torger var den som startade det hela, och är också periodvis väldigt aktiv.
När det gäller instruktioner som håller jag med om att de kunde vara bättre. Antingen göra kortare videor eller kanske en egen webbsida där man hade bättre möjligheter att utforma den med bilder etc. Jag tycker själv att osm-wiki är ganska klumpig att jobba med. Den fungerar väl ganska bra för en FAQ, men att beskriva en mer komplex process, som NVDB-importen tycker jag den inte fungerar så bra för.
Det som har avhållit mig för att gå vidare med ovanstående, är just det mycket svaga intresset från andra att delta i projektet. Varför lägga ned många timmar på videor, mer pedagogiska instruktioner om det är bara är några få som har nytta av dessa? Annars har jag både tid och möjlighet att göra något inom det området. (Jag har ju ständig semester, betald av staten. Dvs. jag är pensionär med massor av fritid! )
Jag har ibland propagerat för att man INTE behöver fixa en hel kommun, då det innebär ganska mycket jobb. Runt 50 timmar för en mindre kommun, och för den som är inkörd på processen. I stället har jag delat upp vissa kommuner i mindre delar, där man på ca 10 timmar kan fixa en delmängd av kommunen.
Men även denna uppdelning tar viss tid att göra, och med tanke på det svaga intresset, har jag inte prioriterat det. I första hand har jag delat upp kommuner som jag själv eventuellt kommer eller har jobbat med.
Om det finns en intresse för att förbättra instruktion mm., är jag villig att hjälpa till. Ge gärna förslag på vad som behöver göras.
Ja, det är mycket användbara. Även för mig, som kan generera egna filer, men det är mycket mer bekvämt att ladda ned färdiga filer.
(Däremot är det fel på vissa av kommunfilerna. Dessa fel behöver rättas, vilket hittills user torger har gjort. Han är ofta upptagen med annat, så det kan ta tid innan felen blir rättade).
Att generera filer med de skript som finns, är användbart endast för de som vet och kan sätta upp ett utvecklingsmiljö för python. Absolut inget för gemene man.
…och samtidigt blir det oändligt mycket lättare att ändra och korrigera en wiki, än att spela in en heeelt ny film, för att man råka göra/säga nåt lite otydligt efter 6 minuter…
Vi kör all vår användardokumentation på jobbet på en wiki och det fungerar otroligt bra. Men visst, den stora vinsten kommer när man ska börja redigera nåt, att bygga upp hela bulken av information från noll är lite jobbigare
Hade personligen helst sett textuella (med bilder) instruktioner, möjligen med kortare videos som komplettering. Den stora fördelen med wikin är att den är tillgänglig för alla som kan tänkas vara intresserade och informationen finns kvar även om nån slutar betala för någon server eller så, men håller med om att dess formattering kan vara begränsande. @Tomas_Marklund kommentar om tiden att bygga upp kontra redigera är såklart också väldigt relevant.
Det är väl lite moment-22; dåliga instruktioner → färre intresserade → mindre nytta av bra instruktioner.
Instruktionen för NVDB-import är väldigt lång. Trotts det, finns det många saker som borde skrivas ytterligare. Problemet med detta är, att ju längre den blir, desto sämre läsbarhet blir det.
Vad behöver förbättras i instruktionerna?
Vad är svårast att förstå?
Sätta upp JOSM?
Hur sätta upp en arbetsarea/lager från nedladdade osm-filer?
Hur man löser problem när utbyte inte fungerar?
Hur man väljer klass på vägar?
Hur man lagar relationer på vägar och rutter?
Hantera konflikter vid uppladdning?
Annat?
Skulle instruktionen bli mer överskådlig genom att dela upp den på flera undersidor?
Förslag på bilder som kan underlätta förståelse?
Lite konkreta grejer utifrån det jag hunnit göra hittills:
Använda nummerlistor istället för punktlistor för att göra det tydligt att steg ska följas i ordningsföljd (enkelt att fixa)
Instruktionerna för att börja jobba var lite otydliga; bl.a. att två lager heter något med “arbetslager” gör det lätt att förvirra ihop om man inte har tungan rätt i mun. Formatering av t.ex. kortkommandon och småbilder/ikoner på verktyg som ska användas skulle vara hjälpa till att bryta upp väggen av text.
Rubriken “Utför uppdatering” skulle nog kunna läggas upp bättre. T.ex. uppfattade jag det lite krångligt att hålla isär de tre scenariorna med segmentlängd när jag läste (när man väl jobbat en stund är det dock solklart hur det ska fungera, men tröskeln skulle kunna sänkas). En illustration med de tre scenariorna sida vid sida skulle nog vara användbart för att visa det grafiskt.
Använda wiki-mallen för taggar för alla referenser till taggar för att både få länk för tydligare formatering
Jag anser också att NVDB-data måste förbättras med bild-data innan import. Den kan inte importeras “rå” i blindo.
För mig är NVDB ett start-steg, där man måste ändra tags och geometri före import. Om man har gjort det så har man också mycket mera due dilligence på benen när man börjar ersätta eksisterande data i OSM.
Helt klart, och alltid i samband med importen. Det är därför min NVDB-import tar väldigt lång tid eftersom alla vägar som ska läggas in som inte är rena skogsvägar som saknas idag så måste man göra detta merarbete för att säkerställa okej geometri och att det är rätt taggning. Jag vill inte peka finger mot andra som har importerat, men en del av dem bör nog tänka mer på detta för att göra vägarna i OSM så bra som möjligt. Särskilt när det kommer till större vägar med på- och avfarter där undertecknad oftast har ritat in väldigt bra geometri redan som någon sedan ersätter med NVDB som är sämre när det hade räckt med att föra över taggarna från NVDB. Men nog med gnäll om det, gjort är gjort och det är efterarbete som gäller där.
En annan sak jag lagt märke till (lite sent så kommer behöver efterjustera där jag redan gjort klart) är att många infarter blir highway=track istället för highway=service+service=driveway.
Finns det något bra sett att hoppa igenom alla ändringar i JOSM innan man laddar upp? Så att man väg-för-väg kan kontrollera att det är rimliga taggar och att den ser ut att finnas i verkligheten? Om ja vore det nog ett bra tillägg i instruktionerna innan uppladdning, tillsammans med att köra valideringar.
Ja det är oftast det bästa. Om man överför för mycket på samma gång så är risken större att man glömmer göra kopplingar, eller får dubbla vägar nånstans.
)
)
