SIECIOWY SYSTEM AGENTOWY W GEOINFORMATYCE OBRAZOWEJ

Transkrypt

1 Akademia Górniczo-Hutnicza im. Stanisława Staszica Wydział Geodezji Górniczej i Inżynierii Środowiska Zakład Fotogrametrii i Informatyki Teledetekcyjnej Rozprawa doktorska SIECIOWY SYSTEM AGENTOWY W GEOINFORMATYCE OBRAZOWEJ Mariusz Twardowski promotor: dr hab. inż., Krystian Pyka Kraków 2007

2 "Mówiąc o wolnym oprogramowaniu mamy na myśli swobodę, a nie cenę." Free Software Foundation

3 Spis Treści Spis treści: 1. Wprowadzenie Przegląd istniejących metod sieciowego udostępniania i kontroli danych Geneza i budowa protokołu TCP/IP Protokoły aplikacji sieciowych typu client-server Telnet FTP (File Transfer Protocol) HTTP (HyperText Transfer Protocol) SMTP (Simple Mail Transfer Protocol), POP3 (Post Office Protocol), IMAP (Internet Message Protocol Access) DNS (Domain Name Server) Protokoły szyfrowane Przykłady wykorzystania protokołów sieciowych do udostępniania danych geoinformacyjnych SZDF - System Zarządzania Danymi Fotogrametrycznymi System internetowego pomiaru obrazów fotogrametrycznych UWM Olsztyn Geoportal.gov.pl BDO - Baza Danych Ogólnogeograficznych Małopolska z lotu ptaka Google Earth Plany miast i mapy samochodowe

4 Spis Treści 3. System agentowy Środowisko systemu agentowego - system operacyjny System D'Agents Serwer systemu Menadżer zasobów API serwera agentowego Interpretery programu agenta D'Agents na tle innych systemów agentowych Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Opracowane metody zwiększające funkcjonalność systemu agentowego Charakterystyka bazy obrazowej Program agenta Program przetwarzania zasobów Zabezpieczenie poufności transmisji danych System propagacji serwerów Opracowane metody na potrzeby interaktywności - interfejs użytkownika Terminal tekstowy Przejściowe połączenie technik przy użyciu terminala i VSD-AGH Projekt interfejsu dedykowanego dla potrzeb wysyłania zapytań i wizualizacji Uogólniona hierarchia aplikacji Interfejs użytkownika Architektura silnika graficznego

5 Spis Treści Charakterystyka obsługiwanych danych graficznych Integracja interfejsu graficznego z systemem agentowym Doświadczenia na danych rzeczywistych i analiza prezentowanych rozwiązań Pola doświadczalne Dane doświadczalne - obrazy i metadane Procedury doświadczeń Praktyczny aspekt proponowanego rozwiązania Korzyści z użytkowania systemu i analiza wydajności Podsumowanie Bibliografia

6 Wprowadzenie 1. Wprowadzenie Rozwijająca się dynamicznie przez ostatnie lata technologia w dziedzinie elektroniki, spowodowała niemal logarytmiczny wzrost mocy obliczeniowej komputerów, które znalazły zastosowanie w praktycznie każdym aspekcie życia. Jednoczesna znaczna poprawa infrastruktury sieci ogólnoświatowej oraz popularyzacja Internetu, daje niewątpliwe powody do tego, aby wykorzystywać te możliwości podczas realizacji wszelkich przedsięwzięć gospodarczych, społecznych czy też naukowych. Dane, które można zapisać, przetworzyć i przedstawić w formie dyskretnej są opracowywane z wykorzystaniem komputera w sposób zdecydowanie szybszy. Wszystko czego potrzeba to jednorazowy wysiłek wniesiony w stworzenie poprawnie działającego systemu, który po dostarczeniu danych może pracować bez dalszej ingerencji człowieka i po pewnym czasie dostarczyć przetworzone informacje. Obszarem nadającym się dobrze na zagospodarowanie, przy użyciu tych technologi, są niewątpliwie wszelkiego typu obrazy wykorzystywane w różnych dziedzinach geoinformacyjnych. Zdjęcia lotnicze i satelitarne stanowią niezwykle bogate źródło informacji o środowisku, w którym żyjemy. Podstawową cechą tych materiałów jest ich doskonała czytelność, czyli bardzo wysoka rozdzielczość, pozwalająca na identyfikację drobnych szczegółów kształtu obiektów, a także wysoka rozdzielczość spektralna, ułatwiająca identyfikację rodzaju i stanu tychże obiektów np.: rodzaju uprawy, zawilgocenia gleby, kultury rolnej. Dodatkowym czynnikiem poprawiającym jakość percepcji informacji zawartej na zdjęciach lotniczych i satelitarnych jest stereoskopia. Współcześnie stereoskopia staje się bardzo popularna dzięki kinom stereoskopowym i możliwościom nowoczesnych kart graficznych działających w technologii migawkowej lub polaryzacyjnej. Jednak walory tych materiałów cyfrowych są znane jedynie specjalistom. Nadal szerokie kręgi osób, które by mogły wiele skorzystać używając obrazów przy realizacji swoich zawodowych i prywatnych zamierzeń, nie ma do nich dostępu lub ten dostęp jest na tyle utrudniony, że w praktyce się go nie wykorzystuje. Ma na to wpływ kilka czynników zarówno formalnych, mentalnych jak i technicznych, jednak ze względu na charakter poniższej pracy w polu zainteresowania będzie tylko ostatni aspekt. Najprostszym sposobem dostępu do różnych materiałów, w tym materiałów obrazowych, jest pozyskiwanie ich z wykorzystaniem łączy internetowych. Jednakże dla mniej wprawnego użytkownika znalezienie właściwych danych w Internecie bywa kłopotliwe. Poza tym główna zaleta materiałów fotogrametrycznych i teledetekcyjnych, 6

7 Wprowadzenie polegająca na jak najlepszym zachowaniu dużej ilości szczegółów sytuacyjnych, jest ich największą wadą w przypadku, gdy dane mają zostać przesłane poprzez sieć komputerową. Stajemy w efekcie przed głównym problemem dużych rozmiarów plików obrazowych. Przechowanie tak dużej ilości danych w jednym miejscu jest problematyczne i wymaga dużych nakładów; łatwiej jest przechowywać materiały na szeregu rozproszonych serwerów. W szczególności zdjęcia stereoskopowe są jednym z tych rodzajów materiałów obrazowych, które wymagają wstępnego przygotowania, aby przeciętny użytkownik mógł je owocnie wykorzystać dla swoich celów. Aby mógł wykonać stereoskopową interpretację treści obrazów, a także proste pomiary sytuacyjne i wysokościowe na modelu stereoskopowym. Znacznym ułatwieniem w wyszukiwaniu oraz pozyskiwaniu cyfrowych obrazów fotogrametrycznych i teledetekcyjnych może okazać się wykorzystanie systemu agentowego. Pełniłby on funkcję serca systemu, polegającego na tym, że ze strony użytkownika wystarczyłoby wskazać obszar, którym jest zainteresowany, a system samodzielnie, od momentu wskazania przez użytkownika obszaru, który go interesuje, wykorzystując odpowiednio zaprogramowanego agenta, dokonywałby przeszukania wszystkich serwerów dostępnych dla tego systemu. System pozwalałby w prosty sposób pozyskiwać dane z rozproszonej bazy obrazów, wykorzystując heterogeniczną, czyli zróżnicowaną pod względem infrastruktury, sieć komputerową. Materiały piktograficzne zgromadzone w czasie takiej automatycznej kwerendy byłyby dostarczane pod określony adres internetowy najbliższy fizycznie użytkownikowi. Następnie przeprowadzana byłaby wizualizacja przy pomocy przeglądarki internetowej, graficznej lub odpowiedniej dedykowanej przeglądarki stereoskopowej, jeżeli taka byłaby charakterystyka materiałów. Idea stworzenia takiego systemu powstała po kongresie ISPRS w 2000 roku, gdzie w jednej z publikacji napomknięte zostało między innymi, że prawdopodobnie możliwe byłoby zastosowanie systemu agentów mobilnych do wyszukiwania informacji przestrzennych w rozproszonej bazie danych [Bishr 2000]. Koncepcja ta jednak nie została rozwinięta, oraz nie zostały przeprowadzone badania potwierdzające słuszność takiego twierdzenia. Duży i sprawnie działający system jest tworzony przy współpracy wielu osób, dlatego wnosząc swoją część pracy do pozostałych osiągnięć należy pamiętać o tym, że powinna być zgodna z przyjętymi założeniami, pozwalając tym samym na jej dalsze wykorzystanie i rozbudowę. Zbiór opracowanych metod działania musi być na tyle uniwersalny, żeby mógł mieć zastosowanie na możliwie wielu platformach systemowych oraz nie zostać ograniczonym tylko do środowiska w którym był tworzony. Dlatego 7

8 Wprowadzenie założenia projektu obejmują wykorzystanie istniejącego oprogramowania, pod warunkiem pełnej dostępności do kodu źródłowego (tzw. Open Source), udostępnianego na licencji L/GPL (Lesser/GNU Public License) [FSF 2007], która pozwala na dowolną jego modyfikację i wykorzystanie. Co prawda sporadycznie, w trakcie testów, wykorzystywane były komercyjne systemy operacyjne, jednak tylko w celu sprawdzenia poprawności proponowanego rozwiązania i nie są one wymagane do pracy systemu. Niniejsza rozprawa stanowi, nie podejmowaną wcześniej, próbę opracowania metody opartej na wykorzystaniu systemu agentów mobilnych do pozyskiwania i późniejszej wizualizacji interesujących obszarów, przedstawionych za pomocą cyfrowych materiałów fotogrametrycznych, które są automatycznie wyszukiwane w rozproszonej bazie danych obrazowych. W rozdziale drugim pracy zawarto przegląd istniejących metod używanych w transmisji danych, a także sposoby wykorzystania tychże metod do udostępniania danych geoinformacyjnych. Pomimo rozwoju na tle technologicznym nie wszyscy zdają sobie sprawę z możliwości, jakie idą w parze z tymi osiągnięciami. Rozdział trzeci to opis działania serca projektu czyli systemu agentowego. Opisane w nim zostało co to jest system agentowy, w jakim środowisku może działać, z jakich elementów się składa, w jaki sposób działa, czego wymaga i co wnosi jeżeli zdecydujemy się go użyć. W rozdziale czwartym skupiono się nad elementami pomocniczymi, które brały udział w powstaniu systemu i których zadaniem jest wspomaganie systemu agentowego. Oprócz tego przedstawiono sposoby poprzez które system agentowy może komunikować się ze światem ludzi. Przeanalizowane zostaną możliwości stworzenia interfejsu użytkownika, który pozwoli na wydawanie poleceń systemowi oraz wizualizację przetworzonych danych. W ostatniej części przedstawiono wyniki działania systemu na danych rzeczywistych i ocenę poprawności tych wyników. Ponadto dokonano porównania opracowanej metody z innymi, wykazując jej wady i zalety oraz możliwości ulepszeń. Celem przeprowadzonych badań było udowodnienie tezy o następującej treści: zastosowanie systemu agentów mobilnych w sieci heterogenicznej do przeszukiwania rozproszonej bazy danych umożliwia automatyczne pozyskiwanie fragmentów obrazów cyfrowych dla potrzeb pomiarów fotogrametrycznych. 8

9 Przegląd istniejących metod sieciowego udostępniania i kontroli danych 2. Przegląd istniejących metod sieciowego udostępniania i kontroli danych W ciągu ostatnich kilku lat można było zaobserwować w Polsce dosłowny "boom na Internet". Chociaż w kręgach akademickich możliwość jego użytkowania znana jest od dłuższego czasu i nie jest żadną nowiną, to "przeciętny Kowalski" zdaje sobie z jego istnienia sprawę o wiele krócej. Firmy telekomunikacyjne ospale wprowadzały rozsądne oferty dostępu do Internetu: historyczny modem, potem SDI i Chello, a teraz Neostrada lub mozolny, ale dostępny z praktycznie dowolnej lokalizacji z telefonu komórkowego, GPRS. Zwiększało to stopniowo zainteresowanie tematem, a dodatkowo tradycyjne media zaczęły emitować reklamy, które docierały do szerokiej publiczności. W efekcie świadomość ogółu społeczeństwa podniosła się do poziomu, na którym oprócz wiedzy o istnieniu, wykreowała się również chęć używania. W obecnej chwili wiele osób może pochwalić się bez chwili zastanowienia, że potrafi korzystać z Internetu. Niestety wciąż na większości komputerów można zaobserwować obecność systemu spod znaku Redmond, którego twórcy dążą do monopolizacji w zakresie systemów informatycznych. W wyniku tylko niewielka grupa, głównie ludzi od dłuższego czasu związanych z tematem, zdaje sobie sprawę z faktu, że używając kolokwialnego terminu "wchodzić na Internet" w rzeczywistości ma na myśli uruchomienie programu pozwalającego na interpretację języka HTML, który to program korzystając z protokołu transmisji danych HTTP łączy się z wybranym poprzez nazwę jawną (np. fotogrametria.agh.edu.pl) serwerem, która to nazwa jest tłumaczona poprzez system DNS na adres IP żądanego serwera. W przybliżeniu, po połączeniu wszystkich tych elementów, otrzymujemy usługę, którą większość osób zna pod nazwą WWW lub witryny internetowej Geneza i budowa protokołu TCP/IP Protokoły należące do grupy TCP/IP (Transmission Control Protocol/Internet Protocol) działające na różnych typach systemów komputerowych i różnego rodzaju systemach operacyjnych pozwalają na komunikację między tymi systemami. Bez tego standardu nie byłoby Internetu, a przynajmniej nie w takiej postaci w jakiej znajduje się obecnie. Idea sieci komputerowej w praktyce została zapoczątkowana we wczesnych latach sześćdziesiątych poprzez, jak często bywa w przypadku znacznych postępów w technologii, rządową organizację RAND, desygnowaną przez Siły Powietrzne Stanów 9

10 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Zjednoczonych [Kistula 1997]. Organizacja miała na celu prowadzenie badań nad możliwością kontroli nad wyrzutniami rakiet i samolotów bombowych w przypadku ataku nuklearnego. Prace zakończyły się propozycją sieci przełączanej pakietami. Idea opierała się na rozbiciu danych na datagramy lub pakiety, z których każdy miałby oznaczenie skąd pochodzi i dokąd zmierza. Pakiety miały być przesyłane z komputera na komputer dopóki informacja nie dotrze do celu. Jeżeli z jakiegokolwiek powodu w którymkolwiek momencie pakiet zaginie, wiadomość może być ponownie wysłana poprzez nadawcę. W kilka lat później powstała pierwsza sieć komputerowa złożona z 4 hostów, połączona obwodem 50Kbps, czyli o prędkości modemu telefonicznego. Przez kolejnych kilka lat protokół komunikacji ewoluował najpierw w NCP (Network Control Protocol) a następnie, w połowie lat siedemdziesiątych, po raz pierwszy pojawił się termin Internet użyty przez V. Cerfa i B. Kahna w publikacji na temat Protokołu Kontroli Transmisji (TCP). Wkrótce też powstała organizacja IETF (The Internet Engineering Task Force), która miała i ma do tej pory za zadanie nadzór nad architekturą Internetu. Potem, na szczęście, zimna wojna się skończyła, a organizacje publiczne i komercyjne zaczęły korzystać z dobrodziejstw sieci komputerowych. W ten sposób powstał protokół, którego używamy w dniu dzisiejszym. TCP/IP jest otwartym systemem, ponieważ specyfikacje jego protokołów dostępne są publicznie i tworzy on podstawę tego co nazywamy siecią ogólnoświatową czyli Internetem. Protokoły sieciowe zazwyczaj projektowane są warstwowo, a zestaw protokołów TCP/IP rozważany jest przeważnie jako system cztero-warstwowy [Braden 2006b]. Najniższa warstwa o nazwie link zajmuje się szczegółami połączenia fizycznego. Jest ona niekiedy nazywana data-link lub network interface i zawiera urządzenie fizyczne, którym jest karta interfejsu oraz sterowniki systemu. Warstwa druga network obsługuje przesyłanie pakietów poprzez sieć np. routing. Składają się na tą warstwę protokoły IP (Internet Protocol), ICMP (Internet Control Message Protocol) i IGMP (Internet Group Management Protocol). Kolejna warstwa transport steruje przepływem danych pomiędzy komputerami, a składają sie na nią dwa znacznie różniące się protokoły TCP (Transmission Control Protocol) i UDP (User Datagram Protocol). Pierwszy z tych protokołów charakteryzuje się wysoką pewnością przepływu danych i zarządza podziałem danych na odpowiednie fragmenty dla poprzedniej warstwy. Sprawdza również poprawne zakończenie przesyłania i przekroczenia czasu życia pakietów. Dzięki temu wyższa warstwa nie musi obsługiwać tych detali. Standardowo protokół TCP wykorzystywany jest w systemach operacyjnych typu Unix. Natomiast protokół UDP przedstawia znacznie bardziej prymitywny interfejs dla wyższej warstwy. 10

11 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Po prostu wysyła pakiety nazywane datagramami i nie przeprowadza żadnej kontroli nad tym procesem. Kontrola musi zostać zaprogramowana za każdym razem w wyższej warstwie. Tego typu protokół używany jest często w systemach z rodziny Windows. Ostatnia najwyższa warstwa nazywana warstwą aplikacji (application) zajmuje się szczegółami konkretnej aplikacji uruchamianej na komputerze. Istnieje wiele powszechnie używanych programów opartych na protokołach tej warstwy np. telnet, ftp, smtp itp. [Braden 2006a], które zostaną przybliżone w dalszej części opracowania. Jak widać warstwa aplikacji zmienia sie w zależności od zastosowania programu, ale warstwy link, network, i transport pozostają niezmienne. Z powyższej struktury wynika najważniejsza cecha protokołu TCP/IP, którą jest enkapsulacja wyższej warstwy w niższą. Gdy aplikacja wysyła dane używając TCP, wówczas TCP przekazuje te dane do IP w postaci segmentów, następnie IP przekazuje te informacje do interfejsu sieciowego w postaci datagramu, aż wreszcie interfejs fizyczny przesyła dane kablem w postaci ramek. Podczas takiej multipleksacji każda z warstw dodaje nagłówki identyfikacyjne tak, aby dane po przesłaniu do drugiego interfejsu mogły zostać demultipleksowane w odwrotnej kolejności. HOST 1 FTP HOST 2 dane dane TCP TCP ROUTER segment segment IP IP datagram ETH FTP ramka datagram modem ETH IP datagram ramka modem Rys Schemat przepływu pakietu danych FTP poprzez sieć opartą na protokole TCP/IP z uwzględnieniem routera łączącego dwie sieci połączone różnymi interfejsami fizycznymi, z uwzględnieniem routera. Poprzez kolejne warstwy dane zamieniane są na segmenty, później na datagramy, aż w postaci ramek przesyłane są interfejsem fizycznym. Router różni się tym od serwera, że odkodowuje strumień danych tylko na poziomie IP przetwarzając jedynie datagramy. Oczywiście warstwa aplikacji teoretycznie mogłaby pomijać inne warstwy i komunikować się z innym programem bezpośrednio, tak jak to miało miejsce np. w systemie DOS, jednak miałoby to niewiele sensu ponieważ w każdej aplikacji trzeba by było wymyślać koło od nowa. 11

12 Przegląd istniejących metod sieciowego udostępniania i kontroli danych 2.2. Protokoły aplikacji sieciowych typu client-server Większość istniejących aplikacji sieciowych zakłada model, w którym z jednej strony połączenia znajduje się klient, czyli komputer żądający połączenia, a z drugiej serwer, czyli komputer oczekujący na nadejście połączenia. Model taki tradycyjnie nazywany jest client-server. Dodatkowo serwery używające tej metody można podzielić na dwie grupy: iteracyjne i konkurentne. W przypadku serwera iteracyjnego czeka on na nadejście połączenia od klienta, przetwarza zapytanie klienta, wysyła odpowiedź i wraca do oczekiwania. Problem powstaje gdy przetwarzanie zajmuje dużo czasu i w tym czasie serwer nie może obsługiwać innego klienta równolegle. Dlatego częściej używany jest serwer konkurentny, który również czeka na połączenie klienta, ale po nadejściu połączenia uruchamia nowy proces serwera np. w nowym wątku, i ten nowy proces obsługuje klienta bez blokowania oryginalnego serwera. Po zakończeniu przetwarzania i wysłaniu odpowiedzi dodatkowy program zostaje zakończony. Generalnie uważa się, że serwery TCP są konkurentne, a serwery UDP iteracyjne, jednak istnieją od tej zasady wyjątki [Bishop i inni 2005] Telnet Wśród rozlicznych usług, które mogą być realizowane w sieciach opartych na protokole TCP/IP, jedną z najbardziej elementarnych i podstawowych jest Telnet [Postel, Reynolds 1983]. Technicznie jest to najprostsza z usług sieciowych: służy do nawiązania interaktywnego połączenia terminalowego ze wskazanym komputerem, a dokładniej z programem - serwerem udostępniającym usługę opartą na protokole o nazwie Telnet, pracującym na tym komputerze. Po nawiązaniu takiego połączenia znaki wpisywane na klawiaturze naszego komputera przesyłane są poprzez sieć do maszyny, z którą jesteśmy połączeni, a przesyłane w odwrotną stronę odpowiedzi wyświetlane są na naszym ekranie. Można w ten sposób wydawać komendy komputerowi na którym jesteśmy zalogowani poprzez linię poleceń, bez konieczności dostępu do klawiatury czy monitora tego zdalnego serwera. Nawiązanie połączenia przez telnet na zdecydowanej większości komputerów uruchamia zwykłą procedurę identyfikacji (logowania) użytkownika. W przypadku jej pomyślnego zakończenia następuje otwarcie normalnej sesji w systemie operacyjnym, tak jakbyśmy siedzieli przy terminalu podłączonym bezpośrednio do komputera, z którym się 12

13 Przegląd istniejących metod sieciowego udostępniania i kontroli danych łączymy. Telnet pozwala zatem na zdalną pracę na dowolnym komputerze w sieci, pod warunkiem posiadania na nim konta, czyli swego rodzaju bycie w miejscu, w którym nas fizycznie nie ma. Jest to oczywiście możliwe tylko w przypadku komputerów z wielodostępnymi systemami operacyjnymi, dostosowanymi do pracy z terminalami, jak np. UNIX, Linux, FreeBSD. Nie jest możliwe nawiązanie połączenia telnetowego z komputerem pracującym pod nadzorem systemu, który nie jest wielodostępnym, jak np. MS-DOS, lub z systemem nie obsługującym terminali, jak serwer sieci Novell Netware - chyba że zostało zainstalowane jakieś specjalne oprogramowanie działające jako serwer telnetu, ale nawet w tym przypadku efekt połączenia telnetowego może dalece się różnić od normalnej pracy w systemie operacyjnym. Dodatkową zaletą pracy zdalnej przy użyciu terminala jest możliwość "uśpienia" procesu programu i wznowieniu go potem "w tle". Operacja ta polega na programowym odłączeniu procesu od aktualnie używanej powłoki shell. Dzięki temu możliwe jest wylogowanie się z systemu zdalnego lub nawet wyłączenie komputera klienta, bez zatrzymywania programu uruchomionego na serwerze. Po pewnym czasie użytkownik może ponownie się zalogować i sprawdzić status procesu który uruchomił lub efekty jego działania. Dodatkowo można nawet przywrócić pozostawiony proces do nowej powłoki, jeżeli do uruchomienia w tle został użyty program screen FTP (File Transfer Protocol) File Transfer Protocol, jest to protokół umożliwiający przesyłanie plików poprzez sieć Internet. Aby możliwe było przesyłanie plików za pomocą tego protokołu, jeden komputer musi pełnić funkcję serwera FTP. Co pozwala użytkownikowi, na drugim komputerze uruchomić program klienta FTP, za pomocą którego loguje się do serwera. Teraz możliwe jest już przesyłanie plików w dwie strony. Użytkownik nie zawsze jednak ma dostęp do wszystkich plików na serwerze; zależy to od uprawnień, jakie mu przysługują. Popularną usługą jest także anonimowe FTP, dzięki któremu użytkownik może się zalogować do komputera, na którym nie ma żadnych praw dostępu. Wówczas jako nazwę użytkownika podaje "anonymous", hasłem zaś jest jego adres . Użytkownik ma wtedy możliwość korzystania z wybranych zasobów serwera bez posiadania specjalnego konta użytkownika. Taki anonimowy dostęp pozwala użytkownikowi na korzystanie z materiałów publicznych, które chcemy rozpowszechnić w jak najszerszym kręgu ludzi. 13

14 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Charakterystyczną cechą protokołu FTP jest użycie dwóch połączeń do wymiany danych. Jedno połączenie control connection służy komunikacji pomiędzy interpreterem protokołu (PI) użytkownika i serwera, w celu wymiany komend i odpowiedzi. Natomiast data connection jest połączeniem full-duplex przez które przesyłane są żądane dane. Może to być część pliku, cały plik lub wiele plików w zależności od przesłanych komend. Za obsługę tego połączenia odpowiada osobny proces data transport process (DTP) [Postel, Reynolds 1985] / \ User Interface <---> User \----^----/ /------\ FTP Commands /----V----\ Server < > User PI FTP Replies PI \--^---/ \----^----/ /--V---\ Data /----V----\ File <---> Server < > User <---> File System DTP Connection DTP System \------/ \ / Server-FTP USER-FTP Rys Połączenie podstawowe przy użyciu protokołu FTP. Osobne połączenie do wydawania komend i osobne do przesyłania danych [Postel, Reynolds 1985]. Można sobie wyobrazić inną sytuację, kiedy użytkownik zapragnie przesłać dane pomiędzy dwoma serwerami FTP bez użycia własnego komputera. W tym przypadku klient ustanawia połączenie kontrolne pomiędzy dwoma serwerami i wysyła żądanie, ażeby te serwery ustanowiły połączenie data między sobą. Control Control > User-FTP < User-PI "C" V V Server-FTP Data Connection Server-FTP "A" < > "B" Port (A) Port (B) Rys Połączenie podstawowe przy użyciu protokołu FTP. Połączenie kontrolne użytkownika do dwóch serwerów, a połączenie danych bezpośrednie między serwerami [Postel, Reynolds 1985]. 14

15 Przegląd istniejących metod sieciowego udostępniania i kontroli danych W takim przypadku obydwa serwery komunikują się z interpreterem protokołu klienta, którego połączenie nie musi być szybkie, lecz musi zostać aktywne podczas całego procesu. Poza wydawaniem komend dane przesyłane są między dwoma serwerami bez udziału klienta. Taka odmiana protokołu FTP nazywana jest powszechnie FXP. Istnieje jeszcze jedno rozwinięcie układu użytkownik - FTP i ma miejsce najczęściej wtedy, gdy połączenie klienta z interesującym go serwerem zawierającym dane jest powolne lub mimo stosunkowo szybkiego łącza ilość danych jest tak duża, że nie chce on używać do transmisji bezpośrednio swojego komputera, który by w tym czasie musiał działać w sposób ciągły. Do takich długotrwałych transferów, lub ich przyspieszenia poprzez transfer miedzy dwoma serwerami, może być wykorzystana, opisana poniżej, metoda pracy zdalnej połączona z transferem. Metoda ta może być poniekąd kontrowersyjna, jednak w wielu przypadkach pozostaje bardzo pomocną. Realizacja tej metody przebiega w następujący sposób: klient za pomocą programu emulującego terminal np. telnet łączy się z serwerem, na którym ma dostęp z poziomu użytkownika. Połączenie to może być nazwane połączeniem kontrolnym, a do jego zrealizowania nie jest potrzebna duża szybkość transmisji, ponieważ służy ono tylko do wydawania poleceń. Klient po zalogowaniu się na serwerze może, z poziomu użytkownika, uruchomić program do obsługi transmisji danych np. ftp udostępniony na serwerze i za jego pomocą połączyć się z serwera na serwer posiadający interesujące klienta dane. Procedura podczas połączenia przebiega tak jak w pierwszym przykładzie, z tą różnicą, że dane nie są przesyłane na komputer klienta, tylko na serwer którego jest użytkownikiem. Użyteczność tej metody jest nieco ograniczona, jednak w niektórych przypadkach nieoceniona. Do takich przypadków zaliczyć można sytuację, w której użytkownik ma powolne łącze w swoim komputerze, ale ma możliwość periodycznego dostępu do serwera, czy to fizycznego lub z wykorzystaniem szybkiej sieci lokalnej. Wówczas może szybko pobrać dane które zgromadził przez pewien okres. Z doświadczenia wynika że protokół FTP sprawuje się bardzo dobrze jeżeli przesyłane pliki nie są zbyt małe. Wynika to z faktu, że rozpoczęcie transferu poprzez połączenie danych ma pewne opóźnienie po wydaniu komendy przez program użytkownika, a co za tym idzie, w przypadku dużej ilości małych plików znaczna ilość czasu tracona jest na wydawanie komend. 15

16 Przegląd istniejących metod sieciowego udostępniania i kontroli danych HTTP (HyperText Transfer Protocol) Chyba najbardziej spopularyzowanym sposobem realizowania połączenia klientserwer jest udostępnianie danych przy pomocy protokołu HTTP z wykorzystaniem graficznych przeglądarek internetowych. Sposób ten charakteryzuje się dostateczną elastycznością i szybkością, które są niezbędne do obsługi rozproszonego systemu informacji hipermedialnych. Jest to ogólny i zorientowany obiektowo protokół, który może być wykorzystywany do wielu zadań, takich jak zarządzanie serwerami nazw lub systemami obiektów rozproszonych, a to dzięki rozszerzeniu jego zestawu instrukcji. Kiedy użytkownik uruchomi swoją przeglądarkę i wprowadzi nazwę serwera lub jego adres IP, następuje poszukiwanie właściwego miejsca w sieci (korporacyjnej lub w Internecie, zależnie od uzyskanego połączenia) [Fielding i inni 1999]. Po jego odnalezieniu nawiązywana jest komunikacja z wybranym serwerem. Rys Komunikacja pomiędzy przeglądarką a serwerem HTTP. Klient (przeglądarka) zgłasza żądanie dostępu do serwera, a ten w odpowiedzi przesyła informacje w formacie HTML. Przeglądarka klienta odpowiednio je interpretuje i obrazuje. Cały proces jest enkapsulowany w poszczególnych warstwach [Kristol, Montulli 1997]. HTTP to protokół sterujący, odpowiedzialny za ustanowienie połączenia pomiędzy klientem a serwerem i przekazujący instrukcje pomiędzy tymi systemami. HTML jest językiem formatującym dokumenty, które w odpowiedni sposób interpretowane są przez przeglądarkę, a następnie wyświetlane na monitorze. 16

17 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Każde zapytanie (żądanie) klienta (czyli przeglądarki) składa się z trzech części: linii zapytania (klient: polecenie method, adres dokumentu i wersja protokołu HTTP; serwer: wersja protokołu HTTP, kod stanu serwera, opisujący m.in. informację czy dana strona istnieje, czy nie i opis, listy nagłówków (klient: opcjonalne powiadomienie serwera m.in. o tym, jakie rodzaje dokumentów potrafi obsłużyć przeglądarka, typ przeglądarki itp.; serwer: dane dotyczące serwera i dokumentu), części zasadniczej (klient: informacje dodatkowe wykorzystywane przez serwer np. podczas wykonywania skryptów CGI; serwer: treść dokumentu, wynik działania skryptu CGI bądź, w wypadku gdy żądany dokument nie istnieje, bądź skrypt nie może być wykonany, czytelną informację o zaistniałym błędzie). HTTP jest protokołem bezstanowym, co oznacza że serwer nie może wysyłać zapytań do klienta [Kristol, Montulli 1997]. W zasadzie po zapytaniu klienta i pobraniu danych połączenie jest przerywane. Jest to poniekąd pożądane ze względów bezpieczeństwa, ale jednocześnie jest wadą pod względem wygody użytkowania. Serwer mogąc pobrać informacje ze strony klienta mógłby w lepszy sposób automatycznie reagować na zapytania, niestety odbywałoby sie to kosztem prywatności. Ze względu na tą cechę powstały odrębne mechanizmy pozwalające na wysyłanie informacji, których potrzebuje serwer, a o których nie wie przeglądarka użytkownika. Przykładem takim mogą być tzw. cookies, które są małymi plikami pobieranymi bez naszej wiedzy z serwera a następnie, przy kolejnym połączeniu z tą samą witryną, są odsyłane zawarte w nich informacje w postaci niezamierzonego zapytania klienta. W rezultacie chociaż serwer nie może wysłać zapytania do klienta to i tak otrzymuje informacje które potrzebował. Dzięki temu istnieje np. możliwość automatycznego logowania na strony. Innym rozszerzeniem przeglądarek podwyższającym funkcjonalność są aplety Java. Przeglądarka pobiera w trakcie procesu oglądania witryny dedykowany aplet mały program, napisany zazwyczaj w języku Java. Jest on uruchamiany dzięki odpowiedniemu środowisku JRE (Java Runtime Environment). Aplet realizuje połączenie na przykład z bazą serwera, jednocześnie dając możliwość wizualizacji danych na ekranie klienta. Ten sposób publicznego udostępniania danych jest chętnie i szeroko wykorzystywany przez GIS, jako możliwość szybkiego dostępu do np. obrazów satelitarnych, w bardzo krótkim czasie po ich pozyskaniu z satelity. 17

18 Przegląd istniejących metod sieciowego udostępniania i kontroli danych SMTP (Simple Mail Transfer Protocol), POP3 (Post Office Protocol), IMAP (Internet Message Protocol Access) SMTP to protokół komunikacyjny opisujący sposób przekazywania poczty elektronicznej w internecie. SMTP to względnie prosty, tekstowy protokół, w którym określa się co najmniej jednego odbiorcę wiadomości (w większości przypadków weryfikowane jest jego istnienie), a następnie przekazuje treść wiadomości. Łatwo przetestować serwer SMTP przy użyciu programu telnet. SMTP zaczął być szeroko używany we wczesnych latach osiemdziesiątych dwudziestego wieku. W tamtym okresie było to uzupełnienie protokołu UUCP (Unix to Unix Copy), który lepiej sprawdzał się przy przekazywaniu poczty między maszynami posiadającymi jedynie okresowe połączenie podczas którego pobierał pocztę [Kleisin 2001]. SMTP natomiast zaprojektowany jest tak, że najlepiej działa, gdy zarówno maszyna nadająca jak i odbierająca są na stałe przyłączone do sieci, co dodatkowo zmniejsza opóźnienie w dostarczeniu wiadomości do odbiorcy. Charakterystyka tej usługi opiera się na ciągłym nasłuchiwaniu na określonym porcie (zazwyczaj 25) na nadchodzącą pocztę. W przypadku nadejścia połączenia serwer używa protokołu aby odebrać wiadomość, a następnie po ewentualnej dodatkowej weryfikacji zapisuje ją w "skrzynce" pocztowej adresata. Oczywiście zapożyczony z języka codziennego termin "skrzynka" (mailbox) nie jest niczym innym, jak zwykłym plikiem przechowywanym na dysku twardym serwera, z nadanym odpowiednim identyfikatorem i prawami dostępu. Dzięki temu zawartość tego pliku może odczytać tylko użytkownik, który jest jego właścicielem. Początkowym problemem był fakt, że protokół SMTP nie radził sobie dobrze z plikami binarnymi, ponieważ stworzony był na potrzeby przesyłania czystego tekstu ASCII. Dlatego w celu kodowania plików binarnych do przesyłu przez SMTP stworzono standardy takie jak MIME [Kleisin i inni 1995]. W dzisiejszych czasach większość serwerów SMTP obsługuje takie rozszerzenia pozwalające przesyłać pliki binarne równie łatwo jak tekst. Jest to jednak obarczone poważna wadą, która wynika z tego, że zakodowany plik binarny znacznie zwiększa swoją objętość. Dlatego przesyłanie plików binarnych poprzez wiadomości należy w miarę możliwości ograniczać, a używać do tego celu np. protokołu FTP. Dodatkowo jednym z ograniczeń pierwotnego SMTP jest brak mechanizmu weryfikacji nadawcy, co ułatwia rozpowszechnianie niepożądanych treści poprzez pocztę elektroniczną (wirusy, spam). Żeby temu zaradzić stworzono rozszerzenie SMTP-AUTH, 18

19 Przegląd istniejących metod sieciowego udostępniania i kontroli danych które jednak jest tylko częściowym rozwiązaniem problemu - ogranicza wykorzystanie serwera wymagającego autoryzacji do zwielokrotniania poczty. Nadal nie istnieje pewna metoda, dzięki której odbiorca autoryzowałby każdego nadawcę - nadawca może "udawać" serwer i wysłać dowolny komunikat do dowolnego odbiorcy. Oczywiście istnieją dodatkowe techniki zapobiegania procederowi uprawianego przez osoby rozsyłające spam. Głównie specjalne programy uruchomione w miejsce usługi SMTP i sprawdzające pocztę przed przekazaniem go do programu dostarczającego pocztę. Metody filtrowania niechcianej poczty z reguły opierają się na tzw. białych i czarnych listach, zawierających serwery lub użytkowników od których chcemy lub nie chcemy dostawać poczty, lub na statystycznej ocenie treści listu metodą Bayes w oparciu o wcześniej wykonane próbki listów "dobrych" i "złych". Ponieważ protokół SMTP z praktycznych względów nie pozwala na pobieranie wiadomości ze zdalnego serwera, dlatego do obsługi ruchu poczty w drugą stronę powstały protokoły POP3 i IMAP, które mogą działać zamiennie. POP3 to protokół internetowy z warstwy aplikacji pozwalający na odbiór poczty elektronicznej ze zdalnego serwera do lokalnego komputera poprzez połączenie TCP/IP. Ogromna większość współczesnych internautów korzysta z POP3 do odbioru poczty. Wcześniejsze wersje protokołu POP zostały całkowicie zastąpione przez POP3. Zwykle jeżeli ktoś mówi o protokole POP ma na myśli jego wersję 3 [Myers, Rose 1996]. Protokół POP3, w przeciwieństwie do SMTP, który służy do wymiany poczty między serwerami z reguły cały czas dostępnymi w sieci, powstał z myślą o użytkownikach, którzy nie posiadają możliwości utrzymywania ciągłego połączenia z Internetem. Jeżeli ktoś łączy się z siecią tylko na chwilę, to poczta nie może dotrzeć do niego protokołem SMTP, ze względu na charakterystykę opisaną powyżej. Kiedy użytkownik połączy się z siecią, to korzystając z POP3 może pobrać czekające na niego listy do lokalnego komputera. Jednak protokół ten ma wiele ograniczeń: połączenie trwa tylko, jeżeli użytkownik pobiera pocztę i nie może pozostać ono uśpione, do jednej skrzynki może podłączyć się tylko jeden klient równocześnie, każdy list musi być pobierany razem z załącznikami i żadnej jego części nie można pominąć, wszystkie odbierane listy trafiają do jednej skrzynki, serwer POP3 nie potrafi sam przeszukiwać czekających w kolejce listów. 19

20 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Komunikacja między klientem pocztowym, a serwerem odbywa się za pomocą zestawu czteroliterowych poleceń, stanowiących trzon protokołu, które przesyłane są w postaci tekstowej. Ze względu na te ograniczenia powstał bardziej zaawansowany protokół IMAP, i chociaż końcowy efekt jego użycia jest taki sam jak protokołu POP3, to posiada on dodatkowe użyteczne funkcje. Podstawową jest możliwość przeglądania czekających listów, na podobieństwo plików w katalogach, w innej kolejności niż przybyły na serwer. Dzięki temu możemy, przed pobraniem treści listu, skasować te listy których nie chcemy pobierać. Oprócz tego IMAP posiada niektóre funkcje pominięte w POP3 [Crispin 2003]. Programy służące do pobierania poczty lokalnie (jak i serwery) najczęściej obsługują oba protokoły, ale z niejasnych powodów POP3 jest bardziej popularny. Jednak dzięki swym możliwościom IMAP jest głównym protokołem używanym do stosunkowo nowej, lecz bardzo popularnej usługi, jaką jest przeglądanie poczty przy pomocy protokołu HTTP i przeglądarki internetowej DNS (Domain Name Server) DNS działa w oparciu o sieć serwerów nazw (name server) przechowujących i przesyłających między sobą dane adresowe. Każdy komputer dołączany do sieci Internet, czy to łączem stałym, czy komutowanym (telefonicznym), musi korzystać z przynajmniej jednej usługi serwera nazw, ażeby wpisywane np:. w przeglądarkach adresy internetowe działały poprawnie. Serwery nazw zawierają dane o pewnej części całej przestrzeni adresowej DNS (DNS namespace). Dane z każdej domeny w postaci odpowiednich plików stref są zawsze przechowywane na co najmniej dwóch serwerach. Jeden z nich tzw. podstawowy serwer nazw (primary name serwer) jest autorytatywnym źródłem informacji o danej domenie. Pozostałe (co najmniej jeden, a najlepiej kilka) to serwery wtórne (secondary), które przechowują kopię zawartości serwera podstawowego. Istnienie kilku serwerów wtórnych dla danej domeny jest ważne, ponieważ zwiększa to niezawodność i odporność całego systemu na awarie. Typowy komputer podłączony do sieci komunikuje się z systemem DNS wysyłając zapytanie do serwera, który jest podany jako jego serwer nazw i oczekując na odpowiedź. Zapytanie to polega na wysłaniu nazwy jawnej np. fotogrametria.agh.edu.pl, 20

21 Przegląd istniejących metod sieciowego udostępniania i kontroli danych natomiast w odpowiedzi serwer DNS przysyła adres IP który odpowiada danej nazwie. Większość serwerów, właściwie wszystkie z jakimi mogą mieć do czynienia zwykli użytkownicy, działa w sposób rekurencyjny. Oznacza to, że serwery te po otrzymaniu zapytania realizują odpowiednią sekwencję zapytań do innych serwerów i zwracają odpowiedź pozytywną - znaleziony adres, albo negatywną - nie ma maszyny o takiej nazwie. shaman@fotos:~$ dig fotogrametria.agh.edu.pl ; <<>> DiG <<>> fotogrametria.agh.edu.pl ;; global options: printcmd ;; Got answer: ;; >>HEADER<< opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;fotogrametria.agh.edu.pl. IN A ;; ANSWER SECTION: fotogrametria.agh.edu.pl IN A ;; AUTHORITY SECTION: fotogrametria.agh.edu.pl IN NS galaxy.uci.agh.edu.pl. fotogrametria.agh.edu.pl IN NS fotos.fotogrametria.agh.edu.pl. ;; ADDITIONAL SECTION: fotos.fotogrametria.agh.edu.pl IN A galaxy.uci.agh.edu.pl IN A ;; Query time: 25 msec ;; SERVER: #53( ) ;; WHEN: Mon May 22 21:31: ;; MSG SIZE rcvd: 135 Rys Przykładowe zapytanie wydane poleceniem dig i odpowiedź serwera nazw DNS. Część serwerów zwłaszcza te, które obsługują domeny znajdujące się wysoko w hierarchii przestrzeni nazw, to serwery nierekurencyjne. Serwer taki nie podaje ostatecznej odpowiedzi na zapytanie. Odsyła jedynie do innego serwera, który może dać odpowiedź. Oprogramowanie po stronie klienta zazwyczaj wykorzystywane w stacjach roboczych i komputerach osobistych nie może korzystać bezpośrednio z usług serwerów nierekurencyjnych. Raz dana odpowiedź jest przez pewien czas przechowywana w pamięci podręcznej serwera i przy ponownym zapytaniu o ten sam adres serwer podaje go nie 21

22 Przegląd istniejących metod sieciowego udostępniania i kontroli danych komunikując się z innymi. Możliwość buforowania (cache) informacji zmniejsza znacznie ruch w sieci i poprawia efektywność działania systemu. W przypadku dużych sieci lokalnych korzystne jest uruchamianie serwerów, które nie przechowują informacji o żadnej domenie, a tylko buforują wielokrotnie ponawiane zapytania. Wskazane jest umieszczanie buforującego serwera nazw w każdej gałęzi sieci lokalnej, z której wychodzi się do Internetu i skonfigurowaniu wszystkich stacji roboczych w tej sieci tak, aby był ich podstawowym serwerem DNS. Operacja taka pozwala na znaczne zmniejszenie niepotrzebnego ruchu, który byłby generowany w sieci WAN w przypadku braku obecności takiego serwera Protokoły szyfrowane Wszystkie przedstawione do tej pory protokoły miały podstawową poważną wadę. Mianowicie informacje przekazywane przez nie poprzez sieć heterogeniczną przesyłane są w postaci jawnej, czyli np. wysyłając pewien tekstowy plik istnieje pewne prawdopodobieństwo, że osoba postronna będzie mogła "podsłuchać" transmisję i zapoznać się z jej treścią bez naszej wiedzy i zgody. Nie ma to znaczenia jeżeli przesyłamy mało ważne lub publiczne dostępne informacje np. pobierając prognozę pogody z jednego z serwisów. Jednak sytuacja drastycznie się zmienia jeżeli te informacje są poufne. W najbardziej powszechnym przypadku ma to miejsce, gdy na przykład podajemy swój login i hasło, aby przeczytać pocztę poprzez interfejs WWW lub wykonać przelew w banku internetowym. Jeszcze gorsza sytuacja istnieje gdy używamy np. klienta poczty typu Outlook, który automatycznie zapamiętuje nasze hasło i łączy się co kilka minut z serwerem POP3, w celu sprawdzenia czy nie nadeszła nowa wiadomość. Część użytkowników nie zdaje sobie sprawy, że mimo iż nie podajemy żadnych informacji świadomie to w rezultacie nasz login i hasło wysyłane są co kilka minut jako zwykły tekst ASCII do serwera, i ktokolwiek chcący naruszyć naszą prywatność może to wykorzystać. Dlatego w celu podwyższenia bezpieczeństwa każdy z wymienionych poprzednio protokołów ma odpowiednik w postaci protokołu szyfrowanego, a ściślej mówiąc dodatkowej warstwy aplikacji, która enkapsuluje w sobie zwykły protokół. Czyli znajduje się pomiędzy standardową warstwą aplikacji a stosem TCP/IP. Generalnie w codziennym użyciu są trzy najbardziej popularne protokoły enkrypcji: SSL (Secure Socket Layer), SSH (Secure Shell) i PGP (Pretty Good Privacy). Wszystkie mają możliwość korzystania z klucza asymetrycznego do enkrypcji danych. W skrócie taki klucz charakteryzuje 22

23 Przegląd istniejących metod sieciowego udostępniania i kontroli danych podział na dwie części, publiczną i prywatną. Idea takiego rozwiązania polega na tym, że informacja zaszyfrowana jedną częścią klucza może zostać odkodowana tylko jego drugą połową. Do większości protokołów stosuje się SSL który doczekał się wersji trzeciej implementacji i rozwijany jest dalej pod nazwą TLS (Transport Layer Security) [Allen, Dierks 1999]. Dla odróżnienia od zwykłych protokołów przyjęło się nazewnictwo polegające na dodaniu litery S do nazwy zwykłego protokołu. W ten sposób otrzymujemy szyfrowane protokoły FTPS, HTTPS, POP3S, SMTPS itp. Protokoły te, jako takie, działają w taki sam sposób jak zwykłe ich odpowiedniki ponieważ warstwa TLS jest dla nich przeźroczysta. Istnieje jedna różnica, że jak już wspomniano, dane przechodzą przez dodatkową warstwę enkrypcji a następnie po stronie odbiorcy są dekryptowane. SSL jest protokołem służącym do wymiany danych spełniającym trzy warunki ochrony informacji: integralność informacji, uwierzytelnianie oraz poufność, jednak nie spełnia on zasady niezaprzeczalności. Spełnia swoją funkcję dzięki bezpiecznej wymianie kluczy pomiędzy klientem i serwerem. Składa się z dwóch warstw: TLS Record i TLS Handshake. Niższa warstwa rekordu gwarantuje bezpieczeństwo, korzystając z unikalnych kluczy symetrycznych generowanych dla każdego połączenia, bazując na prywatnych częściach klucza stron, przy użyciu jednego z algorytmów enkrypcji np.: DES, 3DES, RC5 itp. Po ustanowieniu takiego bezpiecznego połączenia druga warstwa "uścisku dłoni" może autoryzować każdą ze stron, uzgodnić algorytmy i klucze zanim warstwa aplikacji zacznie przesyłanie danych. Jak można łatwo zauważyć w nazwach bezpiecznych protokołów nie występuje nazwa "TelnetS". Jest to pominięcie celowe, ponieważ nie używa sie takiej nazwy w globalnie przyjętych standardach. A to dlatego że do połączenia zdalnego terminala w trybie szyfrowanym używany jest specjalny protokół SSH. Dlaczego nie można używać też SSL? Ależ można, lecz wiązałoby się to z kilkoma niedogodnościami, a SSH jest gotowym sposobem na realizację tego typu połączeń. SSH składa się z trzech warstw od najniższej do najwyższej: transportu (SSHTRANS), autentykacji użytkownika (SSH-USERAUTH) i protokołu połączeń (SSHCONNECT) [Lonvick, Ylonen 2006]. Gdy połączenie poprzez warstwę transportu zostanie ustanowione, klient wysyła żądanie udostępnienia usługi poprzez warstwę autoryzacji. Jeżeli operacje te zostaną zakończone sukcesem następuje udostępnienie kanału pozwalającego na szereg zastosowań. Jednym jest oczywiście praca w terminalu. Jednak siła protokołu SSH tkwi w możliwości kreowania tzw. tuneli poprzez ustanowione połączenie. Dzięki temu mechanizmowi można w najprostszy sposób zamapować zdalne 23

24 Przegląd istniejących metod sieciowego udostępniania i kontroli danych porty na innym komputerze, tak jak byłyby to jego własne. Czyli w dowolny sposób możliwe jest przekierowanie jakiegokolwiek protokołu poprzez bezpieczny kanał na dowolny inny komputer Trzecim wspomnianym protokołem szyfrującym jest PGP. Różni się znacząco od poprzedników tym, że nie działa standardowo jako warstwa sieciowa. Również korzysta z par kluczy, jednak jego celem jest zaszyfrowanie całego pliku przed wysłaniem. Ma on zastosowanie głownie do prywatnej korespondencji , gdzie tzw. prywatna część klucza jest dostępna wyłącznie autorowi wiadomości pocztowej. Natomiast publiczna część jest rozpowszechniana w dowolny sposób. W wyniku, wysłany i zaszyfrowany do osoby, która otrzymała publiczną część klucza będzie mógł być odszyfrowany. Dzięki temu odbiorca będzie miał pewność, że wiadomość którą otrzymał z pewnością została nadana poprzez konkretnego adresata. Dodatkowo jeżeli nadawca przekaże część publiczną klucza tylko wybranej grupie osób, będzie miał pewność, że jego korespondencja nie zostanie odczytana poprzez osoby postronne Przykłady wykorzystania protokołów sieciowych do udostępniania danych geoinformacyjnych Ze względu na coraz większą dostępność i popularność Internetu w ostatnich latach powstało kilka projektów związanych z udostępnianiem geoinformacji, w szczególności obrazowych, poprzez sieć komputerową. Można wskazać na wiele czynników, które w mniejszy lub większy sposób przyczyniły się do tego stanu rzeczy. Za czynniki pośrednie można uznać: rozwój technologiczny - obniżenie kosztów sprzętu komputerowego przy zwiększonej wydajności, rozwój software - duża liczba darmowych programów ogólnie dostępnych do użytku, rozwój intelektualny - coraz większa grupa ludzi zainteresowana technologiami Internetu promowanego w wyraźny sposób przez inne media. Natomiast jako czynniki bezpośrednie związane ściśle z profilem działalności osób związanych z geoinformatyką można wymienić: 24

25 Przegląd istniejących metod sieciowego udostępniania i kontroli danych niższe koszty dystrybucji grafiki poprzez sieć niż w tradycyjnej formie papierowej mapy, mniejszy nakład czasu potrzebny do dostarczenia materiałów, możliwość częstszych aktualizacji, interaktywna możliwość wyboru lokalizacji obszaru na mapie i parametrów z nim związanych. Projekty te najczęściej mają postać apletów uruchamianych poprzez przeglądarkę WWW z odwołaniem do bazy znajdującej się na serwerze. Rozwiązania takie posiadają swoje walory użytkowe, jednak są wykonane metodami powodującymi centralizację dostępu do danych przeglądarka musi połączyć się z odległym serwerem, przez co użytkownik musi dłużej czekać na pobranie obrazu niżby to miało miejsce w przypadku serwera lokalnego. Ponadto centralizacja powoduje mniejsze możliwości dowolnego rozszerzania pojemności bazy obrazów, ze względu na fizyczne ograniczenia sprzętu wykorzystanego jako serwer. Kolejnym mankamentem jest dyskusyjna niezawodność takiej metody: w przypadku awarii serwera dane, które na nim się znajdowały, nie będą dostępne. Dodatkowo część rozwiązań oparta jest na oprogramowaniu komercyjnym o zamkniętym kodzie źródłowym. Narzędzia te są może trochę łatwiejsze w obsłudze i grają pierwsze skrzypce w świetle idei RAD (Rapid Application Development), jednak w przypadku stagnacji tego oprogramowania może okazać się, że nie będzie możliwy rozwój a nawet kontynuacja danego projektu SZDF - System Zarządzania Danymi Fotogrametrycznymi Jednym z większych projektów działających w Polsce w zakresie udostępniania danych obrazowych jest System Zarządzania Danymi Fotogrametrycznymi przedstawiony na stronie internetowej CODGiK w Warszawie [CODGiK 2006b]. Jest to rozwiązanie komercyjne, którego zamierzeniem jest archiwizacja danych i ich eksploatacja w szybszy sposób niż to ma miejsce w przypadku tradycyjnych zasobów, dzięki udostępnieniu zdjęć i ortofotomap drogą internetową. W zasobach CODGiK znajdują się zdjęcia lotnicze wykonane w skali 1:13000 pokrywające łącznie ponad 14 tys. km2 powierzchni kraju, które zostały wykonane w latach Oprócz tego w bazie SZDF znalazły się zdjęcia wykonane w ramach projektu PHARE 2001 wykonane w skali 1:

26 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Rys Pokrycie Polski zdjęciami 1:13000 i 1:26000 w zasobach SZDF [CODGiK 2006a]. Dodatkowo system udostępnia zbiór ortofotomap, które dostępne są w kilku standardach. Pierwszy standard, zakładający piksel terenowy ortofotomapy 0.5-1m i błąd RMSE m, jest tworzony w oparciu o zdjęcia w skali 1:26000, oraz o obrazy satelitarne IKONOS2. Natomiast drugi rodzaj, o rozmiarze piksela 0.25m i błędzie RMSE 0.75m, wykonywany jest ze zdjęć o dwukrotnie większej skali [CODGiK 2006a]. Rys Ortofotomapy znajdujące sie w zasobach SZDF [CODGiK 2006a]. 26

27 Przegląd istniejących metod sieciowego udostępniania i kontroli danych System SZDF zbudowany jest w oparciu o komercyjny produkt firmy Z/I Imaging o nazwie TerraShare, który jest kompleksowym rozwiązaniem przeznaczonym do zarządzania i udostępniania danych obrazowych oraz komplementarnego numerycznecgo modeleu terenu. System składa się z kilku elementów dostarczanych przez firmę Intergraph: - TerraShare Server, który spełnia funkcję serwera usług, działający na tradycyjnej zasadzie client-server i oparty na bibliotece Microsoft COM+. Serwer zarządza danymi geoprzestrzennymi i metadanymi, korzystając z jednej z relacyjnych baz danych: Oracle lub MS SQL Server, - TerraShare Client, który działa jako rozszerzenie programu MS Explorer i odpowiada za interakcję z użytkownikiem systemu, w tym za selekcję i wizualizację danych, - TerraShare Raster odpowiada za przetwarzanie danych obrazowych, przeprowadza mozaikowanie i transformację danych do aktualnej projekcji w oprogramowaniu klienta, - TerraShare Production Manager integruje zarządzanie i automatyzację wszystkich procesów, - TerraShare Advanced Server, który jest rozszerzeniem serwera podstawowego i pozwala na przetwarzanie danych rozproszonych. Rys Schemat blokowy systemu TerraShare [Intergraph 2006]. Jak widać z opisu, system TerraShare jest kompletnym rozwiązaniem służącym do szybkiego wdrożenia idei udostępniania danych obrazowych. Znajdują się w nim 27

28 Przegląd istniejących metod sieciowego udostępniania i kontroli danych standardowe moduły serwera, klienta i modułu do przetwarzania. Oprócz tego posiada istotny element, którym jest moduł do przetwarzania danych z użyciem clustra komputerowego i pozwala na rozłożenie obciążenia wynikającego z automatycznej obróbki danych rastrowych [Long, Madani 2005]. Jednak przy całym splendorze tego rozwiązania nieuchronnie wyłania się jego podstawowa wada: w aktualnej postaci ograniczenie tylko i wyłącznie do jednego systemu operacyjnego. Pod względem atrakcyjności użytkowania systemu oczywiście najbardziej obciążone tą wadą jest oprogramowanie klienckie systemu. Bo, o ile rozwiązania stojące za kurtyną "użytkowych fajerwerków" można w tej kwestii pominąć i stwierdzić, że kreator systemu powinien mieć wolny wybór w kwestii oprogramowania, to z drugiej strony użytkownik takiego systemu nie powinien być zmuszany do korzystania z określonego systemu operacyjnego. Tymczasem silne powiązanie oprogramowania klienta z Eksploratorem Windows powoduje brak jakiejkolwiek możliwości wykonania programu w innych systemach operacyjnych. Dodatkowo oprogramowanie to instaluje się stosując mechanizm kontrolek ActiveX, który jest kolejnym produktem z Redmond będącym poważnym zagrożeniem bezpieczeństwa dla komputera użytkownika, zwłaszcza przy obecnej rosnącej wrogości Internetu, Jednym z bardziej interesujących modułów systemu jest TS Advanced Server pozwalający na przetwarzanie rozproszone. Idea ta jest znana od pewnego czasu, chyba najbardziej rozpowszechniona przez program SETI@home (Search Extra Terrestrial Inteligence) [SETI 2006] i jest niewątpliwie kolejnym krokiem w kierunku rozwoju technologicznego. System przetwarzania rozproszonego pozwala na rozdzielenie czasu pracy na procesory wielu komputerów tworzących klaster. Odbywa się to przy użyciu odpowiedniego oprogramowania, tak jak to ma miejsce w tym przypadku TS Advanced Server. Rozwiązanie to niewątpliwie podąża za trendami nowoczesnej koncepcji współpracy komputerowej, a materiały reklamowe i publikacje firmy przedstawiają zalety proponowanego rozwiązania, które bezsprzecznie stanowi element znacznie podnoszący wydajność systemu [Long, Madani 2005]. Jednak, w świetle przedstawionej wcześniej charakterystyki systemu TerraShare, nieuchronnie pojawia się pytanie: skoro zadano sobie trud stworzenia modułu do przetwarzania rozproszonego, aby podwyższyć wydajność rozwiązania, to dlaczego wykorzystano system operacyjny, który działa tylko i wyłącznie z uruchomionym środowiskiem graficznym, które jednocześnie obniża wydajność rozwiązania, a które jest zupełnie niepotrzebne na serwerze dedykowanym automatycznemu przetwarzaniu? 28

29 Przegląd istniejących metod sieciowego udostępniania i kontroli danych System internetowego pomiaru obrazów fotogrametrycznych UWM Olsztyn Bardzo ciekawy system został stworzony w Katedrze Fotogrametrii i Teledetekcji w UWM Olsztyn. Służy do orientacji stereoskopowej pary obrazów przy pomocy apletu Java, uruchamianego w przeglądarce internetowej [Janowski i inni 2001]. Dodatkowo zaproponowany w systemie został dedykowany program napisany w języku Delphi, który realizuje interfejs użytkownika bez użycia przeglądarki [Janowski i inni 2004b]. System pozwala wybrać stereoparę z przedstawionego bloku zdjęć, a następnie wyświetlić fragment zdjęcia z dowolnego poziomu piramidy obrazów. Potem można określić współrzędne pikselowe wybranych punktów homologicznych poprzez dopasowanie automatyczne. Dodatkowo można określić współrzędne pikseli w układzie lokalnym, za pomocą poligonu zaznaczyć obszar, którego powierzchnia zostanie obliczona i wreszcie określić elementy orientacji zewnętrznej pojedynczego zdjęcia [Paszotta 2003]. Użytkownik wskazuje środek obszaru, rozmiar oraz poziom piramidy, aby otrzymać wymagany fragment zdjęcia. Te parametry wraz z identyfikatorem użytkownika wysyłane są do systemu poprzez aplet Java. Wówczas na serwerze generowany jest obraz wraz z parametrami. Ponieważ zgodnie z zasadami protokołu HTTP omawianego w punkcie 2.2.3, serwer nie może wysłać wygenerowanych danych samoistnie, lecz użytkownik musi je pobrać, dlatego przeglądarka otrzymuje tylko informacje, że dane są gotowe. Ze względu na to, że wraz z fragmentem zdjęcia dołączona jest informacja o jego orientacji, dlatego możliwe jest określenie współrzędnych modelu (terenowych) wybranego punktu. Dodatkową funkcją programu interfejsu jest możliwość określenia elementów orientacji zewnętrznej pojedynczego zdjęcia na podstawie ortofotomapy i odpowiadającego jej numerycznemu modelowi terenu. Realizacja tego problemu przebiega dwuetapowo. W pierwszym etapie wybieramy 3 pary punktów homologicznych na zdjęciu i na ortofotomapie, a następnie wykorzystujemy je do dwóch równoległych procesów. W pierwszym wykonując orientację wewnętrzną za pomocą transformacji afinicznej wyznaczamy współrzędne tłowe x' i y' z pierwszego zestawu punktów. Jednocześnie korzystając z drugiego zestawu i parametrów ortofotomapy wyznaczamy współrzędne terenowe X i Y drugiego punktu. Dodatkowo przeprowadzamy interpolację korzystając z uzyskanych współrzędnych płaskich i NMT wyznaczając w ten sposób współrzędną Z dla punktu. W drugim etapie wykorzystując uzyskane parametry oraz równanie kolinearności przekształcone do postaci parametrycznej DLT, wyznaczamy współczynniki orientacji 29

30 Przegląd istniejących metod sieciowego udostępniania i kontroli danych zewnętrznej zdjęcia [Paszotta 2003]. W celu sprawdzenia dokładności tej metody możemy z nich skorzystać, ażeby ponownie wykonać model i porównać go z istniejącym. Rys Wygląd interfejsu użytkownika w wersji dedykowanej podczas pracy systemu [Janowski i inni 2004a]. Od strony technicznej projekt używa apletu Java jako interfejs klienta, natomiast zarządzanie zasobami spada na serwlet Tomcat w połączeniu z językiem skryptowym JSP. Te dwa elementy, na podstawie zapytań z serwera Apache, selekcjonują odpowiednie dane z istniejącej bazy danych, opartych na silnikach Oracle i Pradox, w połączeniu z plikami tekstowymi zawierającymi dane z kalibracji kamer oraz elementy orientacji zdjęć. Dodatkowo osobno przechowywane są piramidy obrazów w postaci bitmap. Serwlet na podstawie parametrów określonych przez użytkownika i korzystając z zawartości bazy danych wybiera odpowiedni fragment obrazu z dużych bitmap, a następnie kompresuje je do formatu JPEG, aby maksymalnie zmniejszyć ich rozmiar przed wysłaniem [Janowski i inni 2002]. Po wybraniu odpowiednich danych informacje są przesyłane do interfejsu użytkownika, w przypadku apletu realizacja tego etapu należy do serwera Apache. Schemat tego rozwiązania przedstawiono na rysunku

31 Przegląd istniejących metod sieciowego udostępniania i kontroli danych ba za d any c h g r a fi c z n a p r z e g lą d a r k a W W W [JA V A A P L E T ] p r z e g lą d a r k i w u r z a d z e n ia c h m o b iln y c h [JA V A M ID L E T ] a p lik a c h a d e d y k o w a n a d la W in d o w s [ D E L P H I] [ O r a c le / P a r a d o x /T X T d a n e k a lib r a c ji k a m e r, e le m e n ty o r ie n t a c ji z d ję ć ] z a m a w i a n ie p o b ie r a n ie z a p y t a n ie s e rw e r W W W [A P A C H E ] J A V A s e r w le t o d p o w ie d ź [T O M C A T, J S P ] p ir a m id y z d ję ć [B M P ] Rys Schemat blokowy połączeń w systemie od strony serwera [Janowski i inni 2004a] Geoportal.gov.pl Prawdopodobnie największym w Polsce przedsięwzięciem ostatnich lat w zakresie udostępniania materiałów obrazujących powierzchnię terenu jest projekt o nazwie Geoportal. Celem projektu jest stworzenie cyfrowego repetytorium informacji katastralnej i geograficznej oraz komercyjne udostępnianie tych materiałów za pośrednictwem Internetu [Dygaszewicz 2007]. W zamierzeniu ma on być częścią składową portalu ogólnoeuropejskiego. W obecnej chwili Geoportal nie jest jeszcze ukończony (zakończenie planowane jest na marzec 2008 r.) [Geoportal 2007], lecz posiada możliwość przeglądania zasobów CSD (Centralnej Składnicy Danych) przy pomocy przeglądarki internetowej. Aktualnie z dostępnych na stronie materiałów można przeglądać do wyboru: ortofotomapy, numeryczny model terenu w postaci mapy hipsometrycznej, rastrowe mapy topograficzne, bazę danych ogólnogeograficznych lub wektorową mapę Polski. Przedstawiona na rysunku 2.11 przeglądarka działa na zasadzie skryptu Java, który realizuje funkcję interfejsu. Interfejs po otrzymaniu komend od użytkownika wysyła zapytanie do bazy pobierając odpowiednie dane graficzne do wyświetlenia. Następnie w przypadku bazy danych ogólnogeograficznych, rastrowej mapy topograficznej i mapy wektorowej plik w formacie PNG jest wyświetlany w przeglądarce. Natomiast w przypadku mapy wysokościowej i ortofotomapy wyświetlany obraz jest w formacie JPEG. 31

32 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Rys Przykład wglądu przeglądarki zasobów Geoportalu dla mapy wysokościowej. Zaletą interfejsu jest to, że działa prawdopodobnie w każdej przeglądarce internetowej, bez względu na system operacyjny, pod warunkiem, że przeglądarka obsługuje język skryptów Java. W chwili obecnej warunek ten spełniony jest przez praktycznie każdą współczesną przeglądarkę stron WWW BDO - Baza Danych Ogólnogeograficznych Udostępniana na stronie Centralnego Ośrodka Dokumentacji Geodezyjnej i Kartograficznej Baza Danych Ogólnogeograficznych (BDO) udostępnia dane w skali podstawowej 1: oraz mniejszych skalach (1: , 1: , 1: ). BDO powstała w oparciu o różne materiały źródłowe. Za najistotniejszy uważany jest zasób bazy VMap poziomu 1, który został udostępniony przez Zarząd Geografii Wojskowej Sztabu Generalnego Wojska Polskiego. W skład tematyczny bazy wchodzi podział administracyjny, osadnictwo i obiekty antropogeniczne, hydrografia, rzeźba terenu, transport, pokrycie terenu i użytkowanie ziemi, obszary chronione i nazwy geograficzne. Baza integruje kilka funkcjonujących rejestrów publicznych i innych baz danych, poprzez uwzględnienie stosowanych tam identyfikatorów obiektów przestrzennych. Identyfikatory te wiążą geometrię obiektów z rejestrami. W skład BDO wchodzą rejestry: Krajowego Rejestru Urzędowego Podziału Terytorialnego (TERYT), prowadzonego przez 32

33 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Główny Urząd Statystyczny, Banku Danych Drogowych, prowadzonego przez Generalną Dyrekcję Dróg Krajowych i Autostrad, Komputerowej Mapy Podziału Hydrograficznego Polski, prowadzonej przez Instytut Meteorologii i Gospodarki Wodnej oraz Krajowego Systemu Obszarów Chronionych, prowadzonego przez Ministerstwo Środowiska [CODGiK 2006a]. BDO jest przykładem powiązania serwera, zawierającego kilka typów danych geoinformacyjnych, z programem interfejsu będącym apletem Java i wykonującym się na komputerze użytkownika, po wcześniejszym jego zainstalowaniu. Rys Aplet Java ArcIMS uruchomiony w przeglądarce pozwala na interakcję z danymi graficznymi. Na rysunku 2.12 przedstawiono widok ekranu komputera po uruchomieniu apletu w przeglądarce Firefox. Niestety aktualna wersja apletu w wersji Java2 nie zezwala na instalację oprogramowania przy użyciu tej przeglądarki. Pozostaje więc "jedynie słuszny" produkt znanego producenta okienkowego systemu operacyjnego, pozbawiając tym samym część użytkowników możliwości skorzystania z BDO. 33

34 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Od strony serwera, udostępniającego dane, użytych zostało kilka programów umożliwiających zarządzanie bazą danych. Fizycznie są to dwa komputery: jeden z systemem Windows Serwer a drugi z Linuxem. Serwer Windows odpowiada za obsługę komercyjnego serwera ESRI wraz z ECW, oraz utrzymywanie serwera WEB, który udostępnia usługę sieciową dla apletu interfejsu użytkownika. Może być tym celu wykorzystana standardowa usługa Microsoft Web Server. Zestaw ten połączony jest poprzez sieć z serwerem Linux na którym działa baza danych MySQL zawierająca dodatkowe informacje wymagane dla systemu. Zapytania do tej bazy realizowane są za pomocą interfejsu PHP. Rys Schemat połączenia poszczególnych elementów BDO [CODGiK 2006a]. 34

35 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Małopolska z lotu ptaka Przykładem regionalnego projektu jest system prezentacji map przedstawiony poprzez Wojewódzki Ośrodek Dokumentacji Geodezyjnej i Kartograficznej (WODGiK) w Krakowie. Wizualizację projektu o ogólnej nazwie "Małopolska z lotu ptaka" można zobaczyć pod adresem internetowym podanum w bibliografii [WODGiK 2007]. W zasobach ośrodka, jak sama jego nazwa wskazuje, znajdują się materiały dotyczące województwa małopolskiego, w tym ortofotomapy powstałe ze zdjęć lotniczych, które stanowią grupę najbardziej aktualnych materiałów (najnowsze mapy fotograficzne opracowane w 2003 roku dotyczą kotliny nowotarskiej) [WODGiK 2007]. Największa rozdzielczość zasobów które oferuje ośrodek w przybliżeniu odpowiada mapie w skali 1:10000, co wskazuje na ich zastosowanie głównie w systemach GIS. Rys Ortofotomapa przedstawiona w systemie WODGiK, widoczny fragment Rynku Krakowskiego. Drugim rodzajem zasobów jakie udostępnia ośrodek poprzez system wizualizacji jest, przedstawiona na rysunku 2.15, mapa topograficzna województwa w skali 1: Materiały te pochodzą z lat [WODGiK 2007]. 35

36 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Rys Mapa topograficzna w systemie WODGiK. Ciekawostką, której nie posiadają inne systemy, jest udostępnienie w zasobach systemu wizualizacyjnego mapy historycznej pokazanej na rysunku 2.16, która może posłużyć do studiów nad zmianą zagospodarowania miasta. Rys Mapa historyczna w systemie WODGIK. 36

37 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Dodatkowo system pozwala na wybór obiektów, które następnie pokazuje na mapie. Obiekty te podzielone są na różne kategorie, a w szczególności: muzea, obiekty sakralne, szlaki, zabytki, itp. Tak więc można wykorzystać system podczas planowania wycieczki krajoznawczej lub zwiedzania obiektów zabytkowych, bez konieczności poszukiwania ich na tradycyjnej mapie. Technologia użyta w projekcie systemu nie odbiega znacząco od poprzednich rozwiązań. Główna część przeglądarki oparta jest na wtyczce Adobe Flash Player o nazwie Zoomify, która odpowiada za wizualizację rastrów w okienku mapy. W niej tez zaimplementowane zostały funkcje powiększania i przesuwania obrazu. Natomiast elementy odpowiadające za wybór obiektów powiązane są z bazą danych w której przechowywane są współrzędne tychże obiektów. Zaletą tego rozwiązania jest uniwersalność pod względem użytkowym, ponieważ wspomniana wtyczka Flash współdziała z licznymi przeglądarkami i systemami operacyjnymi. Wadą natomiast to, że pomimo wszystko wtyczka ta jest produktem komercyjnym o zamkniętym źródle, co w przyszłości może się źle skończyć jeżeli firma Adobe zbankrutuje. WODGiK oferuje na swojej stronie również drugie rozwiązanie w postaci bazy danych ogólnogeograficznych, która oparta jest od strony serwera o oprogramowanie Geomedia Web Map, a od strony użytkownika o wtyczkę SVGViewer. Niestety po próbie uruchomienia systemu komunikat o treści "Adobe SVGViewer 3.01 działa obecnie jedynie z Internet Explorerem w wersjach wyższych niż 5.5." efektywnie zneutralizował możliwość przetestowania tego rozwiązania w systemie Linux. Na zakończenie należy jednak wspomnieć fakt, że WODGiK na swojej stronie jako jeden z nielicznych tego typu ośrodków promuje rozwiązania GIS w oparciu o oprogramowanie na licencji GPL. W szczególności wyśmienity pakiet GRASS, który jest kompleksowym narzędziem do analizy geoprzestrzennej, oraz darmowe serwery udostępniania map w internecie: OpenMap, Degree i MapServer [WODGiK 2003]. Nie do końca natomiast można się zgodzić z opisem tych systemów, ogólnie określonych jako aplikacje służące do renderowania obrazu. Chociaż po części jest to prawdą, to należy pamiętać, że pojęcie renderowania rozumie się jako szczególny przypadek generowania obrazu, i najczęściej używane jest do określenia procesu generowania zaawansowanych obrazów w grafice 3D. W szczególności włączając w to efekty odbicia i załamania światła, mgły, cieni, które nie mają zastosowania w płaskiej, z definicji, mapie. Efekty te jednak można potencjalnie wykorzystać np. narzucając treść rastra na trójwymiarowy model terenu po teselacji. 37

38 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Google Earth Projektem o zasięgu globalnym jest Google Earth, który udostępnia obrazy satelitarne i lotnicze pozyskane w ciągu ostatnich trzech lat na terenie całego świata. Materiały te, w miejscach w których zdjęcia pochodzą z satelitów VHRS (Very High Resolution Satellite) lub nalotów fotogrametrycznych, sięgają rozdzielczością poniżej jednego metra na piksel. Ponadto na część powierzchni nałożone zostały modele 3D budynków znajdujących się w tych miejscach. Dodawanie tych modeli dostępne jest dla użytkowników za pośrednictwem programu SketchUp, który również jest udostępniany przez Google [GoogleEarth 2007]. Rys Europa Środkowa w przeglądarce Google Earth. Przedstawiony na rysunku 2.17 program przeglądarki obrazów to dedykowana aplikacja oparta na technologii OpenGL, co pozwala na płynną i szybką wizualizację treści. Obrazy ładowane są do przeglądarki na zasadzie piramidy obrazów, co pozwala na dynamiczną nawigację. Oczywiście powoduje to też efekt "rozmycia obrazu" przy niezbyt szybkim łączu internetowym. Obraz jest wówczas przeskalowany sprzętowo za pomocą szybkiej transformacji, zanim dane na żądanym poziomie szczegółów zdążą zostać załadowane dla interesującego obszaru. 38

39 Przegląd istniejących metod sieciowego udostępniania i kontroli danych Dodatkowymi atutami programu oprócz wizualizacji samych zdjęć jest możliwość nakładania warstw wektorowych np. granic państw lub dróg, a nawet miejsc godnych zwiedzania. Oprócz tego program umożliwia wizualizację obiektów 3D, np. budynków zdefiniowanych wcześniej w innym programie o nazwie SketchUP, stworzonym również przez Google. Ponadto przeglądarka umożliwia projektowanie tras i odtwarzanie ich z ustalonej w programie perspektywy, a także pomiar długości trasy. Rys Widok perspektywiczny Nowego Jorku z włączonymi modelami budynków i zaprojektowaną trasą. Interfejs użytkownika (menu, ikony, paski narzędzi) jest realizowany przy pomocy biblioteki Qt, która jest zaportowana na większość systemów operacyjnych. Dzięki temu oprócz Windows powstały również wersje przeglądarki pod Linux i MacOS. Ze względu na zastosowanie biblioteki OpenGL do wizualizacji wymagana oczywiście jest karta graficzna która obsługuje tą bibliotekę, czyli praktycznie każda karta wyprodukowana po roku Innym aspektem projektu Google Earth jest możliwość korzystania z danych obrazowych we własnej aplikacji Java, w postaci serwletu poprzez który dane przekazywane są do przeglądarki Google Earth [Berg 2005]. Dodatkowo możliwe jest napisanie serwletu w ten sposób, że oprócz danych pobieranych z Google będzie on 39

40 Przegląd istniejących metod sieciowego udostępniania i kontroli danych udostępniał dane znajdujące się na alternatywnym serwerze skonfigurowanym przez nas. Dzięki temu dla wybranych obszarów możemy "podmieniać" obrazy, zastępując te, które znajdują się na serwerze Google i uzyskać w ten sposób np. lepszą rozdzielczość obrazów dla tych obszarów. Przykładem takiego rozwiązania praktycznego może być projekt tworzony na Uniwersytecie Warmińsko-Mazurskim w Olsztynie. W projekcie tym stworzono serwlet, który dla obszaru okolic Olsztyna zastępuje obrazy Google fragmentami obrazów pochodzących z przetworzonych geometrycznie zdjęć satelitarnych Iconos, oraz obrazami udostępnianymi poprzez GlobeXplorer o średniej rozdzielczości piksela terenowego 8 metrów. Następnie obrazy te wyświetlane są w przeglądarce Google Earth, zamiast obrazów oryginalnych, jeżeli wywołamy opracowaną w projekcie lokalizację [Jędryczka 2007]. Oczywiście przy odpowiedniej modyfikacji serwletu i lokalnej bazy danych obrazowych można się spodziewać, że taką samą operację można by było wykonać np. wykorzystując zdjęcia lotnicze o dużo lepszej rozdzielczości Plany miast i mapy samochodowe Jedną z bardzo popularnych form dystrybucji informacji geograficznej stały się liczne plany miast i mapy samochodowe. Najczęściej są one najprostszą implementacją zagadnienia pod względem zarządzania danymi obrazowymi. Rys Prosty przykład planu Krakowa [Plan Krakowa 2006] i mapy samochodowej Polski [Mapa Samochodowa Polski 2006]. Zazwyczaj funkcję tą spełnia skrypt PHP w odpowiedni sposób dzielący duży raster na mniejsze elementy i wyświetlający go w małych kawałkach. Funkcję transportu danych obrazowych przejmuje na siebie serwer WWW np. Apache. Jednak oprócz tego 40

41 Przegląd istniejących metod sieciowego udostępniania i kontroli danych można znaleźć implementacje podające współrzędne georeferencyjne wybranego punktu, mierzące odległości lub szukające najkrótszej drogi [Atlas Polski 2005]. Wówczas praca skryptu wspomagana jest przez silnik bazodanowy, który dostarcza niezbędnych informacji. Rys Przykład bardziej rozbudowanego atlasu Polski [Atlas Polski 2005]. Zasada działania podobnych systemów jest stosunkowo prosta. Klient poprzez przeglądarkę wysyła zapytanie do serwera WWW np. Apache, który przekazuje je do skryptu PHP. Skrypt w razie potrzeby łączy się z serwerem bazy danych i pobiera odpowiedni fragment obrazu. Następnie serwer HTTP generuje odpowiednio stronę HTML, która jest przesyłana i wyświetlana w przeglądarce użytkownika. przeglądarka WWW raster mapy PHP Serwer np. Apache SQL baza danych np. MySQL Rys Uproszczony schemat najbardziej istotnych bloków używanych przy serwowaniu danych przedstawiających różnorodne mapy rastrowe. Stosowany przy prostych atlasach planach itp. 41

42 System agentowy 3. System agentowy Idea systemu agentowego, jako inteligentnego sposobu pozyskiwania danych, jest dynamicznie rozwijającą się w ostatnich latach dziedziną wiedzy dostarczającą podstaw teoretycznych do wykorzystania sieci komputerowych w różnorakiego rodzaju zastosowaniach, wymagających automatycznych decyzji o przydatności pozyskiwanych danych cyfrowych. Jednocześnie ze względu na szybki wzrost mocy obliczeniowej komputerów oraz dzięki znacznemu polepszeniu wydajności infrastruktury sieciowej powstała możliwość udostępnienia bazy zobrazowań cyfrowych dla potrzeb wizualizacji, lub dalszych prac pomiarowych. Jednoczesna popularyzacja i powszechna dostępność Internetu powoduje potrzebę tworzenia narzędzi pozwalających na wygodny i szybki dostęp do informacji, minimalizujący konieczność ingerencji użytkownika w ten proces jak również rekompensujący jego brak wiedzy w zakresie oceny przydatności materiałów możliwych do pozyskania. Ze względu na nietypową i specjalistyczną charakterystykę cyfrowych zobrazowań fotogrametrycznych, polegającą na jak najlepszym zachowaniu dużej ilości szczegółów sytuacyjnych, pojawia się główny problem dużych rozmiarów plików obrazowych. Przechowanie takiej ilości danych może odbywać się obecnie na kilka sposobów, z wykorzystaniem różnego rodzaju nośników danych, jednak późniejszy wygodny i szybki dostęp do danych zawsze bywa ograniczony. Zwłaszcza jeżeli materiały składowane są fizycznie w jednym miejscu. Sytuacja ulega zmianie jeżeli do przechowywania danych wykorzystamy dostępne w Internecie serwery, przez co niemal natychmiastowa dostępność w prawie dowolnym miejscu przestanie być problemem. Jednak sama dostępność materiału nie implikuje naszej wiedzy o tym, że dane nam potrzebne są rzeczywiście dostępne. Dlatego z pomocą przychodzi system pozwalający na zarządzanie tą rozproszoną bazą danych. Z różnych względów jednym z najlepszych do tej roli wydaje się być system agentów mobilnych, który zazwyczaj doskonale przystosowany jest do pracy w sieci. Jednak nietypowy rodzaj danych wymaga weryfikacji i zmiany niektórych założeń i rozwiązań stosowanych do tej pory [Twardowski, Jachimski 2003]. Przedstawiany w tym opracowaniu system wymiany informacji składa się z kilku warstw współdziałających w odpowiedni sposób ze sobą, co pozwala na realizację założonego celu. Można wyróżnić kilka podstawowych elementów składających się na funkcjonalny system, z których pierwszym jest główny element, czyli rozproszona baza danych obrazowych składowanych na różnych serwerach sieciowych. Drugim elementem 42

43 System agentowy jest serwer systemu agentowego koordynujący wszystkie zadania pomiędzy agentami, zasobami i użytkownikiem, współdziałający równolegle z menadżerem zasobów, zapewniającym bezpieczeństwo dostępu do danych. Kolejnymi częściami są odpowiednio przygotowane programy modułu do przetwarzania obrazów, oraz agenta migrującego pomiędzy serwerami i zbierającego informację o zasobach, w razie potrzeby zamawiając odpowiednie ich fragmenty. Ostatnim członem, odpowiadającym za komunikację z człowiekiem, jest interfejs użytkownika. Może on mieć postać zwykłego terminala tekstowego, jak również strony WWW, czy też dedykowanego programu przystosowanego do pracy z systemem i uruchamianego na komputerze klienta. Wszystkie te elementy współdziałają ze sobą łącząc się za pośrednictwem odpowiednich protokołów sieciowych. Należy też wyjaśnić, że gdy poruszamy kwestię "systemu agentowego" musimy pamiętać, że tym samym terminem będziemy nazywać pojedynczą instalację oprogramowania agentowego na jednym serwerze, jak również zbiór wielu serwerów z zainstalowanym tymże oprogramowaniem. Spowodowane jest to faktem skalowalności systemu, po prostu pojedyncza instalacja jest szczególnym przypadkiem systemu agentowego, która działa tylko na fizycznie jednym komputerze. Jest to przykład w pełni działający, chociaż rozmija się z ideą wymiany informacji pomiędzy rozproszonymi komputerami. Tak więc termin system agentowy będzie używany zamiennie w zależności od aktualnego zakresu rozważanej problematyki. Drugim terminem mającym różne znaczenia w zależności od rozpatrywanej hierarchii jest "serwer", które może miećznaczenie fizycznej maszyny czy też komputera. System agentowy zbiór serwerów Serwer (komputer, host) System agentowy (serwer usługi - program) Serwer (komputer, host) System agentowy (serwer usługi - program) Serwer (komputer, host) System agentowy (serwer usługi - program) Rys Schemat zależności pomiędzy pojęciami system agentowy - serwer. 43

44 System agentowy Jednocześnie słowem "serwer" określa się usługę sieciową uruchomioną na tym komputerze, czyli program który zezwala na stworzenie połączenia sieciowego pomiędzy komputerami. Dlatego też w przypadku pierwszym w użyciu będzie wymiennie słowo "host", które w nomenklaturze sieciowej tradycyjnie oznacza właśnie fizyczny komputer. Trzecim problemem jest kontrowersja na temat odmiany nazwy agent, która odnosi sie do rzeczy jaką stanowi program agenta. Przyjęto odmianę zgodną ze słowem "program", występującą w literaturze dotyczącej systemów agentowych [Ordysiński 2001] Środowisko systemu agentowego - system operacyjny Podstawowe elementy systemu agentowego, czyli serwer agentowy i sam agent są programami komputerowymi, dlatego wymagany jest odpowiedni system operacyjny działający na komputerze, który umożliwi im wykonanie swojego kodu. Aktualnie może to być w zasadzie dowolny system operacyjny działający na dowolnym rodzaju sprzęcie, a jedynym wymaganiem jest obsługa protokołu TCP/IP. Dzieje się tak dlatego, że za sprawą wysiłku kilku projektów o charakterze open source, nastąpiła znaczna integracja platform systemowych za pośrednictwem portów aplikacji (aplikacji zaadoptowanych na poziomie źródła z jednej platformy na inną), emulatorów API, czy też wreszcie programowych emulatorów sprzętu. W rezultacie korzystając z tych mechanizmów, w skrajnych przypadkach, można uruchomić dzisiaj program używając systemu operacyjnego, o którym jakiś autor programu, pisząc go, nawet nie słyszał. Oczywiście nie zawsze jest to łatwe i niekiedy obarczone nieprzewidzianymi wadami, dlatego do celów tego projektu starano się zachować integralność stosowanych rozwiązań. Oprócz tego kilka lat temu, gdy projekt był rozpoczynany, nie były dostępne takie możliwości i starano się zachować uniwersalność rozwiązań, przedkładając je ponad wątpliwą wygodę, a na pewno sztywność niektórych rozwiązań komercyjnych, działających tylko w ograniczonych warunkach. Dlatego, gdy to było możliwe, jako język programowania wybierano ANSI C lub C++, ponieważ jest to standard, który posiada kompilator na praktycznie każdym systemie operacyjnym. Dlatego też wybierano do projektu programy, czy też biblioteki, które co najmniej oferują dostęp do źródeł, najlepiej w C/C++ i najlepiej na licencji wolnego oprogramowania L/GPL (Lesser/GNU Public License) [FSF 2007]. Tymi samymi kryteriami kierowano się przy wyborze systemu operacyjnego, przynajmniej obsługującego projekt w części serwerowej. Dlatego też wybór oprogramowania mającego spełniać funkcję systemu operacyjnego dla serwerów padł na system należący do rodziny UNIX, a konkretnie jedna 44

45 System agentowy z wielu dystrybucji systemu operacyjnego, o nazwie Linux. Jest to nowoczesny, wielozadaniowy, stabilny i elastyczny system operacyjny, który bardzo dobrze spełnia swoją funkcję zarówno w charakterze serwera sieciowego jak i stacji roboczej do codziennego użytku. Jednym z bardzo istotnych jego atutów jest właśnie nieograniczony dostęp do kodu źródłowego, a ponadto jego licencja GPL pozwala na dowolną zmianę tych źródeł i ich ponowne ich rozpowszechnianie [FSF 2007]. Jedna licencja znacząco upraszcza sprawę pod względem formalnym i eliminuje dylematy związane z wyborem kiedy coś można, a kiedy nie można wykorzystać. Dotyczy to samego systemu, jak i wszystkich jego dodatkowych składników. Ponieważ, gdy mówimy o systemie Linux, mamy na myśli zazwyczaj jedną z jego dystrybucji, gdzie oprócz jądra (ang. kernel), obecna jest obszerna kompilacja różnych programów w postaci binarnej, zarówno systemowo-administracyjnych, jak i tych, którymi posługuje się końcowy użytkownik. Jądro systemu Linux ma charakter monolityczny, jednak w przeciwieństwie do innych tego typu kerneli, pozwala na kompilację sterowników jako modułów które w trakcie pracy systemu mogą być włączane lub wyłączane na żądanie. Istnieje dyskusja na temat niewłaściwości używania jądra monolitycznego w nowoczesnych systemach, na rzecz tzw. mikrokerneli (np. nowsze systemy z Redmond). Jednak poza teoretycznymi dywagacjami o słuszności danego rozwiązania nie ma praktycznych powodów dla których model jądra stosowany w systemie Linux miałby zostać porzucony, skoro działa lepiej niż niektóre opiewane rozwiązania oparte na mikrokernelach [DiBona i inni 1999]. Linux zachowuje zgodność ze standardami ANSI i POSIX [Wierzenius 1998], działa na wielu procesorach m.in.: Intel, Sparc, Alpha, Motorola, oraz obsługuje większość urządzeń znajdujących się w komputerach. W poprzednim roku dodana została także obsługa procesorów 64-bitowych [Kernel 2006] i nie trzeba kupować nowej wersji systemu, żeby uzyskać tą funkcjonalność, wystarczy skompilować posiadane jądro z odpowiednimi ustawieniami konfiguracyjnymi. Dzięki temu można stosować Linux-a na szerokiej gamie dostępnego dzisiaj sprzętu komputerowego, a co za tym idzie można stosować również całe oprogramowanie działające w tym systemie. Oczywiście system posiada pełną obsługę protokołu TCP/IP, jak również wielu innych np.: SMB, NFS, CODA, IPX [Bautts i inni 2005]. Ponadto od kilku lat możliwa jest w nim praca przy użyciu uniwersalnego systemu graficznego X-Windows, dzięki czemu staje się coraz bardziej popularny wśród użytkowników mniej zaawansowanych, przyzwyczajonych raczej do klikania w ikony, niż wprowadzania komend z tekstowej linii poleceń. X-Windows jednocześnie otwarło drogę do implementacji wielu aplikacji graficznych, zarówno działających w trybie 2D, jak i tych wymagających akceleracji za 45

46 System agentowy pośrednictwem biblioteki OpenGL, będącej interfejsem programistycznym do obsługi grafiki trójwymiarowej, przy użyciu nowoczesnych kart graficznych [Kilgard 1996]. Większość standardowych dystrybucji Linux-a zawiera również środowisko programistyczne, najczęściej jest to C/C++, ale również: Pascal, Delphi, Java, Python, Tcl/Tk i wiele innych. Niekiedy jest to tylko kompilator, jednak w niektórych przypadkach mamy do czynienia z pełnowartościowym i profesjonalnym IDE (ang. Integrated Development Enviroment). Oprócz tego istnieje projekt Wine, który pozwala na uruchamianie pod kontrolą Linux-a sporej liczby aplikacji napisanych dla rodziny systemów z Redmond, poprzez translację ich API (ang. Application Programing Interface) na polecenia X-Windows,. Rys Przykładowy wygląd pulpitu X-Windows podczas pracy w systemie Linux. Tak szeroka gama możliwości, z których jasno widać elastyczność tego systemu operacyjnego, była decydującym atutem do zastosowania systemu Linux jako platformy do powstania przedstawianego opracowania. Oczywiście program serwera agentowego może działać również na innych systemach należących do rodziny UNIX. Najbliższe dla Linux-a to NetBSD oraz FreeBSD, które jednak bardziej zorientowane są na pracę typowo serwerową. Nie posiadają tak dobrego wsparcia od strony producentów sterowników ze względu na mniejszą popularność tych systemów, przez co tracą na na elastyczności. Innym bardzo dobrym systemem który może posłużyć jako platforma 46

47 System agentowy systemowa jest Solaris. Jest to potężny system przeznaczony do obsługi tysięcy użytkowników i wspierany przez firmę Sun, jednak dopiero niedawno został on upowszechniony za darmo w charakterze otwartego źródła. Jeżeli chodzi o systemy z rodziny Windows, to można sobie wyobrazić potencjalną adaptację przedstawianego systemu np. za pośrednictwem emulatora programowego (np. colinux), lub też emulatora sprzętu (np. QEmu lub VmWare). Jednak mija się z celem wykorzystywanie systemu operacyjnego, który nie jest stabilny, nadmiernie i bez uzasadnienia zużywa zasoby sprzętowe, ma znikome możliwości konfiguracji, jest podatny na wirusy a użyteczny staje się dopiero po zainstalowaniu drogich programów. Tymczasem np. Linux oferuje kilkaset programów dostępnych wraz z popularnymi dystrybucjami zaraz po instalacji System D'Agents Rolę silnika, spełniającego funkcję systemu agentowego, przejął program D'Agents powstały na uniwersytecie Dartmouth w Hannover (New Hampshire, USA). System ten realizuje kilka podstawowych celów, które zapewniają sprawne i wydajne działanie. Pierwszym jest obsługa kilku języków w których może być napisany program agenta, obecnie są to Tcl, Java i Schema [Gray 2002]. Drugim jest redukcja poleceń związanych z migracją do pojedynczej komendy, która mogła nastąpić w dowolnym momencie działania systemu i która mogła zachować aktualny stan agenta, oraz przesłać go do innego serwera. Dzięki temu, podczas pisania programu agenta, nie trzeba zajmować się detalami transmisji, nawet jeżeli zdalny komputer jest przenośny i może być przez nieokreślony czas niedostępny w sieci. Trzecim celem jest elastyczny, wydajny, niskopoziomowy mechanizm komunikacji, który ukrywa detale komunikacji i zaimplementowany jest na poziomie kolejkowania wiadomości lub strumieni danych. Natomiast mechanizmy wyższego poziomu nie są zawarte w podstawowym systemie, lecz na poziomie programu agenta. Dzięki przedstawionym na rysunku 3.3 rozłożeniu systemu na warstwy, program agenta może wykorzystać mechanizm który jest najbardziej dostosowany do aktualnie wykonywanego zadania. Kolejne założenia systemu implikują użycie języka wysokiego poziomu, jako głównego do tworzenia programu agentów, oraz wykorzystanie protokołu TCP/IP, jako głównego mechanizmu transportu. Oprócz tego system zawiera odpowiednie zabezpieczenia pod względem ochrony danych, a co za tym idzie ochrona każdego serwera fizycznego przed wrogimi programami. 47

48 System agentowy Rys Wielowarstwowa architektura systemu D'Agents. Pięć poziomów składa się na API dostępnych mechanizmów transportu: serwer akceptujący nadchodzące wiadomości i będący mediatorem pomiędzy agentami, niezależne od języka jądro, interpreter dla każdego języka i właściwa obsługa agenta [Gray 2002]. Ochrona systemu możliwa jest za pośrednictwem cyfrowych sygnatur agentów, które dzięki temu mogą być identyfikowane jako przyjazne. Oprócz tego istnieje odpowiedni mechanizm tolerancji błędów, które są nieuchronne w niepewnym medium, jakim jest Internet Serwer systemu Zadaniem systemu serwera agentowego D'Agents jest stworzenie środowiska, do którego mógłby zostać przyjęty agent, wykonać zadanie i zostać przesłany dalej. Jest to program, który wykonuje się w systemie operacyjnym w sposób ciągły i udostępnia usługę poprzez odpowiedni port protokołu TCP/IP, poprzez który agenty mogą łączyć się z systemem. Kod źródłowy systemu, który oczywiście jest dostępny publicznie, został napisany w języku C, co pozwala na ewentualne poprawki w przypadku nieprawidłowego zachowania lub potrzeby zmiany działania fragmentu programu. Już na samym początku projektu okazało się to nieocenione, ze względu na pewne niezgodności różnych wersji kompilatorów C/C++ i przyjętych przez nie odstępstw od standardów ANSI. Serwer systemu agentowego śledzi agenty, które aktualnie wykonują się w jego środowisku, odpowiada na pytania na temat ich statusu, oraz pozwala na zatrzymanie i wznowienie uruchomionego programu agenta. Natomiast w sferze migracji serwer odpowiada za sprawdzenie tożsamości właściciela/nadawcy agenta oraz przekazanie go do odpowiedniego interpretera języka wyższego poziomu. Wybiera również odpowiedni mechanizm transportu dla agentów wychodzących. Warstwa komunikacji serwera zawiera dwupoziomową przestrzeń adresową, która pozwala agentom na wzajemną komunikację. Pierwszym poziomem jest sieciowa lokalizacja agenta, a drugim unikalny identyfikator 48

49 System agentowy przydzielany agentowi lub nazwa symboliczna zawarta w programie agenta. W przypadku wymiany informacji pomiędzy dwoma agentami serwer pośredniczy w ich komunikacji, zapewniając bezstronność operacji. agenttcl@zoska:./start_agentd May 7 08:15: agentd: INFO: server keyname is "Agent Tcl server < > < >" May 7 08:15: loadconfig: initial: INFO: IP address of machine "localhost" is May 7 08:15: loadconfig: initial: INFO: IP address of machine " " is May 7 08:15: loadconfig: initial: INFO: IP address of machine " " is May 7 08:15: loadconfig: initial: INFO: IP address of machine " " is May 7 08:15: loadconfig: initial: INFO: IP address of machine "fotos.fotogrametria.agh.edu.pl" is May 7 08:15: loadconfig: initial: INFO: IP address of machine "localhost" is May 7 08:15: loadconfig: initial: INFO: keyname for TrustedMachine "localhost" is "Agent Tcl server < >" May 7 08:15: loadconfig: initial: INFO: IP address of machine " " is May 7 08:15: loadconfig: initial: INFO: keyname for TrustedMachine " " is "Agent Tcl server < >" May 7 08:15: agentd: INFO: environment variable "HOME" is set to "/home/agenttcl" Rys Uruchomienie procesu serwera agentowego. Po uruchomieniu procesu serwera program przechodzi w tryb pracy, który nazywany jest w systemach rodziny UNIX daemon i polega on na tym, że program działa w tle, niezależnie od tego czy powłoka poleceń z której został on uruchomiony nadal działa czy nie. Podobny efekt można uzyskać w systemie Linux dla dowolnego programu, nawet jeżeli nie był on napisany z myślą o takim trybie pracy, ale wówczas musimy posłużyć sie programem o nazwie screen Menadżer zasobów Środowisko musi zapewnić agentowi w razie potrzeby dostęp do wybranych materiałów znajdujących się na serwerze, co jest realizowane poprzez menadżera zasobów dostępnego w systemie D'Agents. Zarządca zasobów współdziała z serwerem agentów i strzeże dostępu do krytycznych elementów fizycznego serwera, takich jak ekran, karta sieciowa, czy też dysk twardy. Decyduje on jakie operacje na serwerze może wykonać agent, na podstawie identyfikatora właściciela. 49

50 System agentowy Ponadto udostępnienie zasobów odbywa się poprzez przypisanie dla danego procesu odrębnego użytkownika, utworzonego specjalnie na te potrzeby w systemie operacyjnym. Dzięki takiemu działaniu dostęp menadżera zasobów jest równy uprawnieniom właściciela procesu czyli użytkownika który program uruchomił. Menadżer zasobów Serwer systemu agentowego agent - skrypt - program - odczyt - zapis... Rys Schemat dostępu agenta do zasobów serwera. Wpływa to na bezpieczeństwo systemu przy ewentualnych nieprawidłowościach w działaniu jak również atakach z zewnątrz [Bauer 2002]. W przypadku nieprawidłowej pracy, na skutek ukrytego błędu w programie lub działania celowego, może dojść do sytuacji w której menadżer przydzieli agentowi większe prawa niż są mu należne. W tej sytuacji gdyby proces był uruchomiony z prawami administratora, wówczas agent miałby nieograniczony dostęp do serwera sprzętowego i systemu operacyjnego. Przydzielenie zwykłego użytkownika temu procesowi naraża potencjalnie tylko zasoby do których dostęp ma sam menadżer, w tym przypadku bazę obrazów. Dla uproszczenia procedury nazwa i grupa użytkownika była taka sama na wszystkich serwerach testowych. Nie jest to niezbędne, jednak znacząco wpływa na wygodę pod względem kontroli działania programów na wszystkich serwerach. Dodatkowym krokiem zwiększającym bezpieczeństwo serwera przed niechcianym dostępem może być opcjonalnie stworzenie tzw. sandbox przy użyciu programu chroot. Polega to na wydzieleniu z pozostałych zasobów serwera odrębnego środowiska w którym niewidoczne są pozostałe elementy, nawet w przypadku posiadania praw administratora. Dodatkowo, jeżeli chodzi o dostęp do zasobów, program menadżera może realizować go na dwa sposoby. Jednym jest oczywisty dostęp bezpośredni, gdzie agent przekazuje swoje parametry zapotrzebowania do serwera agentowego, a menadżer przydziela mu prawo bezpośredniego dostępu do danych, które go interesują. Wówczas może pobrać dane określone przez jego parametry. Drugą metodą jest dostęp pośredni, gdzie dla agenta-gościa przydzielony zostaje agent-gospodarz, który prowadzi z nim całość negocjacji, czyli odbiera wiadomość o zapotrzebowaniu i następnie komunikuje się z serwerem pobierając odpowiednie dane. Ostatecznie dane te przekazuje do agenta- 50

51 System agentowy gościa, którego program podczas całego procesu zostaje podtrzymywany przez serwer agentowy, ale w żadnym momencie agent-gość nie ma dostępu bezpośredniego do zasobów API serwera agentowego Trzecią częścią systemu D'Agents jest jądro interfejsu programistycznego wyższego poziomu (Application Programming Interface), które pozwala na komunikację pomiędzy agentami a serwerem agentowym. Interfejs dostarcza kilkunastu poleceń, których efektem jest możliwość zaistnienia programu agenta, jak również zdolność do komunikacji z innymi agentami. Do rozpoczęcia pracy agenta wymagana jest jego rejestracja w systemie i nadanie mu identyfikatora wraz z parametrami zawierającymi jego status. Analogicznie, po zakończeniu zadania, należy wydać komendę, która zwolni zasoby zajmowane przez proces agenta. Podstawowe komendy sterujące inicjalizacją i zakończeniem to begin, która rejestruje agenta w środowisku serwera, agent pozyskuje serwer kontrolujący i otrzymuje nazwę symboliczną, oraz end, która powiadamia serwer, że agent zakończył zadanie, zasoby zajmowane przez proces mogą zostać zwolnione [Gray 1997]. Drugim zestawem są komendy pozwalające na migrację agenta pomiędzy serwerami. Pozwalają w kontrolowany sposób przesłać agenta ze środowiska uruchomionego na jednym serwerze do innego. Podstawowe komendy służące do tego celu to submit, która tworzy i wysyła agenta do serwera poprzez stworzenie nowego procesu, co zazwyczaj uzyskuje się poprzez użycie w środowisku macierzystym skryptu inicjalizującego; jump, która przenosi agenta na inny serwer, lecz bez tworzenia nowego procesu czyli proces na poprzednim serwerze zostaje zakończony po przesłaniu, oraz fork, która klonuje proces programu agenta, przesyłając jego kopię na kolejny serwer, po czym proces kontynuuje swoją pracę na aktualnym serwerze. Przykład zastosowania komend znajduje sie w następnym rozdziale i ilustruje go rysunek 4.1. Poza możliwością interakcji ze środowiskiem możliwa jest również komunikacja pomiędzy samymi agentami w przypadku spotkania się ich w jednym środowisku serwera agentowego. Aby to było możliwe API przewiduje komendę status, która zwraca informację o wszystkich agentach aktualnie działających w danym środowisku, wraz z danymi o ich właścicielach i identyfikatorach. Dzięki temu agent, o ile jego program to przewiduje, może wysłać polecenie meet, które jest prośbą o nawiązanie kontaktu z innym agentem na podstawie jego identyfikatora otrzymanego z poprzedniej komendy. 51

52 System agentowy Bezpośrednie połączenie i wymiana danych między nimi możliwa jest przy użyciu komend send, która jest operacją asynchroniczną, wysyłającą wiadomość do innego agenta i którą przechowuje serwer dopóki drugi agent nie wyda komendy agent_receive, odbierającej wiadomość. Przy czym w przypadku komendy agent_receive istnieje kilka możliwości jej użycia, pozwalających na określenie czy agent powinien oczekiwać połączenia w sposób ciągły czy tylko reagować w przypadku wysłania do niego sygnału. Możliwa jest również całkowita izolacja powodująca odmowę na każdą próbę kontaktu. Wszystkie te operacje podlegają sprawdzeniu autoryzacji i limitu dostępu do zasobów, jeżeli taki istnieje. Poza tym wszystkie operacje, które przewidują interakcję z innym serwerem, są wstrzymywane dopóki zdalny serwer nie zatwierdzi operacji, lub wyspecyfikowany przez agenta czas oczekiwania się nie zakończy [Gray 1997] Interpretery programu agenta System agentowy został napisany w języku C, lecz skrypty agentów, których pracą steruje, mogą być napisane w innych językach programowania. Warunkiem koniecznym jest obsługa poleceń jądra systemu agentowego przedstawionego wcześniej, tak więc można sobie wyobrazić że dowolny język programowania mógłby być zmodyfikowany do tego celu. Nie jest to jednak konieczne, ponieważ system D'Agents zawiera już trzy interpretery do wyboru, którymi są: Tcl, Java i Schema. Widoczny jest fakt, że w ten sposób otrzymujemy czwartą warstwę architektury tego systemu agentowego, czyli warstwę interpretera. Warstwa ta składa się z czterech części odpowiednio dla każdego języka: samego interpretera poleceń, modułu bezpieczeństwa który zapobiega nieautoryzowanemu dostępowi do zasobów, modułu stanu który ma możliwość tworzenia zrzutu wewnętrznego stanu agenta i późniejszego jego odtworzenia, oraz zestawu poleceń zastępczych służących do komunikacji z podstawowym API serwera. Tcl jest językiem skryptowym wysokiego poziomu, który był bardzo popularny po tym jak został wyprodukowany pod koniec lat osiemdziesiątych. Język ten jest prosty do nauczenia i dzięki swojej prostocie jednocześnie łatwo rozpoznawany jako "podobny" przez programistów. Ponieważ jest językiem interpretowanym, kod programu w nim napisanego jest łatwo portowalny na inne systemy i łatwo zaopatrzyć go w zabezpieczenia. Może być zawarty w aplikacjach innych języków, realizując zadania które byłyby kłopotliwe do zaimplementowania. Oprócz tego możliwe jest jego rozbudowanie o polecenia użytkownika, dzięki czemu łatwo go zintegrować z systemem 52

53 System agentowy serwera agentowego. Obarczony jest jednak wadami, z których pierwsza i znana w każdym interpretowanym języku jest taka, że program napisany w Tcl jest wiele razy wolniejszy od odpowiedników skompilowanych do postaci kodu maszynowego. Oprócz tego nie posiada on mechanizmów, które można byłoby zastosować do modularyzacji, co przy większych programach może powodować niejasności w kodzie programu. Jednak największą wadą jest to, że Tcl nie posiada mechanizmu do zachowania wewnętrznego stanu uruchomionego skryptu. Dzieje się tak dlatego, że o ile wcześniejsze wady w przypadku agentów mogą być ominięte, to w przypadku ostatniej niemożliwym byłoby uzyskanie funkcji przesłania agenta w dowolnym momencie do innego środowiska. Dlatego też używana w D'Agents wersja Tcl 7.5 musiała zostać zmodyfikowana o osobny stos programu i komendy pobierające stan programu. Do tego dołączone zostały rozszerzenia do komunikacji z jądrem systemu agentowego przedstawione wcześniej, z tym ze do komend dołączony został przedrostek agent_, aby zapobiec konfliktowi nazw pomiędzy tymi dwoma implementacjami. Tak więc program agenta, który ma korzystać z tego języka, jest po prostu skryptem zgodnym ze standardem Tcl, z tą różnicą ze musi wywołać komendę agent_begin aby zarejestrować się w systemie, lub agent_submit aby przesłać swoją część mobilną na inny serwer i tak podobnie ze wszystkimi innymi komendami. Pozostałe dwa interpretery, czyli Java i Schema, docelowo mają działać podobnie jak Tcl, jednak aktualna wersja systemu nie obsługuje ich tak dobrze jak wersję Tcl, są one mniej stabilne [Gray 1997]. Poza tym wersja modułu dla Java dostępna jest po wysłaniu zapytania do autora, na które niestety nie udało się otrzymać odpowiedzi. Dlatego też te dwa języki zostały pominięte w badaniach D'Agents na tle innych systemów agentowych Zastosowany w projekcie system agentowy D'Agents nie jest jedynym tego typu projektem. Istnieją również inne, zarówno darmowe jak i komercyjne. Na wybór systemu agentowego złożyło się kilka czynników, z których, z praktycznego punktu widzenia najważniejszymi były dostępność kodu źródłowego oraz fakt, że ten kod źródłowy napisany jest w języku C/C++. Oczywiście oprócz samego systemu można porównywać cechy systemu specyficzne dla agentów, takie jak: obsługiwany język agentów działających w systemie, migrację procesu agenta i danych, wielowątkowość, rodzaj komunikacji między agentami, rodzaj autentykacji, skalowalność itp. 53

54 System agentowy W tabeli 5.1 przedstawiono zestawienie kilku systemów agentowych z wyróżnieniem ich cech. Kolumna MW oznacza migrację wątku - sposób w jaki wątek agenta może migrować między serwerami, czyli rodzaj mobilności - silny (S) lub słaby (W). W przypadku silnej mobilności system chwyta i migruje status wątku, który zawiera stos wywołań procedur i zmienne lokalne. W przypadku słabej mobilności agent sam musi zadbać o zachowanie tych parametrów. System Język MW MK WW PS Komunikacja Aglets Java W Ara Dost. sieć Zasoby SP/ N OD T obiekt jako ACLS wiadomość bd C, C++, S Tcl SP N T surowe dane ACLS T Bond Java, Python, Jess W SP T N XML bd bd Concordia Java W SP/ T OD T obiekt zdarzenie jako ACLU N D'Agents Tcl, Java, S Scheme SP N N string ACLU T FarGo Java W bd bd bd wywołania metod bd lub zdarzeń bd Grasshopper Java W OD T bd obiekt bd Jumping Beans W SP T T metody CORBA ACLU T Messengers M0 W SP N bd dzielona pamięć bd (tylko lokalnie) T Mole Java W OD T T obiekt bd N ucode Java W SP/ T OD N obiekt brak N NOMADS Java S SP T N surowe dane JS T Visual Obliq W SP bd bd metody ACL N Tacoma C W SP T bd surowe dane OS N Telescript Telescript S SP N T metody zdarzenia lub bd T Voyager Java bd T T metody Java W bd bd bd Tabela 5.1. Zestawienie cech agentów w różnych systemach agentowych [Gray i inni 2001]. Z praktycznego punktu widzenia agenty o silnej mobilności łatwiej zaprogramować, jednak zazwyczaj konieczna jest modyfikacja interpretera systemu. 54

55 System agentowy Dlatego też komercyjne produkty preferują słabą mobilność i brak konieczności udostępniania zmodyfikowanego kodu źródłowego interpretera [Gray i inni 2001]. Kolumna MK to migracja kodu - sposób w jaki kod źródłowy agenta może być przesłany na kolejny serwer. Przedstawione systemy pozwalają na przesłanie kodu z serwera aktualnego na następny przed migracją (SP -sender push), lub pobranie tego kodu na życzenie z serwera poprzedniego (OD - on-demand). Kolumna WW informuje o możliwości przesyłania agentów wielowątkowych, jednak cecha ta ma zazwyczaj niewielkie zastosowanie. Kolumna PS (persistence) przedstawia zachowanie się kodu agenta w przypadku awarii serwera w momencie gdy agent jest uruchomiony na tym serwerze. Agent persystentny (ang. persistent - trwały) to agent, którego proces zapisywany jest w pamięci nieulotnej, np. na dysku twardym. W kolumnie Komunikacja możemy sprawdzić informację o sposobie przekazywania danych pomiędzy agentami. Oprócz danych surowych, mogą to być wiadomości sformatowane jako ciągi znaków (string), dane w formacie XML lub specyficzne dla systemu formaty obiektów lub metod. Kolumna dostęp sieciowy przedstawia metodę kontroli nad dostępem przychodzącego agenta do systemu agentowego, może to być lista dostępu użytkowników (ACLU), lista dostępu serwerów z których agent zapoczątkował trasę (ACLS) lub specyficzne metody dla systemu operacyjnego w tym wirtualnej maszyny Java. Ostatnia kolumna przedstawia dodatkowy stopień możliwości zabezpieczenia danych, gdy proces agenta jest już uruchomiony w środowisku serwera. W wyniku analizy charakterystyki różnych systemów agentowych można stwierdzić, że część cech się pokrywa a część wypada na korzyść systemu D'Agents. Na niekorzyść tego systemu przemawia niewątpliwie cecha trwałości procesu, która może spowodować utratę agenta w przypadku zbiegu okoliczności, w którym serwer przestaje działać akurat wtedy gdy agent na nim pracuje. Nie jest to jednak wada krytyczna z punktu widzenia celu postawionego w niniejszej pracy przed systemem agentowym. 55

56 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie 4. Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Analiza założonego w projekcie zagadnienia wykazała, że kompleksowe rozwiązanie problemu automatycznej komunikacji na wszystkich szczeblach systemu będzie wymagało powiązania różnych technik, zarówno programistycznych jak i rozwiązań sieciowych. Kilkunastoletnie doświadczenie autora, związane z administracją systemów komputerowych i programowaniem w różnych językach, pozwoliło określić, które techniki będą optymalnym rozwiązaniem dla konkretnego problemu. Dlatego też, w zależności od charakterystyki zagadnienia, w zastosowaniach ogólnych zaadaptowano różne istniejące programy, których tworzenie od początku nie miałoby sensu. Poza tym, powstały również nowe programy w sytuacjach, gdzie działanie musiało być bardziej sprecyzowane. Poniższy rozdział przedstawia bardziej szczegółowo ważniejsze elementy stworzone na potrzeby projektu, w którym bezpośrednio zastosowano między innymi: własne skrypty powłoki shell napisane w języku bash [Burtch 2004], własne autorskie programy napisane w języku C/C++ [CPPR 2007], własne i istniejące skrypty w języku TCL [TCL 2007], liczne standardowe programy projektu GNU [GNU 2007], serwery usług sieciowych np.: Apache [Apache 2007], Samba [Samba 2007], nfsd [NFSd 2007], bind [ISC 2007], vsftpd [VSFtpd 2007], sshd [OpenSSH 2007], OpenVPN [Yonan 2007]. Oprócz elementów użytych bezpośrednio do opracowania projektu, wymagane było użycie wielu programów pochodnych, pozwalających na uzyskanie produktów końcowych i testowania zastosowanych rozwiązań. Z bardziej istotnych można wymienić: Linux - system operacyjny w którym powstawała większość elementów projektu, w szczególności dystrybucja Slackware wer. od 9.0 do 11.0 [Slackware 2007], Eclipse - modularne zintegrowane środowisko programistyczne dla C/C++, Java i PHP [Eclipse 2007], Anjuta - zintegrowane środowisko programistyczne dla C/C++ [Kumar 2007], Gimp - program do prostego przetwarzania obrazów rastrowych [GIMP 2007], OpenOffice - rozbudowany pakiet edycji dokumentów biurowych w którym powstał min. ten manuskrypt [OpenOffice 2007], Firefox - przeglądarka stron WWW użyta do testowania rozwiązań przedstawionych w rozdziale 2 [Firefox 2007], QEmu - emulator sprzętu komputerowego, który pozwolił w niektórych 56

57 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie przypadkach na szybkie testowanie elementów projektu w różnych systemach operacyjnych [Bellard 2007], Scilab - program do obliczeń matematycznych, pozwolił na kontrolę poprawności własnych procedur obliczeniowych [Scilab 2007]. Ponadto poprawne działanie elementów projektu wymagało stworzenia unikalnych plików konfiguracyjnych, determinujących specyficzne zachowanie usług, jak i systemów operacyjnych. Ze względu na fakt, że wszystkie zastosowane projekty udostępniane są na zasadzie otwartego źródła, dlatego literaturę do większości stanowiła dokumentacja poszczególnych projektów, zazwyczaj dostępna publicznie na ich stronach domowych. Kompletny kod źródłowy wszystkich programów autorskich, powstałych w trakcie badań, znajduje sie w załączniku w postaci cyfrowej na płycie CD (ze względu na znaczny rozmiar nie został opublikowany w formie drukowanej) Opracowane metody zwiększające funkcjonalność systemu agentowego Wiele zastosowań agentów mobilnych odnosi się do problemów ekonomicznych, menadżerskich, czy też logistycznych. Zjawisko takie ma miejsce ze względu na charakter danych odnoszących się do danego problemu, które w tym przypadku są często metadanymi i są informacją docelową samą w sobie. W takich też zastosowaniach agenty najlepiej sobie radzą, ponieważ główną zasadą ich sprawności jest przenoszenie stosunkowo niewielkiej ilości danych cyfrowych na raz, ażeby zapewnić ich mobilność. Dane obrazowe, z którymi mamy do czynienia w geoinformatyce, czy też w szczególności w fotogrametrii, są cyfrowymi zdjęciami lotniczymi lub zobrazowaniami satelitarnymi, których wielkość często waha się w granicach megabajtów, a nawet przekracza te rozmiary. Dlatego też wymagane było rozwiązanie problemu połączenia funkcjonalności agentów z możliwością transportu potencjalnie dużych ilości danych. Nasuwa się oczywisty wniosek, że przenoszenie danych obrazowych bezpośrednio przez agenty byłoby wielokrotnie większym obciążeniem dla sieci niż to ma miejsce w przypadku rozwiązań tradycyjnych. Generowany byłby zbędny ruch w sieci przy każdym skoku agenta, który byłby "rozepchany" zbędnymi danymi, co rozmijałoby się z ogólną ideą usprawniania pracy i odciążenia połączeń internetowych. Zastosowano więc, opisane poniżej, rozwiązania hybrydowe, polegające na odpowiednim połączeniu funkcjonalności agentów oraz sprawdzonych metod tradycyjnych. Uzyskany w ten sposób efekt powoduje automatyzację procesu, zarówno poszukiwania odpowiednich fragmentów obrazów jak i późniejszemu ich przesyłaniu w przewidziane lokacje. 57

58 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Charakterystyka bazy obrazowej Do celów badawczych założono najprostszy model bazy danych, czyli zasoby obrazowe składowane na dysku twardym w jednym katalogu w postaci plików w formacie zgodnym z TIFF 6.0. Pliki wyposażone zostały w odpowie dnie metadane określające jednoznacznie ich położenie w przestrzeni. Rozwiązanie takie jest proste, a przy tym ma dwie podstawowe zalety usprawniające pracę przy tworzeniu projektu. Jedną była możliwość szybkiego przystosowania dowolnej ilości istniejących obrazów do takiego modelu, poprzez zwykłe ich skopiowanie w odpowiednie miejsce na serwerze bez konieczności jakiegokolwiek przetwarzania. Drugą zaletą tego rozwiązania jest brak konieczności stosowania dodatkowego skomplikowanego oprogramowania do lokalnego zarządzania bazą, co eliminuje potencjalne problemy nie wnoszące nic pozytywnego do projektu. Jedynym usprawnieniem, jakie można zastosować, byłoby odpowiednie periodyczne indeksowanie plików wraz z ich koordynatami referencyjnymi i zapisywanie wyniku w postaci jednego pliku co zaoszczędziłoby czas w przypadku bardzo dużej ilości plików. Spowodowane to jest aktualnymi ograniczeniami sprzętowymi, które biorąc pod uwagę rozwój technologii, w niedługim czasie mogą nie mieć znaczenia. W szczególności mowa jest tutaj o średnim czasie dostępu do danych na dysku twardym, który w nowoczesnych komputerach jest wąskim gardłem dla przetwarzania danych. Sytuacja taka będzie miała miejsce dopóki z napędów pamięci masowej nie zostaną wyeliminowane elementy mechaniczne Program agenta Głównym elementem synchronizującym zapytania do rozproszonej bazy jest agent mobilny, czyli stosunkowo nowa forma programu, która pojawiła się w ogólnie pojętej informatyce i wywołała sporo zamieszania. Już od samego początku głównym problemem była jednolita definicja agenta. Był to problem do tego stopnia trudny do rozwiązania, że w podsumowaniu Trzecich Warsztatów nt. Teorii Agentów, Architektury i Języków przedstawione zostało kilkanaście propozycji definicji wysuniętych przez różnych autorów [Franklin, Graesser 1996]. Jednak rozważając różne typy zastosowań agentów, najbardziej adekwatne wydaje się określenie agenta jako programu, który ma możliwość przesyłania swojego uruchomionego procesu poprzez komputerową sieć heterogeniczną. Pozostałe elementy różnych definicji dodają tylko dodatkowe cechy 58

59 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie w zależności od zastosowania. Dlatego można wymienić kilka cech, którymi w większości przypadków charakteryzują się agenty mobilne. Jedną z pierwszych wymienianych cech jest autonomia, czyli zdolność do działania bez konieczności bezpośredniej interwencji człowieka, jak również bez konieczności nadzoru nad wykonywanymi przez agenta działaniami i stanem wewnętrznym. Drugą podstawową cechą jaką można scharakteryzować agenty to zdolność komunikacji, czyli możliwość wymiany informacji z człowiekiem, innymi agentami czy też dowolnym środowiskiem używającym tej samej implementacji języka. Jako kolejną cechę można można wymienić adaptywność, czyli zmianę zachowania na podstawie poprzednich zaszłych wydarzeń. Inną cechą jest reaktywność, czyli odpowiednia reakcja na zmieniające się środowisko. Jak widać cechy te przypisują agentowi wiele elementów wcześniej zarezerwowanych dla istot biologicznych, jak również można stwierdzić, że bazując na opisie tych cech, agentem może być program wykonujący określone zadanie przy przetwarzaniu danych naukowych, ale jednocześnie za agenta można uznać odpowiednio opracowany program rozrywkowy czy też większość wirusów komputerowych. Kod źródłowy agenta wykorzystywanego w tym projekcie został napisany w języku TCL, ze względu na fakt, że jest on najlepiej obsługiwanym poprzez system D'Agents. Jednak w różnych systemach agentowych zastosowanie mają również inne języki, takie jak: Java, Python, Obliq, Perl czy Telescript [Versteeg 1997]. Zadaniem agenta jest odebranie zapytania od klienta/użytkownika, wysłanie zapytania do menadżera lokalnych zasobów, odebranie od niego odpowiedzi na temat ewentualnych interesujących obszarów i migracja na kolejny serwer, gdzie sytuacja się powtarza dopóki agent nie powróci do macierzystego serwera z zebranymi informacjami. Podstawową funkcjonalność programu agenta można przedstawić na uproszczonym schemacie jego kodu źródłowego. W podanym przykładzie lokalny agent rodzic inicjalizuje pracę agenta potomka tworząc mobilny proces poprzez komendę agent_submit, co powoduje wysłanie agenta na pierwszy serwer i niezależne wykonywanie własnego procesu, wraz z przenoszeniem na kolejne serwery za pomocą komendy agent_jump. W miejscu na realizację zadania agent jest zdolny wykonać dowolną operację jaka jest dostępna dla menadżera zasobów będącego częścią D Agents. Może to być odczyt i zapis danych do dowolnego pliku, sprawdzenie zawartości zasobów lub uaktualnienie bazy danych. Zakończenie zadania powoduje dodanie informacji o jego przebiegu do listy i jeżeli nie ma więcej serwerów na liście, agent wraca do miejsca w którym rozpoczął drogę i zwraca rezultaty do agenta rodzica. 59

60 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Agent potomek: Agent rodzic: proc potomek {serwery} { # zarejestruj proces agent_begin global agent # przemieś ć się na kolejny serwer z listy set serwery {A B } # wyś lij potomka migracja agent_submit \ $agent(local-server) \ -procs child \ -vars serwery \ -script {potomek $serwery} # pobierz rezultaty agent_receive \ code wynik -blocking puts $wynik agent_end set wynik {} foreach serwer $serwery { agent_jump $serwer # / wykonaj zadanie, uaktualnij liste wyniku/ } # wyś lij rezultat i zakoń cz agent_send \ $agent(root) 0 $wynik agent_end Rys Schemat podstawowej implementacji programu agenta. Podstawowym założeniem podczas pracy nad programem agenta było zachowanie jego możliwie jak najmniejszych rozmiarów w celu polepszenia parametrów migracji. Atutem zastosowania języka Tcl w opracowaniu jest możliwość wykorzystania wszystkich komend standardowego języka Tcl, co implikuje bardzo ważną możliwość uruchomienia dowolnego programu dostępnego dla środowiska do którego trafia agent mobilny, za pomocą komendy exec [TCL 2007]. Nie jest to może najbardziej eleganckie rozwiązanie, ale dzięki temu możliwe jest właśnie ograniczenie rozmiaru kodu przesyłanych agentów i sprowadzenie ich funkcji do operacji kontrolnych i informacyjnych, przenosząc właściwą część pracy na odpowiednie programy znajdujące się na poszczególnych systemach operacyjnych, działające w charakterze modułów systemu. Dzięki temu bardzo rosną możliwości zastosowania agentów w połączeniu z programami napisanymi w innych językach programowania, a nawet skryptów wykonywalnych powłoki systemu. 60

61 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Program przetwarzania zasobów Dzięki możliwości zastosowania przedstawionej komendy exec zdecydowano się na stworzenie programu, którego zadaniem jest obróbka obrazów cyfrowych na podstawie parametrów dostarczonych przez agenta. Program został napisany przy użyciu naturalnego języka dla systemu Linux czyli C, co jest dodatkowym usprawnieniem w działaniu systemu, ze względu na wielokrotnie większą prędkość przetwarzania obrazu w porównaniu z odpowiednikiem napisanym w języku Tcl. W tym przypadku zalety Tcl przedstawione poprzednio tracą na znaczeniu na rzecz konieczności szybkiego przetwarzania dużej ilości danych. Program o roboczej nazwie tiffcrop pobiera parametry z linii poleceń, podczas jego uruchomienia przez agenta, przez co współdziałają ze sobą tak samo dobrze, jakby to miało miejsce gdyby kod programu roboczego napisany był w Tcl i zawarty w kodzie agenta, tylko wielokrotnie szybciej. Zadaniem napisanego programu jest wycięcie fragmentu obszaru obrazu cyfrowego zapisanego w formacie zgodnym ze specyfikacją Adobe TIFF 6.0. Aktualnie program ma możliwość wycięcia fragmentu obrazu na podstawie kilku kryteriów. Podstawowym jest podanie przesunięcia i rozmiaru żądanego fragmentu w układzie lokalnym zdjęcia (układ obrazu cyfrowego). Opcja ta nie ma dużego zastosowania, jednak jako wyjściowa dla pozostałych została udostępniona, ponieważ może się okazać użyteczną w niektórych przypadkach, zwłaszcza podczas testów. Drugą możliwością jest określenie współrzędnych poprzez minimum i maksimum narożników obszaru w układzie określonym poprzez parametry podane w nagłówku obrazu cyfrowego, na co pozwala specyfikacja formatu obrazu tiff, w tym przypadku określa się obraz jako geotiff. Trzecią możliwością jest skorzystanie z opcji użycia pliku referencyjnego obrazu wraz z określeniem współrzędnych terenowych narożników obszaru. Jest to niewątpliwie najbardziej elastyczna metoda, ponieważ nie jest ograniczona w żaden sposób przez format pliku obrazowego. Można z niego odczytać dowolne parametry dla danego obrazu, takie jak współrzędne, wielkości pikseli, czy parametry orientacji. Pozostaje kwestia formatu tego pliku dla poprawnego odczytania danych. W trakcie testów skorzystano z istniejącego formatu pliku referencyjnego "tfw", czyli tzw. ESRI World File w którym przechowywane są współczynniki transformacji płaskiej z układu terenowego do układu obrazu [Lyakovsky 2006]. Plik zawiera tylko informacje o współczynnikach, które pozwalają wyliczyć współrzędne terenowego na podstawie wzoru transformacji afinicznej: 61

62 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie x ' = Ax By C y ' =Dx Ey F (4.1) gdzie A i E są interpretowane jako współczynniki zmiany skali odpowiednio wzdłuż obu osi, B i D jako parametry rotacji, a C i F określają translację pomiędzy dwoma układami. Współczynniki te są zapisane w postaci pliku tekstowego w kolejności: A, D, B, E, C, F, oraz są rozdzielone znakiem nowej linii. Należy tu zwrócić uwagę na fakt, że nie wszystkie programy poprawnie interpretują tą formę zapisu. Ponieważ plik w formacie tfw stosowany jest głównie do ortofotomap i innych map rastrowych, nie pozwala on na przechowanie większej ilości informacji, co jest niewystarczające w przypadku zdjęć stereoskopowych. Rekonstrukcja modelu stereoskopowego ze zdjęć lotniczych wymaga znajomości elementów orientacji zewnętrznej i wewnętrznej poszczególnych zdjęć. Dane takie powstają najczęściej na drodze aerotriangulacji i są zapisywane w określony sposób, ustalony w programie użytym do wykonania tej aerotriangulacji. Niestety nie opracowano jeszcze standardu zapisu i każdy producent oprogramowania stosuje nieco inne zasady formatowania danych. Najczęściej dokumentacja aerotriangualcji jest zapisywana w postaci plików tekstowych, takich jak pokazany na rysunku 4.2 przykładowy plik z programu MATCH-AT firmy INPHO [INPHO 2007]. Przykład ten wybrano ze względu na jego reprezentatywność i przejrzystość struktury. W pliku tym w zaprezentowanym rekordzie $PHOTO na początku znajdują się zmienne porządkowe określające numer zdjęcia ($PHOTO_NUM), ścieżkę dostępu do pliku ($PHOTO_FILE), nazwę kamery i stożka ($CAMERA_ID), średnią wysokość terenu ($TERRAIN_HEIGHT), rozmiar piksela obrazu ($PIXEL_SIZE) oraz współrzędne znaczków tłowych w układzie pikselowym ($FIDUCIALS). Z kolei w segmencie $INT_ORI znajdują się parametry orientacji wewnętrznej w postaci współczynników transformacji afinicznej, na podstawie której można wyliczyć współrzędne pikselowe dla zadanych współrzędnych w układzie tłowym. Następnie w segmencie $EXT_ORI plik zawiera stałą kamery, liniowe elementy orientacji zewnętrznej oraz macierz obrotu pomiędzy układem kamery a układem terenowym. Na podstawie tych danych określić można transformację z układu współrzędnych terenowych X, Y, Z do współrzędnych tłowych wg. równań kolinearności. Łącząc te dwie transformacje można przeliczyć współrzędne terenowe na współrzędne pikselowe, które potrzebne są przy pozyskaniu wycinka zdjęcia. Ponadto, aby możliwe było później odtworzenie poprawnych parametrów dla wycinków, należy określić i zachować wektor przesunięcia wycinka względem oryginalnego obrazu. 62

63 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie $PHOTO $PHOTO_NUM : 07\~6804 $PHOTO_FILE : D:\Oliveira\Images\6804.tif $CAMERA_ID : rc30_13372/00 $TERRAIN_HEIGHT : $PIXEL_SIZE : $SCAN_POS : 1 $FIDUCIALS : $END_POINTS $IO_SIG0 : $IO_PARS : 2 2 $INT_ORI : 13:01:32 05/04/ $EXT_ORI : 13:01:32 05/04/ $PHOTO_POINTS : { \* } { \* } { \* } { \* } { \* } { \* } Rys Fragment pliku projektu wygenerowanego przez program MATCH-AT. Decyzja o wykorzystaniu pliku w tym formacie spowodowana była faktem, że program ten jest wykorzystywany powszechnie przez firmy fotogrametryczne zajmujące się m.in. produkcją ortofotomap ze zdjęć lotniczych. Plik projektu musi być wygenerowany po zakończonym procesie aerotriangulacji dla bloku zdjęć lotniczych, wówczas zawarte w tym pliku informacje pozwalają określić, przy pomocy odpowiednich obliczeń numerycznych, położenie zdjęcia w zastosowanym układzie współrzędnych. Oprócz tego należy zmienić wpisy określające położenie fizyczne zdjęcia w bazie obrazowej, ponieważ zawsze się będą one różnić od położenia plików wykorzystywanych w MATCH-AT, ze względu na inny format zapisu ścieżek dostępu do plików w różnych systemach operacyjnych. Program do przetwarzania bazy obrazowej napisany jest w taki sposób, aby z danego obrazu pozyskiwał jak największy interesujący użytkownika obszar, 63

64 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie a w szczególnym przypadku cały interesujący fragment może być zawarty w jednym obrazie źródłowym. Połączenie przedstawionych opcji z analizą obrazów na serwerach daje nam możliwość otrzymania wszystkich interesujących dostępnych fragmentów zdjęć określonych przez naroża opracowania zadane przez użytkownika i przeniesione przez agenta. Dzięki temu możliwe jest pozyskanie np. fragmentów fotomap dla obszaru o ile takie istnieją, jak również np. wycinków stereogramu dla obszaru, w celu stworzenia modelu dla tego fragmentu. Do napisania programu wykorzystano otwartą bibliotekę libtiff, dzięki której było możliwe łatwe manipulowanie formatem pliku TIFF [Libtiff 2007]. Bardziej szczegółowa analiza algorytmu programu oraz problem braku standardów zapisu plików aerotriangulacji będą przedstawione w następnym rozdziale Zabezpieczenie poufności transmisji danych Podczas tworzenia projektu zwrócono również uwagę na bezpieczeństwo przesyłania danych poprzez heterogeniczną sieć komputerową. Nie jest to co prawda zagadnienie krytyczne dla tego systemu, ze względu na fakt, że wykorzystywane dane trudno jest zakwalifikować do ściśle tajnych, lecz mimo to rozpatrzono i przetestowano możliwość uniwersalnego zabezpieczenia danych podczas transmisji, poprzez ich szyfrowanie. System agentowy D'Agents oferuje możliwość enkrypcji agentów przy pomocy klucza PGP, jednak nie jest to rozwiązanie zadowalające dla architektury projektu, ponieważ PGP obwarowane jest różnymi ograniczeniami formalnymi (prawdopodobnie możliwe byłoby zastosowanie GnuPG, jednak wiązałoby się to ze znacznym nakładem pracy). Oprócz tego, w związku z faktem, że dane obrazowe nie są przesyłane wraz z agentem, lecz alternatywnymi drogami transportu, trzeba by było zastosować jeszcze inne rozwiązanie poza PGP, specjalnie do transmisji obrazów. Dlatego też zdecydowano się na rozwiązanie kompleksowe, które szyfruje cały ruch pomiędzy serwerami, w postaci wirtualnej sieci prywatnej szyfrowanej protokołem SSL. W tym celu wykorzystano oprogramowanie OpenVPN, które realizuje bezproblemowo to zagadnienie i jest stosunkowo proste w konfiguracji [Yonan 2007]. Dzięki takiemu rozwiązaniu można połączyć wszystkie serwery należące do systemu w jedną szyfrowaną sieć wirtualną, gwarantując w ten sposób całkowitą poufność transmisji pomiędzy tymi serwerami. 64

65 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie System propagacji serwerów Poprawne i wydajne działanie systemu agentowego zależy w dużej mierze od faktu, że agent może skorzystać z informacji o tym, które serwery należą do tego systemu. Oczywiście najprostszym rozwiązaniem, używanym w projekcie, jest statyczna lista serwerów wprowadzona lub wczytywana bezpośrednio do agenta. W przypadku małej liczby serwerów i do testów jest to rozwiązanie w zupełności wystarczające. Wadą tego rozwiązania jest konieczność ręcznego uaktualniania tej listy lub stworzenia systemu, który zrobi to automatycznie. W przypadku dużej liczby serwerów można rozważyć drugą możliwość, jaką jest wykorzystanie, istniejącego już od zarania sieci komputerowej, systemu propagacji nazw czyli usługi DNS [ISC 2007]. Możliwość zastosowania DNS w przedstawionym projekcie przeanalizowano tylko teoretycznie, opierając sie na wcześniejszym doświadczeniu w pracy z tą usługą. Stwierdzono po analizie, że możliwe jest takie skonfigurowanie usługi, ażeby wszystkie serwery w systemie miały unikalną domenę i agent na podstawie zapytań DNS mógłby określić, które serwery ma odwiedzić. Metody tej jednak nie zaimplementowano praktycznie w projekcie ze względu na konieczność przeprowadzenia formalnego procesu oficjalnej rejestracji domeny specjalnie na potrzeby projektu Opracowane metody na potrzeby interaktywności - interfejs użytkownika Ostatnim, lecz bardzo istotnym elementem w przedstawianym systemie będzie interfejs, poprzez który końcowy użytkownik będzie mógł skorzystać z zalet przedstawionego systemu. Nie jest to element niezbędny, ponieważ system agentowy będzie działał bez względu na to czy użytkownik może wydawać polecenia czy nie, jednak jest wskazane, aby przedstawione rozwiązania miały wymiar praktyczny. Sposobów na rozwiązanie komunikacji z systemem jest kilka. Postarano się przybliżyć te, które były stworzone i wykorzystywane dla potrzeb systemu Terminal tekstowy Najprostszym interfejsem używanym z powodzeniem do tej pory w pracach doświadczalnych jest oczywiście konsola terminala tekstowego, dostępna w każdym systemie operacyjnym np. w postaci programu telnet lub szyfrowanego ssh [OpenSSH 65

66 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie 2007]. W przeciwieństwie do opisu protokołów z poprzedniego rozdziału, tutaj celowo używane są małe litery, które tradycyjnie pozwalają odróżnić protokół od programu opierającego swoją funkcjonalność na implementacji tego protokołu. Konsola tekstowa pozwala na połączenie się z dowolnym serwerem zdalnym należącym do systemu i udostępniającym tą usługę sieciową. Dzięki niej można zdalnie uruchomić program agenta i podać parametry zapytania w trybie tekstowym. Użytkownik wydając polecenie, zawierające nazwę agenta i następujące po niej parametry geometryczne, wprawia w ruch ciąg wydarzeń, który szczegółowo był opisywany poprzednio. Czyli fragment programu - rodzica uruchamia się, interpretuje zapytanie i tworzy proces potomka, który migruje na kolejne serwery. Rys Przykład wykorzystania terminala tekstowego jako interfejsu systemu. Agent zostaje uruchomiony i kolekcjonuje informacje o zawartości bazy danych obrazów na kolejnych serwerach systemu. 66

67 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Należy nadmienić, że w tym najprostszym przypadku użytkownik musiałby zostać zalogowany na czas trwania kwerendy, aby część programu - rodzica będąca efektywnie interfejsem systemu, mogła działać. Jednak w tym przypadku z pomocą przychodzi elastyczność systemu Linux i cecha wspomniana w podrozdziale 2.1, która pozwala na uruchamianie procesu w tle, czyli bez konieczności trwania procesu terminala, który go zapoczątkował. Użycie tego mechanizmu jest bardzo proste i polega na dodaniu na końcu linii poleceń znaku ampersand "&", który w środowisku typu UNIX mówi interpreterowi poleceń powłoki, aby odłączył właśnie uruchamiany proces od swojego i przesłał go od razu w tło. W takim przypadku użytkownik może wylogować się z systemu i nawet wyłączyć swój komputer, a nie będzie to miało wpływu na działanie agenta potomka, ani agenta rodzica będącego lokalnym interfejsem. Agent zakończy swoje zadanie i przekaże wyniki w przewidziane konfiguracją miejsce, gdzie będą oczekiwać na to, aż użytkownik zdecyduje się z nich korzystać. Przedstawiony w skrócie interfejs terminala jest prosty, wystarczająco wygodny i z powodzeniem służył w pracy badawczej do przeprowadzania eksperymentów. Jednak to rozwiązanie ma poważną wadę, którą jest brak możliwości wyświetlania grafiki w trybie tekstowym, a która jest akurat w tym przypadku niezwykle ważna dla ułatwienia użytkowania systemu. Dlatego w połączeniu z terminalem użytkownik musiałby użyć programu do transferu danych np. ftp, aby pobrać wyniki zwrócone przez system na komputer ze środowiskiem graficznym. Następnie mógłby obejrzeć wyniki za pomocą dowolnych programów graficznych jak każdy inny obraz który, znajduje się na jego komputerze Przejściowe połączenie technik przy użyciu terminala i VSD-AGH Przedstawione rozwiązanie z wykorzystaniem samego terminala było najszybszą metodą na otrzymanie działającego i pełnowartościowego interfejsu jeżeli chodzi o wysyłanie zapytań. Jednak ze względu na przedstawione ograniczenia było to niewygodne i nie rozwiązywało kompleksowo problemu np. stereoskopowej obserwacji wycinków stereogramu. Dlatego rozpoczęto pracę nad usprawnieniem systemu poprzez integrację funkcjonalności terminala z innymi programami. W trakcie badań nad usprawnieniem systemu wykorzystano istniejącą stację graficzną VSD-AGH [Jachimski 1995]. Zamysł opierał się na wykorzystaniu funkcjonalności programu VSD jako interfejsu graficznego do wizualizacji, ale również 67

68 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie stwarzającego możliwość wykonania prostych pomiarów na otrzymanych materiałach, zwłaszcza stereograficznych. Ponieważ program VSD-AGH napisany był dla systemu MS-DOS w języku Pascal, dlatego należało trochę przystosować go do pracy w sieci. Jedynym rozsądnym i najszybszym rozwiązaniem wydało się skorzystanie z możliwości standardowej emulacji DOS w systemie Windows 95/98. Po drobnych korektach okazało się, że program napisany w trybie rzeczywistym VESA działa na tym etapie zadowalająco w trybie chronionym Windows. Pozostało tylko skorzystać z możliwości mapowania dysku sieciowego z danymi, które znajdują się na serwerze w sieci lokalnej. W tym przypadku z pomocą przyszedł działający w systemie Linux serwer Samba [Blair 1998], który pozwolił na mapowanie danych pozyskanych z systemu agentowego w ten sposób, aby można było je odczytać bezpośrednio na DOS-owej stacji graficznej [Twardowski 2002]. W celu ułatwienia przeciętnemu użytkownikowi opanowania przedstawionego procesu, powstał również program nakładki do VSD, który automatyzował te czynności jak również inne związane z eliminacją ręcznego wpisywania ścieżek dostępu do plików oraz konfiguracji VSD. Nakładka nazwana roboczo "VSD Frontend" napisana została w języku C/C++ i przy użyciu architektury Microsoft SDK przewidzianej dla systemów rodziny Windows [Microsoft 2007]. Rys VSD Frondend - program w formie nakładki wspomagający pracę VSD-AGH pod Windows, będąca pośrednim etapem na drodze do dedykowanego interfejsu użytkownika. 68

69 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie W przypadku programu nakładki zachowanie zasad elastyczności pod kątem zastosowania wieloplatformowego nie miało znaczenia z uwagi na to, że program został specyficznie zaprojektowany do obsługi VSD, którego kod źródłowy również nie jest możliwy do zaportowania pod inne systemy w jakikolwiek prosty sposób. Ze względu na architekturę tego programu, zapoczątkowanego we wczesnych latach 90-tych, większość jego procedur korzysta bezpośrednio z odwołań do sprzętu w trybie rzeczywistym, w tym cała gama procedur do wizualizacji używa bezpośredniego dostępu do rejestrów i pamięci graficznej. Oprócz tego ze względu na brak jednolitych standardów i ograniczeń sprzętowych program korzysta z wielu zmiennych globalnych i dodatkowo kod źródłowy sformatowany jest tak, aby maksymalnie zmniejszyć jego rozmiar ze względów na ograniczenia ówczesnych edytorów. Innym problemem okazało się zachowanie orientacji dla zdjęć, ponieważ pliki konfiguracyjne VSD są w postaci binarnej i wygenerowanie ich, nawet jeżeli parametry orientacji zdjęć byłyby znane, nastręcza wielu problemów natury programistycznej. Dlatego właśnie ze względu na niereformowalny charakter tej stacji cyfrowej wymagane było "obejście problemu" i stworzenie pomocniczego programu, pozwalającego w przypadku stereogramu na odtworzenie brakujących pikseli dla fragmentu obrazu, na podstawie raportu generowanego przy pozyskiwaniu danych. Brakująca część obrazu zastępowana jest poprzez pustą informacje, czyli np. czarne piksele, które mają na celu odtworzenie wielkości oryginalnego obrazu lokalnie, w ten sposób żeby był on adekwatny do plików zawierających dane orientacji obrazów. Oczywiście ma to związek tylko i wyłącznie z trudnością pozyskania tych danych wprost z plików generowanych przez VSD-AGH, ponieważ zapisywane są one w postaci pliku binarnego, nie posiadającego dokumentacji. Opisywane połączenie elementów okazało się w praktyce po części bardzo użyteczne, jednak w trakcie testów i użytkowania ujawniła się najsłabsza strona rozwiązania, którego częścią jest program napisany dla starszego systemu, wykorzystujący wiele odwołań do urządzeń w trybie rzeczywistym DOS. W dniu dzisiejszym odwołania bezpośrednie do sprzętu są już reliktem minionej epoki w historii rozwoju ogólnie pojętej koncepcji informatyzacji. Obecnie każdy nowoczesny system operacyjny działa w trybie wirtualnym, ukrywając warstwę sprzętową pod powłoką odpowiednich sterowników, a odwołania w trybie rzeczywistym nie mają już miejsca. Używanie ich, pomimo że teoretycznie możliwe, przysparza wielu problemów, powodując nieprawidłowości w działaniu programu, jak również brak stabilności samego systemu operacyjnego. 69

70 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Projekt interfejsu dedykowanego dla potrzeb wysyłania zapytań i wizualizacji Badania nad poprawnością działania systemu ujawniły potrzebę stworzenia zintegrowanego pakietu spełniającego zarówno funkcję interfejsu graficznego, a także interfejsu pozwalającego użytkownikowi na komunikowanie się z systemem agentowym, bez konieczności używania i znajomości żadnych innych technik pracy zdalnej i transferu danych. Głównymi czynnikami przemawiającymi za powstaniem takiego zintegrowanego interfejsu były nie tylko oczywiste elementy takie jak uproszczenie obsługi systemu, ale również czynniki związane ze stabilnością, elastycznością i otwartością systemu. Analiza tego problemu pozwoliła na określenie wytycznych które kierowały późniejszym procesem powstawania interfejsu. Pierwszym i nadrzędnym założeniem rozwiązania było jego wieloplatformowość, czyli program powinien, bez niemal żadnych poprawek, pozwolić skompilować swoje źródło na dowolnym systemie operacyjnym. Założenie to pociąga za sobą szereg pochodnych elementów, z których pierwszym i podstawowym jest wybór języka programowania. Powszechną wiedzą jest niekończąca się w środowisku informatycznym debata nad wyższością jednego języka nad innymi, powodując lawinę argumentów, które nie przynoszą jednoznacznej odpowiedzi. Niezmiennym elementem natomiast jest fakt, że wybór języka jest w głównej mierze subiektywny i zależy od osoby tworzącej konkretną aplikację. Dziś stosunkowo wysoka wydajność sprzętu komputerowego tworzy precedens, w którym historyczny czynnik wyboru języka w zależności od wymaganej szybkości aplikacji jest pomijalny. Teraz bardziej liczy się wygoda i przejrzystość kodu źródłowego niż fakt, że ten sam algorytm napisany przy użyciu różnych języków spowoduje po kompilacji różnice w wydajności końcowej aplikacji. Dlatego też do realizacji projektu zdecydowano się na język C++, który jest uniwersalny, wystarczająco szybki i subiektywnie wygodny [Eckel 2000]. Uniwersalność tego języka odbija się bezpośrednio na wielorodności jego zastosowań, poczynając na systemach operacyjnych poprzez niezliczone biblioteki, a kończąc na prostych aplikacjach [Bulka, Meyhew 1999]. Wybór języka programowania to tylko jedna strona zagadnienia tworzenia programu, która znajduje się bardziej w sferze teoretycznych dywagacji i gramatycznej konsystencji. Drugą stroną jest wybór kompilatora tego języka który tłumaczy idee wyrażone za pomocą wybranej składni na język zrozumiały dla procesora. Ponieważ kompilator wprowadza bardziej przyziemny wymiar dla idei jaką jest składnia języka, dlatego należy pamiętać, że kod źródłowy będzie przypominał bardziej częściowo 70

71 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie zmodyfikowany język, co można porównać do slangu lub gwary w przypadku języka naturalnego. Innymi słowy, kod źródłowy napisany dla konkretnego kompilatora C++ może zawierać wyrażenia będące rozszerzeniem tego języka, które niekoniecznie muszą być zrozumiałe dla innego kompilatora [Stroustrup 1997]. Dlatego też, opierając się na powyższych argumentach, zdecydowano się na zastosowanie GCC jako kompilatora, ponieważ jego implementacje są obecne dla większości systemów operacyjnych. Ponadto licencja GPL tego kompilatora pozwala generalnie na jego wykorzystanie, w dowolnym celu, co jest cechą unikalną zakresie aplikacji tego typu. W trakcie tworzenia programu starano się zachować takie same kryteria dla wszystkich wykorzystanych elementów, w szczególności bibliotek które posłużyły do powstania tej aplikacji Uogólniona hierarchia aplikacji Dzięki obiektowej charakterystyce języka C++ [Straustrup 1997] możliwe było zaprojektowanie systemu podzielonego na funkcjonalne moduły. Pozwala to, lepiej niż w przypadku programowania strukturalnego, kontrolować kolejne etapy powstawania programu i szybciej lokalizować błędy w miarę dodawania kodu źródłowego. Głównymi elementami składającymi się na program są: kod zarządzający projektem, który użytkownik tworzy w programie, kod interfejsu użytkownika, na który składa się główne menu wyboru funkcji programu oraz zestaw okien dialogowych pozwalających na wprowadzanie parametrów działania programu, kod silnika graficznego, który realizuje funkcje wizualizacji danych graficznych, zarówno rastrowych jak i wektorowych, na ekranie monitora za pośrednictwem karty graficznej, kod obsługujący dane graficzne, który wirtualnie łączy dane rastrowe i wektorowe tworząc zunifikowaną warstwę abstrakcji dla danych obrazowych pozwalając na uniwersalna wizualizację przy użyciu silnika graficznego, kod realizujący transformacje pomiędzy układami współrzędnych, pozwala na określenie parametrów modelu dla obrazu graficznego, kod do obsługi protokołów sieciowych, pozwalający na komunikację pomiędzy serwerami wchodzącymi w skład systemu agentowego a stacją roboczą użytkownika. 71

72 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Dane rastrowe Dialogi Dane graficzne Interfejs użytkownika Projekt Dane wektorowe Transformacje Moduł sieciowy Silnik graficzny Rys Schemat hierarchii aplikacji dedykowanego interfejsu graficznego. Przedstawiony na rysunku 4.5 uproszczony schemat hierarchii programu określa sposób przepływu danych w programie interfejsu. Dane obrazowe pobrane za pomocą modułu sieciowego wprowadzane są do projektu i interpretowane poprzez moduł obsługujący dane graficzne. Następnie na podstawie współczynników transformacji są one wizualizowane za pomocą silnika graficznego Interfejs użytkownika Każdy program mający na celu interakcję z użytkownikiem musi posiadać interfejs, który będzie pozwalał na wprowadzanie parametrów programu i modyfikację jego zachowań. Pod tym względem program przeszedł w trakcie prac nad projektem wiele modyfikacji. Pierwsza wersja programu nie posiadała interfejsu graficznego w postaci menu i dialogów, a interakcja z programem odbywała się za pomocą linii poleceń podczas uruchamiania programu oraz skrótów klawiszowych. Pomimo że taka metoda w pełni realizuje założone w projekcie cele, pozwalając na wizualizację wycinków obrazów, to po pewnym czasie okazało się, że tendencje praktycznej obsługi aktualnych aplikacji wymagają graficznej reprezentacji wykonywanych operacji, poprzez wskazania kursora, czyli tzw. interfejsu okienkowego w postaci menu i dialogów. Ponieważ decyzja odnośnie wyboru takiego interfejsu wpływała na całokształt projektu pod względem tworzenia programu jak i samej jego późniejszej obsługi, dlatego 72

73 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie przeprowadzono szereg prób wykorzystując najbardziej popularne biblioteki realizujące funkcję interfejsu użytkownika. Wymagało to żmudnych badań nad praktycznym zastosowaniem m.in. bibliotek: freeglut [Olszta i inni 2005], wxwidgets [Roebling i inni 2007], Qt [Trolltech 2007], glfw [Berglund 2006], FLTK [Spitzak 2007], plib [Baker 2007], gtk2 [Rietvield, Janik 2006]. Każda z bibliotek została przeanalizowana pod kątem wygody, spójności kodu, objętości kodu w stosunku do rezultatów i przystosowania współpracy z biblioteką graficzną OpenGL. Niektóre zostały odrzucone ze względu na zupełny brak trybu menu (np.: freeglut, glfw), niektóre ze względu na rozmiar lub licencję (np.: wxwidgets, gtk2, Qt). Ostatecznie wybór padł na bibliotekę FLTK2, która zawiera podstawowe elementy niezbędne do stworzenia pełnowartościowej aplikacji okienkowej, przy jednoczesnym małym rozmiarze oraz stosunkowo łatwej i szybkiej możliwości tworzenia interfejsu za pomocą dedykowanej aplikacji Fluid. Rys Aplikacja Fluid do tworzenia interfejsu programu. FLTK jest niewielką, elastyczną biblioteką wieloplatformową i z powodzeniem została przetestowana na kilku systemach operacyjnych. Pozwala ona na proste i szybkie tworzenie menu graficznego przedstawionego na rysunku 4.7. Ponadto posiada wbudowaną obsługę dla akcelerowanego trybu graficznego OpenGL za pośrednictwem klasy GlWindow, która pozwala silnikowi graficznemu na renderowanie obiektów bezpośrednio do okna aplikacji [Spitzak 2007]. Zastosowanie jej w projekcie pozwoliło na stworzenie uniwersalnej platformy do dalszej rozbudowy programu. 73

74 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Rys Główne okno programu z menu i kontekstem OpenGL. Program może wyświetlać dowolne obrazy, nie tylko stereogramy. Na przykładzie fragment mapy topograficznej Architektura silnika graficznego Silnik graficzny służący do przedstawiania obiektów na ekranie oparty jest o wieloplatformową bibliotekę OpenGL, która pozwala nie tylko na wydajne renderowanie obiektów ale również na pracę w trybie stereo z zastosowaniem okularów migawkowych lub polaryzacyjnych [Martz 2006]. Biblioteka ponadto jest dobrze udokumentowana w zastosowaniu na różnych systemach operacyjnych [Cojot 1996, Kilgard 1996, Fosner 1996] i wspomagana przez niemal wszystkich producentów kart graficznych m.in.: nvidia i ATI. Przejrzyście i jednoznacznie zdefiniowana specyfikacja biblioteki pozwala na dokładne odwzorowanie obrazu na ekranie monitora, przy pomocy stosunkowo łatwego w obsłudze API kompatybilnego z językiem C/C++ [Alkaley, Segal 2006]. Ze względu na charakterystykę wizualizacji program interfejsu zawiera obsługę dzielenia okna graficznego w zależności od wymaganego trybu co przedstawiono na rysunku 4.8. Aktualnie dostępne są tryby: pojedynczego zdjęcia, podwójnie dzielonego ekranu dla stereoskopu zwierciadlanego, poczwórnie dzielonego ekranu (rysunek 4.9), na potrzeby identyfikacji jednego punktu na czterech pokrywających się zdjęciach oraz tryb stereo dla wykorzystania okularów migawkowych lub polaryzacyjnych. 74

75 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Rys Tryb dzielonego ekranu dla stereoskopu zwierciadlanego. W przypadku migawkowego trybu stereo wymagany jest odpowiedni sprzęt w postaci karty graficznej obsługującej tzw. quadbuffer, który pozwala na renderowanie osobno lewego i prawego tylnego bufora obrazu, gdy w międzyczasie przedni lewy i prawy bufor są widoczne i wyświetlane naprzemiennie na ekranie monitora. Rys Tryb dzielonego poczwórnego ekranu. 75

76 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Dodatkowo do poprawnej obserwacji w tym trybie wymagane są okulary migawkowe LCD (Liquid Crystal Display), które po podłączeniu do karty graficznej (kablem lub bezprzewodowo) realizują funkcję przesłaniania lewego lub prawego oka obserwatora i są zsynchronizowane do treści wyświetlanej na ekranie. Działanie okularów migawkowych opiera się na zasadzie polaryzacji ciekłych kryształów w nich zawartych na skutek przyłożenia potencjału. Przepływ prądu przez materiał polaryzujący zawarty w normalnie przeźroczystym okularze powoduje, że następuje polaryzacja roztworu w którym kryształy zmieniają położenie i blokują przepływ promieni widzialnych. W momencie zaniku napięcia kryształy powracają do pierwotnego położenia i okular ponownie przepuszcza światło. Dlatego też okulary migawkowe mogą być używane wyłącznie z monitorami CRT, lub z rzutnikami. W przypadku paneli LCD istnieje konflikt polaryzacji i należy stosować okulary o stałej polaryzacji. Pod względem wykonywania pomiaru cechą unikalną programu, w porównaniu z innymi rozwiązaniami, spotykanymi w stacjach cyfrowych, jest działanie w trybie nieruchomego kursora, podczas gdy obraz pod kursorem przesuwa się w zależności od ruchów urządzenia wskazującego np. myszy. Zaletą tego rozwiązania jest większy komfort obserwacji dla użytkownika, ponieważ znaczek pomiarowy zawsze znajduje się w centrum pola widzenia. Wadą natomiast to, że do płynnego przesuwania obrazu w czasie rzeczywistym wymagana jest większa wydajność procesora komputera powiązana z dodatkową sprzętową akceleracją graficzną Charakterystyka obsługiwanych danych graficznych Prezentowany program obsługuje obecnie obrazy w postaci plików rastrowych zapisanych w formacie zgodnym ze specyfikacją TIFF 6.0 o dowolnej ilości bitów na piksel (8, 16, 32), dowolnym formacie przechowywania danych (tile, strip, line) oraz kompresjach LZW, Deflate oraz JPEG. Przy czym algorytm LZW ograniczony jest wyłącznie do ekstrakcji, ze względu na ograniczenia patentowe. Obsługa formatu TIFF odbywa się za pośrednictwem biblioteki libtiff wspomaganej przez bibliotekę geotiff w celu przyszłościowego rozwoju aplikacji o obsługę obrazów z zawartymi informacjami w tym formacie. Dodatkowo eksperymentalnie wprowadzona została obsługa obrazów w formacie BMP, JPEG, PNG i GIF za pośrednictwem biblioteki FLTK. Program przewiduje jednoczesną obsługę dowolnej ilości obrazów i zarządzanie nimi w dowolnej konfiguracji wizualizacyjnej, co przedstawiono na rysunku

77 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Rys Dowolna liczba załadowanych obrazów w projekcie i zarządzanie ich wyświetlaniem. Ze względu na znaczne rozmiary zdjęć fotogrametrycznych program w odpowiedni sposób zarządza zasobami wycinając do wizualizacji wymagane w danym momencie dane. W przypadku wycinków obrazów pobieranych z systemu agentowego jest to cecha pomijalna, jednak ten sam algorytm znajduje zastosowanie w obu przypadkach. Biorąc pod uwagę tempo rozwoju technologii cyfrowej można przypuszczać, że w nadchodzących latach rozmiar pamięci operacyjnej przeciętnych komputerów będzie na tyle duża, że aktualne obrazy będą się w niej mieścić bez większego trudu. Mogłoby to wskazywać, że funkcjonalność alokowania tylko widocznego obszaru obrazu stanie się nieistotna. Należy jednak pamiętać, że oprócz rozwoju techniki rośnie też zapotrzebowanie użytkowników i prawdopodobnie w przyszłości znacznie zwiększą się także rozmiary obrazów cyfrowych. Oprócz obsługi danych rastrowych program przewiduje wizualizację danych wektorowych, na potrzeby np. mierzenia punktów lub rysowania linii. Moduł dodawania elementów wektorowych pozwala na wybranie jednej ze zdefiniowanych grup lub wprowadzić własną grupę. Poza tym można zdefiniować które koordynaty chcemy użyć przy pomiarze, co ma potencjalne zastosowanie np. w przypadku zdjęć naziemnych, na których tradycyjnie pomiar odbywa się w układzie obróconym w stosunku do wykorzystywanego przy pomiarze na zdjęciach lotniczych lub satelitarnych. 77

78 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Rys Dodanie grupy punktów. Rys Rejestracja punku w układzie tłowym. Rys Zaznaczone pomierzone w programie punkty. 78

79 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Po przeprowadzeniu pomiaru można wyświetlić koordynaty punktów w zależności od układu odniesienia co przedstawiono na rysunku Ponadto w tym samym oknie dialogowym możliwa jest edycja parametrów wybranej grupy: koloru, rozmiaru symbolu, aktywność i widoczność grupy, oraz możliwość zdefiniowania autonumeracji. Na chwilę obecną w programie dostępna jest funkcja pomiaru punktów na obrazach, która to może być przeprowadzona niezależnie dla każdego zdjęcia i w dowolnych grupach. Rys Współrzędne rastrowe pomierzonych w programie punktów Integracja interfejsu graficznego z systemem agentowym W celu maksymalnego uproszczenia relacji pomiędzy użytkownikiem a systemem agentowym, wprowadzono do programu, przedstawiony na rysunku 4.15, dedykowany moduł sieciowy automatycznego realizujący pobierania funkcję żądanych zapytań do fragmentów systemu agentowego bezpośrednio do oraz interfejsu graficznego. Moduł wymaga podania najbliższego serwera, na którym działa system agentowy, współrzędnych wymaganej lokacji oraz rozmiaru żądanego fragmentu. Następnie użytkownik musi wysłać zapytanie do serwera i po pewnym okresie sprawdzić rezultaty kwerendy. 79

80 Przedstawienie rozwiązań autorskich zastosowanych w budowanym systemie Rys Moduł wysyłania zapytań do systemu agentowego z podaną nazwą serwera, centrum interesującego obszaru i rozmiarem żądanego fragmentu obszaru. Jednostki zależne są od aktualnego układu. Na podstawie wprowadzonych parametrów moduł łączy sie z serwerem za pomocą protokołu HTTP wysyłając zapytanie typu POST. Serwer HTTP wykorzystując informacje za pośrednictwem skryptu CGI wywołuje na serwerze program agenta, który gromadzi dane ze wszystkich serwerów należących do systemu. Jeżeli agent znajdzie odpowiadające dane, wówczas zostają one udostępnione na serwerze który zapoczątkował proces i możliwa jest ich wizualizacja w interfejsie graficznym. Moduł sieciowy Serwer HTTP (np. Apache) System agentowy zbiór serwerów Agent Rys Schemat przepływu informacji pomiędzy interfejsem a systemem agentowym. Do stworzenia modułu wykorzystano bibliotekę libcurl [curl 2007], która realizuje funkcję transmisji danych pomiędzy interfejsem a serwerem HTTP, dzięki czemu moduł obsługi sieciowej mógł zostać w znacznym stopniu uproszczony. Użyta biblioteka zapewnia ponadto obsługę wielu innych protokołów sieciowych takich jak: FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, dzięki czemu zapewniona zostaje w programie elastyczność w przypadku konieczności rozbudowy lub zmiany protokołu wymiany danych. 80

81 Doświadczenia na danych rzeczywistych i analiza prezentowanych rozwiązań 5. Doświadczenia na danych rzeczywistych i analiza prezentowanych rozwiązań Przeprowadzone badania miały na celu określenie poprawności działania systemu agentowego w procesie pozyskiwania danych obrazowych, w szczególności zeskanowanych obrazów cyfrowych pochodzących ze zdjęć lotniczych, rozrzuconych na pewnej ilości serwerów połączonych siecią komputerową. W trakcie prowadzenia badań wykonanych zostało szereg doświadczeń na różnorodnych danych obrazowych pozyskanych z rozmaitych źródeł. Dane te rozmieszczane były na różnych serwerach, w taki sposób, aby zapewnić jak największe rozproszenie danych. Ze względu na fakt, że jest to pierwsza próba zastosowania takiego systemu, niemożliwym jest porównanie go do innych podobnych. Można natomiast porównać opracowany system do sposobów tradycyjnych oraz sposobów udostępniania danych geoinformacyjnych przedstawionych w rozdziale drugim Pola doświadczalne W trakcie badań wykorzystano serwery oparte o komputery PC o różnych parametrach technicznych, z których istotne to prędkość procesora, ilość pamięci operacyjnej RAM oraz jakość połączenia sieciowego i zastosowany system operacyjny. Pierwsza działająca implementacja systemu wykonana została na komputerze klasy Pentium 150MHz, wyposażonego w 32MB pamięci RAM i podłączonego do sieci o przepustowości 10MB/s. Zainstalowanym na nim systemem była dystrybucja Linux Slackware w wersji 8.1, systemem agentowym była ówczesna wersja 2.0 systemu D'Agents, interfejsem do wydawania poleceń był terminal tekstowy, a wyniki wizualizowane były przy pomocy programu VSD-AGH. W trakcie prowadzenia badań na przestrzeni kilku lat dodawano nowe serwery o prędkościach procesora MHz i Mb pamięci RAM, na których instalowano system Linux Slackware w kolejnych pojawiających się wersjach do wersji 11.0 włącznie. W zależności od lokalizacji fizycznej serwerów podłączone były one do sieci Internet poprzez łącza o prędkościach 1-100MB/s. Fizyczne lokalizacje serwerów ograniczały się głównie do terenu Krakowa, z czego m.in. trzy znajdowały się w Zakładzie Fotogrametrii w budynku C4 AGH podłączone do sieci AGH o prędkości 100MB/s. Jeden, przez pewien okres, w akademiku na Miasteczku Studenckim AGH połączony z ZFiIT (Zakład Fotogrametrii i Informatyki 81

82 Doświadczenia na danych rzeczywistych i analiza prezentowanych rozwiązań Teledetekcyjnej) poprzez sieć szkieletową AGH o przepustowości rzędu 100MB/s. Dwa serwery znajdowały się poza obrębem AGH w prywatnej firmie, połączony poprzez sieć Polpak z wykorzystaniem łącza typu Frame Relay o przepustowości rzędu 2MB/s. Jeden serwer znajdował się w innej firmie połączony do sieci przy pomocy łącza asynchronicznego DSL o przepustowosci 512/4096 KB/s. Ponadto przez krótki okres wykorzystywano udostępniony jeden serwer znajdujący sie na terenie Politechniki Wrocławskiej, która dysponuje łączem 100MB/s. Łącznie podczas badań wykorzystano około różnych 15 serwerów, używanych w różnych ramach czasowych, w zależności od uzyskanego do nich dostępu. W ostatnim okresie badań, podczas prac nad interfejsem dedykowanym dla systemu, pole testowe zawężono do sieci lokalnej ZFiIT, w której pracują trzy serwery z zainstalowanym systemem agentowym - fotos, klon i hal, z których ostatni został zakupiony specjalnie do tego celu w ramach grantu promotorskiego KBN 4 T12E Powodem ograniczenia pola testowego były trudności w utrzymaniu sprawności operacyjnej większej ilości serwerów, jak również ograniczenia Uczelnianego Centrum Informatyki co do ilości wychodzących poza uczelnię danych. Ponadto do testowania poprawności działania samego interfejsu użytkownika w zupełności wystarczy tylko jeden serwer, który odbiera od niego zapytania Dane doświadczalne - obrazy i metadane Do przeprowadzenia testów z zakresu pozyskiwania stereogramów wykorzystano obrazy cyfrowe pochodzące z barwnych zdjęć lotniczych wykonanych kamerą Wild RC30 o ogniskowej mm i zeskanowanych w rozdzielczości około 7um, pochodzące z nalotu fotogrametrycznego wykonanego nad obszarem miejscowości Oliveira do Bairro w Portugali. Obrazy zapisane były w postaci plików TIFF o wielkościach nieskompresowanych ok. 1GB i rozdzielczości ok x11000 pikseli. Na rysunku 5.1 przedstawione zostało pokrycie zdjęciami dla testowanego terenu, zawierające łącznie 112 obrazów. Następnie została wykonana aerotriangulacja dla tych obrazów w programie MATCH-AT, tak więc wykorzystano plik projektu wygenerowany z tego programu, ażeby określić współrzędne terenowe na obrazie. Pokazany na rysunku 4.2 format pliku projektu, w polu o nazwie $INT_ORI, przedstawia współczynniki transformacji afinicznej dla obrazu o nazwie 6804.tif na podstawie której ze wzoru: 82

83 Doświadczenia na danych rzeczywistych i analiza prezentowanych rozwiązań x=ax t By t C y=dx t Eyt F (5.1) program tiffcrop może wyznaczyć współrzędne pikselowe dla odpowiednich zadanych współrzędnych tłowych. Rys Pokrycie zdjęciami lotniczymi dla obszaru Oliveira do Bairro. Oprócz tego w tym samym pliku poniżej, w polu $EXT_ORI znajdują się: stała kamery, współrzędne środka rzutu i macierz obrotu kamery, na podstawie których oraz na podstawie równania kolinearności ze wzoru: xt = X Xo a11 Y Yo a 21 Z Zo a 31 c X Xo a13 Y Yo a 23 Z Zo a 33 k (5.2) y t= X Xo a 12 Y Yo a 22 Z Zo a32 c X Xo a13 Y Yo a23 Z Zo a33 k można wyznaczyć współrzędne tłowe dla odpowiednich zadanych współrzędnych 83

84 Doświadczenia na danych rzeczywistych i analiza prezentowanych rozwiązań terenowych. Dzięki temu przechodząc poprzez poszczególne etapy program tiffcrop może na podstawie zadanych współrzędnych terenowych stwierdzić czy piksele odpowiadające tym współrzędnym znajdują się na tym obrazie. Po wyznaczeniu odpowiedniego obszaru program może wyznaczyć współczynniki DLT (Direct Linear Transformation). Współczynniki te nie są niezbędne, jednak za ich użyciem przemawia koncepcja ujednolicenia współczynników dla wszystkich zdjęć. Nie wszystkie zdjęcia (np. niemetryczne) mają zdefiniowane parametry orientacji, ale za to wszystkie mogą mieć zdefiniowane współczynniki DLT. Dlatego przyjmując odpowiednio: A= c k a11 u B= c k a21 u C= c k a 31 u D=c k a11 Xo a21 Yo a 31 Zo u E=a13 u F =a 23 u G=a 33 u H = c k a 12 u I = c k a 22 u J = c k a 32 u K =c k a11 Xo a 21 Yo a 31 Zo u (5.3) gdzie: u= a 13 Xo a 13 Yo a13 Zo 1 (5.4) oraz przesunięcie fragmentu względem oryginalnego obrazu sx i sy, a następnie przekazać je do programu przeglądarki która pracując w trybie stereografu na podstawie wzoru: xt = AX BY CZ D EX FY GZ 1 (5.5) yt = HX IY JZ D EX FY GZ 1 może wyznaczyć współrzędne tłowe dla obrazu, i na podstawie wzoru: x=ax t By t C sx y=dx t Eyt F sy (5.6) oraz współczynników transformacji z pola $INT_ORI może wyznaczyć współrzędne rastrowe pikseli dla zadanych współrzędnych terenowych. Oczywiście zastosowany plik MATCH-AT nie jest jedynym formatem który można by było użyć w systemie do określenia potrzebnych parametrów. W przypadku plików generowanych przez programy innych firm (ImageStation Automatic 84

85 Doświadczenia na danych rzeczywistych i analiza prezentowanych rozwiązań Triangulation - produkt firmy Intergraph [Intergraph 2007] czy też ORIMA - firmy Leica Geosystems [Leica 2007]) istnieje konieczność dodania do systemu agentowego modułu, który poprawnie zinterpretowałby te pliki, lub zmodyfikowania modułu istniejącego Procedury doświadczeń Różnorodność konfiguracji sprzętowych serwerów i ich oprogramowania pozwoliła na określenie poprawności działania systemu agentowego w różnych warunkach. Dodatkowo w trakcie doświadczeń symulowane były awarie serwerów i analizowano zachowanie systemu w takich warunkach. Na rysunku 5.2 zobaczyć można przykład doświadczenia w którym biorą udział trzy serwery z których na pierwszym nie działa menadżer zasobów, tak więc następuje odmowa dostępu, na drugim system działa poprawnie, więc zwrócona zostaje lista dostępnych obrazów z niektórymi ich właściwościami, natomiast na trzecim system agentowy nie jest uruchomiony, na skutek np. całkowitej fizycznej awarii serwera podczas braku zasilania i agent zgłasza, że nie może przeskoczyć na ten serwer. Należy zwrócić uwagę, że pomimo nawet całkowitej awarii części serwerów agent kontynuuje swoją pracę i poprawnie zakańcza program. Dzięki temu można stwierdzić odporność systemu na różnorakie awarie pojedynczych serwerów i jego stabilność działania. W trakcie badań oprócz całkowitych awarii symulowano ponadto częściowe usterki takie jak: brak praw dostępu do odczytu danych, błędne dane obrazowe w bazie, błędne daty systemowe na serwerach itp. We wszystkich przewidzianych przypadkach program agenta reagował w poprawny sposób zgłaszając odpowiedni komunikat i/lub zwracając pozyskane dane z bazy obrazowej jeżeli była ona dostępna na chociaż jednym serwerze. Pamiętać należy jednak o przypadku utraty agenta w momencie gdy już znajduje się na serwerze, co zostało opisane wcześniej. Ponieważ usterka taka jest wysoce nieprawdopodobna, jak również trudno stwierdzić kiedy agent znajduje się na konkretnym serwerze ze względu na jego autonomię, dlatego też nie udało się przeprowadzić symulacji takiej usterki. Przypuszczać jednak można, że zapytanie do systemu będzie musiało być wysłane ponownie, a zabezpieczeniem przed tą usterką jest maksymalny czas oczekiwania na powrót agenta. 85

86 Doświadczenia na danych rzeczywistych i analiza prezentowanych rozwiązań Rys Zachowanie systemu agentowego w przypadku różnych awarii serwerów. Oprócz testów na poprawne działanie samego systemu agentowego przeprowadzono również procedurę weryfikacji poprawności pozyskanych danych. W tym celu na wybranych obrazach niezależnie przeprowadzono procedury pomiarowe metodami tradycyjnymi oraz przy pomocy prezentowanego systemu. W pierwszym etapie prac nad systemem, w przypadku pojedynczych rastrów stosowanych w GIS, fragment obrazu pozyskany z systemu nakładany był na kompletny obraz jako dodatkowa warstwa w programie GIMP. Stwierdzono, że błędy pozyskiwania danych nie przekraczają jednego piksela, co do celów obserwacyjnych jest w zupełności wystarczające. Natomiast w przypadku zdjęć lotniczych stereo procedura była bardziej skomplikowana, ze względu na konieczność zachowania poprawnych parametrów orientacji dla fragmentów obrazów. W celu sprawdzenia poprawności wyników posłużono się stacją cyfrową VSD-AGH i najpierw przeprowadzono orientację wybranych stereopar, a następnie pomierzono wybrane szczegóły sytuacyjne (najczęściej narożniki budynków). W kolejnym kroku tą samą czynność, czyli pomiar tych samych szczegółów sytuacyjnych, wykonano na pozyskanych z systemu fragmentach obrazu, tym razem używając stworzonej dedykowanej przeglądarki. 86

87 Doświadczenia na danych rzeczywistych i analiza prezentowanych rozwiązań VSD-AGH: VGLFL: Rys Wyniki pomiarów podczas niezależnego pomiaru (z lewej) i pomiaru w systemie (z prawej). Przedstawione na rysunku przykładowe wyniki pomiarów pozwoliły na stwierdzenie, że drobne różnice współrzędnych rzędu kilku milimetrów dla pomierzonych szczegółów sytuacyjnych można zakwalifikować jako błędy interpretacji operatora w wyznaczaniu punktów oraz błędy pomiaru wprowadzone podczas niezależnej orientacji obrazów Praktyczny aspekt proponowanego rozwiązania Jak pokazuje praktyka, geodane obrazowe są przechowywane w rozproszonych bazach danych. Są to bazy zakładane przez instytucje publiczne oraz firmy prywatne. Zarówno rozproszenie jak i ogromne ilości tych danych powodują, że utrudniona jest efektywność ich wykorzystania. Dlatego w ostatnich latach zwraca się większą uwagę na tworzenie metadanych, które są informacjami o istniejących geodanych. Jest to w tej chwili krytyczny problem w tworzeniu infrastruktury danych przestrzennych [INSPIRE 2007]. Rozwijane są specjalistyczne serwery katalogowe do przeszukiwania metadanych [Gotlib i inni 2006]. Z pewnością będzie to proces długotrwały a obejmuje tylko część geodanych, która mieści się w polu zainteresowania służb publicznych, odpowiedzialnych za informację przestrzenną. Wszystko wskazuje na to, że poza polem ich zainteresowania znajdą się zdjęcia lotnicze, które obecnie są traktowane jedynie jako materiał przejściowy do opracowania ortofotomapy. W ten sposób nie da się wykorzystać możliwości uzyskania efektu stereoskopowego dla celów interpretacji treści. W efekcie zdjęcia lotnicze pozostaną tzw. zasobem bazowym, poza sferą użyteczną, z wielką stratą dla zadań w których percepcja trzeciego wymiaru wpływa zarówno na walory poznawcze jak i na wrażenia estetyczne. Jednym z głównych atutów przedstawianego systemu jest elastyczność, która 87

88 Doświadczenia na danych rzeczywistych i analiza prezentowanych rozwiązań między innymi na możliwość dodania obsługi dowolnego formatu plików. Tak więc jeżeli powstanie zintegrowany system metadanych nie będzie żadnych przeciwwskazań, aby system agentowy nie mógł z nich korzystać. Wymagane wtedy by było napisanie odpowiedniego modułu, który rozumie i korzysta z metadanych na różnych serwerach. Ponadto zachowana by została funkcjonalność przeszukiwania zasobu bazowego, czyli zdjęć lotniczych. Mając na uwadze poprawiający się dostęp do sieci ogólnoświatowej, można założyć, że użytkownik poszukujący zdjęć lotniczych do utworzenia modelu stereo określonego obszaru geograficznego. Dlatego w opracowywanym projekcie uznaje się pozycję B, L środka obszaru zainteresowania lub cztery narożniki okna geograficznego. Dla użytkownika profesjonalnego pozostawia się możliwość definiowania obszaru poprzez współrzędne prostokątne płaskie, w określonym układzie współrzędnych. W obecnej chwili korzystanie z długości i szerokości geograficznej, do określenia które zdjęcia zostały wykonane w tym miejscu, jest utrudnione ze względu na fakt, że w plikach aerotriangulacji nie ma informacji o kodach do bazy udostępnianej przez OPG Surveying and Positioning Commitee [EPSG 2007]. Jeżeli w przyszłości zapis o tym kodzie znajdzie się w plikach referencyjnych wówczas można będzie użyć biblioteki GDAL do transformacji pomiędzy układami lokalnymi występującymi w plikach z danymi aerotriangulacji a układem globalnym. Biblioteka GDAL działa jako translator pomiędzy rastrowymi formatami danych geoprzestrzennych i jest opublikowana z licencją X/MIT [GDAL 2007]. Jednym z jej składników jest biblioteka OGR, w której dzięki klasie OGRSpatialReference można na podstawie kodu EPSG odczytywać parametry dotyczące układów współrzędnych w poszczególnych krajach Korzyści z użytkowania systemu i analiza wydajności Ponieważ nie istnieje żaden inny system o otwartym źródle podobny do prezentowanego, a komercyjne projekty nie wspominają o zastosowaniu systemów agentowych, dlatego wydajność opracowania można porównać tylko do metod tradycyjnych [Gray 2001]. W przypadku użycia takich metod musielibyśmy najpierw wyszukać samodzielnie obrazy, które przedstawiają interesujący nas obszar, a następnie pobrać pliki zawierające zeskanowane obrazy o objętościach często przekraczających 500Mb. W tym celu trzeba by było np. zalogować się klientem ftp na serwer, pobrać listę obrazów z ich zakresami pokrycia terenu (przy założeniu że takowa by istniała), znaleźć 88

89 Doświadczenia na danych rzeczywistych i analiza prezentowanych rozwiązań na niej nazwy plików interesujących obrazów, a następnie zapoczątkować proces pobierania plików i poczekać, aż transfer plików się zakończy. W przypadku popularnych dzisiaj łączy 512kB/s transfer pliku 500Mb trwałby około trzech godzin, a w przypadku zdjęć stereo czas ten by się podwoił. Następnie po pobraniu obrazów wymagana byłaby jedna z komercyjnych stacji cyfrowych, sprzedawanych po kilka - kilkanaście tysięcy złotych, pozwalających na obserwację stereoskopową zdjęć i ewentualny pomiar fotogrametryczny, ponieważ aktualnie nie ma darmowych programów działających w takim charakterze. Przedstawiony powyżej przykład niewątpliwie podkreśla przewagę wydajności prezentowanego rozwiązania nad metodami tradycyjnymi. Oczywiście metody tradycyjne można by wspomóc jednym z projektów przedstawionych w rozdziale drugim, jednak nie przewidują one w większości zastosowania zdjęć lotniczych, za wyjątkiem projektu opracowanego na UWM. Ponadto są to rozwiązania scentralizowane, a co za tym idzie musiałyby one przezwyciężyć problem przechowywania dużej ilości danych w jednym miejscu. W kwestii wydajności samego systemu agentowego należy wspomnieć, że przyjętym modelem migracji w projekcie był przedstawiony na rysunku 5.3 model szeregowy. W modelu tym agent "przeskakuje" kolejno z serwera na serwer, aż do jego powrotu na serwer macierzysty. Czyli w efekcie wysyłany jest jeden agent na jedno zapytanie zadane przez użytkownika obsługującego interfejs. Rys Szeregowy model migracji. Możliwy do użycia jest przedstawiony na rysunku 5.4 model równoległy, w którym wiele agentów wysyłanych jest jednocześnie na liczne, lub w szczególnym przypadku, wszystkie serwery. Czyli liczba agentów byłaby iloczynem pomiędzy liczbą serwerów a ilością zapytań wysłanych przez użytkowników. 89

90 Doświadczenia na danych rzeczywistych i analiza prezentowanych rozwiązań Rys Równoległy model migracji. Model równoległy co prawda zwiększyłby wydajność systemu i rezultaty pozyskane zostałyby w krótszym czasie, jednak potencjalnie wiązałoby się to z duplikatami części zamówionych danych, co w wyniku zwiększyłoby w znacznym stopniu obciążenie sieci. Dlatego też nie zajmowano się w badaniach tym wariantem modelu migracji. W dalszych pracach rozwojowych nad projektem można rozważyć ten aspekt i wyeliminować przewidywane problemy poprzez dalsze udoskonalenie "inteligencji" agenta oraz wprowadzenie komunikacji między agentami. 90