Ing. Pavel Veselý
Digis, spol. s r.o.
Gen.Sochora 6176
708 00 Ostrava-Poruba
tel (069) 693 8987
e-mail: pvesely@digis.cz
This paper describes some concepts of the transfer of graphic and descriptive data between GIS servers and their clients. Different solutions of data processing and data structure in GIS by ESRI, Autodesk and DIGIS are compared here. A three-layer architecture "Application Server - WWW Server - WWW Viewer" is described in detail, including its advantages and disadvantages.
Tento příspěvek popisuje různé způsoby přenosu grafických a popisných dat mezi klientem a serverem geografického informačního systému v prostředí internetu a intranetu. Rozebírá a porovnává řešení použitá v systémech ESRI ArcIMS, Autodesk MapGuide a také v systému AMEBA firmy DIGIS. Popisuje strukturu přenášených dat a způsob jejich zpracování na straně klienta systému GIS. Soustředí se především na tříúrovňovou architekturu "Aplikační server - WWW server - WWW proklížeč", popisuje její výhody, nevýhody a vlastní technické provedení v rámci systémů ArcIMS a MapGuide.
Přenos dat a jejich následné zobrazení na straně klienta je jedním ze základních stavebních kamenů každého informačního systému. V případě geografických informačních systémů je celý problém navíc značně zkomplikován daty grafickými. Jejich zpracování, přenos a následná práce s nimi na straně klienta kladou vysoké nároky na hardware i software.
Následující popis komponent systému GIS je převzat ze specifikace OpenGIS Consortium Web Map Serveru (OGC WMS). Struktura komponent systémů jiných výrobců je podobná, ne-li stejná.
Dekompozici procesu zpracování grafických dat a jejich zobrazení ukazuje obr.1.
Obr. č.1 Proces zpracování dat
Podle toho, které funkce se provádí na straně serveru a které na straně klienta se hovoří o tenkých (thin), středních (medium) a tlustých (thick) klientech. Rozdělení názorně ukazuje obr.2.
Obr. č. 2 Zpracování dat klienty
Použití toho kterého typu klienta výrazně ovlivní strukturu přenášených dat. V zásadě se dá hovořit o přenosu dat (obr. 3), přenosu grafických objektů (obr. 4) a přenosu rastrového obrázku (obr. 5).
Obr. č.3 Přenos dat
Obr. č.4 Přenos grafických objektů
Obr. č.5 Přenos obrazu
V tomto případě je na straně serveru pouze služba, která zpracovává požadavky klienta do formy dotazů do příslušného datového úložiště a obdržená data přeposílá zpátky na klienta. Data se tedy na serveru nijak nezpracovávají a veškerá práce s vykreslením grafických dat je na klientské aplikaci. Toto řešení je výhodné pouze v případě, kdy se jako klientská aplikace používá některý s robustních nástrojů (jako např. ArcInfo), která umožňuje jak prohlížení, tak i editaci a pro kterou je server skutečně jen pouhým zdrojem dat. Příkladem takovéhoto řešení je ArcExplorer/ArcInfo na straně klienta a ArcSDE na straně serveru.
Vlastní data se přenáší ve formátu stanoveném příslušným GIS. Popis struktury tohoto formátu není většinou běžně dostupný. Výjimkou z tohoto pravidla je OGC WMS, kde se data přenáší ve formátu XML dle specifikace OGC Simple Features.
Častějším případem je použití středního klienta. Toto řešení je popisováno jako dvouúrovňové, komunikace probíhá přímo mezi aplikací klienta a serveru.
Tentokrát server vygeneruje grafické objekty, které odešle na klienta. Klient tedy neobdrží pouze soubor dat jako v předchozím případě, ale obrazy objektů vytvořené podle svých požadavků. Tedy např. obraz parcely jako polygon vyplněný zadanou barvou nebo obraz ulice jako linii příslušné barvy a tloušťky.
Výhody jsou následující:
Nevýhody:
ESRI nabízí jako dvouúrovňové řešení spojení aplikací ArcExlplorer na straně klienta a aplikační server ArcIMS. Zde ArcIMS zpracovává dotazy a sestavuje grafické objekty. Ty mohou být odeslány na klienta jak ve vektorové tak v rastrové podobě. Vektorové objekty jsou odesílány ve formátu XML (přesněji ArcXML) a rastrové obrázky jsou ve formátu JPG nebo PGN.
Technicky vzato na straně severu na TCP-IP portu běží služba ArcIMS Server, která má za úkol rozdělovat dotazy podle toho, zda se jedná o dotazy na popisná data, ta pak putují na QueryServer (dotazovací server), nebo o dotazy na data grafická, ty jsou zaslány na FeatureServer (odpovědí je vektorová kresba) nebo na ImageServer (odpovědí je rastrový obrázek).
Autodesk MapGuide má na straně klienta komponentu ActiveX, která běží jako součást prohlížeče InternetExplorer. Server MapGuide je integrován jako jedna ze služeb WWW serveru. Je zapotřebí zdůraznit, že služba MapGuide slouží především pro zpracovávání a poskytování grafických dat. Přístup a práce s popisnými daty je řešen skriptovacími jazyky na straně serveru. Je možno použít ColdFusion, který je dodáván jako součást MapGuide nebo ASP či JavaScript.
Grafická data jsou uložena a přenášena jako soubory formátu MWF, který dokáže klientská komponenta ActiveX přečíst a zobrazit. Popisná data jsou dodána na klienta jako běžné HTML stránky, vygenerované podle svých zdrojů, stránek CFM, ASP apod.
Systém AMEBA nemá vlastní funkce pro zpracování grafických dat, proto musí používat jako zdroje systémy jiných výrobců. Při použití ArcIMS server AMEBA funguje jako střední klient tohoto systému. Zasílá na něj dotazy ve formátu ArcXML a přebírá odpovědi, které transformuje do podoby svých vlastních systémových objektů, propojuje s daty jiných datových zdrojů a ve formě JAVA objektů odesílá na AMEBA klienta. Ten je opět středním klientem, tentokrát systému AMEBA.
Při komunikaci mezi klientem a serverem je použito rozhraní RMI. Na straně serveru běží služba RMI Registry, která přes vybraný port TCP-IP (nejčastěji 1099) umožňuje spojení mezi JAVA klientem a serverem.
V případě tenkých klientů se jedná o přenos (a zobrazení) pouhého rastrového obrázku. Ten se vygeneruje na straně serveru přesně podle požadavků klienta, tedy nad požadovanými daty, v požadovaném formátu (GIF, JPG nebo PNG) a v požadované velikosti a následně odešle jako odpověď. Jako renderer se užívá převážně zvláštní aplikace, která běží v rámci WWW serveru. Nejčastěji se jedná o servlet (zvláštní druh JAVA aplikace). Právě tato aplikace vytváří střední úroveň ve tříúrovňové architektuře klient-WWW server-aplikační server.
Výhody tohoto řešení jsou následující:
Nevýhody:
Tříúrovňové řešení ESRI ArcIMS se sestává z aplikačního serveru ArcIMS, servletu běžícího v rámci WWW serveru a WWW prohlížeče. komunikace mezi jednotlivými komponentami je zajištěna pomocí ArcXML. WWW prohlížeč odešle dotaz na příslušnou adresu WWW serveru, kde běží servlet ArcIMS. V tomto dotazu se serveru metodou post předají parametry s názvy ArcXMLRequest a JavaScriptFunction. Tyto parametry označují jednak vlastní ArcXML dotaz a jednak některé parametry stránky, kterou servlet později vygeneruje. Servlet hodnotu parametru ArcXMLRequest odešle na alikační server a z něj pak obdrží ArcXML odpověď. Ta může obsahovat buď popisná data, nebo adresu serverem vygenerovaného rastrového obrázku. Zde ale nastává problém. Jak odeslat tato data na klienta tak, aby je dokázal zobrazit? U ESRI si s touto otázkou poradili po svém. Servlet vytvoří HTML stránku pojmenovanou PostFrame. Na této stránce je kód JavaScriptu s objektem theResponse. Jeho obsahem je pak ona ArcXML odpověď. Kromě toho je na stejné stránce příkaz, který po načtení stránky na klientovi spustí metodu JavaScriptu na stránce určené v dotazu parametrem JavaScriptFunction. Této metodě pak předá objekt theResponse. Je pak na tvůrci HTML stránek, aby do nich zakomponoval i stránku PostFrame a metodu, která z předané odpovědi dokáže vytáhnout URL adresu obrázku nebo předávaná popisná data.
Další možností, jak ArcIMS může komunikovat s WWW prohlížečem je použít WMS Connector. Tento interface na straně serveru přidává možnost komunikovat ve formátu OGC WMS.
Toto řešení je oproti ArcIMS jednodušší z několika důvodů:
MapGuide používá formát dotazu podle specifikace interface OGC WMS. Je pouze doplněný o několik málo parametrů, specifických právě pro MapGuide.
Struktura dotazů a odpovědí mezi klientem a serverem je u různých GIS velmi odlišná. Je téměř nemožné vytvořit jednoho univerzálního klienta GIS, který by dokázal zpracovat data poskytovaná různými servery GIS. Proto existují snahy o standardizaci způsobů komunikace. Jednou z nich je i projekt WMS vytvořený OGC.
Dle specifikace OGC se dotaz předává jako skupina parametrů v URL adrese serverové aplikace (servletu). Pomocí nich se určuje, zda požaduji data popisná nebo obrazová (request=map|feature_info), jaké má mít vygenerovaný obrázek rozměry (width=500&height=400), jaký má mít formát (format=PGN), které objekty mají být vybrané (select=....) atd.
Jako odpověď na dotaz přijde na klienta buď přímo vygenerovaný obrázek, nebo XML s popisnými daty.
Pro budoucí tříúrovňové řešení systému AMEBA jsme se rozhodli použít podobné řešení, jako ArcIMS. Skládá se z návrhu XML pro dotazy a odpovědi, který bude zahrnovat nejen popis struktury objektů systému AMEBA, ale i možnost komunikovat pomocí ArcXML přímo s aplikačním serverem ArcIMS. Dalším krokem bude vytvoření servletu, který umožní převod XML struktury do systémových JAVA objektů systému AMEBA a zpět. Tento servlet bude sloužit nejen jako generátor HTML stránek, ale i jko rozhraní pro přístup externích aplikací (systémů) do AMEBy.