Modelování konzistentní báze geodat na úrovni datového modelu katastru nemovitostí

Transkript

1 ZÁPADOČESKÁ UNIVERZITA V PLZNI FAKULTA APLIKOVANÝCH VĚD Modelování konzistentní báze geodat na úrovni datového modelu katastru nemovitostí Ing. Karel Janečka Disertační práce k získání akademického titulu doktor v oboru Geomatika Školitel: Doc. Ing. Václav Čada, CSc. Katedra: Katedra matematiky, oddělení geomatiky Datum odevzdání práce: Plzeň, 2009

2 UNIVERSITY OF WEST BOHEMIA IN PILSEN FACULTY OF APPLIED SCIENCES Modelling of consistent geodatabase on data model of cadastre level Ing. Karel Janečka Dissertation thesis in partial fulfillment of requirements for the degree of Doctor of Philosophy in specialization Geomatics Supervisor of dissertation: Doc. Ing. Václav Čada, CSc. Department: Department of mathematics, geomatics section Date of thesis consignation: Pilsen, 2009

3 Věnováno mým rodičům a Lence Dedicated to my parents and Lenka

4 Prohlášení Prohlašuji, že jsem tuto práci vypracoval samostatně pouze s použitím uvedené literatury. V Plzni, Karel Janečka iv

5 Poděkování Na tomto místě bych chtěl poděkovat svému školiteli Doc. Ing. Václavu Čadovi, CSc. za pomoc, rady a pečlivé vedení, které přispělo ke vzniku této práce. Dále děkuji Ing. Jiřímu Poláčkovi, CSc. a Ing. Petru Součkovi, Ph.D., bez kterých by tato práce nemohla vzniknout. V neposlední řadě bych chtěl poděkovat svým rodičům a své ženě Lence, za jejich porozumění a podporu. Karel Janečka v

6 Abstrakt Disertační práce je orientována do oblasti zvýšení kvality, zefektivnění způsobu uložení a publikování prostorových dat katastru nemovitostí, zejména digitální katastrální mapy (DKM) ve spojitosti s informačním systémem katastru nemovitostí (ISKN). Definice cílů práce vycházela bezprostředně z aktuálních potřeb a budoucích plánů Českého úřadu zeměměřického a katastrálního (ČÚZK) v Praze. Veškeré programy, které byly v průběhu práce vytvořeny, pracují s vektorovými prostorovými daty katastru nemovitostí. V práci je proto nejprve popsán aktuální způsob uložení vektorových prostorových dat katastru nemovitostí a popsána specifika vyhodnocení dotazů na prostorová data v něm uložená. Byla provedena rešerže topologických datových struktur jako možného způsobu uložení vektorových prostorových dat v relačních systémech řízení báze dat. Z důvodu historie vzniku a plnění ISKN daty, včetně prostorových, je možné, že se v datech vyskytují různé typy chyb, které brání dalšímu zpracování těchto dat. Je žádoucí, aby se tyto chyby z dat odstranily. To vzhledem k jejich množství není prakticky možné zajistit jinak, než automatizovaně. Byla tak provedena rešerže algoritmů z oblasti výpočetní geometrie, jejichž použití zaručuje efektivní způsob vyhledání některých typů chyb. Dále jsem v práci popsal vlastní algoritmus a postupy, které automatizovaně vyhledávají vybrané typy chyb. ČÚZK svá data poskytuje v několika aplikacích. Data jsou pro tyto aplikace připravována způsoby, z nichž některé již neodpovídají potřebám ČÚZK. Týká se to především převodu definičních bodů parcel a budov, orientační mapy parcel a digitální katastrální mapy do vektorového formátu shapefile. V práci je popsán nový a efektivnější způsob generování těchto vektorových vrstev přímo z ISKN. Práce přináší výstupy a závěry, které mají praktický dopad na vybraná data katastru nemovitostí, především na zvýšení jejich kvality v ISKN a způsob přípravy pro publikování v aplikacích ČÚZK. V práci je popsán možný způsob uložení prostorových dat katastru nemovitostí v Oracle Spatial, včetně praktického ověření přechodu od současného datového modelu do interních modelů pro uložení vektorových dat v nadstavbě Spatial. Uložení dat v datových strukturách Oracle Spatial umožní plné využití funkcionality, která je v nadstavbě Spatial k dispozici. vi

7 Abstract This doctoral thesis is oriented on improving of data quality of spatial data of cadastre, especially of digital cadastral map (DCM). Next I solved the problem how to store DCM in database in more efficient way and how to convert this data from the information system of cadastre (ISC) into the shapefile for their publishing in various applications. Definition of objectives resulted from actual requirements and future plans of the Czech Office of Survaying, Mapping and Cadastre (COSMC) in Prague. All programs which were created work with spatial data of cadastre. Hence first of all I described the actual way of storage of spatial data of cadastre in ISC. Next I discussed the problem of spatial queries on DCM. Background research of topology data models as a possible way how to store spatial data in database was done. Due to the history of creation of ISC and the way of its data filling it is possible that we can find some inconsistencies in spatial data in ISC. This fact precludes to the automatic processing of this data. of course, we want to remove these inconsistencies. Due to the huge amount of spatial data in ISC we have to do it in the appropriate manner. We can use some algorithms from the field of computational geometry to solve this problem. I also proposed my own algortithms for finding some types of inconsistencies. COSMC provides its data in several applications. the way of preparation of spatial data for their usage in these applications is today not appropriate. I proposed new and more effective way how to convert definition points of parcels and buildings, orientation map of parcels and digital cadastral map into shapefile direct from ISC. This doctoral thesis produces results which affect spatial cadastral data. the data quality was increased as well the way of their conversion into the shapefile data format was rectified. There we can find detail description how to store cadastral data in Oracle Spatial in this work. Next the way of conversion between ISC and Oracle Spatial was described and verified in this work. Storing of cadastral data in Oracle Spatial brings the possibility to use that many functions as many as Oracle Spatial offers. vii

8 Obsah 1 Úvod 18 2 Možnosti uložení prostorových dat v informačních systémech Topologické datové modely pro dvojdimenzionální prostor Využití topologicky strukturovaných dat v SŘBD Vybrané topologické datové struktury Left right topologie bez odkazů na hrany Left right topologie s ukládáním odkazů na hrany Okřídlená hrana Geometrický popis prvků nad topologicky strukturovanými daty Topologický koncept firmy ESRI Topologický koncept firmy Laser-Scan Porovnání konceptu Geodatabase a Radius Topology Topologicky či netopologicky strukturovaná data? Ukládání a dotazování topologicky strukturovaných dat v Oracle Spatial Současný datový model uložení prostorových dat v ISKN Prostorová data v Informačním systému katastru nemovitostí Výběr hranice parcely z ISKN Využití výpočetní geometrie pro nalezení nekonzistencí v prostorových datech Nalezení dvojice nejbližších bodů pomocí techniky sweep line Nalezení všech průsečíků v množině úseček AVL strom Vlastnosti vrcholů AVL stromu Vlastnosti AVL stromu Operace Automatická lokalizace chyb v prostorových datech ISKN Duplicitní mapové značky

9 5.2 Duplicitní definiční body budov Duplicitní vztažné body pro umístění textových prvků Nespočtené průsečíky Šťopky Prázdné polygony Algoritmus Najdi prázdné polygony Program Prazdne polygony Neplatná hodnota atributu TYPPPD KOD Hraniční úseky parcel se shodným počátečním a koncovým bodem Nevalidní geometrické popisy Procedura KAJA NEVALIDNI GM KP Procedura KAJA NEVALIDNI GM KU Funkce VALIDATE GEOMETRY WITH CONTEXT Tvorba dat pro vybrané aplikace ČÚZK Současný způsob přípravy dat pro vybrané aplikace ČÚZK Datový formát shapefile GeoTools Generování definičních bodů do formátu shapefile Funkční požadavky na program GenerovaniSHP.jar Generování definičních bodů pro zvolené katastrální území Generování definičních bodů pro všechna katastrální území, obsahující alespoň jeden definiční bod Generování definičních bodů pro všechna katastrální území pro zvolený počet dnů zpětně Kontrola funkčnosti Grafická ukázka výstupu z programu GenerovaniSHP.jar Převod digitální katastrální mapy do formátu shapefile Digitální katastrální mapa Funkční požadavky na program DKM2SHP.jar Generování kružnic Generování kruhových oblouků Generování křivek Interpolační křivky Fergusonova kubika Kubické spline křivky Generování dlaždic GenerujSit.jar Aktuální stav tvorby DKM

10 Program StatistikyDigitalizace.jar Převod orientační mapy parcel do formátu shapefile Orientační mapa parcel Funkční požadavky na program OMP2SHP.jar Grafická ukázka výstupu z programu OMP2SHP.jar Převod vybraných grafických dat ISKN do datových struktur Oracle Spatial Oracle Spatial Objektově-relační model Spatial Podporované geometrické typy Hierarchické uspořádání dat v Oracle Spatial Souřadnicový systém Tolerance Dotazovací model Indexování prostorových dat v Oracle Spatial Porovnání datových struktur Čtyřstrom a R-strom pro indexaci prostorových dat v prostředí Oracle Spatial Datový typ SDO GEOMETRY Atribut SDO GTYPE Atribut SDO SRID Atribut SDO POINT Atribut SDO ELEM INFO Atribut SDO ORDINATES Metody objektového datového typu SDO GEOMETRY Geometry Metadata Views Atribut TABLE NAME Atribut COLUMN NAME Atribut DIMINFO Atribut SRID Topologický koncept okřídlené hrany Tabulky pro uložení topologie Node information table Face information table Edge information table Relation information table Datový typ SDO TOPO GEOMETRY Konstruktor pro operaci vkládání specifikující topologické elementy Metoda GET GEOMETRY

11 7.5.9 Hierarchie vrstev geometrických popisů topologických prvků Program DKM2Spatial.jar Převod vybraných dat katastru nemovitostí do objektově-relačního datového modelu Převod vybraných dat katastru nemovitostí do topologického datového modelu Vytvoření objektově-relačního modelu vybraných prostorových dat katastru nemovitostí Vytvoření tabulek obsahující sloupec typu SDO GEOMETRY Načtení dat do tabulek Aktualizace metadat o sloupcích typu SDO GEOMETRY Vytvoření prostorových indexů Kontrola a vizualizace načtených dat Vytvoření topologie z topologicky strukturovaných dat Vytvoření topologie Načtení topologických dat do tabulek Vytvoření prvkových tabulek Asociace prvkových tabulek s topologií Inicializace topologických metadat Načtení dat do prvkových tabulek pomocí konstruktoru typu SDO TOPO GEOMETRY Kontrola topologie Nároky na uložení Vyhodnocení prostorových dotazů Možnosti rozšíření programu DKM2Spatial.jar Závěr 145 A Obsah přiloženého DVD 152 B Automatická lokalizace chyb v prostorových datech ISKN 154 B.1 SQL dotaz pro vybrání šťopek B.2 Vytvoření procedury KAJA ZRUSENA PLATNOST TYPPPD KOD B.3 Vytvoření procedury KAJA NAJDI DUPL VRCH KU B.4 Vytvoření procedury KAJA NAJDI DUPL VRCH KP B.5 Vytvoření procedury KAJA NEVALIDNI GM KU

12 B.6 Vytvoření procedury KAJA NEVALIDNI GM KP C Vytvořené pomocné funkce v centrální databázi ISKN 162 C.1 PL/SQL funkce pro vytvoření osmimístného čísla bodu C.2 PL/SQL funkce pro vypsání pole souřadnic C.3 PL/SQL funkce pro vypsání pole s informacemi o geometrickém prvku D DKM2Spatial.jar 165 D.1 SQL dotaz pro výběr vstupních dat

13 Seznam obrázků 1.1 Cíle práce Left right topologie bez odkazů na hrany Left right topologie s ukládáním odkazů na hrany Okřídlená hrana Ukázka topologického pravidla z konceptu ESRI Geodatabase Struktura Radius Topology Zrekonstruovaný datový model pro uložení prostorových dat v ISKN sweep-line technika pro nalezení dvojice nejbližších bodů Omezení vyhledávací oblasti pro nalezení dvojice nejbližších bodů Ukázka ne-avl stromu Stejný strom poté, co byl vyvážen Ukázka LL-rotace stromu Ukázka RR-rotace stromu Ukázka RL-rotace stromu Ukázka LR-rotace stromu Nalezená duplicitní mapová značka Nalezená duplicitní mapová značka Nalezený nespočtený průsečík ve vnitřní kresbě Ukázka nalezené šťopky Prázdný polygon - přehled Prázdný polygon - detail Ukázka výpisu prázdného polygonu Definiční body v katastrálním území Detail vygenerované DKM - liniové a bodové prvky Vygenerovaná dlaždice DKM Vygenerovaná kružnice a kruhový oblouk Vygenerované křivky a kruhové oblouky Způsob řazení dat Statistika tvorby DKM Vygenerovaný mapový list orientační mapy parcel

14 7.1 Dotazovací model Ukázka MBR Hierarchický R tree index Bodový čtyřstrom Plošný čtyřstrom Oracle nine-intersection model Koncept okřídlené hrany Ukázka topologických primitiv Mapování mezi prvkovou tabulkou a tabulkami s topologickými primitivy Ukázka uzlů, hran a stěn Hierachire vrstev zjednodušeného administrativního členění ČR Vytvoření tabulky AK PARCELY obsahující sloupec datového typu SDO GEOMETRY Vytvoření tabulky AK DEF BODY obsahující sloupec datového typu SDO GEOMETRY Aktualizace metadat o sloupcích datového typu SDO GEOMETRY Vytvoření prostorových indexů nad sloupci typu SDO GEOMETRY Kontrola validnosti geometrie Zobrazení parcel a definičních bodů uložených pomocí objektověrelačního modelu Vytvoření topologie Vytvoření prvkové tabulky KATASTR AK PARCELY Vytvoření prvkové tabulky KATASTR DEF BODY Asociace prvkových tabulek s topologií Inicializace topologických metadat Rozšíření tabulky KATASTR AK PARCELY o sloupec geometrie Naplnění sloupce GEOMETRIE v tabulce KATASTR AK PARCELY Aktualice metadat o sloupci GEOMETRIE Vytvoření prostorového indexu nad sloupcem geometrie Zobrazení katastrálního území uloženého pomocí okřídlené hrany Zobrazení parcel a definičních bodů uložených pomocí okřídlené hrany Testování metody get geometry Velikost bloku v testovací databázi Zjištění velikosti tabulky Přehled vytvořených indexů Použití funkce QUALITY DEGRADATION A.1 Obsah přiloženého DVD

15 Seznam tabulek 2.1 Časy (v sekundách) potřebné ke zodpovězení dotazů [LOUW] Datové bloky ve skupině PKMP Vybrané bloky ze skupiny NEMO Vzájemná závislost úrovně dlaždic, průměrného počtu dlaždic na jeden objekt a času potřebného pro vytvoření indexu ([KORA]) Porovnání časů potřebných pro vytvoření a aktualizaci jednotlivých indexů [22] Porovnání průměrných časů (průměr pro různé velikosti dotazovacího okna) pro vyhodnocení dotazů nad daty USBG ([KORA],[ORSG]) Předdefinované hodnoty atributu SDO GTYPE Struktura tabulky <topology-name> NODE$ Struktura tabulky <topology-name> FACE$ Struktura tabulky <topology-name> EDGE$ Ukázka vzájemné provázanosti identifikátorů v tabulce <topologyname> EDGE$ Struktura tabulky <topology-name> RELATION$ Atributy datového typu SDO TOPO GEOMETRY Velikost tabulek s prostorovými daty katastru nemovitostí Velikost indexů Časy potřebné pro vybrání prvků pomocí dotazovacího okna Časy potřebné pro vybrání prvků pomocí dotazovacího okna pro functionbased index

16 Seznam ukázek 3.1 Vybrání částí hraničních úseků parcel Ukázka z vygenerovaného souboru 201 dupl-map-znacky.txt Ukázka z vygenerovaného souboru 101 dupl-def-body-budov.txt Ukázka z vygenerovaného souboru 201 dupl-parcelni-cisla.txt Ukázka výstupu procedury KAJA ZRUSENA PLATNOST TYPPPD Ukázka spuštění procedury KAJA NAJDI DUPL VRCH KP Ukázka obsahu souboru 301-duplicitni-vrcholy (soubor obsahující úseky se shodným počátečním a koncovým bodem pro katastrální pracoviště s kódem 301) Ukázka spuštění procedury KAJA NEVALIDNI GM KP pro katastrální pracoviště s kódem Ukázka výstupu pro katastrální pracoviště České Budějovice Definice funkce VALIDATE GEOMETRY WITH CONTEXT Podmínka pro výběr definičních bodů zpětně Kontrola počtu definičních bodů Ukázka souboru sit2000.sql. Příklad vložení jedné dlaždice Definicie tabulky KAJA SIT CR Definice datového typu SDO GEOMETRY Definice datových typů SDO POINT TYPE, SDO ELEM INFO ARRAY a SDO ORDINATE ARRAY Definice typu SDO DIM ARRAY Definice typu SDO DIM ELEMENT Definice datového typu SDO TOPO GEOMETRY Definice konstruktoru SDO TOPO GEOMETRY Definice konstruktoru SDO TOPO GEOMETRY Definice datového typu SDO TOPO OBJECT ARRAY Ukázka souboru parcely.sql Ukázka souboru def-body.sql Ukázka souboru steny.sql Ukázka souboru hrany.sql Ukázka souboru node.sql Ukázka souboru topo ak parcely.sql Ukázka souboru topo def body.sql

17 7.16 Vložení universal face Anonymní PL/SQL blok pro zjištění doby trvání prostorového dotazu nad datovým typem SDO GEOMETRY Anonymní PL/SQL blok pro zjištění doby trvání prostorového dotazu nad datovým typem SDO TOPO GEOMETRY Anonymní PL/SQL blok pro zjištění doby trvání prostorového dotazu pomocí function-based indexu Definice funkce VRAT GEOMETRII Definice funkce VRAT GEOMETRII Vytvoření indexu nad funkcí VRAT GEOMETRII Aktualizace pohledu USER SDO GEOM METADATA B.1 Zdrojový kód SQL dotazu pro výběr šťopek z ISKN B.2 Zdrojový kód SQL dotazu pro výběr prvků se zrušenou platností kódu typppd kod z ISKN B.3 Vytvoření procedury KAJA NAJDI DUPL VRCH KU B.4 Vytvoření procedury KAJA NAJDI DUPL VRCH KP B.5 Vytvoření procedury KAJA NEVALIDNI GM KU B.6 Vytvoření procedury KAJA NEVALIDNI GM KP C.1 Funkce vracející osmimístné číslo bodu C.2 Funkce vypisující pole souřadnic do textového řetězce C.3 Funkce vypisující pole s informacemi o geometrickém prvku do textového řetězce D.1 Výběr vstupních dat pro program DKM2Spatial.jar

18 Kapitola 1 Úvod Od června roku 2006 do září roku 2008 probíhala intenzivní spolupráce mezi mnou, jakožto předkladatelem této disertační práce a sekcí centrální databáze na Českém úřadu zeměměřickém a katastrálním v Praze (ČÚZK). Cílem této vzájemné spolupráce byla realizace několika hlavních bodů: Návrh a implementace algoritmů a postupů zajišťujících konzistenci prostorových dat v informačním systému katastru nemovitostí (ISKN). Vytvoření nástroje pro generování grafických výstupů z ISKN tak, aby tato data mohla být dále poskytována v aplikacích ČÚZK. Vytvoření transformačního modulu pro přechod ze současného způsobu uložení vybraných prvků prostorových dat ISKN do datových struktur Oracle Spatial a testování tohoto prostředí pro uložení a správu vybraných prvků grafických dat ISKN. Cíle práce byly motivovány především plánovanou centralizací informačního systému katastru nemovitostí a snahou zpřístupnit prostorová data včetně navázaných atributových dat moderním způsobem odborné a širší veřejnosti. Je žádoucí, aby budoucí centrální databáze ISKN obsahovala validní prostorová data, především z důvodu jejich dalšího zpracování v různých aplikacích a systémech, které s daty katastru nemovitostí pracují. ČÚZK poskytuje svá data v několika aplikacích. Současný a možný budoucí způsob přípravy vybraných prostorových dat pro jejich využití v těchto aplikacích, zejména ve WMS a Nahlížení do katastru nemovitostí, je popsán v této práci. V práci je dále uveden popis současného způsobu uložení prostorových dat v informačním systému katastru nemovitostí a specifika dotazování dat nad současným způsobem uložení prostorových dat. Uvedl jsem souhrnný přehled vybraných topologických datových struktur jako možné varianty pro uložení dat katastru nemovitostí s uvedením základních výhod a nevýhod konkrétní struktury, 18

19 včetně rešerše porovnání mezi uložením prostorových dat ve zvolené topologické datové struktuře a přímým uložením geometrických popisů prostorových prvků. V práci je také diskutována otázka zajištění konzistence vektorových prostorových dat v ISKN, mimo jiné s využitím algoritmů výpočetní geometrie a popsány způsoby identifikace chyb, které se prozatím v datech vyskytují. Řešena je také otázka aktualizace způsobu přípravy vybraných prostorových dat katastru nemovitostí pro jejich následné poskytování ve vybraných aplikacích ČÚZK. Podrobně je v práci popsáno prostředí Oracle Spatial, jako možná varianta pro efektivní uložení a správu dat katastru nemovitostí. Při vypracování disertační práce jsem chtěl v této oblasti navázat na výsledky mé diplomové práce a rozšířit poznání v problému uložení a správy vybraných prostorových dat katastru nemovitostí pomocí nadstavby Spatial. Souhrnně jsou cíle práce znázorněny na obrázku 1.1. Obrázek 1.1: Cíle práce 19

20 Kapitola 2 Možnosti uložení prostorových dat v informačních systémech Potřeba integrované architektury v databázových systémech pro uložení geodat, kdy jsou v databázi uložena nejen data popisná (jméno, příjmení, adresa atd. s využitím standardních databázových datových typů), ale rovněž prostorová, je v současnosti zřejmá. Dodavatelé databázových systémů mají ve svých produktech již integrované prostorové datové typy více či méně odpovídající specifikacím OGC (Open Geospatial Consortium). Podle těchto specifikací může být prostorový objekt reprezentován v systému řízení báze dat dvěma rozdílnými logickými vektorovými modely: geometrickým datovým modelem, topologickým datovým modelem. Oba modely mají své silné a slabé stránky. Geometrický přístup nabízí přímý přístup k souřadnicím objektů, topologický přístup naproti tomu ukládá informace o prostorových vztazích (např. sousednost). Vzhledem k tomu, že geometrický model poskytuje přímý přístup k souřadnicím, společné části sousedních polygonů jsou uloženy vícekrát, což vede k redundanci dat. Topologický přístup eliminuje tyto duplicity v datech použitím odkazů (references) na jednoznačně identifikovatelná topologická primitiva. V průběhu posledních let dochází k testování a implementaci uložení prostorových dat pomocí topologických datových struktur. Existují především komerční řešení, která otázku uložení prostorových dat v topologických strukturách řeší různými způsoby s využitím vlastních topologických modulů (topology engines). 20

21 2.1 Topologické datové modely pro dvojdimenzionální prostor Základními (bude uvažována pouze situace v 2D) topologickými primitivy 1, formálně popsaných a nadefinovaných např. v [GUSC] jsou: uzel (node) hrana (edge) stěna (face) 2.2 Využití topologicky strukturovaných dat v SŘBD Pro uložení topologické informace uvnitř systému řízení báze dat musí být vytvořeny tabulky, ve kterých budou uloženy informace o stěnách, hranách a uzlech. To znamená, bude zapotřebí minimálně tří tabulek. Struktura tabulek závisí na volbě konkrétního topologického modelu. Vzhledem ke skutečnosti, že geometrie stěn je uložena přes odkazy mezi jednotlivými topologickými primitivy, je zapotřebí implementovat funkci, která z uložených dat pomocí referencí zrekonstruuje geometrický popis stěn. Relační systém řízení báze dat může mimo jiné efektivním způsobem uložit odkazy na topologická primitiva: například na stěnu na levé a pravé straně hrany, odkaz z jedné hrany na přilehlou sousední hranu atd., tzn. modelování dat pomocí topologie. Avšak systém řízení báze dat plně nepodporuje správu topologické struktury, pokud není schopen provést kontroly konzistence dat, jako například, zda je stěna uzavřena, zda nedochází ke křížení některých hranic a pokud nenabízí potřebné operátory pro: základní editační operace (rozdělení/spojení stěny, vložení/odebrání hrany), výpočet obvodu nebo obsahu topologicky reprezentované plochy, řešení otázek typu: jaké plochy jsou dotčeny daným dotazem?, výběr sousedních prvků,... a další 1 Topologický objekt, který reprezentuje jednotlivý nerozložitelný prvek (ČSN EN ISO 19107) 21

22 Problémem pro řešení bodů uvedených výše je skutečnost, že deklarativní jazyk SQL nemůže realizovat navigační přístup k datům. V SQL například nelze vyjádřit požadavek: sleduj odkaz next na sousední přilehlou hranu, dokud nejsme zpět ve výchozím uzlu. Samozřejmě je to snadno řešitelné použitím některého vyššího programovacího jazyka. Ačkoli jsou některé operace v relačním systému řízení báze dat nad topologicky strukturovanými daty obtížné, jako například výpočet plochy, má tato struktura mnoho výhod: odstraňuje duplicitu v ukládaných datech, po editaci dat je snazší udržet konzistenci dat, topologický přístup je výhodnější při vizualizaci v některých front end systémech, protože se z disku načítá menší množství potřebných dat, je efektivní pro vybrané typy dotazů, například dotaz na nalezení sousedů. Některé relační systémy řízení báze dat jsou v současnosti obohaceny o prvky objektově orientované technologie. To umožňuje rozšíření SŘBD o nové datové typy a funkce, které existují a pracují uvnitř DBMS. V kapitolách 2.3 až 2.9 jsou ve stručnosti popsány vybrané práce, které se zabývaly popisem a testováním vybraných řešení pro správu topologicky strukturovaných dat. Velmi často bylo v těchto pracích provedeno srovnání s popisem prostorových dat s využitím geometrických primitiv. Některé práce rovněž porovnávaly vybraná komerční řešení mezi sebou. 2.3 Vybrané topologické datové struktury Popis uvedených struktur čerpá především poznatky z [MEIJ] a [QUST]. Obecně mohou být topologické struktury charakterizovány následujícími parametry: použitá topologická primitiva (uzel, hrana, stěna), orientace elementů (ano/ne), uložení explicitních topologických vztahů (odkaz na stěnu vlevo,... ), definice topologických pravidel (není dovoleno křížení hran,... ). 22

23 2.3.1 Left right topologie bez odkazů na hrany Left right topologie bez odkazů na hrany je založena na ukládání informací o stěně vlevo a vpravo pro každou orientovanou hranu. Na základě této informace můžeme získat kolekci hran náležejících jedné stěně a z nich stěnu zrekonstruovat. Všechny hrany jsou orientované a každá hrana má počáteční a koncový uzel. Mezi vybranými hranami musí proběhnout operace vyhledání hran, které lze dočasně vzájemně navázat, tzn. mající společný uzel. Obrázek 2.1: Left right topologie bez odkazů na hrany Ve chvíli, kdy jsou vytvořeny dočasné hranové řetězce, musí být souřadnice uzlů orientovány příslušným způsobem, tzn. hranový řetězec utvářející vnější hranici v protisměru chodu hodinových ručiček, hranové řetězce utvářející vnitřní hranice ve směru chodu hodinových ručiček. Tato orientace může být odvozena z výpočtu tzv. signed area pro každý dočasný hranový řetězec. Každý hranový řetězec obsahuje n bodů (x 1, y i ), i = 0,..., n, x 0 = x n, y 0 = y n. Signed area je pak vypočítána podle následujícího vztahu kde a i = x i y i+1 x i+1 y 1. A signed = 1 n 1 a i, (2.1) 2 i=0 23

24 Rozhodnutí, který dočasný hranový řetězec bude označen jako vnitřní a které dočasné hranové řetězce jako vnější, závisí na velikosti absolutní hodnoty A signed. Hranový řetězec s nejvyšší hodnotou musí být řetězcem vnějším. Výhodou tohoto přístupu je, že se do databáze neukládá příliš mnoho odkazů. Nevýhodou je naproti tomu nemožnost rozhodnout, které dočasné hranové řetězce jsou vnitřní a který vnější bez nutnosti provedení geometrických výpočtů. Rovněž je nutná operace vyhledání sousedních (navazujících) hran Left right topologie s ukládáním odkazů na hrany Tento model je opět založen na ukládání informací o stěně vlevo a stěně vpravo pro každou orientovanou hranu. Na základě této informace může být vybrána množina hran, které náleží jedné stěně. Každá hrana obsahuje dva uzly počáteční a koncový. Pomocí těchto informací o uzlech lze zrekonstruovat dočasný hranový řetězec. Obrázek 2.2: Left right topologie s ukládáním odkazů na hrany Za další, pro každou stěnu jsou explicitně uloženy odkazy na její vnější hranový řetězec a všechny vnitřní hranové řetězce. Odkazy na počáteční hrany těchto řetězců mají přiřazeny znaménko, aby bylo zřejmé, jak jsou počáteční hrany vůči stěně orientovány. Dočasné hranové řetězce pak mohou být díky této informaci přímo korektně orientovány bez nutnosti dalších výpočtů, což je hlavní výhoda tohoto konceptu. Nevýhodou je režie nutná pro ukládání odkazů na počáteční hrany a znamének u každé stěny. 24

25 2.3.3 Okřídlená hrana Koncept okřídlené hrany je založen na ukládání nejméně dvou odkazů u každé orientované hrany. Odkazů na next left hranu a next right hranu. Pomocí těchto odkazů je možné snadno utvářet hranové řetězce. Rovněž by u každé orientované hrany měly být uloženy odkazy na stěnu vlevo a stěnu vpravo od hrany. Pro každou stěnu je uložen odkaz na počáteční hranu vnějšího hranového řetězce a odkazy na počáteční hrany vnitřních hranových řetězců. Odkazy na počáteční hrany řetězců jsou ukládány společně s orientacemi počátečních hran vůči stěně, což je důležité pro správnou orientaci vnější hranice, resp. vnitřních hranic stěny. Obrázek 2.3: Okřídlená hrana Při sestavování hranového řetězce začneme u počáteční hrany a pokračujeme podle znaménka odkazu na tuto hranu buď hranou pod odkazem next left, případně next right. Proces končí ve chvíli, kdy bychom do řetězce přidali počáteční hranu. Výhodou této struktury je jednoduchost konstrukce hranového řetězce, pouze pomocí odkazů. Velmi rychle by tak byl například zodpovězen požadavek na vybrání všech (hranic) parcel, pokud by tyto byly uloženy pomocí konceptu okřídlené hrany. Nevýhodou je udržování velkého množství odkazů, což může při značném objemu dat (miliony parcel) vést ke zvýšenému nároku na diskový prostor [PEQU]. 25

26 2.4 Geometrický popis prvků nad topologicky strukturovanými daty V [BAUM] bylo řešeno uložení prostorových dat do vybrané topologické struktury a především implementace funkce, která provádí převod prostorového popisu prvku z topologických primitiv do popisu s využitím geometrických primitiv. Tento model pak podporuje to nejlepší z obou přístupů. U topologického přístupu je to odstranění redundance dat, u geometrického přístupu, pokud bude nad danou funkcí vybudován vhodný index, snadnost dotazování a analýz geometrických primitiv. V praktické části práce se použila data katastrální mapy, protože topologie hraje klíčovou roli v množině dat reprezentujících parcely pokrývající nějaké území. Data byla uložena do struktury left-right topologie s odkazy (viz kapitola 2.3.2). Pro možnost rozšíření jádra SŘBD (konkrétně byl v práci využit SŘBD od firmy Oracle ve verzi 9i) o topologickou funkcionalitu byla vytvořena tabulka s metadatovými informacemi popisujícími topologickou strukturu v SŘBD. Naprogramovaná funkce v jazyce PL/SQL pomocí metadatových informací realizuje geometrické popisy prvků (využití objektového datového typu SDO GEOMETRY, viz 7.3, [ORSG]) z primitiv topologických. Pro rychlejší odpovědi na prostorové dotazy byl nad příslušnou funkcí vystavěn prostorový index (function based index). Ve verzi 10g je tento postup již zastaralý. Není nutné programovat vlastní funkci na získání geometrického popisu prvku z topologických primitiv, k dispozici je totiž metoda GET GEOMETRY (kapitola 7.5.8) datového typu SDO TOPO GEOMETRY (kapitola 7.5.6). Poté je možné naprogramovat funkci, která bude danou metodu volat a vytvořit index nad touto naší funkcí. 2.5 Topologický koncept firmy ESRI V topologickém konceptu firmy ESRI ESRI Geodatabase uživatel definuje topologická pravidla z množiny nabízených pravidel. To znamená, že uživatel rozhoduje, které topologické vztahy jsou pro něj důležité a podle toho určí žádné či několik topologických pravidel. Topologická primitiva nejsou udržována jako speciální typ prvku; namísto toho je jako persistentní udržována geometrie prvku. Data jsou uložena jako objekty, s geometrií reprezentovanou v podobě seznamu souřadnic. Topologie musí být vytvořena na základě množiny topologických pravidel, jako například parcely se nesmí překrývat nebo budovy se nesmí překrývat s vodními plochami. Pokud máme vytvořena tato topologická pravidla, můžeme provést kontrolu topologie v rámci příslušné datové množiny. Topologické chyby se pouze objeví v tabulce chyb (error-table), nedojde k jejich odstranění. Proces validace topologie je fundamentální operace nad topologií definovanou pomocí pravidel prováděná topologickým enginem. Proces validace je odpovědný 26

27 Obrázek 2.4: Ukázka topologického pravidla z konceptu ESRI Geodatabase za kontrolu všech určených topologických pravidel a generování chybových hlášení o místech, kde byla pravidla porušena. 2.6 Topologický koncept firmy Laser-Scan Topologický koncept firmy Laser-Scan Radius Topology je odlišný od ESRI Geodatabase. Uživatel se rozhodne, zda bude mít v databázi trvale uložen prostorový popis prvků pomocí geometrických a zároveň topologických primitiv, nebo zda bude mít trvale uložena pouze topologická primitiva a prostorový popis prvků pomocí geometrických primitiv bude odvozován. V konceptu Radius Topology může být mapa reprezentována jako lineární (jednodimenzionální) síťová topologie nebo jako dvojdimenzionální rovinná topologie. Síťová topologie používá uzlová a hranová primitiva k popisu vzájemně propojených liniových prvků a bodů na mapě. Rovinná topologie používá navíc primitiva stěna k možnosti popsat dvojdimenzionální oblasti, které se v mapě vyskytují. Veškeré požadované topologické odkazy jsou uloženy explicitně v mnoha tabulkách. Tabulka edge-to-edge umožňuje využití modelu okřídlené hrany. V konceptu Radius Topology je možné data udržovat v tzv. manifolds (oblasti zájmu). Příkladem manifolds mohou být například administrativní jednotky, typy vegetace či způsob využití půdy. Manifolds dovolují aplikaci vytvořit a spravovat nezávislé topologické množiny dat v rámci jednoho systému řízení báze dat. Topologický koncept Radius Topology je zachycen na obrázku Porovnání konceptu Geodatabase a Radius Topology V [BAST] bylo provedeno porovnání mezi datovým modelem firmy ESRI a datovým modelem firmy Laser-Scan pro správu topologických dat. Porovnání spočívalo v provedení provozních analýz (functional analysis) správy topologické struk- 27

28 Obrázek 2.5: Struktura Radius Topology tury. Datová sada použitá v testech obsahovala mnoho topologických chyb, takže mohlo být provedeno srovnání, který z topologických konceptů najde více takových chyb. Rovněž byla testována situace editace dat - přidání nových polygonů nebo naopak odebrání některých polygonů z dat. Základní otázka této práce zněla: Jaké jsou hlavní rozdíly mezi datovým modelem, u kterého je topologická konzistence založena na pravidlech definované topologie (ESRI) a datovým modelem, který aplikuje explicitní topologickou strukturu (Laser-Scan)? Podle [CLFE] jsou topologické vztahy definovány jako podmnožina prostorových vztahů charakterizovaných vlastností, že zůstávají zachovány po topologických transformacích jako jsou posun, rotace nebo změna měřítka. Zřejmě by bylo možné snadno zpracovat prostorové dotazy, pokud by všechny geometrické vztahy mezi objekty byly explicitně uloženy; avšak tato možnost je vzhledem k případným nárokům na diskový prostor, správě obrovského množství dat a dalším faktorům z toho plynoucích, nereálná. Namísto toho je více vhodné uložit pouze vybrané vztahy (například sousednost) a zbylé v případě potřeby dopočítat. 28

29 Výhody a nevýhody obou konceptů V testech byl použit software ArcGIS 8.3 firmy ESRI a Radius Topology firmy Laser-Scan nakonfigurovaný s databázovým systémem Oracle 9i s nadstavbou Spatial. Hlavní výhody konceptu Geodatabase jsou: Topologická struktura není explicitně uložena. Uživatel rozhodne, která topologická pravidla jsou pro jeho účely důležitá. Uživatel rozhodne, co se má stát s prostorovými objekty, pokud nesplňují všechny topologické podmínky. Topologické chyby nejsou řešeny automaticky, musí být vyřešeny uživatelem. Proces validace dat je v porovnání s Radius Topology relativně krátký. Po editaci některých objektů v geodatabázi nemusí být validována všechna data, ale pouze editovaná data (tzv. dirty area). Topologický koncept Geodatabase je uživatelsky přívětivý. Pro vytvoření množiny logických podmínek nad daty nevyžaduje speciální znalosti o topologii. Rovněž je k dispozici velmi názorný průvodce implementováním topologických pravidel. Hlavní nevýhody konceptu Geodatabase jsou: Přílišná redundance v datech; všechny hrany sdílené mezi sousedními prvky jsou uloženy dvakrát. Po validaci topologie data stále nesplňují kladené topologické podmínky, pokud se v datech vyskytují nějaké chyby. Na chyby je uživatel pouze upozorněn, k jejich odstranění je zapotřebí jeden krok navíc. Pokud se objeví objekt, který nesplňuje specifikované podmínky, nemusí to nutně znamenat, že jsou zde topologicky špatná data. Je možné, že některá z podmínek není definována dobře. Ne všechna topologická pravidla mohou být implementována. Hlavní výhody Laser-Scan Radius Topology jsou: Topologie je explicitně vyjádřena. Uživatel může vložit data do databáze pouze v případě, že jsou tato data topologicky korektní nebo pokud je umožněna automatická oprava chyb. 29

30 Po vložení dat do topologické struktury se uživatel o topologii nemusí dále starat, data v topologické struktuře zůstávají korektní. To může být mimo jiné užitečné ve chvíli, kdy firma poskytuje data zákazníkům. Zákazník má jistotu, že dostává topologicky validní data. Pomocí SQL je možné dotazovat databázi na úrovni systému řízení báze dat. V tomto topologickém modelu je každá hrana uložena v databázi pouze jednou. Radius Topology je postaven na standardech, otevřený a interoperabilní a není proto svázán s jediným konkrétním dodavatelem. Mezi nevýhody Laser-Scan Radius Topology patří: Proces validace zabere relativně velmi mnoho času. Provede se ovšem pouze jednou. Nejsou možná topologická pravidla založená na sémantice. Vzhledem k topologické struktuře a mnoha referenčním tabulkám (tabulky s odkazy) jsou zvýšeny nároky na uložení dat. ESRI a Laser-Scan mají odlišný přístup ke správě topologie, přičemž oba dva přístupy mají svá pro a proti. Výběr konkrétního řešení závisí na požadavcích kladených na výslednou aplikaci pracující nad prostorovými daty. 2.8 Topologicky či netopologicky strukturovaná data? V práci [LOUW] bylo testováno, zda je systém řízení báze dat (SŘBD) využívající topologickou strukturu pro uložení prostorových dat z hlediska funkčnosti a výkonu lepší než SŘBD využívají netopologickou datovou strukturu. Testy probíhaly s využitím Radius Topology. Hlavní otázka studie byla rozdělena do několika dílčích: Jakým způsobem je topologická struktura implementována v SŘBD? Jakou funkcionalitu (modelování dat, dotazování, editování,... ) nabízí Radius Topology? Jaké jsou požadavky (z pohledu místa na pevném disku) na uložení topologicky a netopologicky strukturovaných dat (data popsána pomocí geometrických primitiv)? 30

31 Jsou výsledky dotazů shodné při použití obou způsobů uložení dat? Jsou výsledky prostorových dotazů získány rychleji s využitím topologicky strukturovaných dat, nebo je lepší popis dat pomocí geometrických primitiv (tzv. plain geometry)? Data využitá pro tato testování byla v měřítku 1:50000 (region Flevoland, Nizozemí). Editace topologicky strukturovaných dat v Radius Topology je omezena několika pravidly. Ty zabraňují vzniku nekonzistencí v datové sadě a garantují kvalitu dat. Výkonnostní test Radius Topology sestával z porovnání požadavků na uložení (z pohledu použitého místa na pevném disku) pro verzi plain geometry a verzi topologickou a z porovnání výsledků některých prostorových dotazů. Teoreticky by se nechalo předpokládat, že topologicky strukturovaná dat budou vyžadovat méně prostoru pro své uložení než v případě plain geometry. Zřejmě proto, že se ukládá pouze geometrie uzlů a dále odkazy mezi jednotlivými topologickými primitivy a ne celý geometrický popis prvku jako v případě plain geometry, což nutně vede k redundanci dat. Ovšem výsledkem porovnání potřebného místa pro uložení dat je skutečnost, že nároky topologicky strukturovaných dat jsou mnohem vyšší. Vysvětlením je způsob, jakým Radius Topology implementuje topologickou strukturu. Radius Topology využívá pro uložení primitiv a odkazů mnoha tabulek, pro které musí být vytvořeno velké množství indexů, což ve výsledku vyžaduje více místa pro uložení. Většina položených dotazů na SŘBD v tomto testu měla geometrický charakter (dotazy 1.x až 5.x), pouze jedna otázka se dotazovala na topologický vztah (dotazy 6.x). Položené dotazy na SŘBD: 1.1. Najdi všechny objekty uvnitř relativně prázdné obdélníkové oblasti Najdi všechny objekty uvnitř relativně naplněné obdélníkové oblasti Najdi všechny objekty uvnitř relativně prázdné polygonové oblasti Najdi všechny objekty uvnitř relativně naplněné polygonové oblasti. 3. Najdi a ořízni všechny objekty podle vyhledávacího polygonu s dvěma dírami Najdi všechny objekty, které se protínají s geometrií dotazu - linií, jdoucí relativně prázdnou oblastí Najdi všechny objekty, které se protínají s geometrií dotazu - linií, jdoucí relativně naplněnou oblastí. 31

32 5.1. Najdi všechny objekty, které obsahují danou množinu 3 dotazovacích bodů v relativně prázdné oblasti Najdi všechny objekty, které obsahují danou množinu 6 dotazovacích bodů v relativně naplněné oblasti Najdi všechny sousední objekty k danému simple objektu Najdi všechny sousední objekty k danému complex objektu. Při geometrickém dotazu (1.x až 5.x) na topologicky strukturovaná data může být geometrický popis prvku zkonstruován v reálném čase. Při shodném dotazu na plain geometry data nemusí být geometrický popis prvku rekonstruován, neboť je uložen kompletní na jednom místě. To je hlavní důvod, proč nebyl výkon Radius Topology při vyhodnocování geometrických dotazů dobrý v porovnání s plain geometry přístupem. Výjimku v úspěšnosti rychlosti zodpovězení tvořil dotaz (dotazy 6.x) na topologický vztah, při kterém byl podstatně úspěšnější Radius Topology. Z důvodu, že pro vyhodnocení dotazu stačilo projít pouze příslušné odkazy. Přehled o časech potřebných pro vyhodnocení jednotlivých dotazů podává tabulka 2.1. Tabulka 2.1: Časy (v sekundách) potřebné ke zodpovězení dotazů [LOUW] Plain Topology Relation Query type # rows geometry version of time Query returned version 1.1 Rectangle :2 1.2 Rectangle :3 2.1 Polygon :4 2.2 Polygon :4 3 Clip :2 4.1 Polyline :5 4.2 Polyline :5 5.1 Points :3 5.2 Points :2 6.1 Adjacency :1 6.2 Adjacency :1 Závěr práce je takový, že v době, kdy byla prováděna (práce publikována v červnu 2003), je výkon SŘBD využívající netopologicky strukturovaných dat v podobě plain geometry vyšší než výkon SŘBD s topologicky strukturovanými daty (s využitím Radius Topology). Volba, jaký přístup pro uložení prostorových dat zvolit, silně závisí na hlavních požadavcích na využití těchto dat. V případě 32

33 častého kladení geometrických dotazů bude výhodnější využít plain geometry, při vyšších požadavcích například na udržení konzistence dat bude lepší preferovat uložení dat v topologické struktuře. 2.9 Ukládání a dotazování topologicky strukturovaných dat v Oracle Spatial V [PEQU] byl testován modul pro správu topologicky strukturovaných dat v prostředí Oracle Spatial (verze 10g). Bylo provedeno srovnání nabízené funkcionality tohoto topologického modulu s jinými vybranými řešeními pro správu topologických dat. Rovněž byly zkoumány nároky na uložení dat a času potřebného pro vyhodnocení dotazů. Model použitý uvnitř systému řízení báze dat odpovídá konceptu okřídlené hrany, viz 7.7. Nad tímto modelem mohou být definovány vzhledy jevů (features). V provedených experimentech byla načtena topologicky modelovaná část katastrální mapy Nizozemska (přibližně 1 milion parcel) a provedena řada dotazů. Shodné dotazy byly otestovány nad stejnou množinou dat uloženou jako množina polygonů (s využitím geometrických primitiv). Při uvažování množiny dat čítající přibližně objektů a méně byly vždy dotazy zodpovězeny rychleji nad uložením dat pomocí geometrických primitiv. Pokud byla datová množina větší, topologické dotazy (vyžadující přístup pouze k uloženým odkazům na topologická primitiva) byly efektivněji zodpovězeny nad topologicky strukturovanými daty. Geometrické dotazy (vyžadující přístup ke geometrickému popisu prvku, který musí být nejdříve zkonstruován pomocí odkazů mezi topologickými primitivy) jsou vždy rychleji zodpovězeny nad netopologicky strukturovanými daty. Rovněž je vhodné zmínit, že data uložená v topologickém modelu vyžadují několikanásobně více prostoru pro své uložení. Shodně s pracemi [OOTI] a [PENN], ve kterých byla rovněž testována verze Oracle Spatial 10g, byl uveden závěr, který doporučuje použít topologický modul Oracle pro správu již validní topologie. Zároveň je uvedeno, že tento modul není vhodný z hlediska poskytované funkcinality pro čištění dat, především v porovnání s ESRI Geodatabase. 33

34 Kapitola 3 Současný datový model uložení prostorových dat v ISKN Současný způsob uložení vektorových prostorových dat v ISKN je velmi důležitý pro téměř každou oblast, kterou jsem v rámci disertační práce zpracovával. Z tohoto důvodu je popsání (přibližného) datového modelu věnována samostatná kapitola v začátku práce. 3.1 Prostorová data v Informačním systému katastru nemovitostí Informační systém katastru nemovitostí (ISKN) vytvořený nad databázovým systémem firmy Oracle obsahuje kromě dat souboru popisných informací (SPI) rovněž prostorová data, především v podobě digitální katastrální mapy (DKM). Digitální katastrální mapa, vedená jako spojitá a bezešvá mapa, se zpracovává pro jednotlivá katastrální území nebo jejich část v S-JTSK ve vztažném měřítku 1:1000. O struktuře uložení DKM ve zdrojové databázi ISKN lze získat nejvíce informací z dokumentu [CUZK], který úzce souvisí s novým výměnným formátem (NVF). Na základě informací z tohoto dokumentu je možné zrekonstruovat přibližný datový model uložení prostorových dat v ISKN. Jedním z nejdůležitějších kroků rekonstrukce datového modelu je výběr potřebných datových bloků. 1 Předmětem mého zájmu byly především datové bloky spadající do skupiny nazvané Prvky katastrální mapy (PKMP). Tato skupina obsahuje datové bloky pro uložení prvků katastrální mapy. Seznam vybraných bloků je uveden v tabulce Součást souboru NVF náležející do nějaké nadřazené skupiny a obsahující právě jeden uvozující řádek obsahující seznam atributů s jejich datovými typy a řádky obsahující vlastní data. 34

35 Tabulka 3.1: Datové bloky ve skupině PKMP Kód Název tabulky v popise Popis výměnného formátu [CUZK] SOBR BODY POLOHOPISU Souřadnice obrazů bodů polohopisu v mapě. SBP SPOJENI B POLOH Spojení bodů polohopisu - definuje polohopisné liniové prvky. SBM DPM SDOGEOM Spojení bodů mapy - definuje nepolohopisné liniové prvky. KODCHB KODY CHAR Q BODU Číselník kódů charakteristiky kvality bodu. TYPSOS T SOURAD SYS Číselník typů souřadnicových systémů. HP HRANICE PARCEL Hranice parcel. OP OBRAZY PARCEL Obrazy parcel (parcelní číslo, značka druhu pozemku,... ). OB OBRAZY BUDOV Obrazy budov (obvod budovy, značka druhu budovy). DPM DALSI PRVKY MAPY Další prvky mapy. OBBP OBRAZY BODU BP Obrazy bodů BP. TYPPPD T PRVKU P DAT Číselník typů prvků prostorových Při rekonstrukci modelu nebyly uvažovány všechny vybrané bloky ze skupiny PKMP a naopak byly zahrnuty bloky i z jiné skupiny. Jednalo se o vybrané bloky ze skupiny Nemovitosti (NEMO), uvedených v tabulce 3.2. dat. Tabulka 3.2: Vybrané bloky ze skupiny NEMO Kód Název tabulky v popise Popis výměnného formátu [CUZK] PAR PARCELY Parcely KATUZE KATASTR UZEMI Číselník katastrálních území OBCE OBCE Číselník obcí OKRESY OKRESY Číselník okresů KRAJE KRAJE Číselník krajů Při navrhování vazeb mezi tabulkami jsem využil dokumentu [CUZK]. Výsledný návrh logického modelu je znázorněn na obrázku 3.1 [JANE]. 35

36 Obrázek 3.1: Zrekonstruovaný datový model pro uložení prostorových dat v ISKN 36

37 3.2 Výběr hranice parcely z ISKN Klasickým dotazem na ISKN je vykreslení všech parcel spadajících do vybraného katastrálního území. Pokuch bychom požadovali prosté vykreslení, pak stačí z databáze vybrat příslušné části hranic a jednotlivé úseky vykreslit. Ve výsledku máme vykresleny všechny parcely ležící v katastrálním území. Vzhledem k povaze uložení potřebných dat pro vykreslení (viz kapitola 3.1) parcel, je tato úloha jednoduchá. Vybrání částí hraničních úseků parcel provedeme následujícím dotazem (u každé hrany mám uložen odkaz na stěnu (parcelu) vlevo a stěnu vpravo): Ukázka 3.1: Vybrání částí hraničních úseků parcel SELECT hp. id, so. s o u r a d n i c e x, so. s o u r a d n i c e y FROM h r a n i c e p a r c e l hp, s p o j e n i b p o l o h sb, s o u r a d n i c e o b r a z u so WHERE ( hp. p a r i d 1 IN (SELECT pa. i d FROM p a r c e l y pa WHERE katuze kod = ) OR hp. p a r i d 2 IN (SELECT pa. i d FROM p a r c e l y pa WHERE katuze kod = ) ) AND hp. i d = sb. hp id AND sb. bp id = so. i d ; Syntaxe a sémantika dotazu odpovídá přibližnému datovému modelu, zobrazenému na obrázku 3.1. Obtížnější situace nastane, pokud bychom chtěli s hranicí konkrétní parcely dále manipulovat, nejen ji vykreslit, ale například exportovat jako objekt nebo s ní jako s objektem pracovat. Množina hran vrácená uvedeným dotazem v sobě ovšem neobsahuje informace potřebné pro sestavení hranice parcely jako objektu. Pak by bylo nutné při současném způsobu uložení provést tyto kroky: vybrání všech částí hranic (hran), ze kterých budou rekonstruovány hranice parcel, sestavení geometrických popisů parcel. Z pohledu systému řízení báze dat bude náročnější druhý krok. Vzhledem k tomu, že v ISKN není uložen odkaz z konkrétní parcely na počáteční hranu hranice parcely a zároveň není k dispozici informace o sousedních hranách k dané hraně (next left, next right), musí být vždy v množině hran tvořících hranici parcely nalezeny dvě sousední (navazující) hrany a takto postupně vytvořit hranici parcely. Rovněž je nutné ohlídat případy, kdy je počáteční a koncový uzel hrany identický. Takové případy se v datech ISKN prozatím mohou vyskytnout a je nutné je v systému rovněž automaticky lokalizovat a odstranit. Nalezení takovýchto případů je popsáno v kapitole 5.9. Problémem sestavení hranice parcel jako objektu se zabývá kapitola

38 Kapitola 4 Využití výpočetní geometrie pro nalezení nekonzistencí v prostorových datech Řada prací z oblasti výpočetní geometrie, např. [KLZA], [SEUB], [LAMI] či [ABJO], se věnuje problematice čištění prostorových dat. Některé algoritmy lze zase za předpokladu topologicky čistých dat použít například pro účely generalizace nebo získávání nových prostorových prvků. Uvedu příklady dvou vybraných algoritmů, které lze použít pro účely katastru nemovitostí. Oba dva algoritmy jsem implementoval v programovacím jazyce Java a použil pro účely nalezení některých typů nekonzistencí v prostorových datech katastru nemovitostí. V práci [KAIN] jsou vyjmenovány charakteristiky topologicky konzistentní množiny dat: Každá hrana musí být ohraničena dvěma uzly (počáteční a koncový uzel). Každá hrana má stěnu vlevo a stěnu vpravo. Každá stěna má uzavřenou hranici sestávající ze střídavé posloupnosti uzlů a hran. Kolem každého uzlu je střídavá uzavřená sekvence hran a stěn. Hrany se vzájemně neprotínají, pouze v uzlech. Velmi často dochází při implementaci algoritmů z oblasti výpočetní geometrie k využití stromových struktur. Je to pochopitelné, stromové struktury nabízejí relativně rychlý přístup k potřebným datům. V práci jsem hojně využil stromovou strukturu AVL strom, a to nejen v programech pro vyhledávání nekonzistencí v prostorových datech katastru nemovitostí, ale také v programu DKM2Spatial.jar, popsaného v kapitole 7.6. Z tohoto důvodu bude v kapitole 4.3 struktura AVL strom ve stručnosti popsána. 38

39 4.1 Nalezení dvojice nejbližších bodů pomocí techniky sweep line Úloha nalezení dvojice nejbližších bodů je typickou úlohou z oblasti výpočetní geometrie. Algoritmus je aplikovatelný například na nalezení duplicitních bodů kresby digitální katastrální mapy. Pro nalezení dvojice nejbližších bodů v rovině (omezíme se na 2D případ) lze použít různé techniky. Jednou z těchto technik je i sweep line technika. Princip techniky spočívá v tom, že se svislice pohybuje zleva doprava skrze rovinu a pokaždé, když protne nějaký bod ze vstupní množiny bodůs, dochází k prošetřování situace v daném bodě. Je zřejmé, že body musí být před započetím pohybu svislice seřazeny podle souřadnice X. V průběhu algoritmu udržujeme informace o: Dvojici nejbližších bodů z dosud prošlých bodů vstupní množiny S. Vzdálenosti d mezi dvěma nejbližšími body. Všech bodech nacházejících se uvnitř pásu do vzdálenosti d nalevo od svislice (sweep line). Tyto body tvoří množinu D, viz. obrázek 4.1. Obrázek 4.1: sweep-line technika pro nalezení dvojice nejbližších bodů Pokaždé, když svislice při svém průchodu rovinou dorazí do bodu p, provedou se následující kroky: Odstraní se všechny body z D, které jsou ve vzdálenosti větší než d od p. 39

40 Ze zbylých bodů v D se nalezne nejbližší bod k bodu p. Pokud je vzdálenost mezí tímto bodem a bodem p menší než d (aktuální hodnota nejmenší vzdálenosti dvou bodů), pak se aktualizuje dvojice nejbližších bodů a hodnota d. Po průchodu svislice posledním bodem z D dostaneme na výstupu dvojici nejbližších bodů, včetně hodnoty d. Pokud se zamyslíme nad bodem dva, tak zjistíme, že nepotřebujeme prohledávat všechny body nalevo od p. Body, které jsou ve vzdálenosti větší než d od p, nemusí být kontrolovány, protože nemohou být potenciálně součástí dvojice nejbližších bodů. To znamená, že při hledání rovněž nemusíme uvažovat body z D, které leží ve vzdálenosti větší než d od p ve směru osy Y. Prohledávací oblast tak bude mít rozměry d * 2d, jak je ukázáno na obrázku 4.2. Obrázek 4.2: Omezení vyhledávací oblasti pro nalezení dvojice nejbližších bodů Celý algoritmus pracuje se složitostí O (n log n) ([CLPA]). 4.2 Nalezení všech průsečíků v množině úseček Algoritmus na nalezení všech průsečíků v množině úseček je dobře aplikovatelný na digitální katastrální mapu. Využil jsem tohoto algoritmu pro nalezení všech nespočtených průsečíků v množině úseček, které představovaly vnitřní kresbu či hraniční úseky parcel. Více o aplikaci tohoto algoritmu na prostorová data katastru nemovitostí lze nalézt v kapitole

41 Popis algoritmu Princip algoritmu vychází ze sweep line techniky, představené v kapitole 4.1 Nejprve je nutné vrcholy setřídit podle x do tzv.časového plánu δ. Svislici (sweep line) zastavíme v každém x vrcholu. V případě, že pracujeme s úsečkami v obecné poloze, je potřeba svislici zastavit i v nalezeném průsečíku. Z tohoto důvodu je nalezený průsečík v průběhu algoritmu zařazen do časového plánu δ. Dále potřebujeme další datovou strukturu - pomocnou frontu, označíme ji A. Množinu všech dosažených úseček (již do nich dorazila sweep-line) a aktuálních úseček (sweep-line není dál ve směru x než je x souřadnice koncového bodu úsečky) budeme uchovávat ve struktuře označené v popisu algoritmu jako T. Algoritmus pracuje v následujících krocích: Vrcholy setřídit podle x (sekundárně podle y) do časového plánu δ A 0; WHILE δ <> 0 DO { do vyčerpání časového plánu δ} vyber z δ jeden vrchol p IF máme počáteční bod úsečky THEN vlož s do T najdi v T s1 bezprostředně nad s najdi v T s2 bezprostředně pod s IF s1 s THEN A (s1, s); IF s2 s THEN A (s, s2) ELSE IF máme koncový bod úsečky THEN najdi v T s1 bezprostředně nad s najdi v T s2 bezprostředně pod s IF s1 s2 THEN A (s1, s2) zruš s v T ELSE 41

42 S3 úsečka bezprostředně nad s1, s4 pod s2 IF s3 s2 THEN A (s3, s2); IF s1 s4 THEN A (s1, s4) vyměň s1, s2 v T ENDIF { zpracování detekovaných průsečíků } WHILE A <> 0 DO A{ průsečíky mají souřadnici x} IF x není prvkem δ THEN vlož x do δ ENDIF ENDDO ENDDO Celý algoritmus pracuje se složitostí O ((n+k) log n) ([BEOT]). Struktury δ a T jsem implementoval jako vyvážené vyhledávací stromy. Popis použitého vyváženého vyhledávacího stromu, AVL stromu, lze nalézt v kapitole 4.3. Popis AVL stromu vychází z [ADVL], obrázky převzaty z [WIKI]. 42

43 4.3 AVL strom AVL strom je datová struktura pro uchovávání údajů a jejich vyhledávání. Pracuje v logaritmicky omezeném čase. Jedná se o samovyvažující se binární vyhledávací strom. Obrázek 4.3: Ukázka ne-avl stromu Obrázek 4.4: Stejný strom poté, co byl vyvážen Vlastnosti vrcholů AVL stromu Vrchol má maximálně dva následníky (je to binární strom). V levém podstromu vrcholu jsou pouze vrcholy s menší hodnotou klíče (je to binární vyhledávací strom). V pravém podstromu vrcholu jsou pouze vrcholy s větší hodnotou klíče (je to vyhledávací strom). Délka nejdelší větve levého a pravého podstromu se liší nejvýše o 1 (vyvážení AVL stromu) Vlastnosti AVL stromu Hlavní vlastností AVL stromu je, že definice nedovoluje, aby strom zdegeneroval, tj. zajišťuje vyváženost stromu. 43

44 4.3.3 Operace Na AVL stromech je možno v čase O(log(N)) provádět následující operace: vyhledání uzlu vložení uzlu zrušení uzlu Vyhledání uzlu v AVL stromu Vyhledávání uzlu v AVL stromu se realizuje stejně jako u binárního vyhledávacího stromu. Tato operace neklade žádné speciální požadavky a nemění strukturu stromu. Vkládání do AVL stromu Přidáváme-li nebo rušíme-li vrchol ve vyváženém stromu, může se ovšem stát nevyváženým. Koeficient vyváženosti i-tého uzlu B i = v Li v Ri, kde v Li je výška levého podstromu i-tého uzlu a v Ri je výška pravého podstromu i-tého uzlu. Strom s kořenem i je vyvážený, jestliže B i 1. Předpokládejme, že přidáme uzel do levého podstromu. Pokud si označíme K kořen, L levý, P pravý podstrom a v L, v P jejich výšky, pak před přidáním bude platit jedna z následujících možností: v L = v P Po přidání bude tedy výška levého podstromu přinejhorším o jedničku větší, než je výška pravého podstromu, a proto bude vyváženost stromu zachována. v L < v P Po přidání budou výšky podstromů sobě rovny a kritérium vyváženosti se tedy ještě zlepší. v L > v P Po přidání bude výška levého podstromu o dvě větší než je výška pravého podstromu a bude kritérium vyváženosti stromu porušeno. Před vložením hodnoty nejprve zjistíme, zda se daný uzel ve stromu již nenachází. Pokud takový uzel neexistuje, pak přidáme nový stejně jako u binárního vyhledávacího stromu a určíme pro něj koeficient vyváženosti. Potom následuje zkontrolování koeficientu vyváženosti pro každý uzel na cestě směrem ke kořeni stromu. Není-li splněno kritérium vyváženosti, musíme provést vyvažování stromu pomocí cyklické záměny ukazatelů (rotace stromu). 44

45 Při operaci vkládání a rušení je zapotřebí uchovávat o každém uzlu jeho koeficient vyváženosti. Proto je vhodné tento koeficient ukládat do každého vrcholu. Vyvažování AVL stromu Operace potřebné pro vyvažování jsou realizovány cyklickými záměnami ukazatelů. Můžeme provádět jednoduché RR-rotace, LL-rotace nebo dvojité LRrotace, RL-rotace. Při rotaci je nutné aktualizovat koeficient vyváženosti každého rotovaného uzlu. Na první ukázce je po přidání uzlu 1 porušena vyváženost stromu, protože u uzlu 5 a u uzlu 4 nabývá koeficient vyváženosti hodnoty 2. Jednoduchou LLrotací získáme opět vyvážený strom. V druhé ukázce je po vložení vrcholu 7 porušena vyváženost, která je odstraněná RR-rotací. Obrázek 4.5: Ukázka LL-rotace stromu Obrázek 4.6: Ukázka RR-rotace stromu Rušení uzlů z AVL stromu Rušení uzlů se vykonává stejně jako u binárního vyhledávacího uzlu s tím, že pokud dojde k porušení vyváženosti, provede se znovuvyvážení pomocí příslušných jednoduchých či dvojitých rotací. 45

46 Obrázek 4.7: Ukázka RL-rotace stromu Obrázek 4.8: Ukázka LR-rotace stromu 46

47 Kapitola 5 Automatická lokalizace chyb v prostorových datech ISKN V České republice je primárním zdrojem prostorových dat informační systém katastru nemovitostí, spravovaný Českým úřadem zeměměřickým a katastrálním. V tomto systému jsou uložena nejen data atributová, ale také data prostorová, především v podobě digitální katastrální mapy. Pro uložení prostorových dat katastru nemovitostí je využito nadstavby databázového systému Oracle - Oracle Spatial. Důležitým problémem v oblasti využití vektorových prostorových dat je zajištění konzistence prostorových vztahů, které se mezi geometrickými reprezentacemi jednotlivých prostorových prvků vyskytují. Obecné požadavky na topologicky čistá data jsou všeobecně známy. Tato kapitola je zaměřena na zajištění konzistence vektorových prostorových dat katastru nemovitostí, konkrétně digitální katastrální mapy. Míra využití a funkcionalita nadstavby Spatial není taková, aby mohly být složitější postupy vedoucí k nalezení nekonzistencí v prostorových datech opřeny právě o funkčnost samotné nadstavby Spatial. Cílem je prostorová data zkontrolovat, následně opravit a mít je ve stavu, kdy budou chyby negativně ovlivňující například automatickou generalizaci, eliminovány. Data po zobrazení v klientu (Kokeš, Microstation,... ) mohou být ve zvolené úrovni podrobnosti vizualizována uspokojivě, ovšem při dostatečně velkém přiblížení se na část dat lze pozorovat nedostatky v prostorových vztazích mezi prvky, například hranicemi parcel. Tento způsob identifikace chyb je pro celou oblast, na které se digitální katastrální mapa vyskytuje (více o pokrytí území ČR DKM v kapitole 6.11), samozřejmě nereálný a především kategoricky špatný. Navržené řešení spočívá v návrhu vlastních postupů a algoritmů a v aplikování vhodných algoritmů z oblasti výpočetní geometrie použitých nad prostorovými daty ISKN, které dokáží příslušný typ nekonzistence najít nad určeným rozsahem prostorových dat. 47

48 5.1 Duplicitní mapové značky Při grafickém určení značky druhu pozemku může dojít k tomu, že bude značka zanesena dvakrát (případně vícekrát) ve smyslu, že vztažné body značek budou ve vzdálenosti menší než určená prahová hodnota. Řešení tohoto problému opět vyžaduje automatizovaný přístup. Byl implementován algoritmus využívající techniky sweep line (viz 4.1) známé z oblasti výpočetní geometrie, který prohledá vstupní množinu dat (vztažné body mapových značek vyjadřujících druh pozemku), nalezne dva nejbližší body a na základě prahové hodnoty rozhodne o tom, zda jsou dva body identické. Pokud jsou dva nejbližší body od sebe ve vzdálenosti větší než prahová hodnota, algoritmus dále nepokračuje. V opačném případě najde další dvojici nejbližších bodů a provede nové porovnání vůči prahové hodnotě. Pro nalezení duplicitních mapových značek byl vytvořen program DuplicitniZnacky.jar v programovacím jazyce Java. Program hledá duplicitní mapové značky v rozsahu katastrálního pracoviště. Prahová hodnota, dokdy jsou dva body reprezentující vztažné body umístění mapových značek považovány za duplicitní, byla zvolena 1 m. Spuštění programu (program se spouští z příkazové řádky): java jar DuplicitniZnacky.jar login password kod pracoviste dupl body kde: login přihlašovací jméno do databáze password heslo kod pracoviste kód katastrálního pracoviště, ve kterém budou duplicitní mapové značky hledány dupl body číselná konstanta (pro duplicitní mapové značky rovna 1) Ukázka spuštění pro fiktivního uživatele Josefa Nováka s přihlašovacím jménem novakj a s heslem Abc123 pro katastrální pracoviště s kódem 201: java jar DuplicitniZnacky.jar novakj Abc Program generuje textový soubor se jmennou konvencí kod pracoviste duplmap-znacky.txt, který obsahuje výpis nalezených duplicitních bodů představujících vztažné body duplicitních mapových značek. Ukázka z vygenerovaného souboru 201 dupl-map-znacky.txt je zachycena v ukázce

49 Ukázka 5.1: Ukázka z vygenerovaného souboru 201 dupl-map-znacky.txt Dvojice n e j b l i z s i c h znacek ( m) : K a t a s t r a l n i uzemi : C i s l o p a r c e l y : 1168 Souradnice znacky [ X,Y ] : K a t a s t r a l n i uzemi : C i s l o p a r c e l y : 1168 Souradnice znacky [ X,Y ] : Dvojice n e j b l i z s i c h znacek ( m) : K a t a s t r a l n i uzemi : C i s l o p a r c e l y : 1958/1 Souradnice znacky [ X,Y ] : K a t a s t r a l n i uzemi : C i s l o p a r c e l y : 1958/1 Souradnice znacky [ X,Y ] : Na obrázku 5.1 a 5.2 je zobrazena ukázka nalezené duplicitní mapové značky. Obrázek 5.1: Nalezená duplicitní mapová značka 5.2 Duplicitní definiční body budov Program DuplicitniZnacky.jar umožňuje rovněž vyhledávat duplicitní definiční body budov. Rozdíl oproti nalezení duplicitních mapových značek je ve volbě parametru dupl body. Pokud chceme, aby program našel duplicitní definiční body budov, je hodnota parametru dupl body rovna 2. 49

50 Obrázek 5.2: Nalezená duplicitní mapová značka [JANO] Ukázka spuštění pro fiktivního uživatele Josefa Nováka s přihlašovacím jménem novakj a s heslem Abc123 pro katastrální pracoviště s kódem 101: java jar DuplicitniZnacky.jar novakj Abc Program generuje textový soubor se jmennou konvencí kod pracoviste dupldef-body-budov.txt, který obsahuje výpis nalezených duplicitních bodů představujících vztažné body duplicitních definičních bodů budov. Ukázka z vygenerovaného souboru 101 dupl-def-body-budov.txt: Ukázka 5.2: Ukázka z vygenerovaného souboru 101 dupl-def-body-budov.txt Dvojice n e j b l i z s i c h znacek ( m) : K a t a s t r a l n i uzemi : C i s l o p a r c e l y : 1 Souradnice znacky [ X,Y ] : K a t a s t r a l n i uzemi : C i s l o p a r c e l y : 1 Souradnice znacky [ X,Y ] : Dvojice n e j b l i z s i c h znacek ( m) : K a t a s t r a l n i uzemi : C i s l o p a r c e l y : 1 Souradnice znacky [ X,Y ] : K a t a s t r a l n i uzemi : C i s l o p a r c e l y : 1 Souradnice znacky [ X,Y ] :

51 5.3 Duplicitní vztažné body pro umístění textových prvků Program DuplicitniZnacky.jar umožňuje rovněž vyhledávat duplicitní definiční vztažné body parcelních čísel. Pokud chceme, aby program našel duplicitní definiční vztažné body parcelních čísel, je hodnota parametru dupl body rovna 3. Ukázka spuštění pro fiktivního uživatele Josefa Nováka s přihlašovacím jménem novakj a s heslem Abc123 pro katastrální pracoviště s kódem 201: java jar DuplicitniZnacky.jar novakj Abc Program generuje textový soubor se jmennou konvencí kod pracoviste duplparcelni-cisla.txt, který obsahuje výpis nalezených duplicitních bodů představujících vztažné body parcelních čísel. Případně je v souboru uvedena informace, že v příslušném katastrálním pracovišti nebyly nalezeny duplicitní vztažné body textových prvků parcelních čísel. Ukázka z vygenerovaného souboru 201 dupl-parcelni-cisla.txt, pokud katastrální pracoviště neobsahuje žádná duplicitní parcelní čísla: Ukázka 5.3: Ukázka z vygenerovaného souboru 201 dupl-parcelni-cisla.txt Pro k a t a s t r a l n i p r a c o v i s t e 201 zadna d u p l i c i t n i p a r c e l n i c i s l a nenalezena. 5.4 Nespočtené průsečíky Digitální katastrální mapa obsahuje i tzv. vnitřní kresbu, kterou se znázorňují například hranice budov. Je žádoucí, aby pro všechna křížení linií vnitřní kresby existovaly spočtené průsečíky a údaje o nich byly uloženy v databázi. Prozatím tomu tak ovšem být nemusí, proto je vhodné, mít k dispozici nějaký program, který by tyto nespočtené průsečíky v prostorových datech ISKN našel. Stejně tak by tento program měl umět najít nespočtené průsečíky na hranicích parcel (hranicích katastrálních území, hranicích obcí, hranicích okresů nebo hranicích kraje). Pro řešení problému se opět nabízí možnost sáhnout po vhodném algoritmu z oblasti výpočetní geometrie a zakomponovat jej do výsledného programu. Algoritmus, jehož popis lze najít v kapitole 4.2 a který je založen na již zmíněné sweep-line technice, přesně splňuje kritéria na takový algoritmus kladená aby byly nalezeny ve vstupní množině dat (liniové úseky vnitřní kresby) všechny průsečíky efektivním způsobem, tzn. ne hrubou silou, čili testováním každého úseku s každým. Algoritmus byl implementován v programovacím jazyce Java s využitím vhodných datových struktur, především AVL stromu (viz 4.3). Program 51

52 na vyhledání nespočtených průsečíků má název NespoctenePruseciky.jar a umožňuje vyhledat nespočtené průsečíky pro data v rozsahu daném jedním ze vstupních parametrů. Stejně tak je možné volbou příslušného parametru zadat typ kontrolovaných dat. Spuštění programu (program se spouští z příkazové řádky) - varianta A: java jar NespoctenePruseciky.jar login password rozsah typ dat kod prac Spuštění programu (program se spouští z příkazové řádky) - varianta B: java jar NespoctenePruseciky.jar login password rozsah kod ku1 kod ku2 kde: login přihlašovací jméno do databáze password heslo rozsah rozsah kontrolovaných dat varianta A: typ dat -1 = vybírají se data v rozsahu katastrálního pracoviště -2 = vybírají se data pro dvě katastrální území -1 = vybírají se data odpovídající hraničním úsekům (hranice katastrálního území, hranice obce) -2 = vybírají se data odpovídající vnitřní kresbě v daném katastrálním pracovišti kod prac kód katastrálního pracoviště, ve kterém budou duplicitní mapové značky hledány varianta B: kod ku1 kód katastrálního pracoviště kod ku2 kód katastrálního pracoviště Nalezené nespočtené průsečíky se zapíší do automaticky generovaného souboru nespoctene-pruseciky.txt. Soubor se vytvoří v adresáři, ze kterého je spouštěn program NespoctenePruseciky.jar. 52

53 Možné příklady spuštění programu pro fiktivního uživatele Josefa Nováka s přihlašovacím jménem novakj a s heslem Abc123. Možný příklad spuštění programu - varianta A: java -jar NespoctenePruseciky.jar oko josefn Abc kde -1 = data v rozsahu katastrálního pracoviště -1 = data odpovídající hranicím kat. území v daném pracovišti 201 = konkrétní kód kat. pracoviště Možný příklad spuštění programu - varianta A: java -jar NespoctenePruseciky.jar oko josefn Abc kde -1 = data v rozsahu katastrálního pracoviště -2 = data odpovídající vnitřní kresbě v daném pracovišti 201 = konkrétní kód kat. pracoviště Na obrázku 5.3 je ukázka nespočteného průsečíku nalezeného ve vnitřní kresbě. Možný příklad spuštění programu - varianta B: java -jar NespoctenePruseciky.jar oko josefn Abc kde -2 = data v rozsahu dvou sousedních katastrálních území (každé je ale z jiného katastrálního pracoviště) = data odpovídající hranici kat. území (obce, okresu, kraje) s kódem = data odpovídající hranici kat. území (obce, okresu, kraje) s kódem Pokud vybíráme data pro katastrální území, musíme uvažovat skutečnost, že pokud je hraniční úsek součástí nakříklad hranice katastrálního území a zároveň hranice obce, bude tento úsek vybrán jako úsek hranice obce. Důvod je takový, že tento úsek je v ISKN uložen pouze jedenkrát a podle hodnoty atributu TYPPPD KOD je určeno, o jaký typ hraničního úseku se jedná. 53

54 Obrázek 5.3: Nalezený nespočtený průsečík ve vnitřní kresbě 5.5 Šťopky Ze způsobu uložení hranic parcel v ISKN vyplývá, že je pro každou hranu (segment hranice parcely) uložen v odpovídajícím záznamu identifikátor parcely vlevo a identifikátor parcely vpravo. Pokud neexistuje digitální katastrální mapa po obou stranách daného hraničního úseku, je příslušný identifikátor roven hodnotě NULL. V případě, kdy hrana reprezentuje segment vlastnické hranice oddělující dvě různé parcely (za předpokladu existence DKM po obou stranách hrany), je vyžadováno, aby pro tuto hranu byly uloženy odkazy na parcely po obou stranách. Můžete se stát, že oba dva uložené identifikátory jsou shodné, resp. odkazují na i- dentickou parcelu. Pak hovoříme o tzv. šťopkách. Bohužel, není mi znám žádný odborný ekvivalent. Z tohoto důvodu byl pro označení tohoto typu chyby zvolen pracovní název šťopka, převzatý od pracovníků rezortu ČÚZK. Příklad šťopky ilustruje obrázek 5.4. Pro automatizovanou lokalizaci této chyby byl vytvořen dotaz v jazyce SQL (zdrojový kód je součástí přílohy, viz B.1), který ve všech lokalitách pokrytých DKM vyhledá tento typ chyby. Skript lze spustit v libovolném SQL klientovi, ze kterého se lze připojit ke zdrojové databázi. Nalezená šťopka je mezi body 75 a 163, jak je patrné z obrázku 5.4. Všimněme si, že identifikátor parcely vlevo a vpravo od tohoto úseku hranice parcely je shodný. V obou případech je odkazována parcela s hodnotou identifikátoru Nalezený hraniční úsek parcely tak byl nalezen správně. Štopky jsou generovány pro celou ČR najednou, do výstupního souboru s ná- 54

55 Obrázek 5.4: Ukázka nalezené šťopky zvem stopky CR.txt, viz přiložený zdrojový kód v příloze B.1 Jednoduchou změnou zdrojového kódu lze generovat šťopky například pouze pro vybraný kraj. Tento postup byl uplatněn v případě Zlínského kraje. Nejprve se ze souboru s daty pro celou ČR vyseparovala data pro jednotlivé kraje a v rámci krajů došlo, či dochází k odstranění šťopek (obecně čištění dat). Ve Zlínském kraji šťopky odstranili a v rámci kontroly se zdrojový skript spustil pouze pro Zlínský kraj. Z původního množství šťopek v tomto kraji (řádově desítky), byl po kontrole nalezen počet šťopek v řádech jednotek. Tyto šťopky se vygenerovaly do souboru stopky-zlinskykraj k txt (opět jednoduchá změna zdrojového kódu skriptu). Vygenerovaný soubor byl odeslán k finálnímu odstranění šťopek ve Zlínském kraji. 5.6 Prázdné polygony Příkladem chyby, která se v digitální katastrální mapě vyskytuje, může být prázdný polygon. Prázdným polygonem se rozumí uzavřená posloupnost vrcholů na sebe navazujících hraničních úseků parcel, která ovšem nepředstavuje hranici parcely. Prázdný polygon typicky vzniká ve chvíli, kdy dochází ke vzniku nové parcely a při vložení nového bodu hranice parcely nedojde k jeho přesnému umístění na část hraničního úseku, který se v datech již vyskytuje. Geometricky může situace vypadat například jako na obrázku 5.5. Všimněme si spojnic bodů 130 5, a Že je zde spojnice navíc? Pokud se vizualizací přiblížíme k bodu 5, 55

56 Obrázek 5.5: Prázdný polygon - přehled je vidět, že dochází ke vzniku prázdného polygonu mezi body 130, 5 a 129 (viz. obr. 5.6) a tudíž se v datech objevuje i spojnice Identifikovat všechny výskyty takovéto chyby v datech ISKN vyžaduje automatizovaný přístup. Navrhl jsem algoritmus ([JANJ]), který dokáže v množině vstupních dat vyhledat prázdné polygony a na výstupu poskytnout informace o bodech polohopisu, které tvoří lomové body hledaného prázdného polygonu. Algoritmus byl naprogramován v jazyce Java Algoritmus Najdi prázdné polygony Vstupní data Aby bylo možné co nejblíže prostorově určit lomové body geometrického popisu prázdného polygonu, bylo nutné z ISKN vybrat potřebné údaje kód katastrálního území, souřadnice bodu a položky, ze kterých bylo na výstupu sestaveno úplné číslo bodu. Data byla vybírána tak, aby algoritmus zpracovával nejmenší možný počet hraničních úseků parcel, tzn. úseky, u kterých podle naplnění atributů v tabulkách ISKN bylo možné rozhodnout již na straně databáze, že nemohou být součástí geometrického popisu prázdného polygonu, nebyly vybrány. Jedná se o úseky, u kterých jsou po obou stranách (podél hraničního úseku) uloženy parcely s rozdílnými identifikátory. Vstupní data byla načtena do datové struktury, která byla navržena tak, aby se co nejvíce zjednodušilo vlastní hledání prázdného polygonu. Body (počáteční, 56

57 Obrázek 5.6: Prázdný polygon - detail koncové) byly načítány po dvojicích, jedna dvojice bodů představuje jeden hraniční úsek. Pokud se některý hraniční úsek sestával z více bodů (lomená čára), byl tento úsek do datové struktury uložen po dílčích úsecích odpovídajících spojnicím dvojic sousedních bodů. Po načtení všech dat ze vstupního souboru si každý hraniční úsek v obou svých koncových bodech pamatuje odkaz na hraniční úsek (samozřejmě pokud takový hraniční úsek existuje), s nímž svírá nejmenší levotočivý úhel (úhel v protisměru chodu hodinových ručiček). Algoritmus hledání všech kružnic ve vstupních datech pracuje v následujících krocích: 1. Inicializace algoritmu Najdi prázdné polygony Hrana hr = prázdná hrana; Hrana hr next = prázdná hrana; Pole hr circ = prázdné pole hran; Pole hr graf = pole hran grafu; Int index = 0; 2. Do hrany hr načti hranu z hr graf, ze které je možné vyjít, tzn. hranu, která není součástí žádné již nalezené kružnice a zároveň u ní nenastal jev, že byla načtena jako počáteční a kružnice z ní nebyla nalezena. Pokud taková hrana již 57

58 ve vstupních datech není, algoritmus končí. 3. Má hr přilehlou hranu? ANO pokračuj na 4. NE hr nastav příznak toho, že byla načtena jako počáteční a nebyla z ní nalezena kružnice; vrať se na hr circ[index] = hr; index ++; Existuje k hraně hr přilehlá hrana hr next v obou jejích bodech? ANO pak proměnné hr přiřaď hranu hr next z prvního načteného bodu hrany hr. NE přiřaď hr hranu hr next z bodu, ve kterém přilehlá hrana existuje. 5. hr circ[index] = hr; index ++; Uvažuj koncový bod hrany hr, ve kterém nedošlo k napojení hran. Existuje v tomto bodě hrana hr next? ANO přiřaď do proměnné hr hranu hr next. NE hr next je rovna NULL, nastav hraně na pozici hr circ[0] příznak toho, že byla načtena jako počáteční a nebyla z ní kružnice nalezena. Opakuj bod 5., dokud hr není rovno hr circ[0] (v tom případě jsme nalezli kružnici), nebo hr next není rovno NULL (kružnice nebyla z výchozí hrany nalezena). Vynuluj hr circ; index = 0; hr = NULL; hr next = NULL; 6. Jdi na 2. Algoritmus byl prezentován na 9. mezinárodní doktorandské konferenci JUNI- ORSTAV 2007 v Brně. V sekci Praktické aspekty geodézie obsadil příspěvek [JANJ] 2. místo. 58

59 5.7 Program Prazdne polygony Algoritmus popsaný v kapitole tvoří jádro programu Prazdne polygony.jar, vytvořeného v programovacím jazyce Java. Program se spouští z příkazové řádky následujícím příkazem: java jar Prazdne polygony.jar login password kod pracoviste kde login přihlašovací jméno do databáze password heslo kod pracoviste kód katastrálního pracoviště Příklad spuštění programu pro katastrální pracoviště s kódem 201 pod uživatelem oko josefn s heslem Abc123: java -jar Prazdne polygony.jar oko josefn Abc Program vygeneruje textový soubor kod pracoviste prazdne polygony.txt s výpisem všech prázdných polygonů v příslušném katastrálním pracovišti. Prázdný polygon zachycený na obrázcích 3 a 4 byl nalezen navrženým algoritmem. Na obrázku 5.7 je ukázka výpisu ze souboru kod pracoviste prazdne polygony.txt. Obrázek 5.7: Ukázka výpisu prázdného polygonu 59

60 5.8 Neplatná hodnota atributu TYPPPD KOD V ISKN, v číselníku s popisem typů prvků prostorových dat, je mimo jiné uveden atribut PLATNOST DO. Cílem je najít všechny záznamy v tabulkách, u kterých se u jednotlivých záznamů eviduje atribut TYPPPD KOD (typ prvku prostorových dat), které jsou typu, jehož platnost již není aktuální. Součástí přílohy (viz B.2) je PL/SQL procedura KAJA ZRUSENA PLATNOST TYPPPD, která má jeden vstupní parametr kodkp. Tento parametr představuje kód katastrálního pracoviště, pro které proběhne vyhledání všech záznamů s neplatnou hodnotou atributu TYPPPD KOD. Ukázka 5.4 zobrazuje výstup pro katastrální pracoviště s kódem 405. Ukázka 5.4: Ukázka výstupu procedury KAJA ZRUSENA PLATNOST TYPPPD P r a c o v i s t e : 405 K a t a s t r á l n í úřad pro Plzeňský kraj, K a t a s t r á l n í p r a c o v i š t ě Plzeň město K a t a s t r a l n i uzemi : Černice Tabulka AK DALSI PRVKY MAPY obsahuje prvek ( První břemeno ) s p r o s l o u p l a t n o s t i Pocet vyskytu : 77 K a t a s t r a l n i uzemi : Tymákov Tabulka AK DALSI PRVKY MAPY obsahuje prvek 1019 ( Popisné p a r c e l n í č í s l o ( volné ) ) s p r o s l o u p l a t n o s t i Pocet vyskytu : 19 Tabulka AK DALSI PRVKY MAPY obsahuje prvek 1028 ( Čára pro u m í s t ě n í š i p k y ( volná ) ) s p r o s l o u p l a t n o s t i Pocet vyskytu : 19 Tabulka AK DALSI PRVKY MAPY obsahuje prvek 1029 ( Šipka k parcelnímu č í s l u ( volná ) ) s p r o s l o u p l a t n o s t i Pocet vyskytu : Hraniční úseky parcel se shodným počátečním a koncovým bodem Hraniční úseky parcel jsou v ISKN určeny pomocí dvou koncových bodů a případných mezilehlých bodů. V datech se vyskytuje případ, kdy hraniční úsek sestává ze dvou bodů (počáteční a koncový) o shodných Y, X souřadnicích, tzn. koncové body jsou identické. Byla vytvořena procedura v jazyce PL/SQL, která všechny takovéto úseky v datech identifikuje. Název procedury je KAJA NAJDI DUPL VRCH KP. Má jeden vstupní parametr - kód katastrálního 60

61 pracoviště. Vyhledává tedy úseky parcel se shodným počátečním a koncovým bodem v rámci zvoleného katastrálního pracoviště. Způsob spuštění procedury KAJA NAJDI DUPL VRCH KP je ukázán v u- kázce 5.5. Ukázka 5.5: Ukázka spuštění procedury KAJA NAJDI DUPL VRCH KP BEGIN EXEC KAJA NAJDI DUPL VRCH KP( ) ; END; V rámci vykonávání procedury KAJA NAJDI DUPL VRCH KP jsou načteny kódy všech katastrálních území, která do daného katastrálního pracoviště spadají. Pro jednotlivé kódy katatrálních území se volá PL/SQL procedura KAJA NAJDI DUPL VRCH KU, do které je tento kód předán jako vstupní parametr a v rámci které proběhne vlastní vyhledání úseků se shodným počátečním a koncovým bodem. Seznam nalezených úseků je uložen do souboru kod pracoviste-duplicitni-vrcholy. Ukázka 5.6: Ukázka obsahu souboru 301-duplicitni-vrcholy (soubor obsahující úseky se shodným počátečním a koncovým bodem pro katastrální pracoviště s kódem 301) K a t a s t r a l n i p r a c o v i s t e K a t a s t r á l n í úřad pro J i h o č e s k ý kraj, K a t a s t r á l n í p r a c o v i š t ě České Budějovice K a t a s t r a l n i uzemi Adamov u Českých Budějovic V k a t a s t r a l n i m uzemi Adamov u Českých Budějovic celkem n a l e z e n o 0 d u p l i c i t n i c h bodu. K a t a s t r a l n i uzemi Borovany D u p l i c i t n i bod : D u p l i c i t n i bod : D u p l i c i t n i bod : D u p l i c i t n i bod : Nevalidní geometrické popisy Tento typ chyby úzce souvisí s problematikou přípravy dat pro WMS (viz 6). Například v případě generování digitální katastrální mapy do souborů shapefile dochází pro každou dlaždici k testování průniku mezi geometrickou reprezentací této dlaždice a geometrií uloženou v příslušném sloupci v konkrétní tabulce. Konkrétně může jít například o tabulku, ve které je uložena vnitřní kresba. Pro každý záznam v takové tabulce je společně s ostatními atributy uložena i aproximace geometrického prvku. Touto aproximací je minimální ohraničující obdélník, viz obrázek 7.2. Při výběru, které záznamy budou vybrány pro danou dlaždici, se uvažuje výsledek operátoru SDO RELATE (podrobnosti v [ORSG]). 61

62 Vzhledem k tomu, že tento operátor vyžaduje, aby vstupní geometrické popisy byly z pohledu Spatial validní a ne ve všech případech tomu tak je, bylo nutné tyto nevalidní geometrické popisy prostorových prvků nalézt. K tomu lze využít funkci VALIDATE GEOMETRY WITH CONTEXT, z balíku SDO GEOM, který je v Oracle Spatial dostupný Procedura KAJA NEVALIDNI GM KP Procedura KAJA NEVALIDNI GM KP 1, napsaná v jazyce PL/SQL, slouží k nalezení všech záznamů v tabulce se záznamy o vnitřní kresbě (obecně dalších prvcích mapy), které mají nevalidní geometrický popis minimálního ohraničujícího obdélníku. Data jsou prohledávána v rozsahu katastrálního pracoviště. Kód katastrálního pracoviště je jediným vstupním parametrem procedury. Procedura se spouští z libovolného SQL klienta, který komunikuje se zdrojovou databází. Ukázka 5.7: Ukázka spuštění procedury KAJA NEVALIDNI GM KP pro katastrální pracoviště s kódem 301 BEGIN KAJA NEVALIDNI GM KP( ) ; END; Ukázka výstupu pro katastrální pracoviště České Budějovice: Ukázka 5.8: Ukázka výstupu pro katastrální pracoviště České Budějovice K a t a s t r a l n i p r a c o v i s t e K a t a s t r á l n í úřad pro J i h o č e s k ý kraj, K a t a s t r á l n í p r a c o v i š t ě České Budějovice K a t a s t r a l n i uzemi B o š i l e c Typ chyby : N e v a l i d n i g e o m e t r i e s d o e l e m i n f o a r r a y : s d o o r d i n a t e a r r a y : Typ chyby : N e v a l i d n i g e o m e t r i e s d o e l e m i n f o a r r a y : s d o o r d i n a t e a r r a y : Typ chyby : N e v a l i d n i g e o m e t r i e s d o e l e m i n f o a r r a y : s d o o r d i n a t e a r r a y : V k a t a s t r a l n i m uzemi B o š i l e c celkem n a l e z e n o 3 n e v a l i d n i c h g e o m e t r i i. 1 Prefix KAJA je odvozen od jmenné konvence pro pojmenovávání vlastní objektů v databázi ISKN. Prefix vznikne spojením prvních dvou písmen ze jména a prvních dvou písmen z příjmení strůjce objektu. 62

63 Procedura KAJA NEVALIDNI GM KP volá proceduru KAJA NEVALIDNI GM KU, která provádí vlastní vyhledávání nevalidních geometrických popisů. Při volání procedury KAJA NEVALIDNI GM KU se této proceduře postupně předávají kódy všech katastrálních území, spadajících do katastrálního pracoviště s kódem kod kp. Pro výpis atributů SDO ELEM INFO a SDO ORDINATES byly naprogramovány v jazyce PL/SQL funkce, které vrací výpis těchto polí. Jedná se o funkce KAJA ELEM INFO TO TXT, respektive KAJA COORDINATES TO TXT. Tyto funkce jsou uvedene v příloze (viz C.3 a C.2) Procedura KAJA NEVALIDNI GM KU Procedura KAJA NEVALIDNI GM KU, napsaná v jazyce PL/SQL, provádí vlastní vyhledávání nevalidních geometrických popisů minimálních ohraničujících obdélníků pro záznamy v tabulce obsahující vnitřní kresbu a náležící do příslušného katastrálního území. Procedura KAJA NEVALIDNI GM KU má jeden vstupní parametr. KAJA NEVALIDNI GM KU(kod ku) kde: kod ku kód katastrálního území O validnosti geometrického popisu se rozhodne na základě návratové hodnoty funkce VALIDATE GEOMETRY WITH CONTEXT Funkce VALIDATE GEOMETRY WITH CONTEXT Funkce VALIDATE GEOMETRY WITH CONTEXT, která je součástí nadstavby Oracle Spatial, má následující formální zápis: Ukázka 5.9: Definice funkce VALIDATE GEOMETRY WITH CONTEXT SDO GEOM.VALIDATE GEOMETRY WITH CONTEXT ( thegeometry IN SDO GEOMETRY, t o l e r a n c e IN NUMBER ) RETURN VARCHAR2; kde: thegeometry geometrický popis prvku tolerance viz kapitola

64 Pokud funkce vrátí hodnotu TRUE, je geometrický popis validní. V ostatních případech geometrický popis minimálního ohraničujícího obdélníku příslušného záznamu není validní. Více lze o této funkci nalézt v [ORSG]. 64

65 Kapitola 6 Tvorba dat pro vybrané aplikace ČÚZK V této kapitole bude popsán alternativní způsob přípravy dat pro vybrané aplikace ČÚZK. Konkrétně digitální katastrální mapy, orientační mapy parcel a definičních bodů parcel a budov. Data jsou v požadovaném datovém formátu prostorových dat přímo generována z databáze ISKN. Zvoleným prostorovým datovým formátem pro uložení dat poskytovaných přes WMS (Web Map Service - webová mapová služba, více v [WMSS]) byl zvolen datový formát firmy ESRI shapefile. WMS používá i volně přístupná webová aplikace Nahlížení do katastru nemovitostí ( 6.1 Současný způsob přípravy dat pro vybrané aplikace ČÚZK Přesný postup přípravy dat pro WMS není v současné době popsán v žádném oficiálním dokumentu. Přibližný postup je takový, že se ze souborů nového výměnného formátu (NVF) rozrastruje kresba digitální katastrální mapy a orientační mapy parcel. Rozrastrování probíhá pomocí makra, jehož autorem je firma Gepro. Okolní rastry jsou vymaskovány, to znamená, že se ořízne hranice rastru tak, aby pasovala na hranici DKM. Soubory s NVF jsou vytvářeny ke každému 1. a 15. dni v měsíci. Generování souborů s NVF trvá přibližně 4 dny, proces rozrastrování a vystavení trvá přibližně 8 dní. 6.2 Datový formát shapefile Shapefile je datový formát firmy ESRI pro ukládání prostorových dat. Společně s daty prostorovými jsou ukládána i data atributová. Ukládání prostorových dat 65

66 do shapefile představuje ukládání dat po vrstvách. Jedna taková vrstva sestává z následujících souborů: nazev-vrstvy.shp shapefile, soubor obsahující geometrické popisy prostorových prvků obsažených ve vrstvě. nazev-vrstvy.dbf soubor obsahující atributová data vztahující se k prostorovým prvkům obsaženým ve vrstvě. nazev-vrstvy.shx soubor obsahující uložení prostorového indexu nad geometrickými popisy prvků obsažených ve vrstvě. Při ukládání geometrických popisů v souboru shapefile nejsou uvažovány topologické vztahy mezi příslušnými prostorovými prvky. Geometrický popis prostorového prvku je uložen ve formě množiny souřadnic. Shapefile podporuje všechny potřebné (z pohledu účelu programů popsaných v kapitolách 6.5, 6.13 a 6.9) prostorové typy: bod pro uložení definičních bodů a vybraných bodových prvků digitální katastrální mapy linie pro uložení hranic parcela a vybraných liniových prvků digitální katastrální mapy polygon Podrobný popis formátu shapefile lze nalézt v [ESRI]. Shapefile může být vytvořen několika různými způsoby. Jedním z možných způsobů je na základě podrobné specifikace formátu [ESRI] shapefile naprogramovat vlastní software, který bude umožňovat převod prostorových dat do formátu shapefile. Příkladem může být projekt GeoTools [GEOT]. Programový kód tříd, které jsou součástí knihovny GeoTools, respektují specifikace Open Geospatial Consortium (OGC, [GGIS]). 6.3 GeoTools K vytvoření shapefilů definičních bodů parcel a budov, orientační mapy parcel a digitální katastrální mapy byl použit programový kód z GeoTools. GeoTools je knihovna tříd naprogramovaných v jazyce Java s otevřeným zdrojovým kódem. Tato knihovna poskytuje metody pro manipulaci s prostorovými daty. Knihovna může být použita například i při implementaci geografického informačního systému. 66

67 6.4 Generování definičních bodů do formátu shapefile V rámci procesu přípravy dat pro mapový server ČÚZK byl vytvořen program GenerovaniSHP.jar. Tento program slouží ke generování definičních bodů parcel a budov do formátu shapefile. Zdrojovými daty jsou data katastru nemovitostí, konkrétně definiční body uložené v ISKN. Definiční body jsou v ISKN uloženy s využitím objektového datového typu SDO GEOMETRY. Pomocí tohoto typu jsou uloženy souřadnice definičních bodů. Více o datovém typu SDO GEOMETRY lze nalézt v kapitole Funkční požadavky na program GenerovaniSHP.jar Program GenerovaniSHP.jar byl vytvořen v programovacím jazyce Java. Pomocí tohoto programu je možné generovat: definiční body pro zvolené katastrální území, definiční body pro všechna katastrální území, na kterých se vyskytuje alespoň jeden definiční bod (definiční body ke všem parcelám a budovám by měly být v ISKN k dispozici k ), definiční body pro všechna katastrální území pro zvolený počet dnů zpětně. Generují se shapefily pro katastrální území, ve kterých došlo ke změně (přidání definičního bodu) ve zvoleném počtu dnů zpětně. Program pracuje tak, že se pomocí přihlašovacích údajů (uživatelské jméno, heslo) přihlásí k databázi, vybere z ní na základě vstupního parametru potřebné údaje a generuje příslušný výstup. Ke každému souboru shapefile je generován soubor s příponou dbf. Tento soubor má shodný název jako generovaný soubor s příponou shp. Ve vytvořeném dbf souboru jsou uloženy atributové informace k definičním bodům. U definičních bodů se uvažují následující atributové informace: popis Popis definičního bodu. druh defb Druh definičního bodu. Atribut popis Hodnoty ukládané do pole popis představují parcelní čísla parcel a budov, ke kterým se vztahují dané definiční body. 67

68 Definiční body parcel Parcelní číslo může obsahovat poddělení čísla parcely a případně také díl parcely. Jednotlivé informace jsou od sebe v poli popis odděleny znakem /. Například hodnota 242/5 uložená v poli popis znamená, že se daný definiční bod váže k parcele s kmenovým číslem parcely 242 a podlomením čísla parcely 5. V případě, kdy jsou parcely v katastrálním území číslovány ve dvou číselných řadách, tak u stavebních parcel je hodnota v poli popis uvozena prefixem st., který značí, že se jedná o definiční bod vztahující se ke stavební parcele. Definiční body budov V případě záznamů pro definiční body budov se mohou v poli popis objevit následující hodnoty: č.p. jedná se o budovu s číslem popisným č.e. jedná se o budovu s číslem evidenčním bez č.p./č.e. jedná se o budovu bez čísla popisného a evidenčního Atribut druh defb V poli druh defb se mohou vyskytnout následující hodnoty: 1 definiční bod pozemkové parcely 2 definiční bod stavební parcely 3 definiční bod budovy s číslem popisným, či evidenčním 4 definiční bod budovy bez čísla popisného a evidenčního 5 definiční bod parcely zjednodušené evidence Ukázka spuštění programu GenerovaniSHP.jar: java -jar GenerovaniSHP.jar login password volba behu cesta kde: login uživatelské jméno pro připojení do databáze password uživatelské heslo volba behu hodnota tohoto parametru určí, co bude program GenerovaniSHP.jar generovat na výstupu: 68

69 NNNNNN šestimístný kód katastrálního území - program vygeneruje definiční body pro zvolené katastrální území all vygenerují se definiční body pro všechna katastrální území, na jejichž území existuje k datu spuštění digitální katastrální mapa -C vygenerují se shapefily pro katastrální území, ve kterých došlo ke změně ve zvoleném počtu dnů zpětně cesta cesta pro umístění vygenerovaných shapefilů Program generuje (ve všech variantách spuštění) následující výstupní soubory: nnnnnn.shp soubor obsahující geometrické popisy definičních bodů nnnnnn.dbf soubor obsahující atributové informace vztažené k definičním bodům nnnnnn.shx soubor obsahující informace o prostorovém indexu vybudovaném nad prostorovými daty uloženými v souboru nnnnnn.shp nnnnnn ve všech uvedených případech označuje šestimístný kód katastrálního území Generování definičních bodů pro zvolené katastrální území Ukázka spuštění programu, pokud chceme generovat definiční body pro zvolené katastrální území: java -jar GenerovaniSHP.jar novakj Abc c:\generovanishp\shp Po spuštění pod uživatelem novakj s heslem Abc123 program vygeneruje shapefile s názvem shp. Dále soubory dbf a shx. Soubory budou uloženy v adresáři c:\generovanishp\shp Generování definičních bodů pro všechna katastrální území, obsahující alespoň jeden definiční bod Ukázka spuštění programu, pokud chceme generovat definiční body pro všechna katastrální území, obsahující alespoň jeden definiční bod: java -jar GenerovaniSHP.jar novakj Abc123 all c:\generovanishp\shp 69

70 Po spuštění pod uživatelem novakj s heslem Abc123 program vygeneruje shapefily s definičními body pro všechna katastrální území. Soubory budou uloženy v adresáři c:\generovanishp\shp. V současné době trvá vygenerování shapefilů s definičními body pro všechna katastrální území, obsahující alespoň jeden definiční bod, přibližně šest hodin Generování definičních bodů pro všechna katastrální území pro zvolený počet dnů zpětně Ukázka spuštění programu, pokud chceme generovat definiční body pro všechna katastrální území, pro zvolený počet dnů zpětně: java -jar GenerovaniSHP.jar novakj Abc123-3 c:\generovanishp\shp Po spuštění pod uživatelem novakj s heslem Abc123 program vygeneruje shapefily pro všechna katastrální území, ve kterých došlo ke změně ve zvoleném počtu dnů zpětně, v tomto případě konkrétně v posledních třech dnech od data spuštění programu. Soubory budou uloženy v adresáři c:\generovanishp\shp. Konkrétně probíhá výběr dat za zvolený počet dnů zpětně na základě následující podmínky: Ukázka 6.1: Podmínka pro výběr definičních bodů zpětně TO CHAR( i s k n.ak OBRAZY DEF BODU.CREATE DATE, YYYY.MM.DD HH24 : MI : SS ) > TO CHAR(SYSDATE 1, YYYY.MM.DD ) 0 0 : 0 0 : 0 0 ; Pokud se generují shapefily pro katastrální území, ve kterých došlo ke změně v průběhu posledního dne, je obvykle vygenerováno shapefilů. 6.6 Kontrola funkčnosti Pro kontrolu, zda byl programem GenerovaniSHP.jar vybrán a zpracován správný počet definičních bodů, jsem vytvořil dotaz (v tomto dotazu se kontroluje počet definičních bodů uložených v ISKN pro katastrální území se šestimístným kódem ), viz ukázka

71 Ukázka 6.2: Kontrola počtu definičních bodů SELECT SUM( rows) AS t o t a l r o w s FROM ( SELECT COUNT( db. i d ) AS rows FROM i s k n. a k p a r c e l y pa, i s k n. a k o b r a z y d e f b o d u db WHERE pa. katuze kod = AND pa. i d = db. p a r i d UNION ALL SELECT COUNT( db. i d ) AS rows FROM i s k n.ak BUDOVY bu, i s k n.ak OBRAZY DEF BODU db, i s k n.ak PARCELY pa WHERE pa. katuze kod = AND pa. bud id = bu. i d AND bu. i d = db. bud id ) AS pocet ; Počet bodů vrácený předchozím dotazem se v rámci běhu programu GenerovaniSHP.jar porovná s počtem bodů vygenerovaných do konkrétního shapefilu. V případě, že by tento počet nesouhlasil, vypíše se do logovacího souboru informace o tom, že program zapsal do výstupního souboru rozdílný počet definičních bodů, než kolik jich je ve skutečnosti uloženo v ISKN. 6.7 Grafická ukázka výstupu z programu GenerovaniSHP.jar Obrázek 6.1 zobrazuje definiční body vygenerované pro katastrální území Plzeň se šestimístným kódem Převod digitální katastrální mapy do formátu shapefile Na převod digitální katastrální mapy do formátu shapefile byl vytvořen program DKM2SHP.jar. Program umožňuje generovat digitální katastrální mapu po dlaždicích Digitální katastrální mapa Digitální katastrální mapa (DKM) se zpracovává pro katastrální území nebo jeho část v S JTSK ve vztažném měřítku 1:1000. Vede se jako spojitá a bezešvá mapa pro území celé ČR prostředky informačního systému katastru nemovitostí (ISKN). Forma a obsah DKM jsou stanoveny v 16 vyhlášky č. 26/2007 Sb. Pro zavedení DKM do ISKN a pro poskytování výstupů obsahu DKM z ISKN se používá výměnný formát podle zvláštního předpisu [CUZK]. 71

72 Obrázek 6.1: Definiční body v katastrálním území Funkční požadavky na program DKM2SHP.jar Vzhledem ke skutečnosti, že digitální katastrální mapa sestává z bodových i liniových prvků, jsou pro každou dlaždici digitální katastrální mapy vygenerovány dva shapefily. Jeden bodový, obsahující bodové prvky, druhý liniový, obsahující liniové prvky. U bodových shapefilů s bodovými prvky digitální katastrální mapy evidujeme následující atributy: id Identifikátor bodového prvku. typppd kod Typ prvku prostorových dat. text Textový popis. angle Úhel natočení textového popisu. size Velikost textového popisu. 72

73 Atribut id U bodových prvků digitální katastrální mapy je hodnota v tomto poli jednoznačným identifikátor konkrétního bodového prvku. Hodnota je převzata z ISKN. Atribut typppd kod Hodnota v tomto sloupci značí typ prvku prostorových dat. Hodnoty jsou převzaty z ISKN. Atribut text Atribut text obsahuje parcelní číslo včetně případného podlomení. Hodnoty pro určení parcelního čísla jsou převzaty z ISKN. Atribut angle Textový popis může být na grafickém výstupu různě pootočen. Informace o velikosti úhlu natočení je uložena právě v poli angle. Hodnota je převzata z ISKN. Atribut size Hodnota atributu size udává velikost textového popisu. Hodnota je převzata z ISKN. Obrázek 6.2 zobrazuje detail vygenerované kresby, na kterém je vidět kombinace liniových a bodových prvků digitální katastrální mapy. U liniových shapefilů s liniovými prvky digitální katastrální mapy evidujeme následující atributy: id Identifikátor bodového prvku. typppd kod Typ prvku prostorových dat. Atribut id U liniových prvků digitální katastrální mapy není hodnota v tomto poli jednoznačným identifikátorem konkrétního liniového prvku, přesněji konkrétního záznamu ve vygenerované dbf tabulce. Je to z důvodu, že pokud je z databáze při vytváření konkrétní dlaždice DKM načtena polylinie, je tato polylinie do generovaného shapefilu uložena po jednotlivých dílčích úsečkách. Hodnota pro pole id je převzata z ISKN. 73

74 Obrázek 6.2: Detail vygenerované DKM - liniové a bodové prvky Atribut typppd kod Hodnota v tomto sloupci značí typ prvku prostorových dat. Hodnoty jsou převzaty z ISKN, jsou ovšem před uložením do sloupce typppd kod modifikovány. Pokud je způsob určení výměry alespoň jedné ze dvou parcel, které mezi sebou daný hraniční úsek svírají, rovna 2 (graficky ze souřadnic S JTSK), nebo je kód kvality bodu počátečního a koncového bodu roven 3, je uložená hodnota vypočtena ze vztahu: typppd kod = typppd kod * 10 V jiném případě je hodnota atributu typppd kod vypočtena ze vztahu: typppd kod = (typppd kod * 10) + 1 Tento způsob výpočtu hodnoty atributu typppd kod je způsoben požadavkem na grafické rozlišení hraničních úseků splňujících výše uvedenou podmínku na způsob určení výměry a kód kvality určení počátečního a koncového bodu. Program DKM2SHP.jar má následující parametry: java -jar DKM2SHP.jar uzivatel heslo cesta pocet radku 74

75 kde: uzivatel uživatelské jméno pro připojení do databáze heslo uživatelské heslo cesta cesta pro umístění vygenerovaných shapefilů pocet radku dlaždice vygenerované programem GenerujSit.jar jsou generovány shora dolů zprava doleva po řádcích; hodnota parametru pocet radku udává, kolik řádků dlaždic s vygenerovanou digitální katastrální mapou bude uloženo ve společném podadresáři v adresáři určeném hodnotou parametru cesta Parametr pocet radku byl zaveden pro snazší manipulaci s vynegerovanými shapefily. Nebylo žádoucí, aby se všechny vygenerované shapefily generovaly do jednoho společného adresáře a tento adresář pak obsahoval řádově desetitisíce souborů. Název adresáře je generován v závislosti na hodnotě parametru pocet radku. Skládá se ze souřadnic levého dolního rohu a pravého horního rohu minimální ohraničující oblasti všech dlaždic, které obsahuje. Znamená to, že tento adresář bude obsahovat všechny dlaždice, které by celé ležely uvnitř této oblasti. Pokud je název adresáře například , pak dlaždice, jejíž levý dolní roh má souřadnice [ ;926000] a pravý horní roh má souřadnice [ ;924000], bude obsažena po skončení běhu programu v tomto adresáři. Samozřejmě za předpokladu, že se v oblasti dané souřadnicemi dlaždice nacházela digitální katastrální mapa. Uvedený příklad názvu adresáře byl pro hodnotu parametru pocet radku rovno tři. Konkrétní příklad spuštění programu DKM2SHP.jar pod uživatelským jménem novakj s heslem Abc123 a s uložením vygenerovaných shapefilů do adresáře c:\dkm2shp\shp: java -jar DKM2SHP.jar novakj Abc123 c:\dkm2shp\shp 3 Obrázek 6.3 zobrazuje obsah jedné vygenerované dlaždice (liniové prvky) Generování kružnic Předpis pro vyhotovení digitální katastrální mapy umožňuje, aby hranici parcely tvořila v jejím geometrickém vyjádření kružnice. Při tvorbě programu DKM2SHP.jar tak bylo nutno zohlednit i tuto skutečnost. Program DKM2SHP.jar generuje kružnici aproximovanou dostatečně malými úsečkami. Při určení hodnoty délky úsečky se vycházelo především z požadavku, aby tvar hranice parcely i při bližším přiblížení působil jako kružnice. Ve výsledku jsem pro délku úsečky apriori stanovil hodnotu 10 cm. 75

76 Obrázek 6.3: Vygenerovaná dlaždice DKM Kružnice může být určena buď svým středem a poloměrem, případně pomocí třech bodů ležících na kružnici. Oba dva způsoby zadání kružnice ISKN v současné době podporuje. V programu DKM2SHP.jar se řeší generování kružnice následovně - pokud je načtena kružnice, která je zadána svými třemi body, je nejprve zjištěn střed budoucí vygenerované kružnice a následně poloměr. Pokud je kružnice ve vstupních datech zadána svým středem a poloměrem, přistoupí se rovnou k provedení algoritmu generujícího výslednou kružnici. Pro výpočet kružnic aproximovaných liniovými úsečkami ke geometrickému vyjádření hranic parcel kruhového tvaru bylo využito rovnice kružnice: kde: x = x s + r cos α y = y s + r sin α [x s, y s ] souřadnice středu kružnice r poloměr generované kružnice α úhel který mezi sebou svírají body i a i + 1 kružnice 76

77 Pro α platí: 0 <= α < 2 π Volba velikosti přírůstku úhlu α v závislosti na r určuje počet bodů na obvodu výsledné kružnice. Konkrétně je hodnota přírůstku úhlu α určena vztahem: α = 2 (sin(0.05/r)) Obrázek 6.4 ilustruje vytvořenou kružnici a kruhový oblouk. Obrázek 6.4: Vygenerovaná kružnice a kruhový oblouk Generování kruhových oblouků Část hranice parcely může být geometricky vyjádřena jako kruhový oblouk. Při tvorbě programu DKM2SHP.jar tak bylo nutno zohlednit i tuto skutečnost. Pokud je část hranice parcely v digitální katastrální mapě reprezentována kruhovým obloukem, je tento kruhový oblouk zadán a v ISKN uložen pomocí třech bodů. Počátečním, koncovým a mezilehlým. Z těchto informací je vypočten výsledný kruhový oblouk aproximovaný dostatečně malými úsečkami. Velikost 77

78 useček aproximujících kruhový oblouk je závislá na poloměru daného kruhového oblouku. Hodnota přírůstku úhlu α je určena vztahem: kde: α = 2 (sin(0.05/r)) r poloměr generovaného kruhového oblouku Generování křivek Vybrané prvky digitální katastrální mapy mohou mít ve svém geometrickém vyjádření tvar obecné křivky. Při tvorbě programu DKM2SHP.jar tak bylo nutno zohlednit i tuto skutečnost. Informace o tom, že má být daný prostorový prvek generován jako křivka, je uložena v systému ISKN. Vlastní způsob vykreslení prvku je pak na obslužném software. Mé řešení spočívá ve vyjádření uvedených prostorových prvků jako křivky aproximované přirozeným kubickým splinem s uniformní parametrizací. Při konstrukci křivek jsem vycházel z teoretického popisu v [JEZE]. Ve stručnosti je konstrukce přirozeného kubického spline popsána v kapitolách 6.9.4, a Interpolační křivky V počítačové grafice interpolace slouží ke kreslení (definování) křivky, pro kterou známe několik bodů (nazýváme je opěrnými body nebo uzly interpolace). Interpolační křivka těmito body prochází. Problémem však je, jak stanovit hodnotu parametru, pro níž obdržíme daný opěrný bod interpolační křivky. Interpolační křivka je dána opěrnými body P 0, P 1,..., P n a hodnotami t 0, t 1,..., t n parametru pro tyto body. Má pak vektorové vyjádření a platí P = P(t), t t 0, t n P i = P(t i ), i = 0,..., n. Hodnoty parametru t i se většinou určují automaticky. Je-li t i+1 t i = konst, mluvíme o uniformní parametrizaci interpolační křivky. Nejčastěji se v tomto případě volí t i = i. Interpolační křivka se zpravidla vytváří z jednotlivých oblouků křivky, neboť pokud bychom chtěli jednou vektorovou funkcí s polynomickými složkami popsat celou interpolační křivku, byly by tyto polynomy vysokého stupně (stupně n). Základem pro výpočet interpolační křivky po obloucích je tzv. Fergusonova kubika. 78

79 6.9.5 Fergusonova kubika Nechť jsou dány body P i a P i+1 s polohovými vektory P i a P i+1. Označme dále P i a P i+1 tečné vektory v těchto bodech. Nechť uvedeným bodům odpovídají hodnoty t i a t i+1 parametru. Fergusonovu kubiku určíme pomocí rovnice P(t) = H 0 (t t i )P i + H 1 (t t i )P i H 2 (t t i )P i + H 3 (t t i )P i+1, (6.1) kde H i (s) jsou polynomy třetího stupně. Z podmínek P(t i ) = P i, P(t i + 1) = P i+1, P (t i ) = P i, P (t i+1 ) = P i+1 určíme vektory koeficientu u jednotlivých mocnin výrazu t t i a dojdeme při označení i k = t i+1 t i, s = t t i k těmto vztahům H 0 (s) = 2 i k 3 s 3 3 H 1 (s) = 2 i k 3 s H 2 (s) = 1 i k 2 s 3 2 H 3 (s) = 1 i k 2 s 3 1 s 2 + 1, i k 2 s 2, i k 2 i k s2 + s, i k s2. (6.2) Pro uniformní parametrizaci t i = 0, t i+1 = 1, tj. i k = 1 získáme ze vztahu 6.2 funkce F i : F 0 (t) = 2t 3 3t 2 + 1, F 1 (t) = 2t 3 + 3t 2, F 2 (t) = t 3 2t 2 + t, F 3 (t) = t 3 t 2. (6.3) Kubické spline křivky Nejprve definujeme pojem kubické spline funkce: Nechť je dána posloupnost x 0 < x 1 < < x n a funkční hodnoty y 0, y 1,..., y n. Kubickou spline funkcí f(x) rozumíme interpolační funkci, tj. platí f(x i ) = y i, která je na každém z intervalů x i, x i+1 polynomem třetího stupně a funkce f má spojitou první a druhou derivaci v intervalu (x 0, x n ). Zadáním opěrných bodů však není kubická spline funkce určena jednoznačně, neboť kubické polynomy (je jich n) mají celkem 4n vektorových koeficientů a k dispozici máme 4n 2 podmínek: krajní body jednotlivých úseků n podmínek, spojitost první derivace n 1 podmínek, spojitost druhé derivace n 1 podmínek. Je zřejmé, že k určení kubické spline funkce je třeba zvolit ještě dvě další podmínky. Zpravidla se zadávají hodnoty první derivace v počátečním a koncovém 79

80 bodě křivky nebo hodnoty druhé derivace v těchto bodech (speciálně se často volí podmínka volného konce, tj. nulová druhá derivace v krajních bodech). Spline křivkou (kubickou) pro dané opěrné body P 0, P 1,..., P n a dané hodnoty parametru t 0 < t 1 < < t n rozumíme křivku P = P(t), t t 0, t n, pro níž každá ze složek vektorové funkce P(t) je kubickou spline funkcí. Zadání hodnot parametru pro opěrné body se většinou realizuje jistým algoritmem. Např. se volí uniformní parametrizace t i = i. Výpočet kubické spline křivky provedeme tak, že nejprve určíme tečné vektory křivky v opěrných bodech a pak jednotlivé oblouky spline křivky vypočteme jako Fergusonovy kubiky podle vztahů 6.1 a 6.2. Označme P i, i = 0,..., n hledané tečné vektory kubické spline křivky v opěrných bodech. Vzhledem k požadavku spojitosti druhé derivace získáme z 6.1 a 6.2 po úpravách vztah 1 i k i+( 2 P i k + 2 i+1 k i+1+ 1 )P i+1 k P i+2 = 3 i+1 k P i+2+( 3 2 i k 3 2 i+1 k )P i i k P i, (6.4) 2 kde i = 0,..., n 2. Zbylé dvě rovnice pro výpočet tečných vektorů odvodíme z následující podmínky: Jsou dány vektory A a B druhých derivací v počátečním a koncovém bodě křivky. V tomto případě z 6.1 a 6.2 doplníme soustavu 6.4 o rovnice 2P 0 + P 1 = 3 (P 0 k 1 P 0 ) 0 k A, 2 P n 1 + 2P 3 n = (P n 1 k n P n 1 ) + n 1 k (6.5) B. 2 Speciálně pro A = B = o dostáváme tzv. kubický přirozený spline. Řešení soustavy n rovnic o n neznámých vektorech je provedeno Gaussovou eliminací. Matice soustavy je diagonálně dominantní a navíc je tato matice třídiagonální. Obrázek 6.5 ilustruje kombinaci vytvořených křivek a kruhových oblouků Generování dlaždic Dlaždice mají v aktuální verzi programu rozměr 2 x 2 km. Proces nalezení optimálního rozměru dlaždice byl záležitostí dlouhého testování. Základními požadavky pro určení rozměru dlaždice byl požadavek na to, aby generované shapefily nebyly příliš veliké a dále, aby se negenerovalo přílišné množství dlaždic. Výsledkem je rozměr dlaždice 2x2 km. Pro vygenerování sítě dlaždic byl vytvořen program GenerujSit.jar. 80

81 Obrázek 6.5: Vygenerované křivky a kruhové oblouky GenerujSit.jar Program na generování dlaždic byl vytvořen v programovacím jazyce Java. V kódu jsou jako konstanty uvedeny extremální hodnoty souřadnic v osách X a Y pro souřadnicový systém S -JTSK nabývané v ČR, které slouží jako limity při generování dlaždic. Generovaná síť je tedy omezena následujícími limitami [m]: X min = X max = Y min = Y max = Program GenerujSit.jar se spouští následujícím způsobem: java -jar GenerujSit.jar a kde: a délka strany dlaždice v metrech 81

82 Pro vygenerování dlaždic s rozměrem 2 x 2 km se spustí program GenerujSit.jar spustíme program následovně: java -jar GenerujSit.jar 2000 Program vygeneruje dlaždice o rozměrech 2 x 2 km uložených v textovém souboru sit2000.sql. Tento soubor obsahuje SQL DML příkazy INSERT pro vložení dlaždic do databáze. Celkem se pro dlaždice o rozměrech 2 x 2 km vygeneruje záznamů. Ukázka 6.3: Ukázka souboru sit2000.sql. Příklad vložení jedné dlaždice INSERT INTO KAJA SIT CR 2000 VALUES( MDSYS.SDO GEOMETRY( 2003, NULL, NULL, MDSYS.SDO ELEM INFO ARRAY( 1, , 3 ), MDSYS.SDO ORDINATE ARRAY( , , , ) ), ) ; Jak je vidět ze struktury souboru sit2000.sql, data se v databázi ukládají do tabulky KAJA SIT CR Definice tabulky KAJA SIT CR 2000 je následující: Ukázka 6.4: Definicie tabulky KAJA SIT CR 2000 CREATE TABLE KAJA SIT CR 2000 ( geometrie MDSYS.SDO GEOMETRY ) ; Tabulka KAJA SIT CR 2000 obsahuje dlaždice kompletně pokrývající území ČR. Obsahuje ale také dlaždice, které leží mimo území ČR. V současné verzi programu DKM2SHP.jar jsou při generování digitální katastrální mapy do formátu shapefile uvažovány i tyto dlaždice. Aby se negeneroval prázdný shapefile, zůstane takovýto shapefile nevygenerovaný. Prázdné shapefily se sice negenerují, ale i tak musí proběhnout test na průnik mezi geometrií dlaždice a geometriemi prvků digitální katastrální mapy. Možné rozšíření programu DKM2SHP.jar tak spočívá v eliminaci dlaždic, které celé leží za hranicemi ČR. Další rozšíření může spočívat v eliminaci dlaždic, které sice mají neprázdný průnik s hranicí ČR, případně v ní leží celým svým obsahem, ale jsou v území, ve kterém v současné době neexistuje digitální katastrální mapa Aktuální stav tvorby DKM Délka trvání programů na generování grafických výstupů z ISKN ve formátu shapefile a množství generovaných dat, závisí na procesu digitalizace souboru geodetických informací, respektive tvorbě digitální katastrální mapy. Stejně tak 82

83 je tomu u programů na nalezení nekonzistencí v prostorových datech ISKN, kde je možné kontroly spouštět pouze pro lokality s DKM. Ke konci roku 2007 byla digitální katastrální mapa k dispozici přibližně pro třetinu katastrálních území [CADA]. Pro možnost generovat přehlednou statistiku o stavu tvorby digitální katastrální mapy jsem vytvořil program StatistikyDigitalizace.jar Program StatistikyDigitalizace.jar Program se spouští se šesti vstupními parametry. Spuštění programu: java jar StatistikyDigitalizace.jar soubor1 soubor2 stav dat soubor3 rok min q kde: soubor1 soubor se vstupními daty. soubor2 soubor pro uložení výsledku. stav dat konec aktuálního kvartálu. Formát: DD.MM.RRRR (např ). soubor3 soubor s výslednými hodnotami pro předchozí kvartál. rok aktuální rok. Formát: RRRR (např. 2007). min q konec minulého kvartálu. Formát: DD.MM.RRRR (např ). Každý řádek vstupních dat v souboru soubor1 odpovídá právě jednomu katastrálnímu území. Data se generují čtvrtletně s tím, že program rovněž porovná přírůstek/ úbytek daného typu mapy oproti předchozímu čtvrtletí. Ukázka konkrétního spuštění programu: java jar StatistikyDigitalizace.jar celysgizaklad1q07.xls SGI q.xls SGI q.xls Poznámka: Před spuštěním programu je potřeba mít vstupní data seřazená, viz 6.6. Program generuje souhrnný přehled po katastrálních pracovištích, viz obrázek Převod orientační mapy parcel do formátu shapefile Orientační mapa parcel V územích, ve kterých není digitální katastrální mapa ani digitalizovaná mapa v S JTSK, se poskytuje orientační mapa parcel. Orientační mapu parcel zpravidla 83

84 Obrázek 6.6: Způsob řazení dat Obrázek 6.7: Statistika tvorby DKM 84

85 tvoří rastrové obrazy katastrální mapy a map dřívějších pozemkových evidencí přibližně transformované do SJTSK doplněné definičními body parcel, budov a vodních děl. Orientační mapa v S JTSK je do obnovy rastrového obrazu katastrální mapy doplňována informativním zobrazením změn v katastrální mapě Funkční požadavky na program OMP2SHP.jar U digitální katastrální mapy program DKM2SHP.jar produkoval shapefily, přičemž jeden shapefile obsahoval data v rozsahu 2 x 2 km, pokud na tomto území existovala (alespoň z části) digitální katastrální mapa. V případě programu OMP2SHP.jar je situace rozdílná. Pro každý mapový list orientační mapy parcel exituje v ISKN časový údaj o posledním datu aktualizace (přeskenování). Pokud jsou v ISKN uloženy prvky orientační mapy parcel, které byly vytvořeny až po posledním přeskenování, jsou tyto prvky vygenerovány. Důležité je, že vygenerovaný shapefile pro konkrétní mapový list orientační mapy parcel má rozsah daný souřadnicemi rohů tohoto listu, které jsou rovněž uloženy v ISKN. Narozdíl od shapefilů s digitální katastrální mapou nemají shapefily s orientační mapou parcel uměle stanoveny jednotný souřadnicový rozsah. Vzhledem ke skutečnosti, že orientační mapa parcel sestává z bodových i liniových prvků, jsou pro každý mapový list orientační mapy parcel vygenerovány dva shapefily. Jeden bodový, obsahující bodové prvky, druhý liniový, obsahující liniové prvky. U bodových shapefilů s bodovými prvky orientační mapy parcel evidujeme následující atributy: id Identifikátor bodového prvku. typppd kod Typ prvku prostorových dat. text Textový popis. angle Úhel natočení textového popisu. Atribut id U bodových prvků orientační mapy parcel je hodnota v tomto poli jednoznačným identifikátor konkrétního bodového prvku. Hodnota je převzata z ISKN. Atribut typppd kod Hodnota v tomto sloupci značí typ prvku prostorových dat. Hodnoty jsou převzaty z ISKN. 85

86 Atribut text Atribut text obsahuje parcelní číslo včetně případného podlomení. Hodnoty pro určení parcelního čísla jsou převzaty z ISKN. Atribut angle Textový popis může být na grafickém výstupu různě pootočen. Informace o velikosti úhlu natočení je uložena právě v poli angle. Hodnota je převzata z ISKN. U liniových shapefilů s liniovými prvky orientační mapy parcel evidujeme následující atributy: id Identifikátor liniového prvku. typppd kod Typ prvku prostorových dat. Atribut id U liniových prvků orientační mapy parcel není hodnota v tomto poli jednoznačným identifikátorem konkrétního liniového prvku, přesněji konkrétního záznamu ve vygenerované dbf tabulce. Je to z důvodu, že pokud je z databáze při vytváření konkrétního mapového listu OMP načtena polylinie, je tato polylinie do generovaného shapefilu uložena po jednotlivých dílčích úsečkách. Hodnota pro pole id je převzata z ISKN. Atribut typppd kod Hodnota v tomto sloupci značí typ prvku prostorových dat. Hodnoty jsou převzaty z ISKN. Program OMP2SHP.jar má následující parametry: java -jar GenerovaniSHP.jar uzivatel heslo cesta kde: uzivatel uživatelské jméno pro připojení do databáze heslo uživatelské heslo cesta cesta pro umístění vygenerovaných shapefilů 86

87 Všechny vygenerované soubory jsou uloženy v adresáři určeném hodnotou parametru cesta. Konkrétní příklad spuštění programu OMP2SHP.jar pod uživatelským jménem novakj s heslem Abc123 a s uložením vygenerovaných shapefilů do adresáře c:\omp2shp\shp: java -jar GenerovaniSHP.jar novakj Abc123 c:\omp2shp\shp 6.14 Grafická ukázka výstupu z programu OMP2SHP.jar Obrázek 6.8 zobrazuje bodové a liniové prvky pro jeden vygenerovaný mapový list orientační mapy parcel. Obrázek 6.8: Vygenerovaný mapový list orientační mapy parcel 87

88 Kapitola 7 Převod vybraných grafických dat ISKN do datových struktur Oracle Spatial ISKN je vytvořen nad databázovým systémem Oracle. K uložení grafických dat je částečně využito nadstavby Oracle Spatial (dále jen Spatial). Spatial pro uložení vektorových prostorových dat nabízí několik způsobů uložení. V práci jsem se prakticky věnoval využití objektově-relačního modelu dat (s využitím objektového datového typu SDO GEOMETRY a topologickému konceptu okřídlené hrany (s využitím datového typu SDO TOPO GEOMETRY). 7.1 Oracle Spatial Základní funkcionalita pro správu prostorových dat je nabízena ve všech edicích databáze Oracle. Tato funkcionalita vychází ze současných požadavků na zpracování prostorových dat, především pak velkého objemu manipulovaných dat. Mezi základní prvky správy prostorových dat patří možnost vytváření prostorového indexu, dotazování dat a manipulování s nimi pomocí dotazovacího jazyka SQL. Databáze Oracle v edici Enterprise nabízí prostorové rozšíření Spatial, umožňující provádění pokročilejších prostorových funkcí. Podporuje též velké množství souřadnicových systémů, k dispozici jsou funkce pro vzájemnou transformaci mezi nimi. V celku tak může jít o základní funkcionalitu geografického informačního systému. Procedury a funkce Oracle Spatial jsou nabízeny jako podprogramy v balících 1 PL/SQL. Spatial má implicitně k dispozici několik balíků procedur a funkcí. 1 Procedury a funkce, které spolu souvisí, je možno pro další použití vkládat do tzv. balíků. Zde jsou obsaženy všechny typy, konstanty, proměnné, výjimky, kurzory, procedury a funkce, ke kterým je možno přistupovat z ostatních aplikací (pokud mají k danému balíku patřičná přístupová práva). 88

89 Obecně pro podprogramy z těchto balíků platí několik společných zásad. Nevyžadují například definování prostorového indexu a ani prostorový index nepoužívají, pokud je definován. Pokud jsou vstupními parametry procedury nebo funkce Oracle Spatial geometrické popisy dvou prvků, musí být oba vztaženy ke shodnému souřadnicovém systému a podobně. Více v [ORSG] a [ORST]. Pro efektivní použití nabízených podprogramů je nutné pochopit základní principy a filosofii prostředí Oracle Spatial. Oracle Spatial (dále jen Spatial) je integrovaná množina funkcí a procedur, které umožňují uložení, přístup a analýzu prostorových dat rychlým a efektivním způsobem v databázi Oracle. Spatial se skládá z následujících komponent: Schématu předepisujícího ukládání, syntaxy a sémantiku podporovaných geometrických datových typů. Mechanismu prostorového indexování. Množiny operátorů a funkcí pro provádění prostorových dotazů a analýz. Podpůrných utilit. 7.2 Objektově-relační model Spatial Spatial podporuje objektově-relační model uložení prostorových dat. Pro uložení prostorových dat využívá objektového datového typu SDO GEOMETRY. V jedné tabulce jsou tak pro prvek popisná data uložena společně s prostorovými. Výhody nabízené objektově-relačním modelem jsou především: Podpora mnoha geometrických typů, např. oblouků, kružnic, liniových řetězců či polygonů. Snadné použití při vytváření a údržbě prostorových indexů a dotazů. Uložení geometrických popisů prvků v jednom řádku a jednom sloupci tabulky. Optimální výkon Podporované geometrické typy Geometrický popis prvku je de facto seřazená sekvence vrcholů spojených přímými liniovými segmenty nebo kruhovými oblouky. Sémantika geometrického popisu prvku je určena jeho typem. Spatial podporuje několik primitivních geometrických typů, a to: 89

90 Bod a shluk bodů. Liniový řetězec. Polygon o n bodech. Liniový řetězec, kde je každý dílčí úsek tvořen kruhovým obloukem. Polygon, kde je každý dílčí úsek tvořen kruhovým obloukem. Smíšený liniový řetězec liniový řetězec, kde je každý dílčí úsek tvořen buď přímým liniovým segmentem, nebo kruhovým obloukem. Smíšený polygon polygon, kde je každý dílčí úsek tvořen buď přímým liniovým segmentem, nebo kruhovým obloukem. Kružnice. Pravoúhelník Hierarchické uspořádání dat v Oracle Spatial Spatial na sloupec typu SDO GEOMETRY nahlíží jako na vrstvu. Vrstva obsahuje jednotlivé prostorové prvky tvořené základními geometrickými elementy. Element Element je základní stavební blok geometrického popisu prvku. Podporované prostorové typy elementů jsou body, liniové řetězce a polygony. Souřadnice v elementu jsou ukládány jako pár souřadnic X,Y. Bodové elementy sestávají z jednoho páru X,Y souřadnic. Liniové elementy, reprezentující liniový segment elementu, sestávají ze dvou párů souřadnic X,Y. Polygonové elementy tvoří dva páry souřadnic X,Y pro každý liniový segment polygonu. Souřadnice jsou definovány v požadovaném pořadí (pro vnější polygon v protisměru chodu hodinových ručiček, pro vnitřní polygon ve směru chodu hodinových ručiček). Geometrický popis prvku Geometrický popis prvku je reprezentace prostorového prvku, modelovaná jako uspořádaná množina primitivních elementů. Geometrický popis může tvořit samostatný element podporovaného primitivního typu, nebo homogenní či heterogenní soubor elementů. Multipolygon, který bude reprezentovat množinu několika polygonů, je homogenní kolekce. O heterogenní kolekci se jedná v případě, že jsou jednotlivé elementy rozdílných typů, například bod a polygon. 90

91 Vrstva Vrstva je soubor geometrických popisů prvků majících shodnou množinu atributů. Jedna vrstva může obsahovat například topografické prvky, druhá může popisovat hustotu zalidnění a třetí síť silnic a mostů v určité oblasti (linie a body). Všechny geometrické popisy prvků dané vrstvy jsou uloženy v databázi ve standardní tabulce Souřadnicový systém Souřadnicový systém dovoluje interpretovat množinu souřadnic jako reprezentaci polohy v reálném prostoru. Prostorová data jsou spojena s určitým souřadnicovým systémem, který může být souřadnicově spjatý s určitou aproximací Země, nebo jako například kartézský systém souřadnic nemusí být souřadnicově spjatý s žádnou aproximací Země. Spatial nabízí podporu pro mnoho různých souřadnicových systémů a pro konvertování dat mezi těmito systémy. Bohužel, Spatial v současné době nepodporuje souřadnicový systém S JTSK. Prostorová data mohou být v prostředí Spatial spojena s kartézským, geodetickým, projektivním, nebo místním souřadnicovým systémem Tolerance Tolerance je použita ke spojení stupně přesnosti s prostorovými daty. Určuje vzdálenost, ve které od sebe mohou být dva body a stále budou považovány za shodné. Hodnota odchylky musí být kladné číslo různé od nuly. Význam hodnoty tolerance závisí na tom, zda jsou či nejsou prostorová data spojená s geodetickým souřadnicovým systémem. Pro data v geodetickém souřadnicovém systému je hodnota tolerance v metrech. Například hodnota 100 znamená toleranci 100 metrů. Hodnota tolerance pro geodetická data by neměla být menší než (1 milimetr). Pokud určíme menší hodnotu tolerance než 0.001, Spatial použije hodnotu Pro data v jiném než geodetickém systému je hodnota tolerance v jednotkách souřadnicového systému, ve kterém jsou data vyjádřena. To znamená, že pokud je zvolenou jednotkou míle, hodnota znamená toleranci 1/200 míle. V obou případech ale platí, že čím menší je hodnota tolerance, tím jsou data přesnější. Hodnota tolerance se specifikuje ve dvou případech: V definici metadat pro prvky ve vrstvě. 91

92 Jako vstupní parametr některých funkcí Dotazovací model Spatial používá k řešení prostorových dotazů a prostorových spojení dvouvrstvý dotazovací model. Během něj jsou vykonány k vyhodnocení dotazů dvě odlišné operace. Výstupem kombinace těchto dvou operací je hledaná množina geometrických popisů prvků. Vykonané operace jsou označovány jako primární a sekundární operace filtrování (primární a sekundární filtr): Primární filtr umožňuje rychlý výběr potenciálních záznamů, které jsou předány sekundárnímu filtru. Sekundární filtr aplikuje přesné výpočty na geometrické popisy prvků, které mu předal filtr primární. Sekundární filtr dává přesnou odpověď na prostorový dotaz. Obrázek 7.1 ilustruje vztah mezi primárním a sekundárním filtrem. Obrázek 7.1: Dotazovací model Jak ukazuje obrázek 7.1, operace primárního filtrování aplikovaná na rozsáhlou množinu vstupních dat produkuje množinu menší, která obsahuje hledané geometrické popisy prvků, ale může také obsahovat záznamy navíc, které nemají být do výsledku zahrnuty. K odstranění nežádoucích záznamů dojde aplikováním sekundárního filtru. Cílem primárního filtru je rychle vytvořit podmnožinu dat a redukovat zatížení zpracování pro sekundární filtr. K tomu Spatial používá prostorový index, jehož charakteristiky rozhodují o úspěšnosti primárního filtru Indexování prostorových dat v Oracle Spatial Zavedení možností prostorového indexování do databáze Oracle je klíčové pro produkt Spatial. Prostorový index nabízí mechanizmus k vyhledávání založený na prostorových kritériích. 92

93 Prostorový index je potřebný k: Nalezení geometrického popisu prvku uvnitř indexovaného datového prostoru, které mají souvislost s daným bodem nebo oblastí zájmu (dotazovací okno). Nalezení dvou geometrických popisů prvků z různých indexovaných prostorů, které spolu prostorově souvisí (prostorové spojení). Oracle Spatial používá k indexování prostorových dat dvě datové struktury: Čtyřstrom (Quadtree), R-strom (R-tree). Následně budou stručně popsány jednotlivé datové struktury. Kapitola pak obsahuje výstupy z testování a porovnání těchto dvou datových struktur pro indexování prostorových dat v prostředí Oracle Spatial. R tree index R-strom je m-ární strom s těmito vlastnostmi ([POZE]): Každý nelistový uzel má n bezprostředních následníků, n z m1,m ; m1 m 2. Každý listový uzel obsahuje n indexových záznamů, n z m1,m ; m1 m 2. Kořen má nejméně dva bezprostřední následníky, není-li listem. Všechny cesty v R-stromu jsou stejně dlouhé Odkazy na objekty jsou uloženy v listech. R tree index aproximuje každý geometrický popis prvku samostatným pravoúhlým čtyřúhelníkem (též minimum bounding rectangle MBR), jak ukazuje obrázek 7.2. Obrázek 7.2: Ukázka MBR R tree index pro vrstvu geometrických popisů sestává z hierarchického indexu na konvexní obálky prvků ve vrstvě, jak je ukázáno na obrázku

94 Obrázek 7.3: Hierarchický R tree index Čtyřstrom Čtyřstrom je typem dlaždicového indexu. Název indexu je odvozený ze způsobu vytváření. Prostor je na rozdíl od dlaždicového indexu, kdy je prostor pravidelně rozdělen na dlaždice určité velikosti, rekurzivně dělen do kvadrantů v závislosti na rozmístění objektů. Pro čtyřstrom existuje několik variant. Bodový čtyřstrom (Point Quadtree) Používá se pro indexování bodových prvkových tříd. Rozděluje prostor v závislosti na poloze bodů. Kořen stromu reprezentuje celý prostor. Následně je rozdělen do čtyř obecně různě velikých oblastí (obdélníků) v závislosti na souřadnicích x, y prvního bodu, viz obrázek 7.4. Obrázek 7.4: Bodový čtyřstrom 94

95 Plošný čtyřstrom (Region Quadtree) Tato struktura může být využita pro indexování liniových a polygonových prvkových tříd. Nejprve jsou objekty uzavřeny do čtverců, které jsou následně pravidelně děleny na další menší čtverce, dokud není: objekt souvisle pokryt, dosáhnuta předem nastavená hloubka dělení. Obrázek 7.5: Plošný čtyřstrom Porovnání datových struktur Čtyřstrom a R-strom pro indexaci prostorových dat v prostředí Oracle Spatial Společnost Oracle provedla testování vybraných datových struktur určených k indexování prostorových dat. Konkrétně byly v prostředí Oracle Spatial testovány stromové struktury Čtyřstrom (Quadtree) a R strom (R tree). V provedených testech byly použity dvě datové sady první sestávala přibližně z 230 tisíc polygonů (USBG US Blockgroup), druhá obsahovala přes 10 milionů bodů (ABI US Business Area). Vliv úrovně dlaždic na výkon čtyřstromu Pro určení vlivu úrovně dlaždic na výkon čtyřstromu byla vybrána podmnožina z datové sady USBG obsahující přibližně 24 tisíc polygonů. Tabulka

96 Tabulka 7.1: Vzájemná závislost úrovně dlaždic, průměrného počtu dlaždic na jeden objekt a času potřebného pro vytvoření indexu ([KORA]). Úroveň dlaždic Průměrný počet dlaždic Doba vytvoření indexu [s] na geometrii ukazuje závislost v úrovni dlaždic, průměrným počtem dlaždic na jeden objekt a časem potřebným pro vytvoření indexu. Z tabulky je vidět, že se stoupající úrovní dlaždic se zvyšuje průměrný počet dlaždic na jeden objekt; stejně tak se zvyšuje čas potřebný pro vytvoření indexu. Vytvoření a aktualizace prostorových indexů Tabulka 7.2 obsahuje přehled časů potřebných pro vytvoření a aktualizaci jednotlivých indexů. Tabulka 7.2: Porovnání časů potřebných pro vytvoření a aktualizaci jednotlivých indexů [22]. Operace Čtyřstrom R-strom Vytvoření indexu (ABI) 4203 s s Vytvoření indexu (USBG) 8330 s 454 s Vložení bodů (ABI) 67 s 131 s Vložení malých polygonů (USBG) 183 s 330 s Vložení velkých polygonů (USBG) 3600 s 166 s Místo pro uložení (ABI) 909 MB 824 MB Místo pro uložení (USBG) 728 MB 24 MB Z tabulky je patrné, že čtyřstrom bude rychlejší pro bodová data; naopak R-strom bude rychlejší pro liniová a polygonová data. V obou případech ovšem R-strom vyžaduje méně místa pro své uložení. 96

97 Vyhodnocení prostorových dotazů V testech byly uvažovány dva typy dotazů dotazy s dotazovacím oknem (query window) a dotazy na vzdálenost. Dotazy na vzdálenost (nalezení nejbližších sousedů) jsou vždy vyhodnoceny rychleji použitím R-stromu. Tabulka 7.3 obsahuje přehled časů potřebných pro vyhodnocení různých (z pohledu dotazovaného prostorového vztahu query mask) dotazů. Jednotlivé prostorové vztahy jsou znázorněny na obrázku 7.6. Obrázek 7.6: Oracle nine-intersection model Tabulka 7.3: Porovnání průměrných časů (průměr pro různé velikosti dotazovacího okna) pro vyhodnocení dotazů nad daty USBG ([KORA],[ORSG]) Prostorový vztah Čtyřstrom [s] R-strom [s] anyinteract inside contains touch coveredby covers equal overlapbdydisjoint overlapbdyintersect Z porovnání vyplývá, že dotazy s využitím R-stromu byly zodpovězeny vždy rychleji, v některých případech až mnohonásobně. Při použití čtyřstromu uživatel musí nalézt vhodnou maximální úroveň dlaždic, aby bylo použití tohoto indexu maximálně efektivní. Použití R-stromu z tohoto pohledu optimalizaci nepotřebuje a jak z testů vyplynulo, v drtivé většině 97

98 případů poskytuje lepší výkon než čtyřstrom. Indexovat prostorová data uložená v Oracle Spatial pomocí R-stromu je přímo doporučováno v oficiální dokumentaci [ORSG]. 7.3 Datový typ SDO GEOMETRY Oracle Spatial ukládá prostorová data společně s daty atributovými podle objektově relačního datového modelu. Geometrický popis prostorového objektu je uložen pomocí objektového typu SDO GEOMETRY. Jakákoli tabulka, která má sloupec či sloupce typu SDO GEOMETRY, musí mít jiný sloupec, který definuje unikátní primární klíč pro tuto tabulku. Tabulky obsahující alespoň jeden sloupec typu SDO GEOMETRY jsou označovány jako geometrické tabulky (geometry tables). Objektový typ SDO GEOMETRY je v prostředí Spatial definován následujícím způsobem: Ukázka 7.1: Definice datového typu SDO GEOMETRY CREATE TYPE sdo geometry AS OBJECT ( s do g type NUMBER, s d o s r i d NUMBER, s d o p o i n t SDO POINT TYPE, s d o e l e m i n f o MDSYS.SDO ELEM INFO ARRAY, s d o o r d i n a t e s MDSYS.SDO ORDINATE ARRAY ) ; V definici typu SDO GEOMETRY jsou kromě numerického datového typu NUMBER použity rovněž typy SDO POINT TYPE, SDO ELEM INFO ARRAY a SDO ORDINATE ARRAY, které jsou definovány následovně: Ukázka 7.2: Definice datových typů SDO POINT TYPE, SDO ELEM INFO ARRAY a SDO ORDINATE ARRAY CREATE TYPE s d o p o i n t t y p e AS OBJECT ( x NUMBER, y NUMBER, z NUMBER ) ; CREATE TYPE s d o e l e m i n f o a r r a y AS VARRAY ( ) OF NUMBER; CREATE TYPE s d o o r d i n a t e a r r a y AS VARRAY ( ) OF NUMBER; Atribut SDO GTYPE Atribut SDO GTYPE označuje geometrický typ geometrického popisu prvku. Možné geometrické typy korespondují s těmi, které jsou specifikovány v [OGIC]. V prostředí Spatial je přímá shoda mezi pojmenováním a sémantikou typů s typy, uvedenými v [OGIC]. Kód typu prvku sestává ze čtyř číslic. Lze ho psát ve tvaru dltt, kde: 98

99 d identifikuje počet dimenzí (2, 3, nebo 4). l tato hodnota je užitečná při využití lineárního odkazování, což není případ této práce, proto stačí ponechat výchozí hodnotu 0. tt identifikuje geometrický typ (hodnoty 00 až 07 jsou předdefinované, 08 až 99 jsou rezervovány pro uživatelem definované typy). V tabulce 7.4 je uveden přehled předdefinovaných hodnot atributu SDO GTYPE. Tabulka 7.4: Předdefinované hodnoty atributu SDO GTYPE Hodnota Geometrický typ Geometrický popis prvku dl00 UNKNOWN GEOMETRY Spatial ignoruje tento popis prvku. dl01 POINT Obsahuje jeden bod. dl02 dl03 LINE nebo CURVE POLYGON Sestává se z jednoho liniového řetězce, který může obsahovat přímé či obloukové segmenty nebo obojí. (LINE a CURVE jsou v tomto kontextu synonyma.) Obsahuje jeden polygon s nebo bez děr. dl04 COLLECTION Jedná se o heterogenní soubor prvků. dl05 MULTIPOINT Obsahuje jeden nebo více bodů. dl06 dl07 MULTILINE nebo MULTICURVE MULTIPOLYGON Obsahuje jeden nebo více liniových řetězců. Prvek může obsahovat disjunktní polygony (více než jedna vnější hranice). 99

100 Všechna geometrická data v rámci jedné vrstvy musí mít stejný počet dimenzí. Nemůžeme například v jedné vrstvě uchovávat dvojdimenzionální a trojdimenzionální data Atribut SDO SRID Atribut SDO SRID slouží k identifikaci souřadnicového systému, ve kterém je prostorový prvek geometricky popsán. Jestliže je hodnota atributu SDO SRID NULL, znamená to, že s geometrickým popisem prvku není asociován žádný souřadnicový systém. V případě, kdy atribut SDO SRID nenabývá hodnoty NULL, musí obsahovat jednu z hodnot ze sloupce srid z tabulky MDSYS.CS SRS. 2 Všechny geometrické popisy prvků v rámci jednoho sloupce typu SDO GEOMETRY musí mít shodnou hodnotu atributu SDO SRID Atribut SDO POINT Atribut SDO POINT je definován pomocí objektového typu SDO POINT TYPE. Tento typ má atributy x, y, z, všechny typu NUMBER. Jestliže jsou pole SDO ELEM INFO a SDO ORDINATES obojí prázdná (mají hodnotu NULL) a zároveň hodnota atributu SDO POINT není prázdná, považují se hodnoty atributů x a y za souřadnice bodu. V jiném případě je atribut SDO POINT ignorován. Optimálně by se měly souřadnice bodu uložit do atributu SDO POINT; a pokud jsou ve vrstvě pouze body, doporučuje se ukládat souřadnice těchto bodů právě do atributu SDO POINT Atribut SDO ELEM INFO Atribut SDO ELEM INFO popisuje způsob interpretace souřadnic geometrického popisu prvku uložených v atributu SDO ORDINATES. Atribut SDO ELEM INFO lze interpretovat pomocí trojice hodnot následujícím způsobem: SDO STARTING OFFSET indikuje uložení první souřadnice pro daný element uvnitř pole SDO ORDINATES. Hodnoty offsetu začínají číslem 1. První souřadnice pro první element tak bude na pozici SDO GEOMETRY. SDO ORDINATES (1). SDO ETYPE indikuje typ elementu. Detailní popis lze najít v [ORSG]. Vybrané hodnoty: 1 bod 2 Systémová tabulka obsahující přes 900 nadefinovaných souřadnicových systémů. 100

101 1003 nebo 2003 polygon SDO INTERPRETATION v závislosti na hodnotě SDO ETYPE vyjadřuje jednu ze dvou věcí: Pokud je hodnota atributu SDO ETYPE rovna 4, 1005 nebo 2005, pak hodnota SDO INTERPRETATION udává, kolik dalších trojic hodnot je použitých k popisu elementu. Pokud je hodnota SDO ETYPE rovna 1, 2, 1003 nebo 2003, pak SDO INTERPRETATION vymezuje, jak interpretovat pořadí souřadnic elementu. Například může nést informaci o tom, zda je hranice polygonu tvořena sekvencí spojených přímých linií (=1) či kruhových oblouků (=2) Atribut SDO ORDINATES Atribut SDO ORDINATES je definován pomocí pole čísel proměnné délky typu NUMBER. V poli jsou uloženy souřadnice bodů, které vytváří geometrický popis hranice prostorového prvku. Toto pole musí být vždy užito společně s polem SDO ELEM INFO. Hodnoty v poli jsou seřazeny podle dimenze. Například polygon, jehož hranici tvoří čtyři dvojdimenzionální body, je uložen jako množina hodnot {X1, Y1, X2, Y2, X3, Y3, X4, Y4, X1, Y1}. V třídimenzionálním prostoru by byl uložen jako množina hodnot {X1, Y1, Z1, X2, Y2, Z2, X3, Y3, Z3, X4, Y4, Z4, X1, Y1, Z1}. Testovaná verze Oracle Spatial podporuje pouze dvojdimenzionální prostorové objekty. Z tohoho důvodu proces tvorby prostorového indexu, operátory a funkce pracující s objektovým typem SDO GEOMETRY, ignorují hodnotu Z. Hodnoty v poli SDO ORDINATES nesmí mít hodnotu null Metody objektového datového typu SDO GEOMETRY Objektový datový typ SDO GEOMETRY má rovněž metody, které poskytují přístup k některým jeho atributům. Celkem se jedná o tři následující metody: GET DIMS vrací počet dimenzí geometrického popisu prvku (hodnota d z atributu SDO GTYPE). GET GTYPE vrací geometrický typ geometrického popisu prvku (hodnota tt z atributu SDO GTYPE). GET LRS DIM vrací hodnotu l z atributu SDO GTYPE geometrického popisu prvku. 101

102 7.4 Geometry Metadata Views Metadata o prostorovém prvku uchovávají informace o jeho geometrickém popisu týkající se rozsahu možných nabývaných hodnot v každé dimenzi včetně tolerance (odchylky) v dané dimenzi. Jsou uložena v globální tabulce, jejímž vlastníkem je systém. Každý uživatel Oracle Spatial má k dispozici následující pohledy (views): USER SDO GEOM METADATA obsahuje informace o všech prostorových tabulkách vlastněných uživatelem. Z toho vyplývá, že uživatel Spatial do něj musí vkládat metadata týkající se sloupců typu SDO GEOMETRY, které si vytvořil. Toto je jediný pohled, na který má uživatel oprávnění provádět změny (příkaz UPDATE). ALL SDO GEOM METADATA obsahuje metadata o všech prostorových tabulkách. Uživatel k nim může přistupovat pomocí příkazu SELECT. Při vložení nového záznamu do pohledu USER SDO GEOM METADATA Spatial zajišťuje automatickou aktualizaci pohledu ALL SDO GEOM METADATA. Pohled USER SDO GEOM METADATA na metadata má definován následující atributy: ( ); TABLE NAME VARCHAR2 (32), název tabulky COLUMN NAME VARCHAR2 (32), název sloupce DIMINFO SDO DIM ARRAY rozsah v souřadnicových osách, SRID NUMBER identifikátor souřadnicového systému Kromě toho má pohled ALL SDO GEOM METADATA atribut OWNER, identifikující schéma, které vlastní tabulku uvedenou v atributu TABLE NAME Atribut TABLE NAME Atribut TABLE NAME obsahuje název tabulky obsahující sloupec typu SDO GEOMETRY Atribut COLUMN NAME Atribut COLUMN NAME obsahuje název sloupce typu SDO GEOMETRY Atribut DIMINFO Atribut diminfo je typu SDO DIM ARRAY, který je definován následujícím způsobem: 102

103 Ukázka 7.3: Definice typu SDO DIM ARRAY CREATE TYPE SDO DIM ARRAY AS VARRAY( 4 ) OF SDO DIM ELEMENT; Typ SDO DIM ELEMENT je definován jako: Ukázka 7.4: Definice typu SDO DIM ELEMENT CREATE TYPE SDO DIM ELEMENT AS OBJECT ( sdo dimname VARCHAR2( 6 4 ), s d o l b NUMBER, sdo ub NUMBER, s d o t o l e r a n c e NUMBER ) ; Z předchozí definice je vidět, že můžeme mít prvek popsán až ve čtyřech dimenzích. Podle počtu dimenzí pak atribut diminfo obsahuje příslušný počet objektů SDO DIM ELEMENT, z nichž každý musí mít hodnoty atributů SDO LB, SDO UB a SDO TOLERANCE různé od hodnoty NULL. Řazení souřadnic bodů v poli atributu SDO ORDINATES by mělo odpovídat pořadí definic jednotlivých dimenzí v atributu diminfo. Pokud například atribut SDO ORDINATES obsahuje pole {X1, Y1,..., Xn, Yn}, pak jako první musí být definována v poli diminfo dimenze X a jako druhá dimenze Y Atribut SRID Atribut srid obsahuje kód souřadnicového systému, který je spojen s geometrickými popisy prvků ve sloupci SDO GEOMETRY, nebo hodnotu NULL, jestliže s geometrickým popisem prvku není asociován žádný konkrétní souřadnicový systém. 7.5 Topologický koncept okřídlené hrany Spatial umožnuje uložit vektorová prostorová data do topologické datové struktury, tzv. okřídlené hrany. Tento koncept, vztaženo k Oracle Spatial, spočívá v uložení čtyř odkazů pro každou hranu v databázi na přilehlé hrany k dané hraně, společně s uložením odkazů na hranu vlevo a hranu vpravo od hrany. Z toho vyplývá, že v konceptu okřídlené hrany jsou uvažovány orientované hrany. Princip topologického konceptu okřídlené hrany lze vidět na obrázku 7.7. Topologický koncept okřídlené hrany pracuje se základními topologickými primitivy: uzly, hranami, stěnami. 103

104 Obrázek 7.7: Koncept okřídlené hrany Uzel (node), reprezentovaný bodem, může být izolovaný či neizolovaný. V neizolovaném uzlu se schází dvě a více hran, přičemž prostorová lokalizace uzlu je dána jeho souřadnicemi. Hrana (edge) je ohraničena dvěma uzly: počátečním a koncovým. Počáteční a koncový bod určují orientaci hrany. S hranou je spojený řetězec souřadnic, který popisuje prostorovou reprezentaci hrany. Hrana může obsahovat více mezilehlých vrcholů pospojovaných přímými spojnicemi. Kruhové oblouky nejsou v topologickém konceptu povoleny. Stěna (face), reprezentována polygonem, má odkaz na jednu orientovanou hranu, která je součástí vnější hranice. Stěna může obsahovat i tzv. díru (hole). V tom případě stěna obsahuje i odkaz na hranu, která je součástí této díry. Obrázek 7.8 znázorňuje ukázku topologických primitiv. Šipka u každé hrany značí orientaci této hrany. Poznámky k předchozímu obrázku: E elementy (E1, E2,...) jsou hrany, F elementy (F0, F1,...) jsou stěny a N elementy (N1, N2,...) jsou uzly. F0 je tzv. univerzální stěna. F0 je identifikována hodnotou ID = -1. Pro každou bodovou geometrii je vytvořen uzel, stejně tak pro každý počáteční a koncový bod. Například hrana E25 má počáteční bod N21 a koncový bod N22. Izolovaný uzel (island node) je uzel, který je izolovaný uvnitř stěny. Příkladem izolovaného uzlu je například uzel N4 uvnitř stěny F2. V ISKN může být příkladem izolovaného uzlu například definiční bod parcely. 104

105 Obrázek 7.8: Ukázka topologických primitiv Izolovaná hrana (island edge) je hrana, která je izolovaná uvnitř stěny. Příkladem izolované stěny je například hrana E25 uvnitř stěny F1. Smyčka (loop edge) je hrana, která má shodný počáteční a koncový bod. Příkladem smyčky je hrana E1 s počátečním, resp. koncovým bodem N1. Hrana nemůže obsahovat izolovaný bod. Hranu je možné rozdělit na dvě hrany přidáním nového uzlu na tuto hranu. Pokud by například na výše uvedeném obrázku byla původně hrana mezi uzly N16 a N18, přidáním nového uzlu N17 vzniknou hrany E6 a E7. Informace o topologických vztazích mezi jednotlivými topologickými primitivy jsou uloženy ve speciálních tabulkách. Topologický prvek (topology geometry, feature) je prostorová reprezentace objektu reálného světa pomocí topologických primitiv. Tato reprezentace je uložena jako množina topologických primitiv (uzlů, hran, stěn). Každý topologický prvek má svůj unikátní identifikátor. Tento identifikátor přiřazuje přímo Spatial, například při importu dat do databáze. 105

106 Vrstva topologických prvků (topology geometry layer) sestává z množiny topologických prvků. Data pro konkrétní vrstvu jsou uložena v tzv. prvkové tabulce (feature table). Každý topologický prvek (feature) je definován jako objekt typu SDO TOPO GEOMETRY, viz 7.5.6, který obsahuje informaci o geometrickém typu topologického prvku, identifikátor ID tohoto prvku a identifikátor ID celé topologie. Metadata o topologii automaticky spravuje Spatial Tabulky pro uložení topologie Tabulky pro uložení topologických primitiv jsou vytvořeny v okamžiku vytvoření topologie. Jednotlivé topologické prvky (features) jsou uloženy v prvkové tabulce (feature table). Mimo to je zapotřebí tabulka, která umožní propojení prvkové tabulky a tabulek s topologickými primitivy, ze kterých sestává geometrický popis prvku. Princip ukládání dat topologie zobrazuje obrázek 7.9. Obrázek 7.9: Mapování mezi prvkovou tabulkou a tabulkami s topologickými primitivy Každá prvková tabulka obsahuje sloupec typu SDO TOPO GEOMETRY. Tento typ obsahuje atribut TG LAYER ID (unikátní identifikátor přiřazení Spatial při vytvoření vrstvy), stejně jako atribut TG ID (unikátní identifikátor přiřazený každému prvku ve vrstvě). Hodnoty v těchto dvou sloupcích mají odpovídající hodnoty ve sloupcích TG LAYER ID a TG ID v tabulce <topology-name> RELATION$. Každý prvek má jeden nebo více záznamů v tabulce <topology-name> FACE$. Pokud jsou dány hodnoty atributů TG LAYER ID a TG ID pro konkrétní prvek, množina uzlů, hran a stěn asociovaných s daným prvkem je určena pomocí atributu TOPO ID. 106

107 7.5.2 Node information table Informace o uzlech je potřeba uložit do tabulky <topology-name> NODE$, kde <topology-name> je název topologie, jak je určen při vytváření topologie při volání procedury SDO TOPO.CREATE TOPOLOGY. Strukturu každé tabulky <topology-name> EDGE$ ukazuje tabulka 7.6. Tabulka 7.6: Struktura tabulky <topology-name> NODE$ Sloupec Datový typ Popis NODE ID NUMBER Unikátní identifikátor uzlu EDGE ID NUMBER Unikátní identifikátor (se znaménkem) hrany, pokud je nějaká s uzlem asociována FACE ID NUMBER Unikátní identifikátor stěny, pokud je nějaká s uzlem asociována GEOMETRY SDO GEOMETRY Geometrický popis bodu, reprezentujícího uzel Pro každý uzel, EDGE ID nebo FACE ID musí mít vždy hodnotu NULL: EDGE ID je NULL, pokud je uzel izolovaný FACE ID je NULL, pokud uzel není izolovaný, ale jedná se o počáteční či koncový bod hrany. 107

108 7.5.3 Face information table Informace o stěnách je potřeba uložit do tabulky <topology-name> FACE$, kde <topology-name> je název topologie, jak je určen při vytváření topologie při volání procedury SDO TOPO.CREATE TOPOLOGY. Strukturu každé tabulky <topology-name> FACE$ ukazuje tabulka 7.7. Tabulka 7.7: Struktura tabulky <topology-name> FACE$ Sloupec Datový typ Popis FACE ID NUMBER Unikátní identifikátor stěny BOUNDARY EDGE ID NUMBER Unikátní identifikátor (se znaménkem) hrany, která náleží stěně. ISLAND EDGE ID LIST SDO LIST TYPE Unikátní identifikátory izolovaných hran, pokud jsou nějaké v dané stěně ISLAND NODE ID LIST SDO LIST TYPE Unikátní identifikátory izolovaných bodů, pokud jsou nějaké v dané stěně MBR GEOMETRY SDO GEOMETRY Minimální ohraničující obdélník stěny. Atribut je povinný, vyjma univerzální stěny. Nad tímto sloupcem je vytvořen prostorový index Edge information table Potřebné informace o hranách v topologii jsou uloženy v tabulce <topology-name> EDGE$, kde <topology-name> je název topologie, jak je určen při vytváření topologie při volání procedury SDO TOPO.CREATE TOPOLOGY. Strukturu každé tabulky <topology-name> EDGE$ ukazuje tabulka

109 Tabulka 7.8: Struktura tabulky <topology-name> EDGE$ Sloupec Datový typ Popis EDGE ID NUMBER Unikátní identifikátor hrany START NODE ID NUMBER Unikátní identifikátor počátečního bodu hrany END NODE ID NUMBER Unikátní identifikátor koncového bodu hrany NEXT LEFT EDGE ID NUMBER Unikátní identifikátor (se znaménkem) next left hrany PREV LEFT EDGE ID NUMBER Unikátní identifikátor (se znaménkem) previous left hrany NEXT RIGHT EDGE ID NUMBER Unikátní identifikátor (se znaménkem) next right hrany PREV RIGHT EDGE ID NUMBER Unikátní identifikátor (se znaménkem) previous right hrany LEFT FACE ID NUMBER Unikátní identifikátor stěny vlevo od hrany RIGHT FACE ID NUMBER Unikátní identifikátor stěny vpravo od hrany GEOMETRY SDO GEOMETRY Geometrický popis hrany Hodnoty atributů NEXT LEFT EDGE ID a NEXT RIGHT EDGE ID odkazují na hrany, na které narazíme při pohybu v protisměru chodu hodinových ručiček podél obvodu stěny vlevo, respektive vpravo. Hodnoty atributů PREV LEFT EDGE ID a PREV RIGHT EDGE ID odkazují na hrany, na které narazíme při pohybu po směru chodu hodinových ručiček podél obvodu stěny vlevo, respektivo vpravo. Hodnota atributu LEFT FACE ID odkazuje na stěnu vlevo od orientované hrany, hodnota atributu RIGHT FACE ID odkazuje na stěnu vpravo od orientované hrany. Znaménko před hodnotou libovolného z výše uve- 109

110 dených identifikátorů určuje vzájemnou orientaci odkazovaných prvků. Obrázek 7.10 ilustruje vztahy mezi identifikátory uloženými v tabulce <topology-name> EDGE$. Obrázek 7.10: Ukázka uzlů, hran a stěn Tabulka 7.9 ukazuje hodnoty jednotlivých identifikátorů pro hrany E4 a E8 z obrázku Tabulka 7.9: Ukázka vzájemné provázanosti identifikátorů v tabulce <topology-name> EDGE$ NEXT PREV NEXT PREV START END LEFT LEFT RIGHT RIGHT LEFT RIGHT EDGE NODE NODE EDGE EDGE EDGE EDGE FACE FACE ID ID ID ID ID ID ID ID ID E4 N1 N2 -E5 E3 E2 -E6 F1 F2 E8 N4 N3 -E8 -E8 E8 E8 F2 F Relation information table Pokud pracujeme s topologicky strukturovanými prvky, Spatial automaticky udržuje informace o každém prvku v tabulce <topology-name> RELATION$, kde <topology-name> je název topologie. Je zde právě jedna tabulka pro každou topologii. Každý řádek v tabulce jednoznačně určuje topologicky strukturovaný prvek s ohledem na jeho topologickou vrstvu a topologii. Strukturu každé tabulky <topology-name> RELATION$ ukazuje tabulka

111 Tabulka 7.10: Struktura tabulky <topology-name> RELATION$ Sloupec Datový typ Popis TG LAYER ID NUMBER Unikátní identifikátor topologické vrstvy, do které topologicky strukturovaný prvek náleží TG ID NUMBER Unikátní identifátor topologicky strukturovaného prvku TOPO ID NUMBER Pro topologii, ve které není hierarchie vrstev: unikátní identifikátor topologického primitiva v topologickém popisu prvku. Pokud má topologie hierarchii vrstev, vloží hodnotu Oracle Spatial TOPO TYPE NUMBER Pro topologii, ve které není hierarchie vrstev: 1 = uzel 2 = hrana 3 = stěna Pokud má topologie hierarchii vrstev, vloží hodnotu Oracle Spatial TOPO ATTRIBUTE VARCHAR2 Hodnotu vloží Oracle Spatial Datový typ SDO TOPO GEOMETRY Hlavním datovým typem asociovaným s topologickým datovým modelem je datový typ SDO TOPO GEOMETRY. Objektový typ SDO TOPO GEOMETRY je definován takto: Ukázka 7.5: Definice datového typu SDO TOPO GEOMETRY CREATE TYPE sdo topo geometry AS OBJECT ( t g t y p e NUMBER, t g i d NUMBER, t g l a y e r i d NUMBER, t o p o l o g y i d NUMBER ) ; 111

112 Datový typ SDO TOPO GEOMETRY má atributy, které jsou popsány v tabulce Tabulka 7.11: Atributy datového typu SDO TOPO GEOMETRY Atribut TG TYPE TG ID TG LAYER ID TOPOLOGY ID Popis Typ geometrie topologického prvku: 1 = bod nebo multibod, 2 = (multi)liniový řetězec, 3 = polygon nebo multipolygon 4 = heterogenní kolekce Unikátní identifikátor (vygeneruje Spatial) pro geometrii topologického prvku Unikátní identifikátor topologické vrstvy, do které topologický prvek náleží; hodnotu identifikátoru generuje Oracle Spatial a je unikátní v rámci topologické vrstvy Unikátní identifikátor (vygeneruje Spatial) pro topologický prvek Každá geometrie topologického prvku (de facto konkrétní topologické primitivum) je v rámci topologie jednoznačně identifikováno kombinací hodnot atributů TG ID a TG LAYER ID. Datový typ SDO TOPO GEOMETRY má konstruktory pro vkládání a aktualizaci topologicky modelovaných objektů. Konstruktory, které se váží k datovému typu SDO TOPO GEOMETRY lze rozdělit na dva typy, podle toho, jaké typy objektů používají: Konstruktory, které určují topologické elementy (uzly, hrany a stěny) na nejnižší úrovni hierarchie (viz kapitola 7.5.9). Tyto konstruktory mají alespoň jeden atribut typu SDO TOPO OBJECT ARRAY a žádný atribut typu SDO TGL OBJECT ARRAY. Konstruktory, které specifikují elementy ve vrstvách potomka. Tyto konstruktory mají alespoň jeden atribut typu SDO TGL OBJECT ARRAY a žádný atribut typu SDO TOPO OBJECT ARRAY. K vložení a aktualizaci topologicky strukturovaných objektů v topologii, ve které není zavedena hierarchie vrstev, nebo pokud daná operace ovlivňuje nejnižší úroveň (úroveň 0) hierarchie, musíme použít konstruktory, které určují topologické elementy na nejnižší úrovni (uzly, hrany a stěny). 112

113 Při implementaci programu DKM2Spatial.jar (viz kapitola 7.6) jsem použil konstruktor, který určuje topologické elementy na nejnižší úrovni. Je to z důvodu, že jsem modeloval pouze parcely a definiční body parcel. Vybudování hierarchie v rámci zvolené topologie a použiti dalších konstruktorů je jedním z možných rozšíření programu DKM2Spatial.jar. V kapitole je popsán konstruktor na vkládání topologicky strukturovaných objektů na nejnižší úrovni, použitý v programu DKM2Spatial.jar Konstruktor pro operaci vkládání specifikující topologické elementy Datový typ SDO TOPO GEOMETRY má dva konstruktory pro operaci vložení, ve kterých specifikujeme jednotlivé topologické elementy (uzly, hrany, stěny). Jeden z těchto konstruktorů musíme použít při vytvoření nových topologicky strukturovaných objektů, pokud nemá topologie vybudovánu hierarchii vrstev. Ukázka 7.6: Definice konstruktoru SDO TOPO GEOMETRY SDO TOPO GEOMETRY ( topology VARCHAR2, t g t y p e NUMBER, t g l a y e r i d NUMBER, t o p o i d s SDO TOPO OBJECT ARRAY ) V programu DKM2Spatial.jar je použit tento konstruktor pro vytvoření topologicky strukturovaných popisů parcel a definičních bodů pomocí jednotlivých topologických primitiv. Druhý konstruktor z této kategorie má následující definici: Ukázka 7.7: Definice konstruktoru SDO TOPO GEOMETRY SDO TOPO GEOMETRY ( topology VARCHAR2, table name VARCHAR2, column name VARCHAR2, t g t y p e NUMBER, t o p o i d s SDO TOPO OBJECT ARRAY ) Pro úplnost uveďme definici datového typu SDO TOPO OBJECT ARRAY: Ukázka 7.8: Definice datového typu SDO TOPO OBJECT ARRAY CREATE TYPE SDO TOPO OBJECT ARRAY AS VARRAY OF SDO TOPO OBJECTS; Typ SDO TOPO OBJECTS má atributy: (topo id NUMBER, topo type NUMBER) 113

114 Hodnoty atributů TG TYPE a TOPO IDS musí mít pro danou topologii odpovídající hodnoty v tabulce <topology-name> RELATION$ (tabulka je popsána v kapitole 7.5.5) Metoda GET GEOMETRY Datový typ SDO TOPO GEOMETRY má metodu GET GEOMETRY. Tato metoda pro konkrétní topologicky strukturovaný prvek vrací geometrický popis tohoto prvku modelovaného pomocí objektového datového typu SDO GEOMETRY. Příklad použití této metody lze nalézt v kapitole Hierarchie vrstev geometrických popisů topologických prvků V některých topologiích mají jednotlivé vrstvy mezi sebou hierarchickou závislost. To znamená, že vrstva na nejvyšší úrovni hierarchie sestává z prvků nacházejících se na nižší úrovni hierarchie. Tato vrstva na nižší úrovni hierarchie může dále sestávat z prvků nacházejících se ve vrstvě, která je v rámci hierarchie ještě o další stupeň níže. Názorně si lze takovou hierarchii vrstev představit na příkladu zjednodušeného administrativního členění ČR. Stát ČR na nejvyšší úrovni hierarchie. Sestává se z krajů. Kraje ČR na druhé úrovni hierarchie. Sestávají se z okresů. Okresy ČR na další nižší úrovni hierarchie. Sestávají se z obcí, případně z katastrálních území. 3 Katastrální území na předposlední úrovni hierarchie zjednodušeného administrativního členění ČR. Sestávají se z hranic parcel. Parcely na nejnižší (nejpodrobnější) úrovni celé hierarchie. Hierarchie jednotlivých vrstev zjednodušeného administrativního členění ČR je zachycena na obrázku Pokud mají jednotlivé vrstvy v topologii mezi sebou takovéto hierarchické vazby, je při modelování jednotlivých vrstev efektivnější tuto hierarchickou vazebnost využít, než specifikovat každou vrstvu jednotlivě. Je například efektivnější specifikovat pouze jednotlivé okresy, ze kterých se skládá daný kraj, než určit všechny parcely pro všechna katastrální území ve všech okresech, ze kterých se skládá daný kraj. Nejnižší úroveň v hierarchii vrstev, obsahující největší množství detailu, má označení Úroveň 0. Vyšší úrovně v hierarchii jsou pak očíslovány 1, 2,... Vrstvy, 3 Hranice obcí nejsou v ČR obecně identické s hranicemi katastrálních území. 114

115 Obrázek 7.11: Hierachire vrstev zjednodušeného administrativního členění ČR které jsou v rámci hierarchie sousední, mají vztah rodič potomek. Vrstva na vyšší úrovni hierarchie je tzv. rodičovská vrstva pro právě jednu vrstvu na bezprostředně nižší úrovni hierarchie, tzv. vrstva potomka. Vrstva potomka může mít vazbu na více rodičovských vrstev. Konkrétní ukázku zdrojového kódu pro realizaci jednoduché hierarchie vrstev lze nalézt v [ORSG]. 7.6 Program DKM2Spatial.jar V kapitole 3 byl popsán (přibližný) způsob, jakým jsou prostorová data, konkrétně digitální katastrální mapa, uložena v ISKN. Vzhledem k faktu, že ISKN je vybudován nad databázovým systémem Oracle a využívá, i když ne příliš, k uložení některých dat nadstavbu Spatial, je užitečné a zajímavé zkoumat, jak by se nechalo této nadstavby pro uložení DKM využít více. V programovacím jazyce Java jsem vytvořil program DKM2Spatial.jar, který umožňuje přechod ze současného způsobu uložení vybraných dat digitální katastrální mapy do vybraných struktur Oracle Spatial pro uložení vektorových dat. Program DKM2Spatial.jar převádí do struktur Spatial hranice parcel a definiční body parcel. Konkrétně se jedná o objektově-relační strukturu (využití datového typu SDO GEOMETRY), viz kapitola 7.3 a topologickou datovou strukturu okřídlené hrany (využití datového typu SDO TOPO GEOMETRY, jak již bylo 115

116 zmíněno v [JACA]), viz kapitola 7.5. V této práci jsem převedl data v rozsahu jednoho vybraného katastrálního území. Výběr katastrálního území byl proveden tak, aby data byla topologicky čistá, což je nutný předpoklad pro správný běh programu. Po vyčištění prostorových dat katastru nemovitostí by neměl být problém převést pomocí programu DKM2Spatial.jar i ostatní katastrální území. Na druhou stranu, to že pro otestování programu bylo vybráno jedno katastrální území neznamená, že by pouze toto katastrální území splňovalo podmínky na topologicky čistá data. Cílem vytvoření programu bylo především pochopení specifik přechodu ze současného způsobu uložení prostorových dat katastru nemovitostí do struktur Oracle Spatial se zohledněním specifik současného uložení. Program DKM2Spatial.jar se spouští z příkazové řádky. Má jeden vstupní parametr. Hodnotou vstupního parametru určíme, zda se mají data katastru nemovitostí převést do objektově-relačního modelu dat, nebo do topologického modelu, případně do obou. Vstupní data jsou pro současnou verzi načtena z textového souboru (tento soubor je výsledkem SQL dotazu, který je součástí přílohy D.1). Ve vstupních datech jsou následující údaje (pořadí výčtu atributů v seznamu odpovídá jejich pořadí ve vstupním textovém souboru): kód katastrálního území druh číslování parcel identifikátor parcely druh pozemku kmenové číslo parcely poddělení čísla parcely identifikátor hraničního úseku typ prvku prostorových dat pořadové číslo bodu polohopisu v rámci geometrického popisu prostorového prvku identifikátor bodu polohopisu x souřadnice bodu polohopisu y souřadnice bodu polohopisu identifikátor definičního bodu parcely x souřadnice definičního bodu parcely 116

117 y souřadnice definičního bodu parcely Data jsou ve vstupním souboru seřazena (vzestupně) podle kódu katastrálního území, identifikátoru parcely a pořadového čísla bodu polohopisu. Odkaz na soubor se vstupními daty je uveden přímo ve zdrojovém kódu programu. Z důvodu, že v budoucnosti, pokud bude program využíván, dojde zřejmě k tomu, že data budou načítána přímo z databáze, není soubor se vstupními daty vstupním parametrem, odkaz na něj je přímo ve zdrojovém kódu programu, což je pro účely testování dostačující. Program se spouští z příkazové řádky následujícím způsobem: java -jar DKM2Spatial.jar -data model kde: -data model - volba, do jakého modelu chceme data převést -g objektově-relační datový model -t topologický datový model -a budou vygenerovány skripty pro oba modely Výsledkem běhu programu jsou skripty pro načtení dat do tabulek, které jsou součástí zvoleného uložení dat pomocí nadstavby Spatial. V následujících kapitolách bude popsán princip převodu vybraných prostorových dat katastru nemovitostí do vybrané datové struktury. Pro oba postupy platí, že výběr vstupních dat z databáze ISKN je identický. 7.7 Převod vybraných dat katastru nemovitostí do objektově-relačního datového modelu Pokud chceme pomocí programu DKM2Spatial.jar generovat skripty pro vložení dat do objektově-relačního modelu, spustíme program následujícím způsobem: java -jar DKM2Spatial.jar -g Výstupem jsou následující soubory: parcely.sql soubor sestávající z SQL příkazů INSERT, vkládajících do databáze geometrické popisy parcel a vybrané atributy o parcele def-body.sql soubor sestávající z SQL příkazů INSERT, vkládajících do databáze geometrické popisy definičních bodů parcel společně s jejich identifikátory 117

118 Ukázka souboru parcely.sql příkaz INSERT pro vložení parcely, jejíž geometrický popis bude uložen pomocí objektového datového typu SDO GEOMETRY: Ukázka 7.9: Ukázka souboru parcely.sql INSERT INTO PARCELY VALUES( , , 6, 3, 13, , 2, MDSYS.SDO GEOMETRY( 2003, NULL, NULL, SDO ELEM INFO ARRAY( 1, , 1 ), SDO ORDINATE ARRAY( , , , , , , , ) ) ) ; Vysvětlení jednotlivých popisných hodnot z předešlé ukázky: identifikátor parcely identifikátor definičního bodu 6 kmenové číslo parcely 3 poddělení čísla parcely 13 kód druhu pozemku ti místný kód katastrálního území 2 druh číslování parcel Vysvětlení naplnění atributu SDO GEOMETRY z předešlé ukázky: 2003 polygon ve 2D NULL Spatial ve verzi 10g Release 2 nepodporuje systém S- JTSK NULL bylo by vyplněné, pokud bychom ukládali geometrický popis reprezentující bodový prvek (1,1003,1) ukládáme pouze jeden geometrický popis, jeho první souřadnice v poli SDO ORDINATE ARRAY je uložena na první pozic; spojnice mezi body jsou přímé úsečky 118

119 SDO ORDINATE ARRAY tento atribut obsahuje souřadnice geometrického popisu parcely; první pár souřadnic musí být shodný s posledním párem souřadnic, aby byl splněn požadavek na validnost geometrického popisu Spolu s daty o parcelách se do databáze ukládají informace o definičních bodech. Ukázka souboru def-body.sql - příkaz INSERT pro vložení definičního bodu, jehož geometrický popis bude uložen pomocí objektového datového typu SDO GEOMETRY: INSERT INTO AK DEF BODY VALUES( , MDSYS.SDO GEOMETRY( 2001, NULL, ( , ,NULL), NULL, NULL ) ) ; Ukázka 7.10: Ukázka souboru def-body.sql Vysvětlení jednotlivých popisných hodnot z předešlé ukázky: identifikátor parcely Vysvětlení naplnění atributu SDO GEOMETRY z předešlé ukázky: 2001 bod ve 2D NULL Spatial ve verzi 10g Release 2 nepodporuje systém S- JTSK ( , ,NULL) - souřadnice geometrického popisu NULL ukládáme bod, hodnota je tedy NULL NULL ukládáme bod, hodnota je tedy NULL V případě, že ukládáme geometrický popis bodu, mají se podle dokumentace k Oracle Spatial ukládat souřadnice bodu do atributu SDO POINT TYPE. V programu DKM2Spatial.jar je toto doporučení z oficiální dokumentace uvažováno. To je rozdíl oproti ISKN, kde jsou souřadnice geometrického popisu bodových prvků uloženy v poli SDO ORDINATE ARRAY. 119

120 7.8 Převod vybraných dat katastru nemovitostí do topologického datového modelu Pokud chceme pomocí programu DKM2Spatial.jar generovat skripty pro vložení dat do topologického datového modelu, spustíme program následujícím způsobem: java -jar DKM2Spatial.jar -t Výstupem jsou následující soubory: uzly.sql soubor sestávající z SQL příkazů INSERT, vkládajících do databáze údaje o uzlech hrany.sql soubor sestávající z SQL příkazů INSERT, vkládajících do databáze údaje o hranách steny.sql soubor sestávající z SQL příkazů INSERT, vkládajících do databáze údaje o stěnách topo ak parcely.sql - soubor sestávající z SQL příkazů INSERT, vkládajících do databáze údaje o parcelách do feature table Soubory uzly.sql, hrany.sql a steny.sql obsahují INSERT příkazy pro vložení příslušných topologických primitiv, ze kterých sestávají topologické popisy vybraných prostorových prvků konkrétně hranic parcel a definičních bodů. Postupně budou uvedeny ukázky obsahu jednotlivých souborů. Ukázka souboru steny.sql: Ukázka 7.11: Ukázka souboru steny.sql INSERT INTO k a t a s t r f a c e $ VALUES( , , SDO LIST TYPE ( ), SDO LIST TYPE( ), SDO GEOMETRY( 2003, NULL, NULL, SDO ELEM INFO ARRAY( 1, , 3 ), SDO ORDINATE ARRAY( , , , ) ) ) ; Vysvětlení naplnění atributů z předešlé ukázky: identifikátor stěny odkaz na hranu, která je součástí hranice stěny 120

121 SDO LIST TYPE() pole s identifikátory izolovaných hran; v tomto případě stěna neobsahuje žádnou izolovanou hranu SDO LIST TYPE( ) pole s identifikátory izolovaných uzlů; v tomto případě stěna obsahuje právě jeden izolovaný bod - definiční bod parcely SDO GEOMETRY(2003,...) geometrický popis minimálního ohraničujícího obdélníku stěny; popis je zadán dvěma body - levým dolním a pravým horním bodem, viz naplnění atributu SDO ELEM INFO ARRAY (=(1,1003,3)) Ukázka souboru hrany.sql: Ukázka 7.12: Ukázka souboru hrany.sql INSERT INTO k a t a s t r e d g e $ VALUES( , , , , , , , , , SDO GEOMETRY( 2002, NULL, NULL, SDO ELEM INFO ARRAY( 1, 2, 1 ), SDO ORDINATE ARRAY( , , , ) ) ) ; Vysvětlení naplnění atributů z předešlé ukázky: identifikátor hrany odkaz na počáteční bod hrany odkaz na koncový bod hrany odkaz na next left hranu odkaz na previous left hranu odkaz na next right hranu odkaz na previous right hranu odkaz na stěnu vlevo odkaz na stěnu vpravo 121

122 SDO GEOMETRY(2002,...) geometrický popis ukládané linie Ukázka souboru uzly.sql: Ukázka 7.13: Ukázka souboru node.sql INSERT INTO k a t a s t r n o d e $ VALUES( , , NULL, SDO GEOMETRY( 2001, NULL, SDO POINT TYPE( , ,NULL), NULL, NULL) ) ; Vysvětlení naplnění atributů z předešlé ukázky: identifikátor uzlu odkaz na hranu, které bod náleží NULL odkaz na stěnu, které bod náleží; v případě, že se jedná o isolated node, je uveden konrétní identifikátor stěny. Toto je případ definičního bodu. SDO GEOMETRY(2001,...) geometrický popis ukládaného bodu Ukázka souboru topo ak parcely.sql: Ukázka 7.14: Ukázka souboru topo ak parcely.sql INSERT INTO t o p o a k p a r c e l y VALUES ( , 1, 0, 13, , 2, SDO TOPO GEOMETRY ( KATASTR, 3, 1, SDO TOPO OBJECT ARRAY ( SDO TOPO OBJECT ( , 3) ) ) ) ; Vysvětlení naplnění atributů z předešlé ukázky: identifikátor prkvu (feature), který odpovídá konkrétní parcele s tímto identifikátorem 1 kmenové číslo parcely 122

123 0 poddělení (v případě, že parcelní číslo nemá poddělení, je do databáze namísto hodnoty NULL uložena hodnota 0) 13 kód druhu pozemku kód katastrálního území 2 druh číslování parcel NULL odkaz na stěnu, které bod náleží; v případě, že se jedná o isolated node, je uveden konrétní identifikátor stěny. Toto je případ definičního bodu. SDO TOPO GEOMETRY: KATASTR název topologie 3 geometrický typ topologického primitiva polygon 1 hodnota atributu TG LAYER ID z tabulky ALL SDO TOPO METADATA SDO TOPO OBJECT ARRAY (SDO TOPO OBJECT ( ,3)) odkaz na topologické primitivum, které je součástí topologického popisu tohoto feature ( ) a určení typu primitiva (3 = stěna) Ukázka souboru topo def body.sql: Ukázka 7.15: Ukázka souboru topo def body.sql INSERT INTO k a t a s t r d e f b o d y VALUES ( , SDO TOPO GEOMETRY ( KATASTR, 1, 1, SDO TOPO OBJECT ARRAY ( SDO TOPO OBJECT ( , 1 ) ) ) ) ; Vysvětlení naplnění atributů z předešlé ukázky: identifikátor prkvu (feature), který odpovídá konkrétnímu definičnímu bodu s tímto identifikátorem SDO TOPO GEOMETRY: KATASTR název topologie 1 geometrický typ topologického primitiva - bod 123

124 1 hodnota atributu TG LAYER ID z tabulky ALL SDO TOPO METADATA SDO TOPO OBJECT ARRAY (SDO TOPO OBJECT ( ,1)) odkaz na topologické primitivum, které je součástí topologického popisu tohoto feature ( ) a určení typu primitiva (1 = uzel) 7.9 Vytvoření objektově-relačního modelu vybraných prostorových dat katastru nemovitostí Pokud máme k dispozici data (v mém případě v souborech) ve struktuře popsané v 7.7), můžeme z nich pomocí následující sekvence kroků vytvořit v databázi Oracle objektově -orientovaný model prostorových dat s využitím nadstavby Spatial. Sekvence kroků pro vytvoření objektově-relačního modelu prostorových dat s využitím nadstavby Spatial: Vytvoření tabulek obsahující sloupec datového typu SDO GEOMETRY. Načtení dat do tabulek, včetně sloupce datového typu SDO GEOMETRY. Aktualizace metadat o sloupcích datového typu SDO GEOMETRY. Vytvoření prostorových indexů nad sloupci typu SDO GEOMETRY. Kontrola načtených dat. V následujících kapitolách budou popsány jednotlivé kroky pro vytvoření objektově -relačního modelu vybraných prostorových dat katastru nemovitostí Vytvoření tabulek obsahující sloupec typu SDO GEOMETRY Na obrázcích 7.12 a 7.13 je zachyceno vytvoření prvkových tabulek AK PARCELY, respektive AK DEF BODY Načtení dat do tabulek Data v souborech parcely.sql a def body.sql (viz kapitola 7.7) byla v SQL Developer načtena do tabulek AK PARCELY a AK DEF BODY. Doba nahrání dat do tabulek byla následující: AK PARCELY doba vkládání: vteřiny 124

125 Obrázek 7.12: Vytvoření tabulky AK PARCELY obsahující sloupec datového typu SDO GEOMETRY Obrázek 7.13: Vytvoření tabulky AK DEF BODY obsahující sloupec datového typu SDO GEOMETRY 125

126 AK DEF BODY doba vkládání: vteřiny Celkem se do tabulky AK PARCELY i AK DEF BODY vložilo 1050 záznamů Aktualizace metadat o sloupcích typu SDO GEOMETRY Pro možnost data uložená pomocí objektového datového typu SDO GEOMETRY vizualizovat a především s nimi pracovat pomocí standardních funkcí Oracle Spatial, je nutné aktulizovat metadata, konkrétně pohled USER SDO GEOM METADATA. Obrázek 7.14 zobrazuje vložení metadat pro tabulku AK PARCELY a AK DEF BODY. Obrázek 7.14: Aktualizace metadat o sloupcích datového typu SDO GEOMETRY 126

127 7.9.4 Vytvoření prostorových indexů Vytvoření prostorového indexu je nezbytné pro efektivní vyhodnocení prostorových dotazů. Obrázek 7.15 zobrazuje vytvoření prostorového indexu nad sloupcem GEOMETRIE (datového typu SDO GEOMETRY). Obrázek 7.15: Vytvoření prostorových indexů nad sloupci typu SDO GEOMETRY Kontrola a vizualizace načtených dat Po vygenerování dat v příslušné struktuře a jejich nahrání do databázových tabulek byla data úspěšně vizualizována pomocí rozšíření GeoRaptor Spatial View, viz Při pohledové revizi kresby se data jevila jako topologicky čistá. Pro přesnou kontrolu jsem využil možnosti rozšíření GeoRaptor Spatial View, které umožňuje provést test validity prostorových dat uložených pomocí objektového datového typu SDO GEOMETRY. Úspěšný výsledek provedeného testu je znázorněn na obrázku Data byla tedy programem DKM2Spatial.jar vygenerována správně. Na obrázku 7.17 zachycena vizualizace katastrálních dat uložených v tabulkách AK PARCELY a AK DEF BODY Vytvoření topologie z topologicky strukturovaných dat Pokud máme k dispozici topologicky strukturovaná data (v našem případě data obsažená v souborech popsaných v 7.8), můžeme z nich pomocí následující sekvence kroků vytvořit topologii v databázi. 127

128 Obrázek 7.16: Kontrola validnosti geometrie Obrázek 7.17: Zobrazení parcel a definičních bodů uložených pomocí objektověrelačního modelu 128

129 Sekvence kroků pro vytvoření topologie v databázi z topologicky strukturovaných dat: Vytvoření topologie. Načtení topologických dat do tabulek. Vytvoření prvkových tabulek feature tables. Asociace prvkových tabulek s topologií. Inicializace topologických metadat. Načtení dat do prvkových tabulek pomocí konstruktoru typu SDO TOPO GEOMETRY. Kontrola topologie. V následujících kapitolách budou popsány podrobněji jednotlivé kroky pro vytvoření topologie v databázi z topologicky strukturovaných dat Vytvoření topologie Pro vytvoření topologie je v Oracle Spatial k dispozici procedura CREATE TOPOLOGY z balíku SDO TOPO. Pro testovací účely byla vytvořena topologie KATASTR. Topologii vytvoříme následujícím příkazem (viz také obrázek 7.18): EXECUTE sdo topo.create topology( KATASTR,10); Obrázek 7.18: Vytvoření topologie Hodnota 10 v předešlé ukázce znamená tzv. tolerance value. Jedná se o vzdálenost, od které jsou dva body považovány za rozdílné. Více v kapitole

130 Hodnota je v tomto případě v milimetrech. Nastavení hodnoty tolerance value souvisí s tím, jakým způsobem jsou souřadnice uloženy v ISKN. Tady jsou uloženy na milimetry, i když jejich přesnost je centimetrová. Jedná se čistě o technickou záležitost uložení číselné informace, při práci se souřadnicemi jsou souřadnice uvažovány v centimetrech. Procedura CREATE TOPOLOGY vytvoří tabulky (viz 7.5.1) pro uložení topologických primitiv Načtení topologických dat do tabulek V kapitole 7.8 byly popsány vygenerované soubory programem DKM2Spatial.jar obsahující informace pro vložení topologických primitiv. V tomto bodě je obsah těchto souborů načten do tabulek (v tomto pořadí, viz [ORST]): katastr edge$ doba vkládání: vteřiny katastr node$ doba vkládání: vteřiny katastr face$ doba vkládání: vteřiny Ještě před načtením dat do výše uvedených tabulek se do tabulky katastr face$ vloží univerzální stěna (universal face). Tato stěna má identifikátor -1. Odkazují se na ní hrany, které neleží uvnitř zpracovávaného území. Universal face se vloží následujícím způsobem: INSERT INTO k a t a s t r e f a c e $ VALUES ( 1, NULL, SDO LIST TYPE ( ), SDO LIST TYPE ( ), NULL ) ; Ukázka 7.16: Vložení universal face Vytvoření prvkových tabulek Pro uložení atributových dat o parcelách je vytvořena prvková tabulka katastr ak parcely. Vytvoření této prvkové tabulky je zachyceno na obrázku 7.19: Kromě prvkové tabulky pro uložení atributových dat o parcelách jsem vytvořil prvkovou tabulku pro definiční body. Vytvoření prvkové tabulky pro definiční body je zachyceno na obrázku Prvková tabulka katastr def body obsahuje identifikátor definičního bodu a spojení na odpovídající topologické primitivum konkrétní záznam v tabulce katastr node$. 130

131 Obrázek 7.19: Vytvoření prvkové tabulky KATASTR AK PARCELY Obrázek 7.20: Vytvoření prvkové tabulky KATASTR DEF BODY 131

132 Asociace prvkových tabulek s topologií V tomto okamžiku již máme vytvořenou topologii (s názvem KATASTR). Nyní do ní přidáme dvě topologické vrstvy (pro každou prvkovou tabulku jednu). Vložení topologické vrstvy do topologie provedeme pomocí procedury ADD TOPO GEOMETRY LAYER z balíku SDO TOPO. Vložení topologických vrstev do topologie KATASTR je zachyceno na obrázku Obrázek 7.21: Asociace prvkových tabulek s topologií Načtení dat do prvkových tabulek proběhlo pomocí SQL klienta SQL Developer. Výsledkem tohoto kroku je, že Spatial vygeneruje unikátní hodnotu identifikátoru TG LAYER ID pro každou topologickou vrstvu. Vygenerovaná hodnota je uložena v metadatech o topologii (pohledy USER SDO TOPO METADATA a ALL SDO TOPO METADATA) Inicializace topologických metadat Inicializaci topologických metadat provedeme pomocí procedury INITIALIZE METADATA z balíku SDO TOPO, viz obrázek Načtení dat do prvkových tabulek pomocí konstruktoru typu SDO TOPO GEOMETRY Každý topologický prvek může sestávat z jednoho nebo více topologických primitiv příslušného geometrického typu. Například parcela sestává z jedné stěny, stěna sestává z hran a hrana má počáteční a koncový bod. Prvkové tabulky tak většinou obsahují méně záznamů, než tabulky pro uložení topologických primitiv. Načtení dat do prvkových tabulek proběhlo v SQL klientu SQL Developer. 132

133 Obrázek 7.22: Inicializace topologických metadat Kontrola topologie Po načtení dat do všech tabulek, které jsou pro uložení topologicky strukturovaných dat potřeba, aplikujeme na tato data metodu GET GEOMETRY, která představuje metodu datového typu SDO TOPO GEOMETRY. Je to z důvodu, abychom si mohli topologicky strukturovaná data prohlédnout. Metoda GET GEOMETRY vrátí geometrický popis prvku vyjádřeného pomocí topologických primitiv. Tento popis bude vrácen pomocí datového typu SDO GEOMETRY (viz 7.3) a uložen do sloupce GEOMETRIE, o který rozšíříme prvkovou tabulku KATASTR AK PARCELY. Pokud by geometrický popis prvku pomocí metody GET GEOMETRY nebyl vrácen, znamená to, že uložení prvků vyjádřených pomocí topologických primitiv neproběhlo v pořádku. Pokud bude geometrický popis vrácen a uložen, víme, že naše topologická data jsou validní (v souladu s dokumentací Spatial) a zároveň si je pomocí rozšíření programu SQL Developer budeme schopni vizualizovat. Rozšíření tabulky KATASTR AK PARCELY o sloupec GEOMETRIE Rozšíření tabulky KATASTR AK PARCELY o sloupec GEOMETRIE provedeme (v SQL klientu SQL Developer) pomocí SQL DML příkazu ALTER, jak zachycuje obrázek 7.23 Obrázek 7.23: Rozšíření tabulky KATASTR AK PARCELY o sloupec geometrie Naplnění sloupce GEOMETRIE proběhne s využitím metody GET GEOMETRY 133

134 a SQL DML příkazu ALTER, viz obrázek Obrázek 7.24: Naplnění sloupce GEOMETRIE v tabulce KA- TASTR AK PARCELY Po naplnění sloupce GEOMETRIE je pro zobrazení dat nutné aktualizovat metadata. Aktualizace metadat o sloupci GEOMETRIE v tabulce KATASTR AK PARCELY je zachycena na obrázku Obrázek 7.25: Aktualice metadat o sloupci GEOMETRIE Posledním krokem pro možnost vizualizace dat je vytvoření prostorového indexu nad sloupcem GEOMETRIE, viz obrázek Obrázek 7.26: Vytvoření prostorového indexu nad sloupcem geometrie Nyní už si můžeme pomocí nadstavby GeoRaptor programu SQL Developer prohlédnout topologicky strukturovaná data převedená do uložení pomocí datového typu SDO GEOMETRY. Na obrázku 7.27 je zobrazeno celé testované katastrální území. 134

135 Obrázek 7.27: Zobrazení katastrálního území uloženého pomocí okřídlené hrany Analogicky bychom postupovali, pokud bychom chtěli vizualizovat definiční body, uložené v tabulce KATASTR DEF BODY. Na obrázku 7.28 je zobrazena část testovaného katastrální území včetně definičních bodů. Že jsou správně vygenerována programem DKM2Spatial.jar i topologická data, potvrdilo úspěšné použití metody GET GEOMETRY při plnění sloupce GEO- METRIE v tabulce KATASTR AK PARCELY a KATASTR DEF BODY. Na obrázku 7.29 je zobrazen obsah datového typu SDO GEOMETRY pro vybranou parcelu. Je porovnán obsah pro parcelu uloženou v tabulce AK PARCELY a pro shodnou parcelu uloženou v tabulce KATASTR AK PARCELY. Je patrné, že geometrický popis vybrané parcely vygenerovaný metodou GET GEOMETRY odpovídá geometrickému popisu vygenerovanému programem DKM2Spatial.jar Nároky na uložení V této kapitole bude ukázána velikost jednotlivých tabulek, které byly plněny výstupy z programu DKM2Spatial.jar. Velikost jednoho bloku je v testovacím prostředí 8192 bytů (8 kb), viz obrázek Způsob zjištění velikosti konkrétní tabulky je pak zachycen na obrázku Tabulka 7.12 ukazuje pro každou tabulku její velikost. Z uvedeného vyplývá, že tabulky pro uložení vzorku testovaných dat pomocí topologických primitiv (suffix KATASTR ) jsou přibližně šestkát větší než tabulky pro uložení vzorku katastrálních dat pomocí datového typu SDO GEOMETRY. 135

136 Obrázek 7.28: Zobrazení parcel a definičních bodů uložených pomocí okřídlené hrany Obrázek 7.29: Testování metody get geometry 136

137 Obrázek 7.30: Velikost bloku v testovací databázi Obrázek 7.31: Zjištění velikosti tabulky 137

138 Tabulka 7.12: Velikost tabulek s prostorovými daty katastru nemovitostí Tabulka Velikost [kb] AK PARCELY 295 AK DEF BODY 30 KATASTR AK PARCELY 311 KATASTR DEF BODY 49 KATASTR EDGE$ 1070 KATASTR FACE$ 236 KATASTR NODE$ 219 KATASTR RELATION$ 16 Přibližně šestkrát více místa je také potřeba pro uložení indexů, které jsou nad prostorovými daty vytvořeny. Přehled zobrazuje tabulka Pod názvem indexu je v závorce uvedena tabulka a sloupec, nad kterým je index vytvořen. Index Tabulka 7.13: Velikost indexů Velikost [kb] AK PARCELY SPATIAL IDX 295 (AK PARCELY - GEOMETRIE) AK DEF BODY SPATIAL IDX 30 (AK DEF BODY - GEOMETRIE) KATASTR ND SIDX$ 311 (KATASTR NODE$ - GEOMETRY) KATASTR ED SIDX$ 49 (KATASTR EDGE$ - GEOMETRY) KATASTR FC SIDX$ 1070 (KATASTR FACE$ - MBR GEOMETRY) TOP GEOM SPATIAL IDX 236 (KATASTR AK PARCELY - GEOMETRIE) TOP GEOM DB SPATIAL IDX 219 (KATASTR DEF BODY - GEOMETRIE) Na obrázku 7.32 jsou zobrazeny vybrané informace z tabulky 138

139 SDO INDEX METADATA TABLE. Hodnoty ve sloupci SDO RTREE QUALITY udávají kvalitu vytvořeného indexu. Obrázek 7.32: Přehled vytvořených indexů Více o tomto atributu z oficiální dokumentace ([ORSG]) zjistit nelze. Je zde pouze odkaz na funkci QUALITY DEGRADATION, která vypočítává míru poškození indexu. Pokud tato funkce vrátí hodnotu větší než 2, je doporučeno znovuvytvoření indexu. Pro všechny indexy, které jsou na obrázku 7.32 uvedeny, jsem použil pro otestování daného indexu funkci QUALITY DEGRADATION a ve všech případech byla hodnota menší rovna jedné. To je důležité pro další použití indexů při vyhodnocení prostorových dotazů (viz kapitola 7.12). Ukázka použití funkce QUALITY DEGRADATION je zachycena na obrázku Obrázek 7.33: Použití funkce QUALITY DEGRADATION 139

140 7.12 Vyhodnocení prostorových dotazů V tabulce 7.14 a 7.15 jsou uvedeny časy potřebné pro vyhodnocení prostorových dotazů pomocí dotazovacího okna. Pomocí dotazovacího okna různých velikostí vybíráme všechny prvky, které mají s oknem neprázdný průnik. Časy uvedené v tabulkách 7.14 a 7.15 jsou ve vteřinách (číslo v závorce značí počet vybraných prvků). Tabulka 7.14: Časy potřebné pro vybrání prvků pomocí dotazovacího okna Dlaždice [m] SDO GEOMETRY SDO TOPO GEOMETRY 10x (1) (3) 50x (12) (12) 100x (27) (27) 250x (146) (146) 500x (486) (486) 1000x (690) (690) Z tabulky 7.14 je patrné, že při dotazování na data uložená pomocí datového typu SDO TOPO GEOMETRY je potřeba o řád více času, než při dotazování na data uložená pomocí datového typu SDO GEOMETRY. Zajímavé jsou výsledky pro vytvořený index nad funkcí function-based index, kde doba vyhodnocení dotazu byla nepřímoúměrná velikosti dotazovacího okna, viz Tabulka 7.15: Časy potřebné pro vybrání prvků pomocí dotazovacího okna pro function-based index Dlaždice [m] 10x (1) 50x (12) 100x (27) Function-based index 250x (146) 500x (486) 1000x (690) Doba provedení dotazu byla získána pomocí PL/SQL kódu, který je zachycen na ukázce Pro vyhodnocení prostorového dotazu bylo pro jednotlivé datové typy a indexy nutné modifikovat klauzuli WHERE. Jednotlivé modifikace jsou 140

141 patrné z ukázek 7.17, 7.18 a Ukázka 7.17: Anonymní PL/SQL blok pro zjištění doby trvání prostorového dotazu nad datovým typem SDO GEOMETRY DECLARE v p o c e t NUMBER := 0 ; v s t a r t TIMESTAMP; v konec TIMESTAMP; v r o z d i l INTERVAL DAY( 5 ) TO SECOND; BEGIN v s t a r t := SYSTIMESTAMP; SELECT COUNT( 1 ) INTO v p o c e t FROM AK PARCELY pa WHERE SDO RELATE( pa. geometrie, SDO GEOMETRY( 2003, NULL, NULL, SDO ELEM INFO ARRAY( 1, , 3 ), 50x50m SDO ORDINATE ARRAY( , , , ) ), mask=a n y i n t e r a c t ) = TRUE ; END; v konec := SYSTIMESTAMP; v r o z d i l := ( v konec v s t a r t ) DAY( 5 ) TO SECOND; dbms output. p u t l i n e ( Vybrano prvku : v p o c e t ) ; dbms output. p u t l i n e ( S t a r t : v s t a r t ) ; dbms output. p u t l i n e ( Konec : v konec ) ; dbms output. p u t l i n e ( Doba t r v a n i dotazu : v r o z d i l ) ; Ukázka 7.18: Anonymní PL/SQL blok pro zjištění doby trvání prostorového dotazu nad datovým typem SDO TOPO GEOMETRY DECLARE v p o c e t NUMBER := 0 ; v s t a r t TIMESTAMP; v konec TIMESTAMP; v r o z d i l INTERVAL DAY( 5 ) TO SECOND; BEGIN v s t a r t := SYSTIMESTAMP; SELECT COUNT( 1 ) INTO v p o c e t FROM KATASTR AK PARCELY pa WHERE SDO ANYINTERACT( pa. t o p o l o g i e, SDO GEOMETRY( 2003, NULL, NULL, SDO ELEM INFO ARRAY( 1, , 3 ), 500x500m SDO ORDINATE ARRAY ( , , , ) ) ) = TRUE ; v konec := SYSTIMESTAMP; v r o z d i l := ( v konec v s t a r t ) DAY( 5 ) TO SECOND; 141

142 END; dbms output. p u t l i n e ( Vybrano prvku : v p o c e t ) ; dbms output. p u t l i n e ( S t a r t : v s t a r t ) ; dbms output. p u t l i n e ( Konec : v konec ) ; dbms output. p u t l i n e ( Doba t r v a n i dotazu : v r o z d i l ) ; Ukázka 7.19: Anonymní PL/SQL blok pro zjištění doby trvání prostorového dotazu pomocí function-based indexu DECLARE v p o c e t NUMBER := 0 ; v s t a r t TIMESTAMP; v konec TIMESTAMP; v r o z d i l INTERVAL DAY( 5 ) TO SECOND; BEGIN v s t a r t := SYSTIMESTAMP; SELECT COUNT( 1 ) INTO v p o c e t FROM KATASTR AK PARCELY pa WHERE SDO RELATE(SYSTEM.VRAT GEOMETRII( pa. t o p o l o g i e ), SDO GEOMETRY( 2003, NULL, NULL, SDO ELEM INFO ARRAY( 1, , 3 ), 10x10m SDO ORDINATE ARRAY ( , , , ) ), mask=a n y i n t e r a c t ) = TRUE ; END; v konec := SYSTIMESTAMP; v r o z d i l := ( v konec v s t a r t ) DAY( 5 ) TO SECOND; dbms output. p u t l i n e ( Vybrano prvku : v p o c e t ) ; dbms output. p u t l i n e ( S t a r t : v s t a r t ) ; dbms output. p u t l i n e ( Konec : v konec ) ; dbms output. p u t l i n e ( Doba t r v a n i dotazu : v r o z d i l ) ; Protože není možné vytvořit index nad metodou GET GEOMETRY, viz ([ORST]), vytvořil jsem vlastní PL/SQL funkci VRAT GEOMETRII která volá metodu GET GEOMETRY. Funkce vrací popis prostorového prvku pomocí objektového datového typu SDO GEOMETRY. Ukázka 7.20: Definice funkce VRAT GEOMETRII CREATE OR REPLACE FUNCTION VRAT GEOMETRII( topo mdsys. sdo topo geometry ) RETURN mdsys. sdo geometry DETERMINISTIC AS BEGIN END; RETURN topo. get geometry ( ) ; 142

143 Function-based index je vytvořen nad funkcí VRAT GEOMETRII, která volá metodu GET GEOMETRY datového typu SDO TOPO GEOMETRY. Definice funkce VRAT GEOMETRII je zobrazena v ukázce Ukázka 7.21: Definice funkce VRAT GEOMETRII CREATE OR REPLACE FUNCTION VRAT GEOMETRII( topo mdsys. sdo topo geometry ) RETURN mdsys. sdo geometry DETERMINISTIC AS BEGIN END; RETURN topo. get geometry ( ) ; Vytvoření indexu nad funkcí VRAT GEOMETRII je zachyceno v ukázce Ukázka 7.22: Vytvoření indexu nad funkcí VRAT GEOMETRII CREATE INDEX k a t a s t r f b p a r c e l y i d x ON k a t a s t r a k p a r c e l y (VRAT GEOMETRII( t o p o l o g i e ) ) INDEXTYPE IS MDSYS. SPATIAL INDEX ; Před dotazováním se na prostorová data za použití indexu nad funkcí VRAT GEOMETRII je potřeba aktulizovat pohled USER SDO GEOM METADATA. Ukázka 7.23: Aktualizace pohledu USER SDO GEOM METADATA INSERT INTO user sdo geom metadata (TABLE NAME, COLUMN NAME, DIMINFO, SRID) VALUES ( k a t a s t r a k p a r c e l y, SYSTEM.VRAT GEOMETRII( t o p o l o g i e ), SDO DIM ARRAY( SDO DIM ELEMENT( X, , , 10), SDO DIM ELEMENT( Y, , , 10) ), NULL SRID ) ; 7.13 Možnosti rozšíření programu DKM2Spatial.jar V současné verzi programu se data, se kterými program DKM2Spatial.jar pracuje, načítají ze souboru. Tento soubor je výsledkem dotazu, který je součástí přílohy D.1. Pro testovací účely byl tento způsob dostačující, pokub by byl program využíván v praxi, bylo by efektivnější načítat data přímo z databáze. Tento krok už není tolik náročný a z pohledu funkčnosti programu je de facto pouze technický. 143

144 Ve vstupních datech se pracuje s hranicemi parcel (ne s vnitřní kresbou), kde jednotlivé hraniční úseky představují úsečky (případně polylinie). Jednotlivé lomové body jsou tedy pospojovány přímými liniovými segmenty. Může se stát, že v jiném katastrálním území se vyskytne takový hraniční úsek, který bude geometricky vyjádřen kruhovým obloukem, případně kružnicí. Tuto možnost je při dalším rozšiřování programu nutné zvážit. Velmi zajímavé se mi jeví případné využití hierarchického datového modelu (kapitola 7.5.9). Uplatnění této možnosti pro data katastru nemovitostí může být například užitečné při ukládání hierarchie administrativního členění. Data na vyšší úrovni by nebyla ukládána duplicitně. Hranice vyšších celků by byly ukládány pouze pomocí odkazů na data na nižší (detailnější) úrovni. Nejdetailnější úrovní by zřejmě byla vrstva parcel. 144

145 Kapitola 8 Závěr Problematika začlenění a využití prostorových dat v informačních systémech je velmi obsáhlá a v řadě otázek vlastní implementace i komplikovaná. Ať už máme v našem informačním systému jakákoli data, atributová či prostorová, vždy je pro nás nesmírně důležité, aby tato data byla validní. Výjimkou není ani informační systém katastru nemovitostí. Z důvodů historického vývoje a plnění tohoto systému daty jsou v tuto chvíli v datech nekonzistentnosti. V práci jsem se zaměřil na prostorová data ISKN a na nalezení nekonzistencí, které se v datech mohou objevit. Rovněž jsem se zabýval otázkou možné konverze vybraných prostorových dat do datového formátu shapefile, ve kterém jsou tato data poskytována ČÚZK přes WMS. Současný způsob konverze těchto dat se zdá být pro svoji časovou náročnost nevyhovující, proto jej nahrazuje přístup, který jsem implementoval a popsal v této práci, kdy jsou data do souborů shapefile generována přímo z databáze. Stěžejní část práce spočívala v prozkoumání možnosti využití SŘBD Oracle a nadstavby Spatial pro správu vybraných dat katastru nemovitostí. Zajištění konzistence prostorových dat katastru nemovitostí, konkrétně digitální katastrální mapy, je nezbytnou podmínkou pro další využitelnost těchto dat. Na konkrétních případech jsem prakticky ukázal možnost využití algoritmů z oblasti výpočetní geometrie pro nalezení nekonzistencí v prostorových datech ISKN. Rovněž jsem navrhl a implementoval své vlastní postupy, které v prostorových datech ISKN dokáží automatizovaně vyhledat různé druhy nekonzistencí. Výstupy z této části práce byly velmi kladně ceněny i na 9. mezinárodní konferenci studentů doktorských studijních programů Juniorstav 2007 v Brně, kde jsem prezentoval vlastní algoritmus na vyhledání tzv. prázdných polygonů. Příspěvek s názvem Automatické zajištění konzistence prostorových dat v ISKN obsadil 2. místo v kategorii Praktické aspekty geodézie. Řešení problému čištění dat je nezbytné pro další využití těchto dat. Například využití prostorových dat pro automatizovanou generalizaci je podmíněno jistými pravidly kvality. Těmito pravidly mohou být například požadavky na topologicky čistá data, uvedená v kapitole 4. Pokud se rozhodneme naše prostorová data poskytovat, například přes WMS, což je dnes trend, je rovněž vhodné poskytovat co 145

146 nejčistší data. V práci jsem kromě postupů řešících čištění dat popsal i způsob, jakým lze tato data generovat přímo z databáze do formátu shapefile. Pokud máme data v tomto formátu, lze je snadno poskytovat například přes WMS. ČÚZK poskytuje přes WMS svá prostorová data, mimo jiné definiční body parcel a budov, orientační mapu parcel a digitální katastrální mapu. K přípravě těchto dat pro WMS ve formátu shapefile slouží software (prozatím pouze program OMP2SHP.jar pro generování definičních bodů parcel a budov), který jsem pro tyto účely v rámci spolupráce se sekcí centrální databáze na ČÚZK vytvořil. Software pro generování orientační mapy parcel a digitální katastrální mapy i nadále prochází dalším vývojem, o který se starají především zaměstnanci sekce centrální databáze na ČÚZK. Pomocí vytvořeného software je možné generovat shapefily obsahující definiční body parcel pro zadané katastrální území, pro všechna katastrální území obsahující alespoň jeden definiční bod, případně pro katastrální území pro zadaný počet dnů zpětně. To znamená generovat soubory shapefile pouze pro ta katastrální území, obsahující definiční body parcel či budov vzniklé v požadovaném zpětném časovém intervalu. Orientační mapa parcel je generována po jednotlivých mapových listech tak, jak jsou uloženy rozsahy souřadnic těchto mapových listů v ISKN. Pro každý mapový list je v ISKN uloženo i datum posledního přeskenování. Pokud daný mapový list obsahuje prvky orientační mapy parcel, které nejsou v naskenované verzi mapového listu, jsou tyto prvky vygenerovány v uvedeném rozsahu mapového listu. Digitální katastrální mapa je generována po dlaždicích 2x2 km. Stěžejní část práce se zabývala využitím systému řízení báze dat Oracle a nadstavby Spatial pro uložení digitální katastrální mapy. V práci jsem popsal přechod od stávajícího uložení vybraných prvků DKM až po jejich možné uložení v Oracle Spatial. Konkrétně hranic parcel a definičních bodů parcel a budov. Celý postup jsem i prakticky zrealizoval, čímž jsem získal řadu poznatků, které jsem v práci uvedl. Současný způsob využití nadstavby Spatial v ISKN pro uložení prostorových dat katastru nemovitostí je velmi sporadický. V podstatě je tato nadstavba využita pouze pro ukládání souřadnic bodů polohopisu. To vede k tomu, že není možné v plné míře využít možností, které Spatial pro prostorová data nabízí. Oracle Spatial bezesporu nabízí potenciálně velmi užitečnou funkcionalitu pro prostorová data katastru nemovitostí. Například možnost využití hierarchie pro topologicky strukturovaná data vidím jako velmi zajímavou cestu, kam se dále ubírat při řešení otázky, jak efektivně ukládat prostorová data katastru nemovitostí. Pokud by se data katastru nemovitostí uchovávala v datových strukturách Spatial popsaných v této práci, je k dispozici poměrně široké Java API pro následnou správu a manipulaci dat. Při řešení úkolů, které jsem si předsevzal při obhajobě tezí budoucí doktorské práce, jsem získal velmi mnoho cenných zkušeností. Vyzdvihl bych především vzájemnou spolupráci se sekcí centrální databáze na ČÚZK v Praze. Díky této 146

147 spolupráci jsem mohl detailně poznat informační systém katastru nemovitostí, především pak jeho část zabývající se uložením vektorových prostorových dat. Věřím, že díky dosaženým výsledkům, popsaným v této práci, byla tato spolupráce užitečná pro obě strany. V rámci řešení této disertační práce jsem přispěl ke zvýšení kvality prostorových dat ISKN návrhem a efektivní implementací postupů vyhledávajících automatizovaně nekonzistence, které se v datech mohou nalézet. Dále byla změněna filosofie tvorby vektorových prostorových dat katastru nemovitostí pro jejich moderní způsob poskytování veřejnosti. Především byl ale v práci navržen, popsán a implementován alternativní způsob uložení digitální katastrální mapy v Oracle Spatial. Věřím, že právě touto cestou, využitím standardních datových struktur a funkcionality nadstavby Spatial v maximální možné míře pro správu prostorových dat katastru nemovitostí, je správné se ubírat. Tuto cestu jsem v této práci započal a věřím, že úspěšně. 147

148 Literatura [ABJO] Abdelmoty, A. I.; Jones, Ch., B.: Towards Maintaining Consistency of Spatial Databases. Proceedings of the sixth international conference on Information and knowledge management, pp ISBN: X. [ADVL] Adelson-Velskii; Landis, E., M.:An algorithm for the organization of information. Doklady Akademii Nauk SSSR, 146: , 1962 (Russian). [BAST] Baars, M., Stoter, J., Oosterom, P., Verbree, E.: Rule-based or explicit storage of topology structure: a comparison case study. AGILE 2004, Heraklion, pp [BAUM] Baumgart, B.: A polyhedron representation for computer vision. National Computer Conference, AFIPS Conference Proceedings, vol. 44. AFIPS Press, 1976, pp [BEOT] Bentley, J., L.; Ottmann, T.: Algorithms for reporting and counting geometric intersections. IEEE Transactions on Computers, pages , [CADA] Čada, V.: Zpřesňující transformace - nepřekonatelný problém pro gis úrovně pozemkového datového modelu? In Sborník symposia GIS Ostrava Ostrava: Tanger, s ISBN [CLFE] [CLPA] Clementini, E.; Di Felice, P.; Oosterom, P.: A small set of formal topological relationships suitable for end-user interaction. In Proceedings of the Third International Symposium on Advances in Spatial Databases, pp ISBN: [ONLINE] cs251/closestpair/closestpairps.html [CUZK] Český úřad zeměměřický a katastrální. Struktura výměnného formátu informačního systému katastru nemovitostí České republiky. Číslo jednací 6665/ Praha,

149 [ESRI] [ONLINE] [GEOT] [ONLINE] [GUSC] Güting, R. H., Schneider, M.: Realm-based spatial data types: the ROSE algebra. The VLDB Journal. Volume 4, Issue ISSN: [JACA] [JANE] [JANJ] Janečka, K.; Čada, V.: Possibilities of Storage of Spatial Data of Real Estate Registry Information System. In: FIG Working Week 2008 : Integrating generations, June, Stockholm, Sweden. Copenhagen: FIG, p. Janečka, K.: Modelování geoprostorové báze dat na úrovni datového modelu KN. Diplomová práce (Vedoucí Doc. Ing. Václav Čada, CSc.). Plzeň, Janečka, K.: Konzistence prostorových dat v ISKN. 9. ročník odborné konference JUNIORSTAV. Brno, ISBN: [JANO] Janečka, K.: Zajištění konzistence prostorových dat v Informačním systému katastru nemovitostí. In Sborník symposia GIS Ostrava Ostrava: Tanger, s ISBN [JEZE] Ježek, F.: Geometrické a počítačové modelování. Pomocný učební text. [ONLINE] /file/gpm-all-FJ.pdf [KAIN] Kainz, W.: Geographic Information Science [ONLINE] [KLZA] Klajnšek, G.; Žalik, B.: Merging Polygons With Uncertain Boundaries. Computers & Geosciences 31 (3), pp [KORA] Kothuri, R., K.,V.; Ravada, S.; Abugov, D.: Quadtree and R-tree indexes in Oracle Spatial: a comparison using GIS data. In Proceedings of the ACM SIGMOD international conference on Management of data, pp ISBN: [LAMI] Laurini, R.; Milleret-Raffort, F.: Topological Reorganization of Inconsistent Geographical Databases: A Step Towards Their Certification. Comput. & Graphics. Vol. 18. No. 6, pp

150 [LOUW] Louwsma, J.H.: Topology versus non-topology storage structures; Functional analysis and performance test using Laser-Scan Radius Topology. TU Delft, [MEIJ] [OOTI] [OGIC] [GGIS] Meijers, M.: Implementation and testing of variable scale topological data structures. Master s thesis. TU Delft, p. [ONLINE] Oosterom, P., Tijssen, T., Penninga, F.: Topology storage and use in the context of consistent data management. GISt Report No. 33. TU Delft, 2005, 54 p. [ONLINE] Open GIS Consortium, Inc.: OpenGIS Simple Features Specification For SQL OpenGIS Project Document [ONLINE] [ORSG] Oracle Spatial User s Guide and Reference, 10g Release 2. Oracle Corp [ONLINE] 01.pdf [ORST] Oracle Spatial Topology and Network Data Model, 10g Release 1. Oracle Corp [ONLINE] 01.pdf [PENN] Penninga, F.: Oracle 10g Topology; Testing Oracle 10g Topology using cadastral data. GISt Report No. 26. Delft, p. [ONLINE] [PEQU] Penninga, F., Quak, W., Tijssen, T., Oosterom, P.: Storage and Querying of Topological Structures in Oracle Spatial. Topology and Spatial Databases Workshop. Glasgow, [POZE] Pokorný, J.; Žemlička, M.: Základy implementace souborů a databází. Karolinum, Praha ISBN: [QUST] Quak, W., Stofer, J., Tijssen, T.: Topology in spatial DBMSs. The 3rd international symposium on digital earth: information resources for global sustainability. Brno, [RATO] Radius Topology Administrator s Guide, Issue 1.1 for Radius Topology Version 1.0. Laser-Scan Limited, [SEUB] Servigne, S.; Ubeda, T.; Puricelli, A.; Laurini, R.: A Methodology for Spatial Consistency Improvement of Geographic Databases. GeoInformatica 4 (1), pp

151 [WIKI] Wikipedie. [ONLINE] [WMSS] [ONLINE] 151

152 Příloha A Obsah přiloženého DVD Obrázek A.1: Obsah přiloženého DVD 152