Baza danych przestrzennych dla potrzeb badań Muzeum Archeologicznego w Biskupinie

(1)

ROCZNIKI GEOMATYKI 2018 m TOM XVI m ZESZYT 3(82): 199–217

Baza danych przestrzennych dla potrzeb badañ

Muzeum Archeologicznego w Biskupinie

The spatial database in the research of Archaeological Museum

in Biskupin

Hubert Bujno1_{, Joanna Pluto-Kossakowska}1_{, Jaros³aw Kopiasz}2

1_{Politechnika Warszawska, Wydzia³ Geodezji i Kartografii} 2_{Muzeum Archeologiczne w Biskupinie}

S³owa kluczowe: baza danych przestrzennych, GIS historyczny, archeologia Keywords: spatial database, HGIS, archaeology

Wstêp

îród³em danych wykorzystywanych na potrzeby badañ z zakresu dziedzictwa archeolo-gicznego s¹ ró¿nego rodzaju materia³y analogowe i cyfrowe. W przypadku badañ inwazyj-nych (wykopaliskowych) do pierwszej grupy mo¿na zaliczyæ przede wszystkim dokumen-tacjê: rysunkow¹, fotograficzn¹ i opisow¹. Bardziej zaawansowane produkty uzyskuje siê dziêki technologiom umo¿liwiaj¹cym pozyskiwanie zobrazowañ satelitarnych, zdjêæ lotni-czych oraz naziemnemu i lotniczemu skanowaniu laserowemu. Osobn¹ grupê stanowi¹ mapy anomalii (geomagnetyczna, elektromagnetyczna georadarowa) uzyskanych w wyniku badañ niedestrukcyjnych.

Dane utrwalone w tradycyjnie sporz¹dzonej dokumentacji rysunkowej uzyskiwane s¹ za pomoc¹ urz¹dzeñ geodezyjnych i oprzyrz¹dowania s³u¿¹cego do pomiarów trójprzestrzen-nych (taœmy, kratownice, pantografy, niwelatory, teodolity, tachimetry, poziomice). Coraz czêœciej ró¿norakie dane uzyskane w trakcie badañ (inwazyjnych i nieinwazyjnych) wyko-rzystywane s¹ w celu: wspomagania analiz i ich graficznemu odwzorowaniu, a tak¿e prze-chowywaniu, modyfikacji, uaktualnieniu wykorzystaniu informacji przestrzennych (Zap³ata, Borowski, 2013, s.104). Potencja³ tkwi¹cy w systemach informacji przestrzennej w bada-niach dziedzictwa archeologicznego dostrze¿ono przede wszystkim w zwi¹zku z analiz¹ danych archeologicznych, która najogólniej daje mo¿liwoœæ pozyskiwania nowych informa-cji miêdzy innymi przez poszukiwanie asocjainforma-cji, klasyfikacjê lub grupowanie danych prze-strzennych (Zap³ata, Borowski, 2013, s. 104). W tym kontekœcie wykorzystanie struktur bazodanowych umo¿liwia nie tylko przechowywanie danych przestrzennych, ale przede

(2)

200 HUBERT BUJNO, JOANNA PLUTO-KOSSAKOWSKA, JAROS£AW KOPIASZ

wszystkim wykonywanie zapytañ i wielokryterialnych analiz przestrzennych czy statystyk. Na problemy zwi¹zane z zastosowaniem systemów informacji przestrzennych w archeologii zwraca uwagê £ukasz Banaszek (2010). Autor ten poddaje dyskusji problemy zwi¹zane z zastosowaniem GIS w archeologii, zarówno natury ograniczeñ technicznych, organizacyj-nych, jak i koncepcyjnych. Szczegó³owo odnosi siê do badañ prowadzonych w ramach AZP (akronim Archeologicznego Zdjêcia Polski) oraz badañ mikroregionalnych na przyk³adzie studiów osadniczych w dorzeczu œrodkowej Wieprzy (Banaszek, 2010). Szeroko pojête tech-nologie GIS s¹ stosowane w badaniach archeologicznych w Polsce od pocz¹tku XXI wieku (Mia³dun i in., 2005; Zap³ata, Borowski, 2013; Pig³as i in., 2014). We wszystkich wspomina-nych opracowaniach szeroko dyskutowane s¹ metody pozyskiwania dawspomina-nych oraz potrzeba integracji wieloŸród³owych danych przestrzennych z wykorzystaniem technologii GIS, g³ównie dla potrzeb analiz przestrzennych i wizualizacji niezbêdnych do wnioskowania miêdzy inny-mi w archeologii krajobrazu (Chapman, 2011). Na gruncie polskiej archeologii zastosowanie systemów informacji przestrzennej najczêœciej znalaz³o zastosowanie w badaniach nad osad-nictwem w skali regionalnej. Rzadziej metody analiz przestrzennych mia³y na celu uchwyce-nie relacji artefaktów i struktur osadniczych pojedynczego stanowiska osadniczego (Buch-ner, 2013, s. 787). Dobrym przyk³adem inwentaryzacji i integracji danych wieloŸród³owych dla stanowisk archeologicznych badanych nieinwazyjnie jest portal SNAP, Oddzia³ £ódŸ (http://snap.uni.lodz.pl, dostêp 20.05.2018; Sikora i in., 2015). Systemy GIS, a w tym opra-cowanie baz danych przestrzennych wci¹¿ stanowi¹ rzadkie narzêdzia, którymi pos³uguj¹ siê badacze analizuj¹cy ró¿ne aspekty osadnictwa w skali pojedynczego stanowiska (np. Miko-³ajczyk, 2007: Buchner, 2013; Bujno i in., 2017).

Zindywidualizowany charakter analizowanego stanowiska archeologicznego ka¿dorazo-wo okreœla dobór metod, narzêdzi, danych i nowych rozwi¹zañ gromadzenia, utrzymania, przetwarzania i wizualizacji informacji przestrzennych. W efekcie dobór struktury i narzêdzi badawczych u³atwiaj¹cych wieloaspektowe analizy, które przeprowadza siê w oparciu o bazy danych, czêsto wynika z charakteru stanowiska i postawionego problemu badawczego.

Motywacja, cel i zakres opracowania

Badania archeologiczne na terenie stanowiska 4 w Biskupinie rozpoczêto w 1934 roku. Ju¿ w pierwszych sezonach badañ archeolodzy odkryli znakomicie zachowane, drewniane pozosta³oœci grodu (Kostrzewski 1936, 1938). W tym czasie prace archeologiczne koncen-trowa³y siê g³ównie na pó³nocnym (rys. 1) i œrodkowym odcinku stanowiska, które ze wzglêdu na niskie po³o¿enie nad powierzchni¹ lustra jeziora, kry³y znakomicie zachowane pozosta³o-œci grodu miêdzy innymi trzy rzêdy wa³ów skrzyniowych, nak³adaj¹ce siê na siebie relikty budynków z dwóch faz, dwa, trzy poziomy ulic. Gród z wczesnej epoki ¿elaza w Biskupinie istnia³ co najmniej w dwóch fazach. W fazie starszej wnêtrze grodu rozplanowane by³o w oparciu o sieæ ulic poprzecznych, które scala³a ulica okrê¿na. Pomiêdzy ulicami poprzecz-nymi ustawione by³y rzêdy zwartej zabudowy szeregowej, któr¹ tworzy³y ujednolicone pod wzglêdem wewnêtrznego rozplanowania budynki. W fazie m³odszej sieæ szlaków komunika-cyjnych uleg³a modyfikacji. Oprócz ulic poprzecznych i drogi okrê¿nej wznoszono odcinki szlaków komunikacyjnych na obszarach niezabudowanych. Wzd³u¿ ulic poprzecznych wzno-szono w zabudowie rozproszonej, rzadziej zwartej (szeregowej) zró¿nicowane pod wzglê-dem wielkoœci i rozplanowania budynki (Kopiasz, 2017, s. 350, ryc. 127, 128).

(3)

W trakcie prowadzenia badañ wykopaliskowych w latach 1934-1939 sporz¹dzano dwu-wymiarow¹ dokumentacjê rysunkow¹ (Kopiasz, 2015, s. 63-81) i fotograficzn¹ – naziemn¹ oraz lotnicz¹, która oprócz doskona³ej jakoœci charakteryzuje siê wyj¹tkowymi walorami interpretacyjnymi (Piotrowski, 2005; Kopiasz, 2015, s. 81-85; Kopiasz i in., 2017). Wszech-stronne wykorzystanie bogatego zbioru przedwojennych fotografii i dokumentacji rysunko-wej z Biskupina by³o szczególnie zasadne w przypadku rzetelnego opracowania reliktów zabudowy tego stanowiska (Kopiasz i in., 2017, s. 186). Realizacja tego zadania wymaga³a uporz¹dkowania i integracji ró¿norodnych zbiorów danych przestrzennych w postaci rastro-wej (np. archiwalne zdjêcia, dokumentacja rysunkowa) i wektororastro-wej (m.in. CAD), pozosta-j¹cych w dyspozycji dwóch instytucji:

1) Muzeum Archeologicznego w Biskupinie (MAB) – dokumentacja rysunkowa, zwek-toryzowana dokumentacja planów, kilkadziesi¹t fotografii przedwojennych,

2) Pañstwowego Muzeum Archeologicznego w Warszawie (PMA) – zdecydowana wiêk-szoœæ przedwojennych fotografii.

Muzeum Archeologiczne w Biskupinie funkcjonuje obecnie jako muzeum-rezerwat ar-cheologiczny (wpisany do rejestru zabytków na podstawie decyzji z dnia 16.11.1995 roku, nr rejestru 147/C), ze wspó³czesnymi pe³nowymiarowymi rekonstrukcjami fragmentów grodu (otoczenie pomnika historii objêto ochron¹ konserwatorsk¹ dnia 6.02.2006 roku, nr rejestru C/148). W ramach wielostronnej aktywnoœci placówki, oprócz przechowywania i udostêp-niania odkrytego materia³u zabytkowego, kontynuowane s¹ badania naukowe z

zastosowa-Rysunek 1. Biskupin, stanowisko 4 – przyk³ad zeskanowanego zdjêcia lotniczego wykonanego

(4)

niem nowatorskich metod i po³¹czeniem wielu dyscyplin (Kuciñska-Isaac, 2018), w tym miêdzy innymi fotogrametrii i systemów informacji przestrzennej.

Celem podjêtych badañ nad opracowaniem bazy danych przestrzennych by³o wykazanie mo¿liwoœci integracji ró¿nych Ÿróde³ danych oraz opracowanie dodatkowych funkcjonalno-œci w zakresie wprowadzania i edycji danych wektorowych organizuj¹cych je w zaprojekto-wane struktury zgodnie z przyjêtymi regu³ami relacji przestrzennych i mechanizmami kon-troli. Wa¿nym aspektem badañ s¹ próby opisu w bazie danych, takich atrybutów obiektów jak niepewnoœæ i czas. Podjête dodatkowo zadanie badawcze dotycz¹ce opracowania sche-matu aplikacyjnego dla proponowanej koncepcji bazy danych ma wskazaæ na potencja³ uni-wersalnego opisu w jêzyku UML.

Metodyka opracowania bazy danych przestrzennych

Przy tak postawionych celach metodyka opracowania bazy danych przestrzennych pole-ga³a na dwóch g³ównych zadaniach:

1) opracowaniu modelu koncepcyjnego bazy danych przestrzennych jako schematu apli-kacyjnego z wykorzystaniem UML, wykonanego na podstawie analizy potrzeb pra-cowników MAB,

2) fizycznej realizacji bazy danych wraz z opracowaniem i implementacj¹ zasad kontroli oraz integracji plików rastrowych w œrodowisku QGIS, PostgreSQL i z wykorzysta-niem bibliotek SAGA.

Opracowane œrodowisko GIS wraz z baz¹ danych przestrzennych ma za zadanie przede wszystkim integrowaæ dane archiwalne (historyczne zdjêcia i zwektoryzowane plany – rys. 2, 3) oraz wytworzone wspó³czeœnie na ich podstawie modele zabudowy grodu Biskupin. Celem jest przygotowanie jednolitej struktury bazodanowej, która umo¿liwi wprowadzanie nowych danych pozyskanych z interpretacji archiwalnych zdjêæ i wektoryzowanych planów skatalogowanych i przechowywanych w zewnêtrznych strukturach. W bazie przechowy-wane s¹ metadane o zeskanowanych, zdjêciach i modelach przestrzennych zbudowanych technikami fotogrametrycznymi oraz odniesienie przestrzenne do tych materia³ów. G³ów-nym wsadem do bazy s¹ dane w formacie CAD pochodz¹ce z wczeœniejszych prac wekto-ryzacji i interpretacji historycznych szkiców i zdjêæ. Zosta³y one pozyskane w œrodowisku AutoCAD, chêtnie wykorzystywanym przez archeologów do zapisu danych wektorowych. Format ten jest przydatny w wielu dziedzinach in¿ynierskich i projektowych, ale ma takie w³asnoœci, które uniemo¿liwiaj¹ dalsz¹ pracê analityczn¹, w tym brak mo¿liwoœci zbudowa-nia relacji przestrzennych pomiêdzy obiektami. St¹d zalecanym formatem jest zapis stoso-wany w technologii GIS, który pozwala na budowê obiektów typu poligon oraz realizacjê topologii. Zwa¿ywszy na powy¿sze ró¿nice w zapisie danych, przeniesienie z formatu CAD do formatu GIS nie jest spraw¹ banaln¹ i wymaga opracowania procedur, które pozwol¹ na automatyczny i bezstratny transfer danych do bazy SQL z jednoczesnym zbudowaniem i sprawdzeniem topologii. Opracowana automatyczna procedura konwersji danych wekto-rowych z formatu dxf do shp zosta³a przedstawiona na rysunku 4 w rozdziale „Implementa-cja bazy danych”.

Nawi¹zuj¹c do modelu koncepcyjnego opartego na prostym modelu wektorowym przy projektowaniu bazy danych przyjêto nastêpuj¹ce za³o¿enia:

(5)

m podstaw¹ budynków s¹ elementy konstrukcyjne, odpowiedzialne miêdzy innymi za

przenoszenie na grunt obci¹¿eñ w³asnych i z opartych na nich innych elementów (np. dach),

m na podstawie obrazu uwzglêdniaj¹cego po³o¿enie œcian wytyczane s¹ zarysy

budyn-ków, natomiast wejœcia do budynków i pomieszczeñ pokrywaj¹ siê ze œcianami,

m nie wystêpuj¹ duplikaty obiektów,

m nie wystêpuj¹ obiekty o niepoprawnej geometrii – baza danych opiera siê na prostym

modelu wektorowym (punkt, linia, poligon),

m nie wystêpuj¹ obiekty o geometrii wieloczêœciowej.

Rysunek 2. Biskupin, stanowisko 4 – fragment zeskanowanego archiwalnego planu reliktów odkrytych

(6)

204 HUBER T BUJNO, JOANNA PLUT O-KOSSAKOWSKA, JAROS£A W KOPIASZ

Rysunek 3. Fragment zwektoryzowanego w programie AutoCAD (w formacie dwg) planu stanowiska 4 w Biskupinie;

(7)

Za³o¿eniem koncepcyjnym bazy danych przestrzennych by³o zaprojektowanie narzêdzia usprawniaj¹cego interpretacjê oraz analizê archeologiczn¹ i konstrukcyjn¹ reliktów zabudo-wy grodowej, przy jednoczesnym zabudo-wykorzystaniu najlepszych rozwi¹zañ technologicznych z zakresu baz danych przestrzennych i ich wizualizacji. Baza danych mia³a byæ prostym w u¿yciu narzêdziem z funkcjonalnoœci¹ edycji i wprowadzania nowych danych, przegl¹da-nia, wyszukiwania i wizualizacji danych przez archeologów, bez potrzeby dalszego anga¿o-wania specjalistów GIS. Zaproponowane atrybuty obiektów i ich wartoœci wynikaj¹ z anali-zy potrzeb i specyfiki prac oraz rejestrów funkcjonuj¹cych w MAB i zosta³y opisane w modelu koncepcyjnym bazy danych. Ca³oœciowy model koncepcyjny przedstawiono w schemacie aplikacyjnym UML (za³¹cznik).

Dane wejœciowe i prace przygotowawcze

Materia³y wykorzystane przy opracowaniu bazy danych pochodz¹ z Muzeum Archeolo-gicznego w Biskupinie i Pañstwowego Muzeum ArcheoloArcheolo-gicznego w Warszawie i s¹ to:

m dokumentacja fotograficzna zeskanowana z rozdzielczoœci¹ 3000 dpi z Archiwum PMA

i MAB, która ma walory dokumentacji wykopaliskowej (rys. 1),

m wykaz digitalizacyjny zdjêæ, w którym zawarte s¹ szczegó³owe informacje odnoœnie

inwentaryzacji fotografii wykonanych w okresie przedwojennym, w tym miêdzy in-nymi jego numer inwentarzowy, obszar jaki obejmuje zdjêcie z podzia³em na ary w lokalnym uk³adzie odniesienia, budowle zadokumentowane na kliszach oraz inne metadane dotycz¹ce samego zdjêcia,

m plan wektorowy stanowiska 4 w Biskupinie w formacie dwg przygotowany w

pro-gramie AutoCAD (rys. 3) na podstawie zeskanowanych planów stanowiska w skali 1:10 i 1:100 (rys. 2),

m produkty fotogrametryczne opracowane w czasie trwania projektu, to jest

ortofoto-mapy wykonane na podstawie przedwojennych zdjêæ lotniczych, numeryczny model pokrycia terenu wygenerowany dla ca³ego terenu wykopalisk na podstawie zdjêæ ze œredniego pu³apu, modele fotogrametryczne 3D przygotowane na podstawie zdjêæ archiwalnych i planu wektorowego.

Baza danych zosta³a opracowana w lokalnym uk³adzie wspó³rzêdnych, w którym zosta³a wytyczona w 1935 roku siatka arowa (rys. 3), obejmuj¹ca ca³y pó³wysep i jego nasadê (Kopiasz, 2015). Klasy obiektów, które uwzglêdniono w bazie danych, s¹ œciœle zwi¹zane ze specyfik¹ osadnictwa z wczesnej epoki ¿elaza na stanowisku 4 w Biskupinie i zosta³y opisane w dalszej czêœci artyku³u. Istotn¹ kwesti¹, któr¹ nale¿a³o uwzglêdniæ w trakcie budowy bazy danych by³a kontrola poprawnoœci obiektów wprowadzonych do bazy. Zaproponowano sto-sowne regu³y topologiczne oraz mechanizmy kontroluj¹ce wprowadzane dane atrybutowe w postaci ograniczeñ oraz wyzwalaczy. Baza ma modelowaæ niepewnoœæ przestrzenn¹ obiek-tów oraz ograniczon¹ mo¿liwoœæ tworzenia regu³ topologicznych. Niepewnoœæ jest zwi¹za-na z geometri¹ interpretowanych obiektów, któr¹ nie zawsze mo¿zwi¹za-na jednozzwi¹za-nacznie wyzzwi¹za-na- wyzna-czyæ. Wynikaæ to mo¿e miêdzy innymi: (1) z braku elementu konstrukcyjnego (np. ³¹tki, sumika), którego nie odkryto w trakcie eksploracji, albo zachowa³ siê on szcz¹tkowo, unie-mo¿liwiaj¹c jednoznaczn¹ interpretacjê, lub z rozbie¿noœci pomiêdzy dokumentacj¹ rysun-kow¹ i fotograficzn¹, co wyra¿a siê brakiem niektórych obiektów, (2) z niepewnoœci przy okreœlaniu rodzaju, fazy/etapu powstania czy cech obiektów.

(8)

Model koncepcyjny bazy danych przestrzennych

Model koncepcyjny bazy danych przestrzennych obejmuje szczegó³owe omówienie sa-mych klas obiektów oraz relacji topologicznych pomiêdzy klasami, które nale¿a³o zdefinio-waæ w celu sprawdzenia poprawnoœci wprowadzanych danych. W sumie zaprojektowano 13 klas obiektów, przy czym klasa budynek jest klas¹ g³ówn¹ z najwiêksz¹ liczb¹ relacji do innych klas (6). Drug¹ istotn¹ klas¹ jest zdjêcie, która agreguje dane z kilku Ÿróde³. W dal-szym opisie klas przedstawiono najistotniejsze elementy charakteryzuj¹ce dan¹ klasê, w tym tak¿e zastosowane mechanizmy kontrolne oraz relacje miêdzy klasami (tab. 2).

Klasa „budynek” [budynek]

Podstawow¹ klas¹ obiektów w bazie danych jest „budynek”. Agreguje ona dane z dwóch Ÿróde³: (1) wykazu digitalizacyjnego zdjêæ oraz (2) samego zeskanowanego zdjêcia wraz ze œrodkami rzutów uzyskanymi w procesie aerotriangulacji. Ma ona najwiêksz¹ liczbê atrybu-tów i jest w relacji z wiêkszoœci¹ pozosta³ych klas, co pokazuje schemat UML (za³¹cznik). Ka¿dy budynek wprowadzony do bazy ma nowy, unikalny kod to jest numer budynku miesz-kalnego wed³ug nowej nomenklatury [nr_new_nom], który zawiera: numer rzêdu (na szki-cu), miejsce wystêpowania w danym rzêdzie i fazê/okres. Przyk³adowy kod 0100201 ozna-cza budynek w pierwszym rzêdzie zabudowy, drugi od lewej (zachodu), który pochodzi z fazy starszej (patrz s³owniki w schemacie UML). Drugi wa¿ny atrybut to numer budynku mieszkalnego wed³ug starej nomenklatury [nr_mies_sn], którego kod odnosi siê do wcze-œniej stosowanego zapisu (funkcjonuj¹cy w wykazie digitalizacyjnym zdjêæ w formacie xls). Na podstawie tego jest budowana relacja „wiele do wielu” miêdzy konkretnym zdjêciem i budynkami, które siê na nim znajduj¹. Kolejny atrybut okreœla etap powstania obiektu [faza_etap]. Jest to bardzo istotny atrybut, a ze wzglêdu na trudnoœæ w jego oznaczeniu przygotowano osiem zdefiniowanych wartoœci: starszy, starszy_prawdop, mlodszy, mlod-szy_prawdop, nieokreslony, etap_fazy_starszej, etap_fazy_mlodszej. Ciekawym atrybutem jest liczba pomieszczeñ [licz_pomie]. Poniewa¿ w budynku mo¿e byæ liczba pomieszczeñ niemo¿liwa do oszacowania na przyk³ad 2 lub 3, zdecydowano o tekstowym typie tego atrybutu. Dodatkowo zastosowano „trigger” ograniczaj¹cy, który uaktywnia siê przy niepo-prawnym wprowadzeniu danych.

Klasa „œciana” [sciana]

Wa¿ny atrybut tej klasy to kierunek [kierunek] typu tekstowego o zmiennej d³ugoœci, przyjmuj¹cy wartoœci: „wschodnia”, „zachodnia”, „pó³nocna”, „po³udniowa” i „szczytowa” – co oznacza, ¿e jest ona wspólna dla dwóch budynków szeregowych. Z racji, ¿e mo¿e pojawiæ siê tylko piêæ wartoœci zosta³ ustawiony wyzwalacz ograniczaj¹cy. Drugi wa¿ny atrybut to rodzaj konstrukcji [rodz_konst] przyjmuj¹cy wartoœæ: „dzia³owa” lub „konstruk-cyjna” oraz atrybut [pion_desk] typu BOOLEAN, który okreœla czy œciana jest zbudowana z pionowych desek.

(9)

Klasa „element konstrukcyjny” [elem_kons]

Jest to podstawowy element konstrukcyjny dla obiektów budowlanych zawartych w bazie danych. Na elementach konstrukcyjnych budowane s¹ œciany, na których w dalszej kolejnoœci tworzone s¹ pomieszczenia i budynki i te relacje konstrukcyjne równie¿ zapisano w bazie danych. Klasê opisuj¹ dwa istotne atrybuty rodzaj i kszta³t, oba typu VARCHAR. Rodzaj [rodzaj] przyjmuje wartoœci: „latka, socha_wewnetrzna, latka&socha, latka_zastep-cza”, a kszta³t [kszta³t] przyjmuje wartoœci: „owal, prostokat”.

Klasa „palenisko” [palenisko]

Warstwa punktowa po³¹czona z warstw¹ budynek relacj¹ asocjacji. Relacja ta jest bardzo istotna, czego konsekwencj¹ jest dodanie atrybutu numer budynku [nr_bud] typu INTEGER. Pole to jest uzupe³niane automatycznie dziêki zapytaniu przestrzennemu, które sprawdza czy palenisko zawiera siê w jakimœ budynku, jeœli tak to podaje jego identyfikator. U¿yto zapyta-nia przestrzennego, wiêc konsekwentnie zbudowano dodatkowo wyzwalacz po stronie bu-dynku i paleniska, który uaktywnia siê po ka¿dym INSERT i UPDATE.

Klasa „pomieszczenie” [pomieszcz]

Klasa obiektów typu Polygon, po³¹czona relacj¹ agregacji s³abej z budynkiem oraz œcian¹. Z klas¹ „wejœcie” jest po³¹czona zwi¹zkiem asocjacji, gdzie „wejœcie” mo¿e znajdowaæ siê w granicach pomieszczenia. Atrybut rodzaj [rodzaj] typu tekstowego z ograniczeniem, które kontroluje wprowadzane wartoœci: „izba”, „przedsionek”, „komora”, „pom_gospodarcze”.

Klasa „wejœcie” [wejscie]

Klasa obiektów typu MultiLineString po³¹czona relacj¹ asocjacji z pomieszczeniem i bu-dynkiem. Atrybut rodzaj [rodzaj] typu tekstowego, dla którego dodatkowo opracowano wyzwalacz oparty na zapytaniach przestrzennych sprawdzaj¹cych czy wejœcie jest wewnêtrzne czy zewnêtrzne.

Klasa „szlak komunikacyjny” [szl_komun]

Jest to budowla z³o¿ona z platformy osadzonej na pod³u¿nych legarach wznoszona na powierzchni gruntu lub reliktach wczeœniej istniej¹cych budowli. Atrybut numer szlaku [nr_szlaku] typu INTEGER pojawi³ siê, poniewa¿ nie zawsze jest mo¿liwoœæ jednoznaczne-go okreœlania ulicy jednym polijednoznaczne-gonem. Atrybut rodzaj [rodzaj] typu tekstowejednoznaczne-go z list¹ wy-liczeniow¹ z wartoœciami: „okrê¿na, ³¹cznik, poprzeczna oraz pomost”.

Wszystkie klasy obiektów otrzyma³y tak¿e atrybuty nadawane w sposób automatyczny to jest unikalny identyfikator oraz zwi¹zane z geometri¹ obiektu na przyk³ad powierzchnia, obwód, d³ugoœæ oraz atrybuty porz¹dkuj¹ce, takie jak: ostatni u¿ytkownik modyfikuj¹cy krotkê, data ostatniej modyfikacji, utworzenia rekordu. S¹ te¿ atrybuty wspólne dla obiektów wynikaj¹ce z interpretacji zdjêæ i szkiców jak faza/etap o mo¿liwej wartoœci: „starszy, star-szy_prawdop, mlodszy, mlodstar-szy_prawdop, nieokreslony, etap_fazy_starszej, etap_fazy_mlod-szej” czy niepewnoœæ atrybut typu BOOLEAN, przyjmuj¹cy wartoœæ FALSE, gdy nie jeste-œmy pewni geometrii opracowywanego obiektu lub TRUE. Tabele s³ownikowe zaprojekto-wane w bazie danych zawarto w za³¹czniku – Schemat aplikacyjny UML.

(10)

208 HUBERT BUJNO, JOANNA PLUTO-KOSSAKOWSKA, JAROS£AW KOPIASZ Relacje miêdzy klasami

Istotn¹ kwesti¹ do rozwi¹zania by³o po³¹czenie klas obiektów z ich wystêpowaniem na zdjêciach archiwalnych (klasa zdjêcie) po³¹czonych relacj¹ wiele do wielu. Wymaga³o to opracowania i utworzenia dodatkowej tabeli relacyjnej. Ten etap jest bardzo istotny, a efekt jego funkcjonalnoœci wa¿ny z punktu widzenia u¿ytkowania bazy danych.

Obiekt jest to klasa abstrakcyjna oraz bazowa, z której atrybuty, ograniczenia oraz relacje przejmuj¹ klasy pochodne (Parzyñski, Chojka, 2013). Klasami pochodnymi s¹ wszystkie klasy ze stereotypem Feature Type, wy³¹czaj¹c zdjêcie oraz budynek. Najwa¿niejsz¹ klas¹ znajduj¹c¹ siê w centralnej czêœci schematu jest budynek, co bardzo dobrze odwzorowuje diagram klas. Uwagê zwraca równie¿ klasa zdjêcie, która, przy rozbudowie bazy danych bêdzie wchodziæ w relacje asocjacji z ka¿d¹ klas¹ typu Feature Type. W modelu zastosowa-no trzy relacje: dziedziczenie, asocjacja i agregacja (tabela 1).

Tabela 1. Relacje miêdzy klasami obiektów uwzglêdnione w modelu bazy danych

(Ÿród³o: opracowanie w³asne) y s a l k a w z a N Nazwa y s a l k a j c a l e R Opisrelacji o k s i n e l a p budynek asocjacja wbudynkumo¿eznajdowaæ siêjednopalenisko a n a i c s budynek agregacja trzylubwiêcejœciantworz¹budynek e i c s j e w budynek asocjacja wgranicybudynkuznajdujesiêwejœcie z c z s e i m o p budynek agregacja jednob¹dŸ wielepomieszczeñstanowiczêœæ sk³adow¹ u k n y d u b e i c e j d z budynek asocjacja najednymzdjêciumo¿eznajdowaæ siêkilkabudynków h c a i c ê j d z u k l i k a n ê i s æ a w o d j a n z e ¿ o m k e n y d u b n e d e j z a r o k e n y d u b rzad agregacja jedenb¹dŸ wielebudynkówznajdujêsiêwewn¹trz u d ê z r o g e n t e r k n o k t s n o k _ m e l e sciana agregacja obrazœcianyjestrekonstruowanynapodstawiedwóchb¹dŸ h c y n j y c k u r t s n o k w ó t n e m e l e j e c ê i w o k s i n e l a p obiekt dziedziczenie a n a i c s obiekt dziedziczenie e i c s j e w obiekt dziedziczenie z c z s e i m o p obiekt dziedziczenie n u m o k _ l z s obiekt dziedziczenie t s n o k _ m e l e obiekt dziedziczenie l a w d o p _ l e obiekt dziedziczenie l a w obiekt dziedziczenie n o r h c o l a f obiekt dziedziczenie

Implementacja bazy danych

Fizyczna realizacja bazy danych i jej implementacja w œrodowisku GIS zosta³a zrealizo-wana w oprogramowaniu otwartym to jest: QGIS, PostgreSQL i bibliotek SAGA. Sposób realizacji fizycznego modelu bazy danych obejmuje procesy zaczynaj¹ce siê od

(11)

przygotowa-nia danych w programie obs³uguj¹cym dane wektorowe (tu AutoCAD 2014), przez: import danych, kontrole poprawnoœci geometrycznej obiektów w programie QGIS, utworzenie struk-tury bazodanowej, a¿ do uzupe³nienia danych tabelarycznych. Etapy przetwarzania danych i ich implementacji do opracowanej struktury bazodanowej wymagaj¹ uwzglêdnienia wielu operacji i narzêdzi programistycznych, jak przyk³adowo przedstawiono na schemacie czêœæ dotycz¹c¹ konwersji danych (rys. 4).

Rysunek 4. Schemat konwersji danych wektorowych z formatu dxf do shp (Ÿród³o: Bujno, 2017)

Kontrola danych przy u¿yciu topologii

Na podstawie za³o¿eñ dotycz¹cych kontroli danych opisanych w metodyce zosta³y okre-œlone regu³y do kontroli geometrii obiektów zastosowane dla poszczególnych klas (tabela 2). Kontrole zosta³y wykonane przy u¿yciu narzêdzia o nazwie „Kontrola topologii” dostêpnego w aplikacji QGIS.

Regu³y kontroli zosta³y opracowane w celu ujednolicenia wprowadzanych danych i mini-malizacji b³êdów. Niemniej jednak struktura bazy danych nie jest zamkniêta i umo¿liwia wpro-wadzenie nowych klas obiektów, ich atrybutów i mechanizmów kontrolnych w procesie uzupe³niania i aktualizacji bazy w razie zmiany pogl¹dów lub nowych odkryæ.

(12)

Integracja plików rastrowych

Aby ostatecznie skonfigurowaæ w³aœciw¹ funkcjonalnoœæ opracowanej bazy danych na-le¿y przeprowadziæ prace dope³niaj¹ce ca³¹ implementacjê modelu bazy danych. Klasy takie jak „zdjecia” i „model3D” maj¹ dodatkow¹ kolumnê, która zawiera link do lokalizacji zdjêcia/ modelu przechowywanych w oddzielnych strukturach dyskowych. Dziêki takiemu podej-œciu jest mo¿liwe zdefiniowanie tak zwanych „akcji”, które pozwalaj¹ u¿ytkownikowi z po-ziomu aplikacji:

m dla ka¿dego obiektu z klasy „model3D” otworzyæ odpowiadaj¹cy mu model 3D

w oprogramowaniu SketchUp – s³u¿¹cym miêdzy innymi do przegl¹dania i edytowa-nia wygenerowanych w oparciu o technologie fotogrametryczne modeli 3D (rys. 5),

m dla klasy „zdjêcie” dla wybranego punktu zobaczyæ szybki podgl¹d w oknie QGIS lub

otworzyæ zdjêcie z oryginaln¹ rozdzielczoœci¹ w oprogramowaniu do przegl¹dania plików rastrowych.

Dodatkowo dziêki gotowym bibliotekom, miêdzy innymi GDAL mo¿na wyœwietliæ, ana-lizowaæ i wykonywaæ ró¿norodne analizy przestrzenne na danych rastrowych, miêdzy inny-mi na ortofotomapie lub numerycznym modelu terenu.

Tabela 2. Zastosowane regu³y do kontroli geometrii przy u¿yciu narzêdzia Kontrola topologii

(Ÿród³o: opracowanie w³asne) 1 a w t s r a W Regu³a Warstwa2 r t s n o k _ l e niemo¿emieæ duplikatów brak o k s i n e l a p niemo¿ezawieraæ niepoprawnychgeometrii brak h c y w o i c œ ê z c o l e i w i i r t e m o e g æ e i m e ¿ o m e i n brak w ó t a k i l p u d æ e i m e ¿ o m e i n brak e i c s j e w niemo¿emieæ geometriiwieloczêœciowych brak i i r t e m o e g h c y n w a r p o p e i n æ a r e i w a z e ¿ o m e i n brak w ó t a k i l p u d æ e i m e ¿ o m e i n brak a n a i c s niemo¿emieæ geometriiwieloczêœciowych brak i i r t e m o e g h c y n w a r p o p e i n æ a r e i w a z e ¿ o m e i n brak z æ a w y r k o p ê i s ¹ z s u m i i n i l e c ñ o k el_konstr w ó t a k i l p u d æ e i m e ¿ o m e i n brak k e n y d u b niemo¿emieæ geometriiwieloczêœciowych brak i i r t e m o e g h c y n w a r p o p e i n æ a r e i w a z e ¿ o m e i n Brak z æ a w y r k o p ê i s ¹ z s u m i i n i l e c ñ o k el_konstr w ó t a k i l p u d æ e i m e ¿ o m e i n brak l a w d o p _ l e niemo¿emieæ geometriiwieloczêœciowych brak i i r t e m o e g h c y n w a r p o p e i n æ a r e i w a z e ¿ o m e i n brak n i l e z c z s æ e i m e ¿ o m e i n brak w ó t a k i l p u d æ e i m e ¿ o m e i n brak

(13)

Wnioski

Przy opracowywaniu baz danych przestrzennych istotnym czynnikiem s¹ dane Ÿród³o-we, ich format zapisu i struktury przechowywania. Jednym z g³ównych problemów jest nie tyle wymiana danych miêdzy systemami CAD i GIS, ale sposób modelowania obiektów. Wiêkszoœæ narzêdzi CAD do projektowania to wyrafinowane œrodowiska graficzne z za-awansowanymi narzêdziami do tworzenia dok³adnej geometrii, jej edycji i wymiarowania. Jednak nie potrafi¹ one w prosty sposób ³¹czyæ z grafik¹ dodatkowych danych opisowych i przechowywaæ ich w zewnêtrznych tabelach. Obiekty graficzne nie maj¹ atrybutów w rozumieniu danych wektorowych „bazodanowym”, a jedynie adnotacje tekstowe. Z kolei systemy GIS zapewniaj¹ ³¹czenie prostej grafiki w relacje topologiczne oraz z tabelami prze-chowuj¹cymi dodatkowy opis obiektów. Istnieje mo¿liwoœæ konwersji danych CAD do sys-temów GIS, lecz utrudnieniem jest ¿mudny proces nadawania odniesienia przestrzennego danym wektorowym (uk³ad wspó³rzêdnych geograficznych) oraz tworzenie tabeli atrybu-tów na podstawie opisów i etykiet z projektu CAD.

Drugim bardzo istotnym aspektem, na który warto zwróciæ uwagê, jest specyfika da-nych archeologiczda-nych oraz niepewnoœæ z nimi zwi¹zana, która w du¿ym stopniu uniemo¿-liwia wykorzystanie znacznie wiêkszych mo¿liwoœci jakimi dysponuje PostGIS, na przyk³ad wykorzystanie topologii b¹dŸ prostych regu³ przestrzennych. Warto podkreœliæ, ¿e choæ odpowiednio i starannie przygotowane dane w œrodowisku CAD s¹ bardzo wartoœciowym

Rysunek 5. Akcja otwieraj¹ca model budynku

oraz zdjêcie lotnicze w SketchUp (Ÿród³o:Bujno i in., 2017)

(14)

Ÿród³em danych, to do dalszych prac wektoryzacji i wprowadzania kolejnych danych zaleca siê wykorzystanie œrodowiska typowo GIS-owego. Zaprojektowane elementy zarz¹dzania baz¹ danych bêd¹ dbaæ o to, aby wprowadzane dane by³y poprawne. PostgreSQL z rozsze-rzeniem PostGIS daje du¿e mo¿liwoœci kontroli wprowadzanych danych, co zosta³o pokaza-ne na wielu przyk³adach, miêdzy innymi przy u¿yciu procedur wyzwalanych. Bardzo du¿¹ zalet¹ jest mo¿liwoœæ nadawania praw u¿ytkownikom do zarz¹dzania danymi, ich edycji, aktualizacji, wersjonowania i ostatecznie do publikowania. PostgreSQL w po³¹czeniu z Geo-Server, QGIS i Leaflat umo¿liwiaj¹ tworzenie aplikacji WebGIS i udostêpnienia danych opra-cowanych dla stanowiska 4 w Biskupinie szerokiemu odbiorcy. Zaprojektowane modu³y bazy danych przestrzennych umo¿liwiaj¹ wizualizacje obiektów opracowanych na etapie rekonstrukcji reliktów zabudowy grodowej, dodawanie nowych obiektów w przysz³oœci oraz rozbudowê bazy o nowe funkcjonalnoœci.

Podsumowanie

Technologia GIS jest zalecanym narzêdziem do gromadzenia, usystematyzowania i anali-zy danych przestrzennych. Zaproponowana w wyniku badañ koncepcja znacznie zwiêksza wydajnoœæ pracy: umo¿liwia przegl¹danie zdjêæ, obiektów 3D z poziomu aplikacji, selekcjê zdjêæ wed³ug wybranych atrybutów oraz umo¿liwia pracê w jednym, spójnym œrodowisku. W projekcie bazy danych uwzglêdniono 15 klas obiektów, 20 bezpoœrednich relacji miêdzy nimi, 23 funkcje kontroluj¹ce dane przy u¿yciu topologii oraz procedury wyzwalaj¹ce opra-cowane dla ka¿dej warstwy, w znacznym stopniu podnosz¹ funkcjonalnoœæ bazy danych przestrzennych. Zaprojektowana z wykorzystaniem UML i zaimplementowana w systemie zarz¹dzania relacyjno-obiektowa baza danych PostgreSQL z rozszerzeniem PostGIS zreali-zowa³a za³o¿enia dotycz¹ce bazy danych przestrzennych i ma wszelkie funkcjonalnoœci i postulaty wymagane na obecnym etapie opracowywania i badania osadnictwa z wczesnej epoki ¿elaza na stanowisku 4 w Biskupinie. Opracowany schemat aplikacyjny UML mo¿na traktowaæ jako punkt wyjœcia do budowy baz danych przestrzennych o podobnym charakterze. Podziêkowania. Autorzy artyku³u dziêkuj¹ panu Magistrowi Jaros³awowi Kopiaszowi za zaproszenie do realizacji projektu „Opracowanie zabudowy grodu kultury ³u¿yckiej na stanowi-sku 4 w Bistanowi-skupinie. Badania przedwojenne”, udostêpnienie danych i pomoc przy opracowaniu za³o¿eñ bazy danych. Autorzy sk³adaj¹ podziêkowania dwóm anonimowym Recenzentom, w szczególnoœci drugiemu Recenzentowi, za wszelkie sugestie zamieszczone w tekœcie oraz za wnikliwe i rzeczowe uwagi, które pomog³y w dopracowaniu i edycji artyku³u.

Finansowanie. Baza danych zosta³a zaprojektowana i zrealizowana w ramach projektu „Opracowanie zabudowy grodu kultury ³u¿yckiej na stanowisku 4 w Biskupinie. Badania przedwojenne” finansowanego w latach 2016-2017 ze œrodków Ministra Kultury i Dziedzic-twa Narodowego.

(15)

Literatura (References)

Banaszek £ukasz, 2010: Problemy zwi¹zane z zastosowaniem GIS w archeologii na przyk³adzie badañ prowadzonych w dorzeczu œrodkowej Wieprzy (Issues related to the use of GIS in archaeology using the example of research works in the central Wieprz River basin) Praca dyplomowa, Politechnika Wroc³aw-ska.

Buchner Aneta, 2013: Zastosowanie Systemów Informacji Geograficznej w badaniu struktury przestrzennej osady kultury ³u¿yckiej na stanowisku Stary Œleszów 17, pow. Wroc³awski (The use of GIS systems for investigations of the spatial structure of the Lusatian culture settlement on the Stary Œleszów station). [W:] Kolenda J., Mierzwiñski A., MoŸdzioch S., ¯ygad³o L. (red.), Z badañ nad kultur¹ spo³eczeñstw pradziejowych i wczesnoœredniowiecznych. Ksiêga pami¹tkowa dedykowana Profesorowi, Bogus³awo-wi Gedidze w osiemdziesi¹t¹ rocznicê urodzin, przez przyjació³, kolegów i uczniów: 787-794, Warszawa. Bujno Hubert 2017: Opracowanie bazy danych przestrzennych dla Muzeum Archeologicznego w Biskupinie (Development of a spatial database for the Archaeological Museum in Biskupin). Praca dyplomowa, Politechnika Warszawska.

Bujno Hubert, Pluto-Kossakowska Joanna, Kopiasz Jaros³aw, 2017: Baza danych przestrzennych GIS w badaniach struktur zabudowy grodowej na stanowisku 4 w Biskupinie ( Using the GIS spatial database for studying the structures of the forty field settlement AT site 4 in Biskupin). [W:] Kopisz J., D¹browski H. P., Grossman A., Piotrowski W. (red), V Sprawozdanie Biskupiñskie: 117-130, Biskupin.

Chapman Henry, 2011: Landscape Archaeology and GIS. The History Press, Brimscombe Port, Stroud. Grody wczesnoœredniowieczne w Polsce Centralnej (Early medieval strongholds in Central Poland). Portal

Stowarzyszenia Naukowego Archeologów Polskich. Dostêp 03.2018 r. http://snap.uni.lodz.pl/grody/ Kopiasz Jaros³aw, 2015: Dokumentacja archiwalna osady z wczesnej epoki ¿elaza na stanowisku 4 w

Biskupinie i jej cyfrowa integracja (Archive documentation of the settlement from the Erly Iron Age on site 4 in Biskupin and its digital integration). [W:] Nowaczyk S., Grossman A., Piotrowski W. (red.), IV Sprawozdanie Biskupiñskie: 53-102, Biskupin.

Kopiasz Jaros³aw, 2017: Relikty zabudowy osiedla obronnego w Biskupinie w œwietle interpretacji przed-wojennej dokumentacji rysunkowej i fotograficznej oraz produktów fotogrametrycznych (The remains of the Biskupin fortified settlement in the light of interpretation of the pre-war drawing and photographic documentation). [W:] Kopisz J., D¹browski H.P., Grossman A., Piotrowski W. (red), V Sprawozdanie Biskupiñskie: 185-353, Biskupin.

Kopiasz Jaros³aw, Drzewicz Anna, Grochulska Anna, Piotrowska Krystyna, 2017: Archiwalna dokumenta-cja fotograficzna i jej znaczenie w badaniach struktur zabudowy grodu z wczesnej epoki ¿elaza na stanowisku 4 w Biskupinie (Archival photographic documentation and its significance in the research on structures of buildings of the fortified settlement from the Early Iron Age on site 4 in Biskupin). [W:] Kopisz J., D¹browski H.P., Grossman A., Piotrowski W. (red), V Sprawozdanie Biskupiñskie: 17-46, Biskupin.

Kostrzewski Józef, 1936: Osada bagienna w Biskupinie, w powiecie ¿niñskim (The swamp settlement in Biskupin, ¯nin district). [W:] Kostrzewski J., Lubicz-Niezabitowski E., Jaroñ B., Osada bagienna w Biskupinie, w powiecie ¿niñski. Tymczasowe Sprawozdanie z prac wykopaliskowych Instytutu Prehi-storycznego UP. w latach 1934-1935: 1-20, Poznañ.

Kostrzewski Józef, 1938: Kilka uwag uzupe³niaj¹cych o budowlach mieszkalnych i obronnych kultury ³u¿yckiej w Biskupinie. [W:] Kostrzewski J. (red.), Gród pras³owiañski w Biskupinie, w powiecie ¿niñ-skim. Sprawozdanie z badañ w latach 1937 i 1938 z uwzglêdnieniem wyników z lat 1934-1935 (Some complementing remarks on housing and defense constructions of the Lusatian culture at Biskupin. [In:] Kostrzewski J. (edit.), The Old Slavic Settlement at Biskupin, in the Znin district. Report on investiga-tions in 1937 and 1938 with consideration of results of 1934 and 1935): 15-24, Poznañ.

Kuciñska-Isaac Anna, n.d.: Biskupin – rezerwat Archeologiczny (Biskupin – the Archaeological Reservation). Dostêp: 03.2018 r. https://zabytek.pl/public/upload/objects_media/5679b5cdaf28f.pdf

Mia³dun Jerzy, Mirkowska Izabela, R¹czkowski W³odzimierz, 2005: Wczesnoœredniowieczne za³o¿enia obronne w Polsce pó³nocno-wschodniej: projekt systemu informacji archeologicznej (Early medieval fortified sites in north-eastern Poland – a proposal for an archaeological information system). [W:] Nowa-kowski J., Prinke A., R¹czNowa-kowski W. (red.), Biskupin… i co dalej? Zdjêcia lotnicze w polskiej archeologii (Biskupin... and what next? Aerial photographs In Polish archaeology): 193-204, Poznañ.

(16)

Miko³ajczyk Anna, 2007: Analiza skupieñ kultury hamburskiej ze stanowiska Siedlnica 17, pow. Wschowa w oparciu o Systemy Informacji Przestrzennej (Analysis of clusters of the Hamburg Culture from the Siedlnica 17 station, Wschowa district, basing on Spatial Information Systems). Œl¹skie Sprawozdania Archeologiczne 49: 15-26. Wroc³aw, Instytut Archeologii, Uniwersytet Wroc³awski.

Parzyñski Zenon, Chojka Agnieszka 2013: Infrastruktura informacji przestrzennej w UML (The spatial information infrastructure in the UML). Warszawa, Wyd. Geodeta.

Pig³as Mi³osz, R¹czkowski W³odzimierz, ¯uk Lidia, 2014: Przestrzenna baza danych – w hermeneutycznej spirali interpretacji (The spatial information infrastructure in the UML). Archeologicky vyzkum krajiny a aplikace ICT, Opava.

Piotrowski Wojciech, 2005: Wykopaliska biskupiñskie z lotu ptaka – próba podsumowania (Biskupin exca-vations from the bird’s eye view – an attempt to sum up the problem). [W:] Nowakowski J., Prinke A., R¹czkowski W. (red.), Biskupin… i co dalej? Zdjêcia lotnicze w polskiej archeologii (Biskupin... and what next? Aerial photographs In Polish archaeology): 27-50, Poznañ.

Portal SNAP, Stowarzyszenie Naukowe Archeologów Polskich Oddzia³ w £odzi, Dostêp 20.05.2018 r. http:/ /snap.uni.lodz.pl

Sikora Jerzy, Kittel Piotr, Wroniecki Piotr, 2015: Nieinwazyjne badania grodzisk wczesnoœredniowiecznych Polski Centralnej i ich zaplecza osadniczego: Che³mo, Rêkoraj, Rozprza, Stare Skoszewy, Szyd³ów (Non-invasive research of the early-medieval strongholds in Central Poland and their settlement hinterland: Che³mo, Rêkoraj, Rozprza, Stare Skoszewy, Szyd³ów). Prace i Materia³y Muzeum Archeologicznego i Etnograficznego w £odzi. Seria Archeologiczna 46: 257-300.

Zap³ata Rafa³, Borowski Marcin, 2013: GIS w archeologii – przyk³ad prospekcji i inwentaryzacji dziedzic-twa archeologiczno-przemys³owego (GIS in archaeology – an example of prospection and documentation of archaeological and industrial heritage). Roczniki Geomatyki 11 (4): 103-112, Warszawa, PTIP.

Streszczenie

Celem artyku³u jest zaprezentowanie modelu bazy danych przestrzennych wraz z przygotowaniem œrodowiska GIS zorientowanego na dane Ÿród³owe ró¿nego pochodzenia i formatu (dane wektorowe, rastrowe, modele 3D). Badania objê³y opracowanie, testowanie i wskazanie rozwi¹zañ technologicz-nych GIS w zakresie budowy i funkcjonalnoœci bazy datechnologicz-nych dla potrzeb badañ archeologicztechnologicz-nych prowadzonych przez Muzeum Archeologiczne w Biskupinie (MAB). Prace podjête nad opracowaniem bazy danych s¹ wynikiem zadañ w projekcie realizowanym w latach 2016-2017 przez MAB pt: „Opracowanie zabudowy grodu kultury ³u¿yckiej na stanowisku 4 w Biskupinie. Badania przedwo-jenne”.

W artykule opisano etapy tworzenia modelu konceptualnego i logicznego oraz jego fizyczn¹ imple-mentacjê. Przedstawiono kolejne fazy projektowania, w tym istotny etap importu danych Ÿród³owych typu CAD opracowanych przez archeologów do oprogramowania GIS, sk³adaj¹cy siê z odpowiednie-go przyodpowiednie-gotowania warstw, transferu i przekszta³ceñ danych oraz kontroli za pomoc¹ narzêdzi wyko-rzystuj¹cych mechanizmy topologiczne. Zosta³y szczegó³owo omówione zaprojektowane klasy obiek-tów, relacje wystêpuj¹ce miêdzy nimi, ograniczenia i procedury wyzwalane za³o¿one w bazie danych. Zaprezentowano równie¿ dodatkowe rozwi¹zanie technologiczne w oprogramowaniu QGIS umo¿li-wiaj¹ce wyœwietlanie modeli fotogrametrycznych i archiwalnych zdjêæ lotniczych. Na podstawie zreali-zowanych prac zosta³y sformu³owane wnioski dotycz¹ce danych Ÿród³owych, problemów wynikaj¹-cych ze specyfiki danych archeologicznych, przydatnoœci oprogramowania „open source” oraz wybra-nego podejœcia do zarz¹dzania danymi przestrzennymi dla potrzeb badañ archeologicznych zabudowy grodu kultury ³u¿yckiej prowadzonych na stanowisku 4 Muzeum Archeologicznego w Biskupinie.

Abstract

The aim of this paper is to present the spatial database model within the GIS environment oriented to source data of different origins and formats (vector, raster data, 3D models). Further research has included testing and indication of GIS technological solutions in the field of the database structure and

(17)

functionality for the needs of archaeological research conducted by the Archaeological Museum in Biskupin (MAB). Works undertaken on the development of the database result from tasks performed in the project: „Development of the fortified settlement of Lusatian culture in Biskupin. Pre-war study” conducted by the MAB in 2016-2017.

The paper describes the stages of creating a conceptual and logical model and its technical implemen-tation. Next, the phases of database design were presented, including an important stage of CAD data import to GIS software, consisting of appropriate preparation of layers, transformation of data, and control with the use of topological mechanisms. The designed classes of objects, the relations between them, constraints and triggers established in the database have been discussed in details.

An additional technological solution in QGIS software, enabling the display of photogrammetric models and archival aerial photographs, was also presented. Based on this work, conclusions regar-ding source data, problems resulting from the specifics of archaeological data, the suitability of „open source” software and a selected approach to spatial data management for the archaeological rese-arch at Archaeological Museum in Biskupin were formulated.

Dane autorów / Authors details: in¿. Hubert Bujno

https://orcid.org/0000-0001-6767-8009 bujno@gmail.com

dr in¿. Joanna Pluto-Kossakowska https://orcid.org/0000-0002-6533-1332 joanna.kossakowska@pw.edu.pl mgr Jaros³aw Kopiasz j.kopiasz@biskupin.pl Przes³ano /Received 12.03.2018 Zaakceptowano / Accepted 30.06.2018 Opublikowano / Published 16.08.2018

(18)

Za³¹cznik

(19)