Budowanie wykazów nazw

Ostatnimi czasy dużo się działo w kwestii QAZP2. Ostatnie poprawki błędów, niekiedy dość poważnych, nowe funkcjonalności - na przykład wykonywanie skryptów modyfikujących zawartość bazy danych - co może mieć znaczenie, gdy osoba odpowiadająca za techniczny aspekt bazy połączonej z QAZP2 nie ma do niej bezpośredniego dostępu. W takim wypadku wystarczy spreparować skrypt SQL i wysłać do użytkownika, który za pomocą interfejsu graficznego aplikuje przygotowane zmiany. Rzecz jasna taki mechanizm jest pewnym zagrożeniem dla stanu bazy danych, jednak jest to koszt, który można ponieść, pamiętając, by nie stosować skryptów z niepewnego źródła. Między innymi z tego powodu trudno było mi znaleźć czas i spełnić obietnicę, że nowe artykuły będą wprowadzane conajmniej raz na tydzień.

Ostatnimi czasy na blogu była poruszana kwestia wykazów pojęć archeologicznych, których używa się do klasyfikacji kulturowo-funkcjonalno-historycznej. W QAZP2 wykorzystywane są do tego wykazy przygotowane w Narodowym Instytucie Dziedzictwa i uzupełnione o nazwy, których obecności wymaga praktyka badań archeologicznych. Ich konstrukcję próbowałem opisać w poprzednim artykule, natomiast dzisiaj chciałbym przedstawić inne podejście, które chociaż nie zostało wdrożone, to wydaje się ciekawą alternatywą dla wyżej wspomnianego sposobu budowania wykazów.

Transformacje współrzędnych w QGIS

Nanosząc nowe obiekty w QGIS posługujemy się pewnym systemem odniesienia. Umożliwia on określenie dla dowolnego punktu jego rzeczywistego położenia na powierzchni kuli ziemskiej za pomocą współrzędnych prostokątnych płaskich, które oznaczają w jakiej odległości znajduje się od początku układu. Istnieją globalne systemy odniesienia - obecnie stosowanym standardem na przykład w odbiornikach GPS jest układ WGS84 (GRS80), z kolei w Polsce dla ma mało skalowych (czyli bardziej dokładnych) stosuje się układ 1992. Niekiedy zachodzi konieczność przekształcenia współrzędnych z jednego układu w drugi i zazwyczaj robi się to, by z lokalnego odwzorowania otrzymać globalne, albo w drugą stronę. W QAZP2 mamy do czynienia z drugą sytuacją, gdy odczytując dane z odbiornika GPS zapisane w globalnym układzie WGS84 trzeba je przekształcić na lokalny system 1992.

Zadanie to można wykonać na dwa sposoby:

1. Przy pomocy funkcji przestrzennej bazy danych: funkcja ST_transform(wspolrzedne, srid) (Postgis).
2. Wykorzystując metody z API QGIS.

Funkcja ST_transform przyjmuje dwa parametry: współrzędne oraz srid - identyfikator  systemu odniesienia. Przy czym oryginalny układ odniesienia dla danych które się przekształca musi być znany. Identyfikator układu WGS84 jest równy 4326,  natomiast układu 1992: 2180. Jeżeli oryginalne współrzędne będą zapisane w pierwszym z wynienionych i przekształcamy je do drugiego, to oczywiście będzie prawdziwa następująca relacja: wspolrzedne = ST_transform(ST_transform(wspolrzedne,2180),4326). Pierwsze wywołanie funkcji przekształca je do układu 1992, drugie do układu WGS84 i ta wartość powinna być równa początkowej. Funkcję ST_transform można stosować we wszytkich poleceniach DML oraz DQL do przestrzennej bazy danych.

Podobną operację można wykonać przy pomocy metod z interfejsu QGIS. W tym celu posługujemy się klasą QgsCoordinateReferenceSystem, która służy do reprezentowania wybranego układu odniesienia. Jej obiekt możemy uzyskać na dwa sposoby: ze wskazanej warstwy wektorowej QgsVectorLayer przy pomocy metody crs(), albo konstruując nowy, gdzie w parametrze podaje się identyfikator układu, np. 4326. Klasa QgsGeometry, która w QGIS reprezentuje współrzędne geograficzne posiada metodę transform, za pomocą której dokonuje się przekształcenia. W jej parametrze podaje się obiekt klasy QgsCoordinateTransform tworzony przez podanie oryginalnego i docelowego systemu odniesienia. Przykład wykorzystania zastosowania tego mechanizmu znajduje się w metodzie lib.qgsop.dodaj

Przepis na PostGIS

Podstawą działania QAZP2 jest przestrzenna baza danych. Informacje o śladach działalności człowieka, a także o prowadzonych badaniach archeologicznych łączy się z przestrzenią po przez dodanie do nich współrzędnych geograficznych. W przypadku archeologii jest to kluczowa informacja, gdyż umożliwia analizę danych w kontekście krajobrazu i środowiska, które prawdopodobnie miały niebagatelny wpływ na decyzje podejmowane przez dawnych osadników.

Zanim przejdę do omówienia schematu bazy danych, do którego dostosowany jest QAZP2, w kilku zdaniach opiszę przygotowywanie systemu PostgreSQL do pracy z bazami przestrzennymi. Nie zamierzam szczegółowo omawiać poszczególnych poleceń - lepiej ode mnie robi to bogata dokumentacja. Zgodnie z tytułem - to ma być przepis, który szybko pozwoli upiec ciastko ;). Będę pisał z perspektywy użytkownika Linuksa, a dokładnie Debiana i zakładam, że czytelnicy posiadają podstawową wiedzę na temat posługiwania się tym systemem.

1. Instalacja i konfiguracja PostgreSQL

# apt-get install postgresql postgis

To polecenie chyba nie wymaga komentarza. Po kilku albo kilkunastu minutach oczekiwania (w zależności od prędkości połączenia) aktualna wersja oprogramowania - czyli system PostgreSQL i jego rozszerzenie Postgis powinno znaleźć się na dysku i zostać zainstalowane i uruchomione.

# cd /etc/postgresql/{wersja}/main/
# cp pg_hba.conf pg_hba.bak
# echo "local all all password" >> /etc/postgresql/{wersja}/main/pg_hba.conf
# /etc/init.d/postgresql restart

W domyślnej konfiguracji z bazą może się połączyć użytkownik root albo specjalnie tworzony do tego celu postgresql. A więc przed nawiązaniem połączenia z bazą i wykonaniem polecenia SELECT, UPDATE, CREATE itp. należy zalogować się jako root albo postgresql (ten drugi ma zdefiniowane domyślne hasło postgresql). Osobiście wolę inne podejście, w którym użytkownika i hasło podaje się w chwili łączenia z bazą danych. Ma ono dodatkowe uzasadnienie: w sytuacji, w której będziemy próbowali się połączyć w QGIS z bazą jako inny użytkownik, na przykład milosz, w domyślnej konfiguracji Postgre odrzuci nasze rządanie. Dlatego do pliku pg_hba.conf dodajemy następujący wiersz local all all password (trzecia linia). Żeby zabezpieczyć się przed uszkodzeniem tego pliku, wcześniej (druga linia) należy wykonać jego kopię zapasową. Ta operacja wymaga zrestartowania systemu, co czyni polecenie w lini czwartej.

To jest najprostsza konfiguracja, jaką można sobie wyobrazić, ale w zupełności wystarcza do lokalnego testowania i korzystania z systemu PostgreSQL.

# createuser -U postgresql -W -d -P tester

Na koniec tworzymy nowego użytkownika o nazwie tester, który będzie uprawniony do tworzenia nowych baz danych (przełącznik -d). Przełącznik -P oznacza, że w chwili tworzenia użytkownika zostaniemy poproszeni o nadanie mu hasła. Przełączniki -U i -W są standardowe dla każdego polecenia PostgreSQL. Pierwszym wskazujemy tego użytkownika, jako który łączymy się do bazy w celu utworzenia nowego - w tym przypadku tym użytkownikiem jest wspominany już postgresql; użycie drugiego spowoduje, że przed dodaniem nowego, trzeba będzie podać hasło użytkownika postgresql.

2. Tworzenie bazy PostGIS

# createdb -O tester -h localhost -p 5432 -U tester -W azp2
# createlang plpgsql -U tester -W azp2

Kiedy nowy użytkownik jest już dodany, czas na utworzenie bazy danych. W pierwszym poleceniu tworzymy nową bazę o nazwie azp2, której właścicielem będzie tester (przełącznik -O). Po wykonaniu drugiej komendy w bazie azp2 będzie można tworzyć procedury w języku PL/SQL. Przełączniki -W i -U mają takie samo znaczenie, jak przy dodawaniu nowego użytkownika.

# cd /usr/share/postgresql/{wersja_postgre}/contrib/postgis-{wersja_postgis}
# psql -f postgis.sql -U tester -W azp2
# psql -f spatial_ref_sys.sql -U tester -W azp2

Na koniec do bazy azp2 trzeba dodać procedury, których używamy np. do dodawania współrzędnych, wyszukiwania na ich podstawie, itd., które są zaimplementowane w języku PL/SQL, o którym pisałem powyżej. Polecenia, które dodają wspomniane procedury znajdują się w katalogu utworzonym w chwili instalacji Postgis. Przechodzimy do niego w pierwszej lini, a następnie wywołujemy narzędzie psql podając jako parametr plik postgis.sql, który zawiera definicje procedur SQL. Do pracy z przestrzenną bazą danych przydatne będzie także dodanie definicji systemów odniesienia, które są używane do konwertowania współrzędnych. To także robimy za pomocą polecenia psql podając jako parametr plik spatial_ref_sys.sql.

I tyle. Baza przestrzenna jest gotowa do pracy. Od tej chwili można już tworzyć tabele ze współrzędnymi geograficznymi. Ale o tym innym razem.

Kontekst

Zanim zagłębię się w problemy technologiczne, chciałbym krótko nakreślić ich kontekst, czyli powód dla którego jest rozwijany program QAZP2. Historia rozpoczyna się w 2010 roku, kiedy w związku z rozpoczęciem projektu naukowego w Instytucie Prahistorii UAM, finansowanego ze środków Narodowego Instytutu Dziedzictwa, pojawiła się potrzeba ewidecjonowania wyników badań w relacyjnej bazie danych.  Ważnym składnikiem zapisywanych w niej informacji jest tak zwany komponent przestrzenny, czyli współrzędne geograficzne. W ten sposób wyniki badań mogą być analizowane w kontekście środowiska i krajobrazu, co ma się przyczyniać do lepszego wyjaśniania decyzji podejmowanych przez ludzi w przeszłości.
Jako kontener do przechowywania danych został wybrany system PostgreSQL wyposażony w rozszerzenie PostGIS, które to umożliwia zapisywanie informacji przestrzennych.
Biorąc pod uwagę marny stan finansów polskiej nauki i instytucji zainteresowanych wykorzystywaniem takich informacji do ochrony zabytków w Polsce podjęto decyzję, że wszystkie narzędzia powinny być bezpłatne i tym samym obniżyć próg wejścia. Dlatego do gromadzenia danych jest używany wspomniany PostgreSQL+PostGIS, a do ich wyświetlania program QuantumGIS (QGIS). Ta aplikacja umożliwia proste wprowadzanie danych przestrzennych i tekstowych, jednak ten mechanizm jest niewystarczający do wprowadzania szczegółowych informacji pochodzących z propspekcji terenowej. Rozbudowany formularz do wprowadzenia danych jest realizowany właśnie jako QAZP2.
Zgodnie z aktualnymi założeniami ma umożliwiać wprowadzanie informacji o miejscach, czyli punktach rejestrowanych za pomocą odbiornika GPS; trasach - czyli zapisu drogi, która została pokonana na ziemii albo w powietrzu w czasie wykonywania zdjęć lotniczych; stanowiskach - czyli odnalezionych śladach działalności człowieka - np. osadach, obozowiskach, osadach itp. Oprócz "świeżych" danych w bazie mają się znaleźć także archiwalne pochodzące z badań AZP prowadzonych na przestrzenii lat, które mniej więcej od ostatniej dekady XX wieku są zapisywane w postaci elektronicznej. Ważne w tym wszystkim jest niedestrukcyjny charakter badań, czyli to, że nie prowadzą one do zniszczenia śladów osdanictwa w trakcie wykopalisk, a główną przesłanką do ich prowadzenia, oprócz wyjaśniania przeszłości, jest ich efektywna ochrona przed zniszczeniem.
W obecnej wersji 0.6, która jest dostępna od Poniedziałku do bazy danych można już wprowadzać wszystkie zakładane typy informacji, czyli miejsca, trasy i stanowiska. 

Początek

Przed chwilą zatwierdziłem ostatnie zmiany w QAZP2, czyli nowej wtyczki do QuantumGIS, której zadaniem jest wspomaganie użytkowników w zarządzaniu informacjami zbieranymi w trakcie nieinwazyjnych badań archeologicznych. I pomyślałem, że być może warto opisać doświadczenia z realizacji tego projektu, przede wszystkim po to, by nie umknęły mej pamięci, ale też ze względu na to, że problematyka tworzenia rozszerzeń do QuantumGIS jest w polskojęzycznym internecie rzadko omawiana.
W związku z tym tworząc ten dziennik chciałbym poruszyć następujące kwestie:

1. Wykorzystywanie API QuantumGIS.
2. Tworzenie aplikacji z zastosowaniem biblioteki Qt.
3. Zarządzanie danymi archeologicznymi i ich przetwarzanie. 

Na tą chwilę przychodzą mi do głowy tylko te trzy punkty, ale w każdej chwili lista może ulec rozszerzeniu. Będę starał się pisać na tyle regularnie, na ile pozwolą mi na to obowiązki zawodowe i czasami przemijające twórcze natchnienie ;). W ramach wstępu w kolejnym poście opiszę krótko projek, w ramach którego narodziła się idea utworzenia rozszerzenia QAZP(2)