Ocena możliwości wykorzystania Systemu Informacji Geo- Geo-graficznej (GIS) do badań oddziaływania autostrad na

zago-spodarowanie terenu

W dobie społeczeństwa informacyjnego umiejętność zdobywania informacji jest klu-czowa zarówno dla dynamicznego rozwoju gospodarczego jak i dla dalszego rozwoju nauki (Gotlib i in. 2007). Informacje oraz zbudowana na nich wiedza muszą opierać się na danych, w tym danych przestrzennych. Dane te wymagają procedur działania, ich zgromadzenia, przetwo-rzenia, przeanalizowania, przy wykorzystaniu nowych technologii i w przypadku badań odpo-wiednich podejść badawczych. Taką technologię, która może zrewolucjonizować badania geo-graficzne, jest System Informacji Geograficznej (GIS) (patrz rozdz. 1.2). W niniejszym pod-rozdziale przedstawione zostaną rozważania dotyczące stopnia, w jakim system ten może być przydatny w badaniach oddziaływania autostrad na zmiany wielkości, kształtu działek, użytko-wania ziemi, wybranych cech ekonomiczno-społecznych, oraz jakie są ograniczania przepro-wadzanych w ten sposób badań.

Podstawowym oprogramowaniem stosowanym w niniejszej pracy był ArcGIS 10.5 De-sktop, który zapewnia zestaw narzędzi i metod służących do gromadzenia danych, ich integra-cji, zarządzania, analiz oraz wizualizacji (ArcGIS HELP [en] 2018, Jażdżewska, Lechowski 2018). ArcGIS udostępnia również aplikacje takie jak ModelBuilder, które umożliwiają two-rzenie narzędzi przetwarzających dane przestrzenne w sposób graficzny (Ormsby i in. 2010). Dostarcza również wbudowane narzędzia obsługujące programowanie w językach Python,

Vi-sual Basic for Applications czy JavaScript dając tym samym możliwość tworzenia własnych fragmentów kodów wewnątrz nich, np. kalkulator pól (Field Calculator), tworzenie etykiet. Wreszcie pozwala tworzyć, funkcje, klasy, nowe narzędzia za pomocą języka Python w konsoli

Python wbudowanej w ArcMap lub w oprogramowaniu firm trzecich w oparciu o pakiet ArcPy

(ArcGIS HELP [en] 2018). W niniejszej pracy wykorzystano zarówno funkcjonalność, jaką danej ModelBuilder, jak również wykonano autorskie narzędzia GIS w oparciu o możliwości pakietu ArcPy. Narzędzia te napisano w zewnętrznym oprogramowaniu Pycharm Edu 17.3.

Zastosowany w pracy model postępowania badawczego składa się z 4 etapów i nawiązuje do opisu graficznego systemu GIS zaproponowanego przez Tomlinsona (2007) (Ryc. 2.4). Pierwszy etap polegał na: (1) pozyskaniu danych przestrzennych ze źródeł zewnętrznych, (2) zaprojektowaniu struktury bazodanowej, (3) dostosowaniu danych do importu oraz

99

zaimportowania ich do odpowiednich geobaz plikowych oraz (4) przygotowaniu ich do dal-szego przetwarzania.

Ryc. 2.4 Przyjęty w pracy schemat aplikacyjny wykorzystania Systemu Informacji Geograficznej (GIS) do badania wpływu budowy autostrad na wielkość, kształt i użytkowanie terenu

Źródło: opracowanie własne na podstawie Tomlinson (2007)

Otrzymane dane wchodziły w skład jednego z czterech podstawowych modeli danych: 1.1. danych rastrowych, 1.2 danych wektorowych, 1.3. tabel oraz 1.4. plików tekstowych, każda z tych grup wymagała nieco innego postępowania.

W skład danych rastrowych weszły ortofotomapy z 2004 r. oraz 2009 r. oraz zeskanowane z rozdzielczością 300 dpi mapy geologiczne, geomorfologiczne i glebowe (patrz rozdz. 2.1.4). Ortofotomapy zapisane były w formacie geoTIFF i posiadały zdefiniowany układ współrzęd-nych PL-1992. Mapy analogowe, zapisane z w formacie JPEG wymagały nadania georeferencji (Ryc. 2.4, pkt. 1.3).

Większość pozyskanych danych reprezentowała model wektorowy (Ryc. 2.4, pkt. 1.2) i była zapisana jako plik shapefile lub była dostarczona jako geobaza plikowa zawierająca klasy obiektów (Tab. 2.4). W przypadku zbiorników wód podziemnych dane pozyskano przez usługę WFS (Web Feature Service) umożliwiającą pozyskiwanie wektorowych danych przestrzen-nych przez Internet w formie usługi (Jażdżewska, Lechowski 2018). Tylko dane pochodzące z serwisu OpenStreetMap posiadały inny układ współrzędnych i w związku z tym ze względu optymalizacji pracy wymagały dokonania transformacji do układu PL-1992.

100

Tab. 2.4 Wykaz danych wektorowych wykorzystanych w badaniach

Zasób (Administrator danych)

Układ

współrzędnych ^{Dane Format} danych

Państwowy Rejestr Gra-nic (GUGiK)

PL-1992

Obręby ewidencyjne, gminy, powiaty, woje-wództwa, punkty adresowe

Shapefile Państwowy Rejestr Nazw Geograficznych (GUGiK) Miejscowości Portal Geostatystyczny

(GUS) Miejscowości do celów statystycznych Centralny Rejestr Form

Ochrony Przyrody (GDOŚ)

Korytarze ekologiczne, obszary chronionego krajobrazu, obszary specjalnej ochrony, parki krajobrazowe, parki narodowe, pomniki przyrody, ramsar, rezerwaty, spejcalne ob-szary ochrony, stanowiska dokumentacyjne, użytki ekologiczne, zespoły krajobrazowo-przyrodnicze

Centralna Baza Danych Geologicznych (PIG-PIB) Zbiorniki wód podziemnych Klasy obiek-tów (poprzez usługę WFS) Baza danych obiektów

topograficznych (WOD-GiK)

Kategorie klas obiektów: Sieć wodna (SW), sieć komunikacyjna (SK), sieć uzbrojenia te-renu (SU), pokrycie tete-renu (PT), budynki, budowle i urządzenia (BU), kompleksy użyt-kowania terenu (KU), obiekty inne (OI)

Klasy obiek-tów

OpenStreetMap

(Open-StreetMap Foundation)

WGS-84

Drogi (roads) ^Shapefile

Żródło: opracowanie własne

Część danych wykorzystanych w dalszych analizach przestrzennych została udostęp-niona w formie tabel xls (Ryc. 2.4, pkt. 1.3). Dane w tej postaci pozyskano z krajowego rejestru urzędowego gospodarki narodowej (REGON) oraz z Banku Danych Lokalnych Głównego Urzędu Statystycznego (GUS). W obu przypadkach tabele posiadały identyfikatory, na bazie których można było powiązać je z danymi przestrzennymi. Na tym etapie pracy tabele wyge-nerowane z Banku Danych Lokalnych należało przygotować w taki sposób, aby można było dokonać ich złączenia z podstawowymi jednostkami Państwowego Rejestru Granic. Z kolei wpisy w bazie REGON wymagały przeprowadzenia geokodowania, które w przypadku niniej-szej pracy dokonano w oparciu o znajdujący się w nim adres oraz punkty adresowe pobrane z Państwowego Rejestru Granic.

Ostatnia grupa danych wykorzystana w pracy miała charakter tekstowy i wymagała przeprowadzenia transformacji do plików wektorowych. Znalazły się w niej pliki ASCII, prze-chowujące informacje o numerycznym modelu terenu oraz baza EGiB, zapisana w formacie tekstowym SWDE (Ryc. 2.4, pkt. 1.3). Pliki ASCII mogły zostać przekonwertowane do klasy obiektów multipoint bezpośrednio w oprogramowaniu ArcGIS z wykorzystaniem modułu 3d

Network Analyst. W przypadku EGiB konieczne było wykorzystanie aplikacji zewnętrznych, takich jak SWDE Manager LT, dostępnej poprzez przeglądarkę internetową. Aplikacja

101

umożliwiła wygenerowanie z bazy EGIB warstw (użytków, działek ewidencyjnych) oraz da-nych tabelaryczda-nych dotyczących formy własności. Pozwoliła na przeglądanie bieżących wpi-sów dotyczących działki, budynku, użytku, punktu granicznego. W przeciwieństwie do opro-gramowań komercyjnych pozbawiona była niektórych funkcjonalności, np. możliwości pod-glądania historii zmian poszczególnych działek.

Przyjęty w pracy projekt struktury bazodanowej zakładał powstanie czterech geobaz pli-kowych: rastrowej, edycyjnej, referencyjnej, analitycznej. Geobaza rastrowa była odpowie-dzialna za przechowywanie ortofotomap oraz map analogowych. Oddzielenie ich od pozosta-łego zbioru danych służyło zwiększeniu wydajności pracy. Przy ograniczonych zasobach sprzę-towych przechowywanie wszystkich danych w jednej geobazie znacznie spowalniało prace, zwłaszcza w trakcie edycji. Zadaniem geobazy referencyjnej było przechowywanie wszystkich bazowych klas obiektów i tabel wykorzystywanych w pracy. Z założenia znajdujące się w niej dane nie podlegały ani edycji geometrycznej, ani atrybutowej. Służyła jako repozytorium da-nych możliwych do wykorzystania w dalszych analizach lub w dalszym przetwarzaniu. Geo-baza edycyjna miała charakter tymczasowy, to w niej tworzone były kopie klas obiektów z geobazy referencyjnej, podlegające edycji, przetwarzaniu. Po zakończeniu działania, skryptu, narzędzia lub skończeniu części pracy wyniki z niej były przenoszone, w zależności od celu pracy do geobazy referencyjnej lub analitycznej. Ostatnia, geobaza analityczna przechowywała wyniki przetwarzania, opracowywanych analiz przestrzennych. Jej struktura zapisu plików miała wskazywać, jakiego zadania dotyczyła analiza.

W pierwszej kolejności w geobazie rastrowej stworzono katalogi rastrów oddzielnie dla każdej serii czasowej ortofotomapy. Następnie do każdego z katalogów zaimportowano odpo-wiednie arkusze ortofotomap. Były one podstawą fotointerpretacji użytkowania ziemi w przy-jętej klasyfikacji w 2004 r. oraz materiałem pomocniczym do klasyfikacji użytkowania ziemi w 2014 r. W kolejnym kroku do geobazy rastrowej dodano jako zestaw danych rastrowych (Raster Dataset) zeskanowane mapy geologiczne, geomorfologiczne i glebowe. Przy pomocy narzędzia geoodniesienia (Georeferencing), mapy te zarejestrowano w układzie współrzędnych PL-1992, używając za warstwy referencyjne granic administracyjnych z PRG oraz lokalizacji miejscowości z PRNG. Mapy te zostały następnie zdigitalizowane. W tym celu w geobazie edycyjnej utworzony został zestaw danych „charakterystykaGmin”, w którym utworzono sze-reg klas obiektów, głównie typu powierzchniowego. Do klas tych przerysowano poszczególne, znajdujące się na digitalizowanych mapach warstwy. Po zakończeniu pracy cały zestaw danych zaimportowano do geobazy referencyjnej i wyczyszczono geobazę edycyjną.

102

Obiekty wektorowe, pozyskane na potrzeby pracy wymagały przed importem do geobazy referencyjnej przycięcia oraz przefiltrowania do obszaru badań. Granice administracyjne gmin musiały obejmować dwa zakresy – badane gminy powiatu zgierskiego oraz w szerszym zakre-sie Łódzki Obszar Metropolitalny (ŁOM). Dlatego do geobazy referencyjnej zaimportowane zostały wszystkie gminy z ŁOM, a następnie poprzez pliki warstw (Layers) wyświetlane były te, które aktualnie były potrzebne. Podobnie postąpiono z warstwą powiatów. Dodatkowo, z warstwy województw do geobazy referencyjnej wprowadzono wyłącznie województwo łódz-kie. Z klasy obiektów gminy stworzona została warstwa obszaru badań. Wykorzystując prosty model w ModelBuilder bazujący na iteracji, przycięciu (Clip), funkcji Zlicz (Get Count) i Se-lekcji (Select) docięto do obszaru badań wszystkie pliki shapefile, klasy obiektów znajdujące się w folderze i jego podfolderach (Ryc. 2.5). Wyniki zapisano w geobazie referencyjnej.

Ryc. 2.5 Przykład narzędzia ModelBuilder przycinającego wszystkie pliki do zadanego obszaru badań Źródło: opracowanie własne

Ponieważ zgromadzone w geobazie referencyjnej dane zawierały znaczną liczbę atrybu-tów nieistotnych z punktu widzenia pracy, zostały one usunięte z poszczególnych warstw. Szczególnej uwagi wymagały drogi (SKJZ) zapisane w BDOT. Miały być one podstawą kon-strukcji zestawu danych sieciowych (Network Dataset). W ich przypadku, aby uniknąć efektów krawędziowych, stworzona i zapisana została do geobazy referencyjnej jeszcze jedna kopia dróg, obejmująca wszystkie powiaty sąsiadujące z powiatem zgierskim.

Wyznaczenie potencjalnych form użytkowania ziemi w oparciu o materiały źródłowe wymagało wcześniejszego przygotowania danych. Ponieważ pokrycie terenu w BDOT10k cha-rakteryzuje się ciągłością powierzchni, pełnym pokryciem na całym obszarze i rozłącznością, takim samym schematem atrybutów (takie same nazwy i typy danych) za pomocą funkcji Po-łącz (Merge) zPo-łączono wszystkie formy pokrycia terenu w jedną klasę. Aby na potrzeby przy-szłej wizualizacji danych można było reprezentować granice jednostek administracyjnych a nie

103

ich powierzchnie, dla wszystkich jednostek administracji zastosowano funkcję „Obiekt do li-nii”, dokonującej konwersję pozostałych typów danych przestrzennych (punktów, poligonów) do linii.

W przypadku danych tabelarycznych odmienną procedurę zastosowano dla danych po-chodzących z Banku Danych Lokalnych GUS oraz bazy REGON. Dla danych GUS usunięto scalenia kolumn, dostosowano nagłówki kolumn do wymagań ArcGIS i zaimportowano je za pomocą funkcji ExcelDoTabeli (ExcelToTable) do geobazy referencyjnej. Z kolei dla danych REGON z 2004 r. i 2014 r., przefiltrowano podmioty do badanych gmin, scalono adres w jedną całość, w ArcGIS utworzono metodą prostą lokalizator adresów (Address Locator), w którym za punkty referencyjne posłużyły adresy z PRG (wcześniej sprowadzono cały adres do jednego pola) i przeprowadzono geokodowanie. Punkty, którym nie można było przypisać adresów, próbowano odnaleźć w oparciu o narzędzie geokodowania (Geocode) dostępne poprzez wtyczkę MMQGIS w aplikacji QGIS. Nakładka ta wykorzystywała dane referencyjne Google do odnajdywania adresów. Obecnie, po zmianie warunków licencji korzystania z Google Api jej funkcjonalność została znacząco ograniczona. Adresy, które nie zostały zidentyfikowane przez tę wtyczkę usunięto z bazy (stanowiły one mniej niż 5% wszystkich wpisów w rejestrze). Do geobazy źródłowej dołączono również model TIN oparty na pliku tekstowym ASCII przechowującym informację o położeniu punktu i jego wysokości. Ten numeryczny model te-renu został wygenerowany dwuetapowo. W pierwszej kolejności punkty ASCII zamieniono na klasę obiektów wielopunkty (zapisaną w geobazie edycyjnej). Utworzone dane wykorzystano następnie do wygenerowania modelu za pomocą funkcji utwórz TIN (Create TIN).

Najbardziej pracochłonnym zadaniem na tym etapie opracowania okazało się przygoto-wanie do dalszego przetwarzania, analizowania i wizualizacji działek ewidencyjnych, w mniej-szym stopniu użytków pochodzących z Ewidencji Gruntów i Budynków. W pierwmniej-szym etapie za pomocą aplikacji SWDE Manager LT dla każdej gminy lub w przypadku gminy miejsko-wiejskiej, części gminy dokonano konwersji działek ewidencyjnych, użytków i klasoużytków zapisanych w SWDE na pliki shapefile. W przypadku parceli i użytków dane pobierano dla 2000 r., 2004 r., 2009 r. oraz 2014 r.

Dane z 2000 r. oraz 2009 r. miały funkcje pomocnicze w odtwarzaniu podziałów kata-stralnych, które w wyniku różnych migracji danych nie zachowały się w postaci archiwalnej (patrz rozdz. 2.1.1). Wszystkie warstwy pozyskane z PODGiK posiadały również dodatkowe błędy geometrii. Dlatego następnym krokiem była naprawa obiektów które nie miały geometrii za pomocą funkcji Napraw Geometrię (Repair Geometry). Bez tej korekty nie można byłoby wykonać kolejnego kroku – połączenia danych dotyczących działek lub użytków dla całego

104

obszaru. Połączone pliki zapisane zostały w utworzonym specjalnie w tym celu zestawie da-nych (Feature Dataset) w bazie edycyjnej. Jako układ współrzędda-nych dla zestawu dada-nych usta-lono PL-1992, dzięki czemu w trakcie importowania do niego działek i użytków z poszczegól-nych lat dokonano jednocześnie ich konwersji z układu 2000 strefa 6 na wyżej wspomniany. W zestawie danych utworzono klasę topologii a następnie wykonano naprawy pojawiających się błędów nachodzenia na siebie obiektów oraz luk dla parceli i użytków z 2004 r. i 2014 r. Było to bardzo istotne. Jakiekolwiek błędy topologiczne pojawiające się na tej warstwie skut-kowałyby przerywaniem pracy narzędzi stosowanych w dalszej części przetwarzania, np. funk-cji przetnij (Intersect). Jednocześnie okazało się, że działki z powiatowego ośrodka nie były spójne z zewnętrzną granicą powiatu pozyskaną z PRG oraz w niektórych miejscach z grani-cami pomiędzy gminami. Rozbieżności te nie miały wpływu na realizację celu pracy, dlatego zostały pominięte. Konieczne okazało się jednak uzupełnienie braków działek w 2004 roku, odtworzenie ich wielkości i kształtów, co wykonano przeglądając dane pośrednie oraz pliki SWDE (patrz rozdz. 2.1.4.). Podobne czynności wykonano dla warstwy użytków. Tak przygo-towane, poprawione dane zostały następnie jeszcze raz zweryfikowane pod względem popraw-ności topologii i skopiowane z całym zestawem danych do warstwy referencyjnej.

Na potrzeby pracy z pliku SWDE wygenerowano również raporty dla każdej działki ewi-dencyjnej, w celu pozyskania informacji o własnościach poszczególnych działek w 2014 r. Dane te zagregowano, uporządkowano strukturę atrybutów wyrzucając te, które nie były istotne z punktu widzenia pracy i zaimportowano wspomnianą wcześniej funkcją ExcelDoTabeli do geobazy referencyjnej. Jednocześnie wyczyszczono geobazę edycyjną i przygotowano ją do następnego etapu pracy.

Drugi etap pracy badawczej w środowisku GIS obejmował przetwarzanie istniejących już danych źródłowych, ich harmonizację, integrację, edycję oraz weryfikację ich jakości (Ryc. 2.4). Miał na celu przygotowanie wszystkich danych do analiz przestrzennych, w tym przede wszystkim:

a) przygotowanie klasy obiektów ze schematem klasyfikacji oraz opracowanie zdjęcia użytkowania ziemi z 2004 oraz 2014 r. (pkt. 2.1),

b) uproszczenie kształtu parceli z zachowaniem spójności ich granic oraz wygenerowa-nie dla każdej z nich informacji o liczbie węzłów (spełniających założoną tolerancję), liczbie kątów zbyt ostrych, liczbie kątów zbyt wklęsłych, odchyleniu standardowym odległości pomiędzy centroidą działki i jej wierzchołkami, przeciętnej odległości po-między centroidą działki a jej wierzchołkami, liczbie krawędzi, których wierzchołki są krótsze od zadanej wartości (pkt. 2.2).

105

c) opracowanie modelu sieci transportowej oraz wygenerowanie na jego podstawie ob-szarów obsługi w izochronach dwuminutowych od węzłów autostrady, również opra-cowanie buforów wielopierścieniowych wokół osi autostrad (pkt. 2.3).

W pierwszej kolejności stworzono strukturę atrybutów opartą na przyjętym schemacie klasyfikacji. W tym celu w geobazie referencyjnej utworzono zestaw danych o nazwie „użyt-kowanie” z układem współrzędnych PL-1992 dodano do niego nową, pustą klasę obiektów, której zdefiniowano atrybuty: numer identyfikacyjny działki, numer obrębu ewidencyjnego, funkcja ogólna użytku (pierwszy poziom klasyfikacji), funkcja szczegółowa użytku (drugi po-ziom klasyfikacji), numer jednostki rejestrowej gruntu. Do wprowadzania podstawowych form użytkowania ziemi wykorzystano podtypy. Na poziomie szczegółowym klasyfikacji każdy podstawowy rodzaj użytku miał oddzielną domenę opisującą wchodzące w jej skład grupy. Każdą, utworzoną w ten sposób domenę przypisano do odpowiadającej mu funkcji ogólnej, zakodowanej w podtypach. W celu weryfikacji poprawności topologicznej w ramach schematu klasyfikacji utworzona została klasa topologii, która dla warstwy użytków zakładała weryfika-cję dwóch podstawowych reguł topologicznych: czy obiekty w obrębie klasy nachodzą na sie-bie, oraz czy między obiektami znajdują się jakieś luki. W topologii ustawiono tolerancję sku-piania na 1 cm. Możliwość przesunięcia węzła o 1cm nie zmienia wyników analizy, a pozwoliło pozbywać się bardzo niewielkich powierzchni wynikających z przecinania warstw względem siebie

Tak przygotowany schemat zaimportowano następnie do geobazy edycyjnej. Już w geo-bazie edycyjnej do pustej klasy obiektów zaimportowano obiekty – działki z 2014 r. W następ-nym kroku, za pomocą narzędzia Sumuj (Sum) połączono ze sobą warstwy pokrycia terenu z BDOT10k, kompleksów użytkowania terenu z BDOT10k, użytków z EGiB i działek ewiden-cyjnych z EWiD tworząc niewielkie obiekty. Wykorzystując w trybie edycji funkcję Rozbij (Explode Multipart Feature) zamieniono dodatkowo wszystkie obiekty wieloczęściowe na po-jedyncze segmenty. Takie podejście do identyfikacji funkcji na działce nawiązuje do paradyg-matu klasyfikacji obiektowej, w której najpierw dokonuje się segmentacji obrazu a następnie jego klasyfikacji (Lewiński 2007). Różnica jest tylko taka, że w przypadku klasyfikacji obiek-towej bierze się pod uwagę przede wszystkim dane hiperspektralne w połączeniu z innymi ty-pami danych (np. plikami lidar), w niniejszej pracy zaś oparto się wyłącznie na obiektach wek-torowych i ich relacjach topologicznych, przestrzennych oraz ich informacjach atrybutowych (ibid.).

Procedura w pierwszym etapie klasyfikacji wykorzystywała narzędzia tworzenia podsu-mowania statystycznego (Summary Statistics), sortowania (Sort), dodawania kolumn na

106

podstawie złączenia (Join Field), dodawania kolumn (Add Field) oraz uzupełniania w nich war-tości (Calculate Field). W rezultacie powstała tabela przedstawiająca dominującą pod wzglę-dem procentowego udziału powierzchni kombinację wartości pomiędzy 4 warstwami, które wzięły udział w narzędziu Suma. Aby zachować powtarzalność procedury oraz zautomatyzo-wać pracę, całość została zapisana jako funkcja w języku Python. .25

Wykorzystując zapytania atrybutowe i przestrzenne na opracowanej tabeli identyfiko-wano potencjalną funkcję, jaką dany teren mógł pełnić. W pierwszej kolejności funkcję tę przy-pisywano terenom, co do których istniało bardzo duże prawdopodobieństwo, że nie zaszła w ich obrębie żadna zmiana funkcjonalna, np. na części terenów kolejowych, drogowych, zabu-dowy mieszkaniowej jednorodzinnej, użytków kopalnych i terenów usługowych. Jednocześnie sprawdzono, czy spełnione zostały kryteria minimalnego wydzielenia, założone w klasyfikacji (patrz rozdz. 2.2.2). Obiekty raz przypisane same nie podlegały dalszej klasyfikacji, chociaż wykorzystywano ich atrybuty i geometrię. Poprzez zapytanie atrybutowe sprawdzano np. czy sąsiadujące z nią działki mają ten sam numer jednostki rejestrowej, zakładając, że ten sam wła-ściciel działki sąsiedniej zwiększa szansę, że działka ma tę samą funkcję. W kolejnych krokach, do klasyfikacji włączono pozostałe dane, posiadające powiązania z przyjętą klasyfikacją. Do określania funkcji spośród metod i narzędzi GIS, poza wymienionymi wcześniej wykorzystano: dociągania (Snap), upraszczania kształtu (Simplify), złączeń przestrzennych (Spatial Join), sta-tystyki sumarycznej (Summary Statistics) i sąsiedztwa poligonów (Polygon Neighobrhood). Stworzono klasę obiektów, która zawierała potencjalne formy użytkowania ziemi, a jednocze-śnie była zgodna z podtypami oraz domenami zdefiniowanymi w szablonie projektu. Ostatnimi warstwami, które próbowano automatycznie wydzielać były nieużytki. Stosując zapytania prze-strzenne przekwalifikowane zostały działki, które w kategorii istnienia znajdujących się na nich budynków mieszkalnych miały wartość ‘ncz’ lub ‘bud’. Opierając się na wnioskach z harmo-nizacji założono, że tam, gdzie jest to możliwe warstwy BDOT10k są ważniejsze od użytków EGiB. W oparciu o procedury i reguły klasyfikacyjne możliwe było dopasowanie danych do przyjętej w pracy klasyfikacji, na poziomie 70%-80% (np. dla terenów mieszkaniowych, la-sów), przy czym dokładność klasyfikacji w dużej mierze zależy od formy użytkowania ziemi.

Zgodnie z tą regułą grunty orne, część zabudowy usługowej, przemysłowej, mieszkalnej wydzielano w oparciu o BDOT10k, lecz użytki zielone (łąki i pastwiska), rowy melioracyjne, czy drogi identyfikowano w oparciu o EGiB. Najgorsze dopasowania, nieprzekraczające 50 % wystąpiły w obrębie nieużytków seminarialnych, terenów o funkcjach mieszanych oraz w ob-rębie wybranych klas terenów zieleni i rekreacji (np. zabudowy letniskowej i ogrodów działko-wych), terenów wód (nie można było określić przeznaczenia zbiornika, odróżnić łowiska

107

prywatnego od stawu hodowlanego), powstałych terenów chowu, hodowli i obsługi rolnictwa. W tych przypadkach identyfikacja funkcji wymagała obserwacji ze zdjęć lotniczych, zdjęć za-mieszczonych na Google StreetView lub obserwacji terenowych.

Opracowane wstępnie zdjęcie użytkowania ziemi poddano następnie fotointerpretacji wi-zualnej w oparciu o warstwy ortofotomapy dostępne w odpowiednich katalogach rastrów,

Goo-gle Maps i GooGoo-gle Street View. Na koniec przeprowadzono inwentaryzację terenową w celu oceny jakości opracowanego zdjęcia użytkowania ziemi. Po wprowadzeniu wszystkich mody-fikacji gotowa klasa obiektów została zweryfikowana pod względem poprawności topologicz-nej i jeżeli przeszła pozytywnie kontrolę została przekopiowana do geobazy referencyjtopologicz-nej.

Aby utrzymać topologię pomiędzy użytkowaniem ziemi z dwóch różnych okresów zało-żono, że pierwsze opracowane użytkowanie ziemi powinno być podstawą opracowania kolej-nego. Założono bowiem, że na badanym obszarze nastąpił wzrost fragmentaryzacji przestrzeni w czasie, a więc większą liczbę wydzieleń można było zaobserwować w 2014 r. niż w 2004 r. Ponieważ w programach GIS łatwiej jest łączyć mniejsze obiekty niż dzielić podjęto decyzję, aby jako pierwsze opracować późniejsze użytkowanie ziemi i wykorzystać je do przygotowania