Klasyfikacja kulturowo-historyczna: kodowanie pojęć

W poprzednim artykule opisałem organizację wykazów do kodowania informacji o klasyfikacji kulturowo-historycznej. Dla przypomnienia: na ekranie aplikacji, albo na karcie AZP pokazywane są informacje o tym, z jakiego okresu dziejów (epoka kamienia, średniowiecze, ...), zdaniem archeologa, pochodzi badane stanowisko, jaka była jego funkcja (osada, cmentarzysko, ...), czy sposób i tradycję wykonania znalezionych przedmiotów (kultura pucharów lejkowatych, kultura łużycka, ...). Nazwy wykorzystywane do opisu są przechowywane w tabelach-wykazach: OKRESY_DZIEJOW, JEDNOSTKI, FUNKCJE. Kluczem podstawowym każdej krotki w tabeli wykazu jest ciąg alfanumeryczny kodujący informację, która jest zapisana w rekordzie. W przypadku wykazu funkcji kod ma następującą strukturę ABCCD, gdzie kolejne litery oznaczają jego segmenty. W tym przypadku obowiązkowe jest podanie tylko segmentu A, w którym określa się ogólną funkcję: np. obrzędową literą B, obronną literą O, gospodarczą G, itd. Zatem gdyby w opisie funkcji stanowiska podać kod składający się z litery G, oznaczałoby to tylko tyle, że pełniło ono w przeszłości funkcję gospodarczą. Kolejne segmenty kodu służą do zapisu bardziej szczegółowej informacji. Jeżeli kod S oznacza funkcję sepulkralną (związaną z grzebaniem zmarłych), to SL będzie oznaczało cmentarzysko ciałopalne, SL03 - cmentarzysko ciałopalne płaskie, a SL03J - cmentarzysko ciałopalne płaskie z grobami jamowymi, które to pojęcie jest przykładem najbardziej szczegółowej informacji w wykazie funkcji. Oczywiście sposób konstruowania kodu, opisany na przykładzie funkcji, został zastosowany w wykazie okresów i jednostek kulturowych. 

Jak z każdym kodowaniem informacji, z tym także wiążą się określone zyski i straty, których bilans powinien decydować o jego zastosowaniu do naszego projektu. Do oczywistych zalet oczywiście należy spójna i czytelna reprezentacja informacji w bazie danych. Zamiast w każdym rekordzie charakteryzującym funkcję stanowiska pisać cmentarzysko ciałopalne płaskie z grobami jamowymi można po prostu wstawić kod SL03J i liczyć na to, że będzie on zrozumiały dla odbiorcy. Po drugie znacząco może ułatwić wyszukiwanie informacji o stanowiskach przy pomocy operatora SQL LIKE. Listę stanowisk z funkcją gospodarczą można utworzyć stosując polecenie SELECT * FROM FAKTY WHERE FUNKCJA LIKE 'G%', które uzwględni kod G, GI, GP13 i inne, które pasują do podanego wzorca. Szybkość wykonania takiego polecenia nie jest najwyższa, ale można je zoptymalizować na przykład przez utworzenie odpowiedniego indeksu na kolumnie FUNKCJA. Stosowanie wzorców nie zawsze będzie miało pożądanych skutek, ponieważ np. polecenie SELECT * FROM FAKTY WHERE FUNKCJA LIKE '%04%' zwróci stanowiska z funkcją osada otoczona rowem/rowami (MS04) a także grób szkieletowy katakumbowy (SS04).

Stosowanie kodów wymusza też na autorach pewną ścisłość w charakteryzowaniu stanowisk. Można to postrzegać jako zaletę, gdyż podwyższa to wartość bazy jako źródła archeologicznego, a także jako wadę, gdyż procesy społeczne nie zawsze można wtłoczyć w zmatematyzowany schemat. Jeżeli wykaz można rozszerzać o nowe pojęcia, to w przypadku, gdy brakuje odpowiedniego, można je dodać do tabeli. Natomiast w przypadku, gdy uzupełnianie wykazu jest niemożliwe, to trzeba próbować wykorzystać już istniejące, co może budzić oczywisty sprzeciw wobec utraty informacji.

Klasyfikacja funkcjonalno-kulturowo-chronologiczna: wykazy

Ostatnio sporo się działo w kwestii rozwoju QAZP2. Z radością donoszę, że wtyczka ma już zaimplementowane wszystkie funkcje, których wymagał program badawczy, w ramach którego aplikacja jest realizowana. Tym samym na podstawie zawartości bazy danych można wygenerować karty AZP zgodne ze specyfikacją Ministra Kultury i Dziedzictwa Narodowego. 

Jednym z najważniejszych elementów karty AZP jest określenie dla znalezionych śladów działalności człowieka  konotacji kulturowo-historycznej, czyli innymi słowy dokonanie klasyfikacji funkcjonalno-kulturowo-chronologicznej w oparciu o zebrane fakty, czyli na przykład fragmenty ceramiki, znalezione narzędzia i inne przedmioty, które archeologowi pozwalają określić wiek badanych osad, cementarzysk, itp. Aby przekaz był uniwersalny i czytelny dla każdego naukowca w Polsce do jego formułowania posługujemy się wykazami pojęć opracowanymi w Narodowym Instytucie Dziedzictwa. Taka standaryzacja ma niebagatelne znaczenie, gdyż czyni bazę danych uniwersalnym źródłem informacji nie tylko w ramach projektu, z którego pochodzi, ale dla wszystkich zainteresowanych analizą wydarzeń, które miały miejsce w przeszłości na terenach, z których pochodzą zebrane dane. 

Opracowano trzy zbiory zawierające pojęcia służące do określania chronologii (okresu dziejów, z których pochodzi obiekt osadniczy - na przykład epoka kamienia, epoka brązu, średniowiecze, nowożytność); jednostki kulturowej, która informuje, że dany przedmiot wykazuje podobieństwo w ramach pewnej grupy wskaźników; funkcji - określenie roli obiektu - na przykład cmentarzysko, osada, grodzisko, itd. Każdy z wykazów jest zapisywany w osobnej tabeli, gdyż ich struktura jest odmienna. Konstrukcja schematu bazy danych obsługiwanego przez QAZP2 wynika z tego, że ma ona dwa podstawowe zadania: 

1. dostarczać informacje w celu ich wyświetlania,
2. dostarczać informacje w celu ich przetwarzania i analizy.

Określenia każdej z właściwości (chornologii, jednostki kulturowej i funkcji) można dokonać na kilku poziomach szczegółowości. Na przykładzie chronologii wyróżnić można takie dwa: pierwszy poziom - epoka - na przykład epoka kamienia, epoka żelaza oraz drugi poziom - okres epoki - paleolit (czyli starsza epoka kamienia), II okres epoki brązu, Halsztad C (okres epoki żelaza). Użytkownik zgodnie ze swoimi umiejętnościami, wiedzą i możliwościami określa w ten sposób chronologię dla każdego znalezionego przedmiotu używając pojęć z pierwszego poziomu (mniej szczegółowo) albo drugiego (bardziej szczegółowo). Ma to znaczenie z uwagi na analizę danych, gdyż okres wpływów rzymskich różni się od okresu halsztackiego. Natomiast w przypadku wyświetlania, zwłaszcza w formie karty KEZA, która w dobie współczesnych technologii jest już tylko wyrazem zacofania polskich służb konserwatorskich, jest mniej znaczące. Stąd w każdej tabeli wykazów znajduje się pole skrót zawierajace wartość, która potem jest umieszczana na wydruku. Z kolei w kolumnie NAZWA zapisuje się wartości, które nie są pełną nazwą okresu chronologicznego, ale wyświetlona jest zrozumiała dla archeologa. Na przykład pisząc wartość HA C domyślamy się, że chodzi o Epokę żelaza - okres halsztacki C, z kolei nazwa Grupa mątewska wskazuje na neolityczną kulturę pucharów lejkowatych i to jest trzeci poziom dokładności w określeniu jednostki kulturowej. 

Taka konstrukcja jest wygodna w analizie danych, gdyż wszukując wszystkie ślady związane z okresem Neolitu nie trzeba znać ich szczegółowego oznaczenia, czyli zbędna jest wiedza, czy osada wiąże się z kulturą pucharów lejkowatych, kulturą amform kulistych, czy grupą radziejowską, gdyż wszystkie mieszczą się w zbiorze Neolit. Z kolei szukając faktów dotyczących grupy mątewskiej nie zajmujemy się kulturą ceramiki wstęgowej, ani pozostałymi grupami kultury pucharów lejkowatych.

QGIS: struktury danych

Jednym z warunków sprawnego posługiwania się API programu QGIS jest znajomość jego specyficznych struktur danych, które właśnie chciałbym przybliżyć w tym artykule. Na jego potrzeby będę wyróżniał dwie kategorie danych: przestrzenne - współrzędne kartograficzne określające położenie obiektu przy pomocy punktów, linii, poligonów i innych oraz tekstowe - odnoszące się do dowolnych właściwości obiektu. Ten podział ma zastosowanie bez względu na to, w jakim kontenerze dane są zapisywane - pliku SHP, przestrzennej bazie danych, itp.

Każdy obiekt wyświetlany na mapie w QGIS można uzyskać odwołując się do odpowiedniej warstwy reprezentowanej klasą QgsVectorLayer. Można to zrobić na kilka sposobów - używając wewnętrznego identyfikatora, który do każdego obiektów przypisuje QGIS, iterując po obiektach i wybierając te, które spełniają nasze kryteria (jeżeli na warstwie znajduje się ich naprawdę dużo, to ta metoda może być nieefektywana), albo pobierając listę uprzednio zaznaczonych (np. przez użytkownika programu). W każdym z wymienionych przypadków każdy obiekt jest reprezentowany klasą QgsFeature. Dla każdego z nich można pobrać mapę właściwości, gdzie kluczem są liczby oznaczające kolejność przypisanej do niego właściwości. Aby uzyskać nazwy cech, trzeba w pierwszej kolejności z warstwy pobrać informację o źródle danych przy pomocy metody dataProvider(), a następnie na jej wyniku (czyli obiekcie klasy QgsVectorDataProvider) wykonać metodę fieldNameMap(). Właściwości tekstowe obiektu można modyfikować bezpośrednio - stosując metodę setAttributeMap(), która spowoduje, że stare wartości zostaną zastąpione nowymi, albo funkcją changeAttributeValue do której trzeba podać numer modyfikowanej właściwości, identyfikator obiektu (featureId) oraz nową wartość. 

Drugą ważną metodą klasy QgsFeature jest geometry(), która zwraca referencję do danych przestrzennych. Tydzień temu opisywałem jak przekształcać współrzędne przy pomocy API QGIS i wymienione tam funkcje jako parametry przyjmują wartość typu QgsGeometry. Ale to nie jedyne zastosowanie. Zasadniczo wszystkie operacje na danych przestrzennych można wykonać przy jego pomocy. Ponadto statyczne metody umożliwiają na przykład konwersję danych przestrzennych w postaci tekstowej (WKT) na binarną (WKB).

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