Vektorová architektura systému GRASS GIS

Transkript

1 České vysoké učení technické v Praze CFakulta stavební Vektorová architektura systému GRASS GIS DISERTAČNÍ PRÁCE Praha, 2013 Ing. Martin Landa

2

3 České vysoké učení technické v Praze Fakulta stavební Katedra mapování a kartografie Vektorová architektura systému GRASS GIS GRASS GIS Vector Architecture DISERTAČNÍ PRÁCE CIng. Martin Landa Disertační práce k získání akademického titulu Ph.D. Doktorský studijní program: Geodézie a kartografie Školitel: Prof. Ing. Aleš Čepek, CSc. Praha, červen 2013

4

5 PROHLÁŠENÍ I Prohlášení Jméno doktoranda: Název disertační práce: Martin Landa Vektorová architektura systému GRASS GIS Prohlašuji, že jsem uvedenou doktorskou disertační práci vypracoval samostatně, s použitím odborné literatury a dostupných pramenů uvedených v seznamu literatury, který je součástí této práce. V Solanech 27. června 2013 Ing. Martin Landa

6 II PROHLÁŠENÍ

7 PODĚKOVÁNÍ III Poděkování V první řadě bych chtěl poděkovat mému školiteli prof. Ing. Aleši Čepkovi, CSc. za důvěru ve mě vloženou, za nezměrnou trpělivost, se kterou ke mě během mého strastiplného doktorského studia plného odboček a nejrůznějších úkroků stranou přistupoval, a vždy mě podporoval ve snaze najít cestu, která povede k dokončení této práce. Dále bych chtěl poděkovat rodině, přátelům za podporu a především trpělivost, kterou projevili během mého studia. Děkuji také Žofiji, která mi pomohla v mé životní cestě najít opravdovost. Dík patří i mladému Wertherovi 1 a neblahému Judovi 2, kteří mě provázeli během posledních týdnů před odevzdáním této práce. Při vzniku disertační práce byly použity výhradně aplikace a nástroje free softwaru, jmenovitě geografický informační systém GRASS, databázový systém PostgreSQL s geoprostorovým rozšířením PostGIS, knihovna GDAL/OGR, textový editor GNU Emacs, rodina GNU kompilátorů a mnoho dalších programů, které jsou součástí operačního systému Debian GNU/Linux. Text byl vysázen typografickým systémem L A TEX, obrázky vytvořeny pomocí grafického editoru Dia a Inkscape. Grafy byly generovány v prostředí R. Tímto si dovoluji poděkovat všem, kteří se podíleli a podílejí na jejich vývoji. 1 J. W. Goethe: Utrpení mladého Werthera (Die Leiden des jungen Werthers, 1774). 2 T. Hardy: Neblahý Juda (Jude the Obscure, 1895).

8 IV PODĚKOVÁNÍ

9 SUMMARY V Summary The doctoral thesis deals with 2D and 3D topological vector data processing in geographical information systems (GIS). Within the thesis have been implemented improvements in the open source GRASS GIS vector architecture with a goal to increase its interoperability and to support topological management of 3D vector data. Interoperability has been investigated in two different approaches. The OGR interface introduces to GRASS GIS ability to read and write vector data in various GIS formats. Newly designed native PostGIS interface allows to process and manipulate vector data stored in the open source geospatial database PostGIS including topological access to the data. Within the 3D vector GIS development has been designed a topological model for 3D vector data and later also implemented in the GRASS vector architecture. This part also covers newly designed GRASS tools for processing 3D vector data. The thesis also deals with support of the Czech Cadastral Exchange Data Format in the OGR library, design and implementation of the new GRASS graphical user interface focused on 2D and 3D vector data processing, and also with the metadata management in the GRASS vector libraries. Resumé Disertační práce se zabývá problematikou topologické správy 2D a 3D vektorových dat v geografických informačních systémech (GIS). V rámci práce byly navrženy a realizovány změny ve vektorové architektuře desktopového open source GIS nástroje GRASS, s cílem zlepšení její interoperability a začlenění podpory pro topologickou správu 3D vektorových dat. Interoperabilita je řešena ve dvou rovinách. Kromě integrace knihovny OGR umožňující čtení a zápis vektorových dat v nejrůznějším GIS formátech je zásadním příspěvkem rozšíření vektorové architektury o nativní podporu geodatabáze PostGIS, včetně topologické správy vektorových dat. V souvislosti s vývojem 3D vektorového GIS byl navržen topologický model pro 3D vektorová data a implementován ve vektorové architektuře systému GRASS. Dále byly do systému GRASS začleněny nové nástroje pro práci s 3D vektorovými daty. Mezi vedlejší aplikační výstupy práce lze zařadit implementaci podpory pro výměnný formát Informačního systému katastru nemovitostí v knihovně OGR, návrh a realizaci nové generace grafického uživatelského rozhraní systému GRASS, včetně specializovaných nástrojů orientovaných na práci s 2D a 3D vektorovými daty, a konsolidaci správy metadat ve vektorové architektuře systému GRASS.

10 VI SUMMARY

11 Obsah Úvod 1 1 Úvod do problematiky Geografický informační systém GRASS GIS Historie projektu GRASS GIS Základní terminologie systému GRASS Počátky grafického uživatelského rozhraní systému GRASS GIS Přehled vektorových datových modelů v GIS Špagetový model Seznam lomových bodů Dual Independent Map Encoding Node-Arc-Area Datový model vektorové architektury systému GRASS GIS Specifikace OGC Simple Features Access Datový model specifikace OGC Simple Features Access Knihovna OGR Knihovna OGR jako implementace specifikace OGC SFA Geodatabáze PostGIS Základní charakteristika geodatabáze PostGIS Knihovna libpq PostGIS Topology Datové modely pro 3D GIS Simplexy D Formal Data Structure TEtrahedral Network Simplified Spatial Model VII

12 VIII OBSAH Constructive Solid Geometry Boundary Representation ,8D Objektově orientované datové modely Knihovna CGAL Metadata Proces standardizace v oblasti metadat Technická norma ISO Technická norma ISO Výměnný formát ISKN Informační systém katastru nemovitostí Specifikace výměnného formátu ISKN Analýza současného stavu řešené problematiky Vektorová architektura systému GRASS GIS Poznámky k vektorové architektuře systému GRASS verze 4 a Vektorová architektura systému GRASS verze Topologická správa vektorových dat ve verzi GRASS Změny v topologické správě vektorových dat ve verzi GRASS Podpora pro externí vektorová data ve verzi GRASS Podpora geodatabáze PostGIS v systému GRASS verze Pseudo-topologie Podpora pro 3D vektorová data ve verzi GRASS Správa metadat ve verzi GRASS Správa metadat ve vektorové knihovně GRASS verze Cíle disertační práce 81 4 Analytická část práce Interoperabilita vektorové architektury systému GRASS Integrace knihovny OGR ve vektorové architektuře GRASS verze Integrace PostGIS ve vektorové architektuře GRASS verze Simple Features API vektorové knihovny verze GRASS Podpora geodatabáze PostGIS v systému GRASS GIS Podpora PostGIS v rozhraní OGR ve verzi GRASS

13 OBSAH IX Nativní podpora PostGIS ve verzi GRASS Integrace PostGIS Topology ve vektorové architektuře GRASS GIS Nástroje systému GRASS pro práci s geodatabází PostGIS Podpora pro 3D vektorová data v systému GRASS GIS Topologický model systému GRASS pro 3D vektorová data Nástroje systému GRASS pro práci s 3D vektorovými daty Integrace knihovny CGAL v systému GRASS GIS Návrh správy metadat pro verzi GRASS Konsolidace metadat v systému GRASS GIS Návrh správy metadat odpovídající technické normě ISO Vývoj nové generace GUI systému GRASS GIS Digitalizační nástroj Rozšíření wxgui pro vizualizaci dat ve 3D Grafický modeler Podpora pro výměnný formát ISKN v knihovně OGR Implementace podpory VF ISKN v knihovně OGR FOSS nástroje pro přístup k datům ve výměnném formátu ISKN Topologická správa prvků digitální katastrální mapy Závěr 147 Seznam literatury 151 Seznam zkratek 159 Seznam obrázků 163 Seznam tabulek 167 A Specifikace OGC Simple Features Access 169 A.1 Přehled typů jednoduchých geoprvků B Topologie 2D vektorových dat v systému GRASS 175 C Knihovna CGAL 185 C.1 Ukázková aplikace pro 3D triangulaci

14 X OBSAH D Podpora výměnného formátu ISKN v knihovně OGR 189 D.1 Hlavička výměnného formátu ISKN D.2 Skupiny datových bloků D.3 Přehled OGR-VFK vrstev D.4 UML diagram C++ tříd ovladače VFK D.5 Ukázková aplikace E Obsah přiloženého CD 201

15 Úvod Internet. Síť podrývá svět od chvíle, kdy se zrodil internet, její digitální orgán. A neméně důkladně proměňuje vrstvu po vrstvě i sebe sama. I software byl zprvu chápán jako objekt: uzavřený a prodávaný v krabici. Jenže každý objekt se dá jednoduchým mentálním krokem změnit v síť. Po čtyřech letech práce jsem Faustomat zveřejnil jako open source. Co to znamená? Dovolil jsem komukoliv na světě, aby si prohlédl každý příkaz kódu, a taky ho podle libosti měnil. Právě teď, zatímco já sedím v base, na projektu ve volném čase dře sedm lidí po celém světě. Nejmladší je čtrnáctiletá Korejka. Ten jednoduchý mentální krok byl Pi: překlopil jsem Faustomat z uzavřeného a neproniknutelného objektu na síť příkazů. Každý z uzlů se může libovolně měnit, napojit na lidského vývojáře nebo na jiný software. Otevřel jsem vnitřní strukturu a najednou se vynořilo sedm lidí, kteří na něm zadarmo pracují, tak jako jiní tráví hodiny doplňování Wikipedie jednoduše proto, že navazovat vztahy je mnohem uspokojivější než vyrábět objekty. A tak se lavina řítí dál. Vlnu po vlně se statické objekty nezadržitelně taví do proměnlivých vztahů. Na všech úrovních platí stejný princip: co bylo oddělené se spojuje. Co bylo Hierarchií se mění v Síť. Kde vládla autorita rozhoduje hejno. Tohle je Indrova síť, náš digitální uroboros. Filip Doušek, Hejno bez ptáků (Černá Kniha, str ),

16 2 ÚVOD Disertační práce Vektorová architektura systému GRASS GIS je předkládána v rámci doktorského studia na oboru Geodézie a kartografie Fakulty stavební ČVUT v Praze. Volba tématu a náplň práce byla z části ovlivněna novým studijním oborem Geoinformatika na Fakultě stavební ČVUT v Praze [A1]. Vývoji a využití free softwaru v oblasti geoinformatiky se věnuji od počátku svého magisterského studia na oboru Geodézie a kartografie, Fakultě stavební ČVUT v Praze. Za mým odborným a profesním nasměrováním stojí především prof. Aleš Čepek, pod jehož vedením jsem obhájil na ČVUT v Praze v roce 2005 diplomovou práci na téma Návrh modulu GRASSu pro import dat ve výměnném formátu ISKN. Na toto téma disertační práce v jistých ohledech volně navazuje. Věnuje se vývoji open source desktopového geografického informačního systému GRASS GIS především z pohledu vektorové architektury a integruje podporu výměnného formátu Informačního systému katastru nemovitostí (ISKN) v knihovně OGR. Práce odráží mou odbornou činnost v letech a působení ve vývojových týmech mezinárodních open source projektů GRASS GIS a GDAL/OGR. Text disertační práce je rozdělen do čtyř tematických bloků: úvod do problematiky, analýza současného stavu problematiky, stanovení cílů disertační práce a analytická část prezentující výstupy práce. V úvodní části jsou představeny open source softwarové projekty, které jsou použity v analytické části práce. Jedná se především o open source geografický informační systém GRASS GIS (kap. 1.1), který je zároveň pojícím prvek celé práce. V současné době je GRASS GIS pravděpodobně nejucelenějším open source desktopovým GIS nástrojem, který může být především díky své obrovské šíři analytických nástrojů považován za open source alternativu k nejrozšířenějším proprietárním GIS produktům. V tomto ohledu systém GRASS zaostává především svým grafickým uživatelským rozhraním (kap ), které neodpovídá požadavkům uživatelů běžně rozšířených desktopových GIS nástrojů. Dalším stavebním prvkem je knihovna OGR (kap. 1.4), především v souvislosti s rozšířením vektorové architektury systému GRASS směrem k její větší interoperabilitě, a začlenění podpory pro výměnný formát Informační systém katastru nemovitostí (ISKN). Informační systém ISKN je včetně jeho výměnného formátu stručně představen v kap V kap. 1.5 jsou dále zmíněny základní charakteristiky geodatabáze PostGIS včetně nadstavby PostGIS Topology, umožňující topologickou správu vektorových dat (viz kap ). Topologická nadstavba hraje zásadní roli v navržené integraci geodatabáze PostGIS v systému GRASS.

17 ÚVOD 3 Spojovacím článkem knihovny OGR a geodatabáze PostGIS je specifikace OGC Simple Features Access (SFA). Této problematice se podrobněji věnuje kap. 1.3 a příloha A. Posledním softwarovým projektem, který je v této části práce uveden, je knihovna CGAL (kap. 1.7), a to především s ohledem na rozšíření funkcionality systému GRASS v oblasti analýzy 3D vektorových dat. V teoretické části jsou popsány vektorové modely používané v GIS s důrazem na topologický model vektorové architektury systému GRASS a datový model jednoduchých geoprvků tak, jak jej definuje již zmíněná specifikace OGC Simple Features Access. Tato část zahrnuje přehled 2D datových modelů, konkrétně jde o kap S ohledem na rozšíření topologické správy 3D vektorových dat jsou představeny i některé z 3D datových modelů používaných v oblasti GIS a CAD. Více k tomu tématu je uvedeno v kap Poslední tematická část se věnuje problematice správy metadat v geografických informačních systémech včetně aktuálně platných technických norem v této oblasti. Podrobněji je v kap. 1.8 popsána technická norma ISO pro popis geodat a na ni navazující norma ISO Druhá část práce poskytuje přehled současného stavu problematiky především s ohledem na hlavní téma disertační práce, a to vektorovou architekturu systému GRASS. V kap. 2.1 je vektorová architektura podrobena analýze především z hlediska jejího historického vývoje. Pro práci samotnou je podstatná optimalizace topologické správy vektorových dat ve verzi GRASS 7 (viz kap ). Tyto změny reflektuje jeden z hlavních výstupů práce, a to návrh 3D topologického modelu vektorové knihovny systému GRASS. Dále je v této kapitole zmíněn stav integrace knihovny OGR ve vektorové architektuře GRASS verze 6 (kap. 2.2) a podpora pro práci s 3D vektorovými daty v systému GRASS, viz kap Poslední část je věnována analýze stavu správy metadat v systému GRASS (kap. 2.4) s důrazem na vektorová data, resp. datové struktury a funkce rozhraní pro programování aplikací (API) vektorové knihovny GRASS verze 6. Třetí kapitola shrnuje úvodní dvě části práce, tedy úvod do problematiky a analýzu současného stavu a na základě sebraných poznatků definuje cíle disertační práce. Z navržených cílů vychází poslední část, která shrnuje analytické výstupy práce. Výsledky jsou zhodnoceny v závěru. Poslední část poskytuje přehled analytických výstupů předkládané práce. Kapitola začíná rozšířením stávající neúplné podpory knihovny OGR ve vektorové architektuře systému GRASS. Verze GRASS 7, které je tato práce věnována, již obsahuje plnohodnotnou integraci této knihovny včetně podpory pro zápis dat či pro přímý přístup k externím vektorovým datům, viz kap Vektorové nástroje systému GRASS tak mohou produkovat vektorová

18 4 ÚVOD data v libovolném GIS formátu, který knihovna OGR podporuje v režimu zápisu. Tento fakt výrazně přispívá k interoperabilitě systému GRASS jako vektorovému GIS nástroji. Zásadním příspěvkem v rozšíření interoperability vektorové architektury systému GRASS je ve verzi 7 implementace nativní podpory geodatabáze PostGIS včetně topologické správy vektorových dat v rámci rozšíření PostGIS Topology. Text zohledňuje rozdíly v topologických modelech systému GRASS a PostGIS Topology s ohledem na konverzi topologických elementů mezi těmito datovými modely. Podpora topologické správy vektorových dat je v rámci integrace geodatabáze PostGIS v systému GRASS zcela zásadní, neboť GRASS představuje topologicky orientovaný GIS. Technickým aspektům integrace geodatabáze PostGIS ve vektorové knihovně systému GRASS se věnuje kap Podrobněji se této integraci věnuje dále kap. 4.2 včetně již zmiňované integrace rozšíření PostGIS Topology. Dále jsou v kap zmíněny podpůrné nástroje systému GRASS pro práci s geodatabází PostGIS, které byly autorem práce navrženy, implementovány a posléze i začleněny do distribuce systému GRASS 7. Dalším tématem, které bylo v rámci vektorové architektury systému GRASS řešeno, je návrh topologické správy 3D vektorových dat. To zahrnuje rozšíření stávajícího 2D topologického modelu GRASS směrem ke třetí dimenzi (kap ) a implementaci nástrojů pro tvorbu a další analýzu 3D vektorových dat v systému GRASS, viz kap Další dvě témata se vektorové architektury systému GRASS dotýkají spíše nepřímo. V kap. 4.4 je řešen návrh a implementace knihoven systému GRASS pro správu metadat a konsolidaci této funkcionality jak ve vektorové knihovně systému GRASS, tak v části knihoven pro přístup k datům rastrovým. Dále je popsán vývoj nové generace grafického uživatelského rozhraní (GUI) především s ohledem na komponenty pro digitalizaci a vizualizaci 3D vektorových dat, více v kap Poslední kapitola je věnována návrhu a implementaci podpory výměnného formátu ISKN v knihovně OGR. S ohledem na téma práce je část této kapitoly věnována i topologické správě prvků digitální katarální mapy v geodatabázi PostGIS, viz kap. 4.6

19 Create like a God, Command like a King, Work like a Slave 1 Constantin Brâncuşi Úvod do problematiky Tato kapitola shromažďuje základní informace potřebné k analýze současného stavu problematiky a poskytuje nutný základ pro analytickou část práce. Podrobněji jsou popsány open source softwarové projekty, na kterých později staví analytická část práce. Jde především o desktopový geografický informační systém GRASS GIS (kap. 1.1), knihovny OGR (kap. 1.4), CGAL (kap. 1.7) a geodatabázi PostGIS (kap. 1.5). S ohledem na knihovnu OGR a její integraci ve vektorové architektuře systému GRASS je část textu věnována související specifikaci OGC Simple Features Access (viz kap. 1.3). Část kapitoly je věnována přehledu datových modelů pro vektorová data v GIS. Důraz je kladen na topologické modely především s ohledem na datový model vektorové architektury systému GRASS. Kapitola 1.2 poskytuje přehled 2D datových modelů od špagetového modelu až např. po Node-Arc-Area. Součástí tohoto přehledu je i datový model vektorové architektury systému GRASS. V další části (kap. 1.6) je rozebrána problematika 3D topologickým modelů. Okrajově je zmíněna i problematika metadat v geografických informačních systémech (kap. 1.8). A to především s ohledem na analytickou část práce zabývající se rozšířením správy metadat ve vektorové architektuře systému GRASS. Posledním tématickým okruhem je Informační systém katastru nemovitostí v ČR (ISKN) a jeho výměnný formát s důrazem na implementaci podpory tohoto formátu v knihovně OGR a topologickou správu prvků digitální katastrální mapy v geodatabázi PostGIS s využitím podpory rozšíření PostGIS Topology ve vektorové knihovně systému GRASS (kap ). 5

20 6 KAPITOLA 1. ÚVOD DO PROBLEMATIKY 1.1 Geografický informační systém GRASS GIS GRASS (Geographic Resources Analysis Support System) GIS je multiplatformní geografický informační systém (GIS) určený pro správu 2D/3D rastrových a vektorových geodat, obrazových záznamů, produkci vysoce kvalitních grafických výstupů, prostorové modelování a vizualizaci dat [A2]. GRASS GIS ( je free software 1 [A3] publikovaný pod všeobecnou licencí GNU GPL [B1]. Knihovny systému GRASS a jeho nástroje (tzv. moduly) jsou z větší části implementovány v programovacím jazyce ANSI C. Několik málo modulů je implementováno v programovacím jazyce C++, jiné jsou dostupné v podobě skriptů v jazyce Python. Obrázek 1.1: Logo projektu GRASS GIS (zdroj: [B2]) Historie projektu GRASS GIS Počátky vývoje systému GRASS GIS se datují do první poloviny osmdesátých let minulého století. Projekt tehdy získal oficiální záštitu United States Army Construction Engineering Research Laboratories (USA-CERL), Champaign, Illinois, U.S.A. a byl vyvíjen jako nástroj pro uzemní správu a plánování, primárně určený pro americkou armádu. V roce 1982 byla v laboratořích USA-CERL vytvořena pracovní skupina GIS pod vedením Billa Gorana. Po analýze existujících, především komerčních produktů, bylo rozhodnuto vytvořit vlastní GIS řešení jako public domain (tj. veřejné dílo) [A4]. V této době byly vyvinuty základní komponenty systému, které po jistých obměnách přetrvaly až do dnešních dnů. GRASS GIS se postupně rozšířil do americké státní správy, univerzit i komerčních společností. Svého vrcholu GRASS jako projekt dosáhl na počátku devadesátých let minulého století. Silná uživatelská komunita projektu GRASS (téměř registrovaných uživatelů, na tuto dobu velmi nadprůměrné technické zázemí ové konference, pravidelná setkání, časopis GRASSCLIPPINGS apod.) sehrála nezastupitelnou roli při dalším směřování geoinformačních technologií. Například předchůdce mezinárodní organizace Open Geospatial 1 Free Software (from Wikipedia),

21 1.1. GEOGRAFICKÝ INFORMAČNÍ SYSTÉM GRASS GIS 7 Consorcium (OGC), tj. Open GIS Consorcium, vzniklo v roce 1994 transformací sdružení uživatelů systému GRASS Open GRASS Foundation (OGF). Obrázek 1.2: Časopis GRASSCLIPPINGS jako jeden z projevů silné komunity projektu GRASS na počátku devadesátých let minulého století (zdroj: [B3]). Laboratoře USA-CERL publikovaly první verzi GRASS 1.0 v roce 1982 (obr. 1.4), poslední verze pod touto hlavičkou nesla označení 4.2 a byla vydána v roce V roce 1995 se laboratoře USA-CERL oficiálně vzdaly dalšího vývoje systému GRASS. V současnosti (rok 2013) tak projekt GRASS GIS slaví téměř neuvěřitelných 30 let své existence. Obrázek 1.3: Programátor systému GRASS Dave Gerdes (USA-CERL) před počítačem Compaq 386, na který portoval GRASS 3.0 (zdroj: [A5]).

22 8 KAPITOLA 1. ÚVOD DO PROBLEMATIKY Vývoj systému GRASS se tak postupně přesunul na akademickou půdu (University of Baylor, U.S.A. a Leibniz Universität Hannover, Německo). V roce 1999 byl zdrojový kód projektu GRASS přesunut do centralizovaného repositáře Concurrent Version System (CVS). Téhož roku spatřila světlo světa první verze GRASS GIS vydaná pod licencí GNU GPL GRASS 5.0. V roce 2001 byl zformován pod vedením Markuse Netelera GRASS Development Team, který od této doby systém GRASS GIS dále oficiálně vyvíjí a spravuje. V této dekádě byl publikován GRASS řady 6. První verze 6.0 byla vydána v roce 2001, prozatím poslední verze v červenci V roce 2008 se projekt GRASS GIS stává formujícím členem nadace Open Source Geospatial Foundation (OSGeo) a začíná se pracovat na nové generaci GRASS verze 7. Vydání verze GRASS 7.0 je plánováno na přelom roku 2013 a Ve vývoji systému GRASS GIS lze nalézt dva dobře identifikovatelné milníky. Podporu pro rastrová data s plovoucí desetinnou čárkou ve verzi GRASS 5 a zásadně přepracovanou a rozšířenou vektorovou architekturu ve verzi GRASS 6. V tomto ohledu plánovaná verze GRASS 7 navazuje na GRASS verze 5 a 6 s tím, že přináší dlouho očekávané vlastnosti: nativní podporu pro geodatabázi PostGIS a možnost připojení OGR vrstev v režimu čtení i zápisu. Obrázek 1.4: Časová osa vývoje systému GRASS GIS ( ) Základní terminologie systému GRASS V kapitole jsou vysvětleny základní termíny specifické pro systém GRASS s cílem ulehčit čtenáři orientaci v problematice, které se disertační práce věnuje. Text kapitoly čerpá především z knihy Open Source GIS: A GRASS GIS Approach [A6] a oficiální dokumentace systému GRASS [B4]. Data, ke kterým GRASS přistupuje, mají pevně danou strukturu. Při spuštění aplikace GRASS musí uživatel zvolit tři níže uvedené elementy v daném pořadí: 1. adresář s geodaty (GRASS database) definovaný proměnnou prostředí $GISDBASE. Jde o standardní adresář umístěný na lokálním či síťovém disku, např. /opt/grassdata nebo C:\grassdata v případě OS MS Windows. V tomto adresáři jsou uložena veškerá data, ke kterým GRASS přistupuje (tedy rastrové a vektorové mapy v nativním formátu GRASS, atributové tabulky ve formátu SQLite či DBF, různá nastavení apod.). Výjimku představují atributová (popisná) data skladovaná v některém z externích databázových systémů (např. PostgreSQL či MySQL).

23 1.1. GEOGRAFICKÝ INFORMAČNÍ SYSTÉM GRASS GIS 9 2. lokaci (GRASS location) definovanou proměnnou prostředí $LOCATION_NAME. Lokace je adresář umístěný v GRASS databance. Tento adresář obsahuje data, která souvisejí s daným projektem. Lokace je definována souřadnicovým systémem (referenční elipsoid, kartografické zobrazení, mapové jednotky) a velikostí zájmového území. 3. mapset (GRASS mapset) definovaný proměnnou prostředí $MAPSET. Mapset 2 je souborem map, které tvoří jakýsi logický celek v rámci lokace (tj. projektu). Může například odpovídat jednotlivým uživatelům nebo uceleným analýzám (studium vegetace, záplavová území, apod.). Každá lokace musí obsahovat alespoň jeden mapset s unikátním názvem PERMANENT. Ten většinou obsahuje základní datové vrstvy a ostatní mapsety jsou brány jako pracovní (zpracování vstupních dat, jejich analýza apod.). Příklad spuštění aplikace GRASS GIS verze 7 z příkazové řádky (databanka: /opt/ grassdata, lokace: nc_spm_08, mapset: PERMANENT): $ grass70 /opt/grassdata/nc_spm_08/permanent Při zadání programu grass70 bez parametrů se spustí aplikace v grafickém módu (obr. 1.5). Obrázek 1.5: Úvodní obrazovka grafického uživatelského rozhraní wxgui pro výběr adresáře s geodaty, lokace a mapsetu (autor: Martin Landa, 2012). GRASS GIS je modulární systém, který disponuje poměrně rozsáhlou množinou malých, ale výkonných programů (v terminologii systému GRASS modulů ). To odpovídá koncepci UNIXu 3 jako takového. Daný program má za úkol vyřešit dílčí problém, měl by být co nejmenší a poměrně jednoduchý [A7]. 2 Termín mapset lze přeložit do češtiny jako soubor map. V textu bude použit anglický termín. Termín location je překládán jako lokace. 3 UNIX je v informatice ochranná známka operačního systému vytvořeného v Bellových laboratořích americké firmy AT&T v roce 1965.

24 10 KAPITOLA 1. ÚVOD DO PROBLEMATIKY Nástroje systému GRASS mají konzistentní syntax, jejich jména se skládají z předpony označující skupinu příkazů a krátkého názvu napovídající účel modulu (tab. 1.1). Například modul v.buffer patří do skupiny vector a je určen pro vytvoření obalové zóny (tzv. bufferu ) nad vektorovými daty. Tabulka 1.1: Přehled skupin modulů systému GRASS. prefix skupina popis db. database podpora externích databázových systémů d. display grafické výstupy a vizuální dotazy g. general obecné příkazy pro manipulaci s daty i. imagery zpracování obrazových dat ps. postscript tvorba mapových výstupů ve formátu PostScript r. raster zpracování 2D rastrových dat r3. 3D raster zpracování 3D rastrových dat (voxels) v. vector zpracování 2D/3D vektorových dat Syntax nástrojů systému GRASS je dán množinou přepínačů a parametrů, např. modul v.external.out má čtyři přepínače (-frpg) a tři parametry (dsn, format, options), z toho první dva parametry jsou povinné. Dále jsou definovány tzv. globální přepínače. Mezi čtyři nejpoužívanější patří -verbose (upovídaný výstup), -quiet (vypisuje pouze důležité zprávy a upozornění), -overwrite (automaticky přepisuje výstupní data, pokud již existují) a -help (vypíše základní informace o modulu včetně jeho syntaxe a modul ukončí). Příklad. Spuštění modulu v.external.out z příkazové řádky s přepínačem -help. GRASS> v.external.out --help Description: Defines vector output format. Keywords: vector, export, output, external, OGR, PostGIS Usage: v.external.out [-frpg] dsn=string format=string [options=string[,string,...]] [--verbose] [--quiet] Flags: -f List supported formats and exit -r Cease using OGR/PostGIS, revert to native output and exit -p Print current status -g Print current status in shell script style --v Verbose module output --q Quiet module output

25 1.1. GEOGRAFICKÝ INFORMAČNÍ SYSTÉM GRASS GIS 11 Parameters: dsn format options Name of input OGR or PostGIS data source Format for output vector data default: ESRI_Shapefile Creation options V textu je používán termín mapa, který v tomto případě neodkazuje na mapový výstup (ať v digitální či analogové formě), nýbrž na datovou (mapovou) vrstvu. V odborné literatuře a dokumentaci týkající se systému GRASS se používá termín raster map či vector map. Termín layer je používán pouze v případě vektorových dat, kdy vektorová mapa může obsahovat jednu či více vrstev (viz obr. 1.6). Ke každému vektorovému elementu může být přiřazen libovolný počet párů číselných hodnot (vrstva, kategorie). K dané vrstvě může být přiřazena atributová tabulka, kde daný záznam je jednoznačně identifikován právě kategorií, přičemž vektorový element může být navázán na více záznamů v různých tabulkách a současně v dané vrstvě může být více vektorových elementů se stejnou kategorií [A6]. V textu se budeme držet významu termínů vektorová mapa a vektorová vrstva právě tak, jak je definuje terminologie používaná systémem GRASS. Obrázek 1.6: Diagram znázorňující vztah vektorové vrstvy a atributové tabulky v systému GRASS (zdroj:

26 12 KAPITOLA 1. ÚVOD DO PROBLEMATIKY Počátky grafického uživatelského rozhraní systému GRASS GIS GRASS jako projekt s dlouhou tradicí a historií je poměrně úzce svázán s uživatelským prostředím UNIXových operačních systémů. Nástroje systému GRASS byly původně přístupné pouze z příkazové řádky (CLI). Historicky první prototyp grafického uživatelského rozhraní (GUI) navrženého pro systém GRASS nesl označení TCLTKGRASS (horizont vývoje 1999). Následoval jej o poznání komplexnější GIS Manager (Michael Barton et al., 2004). GIS Manager (obr. 1.7) byl včetně uživatelského rozhraní (UI) digitalizačního modulu v.digit či nástroje pro vizualizaci dat ve 3D nviz napsán v programovacím jazyce Tool Command Language (TCL) s využitím grafické knihovny TK 4. V roce 2006 byla odstraněna závislost na unixové X11 5 architektuře, což umožnilo portování GUI pod OS MS Windows. Obrázek 1.7: GIS Manager ve verzi GRASS 6.3 (autor: Michael Barton, 2004). Nicméně dva základní komponenty tohoto uživatelského prostředí, digitalizační modul v.digit (obr. 1.9) a nástroj pro vizualizaci dat ve 3D nviz, nebyly nikdy do prostředí GIS Manageru plně integrovány a zůstaly jako samostatné aplikace s vlastním uživatelským rozhraním. Limity grafického toolkitu TCL/TK činily vývoj GUI poměrně komplikovaným a především neatraktivním pro potencionální nové vývojáře. V roce 2006 bylo rozhodnuto opustit TCL/TK a navrhnout od základů novou generaci GUI s využitím sofistikovanější grafické knihovny, více v kap Tool Command Language (TCL), grafická knihovna TK, 5 X Window System (též X11 nebo jen X) je v informatice souhrnné označení pro software, který umožňuje vytvořit GUI. Používá se zejména v unixových systémech, kde se stal standardem.

27 1.1. GEOGRAFICKÝ INFORMAČNÍ SYSTÉM GRASS GIS Digitalizační nástroj v.digit Historie digitalizačního modulu v.digit sahá do druhé poloviny osmdesátých let minulého století [A8]. Původní verze uživatelského rozhraní byla orientována na tehdejší textové terminály (obr. 1.8). Obrázek 1.8: Digitalizační modul ve verzi GRASS 4.0 (autor: USA-CERL, 1990). V roce 2000 se začalo pracovat na nové vektorové architektuře GRASS 6 (kap ). V rámci toho bylo jedním z hlavních vývojářů Radimem Blažkem navrženo i nové uživatelské rozhraní modulu v.digit (obr. 1.9), založené na grafické knihovně TCL/TK. Obrázek 1.9: Digitalizační modul ve verzi GRASS 5.7 (autor: Radim Blažek, 2006).

28 14 KAPITOLA 1. ÚVOD DO PROBLEMATIKY 1.2 Přehled vektorových datových modelů v GIS Vektorový datový model v GIS slouží k reprezentaci geoprvků geometrickými entitami (elementy) jako jsou body, linie, či polygony. Na obr je uveden příklad vektorové reprezentace geoprvků čtyřmi geometrickými elementy bodem (A), linií (B) a dvěma sousedícími polygony (C a D). Obrázek 1.10: Příklad vektorového modelu v GIS: reprezentace geometrické složky popisu geoprvků bodem (A), linií (B) a dvěma sousedícími polygony (C a D). Text této kapitoly si neklade za cíl komplexní popis vektorových datových modelů používaných v GIS. Zmíněny jsou pouze vybrané datové modely, a to hlavně s ohledem na topologický datový model vektorové architektury systému GRASS GIS (kap ). Vektorové datové modely používané v GIS lze rozdělit do tří základních skupin [A9]: špagetové, topologické a hierarchické. Geometrické datové modely, u kterých chybí topologická složka popisu geodat, jsou povětšinou intuitivnější a snadněji implementovatelné. Jako příklad můžeme uvést datový model specifikace OGC Simple Features Access (kap. 1.3) či špagetový model (kap ). Topologické modely na rozdíl od geometrických modelů definují prostorové vztahy mezi jednotlivými objekty. V případě hierarchických modelů jsou topologické elementy ukládány v hierarchické struktuře. Topologické informace jsou důležité pro řešení prostorových dotazů bez nutnosti složitých výpočtů. Topologický model musí být kompletní, a to ve smyslu

29 1.2. PŘEHLED VEKTOROVÝCH DATOVÝCH MODELŮ V GIS 15 určování prostorových vztahů jako kombinace základních vztahů definovaných modelem. Kromě toho topologické modely zajišťují, že nedojde k duplicitnímu uložení geometrických objektů, či ke ztrátě konzistence dat Špagetový model Mezi nejjednodušší vektorové datové modely patří tzv. špagetový model 6 (Spaghetti model). Tento model je představován neseřazeným seznamem souřadnic lomových bodů. Špagetový model je velmi jednoduchý, nicméně může obsahovat velké množství duplicitních záznamů. Polygon je reprezentován uzavřeným seznamem lomových bodů, které definují jeho hranici. Vzhledem k tomu je úsek hranice sousedících polygonů uložen dvakrát, tj. pro každý ze dvou polygonů zvlášť. Další důležitou vlastností tohoto modelu je absence topologie, tj. prostorových vztahů mezi jednotlivými entitami modelu. Vzhledem k tomu není tento model efektivní pro většinu prostorových analýz běžně prováděných v GIS, kde prostorové vztahy hrají důležitou roli. Naopak absence topologie není na překážku např. pro vykreslování dat či reprodukci grafického obrazu. Proto je tento datový model často používán např. v digitální kartografii (CAC) [A10]. Obrázek 1.11: Příklad špagetového modelu: reprezentace geometrické složky popisu geoprvků bodem (A), linií (B) a dvěma sousedícími polygony (C a D). Lomové body jsou označeny číselným indexem Konfigurace znázorněná na obr bude ve špagetovém modelu vyjádřena následovně (viz obr. 1.11): 6 Termín spaghetti je použit jako metafora této reprezentace. Neseřazený seznam liniových segmentů se podobá špagetám na talíři.

30 16 KAPITOLA 1. ÚVOD DO PROBLEMATIKY A, 1 # identifikátor bodu, počet vrcholů x1, y1 # souřadnice bodu (bod 1) B, 4 # identifikátor linie, počet vrcholů x2, y2 # souřadnice lomových bodů linie (2-5) x3, y3; x4, y4; x5, y5 C, 7 # identifikátor polygonu, počet vrcholů x6, y6 # souřadnice lomových bodů polygonu (6-11) x7, y7; x8, y8; x9, y9; x10, y10; x11, y11; x6, y6 D, 5 # identifikátor polygonu, počet vrcholů x9, y9 # souřadnice lomových bodů polygonu (9-13) x10, y10; x12, y12; x13, y13; x9, y Seznam lomových bodů Datový model seznamu lomových bodů (Vertex dictionary) vychází ze špagetového modelu (kap ) s tím rozdílem, že neobsahuje duplicitní záznamy. Podobně jako špagetový model, ani tento model nevyjadřuje prostorové vztahy. Seznam souřadnic lomových bodů je uložen ve zvláštní datové struktuře s tím, že každý bod má přiřazen jednoznačný identifikátor. Druhá datová struktura modelu obsahuje seznam identifikátorů elementů, které tvoří geometrickou složku popisu jednotlivých geoprvků [A11]. Následuje příklad pro konfiguraci znázorněnou na obr. 1.11: # seznam lomových bodů a jejich souřadnic 1 : x1, y1 2 : x2, y : x13, y13 # seznam objektů a jejich lomových bodů bod A: 1 linie B: 2, 3, 4, 5 polygon C: 6, 7, 8, 9, 10, 11, 6 polygon D: 9, 10, 12, 13, Dual Independent Map Encoding Vektorový datový model Dual Independent Map Encoding (DIME) byl navržen v US Bureau of the Census 7 s cílem efektivního uložení geodat včetně prostorových vztahů. Konkrétně pro digitální záznamy ulic a na pomoc při shromažďování údajů o počtu obyvatel 7 US Bureau of the Census je americký sčítací úřad. Data produkovaná tímto úřadem představovala v osmdesátých letech minulého století v podstatě první ucelenou datovou sadu geodat, která byla volně dostupná v rámci veřejného sektoru.

31 1.2. PŘEHLED VEKTOROVÝCH DATOVÝCH MODELŮ V GIS 17 na základě geograficky lokalizovaných adresních údajů [A12]. Práce na specifikaci DIME začaly již v roce DIME je tak jedním z prvních známých vektorových modelů v GIS vybudovaných na topologickém základě. Vektorový model DIME sleduje tři základní vlastnosti topologických vztahů: 1. spojitost hran (connectivity), 2. sousednost ploch nalevo a napravo od hrany (contiguity), 3. příslušnost hrany k dané ploše (area definition). Datový model DIME definuje pro každou hranu počáteční a koncový uzel. Tím je určen směr hrany. Každý uzel má přiřazen jednoznačný kód. V místě křížení hran musí být vždy umístěn uzel. Hrana nese zároveň informaci o tom, jaká plocha leží napravo a nalevo. Obrázek 1.12: Příklad vektorového modelu Dual Independent Map Encoding (kompozice odpovídá obr. 1.10). Lomové body jsou označeny číselným indexem 1 13, hrany identifikátorem a l. Příklad pro konfiguraci znázorněnou na obr. 1.12: # seznam lomových bodů a jejich souřadnic 1, x1, y1 2, x2, y , x13, y13 # hrana, plocha napravo, plocha nalevo, počáteční uzel, koncový uzel a,,, 2, 3 b,,, 3, 4

32 18 KAPITOLA 1. ÚVOD DO PROBLEMATIKY c,,, 4, 5 d,, C, 6, 7 e,, C, 7, 8 f,, C, 8, 9 g, D, C, 9, 10 h,, C, 10, 11 i,, C, 11, 6 j, D,, 10, 12 k, D,, 12, 13 l, D,, 13, 9 # plocha: seznam hran formující hranici plochy C : d, e, f, g, h, i D : g, j, k, l Souborový formát, který implementuje datový model DIME je označován jako Geographic Base Files (GBF). V roce 1990 byl tento formát nahrazen formátem Topologically Integrated Geographic Encoding and Referencing (TIGER). Datová struktura formátu TIGER v porovnání s GBF především zpřesňuje geometrickou složku popisu geoprvků. TIGER překonává nedostatky svého předchůdce tím, že ukládá bodové, liniové a plošné elementy zvlášť, a tím zrychluje vyhledávání v datových strukturách [A10] Node-Arc-Area Ve špagetovém či topologickém modelu jako je např. DIME nejsou jednotlivé záznamy entit modelu nijak uspořádány. Pokud např. hledáme všechny hrany, které formují hranici dané plochy, musíme seznam hran projít vícenásobně. Tento problém řeší tzv. hierarchické datové modely tím, že informace o uzlech, hranách a plochách ukládají zvlášť uspořádané v hierarchické struktuře. Plošné elementy jsou definovány prostřednictvím liniových elementů včetně počátečního a koncového uzlu. Toto oddělené uložení jednotlivých typů elementů datového modelu dovoluje jednodušší a rychlejší vyhledávaní, např. v případě sousednosti ploch nás zajímají informace o plochách a pouze částečně informace o hranách. Konkrétně hledáme pouze ty hrany, které mají definovánu plochu na obou stranách [A10]. Představitelem hierarchického datového modelu je Node-Arc-Area (NAA). Tento model definuje tři základní elementy: node uzel jako bodový element, arc hrana či oblouk jako liniový element, area plocha jako plošný element.

33 1.2. PŘEHLED VEKTOROVÝCH DATOVÝCH MODELŮ V GIS 19 Základní vlastnosti tohoto modelu lze definovat v následujících bodech: 1. každá hrana je orientovaná, tj. má definován počáteční a koncový uzel, 2. každý uzel musí být počátečním či koncovým uzlem alespoň jedné hrany, 3. každá plocha je ohraničena jednou nebo více orientovanými hranami, 4. hrany se mohou křížit pouze v uzlech, 5. každá hrana má přesně jednu plochu nalevo a napravo, 6. každá plocha musí být definována jako plocha nalevo či napravo alespoň jedné hrany. Obrázek 1.13: Příklad vektorového modelu Arc-Node-Area (kompozice odpovídá obr. 1.10). Součástí modelu jsou pouze uzly (N 1 4 ), hrany (ARC 1 4 ) a plochy (AREA 1 2 ). Lomové body označené číselným indexem 1 13 nejsou součástí datového modelu Node-Arc-Area. Příklad pro konfiguraci znázorněnou na obr. 1.13: # topologie uzlů uzel, seznam navazujících hran 1, 1 2, 1 3, , # topologie hran arc, počáteční uzel, koncový uzel, plocha napravo, plocha nalevo 1, 1, 2,, 2, 9, 10, 1,

34 20 KAPITOLA 1. ÚVOD DO PROBLEMATIKY 3, 10, 9, 1, 2 4, 9,, 10,, 2 # topologie ploch plocha, seznam hran formující její hranici 1, 2 3 2, 3 4 Geometrie jednotlivých geoprvků je reprezentována bodem, linií a dvěma polygony. Hranice polygonů je definována hranami ARC 2 4. geoprvek : seznam lomových bodů bod A : 1 linie B : arc1 ( ) polygon C: arc2 ( ) + arc3 (10 9) polygon D: arc3 (10 9) + arc4 ( ) Modifikací tohoto datového modelu vzniká DCEL (seznam dvojitě propojených hran), který navíc pro každou hranu přidává informaci o předchozí a následující hraně. Z tohoto rozšířeného modelu vychází datový model Topo-Geo (kap ) Datový model vektorové architektury systému GRASS GIS Datový model vektorové architektury systému GRASS je striktně topologického charakteru. Patří mezi tzv. hierarchické datové modely orientované na efektivní vyjádření topologických vztahů a na jejich rychlé dotazování. Topologická správa vektorových dat včetně rozdílů mezi datovými modely GRASS verze 6 a 7 je podrobněji rozebrána v kap a V současné době je tento datový model omezen pouze na 2D elementy (obr. 1.14). Obrázek 1.14: Diagram topologického modelu vektorové architektury systému GRASS verze 7 (autor: Martin Landa, 2013).

35 1.2. PŘEHLED VEKTOROVÝCH DATOVÝCH MODELŮ V GIS 21 Mezi základní topologické elementy tohoto datového modelu patří uzel (node), linie (line), hraniční linie (boundary) a reprezentační bod plochy (centroid). Hraniční linie je liniové element, který na rozdíl od elementu označovaného jako linie může tvořit hranici plochy. Plošný topologický element (area) je tvořen jednou či více hraničními liniemi a volitelně i jedním centroidem. Izolovaná plocha nebo souvislá množina ploch formuje plošný element označovaný jako ostrov (isle). Z koncepčního hlediska vychází tento model částečně z datového modelu Node-Arc- Area (NAA), viz kap Hrana (arc) je rozdělena na dva liniové elementy: linii a hraniční linii, s tím rozdílem, že v případě linie není součástí topologické informace plocha nalevo a napravo. Navíc zavádí v porovnání s datovým modelem NAA nové topologické elementy, a to reprezentační bod plochy (centroid) a složený plošný element ostrov (isle). Příklad reprezentace kompozice geoprvků z obr v topologickém modelu vektorové architektury systému GRASS verze 7 je znázorněn na obr Obrázek 1.15: Příklad reprezentace geoprvků ve vektorovém modelu systému GRASS (kompozice odpovídá obr. 1.10). Součástí datového modelu jsou pouze uzly (N 1 4 ), linie (L 1 ), hraniční linie (B 1 3 ) a centroidy (C 1 ). Hraniční linie a centroidy formují dvě plochy (A 1, A 2 ). Plochy A 1, A 2 tvoří v tomto případě jeden ostrov označený jako I 1. Lomové body označené číselným indexem 1 13 nejsou součástí datového modelu.

36 22 KAPITOLA 1. ÚVOD DO PROBLEMATIKY 1.3 Specifikace OGC Simple Features Access Specifikace OGC Simple Features Access (SFA) popisuje společnou architekturu pro tzv. jednoduché geoprvky 8 a specifikuje uložení geodat v digitální podobě. Vydání specifikace v roce 1999 znamenalo důležitý krok ve vývoji GIS technologií. V roce 2004 byla specifikace OGC Simple Features Access přijata jako mezinárodní norma označovaná jako ISO a později v roce 2006 adoptována jako technická norma ČSN Text kapitoly zmiňuje podstatné aspekty s ohledem na její implementaci v knihovně OGR a podporu přístupu k jednoduchým geoprvkům ve vektorové knihovně systému GRASS verze 7 (viz kap ). Kompletní dokumentace specifikace OGC Simple Features Access je dostupná online [B6] z webových stránek organizace Open Geospatial Consorcium (OGC). Open Geospatial Consorcium ( je mezinárodní průmyslové konsorcium zahrnující více než 470 obchodních společností, vládních organizací a univerzit. Primárním cílem konsorcia je maximální stupeň interoperability v oblasti GIS Datový model specifikace OGC Simple Features Access Specifikace OGC Simple Features Access zavádí pro popis geometrie geoprvků několik typů elementů. Přehled jednotlivých typů je názorně uveden na obr Typ jednoduchého geoprvku je definován třídou, která určuje jeho vlastnosti (atributy) a metody. Bázovou třídou tohoto modelu je třída Geometry (geometrie). Mezi odvozené třídy patří Point (bod), Curve (křivka), Surface (povrch) či GeometryCollection (sada geometrických objektů). Souhrnný přehled typů elementů definovaných touto specifikací je uveden v příloze A.1. Třída Geometry. Jedná se o bázovou abstraktní 9 třídu. Odvozené třídy reprezentují obecně 0, 1 či 2-dimenzionální geometrické objekty umístěné 2, 3 či 4-dimenzionálním souřadnicovém prostoru (R 2, R 3 či R 4 ). V případě souřadnicového prostoru R 2 je objekt jednoznačně lokalizován souřadnicemi x, y. Prostor R 3 přidává třetí souřadnici označovanou jako z nebo m, R 4 operuje současně se souřadnicemi x, y, z a m. Souřadnice daného objektu musí být definovány v rámci jednoho prostorového referenčního systému, nicméně jejich interpretace závisí na kontextu. Souřadnice z typicky představuje nadmořskou výšku, m naměřenou hodnotu (např. čas). Třída Geometry definuje základní metody jako jsou např. Dimension(), GeometryType(), IsSimple(). 8 Simple Feature. Překlad anglického termínu feature do češtiny se v oblasti GIS ustálil na dvou běžně používaných formách. V souboru českých technických norem, které vznikly přejímáním mezinárodních norem geografické informace řady ISO se používá termín vzhled jevu, a to jako abstrakce jevů reálného světa [A13]. V textu disertační práce je použit v této souvislosti termín geoprvek, který vychází z návrhu terminologického slovníku České asociace pro geoinformace (CAGI) [B5]. Pojem simple feature je překládán jako jednoduchý geoprvek. 9 U abstraktní třídy, na rozdíl od klasické (neabstraktní) třídy, nemůžeme vytvářet objekty, tj. její instance.

37 1.3. SPECIFIKACE OGC Simple Features Access 23 Obrázek 1.16: Datový model specifikace OGC Simple Features Access (zdroj: [B6]). Detailní popis odvozených tříd, jako jsou Point, LineString či Polygon (obr. 1.16), je uveden v příloze A.1. Podrobné informace jsou dostupné v dokumentaci specifikace OGC Simple Features Access [B6]. Na obr je znázorněna kompozice z obr v datovém modelu jednoduchých geoprvků dle specifikace OGC Simple Features Access. Obrázek 1.17: Příklad kompozice jednoduchých geoprvků dle specifikace OGC Simple Features Access. Jednotlivé objekty jsou vyjádřeny bodem (Point, A), lomenou čárou (LineString, B) a dvěma polygony (Polygon, C a D).

38 24 KAPITOLA 1. ÚVOD DO PROBLEMATIKY 1.4 Knihovna OGR I see GDAL/OGR as the glibc/glibc++ 10 of the geospatial software world. It s open, it provides core functionality, I can t understand how anybody gets anything done without it. Howard Butler Knihovna OGR ( poskytuje přístup v režimu čtení a často i zápisu k velkému počtu vektorových GIS formátů [B7]. Datový model knihovny OGR vychází ze specifikace OGC Simple Features Access, viz kap Zkratka OGR původně odkazovala na OpenGIS Simple Features Reference Implementation, nicméně vzhledem k tomu, že knihovna OGR není zcela kompatibilní se specifikací OGC Simple Features Access, byl stanoven vhodnější název OGR Simple Features Library. OGR spoluutváří s knihovnou Geospatial Data Abstraction Library (GDAL) projekt označovaný jako GDAL/OGR. Knihovna GDAL je zaměřena na čtení a zápis rastrových GIS formátů. GDAL/OGR je jako sada dvou knihoven a podpůrných nástrojů implementována v programovacím jazyce C++ a publikována pod open source licencí X/MIT. Původně byl projekt vyvíjen Frankem Warmerdamem, v roce 2006 se stal GDAL/OGR zakládajícím členem nadace Open Source Geospatial Foundation (OSGeo) a Frank Warmerdam historicky prvním předsedou této nadace. Tento fakt dokresluje zásadní postavení projektu GDAL/OGR a jeho původního autora při formování komunity pod hlavičkou nadace OSGeo. Obrázek 1.18: Logo projektu GDAL/OGR (zdroj: [B8]). GDAL/OGR má výsadní postavení mezi open source GIS projekty hned z několika důvodů (viz motto této kapitoly). V současnosti je tato knihovna využívána v celé řadě projektů. Od open source jako je např. GRASS GIS, QGIS či MapServer až po proprietární produkty (např. Esri ArcGIS 9.3+) [B9]. 10 GNU C Library (glibc) je standardní knihovna jazyka C (resp. C++ v případě glibc++) vyvíjená v rámci projektu GNU. Projekt GNU je zaměřený na free software, inspirovaný operačními systémy unixového typu.

39 1.4. KNIHOVNA OGR Knihovna OGR jako implementace specifikace OGC Simple Features Access Datový model knihovny OGR Datový model (tj. datové typy, názvy metod) knihovny OGR je založen na specifikacích OGC Simple Features Access (SFA) [B6] a Simple Features for OLE/COM [B10]. Knihovna OGR implementuje datový typ Geometry dle specifikace OGC SFA jako třídu OGRGeometry. Tato třída je definována jako abstraktní a slouží pro odvození specifických geometrických typů tak, jak je definuje specifikace OGC Simple Features Access (viz obr. 1.16). Jde o následující datové typy: OGRPoint bod, OGRLineString lomená čára, OGRPolygon polygon, OGRGeometryCollection množina různorodých geometrických objektů, OGRMultiPoint množina bodů, OGRMultiLineString množina lomených čar, OGRMultiPolygon množina polygonů. Kromě třídy Geometry knihovna OGR implementuje další specifické abstraktní třídy. Tyto třídy definují vlastnosti a metody, které jsou dále implementovány odvozenými třídami. Jde o následující dvě třídy: OGRCurve jako bázová třída pro OGRLineString, OGRSurface jako bázová třída pro OGRPolygon. Přehled tříd implementující geometrické objekty dle specifikace OGC Simple Features Access je zobrazen na obr Abstraktní třídy jsou zvýrazněny kurzívou. Datový model knihovny OGR je v porovnání s datovým modelem specifikace OGC Simple Features Access mírně zjednodušen a neobsahuje geometrické objekty typu LinearRing, Line (tyto datové typy jsou v knihovně OGR vyjádřeny třídou OGRLineString), Triangle a TIN (vyjádřen třídou Polygon). Kromě toho nejsou součástí datového modelu knihovny OGR datové typy PolyhedralSurface, MultiSurface a MultiCurve. Třída OGRGeometry obsahuje referenci na instanci třídy OGRSpatialReference definující prostorový souřadnicový systém, v rámci něhož je daný objekt lokalizován.

40 26 KAPITOLA 1. ÚVOD DO PROBLEMATIKY Obrázek 1.19: Datový model knihovny OGR (zdroj: [B11]) Objektový model knihovny OGR Knihovna OGR definuje kromě třídy OGRGeometry určující geometrickou složku popisu jednoduchých geoprvků dle specifikace OGC Simple Features Access další třídy, které tvoří její objektový model. Mezi základní třídy objektového modelu knihovny OGR patří: Třída OGRSpatialReference. Definuje prostorový souřadnicový systém dle specifikace OGC Coordinate Transformation Service [B12]. Reference na instanci této třídy je jedním z atributů třídy OGRGeometry. Třída OGRFeature. Třída vyjadřující vlastnosti a metody jednoduchého geoprvku. Tento objekt zahrnuje geometrickou (reference na třídu OGRGeometry) a atributovou složku popisu jednoduchého geoprvku. Každý geoprvek (feature) má přiřazen číselný identifikátor. Atributová složka popisu je vyjádřena třídou OGRFeatureDefn, která obsahuje informace o počtu atributů, jejich datových typech a hodnotách. Jednotlivé atributy jsou vyjádřeny jako instance třídy OGRFieldDefn. Třída OGRLayer. Reprezentuje datovou vrstvu v rámci tzv. data source (datového zdroje). Všechny prvky (instance třídy OGRFeature) sdílí stejné schéma tj. typ geometrie, souřadnicový systém (instance třídy OGRSpatialReference) a seznam atributů (instance třídy OGRFeatureDefn). Třída OGRLayer disponuje metodami pro náhodné a sekvenční čtení geoprvků a zápis nových geoprvků, pokud je zápis pro daný formát knihovnou OGR podporován a datový zdroj je otevřen ovladačem v režimu zápisu. Třída je v objektovém modelu knihovny OGR deklarována jako abstraktní, implementace je ponechána na straně tzv. ovladače (viz níže).

41 1.4. KNIHOVNA OGR 27 Třída OGRDataSource. Reprezentuje specifickou sadu datových vrstev (instancí třídy OGRLayer) pocházejících ze stejného zdroje. Datovým zdrojem může být soubor, adresář, databáze či protokol. Podobně jako v případě třídy OGRLayer je i tato třída definována jako abstraktní a její vlastní implementace je ponechána na straně tzv. ovladače. Třída OGRSFDriver. Tato bázová třída implementuje základní vlastnosti a metody pro tzv. ovladače knihovny OGR. Třídy, implementující ovladače pro čtení a případně zápis knihovnou podporovaných datových formátů, jsou od této třídy odvozeny. Pro bližší informace lze odkázat na implementační detaily ovladače VFK, který vznikl jako jeden z aplikačních výstupů této práce (kap ). Výše uvedené C++ třídy objektového modelu knihovny OGR jsou znázorněny na obr Obrázek 1.20: Diagram C++ tříd objektového modelu knihovny OGR (zdroj: zdrojové kódy knihovny OGR).

42 28 KAPITOLA 1. ÚVOD DO PROBLEMATIKY 1.5 Geodatabáze PostGIS PostGIS ( je rozšíření, umožňující uložení, správu a analýzu geodat v prostředí objektově-relačního databázového systému PostgreSQL. Za vznikem projektu PostGIS stojí společnost Refractions Research se sídlem v Kanadě. PostGIS je nicméně ryze komunitní open source projekt, na kterém se podílí celá řada vývojářů po celém světě. Je publikován pod licencí GNU GPL. První verze PostGIS 1.0 vyšla v roce Obrázek 1.21: Logo projektu PostGIS (zdroj: [B13]). PostgreSQL je open source objektově-relační 11 systém řízení báze dat (SŘBD) 12, který je vyvíjen pod otevřenou licencí typu BSD. PostgreSQL je navržen tak, aby umožňoval definovat nové datové typy, funkce a operátory. Na této flexibilitě je postaven i PostGIS jako rozšíření PostgreSQL orientované na správu, manipulaci a analýzu geodat. PostGIS je open source alternativou k proprietárním produktům jako je Oracle Spatial/- Locator, IBM DB2/Information Spatial DataBlades nebo prostorová nadstavba pro Microsoft SQL Server PostGIS podporuje z velké části kromě specifikace OGC Simple Features Access [B6] také technickou normu ISO Information technology Database languages SQL multimedia and application packages (SQL/MM) [A15]. Spojením s objektově-relačním databázovým systém PostgreSQL, který podporuje z velké části průmyslové normy ANSI SQL a do jisté míry i ANSI SQL 2006, se PostGIS stává jedním z projektů založených na současných průmyslových specifikacích a technických normách. PostGIS je z větší části implementován v programovacím jazyce C a procedurální nadstavbě jazyka SQL pro PostgreSQL označovaného jako PL/pgSQL. PostGIS v současné době (rok 2013) představuje nejucelenější open source řešení v oblasti objektově-relačních geodatabází. PostGIS je podporován celou řadou GIS produktů od mapových serverů (MapServer, GeoServer) až po desktopové GIS aplikace (GRASS GIS, QGIS či Esri ArcGIS 9.3+). 11 Relační model, resp. relační databázová teorie byla poprvé popsána Dr. E. F. Coddem v článku A Relation Model of Data for Large Shared Data Banks [A14]. Objektově-relační model zavádí objektové rysy, viz specifikace SQL:1999 (technická norma ISO 9075). 12 V textu práce je často v této souvislosti používáno zkrácené označení databázový systém.

43 1.5. GEODATABÁZE POSTGIS Základní charakteristika geodatabáze PostGIS PostGIS rozšiřuje objektově-relační databázový systém PostgreSQL o tři základní komponenty [A16]: (1) Prostorové datové typy. Vedle nativních datových typů databázového systému PostgreSQL jako jsou např. integer, char či date přidává PostGIS nový datový typ Geometry a další odvozené typy jako Point, LineString či Polygon (viz specifikace OGC SFA a datové typy uvedené v kap ). Datový typ Geometry a typy z něj odvozené jsou určeny pro vyjádření geometrie geoprvků. Prostorové datové typy vyjadřují vlastnosti geometrických objektů, jako je hranice pro plošné objekty, lomové body pro liniové objekty, dimenze objektu a další. (2) Prostorové funkce. PostGIS definuje přes 300 prostorových operátorů a funkcí operujících nad prostorovými objekty, např. určení délky lomené čáry, výměry plochy apod. Současně definuje dle specifikace OGC Simple Features Access [B6] prostorové funkce, např. vzdálenostní (vytvoření obalové zóny), funkce překrytí (intersect, union) či funkce pro určení prostorových vztahů (touches, crosses, within, atd.). (3) Prostorový index. PostGIS implementuje indexování prostorových (obecně dvou a vícerozměrných) objektů na bázi technologie GiST. Indexování dat je často založeno na datových strukturách označovaných jako B-stromy [A17, A18]. Data jsou v této stromové struktuře uložena jako setříděné hodnoty. Lze jednoznačně určit, zda je daná hodnota menší, větší nebo rovna jiné hodnotě. Z toho vyplývá, že tato datová struktura není vhodná pro dvou a vícerozměrná (prostorová) data. Databázové systémy s podporou pro prostorová data zavádí tzv. prostorové indexy. Prostorový index určuje, které objekty leží uvnitř daného ohraničujícího obdélníku (bounding box). Prostorový index nepracuje s prostorovými objekty jako takovými, ale s jejich minimálními ohraničujícími obdélníky. Prostorový index na rozdíl od indexů založených na B-stromech vrací pouze přibližný výsledek. Z tohoto důvodu jsou prostorové dotazy využívající prostorového indexu rozděleny do dvou kroků: nejprve jsou na základě prostorového indexu vybrány objekty, které přibližně (tj. jejich minimální ohraničující obdélníky) splňují danou podmínku dotazu a v kroku druhém jsou z této množiny objektů vybrány pouze ty, které skutečně daný prostorový vztah splňují. Určení, zda dva objekty daný prostorový vztah splňují, může být poměrně časově náročné. Přibližný výběr objektů na základě prostorového indexu může časovou náročnost vykonání dotazu zásadně snížit. Většina databázových systémů implementuje prostorový index na základě datové struktury označované jako R-stromy. Podobně je tomu u projektu PostGIS, kde je prostorový index založen na modifikované datové struktuře R-stromů označované jako R-tree-over-GiST.

44 30 KAPITOLA 1. ÚVOD DO PROBLEMATIKY Ve verzi PostgreSQL 9.2 byla implementována nová třída indexů SP-GiST. Nad touto třídou lze vybudovat různé typy indexů od quad-tree, k-d trees až po suffix trees. Vývoj SP-GiST byla sponzorována komunitou projektu PostGIS, nicméně k plné integraci indexu SP-GiST v projektu PostGIS zatím nedošlo [A19]. PostGIS integruje knihovnu Proj4, která umožňuje geodata transformovat mezi různými souřadnicovými systémy. Knihovna Proj4 je open source knihovna pro podporu různých kartografických zobrazení a konverzi mezi nimi. Pokročilé prostorové funkce, jako například topologické predikáty, jsou dostupné díky integrované knihovně Geometry Engine Open Source (GEOS). PostGIS díky integraci této knihovny plně implementuje specifikaci OGC Simple Features Access [B6] již od verze 0.8 (rok 2003). Více o knihovně GEOS v kap Aktuální verze PostGIS (květen 2013) nese označení 2.0. Tato verze znamená milník ve vývoji projektu PostGIS, a to především s ohledem na integraci podpory pro rastrová data 13 a topologickou správu vektorových dat (kap ). PostGIS jako rozšíření objektově-relačního databázové systému PostgreSQL je založen na architektuře server-klient (viz obr. 1.22). Obrázek 1.22: Architektura server-klient geodatabáze PostGIS (zdroj: [B14]). PostGIS jako geodatabáze přináší v porovnání se souborově orientovanými GIS aplikacemi (viz obr. 3.1) integrovaný víceuživatelský přístup, možnost komplexních dotazů kombinující geometrickou a popisnou složku popisu geodat a vysoký výkon při přístupu k rozsáhlejším datovým sadám geodat. 13 Nadstavba PostGIS Raster umožňuje správu, manipulaci a analýzu rastrových dat v prostředí geodatabáze PostGIS, včetně bezešvé kombinace rastrových a vektorových dat.

45 1.5. GEODATABÁZE POSTGIS Knihovna libpq Knihovna libpq poskytuje pro databázový systém PostgreSQL rozhraní pro programování aplikací (API) v programovacím jazyce C. Knihovna umožňuje vývoj aplikací v programovacím jazyce C, které komunikují s databázovým serverem PostgreSQL pomocí SQL dotazů. Výsledky dotazů mohou být vlastní aplikací dále zpracovány [A20]. Z knihovny libpq jsou odvozeny knihovny pro přístup k databázi PostgreSQL pro další programovací jazyky jako je C++ (libpqxx), TCL (libpqtcl) či Python. Na knihovně libpq je postaven jeden z hlavních aplikačních výstupů této práce, a to nativní PostGIS rozhraní vektorové knihovny GRASS verze 7 (kap ). Příklad. Ukázka minimalistické aplikace bez ošetření vstupu či chybových stavů v programovacím jazyce C, postavené na knihovně libpq. Aplikace určí celkovou délku komunikací ve vrstvě roadsmajor z geodatabáze pgisnc. 1 # include <libpq -fe.h> 2 3 int main () 4 { 5 char * stmt ; 6 PGconn * conn ; 7 PGresult * res ; 8 9 /* otev řít datab ázi pgisnc */ 10 conn = PQconnectdb (" dbname = pgisnc "); stmt = NULL ; 13 asprintf (& stmt, " SELECT SUM ( ST_Length ( wkb_geometry )) " 14 " FROM roadsmajor "); 15 /* poslat dotaz */ 16 res = PQexec (conn, stmt ); /* zí skat vý sledek dotazu */ 19 fprintf ( stdout, " Celkova delka silnic : %d km\n", 20 atoi ( PQgetvalue (res, 0, 0)) / 1000) ; PQclear ( res ); 23 /* př ipojen í k datab ázi korektn ě uzav řít */ 24 PQfinish ( conn ); return 0; 27 }

46 32 KAPITOLA 1. ÚVOD DO PROBLEMATIKY PostGIS Topology PostGIS implementuje dle specifikace OGC Simple Features Access (SFA) [B6] přístup k jednoduchým geoprvkům. Geometrická složka popisu geodat je vyjádřena jednoduchými elementy jako je bod, lomená čára či polygon. Polygon je definován vnější hranicí (v terminologii SFA tzv. exterior ring) a libovolným počtem vnitřních hranic (interior rings), které definují otvory (holes) v polygonu. Vzhledem k tomu, že datový model SFA není topologický, tak bude např. úsek hranice společný pro dva sousedící polygony uložen dvakrát, tj. pro každý z polygonů zvlášť. Na obr jsou zobrazeny dva sousedící polygony označené jako A a B. Polygony spolu sdílí část své vnější hranice. Tento úsek je zvýrazněn modrou barvou. Obrázek 1.23: PostGIS Simple Features Access: Příklad sousedících polygonů. Jak je vidět z výpisu geometrie polygonů ve formě Well Known Text (WKT), je úsek hranice, který sdílí polygon A a B (100 0, ), uložen dvakrát. polygon geometrie (WKT) A POLYGON((100 0,0 0,0 100, ,100 0)) B POLYGON((100 0, , ,200 0,100 0)) Podpora pro topologickou správu vektorových dat zpočátku v PostGIS zcela chyběla. Vývojáři se přirozeně nejprve orientovali na úspěšnou implementaci specifikace OGC Simple Features Access. Později v roce 2005 byla částí vývojářů započata práce na rozšíření projektu PostGIS, které by umožňovalo topologickou správu vektorových dat. V počáteční fázi vývoje nebylo toto rozšíření označované jako PostGIS Topology součástí oficiální distribuce projektu PostGIS. Vývoj PostGIS Topology spíše stagnoval, teprve v roce 2011 získal nový impuls. Výsledkem snažení týmu vývojářů (především italského vývojáře Sandra Santilliho 14 ) bylo začlenění tohoto rozšíření do hlavní vývojové větve projektu PostGIS. Rozšíření pro topologickou správu vektorových dat bylo poprvé publikováno jako oficiální součást PostGIS ve verzi 2.0 vydané v dubnu 2012 [B15]. 14 Blog vývojáře Sandra Santilli věnovaný vývoji projektu PostGIS, postgis/.

47 1.5. GEODATABÁZE POSTGIS Datový model Topo-Geo PostGIS Topology je postaven na topologickém modelu Topology-Geometry (zkráceně Topo-Geo) [B16], který je součástí technické normy ISO Information technology Database languages SQL multimedia and application packages (SQL/MM) Part 3: Spatial [A15]. Tato technická norma určuje základní charakteristiku implementace včetně definice databázového schématu a funkcí určených pro správu topologických elementů. Datový model Topo-Geo definuje tři základní topologické elementy: uzly (nodes), hrany (edges) a stěny (faces). Kromě toho PostGIS Topology zavádí nový datový typ TopoGeometry, který je doplňkem k datovému typu Geometry. Datový typ TopoGeometry zajišťuje propojení mezi tabulkou s geoprvky a topologickými elementy. Příklad je uveden v kap Kompozice polygonů znázorněná na obr bude v topologickém modelu Topo-Geo rozložena na příslušné topologické elementy, společná část hranice polygonů bude uložena pouze jednou. V tomto případě jako hrana E2, viz obr Polygony A a B jsou v topologickém modelu reprezentovány dvěma uzly N 1 a N 2, třemi orientovanými hranami E 1, E 2 a E 3 a dvěma stěnami F 1 a F 2. Například polygon A je definován následujícími topologickými elementy: dvěma uzly N 1 a N 2, hranami E 1 a E 2 a stěnou F 1. Obrázek 1.24: Příklad topologické reprezentace sousedících polygonů v PostGIS Topology (kompozice odpovídá obr. 1.23). Topologická reprezentace jednotlivých geoprvků je uložena v rámci databázového schématu, v textu bude používán zkrácený termín topologické schéma. Lze definovat různé, nezávislé topologické reprezentace podle povahy vektorových dat. V rámci topologického schématu jsou definovány tabulky pro jednotlivé topologické elementy uzly node, hrany

48 34 KAPITOLA 1. ÚVOD DO PROBLEMATIKY edge a stěny face 15. Jednotlivé záznamy v těchto tabulkách odpovídají vždy jednomu topologickému elementu. Uzly jsou asociovány s geometrickým objektem typu ST_Point, hrany potom s typem ST_LineString, viz specifikace OGC Simple Features Access, se kterou je technická norma ISO částečně kompatibilní. V případě stěn je uložena geometrie pouze minimálního ohraničujícího obdélníku, a to z důvodu prostorového indexování. Topologické elementy musí být v rámci daného schématu vztaženy vždy k jednomu souřadnicovému systému. Každý topologický element má přiřazen unikátní identifikátor, který zajišťuje jeho jednoznačnou identifikaci v rámci dané tabulky. Uzly. Tabulka node obsahuje bodové topologické elementy uzly. Každý uzel je dán unikátním identifikátorem (atribut node_id), geometrií (geom) a volitelně i identifikátorem stěny, ve které je umístěn (containing_face). Tento údaj je relevantní pouze pro tzv. izolované uzly 16. Technická norma ISO dále definuje funkce, které operují nad tímto typem topologického elementu: ST_AddIsoNode() Přidá nový izolovaný uzel do tabulky node. ST_MoveIsoNode() Změní polohu existujícího izolovaného uzlu. ST_RemIsoNode() Odstraní izolovaný uzel z tabulky node. Funkce pro manipulaci s topologickými elementy musí být dle výše zmíněné technické normy implementovány s ohledem na topologickou konzistenci dat. Například při přidání nového izolovaného uzlu musí být zkontrolováno, zda daná stěna, ve které má být uzel lokalizován skutečně existuje, či zda již neexistuje izolovaný uzel o stejných souřadnicích. Pokud jedna z těchto podmínek není splněna, musí funkce skončit vyvoláním výjimky. Hrany. Tabulka edge obsahuje liniové topologické elementy hrany. Každá hrana je označena v rámci této tabulky unikátním identifikátorem (edge_id). Hrana je definována identifikátorem počátečního (start_node) a koncového (end_node) uzlu, identifikátorem hrany stěny lokalizované ve směru dané hrany nalevo (next_left_edge) a stěny napravo od dané hrany (next_right_edge). Dále je uložen identifikátor stěny umístěné nalevo (left_face) a napravo (right_face) od dané hrany. Posledním atributem hrany je její geometrie, v technické normě ISO se uvádí typ geometrie ST_Curve, v případě implementace v PostGIS Topology se používá typ ST_LineString. 15 V technické normě ISO se používá pro název tabulek, resp. pohledů prefix ST_, implementace PostGIS Topology tento prefix nicméně nepoužívá. 16 Pokud se uzel vyskytuje v m hranách, pak stupeň řád uzlu je D n = m. Pokud je řád uzlu D n = 0, jde o uzel izolovaný.

49 1.5. GEODATABÁZE POSTGIS 35 V případě izolované hrany je stěna nalevo a napravo od hrany totožná, identifikátor hrany stěny napravo odkazuje na identifikátor samotné hrany, u hrany stěny nalevo bude tato hodnota záporná. Dále technická norma ISO specifikuje množinu funkcí operujících nad topologickým elementem typu hrana. Podobně jako v případě funkcí určených pro práci s izolovanými uzly technická norma zaručuje zachování topologické konzistence dat při přidaní nové hrany, či odstranění nebo modifikaci již existující hrany. ST_AddIsoEdge() Přidá novou izolovanou hranu, počáteční a koncový uzel musí být definován jako izolovaný. ST_GetFaceEdges() Vrací seznam hran, které tvoří vnější hranici dané stěny. Hrany jsou řazeny proti směru hodinových ručiček. Záporný identifikátor označuje hranu, která je orientována v opačném směru. ST_ChangeEdgeGeom() Změní geometrii dané hrany. Poloha počátečního a koncového uzlu musí být nicméně zachována. ST_RemIsoNode() Odstraní izolovanou hranu. Související uzly z tabulky node odstraněny nejsou. Následuje seznam funkcí, které operují současně jak s hranami tak s uzly: ST_NewEdgesSplit() Rozdělí danou hranu na dvě. Funkce odstraní původní hranu, vloží dvě nové hrany a zároveň vytvoří nový uzel. ST_ModEdgeSplit() Na rozdíl od ST_NewEdgesSplit() modifikuje původní hranu a přidá do tabulky hran pouze jednu novou hranu. ST_NewEdgeHeal() Odstraní uzel, který spojuje dvě hrany. Tím dojde ke spojení těchto hran. Funkce odstraní původní dvě hrany, uzel a přidá novou hranu, jejíž směr odpovídá první hraně. ST_ModEdgeHeal() Na rozdíl od ST_NewEdgeHeal() modifikuje první hranu. Funkce odstraní pouze druhou hranu a uzel, který tyto dvě hrany spojuje.

50 36 KAPITOLA 1. ÚVOD DO PROBLEMATIKY Stěny. Tabulka face obsahuje plošné topologické elementy stěny. Každá stěna je označena unikátním identifikátorem (face_id) a minimálním ohraničujícím obdélníkem (datový typ ST_Polygon). Tabulka face současně obsahuje tzv. obecnou (universal) stěnu, která zahrnuje všechny topologické elementy definované uživatelem. Tato stěna je označována identifikátorem 0 a nemá přiřazen minimální ohraničující obdélník. Následuje přehled funkcí definovaných technickou normou ISO 13249, které operují současně jak s hranami tak se stěnami: ST_AddEdgeNewFaces() Přidá novou hranu. Pokud je to nutné, tak existující stěnu rozdělí tak, že původní stěnu odstraní a přidá nové dvě stěny, které vzniknou přidáním nové hrany. ST_AddEdgeModFace() Na rozdíl od ST_AddEdgeNewFaces() modifikuje existující stěnu a přidá druhou stěnu do tabulky face. ST_RemEdgeNewFace() Odstraní hranu. V případě, že hrana rozdělovala dvě stěny, budou tyto stěny sloučeny. Funkce odstraní původní stěnu a vloží do tabulky face dvě nové. Uzly spojené s odstraněnou hranou nejsou z tabulky node odstraněny. ST_RemEdgeModFace() Na rozdíl od ST_RemEdgeNewFace() jednu z dotčených stěn modifikuje a druhou odstraní. ST_GetFaceGeometry() Vrací geometrický objekt reprezentující vnější hranici plochy (stěny). V technické normě ISO se hovoří o datovém typu ST_Surface, v případě implementace v PostGIS Topology jde o ST_Polygon. Jako poslední z této skupiny definuje technická norma ISO funkce operující s uzly, hranami i stěnami zároveň: ST_InitTopoGeo() Vytvoří uživatelem definované topologické schéma. V rámci tohoto schématu jsou vytvořeny tabulky node, edge a face, zároveň je do tabulky face přidána tzv. obecná stěna s identifikátorem 0. ST_CreateTopoGeo() Vloží do tabulek uzlů, hran a stěn topologické elementy definované v uživatelem poskytnutém objektu typu ST_GeomCollection.

51 1.5. GEODATABÁZE POSTGIS 37 ST_ValidateTopoGeo() Provede validaci dat s ohledem na možnou topologickou inkonzistenci či chyby v datech. Kromě topologického modelu Topology-Geometry definuje technická norma ISO také model Topology-Network, který je určen např. pro aplikace síťových analýz. Topologické elementy, které tento model používá, se omezují pouze na uzly (ST_Node) a hrany označované jako links (ST_LINK). Tento datový model není v PostGIS Topology implementován, proto se jím nebudeme dále zabývat. Topologický model Topology-Network je relevantní pro projekt pgrouting jako nadstavby PostGIS pro aplikace síťových analýz, nicméně ani v rámci tohoto projektu není realizován. Příklad. Na obr je uvedena kompozice, kde jsou jednotlivé fenomény reálného světa modelovány bodovými (fontána), liniovými (cesty) a plošnými (parcely) geoprvky. V případě jednoduchých geoprvků by uvedená konfigurace při dané úrovni generalizace obsahovala jeden bod (datový typ ST_Point) reprezentující fontánu, sedm lomených čar (datový typ ST_LineString) modelujících cesty a čtyři polygony (datový typ ST_Polygon) označující tři parcely a jeden park. Obrázek 1.25: Příklad modelování reálných objektů v GIS (zdroj: [B16]). Výše uvedená konfigurace je v případě topologického modelu Topo-Geo (obr. 1.26) vyjádřena patnácti uzly (N 1 15 ), sedmnácti hranami (E 1 17 ) a pěti stěnami (F 1 5 ). V místě křížení hran je vždy umístěn uzel. Např. cesta č. 1 je reprezentována třemi uzly N 1, N 2 a N 3, dvěma hranami E 1 a E 2 ; parcela č. 3 čtyřmi uzly N 7, N 8, N 11 a N 12, hranami E 9, E 12, E 13 a E 16, a stěnou F 3 ; fontána izolovaným uzlem N 15.

52 38 KAPITOLA 1. ÚVOD DO PROBLEMATIKY Obrázek 1.26: Příklad modelování reálných objektů v topologickém modelu Topo-Geo (zdroj: [B16]). 1.6 Datové modely pro 3D GIS V minulosti byly geografické informace prezentovány hlavně v podobě papírových map. Vzhledem k tomu většina v současnosti běžně používaných geografických informačních systémů (GIS) pracuje primárně s 2D geodaty, prostorové analýzy jsou prováděny ve 2D. Plnohodnotná podpora pro manipulaci, správu a především analýzu 3D geodat není příliš rozšířena. Řada geografických informačních systémů umožňuje pracovat s 2D geodaty rozšířenými o z-ovou souřadnici. V tomto případě hovoříme o 2,5D datech, bodu v tomto případě může být přiřazena pouze jedna hodnota z-ové souřadnice. Tato hodnota je uložena buď v atributové tabulce anebo přímo v geometrické složce popisu geodat. Nicméně prostorové analýzy či topologická správa vektorových dat jsou prováděny stále ve 2D. Příkladem tohoto přístupu může být i systém GRASS ve verzi 6, který do jisté míry 3D vektorová data podporuje, více v kap Vzhledem k tomu, že žijeme ve více rozměrném prostoru, je důležitost zpracování a analýzy 3D prostorových objektů přirozenou záležitostí. Rozšířením výpočetní techniky a rozvojem technologie GIS se posun ke třetí dimenzi, tzv. 3D GIS, stává aktuálním tématem. Touto problematikou se zabývá celá řada odborných publikací, za všechny uveďme např. [A21, A22, A23]. Navazujícím tématem je časo-prostorová analýza 2D/3D geodat, tj. 4D GIS. V minulosti byla navržena řada 3D topologických modelů, a to vždy v závislosti na danou aplikaci. Některé modely jsou vhodnější pro účely vizualizace, jiné například pro správu prostorových vztahů 3D objektů. Snahou v GIS je definovat 3D datový model, který bude stavět na poznatcích používaných 2D topologických modelů a současně bude reflektovat trendy vizualizace dat ve 3D. Téma vizualizace je nicméně pro 3D GIS spíše okrajovou záležitostí, hlavní důraz je kladen na topologickou reprezentaci 3D geodat a prostorovou analýzu dat ve 3D.

53 1.6. DATOVÉ MODELY PRO 3D GIS 39 Třetí dimenze přirozeně ovlivňuje reprezentaci objektů a určení jejich vzájemných prostorových vztahů. Vzhledem k tomu, že je topologický prostor odvozen z metrického prostoru, je ovlivněn rozměrem definovaným jeho metrikou. 2D topologie znamená, že topologické vztahy budou platné pouze ve 2D, podobně 3D topologie je vždy navázána na 3D prostor. Například trojúhelník má ve 2D přesně tři sousedy, ve 3D může být sousedů řádově více. V této kapitole se nejprve zaměříme na tzv. simplexy (kap ) a základní poznatky z teorie grafů, na kterých staví topologické datové modely jako takové. V dalším textu jsou popsány některé 3D datové modely včetně TEtrahedral Network (kap ), který je zásadní pro následnou implementaci 3D topologie v systému GRASS (kap ) Simplexy Geometrická složka popisu geoprvků může být vyjádřena jednoduchými či složenými geometrickými objekty. Složené geometrické objekty lze dále rozložit na jednoduché a složené objekty. Jednoduchý geometrický objekt je v topologickém modelu reprezentován množinou topologických elementů. Na úrovni geometrie mohou být jednotlivé elementy topologického modelu vyjádřeny jako množina tzv. simplexů 17. Jako příklad lze uvést např. datový model TEtrahedral Network (kap ). Simplex je n-rozměrný zobecněný trojúhelník. Jedná se o konvexní obal množiny n + 1 afinně nezávislých bodů umístěných v euklidovském prostoru R n [A24]. Přitom konvexním obalem množiny bodů rozumíme průnik všech konvexních množin, které tyto body obsahují. Izolovaný bod je reprezentován 0-simplexem, úsečka je 1-simplex definovaný dvěma koncovými body, trojúhelník je 2-simplex definovaný třemi afinně nezávislými body, podobně čtyřstěn jako 3-simplex je definován čtyřmi body. Tímto způsobem jsou definovány další vícerozměrné simplexy jako je např. pentachoron (4-simplex) a další. Simplexy nultého až třetího rozměru jsou znázorněny na obr Obrázek 1.27: Ukázka n-rozměrných simplexů: 0-simplex (bod), 1-simplex (úsečka), 2-simplex (trojúhelník) a 3-simplex (čtyřstěn) (zdroj: [A21]). 17 Simplex latinsky jednoduchý.

54 40 KAPITOLA 1. ÚVOD DO PROBLEMATIKY Množinu simplexů můžeme popsat s využitím teorie grafů [A25]. Definice 1. Graf je dvojice G =< V, E >, kde V je neprázdná množina tzv. vrcholů (uzlů) a E V V je množina uspořádaných dvojic vrcholů, tzv. hran. Každý simplex je reprezentován tzv. úplným grafem. Definice 2. Úplným (kompletním) grafem K n nazýváme graf, ve kterém jsou všechny dvojice vrcholů spojeny hranou, počet hran v úplném grafu je roven ( n 2), kde n je počet vrcholů. Platí, že n + 1 afinně nezávislých bodů tvořících n-simplex definují současně uzly K n+1 úplného grafu. Čtyřstěn (3-simplex) lze tedy reprezentovat jako K 4 úplný graf, trojúhelník (2-simplex) jako K 3 úplný graf a úsečka (1-simplex) jako K 2 úplný graf. V n rozměrném metrickém prostoru dále platí, že se dva n-simplexy dotýkají simplexem o rozměru n 1 (viz obr. 1.28). Úsečky (1-simplexy) se dotýkají bodem (tj. 0-simplexem), trojúhelníky (2-simplexy) se dotýkají svými hranami (1-simplexem), čtyřstěny (3-simplex) se dotýkají trojúhelníkem (2-simplexem) atd. V jednorozměrném prostoru může být bod sdílen nejvýše dvěma úsečkami. Naproti tomu ve dvou a vícerozměrném prostoru může být bod sdílen neomezeným počtem úseček. Podobně v dvourozměrném prostoru může být úsečka sdílena nanejvýš dvěma trojúhelníky. Naproti v troj a vícerozměrném prostoru může být úsečka sdílena neomezeným počtem trojúhelníků. V trojrozměrném prostoru může být trojúhelník sdílen nanejvýš dvěma čtyřstěny apod. Obrázek 1.28: Sousednost n-simplexů: (A) dvě úsečky (1-simplexy) se dotýkají bodem (tj. 0-simplexem), (B) dva trojúhelníky (2-simplexy) se dotýkají úsečkou (1-simplexem), (C) dva čtyřstěny (3-simplexy) se dotýkají trojúhelníkem (2-simplexem) (zdroj: [A21]). Zobecněním můžeme definovat množinu n-rozměrných simplexů jako množinu složenou ze simplexů dimenze 0 (0-simplex, bod) až n. Takto zobecněný datový model je znázorněn na obr Aplikací tohoto modelu pro třetí rozměr vzniká datový model TEtrahedral Network (kap ), podobně pro druhý rozměr datový model Triangulated Irregular Network (obr. 1.35). Vezme-li v potaz souvislost mezi rozměrem simplexu a počtem vrcholů úplného grafu tak platí, že množina simplexů je tvořena sadou úplných podgrafů. Nicméně množina simplexů jako celek nemusí nutně tvořit úplný graf.

55 1.6. DATOVÉ MODELY PRO 3D GIS 41 Obrázek 1.29: Zobecněný n-rozměrný simplex datový model (zdroj: [A21]). Eulerova charakteristika. Eulerova charakteristika je definována pro rovinné grafy následujícím výrazem: n + f = e + c + 1 (1.1) kde: n... počet uzlů grafu f... počet stěn e... počet hran c... počet komponent grafu Definice 3. Rovinný graf (též planární graf) je graf, pro který existuje takové rovinné nakreslení, že se žádné dvě hrany nekříží. Definice 4. Komponenta grafu je takový souvislý podgraf, který není obsažen v žádném větším souvislém podgrafu. Je to maximální souvislý podgraf. Souvislý graf má právě jednu komponentu. Eulerova charakteristika je například platná pro datový model nepravidelné trojúhelníkové sítě (TIN), jelikož je tento model omezen na 2D topologii a může být tudíž reprezentován rovinným grafem. V případě datového modelu TEtrahedral Network (viz kap ), který je tvořen 3-simplexy, lze model reprezentovat jako K 4 úplný rovinný graf, nicméně kombinace podgrafů již rovinná být nemusí. V případě modelů založených na vícerozměrných simplexech již graf rovinný není a výše zmíněná Eulerova charakteristika neplatí.

56 42 KAPITOLA 1. ÚVOD DO PROBLEMATIKY Tvrzení, že množina simplexů třetího či vyššího rozměru není reprezentována rovinným grafem vychází z Kuratowskiho věty. Kuratowskiho věta. Graf G je rovinný právě tehdy, není-li žádný jeho podgraf izomorfní k dělení grafu K 5 ani K 3,3. K 5 je úplný graf, K 3,3 je úplný bipartitní graf. Definice 5. Dva grafy G = (V, E) a G = (V, E ) nazýváme isomorfní, jestliže existuje bijektivní (vzájemně jednoznačné) zobrazení f : V V tak, že platí: x, y E, právě když f(x), f(y) E. Definice 6. Bipartitním grafem nazýváme graf, u kterého lze množinu vrcholů rozdělit na dvě disjunktní množiny tak, že žádné dva vrcholy ze stejné množiny nejsou spojeny společnou hranou. Oba výše zmíněné grafy jsou znázorněny na obr Obrázek 1.30: Příklad úplných a bipartitních grafů K a,b (zdroj: [A21]). Z obr je patrné, že množina čtyřstěnů může obsahovat podgrafy, které jsou isomorfní k úplným grafům K 5 a K 3,3. Existence těchto podgrafů nás vede k závěru, že množina čtyřstěnů (tj. 3-simplexů) či vícerozměrných simplexů není reprezentována rovinným grafem. V případě sítě nepravidelných čtyřstěnů (viz kap ) lze formulovat následující tvrzení [A26]: počet uzlů + počet trojúhelníků = počet hran + počet čtyřstěnů + 1 Zobecněný vztah pro n rozměrné simplexy lze vyjádřit následovně: 0-simplex + 2-simplex k-simplex = 1-simplex + 3-simplex l-simplex + 1 kde: k... sudé číslo; k < 0, n > l... liché číslo; l < 1, n >

57 1.6. DATOVÉ MODELY PRO 3D GIS 43 Obrázek 1.31: Podgrafy v rámci datového modelu TEN, které jsou isomorfní k podgrafům K 5 a K 3,3. Tlusté linie znázorňují hrany na obvodu podgrafu. (zdroj: [A21]). Complex objekty. Složené (complex) objekty bývají v odborné literatuře označovány jako complexes. Jde o komplexní objekty, které lze rozložit na množinu simplexů. Complex objekty nultého až třetího rozměru jsou znázorněny na obr Obrázek 1.32: Ukázka n-complex objektů: 1-complex (množina navazujících 1-simplexů), 2-complex (jako množina 2-simplexů) a 3-complex (jako množina 3-simplexů) (zdroj: [A21]). Dekompozice 3D objektů na n rozměrné zobecněné trojúhlelníky, tj. simplexy umožňuje topologicky spravovat i komplexní stěny těles, které nemusí být nutně rovinné. Podobně lze rozložit těleso na jednotlivé čtyřstěny, tj. jednoduché 3D objekty. Potom je například výpočet objemu tělesa poměrně jednoduchou záležitostí: je roven součtu objemů čtyřstěnů definujících toto těleso. Pro vyjádření objemu simplexu tvořeného

58 44 KAPITOLA 1. ÚVOD DO PROBLEMATIKY body A 1, A 2,..., A n můžeme použít následující vztah: a 11 a a 1n 1 V (A 1, A 2,..., A n+1 ) = 1 a 21 a a 2n 1 a n! 31 a a 3n a n+1,1 a n+1,2... a n+1,n 1 (1.2) Pro objem čtyřstěnu tedy platí: x V (A, B, C, D) = 1 A y A z A 1 x B y B z B 1 6 x C y C z C 1 x D y D z D 1 (1.3) D Formal Data Structure Formal Data Structure (FDS) představuje jednu z prvních datových struktur pro 3D prostorové objekty zohledňující geometrickou a tématickou složku popisu objektů [A27]. Model definuje čtyři základní geometrické objekty bod (point), linii (line), povrch (surface) a těleso (body), a čtyři základní elementy topologického modelu uzel (node), oblouk (arc), stěnu (face) a hranu (edge). Základní elementy datového modelu FDS jsou znázorněny na obr Obrázek 1.33: Datový model 3D Formal Data Structure (FDS) (zdroj: [A27]). Model definuje základní pravidla, např. v místě průniku oblouku se stěnou musí být umístěn uzel. Hrana má dvě funkce: určuje hranici stěny a na základě její orientace je určeno těleso nalevo a napravo od dané stěny. Hranu tvoří jeden či více oblouků (arcs).

59 1.6. DATOVÉ MODELY PRO 3D GIS 45 Stěny jsou definovány jako rovinné elementy. Povrch (surface) je definován vnější hranici a volitelně i několika vnitřními hranicemi definující otvory. Těleso (body) je určeno vnějším povrchem a může obsahovat několik vnořených těles či otvorů. Model umožňuje průnik elementů rozdílných dimenzí, např. uzel a oblouk mohou ležet na povrchu stěny, podobně uzel či oblouk může být umístěn uvnitř tělesa TEtrahedral Network TEtrahedral Network (TEN) je datový model, který vychází z rozšíření datového modelu nepravidelné trojúhelníkové sítě (TIN) pro 3D prostorové objekty. Rozšířením nepravidelné trojúhelníkové sítě do třetího rozměru vzniká množina nepravidelných čtyřstěnů. Základními elementy datového modelu TEN jsou uzel (node), hrana (arc), trojúhelník (triangle) a čtyřstěn (tetrahedron). Na rozdíl od modelu 3D FDS je jeden ze základních elementů datového modelu 3D objekt (čtyřstěn). Jednotlivé vztahy mezi elementy modelu uzel-hrana a trojúhelník-čtyřstěn jsou znázorněny na obr v podobě relačních datových struktur. Obrázek 1.34: Datový model TEtrahedral Network (TEN) ve formě relačních datových struktur (zdroj: [A22]). Vztahy mezi jednotlivými elementy relačního modelu zobrazeného na obr lze vyjádřit v následujících bodech: 1. Těleso označené identifikátorem BID patří do tématické třídy bclass. 2. Povrch označený identifikátorem SID patří do tématické třídy sclass. 3. Liniový prvek označený identifikátorem LID patří do tématické třídy lclass. 4. Bodový prvek označený identifikátorem P ID patří do tématické třídy pclass.

60 46 KAPITOLA 1. ÚVOD DO PROBLEMATIKY 5. Hrana ARCNR má počáteční uzel node 1 a koncový uzel node Uzel NODENR je dán souřadnicemi X, Y a Z. 7. Trojúhelník T RIN R je součástí alespoň jednoho povrchu T SID. Jsou definovány nanejvýš dva čtyřstěny ten 1 a ten 2, ke kterým může být daný trojúhelník přiřazen. Trojúhelník je definován třemi hranami edge 1, edge 2 a edge Hrana ARCN R reprezentuje nanejvýš jeden liniový prvek ALID. 9. Čtyřstěn T ET N R reprezentuje nanejvýš jeden objemový prvek (těleso) T BID. Těleso (body) je složeno ze čtyřstěnů, povrch (surface) z trojúhelníků, lomená čára (line) z řady navazujících hran a uzel je reprezentován jako bod (point). Základní pravidlo modelu je založeno na předpokladu, že každý uzel je součástí alespoň jedné hrany, každá hrana je součástí alespoň jednoho trojúhelníku a každý trojúhelník alespoň jednoho čtyřstěnu. Singularity jako např. trojúhelník uvnitř čtyřstěnu nejsou povoleny. V souhrnu lze základní pravidla modelu definovat následovně [A21]: 1. Těleso je tvořeno množinou na sebe navazujících čtyřstěnů. 2. Povrch je tvořen množinou trojúhelníků, které současně definují stěny čtyřstěnů. 3. Liniový prvek je tvořen množinou na sebe navazujících hran, které současně definují strany trojúhelníků či hrany čtyřstěnů. 4. Bodový prvek je reprezentován lomovým bodem alespoň jednoho ze čtyřstěnů. Hlavním rozdílem mezi datovými modely TEN a TIN je odkaz mezi hranou (arc) a trojúhelníkem (triangle). V datovém modelu TIN je pro hranu spravován trojúhelník nalevo a napravo od dané hrany, zatímco v datovém modelu TEN je vztah definován v opačném směru, trojúhelník nese odkaz na související tři hrany. Tento rozdíl je znázorněn na obr tečkovanou čarou. Odkaz na trojúhelník nalevo a napravo od hrany není v datovém modelu TEN reflektován vůbec, jelikož ve 3D může být hrana přiřazena k více než dvěma trojúhelníkům. Popis datového modelu TEtrahedral Network lze definovat na základě simplex a complex objektů (obr. 1.35): 1. Instance uzlu (0-simplex) má souřadnice x, y a z. Uzly mohou definovat bodové geoprvky (0-complex objekt). 2. Hrana (1-simplex) je definována jako lomená čára s koncovými body, které jsou označovány jako uzly. Hrany mohou tvořit liniové geoprvky (1-complex objekt).

61 1.6. DATOVÉ MODELY PRO 3D GIS 47 Obrázek 1.35: Porovnání datového modelu TEN a TIN, část modelu platná pro TIN je zvýrazněna modrou barvou. Komponenty modelu platné pouze pro jeden z modelů jsou znázorněny tečkovanou čarou. (zdroj: [A21]). 3. Trojúhelník (2-simplex) je definován třemi na sebe navazujícími hranami. Trojúhelník může být sdílen celkem dvěma čtyřstěny. Trojúhelníky mohou tvořit povrchové geoprvky (2-complex objekt). 4. Čtyřstěn (3-simplex) je definován čtyřmi trojúhelníky. Čtyřstěn je součástí objemového geoprvku (3-complex objekt). UML diagram datového modelu TEN je zobrazen na obr Obrázek 1.36: UML diagram datového modelu TEN (zdroj: [A28]).

62 48 KAPITOLA 1. ÚVOD DO PROBLEMATIKY Simplified Spatial Model Datový model Simplified Spatial Model (SSM) je zaměřen především na aspekty vizualizace. Byl navržen primárně pro webové aplikace, které jsou určeny pro vizualizaci výsledků prostorových dotazů jako 3D objektů v prostředí webového prohlížeče. Na rozdíl od výše zmíněných datových modelů definuje pouze dva základní topologické elementy a to uzel (node) a stěnu (face). V datovém modelu SSM zcela chybí jednorozměrný element, tj. hrana. Na rozdíl od datového modelu TEN (kap ) nepoužívá ani trojrozměrný element, 3D objekty jsou reprezentovány stěnami. Pořadí uzlů definuje stěnu, která musí být navíc rovinná. Obrázek 1.37: Datový model Simplified Spatial Model (SSM) (zdroj: [A29]). Na podobném principu je postaven datový model Urban Data Model (UDM) [A30], kde dochází k dekompozici stěn na trojúhelníky Constructive Solid Geometry V datovém modelu Constructive Solid Geometry (CSG) je objekt reprezentován kombinací předefinovaných jednoduchých geometrických elementů jako je koule, krychle či válec. Elementy datového modelu CSG jsou pravidelné objekty, které lze libovolně kombinovat. Vzhledem k tomu není datový model CSG vhodný pro modelování nepravidelných komplexních objektů. Příklad rozložení modelovaného objektu na tři pravidelné jednoduché geometrické elementy dle datového modelu CSG je znázorněn na obr Datový model CSG se často využívá podobně jako B-rep (kap ) v počítačem podporovaném projektování (CAD) především v kombinaci s jazykem pro modelování objektů.

63 1.6. DATOVÉ MODELY PRO 3D GIS 49 Obrázek 1.38: Rozklad objektu na jednoduché pravidelné geometrické elementy v rámci datového modelu CSG (zdroj: [A21]) Boundary Representation Mezi základní elementy datového modelu Boundary Representation (B-rep) patří bod (point), hrana (edge), stěna (face) a objem (volume). Hrana může být v geometrické reprezentaci kromě lomené čáry reprezentována i obloukem nebo kružnicí. Stěna může být dána komplexním povrchem, např. s využitím Bézierových křivek. Nemusí být tedy nutně rovinného charakteru. Na obr je znázorněn rovinný polygon v datovém modelu B-rep. Objekt je vyjádřen kombinací elementů datového modelu, body formují hrany, hrany dále stěny. Obrázek 1.39: Reprezentace rovinného polygonu v datovém modelu B-rep (zdroj: [A21]). Datový model B-rep je často využíván v oblasti počítačem podporovaného projektování (CAD). Nicméně vzhledem ke své výpočetní komplexnosti a složitosti určování prostorových vztahů je vhodný především pro pravidelné rovinné objekty [A31]. Topologie není v rámci datového modelu B-rep explicitně reprezentována. Vzhledem k tomu je využití datového modelu B-rep podobně jako v případě CSG v oblasti GIS poměrně limitováno.

64 50 KAPITOLA 1. ÚVOD DO PROBLEMATIKY ,8D Z koncepčního hlediska vychází datový model označovaný jako 2,8D z 2D datových modelů. Lze jej vnímat jako jakýsi mezikrok mezi 2,5D a 3D datovými modely. Na rozdíl od 2,5D umožňuje definovat pro bod více než jednu z-ovou souřadnici. Umožňuje modelovat objekty jako jsou vertikální stěny, římsy či balkóny. Geometrická reprezentace elementů modelu je 3D, nicméně topologie je vyjádřena ve 2D. Vzhledem k tomu nelze korektně modelovat objekty jako např. tunely či mosty. Datový model 2,8D popsaný v [A32] používá 2D datové elementy, tj. uzly (nodes), hrany (edges) a stěny (faces). Elementy geometrického modelu mají kromě souřadnice x, y přiřazenu i souřadnici z. Příklad modelování budovy v rámci modelu 2,8D je znázorněn na obr Objekt domu je složen ze šesti stěn, dvou dveří, čtyř stěn reprezentujících střechu (dvě z nich pro převis střechy), pět stěn tvoří komín. Jak naznačuje obr topologie je totožná s 2D, pouze geometrická reprezentace je 3D. Obrázek 1.40: Reprezentace objektu budovy v datovém modelu 2,8D (A), korespondující topologicky ekvivalentní reprezentace ve 2D (B) (zdroj: [A32]) Objektově orientované datové modely Výše popsané datové modely jako např. 3D Formal Data Structure (viz kap ) jsou vhodné pro implementaci v databázových systémech postavených na relačním modelu. V této souvislosti vzniklo několik studií adaptace datových modelů v prostředí objektově orientovaných databázových systémů. Jedním z nich adaptace modelu FDS v prostředí komerčního objektově orientovaného databázového systému Persistent Objects and Extended Database Technology (POET) [A33]. Mezi další objektově orientované datové modely patří Solid Object Mananagement System (SOMAS) [A34] či model uvedený v [A35].

65 1.7. KNIHOVNA CGAL Knihovna CGAL Computational Geometry Algorithms Library (CGAL) ( je open source C++ knihovna, která poskytuje přístup k efektivním a spolehlivým geometrickým algoritmům. Knihovna CGAL má využití v celé šíři vědních oborů jako je např. počítačová grafika, počítačem podporované projektování (CAD), geografické informační systémy (GIS), molekulární biologie, robotika a další. Knihovna CGAL implementuje algoritmy pro Delaunayovu triangulaci a Voroniovy diagramy ve 2D a 3D, operace s polygony a mnohostěny, zobrazení 3D objektů jako sítě polygonů, tvorbu konvexních obalů, vyhledávací struktury jako jsou kd stromové struktury a řadu dalších [A36]. Obrázek 1.41: Logo projektu CGAL (zdroj: [B17]). Projekt CGAL používá tzv. duální licencování. Od verze 4.0 je licencován pod svobodnou licencí GNU GPL/LGPL a současně pod komerční licencí [B18]. Licence GNU GPL umožňuje začlenění této knihovny do systému GRASS tak, jak je naznačeno v kap Metadata Základ slova metadata pochází z řečtiny a může být přeložen jako data o datech. Technická komise ISO/TC 211 definuje metadata jako strukturovaná data popisující obsah, kvalitativní charakteristiky a další vlastnosti geodat. S geodaty přichází do styku poměrně široká skupina uživatelů, kteří v drtivé většině samotná data neprodukují, ale jsou jim pouze poskytována. Dokumentace poskytovaných dat umožňuje uživateli, aby se s nimi blíže seznámil a v další fázi je vhodně ve svém projektu využíval. Poskytovatel či tvůrce geodat může navíc efektivněji data produkovat, skladovat a aktualizovat [A37, B19]. Metadata jsou nezbytným doplňkem pro korektní a přesnou identifikaci, verifikaci a interpretaci geodat. Geodata jsou produkována a využívána experty na poli geodézie, kartografie, geografie, fotogrammetrie, dálkového průzkumu Země, geologie, územního plánování apod. Jednotný počítačový model dané lokace zpravidla tvoří kombinace geodat různých měřítek, souřadnicových systémů a datového obsahu. Poskytování geodat koncovému uživateli vyžaduje

66 52 KAPITOLA 1. ÚVOD DO PROBLEMATIKY vytvoření a implementaci konceptuálních, metodických a legislativních norem pro popis dat včetně pravidel při jejich výměně [B20]. Metadata stojí na rozhraní mezi daty a informacemi 18, jsou prostředníkem k interpretaci, verifikaci a užití dat, viz obr Obrázek 1.42: Interpretace dat (zdroj: [A39]). Základním požadavkem je modularita metadat umožňující vytvořit novou sestavu na základě již existujícího schématu. Například kombinovat elementy definované v různých schématech. Elementy metadat můžeme rozdělit na tři základní typy [A40] (viz obr. 1.43): 1. Obsah metadat ( metadata o metadatech ) jedná se o doplňující informace nezbytné pro správné porozumění metadatům samotným. 2. Katalog metadat ( orientační metadata ) zastřešující základní popis dat v sémantické, geometrické a temporální rovině. 3. Slovník metadat ( konceptuální metadata ) definuje strukturu, sémantiku dat. Obrázek 1.43: Typy elementů metadat (zdroj: [A41]). V tomto ohledu lze definovat minimální nutnou množinu elementů metadat: jednoznačná identifikace datové sady (název, kód, verze), poskytovatel a původní producent dat, licenční omezení, 18 Informace v tomto smyslu je chápána jako údaj o reálném prostředí, o jeho stavu a procesech v něm probíhajících. Data je výraz pro údaje, používané pro popis nějakého jevu nebo vlastnosti pozorovaného objektu [A38].

67 1.8. METADATA 53 prostorový referenční systém, prostorové schéma, sémantika, časový otisk, rozsah s ohledem na geografickou, sémantickou a temporální rovinu, kvalitativní charakteristiky (prostorové, sémantické a temporální), jazyk metadat, syntax s ohledem na přenositelnost datové sady Proces standardizace v oblasti metadat Počátky standardizace se v této oblasti datují do poloviny devadesátých let minulého století. Snahu o vytvoření evropských norem v oblasti geoinformací zastřešovala v letech technická komise CEN/TC 287. Tyto snahy vyústily ve vydání série technických norem CEN ENv, v oblasti metadat se jedná o 12657, Geographic Information Data description Metadata. V současnosti je za evropskou normu považována mezinárodní norma ISO označovaná jako EN-ISO, českou mutací je ČSN-ISO. V roce 1990 byla v U.S.A. založena komise Federal Geographic Data Committee (FGDC), která za svého působení vytvořila sérii národních norem pro poskytování geodat. V roce 1994 byla vydána první verze FGDC Content Standard for Digital Geospatial Metadata (CDGM), verze 2.0 následovala o čtyři roky později. V současné době se pracuje na adaptaci ISO norem 19XXX jako národního amerického standardu [A42]. V mezinárodním měřítku působí normalizační organizace International Standard Organisation (ISO). V rámci organizace ISO existuje technická komise ISO/TC 211 Geographic information/geomatics, jejímž cílem je vytvoření strukturované sady technických norem v oblasti digitálních geografických informací. Tyto normy specifikují metody, nástroje a služby s ohledem na správu geodat, jejich zpracování, možnosti přístupu a převodu mezi různými uživateli či systémy. Tyto snahy se odrážejí v sérii technických norem označovaných jako ISO 19XXX. Řada těchto norem, resp. jejich návrhů, vzniká v úzké spolupráci s organizací Open Geospatial Consorcium (OGC). Rozsáhlé srovnání třech nejrozšířenějších technických norem pro metadata ISO 19115, CEN a FGDC CDGM je uvedeno v [A39] Technická norma ISO Geographic Information Metadata Práce na technické normě ISO (dále pouze norma ) [A43] byly započaty již v roce 1995, k jejímu vydání došlo až v roce Cílem normy je především: možnost důkladné charakteristiky geografických informací, zjednodušení organizace a správy geoinformací,

68 54 KAPITOLA 1. ÚVOD DO PROBLEMATIKY základní informace nutné pro efektivní využití dat. Výběr elementů metadat byl volen s ohledem na čtyři základní požadavky: 1. lokalizaci geografické informace, 2. zhodnocení lokalizovaných dat (kvalitativní charakteristiky, přesnost, prostorová a temporální rovina, obsahová stránka dat) pro daný účel, 3. extrahování dat včetně přístupu a přenosu geodat (formát, médium, cena, licenční podmínky), 4. využití dat s ohledem na kombinaci s daty, která má již uživatel k dispozici. Norma je postavena na abstraktním objektovém modelu a slovníku dat, který zahrnuje kompletní schéma a definici elementů metadat (tab. 1.2). Objektový model je popsán pomocí unifikovaného modelovacího jazyka (UML) [A44]. Metadata jsou prezentována jako UML balíčky (UML Packages). Každý balíček obsahuje několik entit specifikované či generalizované UML třídy (UML Class). Tyto entity obsahují elementy (atributy UML třídy). Tabulka 1.2: Vztah mezi objektovým modelem UML a daty ISO (zdroj: [A43]). objektový model UML balíček generalizovaná třída specifikovaná třída třída atribut asociace slovník dat sekce entita entita entita element element V rámci normy je definováno schéma, které lze aplikovat jak na ucelené datové sady, řady datových sad, tak i na jednotlivé prvky a jejich popis. Kromě toho norma definuje: povinné a podmínkové (tj. za dané podmínky povinné) sekce, entity a elementy, minimální množinu elementů metadat zaručující použitelnost v nejrůznějších aplikacích či službách, volitelné elementy umožňující rozšířit popis dat s ohledem na potřeby poskytovatele a odběratele dat, metody pro rozšíření metadat s ohledem na zvláštní potřeby.

69 1.8. METADATA 55 Možnosti rozšíření. Nástroje pro popis dat uvedené v normě by měly v obecné míře postačovat. Vzhledem k velké diversitě geodat se mohou vyskytnout situace, kdy obecně definované entity nepokrývají všechny potřeby uživatele. Proto norma umožňuje rozšířit definice s ohledem na specifické potřeby. Komunitní profily. Norma definuje více než 300 volitelných elementů. Poskytuje tak poměrně velký prostor nejrůznějším komerčním či vládním organizacím a komunitám vytvářet v rámci ní své vlastní profily a definovat tak řadu elementů jako povinných. Standardizace profilů je podrobně popsána v navazující technické normě ISO Geographic information Profiles. Obrázek 1.44: Schéma komunitního profilu ISO (zdroj: [A43]) Technická norma ISO Geographic Information Metadata XML Schema Implementation Technická norma ISO popisuje tzv. spatial metadata extensible Mark-up Language (smxml) a implementaci XML schématu odvozeného z technické normy ISO 19115, Geographic information Metadata. V souhrnu tato norma poskytuje obecnou specifikaci jazyka XML [A45] pro popis, validaci a výměnu metadat. Norma klade důraz na možnosti rozšíření interoperability s ohledem na konkrétní implementaci standardu ISO Technická norma ISO zahrnuje: jednotné XML schéma odvozené z modelu ISO UML, technologii transformace ISO a souvisejících abstraktních UML modelů do XML schématu na základě ISO Geographic information Profiles.

70 56 KAPITOLA 1. ÚVOD DO PROBLEMATIKY 1.9 Výměnný formát informačního systému katastru nemovitostí Informační systém katastru nemovitostí Informačním systémem katastru nemovitostí (ISKN) rozumíme integrovaný informační systém (IS) primárně určený pro podporu výkonu státní správy a uživatelských služeb katastru nemovitostí [A46]. ISKN obsahuje nástroje umožňující správu souboru popisných a geodetických informací a prostředky pro podporu správních a administrativních činností při samotném vedení katastru nemovitostí a pro správu dokumentačních fondů. ISKN byl uveden do ostrého provozu v září Systém byl navržen tak, aby byla zvýšena jeho celková bezpečnost a bylo možno bezproblémově začlenit data z externích datových zdrojů, včetně efektivního poskytování požadovaných dat z katastru nemovitostí prostřednictvím dálkového přístupu Specifikace výměnného formátu ISKN Data katastru nemovitostí mohou být poskytována veřejnosti také ve formě souborů s definovaným obsahem. Jedná se o tzv. výměnný formát ISKN v textovém tvaru (dále VF ISKN či VFK ). Bližší informace o vývoji tohoto formátu lze nalézt např. v diplomové práci autora [A47]. Datový soubor výměnného formátu ISKN je prostý textový (ASCII) soubor, který obsahuje čtyři základní části: hlavičku &H, datové bloky &B, datové řádky (věty) &D, koncový znak &K. Datový záznam, nebo-li datová věta, je zakončen znaky <CR><LF> (nový řádek), přičemž znak signalizuje, že následující řádek je pokračováním předchozího řádku a tvoří jeden záznam Hlavička souboru Hlavička souboru obsahuje úvodní informace jako je obsah, rozsah dat, aktuálnost dat a omezující podmínky. Datová věta hlavičky začíná znakem &H. Následuje označení položky a příslušné hodnoty oddělené středníkem. Další informace lze nalézt v příloze D.1.

71 1.9. VÝMĚNNÝ FORMÁT ISKN Datové bloky Datové bloky jsou reprezentovány dvěma typy vět: Definice datového bloku (&B) seznam atributů včetně datových typů (tab. 1.3). Jejich pořadí je určující pro další datové záznamy. Tento typ věty v podstatě odpovídá definici tabulky v relačním databázovém systému. Datový záznam (&D) jednotlivé hodnoty jsou odděleny středníkem, odpovídá záznamu v tabulce. Tabulka 1.3: Datové typy výměnného formátu ISKN. kód datový typ číslo za kódem číselný maximální délka položky N 10.2 maximálně 10 číslic a z toho 2 za desetinnou čárkou bez nevýznamných nul kladná čísla bez znaménka T textový maximální délka textové položky D datumový tvar DD.MM.YYYY HH:MI:SS např :24:05 Bližší popis datových bloků a skupin datových bloků lze nalézt v oficiální dokumentaci výměnného formátu ISKN [B21] a také v příloze D.2. Příklad. Definice datové bloku PAR (parcela) a datového záznamu (vše v jednom řádku): &BPAR;ID N30;STAV_DAT N2;DATUM_VZNIKU D;DATUM_ZANIKU D;PRIZNAK_KONTEXTU N1; RIZENI_ID_VZNIKU N30;RIZENI_ID_ZANIKU N30;PKN_ID N30;PAR_TYPE T10; KATUZE_KOD N6;KATUZE_KOD_PUV N6;DRUH_CISLOVANI_PAR N1;KMENOVE_CISLO_PAR N5; ZDPAZE_KOD N1;PODDELENI_CISLA_PAR N3;DIL_PARCELY N1;MAPLIS_KOD N30; ZPURVY_KOD N1;DRUPOZ_KOD N2;ZPVYPA_KOD N4;TYP_PARCELY N1;VYMERA_PARCELY N9; CENA_NEMOVITOSTI N14.2;DEFINICNI_BOD_PAR T100;TEL_ID N30;PAR_ID N30; BUD_ID N30;IDENT_BUD T1 &DPAR; ;0;" :00:00";"";2; ;;;"PKN";675008;;1;100; ;;;6780;2;13;;;113;;""; ;; ;"a"

72 58 KAPITOLA 1. ÚVOD DO PROBLEMATIKY

73 The only way to deal with an unfree world is to become so absolutely free 2 that your very existence is an act of rebellion. Albert Camus Analýza současného stavu řešené problematiky Kapitola shrnuje současný stav vektorové architektury systému GRASS včetně jejího historického vývoje, a to především s ohledem na podporu externích vektorových datových formátů (kap. 2.2) a přístupu k jednoduchým geoprvkům. V kap je rozebrán pojem pseudo-topologie. Dále je popsán nativní vektorový formát GRASS s důrazem na změny v topologickém modelu vektorové knihovny systému GRASS ve verzi 7, viz kap V druhé části kapitoly je popsán současný stav podpory pro práci s 3D vektorovými daty v systému GRASS (kap. 2.3) a správy metadat rastrových a vektorových dat v tomto systému, viz kap Vektorová architektura systému GRASS GIS Úvodní část textu je věnována základním vlastnostem vektorové architektury systému GRASS a jejímu vývoji od první poloviny devadesátých let dvacátého století, konkrétně od GRASS verze 4 a 5 (kap ) až po aktuální verzi GRASS 6 (kap ). Podstatná část textu je věnována vývoji topologického modelu s ohledem na změny mezi verzemi GRASS 6 a 7, viz v kap a Na poznatky topologické správy vektorových dat v systému GRASS navazují hlavní aplikační výstupy disertační práce. Jde o podporu pro externí vektorové formáty jak v režimu přístupu k jednoduchým geoprvkům, tak i v topologické formě geodatabáze Post- GIS. Dále se jedná o rozšíření datového modelu vektorové architektury systému GRASS o 3D topologické elementy. 59

74 60 KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU ŘEŠENÉ PROBLEMATIKY Poznámky k vektorové architektuře systému GRASS verze 4 a 5 Vektorová knihovna ve verzi GRASS 4 (rok vydání 1991) byla označována jako diglib. V letech se v rámci verze GRASS 5 začalo pracovat na nové vektorové knihovně Vlib, která měla svým přepracovaným rozhraním pro programování aplikací (API) ulehčit implementaci nástrojů systému GRASS pro přístup k vektorovým datům. Plnohodnotné implementace se knihovna Vlib dočkala až v letech ve verzi GRASS 6, což mimo jiné vyžadovalo kompletní přepsání všech existujících nástrojů systému GRASS určených pro zpracování vektorových dat, více v kap Vektorová architektura systému GRASS ve verzi 4 a 5 podporovala pouze 2D vektorová data, byly definovány dva typy liniových elementů hranice plochy (area edge) a linie (line). Správa bodových dat byla separována do zvláštní knihovny Sites Library a nebyla tak součástí vektorové knihovny označované jako diglib. Vektorovému geoprvku mohl být přiřazen nanejvýš jeden celočíselný atribut tzv. číselná kategorie (category number). Formát vektorových dat. Vektorová mapa byla uložena v několika souborech umístěných v odpovídajících adresářích mapsetu. Název souboru vždy odpovídal názvu vektorové mapy, viz tab Tabulka 2.1: Struktura nativního vektorového formátu GRASS verze 4 a 5. adresář dig dig_ascii dig_att dig_cats dig_plus reg popis binární soubor, geometrická složka popisu geoprvků textový soubor, geometrie ve formátu GRASS ASCII textový soubor, atributová složka textový soubor, kategorie, reprezentační body binární soubor, topologie textový soubor, registrační body digitizéru Geometrická složka popisu geoprvků byla uložena v binárním souboru umístěném v adresáři dig a volitelně i v textovém ASCII formátu (adresář dig_ascii). Číselné kategorie byly uloženy v textové formě v adresáři dig_att. Každý řádek obsahoval informaci o kategorii daného vektorového geoprvku typ geoprvku (A pro plochu, L pro liniový geoprvek), souřadnici reprezentačního bodu (x, y) a číslo kategorie. Souřadnice reprezentačního bodu musela být jednoznačná, tak aby umožňovala nalezení geoprvku v souboru s geometrickou složkou popisu (soubor v adresáři dig). Geoprvku mohla být přiřazena maximálně jedna kategorie, tj. řádek v souboru umístěném v adresáři dig_att. Příklad. Plošnému prvku (A) je přiřazena kategorie 7 a liniovému prvku (L) kategorie 2. A L

75 2.1. VEKTOROVÁ ARCHITEKTURA SYSTÉMU GRASS GIS 61 Kategorii mohl být přiřazen krátký popisek (tzv. štítek). Tyto popisky byly uloženy v textové formě v adresáři dig_cats Vektorová architektura systému GRASS verze 6 Z historických důvodů byla vektorová knihovna Vlib implementována nad stávající modifikovanou vektorovou knihovnou diglib převzatou z GRASS verze 5 (kap ). Vektorová architektura GRASS verze 6 tak velmi výrazně navazuje na generaci GRASS verze 5 [A48]. Hlavní motivací bylo překonat limity vektorové architektury GRASS verze 5, tj. podporu pouze 2D vektorových dat a velmi omezenou možnost připojení atributových dat (pouze jeden atribut na vektorový geoprvek!). Dalším cílem bylo zjednodušení rozhraní pro programování aplikací (API) vektorové knihovny. Příklad. Následuje ukázka zdrojového kódu pro určení x-ové souřadnice reprezentačního bodu (centroidu) plochy s identifikátorem 1 : 1 int area_ num ; /* idenfik á tor plochy */ 2 double xx; /* x- ov á sou ř adnice centroidu plochy */ 3 4 struct Map_ info Map ; /* vektorov á mapa */ 5 struct line_ pnts * line_ p ; /* geometrie vektorov é ho elementu */ 6 7 /* alokovat prostor pro datovou strukturu line_ pnts */ 8 line_ p = Vect_ new_ list_ struct (); 9 10 /* otev ř í t vektorovou mapu urbanareas z mapsetu PERMANENT 11 v režimu č ten í */ 12 Vect_open_old (& Map, " urbanareas ", " PERMANENT "); /* nastavit id plochy */ 15 area_ num = 1; Korespondující část zdrojového kódu GRASS verze /* zí skat x-vou sou ř adnici bodu */ 11 xx = Map. Att [ Map. Area [ area_num ]. att ].x; API vektorové knihovny GRASS verze 6 bylo rozšířeno o funkce s prefixem Vect_, které přímý přístup k vnitřním datovým strukturám knihovny před programátorem skrývají. V uvedeném případě nejprve zjistíme identifikátor centroidu (řádek 11) dané plochy a poté načteme geometrii centroidu (řádek 14) do datové struktury line_pnts.

76 62 KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU ŘEŠENÉ PROBLEMATIKY 10 /* z í skat id centroidu dan é plochy */ 11 centroid = Vect_get_area_centroid (Map, area_num ); 12 /* na č í st geometrii centroidu do datov é struktury 13 line_pnts ( line_p ) */ 14 Vect_read_line (Map, line_p, NULL, centroid ); 15 /* zí skat x-vou sou ř adnici prvn ího bodu ( index 0) */ 16 xx = line_p ->x [0]; Vektorová architektura GRASS verze 6 překonává limity svého předchůdce GRASS 5 především možností uložit atributová data v externím relačním databázovém systému a částečnou podporou 3D vektorových dat [A48]. Kromě nativního topologicky orientovaného formátu byla implementována prvotní podpora pro externí vektorové GIS formáty v rámci tzv. OGR rozhraní (více k tomuto tématu v kap. 2.2). Mezi zásadní vlastnosti vektorové architektury GRASS verze 6 patří: category-set k vektorovým geoprvkům lze přiřadit popisná data z více atributových tabulek, 2/3D podpora 2D a 3D vektorových dat (implementována byla pouze topologická správa pro 2D vektorová data), multiformát nativní podpora externích GIS formátů (např. Esri Shapefile, MapInfo, PostGIS atd.), portabilita na platformě nezávislý nativní formát dat, dglib podpora pro síťové analýzy (knihovna GRASS Directed Graph Library), prostorový index založen na R-stromech, multiatributy atributová data uložena v externích relačních databázových systémech. Topologický model vektorové architektury GRASS verze 6 vychází do jisté míry z datového modelu Node-Arc-Area, viz kap Z pohledu geometrie je liniový element (arc) uložen jako sekvence bodů o daných souřadnicích. Segment linie je definován dvěma po sobě následujícími lomovými body (vertices). Vektorová data uložená v nativním datovém formátu mohou obsahovat libovolnou kombinaci typů vektorových elementů. Ke geoprvkům lze přiřadit jednu nebo i více číselných kategorií (category number).

77 2.1. VEKTOROVÁ ARCHITEKTURA SYSTÉMU GRASS GIS 63 Vektorová knihovna definuje čtyři základní typy 2D 1 vektorových elementů, které současně představují topologické elementy v rámci datového modelu systému GRASS: bod (point) bezrozměrný element lokalizovaný souřadnicemi x, y(, z), linie (line) lomená čára, orientovaná sekvence vzájemně propojených lomových bodů, koncové body linie jsou označovány v topologickém modelu jako uzly (nodes), hraniční linie (boundary) linie definující segment hranice plochy, reprezentační bod plochy (centroid) bod umístěný uvnitř sekvence na sebe navazujících hraničních linií, které tvoří topologicky uzavřený celek, definující hranici plochy. Vektorová knihovna definuje plošné 2D topologické elementy: plocha (area): topologická kompozice centroidu a sekvence hraničních linií, které tvoří uzavřený celek, ostrov (isle): izolovaná plocha, anebo skupina sousedících ploch tvořících jeden celek. Obdobně zavádí vektorová knihovna 3D vektorové elementy: stěna (face): 3D plocha (obdoba uzavřené hraniční linie ve 3D), reprezentační bod tělesa (kernel): 3D centroid (obdoba reprezentačního bodu plochy ve 3D). Na závěr uvedeme objemové 3D topologické elementy: těleso, objem (volume): topologická kompozice kernelu a sady stěn definující uzavřený celek, díra (hole): topologická kompozice sady stěn bez kernelu lokalizovaná uvnitř tělesa. Implementace topologické správy 3D vektorových dat zůstala v GRASS verzi 6 nedokončena. Tato verze umožňuje ukládat vektorové elementy typu stěny či kernelu, neumožňuje z nich ale sestavovat objemové topologické elementy a dále je spravovat. Bod, linie, hraniční linie, centroid, stěna a kernel představují v datovém modelu vektorové architektury systému GRASS verze 6 základní typy elementů (tab. 2.2). Plochu a objem lze označit za složené topologické elementy, které jsou utvářeny základními typy elementů. Plošný element označovaný jako ostrov (isle) reprezentuje izolovanou plochu nebo množinu sousedících ploch. Ostrov je definován hranicí, která se nedotýká vnější hranice plochy, ve které ostrov leží. Obdobně je definován otvor, dutina (hole) pro 3D složený element objemu. 1 Pokud je definována z-tová souřadnice označujeme tyto vektorové elementy jako 2,5D.

78 64 KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU ŘEŠENÉ PROBLEMATIKY Tabulka 2.2: Elementy datového modelu vektorové knihovny GRASS verze 5 a 6. element GRASS 5 rozměr GRASS 6 rozměr bod knihovna Sites 2D point 2D/2,5D linie line 2D line 2D/2,5D hraniční linie area edge 2D boundary 2D/2,5D centroid centroid 2D centroid 2D/2,5D plocha area 2D area 2D/2,5D stěna face 3D kernel kernel 3D objem díra Formát vektorových dat. Nativní vektorový formát GRASS ve verzi 6 doznal oproti svému předchůdci z verze GRASS 5 (kap ) výrazných změn. Podobně jako jeho předchůdce je souborově orientovaným formátem, nicméně jeho struktura se zásadně liší, viz tab. 2.1 a tab Vektorová mapa je reprezentována několika soubory uloženými v adresáři odpovídajícím jejímu názvu: $MAPSET/vector/<název vektorové mapy> Význam jednotlivých souborů v adresáři s vektorovou mapou popisuje tab Tabulka 2.3: Struktura nativního vektorového formátu GRASS verze 6. soubor coor topo cidx head dbln hist popis binární soubor, geometrická složka popisu geodat binární soubor, topologie binární soubor, index kategorií textový soubor, hlavičkové informace (metadata) textový soubor, informace o připojení atributových tabulek textový soubor, historie příkazů Z výše uvedeného přehledu vyplývá, že prostorový index není ukládán do souboru na disku, nýbrž je sestavován vektorovou knihovnou při načítání souboru s topologickými informacemi (soubor topo). To samozřejmě prodlužuje čas potřebný pro otevření vektorové mapy. V případě extrémně rozsáhlých vektorových datový sad může čas nutný pro sestavení prostorového indexu dosahovat až několika desítek sekund.

79 2.1. VEKTOROVÁ ARCHITEKTURA SYSTÉMU GRASS GIS Topologická správa vektorových dat ve verzi GRASS 6 Vektorová knihovna GRASS verze 6 používá pro správu topologie 2D vektorových dat celkem čtyři datové struktury P_node, P_line, P_area a P_isle. Datová struktura P_node se používá pro reprezentaci uzlů bezrozměrného topologického elementu, který určuje počáteční či koncový bod liniového elementu. Uzel se používá i pro reprezentaci bodových elementů, tj. bodu a centroidu. Datová struktura P_line slouží pro uložení topologických informací pro vektorové elementy typu bod, linie, hraniční linie a centroid. Datová struktura P_area nese topologické informace o ploše, která vzniká kompozicí množiny hraničních linií a volitelně centroidu umístěného uvnitř této plochy. Plocha či skupina sousedících ploch formují ostrov. Datová struktura P_isle ukládá topologické informace o ostrově, který je definován jako plocha bez centroidu lokalizovaná uvnitř jiné plochy. Na obr. 2.1 je znázorněna kompozice několika jednoduchých geoprvků, a to bodu, lomené čáry a dvou sousedících polygonů. V jednom z polygonů je umístěn otvor. Obrázek 2.1: Reprezentace bodu, linie a dvou polygonů v topologickém modelu vektorové architektury GRASS verze 6. Bod (id 1) je reprezentován v topologickém modelu uzlem n 1 jako degenerovaná hrana se stejným počátečním a koncovým uzlem. Lomená čára je určena jednou linií (id 2) definovanou počátečním uzlem n 2 a koncovým uzlem n 3. Polygony jsou reprezentovány dvěma plochami. Třetí plocha definuje otvor ve druhém polygonu. První plocha je kompozicí dvou hraničních linií (id 3, 4) a centroidu (id 5), hraniční linie sdílí uzly n 4 a n 5. Druhá plocha

80 66 KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU ŘEŠENÉ PROBLEMATIKY je dána dvěma hraničními liniemi (id 4, 6) a centroidem (id 7). Třetí plocha nemá definován centroid a je ohraničena uzavřenou hraniční linii (id 8). Centroidy (id 5 a 7) definující reprezentační body první a druhé plochy jsou v topologickém modelu reprezentovány jako uzly (n 6 a n 7 ). Tyto tři plochy formují celkem dva ostrovy. První a druhá plocha formuje první ostrov, druhý ostrov je definován třetí plochou. Správu topologických informací lze prezentovat ve formě tabulek rozdělených podle typu topologických elementů na tabulku uzlů (tab. 2.4), elementů (tab. 2.5), ploch (tab. 2.6) a ostrovů (tab. 2.7). Do elementů počítáme kromě hran (v terminologii topologického modelu systému GRASS linií a hraničních linií) také body a centroidy. To odpovídá výše zmíněným datovým strukturám P_node, P_line, P_area a P_isle. Každý uzel (tab. 2.4) má přiřazen jednoznačný identifikátor (id) a seznam elementů, které jsou s tímto uzlem spojeny (kladné id odkazuje na element, pro který je daný uzel počátečním uzlem, v případě záporného id jde o koncový uzel), viz datová struktura P_node. Tabulka 2.4: Topologický model GRASS verze 6: tabulka uzlů (viz obr. 2.1). uzel počet elementů id elementu Topologický element (tab. 2.5) nese informaci o svém typu (bod, linie, hraniční linie, centroid). Dále o počátečním a koncovém uzlu a zároveň také o id plochy lokalizované nalevo a napravo od daného elementu. V případě centroidu je použit atribut id plochy nalevo pro plochu, ke které je tento centroid vztažen. U bodových dat je využit typ elementu, ostatní atributy pouze zabírají místo v paměti počítače. Obdobně u linií (které nemohou ze své definice tvořit hranici plochy) postrádá smysl atribut id plochy nalevo a napravo. V případě centroidu není využit atribut id plochy napravo. Z toho vyplývá značná neefektivita vnitřních datových struktur topologického modelu GRASS verze 6. Tento fakt se znatelně projevuje především u bodových geoprvků, které by součástí topologického modelu neměly být vůbec.

81 2.1. VEKTOROVÁ ARCHITEKTURA SYSTÉMU GRASS GIS 67 Tabulka 2.5: Topologický model GRASS verze 6: tabulka topologických elementů (viz obr. 2.1). element typ elementu počáteční koncový plocha plocha uzel uzel nalevo napravo 1 bod linie hraniční linie hraniční linie centroid hraniční linie centroid hraniční linie Topologické informace plošných elementů (tab. 2.6) zahrnují seznam hraničních linií, počet ostrovů a id centroidu vztaženého k danému plošnému elementu. Hraniční linie jsou řazeny ve směru hodinových ručiček. Záporné id označuje hraniční linie, které mají směr opačný. Tabulka 2.6: Topologický model GRASS verze 6: tabulka ploch (viz obr. 2.1). plocha počet hraničních seznam hranic počet ostrovů centroid linií 1 2-3, , 6, Podobně jako plochy, tak i ostrovy (tab. 2.7) jsou definovány seznamem hraničních linií, které je formují. Na rozdíl od ploch jsou řazeny proti směru hodinových ručiček, záporné id označuje linie ve směru hodinových ručiček. Dále existuje odkaz na id plochy, v rámci které je ostrov lokalizován. Plocha s id 0 odpovídá neexistující ploše, v podstatě se jedná o universal face tak, jak je definována v topologickém modelu Topo- Geo (viz kap ). Tabulka 2.7: Topologický model GRASS verze 6: tabulka ostrovů (viz obr. 2.1). ostrov počet hraničních seznam hranic plocha linií 1 2 3,

82 68 KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU ŘEŠENÉ PROBLEMATIKY Změny v topologické správě vektorových dat ve verzi GRASS 7 Optimalizace datových struktur P_node, P_line, P_area a P_isle vektorové knihovny GRASS verze 7 byla na počátku roku 2011 navržena a implementována jedním z vývojářů systému GRASS, členem GRASS Development Team Markusem Metzem 2. Přestože se, vyjma konzultací, na této implementaci autor předložené disertační práce nepodílel, budou tyto změny popsány hlavně s ohledem na navazující část, tj. integraci PostGIS Topology ve vektorové architektuře systému GRASS (kap ) a rozšíření topologického modelu o 3D elementy (kap ). Topologický model GRASS verze 7 navazuje na svého předchůdce (viz kap ). Uvedené změny nepostihují pouze správu topologie vektorových dat, ale i prostorový index a index kategorií. Optimalizované datové struktury pro jednotlivé typy topologických elementů velmi výrazně snižují paměťové nároky pro sestavení topologie 2D vektorových dat. Optimalizace datových struktur se nejvíce projevuje u bodových dat, kde paměťové nároky pro sestavení topologie klesají přibližně o 70%. Jak již bylo zmíněno v kap , topologické elementy reprezentující body, linie, hraniční linie a centroidy nesou příliš rozdílnou informaci nato, aby byly v topologickém modelu zastoupeny pouze jednou unifikovanou datovou strukturou P_line. V rámci optimalizace datových struktur topologického modelu GRASS verze 7 byly topologicky relevantní informace přesunuty z datové struktury P_line do sady datových struktur, které byly navrženy přímo pro daný typ topologického elementu. Datová struktura P_line obsahuje ukazatel na typově specifickou datovou strukturu P_topo_l, P_topo_b či P_topo_c (řádek 10). 1 struct P_ line 2 { 3 /* typ vektorov é ho elementu 4 - bod, linie, hrani č n í linie, centroid */ 5 char type ; 6 /* offset vektorov é ho elementu v souboru s geometri í ( coor ) */ 7 off_ t offset ; 8 /* ukazatel na datovou strukturu s topologick ý mi 9 informacemi - P_ topo_ l, P_ topo_ b č i P_ topo_ c */ 10 void * topo ; 11 }; 2 Optimalizace datových struktur pro správu topologie 2D vektorových dat (autor: Markus Metz), SVN revize r46898.

83 2.1. VEKTOROVÁ ARCHITEKTURA SYSTÉMU GRASS GIS 69 Z topologického modelu vektorové architektury GRASS verze 7 byly odstraněny informace o bodech, resp. bodové elementy nejsou v topologickém modelu reprezentovány uzlem. Z tohoto pohledu topologický model GRASS verze 7 splňuje jednu z podmínek datového modelu Node-Arc-Area (kap ): uzel musí být navázán alespoň na jednu hranu. Zůstaneme-li u 2D vektorových elementů, tak topologický model shromažďuje relevantní informace pouze o liniích, hraničních liniích a centroidech. Na základě hraničních linií a centroidů jsou sestaveny topologické informace o plochách a ostrovech. V případě linií je definován pouze identifikátor počátečního a koncové uzlu. Tím je určen směr linie. Jedná se o datovou strukturu P_topo_l. 1 typedef int plus_ t ; 2 3 /* Topologick ý element : linie */ 4 struct P_ topo_ l 5 { 6 /* id počátečního uzlu */ 7 plus_t N1; 8 /* id koncov ého uzlu */ 9 plus_t N2; 10 }; Topologické informace hraničních linií jsou kromě počátečního a koncového uzlu rozšířeny o identifikátor plochy nalevo a napravo. 1 /* Topologick ý element : hrani č n í linie */ 2 struct P_ topo_ b 3 { 4 /* id počátečního uzlu */ 5 plus_t N1; 6 /* id koncov ého uzlu */ 7 plus_t N2; 8 /* id plochy nalevo ( z á porn é id pro ostrov ) */ 9 plus_ t left ; 10 /* id plochy napravo ( z á porn é id pro ostrov ) */ 11 plus_ t right ; 12 }; Poslední z topologických datových struktur pro 2D vektorová data patří centroidům, kde je relevantní pouze jedna informace, a to identifikátor plochy, vůči které je daný centroid vztažen.

84 70 KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU ŘEŠENÉ PROBLEMATIKY 1 /* Topologick ý element : centroid */ 2 struct P_ topo_ c 3 { 4 /* id plochy v ů č i kter é je centroid vzta ž en 5 z á porn é id pro duplicitn í centroid 6 */ 7 plus_ t area ; 8 }; V případě kompozice uvedené v kap na obr. 2.1 se zmenší počet uzlů o tři (jeden bod a dva centroidy). Uvedená topologická kompozice interpretovaná vektorovou knihovnou GRASS verze 7 je znázorněna na obr Obrázek 2.2: Reprezentace bodu, linie a dvou polygonů v topologickém modelu vektorové architektury GRASS verze Podpora pro externí vektorové GIS formáty v systému GRASS verze 6 Proces integrace podpory externích formátů ve vektorové knihovně systému GRASS začal v roce 2001 implementací nativního rozhraní pro formát Esri Shapefile a PostGIS. V roce 2004, tj. ještě před vydáním verze GRASS 6.0, byla podpora pro tyto dva datové formáty z vektorové knihovny odstraněna, a to hlavně z důvodu jejich nedokončené integrace. Do verze GRASS 6.0 se naopak dostalo rozhraní integrující knihovnu OGR (kap. 1.4). Rozhraní OGR vektorové knihovny systému GRASS doplnilo podporu pro celou řadu vektorových GIS formátů včetně Esri Shapefile a PostGIS.

85 2.2. PODPORA PRO EXTERNÍ VEKTOROVÁ DATA VE VERZI GRASS 6 71 Rozhraní OGR bylo vyvíjeno od roku 2002, ale jeho vývoj později stagnoval. Po vydání verze GRASS 6.0 nebylo rozšiřováno, ani uživateli příliš používáno. Většina nástrojů systému GRASS má méně či více závažné problémy se zpracováním externích vektorových dat připojených přes toto rozhraní. Uživatelé jsou tak ve výsledku nuceni externí vektorová data před dalším zpracováním nejprve konvertovat do nativního vektorového formátu GRASS a teprve potom s nimi dále pracovat. Příklad. Data ve vektorovém formátu podporovaného knihovnou OGR lze ve verzi GRASS 6 registrovat jako standardní vektorovou mapu pomocí modulu v.external, např. GRASS> v.external dsn=/opt/ncshape layer=railroads zaregistruje datovou vrstvu ve formátu Esri Shapefile railroads z adresáře /opt/ncshape. GRASS> v.external dsn="pg:dbname=pgisnc" layer=geodetic_pts \ output=geodeticke_body Ve druhém uvedeném případě zaregistruje modul v.external PostGIS tabulku geodetic_pts z geodatabáze pgisnc. Vektorová mapa bude pojmenována jako geodeticke_body. Nativní podpoře geodatabáze PostGIS v systému GRASS se podrobněji věnuje kap a 4.2. Vzhledem k tomu, že knihovna OGR implementuje specifikaci OGC Simple Features Access (viz kap ), k vektorových datům přistupuje jako k jednoduchým geoprvkům. Tento fakt vzhledem k tomu, že vektorový model, který GRASS používá je striktně topologický, nutil vývojáře systému GRASS, pro externí data dostupná přes rozhraní knihovny OGR, implementovat tzv. pseudo-topologii. Vektorová knihovna systému GRASS přistupuje k vektorových datům ve dvou úrovních: bez topologie nebo včetně topologie. Nicméně většina nástrojů systému GRASS vyžaduje úroveň přístupu k vektorovým datům včetně topologie. Problematice pseudo-topologie sestavované pro jednoduché geoprvky se věnuje kap a částečně i příloha B Podpora geodatabáze PostGIS ve vektorové architektuře systému GRASS verze 6 Pokusy o nativní podporu PostGIS ve vektorové architektuře systému GRASS sahají do roku V souvislosti s vývojem vektorové knihovny GRASS verze 5.1 se skupina studentů z University Sannio (Itálie) pod vedením profesora Giuliana Antoniola věnovala implementaci projektu nazvaného PostGRASS, jako rozšíření vznikající vektorové architek-

86 72 KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU ŘEŠENÉ PROBLEMATIKY tury systému GRASS verze 5.1 pro nativní podporu geodatabáze PostGIS 3. PostGRASS skončil u prvotní implementace, nebyl dále rozvíjen a později nebyl ani začleněn do vznikající vektorové architektury GRASS verze 6. Jediná ucelenější zmínka o projektu PostGRASS je uvedena v [A48] a to v souvislosti s vývojem vektorové architektury GRASS 5.1, ze které byla později odvozena vektorová architektura GRASS verze 6. Vektorová data z geodatabáze PostGIS jsou v systému GRASS 6 dostupná v rámci již zmiňovaného rozhraní OGR. Režim přístupu je omezen pouze na čtení a datový model jednoduchých geoprvků. V tomto ohledu je podpora PostGIS ve verzi GRASS 6 limitována knihovnou OGR. Geodatabáze PostGIS je knihovnou OGR otevřena jako tzv. datový zdroj (data source) a tabulka obsahující geodata jako tzv. vrstva (OGR Layer). Příklad. Následuje ukázka praktické demonstrace vytvoření vektorové mapy jako odkazu na tabulku s geodaty z databáze PostGIS. V našem případě vytvoříme odkaz na PostGIS vrstvu urbanareas z geodatabáze pgisnc. Název databáze je předán modulu v.external pomocí parametru dsn, který v tomto případě odpovídá zápisu datového zdroje (datasource name) pro knihovnu OGR. V případě geodatabáze PostGIS data source začíná prefixem PG: následovaným řetězcem akceptovatelným pro funkci PQconnectdb() z knihovny libpq (kap ). Tento řetězec obsahuje dvojice klicove_slovo=hodnota oddělené alespoň jedním bílým znakem. V našem případě jde o předání pouze jednoho parametru, a to názvu databáze (dbname). Dále je nutné pro modul v.external definovat název OGR vrstvy (tj. PostGIS tabulky s geodaty) pro kterou bude odkaz vytvořen (parametr layer) a název výstupní vektorové mapy (parametr output). Parametr output je volitelný. Pokud není zadán, tak název výstupní vektorové mapy odpovídá názvu PostGIS tabulky. GRASS> v.external dsn=pg:dbname=pgisnc layer=urbanarea output=urbanarea_pg... Building pseudo-topology over simple features Number of nodes: Number of boundaries: 664 Number of centroids: 657 Number of areas: 664 Number of isles: 664 Number of areas without centroid: 7 3 Oznámení projektu PostGRASS (červen 2002), postgis-devel/2002-june/ html.

87 2.2. PODPORA PRO EXTERNÍ VEKTOROVÁ DATA VE VERZI GRASS 6 73 Modul v.external pro vzniklou vektorovou mapu urbanarea_pg vytvoří pseudo-topologii (tj. soubory topo a fidx), více v kap Kromě toho obsahuje adresář vektorové mapy v GRASS databance soubor frmt, který v tomto případě vypadá následovně: FORMAT: ogr DSN: PG:dbname=pgisnc LAYER: urbanarea Připomeňme, že k takto vytvořené vektorové mapě lze přistupovat pouze v režimu čtení, jinými slovy nelze modifikovat geometrii ani atributy geoprvků. Například pokus o odstranění vektorového elementu s identifikátorem 1 skončí chybou. GRASS> v.edit map=urbanarea_pg tool=delete id=1 ERROR: OGR format cannot be updated Podobně nelze modifikovat atributová data. Konkrétním důvodem je chybějící implementace funkce db_execute_immediate() v OGR ovladači knihovny DataBase Management Interface (DBMI). Například pokus o přidání nového atributového sloupce skončí také chybou. GRASS> v.db.addcol map=urbanarea_pg column="vymera double precision" dbmi: db_execute_immediate() not implemented ERROR: Error while executing: ALTER TABLE urbanarea ADD COLUMN vymera double precision Pseudo-topologie Vektorová architektura systému GRASS byla od svého počátku (viz kap ) navržena čistě pro práci s topologickými daty. Později v rámci snah o integraci knihovny OGR byl řešen problém začlenění netopologického datového modelu této knihovny, který je postaven na specifikaci OGC Simple Features Access (kap ), v ryze topologickém prostředí vektorové architektury systému GRASS. Zásadní přepracování vektorové architektury a především drtivé většiny nástrojů pro zpracování vektorových dat umožňující práci s jednoduchými geoprvky, nepřicházelo v úvahu hned z několika důvodů. Kromě omezeného počtu vývojářů by to byl pro GRASS jakýsi úkrok stranou. Již od svého počátku je totiž systém GRASS čistě topologickým GIS. Nástroje systému GRASS vyžadují na vstupu konzistentní topologická data. To klade na uživatele vyšší nároky, na druhou stranu jsou výsledkem práce vždy topologicky korektní vektorová data. Problém byl řešen integrací tzv. pseudo-topologie. Tato forma topologie je sestavována pouze pro externí vektorová data přístupná přes OGR rozhraní vektorové knihovny systému GRASS. Jak již napovídá použitý termín, nejde o skutečné topologické informace. Jedná se o sestavení topologických informací kompatibilních s datovým modelem vektorové

88 74 KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU ŘEŠENÉ PROBLEMATIKY architektury systému GRASS nad geometrií jednoduchých geoprvků bez jejich konverze do topologického formátu, tj. bez rozložení geometrické složky popisu jednoduchých geoprvků na topologické elementy datového modelu systému GRASS. Cílem pseudo-topologie je umožnit nástrojům systému GRASS, které byly původně navrženy pro striktně topologický vektorový formát, přistupovat k jednoduchým geoprvkům v rámci OGR rozhraní vektorové knihovny. Rozdíl mezi topologií sestavovanou pro vektorová data v nativním formátu GRASS a pseudo-topologií pro externí vektorová data ve formě jednoduchých geoprvků načítaných přes rozhraní OGR vektorové knihovny systému GRASS osvětlíme na názorném příkladě. Kompozice dvou ploch včetně otvoru v jedné z nich je znázorněna na obr Obrázek 2.3: Reprezentace jednoduchých geoprvků po převodu do topologického modelu GRASS (A) a sestavení pseudo-topologie na základě jednoduchých geoprvků (B) (autor: Martin Landa, 2013). V případě jednoduchých geoprvků jsou plochy vyjádřeny geometrickým typem Polygon. Polygony jsou definovány vnější hranicí, druhý polygon má přiřazenu navíc jednu vnitřní hranici definující otvor v polygonu. V topologickém modelu GRASS (tj. po konverzi jednoduchých geoprvků do nativního formátu GRASS) bude tato kompozice vyjádřena množinou základních topologických elementů jako jsou uzly, hraniční linie a centroidy. V tomto případě konkrétně třemi uzly (n 1, n 2 a n 3 ) navázanými na čtyři hraniční linie (1, 2, 3, 6). Dále jsou součástí modelu i dva

89 2.2. PODPORA PRO EXTERNÍ VEKTOROVÁ DATA VE VERZI GRASS 6 75 centroidy (4, 5). Směr hraničních linií je určen počátečním a koncovým uzlem, např. pro hraniční linii 1 je počátečním uzlem n 1 a koncovým uzlem n 2. V případě vytvoření vektorové mapy jako odkazu (viz modul v.extrenal) na jednoduché geoprvky je pro potřeby vektorové knihovny systému GRASS vytvořena tzv. pseudotopologie. Vnější hranice polygonu jsou reprezentovány virtuálními (geometrie topologických elementů není nikde uložena) hraničními liniemi 1 a 3. Počáteční a koncový uzel pro tyto hraniční linie je totožný (n 1 ). Vnitřní hranice druhého polygonu je reprezentována hraniční linií 4 s počátečním a koncovým uzlem n 2. Hraniční linie je v pseudo-topologickém modelu vždy uzavřena, tj. počáteční a koncový uzel je totožný. Společná hranice ploch, která je v topologickém modelu reprezentována hraniční linií 2 je v pseudo-topologii uložena dvakrát jako segment hraniční linie 1 a 3. Plochy jsou v datovém modelu GRASS reprezentovány centroidem a množinou hraničních linií, které tvoří uzavřený celek (viz obr. 2.4). V našem případě vzniknou tři plochy. První je ohraničena hraničními liniemi 1 a 2, druhá plocha hraničními liniemi 2 a 3, třetí plocha hraniční linií 6. Uvnitř první a druhé plochy je lokalizován centroid 4, resp. 5. Třetí plocha nemá definován žádný centroid. Obrázek 2.4: Sestavení ploch v topologickém modelu GRASS (A) a v rámci pseudo-topologie pro jednoduché geoprvky (B) (autor: Martin Landa, 2013). V případě pseudo-topologie každá hraniční linie definuje právě jednu plochu, v tomto případě je první plocha definována hraniční linií 1, druhá plocha hraniční linií 3 a třetí plocha hraniční linií 4. Pro první a druhou plochu je přidán v rámci pseudo-topologie virtuální centroid 2, resp. 5. Třetí plocha reprezentující otvor v polygonu centroid nemá. Ostrovy jsou v topologickém modelu GRASS definovány izolovanými plochami nebo souvislou množinou ploch (obr. 2.5). V našem případě vzniknou dva ostrovy, první je ohraničen hraničními liniemi 1 a 3. Druhý ostrov je stejně jako třetí plocha definován hraniční linií 6.

90 76 KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU ŘEŠENÉ PROBLEMATIKY Obrázek 2.5: Sestavení ostrovů v topologickém modelu GRASS (A) a v rámci pseudo-topologie pro jednoduché geoprvky (B) (autor: Martin Landa, 2013). V rámci pseudo-topologie platí, že každá plocha definuje ostrov. V tomto případě vzniknou tři ostrovy, které odpovídají dříve sestaveným plochám. Podrobná analýza postupného sestavovaní topologie pro vektorová data v nativním topologickém formátu GRASS a pseudo-topologie pro jednoduché geoprvky je uvedena v příloze B. 2.3 Podpora pro 3D vektorová data ve verzi GRASS 6 Částečná podpora pro 3D vektorová data byla implementována již ve verzi GRASS 6. Vektorové elementy, jako jsou body, linie, hraniční linie a centroidy, mohou mít definovánu volitelně z-tovou souřadnici. V tomto případě hovoříme o tzv. 2,5D vektorových datech. Pro tato data je sestavována 2D topologie. Například plochy umístěné ve 3D prostoru, které leží nad sebou budou detekovány jako topologicky invalidní, jelikož se jejich průměty do roviny částečně překrývají. Příklad nepravidelné trojúhelníkové sítě (TIN) vytvořené modulem v.delaunay na základě 3D bodových dat je zobrazen na obr V rámci datového modelu vektorové architektury byly ve verzi GRASS 6 definovány dva základní 3D elementy: face (stěna jako 3D plocha) 4 a kernel (3D centroid). Tímto podpora pro 3D vektorová data ve verzi GRASS 6 končí. Podpora pro sestavování 3D topologie, tj. objemů na základě stěn a kernelů, není implementována vůbec. Ve verzi GRASS 6 bylo nově implementováno či aktualizováno několik nástrojů podporujících zpracování 3D vektorových dat včetně 3D vizualizačního nástroje nviz. Podpora pro 4 Termín stěna (face) se používá také v datovém modelu Topo-Geo (kap ) jako plocha ve 2D. V terminologii topologického modelu systému GRASS se tento termín naopak používá pro plochu ve 3D.

91 2.4. SPRÁVA METADAT VE VERZI GRASS 6 77 Obrázek 2.6: Nepravidelná 2,5D trojúhelníková síť vizualizovaná ve 3D (autor: Martin Landa, 2013). 3D vektorová data v systému GRASS verze 6 však zůstala na začátku a nebyla dotažena do podoby funkčního 3D vektorového topologicky orientovaného GIS. Nejcitelnějším limitem je v tomto ohledu chybějící topologická správa 3D vektorových dat. 2.4 Správa metadat ve verzi GRASS 6 Úroveň správy metadat v systému GRASS GIS je obecně na velmi nízké úrovni. Systém správy metadat je značně zastaralý, ve své podstatě nerozšířitelný a do budoucna neudržitelný. Jeho kořeny sahají do počátku osmdesátých let minulého století, kdy systém GRASS vznikal [A6]. Tento stav se příliš nezměnil ani ve verzi GRASS 6. Správa metadat rastrových a vektorových dat není sjednocena jak na úrovni hlavičkových souborů, API knihovny, tak z uživatelského pohledu. To je dáno především odlišnou dobou vzniku rastrové a vektorové knihovny systému GRASS. Vektorová knihovna systému GRASS byla v letech výrazně přepsána (více v kap ). Množina metadat byla v porovnání s rastrovou knihovnou rozšířena, nicméně ani po tomto rozšíření správa metadat vektorových dat není dostačující a neodpovídá standardům v této oblasti, viz kap Správa metadat ve vektorové knihovně GRASS verze 6 Metadata vektorových dat v nativním formátu GRASS jsou uložena v hlavičkovém souboru head a v souboru s historií hist, viz tab Hlavičkový soubor obsahuje informace o tvůrci dat, původu dat, viz tab Druhý soubor nese informace pouze o historii příkazů, které vedly k vytvoření dané vektorové mapy.

92 78 KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU ŘEŠENÉ PROBLEMATIKY Příklad. ORGANIZATION: NC OneMap DIGIT DATE: Mar 19 7 DIGIT NAME: hmitaso Tabulka 2.8: Popis hlavičkového souboru vektorových dat v nativním formátu GRASS. položka ORGANIZATION DIGIT DATE DIGIT NAME MAP NAME MAP DATE MAP SCALE OTHER INFO ZONE MAP THRES popis název organizace datum digitalizace jméno uživatele, který mapu digitalizoval název vektorové mapy datum, kdy byla vrstva vytvořena měřítko mapy jednořádkový uživatelský komentář UTM zóna práhová hodnota při digitalizaci V API vektorové knihovny systému GRASS jde o datovou strukturu dig_head (hlavičkový soubor dig_struct.h). Pro čtení hlavičkového souboru je určena funkce vektorové knihovny Vect_read_header(). 1 struct dig_ head 2 { 3 char * organization ; /* n á zev organizace */ 4 char * date ; /* datum digitalizace */ 5 char * your_name ; /* tvůrce dat */ 6 char * map_name ; /* ná zev mapy */ 7 /* datum vzniku analogov é p ř edlohy mapy */ 8 char * source_ date ; 9 long orig_ scale ; /* me ř í tko analogov é p ř edlohy mapy */ 10 char * line_3 ; /* jedno řá dkov ý koment ář */ 11 /* pr á hov á hodnota p ř i digitalizaci */ 12 double digit_ thresh ; 13 }; Pro manipulaci s historií příkazů je určena skupina funkcí knihovny Vect_hist_*(). Z pohledu uživatele poskytuje základní metadatové informace 2D a 3D vektorových map modul v.info.

93 2.4. SPRÁVA METADAT VE VERZI GRASS 6 79 Příklad. Výpis metadat vektorové mapy geodetic_pts. GRASS> v.info map=geodetic_pts Name: geodetic_pts Mapset: PERMANENT Location: nc_spm_08 Database: /opt/grassdata Title: North Carolina geodetic points (points map) Map scale: 1:1 Name of creator: helena Organization: NC OneMap Source date: Thu Oct 19 22:50: Timestamp (first layer): none Podobně jako u modul r.info pro rastrová data lze pomocí přepínače -h vypsat informace o historii příkazů. GRASS> v.info -h map=geodetic_pts COMMAND: v.in.ogr dsn="gdc.shp" output="geodetic_pts" min_area= snap=-1 GISDBASE: /bigdata/grassdata05 LOCATION: ncfromfile MAPSET: PERMANENT USER: helena DATE: Thu Oct 19 22:50:

94 80 KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU ŘEŠENÉ PROBLEMATIKY

95 There are enough people who already make the very same things. Let the 3 evolving GRASS still be what it is: a topological GIS. Do not make the same errors as other, make your own. Thierry Laronde Cíle disertační práce Cíle práce jsou definovány v přímé souvislosti s vývojem vektorové architektury systému GRASS. V aplikační rovině je hlavním aspektem vývoj robustního open source 3D topologického GIS nástroje. Podstatným prvkem je interoperabilita navržené vektorové architektury. Interoperabilita vektorové architektury systému GRASS je řešena ve dvou rovinách. Jedním z cílů je integrace netopologického datového modelu jednoduchých geoprvků dle specifikace OGC Simple Features Access (kap. 1.3) v prostředí topologického GIS. Jako implementační rámec je v aplikační části použita knihovna OGR. Druhá rovina se věnuje projektu PostGIS (kap. 1.5). PostGIS je v současnosti považován za nejrozšířenější a neucelenější open source relačně-objektovou geodatabázi. Díky tomu hraje nejen v open source, ale i v proprietárních GIS aplikacích významnou roli. Z toho vyplývá jeden z hlavních aplikačních cílů práce zahrnující návrh a implementaci nativní podpory PostGIS ve vektorové architektuře systému GRASS. Vezmeme-li v potaz, že je tato architektura postavena na striktně topologickém datovém modelu, tak se jako klíčový prvek v geodatabázi PostGIS jeví podpora topologické správy vektorových dat. V aplikační části je využita nadstavba PostGIS Topology, která v prostředí geodatabáze PostGIS implementuje topologický model dle technické normy ISO SQL/MM [A15]. Nativní podpora PostGIS ve vektorové architektuře systému GRASS znamená možnost nasazení tohoto nástroje jako aplikace tzv. třetí generace GIS (obr. 3.1). V této generaci GIS je geometrická a atributová složka popisu geodat uložena v jednotném prostředí geodatabáze [A49]. Cílem je poskytnout uživatelům systému GRASS, v podobě geodatabáze PostGIS, plnohodnotnou alternativu k nativnímu topologickému souborově orientovanému vektorovému formátu. 81

96 82 KAPITOLA 3. CÍLE DISERTAČNÍ PRÁCE Obrázek 3.1: Tři generace GIS (zdroj: [A49]). Kromě interoperability vektorové architektury systému GRASS je řešena problematika topologické správy 3D vektorových dat v GIS. Cílem je, na základě analýzy existujících 3D datových modelů, navrhnout pro systém GRASS specifický 3D topologický datový model. Snahou je, aby tento model koncepčně vycházel ze stávajícího 2D topologického modelu a de facto jej rozšiřoval do třetí dimenze. Druhotným cílem je rozšíření nástrojů systému GRASS pro práci s 3D vektorovými daty. V závislosti na hlavních cílech jsou stanoveny cíle vedlejší. V rámci návrhu vektorové architektury systému GRASS verze 7 je cílem konsolidovat správu metadat a integrovat do nově navrženého grafického uživatelského rozhraní nástroje přímo související s aplikačními výstupy práce z oblasti topologické správy 2D a 3D vektorových dat včetně podpory pro externí datové zdroje, jako je geodatabáze PostGIS. Dalším vedlejším cílem, který přímo s vývojem vektorové architektury systému GRASS nesouvisí, je začlenění podpory výměnného formátu ISKN v knihovně OGR. Propojovacím prvkem s tématem práce je analýza topologické správy prvků digitální katastrální mapy, která je umožněna zamýšlenou integrací geodatabáze PostGIS ve vektorové architektuře systému GRASS.

97 KAPITOLA 3. CÍLE DISERTAČNÍ PRÁCE 83 Cíle předkládané disertační práce lze shrnout v následujících bodech: 1. Integrace datového modelu jednoduchých geoprvků (specifikace OGC Simple Features Access) a Topo-Geo (technická norma ISO SQL/MM) ve vektorové architektuře systému GRASS s cílem rozšíření její interoperability. 2. Nativní podpora pro geodatabázi PostGIS v režimu přístupu jednoduchých geoprvků a topologickém přístupu k vektorovým datům. 3. Návrh a implementace topologického modelu v systému GRASS pro správu 3D vektorových dat. 4. Rozšíření nástrojů systému GRASS pro práci s 3D vektorovými daty. 5. Spolupráce na návrhu nového multiplatformního grafického uživatelského rozhraní (GUI) pro systém GRASS s důrazem na nástroje pro vizualizaci a digitalizaci 2D a 3D vektorových dat. 6. Návrh správy metadat v systému GRASS podle aktuálně platných mezinárodních technických norem, implementace pro vektorovou architekturu. 7. Návrh a implementace podpory výměnného formátu ISKN v knihovně OGR, topologická správa prvků digitální katastrální mapy v geodatabázi PostGIS. Na závěr uveďme základní vlastnosti navrhované vektorové architektury systému GRASS ve verzi 7. Druhý a třetí bod pokrývá cíle předkládané práce. (1) Optimalizace topologické správy 2D vektorových dat. Cílem je reimplementace datových struktur topologické správy 2D vektorových dat. Stávající datové struktury nejsou optimalizovány pro různé typy vektorových elementů (kap ). To se projevuje především v případě bodových dat, která jsou poněkud nelogicky součástí topologického modelu ve verzi GRASS 6. Tento fakt diskvalifikuje systém GRASS při práci s extrémně rozsáhlými datovými sadami (např. data LIDAR). Cílem je optimalizovat datové struktury a funkce vektorové knihovny pro sestavení topologie 2D vektorových dat, a tak umožnit systému GRASS zpracování rozsáhlých datových sad v reálném čase. Této problematice se podrobněji věnuje kap Návrh optimalizace implementoval vývojář systému GRASS Markus Metz. (2) Interoperabilita. Cílem je zlepšení interoperability vektorové architektury systému GRASS. Tento bod lze rozdělit na dvě části. Plnohodnotnou integraci knihovny OGR (2a) v režimu čtení a zápisu externích vektorových dat. Cílem je umožnit přímé zpracování vektorových dat v režimu přístupu k jednoduchým geoprvkům bez nutnosti importu do nativního

98 84 KAPITOLA 3. CÍLE DISERTAČNÍ PRÁCE vektorového formátu GRASS. Druhou část představuje implementace nativního rozhraní pro geodatabázi PostGIS (2b), včetně podpory topologické správy vektorových dat. Navržená architektura systému GRASS verze 7 pro přístup k externím geodatům je znázorněna na obr Část relevantní pro disertační práci je zvýrazněna červenou barvou. Obrázek 3.2: Architektura systému GRASS, přístup k externím datům (zdroj: [A50]). (3) Topologie 3D vektorových dat. Navazuje na optimalizaci 2D topologického modelu (1). Jádrem je návrh a implementace topologického modelu pro 3D vektorová data.

99 The solution of every problem is another problem. 4 J. W. Goethe Analytická část práce Kapitola poskytuje souhrnný přehled analytických výstupů práce. První část je zaměřena na rozšíření interoperability vektorové architektury systému GRASS. Toho je dosaženo plnohodnotnou integrací knihovny OGR (kap ) a implementací nativní podpory pro geodatabázi PostGIS, jak v režimu přístupu k jednoduchým geoprvkům, tak i topologické správy vektorových dat v rámci rozšíření PostGIS Topology (kap ). Dále je popsáno navržené API vektorové knihovny systému GRASS pro přístup k jednoduchým geoprvkům (kap ) včetně integrace knihovny GEOS (kap ). Další část textu se věnuje hlavnímu tématu práce, a to integraci geodatabáze PostGIS, jako uložiště vektorových dat pro systém GRASS, s cílem plnohodnotné náhrady nativního topologicky orientovaného formátu. Vyjma úvodní části, která shrnuje možnost přístupu k vektorovým datům přes OGR rozhraní (kap ), je jádrem této části popis navrženého nativního rozhraní PostGIS pro systém GRASS (kap ). Podstatnou částí je vzhledem k tomu, že systém GRASS staví na ryze topologickém datovém modelu, integrace rozšíření PostGIS Topology, umožňující začlenění topologické správy vektorových dat přímo v geodatabázi PostGIS. Integraci PostGIS Topology a datového modelu Topo-Geo v rozhraní PostGIS vektorové knihovny systému GRASS se podrobněji věnuje kap V závěrečné části tohoto bloku jsou zmíněny navržené nástroje systému GRASS pro práci s geodatabází PostGIS, viz kap Dále se text věnuje rozšíření podpory pro zpracování 3D vektorových dat v systému GRASS. To zahrnuje rozšíření topologického modelu GRASS o nové 3D elementy a návrh implementace správy topologie ve 3D (kap ). Kromě toho jsou zmíněny vytvořené nástroje systému GRASS, určené pro tvorbu 3D vektorových dat (kap ) včetně experimentální integrace knihovny CGAL v systému GRASS (viz kap ). 85

100 86 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Poslední dva tématické okruhy, které souvisí přímo se systémem GRASS, jsou věnovány návrhu společné správy metadat pro rastrová a vektorová data dle mezinárodně platných norem v této oblasti (kap. 4.4) a vývoji nové generace grafického uživatelského rozhraní (GUI) systému GRASS (kap. 4.5) s důrazem na komponenty související s hlavními analytickými výstupy práce. Závěrečná část kapitoly je věnována návrhu a implementaci podpory výměnného formátu ISKN (kap ) v knihovně OGR, viz kap Spojovacím článkem s hlavními výstupy práce je kap , která se věnuje uložení geometrie prvků digitální katastrální mapy poskytovaných ve výměnném formátu ISKN v topologickém modelu Topo-Geo. Převod dat výměnného formátu ISKN do PostGIS Topology je umožněn právě podporou tohoto formátu v knihovně OGR a rozhraním PostGIS v systému GRASS, jehož nástroje jsou pro převod použity. 4.1 Rozšíření interoperability vektorové architektury systému GRASS GIS Tato kapitola se věnuje analytické části práce zaměřené na zlepšení interoperability vektorové architektury systému GRASS, a to rozšířením stávajícího neúplného rozhraní pro knihovnu OGR, a především implementací nativního rozhraní pro geodatabázi PostGIS, včetně podpory pro topologickou správu vektorových dat Plnohodnotná integrace knihovny OGR ve vektorové architektuře systému GRASS verze 7 Navržené OGR rozhraní vektorové knihovny GRASS verze 7 vychází koncepčně z verze GRASS 6 (viz kap. 2.2). Na základě analýzy zdrojových kódů rozhraní OGR z vektorové knihovny systému GRASS 6 bylo stanoveno pět dílčích kroků: 1. provést podrobné testování stávající funkcionality rozhraní OGR, 2. rozšířit návrh rozhraní s cílem začlenit chybějící komponenty rozhraní (kap ), 3. opravit zásadní chyby ve stávající implementaci, 4. po stabilizaci rozhraní OGR nově implementovat tzv. přímý přístup v režimu čtení (kap ), 5. implementovat přístup k datům taktéž v režimu zápisu (kap ).

101 4.1. INTEROPERABILITA VEKTOROVÉ ARCHITEKTURY SYSTÉMU GRASS Rozhraní OGR: režim čtení Jak již bylo zmíněno v kap. 2.2, systém GRASS od verze 6 umožňuje přistupovat k externím vektorovým datovým formátům přímo, tj. bez nutnosti konverze do nativního formátu GRASS, a to pomocí modulu v.external. Tento modul vytvoří v aktuálním mapsetu novou vektorovou mapu, která odkazuje na data v původním GIS formátu. Formát dat je popsán v souboru frmt umístěném v adresáři vektorové mapy vedle ostatních souborů (viz tab. 2.3). Soubor obsahuje informace o formátu resp. o rozhraní, které má vektorová knihovna systému GRASS použít pro přístup k datům. V případě OGR rozhraní se jedná o tzv. OGR data source (DSN) a vrstvu (LAYER). Příklad. Pro data ve formátu Esri Shapefile odkazuje DSN na adresář, ve kterém je umístěn soubor ve formátu SHP. Názvu souboru odpovídá OGR vrstva, tj. parametr LAYER: FORMAT: ogr DSN: /opt/ncshape LAYER: railroads Kromě souboru frmt vektorová knihovna systému GRASS vygeneruje soubor fidx, který slouží pro korektní sestavení tzv. pseudo-topologie (kap ). Následuje přehled funkcí API rozhraní OGR vektorové knihovny systému GRASS verze 7. Většina těchto funkcí byla autorem kompletně přepsána či doplněna po stránce funkcionality. Prefix funkcí VX definuje úroveň přístupu k vektorovým datům. Prefix V1 označuje funkce, které přistupují k datům bez topologie, funkce s prefixem V2 naopak přístup k topologickým informacím vyžadují: VX_open_old_ogr() Otevře existující OGR vrstvu jako standardní vektorovou mapu reprezentovanou datovou strukturou Map_info. V1_read_line_ogr() Náhodný přístup k vektorovým elementům v režimu čtení bez topologie. V2_read_line_sfa() Náhodný přístup k vektorovým elementům v režimu čtení včetně topologie. Postfix _sfa označuje funkce společné pro rozhraní OGR a PostGIS v režimu přístupu k jednoduchým geoprvkům (Simple Features Access). VX_read_next_line_ogr() Sekvenční přístup k vektorovým elementům v režimu bez topologie (funkce s prefixem V1) a včetně topologie (V2). Vect_build_ogr() Sestavení pseudo-topologie pro vektorová data. Funkce byla autorem práce rozšířena

102 88 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE o podporu různých úrovní sestavení topologie. Vektorová knihovna definuje několik úrovní topologie pro data uložená v nativním formátu: základní, sestavení ploch, přiřazení ostrovů a centroidů k plochám. Původně byla v rozhraní OGR podporována pouze jedna úroveň (sestavení veškerých topologických informací). Po navržených úpravách lze ovlivnit úroveň sestavení topologických informací i pro OGR vrstvy v rámci pseudotopologie. VX_close_ogr() Korektně uzavře OGR vrstvu a uvolní paměť alokovanou pro datovou strukturu Map_info. Kromě výše uvedených úprav ve vektorové knihovně systému GRASS došlo k zásadnímu přepsání modulu v.external včetně implementace interaktivního GUI dialogu pro tento modul integrovaného do uživatelského rozhraní wxgui (kap. 4.5). Demonstrace dialogu je zobrazena na obr Obrázek 4.1: GUI dialog modulu v.external integrovaný v uživatelském rozhraní wxgui (autor: Martin Landa, 2011) Rozhraní OGR: podpora pro přímý přístup V rámci prací na rozhraní OGR ve vektorové knihovně GRASS verze 7 autor disertační práce implementoval nově tzv. přímý přístup k externím vektorovým datům. Díky tomu může uživatel přistupovat k těmto datům přes rozhraní OGR přímo bez nutnosti vy-

103 4.1. INTEROPERABILITA VEKTOROVÉ ARCHITEKTURY SYSTÉMU GRASS 89 tvářet vektorovou mapu jako odkaz na externí vektorová data pomocí modulu v.external. K přímému přístupu slouží virtuální mapset s názvem OGR. Nástroje systému GRASS pro zpracování vektorových dat disponují co se týče vstupu dvěma povinnými parametry, a to map resp. input (vektorová mapa) a layer (vrstva v rámci vektorové mapy). Problematice termínu vektorová mapa a vrstva se věnuje kap Vektorová vrstva bývá většinou označována číslem, ve verzi GRASS 7 k ní může uživatel přistupovat nejen na základě číselného identifikátoru, ale i na základě jména. Této možnosti využívá právě režim přímého přístupu k externím vektorovým datům. Příklad. Pro demonstraci uveďme názorný příklad: GRASS> v.extract input=bridges layer=1 cat=1-10 output=bridges_1 Modul v.extract vybere ze vstupní vektorové mapy bridges pouze ty geoprvky, které mají přiřazenu vrstvu (layer) 1 a zároveň kategorii 1 až 10 včetně. Vybrané geoprvky jsou uloženy ve výstupní vektorové mapě bridges_1. Výsledek můžeme ověřit modulem v.category, který vypíše informace o přiřazených číselných kategoriích: GRASS> v.category input=bridges_1 option=report Layer/table: 1/bridges_1 type count min max point all Pokud bychom k vstupním vektorovým datům přistupovali přes rozhraní OGR standardně, tak bychom museli nejprve externí vektorová data zaregistrovat pomocí modulu v.external: GRASS> v.external dsn=/opt/ncshape/ layer=bridges Tento příkaz vytvoří v aktuálním mapsetu vektorovou mapu bridges, která bude odkazovat na originální vektorová data ve formátu Esri Shalefile. Teprve poté můžeme s těmito daty pracovat, v našem případě aplikovat modul v.extract a vybrat geoprvky na základě atributového dotazu. Přímý přístup rozhraní OGR umožňuje tento krok přeskočit a k externím vektorovým datům přistupovat bez vytvoření odkazu v podobě nové vektorové mapy registrované v aktuálním mapsetu. K zadaní OGR data source (parametr dsn modulu v.external) je použit parametr input jako název vektorové mapy. Aby se zřetelně odlišil přímý přístup k externím vektorovým datům rozhraní OGR od standardního použití, tak se název vstupní vektorové mapy zadává plně specifikovaný, tj. včetně virtuálního mapsetu OGR.

104 90 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Pokud uživatel zadá pouze název mapy (tj. bez udání mapsetu), např. GRASS> v.info map=bridges tak systém použije první nalezenou vektorovou mapu tohoto jména, kterou najde v tzv. vyhledávací cestě. Plně specifikovaný název mapy má syntax název_mapy@název_mapsetu. Kupříkladu příkaz GRASS> v.info map=bridges@permanent vypíše metadata vektorové mapy bridges umístěné v mapsetu PERMANENT bez ohledu na vyhledávací cestu. Této vlastnosti bylo využito při implementaci přímého přístupu v rozhraní OGR vektorové knihovny systému GRASS. Režim přímého přístupu je automaticky aktivován, pokud název mapsetu zadaného v plně specifikovaném názvu mapy odpovídá mapsetu OGR. V tomto případě název mapy odpovídá OGR datovému zdroji. Druhý povinný parametr (tj. OGR vrstva) je specifikován pomocí parametru layer. Příklad. Demonstrační příkazy uvedené v kap. 2.2 by v režimu přímého přístupu vypadaly následovně, pro Esri Shapefile (adresář /opt/ncshape, SHP soubor railroads): GRASS> v.info map=/opt/ncshape@ogr layer=railroads Pro geodatabázi PostGIS (databáze pgisnc tj. OGR data source PG:dbname=pgisnc, tabulka geodetic_pts): GRASS> v.info map=pg:dbname=pgisnc@ogr layer=geodetic_pts Přímý přístup k externím vektorovým datům přes rozhraní OGR se v porovnání s tvorbou statických odkazů pomocí modulu v.external liší ve dvou zásadních bodech. Kromě toho, že se nevytváří odkaz na externí vektorová data v podobě vektorové mapy registrované v aktuálním mapsetu, nedochází ani k uložení pseudo-topologie (soubory topo a fidx, více v kap ). Tyto informace většina nástrojů systému GRASS při přístupu k vektorovým datům vyžaduje. Z výše uvedeného vyplývá, že se pseudo-topologie v případě přímého přístupu sestavuje v paměti počítače vždy při načítání dat, tj. otevření OGR vrstvy pomocí funkce V2_open_old_ogr(). Příklad. V následujícím demonstračním příkladu provedeme generalizaci vektorové vrstvy roadsmajor silničních komunikací dostupné z PostGIS geodatabáze pgisnc na základě generalizačního Douglas-Peuckerova algoritmu. Výsledná generalizovaná vektorová data budou uložena v nativním formátu systému GRASS jako vektorová mapa roadsmajor_d.

105 4.1. INTEROPERABILITA VEKTOROVÉ ARCHITEKTURY SYSTÉMU GRASS 91 Pro větší názornost nejprve použijeme metodu vytvoření odkazu na externí vektorová data pomocí modulu v.external. GRASS> v.external dsn=pg:dbname=pgisnc layer=roadsmajor Tento příkaz vytvoří v aktuálním mapsetu vektorovou mapu roadsmajor jako odkaz na PostGIS tabulku roadsmajor z geodatabáze pgisnc. Kromě toho sestaví pro tuto vrstvu v režimu přístupu k jednoduchým geoprvkům tzv. pseudo-topologii a uloží topologické informace do souborů topo a fidx umístěných v adresáři s vektorovou mapou. Using external data format PostgreSQL (feature type linestring ) Building pseudo-topology over simple features Number of nodes: Number of lines: v.external complete. Link to vector map <roadsmajor> created. K takto registrovaným datovým vrstvám můžeme přistupovat podobně, jako by byly uloženy v nativním formátu GRASS, pouze s tím zřetelem, že jde o jednoduché geoprvky. Nástroje systému GRASS přistupující k vektorovým datům čerpají topologické informace ze souboru topo a nikoliv z originálních dat. Pokud jsou například po vytvoření odkazu data modifikována mimo systém GRASS, topologické informace uložené v souboru topo zůstávají nezměněny a tím se stávají neaktuálními. To může vést k méně či více podstatným chybám při čtení externích vektorových dat rozhraním OGR vektorové knihovny systému GRASS až například po fatální selhání jeho nástrojů, a to díky nesrovnalosti mezi topologickou a geometrickou složkou popisu geodat. V tomto případě je třeba sestavit pseudo-topologii v systému GRASS znovu pomocí modulu v.build, který přepíše soubor topo a fidx aktuálními topologickými informacemi sestavenými na základě geometrie jednoduchých geoprvků. Podrobněji se procesu sestavovaní pseudo-topologie věnuje kap Jak již bylo zmíněno výše, při přístupu k vektorové mapě jako k odkazu na externí vektorová data jsou topologické informace načítány ze souboru topo a fidx. GRASS> v.generalize input=roadsmajor layer=1 out=roadsmajor_d \ method=douglas threshold=1... Generalization (douglas) v.generalize complete. Number of vertices for selected features reduced from to 4130 (7%).

106 92 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE V případě přímého přístupu se pseudo-topologie a související prostorový index sestavuje v paměti počítače vždy při čtení externích vektorových dat (viz zpráva Building topology... v příkladu uvedeném níže). Topologické informace jsou tedy vždy aktuální, na druhou stranu při větším objemu dat může být sestavení topologie poměrně časově náročné. GRASS> v.generalize input=pg:dbname=pgisnc@ogr layer=roadsmajor \ out=roadsmajor_d method=douglas threshold=1 Building topology for OGR layer <roadsmajor> from datasource PG:dbname=pgisnc Generalization (douglas) v.generalize complete. Number of vertices for selected features reduced from to 4130 (7%). Z hlediska API vektorové knihovny systému GRASS vyžadovala implementace přímého přístupu v rámci rozhraní OGR rozšíření funkcí pro otevření existující vektorové mapy v režimu čtení, konkrétně jde o funkci Vect_open_old(). Výsledkem je návrh a implementace nové funkce Vect_open_old2(). V této souvislosti byly aktualizovány všechny nástroje systému GRASS, které mají na vstupu vektorová data (tj. parametr map, resp. input a layer) tak, aby přímý přístup přes OGR rozhraní podporovaly Rozhraní OGR: podpora pro režim zápisu Jedním ze zásadních aplikačních výstupů disertační práce je implementace režimu zápisu pro rozhraní OGR vektorové knihovny GRASS verze 7. V důsledku tak uživatel může zapisovat vektorová data do externích GIS formátů přímo pomocí standardních nástrojů systému GRASS, které mají na výstupu vektorová data. Rozhraní OGR zapisuje vektorová data ve formě jednoduchých geoprvků. Implementace režimu zápisu v rozhraní OGR zahrnuje rozšíření API vektorové knihovny GRASS verze 7 o funkce umožňující zápis, editaci a odstranění jednoduchých geoprvků z OGR vrstvy. Editace zahrnuje jak změnu geometrické, tak atributové složky popisu geoprvků. Tyto funkce jsou rozděleny do dvou skupin: 1. funkce, které neaktualizují topologické informace (tzv. level 1, prefix V1), 2. funkce, které topologické informace aktualizují na základě změn geometrie jednoduchých geoprvků (tzv. level 2, prefix V2). Funkce s prefixem V2 jsou společné pro rozhraní OGR a PostGIS (kap ) v režimu Simple Features Access (viz postfix funkcí sfa).

107 4.1. INTEROPERABILITA VEKTOROVÉ ARCHITEKTURY SYSTÉMU GRASS 93 Pro zápis nového vektorového elementu, tj. jednoduchého geoprvku dle specifikace OGC Simple Features Access, slouží funkce vektorové knihovny V1_write_line_ogr(), v topologickém režimu funkce V2_write_line_sfa(). Druhá uvedená funkce aktualizuje topologické informace a pro zápis jednoduchého geoprvku volá funkci V1_write_line_ogr(). Výše uvedené funkce nejsou určeny k přímému volání mimo API vektorové knihovny systému GRASS. Nový geoprvek se zapisuje pomocí funkce Vect_write_line(), která volá příslušnou funkci z daného rozhraní, tj. nativního, OGR či PostGIS (viz Map->format) a tzv. úrovně přístupu (Map->level) (řádek 22). V GRASS verzi 7 jsou definovány dvě úrovně (levels), level 1 bez přístupu k topologii a level 2 s přístupem k 2D topologii vektorových dat. Level 3 je rezervován pro 3D topologii, viz kap static off_t (* Vect_write_line_array [][3]) () = { 2 { 3 /* nativn í form át */ 4 write_ dummy, V1_ write_ line_ nat, V2_ write_ line_ nat } 5, { 6 /* OGR rozhran í */ 7 write_ dummy, V1_ write_ line_ ogr, V2_ write_ line_ sfa } 8, { 9 /* PostGIS rozhran í */ 10 write_ dummy, V1_ write_ line_ pg, V2_ write_ line_ pg } 11 }; off_ t Vect_ write_ line ( struct Map_ info * Map, 14 int type, 15 const struct line_ pnts * points, 16 const struct line_ cats * cats ) 17 { 18 off_ t offset ; /*... tělo funkce omezeno pouze na relevantn í část... */ offset = (* Vect_write_line_array [Map -> format ][ Map -> level ]) 23 (Map, type, points, cats ); return offset ; 26 } Dále byly implementovány funkce pro odstranění existujícího geoprvku z OGR vrstvy: V1_delete_line_ogr() a V2_delete_line_sfa(). Funkce V2_delete_line_sfa() po odstranění geoprvku navíc aktualizuje i topologické informace spravované systémem GRASS.

108 94 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Podobně jako u funkcí pro zápis nového geoprvku ani výše uvedené funkce nejsou určeny k přímému volání mimo API vektorové knihovny systému GRASS. Programátor namísto toho volá funkci Vect_delete_line(), která odkazuje v případě OGR rozhraní na funkci V1_delete_line_ogr(), resp. V2_delete_line_sfa() podle toho, zda je vektorová mapa otevřena na úrovni přístupu bez topologie nebo včetně topologie. Poslední ze skupiny editačních funkcí rozhraní OGR, které byly autorem implementovány, jsou funkce V1_rewrite_line_ogr() a V2_rewrite_line_sfa(). Tyto funkce slouží k modifikaci geometrie již existujícího jednoduchého geoprvku. Funkce V1_rewrite_line_ogr() nejprve geoprvek z OGR vrstvy odstraní (viz funkce V1_delete_line_ogr()) a posléze zapíše nový geoprvek pomocí V1_write_line_ogr(). Kromě výše uvedených funkcí pro zápis, odstranění a modifikaci jednoduchých geoprvků, byla implementována funkce vektorové knihovny systému GRASS určená pro tvorbu nových OGR vrstev V1_open_new_ogr(). Vytvoření OGR vrstvy je implementováno následovně: funkce Vect_open_new() v případě OGR rozhraní volá funkci V1_open_new_ogr(), která otevře OGR datový zdroj v režimu zápisu. Při prvním pokusu zapsat do vektorové mapy geoprvek je nová OGR vrstva, pokud již neexistuje, vytvořena. První zapsaný geoprvek tak určuje vektorový typ, který bude k OGR vrstvě přidružen Modul v.external.out Kromě výše zmíněných změn v API vektorové knihovny byl implementován nový modul systému GRASS, který umožňuje uživateli definovat výstupní vektorový formát. V rámci zachování konzistence pojmenování modulů (ve skupině modulů pro zpracování rastrových dat již existuje modul r.external.out) byl zvolen název v.external.out [B22]. Modul byl implementován v programovacím jazyce ANSI C. Modul v.external.out umožňuje definovat externí vektorový formát (parametr format), ve kterém budou vektorová data nástroji systému GRASS zapisována. Výchozím externím formátem je Esri Shapefile (tj. format=esri_shapefile). Dále modul vyžaduje určení tzv. data source (vychází z terminologie knihovny OGR), tj. parametr dsn. Poslední parametr modulu options je nepovinný a umožňuje definovat volby specifické pro zvolený datový formát. Návrat k nativnímu vektorovému formátu GRASS umožňuje přepínač -r (viz syntax modulu uvedená níže). 1 Knihovna OGR umožňuje v dané OGR vrstvě uložit pouze jednoduché geoprvky jednoho typu. Nelze uložit v jedné vrstvě současně bodová a polygonová vektorová data. Tento fakt lze obejít použitím vektorového typu GeometryCollection. Pro tento datový typ je však definována v porovnání se základními typy Point, LineString či Polygon omezená sada prostorových funkcí.

109 4.1. INTEROPERABILITA VEKTOROVÉ ARCHITEKTURY SYSTÉMU GRASS 95 Syntax modulu v.external.out je následující: Description: Defines vector output format. Keywords: vector, export, output, external, OGR, PostGIS Usage: v.external.out [-frpg] dsn=string format=string [options=string[,string,...]] [--verbose] [--quiet] Flags: -f List supported formats and exit -r Cease using OGR/PostGIS, revert to native output and exit -p Print current status -g Print current status in shell script style Parameters: dsn Name of input OGR or PostGIS data source format Format for output vector data default: ESRI_Shapefile options Creation options Pro zvýšení uživatelského komfortu byl autorem navržen a implementován pro modul v.external.out interaktivní GUI dialog uživatelského rozhraní wxgui (viz kap. 4.5). Dialog umožňuje uživatelská nastavení ukládat a znovu načítat. Ukázka GUI dialogu je zobrazena na obr Obrázek 4.2: GUI dialog modulu v.external.out. Vektorová data nejsou nicméně zapisována do externího vektorového formátu ihned. Nejprve jsou data ukládána do přechodné vektorové mapy v nativním topologickém formátu GRASS. Možnost vytvářet přechodné vektorové mapy byla do vektorové knihovny přidána autorem práce právě v souvislosti implementace režimu zápisu pro OGR rozhraní, viz funkce vektorové knihovny Vect_open_tmp_new(). Při uzavření vektorové mapy jsou vektorová data převedena z topologického formátu do formy jednoduchých geoprvků a ty jsou posléze zapsány do externího vektorového formátu. Následně na to je přechodná vektorová mapa odstraněna. Tento postup je vyžadován přede-

110 96 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE vším, pokud je výstupem polygonová vrstva. V tomto případě jsou polygony vytvořeny na základě topologie ploch a ostrovů. Ostrovy mohou definovat otvory v polygonech. Alternativně lze pomocí proměnné prostředí GRASS_VECTOR_EXTERNAL_IMMEDIATE aktivovat přímý zápis vektorových dat do externího formátu bez mezičlánku přechodné vektorové mapy. Přímý zápis bude fungovat pouze pro body, linie a plochy bez vnitřních ostrovů, jejichž hranice je definována pouze jednou uzavřenou hraniční linií. Případný ostrov definující otvor v polygonu bude zapsán jako regulérní polygon umístěný v jiném polygonu. Toto pravidlo platí i pro nativní rozhraní PostGIS v režimu Simple Features Access (kap ). Příklad. Níže uvedený příkaz způsobí, že veškeré nástroje systému GRASS, které mají na svém výstupu vektorová data, je budou zapisovat přímo ve formátu Esri Shapefile, a to v adresáři /opt/geodata/shape. GRASS> v.external.out dsn=/opt/geodata/shape format=esri_shapefile Modul v.external.out vytvoří v aktuálním mapsetu soubor s názvem OGR, který obsahuje informace o datovém formátu, data source a dalších volbách. V našem případě vypadá následovně: dsn: /opt/geodata/shape format: ESRI Shapefile Pro účel demonstrace zápisu vektorových dat do externího formátu použijeme modul v.extract pro výběr jezer (vektorová mapa lakes), které mají rozlohu větší než 2 km 2. GRASS> v.extract input=lakes output=lakes2 where="area>2e6" Data budou v tomto případě uložena ve formátu Esri Shapefile jako soubor lakes2 v adresáři /opt/geodata/shape. Dále bude automaticky vytvořen v aktuálním mapsetu odkaz na výstupní vektorová data. Uživatel tak nemusí tento odkaz vytvářet explicitně pomocí modulu v.external. Existenci odkazu (tj. vektorové mapy lakes2) si ověříme pomocí nástroje v.info. GRASS> v.info map=lakes2... Map format: OGR (ESRI Shapefile) OGR layer: lakes2 OGR datasource: /opt/geodata/shape Feature type: polygon...

111 4.1. INTEROPERABILITA VEKTOROVÉ ARCHITEKTURY SYSTÉMU GRASS Integrace geodatabáze PostGIS ve vektorové architektuře systému GRASS verze 7 Po dokončení práce na rozhraní OGR bylo přikročeno k návrhu a implementaci nativního rozhraní pro geodatabázi PostGIS v režimu přístupu k jednoduchým geoprvkům (kap ) včetně podpory pro zápis dat. V druhé fázi vývoje byl rozšířen návrh rozhraní PostGIS o podporu čtení a zápisu topologických vektorových dat odpovídajících datovému modelu rozšíření PostGIS Topology (viz kap ) Rozhraní PostGIS: Simple Features Access Nativní rozhraní PostGIS na rozdíl od rozhraní OGR implementuje přímý přístup ke geometrické složce popisu geodat bez nutnosti jakéhokoliv mezičlánku (v případě rozhraní OGR se jedná o knihovnu OGR). To kromě možnosti optimalizace přístupu k datům vede k větší flexibilitě řešení jako takového. Prototypy funkcí odpovídají rozhraní OGR vektorové knihovny systému GRASS. Přehled funkcí je uveden v kap , v případě rozhraní PostGIS je zvolen postfix funkcí pg. Funkce s prefixem V1 označují přístup k datům bez topologie, V2 včetně topologie. V režimu čtení jde o následující funkce: V1_open_old_pg(), V2_open_old_pg() Otevření existující PostGIS vrstvy s geodaty. V1_read_line_pg(), V2_read_line_sfa() Náhodný přístup k vektorovým elementům v režimu čtení. V1_read_next_line_pg(), V2_read_next_line_pg() Sekvenční přístup k vektorovým elementům v režimu čtení. Vect_build_pg() Funkce pro sestavení pseudo-topologie volá funkci Vect build_sfa() společnou pro rozhraní OGR a PostGIS. V1_close_pg(), V2_close_pg() Korektní uzavření vektorové mapy, tj. spojení s PostGIS geodatabází. Dále byly implementovány funkce rozhraní PostGIS pro přístup v režimu zápisu: V1_open_new_pg(), V2_open_new_pg() Vytvoření nové PostGIS vrstvy, tj. tabulky s geodaty. V1_delete_line_pg(), V2_delete_line_sfa() Odstranění jednoduchého geoprvku, tj. záznamu z tabulky v geodatabázi.

112 98 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE V1_write_line_pg(), V2_write_line_sfa() Zápis nového jednoduchého geoprvku, tj. přidání záznamu do tabulky v geodatabázi. V1_rewrite_line_pg(), V2_rewrite_line_sfa() Modifikace geometrie jednoduchého geoprvku, tj. atributu geometrie tabulky v geodatabázi. Rozhraní PostGIS v režimu Simple Features Access přistupuje ke geometrické složce popisu geodat podobně jako rozhraní OGR, pouze s tím rozdílem, že ke geometrii (tj. atributu, který má datový typ Geometry) uložené v geodatabázi PostGIS přistupuje vektorová knihovna systému GRASS v režimu čtení a zápisu přímo pomocí knihovny libpq (viz kap ). Přímý přístup k PostGIS datům je v porovnání s rozhraním OGR rychlejší především proto, že není použita mezivrstva abstraktního modelu jako v případě knihovny OGR (kap ). Problematika přístupu k datům přes rozhraní PostGIS vektorové knihovny systému GRASS je podrobněji popsána, a to především z pohledu uživatele v kap Rozhraní PostGIS: Topology Access Kromě přístupu k jednoduchým geoprvkům, tak jak je definuje specifikace OGC Simple Features Access (SFA) a implementuje projekt PostGIS, byla do rozhraní PostGIS vektorové knihovny GRASS verze 7 zakomponována podpora pro topologickou správu vektorových dat. Podpora pro topologická data v geodatabázi PostGIS je implementována v rámci rozšíření PostGIS Topology (kap ). Z pohledu rozhraní pro programování aplikací (API) vektorové knihovny systému GRASS byly implementovány následující funkce: Vect_open_topo_pg() Načte topologické informace (uzly, hrany a stěny z topologického modelu Topo-Geo, viz kap ) ze schématu definovaného rozšířením PostGIS Topology do interních datových struktur vektorové knihovny systému GRASS reprezentující topologické elementy datového modelu GRASS, tj. uzly, linie, hraniční linie, centroidy, plochy a ostrovy (kap ). V2_read_line_pg() Implementuje náhodný přístup k topologickým elementům dle datového modelu systému GRASS. Tento přístup vyžaduje konverzi topologických elementů datového modelu PostGIS Topology (Topo-Geo) a GRASS (více k tomuto tématu v kap ). Ke konverzi dochází při otevření vektorové mapy, viz funkce V2_open_old_pg().

113 4.1. INTEROPERABILITA VEKTOROVÉ ARCHITEKTURY SYSTÉMU GRASS 99 V2_delete_line_pg() Nahrazuje funkci V2_delete_line_sfa() s tím, že namísto jednoduchých geoprvků odstraňuje topologické elementy tak, jak je definuje datový model Topo-Geo (tj. uzly, hrany a stěny). Současně jsou synchronizovány topologické informace udržované vektorovou knihovnou systému GRASS. V2_write_line_pg() Nahrazuje funkci V2_write_line_sfa() s tím, že zapisuje nové elementy v rámci topologického schématu definovaného rozšířením PostGIS Topology, tj. přidává nové záznamy do tabulek node, edge a face (viz kap ). Zároveň jsou aktualizovány topologické informace jak v PostGIS Topology, tak v topologickém modelu, který používá GRASS (kap ). V2_rewrite_line_pg() Přepíše existující topologický element (uzel, hrana či stěna) v datovém modelu Topo- Geo a aktualizuje interní topologické informace udržované vektorovou knihovnou systému GRASS. Dále byly v rámci integrace podpory topologického přístupu v rozhraní PostGIS vektorové knihovny GRASS verze 7 upraveny níže uvedené funkce: V2_open_old_pg() Namísto PostGIS tabulky s geodaty otevře topologické schéma, ve kterém jsou definovány tabulky pro jednotlivé topologické elementy dle datového modelu Topo-Geo, který používá projekt PostGIS Topology. V2_open_new_pg() Namísto nové PostGIS tabulky s geodaty vytvoří nové topologické schéma a v něm tabulky dle definice datového modelu Topo-Geo, tj. node, edge a face. Do posledně zmíněné tabulky vloží tzv. obecnou stěnu (universal face). V2_close_pg() Korektně uzavře vektorovou mapu v režimu přístupu PostGIS Topology. V2_read_next_line_pg() Rozšiřuje funkci pro sekvenční přístup o čtení topologických elementů. Problematice integrace projektu PostGIS Topology do rozhraní PostGIS vektorové architektury GRASS verze 7 z pohledu uživatele systému GRASS se věnuje podrobněji kap

114 100 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Simple Features API vektorové knihovny verze GRASS 7 Vektorová knihovna systému GRASS verze 7 byla v rámci snah o nativní podporu specifikace OGC Simple Features Access (SFA) rozšířena autorem práce o sadu funkcí, které operují nad vektorovými daty v topologickém modelu systému GRASS a zároveň umožňují operace nad jednoduchými geoprvky tak, jak jsou definovány ve specifikaci OGC SFA [B6]. Konkrétně jde o následující funkce: Vect_sfa_get_line_type() Konvertuje typ vektorového elementu definovaného v rámci topologického modelu systému GRASS na typ jednoduchého geoprvku: bod Point, linie LineString, uzavřená hraniční linie Polygon, kategorie převzata z centroidu plochy. Zároveň je kontrolována validnost geometrie jednoduchého geoprvku, např. degenerované linie či polygony. Vect_sfa_get_type() Převede typ jednoduchého geoprvku na typ vektorového elementu definovaného v rámci topologického modelu systému GRASS. Vect_sfa_check_line_type() Kontroluje, zda uvedený typ vektorového elementu odpovídá danému typu z datového modelu jednoduchých geoprvků, např. LinearRing musí být tvořen minimálně třemi segmenty, počáteční a koncový uzel lomené čáry musí být totožný. Vect_sfa_line_dimension() Vrací rozměr (dimenzi) vektorového elementu. bod 0, linie 1, uzavřená hraniční linie 2. Vect_sfa_line_geometry_type() Vrací název typu jednoduchého geoprvku jako textový řetězec. Vect_sfa_is_line_closed() Kontroluje, zda je lomená čára uzavřená, tj. počáteční a koncový uzel jsou totožné.

115 4.1. INTEROPERABILITA VEKTOROVÉ ARCHITEKTURY SYSTÉMU GRASS Výstup dle specifikace OGC Simple Features Access Systém GRASS používá vlastní textovou reprezentaci vektorových dat, tzv. GRASS ASCII vector format. Z uživatelského hlediska je tento formát podporován v režimu importu modulem v.in.ascii a exportu v.out.ascii. Příklad. Export vektorových dat do formátu GRASS ASCII (format=standard). Výběr bodu z vektorové mapy geodetic_pnts, který má přiřazenu číselnou kategorii 1 : GRASS> v.out.ascii input=geodetic_pts cat=1 format=standard P V tomto případě jde o bod (P) s jedním párem souřadnic (1) a jednou přiřazenou číselnou kategorií (1). Na druhém řádku jsou uvedeny souřadnice X,Y. Na posledním řádku je dvojice hodnot: číslo vrstvy (1) a kategorie (1). Pro bližší popis formátu lze odkázat na oficiální dokumentaci [B23]. V rámci práce na Simple Features API byla autorem vektorová knihovna systému GRASS rozšířena o možnost výstupu ve formě Well Known Text (WKT) definovaného konsorciem OGC. Export geometrické složky popisu geoprvků je implementován v rámci funkce Vect_sfa_line_astext(). Podporovány jsou body, linie a plochy. Z uživatelského pohledu je export do WKT dostupný v rámci modulu v.out.ascii s parametrem format=wkt. Příklad. Výpis bodu z vektorové mapy geodetic_pnts s kategorií 1 ve formě WKT: GRASS> v.out.ascii input=geodetic_pts cat=1 format=wkt POINT( ) Exportována je pouze geometrická složka popisu geodat, informace o kategoriích či atributech nejsou součástí tohoto výstupu Integrace knihovny GEOS Geometry Engine Open Source (GEOS) ( je C++ knihovna implementující specifikaci OGC Simple Features Access, a to především prostorové funkce a operátory. GEOS je ve své podstatě C++ port knihovny Java Topology Suite (JTS). Hlavním důvodem existence knihovny GEOS jako C/C++ portu knihovny JTS je především projekt PostGIS (kap. 1.5), který je implementován z větší části v programovacím jazyce C. Knihovna GEOS je od svého počátku velmi úzce spojena s vývojem projektu PostGIS a je v této geodatabázi plně integrována.

116 102 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Jako jeden z vedlejších aplikačních výstupů disertační práce byla knihovna GEOS integrována v API vektorové knihovny GRASS verze 7 [B24]. V souhrnu byly implementovány následující funkce vektorové knihovny: Vect_read_line_geos() Načte geometrii vektorového elementu (bod, linie, hraniční linie, centroid) do datových struktur knihovny GEOS (třída GEOSGeometry). Podporovány jsou pouze 2D vektorová data. Vect_read_area_geos() Načte geometrii plochy (tj. kompozice hraničních linií a centroidu včetně případných ostrovů) do datových struktur knihovny GEOS (třída GEOSGeometry) jako polygon definovaný dle specifikace OGC Simple Features Access. Vect_line_to_geos() Konvertuje geometrii vektorového geoprvku z vnitřních datových struktur vektorové knihovny GRASS do datových struktur používaných knihovnou GEOS. Vect_get_area_points_geos() Vrací vnější hranici plochy jako sekvenci lomových bodů (třída GEOSCoordSequence). Vect_get_isle_points_geos() Vrací vnitřní hranici plochy (tj. hranici ostrova) jako sekvenci lomových bodů (třída GEOSCoordSequence). V tomto ohledu byla výrazně rozšířena funkcionalita jednoho ze zásadních nástrojů systému GRASS pro práci s vektorovými daty, a to modulu v.select sloužícího pro prostorové dotazování. Nativně tento modul podporuje pouze jediný prostorový operátor a to overlap. Integrace knihovny GEOS do vektorové architektury systému GRASS umožnila výrazně rozšířit nabídku prostorových operátorů modulu v.select tak, jak jsou definovány ve specifikaci OGC Simple Features Access [B6]. Jde o následující prostorové vztahy: equals, disjoint, intersects, touches, crosses, within, contains a relate. Operátor relate umožňuje definovat libovolný prostorový vztah na základě matice vzorku definované v rámci rozšířeného rozměrového 9-ti průsečíkového modelu (DE-9IM). Příklad. Jako příklad použití uvedeme výběr geodetických bodů (vektorová mapa geodetic_pts), které jsou prostorově lokalizovány v okresu Transylvania. Nejprve na základě atributového dotazu (modul v.extract) vybereme polygon reprezentující oblast tohoto okresu. GRASS> v.extract input=boundary_county output=transylvania \ where="name= TRANSYLVANIA "

117 4.2. PODPORA GEODATABÁZE POSTGIS V SYSTÉMU GRASS GIS 103 Poté aplikujeme prostorový dotaz (modul v.select). Body ležící uvnitř daného polygonu budou vybrány pomocí prostorové funkce knihovny GEOS GEOSWithin(), tj. prostorového operátoru within. GRASS> v.select ainput=geodetic_pts binput=transylvania \ output=geodetic_pts_trans operator=within 4.2 Podpora geodatabáze PostGIS v systému GRASS GIS Kapitola shrnuje výsledky práce v oblasti integrace geodatabáze PostGIS v systému GRASS verze 7. Návrh a implementace rozhraní PostGIS ve vektorové knihovně systému GRASS je blíže popsán v kap Podpora PostGIS v rozhraní OGR ve verzi GRASS 7 K vektorovým datům uloženým v geodatabázi PostGIS lze přistupovat přes obecnější rozhraní OGR. Na tomto místě uvedeme korespondující příklad z kap aplikovaný na verzi GRASS 7. Ve verzi GRASS 7 používá vektorová knihovna pro přístup k externím datům v geodatabázi PostGIS přednostně nativní rozhraní (kap ). Definováním proměnné prostředí GRASS_VECTOR_OGR můžeme zajistit, že bude pro přístup k datům použito na místo toho rozhraní OGR. Příklad pro příkazový interpret Bash 2 : export GRASS_VECTOR_OGR=1 Vytvoření vektorové mapy urbanarea_pg jako odkazu na PostGIS vrstvu proběhne obdobně včetně sestavení pseudo-topologie. GRASS> v.external dsn=pg:dbname=pgisnc layer=urbanarea output=urbanarea_pg... Using external data format PostgreSQL (feature type polygon ) Building pseudo-topology over simple features Number of nodes: 643 Number of primitives: 1321 Number of boundaries: 664 Number of centroids: 657 Number of areas: 664 Number of isles: 664 v.external complete. Link to vector map <urbanarea_pg> created. 2 Bash je název unixového shellu,

118 104 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Vzhledem k tomu, že rozhraní OGR ve vektorové knihovně GRASS verze 7 podporuje režim zápisu (viz kap ), lze data uložená v geodatabázi PostGIS modifikovat přímo pomocí standardních nástrojů systému GRASS, viz demonstrační příklad níže. Příklad. Příkaz odstraní z vektorové mapy urbanarea_pg, tj. PostGIS vrstvy registrované v aktuálním mapsetu, plošný element s identifikátorem 1. GRASS> v.edit map=urbanarea_pg tool=delete id=1 Selecting features... 1 of 1321 features selected from vector map <urbanarea_pg@sqlite> 1 features deleted... Using external data format PostgreSQL (feature type polygon ) Building pseudo-topology over simple features Number of nodes: 642 Number of primitives: 1319 Number of boundaries: 663 Number of centroids: 656 Number of areas: 663 Number of isles: 663 v.edit complete. Editace atributových dat. Dalším z aspektů plnohodnotné podpory OGR v systému GRASS verze 7 je rozšíření 3 OGR databázového ovladače knihovny DBMI o možnost modifikovat atributová data vektorových geoprvků (OGR Features) standardními nástroji systému GRASS. Uživatel tak může modifikovat kromě geometrie externích vektorových dat také jejich atributy. Příklad. V níže uvedeném demostračním příkladu je přidán do atributové tabulky pomocí modulu v.db.addcolumn nový sloupec s názvem vymera a datovým typem double precision. Posléze je pomocí modulu v.to.db do tohoto atributu uložena vypočtená výměra plošných geoprvků. GRASS> v.db.addcolumn map=urbanarea_pg column="vymera double precision" GRASS> v.to.db map=urbanarea_pg option=area columns=vymera 3 Implementace podpory režimu zápisu v OGR databázovém ovladači DBMI (autor: Martin Landa), SVN revize r47225.

119 4.2. PODPORA GEODATABÁZE POSTGIS V SYSTÉMU GRASS GIS Nativní podpora PostGIS ve verzi GRASS 7 Přístup k vektorovým datům uloženým v geodatabázi PostGIS přes OGR rozhraní vektorové knihovny systému GRASS (viz kap ) není zcela optimální hned ze dvou důvodů. Vektorová data jsou z geodatabáze PostGIS nejprve načtena do abstraktního datového modelu knihovny OGR 4 (kap ). V druhém kroku jsou data jako tzv. OGR Features z datového modelu knihovny OGR načítána do interních datových struktur vektorové knihovny systému GRASS (viz obr. 4.3). Obrázek 4.3: Rozhraní PostGIS a OGR vektorové knihovny systému GRASS (autor: Martin Landa, 2013). S tím souvisí další nevýhoda OGR rozhraní. Knihovna OGR implementuje specifikaci OGC Simple Features Access, tedy bez topologického náhledu na vektorová data. Ve výsledku OGR rozhraní podporuje pouze přístup v režimu jednoduchých geoprvků. Výše uvedené důvody vedly ke snaze rozšířit vektorovou knihovnu GRASS verze 7 kromě rozhraní OGR o nativní podporu geodatabáze PostGIS. Jinými slovy, umožnit vektorové knihovně systému GRASS číst a zapisovat data ve formátu PostGIS nativně, tj. bez knihovny OGR jako mezičlánku. Nativní podpora PostGIS ve vektorové knihovně GRASS verze 7 přináší v porovnání s rozhraním OGR optimalizovaný a rychlejší přístup k datům jak v režimu čtení, tak v režimu zápisu. Odpadá závislost na knihovně OGR, geometrická složka popisu geodat je načítána pomocí funkcí PostGIS rozhraní vektorové knihovny systému GRASS. Atributová složka popisu geodat ovladačem PostgreSQL (pg) knihovny DataBase Management Interface (DBMI), která je součástí základní sady knihoven systému GRASS. 4 V případě OGR ovladače PostgreSQL/PostGIS odpovídá instance třídy OGRDataSource databázi, instance třídy OGRLayer odkazuje na danou tabulku v rámci databáze a instance třídy OGRFeature na jednotlivé záznamy v tabulce.

120 106 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Příklad. Demostrace připojení PostGIS vektorových dat jako vektorové mapy v systému GRASS. Pro ověření výsledku je použit modul v.info, který vypisuje základní metadatové informace o vektorové mapě. GRASS> v.external dsn=pg:dbname=pgisnc layer=urbanarea output=urbanarea_pg GRASS> v.info map=urbanarea_pg... Map format: PostGIS (PostgreSQL) DB table: public.urbanarea DB name: pgisnc Geometry column: wkb_geometry Feature type: polygon Režim zápisu PostGIS rozhraní vektorové knihovny systému GRASS V souvislosti s vývojem nativního rozhraní vektorové knihovny systému GRASS pro geodatabázi PostGIS byl kromě režimu čtení implementován autorem práce také režim zápisu. Rozhraní PostGIS umožňuje vytvářet nová vektorová data či modifikovat existující data v geodatabázi PostGIS přímo pomocí standardních nástrojů systému GRASS. Z uživatelského pohledu je tato funkcionalita dostupná v rámci nově začleněného modulu v.external.out (viz kap ). Podobně jako v režimu čtení, tak i zde, proměnná prostředí GRASS_VECTOR_OGR ovlivňuje, zda bude pro zápis vektorových dat používáno nativní rozhraní PostGIS či PostgreSQL ovladač knihovny OGR. Na rozdíl od knihovny OGR umožňuje nativní rozhraní PostGIS ukládat vektorová data i v topologické formě a nikoliv pouze jako jednoduché geoprvky, více v kap Příklad. V níže uvedené demonstraci nejprve definujeme PostGIS databázi, do které bude systém GRASS výstupní vektorová data zapisovat, a to pomocí modulu v.external.out. GRASS> v.external.out dsn=pg:dbname=pgisnc format=postgresql \ options="schema=grassout" V našem případě je definována geodatabáze pgisnc. Syntax je schodná s OGR rozhraním, tj. prefix PG: a tzv. connection string. Dále je pomocí parametru options definováno databázové schéma, ve kterém budou vektorové vrstvy vytvářeny. Pokud toto schéma neexistuje, bude vektorovou knihovnou systému GRASS automaticky vytvořeno. Pro účel demonstrace nejprve nastavíme výpočetní region pomocí modulu g.region a v rámci tohoto regionu vytvoříme náhodnou bodovou vektorovou mapu (modul v.random).

121 4.2. PODPORA GEODATABÁZE POSTGIS V SYSTÉMU GRASS GIS 107 Na základě takto vytvořených bodových dat provedeme Delaunayho triangulaci 5 (modul v.delaunay). Informace o formátu vektorových dat, počtu a typu vektorových elementů ověříme pomocí modulu v.info. GRASS> g.region n=100 s=0 e=100 w=0 res=1 GRASS> v.random output=n100 n=100 GRASS> v.info map=n Map format: PostGIS (PostgreSQL) DB table: grassout.n100 DB name: pgisnc Geometry column: geom Feature type: point... Number of points: GRASS> v.delaunay -l input=n100 output=d100 GRASS> v.info map=d Map format: PostGIS (PostgreSQL) DB table: grassout.d100 DB name: pgisnc Geometry column: geom Feature type: linestring... Number of lines: Na obr. 4.4 je zobrazena výsledná konfigurace Delaunayovi triangulace. Vstupní bodová data jsou zvýrazněna modrou barvou Integrace PostGIS Topology ve vektorové architektuře GRASS GIS Jedním ze zásadních aplikačních výstupů disertační práce je integrace podpory rozšíření PostGIS Topology, konkrétně topologického modelu Topo-Geo, ve vektorové architektuře GRASS verze 7. 5 Delaunayova triangulace,

122 108 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Obrázek 4.4: Příklad grafického výstupu dat uložených v geodatabázi PostGIS Delaunayova triangulace (autor: Martin Landa, 2012). Topologický model vektorové architektury GRASS verze 7 (kap ) se od modelu Topo-Geo (kap ) implementovaného v rámci PostGIS Topology liší hned v několika aspektech: 1. Bodová data nejsou zahrnuta v topologickém modelu GRASS verze 7. Model Topo-Geo reprezentuje bodová data tzv. izolovanými uzly. 2. Centroid jako topologický element datového modelu GRASS není součástí topologického modelu Topo-Geo. Model Topo-Geo pracuje pouze s uzly, hranami a stěnami. Při konverzi topologické reprezentace vektorových dat ze systému GRASS do modelu Topo-Geo jsou centroidy uloženy jako izolované uzly včetně identifikátoru stěny, viz atribut containing_face tabulky node. 3. Topologický model GRASS nepoužívá hrany jako topologické elementy, nýbrž rozděluje liniové topologické elementy na linie a hraniční linie. Toto rozdělení vede ke znatelné optimalizaci datového modelu, např. u linie (tj. liniového elementu, který ze své podstaty nemůže reprezentovat úsek hranice plochy) není nutné ukládat informaci o ploše ležící napravo či nalevo. 4. Na rozdíl od modelu Topo-Geo neuchovává topologický model GRASS verze 7 v případě liniových elementů informaci o hraně stěny nalevo (next_left_edge) a napravo (next_right_edge). Tyto informace jsou v topologickém modelu GRASS dostupné jako součást topologické kompozice ploch a ostrovů. 5. V modelu Topo-Geo jsou plošné topologické elementy vyjádřeny jako stěny, kromě identifikátoru stěny je uložen také minimální ohraničující obdélník plošného elementu, a to z důvodu prostorového indexování. Pokud uživatel chce například zjistit, které

123 4.2. PODPORA GEODATABÁZE POSTGIS V SYSTÉMU GRASS GIS 109 hrany tvoří vnější hranici plochy, musí být tyto informace zjištěny výpočtem z tabulky hran, viz SQL funkce rozšíření PostGIS Topology ST_GetFaceEdges(). Topologický model GRASS verze 7 informace o plochách ukládá explicitně. Dochází tak k určité míře duplicity uložených topologických informací, a tudíž i k větším paměťovým nárokům kladeným na tento datový model. Na druhou stranu je v důsledku explicitně uložených informací datový model systému GRASS rychlejší v dotazování topologických vlastností především plošných elementů. 6. Plošný topologický element označovaný v datovém modelu GRASS jako ostrov v topologickém modelu Topo-Geo zcela chybí. Souhrnné porovnání topologických modelů Topo-Geo a GRASS nabízí tab Z výše uvedeného je zřejmé, že přímá konverze není mezi těmito datovými modely možná. Chybějící informace je nutné dopočítat, resp. odvodit z dostupných topologických informací daného modelu. Tabulka 4.1: Porovnání topologických modelů GRASS a Topo-Geo. GRASS GIS nlines, lines, angles start/end node start/end node, left/right area area nlines, lines, nisles, isles, centroid nlines, lines, area Node / Uzel Edge / Hrana Line / Linie PostGIS Topology Boundary / Hraniční linie containing_face, geom(point) start/end node, next left/right edge, left/right face, geom (LineString) Centroid / Reprezentační bod plochy Face / Stěna Area / Plocha Isle / Ostrov mbr(polygon) Ke konverzi topologických informací z modelu Topo-Geo dochází při otevření vektorové mapy, která je odkazem na topologické schéma v rámci PostGIS Topology. Podobně při uzavření vektorové mapy dochází k aktualizaci topologických informací Topo-Geo, tj. atributů tabulek node, edge a face, na základě dat uložených v topologickém modelu vektorové knihovny systému GRASS.

124 110 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE V rámci integrace PostGIS Topology v nativním rozhraní PostGIS vektorové knihovny systému GRASS byly implementovány dva topologické režimy. Ve výchozím stavu systém GRASS při konverzi topologických elementů do datového modelu Topo-Geo ukládá do topologického schématu kromě definovaných elementů jako jsou uzly, hrany a stěny také plošné elementy datového modelu GRASS, tj. plochy a ostrovy. Navíc pro uzly definuje dodatečné informace. Topologické schéma je rozšířeno o tři nové tabulky a to node_grass, area_grass a isle_grass, viz tab Vztah mezi tabulkami datového modelu Topo-Geo a rozšiřujícími tabulkami je znázorněn na obr Tabulka 4.2: Přehled dodatečných tabulek datového modelu GRASS. node_id lines angles area_id lines isles centroid isle_id lines area Tabulka uzlů node_grass primární klíč, identifikátor uzlu seznam hran, které jsou s uzlem svázány seznam hodnot úhlů výše uvedených hran v radiánech Tabulka ploch area_grass primární klíč, identifikátor ploch seznam hran, které tvoří hranici plochy seznam ostrovů, které jsou součástí plochy centroid plochy Tabulka ostrovů isle_grass primární klíč, identifikátor ostrovu seznam hran, které tvoří hranici ostrovu plocha se kterou je ostrov spojen Druhý režim aktivovaný volbou options=topo_geo_only=yes u modulů v.external.out (kap ) a v.out.postgis (kap ) ukládá v topologickém schématu pouze tabulky definované rozšířením PostGIS Topology, tj. node, edge a face. Při načítání dat do datového modelu GRASS jsou chybějící informace o uzlech, plochách a ostrovech odvozeny z topologických informací datového modelu Topo-Geo. Z toho vyplývá zvýšená časová náročnost tohoto režimu. Při otevření vektorové mapy se musí chybějící topologické informace dopočítat tak, aby vnitřní datové struktury topologického modelu GRASS byly korektně naplněny. Pro ilustraci je na obr. 4.6 znázorněna topologická reprezentace situace uvedené na obr v topologickém modelu GRASS verze 7. Porovnáním s reprezentací v topologickém modelu Topo-Geo (obr. 1.26) můžeme konstatovat následující rozdíly: 1. bod není reprezentován uzlem (N 15 v modelu Topo-Geo), ale vektorovým elementem P 18 (P Point),

125 4.2. PODPORA GEODATABÁZE POSTGIS V SYSTÉMU GRASS GIS 111 Obrázek 4.5: Relační diagram rozšířeného topologického schématu PostGIS Topology. Relace, které rozšiřují datový model Topo-Geo jsou zvýrazněny zelenou barvou. (autor: Martin Landa, 2013). 2. hrany, které představují hranice ploch, jsou reprezentovány topologickým elementem typu hraniční linie (B Boundary), 3. hrany reprezentující linie (tj. lomené čáry, které nemohou ze své podstaty definovat hranice plochy) jsou označeny jako L 6 a L 17 (L Line), 4. stěny F 1 5 jsou v topologickém modelu GRASS vyjádřeny jako plochy (A area), 5. topologický model GRASS definuje centroidy C 1 5, 6. plochy v topologickém modulu GRASS současně formují ostrovy (v tomto případě plochy A 1 5 formují ostrov I 1 ). Obrázek 4.6: Příklad topologického modelu GRASS verze 7 (viz kompozice obr. 1.25) (autor: Martin Landa, 2013).

126 112 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Nástroje systému GRASS pro práci s geodatabází PostGIS V úvodní části kapitoly jsou popsány již existující nástroje pro import a export vektorových dat PostGIS v systému GRASS v.in.ogr a v.out.ogr (kap ). Hlavní část textu se věnuje nově navrženému nástroji v.out.postgis, viz kap Dále jsou zmíněny plány budoucího vývoje s cílem plnohodnotné podpory geodatabáze PostGIS v systému GRASS Import a export vektorových dat PostGIS v systému GRASS Systém GRASS od verze 6 disponuje nástroji, které umožňují import a export vektorových dat PostGIS, a to pomocí knihovny OGR (kap. 1.4). Vzhledem k tomu, že knihovna OGR implementuje specifikaci OGC Simple Features Access [B6], jsou jednotlivé vektorové elementy vyjádřeny jako jednoduché geoprvky (viz kap ). Tyto jednoduché geoprvky (OGR Features) jsou posléze modulem v.in.ogr rozloženy na topologické elementy odpovídající datovému modelu GRASS, např. polygony jsou rozloženy na hraniční linie a centroidy tak, že část hranice společná pro dva sousedící polygony je uložena pouze jednou. Při této konverzi dochází ke kontrole topologie, případné topologické inkonzistence jsou modulem v.in.ogr automaticky opraveny. V ideálním případě by měly být výstupem po konverzi do nativního formátu GRASS topologicky korektní reprezentace vstupních jednoduchých geoprvků. Příklad. Import polygonových dat z PostGIS databáze pgisnc. Po konverzi je vstupních 656 polygonů reprezentováno v topologickém modelu GRASS 560 uzly (koncové body hraničních linií), 1043 hraničními liniemi a 656 centroidy. Vzniká tak 656 ploch, které formují celkem 182 ostrovů. Ostrov může odpovídat díře v polygonu, anebo souvislé množině polygonů, viz kap GRASS> v.in.ogr dsn=pg:dbname=pgisnc layer=urbanarea output=urbanarea_2... Importing 656 features (OGR layer <urbanarea>) Building topology for vector map <urbanarea_2> Number of nodes: Number of boundaries: 1043 Number of centroids: 656 Number of areas: 656 Number of isles: 182

127 4.2. PODPORA GEODATABÁZE POSTGIS V SYSTÉMU GRASS GIS 113 Opačný postup, tj. konverzi topologicky orientovaných vektorových dat z nativního formátu GRASS do zvoleného výstupního vektorového GIS formátu, který je podporován knihovnou OGR v režimu zápisu, umožňuje modul v.out.ogr. Při této konverzi jsou topologická vektorová data převedena do formy jednoduchých geoprvků a posléze pomocí knihovny OGR uložena do zvoleného výstupního GIS formátu. Příklad. Export vektorové mapy urbanarea do databáze PostGIS pgisnc. Výstupní PostGIS tabulka bude vytvořena v databázovém schématu grassout. GRASS> v.out.ogr input=urbanarea dsn=pg:dbname=pgisnc \ format=postgresql olayer=grassout.urbanarea... v.out.ogr complete. 656 features written to <grassout.urbanarea> (PostgreSQL) Modul v.out.postgis Nově navržený modul v.out.postgis [B25] do jisté míry nahrazuje v.out.ogr pro export vektorových dat ze systému GRASS do geodatabáze PostGIS. Na rozdíl od modulu v.out.ogr nepoužívá pro konverzi knihovnu OGR, nýbrž nativní rozhraní PostGIS vektorové knihovny GRASS verze 7 v režimu zápisu (kap ). Ve výchozím nastavení exportuje topologická data jako jednoduché geoprvky, z tohoto pohledu nabízí stejnou funkcionalitu jako již zmiňovaný modul v.out.ogr. Modul v.out.postgis byl autorem práce implementován v programovacím jazyce ANSI C jako standardní nástroj systému GRASS verze 7. Modul podporuje na rozdíl od v.out.ogr export topologických dat a také 3D vektorová data. V režimu exportu jednoduchých geoprvků jsou 2,5D plochy (tj. plochy, u kterých je pro lomové body hranice definována z-ová souřadnice) a 3D plochy ( stěny v terminologii datového modelu GRASS, viz kap ) exportovány jako 3D polygony (datový typ POLYGONZ). 3D vektorová data lze volitelně vyexportovat do geodatabáze PostGIS jako 2D geoprvky, viz přepínač -2). Syntax modulu je následující: Description: Exports a vector map layer to PostGIS feature table. Keywords: vector, export, PostGIS, simple features, topology, 3D Usage: v.out.postgis [-tl2] input=name [type=string[,string,...]] [layer=string] dsn=string [olayer=name] [olink=name] [options=key=value[,key=value,...]] [--overwrite] [--verbose] [--quiet]

128 114 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Flags: -t Don t export attribute table -l Export PostGIS topology instead of simple features -2 Force 2D output even if input is 3D Useful if input is 3D but all z coordinates are identical --o Allow output files to overwrite existing files --v Verbose module output --q Quiet module output Parameters: input Name of input vector map type Feature type options: point,line,boundary,centroid,area,face,kernel,auto default: auto layer Layer number or name default: 1 dsn Name for output PostGIS datasource olayer Name for output PostGIS layer olink Name for output vector map defined as a link to the PostGIS layer options Creation options Příklad. Export vektorových dat uvedený v kap by v případě modulu v.out.postgis vypadal následovně: GRASS> v.out.postgis input=urbanarea dsn=pg:dbname=pgisnc \ olayer=grassout.urbanarea Syntax je totožná s modulem v.out.ogr pouze s tím rozdílem, že není třeba definovat výstupní datový formát, kterým je vždy PostgreSQL/PostGIS. Modul v.out.postgis na rozdíl od v.out.ogr umožňuje také export vektorových dat do databáze PostGIS v topologické formě. V tomto případě nedochází ke konverzi topologických elementů z datového modelu GRASS do formy jednoduchých geoprvků dle specifikace OGC Simple Features Access, ale k jejich převodu do datového modelu Topo-Geo tak, jak jej implementuje rozšíření PostGIS Topology. Více k tématu konverze mezi topologickými modely GRASS a Topo-Geo v kap V uvedeném příkladě budou plošné vektorové elementy z vektorové mapy urbanarea vyjádřeny v PostGIS Topology topologickými elementy jako jsou uzly, hrany a stěny. V topologickém modelu systému GRASS jsou plochy vyjádřeny množinou hraničních linií a centroidů. Hraniční linie jsou po konverzi do datového modelu Topo-Geo reprezentovány hranami. Koncové body hraničních linií jsou uloženy jako uzly. Centroidy jsou vyjádřeny v datovém modelu Topo-Geo izolovanými uzly umístěnými uvnitř stěn. Plochy a ostrovy jsou reprezentovány v podobě stěn. Ostrov je vyjádřen stěnou se záporným identifikátorem.

129 4.2. PODPORA GEODATABÁZE POSTGIS V SYSTÉMU GRASS GIS 115 Příklad. Topologický režim exportu je aktivován přepínačem -l ( Export PostGIS topology instead of simple features ). GRASS> v.out.postgis -l input=urbanarea dsn=pg:dbname=pgisnc olink=urbanarea_pg Výše uvedený příkaz vytvoří v geodatabázi pgisnc tabulku urbanarea a topologické schéma topo_urbanarea. Toto schéma naplní topologickými elementy datového modelu Topo-Geo jako reprezentaci vstupních vektorových dat topologického modelu GRASS. Díky parametru olink modul taktéž vytvoří v aktuálním mapsetu novou vektorovou mapu urbanarea_pg jako odkaz na vytvořenou PostGIS tabulku urbanarea. Uživatel tak nemusí vytvářet tento odkaz manuálně pomocí modulu v.external Vývoj dalších nástrojů systému GRASS v rámci podpory geodatabáze PostGIS Aktuální vývoj (první polovina roku 2013) nástrojů systému GRASS pro práci s geodatabází PostGIS je zaměřen především na rozšíření digitalizačního nástroje wxgui (kap ) s cílem možnosti editace dat uložených v geodatabázi PostGIS přímo v systému GRASS včetně integrované kontroly topologické konzistence dat. Obrázek 4.7: Editace vektorových dat PostGIS v digitalizačním nástroji wxgui, režim jednoduchých geoprvků (autor: Martin Landa, 2012). V současnosti umožňuje digitalizační nástroj wxgui editaci vektorových dat PostGIS pouze v režimu jednoduchých geoprvků (body, linie, polygony), viz obr Autor práce si klade za cíl rozšířit digitalizační nástroj wxgui tak, aby umožňoval editovat vektorová data PostGIS i v topologickém režimu.

130 116 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE 4.3 Podpora pro 3D vektorová data v systému GRASS GIS Úvodní část textu kapitoly je věnována návrhu rozšíření datového modelu vektorové architektury systému GRASS verze 7 o nové 3D topologické elementy (kap ) s cílem implementace topologické správy 3D vektorových dat. V druhé části textu (kap ) jsou zmíněny nástroje systému GRASS pro zpracování a tvorbu 3D vektorových dat, které vznikly v rámci této práce. Základní 2D vektorové elementy datového modelu GRASS (bod, linie, hraniční linie a centroid) mohou mít volitelně definovánu z-tovou souřadnici. V tomto případě hovoříme o tzv. 2,5D vektorových datech. V této části textu se zaměříme na plnohodnotná 3D geodata, která jsou v topologickém modelu reprezentována 3D objemovými elementy. Jak již bylo zmíněno v kap , vektorová architektura GRASS verze 6 definuje dva základní 3D topologické elementy: stěnu (face) a reprezentační bod objemu (kernel). Tímto z pohledu podpory 3D vektorových dat GRASS ve verzi 6 končí. Zcela chybí topologická správa 3D vektorových dat včetně odvozených topologických elementů jako je objem (volume) či dutina, resp. otvor v tělese (hole) Topologický model systému GRASS pro 3D vektorová data Sada základních 3D topologických elementů (tj. stěna a kernel) datového modelu GRASS byla v rámci tohoto návrhu rozšířena o tři odvozené 3D topologické elementy: edge (hrana 6 ), volume (těleso, objem) a hole (dutina, otvor). Navržený 3D topologický model je koncipován jako rozšíření stávajícího 2D datového modelu (obr. 1.14). Diagram 2D/3D vektorového modelu systému GRASS je znázorněn na obr Část datového modelu relevantní pro správu 3D topologických elementů je zvýrazněna modrou barvou. Ve výsledku datový model umožňuje kromě bodových, liniových a plošných geoprvků definovat také objemové geoprvky (volume feature). Objemový topologický element volume je ohraničen minimálně čtyřmi stěnami. V tomto případě hovoříme o čtyřstěnu (tetraedr). Stěny jsou definovány jako rovinné a jsou ohraničeny minimálně třemi hranami. Hrany definující stěnu jsou řazeny ve směru hodinových 6 Termín hrana je použit v datovém modelu Topo-Geo (kap ) pro 2D liniový topologický element. V případě topologického modelu systému GRASS je tento termín použit pro 3D hraniční linii, tj. hranu stěny.

131 4.3. PODPORA PRO 3D VEKTOROVÁ DATA V SYSTÉMU GRASS GIS 117 Obrázek 4.8: Diagram navrženého 2D/3D topologického modelu vektorové architektury systému GRASS verze 7 koncipovaný jako rozšíření stávajícího 2D datového modelu. Nově definované 3D topologické elementy jsou zvýrazněny modrou barvou. (autor: Martin Landa, 2013). ručiček jako analogie k řazení hraničních linií v případě ploch. Tím je určena orientace stěny. Lze tedy určit objem ležící nalevo a napravo od stěny. Hrana je dána počátečním a koncovým uzlem. Tím je určena orientace hrany. Na obr. 4.9 je zobrazena stěna F 1, která je ohraničena čtyřmi hranami E 1 4. Obrázek 4.9: Určení orientace stěny v navrženém 3D topologickém modelu systému GRASS (autor: Martin Landa, 2013).

132 118 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Hrany E 1 4 určují celkem čtyři uzly N 1 4. V uvedeném případě bude hranice stěny určena hranami v pořadí { E 1, E 2, E 3, E 4 }. Záporné znaménko označuje hranu, která je orientována proti směru hodinových ručiček. Uvnitř objemu může být umístěn kernel, který plní funkci reprezentačního bodu tělesa, podobně jako centroid pro plochu ve 2D. Objem může obsahovat jednu a více dutin či otvorů (obr. 4.10), které jsou v topologickém modelu reprezentovány elementem typu hole. Otvor je modelován jako objem bez kernelu umístěný v dalším objemu. Jde o analogii 2D topologických elementů plochy a ostrova (viz obr. 2.5). Obrázek 4.10: Příklad otvoru ve stěně (A), otvoru v tělese (B) a dutiny v tělese (C) (zdroj: [A35]). Na obr je uveden příklad tělesa s dutinou. Těleso je v topologickém modelu reprezentováno objemem V 1, dutina jako objem V 2. Obrázek 4.11: Reprezentace tělesa s dutinou v 3D topologickém modelu GRASS verze 7 (autor: Martin Landa, 2013). Objem V 1 je ohraničen celkem šesti stěnami F 1 6, které jsou reprezentovány dvanácti orientovanými hranami E Každá hrana je definována dvěma uzly, např. hrana E 1 vede

133 4.3. PODPORA PRO 3D VEKTOROVÁ DATA V SYSTÉMU GRASS GIS 119 z uzlu N 1 do N 2. Uvnitř objemu V 1 je umístěn kernelem K 1. Druhý objem V 2 je ohraničen devíti hranami E 13 21, které tvoří celkem pět stěn F V analogii ke 2D tvoří každý z objemů V 1 a V 2 tzv. dutiny či otvory H 1 a H 2. Kompozice modelovaných 3D objektů je vyjádřena dvěma objemy V 1, V 2 a dvěma dutinami H 1, H 2. Dutina H 2 je totožná s objemem V 2 a reprezentuje v topologickém modelu dutinu ve studovaném tělese. Interní simplex reprezentace. Navržený 3D topologický model je v interní reprezentaci založen na tzv. simplexech (kap ) a vychází do jisté míry z datového modelu TEtrahedral Network (kap ). Hlavní výhodou simplexů je jednoduše definovaný vzájemný vztah mezi těmito objekty. kd simplex je definován množinou k + 1 (k 1)D simplexů. To znamená, že například 2D simplex (trojúhelník) je ohraničen třemi 1D simplexy (úsečkami) a 3D simplex (čtyřstěn) je ohraničen čtyřmi 2D simplexy (trojúhelníky). Další výhodou je rovinný charakter stěn, které jsou popsány třemi afinně nezávislými body. Simplexy jsou navíc vždy konvexní, tento fakt výrazně zjednodušuje úlohu typu bod v polygonu. Cenou je zvýšení náročnosti modelování komplexních objektů, které jsou v rámci tohoto datového modelu rozloženy na množinu simplexů. V tomto ohledu je datový model znázorněný na obr. 4.8 rozšířen o interní datové struktury shromažďující informace o 3D a 2D simplexech, tj. o čtyřstěnech (tetra) a trojúhelnících (triangle). Takto rozšířený datový model je znázorněn na obr D a 0D simplexy již součástí datového modelu jsou, a to v podobě topologických elementů hrany (edge) a uzlu (node). Obrázek 4.12: Diagram znázorňující 3D topologický model vektorové architektury systému GRASS doplněný o správu simplexů. Rozšířující datové elementy jsou zvýrazněny modrou barvou. (autor: Martin Landa, 2013).

134 120 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE V rámci implementace je datový model doplněn o dvě datové struktury: P_topo_tringle a P_topo_tetra. Datová struktura P_volume je rozšířena o seznam souvisejících čtyřstěnů (ntetras, tetras), podobně datová struktura P_face o seznam trojúhelníků (ntriangles, triangles). Na objemový topologický element volume můžeme tedy nahlížet jako na 3D complex, který lze rozložit na 1 až n 3D simplexů, tj čtyřstěnů. Topologický element stěny (face) lze podobně vnímat jako 2D complex, který lze rozložit na 1 až n 2D simplexů. Příklad. Jako příklad můžeme uvést budovu, která je vyjádřena v geometrickém modelu jako mnohostěn (obr. 4.13). Obrázek 4.13: Budova vyjádřená v geometrickém modelu jako mnohostěn (autor: Martin Landa, 2013). Vztah mezi geometrickými a topologickými elementy modelovaného objektu je relací 1 : n. V uvedeném případě to znamená, že je modelovaná budova v topologickém modelu TEN (obr. 4.14) reprezentována množinou na sebe navazujících čtyřstěnů (viz porovnání v tab. 4.3). Povrch modelovaného objektu tvoří 2D simplexy (trojúhelníky), které zároveň definují čtyřstěny. Tabulka 4.3: Vyjádření budovy jako mnohostěnu a množiny simplexů. Budova jako mnohostěn Budova v datovém modelu TEN 1 mnohostěn 8 čtyřstěnů 7 stěn 24 trojúhelníků 15 hran 25 hran 10 bodů 10 uzlů Složený topologický element označovaný jako objem, který v tomto případě reprezentuje 3D objekt modelované budovy, je v datovém modelu TEN rozložen na 8 čtyřstěnů, povrch tělesa tvoří celkem 20 trojúhelníků.

135 4.3. PODPORA PRO 3D VEKTOROVÁ DATA V SYSTÉMU GRASS GIS 121 Obrázek 4.14: Příklad rozložení mnohostěnu v datovém modelu TEN na množinu čtyřstěnů (zdroj: [A28]). V rámci experimentální implementace 3D topologického modelu ve vektorové architektuře systému GRASS autor vytvořil nástroj v.build3d pro sestavení 3D topologie. Podrobnější popis tohoto modulu je uveden v kap Nástroje systému GRASS pro práci s 3D vektorovými daty V rámci rozšíření podpory pro zpracování 3D vektorových dat byly v systému GRASS verze 7 implementovány nové moduly v.to.3d (kap ) a v.delaunay3d (kap ). Dále byly rozšířeny existující moduly v.drape a v.extrude z verze GRASS 6, viz kap Jako poslední je zmíněn experimentální modul v.build3d, který je určen pro sestavení topologie 3D vektorových dat (kap ). Funkcionalita výše zmíněných nástrojů je prezentována na kompozici obsahující bodové, liniové a plošné geoprvky, viz obr Obrázek 4.15: Příklad 2D vektorových dat: bodové (A), liniové (B) a plošné (C) geoprvky (autor: Martin Landa, 2013).

136 122 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Modul v.to.3d Modul v.to.3d [B26] je primárně určen pro převod 2D vektorových dat na 3D vektorová data, kdy je z-ová souřadnice 3D geoprvků odvozena buď z hodnoty atributového sloupce (parametr column) nebo uživatelem specifikované fixní hodnoty height. Příklad. Odvození z-ové souřadnice bodových geoprvků z atributového sloupce vyska. GRASS> v.to.3d input=koty type=point output=koty3d column=vyska Cílem modulu v.to.3d je definovat z-ovou souřadnici geometrického složky popisu geoprvků. Nedochází tedy ke změně typu vektorového elementu jako v případě modulu v.extrude popsaného v kap Příklad nastavení fixní z-ové souřadnice geometrické složky popisu bodových, liniových a plošných geoprvků znázorněných na obr je zobrazen na obr Pro ilustraci jsou geoprvky zobrazeny včetně digitálního modelu terénu (dále DMT), který je použit v případě dalších dvou níže popsaných modulů v.drape a v.extrude. Poznamenejme, že v tomto případě při odvození z-ové souřadnice DMT však nijak nefiguroval. Obrázek 4.16: Příklad použití modulu v.to.3d: nastavení z-ové souřadnice geometrické složky popisu geoprvků pro body (A), linie (B) a plochy (C) (autor: Martin Landa, 2013). Přepínač -r modulu v.to.3d umožňuje opačný proces, tj. převod 3D vektorových dat do 2D odstraněním z-ové souřadnice z geometrické složky popisu geoprvků. Volitelně lze uložit hodnoty z-ové souřadnice jako atribut, v tomto případě hovoříme o transformaci 3D dat na 2,5D vektorová data Další moduly pro tvorbu 3D vektorových dat Kromě nově vytvořeného modulu v.to.3d byly zásadně přepracovány další dva moduly systému GRASS primárně určené pro tvorbu 3D vektorových dat na základě 2D, resp. 2,5D vektorových dat. Jde o moduly v.drape a v.extrude.

137 4.3. PODPORA PRO 3D VEKTOROVÁ DATA V SYSTÉMU GRASS GIS 123 Modul v.drape [B27] je určen pro odvození z-ové souřadnice na základě hodnoty digitálního modelu terénu (DMT) pomocí bilineární, bikubické interpolace nebo metody nejbližšího souseda. Příklad výstupu modulu v.drape pro bodové, liniové a plošné geoprvky (viz obr. 4.15) je znázorněn na obr Obrázek 4.17: Příklad použití modulu v.drape: odvození z-ové souřadnice geometrické složky popisu geoprvků na základě digitálního modelu terénu pro body (A), linie (B) a plochy (C) (autor: Martin Landa, 2013). Příklad. Odvození výšky lomových bodů silničních komunikací ze zadaného DMT na základě bilineární interpolace. GRASS> v.drape input=silnice output=silnice_dmt elevation=dmt method=linear Modul v.extrude [B28] na rozdíl od dvou výše zmíněných modulů v.to.3d a v.drape při konverzi 2D vektorových dat do 3D modifikuje i typ vektorových elementů. Konkrétně: 2D body jsou převedeny na 3D vertikální linie, 2D linie na 3D vertikální stěny a 2D plochy na 3D tělesa (objemy). V případě ploch jsou na základě segmentů hraničních linií vytvořeny vertikální stěny, centroid je převeden na kernel. Takto vytvořený obvod tělesa je doplněn o dvě stěny, resp. množinu stěn pokud nejde o rovinný objekt, které reprezentuje horní a dolní část tělesa. V případě, že je uveden jako parametr elevation rastr DMT, tak je spodní část tělesa odvozena právě ze zadaného DMT. Příklad. Odvození budov z půdorysu, výška budov je dána atributem vyska. Spodní stěna budov je odvozena ze zadaného DMT (parametr elevation). GRASS> v.extrude input=budovy output=budovy3d elevation=dmt hcolumn=vyska

138 124 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Příklad výstupu modulu v.extrude pro 2D bodová, liniová a plošná geodata je uveden na obrázku obr V případě ploch (C) vzniknou tři tělesa, která spolu sdílí vždy jednu stěnu. Obrázek 4.18: Příklad použití modulu v.extrude: konverze 2D vektorových geoprvků na 3D vektorové geoprvky (A) 2D body 3D vertikální linie (B) 2D linie 3D vertikální stěny (C) plochy tělesa (autor: Martin Landa, 2013) Modul v.delaunay3d V rámci testování knihovny CGAL (kap. 1.7) vznikl experimentální nástroj systému GRASS pro 3D triangulaci. Modul v.delaunay3d vytvoří na základě vstupních 3D bodových dat nepravidelnou sít čtyřstěnů (datový model TEN, viz kap a příloha C.1). Modul v.delaunay3d provádí 3D Delaunayho triangulaci s využitím knihovny CGAL. Na rozdíl od ostatních modulů, které vznikly na základě této práce, není tento modul součástí oficiální distribuce systému GRASS verze 7. Modul v.delaunay3d je dostupný v rámci repozitáře GRASS Addons 7. Příklad. Vytvoření nepravidelné sítě čtyřstěnů pro bodová data převzata z obr GRASS> v.delaunay3d input=koty3d output=ten Obrázek 4.19: Příklad použití modulu v.delaunay3d: vytvoření nepravidelné sítě čtyřstěnů na základě vstupních 3D bodových dat (autor: Martin Landa, 2013). 7 GRASS Addons ( je repozitář určený pro uživatelské nástroje, které nejsou oficiální součástí distribuce systému GRASS.

139 4.3. PODPORA PRO 3D VEKTOROVÁ DATA V SYSTÉMU GRASS GIS Vizualizace 3D vektorových dat V rámci projektu wxgui (viz kap. 4.5) autor pracoval kromě jiného i na nadstavbě určené pro vizualizaci geodat ve 3D, viz wxnviz neboli wxgui 3D viewer (kap ). Součástí této činnosti byla i implementace části aplikace wxnviz zodpovědné za vizualizaci 2D a 3D vektorových dat. wxnviz podporuje vizualizaci 3D vektorových dat včetně nastavení barevného zobrazení na základě číselných kategorií či atributových dat přiřazených tělesům, resp. kernelům nebo izolovaným stěnám. Kromě interaktivního nástroje je výsledkem činnosti autora práce i nástroj pro příkazovou řádku m.nviz.image [B29], který umožňuje vytvořit na základně vstupních parametrů, 2D/3D rastrových a vektorových dat kompozici ve 3D a tu zapsat do obrazového formátu PPM nebo TIF. Nástroj v současné době pokrývá základní funkcionalitu aplikace wxnviz. Příklad. Nástroj m.nviz.image byl využit pro vykreslení 3D vektorových dat a podkladového DMT v případě obrázků uvedených v kap a dalších, viz příklad uvedený níže: GRASS> m.nviz.image elevation_map=dmt mode=fine resolution_fine=1 \ vpoint=koty3d vpoint_color=255:165:0 vpoint_marker=sphere \ position=0.69,0.77 height=196 perspective=19 twist=0 zexag=5 \ light_brightness=80 light_color=255:255:255 \ output=koty3d_image format=ppm size=798, Modul v.build3d Modul v.build3d má experimentální charakter. Podobně jako modul v.delaunay3d (kap ) je napsán v programovacím jazyce C++ a integruje knihovnu CGAL (kap. 1.7). Modul sestavuje topologii pro 3D vektorová data. Po ustálení implementace 3D topologie je plánováno funkcionalitu modulu integrovat do standardního modulu systému GRASS pro sestavování topologie v.build. V rámci v.build3d je implementována nová úroveň přístupu k vektorovým datům v systému GRASS. Stávající dvě úrovně přístupu bez topologie (level 1) včetně 2D topologie (level 2), jsou rozšířeny o novou úroveň přístupu, a to včetně 3D topologie (level 3).

140 126 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Příklad. Sestavení 3D topologie pro objekt budovy zobrazené na obr GRASS> v.build3d map=building Building 3D topology for vector map <building>... 7 primitives registered 10 vertices registered Building volumes... 1 volumes built 1 holes built Number of nodes: Number of faces: 7 Number of volumes: 1 Number of holes: 1... Number of edges: 25 Number of triangles: 24 Number of tetrahedrons: Integrace knihovny CGAL ve vektorové architektuře systému GRASS Integrace knihovny CGAL (kap. 1.7) ve vektorové architektuře systému GRASS není tak přímočará jako v případě knihovny GEOS (viz kap ). Knihovna GEOS je podobně jako CGAL napsána v programovacím jazyce C++. Na rozdíl od knihovny GEOS nicméně nedisponuje rozhraním pro programování aplikací (API) v jazyce C (tzv. C-API). Z tohoto důvodu nelze knihovnu CGAL přímo integrovat ve vektorové architektuře systému GRASS, která je implementována v ANSI C. Knihovna CGAL využívá hojně šablon 8. Proto nelze navrhnout universální C-API, které by odpovídalo svou šíří funkcionalitě knihovny samotné. Vytvořit lze pouze pro daný účel specifické C-API, které bude interně používat vždy šablony s deklarací specifického datového typu. Příkladem C-API knihovny CGAL je např. projekt SFGAL 9, který nedávno vznikl pro účel integrace vybraných algoritmů knihovny CGAL v projektu PostGIS, s cílem rozšíření funkcionality této geodatabáze při zpracování 3D geodat. Podobný postup byl autorem zvolen i pro tvorbu C-API knihovny CGAL specifické pro systém GRASS. Výsledkem je rozhraní GRASS-CGAL, které bylo v experimentální verzi začleněno do vektorové architektury systému GRASS 7. 8 Šablona (deklarace template) umožňuje deklarovat celou množinu tříd nebo funkcí, které se liší pouze deklaracemi typů datových členů a argumentů návratových hodnot funkcí [A51]. 9 OGC Simple Feature compliant library on top of CGAL,

141 4.4. NÁVRH SPRÁVY METADAT PRO VERZI GRASS Návrh správy metadat pro verzi GRASS 7 Cílem této části práce je návrh správy metadat v systému GRASS založený na technické normě ISO Geographic Information Metadata a Geographic Information Metadata XML Schema Implementation (kap ) Konsolidace metadat v systému GRASS GIS Nativní datový formát systému GRASS ukládá metadatové informace o rastrových a vektorových mapách v tzv. hlavičkových souborech a souborech s historií příkazů. Jak již bylo zmíněno v kap. 2.4, datový formát, struktura hlavičkového souboru, souboru s historií příkazů a funkce knihovny pro jejich čtení a zápis se liší podle toho, zda jde o data rastrová či vektorová. Cílem navrhovaného řešení je synchronizace nativního rastrového a vektorového formátu ve složce metadat. Funkce pro správu základních metadat jsou přesunuty z rastrové a vektorové knihovny do specializované knihovny, která byla v rámci práce navržena Základní metadata Hlavičkový soubor nativního rastrového formátu GRASS cellhd obsahuje metadata vztažená k rastrové mřížce. Základní metadata jsou uložena v souboru umístěném v adresáři hist. V případě nativního vektorového formátu jsou základní metadata uložena v hlavičkovém souboru head. Rastrová knihovna systému GRASS ve verzi 6 definuje datovou strukturu History, která slouží pro uložení základních metadat a nikoli pro historii příkazů, jak by její název mohl napovídat. Vektorová knihovna pro uložení základních metadat naopak definuje vlastní datovou strukturu dig_head. Navrhované řešení zavádí novou datovou strukturu Map_metadata jako náhradu za datové struktury History z rastrové knihovny a dig_head z knihovny vektorové. Klíče ve slovníku items (řádek 7) odpovídají tab Další klíče je možné definovat podle potřeby. 1 /*! 2 \ brief Z á kladn í metadata map 3 */ 4 struct Map_ metadata 5 { 6 /*! Seznam párů klíč: hodnota */ 7 struct Key_ Value items ; 8

142 128 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE 9 /*! Seznam koment ářů */ 10 char ** commets ; 11 }; Podpůrné funkce pro čtení a zápis metadat jsou implementovány ve specializované knihovně s prefixem funkcí MD. Funkce rastrové a vektorové knihovny, které jsou určeny pro práci s metadaty, byly odstraněny respektive nahrazeny funkcemi z nově navržené knihovny pro správu metadat. Tím byla sjednocena správa metadat rastrové a vektorové knihovny systému GRASS ve verzi Historie příkazů Pro rastrová data je uložen pouze záznam o posledním příkazu, na jehož základě byla data vytvořena, a to navíc jako součást základních metadat (soubor v adresáři hist). Nativní vektorový formát zahrnuje soubor hist, který obsahuje seznam všech příkazů, tj. kompletní historii vzniku vektorové mapy. Tento typ informací není rastrovou knihovnou udržován. Navrhované řešení přesunuje správu historie příkazů z vektorové knihovny do specializované knihovny pro správu metadat. Pro rastrová data je použit stejný formát souboru s historií příkazů jako pro data vektorová. Tento soubor je v případě rastrového formátu uložen v adresáři hist2 tak, aby nedošlo ke kolizi se základními metadaty (adresář hist). Zásadnější přepracování rastrového formátu je plánováno v GRASS verzi 8, kde by mělo dojít ke konsolidaci rastrového a vektorového formátu. Současně byly upraveny nástroje systému GRASS pro tisk metadat r.info a v.info tak, aby poskytovaly informace ve stejné formě jak pro rastrová, tak pro vektorová data Návrh správy metadat odpovídající technické normě ISO Výstupem této části práce je knihovna pro správu metadat umožňující podporu vybraných metadatových schémat. Prezentovaný prototyp implementuje schéma iso19139, viz technická norma ISO a (kap ). Knihovna a související nástroje byly implementovány v programovacím jazyce Python. Jádrem návrhu jsou třídy RasterMetadata a VectorMetadata, které shromažďují metadata ze systému GRASS. Z nich odvozené třídy jsou orientovány na dané metadatové schéma. V případě uvedeného prototypu jde o třídy RasterMetadataIso a VectorMetadataIso, které umožňují správu metadat rastrových a vektorových map na základě technické normy ISO V této souvislosti byly implementovány experimentální nástroje systému GRASS r.info2 a v.info2, které umožňují vygenerovat XML soubor s metadaty odpovídající výše uvedené technické normě.

143 4.4. NÁVRH SPRÁVY METADAT PRO VERZI GRASS Příklad. Tisk metadat vektorové mapy geodetic_pts. Výpis XML souboru byl přiměřeně zkrácen. GRASS> v.info2 map=geodetic_pts schema=iso <? xml version =" 1.0 " encoding ="UTF -8"?> 2 3 < gmd:md_metadata xmlns:gmd =" http: // www. isotc211. org /2005/ gmd " xmlns:gco =" http: // www. isotc211. org /2005/ gco "> 6 < gmd:contact > 7 < gmd:ci_responsibleparty > 8 < gmd: individualname > 9 < gco: CharacterString > helena </ gco: CharacterString > 10 </ gmd: individualname > 11 < gmd: organisationname > 12 < gco: CharacterString > NC OneMap </ gco: CharacterString > 13 </ gmd: organisationname > 14 </ gmd:ci_responsibleparty > 15 </ gmd: contact > 16 < gmd: datestamp > 17 < gco:datetime >Thu Oct :50: </ gco:datetime > 18 </ gmd: datestamp > 19 < gmd:metadatastandardname > 20 < gco: CharacterString > ISO : 2003 / </ gco: CharacterString > 21 </ gmd:metadatastandardname > < gmd:identificationinfo > 24 < gmd:md_dataidentification > 25 < gmd: abstract > 26 < gco: CharacterString > North Carolina geodetic points 27 ( points map ) </ gco: CharacterString > 28 </ gmd: abstract > < gmd:extent > 31 < gmd:ex_extent > </ gmd:ex_extent > 34 </ gmd:extent > 35 </ gmd:md_dataidentification > 36 </ gmd:identificationinfo > 37 </ gmd:md_metadata > Plnohodnotná integrace výše uvedených nástrojů je plánována až do verze GRASS 8, kde dojde k zásadnějším změnám v datových formátech, a to nejen z pohledu metadat.

144 130 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE 4.5 Vývoj nové generace grafického uživatelského rozhraní systému GRASS GIS Vývoj grafického uživatelského rozhraní (GUI) pro systém GRASS souvisí s tématem práce pouze nepřímo. Propojovacím prvek je především vývoj GUI nástrojů reflektujících aplikační výstupy práce v souvislosti s digitalizací a vizualizací 3D vektorových dat. Systém GRASS vyniká především šíří svých analytických nástrojů, zastaralé GUI (viz kap ) značně stěžovalo projektu jeho pozici na trhu. Právě tento aspekt měla změnit nová generace GUI označovaná jako wxgui. Prefix wx zdůrazňuje fakt, že je toto GUI postaveno na grafické knihovně wxpython 10. Vývoj nové generace nativního GUI systému GRASS velmi úzce souvisí s projektem GFOSS-TN. Tento projekt vznikl v rámci spolupráce nadace Fondazione Bruno Kessler a GIS oddělení městského úřadu Trento (Comune di Trento), Itálie. V roce 2011 záštitu nad projektem převzala nadace Fondazione Edmund Mach. Projekt GFOSS-TN představoval vyústění snah migrace GIS oddělení Comune di Trento na free software, a to především MapServer, QGIS a GRASS GIS [B30]. Autor práce se na projektu GFOSS-TN účastnil v letech a jako hlavní vývojář nového GUI. Projekt GFOSS-TN představoval počáteční impuls, bez něhož by pravděpodobně k vývoji nové generace GUI vůbec nedošlo a pokud ano, tak ne v takovéto míře. Zdrojový kód wxgui v současnosti (tj. k červnu 2013) čítá téměř řádek kódu včetně komentářů. Základní požadavky, kladené na novou generaci GUI systému GRASS, lze vyjádřit v následujících bodech: portabilita GRASS jako plně funkční multiplatformní desktopový GIS dostupný pro nejrozšířenější operační systémy, tj. GNU/Linux, Mac OS X a MS Windows, použitelnost uživatelsky přívětivé rozhraní běžné pro srovnatelné desktopové GIS aplikace, rozšiřitelnost možnost rozšířit GUI o nové komponenty jako je např. digitalizační, georektifikační či klasifikační modul, navrhnout API pro tzv. zásuvné moduly. Základní kostra wxgui je tvořena dvěma komponenty (viz obr. 4.20) správcem vrstev (Layer Manager) a mapovým oknem (Map Display Window). Kromě návrhu GUI, včetně základních komponent uživatelského rozhraní, se autor práce významnou měrou podílel 10 wxpython ( je multiplatformní port knihovny wxwidgets pro programovací jazyk Python.

145 4.5. VÝVOJ NOVÉ GENERACE GUI SYSTÉMU GRASS GIS 131 na vývoji dalších komponent wxgui. Konkrétně jde o digitalizační nástroj (kap ), rozšíření pro vizualizaci dat ve 3D (kap ) a grafický modeler (kap ). Obrázek 4.20: Základní komponenty wxgui správce vrstev a mapové okno (autor: Martin Landa, 2012) Digitalizační nástroj Návrh a vývoj digitalizačního nástroje systému GRASS je jedním z vedlejších analytických výstupů práce, a to především s ohledem na změny ve vektorové architektuře s cílem nativní podpory geodatabáze PostGIS, tj. možnosti editovat PostGIS data přímo pomocí nástrojů systému GRASS, včetně topologické správy vektorových dat. Obrázek 4.21: Digitalizační modul wxgui ve verzi GRASS 7 (autor: Martin Landa, 2013).

146 132 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE V druhé polovině roku 2007 byl autorem disertační práce implementován prvotní prototyp digitalizačního modulu integrovaného v prostředí wxgui. V rámci těchto snah vznikla knihovna VEdit [B31] a modul v.edit určený pro neinteraktivní editaci vektorových dat. Knihovna VEdit a modul v.edit byly implementovány v programovacím jazyce ANSI C. Digitalizační nástroj wxgui byl původně implementován v programovacím jazyce C++. K funkcím knihoven systému GRASS bylo přistupováno přes rozhraní Simplified Wrapper and Interface Generator (SWIG). Později v roce 2010 bylo rozhraní SWIG nahrazeno ve zdrojovém kódu systému GRASS integrací Python ctypes 11 [B32]. Vzhledem k tomu byl autorem zdrojový kód wxgui digitalizačního nástroje přepsán na počátku roku 2011 v programovacím jazyce Python a volání funkcí knihoven systému GRASS bylo implementováno právě s využitím rozhraní Python ctypes Rozšíření wxgui pro vizualizaci dat ve 3D Práce na rozšíření wxgui pro vizualizaci dat ve 3D (dále wxnviz) byla započata autorem v květnu 2008 v rámci programu Google Summer of Code. Dále byl vývoj projektu wxnviz v rámci téhož programu podporován v roce 2010 (student: Martin Landa, mentor: Helena Mitášová) a 2011 (student: Anna Kratochvílová, mentor: Martin Landa). WxNviz (obr. 4.22) nahrazuje aplikaci nviz z GRASS verze 6, která je podobně jako původní GUI systému GRASS založena na grafické knihovně TCL/TK (viz kap ). Obrázek 4.22: wxgui rozšíření pro vizualizaci dat ve 3D ve verzi GRASS 7 (autor: Martin Landa, 2010). 11 Integrace Python ctypes v projektu GRASS (autor: Glynn Clements), SVN revize r Digitalizační nástroj wxgui přepsán do jazyka Python (autor: Martin Landa), SVN revize r44823

147 4.5. VÝVOJ NOVÉ GENERACE GUI SYSTÉMU GRASS GIS 133 wxnviz obdobně jako jeho předchůdce využívá pro vizualizaci dat knihovnu GRASS OpenGL (OGSF Library). wxnviz je implementován jako rozšíření wxgui a ve svém důsledku je postaven na stejném uživatelském rozhraní, což je pro uživatele velmi výhodné. Mapové okno wxgui umožňuje plynule přepínat mezi 2D a 3D pohledem Grafický modeler Další komponentou wxgui, která byla vyvinuta autorem jako vedlejší produkt disertační práce je tzv. grafický modeler [B33]. Jedná se o nástroj, který nabízí intuitivní grafické rozhraní k vytváření modelů bez znalosti programování či skriptování. Prostředí grafického modeleru umožňuje řetězit nástroje systému GRASS tak, že výstup z jednoho modulu představuje vstup modulu následujícího. Parametry a přepínače jednotlivých modulů lze parametrizovat a umožnit tak uživateli zadat hodnoty těchto parametrů před spuštěním modelu. Prostředí grafického modeleru umožňuje definovat i proměnné, které ovlivňují parametry jednotlivých nástrojů systému GRASS použitých v daném modelu, definovat cykly for a podmínky typu if a else. Grafický modeler nabízí možnost model uložit do souboru GRASS Model File (GXM). Tento formát je založen na obecném značkovacím jazyce XML a byl autorem navržen speciálně pro potřeby grafického modeleru. Kromě toho lze model exportovat do obrazového souboru, a co je podstatnější, i do skriptu v programovacím jazyce Python. Obrázek 4.23: Příklad hromadného exportu vektorových dat pomocí modulu v.out.ogr do geodatabáze PostGIS ve wxgui grafickém modeleru (autor: Martin Landa, 2012).

148 134 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE 4.6 Podpora pro výměnný formát ISKN v knihovně OGR Knihovna OGR poskytuje přístup k celé řadě vektorových GIS formátů (viz kap. 1.4). Nicméně podpora pro výměnný formát ISKN (Informační systém katastru nemovitostí, kap ) v této knihovně doposud chyběla. Autorovi jsou známy dva projekty, které se věnovali zpracování výměnného formátu ISKN (dále VF ISKN) s využitím free softwaru. Prvním z nich je nástroj systému GRASS v.in.vfk, který je určen k importu dat ve výměnném formátu ISKN do nativního vektorového formátu GRASS (autor Martin Landa, diplomová práce, ČVUT v Praze, 2005 [A47]). Druhým z uvedených projektů je tzv. Otevřený katastr (autor Karel Jedlička et al., Západočeská univerzita v Plzni, 2007 [A52]). V rámci tohoto projektu je distribuována sada nástrojů pro import dat ve výměnném formátu ISKN do prostředí geodatabáze PostGIS. Oba výše zmíněné projekty jsou zaměřeny na vybrané prostředí. V prvním případě se jedná o systém GRASS GIS, v druhém o geodatabázi PostGIS. V tomto ohledu podpora výměnného formátu ISKN v knihovně OGR představuje obecnější řešení. Ve výsledku mohou všechny softwarové projekty, které knihovnu OGR využívají (GRASS GIS, QGIS, MapServer, Esri ArcGIS 9.3+ a další), výměnný formát ISKN podporovat Implementace podpory výměnného formátu ISKN v knihovně OGR Podpora pro výměnný formát ISKN byla autorem práce implementována v rámci tzv. ovladače VFK (VFK driver) knihovny OGR [B34]. Ovladač VFK byl implementován v programovacím jazyce C++ a posléze na začátku roku 2010 začleněn do oficiálního zdrojového kódu knihovny GDAL/OGR 13. První verze knihovny GDAL/OGR podporující výměnný formát ISKN byla vydána v lednu 2010 pod označením Přístup k datům VF ISKN je v knihovně OGR omezen pouze na režim čtení. Objektový návrh ovladače VFK odpovídá zásadám knihovny OGR. Ovladač VFK je implementován v rámci C++ třídy OGRVFKDriver jejíž rodičovskou třídou je OGRSFDriver (viz objektový model knihovny OGR znázorněný na obr. 1.20). Datový zdroj (data source) je implementován jako třída OGRVFKDataSource. Tato třída je odvozena z OGRDataSource. Datová vrstva je zastoupena třídou OGRVFKLayer, jejíž rodičovskou třídou je OGRLayer. Dále byly navrženy interní C++ třídy ovladače VFK implementující čtení dat ve výměnném formátu ISKN a jejich následné zpracování. Jde o následující třídy (viz diagram C++ tříd v příloze na obr. D.1): 13 Začlenění ovladače VFK do knihovny OGR (autor: Martin Landa), SVN revize r18449.

149 4.6. PODPORA PRO VÝMĚNNÝ FORMÁT ISKN V KNIHOVNĚ OGR 135 Třída VFKReader. Třída určená pro čtení dat ve výměnném formátu ISKN. Třída definuje metody pro čtení definic datových bloků (datové věty &B) ReadDataBlocks() a datových záznamů (datové věty &D) ReadDataRecords(). V rámci čtení vstupních dat ve výměnném formátu ISKN je třídou VFKReader zpracována i hlavička souboru (datové věty &H). Rodičovskou třídou je abstraktní třída IVFKReader. Třída VFKDataBlock. Třída reprezentuje datové bloky VF ISKN, tj. datové věty &B. Atributy datového bloku jsou vyjádřeny instancemi třídy VFKPropertyDefn. Třída obsahuje seznam jednotlivých datových záznamů korespondujících s daným datovým blokem vyjádřeným v objektovém modelu instancemi třídy VFKFeature. Třída VFKDataBlock je odvozena z třídy IVFKDataBlock. Třída VFKPropertyDefn. datový typ a délku (tab. 1.3). Třída definující atribut datového bloku, název atributu, jeho Třída VFKFeature. Třída reprezentující datový záznam, tj. datové věty &D VF ISKN. Třída obsahuje seznam atributů vyjádřených instancemi třídy VFKProperty. Třída definuje kromě jiného i metodu GetGeometry(), která vrací geometrii jednoduchého geoprvku, tj. instanci třídy OGRGeometry (viz obr. 1.19). Mezi podporované datové typy patří Point, LineString a Polygon. Třída VFKProperty. Třída definující hodnotu atributu. V letě 2011 byl ovladač VFK knihovny OGR autorem zásadně přepracován a rozšířen o interní podporu databáze SQLite 14. V rámci toho byla implementována C++ třída VFKReaderSQLite (rodičovská třída VFKReader), která načte datové věty výměnného formátu ISKN do databáze SQLite, tabulky jsou vytvořeny na základě definic datových bloků &B. Záznamy v tabulkách odpovídají datovým větám &D. Načtení dat výměnného formátu ISKN do tabulek v relačním databázovém systému SQLite umožňuje rychlejší přístup k datům především při sestavování geometrie jednoduchých geoprvků knihovnou OGR. Například při dotazu na danou parcelu musí ovladač VFK nejprve najít záznam v tabulce (tj. datovém bloku) PAR, a poté v tabulce HP (hranice parcel) najít všechny záznamy odpovídající hledané parcele. Hranice parcel odkazují na záznamy v tabulce SBP (liniové segmenty), která odkazuje na tabulku SOBR se souřadnicemi lomových bodů (viz obr. 4.24). Z těchto lomových bodů je odvozena vnější hranice polygonu parcely. Uložení dat v databázovém systému SQLite umožňuje definovat indexy nad 14 SQLite je light-weight relační databázový systém. SQLite není založen na principu klient-server, kde je databázový server spuštěn jako zvláštní proces. SQLite je implementována jako knihovna napsaná v programovacím jazyce C, kterou lze přilinkovat k aplikaci a přímo používat.

150 136 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE vybranými atributy a tak výrazně zrychlit vyhledávaní v datech s cílem sestavení geometrické a atributové složky popisu jednoduchých geoprvků reprezentovaných v objektovém modelu knihovny OGR instancemi třídy OGRFeature. S ohledem na integraci SQLite do ovladače VFK knihovny OGR byly implementovány C++ třídy VFKDataBlockSQLite (rodičovská třída IVFKDataBlock) a VFKFeatureSQLite (rodičovská třída IVFKFeature). Ve verzi knihovny GDAL/OGR 1.10 (duben 2013) byla rozšířena podpora SQLite v ovladači VFK o možnost uložení sestavené geometrie přímo v databázi ve formátu Well Known Binary (WKB). WKB je binární formát původně použitý ve specifikaci OGC Simple Features Access (kap. 1.3). Při opětovném načtení dat výměnného formátu ISKN ovladačem knihovny OGR není geometrie znovu sestavována, nýbrž je převzata z SQLite databáze. Proces sestavení geometrie může být poměrně časově náročný, zvláště pro parcely (datový blok PAR) či budovy (datový blok BUD), viz kap Vzhledem k tomu může uložení geometrie geoprvků přímo v databázi proces načítání dat výrazně urychlit (tab. 4.4). Pro testování byla použita data VFK, která jsou volně ke stažení na webových stránkách ČÚZK [B21]. Tabulka 4.4: Načítání dat výměnného formátu ISKN knihovnou OGR (v sekundách). všechny bloky pouze PAR První načtení (bez geometrie v DB) Druhé načtení (bez geometrie v DB) První načtení (geometrie v DB) Druhé načtení (geometrie v DB) Soubor ve výměnném formátu ISKN je knihovnou OGR rozpoznán jako tzv. datový zdroj (data source). Jednotlivé datové bloky jako vrstvy (OGR Layers). Ovladač VFK nejprve data ve výměnném formátu ISKN načte do vytvořené interní databáze SQLite. Tato podpůrná databáze je uložena ve stejném adresáři jako vstupní VFK data. Pokud již v tomto adresáři soubor s databází existuje, je ovladačem VFK použit. Znovunačtení dat knihovnou OGR je tedy znatelně rychlejší, data jsou z SQLite databáze načítána přímo bez konverze z výměnného formátu ISKN, viz tab Zpracování hlavičky Data hlavičky souboru (datové věty &H) jsou uložena jako metadata OGR datového zdroje. Následuje ukázka C++ zdrojového kódu pro tisk těchto metadat. 1 OGRVFKDataSource * pods ; 2

151 4.6. PODPORA PRO VÝMĚNNÝ FORMÁT ISKN V KNIHOVNĚ OGR /* otev ř í t OGR data source ( na č í st VFK soubor 4 z aktu álního adres áře) */ 5 pods -> Open ("./ data. vfk ", false ); 6 /* tisk metadat */ 7 std :: cout << " verze : " << pods -> GetInfo (" VERZE ") << std :: endl ; Zpracování datových bloků Datový blok výměnného formátu ISKN odpovídá OGR vrstvě (OGR Layer). Věta uvozená znakem &B definuje název vrstvy, seznam a datové typy atributů. Datové záznamy &D reprezentují geoprvky (OGR Features) OGR vrstvy. Seznam jednotlivých vrstev poskytuje např. nástroj knihovny OGR ogrinfo 15. $ ogrinfo data.vfk 1: PAR 2: BUD 3: ZPOCHN... 59: ZPMZ 60: NZZP 61: SPOL Příklad. Na základě (v jednom řádku) &BSBP;ID N30;STAV_DAT N2;DATUM_VZNIKU D;DATUM_ZANIKU D;PRIZNAK_KONTEXTU N1; RIZENI_ID_VZNIKU N30;RIZENI_ID_ZANIKU N30;BP_ID N30;PORADOVE_CISLO_BODU N38; OB_ID N30;HP_ID N30;DPM_ID N30;PARAMETRY_SPOJENI T100;ZVB_ID N30 je definována OGR vrstva SBP. Následuje informativní výstup z nástroje ogrinfo, viz přehled datových typů uvedených v tab $ ogrinfo data.vfk SBP Layer name: SBP ID: Integer (30.0) STAV_DAT: Integer (2.0) DATUM_VZNIKU: DateTime (0.0) DATUM_ZANIKU: DateTime (0.0) PRIZNAK_KONTEXTU: Integer (1.0) RIZENI_ID_VZNIKU: Integer (30.0) RIZENI_ID_ZANIKU: Integer (30.0) 15 Nástroj knihovny OGR ogrinfo,

152 138 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE BP_ID: Integer (30.0) PORADOVE_CISLO_BODU: Integer (38.0) OB_ID: Integer (30.0) HP_ID: Integer (30.0) DPM_ID: Integer (30.0) PARAMETRY_SPOJENI: String (100.0) ZVB_ID: Integer (30.0) Geometrie prvků digitální katastrální mapy Vybrané datové bloky slouží pro sestavení geometrie prvků digitální katastrální mapy. Přehled datových bloků je zobrazen na obr Obrázek 4.24: Přehled datových bloků výměnného formátu ISKN potřebných k vytvoření geometrie prvků digitální katastrální mapy (zdroj: [A53]). Bodové prvky. Datové bloky SOBR (souřadnice obrazu bodů polohopisu v mapě), OBBP (obrazy bodů BP) a SPOL (souřadnice polohy měřených bodů polohopisu) obsahují informace o bodových datech. Souřadnice bodů jsou uloženy jako atributy SOURADNICE_Y a SOURADNICE_X. Příklad. Výpis vybraného bodového prvku z vrstvy SOBR pomocí nástroje ogrinfo. $ ogrinfo data.vfk SOBR -where ID = Layer name: SOBR Geometry: Point

153 4.6. PODPORA PRO VÝMĚNNÝ FORMÁT ISKN V KNIHOVNĚ OGR OGRFeature(SOBR):1 ID (Integer) = STAV_DAT (Integer) = 0... UPLNE_CISLO (Integer) = SOURADNICE_Y (Real) = SOURADNICE_X (Real) = KODCHB_KOD (Integer) = 4 POINT ( ) Liniové prvky. Datové bloky definující geometrii liniových prvků digitální katastrální mapy jsou SBP (spojení bodů polohopisu) a SBM (spojení bodů mapy). Geometrie liniového prvku je vytvořena na základě minimálně dvou datových záznamů &D, které v tomto ohledu odpovídají vrcholovým bodům linie. Pořadí vrcholových bodů linie určuje atribut PORADOVE_CISLO_BODU, dále BD_ID odkazuje na atribut ID v datovém bloku SOBR, kde jsou uloženy souřadnice bodů. Příklad. SOBR: ID... SOURADNICE_Y SOURADNICE_X KODCHB_KOD SBP: ID... PORADOVE_CISLO_BODU... BP_ID V tomto případě je definována linie se dvěma vrcholovými body. OGRFeature(SBP):1 ID (Integer) = STAV_DAT (Integer) = 0... OB_ID (Integer) = (null) HP_ID (Integer) = DPM_ID (Integer) = (null) PARAMETRY_SPOJENI (String) = "4" ZVB_ID (Integer) = (null) LINESTRING ( , )

154 140 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Polygonové prvky. Polygonové prvky digitální katastrální mapy definují datové bloky PAR (parcely) a BUD (budovy). Vnější a vnitřní hranice polygonu vycházejí z liniových prvků definovaných v datovém bloku SBP. V případě hranice parcel liniovými prvky, které mají definován atribut HP_ID, například: OGRFeature(PAR):1 ID (Integer) = STAV_DAT (Integer) = 0... TEL_ID (Integer) = PAR_ID (Integer) = (null) BUD_ID (Integer) = IDENT_BUD (String) = "a" POLYGON (( , , )) Přístup k datům ve výměnném formátu ISKN přes API knihovny OGR Knihovnu OGR lze využít pro vývoj vlastních aplikací za účelem přístupu k datům ve výměnném formátu ISKN a jejich dalšímu zpracování. Jako příklad je v příloze D.5 uvedena jednoduchá aplikace implementovaná v programovacím jazyce C++ a Python FOSS nástroje pro přístup k datům ve výměnném formátu ISKN Díky implementaci podpory výměnného formátu ISKN v knihovně OGR se otevřel prostor pro přístup a zpracování dat ve výměnném formátu ISKN pro celou řadou nástrojů z oblasti free softwaru (FOSS), které využívají tuto knihovnu pro čtení vektorových GIS formátů. Na tomto místě zmíníme možnosti přístupu k datům ve výměnném formátu ISKN v desktopových GIS aplikacích GRASS GIS a QGIS GRASS GIS Data výměnného formátu ISKN lze do systému GRASS naimportovat podobně jako ostatní datové formáty podporované knihovnou OGR pomocí modulu v.in.ogr (kap ). Příklad. Import dat výměnného formátu ISKN jako vektorové mapy, datové bloky odpovídají vektorovým vrstvám (viz terminologické poznámky v kap ). GRASS> v.in.ogr dsn=data.vfk output=dkm

155 4.6. PODPORA PRO VÝMĚNNÝ FORMÁT ISKN V KNIHOVNĚ OGR 141 K jednotlivým vektorovým vrstvám lze přistupovat pomocí parametru layer. Na základě atributového dotazu například vybereme budovu (vrstva, tj. datový blok BUD) s domovním číslem 99, vybranou budovu uložíme jako vektorovou mapu bud_99. GRASS> v.extract input=dkm layer=bud where="cislo_domovni=99" output=bud_99 Kromě toho modul v.in.ogr umožňuje naimportovat pouze zvolenou OGR vrstvu, tj. datový blok výměnného formátu ISKN. Příklad importu parcel (datový blok PAR). GRASS> v.in.ogr dsn=data.vfk layer=par output=dkm_par Příklad. Vytvoření odkazu na data ve výměnném formátu ISKN (v níže uvedeném příkladě pouze na datový blok BUD, tj. budovy) pomocí modulu v.external. Formát vektorových dat je ověřen modulem v.info. GRASS> v.external dsn=data.vfk layer=bud output=dkm_bud GRASS> v.info map=dkm_bud... Map format: OGR (VFK) OGR layer: BUD OGR datasource: data.vfk Feature type: polygon... Příklad. Přímý přístup přes rozhraní OGR bez tvorby odkazu (viz kap ). V uvedeném příkazu jde o výběr budov, které mají definováno domovní číslo. Výsledek bude uložen jako vektorová mapa bud_cislo. GRASS> v.extract input=data.vfk@ogr layer=bud output=bud_cislo \ where="cislo_domovni IS NOT NULL" QGIS QGIS (Quantum GIS, je multiplatformní desktopová GIS aplikace. Projekt QGIS byl založen v roce 2002 s cílem vývoje prohlížečky geodat pro operační systém GNU/Linux. Postupem času se díky rostoucí komunitě vývojářů a uživatelů stal QGIS multiplatformním projektem podporujícím kromě OS GNU/Linux i MS Windows, Mac OS X či BSD. Díky integraci knihovny GDAL/OGR podporuje QGIS celou řadu rastrových a vektorových GIS formátů [A54]. Kromě toho nativně podporuje Post- GIS, SpatiaLite a GRASS.

156 142 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Obrázek 4.25: Logo projektu QGIS (zdroj: [B35]). Knihovny a základní aplikace systému QGIS jsou implementovány v programovacím jazyce C++ s využitím grafické knihovny Qt. Architektura systému QGIS dovoluje doplnit funkcionalitu aplikace v podobě tzv. zásuvných modulů (plugin). Zásuvné moduly mohou být implementovány v programovacím jazyce C++ a Python. V první polovině roku 2012 byl studenty 16 oboru Geoinformatika na Fakultě stavební ČVUT v Praze navržen a implementován pod vedením autora práce specializovaný zásuvný modul desktopové GIS aplikace QGIS pro práci s daty ve výměnném formátu ISKN (obr. 4.26). Více informací o návrhu a funkcionalitě tohoto zásuvného modulu QGIS v [C1]. Zásuvný modul QGIS pro práci s katastrálními daty byl implementován v programovacím jazyce C++ s využitím rozhraní pro programování aplikaci (API) systému QGIS a ovladače VFK knihovny OGR. Obrázek 4.26: Zásuvný modul QGIS pro práci s katastrálními daty (zdroj: [C1]). 16 Zásuvný modul QGIS pro práci s katastrálními daty byl vyvinut studenty oboru Geoinformatika FSv ČVUT v Praze Annou Kratochvílovou a Václavem Petrášem v rámci předmětu Projekt Informatika 2 v letním semestru 2011/2012.

157 4.6. PODPORA PRO VÝMĚNNÝ FORMÁT ISKN V KNIHOVNĚ OGR Topologická správa prvků digitální katastrální mapy v geodatabázi PostGIS Import dat ve výměnném formátu ISKN do geodatabáze PostGIS lze provést např. nástrojem knihovny OGR ogr2ogr 17. V tomto případě bude výstupem množina PostGIS tabulek odpovídající datovým blokům VFK. Geometrie prvků digitální katastrální mapy bude uložena ve formě jednoduchých geoprvků. V této kapitole se zaměříme na systém GRASS s důrazem na praktickou aplikaci výstupů práce týkajících se nativní podpory PostGIS, a především topologické správy vektorových dat v rozšíření PostGIS Topology (viz kap ). Cílem bude převést geometrii prvků digitální katastrální mapy uložené ve výměnném formátu ISKN do topologické formy spravované v geodatabázi PostGIS. Pro konverzi dat ve výměnném formátu ISKN do topologického schématu spravovaného v rámci PostGIS Topology lze v systému GRASS použít celkem dva postupy. První je postaven na kombinaci modulů v.in.ogr a v.external.out [B22] (viz kap ). Druhý postup využívá modul v.out.postgis [B25] (kap ) v kombinaci s přímým přístupem k externím datům přes OGR rozhraní vektorové knihovny systému GRASS (kap ). V obou případech se tak obejdeme bez mezičlánku vytvářet vektorová data v nativním formátu GRASS. Modul v.in.ogr je určen pro import vektorových dat podporovaných knihovnou OGR do systému GRASS. Výstupem je vektorová mapa v nativním souborově orientovaném formátu. Nicméně v kombinaci s modulem v.external.out můžeme tento výstupní formát změnit. V našem případě bude výstupním formátem PostgreSQL s volbou topology=yes. Bez této volby by vektorová data byla zapsána ve formě jednoduchých geoprvků a nikoliv v topologickém formátu. Příklad. Výstupní data, tabulka dkm_par a topologické schéma topo_dkm_par, budou uložena v geodatabázi pgisvfk. GRASS> v.external.out dsn=pg:dbname=pgisvfk format=postgresql \ options=topology=on GRASS> v.in.ogr dsn=data.vfk layer=par output=dkm_par Alternativní postup je založen na přímém přístupu k datům ve výměnném formátu ISKN přes OGR rozhraní vektorové knihovny systému GRASS, viz kap Nástroj knihovny OGR ogr2ogr,

158 144 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE Příklad. Vstupní data VFK jsou konvertována do geodatabáze PostGIS pomocí modulu v.out.postgis. Topologický výstup je aktivován přepínačem -l. Souřadnicový systém je nastaven na S-JTSK (EPSG:2065). Mapset OGR je virtuální, jeho zadání aktivuje přímý přístup k externím datům pomocí knihovny OGR. GRASS> v.out.postgis -l input=data.vfk@ogr layer=par dsn=pg:dbname=pgisvfk \ options="srid=2065" Topologická správa vektorových dat umožňuje provádět některé z dotazů bez nutnosti dalších výpočtů. V příkladě uvedeném níže budeme hledat parcely sousedící s parcelou, která má kmenové číslo 381. Kompozice je znázorněna na obr Obrázek 4.27: Vizualizace parcel digitální katastrální mapy, zvýrazněna je hranice parcely s kmenovým číslem 381 (autor: Martin Landa, 2013). Níže uvedené SQL dotazy jsou prováděny v geodatabázi PostGIS rozšířenou o správu topologických dat. Parcela s kmenovým číslem 381 je v topologickém modelu Topo-Geo (viz kap ) vyjádřena elementem stěny s identifikátorem SELECT (topo).* FROM dkm_par WHERE KMENOVE_CISLO_PAR = 381; topology_id layer_id id type Dále najdeme stěny, které sdílí hrany se stěnou SELECT right_face AS face FROM topo_dkm_par.edge WHERE left_face = 1043 UNION ALL SELECT left_face AS face FROM topo_dkm_par.edge WHERE right_face = 1043 ORDER BY face;

159 4.6. PODPORA PRO VÝMĚNNÝ FORMÁT ISKN V KNIHOVNĚ OGR 145 face Nakonec najdeme stěny, které jsou ohraničeny výše uvedenými hranami. Tyto stěny reprezentují hledané parcely. SELECT KMENOVE_CISLO_PAR FROM dkm_par WHERE (topo).id IN (253, 262, 263, 1051, 1052, 1060) ORDER BY KMENOVE_CISLO_PAR; kmenove_cislo_par Dotaz by ve výsledku mohl vypadat následovně: 1 SELECT KMENOVE_ CISLO_ PAR FROM dkm_ par WHERE ( topo ). id IN 2 ( 3 SELECT right_ face AS face FROM topo_ dkm_ par. edge WHERE left_ face = 4 ( 5 SELECT ( topo ). id FROM dkm_ par WHERE KMENOVE_ CISLO_ PAR = ) UNION ALL 7 SELECT left_ face AS face FROM topo_ dkm_ par. edge WHERE right_ face = 8 ( 9 SELECT ( topo ). id FROM dkm_ par WHERE KMENOVE_ CISLO_ PAR = ) 11 ) 12 ORDER BY KMENOVE_ CISLO_ PAR ;

160 146 KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE

161 Závěr Ve své disertační práci jsem se zabýval problematikou topologické správy 2D a 3D vektorových dat v geografických informačních systémech (GIS). Pojetí práce bych označil za analyticko-aplikační. V rámci vektorové architektury systému GRASS jsem se věnoval její interoperabilitě a návrhu topologické správy 3D vektorových dat. Jako implementační rámec jsem použil vývojovou verzí open source nástroje GRASS GIS označovanou číslicí 7. S ohledem na řešenou problematiku jsem se věnoval i analýze využitelnosti specifikace OGC Simple Features Access [B6], technické normy ISO Information technology Database languages SQL multimedia and application packages (SQL/MM) [A15] a ISO 19115, Geographic Information Metadata [A43] v open source nástroji GRASS GIS. Z pohledu interoperability vektorové architektury systému GRASS jsem implementoval rozhraní realizující plnohodnotnou podporu externích vektorových GIS formátů (kap. 4.1). Věnoval jsem se integraci knihovny OGR a především návrhu nativní podpory geodatabáze PostGIS včetně topologické správy vektorových dat (kap. 4.2). V rámci této části práce jsem se snažil řešit začlenění netopologického datového modelu jednoduchých geoprvků (simple features) a topologického modelu Topo-Geo z technické normy ISO SQL/MM ve vektorové architektuře systému GRASS. Dalším tématem, kterému jsem se v rámci práce věnoval, je problematika topologické správy 3D vektorových dat v GIS (kap. 4.3). Na základě analýzy existujících 3D datových modelů jsem se snažil navrhnout 3D topologický model pro vektorovou architekturu systému GRASS. V rámci této činnosti jsem implementoval několik nástrojů systému GRASS, které jsou zaměřeny na tvorbu a další zpracování 3D vektorových dat. 147

162 148 ZÁVĚR Vedlejšími aplikační výstupy disertační práce, které s hlavním tématem souvisí nepřímo, bych označil konsolidaci správy metadat ve vektorové knihovně systému GRASS (kap. 4.4) a spolupráci na vývoji nové generace grafického uživatelského rozhraní (GUI) pro GRASS GIS (kap. 4.5). Kromě návrhu a implementace základních komponent GUI jsem se věnoval vývoji nástrojů, které hlavní aplikační výstupy práce integrují v prostředí navrženého grafického uživatelského rozhraní. Implementoval jsem nový digitalizační nástroj a započal vývoj nadstavby pro vizualizaci 3D geodat. Výčet mé činnosti uzavírá realizace podpory výměnného formátu Informačního systému katastru nemovitostí (ISKN) v open source knihovně OGR (kap. 4.6). Kromě toho jsem se okrajově věnoval i problematice topologické správy prvků digitální katastrální mapy v geodatabázi PostGIS. Systém GRASS disponuje velkým množstvím nástrojů pro analýzu geodat reprezentovaných jako 2D a 3D rastrová či vektorová data. V současnosti je mimo jiné kladen důraz skupinou vývojářů systému GRASS na vývoj časoprostorových nástrojů, tedy na implementaci topologicky orientovaného 4D GIS. V tomto ohledu se mi jevila řešená problematika topologické správy 3D vektorových dat jako nanejvýš aktuální. Výsledky prezentované v rámci disertační práce dokreslují moji snahu o posun projektu GRASS směrem k vektorovému GIS třetí generace (obr. 3.1). Jádrem je plnohodnotná integrace open source objektově-relační geodatabáze PostGIS v systému GRASS. Nová generace systému GRASS označovaná jako verze 7, s ohledem na praktický výstup této disertační práce, by podle mého názoru měla přinést větší míru interoperability vektorové architektury, s důrazem na topologickou správu vektorových dat právě v geodatabázi PostGIS. Integrace podpory výměnného formátu ISKN v knihovně OGR představovala mimo jiné impuls pro vývoj specializovaného zásuvného modulu pro populární desktopovou aplikaci QGIS. Tento zásuvný modul byl vyvinut studenty oboru Geoinformatika na ČVUT v Praze (viz kap ). V současnosti je tato aplikace testována na GIS oddělení Městského úřadu Nový Jičín. Integrace podpory výměnného formátu ISKN v mezinárodním open source projektu GDAL/OGR a vývoj specializovaného nástroje pro QGIS může mít podle mého názoru do jisté míry praktické využití na GIS pracovištích veřejné správy jako jsou městské a obecní úřady. Vlastní přínos Přínos disertační práce vidím především v realizaci navrhovaných postupů v mezinárodních open source projektech, přičemž jsem se snažil klást důraz na jejich funkčnost a použitelnost v praxi.

163 ZÁVĚR 149 Přínos práce bych shrnul ve třech hlavních bodech. 1. Integrace datového modelu jednoduchých geoprvků dle specifikace OGC Simple Features Access a topologického modelu Topo-Geo technické normy ISO SQL/MM ve vektorové architektuře systému GRASS s cílem zvýšení její interoperability. Tento bod zahrnuje: rozšíření rozhraní OGR vektorové knihovny systému GRASS o podporu pro režim přímého přístupu a zápisu nejrůznějších vektorových GIS formátů, návrh a implementaci nativní podpory geodatabáze PostGIS ve vektorové architektuře systému GRASS v režimu přístupu jednoduchých geoprvků, rozšíření podpory PostGIS v systému GRASS o topologickou správu vektorových dat integrací projektu PostGIS Topology, implementaci podpůrných nástrojů systému GRASS pro práci s vektorovými daty uloženými v geodatabázi PostGIS, integraci knihovny GEOS s výsledkem rozšíření prostorových vztahů definovaných na základě specifikace OGC Simple Features Access, návrh a realizaci rozhraní pro programování aplikací (API) vektorové knihovny systému GRASS pro režim přístupu jednoduchých geoprvků. 2. Návrh vektorové architektury systému GRASS s cílem implementace 3D topologického GIS. Konkrétně se jedná o: analýzu problematiky topologické správy vektorových dat v systému GRASS a datových modelů pro 3D vektorová data, návrh 3D topologického modelu a souvisejících datových struktur ve vektorové architektuře systému GRASS, implementaci nástrojů systému GRASS pro tvorbu 3D vektorových dat. 3. Vedlejší činnosti, které navazují na hlavní téma 3D topologického GIS s podporou geodatabáze PostGIS: návrh a realizaci nové generace grafického uživatelského rozhraní pro systém GRASS včetně komponent jako je digitalizační nástroj či prostředí pro vizualizaci geodat ve 3D, analýzu správy metadat v systému GRASS a návrh její konsolidace včetně podpory technické normy ISO 19115, návrh a implementaci podpory výměnného formátu ISKN v knihovně OGR včetně analýzy topologické správy prvků digitální katastrální mapy v geodatabázi PostGIS.

164 150 ZÁVĚR V minulých letech jsem se snažil o zapojení studentů oboru Geoinformatika na ČVUT v Praze do aktivní spolupráce na vývoji free softwaru. Jako příklad bych rád zmínil projekt Zásuvného modulu QGIS pro práci s katastrálními daty [C1]. Kromě toho se pod mým vedením v letech 2011 a 2012 zúčastnili dva studenti tohoto oboru prestižního mezinárodního programu Google Summer of Code, zaměřeného na podporu mladých programátorů v oblasti open source vývoje. Oba projekty byly věnovány systému GRASS GIS [C2, C3]. Na závěr bych rád uvedl vybrané bakalářské a diplomové práce, které jsem vedl a jsou v přímé souvislosti s nasazením free software GIS nástrojů v rámci výuky na studijním programu Geodézie a kartografie ČVUT v Praze [C4, C5, C6, C7]. Dílčí výsledky disertační práce jsem průběžně prezentoval na lokálních a mezinárodních konferencích (Geoinformatics FCE CTU, GIS Ostrava, FOSS4G, OGRS) s cílem popularizace free software GIS a prezentace využití těchto nástrojů při výuce na ČVUT v Praze. Pokračování disertační práce Vývoji free software GIS nástrojů, a to především systému GRASS, se věnuji dlouhodobě. Jako člen mezinárodního vývojového týmu projektu GRASS GIS působím již od roku Portfolio free software projektů, na kterých se aktivně podílím, se v posledních letech rozšířilo o knihovnu GDAL/OGR a desktopový nástroj QGIS. V následujících měsících se hodlám věnovat přípravě vydání nové generace GRASS verze 7, které je plánováno na přelom roku 2013 a V tomto ohledu se hodlám zaměřit na testování integrace geodatabáze PostGIS v systému GRASS, dokončení realizace správy metadat založené na mezinárodní technické normě ISO a implementaci vybraných algoritmů, s cílem komplexní topologické správy 3D vektorových dat v systému GRASS.

165 Seznam literatury Primární zdroje (A) [A1] [A2] A. Čepek. Nové technologie: kulturní šok (nejen) pro zeměměřiče. In: Pražská technika Vol. 3/2010 (2010), pp issn: M. Neteler et al. GRASS GIS: A multi-purpose open source GIS. In: Environmental Modelling & Software Vol. 31 (2012). Elsevier. [vid ] Dostupné z: pp issn: [A3] R. Stallman and J. Gay. Free software, free society: selected essays of Richard M. Stallman. Free Software Foundation, isbn: [A4] J. Westervelt. GRASS Roots. In: FOSS/GRASS User Conference, Bangkok, Thajsko. [vid ] Dostupné z: viewpaper.php?id= [A5] J. Westervelt. Early GRASS Community Views on FOSS. In: FOSS4G Free And Open Source Software for Geoinformatics, Lausanne, Švýcarsko. [vid ] Dostupné z: html?contribid=214&sessionid=54&confid= [A6] [A7] [A8] [A9] [A10] M. Neteler and H. Mitasova. Open Source GIS: A GRASS GIS Approach. Springer, isbn: E.S. Raymond. The Art of Unix Programming. Addison-Wesley Professional Computing Series. Addison-Wesley, isbn: J. Čepický and M. Landa. GRASS GIS Digitalization tools. In: Italian GRASS and GFOSS Users Meeting. [vid ] Dostupné z: cz/~landa/publications/2007/italian-gfoss-07/grass-digit.pdf D.J. Peuquet and D.F. Marble. Introductory Readings In Geographic Information Systems. Taylor & Francis, isbn: J. Tuček. GIS - Geografické informační systémy: principy a praxe. CAD & GIS. Computer Press, isbn:

166 152 SEZNAM LITERATURY [A11] J.G. Liu and P. Mason. Essential Image Processing and GIS for Remote Sensing. John Wiley & Sons, isbn: [A12] M.N. DeMers. GIS For Dummies. John Wiley & Sons, isbn: [A13] [A14] [A15] [A16] [A17] J. Šíma. Příspěvek ke zlepšení užívání odborné terminologie v oboru geoinformatiky. In: GEOinformace 10.9 (2002), pp issn: E. F. Codd. A Relational Model of Data for Large Shared Data Banks. In: Commun. ACM 13.6 (1970), pp Mezinárodní organizace pro normalizaci. ISO Information technology Database languages SQL multimedia and application packages Part 3: Spatial R. Obe and L. Hsu. PostGIS in Action. Manning Pubs Co Series. Manning Publications, isbn: P. O Neil and E. O Neil. Database principles, Programming, and Performance. The Morgan Kaufmann Series in Data Management Systems. Morgan Kaufmann Publishers, isbn: [A18] G. Graefe. Modern B-Tree Techniques. Now Publishers, isbn: [A19] [A20] [A21] [A22] [A23] [A24] Y. Manolopoulos, A.N. Papadopoulos, and M.G. Vassilakopoulos. Spatial Databases: Technologies, Techniques and Trends. ITPro collection. Idea Group Pub., isbn: K. Douglas and S. Douglas. PostgreSQL: A Comprehensive Guide to Building, Programming, and Administering PostgreSQL Databases. Developer s Library. Sams, isbn: Morakot Pilouk and A Abdul-Rahman. Spatial data modelling for 3D GIS. springer Berlin Heidelberg, Berlin, Morakot Pilouk. Integrated modelling for 3D GIS. Landbouwuniversiteit te Wageningen, Lixin Wu. Topological relations embodied in a generalized tri-prism (GTP) model for a 3D geoscience modeling system. In: Computers & Geosciences 30.4 (2004), pp Mark Anthony Armstrong. Basic topology. Undergraduate texts in mathematics. In: Springer-Verlag 1 (1983), p [A25] Jiří Demel. Grafy a jejich aplikace. Academia, [A26] Morakot Pilouk, Klaus Tempfli, and Martien Molenaar. A tetrahedron-based 3D vector data model for geo-information. In: (1994). [A27] Martien Molenaar. A topology for 3 D vector maps. In: ITc Journal 1 (1992), pp

167 SEZNAM LITERATURY 153 [A28] [A29] [A30] [A31] [A32] [A33] [A34] [A35] [A36] Ir F Penninga. Constrained tetrahedral models and update algorithms for topographic data. In: Geo-information and computational geometry (), p. 35. Siyka Zlatanova. 3D GIS for urban development. International Inst. for Aerospace Survey and Earth Sciences (ITC), Volker Coors. 3D-GIS in networking environments. In: Computers, Environment and Urban Systems 27.4 (2003), pp Rongxing Li. Data structures and application issues in 3-D geographic information systems. In: Geomatica 48.3 (1994), pp Gerhard Gröger and Lutz Plümer. Exploiting 2D concepts to achieve consistency in 3D GIS applications. In: Proceedings of the 11th ACM international symposium on Advances in geographic information systems. ACM. 2003, pp Alias Abdul-Rahman. The design and implementation of a two and three-dimensional triangular irregular network based GIS. PhD thesis. University of Glasgow, Pfund M. Topologic data structure for a 3D GIS. In: Proceedings of International Society for Photogrammetry and Remote Sensing Journal 34 (2001), pp Arnaud De la Losa and Bernard Cervelle. 3D Topological modeling and visualisation for 3D GIS. In: Computers & Graphics 23.4 (1999), pp E. Fogel, D. Halperin, and R. Wein. CGAL Arrangements and Their Applications: A Step-by-Step Guide. Geometry and computing. Springer Berlin Heidelberg, isbn: url: [A37] J. Růžička. Metadata v procesu realizace GIS projektu. In: GIS Ostrava ISSN: [A38] [A39] I.T.L.E.S. Limited. Introduction To Information Technology. Pearson Education, isbn: J. Ružička. Metadata pro prostorová data. PhD thesis. Institut geoinformatiky, VŠB - Technická univerzita Ostrava, [A40] H. Aalders. Data searching by metadata. In: GIS Ostrava ISSN: [A41] [A42] [A43] H. Moellering, H. Aalders, and A. Crane. World spatial metadata standards. ISBN Elsevier Ltd., W. Kresse and K. Fadaie. ISO Standards for Geographic Information. Springer, isbn: Mezinárodní organizace pro normalizaci. ISO Geographic Information Metadata

168 154 SEZNAM LITERATURY [A44] J. Arlow and I. Neustadt. UML a unifikovaný proces vývoje aplikací. ISBN X. Addison-Wesley, český překlad Computer Press, [A45] E. R. Harold and W.S. Means. XML in a Nutshell. ISBN O Reilly Media, Inc., [A46] R. Chromý. Využití webových služeb v katastru nemovitostí. [vid ] Dostupné z: chromy- dis pdf. PhD thesis. Fakulta stavební ČVUT v Praze, [A47] [A48] [A49] [A50] M. Landa. Návrh modulu GRASSu pro import dat ve výměnném formátu ISKN. [vid ] Dostupné z: MA thesis. Fakulta stavební ČVUT v Praze, R. Blažek, M. Neteler, and R. Micarelli. The new GRASS 5.1 vector architecture. In: Open source GIS - GRASS users conference 2002, Trento, Italy. [vid ] Dostupné z: proceedings/proceedings/pdfs/blazek_radim.pdf P. Rigaux, M.O. Scholl, and A. Voisard. Spatial Databases: With Application to GIS. The Morgan Kaufmann Series in Data Management Systems. Morgan Kaufmann Publishers, isbn: Martin Landa. GRASS GIS 7.0: Interoperability improvements. English. In: GIS Ostrava isbn: url: ~landa/publications/2013/gis- ostrava-2013/paper/landa_grass7_paper. pdf. [A51] A Čepek. Informatika, Úvod do C++, 1. vyd. Praha: Nakladatel stvo ČVUT, s. Tech. rep. ISBN [A52] [A53] [A54] J. Ježek K. Jedlička and J. Petrák. Otevřený katastr svobodné internetové řešení pro prohlížení dat výměnného formátu katastru nemovitostí. In: Geoinformatics FCE CTU Vol. 2 (2007). [vid ] Dostupné z: data/ geoinformatics/ 2007/ 09/ 19/ geoinformatics- fce- ctu pdf. issn: M. Landa. OGR VFK Driver Implementation Issues. In: Symposium GIS Ostrava [vid ] Dostupné z: http : / / geo. fsv. cvut. cz / ~landa / publications/2010/gis-ostrava-2010/paper/landa-ogr-vfk.pdf G.E. Sherman. Desktop GIS: Mapping the Planet with Open Source Tools. Pragmatic Bookshelf Series. Pragmatic Bookshelf, isbn:

169 SEZNAM LITERATURY 155 Online zdroje (B) [B1] Free Software Foundation. GNU General Public License, version 2. [vid ] Dostupné z: [B2] GRASS Development Team. GRASS Logograms. [vid ] Dostupné z: [B3] Archives of scanned GRASSCLIPPINGS issues. [vid ] Dostupné z: [B4] GRASS Development Team. GRASS GIS 7 Reference Manual. [vid ] Dostupné z: [B5] Rapant P. Návrh terminologického slovníku CAGI. [vid ] Dostupné z: [B6] [B7] [B8] [B9] [B10] [B11] [B12] Open Geospatial Consortium. OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture. [vid ] Dostupné z: GDAL/OGR Development Team. Seznam formátů podporovaných knihovnou OGR. [vid ] Dostupné z: GDAL Development Team. GDAL Logograms. [vid ] Dostupné z: http: //svn.osgeo.org/gdal/trunk/gdal/data/gdallogocolor.svg. GDAL/OGR Development Team. Seznam projektů, které používají knihovnu GDAL/- OGR. [vid ] Dostupné z: http : / / trac. osgeo. org / gdal / wiki / SoftwareUsingGdal. Open Geospatial Consortium. Simple Features Implementation Specification for OLE/- COM. [vid ] Dostupné z: sfo. GDAL/OGR Development Team. Rozhraní pro programování aplikací API knihovny OGR. [vid ] Dostupné z: Open Geospatial Consortium. Coordinate Transformation Service Implementation Specification. [vid ] Dostupné z: standards/sfo. [B13] PostGIS Development Team. PostGIS Logograms. [vid ] Dostupné z: [B14] A. Čepek and M. Landa. Přednášky předmětu Úvod do zpracování prostorových dat. [vid ] Dostupné z: [B15] PostGIS Development Team. PostGIS Topology. [vid ] Dostupné z:

170 156 SEZNAM LITERATURY [B16] Mezinárodní organizace pro normalizaci. ISO SQL/MM Part 3: Spatial Change Proposal Topo-Geo and Topo-Net 1: The Concept. [vid ] Dostupné z: 168r2- Topo- Geo- and- Topo- Net- 1- The- Concepts.pdf. [B17] CGAL Development Team. CGAL Logograms. [vid ] Dostupné z: [B18] CGAL Development Team. The CGAL License. [vid ] Dostupné z: [B19] [B20] [B21] [B22] M. Landa. Závěrečná zpráva řešení interního grantu ČVUT CTU [vid ] Dostupné z: /igs/landa-metadata-grass.pdf. D. Hart and H. Phillips. Metadata Primer A "How To" Guide on Metadata Implementation. [vid ] Dostupné z: metaprim.htm. Český úřad zeměměřičký a katastrální. Struktura výměnného formátu informačního systému katastru nemovitostí České republiky. [vid ] Dostupné z: VF_ISKNTEXT. M. Landa and GRASS Development Team. Manuálová stránka modulu v.external.out. [vid ] Dostupné z: external.out.html. [B23] GRASS Development Team. Specifikace GRASS ASCII vektorového formátu. [vid ] Dostupné z: html. [B24] [B25] [B26] [B27] M. Landa and GRASS Development Team. Integrace knihovny GEOS ve vektorové knihovně GRASS verze 7. [vid ] Dostupné z: programming7/vectorlib.html#vlibgeosfn. M. Landa and GRASS Development Team. Manuálová stránka modulu v.out.postgis. [vid ] Dostupné z: postgis.html. M. Landa and GRASS Development Team. Manuálová stránka modulu v.to.3d. [vid ] Dostupné z: http : / / grass. osgeo. org / grass70 / manuals / v.to.3d.html. M. Landa and GRASS Development Team. Manuálová stránka modulu v.drape. [vid ] Dostupné z: http : / / grass. osgeo. org / grass70 / manuals / v.drape.html.

171 SEZNAM LITERATURY 157 [B28] [B29] M. Landa and GRASS Development Team. Manuálová stránka modulu v.extrude. [vid ] Dostupné z: extrude.html. M. Landa and GRASS Development Team. Manuálová stránka modulu m.nviz.image. [vid ] Dostupné z: nviz.image.html. [B30] M. Landa. Závěrečná zpráva projektu GFOSS-TN (2007/2008). [vid ] Dostupné z: [B31] M. Landa and GRASS Development Team. Knihovna GRASS Vedit. [vid ] Dostupné z: [B32] Python Foundation. Ctypes A foreign function library for Python. [vid ] Dostupné z: [B33] M. Landa and GRASS Development Team. Manuálová stránka wxgui grafického modeleru. [vid ] Dostupné z: http : / / grass. osgeo. org / grass70 / manuals/wxgui.modeler.html. [B34] M. Landa. Knihovna OGR: VFK driver. [vid ] Dostupné z: [B35] QGIS Development Team. QGIS Logograms. [vid ] Dostupné z: [B36] Sylvain Pion and Monique Teillaud. 3D Triangulations. [vid ] Dostupné z:

172 158 SEZNAM LITERATURY Studentské práce (C) [C1] A. Kratochvílová a V. Petráš. Quantum GIS plugin for Czech cadastral data. In: Geoinformatics FCE CTU Vol. 8 (2012). issn: [C2] A. Kratochvílová. WxNviz GSoC [vid ] Dostupné z: [C3] [C4] [C5] [C6] [C7] Štěpán Turek. WxVNet GSoC [vid ] Dostupné z: osgeo.org/wiki/grass_gsoc_2012_wxgui_front_end_for_vector_analysis_ modules. A. Kratochvílová. Grafické uživatelské rozhraní pro tvorbu mapových výstupů v systému GRASS. [vid ] Dostupné z: bp/2011/anna-kratochvilova-bp-2011.pdf. MA thesis. Fakulta stavební ČVUT v Praze, Štěpán Turek. Implementace podpory WMS do programů GRASS GIS a SGA GIS. [vid ] Dostupné z: stepan-turek-bp-2012.pdf. MA thesis. Fakulta stavební ČVUT v Praze, Zdeněk Růžička. Workflow Builder pro Quantum GIS. [vid ] Dostupné z: ruzicka- dp pdf. MA thesis. Fakulta stavební ČVUT v Praze, Tereza Fiedlerová. Zásuvný modul QGIS pro slučování vektorových dat. [vid ] Dostupné z: MA thesis. Fakulta stavební ČVUT v Praze, 2013.

173 Seznam zkratek ANSI API ASCII B-rep CAC CAD CAGI CDGM CGAL CEN CLI COM CSG CVS ČSN ČÚZK ČVUT DBMI DCEL DE-9IM American National Standards Institute Application Programming Interface American Standard Code for Information Interchange Boundary Representation Computer Aided Cartography Computer Aided Design České asociace pro geoinformace Content Standard for Digital Geospatial Metadata Computational Geometry Algorithms Library European Committee for Standardisation Command Line Interface Component Object Model Constructive Solid Geometry Concurrent Version System Česká technická norma Český úřad zeměměřický a katastrální České vysoké učení technické DataBase Management Interface Double Connected Edge List Rozšířený rozměrový 9-ti průsečíkový model 159

174 160 SEZNAM ZKRATEK DIME DMT ENv EPSG Esri FDS FGDC FOSS FRVŠ GBF GDAL GEOS GIS GiST GNU GPL GRASS GUI GXM GXW IEEE IS ISKN ISO JTS KN Dual Independent Map Encoding Digitální model terénu European Pre-standards European Petroleum Survey Group Environmental Systems Research Institute Formal Data Structure Federal Geographic Data Committee Free and Open Source Software Fond rozvoje vysokých škol Geographic Base Files Geospatial Data Abstraction Library Geometry Engine Open Source Geografický informační systém Generalized Search Tree Gnu s Not Unix General Public License (všeobecná veřejná licence) Geographic Resources Analysis Support System Grafické uživatelské rozhraní GRASS Model File GRASS Workspace File Institute for Electrical and Electronic Enginners Informační systém Informační systém katastru nemovitostí International Standard Organisation Java Topology Suite Katastr nemovitostí

175 SEZNAM ZKRATEK 161 LGPL LIDAR LOM NAA OGC OGF OGR OLE OS OSGeo QGIS POET PPM SFA S-JTSK SOMAS SSM SQL SQL/MM SŘBD SVN SWIG TC TCL TEN Lesser General Public License Light Detection And Ranging (laserové skenování) Learning Object Metadata Node-Arc-Area Open Geospatial Consorcium Open GRASS Foundation OpenGIS Simple Features Reference Implementation Object Linking and Embedding Operační systém Open Source Geospatial Foundation Quantum GIS Persistent Objects and Extended Database Technology Portable Pixmap Format Simple Features Access Souřadnicový systém jednotné trigonometrické sítě katastrální Solid Object Mananagement System Simplified Spatial Model Structured Query Language Information technology Database languages SQL multimedia and application packages Systém řízení báze dat Subversion Simplified Wrapper and Interface Generator Technical Committee Tool Command Language TEtrahedral Network

176 162 SEZNAM ZKRATEK TIF TIGER TIN UDM UI UML Tagged Image File Format Topologically Integrated Geographic Encoding and Referencing Triangulated Irregular Network Urban Data Model Uživatelské rozhraní Unified Modeling Language USA-CERL United States Army Construction Engineering Research Laboratories VF W3C WKB WKT WWW XML Výměnný formát World Wide Web Consortium Well Known Binary Well Known Text World Wide Web Extensible Markup Language

177 Seznam obrázků 1.1 Logo projektu GRASS GIS Časopis GRASSCLIPPINGS Programátor systému GRASS Dave Gerdes (USA-CERL) Časová osa vývoje systému GRASS GIS ( ) Úvodní obrazovka grafického uživatelského rozhraní wxgui Vztah vektorové vrstvy a atributové tabulky v systému GRASS GIS Manager ve verzi GRASS Digitalizační modul ve verzi GRASS Digitalizační modul ve verzi GRASS Příklad vektorového modelu v GIS Příklad špagetového modelu Příklad vektorového modelu Dual Independent Map Encoding Příklad vektorového modelu Arc-Node-Area Topologický model vektorové architektury systému GRASS Příklad reprezentace geoprvků ve vektorovém modelu systému GRASS Datový model specifikace OGC Simple Features Access Příklad kompozice jednoduchých geoprvků Logo projektu GDAL/OGR Datový model knihovny OGR Diagram C++ tříd objektového modelu knihovny OGR Logo projektu PostGIS Architektura server-klient geodatabáze PostGIS PostGIS Simple Features Access: Příklad sousedících polygonů Příklad topologické reprezentace polygonů v PostGIS Topology Příklad modelování reálných objektů v GIS

178 164 SEZNAM OBRÁZKŮ 1.26 Příklad modelování reálných objektů v topologickém modelu Topo-Geo Ukázka n-rozměrných simplexů Sousednost n-rozměrných simplexů Zobecněný n-rozměrný simplex datový model Příklad úplných a bipartitních grafů Podgrafy v rámci datového modelu TEN Ukázka n-rozměrných complex objektů Datový model 3D Formal Data Structure (FDS) Datový model TEN ve formě relačních datových struktur Porovnání datového modelu TEN a TIN UML diagram datového modelu TEN Datový model Simplified Spatial Model Datový model Constructive Solid Geometry Datový model Boundary Representation Datový model 2,8D Logo projektu CGAL Interpretace dat Typy elementů metadat Schéma komunitního profilu ISO Topologický model GRASS verze Topologický model GRASS verze Sestavení pseudo-topologie pro jednoduché geoprvky Sestavení pseudo-topologie pro plochy Sestavení pseudo-topologie pro ostrovy Nepravidelná 2,5D trojúhelníková síť Tři generace GIS Architektura systému GRASS GUI dialog modulu v.external GUI dialog modulu v.external.out Rozhraní PostGIS a OGR vektorové knihovny GRASS Příklad grafického výstupu dat uložených v geodatabázi PostGIS Relační diagram rozšířeného topologického schématu PostGIS Topology

179 SEZNAM OBRÁZKŮ Příklad topologického modelu GRASS verze Editace vektorových dat PostGIS v digitalizačním nástroji wxgui D/3D topologický model vektorové architektury systému GRASS Orientace stěny ve 3D topologickém modelu GRASS Příklad otvoru a dutiny v tělese Reprezentace tělesa s dutinou v 3D topologickém modelu GRASS Simplex 3D topologický model vektorové architektury systému GRASS Příklad geometrické reprezentace budovy jako mnohostěnu Příklad rozložení mnohostěnu na množinu čtyřstěnů Příklad 2D vektorových dat Příklad použití modulu v.to.3d Příklad použití modulu v.drape Příklad použití modulu v.extrude Příklad použití modulu v.delaunay3d Základní komponenty wxgui Digitalizační modul wxgui ve verzi GRASS wxgui rozšíření pro vizualizaci dat ve 3D wxgui grafický modeler Datové bloky VFK související s geometrií prvků katastrální mapy Logo projektu QGIS Zásuvný modul QGIS pro práci s katastrálními daty Vizualizace parcel digitální katastrální mapy A.1 Simple Features Access: Třída Geometry A.2 Simple Features Access: Třída GeometryCollection A.3 Simple Features Access: Třída Point A.4 Simple Features Access: Třída Curve a LineString A.5 Simple Features Access: Příklad objektu typu LineString A.6 Simple Features Access: Třída MultiCurve a MultiLineString A.7 Simple Features Access: Příklad objektu typu MultiLineString A.8 Simple Features Access: Třída Surface A.9 Simple Features Access: Třída Polygon A.10 Simple Features Access: Příklad objektu typu PolyhedralSurface A.11 Simple Features Access: Třída PolyhedralSurface

180 166 SEZNAM OBRÁZKŮ C.1 Příklad rozložení mnohostěnu na čtyřstěny (aplikace knihovny CGAL) D.1 UML diagram C++ tříd ovladače OGR-VFK

181 Seznam tabulek 1.1 Přehled skupin modulů systému GRASS Vztah mezi objektovým modelem UML a daty ISO Datové typy výměnného formátu ISKN Struktura nativního vektorového formátu GRASS verze 4 a Elementy datového modelu vektorové knihovny GRASS verze 5 a Struktura nativního vektorového formátu GRASS verze Topologický model GRASS verze 6: tabulka uzlů Topologický model GRASS verze 6: tabulka topologických elementů Topologický model GRASS verze 6: tabulka ploch Topologický model GRASS verze 6: tabulka ostrovů Popis hlavičkového souboru vektorových dat v nativním formátu GRASS Porovnání topologických modelů GRASS a Topo-Geo Přehled dodatečných tabulek datového modelu GRASS Vyjádření budovy jako mnohostěnu a množiny simplexů Načítání dat výměnného formátu ISKN knihovnou OGR D.1 Hlavička výměnného formátu ISKN

182 168 SEZNAM TABULEK

183 Příloha A: Specifikace OGC Simple Features Access A.1 Přehled typů jednoduchých geoprvků Třída Geometry Třída Geometry určuje základní vlastnosti geometrických objektů definovaných v rámci specifikace OGC Simple Features Access. Obrázek A.1: Simple Features Access: Třída Geometry (zdroj: [B6]). 169

184 170 PŘÍLOHA A: SPECIFIKACE OGC SIMPLE FEATURES ACCESS Třída GeometryCollection Reprezentuje komplexní objekt (obr. A.2), který je tvořen množinou geometrických objektů. Tyto geometrické objekty musí být vztaženy vůči jednomu referenčnímu souřadnicovému systému. Odvozené třídy, jako např. MultiPoint či MultiLineString, zavádějí další podmínky jako je dimenze či typ geometrických objektů v množině. Třída definuje dvě metody: NumGeometries() (počet geometrických objektů v množině) a GeometryN() (vrací n-tý geometrický objekt množiny). Obrázek A.2: Simple Features Access: Třída GeometryCollection (zdroj: [B6]). Třída Point Jde o bezrozměrný geometrický objekt reprezentovaný jedinečnou polohou v souřadnicovém systému (obr. A.3). Poloha bodu je definována souřadnicemi x a y, volitelně z či m. Třída definuje metody pro získání hodnot souřadnic X(), Y(), Z() a M(). Obrázek A.3: Simple Features Access: Třída Point (zdroj: [B6]). Třída MultiPoint Je odvozena od třídy GeometryCollection s tím, že množina geometrickým objektů je omezena pouze na body (třída Point). Prvky množiny nejsou nijak řazeny. Objekt typu MultiPoint označujeme jako jednoduchý, pokud neobsahuje dva identické body. Třída Curve Jde o jednorozměrný geometrický objekt definovaný sekvencí (lomových) bodů a metodou interpolace mezi těmito body. Specifikace SFA definuje odvozenou třídu LineString (obr. A.4), která je charakterizována lineární interpolací mezi lomovými body. D = [a, b] = {t R a t b} f : [a, b] R n (A.1)

185 PŘÍLOHA A: SPECIFIKACE OGC SIMPLE FEATURES ACCESS 171 Křivka může být označena jako jednoduchá v případě, že neprochází vícekrát jedním bodem s výjimkou koncovým bodů křivky. c Curve, [a, b] = c.domain, c =: f : [a, b] R n c.issimple x 1, x 2 [a, b] : [f(x 1 ) = f(x 2 ) x 1 < x 2 ] [x 1 = a x 2 = b] (A.2) Křivka je uzavřená jestliže platí, že počáteční a koncový bod je totožný. c.isclosed [f(a) = f(b)] (A.3) Křivka, která je jednoduchá a uzavřená, se označuje jako ring. Třída Curve definuje následující metody: StartPoint() (počáteční bod křivky), EndPoint() (koncový bod křivky), Length() (délka křivky), IsClosed() (vrací hodnotu jedna, pokud je křivka uzavřená) a IsRing() (vrací hodnotu jedna, pokud je křivka jednoduchá a uzavřená). Obrázek A.4: Simple Features Access: Třída Curve a LineString (zdroj: [B6]). Třída LineString, Line, LinearRing Třída LineString. Jde o křivku s lineární interpolací mezi lomovými body (obr. A.5). Dvojice lomových bodů definuje liniový segment. Třída LineString definuje metody: NumPoints () (počet vrcholů) a PointN() (vrací daný vrchol jako bod). Obrázek A.5: Simple Features Access: Příklad objektu LineString (1) jednoduchý (2) komplexní (3) jednoduchý a uzavřený (LinearRing) (4) komplexní a uzavřený (zdroj: [B6]).

186 172 PŘÍLOHA A: SPECIFIKACE OGC SIMPLE FEATURES ACCESS Třída Line. Jde o LineString s dvěma vrcholovými body. Třída LinearRing. Jde o LineString, který je současně uzavřený a jednoduchý. Třída MultiCurve Je množina jednorozměrných geometrických objektů odvozená z GeometryCollection. Obsahuje pouze objekty, které jsou typu Curve. Třída MultiCurve (obr. A.6) je definována jako abstraktní a určuje tak sadu metod pro odvozené třídy. Objekt typu MultiCurve označujeme jako jednoduchý v případě, že všechny prvky obsažené v množině jsou jednoduché a dochází k jejich křížení pouze na hranici objektu (tj. na koncových vrcholech křivek). V případě, že všechny prvky množiny jsou uzavřené, označujeme MultiCurve jako celek za uzavřený. Třída zavádí metody IsClosed() (vrací hodnotu jedna v případě, že objekt je uzavřený) a Length (součet délek všech křivek obsažených v množině). Obrázek A.6: Simple Features Access: Třída MultiCurve a MultiLineString (zdroj: [B6]). Třída MultiLineString Je odvozena od třídy MultiCurve, prvky množiny jsou omezeny na typ LineString. Obrázek A.7: Simple Features Access: Příklad objektu MultiLineString (1) jednoduchý (2) komplexní, dva elementy (3) komplexní, uzavřený s dvěma elementy (zdroj: [B6]). Třída Surface Třída Surface. Je definován jako dvourozměrný objekt. Třída Surface (obr. A.8) definuje následující metody: Area() (plocha povrchu), Centroid() (vrací centroid, nemusí nutně ležet na povrchu) a PointOnSurface() (vrací bod lokalizovaný na povrchu).

187 PŘÍLOHA A: SPECIFIKACE OGC SIMPLE FEATURES ACCESS 173 Obrázek A.8: Simple Features Access: Třída Surface (zdroj: [B6]). Třída Polygon Třída Polygon, Triangle. Polygon je definován jako rovinný povrch (Surface) s jednou vnější a libovolným počtem vnitřních hranic (obr. A.9). Každá vnitřní hranice definuje díru v polygonu. Triangle (trojúhelník) je polygon s třemi vrcholy, které neleží na jedné přímce. Trojúhelník nemůže ze své definice obsahovat žádnou vnitřní hranici (tj. díru). Vnější hranice polygonu je tvořena objektem typu LinearRing. Směr vnější hranice je vždy proti směru hodinových ručiček, naopak vnitřní hranice je definována ve směru opačném. Třída Polygon zavádí následující metody: ExteriorRing() (vrací vnější hranici polygonu), NumInteriorRing() (počet vnitřních hranic) a InteriorRingN() (vrací n-tou vnitřní hranici polygonu). Obrázek A.9: Simple Features Access: Třída Polygon (zdroj: [B6]). Třída PolyhedralSurface Jde o objekt, který je tvořen množinou polygonů, které sdílí svoje (vnější) hranice (obr. A.8). V tomto ohledu je nepravidná trojúhelníková síť (TIN) objekt typu PolyhedralSurface, který je tvořen výhradně trojúhelníky. Polygony tvořící objekt PolyhedralSurface musí mít stejnou orientaci, tj. hranice sousedících polygonů musí mít opačnou orientaci. Pokud tato podmínka splněna není, lze tento objekt definovat jako MultiSurface. Na obr. A.10 je znázorněn PolyhedralSurface s konzistentní orientací.

188 174 PŘÍLOHA A: SPECIFIKACE OGC SIMPLE FEATURES ACCESS Obrázek A.10: Simple Features Access: Příklad objektu PolyhedralSurface s konsistentní orientací (zdroj: [B6]). PolyhedralSurface definuje následující metody: NumPaches() (počet polygonů tvořících povrch), PatchN() (vrací n-tý polygon), BoundingPolygons (vrací množinu polygonů tvořící hranici povrchu) a IsClosed (vrací hodnotu jedna, pokud je povrch uzavřený). Třída MultiSurface Jde o kolekci dvourozměrných geometrických objektů (GeometryCollection) typu Surface. Obrázek A.11: Simple Features Access: Třída PolyhedralSurface (zdroj: [B6]).

189 Příloha B: Topologie 2D vektorových dat v systému GRASS Přehled postupného sestavení topologických informací pro pět plošných vektorových elementů v systému GRASS GIS. Sestavované topologické informace pro nativní formát GRASS jsou uvedeny v levé části, pseudo-topologie pro OGR datové zdroje napravo. Obrázky byly vygenerovány pomocí příkazu d.vect a grafického ovladače systému GRASS využívajícího knihovnu Cairo. 1. node n_lines line type GV_BOUNDARY GV_BOUNDARY line type n1 n2 left right 1 GV_BOUNDARY node n_lines line type GV_LINE GV_LINE line type n1 n2 left right 1 GV_LINE

190 176 PŘÍLOHA B: TOPOLOGIE 2D VEKTOROVÝCH DAT V SYSTÉMU GRASS 2. node n_lines line type GV_BOUNDARY GV_BOUNDARY -1 GV_BOUNDARY GV_BOUNDARY line type n1 n2 left right 1 GV_BOUNDARY GV_BOUNDARY node n_lines line type GV_LINE GV_LINE -1 GV_LINE GV_LINE line type n1 n2 left right 1 GV_LINE GV_LINE

191 PŘÍLOHA B: TOPOLOGIE 2D VEKTOROVÝCH DAT V SYSTÉMU GRASS node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY -1 GV_BOUNDARY GV_BOUNDARY -3 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID 1 area n_lines line n_isles centroid 1 3 1,-2, isle n_lines line area 1 3-1,3,2 0 node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_CENTROID 1 area n_lines line n_isles centroid isle n_lines line area

192 178 PŘÍLOHA B: TOPOLOGIE 2D VEKTOROVÝCH DAT V SYSTÉMU GRASS 4. node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY -2 GV_BOUNDARY -1 GV_BOUNDARY GV_BOUNDARY -5 GV_BOUNDARY -3 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID 1 5 GV_BOUNDARY GV_CENTROID 2 area n_lines line n_isles centroid 1 3 1,5, , isle n_lines line area 1 3-1,3,2 0 node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY 3 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_CENTROID 1 3 GV_BOUNDARY GV_CENTROID 2 area n_lines line n_isles centroid isle n_lines line area

193 PŘÍLOHA B: TOPOLOGIE 2D VEKTOROVÝCH DAT V SYSTÉMU GRASS node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY -7 GV_BOUNDARY -1 GV_BOUNDARY GV_BOUNDARY -5 GV_BOUNDARY -3 GV_BOUNDARY GV_BOUNDARY -2 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID 1 5 GV_BOUNDARY GV_CENTROID 2 7 GV_BOUNDARY area n_lines line n_isles centroid 1 3 1,5, ,-5, isle n_lines line area 1 4-1,3,2,7 0 node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY 3 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_CENTROID 1 3 GV_BOUNDARY GV_CENTROID 2 area n_lines line n_isles centroid isle n_lines line area

194 180 PŘÍLOHA B: TOPOLOGIE 2D VEKTOROVÝCH DAT V SYSTÉMU GRASS 6. node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY -7 GV_BOUNDARY 8 GV_BOUNDARY -1 GV_BOUNDARY GV_BOUNDARY -5 GV_BOUNDARY -3 GV_BOUNDARY GV_BOUNDARY 7 GV_BOUNDARY -2 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID 1 5 GV_BOUNDARY GV_CENTROID 2 7 GV_BOUNDARY GV_BOUNDARY GV_CENTROID 3 area n_lines line n_isles centroid 1 3 1,5, ,-5, ,8 0 9 isle n_lines line area 1 4-1,3,2,-8 0 node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY -3 GV_BOUNDARY 5 GV_BOUNDARY 3 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_CENTROID 1 3 GV_BOUNDARY GV_CENTROID 2 5 GV_BOUNDARY GV_CENTROID 3 area n_lines line n_isles centroid isle n_lines line area

195 PŘÍLOHA B: TOPOLOGIE 2D VEKTOROVÝCH DAT V SYSTÉMU GRASS node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY -7 GV_BOUNDARY 8 GV_BOUNDARY -1 GV_BOUNDARY GV_BOUNDARY -5 GV_BOUNDARY -3 GV_BOUNDARY GV_BOUNDARY 7 GV_BOUNDARY -2 GV_BOUNDARY GV_BOUNDARY 10 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID 1 5 GV_BOUNDARY GV_CENTROID 2 7 GV_BOUNDARY GV_BOUNDARY GV_CENTROID 3 10 GV_BOUNDARY area n_lines line n_isles centroid 1 3 1,5, ,-5, ,8, isle n_lines line area 1 5-1,3,2,-10,-8 0 node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY -3 GV_BOUNDARY 5 GV_BOUNDARY 3 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_CENTROID 1 3 GV_BOUNDARY GV_CENTROID 2 5 GV_BOUNDARY GV_CENTROID 3 area n_lines line n_isles centroid isle n_lines line area

196 182 PŘÍLOHA B: TOPOLOGIE 2D VEKTOROVÝCH DAT V SYSTÉMU GRASS 8. node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY -7 GV_BOUNDARY 8 GV_BOUNDARY -1 GV_BOUNDARY GV_BOUNDARY 2 GV_BOUNDARY -5 GV_BOUNDARY -3 GV_BOUNDARY GV_BOUNDARY 7 GV_BOUNDARY -2 GV_BOUNDARY GV_BOUNDARY -8 GV_BOUNDARY 10 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID 1 5 GV_BOUNDARY GV_CENTROID 2 7 GV_BOUNDARY GV_BOUNDARY GV_CENTROID 4 10 GV_BOUNDARY GV_BOUNDARY GV_CENTROID 3 area n_lines line n_isles centroid 1 3 1,5, ,-5, ,-10, ,8, isle n_lines line area 1 4-1,3,11,-8 0 node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY -3 GV_BOUNDARY 7 GV_BOUNDARY 3 GV_BOUNDARY GV_BOUNDARY 5 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_CENTROID 1 3 GV_BOUNDARY GV_CENTROID 2 5 GV_BOUNDARY GV_CENTROID 3 7 GV_BOUNDARY GV_CENTROID 4 area n_lines line n_isles centroid isle n_lines line area

197 PŘÍLOHA B: TOPOLOGIE 2D VEKTOROVÝCH DAT V SYSTÉMU GRASS node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY -7 GV_BOUNDARY 8 GV_BOUNDARY -1 GV_BOUNDARY GV_BOUNDARY 2 GV_BOUNDARY -5 GV_BOUNDARY -3 GV_BOUNDARY GV_BOUNDARY 7 GV_BOUNDARY -2 GV_BOUNDARY GV_BOUNDARY -8 GV_BOUNDARY 10 GV_BOUNDARY GV_BOUNDARY -13 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID 1 5 GV_BOUNDARY GV_CENTROID 2 7 GV_BOUNDARY GV_BOUNDARY GV_CENTROID 4 10 GV_BOUNDARY GV_BOUNDARY GV_CENTROID 3 13 GV_BOUNDARY GV_CENTROID 5 area n_lines line n_isles centroid 1 3 1,5, ,-5, ,-10, ,8, isle n_lines line area 1 4-1,3,11, node n_lines line type GV_BOUNDARY 1 GV_BOUNDARY GV_BOUNDARY -3 GV_BOUNDARY 8 GV_BOUNDARY 3 GV_BOUNDARY GV_BOUNDARY 5 GV_BOUNDARY GV_BOUNDARY -10 GV_BOUNDARY 4-6 GV_BOUNDARY 10 GV_BOUNDARY line type n1/area n2 left right 1 GV_BOUNDARY GV_CENTROID 1 3 GV_BOUNDARY GV_CENTROID 2 5 GV_BOUNDARY GV_BOUNDARY GV_CENTROID 3 8 GV_BOUNDARY GV_CENTROID 5 10 GV_BOUNDARY GV_CENTROID 6 area n_lines line n_isles centroid isle n_lines line area