Prostorový temporální datový model pro webový GIS. Spatiotemporal Data Model for Web GIS

Transkript

1 Abstrakt Prostorový temporální datový model pro webový GIS Spatiotemporal Data Model for Web GIS Ondřej Gojda, Jakub Konopásek Současné internetové standardy nám poskytují mnoho možností pro zpracování a manipulaci s prostorovými daty, ale potíže nastávají při použití temporálních dat. Tradiční relační databáze, široce používané v internetovém prostředí, nejsou určeny pro ukládání časových údajů a tato skutečnost nás omezuje v rozvoji dokonalejších geografických modelů. Tento článek se zabývá srovnáním několika datových modelů a přístupů k řízení temporálních dat, jejich vhodností zejména pro praktické použití, např. provádění složitých dotazů, analýz na základě zpracovávaných údajů, jakož i podpůrné konstrukce specifických datových formátů pro rozličné webové aplikace. Klíčová slova Prostorové temporální databáze, temporální datové modelování, časový údaj, webový GIS Abstract Current Internet standards provide us many options for processing and manipulation with spatial data but difficulties occur when temporal data are needed to be applied. Traditional relational databases widely used on the Internet are not designed to store temporal data and this fact limits us in developing more enhanced geographic models. This article is comparing several data models and approaches for managing temporal data, their suitability especially for practical usage, e.g. performing difficult queries, analyzing managed data as well as supporting construction of specific data formats needed by different web applications. Keywords Spatio-temporal databases, temporal data modelling, time stamping data, web GIS

2 ÚVOD DO PROBLEMATIKY Naprostá většina dat, která v současné době sbíráme, analyzujeme a používáme, jsou určitým způsobem vázána na čas a prostor. Během posledních několika let se analýza a predikce těchto dat, resp. na základě těchto dat stala velice důležitou, žádanou, vyvíjenou a všeobecně hojně využívanou. Databáze a datové modely, které umožňují správu temporálních dat, procházejí poslední dobou mnoha změnami usnadňující jejich manipulaci využívání složitějších dotazů a komplexnější analýzu. Vše toto platí alespoň o databázích a modelech separátně vyvinutých pro specializovaný software. Mnoho aplikací a řešení, které byla donedávna výsadou pouze odborných pracovišť a uživatelů, se nyní více přiblížila širší veřejnosti díky internetu. V oblasti geografických informačních systémů se ustálil termín WebGIS obecný název pro aplikace se základem v GIS, poskytovaných prostřednictvím internetu. Tyto aplikace umožňují koncovým uživatelům využít všech výhod, které s tímto řešením přichází. Zejména dosažitelnost takového systému prakticky kdekoliv s internetovým připojením a navíc bez nutnosti zakoupení a instalace specializovaného softwaru pro účely správy prostorových informací (Kopáčková 2011, Komárková 2010). Všechny operační a podpůrné funkce takovéhoto systému ovšem musí být adaptovány na všechna omezení, která internet přináší. Obecně zde není prakticky žádný problém s ukládáním statických dat, k čemuž jsou samozřejmě využity SQL databáze, jakožto nástroj jednoduše aplikovatelný v internetovém prostředí. SQL reprezentuje standardní relační datový model, který snadno dokáže ilustrovat jeden stav (stav v určitém momentu) modelovaného světa, tzv. snapshot zobrazení. Pokud je takováto databáze aktualizována, tj. alespoň jeden záznam je změněn, znamená to ztrátu předchozího stavu. Existuje ale mnoho aplikací, které běžně potřebují přístup i do předchozích, případně budoucích stavů modelovaného světa. To téměř beze zbytku platí pro všechny geografické systémy, jejichž informace v nich uložené téměř nepřetržitě procházejí určitými změnami (Burney 2010). Pokud chceme implementovat WebGIS a prezentovat jím prostorová temporální data na internetu, musíme mít přístup k aplikacím na specializovaných serverech, nebo se navrátit k původním internetovým technologiím se všemi jejich dobrými i špatnými vlastnostmi. Tento článek se snaží zhodnotit a vybrat nejvhodnější ze současných datových modelů a trendů ve zpracování temporálních dat a jejich ukládání v rámci současných internetových standardů.

3 METODIKA Základem tohoto článku bylo studium teoretických podkladů týkající se relačních databází, jejich aplikace v internetovém prostředí, dotazovacích jazyků a dále podkladů zaměřených na geografické informační systémy, a to zejména na jejich informační složku. Tým autorů poté analyzoval současnou situaci v oblasti správy temporálních dat, přičemž největší důraz byl kladen na současné trendy a technologie, které by bylo možné aplikovat do internetového prostředí. Na základě těchto poznatků byl vytvořen přehled nejpoužívanějších metod pro správu temporálních dat v relačních databázích. V závěru článku je nastíněna možná praktická aplikace probírané problematiky, kterou tým autorů plánuje realizovat v blízké budoucnosti. SPRÁVA TEMPORÁLNÍCH DAT Různé vyjádření času V temporálních databázích se vyskytují tři typy reprezentace času. Prvním z nich je tzv. platný (validní) čas, který je využíván ve většině temporálních databází. Jedná se o čas, který určuje platnost jednotlivých jevů v modelovaném světě, resp. světě modelovaném uloženými daty. Typicky je validní čas používán v souvislosti s minulostí a přítomností, ale vyskytují se i případy, kdy je validní čas určen pro budoucnost. V temporálních databázích je validní čas určen ve formě intervalu (nejčastěji je zadáno datum a čas, kdy daná událost začíná platit a kdy končí), ale v závislosti na povaze informace může jít také o samostatný bod v čase. V Tabulce č. 1 je uveden příklad, kde dva samostatné atributy začátek události ( platne_od ) a její konec ( platne_do ) určují trvání dané události. Tabulka č. 1: Začátek a konec události určen přesným časovým údajem. [Autor] udalost_id platne_od platne_do :00: :00: :15: :15: :08: :08: :10: :10: :09: :09: :18: :18: V oblasti GIS můžeme jako názorný příklad takovéto exprese času uvést plánované, probíhající, či ukončené práce na určitém úseku komunikace (vozovce). Zároveň se jedná o příklad události, která může mít nastaven svůj platný čas i v budoucnosti.

4 Další způsob, jak může být validní čas vyjádřen, je prostřednictvím jedné hodnoty (přesným časovým údajem), která vyjadřuje začátek události, a poté je jako další atribut uveden počet časových jednotek, po které má daná událost platnost (Tabulka č. 2). Tabulka č. 2: Začátek události určen přesným časovým údajem, trvání události časovou jednotkou. [Autor] udalost_id zacatek_udalosti casova_jednotka[dny] :00: :15: :08: :10: :09: :18: Pokud bychom zůstali u příkladu s prací na vozovce, vyjádření validního času pomocí začátku události a časové jednotky určující její trvání se používá především pro plánování budoucích oprav, především pak v odvětví projektového řízení. Při znalosti komplexity daného úkolu a dostupných zdrojů, celková doba trvání určité události může být přesně vypočítána (např. počet dní). Ve skutečnosti pak tyto předem vypočítané termíny nemusí být dodrženy, událost může trvat kratší nebo delší dobu, než bylo vykalkulováno. Právě tehdy (tedy pro zpětné vyjádření události) je ale vhodné použít k vyjádření platného času způsob uveden v Tabulce č. 1. Druhým typem času, který je v temporálních databázích používán, je tzv. transakční čas. Tento čas se také vztahuje k zaznamenaným událostem, ovšem nevyjadřuje jejich trvání z pohledu modelovaného světa, ale z pohledu SŘBD (Ott 2001). Jinými slovy se jedná o časový údaj, kdy v samotné databázi došlo ke změně daného záznamu (vytvoření, aktualizace, smazání). Vždy záleží na samotném databázovém systému, zda je navržen k uchovávání transakčního času, ale v naprosté většině systémy ukládají alespoň čas vytvoření nového záznamu. Tabulka č. 3 znázorňuje ukládání transakčního času, konkrétně datum poslední modifikace záznamu a uživatele, který změnu provedl (Tang 2010, Atay 2010).

5 Tabulka č. 3: Čas modifikace (transakční čas). [Autor] udalost_id zmeneno uzivatel :13:20 user :53:34 user :25:11 admin :41:09 user :35:47 admin :18:28 user Posledním typem času v temporálních databázích je tzv. uživatelský čas (user-defined). V zásadě se jedná o jakýkoliv jiný časový údaj, který chceme ukládat, ale který zároveň žádným způsobem neovlivňuje oba výše zmíněné (validní a transakční) (Combi 2010). Různé typy prostorových temporálních databází a jejich užití V závislosti na tom, zda databáze obsahuje validní, transakční, uživatelský čas, nebo kombinaci všech, diferencujeme několik typů temporálních databází. Tzv. snapshot databáze obsahují pouze uživatelský čas. Reprezentují pouze jeden pohled (momentku snapshot) na modelovaný svět. Valid-time databáze obsahují pouze validní čas, tzn., historie změn databáze není ukládána. Transaction-time databáze (rollback) ukládají pouze transakční čas. V praxi se nejčastěji používají tzv. bitemporální databáze, které kombinují ukládání validního i transakčního času (Combi 2010). Různé úrovně zaznamenávání faktoru času K zaznamenávání času v temporálních databázích je využíváno tří hlavních přístupů. Liší se tím, na které úrovni samotný faktor času integrují do databáze. První z nich integruje čas na úrovní celé relace. V praxi to znamená, že při každé změně modelovaného světa se vytvoří jeho kompletní nová instance snapshot (se zaznamenanou změnou). Tento přístup je výhodný z hlediska jednoduchosti vyhledávání informací o stavu modelovaného světa v jednotlivých bodech v čase. Problém ovšem nastává, pokud chceme z databáze získat data časových řad. Velkou nevýhodou tohoto přístupu je též vysoká redundance dat, která vzniká při každé nové instanci modelovaného světa (Atay 2010, Revesz 2010). Druhý přístup integruje čas na úrovni řádku. Každý řádek v temporální databázi tak má svůj atribut času, ať už se jedná o validní, transakční, či kombinaci obou. Tento způsob integrace času eliminuje vysokou míru redundance dat, i když ne úplně (jak je uvedeno níže). V praxi se tedy při každé změně určitého objektu modelovaného světa vytvoří v databázi pouze nový řádek (resp. jeho kopie) se změnou objektu, ale ostatní nezměněné se již neduplikují.

6 skupina_zmen_1 atribut_3 atribut_2 skupina_zmen_1 atribut_1 validni_cas objekt_id událost_id Pokud má v sobě každý záznam integrován validní čas, stále je možno jednoduše vygenerovat snapshot takovéto databáze pohled na požadované objekty v požadovaném čase. Příklad takovéhoto dotazu je následující: SELECT * FROM temporali_tabulka WHERE platne_od < "pozadovane_datum" and (platne_do > "pozadovane_datum" or platne_do IS NULL) Jak již bylo řečeno, tento přístup neeliminuje redundanci dat úplně. Pokud existuje tabulka se záznamy, které mají více než jeden atribut a zároveň jsou tyto atributy na sobě nezávislé, tzn., mohou se měnit v čase nezávisle na sobě, při každé změně jednoho z nich se vždy vytvoří redundantní data dalšího atributu (příp. dalších atributů, pokud jich je více), který zůstal beze změny. Toto má za následek i poměrně složitou konstrukci dotazů na historii určitého objektu (Viqueira 2007). Jednou z možností, jak se tomuto problému vyhnout, je integrovat do tabulky pomocné atributy zaznamenávající změny skupin atributů, které se v čase vždy mění společně. Příklad zmíněných atributů je ilustrován v Tabulce č. 4. Tabulka č. 4: Skupiny atributů měnících se vždy společně. [Autor] A 1 J X A 0 K Y B 1 K Y 0 Atribut 1 patří do Skupiny změn 1. Atributy 2 a 3 patří do Skupiny změn 2. Díky těmto sloupcům je možno jednoduchým dotazem získat informaci o tom, ve kterém roce došlo ke změně (Ott 2001). Další možnost, jak v rámci přístupu integrace faktoru času na úrovni řádku můžeme eliminovat redundanci na nejnižší možnou úroveň, je rozdělení relace do více tabulek. Na druhou stranu tento proces rezultuje do potřeby mnohem vyšší komplexity a složitosti dotazů týkajících se objektů měnících se v čase. K získání jednoduché informace o jednom objektu v jednom bodě v čase, je nutno dotazem nejdříve spojit všechny relevantní relace do jedné a teprve poté vyhledat požadovanou informaci.

7 Třetí přístup integruje faktor času na úrovni atributu, použitím tzv. vnořených dat. Každý atribut, který uchovává informaci měnící se v čase, je doplněn o vnořený atribut, ve kterém je uložen časový údaj, kdy ke změně příslušného atributu došlo. Tento přístup úplně eliminuje redundanci dat, ale není v souladu s relační datovou normalizací. Pro práci s tímto datovým modelem je třeba využít databáze a dotazovací jazyky, které s vnořenými časovými umí pracovat, což tradiční relační databáze používané ve webovém prostředí nedokážou (Atay 2010, Goralwalla 1995). SPRÁVA ČASOPROSTOROVÝCH DAT Při práci s časoprostorovými údaji obvykle chceme aplikovat tři typy úkonů. Třídit, spravovat a ukládat tyto údaje k těmto činnostem se obvykle používá SŘBD (systém řízení báze dat). Dále tyto údaje chceme analyzovat, zpřesnit, případně transformovat do podoby vhodné pro naše konkrétní potřeby k tomuto se obvykle používají skripty nebo programy s algoritmy specializovanými konkrétně na problematiku, kterou chceme řešit. V neposlední řadě často požadujeme zobrazit vybrané části dat potřebné k analýze, nebo prezentaci výsledků pro koncového uživatele. Pro práci s prostorovými daty existuje několik softwarových aplikací, které jsou na výše uvedené úkony specializovány. Jedním z nejvíce používaných GIS softwarů je ArcGIS Desktop od firmy ESRI (MyTopDozen 2013). Databázový systém ArcGIS ArcGIS obsahuje svůj vlastní databázový systém, analytické nástroje a také je schopen vizualizovat jak vektorové, tak rastrové mapy různými způsoby, připravit je k tisku, případně je exportovat do různých formátů. Ačkoliv jsou tyto programy ideální pro analýzu klasických GIS dat, obvykle postrádají schopnosti řídit temporální data. Dílčí nástroj pro práci s časovými daty byl do programu ArcGIS Desktop přidán až v poslední verzi ArcGIS 10 (Esri 2013). Ovšem ani tyto komplexní programy obvykle nemají schopnost vytvářet složité editovatelné webové aplikace s možností interaktivních pohledů na zpracovávaná data. Pokud takovou možnost zmíněné produkty nabízejí, děje se tak prostřednictvím specializovaného GIS serveru - jako je např. ArcGIS Server (samostatná aplikace pro ArcGIS Desktop). To s sebou přináší jak nekompatibilitu s jinými systémy, tak samozřejmě i vyšší finanční nároky na pořízení a provoz takovéto konkrétní technologie. Pokud chceme vytvořit komplexní webové aplikace, které lze bez problému připojit k jiným databázím a systémům obsahující temporální GIS data, a zároveň nechceme být závislí na specifickém GIS serveru, musíme použít samostatné nástroje upravené pro zpracování, vizualizaci a publikování těchto časových GIS dat na webových stránkách.

8 Existuje několik přístupů a aplikací, které toto umožňují. Mnohé z nich jsou výsledkem vědeckého výzkumu v oblasti časových databází, zobrazení GIS dat atd. Tyto aplikace používají různé SŘBD a další nástroje pro vytvoření finálního webového rozhraní pro koncového uživatele. Dynamické webové aplikace Nejběžnějšími relačními databázovými systémy pro webové stránky a jejich příslušné skriptovací jazyky jsou MySQL a Oracle. Oba jsou v souladu se základními relačními normami a mají mnoho funkcí pro práci s daty, včetně několika prostorových funkcí a testování prostorových vztahů (SolidIT 2013). Pro práci s databází je třeba serverově orientovaný skriptovací jazyk, který umožní vytvářet dynamické webové aplikace. Nejpopulárnější jazykem je v současné době PHP. Disponuje rozsáhlou sadou funkcí pro komunikaci s MySQL, Oracle nebo jinou relační databází, a také existuje mnoho webových aplikací umožňujících práci s databázemi a tabulkami pomocí grafického rozhraní, např. phpmyadmin (Pultar 2010). Skriptovací jazyk nám umožňuje vytvářet dynamické dotazy na data v databázi a vytvářet požadovaný výstup - ať už se jedná o data, která chceme exportovat do ArcGIS pro analytické účely, nebo jako výstup pro koncovou webovou aplikaci. Pro efektivní interaktivní zobrazení dat na straně klienta existuje v podstatě pouze jeden hlavní jazyk používaný k tomuto účelu, a to je java-script (Pultar 2009, Ye 2010). VYTVOŘENÍ WEBOVÉ APLIKACE POUŽÍVAJÍCÍ DATA Z TEMPORÁLNÍ DATABÁZE K vytvoření webové stránky pro zobrazení časoprostorových dat musíme nejprve převést tato data do datového modelu, který nám je umožňuje snadno aktualizovat a aplikovat požadované dotazy. Základní přístup je vytvořit tabulku, která integruje faktor času na úrovni n-tice (řádku) a v závislosti na tom, jak se údaje mění v čase, povolit určitý druh redundance nebo rozdělit konkrétní tabulku do více tabulek se skupinami atributů, které se vždy mění společně. V rámci našeho výzkumu se v současné době snažíme aplikovat různé datové modely při práci s daty v případové studii, která má za úkol provádět testování rychlosti různých datových modelů - srovnání jejich schopnosti přizpůsobit dotazy, snadno spravovat data pro použití v GIS aplikacích, a dále schopnost vizualizace těchto dat pro koncového uživatele. V předběžném výzkumu jsme porovnávali různé webové GIS aplikace a zjistili jsme, že většina z nich zpracovává časoprostorové údaje ve formě jedné tabulky s časovým razítkem pro každý řádek, ve formě platného času (valid time). Většina z těchto aplikací pak umožňuje uživateli zobrazit objekty na podkladové mapě ve vybraném momentě v čase. Obvykle je

9 umožněno uživateli zapnout a vypnout různé vrstvy a nastavit si požadovaný čas formou slideru, tak jak je zobrazeno na Obrázku č. 1. Obrázek č. 1: Časový posuvník v aplikaci ArcGIS 10.[Autor] Náročnější aplikace umožňují uživateli specifikovat časový rámec a zobrazit všechny objekty, které mají platný čas v tomto časovém rámci. Pokud jde o konkrétní formy údajů, které tyto programy používají a se kterými pracují, ty se liší napříč aplikacemi. Většina open-source aplikací používá Keyhole Markup Language (KML), jež je specifická mutace XML, speciálně navržená pro vyjádření geografických informací. Mezi další používané formáty patří GeoRSS, Google spreadsheets, GeoJSON, případně další formáty určené pro specifické aplikace, jako je například ArcGIS shapefile. Každá z těchto formátů má různou míru komplexnosti, která umožňuje další využití zpracovávaných dat. Nejjednodušší aplikace nabízí režim správy pouze základních prostorových souřadnic s datem, názvem a popisem. Další skupina vyspělejších aplikací dokáže spravovat všechny

10 časové údaje v samostatně odděleném souboru, případně tabulce. Poslední skupina aplikací časové údaje diferencuje na úrovni vrstev. V naší případové studii jsme pomocí PHP skriptu ve fázi testování výpisů požadovaných údajů z modelové databáze MySQL. Výsledné datové šablony pak plánujeme převádět do nejpoužívanějších formátů, se kterými operují webové client-side aplikace a GIS. Zejména plánujeme porovnat čas potřebný ke zpracování různých dotazů na různých datových modelech, a čas potřebný pro transformaci výsledků z těchto dotazů do různých výše zmíněných datových formátů. V současné době provádíme již zmíněnou konverzi zkušebních dat do několika datových modelů, které byly vytvořeny pro účely této případové studie. V současné chvíli jsou všechny datové modely založeny na ukládání času jako atributu na úrovni řádku, ale zároveň byly aplikovány různé úrovně redundance dat v těchto datových modelech. Prostřednictvím testů plánujeme zjistit dopad množství redundance dat na rychlost složitějších dotazů a jejich schopnost umožnit snadný přístup k důležitým datům. Z dosavadních výsledků testů provedených na vzorku (relační tabulka čítající 150 řádků) můžeme konstatovat, že výše uvedené testovací procesy vykazují lepší výsledky u modelů, v nichž je aplikována vyšší míra redundance dat. Jak jsme očekávali, u takto malého vzorku dat nebyly výrazně zpomaleny ani procesy, které vyžadovaly například dodatečnou transformaci zpracovávaných dat rozložením složitějších dotazů skriptovacího jazyka na jednodušší. Dále očekáváme, že při aplikaci stejných datových modelů (s vyšší mírou redundance dat) na relace s vyšším celkovým objemem dat bude zřetelně zpomalovat zejména složitější dotazy. Zajisté bude zajímavé porovnání těchto zmíněných datových modelů, s modely vyhovujícími datové normalizaci. Samotné porovnání bude kvantifikováno pomocí multi-kriteriální analýzy a budou mezi sebou porovnány výsledky všech zmíněných datových modelů při aplikaci různého množství dat a různých typů dotazů. Mimo jiné bude naším cílem stanovení mezních hodnot vhodnosti jednotlivých modelů v závislosti na množství zpracovávaných dat. NAVIGAČNÍ APLIKACE Na základě výše popsaného výzkumu v oblasti temporálních datových modelů pro webové prostředí chceme aplikovat získané znalosti k vytvoření webové platformy (geografického informačního systému), která bude kombinovat mapu kampusu, navigační nástroje a školní informační systém IS Studium ČZU v Praze. Tento WebGIS bude především určen pro nově příchozí studenty (1. ročníky) a bude mít za cíl poskytnout jednoduchou a intuitivní orientaci na území univerzitního kampusu. Hlavní myšlenkou bylo vytvořit interaktivní mapu dané oblasti, zejména vnitřní mapy všech univerzitních budov, včetně příslušných údajů z integrovaného školního informačního systému, které jsou relevantní ve smyslu navigace a orientace, v první řadě rozvrhy hodin jednotlivých učeben, konzultační hodiny učitelů atd. Tato uvedená data jsou k dispozici v

11 informačním systému, ale problém je, že se mění minimálně jednou za semestr při změně rozvrhu. Tato dynamická součást plánovaného WebGISu vytváří potřebu najít způsob, jak přenášet a transformovat data z databází školního informačního systému do formy vhodné pro webovou mapovou aplikaci. Jádro plánovaného WebGISu se skládá ze dvou základních komponent. První z nich je temporální databáze a druhá je podrobná vektorová mapa univerzitního kampusu, včetně vnitřních plánů jednotlivých budov. Temporální databáze bude založena zejména na výzkumu popsaného v tomto článku. Mapová složka bude vytvořena kombinací několika metod. Jako základní mapa bude použita open-source platforma OpenLayers. Vzhledem k tomu, že oblast našeho univerzitního kampusu není v této platformě příliš dokonale zaznamenána, bude třeba opravit a aktualizovat všechny nepřesnosti ručně pomocí přenosného GPS modulu s následným zakreslením do mapy. Vnitřní plány budov nám již byly poskytnuty Provozně technickým odborem ve formě technických výkresů CAD. Z těchto souborů byly extrahovány příslušné vrstvy a implementovány do podkladové mapy. Tento proces se provádí v ArcGIS 10 a výsledné vrstvy jsou exportovány do formátu KML, který je platformou OpenLayers podporován. V současné době je k dispozici pilotní verze mapy z vyvíjeného WebGISu zobrazující jedno patro Provozně ekonomické fakulty. Všechny polygony (učebny, kanceláře a chodby) byly převedeny do vektorů manuálně, ale v budoucnu plánujeme tento proces zautomatizovat. Nabízí se několik možností automatizace, jako nejefektivnější se prozatím zdá automatická klasifikace obrazu v ArcGIS. ZÁVĚR V současné době jsme ve fázi průběhu případové studie testující různé datové modely. Vytvořili jsme skript v PHP, který používá vlastní šablony pro zpracování výsledků SQL dotazů. To nám umožňuje testovat rychlost a odezvu potřebnou k vytváření různých formátů temporálních geografických datových souborů. Rádi bychom výsledky probíhajícího a plánovaného výzkumu dostali do formy metodiky určené pro výběr a implementaci temporálního datového modelu speciálně pro WebGIS. Získané znalosti jsou průběžně zpracovávány a implementovány do prozatím pilotní verze navigační aplikace (viz výše), kterou tým autorů v budoucnu plánuje dokončit do podoby funkčního GIS pro kampus ČZU v Praze. PODĚKOVÁNÍ Tento článek byl vytvořen za podpory grantového projektu IGA PEF ČZU v Praze: Metodika návrhu relační databáze a webového rozhraní pro dynamický GIS, č Tým autorů tuto podporu s poděkováním oceňuje.

12 LITERATURA C. E. Atay, A Comparison of Attribute and Tuple Time Stamped Bitemporal Relational Data Models, in Proceedings of the International Conference on Applied Computer Science, Las Vegas, A. Burney, N. Mahmood a K. Ahsan, TempR-PDM: a conceptual temporal relational model for managing patient data, in AIKED'10 Proceedings of the 9th WSEAS international conference on Artificial intelligence, knowledge engineering and data bases, Stevens Point, WSEAS Press, 2010, pp C. Combi, E. Karavnou-Papiliou and Y. Shahar, Temporal Databases, in Temporal information systems in medicine, New York, Springer US, 2010, pp Esri, What's new for temporal data in ArcGIS 10, Esri, [Online]. Available: htm. [Accessed 2013]. I. A. Goralwalla, A. U. Tansel and M. T. Özsu, Experimenting with Temporal Relational Databases, in Proceedings of the 1995 ACM CIKM International Conference On Information And Knowledge Management, New York, J. Komárková, P. Sedlák, M. Novák, A. Musilová a V. Slavíková, Problems in Usability of Web- Based GIS, in Proceedings of the International Conference on Applied Computer Science (ACS), Athens, WSEAS Press, H. Kopáčková, H. Jonášová, I. Mikešová a J. Hejlová, Gathering of Requirements on WebGIS Development - the Example of Bikeway Mapping Application, in Recent Researches in Circuits, Systems, Communications and Computers: Proceedings of the 2nd European Conference of Computer Science (ECCS'11), Stevens Point, WSEAS Press, 2011, pp MyTopDozen.com, MyTopDozen, MyTopDozen.com, [Online]. Available: [Accessed 2013]. T. Ott and F. Swiaczny, Time-Integrative Geographic Information Systems, Berlin: Springer Verlag, E. Pultar, T. J. Cova, M. Yuan and M. F. Goodchild, EDGIS: a dynamic GIS based on space time points, in International Journal of Geographical Information Science, vol. 24:3, pp , E. Pultar, M. Raubal, T. J. Cova and M. F. Goodchild, Dynamic GIS Case Studies: Wildfire Evacuation and Volunteered Geographic, in Transactions in GIS, vol. 13(s1), p ,

13 P. Revesz, Temporal Databases, in Introduction to Databases, London, Springer-Verlag, 2010, pp solid IT, DB-Engines Ranking of Relational DBMS, solid IT, [Online]. Available: [Accessed 2013]. Y. Tang, X. Ye and N. Tang, Temporal Information Processing Technology, New York: Springer Heidelberg, J. R. R. Viqueira and N. A. Lorentzos, SQL extension for spatio-temporal data, in The VLDB Journal, vol. 16(2), p , X. Ye, Z. Peng and H. Guo, Spatio-Temporal Data Model and Spatio-Temporal Databases, in Temporal Information Processing Technology and Its Application, Berlin, Springer Berlin Heidelberg, 2010, pp