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
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.
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.
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.
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.
Jag har suttit i snart 2 år med min NVDB-fil för Arvika för att säkra att vägarna blir perfekta. Men kanske jag ska köra screencapture när jag importerar efteråt. Synd att man inte får med keyboard input. Jag testade med onscreen keyboard en gång men det är omöjligt att se vad som händer.
Steg 1 för Replace Geometry i JOSM är att ändra keybind så man inte har sönder händerna när man håller på med import.
Jag har mappat Replace Geometry till en extratangent på musen. En andra extratangent är kopplad till History. Fungerar väldigt bra, för två av de mesta använda kommandona jag använder.
Om man doppar tårna i JOSM:s bugghanterare så är det lätt att få bilden av att det idag drivs av en person som gör, två personer som vill men där livet inte längre tillåter och att de fajtas med en infrastruktur som behöver moderniseras samt med problemet att de inte kan släppa en ny version för att det inte går att förnya kodsigneringscertifikatet.
Så tyvärr ger det inte en trygg känsla av det verktyg som som OSM verkar helt beroende av.
Min avsikt var att belysa att även JOSM i min sin verkar dras med problemen som tidigare har nämts i tråden, som du säger “brist på resurser”. Så att hoppas på att JOSM kommer bli mer användarvänligt, vackert, snabbare utan att det dyker upp mer resurser t.ex. genom sponsring från OSMF (eller hur det nu funkar) är tyvärr inte troligt.
Det jag har gjort är att försöka förbättra buggbeskrivningar och skicka patchar kring mitt nischade intresse av poolen. Detta med insikten om att det inte ser ut som att någon kommer integrera dem i JOSM den närmaste tiden, men nu finns de i allafall därute om någon vill slita på dem.
Jag är inte förvånad att det ser illa ut med JOSM utveckling, det är “typiskt OSM”.
Men det är just det där som är så svårt att förstå. Man har en världsomspännande databas som används av flera stora företag, ja alla stora drakar som inte vill vara beroende av deras konkurrent Googles kartdata. Microsoft, Facebook, Apple för att nämna tre. Tusentals personer sitter och bidrar data världen över varje dag, år efter år. I kommersiella världen skulle OSM:s databas vara värderad till mångmiljardbelopp.
Hur kan man då hamna i den här situationen? OSM hankar sig fram, man har knappt resurser att drifta sin egen server, och det finns inte folk att utveckla verktygen. Det är obegripligt.
Men visst det hjälper inte att bara sitta här och klaga för ingen av oss här kan göra så mycket åt just den situationen.
Eller jo, det känns lite bättre nu faktiskt. Nu ska jag gå och dricka kaffe. Go kväll!
Tyvärr är det inte unikt för OSM, utan förekommer kring mycket öppen data/öppen källkod.
Som ett exempel kan nämnas OpenSSL, ett projekt (nej, det projektet) som underbygger all säker kommunikation på nätet, och utan att överdriva används av varje person som använder en dator, mobil eller surfplatta, och varje organisation som har någon form av hemsida eller nätverk. Skulle OpenSSL magiskt försvinna så skulle internet omedelbart krascha.
Och projektet har exakt två heltidsutvecklare (vilket i öppen källkod sammanhang ändå är många)…
Finns något begrepp från game theory som beskriver det hela; att alla vill få ut värde men ingen vill stoppa in pengar (inte tillräckligt i alla fall).
Obligatorisk relevant XKCD:
Ingen komplett lösning, men en tanke jag lekt med ett tag: Man kanske borde starta en “OSM Sverige”-förening, för att genom den samla in pengar från sponsorer (användare), som man sedan kan stoppa in i utveckling vi tycker är viktig, eller t.ex. för att köpa icke-öppna data. Min erfarenhet är att de flesta företag faktiskt är villiga att betala en mindre summa för något som ger dem stort värde, bara man hittar rätt person att prata med och kan skicka en svensk faktura. Har något sådant diskuterats tidigare?
Jag är bara en datapunkt så utgå inte bara från mitt svar, får du inte fler som svarar här så kan det nog vara värt ett separat inlägg. Men för min del skulle det inte hjälpa så jättemycket.
Dels för att största hindret fortfarande skulle vara tidsåtagandet, och dels för att jag föredrar text över video. Men speciellt text vs. video finns ju det ju många som tycker raka motsatsen.
Däremot skulle jag tycka det vore intressant rent allmänt att se hur ni som är vana JOSM jobbar, inte nödvändigtvis med NVDB-import utan även med “vanlig” kartering.
Vad gäller verktyg så är nog OBS det vanligaste svaret, gratis och går att göra praktiskt taget allt man behöver.
Jag hade uppskattat det. Försökte läsa instruktionerna igår efter att ha följt den här tråden och trots att de är väldigt detaljerade så kan det vara knepigt att visualisera flödet.
Bara att få se hur någon erfaren hanterar vanliga situationer hade varit väldigt nyttigt. Det blir tydligare vad som är viktigt, hur vägar delas, hur mycket finjusteringar som görs i omgivningen osv.
Jag gillar den här iden
Det finns lite embryo till detta i DK där de bjuder in till mapping-events ihop på plats och virtuellt. Syns på deras epostlista.
