QGIS 3.2 och snart ny LTR

Det är någon vecka kvar innan det är dags för den andra stabila versionen av QGIS 3, men jag tänkte kika lite på vad vi kan förvänta oss i slutet på Juni (efter den 22/6). Jag vill även testa nysläppta Linux Lite 4, så jag kombinerar båda dessa i en virtuell klient och kör på.

Linux Lite är en distribution som är tänkt att vara väldigt resurssnål och därför fungera väl även på lite sämre hårdvara. Linux Lite 4 är baserad på Ubuntu 18.04 och finns numera enbart som 64-bit. Har du väldigt gammal hårdvara som bara har 32-bitars arkitektur så kommer du därför inte längre att kunna använda Linux Lite.

Installationen är inte ett dugg problematisk, boota, klicka installera, välj språk, tangentbord, etc. Skapa användare och vänta, hela 5 minuter innan det är klart!

VirtualBox_LinuxLite_03_06_2018_09_01_36.png

Linux Lite använder xfce som skrivbordsmiljö, vilket gör att man kan anpassa allt som man inte trivs med i gränssnittets utseende, men Linux Lite ser faktiskt ganska trevligt ut redan från början. Bravo!

QGIS installeras med fyra kommandon i terminalen.

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key CAEB3DC3BDF7FB45
echo deb http://qgis.org/debian-nightly bionic main | sudo tee /etc/apt/sources.list.d/qgis.list
sudo apt update
sudo apt install qgis

Sedan är det bara att testa det som skall bli QGIS 3.2.

VirtualBox_LinuxLite_03_06_2018_09_13_11.png

”Ja, men det ser ju lika dant ut som med 3.0…”

Japp! QGIS 3.2 är väldigt likt 3.0, men visst finns det nyheter.

Exempelvis så kommer det i lagerlistan att synas om ett lager är filtrerat:

VirtualBox_LinuxLite_03_06_2018_09_28_48.jpg

Titta noga på den markerade raden i lagerlistan, till höger finns en liten ”filtertratt” som indikerar att det finns ett aktivt ”Leverantörs objektfilter” (suck, en del översättningar i gränssnittet är inte direkt bra).

En annan nyhet är att det nu är betydligt enklare att skapa egna tools i Python med hjälp av välkommenterade mallar.

VirtualBox_LinuxLite_03_06_2018_09_46_33.jpg

Detta är speciellt uppskattat då man i och med 3.0 i princip tog bort möjligheten att skapa förenklade pythonverktyg med anpassad kod. Det nya sättet att skapa verktyg är mer omfattande, men följer normal python syntax och lägger inte till QGIS specifik kod, som bara fungerar med QGIS.

Det blir inte jättemycket nyheter rent användarmässigt i 3.2, åtminstone om man jämför med alla nyheter i 3.0. Det fanns en hel del som inte hanns med i detaljer och i bakgrunden inför 3.0 och detta skall man till del komma ikapp med till 3.2.

Det blir även ett bra test inför nästa version eftersom 3.4 kommer att bli en starkt efterlängtad LTR version av QGIS. 3.4, som senare i höst kommer att användas i väldigt många produktionsmiljöer runt om i världen under lång tid framöver, så särskilt stor vikt kommer att läggas vid att få 3.4 så stabil och effektiv som det över huvud taget går.

Förvänta er inte för mycket nya funktioner i 3.2! Jag uppmanar er dock att installera och testa programmet så mycket det bara går, och dokumentera och rapportera alla tänkbara buggar och konstiga arbetsflöden som ni skulle vilja få fixade inför 3.4 LTR. Om det är funktioner som ni är särskilt intresserade av att få till så överväg om ni skall kontakta något av alla konsultföretag med ”core” utvecklare för att se om det går att finansiera en sådan ändring. Är det bara en ändring som projektet tycker gynnar helheten så skall detta inte vara några större problem (förutom tid och pengar). Om du inte känner att du, eller ditt företag, själva kan finansiera en ändring så går det att kontrollera med QGIS Sverige (http://qgis.se) om det finns andra som är intresserade av samma sak, och då medfinansiera en uppdatering.

Det är nu inte läge att luta sig tillbaka och hoppas att någon annan hittar och rapporterar alla fel och brister i QGIS inför hösten! Använder du eller din organisation programmet så bör ni avsätta tid att säkerställa att era arbetsflöden kommer att fungera även om ett år. Det gör ni bara genom att testa!

  • Lägg in tid i schemat för tester.
  • Skapa testprotokoll.
  • Undersök om nya funktioner förenklar något arbetsflöde.
  • Testa nya funktioner.
  • Dokumentera och rapportera buggar.
  • Behövs ändringar i infrastruktur/lagring, databasversioner, etc.
  • Beräkna kostnader för införandet (budgetera).
  • Har ni skript och mallar som behöver uppdateras.

För att uppgraderingen från 2.18 till 3.4 skall bli så smidig som möjligt så måste ni börja nu!

Annonser

Taggar:

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut /  Ändra )

Google+-foto

Du kommenterar med ditt Google+-konto. Logga ut /  Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut /  Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut /  Ändra )

w

Ansluter till %s

%d bloggare gillar detta: