Problemy prowadzenia analiz sieciowych w przestrzeni trójwymiarowej z wykorzystaniem oprogramowania Network Analyst (ArcGIS) i pgRouting (PostGIS)

ROCZNIKI GEOMATYKI 2017 m TOM XV m ZESZYT 3(78): 271–282

Problemy prowadzenia analiz sieciowych

w przestrzeni trójwymiarowej

z wykorzystaniem oprogramowania

Network Analyst (ArcGIS) i pgRouting (PostGIS)

Problems of 3D network analysis performed

in Network Analyst (ArcGIS) and pgRouting (PostGIS) software

1 _{AGH Akademia Górniczo-Hutnicza, Wydzia³ Geodezji Górniczej i In¿ynierii Œrodowiska,}

Katedra Geomatyki

2 _GISonLine

S³owa kluczowe: modelowanie 3D, baza danych przestrzennych, wnêtrze budynku, nawigacja 3D, wizualizacja, wyznaczanie tras

Keywords: 3D modelling, spatial database, building interiors, 3D navigation, visualization, routing

Wprowadzenie

Analizy sieciowe nale¿¹ do grupy analiz dostêpnej w systemach informacji przestrzennej. Podstaw¹ dzia³ania s¹ dane, na które sk³adaj¹ siê dwa zbiory: zbiór krawêdzi i wierzcho³ków tworz¹ce sieæ. W praktyce z sieci¹ mamy do czynienia w przypadku: sieci ulic, sieci uzbro-jenia terenu, sieci komunikacji miejskiej, itp. W grupie analiz sieciowych mo¿na znaleŸæ takie warianty analiz jak: wyszukanie trasy najkrótszej i/lub najszybszej, wyznaczenie obszarów obs³ugiwanych w zadanym czasie, rozwi¹zanie problemu komiwoja¿era (Cichociñski, Dê-biñska, 2012).

Obszarami, na których mo¿liwoœci analiz sieciowych nie by³y do tej pory szeroko wyko-rzystywane s¹ wnêtrza budynków. Tymczasem z powodu wzrostu liczby ludnoœci i kurcze-nia siê terenów zdatnych pod zabudowê, a tak¿e rosn¹cego zapotrzebowakurcze-nia na powierzch-nie biurowe i lokale mieszkalne (wspó³czesny cz³owiek spêdza prawie 90% swojego ¿ycia w ró¿nego rodzaju wnêtrzach, Klepeis i in., 2001), w ca³ym œwiecie konstruowanych jest coraz wiêcej wysokich, rozleg³ych i skomplikowanych budynków. W wielu krajach nie s¹ rzadkoœci¹ budynki, w których przebywa jednoczeœnie ponad 10 tysiêcy ludzi (Yuan i in., 2009). Budynki takie zapewniaj¹ nie tylko komfortowe warunki przebywania, lecz tak¿e

generuj¹ problemy zwi¹zane chocia¿by z okreœleniem optymalnej trasy dotarcia do wybra-nych miejsc (Vanclooster, 2014), w tym dla osób poruszaj¹cych siê na wózkach, czy te¿ wyznaczeniem dróg ewakuacji (Koo i in., 2012). Przez analogiê mo¿na by³oby przyj¹æ, ¿e tutaj równie¿ znalaz³yby zastosowanie metody i narzêdzia analiz sieciowych. Jednak œrodo-wisko budynków istotnie ró¿ni siê od innych miejsc, w których wykorzystywane s¹ analizy sieciowe. Zasadnicz¹ ró¿nic¹ jest wprowadzenie trzeciego wymiaru (3D). Wymaga to za-równo dostosowania algorytmów, jak równie¿ pokonania trudnoœci zwi¹zanych z wizuali-zacj¹ danych i wyników wykonanych analiz. Przeprowadzone przez autorów rozpoznanie dostêpnego oprogramowania pokaza³o, ¿e spoœród powszechnie stosowanych, tylko dwa systemy umo¿liwiaj¹ prowadzenie trójwymiarowych analiz sieciowych: komercyjne opro-gramowanie ArcGIS firmy Esri z rozszerzeniem Network Analyst oraz nale¿¹cy do grupy wolnego oprogramowania system zarz¹dzania baz¹ danych PostgreSQL z rozszerzeniami PostGIS i pgRouting. Dlatego w niniejszej pracy podjêto siê porównania mo¿liwoœci i ogra-niczeñ prowadzenia analiz sieciowych 3D z wykorzystaniem tych programów. Trzeba zaak-centowaæ, ¿e przedmiotem badañ by³ szeroko pojêty proces analizy od przygotowania da-nych do finalnej wizualizacji.

Dane dla analiz sieciowych 3D

Pierwszym problemem, z którym spotyka siê wykonawca analizy przestrzennej we wnê-trzach budynków, jest dostêpnoœæ odpowiednich danych. Obecnie informacja w postaci cyfrowej na temat struktury budynków (plany architektoniczne) gromadzona jest najczêœciej w postaci wektorowych rysunków wykonywanych w oprogramowaniu CAD (ang. Com-puter Aided Design) i sk³adaj¹cych siê z prostych elementów geometrycznych, takich jak: linie czy ³uki ko³owe (Dominguez, 2012). Opcjonalnie mog¹ byæ tworzone bloki, jako z³o¿e-nia tych prostych elementów oraz innych bloków, co umo¿liwia tworzenie reprezentacji takich powtarzaj¹cych siê elementów, jak: drzwi lub okna. Ponadto oprogramowanie CAD pozwala podzieliæ dane na warstwy grupuj¹ce powi¹zane ze sob¹ elementy, które mo¿na w³¹czaæ i wy³¹czaæ (wyœwietlaæ i gasiæ) w miarê potrzeb. Jednak zastosowania danych w takiej postaci, poza funkcj¹ prezentacyjn¹, s¹ bardzo ograniczone. Dlatego mo¿na obecnie obserwowaæ gwa³towny rozwój dziedziny okreœlanej w skrócie terminem BIM (ang. Buil-ding Information Modeling), w której rysunek zastêpowany jest trójwymiarowym mode-lem, sk³adaj¹cym siê z powi¹zanych ze sob¹ obiektów, posiadaj¹cych nie tylko cechy geo-metryczne, lecz równie¿ inne w³aœciwoœci, a nawet mo¿liwoœæ rejestracji zachowañ (Denis, 2015).

W ostatnim czasie, tematyka gromadzenia i przetwarzania danych opisuj¹cych wewnêtrzn¹ strukturê budynków jest równie¿ przedmiotem badañ w zakresie systemów informacji geograficznej. Pionierskie prace w tym zakresie prowadzili twórcy standardu CityGML (Open Geospatial Consortium, 2012) bêd¹cego aplikacj¹ jêzyka XML dla celów zapisu i wymiany trójwymiarowych modeli miast. CityGML sta³ siê nastêpnie punktem wyjœcia dla sformu³o-wania modelu danych budynków 3D na potrzeby europejskiej infrastruktury informacji prze-strzennej, ustanowionej przez dyrektywê INSPIRE (INSPIRE, 2013), co jest gwarancj¹ popularyzacji tej tematyki. Mo¿na zaobserwowaæ równie¿ próby zastosowania narzêdzi i struktur danych oferowanych przez oprogramowanie GIS dla celów zarz¹dzania budynka-mi (S³owikowski i in., 2014; Harris, 2015).

Jednak nawet kompletna informacja o konstrukcji budynku nie pozwala na wyznaczanie tras w jego wnêtrzu. Konieczne wiêc okaza³o siê zdefiniowanie struktur danych odpowied-nich dla nawigacji w budynkach. Powsta³ w ten sposób IndoorGML (Open Geospatial Con-sortium, 2016).

Standard ten okreœla strukturê przestrzeni nawigowalnych w budynkach. Opisuje szcze-gó³owo abstrakcyjny model danych, jak równie¿ charakteryzuje schemat XML dla informa-cji przestrzennej. IndoorGML nie powiela schematów CityGML, a jedynie wykorzystuje je jako t³o przestrzeni nawigacyjnej. G³ównym za³o¿eniem IndoorGML jest reprezentowanie przestrzeni zamkniêtych (korytarze, pokoje) jako komórek, które s¹ powi¹zane relacjami. Dokonuje siê tego za pomoc¹ obiektów punktowych – wêz³ów, które reprezentuj¹ pomiesz-czenia oraz krawêdzi – obiektów liniowych, ³¹cz¹cych pary wêz³ów. Taki zbiór informacji jest ju¿ wystarczaj¹cy do przeprowadzania analiz sieciowych w budynkach.

Mimo wprowadzenia standardu wci¹¿ brak jest powszechnie dostêpnych narzêdzi po-zwalaj¹cych na automatyczne generowanie sieci niezbêdnej do przeprowadzenia analiz. Co prawda padaj¹ propozycje algorytmów maj¹cych zautomatyzowaæ proces pozyskiwania danych o sieci nawigacyjnej (Karas i in., 2006; Li i in., 2016; Jamali i in., 2017; Xiong i in., 2017), ale dotychczas nie zosta³y one zaimplementowane w popularnym oprogramowaniu. Pozostaje wiêc rêczne dodawanie do bazy poszczególnych elementów, korzystaj¹c z istnie-j¹cych rysunków jako podk³adu (Pu, Zlatanova, 2005).

W taki te¿ sposób zosta³y pozyskane dane wykorzystane w opisywanych poni¿ej bada-niach. Przygotowali je studenci Ko³a Naukowego Geodetów „Dahlta” w ramach opracowy-wania geoportalu System Informacji Przestrzennej AGH (Parkitny i in., 2013).

ArcGIS Desktop z rozszerzeniem Network Analyst

Do przeprowadzenia analiz sieciowych zarówno w œrodowisku 2D, jak i 3D, pakiet Arc-GIS korzysta z algorytmu Dijkstry (1959) bazuj¹cego na teorii grafów. Zatem wymagane jest odpowiednie przygotowanie danych, w ramach którego wyró¿niæ mo¿na dwa aspekty. Pierwszy dotyczy przypisania krawêdziom odpowiednich atrybutów, odpowiadaj¹cych kosz-towi pokonania danego odcinka. W przypadku budynków mo¿e byæ to d³ugoœæ odcinka, b¹dŸ czas jego pokonania pieszo. Jeœli analizy prowadzone s¹ pod k¹tem dostêpnoœci dla osób niepe³nosprawnych poruszaj¹cych siê na wózkach, wówczas z analiz nale¿y wy³¹czyæ wszystkie schody, natomiast jeœli analizy dotyczy³yby wyznaczenia dróg ewakuacyjnych zaleca siê wy³¹czenie z analiz wind (PN-EN 81-73:2006). Wspomniane atrybuty s¹ wymaga-ne do zbudowania zestawu danych sieciowych, bêd¹cego podstaw¹ prowadzenia analiz sie-ciowych w œrodowisku ArcGIS. W przypadku analizowanej sieci kosztem jest d³ugoœæ po-konywanej trasy. W celu dok³adnego zbadania mo¿liwoœci narzêdzia, z analiz wy³¹czono mo¿liwoœæ poruszania siê wind¹. Uwzglêdnienie jej w analizach powodowa³o wykluczenie innych wariantów dróg komunikacyjnych.

Drugi aspekt dotyczy geometrii – dane musz¹ byæ spójne i poprawne topologicznie. ArcGIS nie oferuje regu³ topologicznych dla danych 3D, dlatego w przypadku danych dotycz¹cych budynków wielokondygnacyjnych pojawia siê problem przy sprawdzaniu spójnoœci danych na po³¹czeniach miêdzy kondygnacjami: schodach i windach. Ju¿ pierwsze próby przepro-wadzenia analiz na posiadanych danych pokaza³y istotnoœæ tego zagadnienia, gdy¿ genero-wane wyniki by³y niepoprawne. Dlatego konieczne by³o zaproponowanie uproszczonego

rozwi¹zania polegaj¹cego na wyznaczeniu tras z najwy¿szej na najni¿sz¹ kondygnacjê, zak³a-daj¹c punkt startowy i koñcowy w pobli¿u jednego z ³¹czników miêdzy kondygnacjami. Jeœli trasa zosta³a wyznaczona przez wybran¹ klatkê schodow¹, wówczas mo¿na stwierdziæ, ¿e dane s¹ spójne w obrêbie tego ci¹gu schodowego (rys. 1). Czynnoœæ kontroln¹ nale¿a³o powtórzyæ dla pozosta³ych klatek schodowych i wind. W jednym przypadku trasa zosta³a poprowadzona do innej klatki schodowej, co wskaza³o na brak spójnoœci danych w jednym, b¹dŸ wiêkszej liczbie miejsc badanego ci¹gu komunikacyjnego, które nale¿a³o zlokalizowaæ i poprawiæ b³êdy w danych. Rysunek 1 pokazuje przyk³ad badania spójnoœci danych na jednej z dwóch klatek schodowych w budynku C4, bêd¹cego siedzib¹ Wydzia³u Geodezji Górniczej i In¿ynierii Œrodowiska AGH. W analizowanym budynku znajduj¹ siê dwie klatki schodowe, „boczna” – prosta dwubiegowa i „g³ówna” – ³amana trójbiegowa oraz winda. Punkty pocz¹tkowy i koñcowy zlokalizowano w pobli¿u g³ównej klatki schodowej, jednak trasa zosta³a poprowadzona przez boczn¹ klatkê schodow¹. Powodem takiego wyni-ku by³ brak spójnoœci danych w miejscu zaznaczonym czerwon¹ elips¹ (rys. 1).

Rysunek 1. Najkrótsza trasa z parteru na 5. piêtro zosta³a poprowadzona poprzez odleg³¹ od punktów

startowego i koñcowego klatkê schodow¹, w elipsie zaznaczono przerwê w ci¹g³oœci danych (Ÿród³o: opracowanie w³asne)

Wszelkie operacje zwi¹zane z popraw¹ geometrii danych 3D uda³o siê wykonaæ w aplika-cji ArcScene. Dopiero po takiej kompleksowej kontroli mo¿na by³o przyst¹piæ do w³aœci-wych analiz sieciow³aœci-wych. Rysunek 2 pokazuje poprawnie wyznaczon¹ trasê, na poprawio-nych dapoprawio-nych.

Zarówno analizy sieciowe 3D, jak i prezentacjê wyników wykonuje siê równie¿ z pozio-mu aplikacji ArcScene. Do realizacji analiz konieczne jest zbudowanie modelu z wykorzysta-niem modu³u ModelBuilder (rys. 3). Wymaga to od u¿ytkownika zaawansowanej wiedzy w zakresie budowania modeli we wspomnianej aplikacji.

W z³o¿onych wielokondygnacyjnych budynkach nale¿y u¿yæ odpowiedniej perspektywy, by czytelnie zaprezentowaæ wynik. Problem ustawienia w³aœciwej perspektywy na potrzeby wydruku 2D widoczny jest na dwóch pierwszych rysunkach. Po uwypukleniu przerwy

w ci¹g³oœci danych na rysunku 1, straci³a na czytelnoœci wyznaczona trasa. Natomiast per-spektywa przyjêta na rysunku 2 nie pozwala³a na uwidocznienie b³êdu w danych. Zdecydo-wanie korzystniej jest ogl¹daæ wyniki analiz 3D w dedykowanej aplikacji na przyk³ad Arc-Scene.

W ramach badañ wykonano wiele wariantów analiz sieciowych. Do poprawnie dzia³aj¹-cych zaliczyæ mo¿na wyznaczenie trasy z punktu A do punktu B, równie¿ z uwzglêdnieniem barier: punktowych, liniowych i poligonowych, znalezienie najbli¿szego urz¹dzenia, wyzna-czenie obszarów obs³ugi, w których wynik reprezentowany jest na sieci obiektów linio-wych. Niepoprawnie dzia³aj¹cym narzêdziem okaza³a siê opcja wyznaczenia obszarów ob-s³ugi, w której wynik reprezentowany jest w postaci poligonów zasiêgu (rys. 4). Celem analizy by³o wyznaczenie stref 50, 100 i 150 m oddalonych od punktu pocz¹tkowego zloka-lizowanego na IV piêtrze budynku. W wyniku otrzymano poligony niejako w s¹siedztwie budynku (rys. 4, widok z góry), które zosta³y utworzone na wysokoœci 0 m (zero), gdy¿ wysokoœæ krawêdzi na poziomie piwnicy budynku C4 to 243 m, pokazane jest to na rysunku 4 – widok z boku. Jako wyniku, dla wskazanej analizy, mo¿na by siê spodziewaæ utworzenia stref wewn¹trz budynku, dlatego otrzymany wynik zosta³ potraktowany jako b³êdny.

Rysunek 2. Wyznaczona trasa jest tras¹ najkrótsz¹ z parteru na 5. piêtro i zosta³a poprowadzona

poprzez w³aœciw¹ klatkê schodow¹ (Ÿród³o: opracowanie w³asne)

Rysunek 3. Model realizuj¹cy analizê poszukiwania najkrótszej trasy z punktu A do punktu B

PostgreSQL z rozszerzeniami PostGIS i pgRouting

Rozszerzenie pgRouting jest rozszerzeniem bazy danych PostgreSQL funkcjonuj¹cym jedynie z jej przestrzennym dodatkiem – PostGIS. pgRouting zawiera zbiór funkcji s³u¿¹cych do wyznaczania tras. Wœród algorytmów, opartych na teorii grafów, znalaz³y siê algorytmy: Dijkstry, Astar, Johnsona, b¹dŸ Floyda-Warshalla. W prowadzonych badaniach skupiono siê na najpopularniejszym z algorytmów – Dijkstry.

Sieæ nawigacyjna stosowana w pgRouting musi mieæ okreœlon¹ strukturê. Powinna sk³a-daæ siê z dwóch warstw: liniowej i punktowej. Zgodnie z teori¹ grafów, linia zaczyna siê i koñczy w wêŸle oraz mo¿e siê sk³adaæ z dowolnej liczby wierzcho³ków. W warstwie punktowej znajduj¹ siê wszystkie wêz³y pocz¹tkowe i koñcowe warstwy liniowej. Warstwa liniowa powinna zawieraæ okreœlone pola definiuj¹ce: identyfikator krawêdzi (id_kraw), iden-tyfikator wêz³a pocz¹tkowego (poczatek), ideniden-tyfikator wêz³a koñcowego (koniec), kieru-nek danej krawêdzi (kierukieru-nek), a tak¿e koszt przejœcia (cost). Warstwa punktowa powinna zawieraæ pole z unikalnym identyfikatorem (id_wez), który wykorzystywany jest w atrybu-tach pocz¹tek i koniec warstwy liniowej. pgRouting ma algorytmy automatycznego genero-wania warstwy punktowej na podstawie zadanej warstwy z krawêdziami, jednak sieæ wyko-rzystana w artykule przygotowana zosta³a w ca³oœci rêcznie na podstawie otrzymanych plików w formacie shapefile, z wykorzystaniem ArcGIS oraz autorskich skryptów napisa-nych w jêzyku Python.

Powodem zastosowania pó³automatycznej metody generowania sieci by³a chêæ dostoso-wania bazy do standardu IndoorGML. Utworzona baza wykorzystana zosta³a do analiz sie-ciowych na podstawie sztywno zadanego przez u¿ytkownika punktu pocz¹tkowego i koñ-cowego, mo¿e jednak w przysz³oœci staæ siê czêœci¹ sieci opieraj¹cej siê na pozycji wyzna-czanej w danym momencie. W standardzie IndoorGML wyodrêbnia siê: pomieszczenia, wê-z³y i linie. Wêwê-z³y nie s¹ tworzone przypadkowo, ale okreœlaj¹ pewne elementy budynków, takie jak: pokój, drzwi, korytarz, przejœcie, drzwi g³ówne itd. Dla zapewnienia spójnoœci bazy ka¿dy wêze³ otrzyma³ identyfikator, w którym zakodowany jest jego rodzaj. Przyk³adowo, wêz³y o numerach rozpoczynaj¹cych siê od 1 definiuj¹ pomieszczenia, a od 2 – drzwi. Funkcje pgRouting generuj¹ce sieæ nadaj¹ automatycznie identyfikatory wêz³om, dlatego nie znalaz³y zastosowania w opisywanym przypadku. Du¿o lepiej sprawdzi³ siê natomiast prosty skrypt napisany w jêzyku Python, który w warstwie liniowej wype³nia identyfikatory wêz³a pocz¹tkowego i koñcowego na podstawie porównania wspó³rzêdnych wêz³ów ze wspó³-rzêdnymi krañcowymi danej linii. Po odnalezieniu punktu, którego lokalizacja jest dok³adnie taka sama jak pocz¹tek lub koniec analizowanej linii, skrypt pobiera identyfikator punktu i wpisuje go w pole pocz¹tek lub koniec w tabeli linii.

Sieæ do wyznaczania tras wewn¹trz budynków ró¿ni siê od standardowych przypadków rozpatrywanych w pgRouting. Ma trzeci wymiar, który domyœlnie nie jest obs³ugiwany przez rozszerzenie. Aby móc z powodzeniem wykorzystywaæ algorytmy routingu równie¿ w prze-strzeni trójwymiarowej nale¿a³o w kodzie Ÿród³owym biblioteki zmieniæ wszystkie geome-tryczne funkcje wykorzystywane w algorytmach z 2D na 3D, na przyk³ad ST_Distance na ST_3Ddistance, czy ST_DWithin na ST_3DDWithin. Zalet¹ narzêdzi nale¿¹cych do grupy wolnego oprogramowania jest dostêpnoœæ kodu Ÿród³owego, dziêki czemu mog¹ one byæ dostosowywane do indywidualnych potrzeb.

Po zbudowaniu sieci istnieje mo¿liwoœæ walidacji jej poprawnoœci topologicznej za po-moc¹ funkcji pgr_analyzeGraph.

pgRouting pozwala na wykonanie wiêkszoœci oferowanych przez ArcGIS analiz siecio-wych. Jednak w wielu przypadkach osi¹gniêcie porównywalnego do ArcGIS wyniku wy-maga po³¹czenia kilku dostêpnych narzêdzi w rozbudowane zapytanie SQL.

Do wyznaczenia trasy za pomoc¹ algorytmu Dijkstry s³u¿y funkcja pgr_Dijkstra. Wej-œciowymi parametrami funkcji s¹: zapytanie SQL zwracaj¹ce zbiór rekordów z warstwy liniowej z okreœlonymi kolumnami (ID krawêdzi, pocz¹tek, koniec, koszt), identyfikatory wêz³a pocz¹tkowego i koñcowego wyznaczanej trasy oraz dwie logiczne wartoœci okreœlaj¹-ce kierunkowoœæ i sposób ustalania kosztu trasy. W wyniku otrzymuje siê zbiór rekordów z kolumnami definiuj¹cymi: kolejny wêze³ trasy, krawêdŸ, przez któr¹ przechodzi najkrótsza œcie¿ka oraz koszt przejœcia danego odcinka. Domyœlnie wynik nie zawiera geometrii, dlate-go nale¿y wykorzystaæ funkcjê SQL JOIN, która poprzez identyfikator krawêdzi ³¹czy wy-nikow¹ tabelê trasy z geometri¹ linii (rys. 5).

pgRouting umo¿liwia równie¿ utworzenie obszaru obs³ugi opisywanego w poprzednim rozdziale. Wynik mo¿na zaprezentowaæ zarówno jako poligon, jak i jako linie. Podobnie jak w ArcGIS, generowanie poligonów w przestrzeni 3D nie daje zadowalaj¹cych efektów. Bar-dziej obrazow¹ geometri¹ jest warstwa liniowa. Na rysunku 6 zaprezentowano wszystkie miejsca, dla których odleg³oœæ od zaznaczonego pomieszczenia jest mniejsza ni¿ 30 m.

System zarz¹dzania baz¹ danych PostgreSQL nie dysponuje mo¿liwoœci¹ wizualizacji danych przestrzennych, ani 2D ani 3D. Otrzymany w wyniku zapytania zbiór linii mo¿e zostaæ wyeksportowany do formatu shapefile i zwizualizowany na przyk³ad w programie

ArcGIS, jak zosta³o to pokazane na rysunku 6. Oprogramowanie firmy Esri w standardowej wersji nie pozwala jednak na dynamiczne po³¹czenie z baz¹ PostGIS i prezentacje danych bezpoœrednio z niej. Dobrym rozwi¹zaniem mo¿e byæ tutaj wolne oprogramowanie: QGIS, Geoserver, OpenLayers, które choæ trudniejsze w implementacji, daje mo¿liwoœæ dynamicz-nej prezentacji danych z bazy, równie¿ w widoku 3D (rys. 7).

Powy¿sza wizualizacja jest czêœci¹ aplikacji internetowej bazuj¹cej na bibliotece Open-Layers. Dane przestrzenne przechowywane s¹ w bazie PostGIS i przekazywane do aplikacji za poœrednictwem Geoservera. Obliczanie najkrótszej trasy realizowane jest w postaci ¿¹da-nia wysy³anego do Geoservera. W odpowiedzi uzyskiwana jest tymczasowa warstwa pre-zentuj¹ca najkrótsz¹ trasê pomiêdzy wybranymi przez u¿ytkownika pomieszczeniami. Roz-wi¹zanie to wymaga znacznie wiêkszego nak³adu pracy i po³¹czenia kilku open-sourcowych komponentów w jedn¹ spójn¹ ca³oœæ. Wynikiem jest aplikacja webowa umo¿liwiaj¹ca jedno-czesny dostêp wielu u¿ytkownikom.

Rysunek 5. Zapytanie SQL generuj¹ce najkrótsz¹ trasê pomiêdzy punktami (Ÿród³o: opracowanie w³asne)

Rysunek 6. Wizualizacja obszarów oddalonych 30 m od wyselekcjonowanego pomieszczenia

Podsumowanie

Przeprowadzone badania pozwalaj¹ na okreœlenie cech wspólnych i ró¿nic na ka¿dym z etapów prowadzenia analiz sieciowych w œrodowisku 3D. W tabeli 1 zestawiono najwa¿niej-sze cechy dla obu badanych narzêdzi.

Wnioski

W ramach badañ wykonano testy w oprogramowaniu ArcGIS z rozszerzeniem Network Analyst oraz w systemie oprogramowania bazy danych PostgreSQL z rozszerzeniami Post-GIS i pgRouting. W ka¿dym z programów próbowano przeprowadziæ kompletny proces analizy pocz¹wszy od etapu przygotowania danych a¿ do finalnej wizualizacji. Wykryte naj-wa¿niejsze cechy wspólne i ró¿nice dla obu badanych narzêdzi zestawiono w tabeli 1.

Stwierdzono, ¿e zarówno oprogramowanie komercyjne, jak i wolne oprogramowanie oferuje poprawnie dzia³aj¹ce narzêdzia do analiz sieciowych w przestrzeni 3D. W przypadku obu programów przygotowanie danych do analiz jest etapem najbardziej czaso- i praco-ch³onnym. W du¿ej mierze jest to zwi¹zane z tym, ¿e wci¹¿ jeszcze niewiele jest tworzonych zbiorów danych dla celów analiz sieciowych w budynkach. Brakuje tak¿e gotowych narzê-dzi pozwalaj¹cych na kompleksowe sprawdzenie poprawnoœci danych 3D pod wzglêdem topologicznym. Warto zaznaczyæ, i¿ przy analizach sieciowych 3D we wspomnianych na-rzêdziach wymagana jest od u¿ytkownika dodatkowa, rozszerzona wiedza. W przypadku ArcGIS bêdzie to budowanie modeli w ModelBuilder, natomiast w PostgreSQL edycja kodu Ÿród³owego oprogramowania i znajomoœæ jêzyka SQL. ArcGIS jako kompleksowy system

Rysunek 7. Wizualizacja najkrótszej trasy w przestrzeni 3D, zrealizowana w OpenLayers

pozwala na przejœcie wszystkich etapów analiz sieciowych (przygotowanie danych, analizy, wizualizacja) bez korzystania z innych narzêdzi, chocia¿ w przypadku niektórych postaci wyników (poligony) wizualizacja nie jest wykonywana poprawnie. Natomiast w przypadku rozszerzenia pgRouting z PostgreSQL etap przygotowania danych geometrycznych i wizu-alizacji odbywa siê poza baz¹ danych, w której mo¿na zrealizowaæ edycjê danych atrybuto-wych i przedmiotowe analizy.

Podziêkowania: Autorzy sk³adaj¹ serdeczne podziêkowania dwóm anonimowym

Re-cenzentom za konstruktywne uwagi.

Finansowanie: Praca zosta³a zrealizowana w ramach Badañ Statutowych nr 11.11.150.006

prowadzonych w Katedrze Geomatyki Wydzia³u Geodezji Górniczej i In¿ynierii Œrodowiska Akademii Górniczo-Hutniczej im. Stanis³awa Staszica w Krakowie.

Literatura (References)

Cichociñski P., Dêbiñska E., 2012: Badanie dostêpnoœci komunikacyjnej wybranej lokalizacji z wykorzysta-niem funkcji analiz sieciowych (Accessibility study of a selected location using network analysis func-tions). Roczniki Geomatyki t. 10, z. 4(54): 41-48, PTIP, Warszawa.

Denis F., 2015: Building Information Modelling – Belgian Guide for the construction Industry. http://www.groupseco.com/sites/default/files/the-guide-to-bim_0.pdf

Dijkstra E.W., 1959: A note on two problems in connexion with graphs. Numerische Mathematik 1: 269-271. Domínguez B., García Á.L., Feito F.R., 2012: Semiautomatic detection of floor topology from CAD

architec-tural drawings. Computer-Aided Design 44(5): 367-378.

Harris K.M., 2015: Developing a Custom ESRI Facilities Data Model: Whole Building Management Explo-ring BIM Supported GIS Model. Volume 17, Papers in Resource Analysis. 12pp. Saint Mary’s University of Minnesota Central Services Press. Winona, MN. http://www.gis.smumn.edu/GradProjects/HarrisK.pdf

S I G c r A PostgreSQL a i n e z r e z s z o r a w z a N NetworkAnalyst PostGISipgRouting h c y n a d e i n a w o t o g y z r P Wbudowanenarzêdzia Zewnêtrznenarzêdzia i c œ o n w a r p o p a l o r t n o K j e n z c i g o l o p o t e i N Tak D 3 z i l a n a e i n a n o k y W Tylkopoprzezmodel w y n a w o d u b z y z i l a n a r e d l i u B l e d o M o k l y t e w i l ¿ o m , E I N i j s r e w j e w o w a t s d o p W o g e w o ³ d ó r Ÿ u d o k i j c a k i f y d o m j e i k s r o t u a o p g n i t u o R g p a i n e z r e z s z o r y m t y r o g l a e n a w y t s y z r o k y W Dijkstry Dijkstry,Astar,Johnsona,Floyda-Warshalla : e w o i c e i s y z i l a n a e n p ê t s o D a z s t ó r k j a n a s a r T – i m a r e i r a b z a z s t ó r k j a n a s a r T – o g e z s ¿ i l b j a n e i n e i z e l a n Z – a i n e z d a z r u ) e i n i l ( u g e i s a z y r a z s b O ) y n o g i l o p ( u g ê i s a z y r a z s b O k a T k a T k a T k a T , k i n y w y n w a r p o p e i n ( k a T ) 4 . s y r k a T e i N e i N k a T S I G c r A o d e n l a w y n w ó r o p i k i n y w – k a T D 3 w u k i n y w a j c a z i l a u z i W WsystemieArcGIS ê j c a k i l p a z e z r p o p e n e c S c r A d a ³ k y z r p a n ( u k i l p o d e i c r o p s k e o P ) e l i f e p a h s waplikacjiArcScenelub s r e y a L n e p O i k e t o i l b i b u i c y ¿ u y z r p

Tabela 1. Zestawienie najwa¿niejszych cech wspólnych i ró¿nice rozszerzeñ Network Analystz

INSPIRE, 2013: D2.8.III.2 INSPIRE Data Specification on Buildings – Technical Guidelines. http://inspire.ec.europa.eu/file/1533/download?token=ouzQkBuP

Jamali A., Rahman A.A., Boguslawski P., Kumar P., Gold C.M., 2017: An automated 3D modeling of topological indoor navigation network. GeoJournal 82(1): 157-170.

Karas I.R., Batuk F., Akay A.E., Baz I., 2006: Automatically extracting 3D models and network analysis for indoors. [In:] Innovations in 3D Geo Information Systems: 395-404, Springer Berlin Heidelberg. Klepeis N.E., Nelson W.C., Ott W.R., Robinson J.P., Tsang A.M., Switzer P., Engelmann W.H., 2001: The

National Human Activity Pattern Survey (NHAPS): A resource for assessing exposure to environmental pollutants. Journal of Exposure Analysis and Environmental Epidemiology 11(3): 231-252.

Koo J., Kim Y.S., Kim B., 2012: Estimating the impact of residents with disabilities on the evacuation in a high-rise building: a simulation study. Simulation Modelling Practice and Theory 24: 71-83.

Li X., Hijazi I., Xu M., Lv H., El Meouche R., 2016: Implementing two methods in GIS software for indoor routing: an empirical study. Multimedia Tools and Applications 75(24): 17449-17464.

Open Geospatial Consortium, 2012: OGC City Geography Markup Language (CityGML) Encoding Stan-dard. https://portal.opengeospatial.org/files/?artifact_id=47842

Open Geospatial Consortium, 2016: OGC IndoorGML – with Corrigendum. http://docs.opengeospatial.org/is/14-005r4/14-005r4.html

Parkitny £., Lupa M., Materek K., Inglot A., Pa³ka P., Mazur K., Kozio³ K., Chuchro M., 2013: Koncepcja i opracowanie Geoportalu AGH (The concept and development of AGH Geoportal). Roczniki Geomatyki, t. 11, z. 3(60): 79-85, PTIP, Warszawa.

PN-EN 81-73:2006: Przepisy bezpieczeñstwa dotycz¹ce budowy i instalowania dŸwigów – Szczególne zastosowania dŸwigów osobowych i towarowych – Czêœæ 73: Funkcjonowanie dŸwigów w przypadku po¿aru (Regulations concerning the security of construction and installation of lifts – Particular applica-tions of passenger and freight lifts - Part 73 - Operaapplica-tions of lifts in the case of fire).

Pu S., Zlatanova S., 2005: Evacuation route calculation of inner buildings. [In:] PJM van Oosterom, S. Zlatanova & EM Fendel (Eds.), Geo-information for disaster management: 1143-1161, Springer Verlag, Heidelberg. S³owikowski R., Fija³kowska A., Chmiel J., 2014: System informacji przestrzennej dla wsparcia zarz¹dzania

budynkiem uczelni na przyk³adzie Politechniki Warszawskiej (GIS to support university building mana-gement – the case of the Warsaw University of Technology). Roczniki Geomatyki t. 12, z. 4 (66): 437-444, PTIP, Warszawa.

Vanclooster A., Ooms K., Viaene P., Fack V., Van de Weghe N., De Maeyer P., 2014: Evaluating suitability of the least risk path algorithm to support cognitive wayfinding in indoor spaces: an empirical study. Applied

Geography 53: 128-140.

Xiong Q., Zhu Q., Du Z., Zlatanova S., Zhang Y., Zhou Y., Li Y., 2017: Free multi-floor indoor space extraction from complex 3D building models. Earth Science Informatics 10(1): 69-83.

Yuan J.P., Fang Z., Wang Y.C., Lo S.M., Wang P., 2009: Integrated network approach of evacuation simulation for large complex buildings. Fire Safety Journal 44(2): 266-275.

Streszczenie

Wœród oprogramowania daj¹cego mo¿liwoœci przeprowadzania analiz sieciowych czo³owe miejsca zajmuj¹, bêd¹cy w ofercie firmy Esri, pakiet ArcGIS z rozszerzeniem Network Analyst oraz rozszerze-nie pgRouting dla bazy danych przestrzennych PostGIS.

Celem pracy by³o wykazanie cech wspólnych i ró¿nic, jakie wi¹¿¹ siê z prawid³owym przeprowadze-niem trójwymiarowych analiz sieciowych w tych programach oraz z w³aœciw¹ prezentacj¹ uzyska-nych wyników.

Stwierdzono, ¿e zarówno oprogramowanie komercyjne, jak i wolne oprogramowanie oferuje po-prawnie dzia³aj¹ce narzêdzia do analiz sieciowych w przestrzeni 3D. W programie ArcGIS szczegól-nie istotne by³o w³aœciwe przygotowaszczegól-nie danych 3D, czego szczegól-nie u³atwiaj¹ mo¿liwoœci edycyjne i wizuali-zacyjne dostêpnych narzêdzi. Konieczne by³o zaproponowanie w³asnego rozwi¹zania w zakresie kontroli poprawnoœci topologicznej. Analizy 3D s¹ wykonywane dok³adnie tak samo jak analizy 2D.

Jednak w praktyce okazuje siê, ¿e prezentacja wyników analiz w œrodowisku 3D jest utrudniona, a niektóre opcje dostêpne w 2D, w œrodowisku 3D nie dzia³aj¹ poprawnie.

Modu³ pgRouting domyœlnie ograniczony jest do przestrzeni dwuwymiarowej, lecz dziêki dostêpnoœci kodu Ÿród³owego mo¿liwa by³a autorska modyfikacja odpowiednich funkcji, co pozwoli³o na przejœcie do przestrzeni 3D. Baza danych przeznaczona do przeprowadzania analiz sieciowych musi spe³niaæ specyficzne wymagania stosowanych algorytmów i w zwi¹zku z tym konieczne by³o jej zbudowanie w wieloetapowym procesie, który nie w ka¿dym przypadku mo¿e byæ zautomatyzowany. PostGIS, podobnie jak inne systemy zarz¹dzania bazami danych, nie dysponuje w³asnymi narzêdziami do wizualizacji danych i wyników, dlatego niezbêdne by³o wskazanie dodatkowego oprogramowania zapewniaj¹cego tak¹ funkcjonalnoœæ.

Abstract

There are currently two pieces of software that seem to be holding the leading position in the area of network analysis, i.e. ArcGIS with Network Analyst extension by Esri and pgRouting extension for PostGIS spatial database. The aim of the study was to present the differences and similarities observed while correct execution of network analyses as well as proper presentation of results in both pieces of software are performed.

The study proved that both 3D network analysis tools offered correctly operating, commercial and open source software functionality. In ArcGIS proper preparation of 3D data was essential, which, unfortunately, was not facilitated by available editing and visualization tools. For example, proposing own solution for topological correctness was necessary. 3D analyses are performed in exactly the same way as those in 2D. However, the experience show, that presentation of results for 3D data is impeded and some options available for 2D do not work properly in 3D environment. The pgRouting module is, by default, limited to 2D space. However, the accessibility of source code allowed the authors to make own modifications of particular functions, which enabled moving to 3D. As a database designed for network analyses has to meet specific requirements concerning algorithms to be used, it was necessary to develop it in a multi-step process, which may not be susceptible to automation in each case. Similarly to other database management systems, PostGIS does not offer its own tools for data and results visualization and thus it was necessary to indicate additional software with the needed functionality.

Dane autorów / Authors details:

dr in¿. Ewa Dêbiñska

https://orcid.org/0000-0002-5152-8628 Ewa.Debinska@agh.edu.pl

dr hab. in¿. Piotr Cichociñski

https://orcid.org/0000-0002-8633-1235 Piotr.Cichocinski@agh.edu.pl

mgr in¿. Katarzyna Krystek

https://orcid.org/0000-0002-0136-3458 mazur@agh.edu.pl

Przes³ano / Received 8.01.2017 Zaakceptowano / Accepted 6.09.2017 Opublikowano / Published 30.09.2017