Jag ska förklara. Ett stort projekt, som QGIS, är beroende av många komponenter som någon annan har kontroll över. Detta gäller GDAL, GEOS, PDAL, Untwine, men även många andra komponenter som ligger närmare operativsystemet och inte direkt kontrollerar geo-arbetet.
I det här fallet tar jag ett aktuellt exempel.
Här har jag laddat ner några rutor med laserdata från Lantmäteriet och konverterat dem (enkelt) till COPC i QGIS. Jag har sedan skapat en VPC fil för dessa (Virtual Point Cloud) så att det bara är en fil jag behöver hantera i QGIS. Jag skulle nu vilja skriva alla dessa till en enda COPC fil med verktyget ”Create COPC”, men det går inte…
Det är inte koden i QGIS i sig som är problemet utan det underliggande verktyget Untwine som kraschar.
Om jag testar med kommandot untwine manuellt så fungerar det inte på vpc-filer, men det kan finnas någon metod jag missar.
Kör jag mot de vanliga laz-filerna så fungerar det däremot hur bra som helst:
untwine --files=laz_dir --output_dir=laz_file.copc.laz --single_file=trueOm jag söker lite efter den felkod som rapporteras, så finns det en ”fix” för en typ av fel som genererar denna felkod. Och då framgår det att just det rapporterade felet har lösts i en nyare version av untwine, som inte är den version som är medpackad i QGIS.
Jag vet nu inte om mitt specifika problem hade lösts med en nyare version av untwine, men det belyser i alla fall ett problem som finns med att program är beroende av andra komponenter som hanteras av tredje part.
Det är lätt att ”klaga” på QGIS (i det här fallet), men man behöver nog vara lite mer ödmjuk än så. Man kan nog inte kräva att man alltid använder de senaste verktygen man är beroende av hela tiden. Det kan ju även vara tvärt om, nämligen att ett nytt verktyg har nya buggar eller funktioner som är borttagna, som i sin tur gör att något inte fungerar som det ska.
Slutsatsen är antagligen att det är viktigt att göra ganska omfattande systemtester när man släpper nya versioner av mjukvara. I ett fall med open source program som QGIS, som dessutom är ett av världens största och mest omfattande program med öppen källkod, är detta en monumental uppgift. Har man funktioner man är beroende av så är det väldigt viktigt att man själv har testprotokoll och metoder för att utvärdera nya mjukvaruversioner. Detta gäller absolut inte bara öppen källkod.
Om man inte själv testar nya versioner, helst innan de officiellt släpps, så får man vara lite extra ödmjuk om felen upptäcks efter lanseringen. Visst, det är bättre att rapportera buggar oavsett när man hittar dem, men det vore såklart bättre om vi kunde hjälpas åt innan större lanseringar.
Den 21/2 släpps nästa QGIS version (3.42) och samtidigt blir nuvarande version (3.40) ny LTR. Hur ser det ut för er. Har ni hittat och rapporterat alla irriterande ”buggar” i 3.40 ännu?
Det underlättar även att man har ett litet enkelt exempel som triggar buggar när man felrapporterar saker som den här.
Du har ju ett exempel och har till och med identifierat vari felet ligger. Detta är något som utvecklare av programmet gillar. Att man talar om vilken version av programmet man använder, och hur man har fått det installerat. Samt en felrapport som talar om vad man vill göra, hur man försöker göra det samt vilket fel som uppstår. Det är rätt många som bara skriver att det blir fel, utan att tala om den nödvändiga informationen. Utvecklarna kan varken läsa tankar över internet eller suttit bakom den som felrapporterat och ser vad de gör.
Så ja, felrapportera mer. Men lägg lite tid på att tala om information som man tror att programmerarna behöver för att 0) veta vad användaren vill göra 1) exempel som återskapar felet 2) version av programvara 3) varifrån kommer programmet (om man byggt det själv, laddat från webbsida eller från distributionen (OS) man kör).
Men ja, prova gärna utvecklarversionen någon månad innan den officiellt släpps, så att fel som man hittar kan fixas. Saker som fungerat men som nu slutat fungera.