Det är lätt att lyfta fram och berömma de stora nyheterna och nya funktionerna när utvecklingen av QGIS går framåt. Det är mindre vanligt att ta upp alla de ”små” ändringar som pågår mer eller mindre obemärkt.
I detta inlägg tänkte jag ta upp några ändringar vi har att se fram emot, men som kanske inte kommer att få så mycket uppmärksamhet.
Ett exempel av kanske lite mindre betydelse rent tekniskt är hur akronymer presenteras i QGIS. Just nu är det lite blandat.
Det är stora bokstäver, små bokstäver, blandat…
- WMS
- wms
- Wms
Genom att titta på hur akronymer hanteras i stödsystemen så pågår det ett arbete som skall harmonisera sättet att skriva akronymer i QGIS med Qt. Detta innebär så kallat ”Camel Case” fast med inledande versal. Det skall med andra ord heta ”Wms”, ”Crs” och ”Url”.
Allt är däremot inte logiskt. Under hösten så ändrades nämligen alla ”QGis” till ”QGIS”, delvis med motivet att det är en akronym…
Vi får väl se vad som blir ändrat i praktiken när QGIS 3 väl släpps. Det kommer även att påverka arbetet med översättningar av gränssnittet. Oavsett hur det blir är det jättebra med designregler för hur olika saker skall utformas. Det vore däremot bra om man var konsekvens (hmmm).
I listor med förändringar kan man ofta läsa rubriker som man inte har en aning om vad det handlar om. Smaka exempelvis på ”QgsComposition requires a QgsMapSettings object”.
Det handlar om ”composer” eller layouten och de kartelement som man kan lägga till där. Om man tvingar ”kompositionen” att vara beroende av kartinställningarna, så blir alla kartelement i kompositionen beroende av den inställningen. Det går med andra ord inte att ha olika inställningar för exempelvis koordinatsystem i olika kartelement.
Genom att i stället ”flytta” kartinställningarna till kartelementen så tar man effektivt bort ett hinder för detta! Nu får vi vänta och se om det får någon praktisk effekt i QGIS 3.
Ett annat mindre glamoröst, men ack så viktigt, bekymmer är vilka datatyper som skall vara tillåtna i attribut. Exempelvis så kan man använda QVariant, vilket även kan hantera QBrush eller QSize, som sannolikt aldrig kommer att användas i ett attribut. Ett förslag är i stället att skapa en förenklad lista med tillåtna attributtyper, men låta QVariant vara containern för dessa. En sådan ändring påverkar exempelvis möjligheten att lagra sekundära geometrier till geografiska objekt. Vilken datatyp skulle det i så fall vara.
Detta är endast några exempel på alla förändringar som pågår i bakgrunden utan att vi normala användare känner till det. Det kan däremot vara idé att kika in på QEP listor (https://github.com/qgis/QGIS-Enhancement-Proposals) och listor med API problem (https://github.com/qgis/qgis3.0_api/issues) lite emellanåt. Då kanske man kan få lite inblick i vad som är på gång, men även bli uppmärksam på något som kanske är på väg i fel riktning för dina arbetsflöden, och lyfta sådana farhågor direkt till utvecklarna.