Seminární práce z předmětu Prostorové databáze (PDB)
srpen 2008
| Přehled revizí | ||
|---|---|---|
| Revize 1.1 | 27. dubna 2009 | Pejša Jiří |
|
Zapracování připomínek Ing. Karla Jedličky z 8.4.2009.
| ||
| Revize 1.0 | 15. února 2009 | Pejša Jiří |
|
První verze dokumentu ke zpřipomínkování. | ||
Anotace / Annotation
Tato práce se zabývá databázovou kartografií. Jsou představeny dvě různé oblasti databázové kartografie — Multi-resolution databáze a kartografická vizualizace databází. Multi-resolution databáze je řešením (polo)automatizované aktualizace subdatabází různých úrovní podrobnosti odvozovaných na podkladě jediné aktualizované "master" databáze. Kartografickým vizualizacím je pak věnována značná část této práce. Nejprve se zaměřuje na obecné požadavky databázové kartografie a zkoumá stav SW na trhu. Velká pozornost je pak věnována databázové kartografii v pojetí ESRI - jsou představeny kartografické reprezentace a prozkoumáno jejich uložení v databázi.
This thesis deals with database-driven cartography. There are described two areas of database-driven cartography — Multi-resolution database and cartographic visualization of databases. Multi-resolution database is the solution of (semi)automatic update of subdatabases with different levels of resolution which are derived from single updated master database. Great deal of the thesis examines cartographic visualization of databases. Firstly, it describes general requirements of database-driven cartography and examines available software. Much attention is devoted to database-driven cartography with ESRI conception. There are described cartographic representations with the help of a practical example and further is examined how they are saved in the geodatabase.
Obsah
Seznam obrázků
- 2.1. Architektura propojených databází
- 2.2. Integrované databáze (Integration database)
- 2.3. Struktura spojení (Link structure)
- 2.4. Algoritmus Buffer growing
- 3.1. Ukázka prvního vydání ZM10 (digitální technologií)
- 3.2. Postup tvorby Základní mapy 1:10 000 na podkladě ZABAGED®
- 3.3. Více databází - více kartografických modelů
- 3.4. Geometrie železnice a silnice zobrazená pouze symbologií
- 3.5. Atributová tabulka vrstvy silnic před vytvořením CR
- 3.6. Železnice a silnice po přiřazení RR
- 3.7. Atributová tabulka vrstvy silnic po přiřazení CR
- 3.8. Železnice a silnice po udělení výjimek
- 3.9. Železnice a silnice s výjimkami a jejich geometrie
- 3.10. Železnice a silnice po udělení výjimek
- 3.11. Datové typy sloupců RuleID a Override
- 3.12. GDB_EXTENSIONDATASETS
- 3.13. Atributy a jejich datové typy GDB_EXTENSIONDATASETS
- 3.14. GDB_NETDATASETS v9.1
- 3.15. GDB_EXTENSIONDATASETS v9.2
- 3.16. GDB_EXTENSIONDATASETS v9.3
- 3.17. Data tabulky GDB_FEATUREDATASET
- 3.18. Prvkové datasety (Feature Dataset) pokusné databáze
- 3.19. GDB_EXTENSIONDATASETS po vytvoření několika CR a síťového datasetu
- 3.20. Upozornění při zápisu změny RR do geodatabáze
- 3.21. Postup vykreslení prvku s dvouvrstvým RR
- 3.22. Datové typy sloupců tabulky (vrstvy) RailrdL po přiřazení CR
- 3.23. Datové typy sloupců tabulky (vrstvy) RailrdL po přiřazení CR
- 3.24. Ukázka kódu bodové vrstvy s udělenou výjimkou z geometrie
- A.1. Systémové tabulky geodatabáze ArcSDE 9.2
- A.2. Systémové tabulky síťových datasetů pro SQL Server -výřez
- A.3. Systémové tabulky geodatabáze ArcSDE 9.3
- A.4. Systémové tabulky geodatabáze ArcSDE 9.1
- A.5. Porovnání binárního kódu CR s jedním RR versus se dvěma totožnými RR
- A.6. Zobrazení stylu v Accessu
- A.7. Zobrazení stylu v ArcCatalogu
- A.8. Porovnání XML schematu vrstvy před a po přiřazení CR
- A.9. Porovnání XML schematu vrstvy před a po přiřazení CR
- A.10. Porovnání XML schematu vrstvy před a po přidání kopie RR
- A.11. Porovnání XML schematu vrstvy před a po přidání efektu do RR
- A.12. Porovnání XML schematu vrstvy před a po přidání kopie CR
Seznam tabulek
Další rozvoj kartografie a mapové tvorby bude stále více svázán s vektorovými datovými bázemi a geografickými informačními systémy. Tradiční postupy kartografické tvorby nemají šanci obstát v době informačních technologií. U většiny producentů je již nahradily postupy, v nichž výpočetní technika hraje dominantní roli. V mnoha případech však jde o singulární řešení šitá na míru, která postrádají integritu (celistvost) a jsou často časově neefektivní. Těžko tak mohou naplňovat požadavek aktuálních digitálních, a tím méně analogových, map.
Na využití vektorových datových bází můžeme pohlížet z různých úhlů. V oblasti GIS jsou báze geodat využívány v širokém spektru činností, jejichž výsledky jsou jednoduchými způsoby vizualizovány. Kartografie přistupuje k bázím geodat jako k podkladu, pro tvorbu analogových či digitálních kartografických výstupů. Důraz je kladen na kartograficky správné výstupy.
Pojem Databázové kartografie bychom spíše zařadili do druhého jmenovaného přístupu, avšak je třeba podotknout, že oblasti GIS a kartografických výstupů jsou, a stále více budou, úzce propojeny.
V samotné oblasti Databázové kartografie lze vypozorovat dva hlavní procesy:
- Tvorba a odvozování Multi-resolution databáze
Postup při automatizované aktualizaci geografických databází různých úrovní podrobnosti (měřítek). V tomto referátu se o této problematice pouze stručně zmíníme v kapitole 2 – „Multi-resolution databáze“.
- Tvorba kartografických výstupů (kartografického modelu) na podkladě databáze
Proces tvorby kartografického modelu nad geodatabází (symbolizace) je hlavním předmětem kapitoly 3 – „Kartografická vizualizace geodatabází“.
Obsah
Následující kapitola stručně referuje o poznatcích německých kolegů ohledně této problematiky, publikovaných v článku [Istanbul 2004].
V současnosti je mnoho kartografických modelů udržováno v různých databázích různých úrovní podrobnosti. To způsobuje značnou neefektivitu a nekonzistenci při jejich aktualizacích. Řešením může být multi-resolution (déle M-R) databáze, která provazuje databáze různých podrobností vzájemným propojením odpovídajících si objektů. To by umožnilo aktualizovat pouze databázi s nejvyšším rozlišením a následná aktualizace databází s vyšším rozlišením by mohla proběhnou poloautomatizovaně.
Budování M-R databáze lze rozdělit do následujících kroků [Istanbul 2004]:
Určení sad (vrstev) propojovaných objektů a jejich klasifikace,
Geometrický výpočet odpovídajících si objektů,
Automatický výběr správně rozpoznaných spojení na podkladě připravených pravidel,
Ruční výběr automaticky nerozpoznaných spojení.
Pro udržení kvality původních datových sad je vhodné udržovat je odděleně od databáze, která vznikne jejich spojením[1]. Z toho důvodu je vhodná architektura propojených databází[2]. To umožňuje nezávislost originálních databází[3] a zachování přístupu lokálních aplikací. Tyto databáze jsou spojeny tzv. propojující vrstvou[4], která zajišťuje přístup globálních aplikací. Tato vrstva udržuje propojení odpovídajících si objektů a metadata pro přístup a pro procesy (např. generalizace, párování..).
2.1.1. Struktura propojující[5] databáze
Objekty v jedné databázi nemusí odpovídat objektům v druhé jedna ku jedné z důvodu různých datových modelů či různé podrobnosti. Proto je třeba aby se struktura pro uchovávání spojení dokázala vypořádat s vazbami kardinality N:M, 1:N i 1:1 (viz následující obrázek):
Požadavek je zajištěn následovně: sady objektů reprezentujících reálný objekt v první databázi, jsou modelovány jako spojené objekty, které jsou asociovány operací párování s odpovídajícím spojením objektů z druhé. Topologické vztahy mezi jednotlivými objekty jsou modelovány jako třída vztahů.
Proces propojování odpovídajících si objektů v obou databázích sestává z několika kroků:
Sémantická klasifikace (Semantic classification)
Aplikace algoritmu Buffer growing
Výběr (Selection)
Účelem této klasifikace je sémantická analýza dat, které mají být vstupem v procesu párování. Dojde k oddělení všech vrstev, které určitě nereprezentují stejné objekty. Výstupem této operace jsou tedy tzv. sady hrubě spárovaných vrstev (coarse class matching).
Dále je vhodné analyzovat, zda není možné tyto sady ještě dále rozdělit na disjunktní množiny, abychom získali menší sady pro porovnávání. Popis sémantické klasifikace je uložen v integrované databázi (viz obrázek 2.2 – „Integrované databáze (Integration database)“).
Jedná se o algoritmus vhodný pro vyhledání párových liniových prvků. Je založen na předpokladu, že odpovídající si objekty mají podobnou polohu.
Princip (viz obrázek 2.4 – „Algoritmus Buffer growing“): Kolem každého prvku v jedné databázi je vytvořena obálka (buffer). Všechny objekty v druhé databázi, které plně spadají do této obálky jsou vyhodnoceny jako kandidáti na propojení. V případě, že se nějaký prvek protíná hranici dvou obálek a nespadá tedy ani do jedné, jsou prvky v první databázi spojeny a je vytvořena nová obálka kolem tohoto prvku. Následně jsou jako kandidáti na spojení vyhodnoceny i zbývající prvky, pokud se nachází uvnitř obálky. Prvky, které se již nachází v množině kandidátů již vyhodnocovány nejsou.
V předchozím kroku získáme množinu kandidátů na spojení. Nyní je třeba rozhodnout, které z nich mohou být potvrzeny jako správné a které vyřadit jako chybné.
Pokud je jeden prvek součástí dvou nebo více dvojic kandidátů, dochází ke konfliktu a všechna zúčastněná spojení jsou označena jako chybná. Na druhou stranu, pokud dvojice kandidátů splňují kladené kvalitativní požadavky (viz dále) a nejsou s jinými v konfliktu, mohou být označeny jako správné.
Automatizovaný výběr spojení, které budou označeny jako správné či chybné, lze provádět pomocí kvalitativních pravidel. Jedná se o parametry určující míru podobnosti dvou prvků (například délka, podobnost názvů atd.).
Nejprve je nutné spočítat všechny parametry kvality, pro všechna kritéria a pro všechny kandidátní dvojice. Dále existuje mnoho způsobů, jak rozhodnout, které řešení použít:
Jako řešení bude vybrána kombinace s nejvyšším součtem míry podobnosti (výpočetně náročné).
Je stanoven práh a všechna spojení s nižší mírou podobnosti jsou označena jako chybná.
Postupovat jako v předchozím bodě s tím rozdílem, že je stanoven maximální a minimální práh. Dále se postupuje iterativně od maximálního prahu k minimálnímu, přičemž při každé iteraci jsou zjemněny množiny chybných a správných spojení.
Pro liniové objekty vede tento iterativní proces k dobrým výsledkům, pokud je jako kritérium uvažována "podobnost délek". Práh je tedy definován jako maximální hodnota podílu délek.
Výsledkem automatizovaného výběru jsou ještě kandidátní dvojice, které nemohly být automaticky označeny jako správné, či chybné. Jedná se například o dvojice, které splňují všechny kvalitativní požadavky, ale jsou v konfliktu s jinými objekty. V tomto případě je již nutné, rozhodnutí nechat na operátorovi.
Ruční aktualizace (kartografických) databázových modelů různých měřítek jsou procesy náročné na čas a lidskou práci, které navíc mohou vést k nekonzistenci těchto bází geodat. Řešením může být tzv. Multi-resolution databáze, která udržuje propojení odpovídajících si objektů v těchto databázích. Následná aktualizace pak může být značně usnadněna zavedením změn pouze v databázi, která je nejpodrobnější a následným promítnutím změn do všech menších měřítek.
V kapitole jsou shrnuty poznatky z článku [Istanbul 2004]. Autoři představují jednu z možných architektur realizující Multi-resolution databázi. Dále jsou představeny a realizovány algoritmy pro liniové prvky, které lze použít při budování této databáze.
Jedná se o problematiku, která sotva kdy bude realizována zcela automatizovaně. Avšak rostoucí informatizací při budování, údržbě a publikování kartografických děl, lze v budoucnu očekávat výzkum a konkrétní realizace Multi-resolution databází.
Obsah
V kapitole se nejprve zaměřím na to, jak by mohl takový ideální kartografický software vypadat (částečně čerpáno z [Hardy_SW] a [Neuffer Swisstopo]) a na řešení dostupná v současnosti. Dále stručně popíši technologickou linku výroby Základní mapy 1:10 000 a zmíním univerzální datový model multi-databázové technologické linky. V závěru se podrobně zabývám ESRI řešením databázové kartografie - kartografickými reprezentacemi a jejich uložením v geodatabázi.
Univerzální software pro kartografy neexistuje a dosud nikdy neexistoval, nicméně možnosti se stále rozšiřují a kartografové se mohou na jeho vývoji podílet. Při tvorbě bází geodat je často opomíjen fakt, že slouží nejen pro účely širokého spektra činností GIS, ale také pro účely kartografické vizualizace. To ztěžuje práci kartografům, kteří často tyto databáze využívají pro účely tvorby mapových výstupů. Kartografové by se tedy měli angažovat i v oblasti navrhování bází geodat.
V současnosti se při vytváření map využívá jak možností geografických informačních systémů (GIS), tak grafických programů:
- Role GIS
GIS je používán pro správu primárních dat, jejich analýzu a přípravu vstupních dat do kartografického procesu. Zajišťuje konzistentní a bezešvé uložení dat v databázi. Data pak mohou být využívána pro více účelů a mohou být pružně (víceuživatelsky) aktualizována. Programy pro tyto účely však neposkytují ucelené nástroje pro kartograficky správnou vizualizaci dat.
- Role grafických programů
Grafické programy poskytují mnoho nástrojů pro symbolizaci dat, jejich editaci, konstruování mapové kompozice a přípravu kvalitních tiskových (či jiných) výstupů.
Při vizualizaci geodatabází jsou využívány nástroje obou těchto přístupů, proto by bylo vhodné, kdyby bylo softwarové řešení pro kartografy integrováno do jednoho prostředí. Neustálé konverze dat mohou vést k chybám a zvýšeným časovým nákladům. V ideálním případě by kartografický model měl být provázán s daty, aniž by docházelo ke znehodnocování zdrojových dat editací kartografického modelu. Také by měl umožňovat provázání popisné složky mapy do databáze a nástroje pro aktualizace a generalizace. Takovýto systém může být vyvinut z grafických programů přidáním funkcionality GIS (příklad MGE) nebo z GIS programů přidáním požadované grafické podpory.
Tvorba map je iterativní proces a proto výhody využití výpočetní techniky jsou nesporné: automatizace, optimalizace postupů, možnost více tiskových výstupů nad jedněmi daty, nižší finanční a časové náklady. Mapy jsou však čím dál více zobrazovány na obrazovkách (PC, PDA, mobilní telefony, GPS navigace, ...) a proto je třeba klást důraz také na digitální výstupy mapové tvorby.
Samotná tvorba kartografického výstupu z databáze však není, a zřejmě nikdy nebude, zcela automatizována. Cílem tedy je minimalizace množství zásahů a rozhodnutí prováděných operátorem.
Poznámka
Od kompletní automatizace tvorby kartografického výstupu z báze geodat je třeba odlišovat její integrovatelnost v rámci komplexního řešení GIS. To je v současnosti (oproti prvně jmenovanému problému) řešitelná úloha.
- Požadavky na technologii pro komplexní zpracování kartografických produktů (dle [Neuffer Swisstopo]):
Jednotný SW od sběru dat k jejich publikování (minimalizace počtu konverzí dat a GUI),
Centralizovaná databáze (celistvost a integrita dat),
Možnost více souborů (způsobů) symbolizace nad jedněmi daty,
Možnost vytváření kvalitních kartografických výstupů,
Možnost generalizace a aktualizace ("časově odolná" technologie),
Svoboda při vytváření symbologie.
V kapitole jsem se snažil uvést současné hlavní "hráče" na poli databázové kartografie. Tento přehled rozhodně není kompletní a definitivní.
- ESRI: ArcGIS
ArcGIS ve verzi 9.2 implementoval mechanismus kartografických reprezentací. Tím udělal první krok k naplňování výše zmíněných požadavků ideálního kartografického software. Podrobněji viz kapitola 3.4 – „ESRI řešení“.
- Intergraph: Geomedia
Jedná se o konkurenta ESRI na poli komplexního řešení pro databázovou kartografii. Bližší informace o tomto produktu se mi bohužel nepodařilo zjistit.
- Pitney Bowes MapInfo: MapInfo
Podpora pro kartografické rutiny je velmi mizivá. Jedná se spíše o analytický nástroj srovnávaný (dle [Wiki:MapInfo]) s ArcView 3.x od ESRI.
- OCAD AG: OCAD
Jde o poměrně propracovaný nástroj pro vytváření dobrých kartografických výstupů. Jeho výhodou jsou také nízké pořizovací náklady[6]a nároky na HW. Má však také poměrně dost stinných stránek. Ačkoliv je propojení do databáze možné přes ovladač ODBC, jedná se spíše o grafický program. Zřejmě tedy také není uspokojivě řešena víceuživatelská editace jedné (bezešvé) "master" databáze. Přímá správa dat v připojených databázích bude také problematická a absence analytických nástrojů GIS vylučuje automatizaci mnohých kartografických rutin, které je pak nutné provádět ručně. Také není možné oddělení vznikajícího kartografického modelu od vlastních dat a při jeho editaci je tedy nutné manipulovat přímo s daty. Podpora uživatelského skriptování je též zatím v začátcích. K ideálu databázové kartografie jak je popsán výše tedy schází hodně, nicméně může se jednat o dobrou alternativu pro ty, kteří chtějí kvalitní kartografické výstupy a nemají na výše zmíněné systémy dostatek prostředků.
V této kapitole stručně zmíním technologii používanou Zeměměřickým úřadem při vytváření Základní mapy ČR 1:10 000 (ZM10).
Na stránkách úřadu stojí: „Od roku 2001 se obnovená vydání ZM 10 zpracovávají digitální technologií ze Základní báze geografických dat České republiky – ZABAGED® v návaznosti na aktualizaci ZABAGED®, s rozšířeným mapovým obsahem a rozšířeným barevným rozlišením vybraných ploch. ZM 10 tvoří základní podklad pro odvození map menších měřítek. ZM 10 získala ocenění MAPA ROKU 2001. Od října 2006 jsou již všechny listy Základní mapy ČR 1:10 000 zpracovány v této nové podobě. Aktualizace celého území ČR je rozvržena do tří let.“
Popis tvorby (viz schema 3.2 – „Postup tvorby Základní mapy 1:10 000 na podkladě ZABAGED®“):
Databáze ZABAGED® je uložena v databázi Oracle. Nad ní jsou spuštěny skripty pro export[7].
Export uloží atributovou složku do databáze ve formátu
MDBa grafickou složku do výkresu ve formátuDGNpo jednotlivých listech ZM10, které jsou propojené přes ODBC. Vzniká tak základ projektu pro MGE.Následně je střídavě za pomoci skriptů a editací operátorů[8] nad daty vytvářen kartografický model.
Po revizi a případných opravách je proveden export do formátu PDF pomocí programu MERCATOR[9].
Nakonec je prováděn tisk na digitálním tiskovém stroji MAN DicoPress 500.
Obrázek 3.2. Postup tvorby Základní mapy 1:10 000 na podkladě ZABAGED®
 |
(zpracováno na základě konzultace na ZÚ (pracoviště Sedlčany))
Jak název kapitoly napovídá, nejedná se o zcela optimální implementaci databázové kartografie tak jak byla popsána v kapitole 3.1 – „Kartografický software“. Při editaci kartografického modelu dochází ke změně geometrie vlastních dat. Také provázání s databází a analytické možnosti jsou slabinou tohoto řešení což činí vzniklý kartografický model velmi obtížně aktualizovatelným. Proto je postupováno tak, že kartografický model není při aktualizaci využíván a je vytvořen zcela nově. Nejednotné prostředí při tvorbě sice nemusí být nutně slabinou (umožní pro různé činnosti využít nejlepších nástrojů), ale problematické a časově[10] neefektivní jsou vzájemné konverze dat.
Jedná se však o dobíhající technologii a na obzoru se již rýsuje nové řešení postavené na produktech ESRI[11].
Při popisu vztahů zdrojových databází a kartografických modelů je třeba důsledně rozlišovat kartografický a datový model a postupy modelové a kartografické generalizace. Nejprve tedy několik definic:
- Generalizace
„V kartografickém smyslu je generalizace výběr a zjednodušování reprezentace detailů objektů s ohledem na měřítko a/nebo účel mapy.“[UGI]
- Modelová generalizace
Modelová generalizace je proces, který probíhá mezi dvěma modely bází geodat. Výsledkem je báze geodat obyčejně nižší úrovně podrobnosti.[12]
- Kartografická generalizace
„Kartografická generalisace (zevšeobecňování) je procesem, který řeší na vědeckých základech výběr hlavních, podstatných skutečností a jejich zobrazení na mapě v charakteristických rysech.“[Kovarik]
„Kartografická generalizace je výběr hlavního, podstatného a jeho cílevědomé zevšeobecnění mající na zřeteli zobrazení na mapě každé části skutečnosti v jejích základních, typických rysech a charakteristických vlastnostech v souladu s účelem, tématikou a měřítkem mapy.“[Saliscev]
„Kartografická generalizace spočívá ve výběru, geometrickém zjednodušení a zevšeobecnění objektů, jevů a jejich vzájemných vztahů pro jejich grafické vyjádření v mapě, ovlivněné účelem, měřítkem mapy a vlastním předmětem kartografického znázorňování.“[13]
- Digitální kartografický model
„Dvojrozměrný model mapy obsahující kartografické značky převedené do digitální vektorové nebo rastrové formy.“[VUGTK Slovnik]
Dosud používané systémy, nesplňovaly ideály databázové kartografie tak jak byly popsány v kapitole 3.1 – „Kartografický software“. Zdrojovou (master) databázi proto bylo zpravidla nutné zkopírovat (respektive její geometrickou složku) a nad ní byly prováděny techniky kartografické generalizace a jiné kartografické procesy (nejprve výběr, komplexace, dále symbolizace, později např. eliminace, zjednodušování, agregace, prostorové redukce, aj.). Takto postupně vznikal kartografický model - manipulací s původní geometrií. Rozlišit kartografický model od původní geometrie tedy není nijak obtížné. Pokud se však současné systémy začnou blížit zmiňovaným ideálům[14], je třeba věnovat trochu více pozornosti odlišení kartografického modelu.
Jak bylo nastíněno, kartografickým ideálem je databáze, která spolu s geometrickou složkou uchovává i její kartografickou reprezentaci. Vlastní geometrie v databázi tedy reprezentuje zdrojová data a kartografická reprezentace reprezentuje kartografický model.
Databáze vytvářené pro geografické informační systémy často obsahují více prvků (a atributů), než je možné vtěsnat na jeden kartografický výstup. A to ani není cílem, neboť kartografické výstupy jsou vytvářeny za nějakým účelem. Zpravidla tedy kartografy zajímá určitý výběr, který ještě může být modifikován modelovou či kartografickou generalizací. Data v master databázi tedy bývají uložena v takové podrobnosti či hustotě, která pro výslednou mapu nemusí být využitelná. Jsou-li data, nad nimiž je vytvářena kartografická reprezentace (neboli kartografický model), původními daty, pak kartografickým modelem nazveme kartografickou reprezentaci těchto dat. Pokud bychom však ze zdrojové databáze vytvářeli subdatabáze (např. různých měřítek) modifikované modelovou generalizací (např. výběr, eliminace, zjednodušení, agregace), tak kartografickým modelem opět nazveme až kartografické reprezentace nad vlastními geometrickými daty. Zde je pak také prostor pro Multi-resolution databáze zmiňované v kapitole 2 – „Multi-resolution databáze“. Subdatabáze menších měřítek vznikají z master databáze modelovou generalizací. Při tomto procesu již mohou být vytvářeny vazby jednotlivých prvků mezi databázemi a může tak vzniknout Multi-resolution databáze, jejíž aktualizace je prováděna poloautomatizovaně od master databáze nejvyššího měřítka. Je však třeba podotknout, že se stále ještě jedná o vzdálenou budoucnost.
- Více databází - více kartografických modelů
Postupy vytváření kartografických modelů z databází mohou být různé. Záleží na použitých technologiích a míře přiblížení se ideálům databázové kartografie. Zde se zaměřím pouze na nejobecnější případ respektující zmiňované ideály.
Podkladem je databáze nejvyššího měřítka - master databáze (viz obrázek 3.3 – „Více databází - více kartografických modelů“). Z ní jsou vytvářeny subdatabáze menších měřítek postupy modelové generalizace, které mohou být následně (polo)automatizovaně aktualizovány. Nad jednotlivými subdatabázemi mohou být vytvářeny za použití kartografické generalizace kartografické modely s různými účely (základní mapa, silniční mapa,...). Prvky kartografického modelu jsou však stále svázány s původní geometrií. Z kartografických modelů je pak možné vytvářet různé výstupy - analogová mapa, digitální mapa v rastrové podobě atd.. Digitální výstupy pak mohou být publikovány např. jako mapová služba v prostředí internetu.
Obrázek 3.3. Více databází - více kartografických modelů
Vysvětlivky: DLM - digital landscape model = digitální model území (DMÚ); DCM - digital cartographic model = digitální kartografický model; Cartographic Generalization = Kartografická generalizace; Cartographic Representation = Kartografická reprezentace; Model Generalisation = Modelová generalizace; Propagation = promítnutí změn; Output = Výstup.
Inspirováno dle [Neuffer Swisstopo].
„Příští hlavní verze ArcGIS 9.2 ... zahrnuje stovky vylepšení v ArcGIS Desktop ... Inovace v kartografii a vylepšení geodatabází přidává ArcGIS 9.2 nové schopnosti, které napomůžou vyšší produktivitě. ... Nové kartografické nástroje a funkcionalita umožní uživatelům vykonávat všechny práce kartografické produkční linky - od pořízení dat až po předtiskovou přípravu - pomocí ArcGIS 9.2.“
„ArcGIS 9.2 toho dosáhne využitím nových metod symbolizace prvků zvaných reprezentace.“[15][ArcUser]
Takto se postupně začal představovat nový nástroj pro kartografy zvaný Kartografické reprezentace (Cartographic Representations). V následujících kapitolách jej nejprve stručně představím, neboť je to právě tento nástroj, který najde mnohé uplatnění v databázové kartografii. Následně se trochu podrobněji podívám na uložení kartografických reprezentací v geodatabázi.
Jak již bylo několikrát zmíněno, jedním z ideálů databázové kartografie je uložení kartografické vizualizace v databázi spolu s daty. A to je přesně to, co jsou kartografické reprezentace (CR).
„Reprezentace prvkových tříd poskytují větší flexibilitu a kontrolu nad mapovou symbologií ukládáním komplexních symbolů založených na pravidlech uvnitř geodatabáze spolu s daty.“[16][RepreTutor]
Jedná se o nový způsob práce se symbologií jednotlivých prvků. Tato technologie umožňuje ukládat soubory pravidel uvnitř geodatabáze, které vizualizují jednotlivé prvky. Oproti klasické symbologii se tedy nejedná o vlastnosti vrstvy v mapovém dokumentu. Tato pravidla se nazývají reprezentační pravidla (Representation Rules - RR). CR poskytují větší kontrolu nad přesností a definicemi reprezentací jednotlivých prvků. Stručnou charakteristiku shrnují následující body:
Každý prvek si v databázi nese záznam o svém RR uložený v databázi,
Pro jeden prvek je možné definovat více různých CR což umožní produkci různých kartografických výstupů nad stejnými daty (geodatabází),
Výjimky od RR jsou umožněny, což znamená, že v případě potřeby je možné RR editovat a provádět například kartografické posuny,
Nad RR jsou definovány kartografické nástroje (Cartographic geoprocessing tools), které poskytují prostor pro automatizaci kartografických prací a pro pokročilé práce s reprezentacemi.
3.4.1.1. Reprezentační pravidla (Representation Rules) a Výjimky (Overrides) v praxi[17]
Pro demonstraci RR se zaměřme na vrstvy železnice a silnice. Na obrázku 3.4 – „Geometrie železnice a silnice zobrazená pouze symbologií“ jsou železnice a sinice ještě zobrazeny "obyčejnou" symbologií (hnědá linie - železniční trať, hnědé body - železniční stanice, žluté linie - silnice).
Vrstvy (Feature Classes) po vytvoření nedovolují vytváření reprezentačních pravidel (RR) - pro každou vrstvu je třeba její kartografickou reprezentaci (CR) vytvořit. Například při pohledu do atributové tabulky vrstvy silnic (Attribute Table) před vytvořením její CR (viz obrázek 3.5 – „Atributová tabulka vrstvy silnic před vytvořením CR“) nezpozorujeme nic zvláštního - vidíme "standardní" sloupce každé vrstvy (OBJECTID, FCsubtype, gfid, Shape..) a uživatelem vytvořené atributy.
Vytvoření CR vrstvy je otázkou pár kliknutí (viz např. [RepreTutor]). Tím v atributové tabulce přibudou dva sloupce (viz obrázek 3.7 – „Atributová tabulka vrstvy silnic po přiřazení CR“): RuleID a Override[18]. Ve sloupci RuleID je uloženo ID RR použitého pro daný segment. Sloupec Override uchovává případné výjimky od RR (ať geometrického či atributového typu).
Nyní je již možné přiřadit RR, která jsme si předem vytvořili (nebylo v tomto článku popisováno - možno nalézt např. v [RepreTutor]). Železniční trať, stanice, zastávky a silnice mohou vypadat například jako na obrázku 3.6 – „Železnice a silnice po přiřazení RR“.
Z předchozí ukázky je zřejmé, že z kartografického hlediska dochází ke kolizím značek silnice, železnice a vodního toku. Bude třeba provést kartografické odsuny a jiné editace pro docílení optimálního výstupu.
Abychom dodrželi zásady databázové kartografie, tak editace byly prováděny udělováním výjimek. Byly uděleny tyto výjimky (viz obrázek 3.8 – „Železnice a silnice po udělení výjimek“):
- Výjimky z vlastnosti:
Všem koncům železnice, které jsou volné (tj. nenavazuje na ně další segment železnice) byla udělena výjimka od vlastnosti Endings=Round na Endings=Butt a na konci železnice Endings=Square. Tato vlastnost je v defaultním RR nastavena na hodnotu Round kvůli plynulému navazování značky linie v zatáčkách, kde se stýkají dva segmenty. Tuto operaci lze provést automatizovaně za použití nástroje ArcToolboxu - Calculate Line Caps.
- Výjimky z geometrie:
Tam kde docházelo ke kolizi sinice a železnice, respektive silnice a vodního toku jsem udělil segmentům silnice výjimky z geometrie. Jde o místa kde se rozdvojují žluté linie (původní geometrie) od značek silnic (reprezentace původní geometrie).
- Volná reprezentace:
Pro demonstraci tohoto typu výjimky jsem využil posledních tří segmentů železnice (od zastávky do jejího konce). Tyto segmenty jsem takzvaně konvertoval do volné reprezentace a následně jsem jim přidal efekt Smooth curve. To způsobilo vyhlazení reprezentace těchto segmentů.
Volné reprezentace jsem musel využít proto, že původní definice RR tento efekt neobsahuje a musel jsem ho reprezentacím těchto prvků přidat. Nešlo tedy použít běžnou výjimku z vlastnosti.
Výsledný výstup je na obrázku 3.10 – „Železnice a silnice po udělení výjimek“.
Zkoumání bylo prováděno na geodatabázi ArcSDE Personal spravovanou pomocí databázového systému SQL Server 2005 Express. Do této databáze jsem přistupoval pomocí různých klientů (viz kapitola 5 – „Použité programové vybavení“).
Datovým typem sloupce RuleID, který
vznikne po vytvoření CR je deseticiferný INT (viz obrázek 3.11 – „Datové typy sloupců RuleID a
Override“) neboli tzv. Long Integer (jak
lze zjistit v ArcCatalogu) - evidentně tedy musí jít (jak již bylo
řečeno) pouze o referenci na vlastní RR uložené jinde v databázi. V
[AG92 Help][19] stojí: „Samotná reprezentační pravidla jsou
uložena v geodatabázových tabulkách.“[20] a v [AG92 Help][21] „Změna reprezentačního pravidla je změnou
schematu: Jakákoliv změna ve struktuře, vlastnosti nebo definice
reprezentačního pravidla je změnou schematu a promítne se okamžitě
ve všech verzích. Data reprezentačních pravidel jsou uložena v
neverzované tabulce GDB_EXTENSIONDATASETS,
takže přetrvávají napříč celou databází. Reprezentační pravidla
mohou být změněna pouze mimo editaci.“[22]
- Tabulka
GDB_EXTENSIONDATASETS Přehled systémových tabulek geodatabáze lze nalézt například v [EDN92][23], [EDN93][24] nebo [EDN91][25]. V těchto zdrojích jsou shrnuty systémové tabulky geodatabází ArcSDE verzí 9,2, 9.3 a 9.1. V seznamech tabulek však hledaná tabulka
GDB_EXTENSIONDATASETSchybí. Nicméně ve schematech, které jsou k tabulkám přiloženy se již nachází. Dokumentace systémových tabulek geodatabáze pro SQL Server se také nachází v [AG92 Help][26], či [AG93 Help][27]. Zde je také možné nalézt schemata systémových tabulek verzí 9.2 a 9.3 a jejich popis.[AG92 Help] definuje tuto tabulku následovně: „Tabulka
GDB_EXTENSIONDATASETSobsahuje informace o rozšiřujících datasetech (jako je síťový dataset nebo terénní dataset) uvnitř geodatabáze.“[28]Datové typy a jejich popis jsou patrné z následujícího obrázku:
Porovnáním těchto údajů (viz předchozí obrázek) se skutečností (viz následující obrázek) zjistíme, že se atributy a jejich datové typy shodují.
Ve schematu pro verzi 9.2 je tabulkaGDB_EXTENSIONDATASETSzařazena ve skupině Datasets a je u ní poznámka: „DříveGDB_NETDATASETS.“[29] (viz příloha A.1 – „Systémové tabulky geodatabáze ArcSDE 9.2“). V diagramu pro ArcSDE verze 9.3 (viz příloha A.3 – „Systémové tabulky geodatabáze ArcSDE 9.3“)[30] je však tato tabulka zařazena ve skupině Geometric Networks. U obou verzí je u atributuDatabaseNamepoznámka: „V databázích Oracle má hodnotu Null.“[31]. Ještě jsem tedy nahlédl do diagramu pro verzi 9.1, kde jsem podle předpokladu tuto tabulku nenalezl (ve verzi 9.1 ještě CR neexistovaly). Nalezl jsem tam však tabulkuGDB_NETDATASETS. Všechny tyto tři tabulky mají shodné atributy. Lze se domnívat, že tabulkaGDB_NETDATASETSjiž dříve sloužila i pro jiné účely (např. geometrické sítě či terénní datasety). Ve verzi 9.2 byla přejmenována naGDB_EXTENSIONDATASETS, neboť s verzí 9.2 vznikla potřeba ukládání kartografických reprezentací a byla formálně přeřazena do skupiny Datasets. Nicméně tato tabulka stále slouží pro ukládání (nejenom) datasetů geometrický sítí (viz obrázek 3.19 – „GDB_EXTENSIONDATASETS po vytvoření několika CR a síťového datasetu“) a zřejmě proto na diagramu 9.3 je opět formálně zařazena ve skupině Geometric Networks.Oproti skutečnosti (viz výše) však v diagramech chybí atribut DatasetType typu Long Integer. Tento atribut slouží pro rozlišení různých typů ukládaných dat - tedy například k rozlišení uložených CR (DatasetType=21) od síťových datasetů (DatasetType=19).
V instalačním adresáři programu ArcGIS ve složce
../Documentation/jsem ještě nalezl podrobnější schema tabulek síťových datasetůSS_NetworkDS.PDF(viz příloha A.2 – „Systémové tabulky síťových datasetů pro SQL Server -výřez“), které mimo jiné zahrnuje právě tabulky skupiny Geometric Networks. V něm jsou vyznačeny vazby tabulkyGDB_EXTENSIONDATASETS, která je přímo vázána přes atributDatasetIDnaIDtabulkyGDB_FEATUREDATASET. Tato tabulka obsahuje pouze[32] seznam datasetů (Feature Dataset) - v mém případě pouze jediný -ERM_Project, ve kterém mám umístěny všechny vrstvy (viz následující obrázky).Zvláštní mi přijde atribut
DatasetIDtabulkyGDB_EXTENSIONDATASETS -obsahuje hodnoty, které neodpovídají hodnotám (resp. hodnotě)IDtabulkyGDB_FEATUREDATASET, jako je tomu u atributuDatasetIDtabulkyGDB_OBJECTCLASSESnebo takéGDB_GEOMNETWORKS(viz stále přílohu A.2 – „Systémové tabulky síťových datasetů pro SQL Server -výřez“). Všiml jsem si, že hodnotyDatasetIDtabulkyGDB_EXTENSIONDATASETSpřipomínají ID jednotlivých vrstev geodatabáze (viz např. atributlayer_idtabulkySDE_layers), nicméně tato domněnka se nepotvrdila - jedná se o různé hodnoty.Přes veškerou snahu se mi nepodařilo zjistit, jakým způsobem je provedena vazba mezi atributem
RuleID[18] jednotlivých Business tables a tabulkouGDB_EXTENSIONDATASETS(zřejmě s jejím atributemDatasetID).Při nahlédnutí do tabulky před vytvořením jakékoliv CR (či geometrické sítě atp.) ještě neobsahuje žádná data. Po vytvoření CR nebo např. síťového datasetu určité vrstvě v tabulce vznikne záznam. Na obrázku 3.19 – „GDB_EXTENSIONDATASETS po vytvoření několika CR a síťového datasetu“ je zvýrazněno uložení CR a síťového datasetu vrstvy RailrdL; dále jsou tam uloženy další CR jiných vrstev.
Lze tedy tvrdit, že v této tabulce jsou uloženy CR jednotlivých vrstev - tedy konkrétně v binární podobě v atributu
Propertieskterý je datového typu Image[33]/Blob[34]. Jeden řádek vždy odpovídá jedné vrstvě - to znamená, že nejsou ukládána jednotlivá RR zvlášť, ale všechna RR dané vrstvy (respektive její reprezentace) jsou uložena souhrnně ve zmiňovaném poli. Tuto hypotézu jsem ověřil porovnáním binárního kódu liniové vrstvy s jedním RR (pravidlo se čtyřmi liniovými vrstvami a efekty Offset curve) s binárním kódem této vrstvy po přidání totožné kopie prvního RR (viz přílohu A.5 – „Porovnání binárního kódu CR s jedním RR versus se dvěma totožnými RR“). V kódu je možné nalézt řetězce odpovídající názvům RR (v ukázce zvýrazněny modře) - je tedy vidět, že kód narostl o přibližně na dvojnásobek toho, co lze považovat za kód prvního RR. Podobně když nahlédneme do kódu CR vrstev z ukázky v kapitole 3.4.1.1 – „Reprezentační pravidla (Representation Rules) a Výjimky (Overrides) v praxi“ - například vrstvy silnic, tak lze v binárním kódu nalézt sekvence odpovídající všem vytvořeným RR.Když je tedy vrstvě vytvořena CR (např. v ArcCatalogu, ArcMapu či pomocí ArcToolboxu (podrobněji opět viz [RepreTutor]), pak to neznamená nic jiného, než vytvoření řádky v tabulce
GDB_EXTENSIONDATASETS. Následně změna definice jakéhokoliv RR dané CR znamená změnu ve zmiňovaném poliProperties, což lze také pozorovat na změně jeho velikosti. To dokládá pravdivost často citované věty (viz citaci v úvodu kapitoly) o uložení CR v geodatabázi a účel dialogového okna, které při každé změně RR (např. v ArcMapu) upozorňuje na uložení změny v geodatabázi (viz obrázek 3.20 – „Upozornění při zápisu změny RR do geodatabáze“).Následující tabulka obsahuje vybrané změny definice různých RR a příslušnou změnu velikosti atributu
Properties:Tabulka 3.1. Změna velikosti atributu
Propertiespro některé vybrané operace.Změna/operace Velikost pole před změnou [Bytes] Velikost pole po změně [Bytes] Rozdíl [Bytes] Bodová vrstva Vytvoření CR[a] 0 380 380 Změna velikosti defaultního symbolu[b] 380 394 14 Změna barvy symbolu[c] 394 779 385 Změna úhlu natočení 779 793 14 První kopie vytvořeného pravidla 793 1344 551 Druhá kopie vytvořeného pravidla 1344 1895 551 Smazání druhé kopie 1895 1344 -551 Změna symbolu první kopie za symbol o 22 bodech 1344 1988 644 Přidání efektu Buffer první kopii 1988 2015 27 Liniová vrstva Vytvoření CR[a] 0 360 360 Změna tloušťky čáry 360 374 14 Změna barvy čáry 374 406 32 Změna vlastnosti způsobu napojení (Caps, Joins) 406 416 10 Přidání efektu Dashes 416 450+10[d]+50[e] 34+10+50 Přidání efektu Cut curve 510 544+28[f] 34+28 Přidání efektu Offset curve 572 606+14[g]+10[h]+8[i] 34+14+10+8 Přidání nové bodové vrstvy do RR 638 710+82[j] 72+82 První kopie vytvořeného pravidla 790 1340 550 Druhá kopie vytvořeného pravidla 1340 1890 550 Smazání druhé kopie vytvořeného pravidla 1890 1340 -550 Polygonová vrstva Vytvoření CR 0 362 362 Změna barvy 362 415 53 Přidání efektu Offset curve 415 449+32[k] 34+32 Přidání nové liniové vrstvy do RR 481 535+87[l] 54+87 Přidání nové bodové vrstvy do RR 622 694+502[m] 72+502 První kopie vytvořeného pravidla 1195 2148 953 Druhá kopie vytvořeného pravidla 2148 3101 953 Smazání druhé kopie vytvořeného pravidla 3101 2148 -953 [a] Již při vytváření nové CR je uloženo alespoň jedno defaultní RR. Nelze vytvořit CR bez jakéhokoliv RR.
[b] Je to černý čtverec
[c] Jde pouze o první změnu. Každá další změna již neznamená žádný nárůst velikosti. Tato operace není inverzní.
[d] Změna vlastnosti Endings
[e] Proměnlivé dle vlastnosti Pattern-záleží na složitosti vzorku.
[f] Změna vlastností Begin/End cut.
[g] Změna vlastnosti Offset.
[h] Změna vlastnosti Method.
[i] Změna vlastnosti Simple.
[j] Max. nárůst při změně různých možností vlastnosti Along line.
[k] Max. nárůst při změně různých vlastností efektu.
[l] Max. nárůst při změně různých vlastností linie bez efektů.
[m] Max. nárůst při změně různých vlastností bodových symbolů s umístěním
Inside polygon.
- Postřehy:
Použití značky v RR (vytvořené pomocí Marker Editoru) znamená poměrně velký nárůst velikosti - čím složitější značka (tj. čím více bodů a vrstev), tím větší nárůst,
Přidání efektu v RR znamená vždy konstantní nárůst velikosti o 34Bajtů (podle druhu efektu a tedy podle počtu a charakteru jeho vlastností pak jsou další změny velikosti různé).
Z tabulky je také zřejmé, že nárůst objemu databáze vytvořením CR není to co by bylo limitujícím faktorem tohoto nástroje. Tím ale s velkou pravděpodobností bude rychlost vykreslování dat při velkém počtu vrstev s CR (otázkou se ještě budu zabývat v kapitole o výjimkách). Na obrázku 3.21 – „Postup vykreslení prvku s dvouvrstvým RR“ je popsán způsob vykreslení prvku s RR: horní skupina obrázků představuje záznam v atributové tabulce (Bussines table), dolní skupina je pak schematicky znázorněné RR. Má-li vrstva vytvořenu CR a prvek přiřazeno některé RR, tak se začne vykreslovat. Ukázka představuje liniovou vrstvu a dvouvrstvé RR (na výstupu jsou generovány 2 vrstvy). První vrstvou je linie, která má dva efekty - "čárkování" a odsun od osy a až na konec je vykreslen základní symbol - linie. Druhou vrstvu tvoří značková vrstva (marker layer) s efektem umístění značky - zvolená značka je vykreslena v pravidelném intervalu v ose linie.
Na rychlost vykreslení tedy nebude mít vliv ani tak objem uložených RR, jako spíše složitost RR. Čím více vrstev a čím více použitých efektů, tím bude vykreslení pomalejší.
V předchozí kapitole jsem popsal, jak jsou RR uloženy v geodatabázi. RR však mohou být uložena i jinde: ve stylu a ve schematu geodatabáze.
- Uložení RR ve stylu
Po vytvoření každého RR jej lze pomocí volby Save Rule to Style uložit do stylu který lze editovat ve Style Manageru. Podobně lze ukládat také vytvořené značky. RR nalezneme ve složce
Representation Rulesa značky ve složceRepresentation markers. Zde je lze také editovat ale změna provedená v RR uloženém ve stylu se neprojeví v mapě[35]. Toto uložení je totiž vně databáze v souboru stylu, který se nachází v adresáři[36]Documents and Settings\<nazev_uctu_uzivatele>\Application Data\ESRI\ArcMap\<nazev_uctu_uzivatele>.style. Pokud změníme tomuto souboru koncovku na .MDB, tak je pak možné prohlédnou jeho obsah a případně jej editovat například v Accessu (viz přílohu A.6 – „Zobrazení stylu v Accessu“) nebo v ArcCatalogu (viz přílohu A.7 – „Zobrazení stylu v ArcCatalogu“).Tento způsob však vzhledem ke zmíněným obtížím není vhodný pro sdílení velkých souborů CR.
- Uložení ve schematu geodatabáze
V úvodu kapitoly 3.4.1.2 – „Uložení Kartografických reprezentací (CR) v geodatabázi“ bylo citováno, že změna RR je změna schematu databáze uložená v tabulce
GDB_EXTENSIONDATASET. Velmi elegantní způsob pro sdílení CR (a to s daty nebo bez) je tedy export databázového schematu do XML pomocí funkce Export/XML Workspace Document[37]. Toto schema je pak možné importovat do vlastní databáze.Pro otestování tohoto způsobu jsem vytvořil pokusnou Personal Geodatabase, kde jsem vytvořil bodovou a liniovou vrstvu. Těmto vrstvám jsem pak různě měnil nastavení týkající se reprezentací. U jednotlivých stavů jsem vyexportoval XML dokumenty a následně hledal změny. Výsledky shrnuje tabulka 3.2 – „Testování exportovaných XML dokumentů“:
Tabulka 3.2. Testování exportovaných XML dokumentů
Typ vrstvy Operace provedená mezi stavy Snímek v příloze Komentář Bodová Vytvoření CR A.8 – „Porovnání XML schematu vrstvy před a po přiřazení CR“ a A.9 – „Porovnání XML schematu vrstvy před a po přiřazení CR“ Došlo celkem ke 3 změnám: přibyla doména
pointFCdemo__C_R_Rules, v elementuFieldArraypřibyly sloupceRuleIDaOverride[a] a přibyl elementDatasetDefinitions, který obsahuje definici CR a příslušných RR.Definice RR jsou tedy i v tomto dokumentu v binární podobě v elementu
RepresentationRules. Za povšimnutí také stojí předposlední element druhé ukázkyDSID=10. Je to právě tato hodnota, kterou se mi (zatím) nepodařilo nalézt v tabulkách geodatabáze a která zajišťuje vazbu mezi jednotlivými atributovými tabulkami (Bussines tables) a atributemDatasetIDtabulkyGDB_EXTENSIONDATASET.Bodová Vytvoření druhého RR kopií prvního. A.10 – „Porovnání XML schematu vrstvy před a po přidání kopie RR“ Binární kód narostl cca dvakrát. První část je téměř totožná (představuje první pravidlo které zůstalo zachováno) a druhá část představuje druhé přidané pravidlo. Po trošce hledání lze nalézt velmi podobné části kódu, neboť se jedná o totožná pravidla. Liniová Přidání efektu (Dashes) do RR A.11 – „Porovnání XML schematu vrstvy před a po přidání efektu do RR“ Přidání několika sekvencí kódu. Liniová Vytvoření druhé (totožné) CR A.12 – „Porovnání XML schematu vrstvy před a po přidání kopie CR“ Vznikl nový element DataElement, který je velmi podobný tomu prvnímu. Tento element tedy obsahuje definici jedné CR dané vrstvy.[a] Tyto dvě změny jsou zřejmé a ne příliš zajímavé. Proto je už dále nebudu zmiňovat.
Tento způsob exportu/importu CR je vhodný pro předávání velkých souborů CR. Mohl by tak najít uplatnění v kartografické výrobě při zpracování rozsáhlých mapových souborů.
- Výjimky obecně
V [AG92 Help][38] stojí „Reprezentace prvkových tříd zobrazují prvky podle vlastností určených reprezentačními pravidly. Občas je nezbytné vytvořit výjimku od pravidla pro zobrazení různorodých dat, vyřešení konfliktů nebo pro zvýraznění zvláštních prvků. Tyto výjimky, neboli overrides mohou být uděleny jednotlivým reprezentacím během editace, aniž by došlo k přerušení struktury reprezentačního pravidla.“[39]
Obecně bychom mohli rozlišit tři typy výjimek:
- Výjimka z vlastnosti RR (Properties override)
Definice jednotlivých RR se skládají z vrstev s různými kartografickými vlastnostmi a případně z různých efektů s příslušnými vlastnostmi. Jednotlivým prvkům lze udělit výjimku z těchto vlastností definovaných v RR. Například u linie lze změnit barva, tloušťka, typ zakončení atp. V případě že některé vlastnosti prvku udělím výjimku z vlastnosti, tak tato vlastnost již nepodléhá původní definici. Avšak ostatní vlastnosti ano, takže pokud změním definici těchto vlastností v RR, tak se změní i u prvků, které žádnou výjimku nemají[40]. Například u některého segmentu silnice změním RR barvu kontury z šedé na černou. Když se však následně rozhodnu v definici RR silnice změnit barvu výplně ze žluté na červenou, tak se změna provede i u těch segmentů, které mají změněnu barvu kontury.
- Výjimka z geometrie RR (Geometry override)
V případě potřeby, lze změnit i geometrii kartografické reprezentace prvku (např. kartografický odsun, kartografická generalizace atd.). Oproti editaci je zde jeden významný rozdíl: udělení geometrické výjimky některému RR nemění geometrii původního prvku. To ovšem platí pouze tehdy, když při vytváření CR zvolíme Store change to geometry as representation override. V opačném případě, kdybychom zvolili Change the geometry of the supporting feature, tak by při editaci geometrie kartografické reprezentace prvku ke změně původní geometrie docházelo. V našem případě by to však znamenalo zavrhnutí jednoho z hlavních principů databázové kartografie.
- Volná reprezentace (Free representation)
Předchozí dvě výjimky umožňují upravit RR daného prvku co do vzhledu a polohy, avšak pouze v mezích určených definicemi vytvořených RR dané CR. Například pokud budu mít vodní tok reprezentovaný jednoduchým RR plné modré čáry tloušťky 1mm, tak mám možnost udělit výjimku z vlastnosti tloušťce, barvě a způsobu na navazování a zakončení linií. Mám také možnost udělit výjimku z geometrie - například odsunem toku od komunikace. Nemám však možnost udělit výjimku od vlastnosti, kterou dané RR neobsahuje - například přidat efekt "čárkování".
To umožňuje právě tento typ výjimky. Pokud pro daný segment chci mít úplnou svobodu jeho zobrazení, konvertuji ho do volné reprezentace. Zaniká pak jakákoliv vazba na původní RR a mám možnost, stejně jako při definování RR, zcela upravit vzhled prvku dle svých představ. Při tomto typu výjimky má prvek v atributovém sloupci
RuleIDhodnotu-1.
Výjimky z vlastnosti a geometrie je možné kdykoliv vrátit zpět do původní podoby jak je definuje RR (například interaktivně v , nebo pomocí nástroje v ). U volné reprezentace je třeba ručně vybrat požadovaný prvek z znovu mu nastavit některé definované RR.
- Uložení výjimek
Již bylo řečeno, že sloupec Override je druhý, který vznikne po vytvoření CR v atributové tabulce (Business table). V [RepreTutor] stojí: „Pole override je pole, v němž je uloženy výjimky od reprezentačního pravidla daného prvku. Jeho datový typ je BLOB. Standardní jméno pro toto pole je Override.“[41]
Na obrázku 3.22 – „Datové typy sloupců tabulky (vrstvy) RailrdL po přiřazení CR“ se můžeme přesvědčit, že datovým typem atributu Override je skutečně typ Image[42]/Blob[43]. Zajímavou informací je možná velikost jednoho objektu - přes 2GB. Jde však o využití datového typu používaného pro ukládání velkých binárních objektů (např. i obrázky, video..). Pro tuto aplikaci je to velikost více než dostačující - těžko se bude geometrie nějakého segmentu potýkat s touto hranicí.
Výjimky z vlastností, výjimky z geometrie i volné reprezentace jsou ukládány v binární podobě v tomto sloupci atributové tabulky (business table) - mohli jsme se o tom přesvědčit na příkladu v kapitole 3.4.1.1 – „Reprezentační pravidla (Representation Rules) a Výjimky (Overrides) v praxi“. Zaměřme se na segment silnice s
OBJECTID=1878(viz zvýrazněný prvek na obrázku 3.6 – „Železnice a silnice po přiřazení RR“). Nepřesvědčíme se o tom však z tabulky v ArcCatalogu, kde poleOverridetohoto prvku před udělením geometrické výjimky (viz obrázek 3.7 – „Atributová tabulka vrstvy silnic po přiřazení CR“) a po ní (viz obrázek 3.9 – „Železnice a silnice s výjimkami a jejich geometrie“) obsahuje stále stejnou hodnotu, a to datový typ tohoto pole: „Blob“. Je třeba použít jiného klienta než ArcCatalog. Na obrázku 3.23 – „Datové typy sloupců tabulky (vrstvy) RailrdL po přiřazení CR“ je snímek prvku1878po udělení výjimky - stejně jako okolní prvky měl před tímto úkonem v poliOverridehodnotu (null), nyní je zde uložen binární objekt o velikosti1060Bytes.Z vlastního binárního kódu uložených výjimek toho příliš vyčíst nelze, stejně jako v případě uložení CR. Pouze jedna věc: v binárním kódu výjimky z geometrie a volné reprezentace je uložena prostorová reference daného prvku (definice souřadnicového systému, zobrazení, atd.) ve formátu Well-known text (
WKT) - na následujícím obrázku viz modré zvýraznění:Zajímalo mě, jak závisí velikost pole Override na typu udělené výjimky a velikosti geometrie prvku. Vytvořil jsem tedy tři vrstvy - bodovou, liniovou a polygonovou a v nich testované objekty o různých velikostech. Těmto vrstvám jsem vytvořil CR a objektům přiřadil RR (pro bodovou jsem použil CR železničních stanic, pro liniovou CR silnic a pro polygonovou CR vodních ploch). Těmto objektům jsem pak udělil různé typy výjimek jak jsou popsány v úvodním odstavci této kapitoly.
Velikost geometrie jsem vyčetl z příslušných[44] "Feature table" (mají prefix "f..") v geodatabázi. Velikost jednotlivých výjimek jsem vyčetl přímo z polí
Overridev příslušných bussines table.Výsledky jsem shrnul v následující tabulce:
Tabulka 3.3. Změny velikosti pole Override v závislosti na typu udělené výjimky
Typ geometrie Počet vrcholů Velikost geometrie [Bytes] Typ výjimky Výjimka z vlastnosti Velikost [Bytes] / [%] velikosti geometrie Výjimka z geometrie Velikost [Bytes] / [%] velikosti geometrie Volná reprezentace Velikost [Bytes] / [%] velikosti geometrie Bod 1 20 Angle≠0; Angle=45 42 / 210 (posun) 881 / 4405 posun; přidání 2 vrstvy (žlutý čtverec, Size=8) 2568 / 12840 Linie 2 28 Endings≠Round; Endings=Butt 52 / 186 (posun) 941 / 3361 přidán efekt Dashes: Pattern=1 1; Endings=With half pattern 1332 / 4757 Linie 10 92 Endings≠Round; Endings=Butt 52 / 57 (posun) 1069 / 1162 přidán efekt Dashes: Pattern=1 1; Endings=With half pattern 1460 / 1587 Linie 100 858 Endings≠Round; Endings=Butt 52 / 6 (posun) 2509 / 292 přidán efekt Dashes: Pattern=1 1; Endings=With half pattern 2900 / 338 Polygon 3 46 Visible=0 36 / 78 (posun) 973 / 2115 přidán efekt Smooth curve: Flat tolerance=0.1 1339 / 2911 Polygon 10 101 Visible=0 36 / 36 (posun) 1085 / 1074 přidán efekt Smooth curve: Flat tolerance=0.1 1451 / 1437 Polygon 100 802 Visible=0 36 / 4 (posun) 2525 / 315 přidán efekt Smooth curve: Flat tolerance=0.1 2891 / 360 - Postřehy:
Udělení výjimky z vlastnosti představuje vždy stejný nárůst velikosti v rámci daného typu geometrie a nezávisle na její původní velikosti (např. nárůst v případě polygonové vrstvy vždy tvořil 36 bytes).
Velikosti jednotlivých typů výjimek dopadly dle očekávání: nejméně výjimky z vlastnosti, nejvíce volné reprezentace.
U prvků, jejichž velikost geometrie je malá, představují výjimky relativně značný nárůst velikosti (v tabulce až 12840%). Se zvětšující se velikostí geometrie však tento nárůst klesá. Přesto v testovaných případech dosahoval u 100 bodových prvků a u nejčastějšího typu výjimky z geometrie (používaného v kartografii) 300%!!
Lze se domnívat, že volná reprezentace představuje největší nárůst velikosti proto, že ve svém binárním kódu bude mít zřejmě uloženo vlastní RR.
Při vytváření tabulky 3.3 – „Změny velikosti pole Override v závislosti na typu udělené výjimky“ jsem prováděl také exporty příslušných vrstev do výměnného formátu XML Workspace Document který byl již zmiňován v souvislosti s exporty a importy CR ve schematu geodatabáze. Zajímalo mě, zda a případně kde jsou v tomto souboru uloženy výjimky jednotlivých prvků. Následující tabulka tedy shrnuje změny, ke kterým docházelo postupně od prázdné bodové vrstvy bez CR k vrstvě se třemi body s přiřazenými RR a různými typy výjimek (pro tyto změny jsem již nevytvářel obrazové ukázky jako v případě uložení CR ve schematu):
Tabulka 3.4. Tabulka změn exportovaného XML s daty v závislosti na udělených výjimkách
Vrstva před změnou Vrstva po změně Změna v exportovaném XML kódu Ukázka kódu Bez CR, Bez Dat S CR , Bez Dat +[a] Domain <jmeno CR>_Rules
+ Children .. definice RR
+ Field RuleID
+ Field Override
- S CR , Bez Dat S CR, S jedním bodem + Record 1 .. souřadnice bodu - S CR, S jedním bodem S CR, Se třemi body + Record 2 a 3 .. souřadnice dalších dvou bodů - S CR, Se třemi body S CR, Bodům přiřazena RR změna Record/Values/Value před změnou: <Value xsi:nil='true'></Value> po změně: <Record xsi:type='esri:Record'> <Values xsi:type='esri:ArrayOfValue'> <Value xsi:type='xs:int'>3</Value> <Value xsi:type='esri:PointN'> <X>-709272.252</X> <Y>-1641690.3994</Y> </Value> <Value xsi:type='xs:int'>2</Value> <Value xsi:nil='true'></Value> </Values> </Record>Bodům přiřazena RR Prvnímu bodu udělena výjimka z vlastnosti změna Record/Values/Value bodu 1 před změnou: <Value xsi:nil='true'></Value> po změně: <Value xsi:type='xs:base64Binary'> AQAAABAAAAAAAAAAAAAAAAEAAAABAAAAAQAAAAMAAAAFAAAAAAAAgEZA </Value>
Prvnímu bodu udělena výjimka z vlastnosti Druhému bodu udělena výjimka z geometrie změna - totéž co předchozí, jen binární kód je mnohem delší - Druhému bodu udělena výjimka z geometrie Druhému bodu udělena výjimka z geometrie a vlastnosti změna - drobná změna v binárním kódu; s každou výjimkou z vlastnosti nárůst velikosti, ale oproti výjimce z geometrie pouze malý - Druhému bodu udělena výjimka z geometrie a vlastnosti Třetímu bodu udělena volná reprezentace Číslo RR se změní na -1 a binární kód je ještě delší před změnou: <Value xsi:type='xs:int'>2</Value> <Value xsi:nil='true'></Value> po změně: <Value xsi:type='xs:int'>-1</Value> <Value xsi:type='xs:base64Binary'> AQAAABAAAAAYAAAAAAAAAP////8AAAAAAQACAAAAAQAAAAEAAAACAAAAPgAAAJ8DAAAAAAAAAQAA AAEAAABBy6UA2lLQEajyAGCMhe3lAgAUAAAAAQAAAOAkBoEwpSXBEBQ/ZtoMOcEAZ2Iq0h2yEb9R . . . xOl+I9HQEYODCAAJuZbMAQABAAAAAAAAAABZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA AAEAAAD/////AgAAAAUAG41Go9FoBEAWAAAAAAAAAP97DBY3ImdKsWOJwiPbCh0BAAAAAAAAAAAA AAAAAAIAAAABAAAAAgAAAAAAAAA=</Value>[a] Přibyl atribut.
[6] OCAD Professional v současnosti (červenec 2008) stojí v přepočtu necelých 25 000Kč.
[7] Na míru ušité řešení od firmy BERIT.
[8] Technologii vyvíjela firma VARS BRNO a.s..
[9] „Program STAR-APIC Mercator je uznávaný jako jedno z předních řešení Kartografické produkce. Mercator je používnán vydavateli map a národnímy mapovými agenturami po celém světě a umožňuje vám rychle a efektivně vytvářet a publikovat výstupy nejvyšší kvality.“
„STAR-APIC Mercator software is acknowledged as one of the leading Cartographic Publishing solutions. Used by map publishers and National Mapping Agencies around the world Mercator allows you to create and publish the highest quality mapping quickly and efficiently.“ [Star-apic]
[10] a zřejmě také finančně
[11] Technologii vyvíjí společnost T-MAPY spol. s.r.o..
[12] Půjde o obdobu kartografické generalizace s použitím zcela objektivních kritérií a metod. Nebude tedy uvažována kartografická abstrakce.
[13] ČSN 73046
[14] V současnosti (červenec 2008) se zřejmě tomuto ideálu nejvíce přibližují produkty ESRI (O ArcGIS Cartographic Representation™ viz kapitola 3.4 – „ESRI řešení“).
[15] „The next major release of the ArcGIS platform, ArcGIS 9.2 ... includes hundreds of enhancements to ArcGIS Desktop ... Innovations in cartography and improvements to the geodatabase add new capabilities to ArcGIS 9.2 that will help users be more productive. ... New cartographic tools and functionality let users accomplish the entire cartographic workfow—from data capture to the preparation of fnished map products—inside ArcGIS 9.2.“
„ArcGIS 9.2 accomplishes this by employing a new method for symbolizing features called representations.“
[16] „Feature class representations give you greater fexibility and control of your map symbology by storing complex, rule-based symbols in the geodatabase along with the map data.“
[17] Poznámka autora: omlouvám se za zanoření kapitol do čtvrté úrovně, neboť to může být nepřehledné. Avšak vzhledem k rozsahu těchto kapitol by jejich přesunutí do třetí úrovně způsobilo ještě větší chaos.
[18] Případně jak si je uživatel při vytváření CR pojmenuje - jde o defaultní názvy.
[20] „The representation rules themselves are stored within the geodatabase system tables.“
[22] „Changing a representation rule is a schema change:
Any changes to the structure, the property values, or the field
mappings of a representation rule is a schema change and will be
reflected in all versions immediately. Representation rule
information is held in the non-versioned
GDB_EXTENSIONDATASETS table, so it is
persisted across the database. Representation rules can only be
changed outside an edit session.“
[28] „The
GDB_EXTENSIONDATASETS table
contains information about the dataset extensions (such as
network datasets or terrain datasets) in a
geodatabase.“
[29] „Formerly
GDB_NETDATASETS.“
[30] Poměrně zajímavé je to, že jak na stránkách helpu
pro verzi 9.2, tak pro verzi 9.3 se tabulka jmenuje:
ArcSDE92_GDBSysTablesDiagram.pdf.
Zřejmě ji někdo zapomněl přejmenovat :-).
[31] „Null in Oracle databases“
[32] ..jak jsem vytušil z názvu a z dat v tabulce
[33] Řečeno dialektem SQL Serveru.
[34] Řečeno dialektem ArcSDE, respektive Oracle.
[35] Bylo by nutné u dané vrstvy upravené RR načíst pomocí funkce Load Rule... původní staré RR smazat a příslušným prvkům nové pravidlo znovu přiřadit.
[36] Ve Windows XP.
[37] Volba pro celou geodatabázi, Featrure Dataset i Feature Class. Exportuje vše - datasety, prvkové třídy, domény, indexy, data svázaná s exportovanou vrstvou, tabulky, anotační třídy atd.
Volba Export/XML Recordset Document je pouze pro prvkové třídy. XML Recordset Document exportuje pouze data obsažená v dané vrstvě (tedy zřejmě i pole Override) ale neexportuje databázové schema, kde jsou uloženy definice RR. V případě že databáze do které bychom importovali obsahuje totožné definice CR a potažmo RR, pak by byla možná i tato volba.
[39] „Feature class representations display the features of your data according to the properties established in representation rules. There may be times when it becomes necessary to make exceptions to these rules to depict the full diversity of your data, to resolve visual congestion, or to highlight special features. These exceptions, or overrides, can be made for individual feature representations during an edit session without disrupting the structure of the representation rule.“
[40] Přestože jiná vlastnost toho samého pravidla výjimku má.
[41] “The Override Field is the field that stores any overrides to a representation rule for a feature. It is a BLOB field type. The default name for this field is Override.”
[42] Řečeno dialektem SQL Serveru.
[43] Řečeno dialektem ArcSDE, respektive Oracle.
[44] Pro nalezení té správné f
tabulky k dané business table je
třeba nahlédnout například do tabulky SDE_layers, kde v
atributu layer_id zjistíme
odpovídající číslo f tabulky. V
f tabulce se pak jedná o atribut
points, který je také binárního
typu. Více lze nalézt například v těchto zdrojích: [Vokounova], [Jedlinsky], diagram
SS_fc_tables.PDF v dokumentaci
ArcGIS, [AG92 Help]:Feature
classes in a geodatabase in SQL
Server.
Současným trendem v moha oblastech IT je ukládání čehokoliv do databází. Ne jinak je tomu i v GIS a kartografii. Zatímco však GIS jsou s databázemi spjaty již od počátku, tak v oblasti kartografie to je trend poslední doby. Databázová kartografie se tak v současnosti rozvíjí a to zejména v oblastech software a použitých metod.
V práci jsme stručně popsali termín Multi-resolution databáze, který představuje výzvu pro současnou kartografii.
V oblasti kartografické vizualizace databází jsme se zabývali komplexním databázovým přístupem při vytváření kartografických výstupů. Snažili jsme se vyhledat hlavní dostupná programová řešení v této oblasti. Také je popsáno řešení využívané při tvorbě Základní mapy 1:10 000, které bylo jedním z prvních řešení s rysy databázové kartografie.
Větší část práce zkoumá kartografické reprezentace
(Cartographic Representations - CR) - nástroj
nabídnutý firmou ESRI. Na praktickém příkladu jsou předvedeny základní
principy využití CR. Podrobněji se zabýváme uložením CR v geodatabázi.
Zjistili jsme, že kartografické reprezentace jednotlivých vrstev jsou
uloženy v binární formě v systémové tabulce geodatabáze
GDB_EXTENSIONDATASET. Vytvořená tabulka podává
představu o závislosti velikosti uložených CR na složitosti definovaných
reprezentačních pravidel. Zkoumáno je také uložení výjimek které je možné
udělit prvkům s přiřazeným pravidlem. Jsou popsány tři typy výjimek a to,
kde jsou v geodatabázi uloženy. Tabulka opět shrnuje velikost uložených
výjimek v závislosti na jejich typu.
Další práce bude věnována zkoumání rychlosti vykreslování vrstev s různě komplikovanými reprezentačními pravidly a zátěži, kterou pro databázi představují různé typy udělených výjimek.
ArcInfo Desktop 9.2, Build 1420,
ArcSDE Personal Server version 9.00.3068.00,
Microsoft SQL Server 2005 Express Edition version 9.2.3042.00,
DbVisualizer Personal 6.0.10, Build 1303,
ExamDiff Pro, Version 4.0, Build 4.0.2.11,
Microsoft Office Access 2007,
XML diff, version 1.0, Copyright© 2007 Martin Satke,
Oracle SQL Developer, version 1.2.1,
Microsoft SQL Server Management Studio Express version 9.00.3042.00
Foxit Reader, IrfanView, XMLmind XML Editor Personal Edition 3.8.1
..a mnohé další.
[Istanbul 2004] MANTEL, Daniela, LIPECK, Udo . MATCHING CARTOGRAPHIC OBJECTS IN SPATIAL DATABASES . In XXth ISPRS Congress . [s.l.] : [s.n.], 2004. Vol. XXXV, part B4. s. 172-176. Dostupný z WWW: <http://www.isprs.org/istanbul2004/comm4/comm4.htm>. ISSN 1682-1750.
[Hardy_SW] BUCKLEY, Aileen, HARDY, Paul. Cartographic Software Capabilities and Data Requirements : Current Status and a Look toward the Future. ACSM CAGIS. 2006, vol. 34, no. 2 [cit. 2008-08-20], s. 155-157. Dostupný z WWW: <http://www.pghardy.net/paul/papers/>.
[Wiki:MapInfo] Wikipedia : MapInfo Professional [online]. 15 August 2008 [cit. 2008-08-20]. Dostupný z WWW: <http://en.wikipedia.org/wiki/MapInfo_Professional>.
[Star-apic] STAR-APIC : Cartographic publishing software [online]. [2008] [cit. 2008-08-20]. Dostupný z WWW: <http://www.star-apic.co.uk/products.html>.
[Neuffer Swisstopo] NEUFFER, Dieter, et al. Database Driven Cartography – The ‘swisstopo’ Example . Vienna : [s.n.], 2006. Dostupný z WWW: <http://www.pghardy.net/paul/papers/>. s. 11.
[VUGTK Slovnik] VÚGTK. TERMINOLOGICKÝ SLOVNÍK ZEMĚMĚŘICTVÍ A KATASTRU NEMOVITOSTÍ : digitální kartografický model [online]. 2005-2008 [cit. 2008-08-20]. Dostupný z WWW: <http://www.vugtk.cz/slovnik/1046_digital-cartographic-model-(dcm)>.
[UGI] Úvod do geografických informačních systémů (GIS) [online]. 2007 [cit. 2008-08-20]. Dostupný z WWW: <http://www.gis.zcu.cz/studium/ugi/elearning/index1.htm>.
[ArcUser] ArcUser : Enhanced Cartography and Geodatabase Improvements at 9.2. ESRI. vol. 1998, no. January–March. Dostupný z WWW: <http://www.esri.com/library/reprints/pdfs/arcuser-cartography.pdf>.
[RepreTutor] ESRI. Representations Tutorial. [s.l.] : [s.n.], 2006. 41 s. Dostupný z WWW: <http://webhelp.esri.com/arcgisdesktop/9.2/pdf/Representations_Tutorial.pdf>.
[Jedlinsky] JEDLINSKÝ, Jan. Způsoby uložení prostorových dat v databázi pro účely pozemkového datového modelu. Plzeň, 2006. 80 s. Západočeská univerzita v Plzni. Vedoucí diplomové práce Ing. Karel Jedlička. Dostupný z WWW: <http://www.gis.zcu.cz/studium/dp/2006/Jedlinsky__Zpusoby_ulozeni_prostorovych_dat_v_databazi_pro_ucely_pozemkoveho_datoveho_modelu__DP.pdf>.
[Vokounova] VOKOUNOVÁ, Lucie. Návrh struktury datového modelu pro správu elektrických distribučních sítí ZČE v GIS analýzou mezinárodního datového modelu ArcFM. Plzeň, 2003. 152 s. Západočeská univerzita v Plzni. Diplomová práce. Dostupný z WWW: <http://www.gis.zcu.cz/studium/dp/2003/Vokounova__Navrh_struktury_datoveho_modelu_pro_spravu_elektrickych_distribucnich_siti_ZCE_v_GIS_analyzou_mezinarodniho_datoveho_modelu_ArcFM__DP.pdf>.
[Pejsa 2007] PEJŠA, Jiří. Úvodní studie do problematiky EuroRegionalMap ČR : Vývoj technologie tvorby map 1:200 000 z dat EuroRegionalMap. Plzeň, 2007. 89 s. Vedoucí bakalářské práce Doc. Ing. Václav Čada, CSc. Dostupný z WWW: <http://www.gis.zcu.cz/studium/dp/2007/Pejsa__Uvodni_studie_do_problematiky_EuroRegionalMap_CR__BP.pdf>.
[AG92 Help] ESRI. ArcGIS Desktop Help 9.2 [online]. 1999-2006 , March 28, 2008 [cit. 2008-08-20]. Dostupný z WWW: <http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=welcome>.
[AG93 Help] ESRI. ArcGIS Desktop Help 9.3 [online]. 1999-2008 , March 15, 2007 [cit. 2008-08-20]. Dostupný z WWW: <http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=welcome>.
[EDN92] ESRI. ArcSDE© 9.2 Developer Help [online]. 1995-2008 [cit. 2008-08-20]. Dostupný z WWW: <http://edndoc.esri.com/arcsde/9.2/welcome.htm>.
[EDN93] ESRI. ArcSDE© 9.3 Developer Help [online]. 1995-2008 [cit. 2008-08-20]. Dostupný z WWW: <http://edndoc.esri.com/arcsde/9.3/welcome.htm>.
[EDN91] ESRI. ArcSDE 9.1 Developer Help [online]. 2005 [cit. 2008-08-20]. Dostupný z WWW: <http://edndoc.esri.com/arcsde/9.1/>.