QGIS News #2. QGIS 3

Najważniejszym wydarzeniem w GIS w tym roku będzie opublikowanie wersji oznaczonej numerem 3. Dlaczego ta zmiana jest tak znacząca? W jaki sposób wpłynie ona na społeczność? Zapraszamy do lektury wszystkich użytkowników QGIS – szczególnie tą jej części, która aktywnie uczestniczy w rozwoju aplikacji m.in. poprzez tworzenie wtyczek i skryptów.

QGIS API

API jest to tzw. interfejs programistyczny aplikacji (z ang. Application Programming Interface). Za jego pomocą aplikacje mogą się komunikować między sobą. Dostępnych jest wiele rodzajów API. Aplikacje internetowe wykorzystują żądania, np. w formie adresów URL, których można użyć do pozyskiwania z nich informacji lub manipulowania danymi. Przykładem może być API naszej aplikacji DIVI do zarządzania danymi przestrzennymi. Swoje własne API mają również takie serwisy jak Facebook czy Twitter. W przypadku aplikacji desktopowych są to zazwyczaj udostępniane przez nie funkcje lub klasy. W ten właśnie sposób działa QGIS, który można sobie wyobrazić jako zestaw bibliotek (pliki .dll w Windows, .so w Linux) zawierających klasy poszczególnych elementów aplikacji związanych zarówno z interfejsem graficznym (okno mapy, przyciski, panele itp.) jak i manipulowaniem danymi przestrzennymi (obsługa różnych formatów, operacje na geometrii i atrybutach itd.). Sam plik wykonywalny QGIS po prostu wywołuje te klasy i ich metody tworząc znane wszystkim okno główne programu oraz wykonując różne operacje.

API ewoluuje z każdą kolejną wersją poprzez dodawanie nowych klas i funkcji lub aktualizację już istniejących. Zazwyczaj zmiany te są wstecznie kompatybilne tzn. ich wprowadzenie nie wpływa na działanie innych narzędzi wykorzystujących istniejące rozwiązania np. wtyczek. Dzięki temu działają one w nowym wydaniu bez konieczności aktualizacji. QGIS API jest udokumentowane i dostępne jako strona internetowa. Jest ono wersjonowane i można przejść na stronę API dla konkretnych wydań QGIS aby porównać zmiany jakie w nim zaszły.

Zdarza się jednak, że programiści wprowadzają nowe rozwiązanie, które zastępuje już istniejącą funkcjonalność. Powoduje to konieczność stworzenia zestawu nowych klas i funkcji, które częściowo pokrywają się zakresem z istniejącym kodem. Najczęściej stare klasy pozostają w kodzie i ciągle mogą być używane przez inne narzędzia. Przykładem jest wprowadzenie w QGIS 2.10 i późniejsza rozbudowa nowego silnika geometrii. Aktualnie oba silniki działają równolegle i mogą być wykorzystywane przez programistów. Na stronie QGIS API można znaleźć wiele klas, które w nazwie posiadają dopisek V2, oznaczający, że zastępuje ona starsze rozwiązanie. Taki system jest dobry, ponieważ z jednej strony pozwala na działanie istniejących wtyczek jak i daje programistom czas na przejście do nowego API. Należy jednak pamiętać, że powoduje to zwiększanie rozmiaru kodu źródłowego przez co staje się on trudniejszy w utrzymaniu i testowaniu. Dlatego w pewnym momencie istnieje konieczność usunięcie starych rozwiązań i pozostawienia tylko nowych. Jak można się domyślić powoduje to brak wstecznej kompatybilności aplikacji i wiele z nich przestaje działać. W projekcie QGIS taka sytuacja jest sygnalizowana przez autorów zmianą głównej liczby w wersji aplikacji. Ostatnio miała ona miejsce we wrześniu 2013 r. kiedy po QGIS 1.8 pojawiła się wersja 2.0. Teraz czeka nas kolejny skok z wersji 2.18 na 3.0.

Zerwanie wstecznej kompatybilności nie wynika tylko z konieczności wyczyszczenia QGIS API, ale również z powodu pojawienia się nowych, stabilnych wydań innych aplikacji wykorzystywanych przez QGIS.

Qt 5

Qt jest programistycznym frameworkiem umożliwiającym tworzenie graficznych interfejsów aplikacji na wiele platform m.in Windows, OS X czy Linux. Liberalna licencja pozwala na korzystanie z niego bez opłat, co znacząco przyczyniło się do jego popularności, szczególnie w świecie Open Source. Jest to podstawowy zestaw bibliotek i narzędzi, z których korzysta QGIS.

Wersje QGIS 2.x korzystają z Qt 4.8. Od grudnia 2012 r. dostępna jest wersja 5 tego frameworka, najnowsze wydanie oznaczone jest numerem 5.8. Przynosi ono wiele usprawnień, szczególnie w zakresie tworzenia interfejsów oraz szybkości renderowania grafiki, co jest szczególnie ważne dla takiej aplikacji jak QGIS, która często musi wyświetlać skomplikowane obiekty przestrzenne. Qt 5 zostało zaprojektowane w ten sposób, aby było jak najbardziej podobne pod kątem API do poprzedniej wersji. Dzięki temu istnieje możliwość kompilacji QGIS 2.x z Qt 5. Problem jednak pojawia się przy wtyczkach, które często posiadają kod działający tylko z Qt 4, ze względu np. na import modułów lub starą formę łączenia sygnałów i slotów. QGIS 3 będzie dostosowany tylko do Qt 5, w związku z czym przestanie działać wiele wtyczek, które nie będą dostosowane do nowego API.

Python 3

Kolejnym ważnym elementem, z którego korzysta QGIS jest język programowania Python. Kilka lat temu opisaliśmy, w jaki sposób można wykorzystać Python w celu rozszerzenie możliwości głównej aplikacji. Najbardziej popularne jest tworzenie własnych wtyczek oraz skryptów uzupełniających brakujące funkcjonalności.

Aktualnie istnieją dwie główne wersje interpretera języka Python: 2 i 3. Wersja 3 została wydana w 2008 r.i oferuje ona wiele nowych lub zmienia wcześniejsze rozwiązania. W przeciwieństwie jednak do Qt, który starał się zachować wsteczną kompatybilność z wcześniejszą wersją, nowy Python nie jest napisany pod tym kątem. Sytuacja jest tu bliższa QGIS’owi, gdzie zmiana głównej wersji pociąga za sobą znaczące zmiany w API. Początkowo, głównie ze względu na niewielką liczbę dostępnych modułów, Python 3 nie był zbyt popularny i większość projektów pozostała przy gałęzi 2.x. Z tego też względu wsparcie dla Pythona 2.x (aktualnie 2.7) zostało przedłużone z 2015 r. do 2020. Jednak z czasem większość bibliotek została przystosowana do nowej wersji i coraz więcej osób przenosi kod źródłowy na wersję 3.

Na stronie PythonClock znajduje się informacja o czasie jaki pozostał do przejścia na nowszą wersję.

QGIS 3 będzie wspierał tylko Python 3, tak więc narzędzia, które nie są do niego dostosowane przestaną działać i będą wymagały wprowadzenia poprawek.

GDAL 2

QGIS 3 porzuci również wsparcie dla bibliotek GDAL/OGR w wersji poniżej 2.0. Ten krok w najmniejszym stopniu będzie odczuwalny dla zewnętrznych programistów, ponieważ w zdecydowanej większości przypadków nie korzystają oni z niej bezpośrednio, ale za pośrednictwem QGIS API. Sam QGIS od dłuższego czasu działa z wersją 2.0 (lub nowszą) tych bibliotek. Porzucenie starszej wersji pozwoli jednak na usunięcie z kodu źródłowego zależności, które do tej pory były wymagane aby aplikacja poprawnie z współpracowała GDAL/OGR 1.x.

Termin wydania QGIS 3.0

Na chwilę obecną nie ma dokładnej daty wydania QGIS 3.0. Na przełomie kwietnia i maja br. planowane jest spotkanie programistów w niemieckim Essen. Mniej więcej wtedy QGIS przejdzie do fazy feature freeze, czyli nie będą dodawane nowe funkcjonalności, a programiści skupią się na usuwaniu błędów i dopracowaniu wprowadzonych narzędzi. Następne spotkanie twórców ma odbyć się na początku sierpnia w duńskim Nødebo. Jeśli nic nie będzie stało na przeszkodzie po tym terminie zostanie wydana nowa wersja. Należy jednak podkreślić, że nie są to oficjalne terminy i mogą one zostać zmienione.


Jak widać z powyższego opisu QGIS 3 przyniesie wsparcie dla nowych wersji wykorzystywanych przez niego narzędzi. Jednocześnie kod źródłowy QGIS zostanie odchudzony poprzez wyczyszczenie API i zastąpienie starych rozwiązań nowymi, często szybszymi metodami. Wydaje się, że to dużo zmian jak na jedno wydanie. Należy jednak mieć na uwadze, że dzięki temu ograniczone do minimum zostaną niedogodności zarówno dla twórców rozszerzeń jak i użytkowników aplikacji. Ci pierwsi będą musieli dostosować kod tylko raz (w przeciwieństwie do kilku podejść jeśli zmiany wprowadzane byłyby stopniowo). QGIS w wersji 3.0 nie będzie wydaniem LTR, najprawdopodobniej status ten zostanie nadany kolejnej oficjalnej wersji czyli 3.2.  Da to dodatkowy czas programistom na poprawienie i przetestowanie stworzonych przez siebie narzędzi.