Om importprojekt, JOSM och iD

Communities Sverige (Sweden)
1

Fortsättning av Varför finns inte stadsdelar, kvarter, bostadsområden utsatt i Uppsala? - #8 by torger då det började bli off-topic och jag misstänker att det kan bli lite mer diskussion om detta ämne.

Jag både håller med och inte. iD är, speciellt i jämförelse med JOSM men även i bredare bemärkelse än så, ett väldigt bra exempel på användarvänlighet och nog det enskilt viktigaste för att få in nya mappers till OSM. Och helt enkelt p.g.a. begränsningarna i vad som går att göra med en webbapp så kommer det finnas en övre gräns för vad iD kan vara användbart till.

Däremot så tycker jag inte man ska räkna ut iD för upp till medelstora ytor (det klarar definitivt stora nog där det börjar bli fördelaktigt att begränsa sig själv bara får att inte göra för mycket i en enskild changeset). Det finns några svagheter (t.ex. validering av multipolygoner) men de är relativt enkla att lösa, bara någon lägger tiden på det.

För importer saknas ännu funktionalitet, men det är inte jättemycket som saknas. Det största problemet där tycker jag snarare handlar om uppdelning av stora importjobb, vilket skulle vara fördelaktigt även för JOSM. MapRoulette är en bra lösning men blir ineffektivt vid stora jobb (skulle behöva möjlighet att jobba med många tasks samtidigt), HOT Tasking Manager är intressant men inte jättebra anpassat till importer och väldigt tight kopplat med HOT.

(emphasis mine)

Tillbaka till tidigare problemet; kan man bara dela upp området i mindre bitar så blir det både hanterligt för iD och bättre för JOSM-användare.

Tillbaka till problemet, det här tankesättet leder bara till gatekeeping och färre som kan och vill engagera sig.

Jag gjorde här först en långrandig uträkning men insåg att den inte tillför så mycket och bara bjuder in till att ifrågasätter enskilda siffror. Men tänker att det inte ska behöva så många argument för att förklara att många som deltar med bara lite tid också är viktigt, även för importprojekt.

Som skrivet ovan, mycket riktigt saknar iD några vitala funktioner idag, men inga gigantiska hinder.

Upprepar mig själv; steg ett är att OSM communityn som helhet (är långt ifrån inte bara i svenska forumet) måste komma bort från stigmat kring iD (med trådar som denna som extremexempel). Nej, det kommer aldrig bli ett verktyg som passar till allt (men det gör inte heller JOSM) och det saknar flera funktioner, men det är ett förhållandevis kompetent verktyg redan idag.

1 Like
2

Gatekeeping är inte enkom dåligt. Vi har haft några som har importerat i Norge och dom har haft noll koll. Det är därför det ser ut såhär nu och det är ingen som orkar ta tag i att fixa det: OpenStreetMap

Vi bör inte uppmana användare utan bred kunskap och erfarenhet till att jobba på stora importer :pray:. Det blir bara en osalig röra för alla andra att städa upp - om (när) det blir fel.

2 Likes
3

Förstår och håller med, så för att förtydliga vad jag menar: Gatekeeping utifrån använt verktyg är dåligt, gatekeeping utifrån OSM-kunskap kan vara bra och nödvändigt.

Ditt exempel visar ju också tydligt på att behovet att använda JOSM för importer inte hindrar personer med i övrigt bristande kunskap att köra på.

1 Like
4

Med risk för att bli tjatig och off-topic så är NVDB-importer uppdelade. Jag har nämnt det redan en gång. Och det finns tydlig information om detta på NVDB-projektets sidor. Och man läser där så baseras hela arbetsprocessen på unika funktioner i JOSM, som inte finns i ID. Även med dessa unika verktyg, så är NVDB-importen inget någon nybörjare kan eller ska ge sig på.

Emellanåt dyker det upp entusiaster här som tror att man med något magisk skript kan utför import från NVDB på kort tid. Dessa entusiaster brukar dock ganska snabbt inse att en sådan import är betydligt mer komplex än vad man kan tro. Och dessa personer går vidare till annat. Och jag kan tänka mig att sådan komplexitet finns i de flesta importer man tänker göra av större mängder öppen data.

5

Frågan är då om de är tillräckligt små. Och det är såklart en avvägningsfråga; för någon som har tiden att jobba ganska intensivt med det så är det såklart effektivare med större arbetspaket, för andra passar det bättre med mindre. Gillar t.ex. funktionaliteten som finns i HOT Tasking Manager där man enkelt kan dela upp en ruta i mindre bitar, men att få till något så användarvändligt för något så komplicerat som vägar är såklart icke-trivialt. Men ändå något man skulle kunna fundera på, om man vill få med fler som hjälper till!

Bra utgångspunkt för det som faktiskt skulle vara en framåtdrivande diskussion: vilka är de exakta funktionerna som saknas i iD? Känner de som utvecklar iD till behoven?

Kan arbetsprocessen justeras för att inte kräva dessa unika funktioner?

Återigen så är detta inget jag på något sett påstått. Här kommer problemet igen fram att det finns en utbredd åsikt att “iD användare = nybörjare / JOSM-användare = expert” vilket är det jag tycker man behöver komma ifrån. Ja, JOSM med sin högre tröskel kommer ha fler användare som hållit på länge nog att lära sig det verktyget och iD med sin lägre tröskel kommer vara det de flesta nybörjare börjar med, men det finns inget som hindrar någon att använda iD även efter att man inte längre kan anses som nybörjare, och som @Wulfmorn s exempel visade så behöver man inte vara expert för att försöka sig på en import med JOSM.

Jag råkar ha ganska bra koll på dataintegration av just vägar och specifikt med NVDB inblandat då jag var med och tog fram en hel del verktyg och processer kring Lantmäteriets övergång till att använda NVDB, och alla de svårigheter/komplexiteter som är inblandade i det. Ändå tror jag inte att det skulle vara omöjligt att få nytta av oss som inte investerat i att lära sig JOSM i det importprojektet, men för att mera säkert besvara den frågan så måste det först öppnas upp för att det kan vara en möjlighet.

Sedan så är vägar (och andra “ihophängande” datamängder som marktäcke m.m.) extra svåra just för att de hänger ihop, de flesta andra företeelser är enklare. Som ett exempel, och möjligen som inspiration till vad som skulle gå att lösa för vägar, så började jag skissa på följande process för att integrera byggnader från NGP:

  1. Hämta NGP-byggnader och OSM-byggnader i en kommun
  2. Matcha, byggnader med IoU över ett visst värde och med inget eller minimalt överlapp med andra byggnader anses vara samma
  3. Filtrera bort byggnader där geometrin har ett IoU över ett visst värde (de anses redan tillräckligt rätt i OSM), hänsyn i detta steg kan tas till de koordinatnoggrannheter som anges i NGP och källmaterial i OSM
  4. Lägg i tre “högar”:
    a. en med matchade byggnader där nya geometrin (den från NGP) inte skulle överlappa något annat i OSM och där byggnaden inte har t.ex. entré, eller där byggnad helt saknas i OSM
    b. en med matchade byggnader som inte hamnade i a., eller byggnad som helt saknas i OSM och utan överlapp med annat i OSM
    c. en med byggnader som inte kunde matchas i steg 2.
  5. Dela upp högarna i geografiskt sammanhållna kluster, t.ex. genom att klippa efter större vägar
  6. Tillhandahåll dels som filer för JOSM, och dels som GeoJSON eller dylikt för iD

Byggnader från hög a. skulle de flesta kunna hjälpa till med, även nästintill absoluta nybörjare, det finns ganska lite som kan gå fel med dem. Byggnader från hög b. kräver lite mer, då man kan behöva justera andra kringliggande objekt, men fortfarande möjligt för de flesta som karterat något tiotal timmar att hjälpa till med. Byggnader från hög c. är svårast, det kommer handla om byggnader som är uppdelade i antingen NGP eller OSM, och där man kan behöva göra mer komplicerade avvägningar. Notera att det dock bara handlar om svårast kunskapsmässigt, det finns inget hinder som jag ser just nu för att jobba med alla tre högar i antingen JOSM eller iD (förutsatt att iD får funktionerna nedan).

För att kunna jobba effektivt med det i iD skulle följande funktioner krävas:

  • Kunna jobba sig igenom alla objekt i data man lägger till (så att man inte missar något)
  • Visuell koppling mellan objekt i OSM och tillagt data
  • Knapp för att “merga in” taggar från kopplat objekt i tillagt data
  • Knapp för att ersätta med geometrin från kopplat objekt i tillagt data

Ingen av dessa punkter bör vara särskilt svåra att få till (med förbehåll att jag inte gjort mig bekant med iDs kod, än), d.v.s. det finns inget fundamentalt motsägelsefullt att utveckla dessa funktioner i en webbapp.

Ytterligare möjlighet skulle vara att lägga på en ref:se:ngp:byggnad= eller dylikt för enklare framtida uppdatering, dock skulle det utgöra ganska mycket data för bara den taggen på varje byggnad, så något man skulle behöva ta ställning till först.

6

Saknas det dokumentation för att minska gapet mellan iD, JOSM, casual och powermapper?

Jag har hållit på med OSM ett antal år, ibland tittat på JOSM men inte fattat något. Sedan några månader tillbaka använder jag det nästan uteslutande och förstår inte hur jag klarade mig utan så länge.

Det jag nu har problem med är att hitta lager och data som jag får använda, jag älskar NVDB lagret som i min värld hjälper mig att se om ortofoto ligger rätt, något som jag bara blundat för tidigare. Jag har dock ingen aning om hur jag ser beläggning, hastighet och annat utan står kvar på nivån, är det en cykelväg, gångväg eller bilväg?

Jag läser i WeeklyOSM att någon använt laserdata för att se genom träden, koolt det hade hjälpt mig men jag hittar inget information om att detta finns för Sverige. Nu läser jag i en anna tråd här att det kanske finns?

Jag hittar ett vattendrag som enligt kartan växlar mellan dike och å flera gånger på en sträcka av några kilometer, tror inte det är så i verkligheten men finns det något underlag som kunde hjälpa mig att korrigera kartan?

Jag kanske bara är sämst på att hitta vad vi har att tillgå här i Sverige men det är frågor som dessa som gör att jag inte tittar närmre på importprojekt, det blir för stort steg. Jag undviker ibland även att ändra saker för jag är rädd att det stör de importprojekt som jag vet pågår men det kanske medför att datat kommer vara felaktigt lång tid framöver?

7

Det tror jag kan vara en stor bidragande faktor till problematiken, ja. Tillsamnans med att iD säkert i början bidrog till en del dåliga ändringar, vilket jag förstår kan ha gett många veteraner en negativ bild, även om den sedan dess förbättrats.

Det gör det mycket riktigt, och det är till och med öppna data så fritt att använda!

Kan tyvärr inte svara dig hur du använder det i JOSM (en möjlighet i både JOSM och iD är att sätta upp en WMS-tjänst, men då riskerar man förlora mycket information och det är icke-trivialt tekniskt. Om du kan leta fram weeklyOSM-inlägget så kan säkert någon här hjälpa dig hur du ska göra med just svenska laserdata.

Kanske relevant: `osm-river-basins`: Website to show how are rivers in OSM connected

8

I början när jag startade med NVDB-projektet försökte jag jobba med “rutor”. Jag ritade in temporära motorvägar (!) för att få en visuell bild av ett rutnät. (Dessa motorvägar tog jag naturligtvis bort innan uppladdning). Men ju fler rutor man har, desto flera skarvar får man på vägar som passerar flera rutor. Alla dessa skarvar måste hanteras innan uppladdning. Skarven kunde i vissa fall hamna i exempelvis en komplex vägkorsning och “städning” av den blev extra svår. Detta gjorde att jag övergav den här metoden. Jag antar att skapa ett rutnät fungerar bättre för mindre objekt som byggnader etc. men objekt som har stor utbredning eller längd är det inte så enkelt.

I stället för ett fyrkantigt rutnät har jag nu (i vissa kommuner) gjort en uppdelning av vägnätet i mindre delar, så att antalet vägskarvar minimeras och att varje subdel blir ungefär 500 “ways” stor. Man skulle naturligtvis kunna minska storleken ännu mindre. Det ökar dock den total mängden vägskarvar. För min del är 500 ways lagom, och tar mig ca 5-10 arbetstimmar att göra klar. Och då jag har gott om fritid (är pensionär) så är den tiden överkomlig. Men kanske är sådana arbetspaket ändå för stora för vissa.

9

Ska försöka vara lite mer kortfattad för en gångs skull:

  • OSM är en do-ocracy, dvs de som gör jobbet bestämmer vad som händer. Föreslår man att man ska utveckla nya verktyg kommer det inte bli nya verktyg om man inte sätter sig ned och kodar själv, eller lyckas med konststycket att övertyga någon annan att göra det.
  • Det är långt ifrån alla som mappar i OSM som ens är intresserade av att OSM ska få en heltäckande högkvalitativ mappning i Sverige. Det är en ganska vanlig syn att man hellre ser OSM med hål i mappningen här och var, än att OSM till stora delar har likadant data som lantmäteriet. Jag tror detta är en mycket stark bidragande orsak till att importprojekt går trögt i Sverige.
  • ID-användare som lägger ned 100-tals timmar i ID men inte gått över JOSM så beror det inte på att JOSM är för svårt, utan då är man inte intresserad av att jobba med importprojekt alls. Det är helt okej, man har olika intressen. ID är ett utmärkt och effektivt verktyg för viss typ av mappning. Men inte just importer.
  • Jag tror det är dålig idé att lägga ner tid att försöka vidareutveckla iD till att bli nåt slags importverktyg. Dels tycker jag det är dumt att slösa utvecklingsresurser då det redan finns mycket kompetent verktyg för uppgiften (JOSM), och dels tror jag det är väldigt mycket utvecklingsarbete (som någon eldsjäl ska göra), och dels tror jag inte att det ändå kommer få så många att ansluta sig till importprojektet.
  • Även om man gör ett enkelt verktyg kommer det behöva vara precis lika mycket dokumentation att plöja om vad man behöver tänka på vid importen så man respekterar tidigare kartläggning och kompletterar manuellt med information som importen inte har, man kan se NVDB-projektets dokumentation som exempel. Jag tror det är en minst lika stor tröskel som att lära sig JOSM. Jag tror inte det är ett verktygsproblem först och främst.
  • Även om man gör ID till ett importverktyg där man kan jobba med mycket små paket och folk faktiskt sätter sig in och bidrar, så kommer det inte ändra på förhållandet att rekryterar man en power mapper som kör JOSM kommer den personen bidra mer i volym än 40 personer som casually importerar mikropaket.
  • Som Msiipola säger ovan så kan det beorende på geometri vara mycket tekniskt svårt att bryta ner i mikropaket. Byggnader enkelt. Vägar svårt, landtäcken svårt. För att dela upp NVDB i mindre paket så sitter en människa, oftast Msiipola eller jag själv, och lägger snitten på smarta ställen så det ska bli så lite skarvningsproblem som möjligt.
10

Precis, sånt jag syftade på med sammanhängande datamängder.

Men bara för att ge exempel (inte att jag menar att det ska göras): Man skulle kunna dela upp det så att man först har arbetspaket som bara hanterar de större vägarna (t.ex. highway=secondary or uppåt), och när det är färdigställt kan man dela upp resten med de större vägarna som avgränsning. Det blir inte uniforma paket som med rutnät; vissa kanske kommer att innehålla så lite att det grupperas med ett annat närliggande paket och vissa blir fortfarande en hel stadsdel, men det borde inte vara något problem i praktiken.

Gällande storleken så är det som sagt svårt; för min egen del så hade en tiondel av det varit mer passande; även om jag i alla fall på helgerna ofta har ganska många timmar sammanhängande lediga så har jag lärt mig undvika för stora åtaganden; jag kanske skulle hinna börja och göra typ en tredjedel, men sen ska något annat göras och jag kanske inte har tid igen på flera veckor, och under hela den tiden ligger det påbörjade arbetet och gnager och stressar. Bättre då för någon som mig med mindre arbetspaket och att jag med tur hinner göra klart flera.

Och problemet där är såklart att det för andra ser helt annorlunda ut; för dig är 5-10h idealt, för mig runt 1h, för någon annan ska det inte vara mer än en fikarast. Det är en jättesvår avvägning, och såklart speciellt svårhanterligt när någon skulle behöva göra uppdelningen mer eller mindre manuellt. Jag, och säkert ingen annan, väntar sig att du ska springa och ta fram uppdelningar efter alla dessa olika förutsättningar.

Kanske en möjlig lösning skulle vara att få igång fler importprojekt, där respektive projekt kör på olika storlekar på arbetspaket? Så att de med mer tid kan köra på NVDB, de med mindre på t.ex. byggnader?

11

Jag tror det kan vara ett marknadsföringsproblem. Jag och Msiipola framstår säkert som grumpy old men :slight_smile: (talar jag för mig själv stämmer det en del), så man behöver väl nån glad typ som raggar folk.

Och detta med arbetspaket. Det finns inget som kräver att man måste bli klar med sin NVDB-klump direkt, man kan dra ut det över längre tid och ladda upp i små bitar. Jag gör det själv hela tiden. Det enda är att man låser upp paketet man jobbar med så ingen annan kan jobba med det samtidigt, och man måste liksom committa sig att göra klart paketet innan man lägger ned helt så det går dokumentera vad som är genomgånget och ej.

Ett paket är kanske 5 - 10 timmars arbete. Men man kan dela upp det i 15-minutersbitar om man vill, man behöver bara binda upp sig att man kommer spendera tillräckligt många 15-minutersbitar så man kommer upp till de där 5 eller 10 timmarna som krävs.

(Uppdelningen tar JOSM hand om, man kan spara pågående arbete lokalt och sen stänga ned, vika ihop laptopen, ta hand om vardagens bestyr, och öppna upp senare och fortsätta där man var.)

12

Säger jag inte så mycket emot, så är det ju med alla open data/open source projekt. När det gäller ändringar i iD så har jag ganska högt på min lista att börja försöka sätta mig in i det (med prio 1 på bättre validering av multipolygoner).

Samtidigt måste man vara försiktig med denna tankegång, tar man den som en självklarhet riskerar man att landa i att “vi anpassar bara efter de som har mycket tid att ge, och redan gjort mycket” och på så viss strypa tillgången på nya som har tid att ge. Tyvärr är detta en vanlig fälla jag sett flera gånger i opensource-sammanhang, och även här ser jag samma tendenser (tydligast exempel är inlägget som föreslog att spärra iD i Sverige, vilket visar det extremt tydligt).

Bara utifrån mig själv, så har jag lagt ner 100-200h and counting på vad som möjligtvis kan bli ett importprojekt. Så för min del är dit påstående rent av fel.

Och även för andra tror jag återigen att detta till stor del är (omedveten) gatekeeping. Du ser att ingen icke-JOSM-användare deltar i importprojekt, och antar därför att iD-användare inte är intresserade av importprojekt. Det är inte möjligt att det finns många iD-användare som är intresserade (även om bara i sitt hemområde) men som inte kan eller vill lära sig ett nytt verktyg för det?

iD behöver inte (och kommer inte) bli ett multiverktyg på samma sätt om JOSM, men som tidigare beskrivet ser jag det inte som oöverkomligt att komma till en nivå där man ändå kan få värdefull hjälp av iD-användare.

Fullt förståeligt att det kräver att läsa på för import, men det innebär bara att någon som vill hjälpa till behöver sätta sig och lära sig 40+40h material (importen + JOSM), istället för 40h (importen, sitt vanliga verktyg kan man redan).

Och, för att igen utvidga till andra importprojekt än NVDB: I nästan alla dataintegrationsprojekt finns det olika delar av datat som är olika svårt att integrera. Genom att dela upp det likt i mitt exempel med byggnader öppnar man upp för personer som bara hinner/orkar sätta sig in i några paragrafer med instruktioner, samtidigt som de som har mer tid att ge kan fokusera på det krångligare delarna.

Och vad är problemet med detta?

13

För att förtydliga mitt tidigare inlägg; jag (som de flesta andra) håller på med OSM på fritiden, en fritid som även delas av annat (i mitt fall huvudsakligen renovering, andra programmeringsprojekt och hundpromenader). Eftersom det är min fritid vill jag kunna bestämma över den själv så mycket det bara går, sätter jag mig ned vid datorn kanske mappar lite i OSM, kanske jobbar med ett importprojekt (om jag skulle bli delaktig i ett sådant), kanske programmerar något helt annat, kanske bara tittar på YouTube. Även om det förekommer så är jag väldigt restriktiv med projekt där andra blir beroende av min fritid, då sånt alltid är förenat med extra tryck att välja just det projektet, även om jag kanske hellre skulle göra något annat. Att ge mig på större åtaganden har jag mitt vanliga arbete för :wink:

Så ja, självklart skulle jag kunna dela upp ett större paket i mindre bitar, men så länge inte hela processen är upplagd för att jag kan ta några små paket och göra dem, och sen försvinna från jordens yta i ett år för att jag har annat för mig, så kommer jag vara väldigt försiktig med att ge mig in i det.

Och jag tror att detta är en liknande problematik som många andra står för.

Jag har nog under det senaste halvåret lagt en 100-200h totalt på kartering, i bitar från 5 minuter till en halvtimme åt gången. På den tiden hade jag alltså hunnit med flera kommuner i NVDB-importen (minus tid att lära mig JOSM och importproceduren), men av ovan nämnd anledning har jag inte gjort det. Istället har jag lagt tiden på att mer eller mindre systematiskt gå igenom min hemkommun (Tierp och kartera allt jag ser från satellitbild). Fördelen med detta är att det som sagt inte påverkar någon annan nämnvärt om jag skulle tappa intresset mitt i; kommunen skulle inte vara färdigt genomgången men de bitar jag hunnit med hade varit bättre. Och jag behöver aldrig markera det som “ej färdigt” i någon wiki eller så, jag kan bara släppa det.

2 Likes
14

Jag försökte bara illustrera att det kan vara mer värt att lägga ner tid på att rekrytera power mappers. Man kommer ju behöva rekrytera vanliga casual mappers också, bara 40 ggr så många.

Något jag funderat på göra själv men inte orkat, vilket jag tror skulle vara lååååångt effektivare än hålla på och mecka med att bygga om iD, är att helt enkelt göra en youtube-video som går igenom hur man jobbar med ett specifikt importprojektet i JOSM. Många föredrar lära sig via en video istället för att läsa en massa text. Det skulle också gå visa där att när man väl kör är det inte så komplicerat, och det går jobba i mindre stunder åt gången.

Det finns väldigt många som tycker saker om JOSM som inte använder det. Jag har i alla fall använt ID i flera säsonger och använder det fortfarande som komplement. Att JOSM är svåranvänt för en nybörjare är samma anledning att ett CAD-program är svåranvänt, man blir overwhelmed över mängden funktioner varav man bara behöver använda en handfull själv, man vet bara inte vilka. Och så ser det lite osexigt ut med fula ikoner mm som alla Java-program utvecklade av frivilliga, webben har snott alla som kan göra snygga gränssnitt :slight_smile: .

Det finns faktiskt många som använder JOSM som inte jobbar med importprojekt, och där kan anledningen vara att man inte är intresserad, eller att man fått uppfattningen att det är för svårt eller att man behöver binda upp sig i väldigt lång tid och göra långa arbetspass. Bristen på intresse är det inte så mycket göra åt, men en instruktionsvideo skulle kunna visa att det inte nödvändigtvis är så svårt, och att man kan dela upp i korta arbetspass.

Jag har gjort instruktionsvideor i lite andra sammanhang som komplement till skriven dokumentation och det går direkt se ett lyft. Jag är dock långt ifrån en begåvning i att göra den typen av videor så det skulle innebära några veckors arbete för min del, och hittills har jag prioriterat att själv bidra med mappning istället, även om det potentiellt vore bättre spenderad tid att göra den där videon så man får in några fler i projektet.

15

Ja precis. Jag jobbar mycket ideellt inom idrott också och det är svinsvårt att få folk att göra saker, det är mycket svårare än förr, för det finns helt enkelt mer grejer att göra på fritiden, och folk vill absolut inte binda upp sig ens för ett par timmar, tiderna förändras. Jag är inte bättre själv, har duckat ett och annat funktionärsjobb genom tiderna kan jag säga…

Sen är det så att som jag nämnt tidigare att för många är OSM lite som att lägga patiens eller lägga pussel. Det är ett trevligt tidsfördriv. Och man vill behålla det trevligt, och importprojekt uppfattas sällan som trevliga. De är effektiva, men inte “mysiga”. Många uppfattar dem som lite hotfulla till och med (ska nån komma och förstöra min data nu med en tråkig importdatabas?). Jag ägnar mig själv åt mysmappning emellanåt för det gillar jag också, och det är värdefullt, man lägger in detaljer stigar genvägar mm som inte alls finns med i LM/NVDB.

Men så har jag ett övergripande mål och önskan att OSM ska vara heltäckande i Sverige med en hög lägstanivå på kvaliteten istället för svarta hål här och var (som oftast är glesbygd som jag brinner lite extra för), vars kvalitet höjs ytterligare med små lokala bidrag från “the crowd”, och då måste effektivare arbetsmetoder till.

Jag tror dock att den överväldigande mängden kartläggare i Sverige är såna vars primära mål är att mappningen ska vara optimalt kul för dem själva, de har ingen tanke på att kartläggningen ska vara effektiv, och man brinner inte alls för att OSM-databasen för Sverige i stort ska vara bra. Mytbildningen runt OSM är att all mappning görs av “the crowd” en väldigt liten ruta i taget, men sanningen är att grunden byggs upp av power mappers och att OSM inte skulle vara så framgångsrik som den är idag utan deras insats, som inkluderar importprojekt.

16

Det är är lite samma problem som jag försökt motverka på jobbet på sistone:

Vi är i stort behov av fler kollegor, helst personer med erfarenhet som man kan kasta in i kunduppdrag direkt. Problemet är bara att det inte bara är vi som har brist på såna, så även fast vi haft ute flera annonser, är en allmänt attraktiv arbetsgivare, o.s.v. så har vi inte lyckats fylla behovet. Senaste annonsen fick vi inte ett enda kvalificerat svar på.

Istället skulle vi kunna rekrytera nyexaminerade/juniora personer utan den erfarenheten. Vi påbörjade det i våras, fick 5-6 personer som var superintressanta, och fick sen direktiv uppifrån att vi inte fick anställa dem för att vi behövde folk med erfarenhet istället. Personer som alltså praktiskt taget inte existerar.

Så nu står vi här, fortfarande med brist på kollegor, erfarna kan vi inte rekrytera och juniora får vi inte.

Och här har du tagit upp något intressant, nästan alla dessa diskussioner jag sett inom OSM handlar bara om bristerna i iD, och hur dåligt iD är, och varför JOSM är så mycket bättre för erfarna.

Diskussionerna om vad som faktiskt skulle behövas för att göra JOSM mera tillgängligt, för att sänka tröskeln till dess användning är det däremot få som har. Du pratar om behovet av eldsjälar för att förbättra iD (vilket jag helt håller med om), men vart är önskan efter eldsjälar som förbättrar JOSM?

Utifrån erfarenhet från andra sammanhang så kan jag våga mig på en kvalificerat gissning: Man skulle kunna betala några miljoner på att ta in världens främsta experter på användarvänlighet och göra en revamp av JOSM som behåller alla avancerade funktioner men avsevärt sänker tröskeln för nykomlingar. Och vid första bästa tillfälle skulle en grupp veteraner som minsan vet bäst hur JOSM ska fungera ta tillfället i akt och rösta ner alla försök att ändra något.

17

Alltså jag tror vi är mer på samma sida egentligen. Jag är mycket besviken på hur OSM driftas globalt, att man inte lyckats professionalisera det mer, dra nytta av alla pengar som finns i storföretagen som använder databasen. Det borde finnas ett helt team med betalda utvecklare som bara jobbar med verktyg för oss kartläggare. Vi har världens största databas med öppna data med stora mjukvaruföretag i användarbasen men dras ändå med verktyg som ser ut som de var gjorda på 90-talet, och funkar lite så också.

Man ligger kvar i nån slags idealism att allt ska göras gratis, inklusive verktygen. Livrädda för att företagen ska få för mycket makt. Men det går navigera det. Istället är plattformen stangerad, API:t är i stort sett oförändrat sen 2008. Och du har mycket rätt i att det finns en utbredd veto-kultur inom faktiskt precis allt som är OSM. Alla nya förslag hittar man en anledning att säga nej till.

Mitt motstånd till att bygga om iD till importverktyg kanske uppfattas som jag är en del av den kulturen, men det är inte så. Det är för att jag inte tror på idén, och jag tror inte så jättemycket på potentialen i crowden att bli importörer. Men jag kan se att det kanske kan funka med instegsport, man gör det vääääldigt lätt att börja, och så börjar en del göra mer och mer och mer. Det är bara väldigt mycket jobb och tekniskt svårt att få till en sådan instegsport tror jag.

Det som vore lättast och ett bra pilotprojekt för att testa idén är att göra ett enbart för byggnadsdata när det kommer. Jag tror att det blir mycket drygt att få till för NVDB och generellt marktäcke.

Om du vill bygga något sådant så är jag all for it, och skulle älska om jag blir motbevisad och man ser stora volymframsteg. Men det blir nog svårt att övertyga mig om att programmera det :slight_smile:

För grejen det som är lätt att implementera i ID blir också extremt lätt att importera via JOSM. Ett byggnadslager kommer vara jätteenkelt att jobba med i JOSM då byggnader nästan aldrig är hopkopplad med andra polygoner och är väldigt små.

Skulle jag själv lägga ned programmeringstid på att förbättra verktyg i OSM-världen, vilket jag ibland funderat på, så skulle jag jobba på ett polygon-plugin till JOSM. Det är fortfarande obegripligt besvärligt att jobba med polygoner, gäller både iD och JOSM. JOSM har en del plugin med en del användbara funktioner som borde vara default, men fortfarande är det långt knöligare än det behöver vara. Var finns bounded flood-fill till exempel? Nä man ska vara in och peta i råa datastrukturer precis som de ser ut i databasen…

Hanteringen av routes är ännu värre… ojoj man ska inte tänka för mycket på det.

18

Jag har sett i annan tråd att det uppfattas som jag klankar ned på iD-användare. Pga JOSM/ID-kriget som pågår ovanför mitt huvud så tror jag favorisering av det ena eller andra verktyget för en viss uppgift kommer trigga folk. Det är tråkigt, men jag hinner inte riktigt med navigera den politiken.

Grejen är att ID saknar funktioner som krävs för att göra importarbeten, och det går generellt jobba snabbare i JOSM än i ID med personliga makron osv om man vill hålla på med det. Det är objektiva fakta.

Om det sen är bättre att vidareutveckla ID så det kan göra mer vad JOSM kan, eller vidareutveckla JOSM så att det inte är så förbaskat motbjudande fult knöligt för nykomlingar det är en åsikt som man kan ha den ena eller den andra. Jag tror mer på att vidareutveckla JOSM i det här läget, men har dålig koll på politiken i just det projektet. Av nån anledning ser det ju ut som det gör fortfarande, så risk att den är stark infekterad av veto-kultur. Det går alltid göra custom plugins dock, som är användbara för vana användare men gör inte programmet snyggare eller mer inbjudande för nykomlingar.

Jag anslöt till OSM sent, 2018. Jag har inget av den ursprungliga “OSM-filosofin” i blodet. Det som driver mig är att kartlägga hela Sverige och glesbygden så det automagiskt dyker upp i tjänster runtom i världen. Vill man bidra till en öppen geodatabas finns det bara ett alternativ, OSM, take it or leave it. Så fort OSM slutar ha relevans som leverantör till tjänster som faktiskt folk använder så kommer jag sluta bidra till OSM.

19

Det är nog inget som sker per automatik, men kommer man bara på rätt lösning så tror jag inte att det finns något fundamentallt motsägelsefullt i det.

Och kreativitet finns det ju faktisk gott om i OSM-sammanhang, bara nyligen stötte jag på MapSwipe som var nästan lite mindblowing för mig. Helt annat sätt att tänka kring att bidra till OSM, men samtidigt nog väldigt effektivt. Det är också ett arbetssätt som likt AI-verktyg kan ge väldigt mycket värde till power mappers, då man kan låta casual mappers (som kanske bara hinner swipa lite på pendeltåget) filtrera bort ointressant, så att power mappers kan fokusera på det viktiga.

Med det sagt så är det ju inte så lätt att tvinga fram en sån kreativ lösning.

Skulle vilja, men tiden krävs ju tyvärr också…

Också en av de första grejerna jag letade efter i iD, men är ganska säker att den aldrig kommer bli standard i varken iD eller JOSM, p.g.a. den eviga debaten om marktäcke ska ansluta till vägar eller inte.

Och det ena utesluter ju inte det andra, så länge det finns folk som är villiga att lägga ned tiden finns ju behov av förbättringar i båda verktyg, då de rent teknikmässigt nog aldrig kommer kunna helt ersätta det andra. Det kommer nog alltid finnas begränsningar i hur stora datamängder en webbapp kan hantera (även om taket sakta ökar med tiden), och lika så kommer det alltid finnas ett behov av ett verktyg som inte kräver installation.

Och det är ju faktiskt bara om man ser det ur väldigt kommersiella ögon som det blir ett antingen eller, d.v.s. onödigt att lägga pengar på separata spår. I praktiken, där vi som du säger tyvärr, är beroende av eldsjälar så kommer visa eldsjälar bara blossa upp för Java-utvecklingen i JOSM, och andra bara för webbutvecklingen i iD. Personligen tycker jag det är synd att Merkaartor inte är vanligare, då det teknikmässigt (C++/Qt) är det jag hade föredragit.

20

Angående svårigheter att göra NVDB-importen håller jag med. Tyvärr ser inte jag att man enkelt skulle förenkla det, förutsatt att man vill behålla info från gammal väg till ny, och som inte finns i NVDB-datat.

I JOSM används funktionen “Replace geometry” från plugin:en UtilsPlugin2. Utan den funktionen skulle importen inte kunna göras på rimlig tid. Och “rimlig tid” är det som i dagsläget är aktuellt. Dvs. 5-10 för delavsnitt, 50 timmar för en mindre landsortskommun. Och i ID finns inte någon funktion motsvarande “Replace geometry”, vilket gör att ID inte kan användas.

Även om “Replace geometry” underlättar mycket, är det bara grunden. Med den kan man göra enkla uppdateringar med 3 musklick! Tyvärr är dessa enkla fall ganska få. Och övriga mer komplicerad fall kräver att man har erfarenhet och kunskap. Alltså inget för casual mappers.

Om man hade ett verktyg (AI?) som kunde hantera även komplexa fall skulle det underlätta mycket. Ett verktyg som hade reglera för hur man gör i olika situationer. Som man nu manuellt får göra och besluta.