Vektorová architektura systému GRASS GIS

C

České vysoké učení technické v Praze Fakulta stavební

Vektorová architektura systému GRASS GIS DISERTAČNÍ PRÁCE

Praha, 2013

Ing. Martin Landa

České vysoké učení technické v Praze Fakulta stavební Katedra mapování a kartografie

C

Vektorová architektura systému GRASS GIS GRASS GIS Vector Architecture DISERTAČNÍ PRÁCE

Ing. 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

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 ..................

II

PROHLÁŠENÍ

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 Wertherovi1 a neblahému Judovi2 , 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 LATEX, 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 2

J. W. Goethe: Utrpení mladého Werthera (Die Leiden des jungen Werthers, 1774). T. Hardy: Neblahý Juda (Jude the Obscure, 1895).

IV

PODĚKOVÁNÍ

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.

VI

SUMMARY

Obsah Úvod

1

1 Úvod do problematiky 1.1

1.2

1.3

1.4

1.5

1.6

5

Geografický informační systém GRASS GIS . . . . . . . . . . . . . . . . . .

6

1.1.1

Historie projektu GRASS GIS . . . . . . . . . . . . . . . . . . . . . .

6

1.1.2

Základní terminologie systému GRASS . . . . . . . . . . . . . . . . .

8

1.1.3

Počátky grafického uživatelského rozhraní systému GRASS GIS . . .

12

Přehled vektorových datových modelů v GIS . . . . . . . . . . . . . . . . .

14

1.2.1

Špagetový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

1.2.2

Seznam lomových bodů . . . . . . . . . . . . . . . . . . . . . . . . .

16

1.2.3

Dual Independent Map Encoding . . . . . . . . . . . . . . . . . . . .

16

1.2.4

Node-Arc-Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

1.2.5

Datový model vektorové architektury systému GRASS GIS . . . . .

20

Specifikace OGC Simple Features Access . . . . . . . . . . . . . . . . . . . .

22

1.3.1

Datový model specifikace OGC Simple Features Access . . . . . . .

22

Knihovna OGR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

1.4.1

Knihovna OGR jako implementace specifikace OGC SFA . . . . . .

25

Geodatabáze PostGIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

1.5.1

Základní charakteristika geodatabáze PostGIS . . . . . . . . . . . .

29

1.5.2

Knihovna libpq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

1.5.3

PostGIS Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

Datové modely pro 3D GIS . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

1.6.1

Simplexy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

1.6.2

3D Formal Data Structure . . . . . . . . . . . . . . . . . . . . . . . .

44

1.6.3

TEtrahedral Network . . . . . . . . . . . . . . . . . . . . . . . . . .

45

1.6.4

Simplified Spatial Model . . . . . . . . . . . . . . . . . . . . . . . . .

48

VII

VIII

OBSAH 1.6.5

Constructive Solid Geometry . . . . . . . . . . . . . . . . . . . . . .

48

1.6.6

Boundary Representation . . . . . . . . . . . . . . . . . . . . . . . .

49

1.6.7

2,8D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

1.6.8

Objektově orientované datové modely . . . . . . . . . . . . . . . . .

50

1.7

Knihovna CGAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

1.8

Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

1.8.1

Proces standardizace v oblasti metadat . . . . . . . . . . . . . . . .

53

1.8.2

Technická norma ISO 19115 . . . . . . . . . . . . . . . . . . . . . . .

53

1.8.3

Technická norma ISO 19139 . . . . . . . . . . . . . . . . . . . . . . .

55

Výměnný formát ISKN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

1.9.1

Informační systém katastru nemovitostí . . . . . . . . . . . . . . . .

56

1.9.2

Specifikace výměnného formátu ISKN . . . . . . . . . . . . . . . . .

56

1.9

2 Analýza současného stavu řešené problematiky 2.1

59

Vektorová architektura systému GRASS GIS . . . . . . . . . . . . . . . . .

59

2.1.1

Poznámky k vektorové architektuře systému GRASS verze 4 a 5 . .

60

2.1.2

Vektorová architektura systému GRASS verze 6 . . . . . . . . . . . .

61

2.1.3

Topologická správa vektorových dat ve verzi GRASS 6 . . . . . . . .

65

2.1.4

Změny v topologické správě vektorových dat ve verzi GRASS 7 . . .

68

Podpora pro externí vektorová data ve verzi GRASS 6 . . . . . . . . . . . .

70

2.2.1

Podpora geodatabáze PostGIS v systému GRASS verze 6 . . . . . .

71

2.2.2

Pseudo-topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

2.3

Podpora pro 3D vektorová data ve verzi GRASS 6 . . . . . . . . . . . . . .

76

2.4

Správa metadat ve verzi GRASS 6 . . . . . . . . . . . . . . . . . . . . . . .

77

2.4.1

77

2.2

Správa metadat ve vektorové knihovně GRASS verze 6 . . . . . . . .

3 Cíle disertační práce

81

4 Analytická část práce

85

4.1

4.2

Interoperabilita vektorové architektury systému GRASS . . . . . . . . . . .

86

4.1.1

Integrace knihovny OGR ve vektorové architektuře GRASS verze 7 .

86

4.1.2

Integrace PostGIS ve vektorové architektuře GRASS verze 7 . . . .

97

4.1.3

Simple Features API vektorové knihovny verze GRASS 7 . . . . . .

100

Podpora geodatabáze PostGIS v systému GRASS GIS . . . . . . . . . . . .

103

4.2.1

103

Podpora PostGIS v rozhraní OGR ve verzi GRASS 7

. . . . . . . .

OBSAH

4.3

4.4

4.5

4.6

IX 4.2.2

Nativní podpora PostGIS ve verzi GRASS 7 . . . . . . . . . . . . . .

105

4.2.3

Integrace PostGIS Topology ve vektorové architektuře GRASS GIS .

107

4.2.4

Nástroje systému GRASS pro práci s geodatabází PostGIS . . . . .

112

Podpora pro 3D vektorová data v systému GRASS GIS . . . . . . . . . . .

116

4.3.1

Topologický model systému GRASS pro 3D vektorová data . . . . .

116

4.3.2

Nástroje systému GRASS pro práci s 3D vektorovými daty . . . . .

121

4.3.3

Integrace knihovny CGAL v systému GRASS GIS . . . . . . . . . .

126

Návrh správy metadat pro verzi GRASS 7 . . . . . . . . . . . . . . . . . . .

127

4.4.1

Konsolidace metadat v systému GRASS GIS . . . . . . . . . . . . .

127

4.4.2

Návrh správy metadat odpovídající technické normě ISO 19115 . . .

128

Vývoj nové generace GUI systému GRASS GIS . . . . . . . . . . . . . . . .

130

4.5.1

Digitalizační nástroj . . . . . . . . . . . . . . . . . . . . . . . . . . .

131

4.5.2

Rozšíření wxGUI pro vizualizaci dat ve 3D . . . . . . . . . . . . . .

132

4.5.3

Grafický modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

133

Podpora pro výměnný formát ISKN v knihovně OGR . . . . . . . . . . . .

134

4.6.1

Implementace podpory VF ISKN v knihovně OGR . . . . . . . . . .

134

4.6.2

FOSS nástroje pro přístup k datům ve výměnném formátu ISKN . .

140

4.6.3

Topologická správa prvků digitální katastrální mapy . . . . . . . . .

143

Závěr

147

Seznam literatury

151

Seznam zkratek

159

Seznam obrázků

163

Seznam tabulek

167

A Specifikace OGC Simple Features Access A.1 Přehled typů jednoduchých geoprvků . . . . . . . . . . . . . . . . . . . . . .

169 169

B Topologie 2D vektorových dat v systému GRASS

175

C Knihovna CGAL

185

C.1 Ukázková aplikace pro 3D triangulaci . . . . . . . . . . . . . . . . . . . . . .

185

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 . . . . . . . . . . . . . . . . . . . . . . .

189

D.2 Skupiny datových bloků . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

189

D.3 Přehled OGR-VFK vrstev . . . . . . . . . . . . . . . . . . . . . . . . . . . .

194

D.4 UML diagram C++ tříd ovladače VFK . . . . . . . . . . . . . . . . . . . .

195

D.5 Ukázková aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

196

E Obsah přiloženého CD

201

Ú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. 93-94), 2012

1

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 2007-2013 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. 1.1.3), 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. 1.9.1. 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. 1.5.3). Topologická nadstavba hraje zásadní roli v navržené integraci geodatabáze PostGIS v systému GRASS.

Ú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. 1.2. 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. 1.6. 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 19115 pro popis geodat a na ni navazující norma ISO 19139. 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. 2.1.4). 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. 2.3. 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. 4.1.1. Vektorové nástroje systému GRASS tak mohou produkovat vektorová

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. 4.1.2. 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. 4.2.4 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. 4.3.1) a implementaci nástrojů pro tvorbu a další analýzu 3D vektorových dat v systému GRASS, viz kap. 4.3.2. 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. 4.5. 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

Create like a God, Command like a King, Work like a Slave

Constantin Brâncuşi

1

Ú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. 4.6.3). 5

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 (http://grass.osgeo.org) je free software1 [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]).

1.1.1 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ěř 6 000 registrovaných uživatelů, na tuto dobu velmi nadprůměrné technické zázemí – e-mailové 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), http://en.wikipedia.org/wiki/Free_software

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 1992. 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]).

8


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 6.4.3 v červenci 2013. 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 2014. 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 (1982-2013).

1.1.2 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).


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. Mapset2 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 UNIXu3 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.

10


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


11

Parameters: dsn Name of input OGR or PostGIS data source format Format for output vector data default: ESRI_Shapefile options 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: http://grasswiki.osgeo.org/wiki/File:Catsnlayers.png).

12


1.1.3 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 TK4 . V roce 2006 byla odstraněna závislost na unixové X115 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. 4.5. 4

Tool Command Language (TCL), grafická knihovna TK, http://www.tcl.tk 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. 5


13

1.1.3.1 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. 2.1.2). 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).

14


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. 1.10 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. 1.2.5). 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. 1.2.1). 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

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.

1.2.1 Špagetový model Mezi nejjednodušší vektorové datové modely patří tzv. špagetový model6 (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 1 − 13. Konfigurace znázorněná na obr. 1.10 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“.

16


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, y9

1.2.2 Seznam lomových bodů Datový model seznamu lomových bodů (Vertex dictionary) vychází ze špagetového modelu (kap. 1.2.1) 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 1 : x1, 2 : x2, ... 13: x13,

lomových bodů a jejich souřadnic y1 y2 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, 9

1.2.3 Dual Independent Map Encoding Vektorový datový model Dual Independent Map Encoding (DIME) byl navržen v US Bureau of the Census7 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.


17

na základě geograficky lokalizovaných adresních údajů [A12]. Práce na specifikaci DIME začaly již v roce 1965. 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 1, x1, 2, x2, ... 13, x13,

lomových bodů a jejich souřadnic y1 y2 y13

# hrana, plocha napravo, plocha nalevo, počáteční uzel, koncový uzel a , , , 2 , 3 b , , , 3 , 4

18 c d e f g h i j k l

KAPITOLA 1. ÚVOD DO PROBLEMATIKY , , , , , , , , , ,

D

D D D

, , , , , , , , , ,

C C C C C C

, , , , , , , , , ,

4 6 7 8 9 10 11 10 12 13

, , , , , , , , , ,

5 7 8 9 10 11 6 12 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].

1.2.4 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.


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 (N1−4 ), hrany (ARC1−4 ) a plochy (AREA1−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 , 2 3 4 4 , 2 3 4 # topologie hran arc, počáteční uzel, koncový uzel, plocha napravo, plocha nalevo 1 , 1 , 2 , , 2 , 9 , 10 , 1 ,

20 3 4

KAPITOLA 1. ÚVOD DO PROBLEMATIKY , 10 , 9,

, 9 , 10

, 1 ,

, 2 , 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 ARC2−4 . geoprvek : bod A : linie B : polygon C: polygon D:

seznam lomových bodů 1 arc1 (2 3 4 5) arc2 (9 8 7 6 11 10) + arc3 (10 9) arc3 (10 9) + arc4 (9 13 12 10)

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. 1.5.3).

1.2.5 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. 2.1.3 a 2.1.4. 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).


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-ArcArea (NAA), viz kap. 1.2.4. 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. 1.10 v topologickém modelu vektorové architektury systému GRASS verze 7 je znázorněn na obr. 1.15.

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 (N1−4 ), linie (L1 ), hraniční linie (B1−3 ) a centroidy (C1 ). Hraniční linie a centroidy formují dvě plochy (A1 , A2 ). Plochy A1 , A2 tvoří v tomto případě jeden ostrov označený jako I1 . Lomové body označené číselným indexem 1 − 13 nejsou součástí datového modelu.

22


1.3 Specifikace OGC Simple Features Access Specifikace OGC Simple Features Access (SFA) popisuje společnou architekturu pro tzv. jednoduché geoprvky8 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 19125 a později v roce 2006 adoptována jako technická norma ČSN 19125. 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. 4.1.3). Kompletní dokumentace specifikace OGC Simple Features Access je dostupná online [B6] z webových stránek organizace Open Geospatial Consorcium (OGC). Open Geospatial Consorcium (http://www.opengeospatial.org) 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.

1.3.1 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. 1.16. 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 (<2 , <3 či <4 ). V případě souřadnicového prostoru <2 je objekt jednoznačně lokalizován souřadnicemi x, y. Prostor <3 přidává třetí souřadnici označovanou jako z nebo m, <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 19100 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.

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. 1.17 je znázorněna kompozice z obr. 1.10 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).

24


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 (http://gdal.org/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. 1.4.1. 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.

1.4. KNIHOVNA OGR

25

1.4.1 Knihovna OGR jako implementace specifikace OGC Simple Features Access 1.4.1.1 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. 1.19. 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.

26


Obrázek 1.19: Datový model knihovny OGR (zdroj: [B11]). 1.4.1.2 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).

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. 4.6.1). Výše uvedené C++ třídy objektového modelu knihovny OGR jsou znázorněny na obr. 1.20.

Obrázek 1.20: Diagram C++ tříd objektového modelu knihovny OGR (zdroj: zdrojové kódy knihovny OGR).

28


1.5 Geodatabáze PostGIS PostGIS (http://www.postgis.org) 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 2001.

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 2008. PostGIS podporuje z velké části kromě specifikace OGC Simple Features Access [B6] také technickou normu ISO 13249 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 92-2003+ 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“.

1.5. GEODATABÁZE POSTGIS

29

1.5.1 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. 1.3.1). 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.

30


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. 4.1.3.2. 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á data13 a topologickou správu vektorových dat (kap. 1.5.3). 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.


31

1.5.2 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. 4.1.2.1). 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 6 7

char * stmt ; PGconn * conn ; PGresult * res ;

8 9 10

/* otev ř í t datab á zi ’ pgisnc ’ */ conn = PQconnectdb ( " dbname = pgisnc " ) ;

11 12 13 14 15 16

stmt = NULL ; asprintf (& stmt , " SELECT SUM ( ST_Length ( wkb_geometry ) ) " " FROM roadsmajor " ) ; /* poslat dotaz */ res = PQexec ( conn , stmt ) ;

17 18 19 20

/* z í skat v ý sledek dotazu */ fprintf ( stdout , " Celkova delka silnic : % d km \ n " , atoi ( PQgetvalue ( res , 0 , 0) ) / 1000) ;

21 22 23 24

PQclear ( res ) ; /* p ř ipojen í k datab á zi korektn ě uzav ř í t */ PQfinish ( conn ) ;

25 26 27 }

return 0;

32


1.5.3 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. 1.23 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, 100 100), uložen dvakrát. polygon | geometrie (WKT) ---------+---------------------------------------------A | POLYGON((100 0,0 0,0 100,100 100,100 0)) B | POLYGON((100 0,100 100,200 100,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 Santilliho14 ) 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, http://strk.keybit.net/projects/ postgis/.


33

1.5.3.1 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 13249 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. 4.6.3. Kompozice polygonů znázorněná na obr. 1.23 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. 1.24. Polygony A a B jsou v topologickém modelu reprezentovány dvěma uzly N1 a N2 , třemi orientovanými hranami E1 , E2 a E3 a dvěma stěnami F1 a F2 . Například polygon A je definován následujícími topologickými elementy: dvěma uzly N1 a N2 , hranami E1 a E2 a stěnou F1 .

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

34


edge a stěny face15 . Jednotlivé záznamy v těchto tabulkách odpovídají vždy jednomu topo-

logické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 13249 čá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é uzly16 . Technická norma ISO 13249 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 13249 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 13249-3 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 Dn = m. Pokud je řád uzlu Dn = 0, jde o uzel izolovaný.


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 13249 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.

36


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 13249 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 13249 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.


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 13249 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. 1.25 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 (N1−15 ), sedmnácti hranami (E1−17 ) a pěti stěnami (F1−5 ). V místě křížení hran je vždy umístěn uzel. Např. cesta č. 1 je reprezentována třemi uzly N1 , N2 a N3 , dvěma hranami E1 a E2 ; parcela č. 3 čtyřmi uzly N7 , N8 , N11 a N12 , hranami E9 , E12 , E13 a E16 , a stěnou F3 ; fontána izolovaným uzlem N15 .

38


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. 2.3. 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.

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. 1.6.1) 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. 1.6.3), který je zásadní pro následnou implementaci 3D topologie v systému GRASS (kap. 4.3.1).

1.6.1 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. 1.6.3). 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
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ý.

40


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 Kn nazýváme graf, ve kterém jsou všechny dvo jice vrcholů spojeny hranou, počet hran v úplném grafu je roven n2 , kde n je počet vrcholů. Platí, že n + 1 afinně nezávislých bodů tvořících n-simplex definují současně uzly Kn+1 úplného grafu. Čtyřstěn (3-simplex) lze tedy reprezentovat jako K4 úplný graf, trojúhelník (2-simplex) jako K3 úplný graf a úsečka (1-simplex) jako K2 ú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. 1.29. Aplikací tohoto modelu pro třetí rozměr vzniká datový model TEtrahedral Network (kap. 1.6.3), 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.


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 f e c

... ... ... ...

počet počet počet počet

uzlů grafu stěn hran 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. 1.6.3), který je tvořen 3-simplexy, lze model reprezentovat jako K4 ú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í.

42


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 K5 ani K3,3 . K5 je úplný graf, K3,3 je úplný bipartitní graf. Definice 5. Dva grafy G = (V, E) a G0 = (V 0 , E 0 ) nazýváme isomorfní, jestliže existuje bijektivní (vzájemně jednoznačné) zobrazení f : V → V 0 tak, že platí: x, y ∈ E, právě když f (x), f (y) ∈ E 0 . 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. 1.30.

Obrázek 1.30: Příklad úplných a bipartitních grafů Ka,b (zdroj: [A21]). Z obr. 1.31 je patrné, že množina čtyřstěnů může obsahovat podgrafy, které jsou isomorfní k úplným grafům K5 a K3,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. 1.6.3) 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 l

... ...

sudé číslo; k ∈< 0, n > liché číslo; l ∈< 1, n >


43

Obrázek 1.31: Podgrafy v rámci datového modelu TEN, které jsou isomorfní k podgrafům K5 a K3,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. 1.32.

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

44


body A1 , A2 , . . . , An můžeme použít následující vztah:

a

11

a21 1

V (A1 , A2 , ..., An+1 ) =

a31 n!

...

an+1,1

a12 a22 a32 ... an+1,2

... a1n ... a2n ... a3n ... ... . . . an+1,n

1

1

1

1

1

(1.2)

Pro objem čtyřstěnu tedy platí:

xA

1

xB V (A, B, C, D) = 6

xC

xD

yA zA yB z B yC zC yD zD

1

1

1

1

(1.3)

1.6.2 3D 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. 1.33.

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).


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.

1.6.3 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. 1.34 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. 1.34 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.

46

KAPITOLA 1. ÚVOD DO PROBLEMATIKY 5. Hrana ARCN R má počáteční uzel node1 a koncový uzel node2 . 6. Uzel N ODEN R 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 ten1 a ten2 , ke kterým může být daný trojúhelník přiřazen. Trojúhelník je definován třemi hranami edge1 , edge2 a edge3 . 8. 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. 1.35 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).


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. 1.36.

Obrázek 1.36: UML diagram datového modelu TEN (zdroj: [A28]).

48


1.6.4 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. 1.6.3) 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.

1.6.5 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. 1.38. Datový model CSG se často využívá podobně jako B-rep (kap. 1.6.6) v počítačem podporovaném projektování (CAD) především v kombinaci s jazykem pro modelování objektů.


49

Obrázek 1.38: Rozklad objektu na jednoduché pravidelné geometrické elementy v rámci datového modelu CSG (zdroj: [A21]).

1.6.6 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. 1.39 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.

50


1.6.7 2,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. 1.40. 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. 1.40 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]).

1.6.8 Objektově orientované datové modely Výše popsané datové modely jako např. 3D Formal Data Structure (viz kap. 1.6.2) 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].

1.7. KNIHOVNA CGAL

51

1.7 Knihovna CGAL Computational Geometry Algorithms Library (CGAL) (http://www.cgal.org) 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. 4.3.3.

1.8 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

52


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 informacemi18 , jsou prostředníkem k interpretaci, verifikaci a užití dat, viz obr. 1.42.

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].

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.

1.8.1 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 1991-1999 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 12657 a FGDC CDGM je uvedeno v [A39].

1.8.2 Technická norma ISO 19115 Geographic Information – Metadata Práce na technické normě ISO 19115 (dále pouze „norma“) [A43] byly započaty již v roce 1995, k jejímu vydání došlo až v roce 2003. Cílem normy je především: • možnost důkladné charakteristiky geografických informací, • zjednodušení organizace a správy geoinformací,

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 19115 (zdroj: [A43]). objektový model UML

slovník dat

balíček

sekce

generalizovaná třída

entita

specifikovaná třída

entita

třída

entita

atribut

element

asociace

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.

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 19106 Geographic information – Profiles.

Obrázek 1.44: Schéma komunitního profilu ISO 19115 (zdroj: [A43]).

1.8.3 Technická norma ISO 19139 Geographic Information – Metadata – XML Schema Implementation Technická norma ISO 19139 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 19115. Technická norma ISO 19139 zahrnuje: • jednotné XML schéma odvozené z modelu ISO 19100 UML, • technologii transformace ISO 19115 a souvisejících abstraktních UML modelů do XML schématu na základě ISO 19106 Geographic information – Profiles.

56


1.9 Výměnný formát informačního systému katastru nemovitostí 1.9.1 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áří 2001. 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.

1.9.2 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 (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. 1.9.2.1 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.

1.9. VÝMĚNNÝ FORMÁT ISKN

57

1.9.2.2 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

N

číselný maximální délka položky 10.2 → maximálně 10 číslic a z toho 2 za desetinnou čárkou bez nevýznamných nul – 0.2 → .2 kladná čísla bez znaménka

T

textový

D

datumový tvar DD.MM.YYYY HH:MI:SS např. “09.09.1999 08:24:05”

maximální délka textové položky

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;28256708;0;"12.12.199612:00:00";"";2;96835708;;;"PKN";675008;;1;100; ;;;6780;2;13;;;113;;"";13913708;;4282708;"a"

58


The only way to deal with an unfree world is to become so absolutely free that your very existence is an act of rebellion.

Albert Camus

2

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. 2.2.2 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. 2.1.4. 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. 2.4.

2.1 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. 2.1.1) až po aktuální verzi GRASS 6 (kap. 2.1.2). 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. 2.1.3 a 2.1.4. 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 PostGIS. Dále se jedná o rozšíření datového modelu vektorové architektury systému GRASS o 3D topologické elementy. 59

60

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

2.1.1 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 1999-2001 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 2002-2005 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. 2.1.2. 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. 2.1. Tabulka 2.1: Struktura nativního vektorového formátu GRASS verze 4 a 5. adresář

popis

dig

binární soubor, geometrická složka popisu geoprvků

dig_ascii

textový soubor, geometrie ve formátu GRASS ASCII

dig_att

textový soubor, atributová složka

dig_cats

textový soubor, kategorie, reprezentační body

dig_plus

binární soubor, topologie

reg

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 389668.32 4433900.99 7 L 395103.96 4434881.19 2

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.

2.1.2 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. 2.1.1). 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 */ /* x - ov á sou ř adnice centroidu plochy */

2 double xx ; 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 = V e c t _ n e w _ l i s t _ s t r u c t () ; 9 10 /* otev ř í t vektorovou mapu ’ urbanareas ’ z mapsetu ’ PERMANENT ’ 11

v re ž imu č ten í */

12 Vect_open_old (& Map , " urbanareas " , " PERMANENT " ) ; 13 14 /* nastavit id plochy */ 15 area_num = 1;

Korespondující část zdrojového kódu GRASS verze 5. 10 /* 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.

62


10 /* z í skat id centroidu dan é plochy */ 11 centroid = V e c t _ g e t _ a r e a _ c e n t r o i d ( 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. 1.2.5. 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).


63

Vektorová knihovna definuje čtyři základní typy 2D1 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.

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

bod

knihovna Sites

linie

rozměr

GRASS 6

rozměr

2D

point

2D/2,5D

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. 2.1.1) 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. 2.3. Vektorová mapa je reprezentována několika soubory uloženými v adresáři odpovídajícím jejímu názvu: $MAPSET/vector/

Význam jednotlivých souborů v adresáři s vektorovou mapou popisuje tab. 2.3.

Tabulka 2.3: Struktura nativního vektorového formátu GRASS verze 6. soubor

popis

coor

binární soubor, geometrická složka popisu geodat

topo

binární soubor, topologie

cidx

binární soubor, index kategorií

head

textový soubor, hlavičkové informace (metadata)

dbln

textový soubor, informace o připojení atributových tabulek

hist

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.


65

2.1.3 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 n1 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 n2 a koncovým uzlem n3 . 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 n4 a n5 . Druhá plocha

66


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 (n6 a n7 ). 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ů

1 2 3 4

1 1 1 3

5

3

6 7 8

1 1 2

id elementu 1 2 -2 4 6 3 -6 -4 -3 5 7 -8 8

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.


67

Tabulka 2.5: Topologický model GRASS verze 6: tabulka topologických elementů (viz obr. 2.1). element 1 2 3 4 5 6 7 8

typ elementu bod linie hraniční hraniční centroid hraniční centroid hraniční

počáteční uzel

koncový uzel

plocha nalevo

plocha napravo

1 2 4 4 6 4 7 8

1 3 5 5 6 5 7 8

0 0 1 2 1 -1 2 -2

0 0 -1 1 0 2 0 3

linie linie linie 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 linií

1 2

2 2

seznam hranic

počet ostrovů

centroid

-3, 4 -4, 6, 2

0 1

5 7

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 TopoGeo (viz kap. 1.5.3.1).

Tabulka 2.7: Topologický model GRASS verze 6: tabulka ostrovů (viz obr. 2.1). ostrov

počet hraničních linií

1 2

2 1

seznam hranic

plocha

3, 6 -8

0 2

68


2.1.4 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 Metzem2 . 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. 4.1.2.2) a rozšíření topologického modelu o 3D elementy (kap. 4.3.1). Topologický model GRASS verze 7 navazuje na svého předchůdce (viz kap. 2.1.3). 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. 2.1.3, 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 - bod , linie , hrani č n í linie , centroid */ char type ; /* offset vektorov é ho elementu v souboru s geometri í ( coor ) */ off_t offset ; /* ukazatel na datovou strukturu s topologick ý mi informacemi - P_topo_l , P_topo_b č i P_topo_c */ void * topo ;

4 5 6 7 8 9 10 11 };

2

Optimalizace datových struktur pro správu topologie 2D vektorových dat (autor: Markus Metz), SVN revize r46898.


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. 1.2.4): 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 */ plus_t N1 ; /* id koncov é ho uzlu */ plus_t N2 ;

7 8 9 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 */ plus_t N1 ; /* id koncov é ho uzlu */ plus_t N2 ; /* id plochy nalevo ( z á porn é id pro ostrov ) */ plus_t left ; /* id plochy napravo ( z á porn é id pro ostrov ) */ plus_t right ;

5 6 7 8 9 10 11 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.

70


1 /* Topologick ý element : centroid */ 2 struct P_topo_c 3 { 4

/* id plochy v ů č i kter é je centroid vzta ž en z á porn é id pro duplicitn í centroid */ plus_t area ;

5 6 7 8 };

V případě kompozice uvedené v kap. 2.1.3 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. 2.2.

Obrázek 2.2: Reprezentace bodu, linie a dvou polygonů v topologickém modelu vektorové architektury GRASS verze 7.

2.2 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.

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. 4.1.2.1 a 4.2. Vzhledem k tomu, že knihovna OGR implementuje specifikaci OGC Simple Features Access (viz kap. 1.4.1), 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. 2.2.2 a částečně i příloha B.

2.2.1 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 2002. 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-

72


tury systému GRASS verze 5.1 pro nativní podporu geodatabáze PostGIS3 . 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. 1.5.2). 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: 1300 ... 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 postgis-devel/2002-June/000023.html.

2002),

http://postgis.refractions.net/pipermail/


73

Modul v.external pro vzniklou vektorovou mapu urbanarea_pg vytvoří pseudo-topologii (tj. soubory topo a fidx), více v kap. 2.2.2. 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’

2.2.2 Pseudo-topologie Vektorová architektura systému GRASS byla od svého počátku (viz kap. 2.1.1) 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. 1.3.1), 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é

74


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. 2.3.

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 (n1 , n2 a n3 ) navázanými na čtyři hraniční linie (1, 2, 3, 6). Dále jsou součástí modelu i dva


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 n1 a koncovým uzlem n2 . 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ý (n1 ). Vnitřní hranice druhého polygonu je reprezentována hraniční linií 4 s počátečním a koncovým uzlem n2 . 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.

76


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. 2.6 . 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. 1.5.3.1) jako plocha ve 2D. V terminologii topologického modelu systému GRASS se tento termín naopak používá pro „plochu ve 3D“.

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 2001-2005 výrazně přepsána (více v kap. 2.1.2). 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. 1.8.1.

2.4.1 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. 2.3. Hlavičkový soubor obsahuje informace o tvůrci dat, původu dat, viz tab. 2.8. Druhý soubor nese informace pouze o historii příkazů, které vedly k vytvoření dané vektorové mapy.

78


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

popis

ORGANIZATION DIGIT DATE DIGIT NAME MAP NAME MAP DATE MAP SCALE OTHER INFO ZONE MAP THRES

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 */ char * date ; /* datum digitalizace */ char * your_name ; /* tv ů rce dat */ char * map_name ; /* n á zev mapy */ /* datum vzniku analogov é p ř edlohy mapy */ char * source_date ; long orig_scale ; /* me ř í tko analogov é p ř edlohy mapy */ char * line_3 ; /* jedno ř á dkov ý koment á ř */ /* pr á hov á hodnota p ř i digitalizaci */ double digit_thresh ;

4 5 6 7 8 9 10 11 12 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.

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:25 2006 | | 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=0.0001 snap=-1 GISDBASE: /bigdata/grassdata05 LOCATION: ncfromfile MAPSET: PERMANENT USER: helena DATE: Thu Oct 19 22:50:25 2006

80


There are enough people who already make the very same things. Let the evolving GRASS still be what it is: a topological GIS. Do not make the same errors as other, make your own. Thierry Laronde

3

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 13249 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

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.


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 13249 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. 2.1.3). 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. 2.1.4. 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

84


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. 3.2. Čá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.

The solution of every problem is another problem.

J. W. Goethe

4

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. 4.1.1) 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. 4.2.2). Dále je popsáno navržené API vektorové knihovny systému GRASS pro přístup k jednoduchým geoprvkům (kap. 4.1.3) včetně integrace knihovny GEOS (kap. 4.1.3.2). 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. 4.2.1), je jádrem této části popis navrženého nativního rozhraní PostGIS pro systém GRASS (kap. 4.2.2). 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. 4.2.3. 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. 4.2.4. 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. 4.3.1). Kromě toho jsou zmíněny vytvořené nástroje systému GRASS, určené pro tvorbu 3D vektorových dat (kap. 4.3.2) včetně experimentální integrace knihovny CGAL v systému GRASS (viz kap. 4.3.3). 85

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. 1.9.2) v knihovně OGR, viz kap. 4.6. Spojovacím článkem s hlavními výstupy práce je kap. 4.6.3, 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.

4.1.1 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. 4.1.1.1), 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. 4.1.1.2), 5. implementovat přístup k datům taktéž v režimu zápisu (kap. 4.1.1.3).

4.1. INTEROPERABILITA VEKTOROVÉ ARCHITEKTURY SYSTÉMU GRASS

87

4.1.1.1 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. 2.2.2). 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

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. 4.1.

Obrázek 4.1: GUI dialog modulu v.external integrovaný v uživatelském rozhraní wxGUI (autor: Martin Landa, 2011).

4.1.1.2 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-


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. 1.1.2. 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 point 10 1 ... all 10 1

max 10 10

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.

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. 2.2.2). 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.


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: 266 ... Number of lines: 355 ... v.external complete. Link to vector map 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. 2.2.2. 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 55717 to 4130 (7%).

92


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 from datasource ’PG:dbname=pgisnc’... ... Generalization (douglas)... ... v.generalize complete. Number of vertices for selected features reduced from 55717 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. 4.1.1.3 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. 4.2.2) v režimu Simple Features Access (viz postfix funkcí sfa).


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. 4.3. 1 static off_t (* V e c t _ w r i t e _ l i n e _ a r r a y [][3]) () = { 2

{

3

/* nativn í form á t */ write_dummy , V1_write_line_nat , V2_wri te_lin e_nat }

4 5

, {

6

/* OGR rozhran í */ write_dummy , V1_write_line_ogr , V2_wri te_lin e_sfa } , { /* PostGIS rozhran í */ write_dummy , V1_write_line_pg , V2_write_line_pg }

7 8 9 10 11 }; 12

13 off_t Vect_write_line ( struct Map_info * Map , 14

int type , const struct line_pnts * points , const struct line_cats * cats )

15 16 17 { 18

off_t offset ;

19 20

/* ... t ě lo funkce omezeno pouze na relevantn í č á st ... */

21 22

offset = (* V e c t _ w r i t e _ l i n e _ a r r a y [ Map - > format ][ Map - > level ]) ( Map , type , points , cats ) ;

23 24 25

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.

94


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žen1 . 4.1.1.4 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í.


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. 4.2.

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-

96


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. 4.1.2.1). 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 km2 . 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 layer: | OGR datasource: | Feature type: ...

OGR (ESRI Shapefile) lakes2 /opt/geodata/shape polygon


97

4.1.2 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. 4.1.2.1) 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. 4.1.2.2). 4.1.2.1 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. 4.1.1.1, 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.

98


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. 1.5.2). 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. 1.4.1). 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. 4.2.2. 4.1.2.2 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. 1.5.3). 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. 1.5.3) 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. 2.1.4). 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. 4.2.3). Ke konverzi dochází při otevření vektorové mapy, viz funkce V2_open_old_pg().


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. 1.5.3). Zároveň jsou aktualizovány topologické informace jak v PostGIS Topology, tak v topologickém modelu, který používá GRASS (kap. 2.1.4). V2_rewrite_line_pg() Přepíše existující topologický element (uzel, hrana či stěna) v datovém modelu TopoGeo 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. 4.2.3.

100


4.1.3 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é.

4.1. INTEROPERABILITA VEKTOROVÉ ARCHITEKTURY SYSTÉMU GRASS 101 4.1.3.1 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 1 1 571530.81289275 265739.96842595 1 1

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(571530.81289275 265739.96842595)

Exportována je pouze geometrická složka popisu geodat, informace o kategoriích či atributech nejsou součástí tohoto výstupu. 4.1.3.2 Integrace knihovny GEOS Geometry Engine Open Source (GEOS) (http://geos.osgeo.org) 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.

102


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’"

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. 4.1.2.1.

4.2.1 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. 2.2.1 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. 4.2.2). 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 Bash2 : 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 created. 2

Bash je název unixového shellu, http://cs.wikipedia.org/wiki/Bash

104


Vzhledem k tomu, že rozhraní OGR ve vektorové knihovně GRASS verze 7 podporuje režim zápisu (viz kap. 4.1.1.3), 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 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.


105

4.2.2 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. 4.2.1) 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 OGR4 (kap. 1.4.1). 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.

106


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: | DB table: | DB name: | Geometry column: | Feature type: ...

PostGIS (PostgreSQL) public.urbanarea pgisnc wkb_geometry polygon

4.2.2.1 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. 4.1.1.4). 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. 4.2.3. 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).


107

Na základě takto vytvořených bodových dat provedeme Delaunayho triangulaci5 (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=n100 ... | Map format: PostGIS (PostgreSQL) | DB table: grassout.n100 | DB name: pgisnc | Geometry column: geom | Feature type: point ... | Number of points: 100 ... GRASS> v.delaunay -l input=n100 output=d100 GRASS> v.info map=d100 ... | Map format: PostGIS (PostgreSQL) | DB table: grassout.d100 | DB name: pgisnc | Geometry column: geom | Feature type: linestring ... | Number of lines: 283 ...

Na obr. 4.4 je zobrazena výsledná konfigurace Delaunayovi triangulace. Vstupní bodová data jsou zvýrazněna modrou barvou.

4.2.3 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, http://en.wikipedia.org/wiki/Delaunay_triangulation

108


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. 1.2.5) se od modelu Topo-Geo (kap. 1.5.3.1) 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é


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. 4.1. 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

PostGIS Topology Node / Uzel containing_face, geom(Point) Edge / Hrana start/end node, next left/right edge, left/right face, geom (LineString) Line / Linie

start/end node Boundary / Hraniční linie start/end node, left/right area Centroid / Reprezentační bod plochy area Face / Stěna mbr(Polygon) Area / Plocha nlines, lines, nisles, isles, centroid Isle / Ostrov nlines, lines, area

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.

110


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. 4.2. Vztah mezi tabulkami datového modelu Topo-Geo a rozšiřujícími tabulkami je znázorněn na obr. 4.5. Tabulka 4.2: Přehled dodatečných tabulek datového modelu GRASS. Tabulka uzlů – node_grass node_id

primární klíč, identifikátor uzlu

lines

seznam hran, které jsou s uzlem svázány

angles

seznam hodnot úhlů výše uvedených hran v radiánech Tabulka ploch – area_grass

area_id

primární klíč, identifikátor ploch

lines

seznam hran, které tvoří hranici plochy

isles

seznam ostrovů, které jsou součástí plochy

centroid

centroid plochy Tabulka ostrovů – isle_grass

isle_id

primární klíč, identifikátor ostrovu

lines

seznam hran, které tvoří hranici ostrovu

area

plocha se kterou je ostrov spojen

Druhý režim aktivovaný volbou options=TOPO_GEO_ONLY=YES u modulů v.external.out (kap. 4.1.1.4) a v.out.postgis (kap. 4.2.4.2) 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. 1.25 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 (N15 v modelu Topo-Geo), ale vektorovým elementem P18 (P → Point),


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 L6 a L17 (L → Line), 4. stěny F1−5 jsou v topologickém modelu GRASS vyjádřeny jako plochy (A → area), 5. topologický model GRASS definuje centroidy C1−5 , 6. plochy v topologickém modulu GRASS současně formují ostrovy (v tomto případě plochy A1−5 formují ostrov I1 ).

Obrázek 4.6: Příklad topologického modelu GRASS verze 7 (viz kompozice obr. 1.25) (autor: Martin Landa, 2013).

112


4.2.4 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. 4.2.4.1). Hlavní část textu se věnuje nově navrženému nástroji v.out.postgis, viz kap. 4.2.4.2. Dále jsou zmíněny plány budoucího vývoje s cílem plnohodnotné podpory geodatabáze PostGIS v systému GRASS.

4.2.4.1 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. 1.4.1). 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. 1.2.5. GRASS> v.in.ogr dsn=PG:dbname=pgisnc layer=urbanarea output=urbanarea_2

... Importing 656 features (OGR layer )... ... Building topology for vector map ... ... Number of nodes: 560 ... Number of boundaries: 1043 Number of centroids: 656 Number of areas: 656 Number of isles: 182


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 (PostgreSQL).

4.2.4.2 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. 4.1.2.1). 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. 4.3.1) 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]

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. 4.2.4.1 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. 4.2.3. 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.


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.

4.2.4.3 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. 4.5.1) 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. 4.7. 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.

116


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. 4.3.1) s cílem implementace topologické správy 3D vektorových dat. V druhé části textu (kap. 4.3.2) 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. 2.1.2, 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).

4.3.1 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 (hrana6 ), • 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. 4.8. Čá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. 1.5.3) 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.

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 F1 , která je ohraničena čtyřmi hranami E1−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).

118


Hrany E1−4 určují celkem čtyři uzly N1−4 . V uvedeném případě bude hranice stěny určena hranami v pořadí {−E1 , E2 , E3 , E4 }. 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. 4.11 je uveden příklad tělesa s dutinou. Těleso je v topologickém modelu reprezentováno objemem V1 , dutina jako objem V2 .

Obrázek 4.11: Reprezentace tělesa s dutinou v 3D topologickém modelu GRASS verze 7 (autor: Martin Landa, 2013). Objem V1 je ohraničen celkem šesti stěnami F1−6 , které jsou reprezentovány dvanácti orientovanými hranami E1−12 . Každá hrana je definována dvěma uzly, např. hrana E1 vede


119

z uzlu N1 do N2 . Uvnitř objemu V1 je umístěn kernelem K1 . Druhý objem V2 je ohraničen devíti hranami E13−21 , které tvoří celkem pět stěn F7−11 . V analogii ke 2D tvoří každý z objemů V1 a V2 tzv. dutiny či otvory H1 a H2 . Kompozice modelovaných 3D objektů je vyjádřena dvěma objemy V1 , V2 a dvěma dutinami H1 , H2 . Dutina H2 je totožná s objemem V2 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. 1.6.1) a vychází do jisté míry z datového modelu TEtrahedral Network (kap. 1.6.3). 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. 4.12. 1D 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).

120


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 7 stěn 15 hran 10 bodů

8 čtyřstěnů 24 trojúhelníků 25 hran 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ů.


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. 4.3.2.5.

4.3.2 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. 4.3.2.1) a v.delaunay3d (kap. 4.3.2.3). Dále byly rozšířeny existující moduly v.drape a v.extrude z verze GRASS 6, viz kap. 4.3.2.2. Jako poslední je zmíněn experimentální modul v.build3d, který je určen pro sestavení topologie 3D vektorových dat (kap. 4.3.2.5). Funkcionalita výše zmíněných nástrojů je prezentována na kompozici obsahující bodové, liniové a plošné geoprvky, viz obr. 4.15.

Obrázek 4.15: Příklad 2D vektorových dat: bodové (A), liniové (B) a plošné (C) geoprvky (autor: Martin Landa, 2013).

122


4.3.2.1 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. 4.3.2.2. 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. 4.15 je zobrazen na obr. 4.16. 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.

4.3.2.2 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.


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. 4.17.

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

124


Příklad výstupu modulu v.extrude pro 2D bodová, liniová a plošná geodata je uveden na obrázku obr. 4.18. 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).

4.3.2.3 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. 1.6.3 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 Addons7 . Příklad. Vytvoření nepravidelné sítě čtyřstěnů pro bodová data převzata z obr. 4.15. 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 (http://grasswiki.osgeo.org/wiki/AddOns) je repozitář určený pro uživatelské nástroje, které nejsou oficiální součástí distribuce systému GRASS.


125

4.3.2.4 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. 4.5.2). 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. 4.3.2.2 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,533

4.3.2.5 Modul v.build3d Modul v.build3d má experimentální charakter. Podobně jako modul v.delaunay3d (kap. 4.3.2.3) 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).

126


Příklad. Sestavení 3D topologie pro objekt budovy zobrazené na obr. 4.13. GRASS> v.build3d map=building Building 3D topology for vector map ... 7 primitives registered 10 vertices registered Building volumes... 1 volumes built 1 holes built Number of nodes: 10 ... Number of faces: 7 Number of volumes: 1 Number of holes: 1 ... Number of edges: 25 Number of triangles: 24 Number of tetrahedrons: 8

4.3.3 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. 4.1.3.2). 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ě šablon8 . 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 SFGAL9 , 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, https://github.com/Oslandia/SFCGAL

4.4. NÁVRH SPRÁVY METADAT PRO VERZI GRASS 7

127

4.4 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 19115 Geographic Information – Metadata a 19139 Geographic Information – Metadata – XML Schema Implementation (kap. 1.8.2).

4.4.1 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. 4.4.1.1 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. 2.8. Další klíče je možné definovat podle potřeby. 1 /* ! 2

\ brief Z á kladn í metadata map

3 */ 4 struct Map_metadata 5 { 6 7 8

/* ! Seznam p á r ů kl í č : hodnota */ struct Key_Value items ;

128 9

KAPITOLA 4. ANALYTICKÁ ČÁST PRÁCE /* ! Seznam koment á ř ů */ char ** commets ;

10 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 7.

4.4.1.2 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.

4.4.2 Návrh správy metadat odpovídající technické normě ISO 19115 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 19115 a 19139 (kap. 1.8.3). 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 19139. 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ě.

4.4. NÁVRH SPRÁVY METADAT PRO VERZI GRASS 7

129

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=iso19139

1 2 3 < gmd:MD_Metadata xmlns:gmd = " http: // www . isotc211 . org /2005/ gmd " 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

... xmlns:gco = " http: // www . isotc211 . org /2005/ gco " > < gmd:contact > < gmd:CI_ResponsibleParty > < g md :i nd iv id ua lN am e > < g co : C ha r a ct e r St r i ng > helena < gmd:organisationName > < g co : C ha r a ct e r St r i ng > NC OneMap < gmd:dateStamp > < gco:DateTime > Thu Oct 19 22 :50:25 2006 < gmd:metadataStandardName > < gc o : C ha r a ct e r St r i ng > ISO 19115 :2003 /19139 ... < gmd:identificationInfo > < gmd:MD_DataIdentification > < gmd:abstract > < g co : C ha r a ct e r St r i ng > North Carolina geodetic points ( points map ) ... < gmd:extent > < gmd:EX_Extent > ...

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.

130


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. 1.1.3) 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ě wxPython10 . 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 2007-2008 a 2011-2012 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ěř 70 000 řá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 (http://www.wxpython.org) je multiplatformní port knihovny wxWidgets pro programovací jazyk Python.

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. 4.5.1), rozšíření pro vizualizaci dat ve 3D (kap. 4.5.2) a grafický modeler (kap. 4.5.3).

Obrázek 4.20: Základní komponenty wxGUI – správce vrstev a mapové okno (autor: Martin Landa, 2012).

4.5.1 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).

132


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 ctypes11 [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 ctypes12 .

4.5.2 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. 1.1.3).

Obrázek 4.22: wxGUI rozšíření pro vizualizaci dat ve 3D ve verzi GRASS 7 (autor: Martin Landa, 2010). 11 12

Integrace Python ctypes v projektu GRASS (autor: Glynn Clements), SVN revize r42262 Digitalizační nástroj wxGUI přepsán do jazyka Python (autor: Martin Landa), SVN revize r44823

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.

4.5.3 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).

134


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. 1.9.1) 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.

4.6.1 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/OGR13 . První verze knihovny GDAL/OGR podporující výměnný formát ISKN byla vydána v lednu 2010 pod označením 1.7.0. 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.

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. Třída definující atribut datového bloku, název atributu, jeho datový typ a délku (tab. 1.3). 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 SQLite14 . 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.

136


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. 4.6.1.3. 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)

28.3 15.3

5.7 3.0

První načtení (geometrie v DB) Druhé načtení (geometrie v DB)

28.8 12.8

5.9 0.5

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. 4.4. 4.6.1.1 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


137

3 /* 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 ;

4.6.1.2 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 ogrinfo15 . $ 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. 1.3. $ 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, http://www.gdal.org/ogrinfo.html

138


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) 4.6.1.3 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. 4.24.

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 = 311040708’ Layer name: SOBR Geometry: Point


139

... OGRFeature(SOBR):1 ID (Integer) = 311040708 STAV_DAT (Integer) = 0 ... UPLNE_CISLO (Integer) = 1014270001 SOURADNICE_Y (Real) = 650451.45 SOURADNICE_X (Real) = 1069791.42 KODCHB_KOD (Integer) = 4 POINT (-650451.449999999953434 -1069791.419999999925494)

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 -----------+-----+--------------+--------------+-----------311127708 | | 651377.77 | 1069006.53 | 4 311130708 | | 651381.75 | 1069005.69 | 4 SBP: ID | ... | PORADOVE_CISLO_BODU | ... | BP_ID | ... -----------+-----+---------------------+-----+------------+----286100708 | | 1 | | 311127708 | 286101708 | | 2 | | 311130708 |

V tomto případě je definována linie se dvěma vrcholovými body. OGRFeature(SBP):1 ID (Integer) = 286100708 STAV_DAT (Integer) = 0 ... OB_ID (Integer) = (null) HP_ID (Integer) = 151540708 DPM_ID (Integer) = (null) PARAMETRY_SPOJENI (String) = "4" ZVB_ID (Integer) = (null) LINESTRING (-651377.77 -1069006.53, -651381.75 -1069005.69)

140


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) = 92340708 STAV_DAT (Integer) = 0 ... TEL_ID (Integer) = 64156708 PAR_ID (Integer) = (null) BUD_ID (Integer) = 25735708 IDENT_BUD (String) = "a" POLYGON ((-651240.46999999997206 -1069564.110000000102445 -651217.300000000046566 -1069525.409999999916181, ... -651244.46999999997206 -1069564.21999999997206, -651240.46999999997206 -1069564.110000000102445))

4.6.1.4 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.

4.6.2 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.

4.6.2.1 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. 4.2.4.1). 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. 1.1.2). GRASS> v.in.ogr dsn=data.vfk output=dkm


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 layer: | OGR datasource: | Feature type: ...

OGR (VFK) BUD data.vfk polygon

Příklad. Přímý přístup přes rozhraní OGR bez tvorby odkazu (viz kap. 4.1.1.2). 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"

4.6.2.2 QGIS QGIS (Quantum GIS, http://www.qgis.org) 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 PostGIS, SpatiaLite a GRASS.

142


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 studenty16 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.


143

4.6.3 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 ogr2ogr17 . 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. 1.5.3). 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. 4.1.1.4). Druhý postup využívá modul v.out.postgis [B25] (kap. 4.2.4.2) v kombinaci s přímým přístupem k externím datům přes OGR rozhraní vektorové knihovny systému GRASS (kap. 4.1.1). 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. 4.1.1.2. 17

Nástroj knihovny OGR ogr2ogr, http://www.gdal.org/ogr2ogr.html

144


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. 4.27.

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. 1.5.3.1) vyjádřena elementem stěny s identifikátorem 1043. SELECT (topo).* FROM dkm_par WHERE KMENOVE_CISLO_PAR = 381; topology_id | layer_id | id | type -------------+----------+------+-----1 | 1 | 1043 | 3

Dále najdeme stěny, které sdílí hrany se stěnou 1043. 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;


145

face -----253 262 263 1051 1052 1060

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 ------------------368 380 382 393 394 395

Dotaz by ve výsledku mohl vypadat následovně: 1 SELECT KME NOVE_C ISLO_P AR FROM dkm_par WHERE ( topo ) . id IN 2 3 4 5 6 7 8 9 10 11 12

( SELECT right_face AS face FROM topo_dkm_par . edge WHERE left_face = ( SELECT ( topo ) . id FROM dkm_par WHERE KME NOVE_C ISLO_P AR = 381 ) UNION ALL SELECT left_face AS face FROM topo_dkm_par . edge WHERE right_face = ( SELECT ( topo ) . id FROM dkm_par WHERE KME NOVE_C ISLO_P AR = 381 ) ) ORDER BY KME NOVE_C ISLO_P AR ;

146


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 13249 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 13249 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

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. 4.6.2). 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.

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 13249 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.

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 2005. 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 2014. 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 19115 a implementaci vybraných algoritmů, s cílem komplexní topologické správy 3D vektorových dat v systému GRASS.

Seznam literatury Primární zdroje (A) [A1]

A. Čepek. “Nové technologie: kulturní šok (nejen) pro zeměměřiče”. In: Pražská technika Vol. 3/2010 (2010), pp. 18–19. issn: 1213-5348.

[A2]

M. Neteler et al. “GRASS GIS: A multi-purpose open source GIS”. In: Environmental Modelling & Software Vol. 31 (2012). Elsevier. [vid. 6. 5. 2012] Dostupné z: http://dx.doi.org/10.1016/j.envsoft.2011.11.014, pp. 124–130. issn: 1364-8152.

[A3]

R. Stallman and J. Gay. Free software, free society: selected essays of Richard M. Stallman. Free Software Foundation, 2002. isbn: 9781882114986.

[A4]

J. Westervelt. “GRASS Roots”. In: FOSS/GRASS User Conference, Bangkok, Thajsko. [vid. 6. 8. 2011] Dostupné z: http://gisws.media.osaka-cu.ac.jp/grass04/ viewpaper.php?id=53. 2004.

[A5]

J. Westervelt. “Early GRASS Community Views on FOSS”. In: FOSS4G2006 Free And Open Source Software for Geoinformatics, Lausanne, Švýcarsko. [vid. 8. 10. 2011] Dostupné z: http://2006.foss4g.org/contributionDisplay7563. html?contribId=214&sessionId=54&confId=1. 2006.

[A6]

M. Neteler and H. Mitasova. Open Source GIS: A GRASS GIS Approach. Springer, 2010. isbn: 9781441942067.

[A7]

E.S. Raymond. The Art of Unix Programming. Addison-Wesley Professional Computing Series. Addison-Wesley, 2004. isbn: 9780131429017.

[A8]

J. Čepický and M. Landa. “GRASS GIS Digitalization tools”. In: Italian GRASS and GFOSS Users Meeting. [vid. 6. 6. 2012] Dostupné z: http://geo.fsv.cvut. cz/~landa/publications/2007/italian-gfoss-07/grass-digit.pdf. 2007.

[A9]

D.J. Peuquet and D.F. Marble. Introductory Readings In Geographic Information Systems. Taylor & Francis, 1990. isbn: 9780850668575.

[A10]

J. Tuček. GIS - Geografické informační systémy: principy a praxe. CAD & GIS. Computer Press, 1998. isbn: 9788072260911. 151

152

SEZNAM LITERATURY

[A11]

J.G. Liu and P. Mason. Essential Image Processing and GIS for Remote Sensing. John Wiley & Sons, 2009. isbn: 9780470746042.

[A12]

M.N. DeMers. GIS For Dummies. John Wiley & Sons, 2009. isbn: 9780470521502.

[A13]

J. Šíma. “Příspěvek ke zlepšení užívání odborné terminologie v oboru geoinformatiky”. In: GEOinformace 10.9 (2002), pp. 4–6. issn: 1214-2204.

[A14]

E. F. Codd. “A Relational Model of Data for Large Shared Data Banks”. In: Commun. ACM 13.6 (1970), pp. 377–387.

[A15]

Mezinárodní organizace pro normalizaci. ISO 13249-3 Information technology – Database languages – SQL multimedia and application packages – Part 3: Spatial. 2011.

[A16]

R. Obe and L. Hsu. PostGIS in Action. Manning Pubs Co Series. Manning Publications, 2011. isbn: 9781935182269.

[A17]

P. O’Neil and E. O’Neil. Database–principles, Programming, and Performance. The Morgan Kaufmann Series in Data Management Systems. Morgan Kaufmann Publishers, 2001. isbn: 9781558604384.

[A18]

G. Graefe. Modern B-Tree Techniques. Now Publishers, 2011. isbn: 9781601984821.

[A19]

Y. Manolopoulos, A.N. Papadopoulos, and M.G. Vassilakopoulos. Spatial Databases: Technologies, Techniques and Trends. ITPro collection. Idea Group Pub., 2005. isbn: 9781591403890.

[A20]

K. Douglas and S. Douglas. PostgreSQL: A Comprehensive Guide to Building, Programming, and Administering PostgreSQL Databases. Developer’s Library. Sams, 2003. isbn: 9780735712577.

[A21]

Morakot Pilouk and A Abdul-Rahman. Spatial data modelling for 3D GIS. springer Berlin Heidelberg, Berlin, 2007.

[A22]

Morakot Pilouk. Integrated modelling for 3D GIS. Landbouwuniversiteit te Wageningen, 1996.

[A23]

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. 405–418.

[A24]

Mark Anthony Armstrong. “Basic topology. Undergraduate texts in mathematics”. In: Springer-Verlag 1 (1983), p. 983.

[A25]

Jiří Demel. Grafy a jejich aplikace. Academia, 2002.

[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. 25–33.

SEZNAM LITERATURY

153

[A28]

Ir F Penninga. “Constrained tetrahedral models and update algorithms for topographic data”. In: Geo-information and computational geometry (), p. 35.

[A29]

Siyka Zlatanova. 3D GIS for urban development. International Inst. for Aerospace Survey and Earth Sciences (ITC), 2000.

[A30]

Volker Coors. “3D-GIS in networking environments”. In: Computers, Environment and Urban Systems 27.4 (2003), pp. 345–357.

[A31]

Rongxing Li. “Data structures and application issues in 3-D geographic information systems”. In: Geomatica 48.3 (1994), pp. 209–224.

[A32]

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. 78–85.

[A33]

Alias Abdul-Rahman. “The design and implementation of a two and three-dimensional triangular irregular network based GIS”. PhD thesis. University of Glasgow, 2000.

[A34]

Pfund M. “Topologic data structure for a 3D GIS”. In: Proceedings of International Society for Photogrammetry and Remote Sensing Journal 34 (2001), pp. 233–237.

[A35]

Arnaud De la Losa and Bernard Cervelle. “3D Topological modeling and visualisation for 3D GIS”. In: Computers & Graphics 23.4 (1999), pp. 469–478.

[A36]

E. Fogel, D. Halperin, and R. Wein. CGAL Arrangements and Their Applications: A Step-by-Step Guide. Geometry and computing. Springer Berlin Heidelberg, 2012. isbn: 9783642172830. url: http://www.google.cz/books?id=u0CONtnwi9YC.

[A37]

J. Růžička. “Metadata v procesu realizace GIS projektu”. In: GIS Ostrava 2002. ISSN: 1213-2454. 2002.

[A38]

I.T.L.E.S. Limited. Introduction To Information Technology. Pearson Education, 2005. isbn: 9788177581188.

[A39]

J. Ružička. “Metadata pro prostorová data”. PhD thesis. Institut geoinformatiky, VŠB - Technická univerzita Ostrava, 2002.

[A40]

H. Aalders. “Data searching by metadata”. In: GIS Ostrava 2001. ISSN: 1213-2454. 2001.

[A41]

H. Moellering, H. Aalders, and A. Crane. World spatial metadata standards. ISBN 0-08-043949-7. Elsevier Ltd., 2005.

[A42]

W. Kresse and K. Fadaie. ISO Standards for Geographic Information. Springer, 2004. isbn: 9783540201304.

[A43]

Mezinárodní organizace pro normalizaci. ISO 19115 Geographic Information – Metadata. 2004.

154

SEZNAM LITERATURY

[A44]

J. Arlow and I. Neustadt. UML a unifikovaný proces vývoje aplikací. ISBN 80-7226947-X. Addison-Wesley, český překlad Computer Press, 2003.

[A45]

E. R. Harold and W.S. Means. XML in a Nutshell. ISBN 0-596-00764-7. O’Reilly Media, Inc., 2004.

[A46]

R. Chromý. “Využití webových služeb v katastru nemovitostí”. [vid. 30. 7. 2012] Dostupné z: http://geo.fsv.cvut.cz/proj/dis/2008/radek- chromy- dis2008.pdf. PhD thesis. Fakulta stavební ČVUT v Praze, 2008.

[A47]

M. Landa. “Návrh modulu GRASSu pro import dat ve výměnném formátu ISKN”. [vid. 5. 5. 2011] Dostupné z: http://geo.fsv.cvut.cz/proj/dp/2005/martinlanda-dp-2005.pdf. MA thesis. Fakulta stavební ČVUT v Praze, 2005.

[A48]

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. 14. 7. 2010] Dostupné z: http://www.ing.unitn.it/~grass/conferences/GRASS2002/ proceedings/proceedings/pdfs/Blazek_Radim.pdf. 2002.

[A49]

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, 2002. isbn: 9781558605886.

[A50]

Martin Landa. “GRASS GIS 7.0: Interoperability improvements”. English. In: GIS Ostrava 2013. 2013. isbn: 978-80-248-2951-7. url: http : / / geo . fsv . cvut . cz / ~landa/publications/2013/gis- ostrava-2013/paper/landa_grass7_paper. pdf.

[A51]

A Čepek. Informatika, Úvod do C++, 1. vyd. Praha: Nakladatel’stvo ČVUT, 2004. 265 s. Tech. rep. ISBN 80-01-03074-1.

[A52]

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. 3. 8. 2011] Dostupné z: http://geo.fsv.cvut.cz/ data/geoinformatics/2007/09/19/geoinformatics- fce- ctu- 2007- 02.pdf. issn: 1802-2669.

[A53]

M. Landa. “OGR VFK Driver Implementation Issues”. In: Symposium GIS Ostrava 2010. [vid. 4. 3. 2012] Dostupné z: http : / / geo . fsv . cvut . cz / ~landa / publications/2010/gis-ostrava-2010/paper/landa-ogr-vfk.pdf. 2010.

[A54]

G.E. Sherman. Desktop GIS: Mapping the Planet with Open Source Tools. Pragmatic Bookshelf Series. Pragmatic Bookshelf, 2008. isbn: 9781934356067.

SEZNAM LITERATURY

155

Online zdroje (B) [B1]

Free Software Foundation. GNU General Public License, version 2. [vid. 5. 5. 2012] Dostupné z: http://www.gnu.org/licenses/gpl-2.0.html.

[B2]

GRASS Development Team. GRASS Logograms. [vid. 15. 3. 2012] Dostupné z: http://grass.osgeo.org/download/logograms.php.

[B3] Archives of scanned GRASSCLIPPINGS issues. [vid. 10. 5. 2012] Dostupné z: http://skagit.meas.ncsu.edu/~helena/grasswork/grassclip/. [B4]

GRASS Development Team. GRASS GIS 7 Reference Manual. [vid. 1. 6. 2012] Dostupné z: http://grass.osgeo.org/grass70/manuals/index.html.

[B5]

Rapant P. Návrh terminologického slovníku CAGI. [vid. 4. 4. 2013] Dostupné z: http://mailman.fsv.cvut.cz/lists/gis-cz/2000/msg00060.html.

[B6]

Open Geospatial Consortium. OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture. [vid. 25. 11. 2011] Dostupné z: http://www.opengeospatial.org/standards/sfa.

[B7]

GDAL/OGR Development Team. Seznam formátů podporovaných knihovnou OGR. [vid. 7. 7. 2012] Dostupné z: http://gdal.org/ogr/ogr_formats.html.

[B8]

GDAL Development Team. GDAL Logograms. [vid. 29. 3. 2012] Dostupné z: http: //svn.osgeo.org/gdal/trunk/gdal/data/GDALLogoColor.svg.

[B9]

GDAL/OGR Development Team. Seznam projektů, které používají knihovnu GDAL/OGR. [vid. 2. 3. 2012] Dostupné z: http : / / trac . osgeo . org / gdal / wiki / SoftwareUsingGdal.

[B10]

Open Geospatial Consortium. Simple Features Implementation Specification for OLE/COM. [vid. 1. 3. 2012] Dostupné z: http://www.opengeospatial.org/standards/ sfo.

[B11]

GDAL/OGR Development Team. Rozhraní pro programování aplikací API knihovny OGR. [vid. 1. 5. 2012] Dostupné z: http://gdal.org/ogr/ogr_arch.html.

[B12]

Open Geospatial Consortium. Coordinate Transformation Service Implementation Specification. [vid. 5. 4. 2012] Dostupné z: http : / / www . opengeospatial . org / standards/sfo.

[B13]

PostGIS Development Team. PostGIS Logograms. [vid. 16. 8. 2012] Dostupné z: http://postgis.org/download/logo_suite/.

[B14]

A. Čepek and M. Landa. Přednášky předmětu „Úvod do zpracování prostorových dat“. [vid. 1. 4. 2012] Dostupné z: http://geo.fsv.cvut.cz/~gin/uzpd/uzpd.pdf.

[B15]

PostGIS Development Team. PostGIS Topology. [vid. 5. 7. 2012] Dostupné z: http://postgis.org/documentation/manual-2.0/Topology.html.

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. 4. 2. 2012] Dostupné z: http://www.wiscorp.com/H2- 2004- 168r2- Topo- Geo- and- Topo- Net- 1- TheConcepts.pdf.

[B17]

CGAL Development Team. CGAL Logograms. [vid. 1. 6. 2013] Dostupné z: http://www.cgal.org/logo.html.

[B18]

CGAL Development Team. The CGAL License. [vid. 1. 6. 2013] Dostupné z: http://www.cgal.org/license.html.

[B19]

M. Landa. Závěrečná zpráva řešení interního grantu ČVUT CTU0604711. [vid. 1. 3. 2012] Dostupné z: http://geo.fsv.cvut.cz/~landa/publications/ 2007/igs/landa-metadata-grass.pdf.

[B20]

D. Hart and H. Phillips. Metadata Primer – A "How To" Guide on Metadata Implementation. [vid. 7. 8. 2012] Dostupné z: http://www.lic.wisc.edu/metadata/ metaprim.htm.

[B21]

Č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. 6. 6. 2012] Dostupné z: http://www.cuzk.cz/Dokument.aspx?PRARESKOD=998&MENUID=0&AKCE=DOC:10VF_ISKNTEXT.

[B22]

M. Landa and GRASS Development Team. Manuálová stránka modulu v.external.out. [vid. 5. 7. 2012] Dostupné z: http : / / grass . osgeo . org / grass70 / manuals / v . external.out.html.

[B23]

GRASS Development Team. Specifikace GRASS ASCII vektorového formátu. [vid. 5. 4. 2012] Dostupné z: http://grass.osgeo.org/grass70/manuals/vectorascii. html.

[B24]

M. Landa and GRASS Development Team. Integrace knihovny GEOS ve vektorové knihovně GRASS verze 7. [vid. 14. 8. 2012] Dostupné z: http://grass.osgeo.org/ programming7/vectorlib.html#vlibGeosFn.

[B25]

M. Landa and GRASS Development Team. Manuálová stránka modulu v.out.postgis. [vid. 1. 7. 2012] Dostupné z: http://grass.osgeo.org/grass70/manuals/v.out. postgis.html.

[B26]

M. Landa and GRASS Development Team. Manuálová stránka modulu v.to.3d. [vid. 11. 5. 2013] Dostupné z: http : / / grass . osgeo . org / grass70 / manuals / v.to.3d.html.

[B27]

M. Landa and GRASS Development Team. Manuálová stránka modulu v.drape. [vid. 17. 5. 2013] Dostupné z: http : / / grass . osgeo . org / grass70 / manuals / v.drape.html.

SEZNAM LITERATURY

157

[B28]

M. Landa and GRASS Development Team. Manuálová stránka modulu v.extrude. [vid. 16. 5. 2013] Dostupné z: http://grass.osgeo.org/grass70/manuals/v.to. extrude.html.

[B29]

M. Landa and GRASS Development Team. Manuálová stránka modulu m.nviz.image. [vid. 20. 5. 2013] Dostupné z: http://grass.osgeo.org/grass70/manuals/m. nviz.image.html.

[B30]

M. Landa. Závěrečná zpráva projektu GFOSS-TN (2007/2008). [vid. 1. 5. 2012] Dostupné z: http://geo.fsv.cvut.cz/~landa/projects/gfosstn/2008/fbkreport/latex/landa-grass-fbk.pdf.

[B31]

M. Landa and GRASS Development Team. Knihovna GRASS Vedit. [vid. 5. 5. 2012] Dostupné z: http://grass.osgeo.org/programming7/veditlib.html.

[B32]

Python Foundation. Ctypes – A foreign function library for Python. [vid. 4. 2. 2012] Dostupné z: http://docs.python.org/library/ctypes.html.

[B33]

M. Landa and GRASS Development Team. Manuálová stránka wxGUI grafického modeleru. [vid. 1. 3. 2012] Dostupné z: http : / / grass . osgeo . org / grass70 / manuals/wxGUI.Modeler.html.

[B34]

M. Landa. Knihovna OGR: VFK driver. [vid. 1. 8. 2012] Dostupné z: http://gdal.org/ogr/drv_vfk.html.

[B35]

QGIS Development Team. QGIS Logograms. [vid. 5. 8. 2012] Dostupné z: http://en.wikipedia.org/wiki/File:QGis_Logo.png.

[B36]

Sylvain Pion and Monique Teillaud. 3D Triangulations. [vid. 1. 6. 2013] Dostupné z: http://doc.cgal.org/4.2/CGAL.CGAL.3D-Triangulations/html/.

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: 1802-2669.

[C2]

A. Kratochvílová. WxNviz GSoC 2011. [vid. 18. 8. 2012] Dostupné z: http://grass.osgeo.org/wiki/WxNviz_GSoC_2011.

[C3]

Štěpán Turek. WxVNet GSoC 2012. [vid. 19. 8. 2012] Dostupné z: http://grass. osgeo.org/wiki/GRASS_GSoC_2012_WxGUI_front_end_for_vector_analysis_ modules.

[C4]

A. Kratochvílová. “Grafické uživatelské rozhraní pro tvorbu mapových výstupů v systému GRASS”. [vid. 6. 7. 2012] Dostupné z: http://geo.fsv.cvut.cz/proj/ bp/2011/anna-kratochvilova-bp-2011.pdf. MA thesis. Fakulta stavební ČVUT v Praze, 2011.

[C5]

Štěpán Turek. “Implementace podpory WMS do programů GRASS GIS a SGA GIS”. [vid. 24. 6. 2012] Dostupné z: http://geo.fsv.cvut.cz/proj/bp/2012/ stepan-turek-bp-2012.pdf. MA thesis. Fakulta stavební ČVUT v Praze, 2012.

[C6]

Zdeněk Růžička. “Workflow Builder pro Quantum GIS”. [vid. 16. 7. 2012] Dostupné z: http://geo.fsv.cvut.cz/proj/dp/2012/zdenek- ruzicka- dp- 2012.pdf. MA thesis. Fakulta stavební ČVUT v Praze, 2012.

[C7]

Tereza Fiedlerová. “Zásuvný modul QGIS pro slučování vektorových dat”. [vid. 24. 6. 2013] Dostupné z: http://geo.fsv.cvut.cz/proj/bp/2013/terezafiedlerova-bp-2013.pdf. MA thesis. Fakulta stavební ČVUT v Praze, 2013.

Seznam zkratek ANSI

American National Standards Institute

API

Application Programming Interface

ASCII

American Standard Code for Information Interchange

B-rep

Boundary Representation

CAC

Computer Aided Cartography

CAD

Computer Aided Design

CAGI

České asociace pro geoinformace

CDGM

Content Standard for Digital Geospatial Metadata

CGAL

Computational Geometry Algorithms Library

CEN

European Committee for Standardisation

CLI

Command Line Interface

COM

Component Object Model

CSG

Constructive Solid Geometry

CVS

Concurrent Version System

ČSN

Česká technická norma

ČÚZK

Český úřad zeměměřický a katastrální

ČVUT

České vysoké učení technické

DBMI

DataBase Management Interface

DCEL

Double Connected Edge List

DE-9IM

Rozšířený rozměrový 9-ti průsečíkový model 159

160

SEZNAM ZKRATEK

DIME

Dual Independent Map Encoding

DMT

Digitální model terénu

ENv

European Pre-standards

EPSG

European Petroleum Survey Group

Esri

Environmental Systems Research Institute

FDS

Formal Data Structure

FGDC

Federal Geographic Data Committee

FOSS

Free and Open Source Software

FRVŠ

Fond rozvoje vysokých škol

GBF

Geographic Base Files

GDAL

Geospatial Data Abstraction Library

GEOS

Geometry Engine Open Source

GIS

Geografický informační systém

GiST

Generalized Search Tree

GNU

Gnu’s Not Unix

GPL

General Public License (všeobecná veřejná licence)

GRASS

Geographic Resources Analysis Support System

GUI

Grafické uživatelské rozhraní

GXM

GRASS Model File

GXW

GRASS Workspace File

IEEE

Institute for Electrical and Electronic Enginners

IS

Informační systém

ISKN

Informační systém katastru nemovitostí

ISO

International Standard Organisation

JTS

Java Topology Suite

KN

Katastr nemovitostí

SEZNAM ZKRATEK LGPL

Lesser General Public License

LIDAR

Light Detection And Ranging (laserové skenování)

LOM

Learning Object Metadata

NAA

Node-Arc-Area

OGC

Open Geospatial Consorcium

OGF

Open GRASS Foundation

OGR

OpenGIS Simple Features Reference Implementation

OLE

Object Linking and Embedding

OS

Operační systém

OSGeo

Open Source Geospatial Foundation

QGIS

Quantum GIS

POET

Persistent Objects and Extended Database Technology

PPM

Portable Pixmap Format

SFA

Simple Features Access

S-JTSK

Souřadnicový systém jednotné trigonometrické sítě katastrální

SOMAS

Solid Object Mananagement System

SSM

Simplified Spatial Model

SQL

Structured Query Language

SQL/MM

Information technology – Database languages – SQL multimedia and application packages

SŘBD

Systém řízení báze dat

SVN

Subversion

SWIG

Simplified Wrapper and Interface Generator

TC

Technical Committee

TCL

Tool Command Language

TEN

TEtrahedral Network

161

162

SEZNAM ZKRATEK

TIF

Tagged Image File Format

TIGER

Topologically Integrated Geographic Encoding and Referencing

TIN

Triangulated Irregular Network

UDM

Urban Data Model

UI

Uživatelské rozhraní

UML

Unified Modeling Language

USA-CERL United States Army Construction Engineering Research Laboratories VF

Výměnný formát

W3C

World Wide Web Consortium

WKB

Well Known Binary

WKT

Well Known Text

WWW

World Wide Web

XML

Extensible Markup Language

Seznam obrázků 1.1

Logo projektu GRASS GIS. . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.2

Časopis GRASSCLIPPINGS. . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.3

Programátor systému GRASS Dave Gerdes (USA-CERL). . . . . . . . . . .

7

1.4

Časová osa vývoje systému GRASS GIS (1982-2013). . . . . . . . . . . . . .

8

1.5

Úvodní obrazovka grafického uživatelského rozhraní wxGUI. . . . . . . . . .

9

1.6

Vztah vektorové vrstvy a atributové tabulky v systému GRASS. . . . . . .

11

1.7

GIS Manager ve verzi GRASS 6.3. . . . . . . . . . . . . . . . . . . . . . . .

12

1.8

Digitalizační modul ve verzi GRASS 4.0. . . . . . . . . . . . . . . . . . . . .

13

1.9

Digitalizační modul ve verzi GRASS 5.7. . . . . . . . . . . . . . . . . . . . .

13

1.10 Příklad vektorového modelu v GIS. . . . . . . . . . . . . . . . . . . . . . . .

14

1.11 Příklad špagetového modelu. . . . . . . . . . . . . . . . . . . . . . . . . . .

15

1.12 Příklad vektorového modelu Dual Independent Map Encoding. . . . . . . .

17

1.13 Příklad vektorového modelu Arc-Node-Area. . . . . . . . . . . . . . . . . . .

19

1.14 Topologický model vektorové architektury systému GRASS. . . . . . . . . .

20

1.15 Příklad reprezentace geoprvků ve vektorovém modelu systému GRASS. . .

21

1.16 Datový model specifikace OGC Simple Features Access. . . . . . . . . . . .

23

1.17 Příklad kompozice jednoduchých geoprvků. . . . . . . . . . . . . . . . . . .

23

1.18 Logo projektu GDAL/OGR. . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

1.19 Datový model knihovny OGR. . . . . . . . . . . . . . . . . . . . . . . . . .

26

1.20 Diagram C++ tříd objektového modelu knihovny OGR. . . . . . . . . . . .

27

1.21 Logo projektu PostGIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

1.22 Architektura server-klient geodatabáze PostGIS. . . . . . . . . . . . . . . .

30

1.23 PostGIS Simple Features Access: Příklad sousedících polygonů. . . . . . . .

32

1.24 Příklad topologické reprezentace polygonů v PostGIS Topology. . . . . . . .

33

1.25 Příklad modelování reálných objektů v GIS. . . . . . . . . . . . . . . . . . .

37

163

164

SEZNAM OBRÁZKŮ 1.26 Příklad modelování reálných objektů v topologickém modelu Topo-Geo. . .

38

1.27 Ukázka n-rozměrných simplexů. . . . . . . . . . . . . . . . . . . . . . . . . .

39

1.28 Sousednost n-rozměrných simplexů. . . . . . . . . . . . . . . . . . . . . . . .

40

1.29 Zobecněný n-rozměrný simplex datový model. . . . . . . . . . . . . . . . . .

41

1.30 Příklad úplných a bipartitních grafů. . . . . . . . . . . . . . . . . . . . . . .

42

1.31 Podgrafy v rámci datového modelu TEN. . . . . . . . . . . . . . . . . . . .

43

1.32 Ukázka n-rozměrných complex objektů. . . . . . . . . . . . . . . . . . . . .

43

1.33 Datový model 3D Formal Data Structure (FDS). . . . . . . . . . . . . . . .

44

1.34 Datový model TEN ve formě relačních datových struktur. . . . . . . . . . .

45

1.35 Porovnání datového modelu TEN a TIN. . . . . . . . . . . . . . . . . . . . .

47

1.36 UML diagram datového modelu TEN. . . . . . . . . . . . . . . . . . . . . .

47

1.37 Datový model Simplified Spatial Model. . . . . . . . . . . . . . . . . . . . .

48

1.38 Datový model Constructive Solid Geometry. . . . . . . . . . . . . . . . . . .

49

1.39 Datový model Boundary Representation. . . . . . . . . . . . . . . . . . . . .

49

1.40 Datový model 2,8D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

1.41 Logo projektu CGAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

1.42 Interpretace dat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

1.43 Typy elementů metadat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

1.44 Schéma komunitního profilu ISO 19115. . . . . . . . . . . . . . . . . . . . .

55

2.1

Topologický model GRASS verze 6. . . . . . . . . . . . . . . . . . . . . . . .

65

2.2

Topologický model GRASS verze 7. . . . . . . . . . . . . . . . . . . . . . . .

70

2.3

Sestavení pseudo-topologie pro jednoduché geoprvky. . . . . . . . . . . . . .

74

2.4

Sestavení pseudo-topologie pro plochy. . . . . . . . . . . . . . . . . . . . . .

75

2.5

Sestavení pseudo-topologie pro ostrovy. . . . . . . . . . . . . . . . . . . . . .

76

2.6

Nepravidelná 2,5D trojúhelníková síť. . . . . . . . . . . . . . . . . . . . . . .

77

3.1

Tři generace GIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

3.2

Architektura systému GRASS. . . . . . . . . . . . . . . . . . . . . . . . . .

84

4.1

GUI dialog modulu v.external. . . . . . . . . . . . . . . . . . . . . . . . .

88

4.2

GUI dialog modulu v.external.out.

. . . . . . . . . . . . . . . . . . . . .

95

4.3

Rozhraní PostGIS a OGR vektorové knihovny GRASS. . . . . . . . . . . . .

105

4.4

Příklad grafického výstupu dat uložených v geodatabázi PostGIS. . . . . . .

108

4.5

Relační diagram rozšířeného topologického schématu PostGIS Topology. . .

111

SEZNAM OBRÁZKŮ

165

4.6

Příklad topologického modelu GRASS verze 7. . . . . . . . . . . . . . . . .

111

4.7

Editace vektorových dat PostGIS v digitalizačním nástroji wxGUI. . . . . .

115

4.8

2D/3D topologický model vektorové architektury systému GRASS. . . . . .

117

4.9

Orientace stěny ve 3D topologickém modelu GRASS. . . . . . . . . . . . . .

117

4.10 Příklad otvoru a dutiny v tělese. . . . . . . . . . . . . . . . . . . . . . . . .

118

4.11 Reprezentace tělesa s dutinou v 3D topologickém modelu GRASS. . . . . .

118

4.12 Simplex 3D topologický model vektorové architektury systému GRASS. . .

119

4.13 Příklad geometrické reprezentace budovy jako mnohostěnu. . . . . . . . . .

120

4.14 Příklad rozložení mnohostěnu na množinu čtyřstěnů. . . . . . . . . . . . . .

121

4.15 Příklad 2D vektorových dat. . . . . . . . . . . . . . . . . . . . . . . . . . . .

121

4.16 Příklad použití modulu v.to.3d. . . . . . . . . . . . . . . . . . . . . . . . . .

122

4.17 Příklad použití modulu v.drape.

. . . . . . . . . . . . . . . . . . . . . . . .

123

4.18 Příklad použití modulu v.extrude. . . . . . . . . . . . . . . . . . . . . . . .

124

4.19 Příklad použití modulu v.delaunay3d. . . . . . . . . . . . . . . . . . . . . .

124

4.20 Základní komponenty wxGUI. . . . . . . . . . . . . . . . . . . . . . . . . . .

131

4.21 Digitalizační modul wxGUI ve verzi GRASS 6.4. . . . . . . . . . . . . . . .

131

4.22 wxGUI rozšíření pro vizualizaci dat ve 3D. . . . . . . . . . . . . . . . . . . .

132

4.23 wxGUI grafický modeler.

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

133

4.24 Datové bloky VFK související s geometrií prvků katastrální mapy. . . . . .

138

4.25 Logo projektu QGIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

142

4.26 Zásuvný modul QGIS pro práci s katastrálními daty. . . . . . . . . . . . . .

142

4.27 Vizualizace parcel digitální katastrální mapy. . . . . . . . . . . . . . . . . .

144

A.1 Simple Features Access: Třída Geometry. . . . . . . . . . . . . . . . . . . .

169

A.2 Simple Features Access: Třída GeometryCollection. . . . . . . . . . . . . . .

170

A.3 Simple Features Access: Třída Point. . . . . . . . . . . . . . . . . . . . . . .

170

A.4 Simple Features Access: Třída Curve a LineString. . . . . . . . . . . . . . .

171

A.5 Simple Features Access: Příklad objektu typu LineString. . . . . . . . . . .

171

A.6 Simple Features Access: Třída MultiCurve a MultiLineString. . . . . . . . .

172

A.7 Simple Features Access: Příklad objektu typu MultiLineString. . . . . . . .

172

A.8 Simple Features Access: Třída Surface. . . . . . . . . . . . . . . . . . . . . .

173

A.9 Simple Features Access: Třída Polygon. . . . . . . . . . . . . . . . . . . . .

173

A.10 Simple Features Access: Příklad objektu typu PolyhedralSurface. . . . . . .

174

A.11 Simple Features Access: Třída PolyhedralSurface. . . . . . . . . . . . . . . .

174

166

SEZNAM OBRÁZKŮ C.1 Příklad rozložení mnohostěnu na čtyřstěny (aplikace knihovny CGAL). . . .

187

D.1 UML diagram C++ tříd ovladače OGR-VFK. . . . . . . . . . . . . . . . . .

195

Seznam tabulek 1.1

Přehled skupin modulů systému GRASS. . . . . . . . . . . . . . . . . . . .

10

1.2

Vztah mezi objektovým modelem UML a daty ISO 19115. . . . . . . . . . .

54

1.3

Datové typy výměnného formátu ISKN. . . . . . . . . . . . . . . . . . . . .

57

2.1

Struktura nativního vektorového formátu GRASS verze 4 a 5. . . . . . . . .

60

2.2

Elementy datového modelu vektorové knihovny GRASS verze 5 a 6. . . . .

64

2.3

Struktura nativního vektorového formátu GRASS verze 6. . . . . . . . . . .

64

2.4

Topologický model GRASS verze 6: tabulka uzlů. . . . . . . . . . . . . . . .

66

2.5

Topologický model GRASS verze 6: tabulka topologických elementů. . . . .

67

2.6

Topologický model GRASS verze 6: tabulka ploch. . . . . . . . . . . . . . .

67

2.7

Topologický model GRASS verze 6: tabulka ostrovů. . . . . . . . . . . . . .

67

2.8

Popis hlavičkového souboru vektorových dat v nativním formátu GRASS. .

78

4.1

Porovnání topologických modelů GRASS a Topo-Geo. . . . . . . . . . . . .

109

4.2

Přehled dodatečných tabulek datového modelu GRASS. . . . . . . . . . . .

110

4.3

Vyjádření budovy jako mnohostěnu a množiny simplexů. . . . . . . . . . . .

120

4.4

Načítání dat výměnného formátu ISKN knihovnou OGR. . . . . . . . . . .

136

D.1 Hlavička výměnného formátu ISKN. . . . . . . . . . . . . . . . . . . . . . .

189

167

168

SEZNAM TABULEK

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

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 ∈ < | a ≤ t ≤ b} f : [a, b] →
(A.1)


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] →
(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]).

172


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).


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í.

174


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]).

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 1 2

n_lines 1 1

line 1 -1

line 1

type GV_BOUNDARY

type GV_BOUNDARY GV_BOUNDARY n1 1

n2 2

left 0

right 0

175

node 1 2

n_lines 1 1

line 1 -1

line 1

type GV_LINE

n1 1

type GV_LINE GV_LINE n2 2

left 0

right 0

176

PŘÍLOHA B: TOPOLOGIE 2D VEKTOROVÝCH DAT V SYSTÉMU GRASS 2.

node 1 2

n_lines 1 2

3

1

line 1 2

line 1 -2 -1 2

type GV_BOUNDARY GV_BOUNDARY

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY n1 1 3

n2 2 2

left 0 0

node 1 2

right 0 0

n_lines 1 2

3

1

line 1 2

type GV_LINE GV_LINE

line 1 -2 -1 2 n1 1 3

type GV_LINE GV_LINE GV_LINE GV_LINE n2 2 2

left 0 0

right 0 0


node 1

n_lines 2

2

2

3

2

line 3 1 -2 -1 2 -3

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY

line 1 2 3 4

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID

n1/area 1 3 1 1

area 1

n_lines 3

line 1,-2,-3

isle 1

n_lines 3

line -1,3,2

n2 2 2 3

n_isles 0 area 0

left -1 1 1

right 1 -1 -1

centroid 4

node 1

n_lines 2

line -1 1

type GV_BOUNDARY GV_BOUNDARY

line 1 2

type GV_BOUNDARY GV_CENTROID

area 1

n_lines 1

line 1

n_isles 0

isle 1

n_lines 1

line -1

area 0

n1/area 1 1

n2 1

left -1 centroid 2

right 1

177

178


node 1

n_lines 2

2

3

3

3

line 3 1 5 -2 -1 2 -5 -3

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY

line 1 2 3 4 5 6

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID

n1/area 1 3 1 1 2 2

n2 2 2 3

left -1 2 1

right 1 -1 -1

3

2

1

area 1 2

n_lines 3 2

line 1,5,-3 -2,-5

n_isles 0 0

isle 1

n_lines 3

line -1,3,2

area 0

centroid 4 6

node 1

n_lines 2

2

2

line -1 1 -3 3

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY

line 1 2 3 4

type GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID

n1/area 1 1 2 2

area 1 2

n_lines 1 1

line 1 3

n_isles 0 0

isle 1 2

n_lines 1 1

line -1 -3

area 0 0

n2 1

left -1

right 1

2

-2

2

centroid 2 4

PŘÍLOHA B: TOPOLOGIE 2D VEKTOROVÝCH DAT V SYSTÉMU GRASS

179

5.

node 1

n_lines 2

2

3

3

3

4

2

line 3 1 5 -7 -1 2 -5 -3 7 -2

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY

line 1 2 3 4 5 6 7

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID GV_BOUNDARY

n1/area 1 3 1 1 2 2 4

n2 2 4 3

left -1 2 1

right 1 -1 -1

3

2

1

2

2

-1

area 1 2

n_lines 3 3

line 1,5,-3 -2,-5,-7

n_isles 0 0

isle 1

n_lines 4

line -1,3,2,7

area 0

centroid 4 6

node 1

n_lines 2

2

2

line -1 1 -3 3

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY

line 1 2 3 4

type GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID

n1/area 1 1 2 2

area 1 2

n_lines 1 1

line 1 3

n_isles 0 0

isle 1 2

n_lines 1 1

line -1 -3

area 0 0

n2 1

left -1

right 1

2

-2

2

centroid 2 4

180


node 1

n_lines 2

2

4

3

3

4

3

line 3 1 5 -7 8 -1 2 -5 -3 -8 7 -2

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY

line 1 2 3 4 5 6 7 8 9

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_BOUNDARY GV_CENTROID

n1/area 1 3 1 1 2 2 4 2 3

n2 2 4 3

left -1 2 1

right 1 -1 -1

3

2

1

2 4

2 -1

3 3

area 1 2 3

n_lines 3 3 2

line 1,5,-3 -2,-5,-7 7,8

n_isles 0 0 0

isle 1

n_lines 4

line -1,3,2,-8

area 0

centroid 4 6 9

node 1

n_lines 2

2

4

line -1 1 -5 -3 5 3


line 1 2 3 4 5 6

type GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID

n1/area 1 1 2 2 2 3

area 1 2 3

n_lines 1 1 1

line 1 3 5

n_isles 0 0 0

isle 1 2 2

n_lines 1 1 1

line -1 -3 -5

area 0 0 0

n2 1

left -1

right 1

2

-2

2

2

-3

3

centroid 2 4 6


181

7.

node 1

n_lines 2

2

4

3

3

4

3

5

2

line 3 1 5 -7 8 -1 2 -5 -3 -10 7 -2 -8 10

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY

line 1 2 3 4 5 6 7 8 9 10

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_BOUNDARY GV_CENTROID GV_BOUNDARY

n1/area 1 3 1 1 2 2 4 3 3 5

area 1 2 3

n_lines 3 3 3

line 1,5,-3 -2,-5,-7 7,8,10

isle 1

n_lines 5

line -1,3,2,-10,-8

n2 2 4 3

left -1 2 1

right 1 -1 -1

3

2

1

2 5

2 -1

3 3

4

-1

3

n_isles 0 0 0 area 0

centroid 4 6 9

node 1

n_lines 2

2

4

line -1 1 -5 -3 5 3


line 1 2 3 4 5 6

type GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID

n1/area 1 1 2 2 2 3

area 1 2 3

n_lines 1 1 1

line 1 3 5

n_isles 0 0 0

isle 1 2 3

n_lines 1 1 1

line -1 -3 -5

area 0 0 0

n2 1

left -1

right 1

2

-2

2

2

-3

3

centroid 2 4 6

182


node 1

n_lines 2

2

4

3

4

4

3

5

3

line 3 1 5 -7 8 -1 11 2 -5 -3 -10 7 -2 -11 -8 10

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY

line 1 2 3 4 5 6 7 8 9 10 11 12

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_BOUNDARY GV_CENTROID

n1/area 1 3 1 1 2 2 4 2 4 5 3 3

area 1 2 3 4

n_lines 3 3 3 3

line 1,5,-3 -2,-5,-7 2,-10,-11 7,8,10

isle 1

n_lines 4

line -1,3,11,-8

n2 2 4 3

left -1 2 1

right 1 3 -1

3

2

1

2 5

2 -1

4 4

4 5

3 3

4 4

n_isles 0 0 0 0 area 0

centroid 4 6 12 9

node 1

n_lines 2

2

4

3

2

line -1 1 -7 -3 7 3 -5 5

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY

line 1 2 3 4 5 6 7 8

type GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID

n1/area 1 1 2 2 3 3 2 4

area 1 2 3 4

n_lines 1 1 1 1

line 1 3 5 7

n_isles 0 0 0 0

isle 1 2 3 4

n_lines 1 1 1 1

line -1 -3 -5 -7

area 0 0 0 0

n2 1

left -1

right 1

2

-2

2

3

-3

3

2

-4

4

centroid 2 4 6 8


183

9.

node 1

n_lines 2

2

4

3

4

4

3

5

3

6

3

line 3 1 5 -7 8 -1 11 2 -5 -3 -10 7 -2 -11 -8 10 13 -13

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY

line 1 2 3 4 5 6 7 8 9 10 11 12 13 14

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID

n1/area 1 3 1 1 2 2 4 2 4 5 3 3 6 5

area 1 2 3 4 5

n_lines 3 3 3 3 1

line 1,5,-3 -2,-5,-7 2,-10,-11 7,8,10 -13

isle 1 2

n_lines 4 1

line -1,3,11,-8 13

left -1 2 1

right 1 3 -1

3

2

1

2 5

2 -1

4 4

4 5

3 3

4 -1

6

5

-2

area 0 0

n_lines 2

2

4

3

2

4

4 4

n2 2 4 3

n_isles 0 0 0 0 0

node 1

centroid 4 6 12 9 14

line -1 1 -8 -3 8 3 -5 5 6 -10 -6 10

type GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY GV_BOUNDARY

line 1 2 3 4 5 6 7 8 9 10 11

type GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID GV_BOUNDARY GV_CENTROID

n1/area 1 1 2 2 3 4 3 2 5 4 6

area 1 2 3 4 5

n_lines 1 1 1 1 1

line 1 3 5 8 10

n_isles 0 0 0 0 0

isle 1 2 3 4 5

n_lines 1 1 1 1 1

line -1 -3 -5 -8 -10

area 0 0 0 0 0

n2 1

left -1

right 1

2

-2

2

3 4

-3 4

3 -4

2

-5

5

4

-6

6

centroid 2 4 7 9 11

184


Příloha C: Knihovna CGAL C.1 Ukázková aplikace pro 3D triangulaci Ukázková C++ aplikace je převzata z dokumentace knihovny CGAL [B36] a upravena pro účel této práce. Implementací 3D triangulace jako modulu pro systém GRASS se podrobněji zabývá kap. 4.3.2.3. Následuje stručný rozbor ukázkové aplikace. Nejprve jsou vloženy potřebné hlavičkové soubory a definovány pomocí příkazu typedef použité datové typy.

1 # include < iostream > 2 # include < cassert > 3 # include < vector > 4 5 # include < CGAL / E x a c t _ p r e d i c a t e s _ i n e x a c t _ c o n s t r u c t i o n s _ k e r n e l .h > 6 # include < CGAL / Triangulation_3 .h > 7 8 typedef CGAL :: E x a c t _ p r e d i c a t e s _ i n e x a c t _ c o n s t r u c t i o n s _ k e r n e l K ; 9 10 typedef CGAL :: Triangulation_3

Triangulation ;

11 12 typedef Triangulation :: Cell_handle 13 typedef Triangulation :: Vertex_handle 14 typedef Triangulation :: Locate_type 15 typedef Triangulation :: Point

Cell_handle ; Vertex_handle ; Locate_type ; Point ;

Jako vstupní body poslouží vrcholové body objektu budovy znázorněné na obr. 4.13. Nejprve je vytvořena instance standardního kontejneru typu vector (řádek 19). Do tohoto kontejneru jsou postupně přidávány vstupní body jako instance třídy Point (řádek 21). 185

186

PŘÍLOHA C: KNIHOVNA CGAL

16 int main () 17 { 18 19

// naplnit seznam bod ů ( budova ) std :: vector < Point > P ;

20 21 22 23 24

P . push_back ( Point (0 ,0 ,0) ) ; P . push_back ( Point (0 ,100 ,0) ) ; P . push_back ( Point (200 ,100 ,0) ) ; P . push_back ( Point (200 ,0 ,0) ) ;

25 26 27

P . push_back ( Point (200 ,100 ,100) ) ; P . push_back ( Point (0 ,100 ,100) ) ;

28 29 30


31 32 33


3D triangulace na základě seznamu vstupních bodů je provedena v rámci konstruktoru třídy Triangulation (řádek 35). 34 35

// prov é st 3 D triangulaci Triangulation T ( P . begin () , P . end () ) ;

Výsledek triangulace je otestován bodem o souřadnicích x = 0, y = 0, z = 0. Pomocí metody locate() je zjištěno (řádek 40), že jde o vrcholový bod vytvořené sítě (řádek 43). Metoda locate() vrací odkaz na související čtyřstěn c a index vrcholového bodu li v rámci daného čtyřstěnu. 36 37 38 39 40 41 42 43

// otestovat v ý sledek triangulace -- bod (0 ,0 ,0) Locate_type lt ; int li , lj ; Point p (0 ,0 ,0) ; Cell_handle c = T . locate (p , lt , li , lj ) ; // p je lomov ý m bodem č ty ř st ě nu c s indexem li : assert ( lt == Triangulation :: VERTEX ) ; assert (c - > vertex ( li ) -> point () == p ) ;

Dále je otestován v pořadí následující vrcholový bod v čtyřstěnu c (řádek 45). Pomocí metody neighbor() je zjištěn sousedící čtyřstěn nc (řádek 47) a je otestováno, zda daný vrcholový bod v definuje čtyřstěn nc (řádek 53).


44

// otestovat n á sleduj í c í lomov ý bod č ty ř st ě nu Vertex_handle v = c - > vertex (( li +1) & 3) ; // v je jedn í m z dal š í ch lomov ý ch bod ů č ty ř st ě nu c Cell_handle nc = c - > neighbor ( li ) ; // nc je sousedem č ty ř st ě nu c sm ě rem proti lomov é mu bodu // asociovan é mu s p

45 46 47 48 49 50 51

// nc mus í obsahovat lomov ý bod v : int nli ; assert ( nc - > has_vertex (v , nli ) ) ; // nli je index lomov é ho bodu v nc

52 53 54

Na závěr je výsledek triangulace vypsán (řádek 57) na standardní výstup. 55

// vypsat v ý sledek 3 D triangulace na standardn í v ý stup std :: cout << " Number of vertices : " << T . nu mb er _o f_ ve rt ic es () << std :: endl ; std :: cout << " Number of edges : " << T . n u m b e r _ o f _ f i n i t e _ e d g e s () << std :: endl ; std :: cout << " Number of triangles : " << T . n u m b e r _ o f _ f i n i t e _ f a c e t s () << std :: endl ; std :: cout << " Number of tetrahedrons : " << T . n u m b e r _ o f _ f i n i t e _ c e l l s () << std :: endl ; return 0;

56 57 58 59 60 61 62 63 64 65 }

Výstup testovací aplikace v našem případě vypadá následovně: Number Number Number Number

of of of of

vertices: 10 edges: 28 triangles: 30 tetrahedrons: 11

Hrany vytvoření sítě jsou znázorněny na obr. C.1.

Obrázek C.1: Rozložení mnohostěnu na síť nepravidelných čtyřstěnů (autor: Martin Landa, 2013).

187

188


Příloha D: Podpora výměnného formátu ISKN v knihovně OGR D.1 Hlavička výměnného formátu ISKN Tabulka D.1: Hlavička výměnného formátu ISKN. klíč

popis

VERZE

označení verze VF

VYTVORENO

datum a čas vytvoření souboru

PUVOD

původ dat

CODEPAGE

označení kódové stránky

SKUPINA

seznam skupin datových bloků souboru

JMENO

jméno osoby, která soubor vytvořila

PLATNOST

časová podmínka použita pro vytvoření souboru

KATUZE

omezující podmínka – katastrální území

OPSUB

omezující podmínka – oprávněné subjekty

PAR

omezující podmínka – parcely

POLYG

omezující podmínka – polygon

D.2 Skupiny datových bloků Nemovitosti Skupina nemovitostí obsahuje informace o parcelách, budovách, jejich využití, způsobech ochrany a uzemní identifikaci. • PAR – parcely (tj. pozemek, který je geometricky a polohově určen) a obsahuje informace jako např. kód katastrálního území, číslo parcely, její druh a způsob využití 189

190

PŘÍLOHA D: PODPORA VF ISKN V KNIHOVNĚ OGR • BUD – informace o budovách (číslo budovy, odkaz na parcelu, způsob využití) • CABU – části budov označené čísly popisnými, pokud byly sloučeny do jedné budovy • ZPOCHN – číselník způsobu ochrany nemovitostí • DRUPOZ – číselník druhu pozemků • ZPVYPO – číselník druhu způsobu využití pozemku • ZDPAZE – číselník zdroje evidence parcel v půdních celcích • ZPURVY – číselník způsobu určení výměry parcely • TYPBUD – číselník typu budov • MAPLIS – číselník mapových listů katastrálních map • KATUZE – číselník katastrálních území • OBCE – číselník obcí ČR • CASOBC – číselník částí obcí ČR • OKRESY – číselník okresů • KRAJE – číselník krajů • NKRAJE – číselník nových krajů • RZO – vazební blok přiřazující způsob ochrany nemovitostí ke konkrétní parcele, budově nebo jednotce • ZPVYPU – číselník způsobu využití budov

Jednotky Informace o jednotkách, jejich typ a způsob využití. • JED – informace o jednotkách (bytový, nebytový prostor vyčleněný jako jednotka) • TYPJED – číselník typů bytových a nebytových prostor • ZPVYJE – číselník způsobů ochrany nemovitostí

Bonitní díly parcel • BDP – informace o bonitních dílech parcely

PŘÍLOHA D: PODPORA VF ISKN V KNIHOVNĚ OGR

191

Vlastnictví Informace o oprávněných subjektech a jejich vlastnictví. • OPSUB – fyzická nebo právnická osoba jako vlastník nebo jiný oprávněný subjekt • VLA – vlastnický vztah jednotlivých oprávněných osob k nemovitostem • CHAROS – číselník charakteristiky oprávněného subjektu • TEL – listy vlastnictví

Jiné právní vztahy Informace o JPV a číselníky typů právních vztahů. • JPV – jiný právní vztah, jiný než vlastnický vztah jednoho subjektu k jednomu předmětu • TYPPRAV – číselník typů právních vztahů (např. vlastnictví, věcné břemeno, právo trvalého užívání)

Řízení Informace o řízení, listiny, přiřazení listin k nemovitostem a oprávněným subjektům. • RIZENI – hlavička řízení • RIZKU – vazební blok vztahu řízení ke katastrálnímu území • OBJRIZ – objekty řízení (nemovitost účastná řízení) • PRERIZ – předměty řízení • UCAST – účastníci řízení (fyzické nebo právnické osoby dotčené příslušným řízením) • ADRUC – adresa účastníka řízení • LISTIN – listiny řízení • DUL – číselník dalších údajů k listině • LDU – vazební blok listinou a dalšími údaji listiny • TYPLIS – číselník typů listin • TYPPRE – číselník typů předmětů řízení

192

PŘÍLOHA D: PODPORA VF ISKN V KNIHOVNĚ OGR • TYPRIZ – číselník typu řízení • TYPUCA – číselník typu účastníka řízení • UCTYP – vazební blok mezi účastníky řízení a blokem TYPUCA • RL – vazební blok mezi nemovitostmi a vlastnictvím • OBESMF – údaje o obeslání v rámci definovaných operací

Prvky katastrální mapy • SOBR – body polohopisu • SBP – vazba mezi podrobnými body, jejichž spojením vzniká liniový polohopisný prvek • SBM – vazba mezi body, jejichž spojením vzniká liniový nepolohopisný prvek • KODCHB – číselník kódu charakteristiky kvality bodu • TYPSOS – číselník souřadnicových systémů • HP – hranice parcel, které představuje liniový polohopisný prvek • OP – obrazy parcel • OB – obrazy budov • DPM – polohopisné prvky katastrální mapy, které nezobrazují popisné údaje katastru • OBBP – body polohových polí • TYPPPD – číselník prvků katastrální mapy • ZVB – grafické vyjádření rozsahu práva, která omezuje vlastníka pozemku ve prospěch jiného • POM – exportovaná data prvků orientační mapy • SPOM – exportovaná data prvků orientační mapy

BPEJ Bonitované půdně ekologické jednotky jsou základními oceňovanými jednotkami zemědělských půd. Vyjadřují rozdílné produkční a ekonomické efekty zemědělského území. • HPBEJ – liniový prvek, který tvoří rozhraní mezi dvěma různými BPEJ • OBPEJ – označení BPEJ, textový popisný prvek, který vyjadřuje hodnotu kódu BPEJ


193

Geometrický plán Hlavička geometrického plánu. • NZ – návrh změn • ZPMZ – záznam podrobného měření změn • NZZP – vazební blok mezi návrhem změn a ZPMZ • SPOL – souřadnice polohy, body polohopisu

Rezervovaná čísla • RECI – rezervovaná čísla parcel (tj. parcelní čísla rezervovaná pro účely vyhotovení geometrického plánu) • DOCI – dotčená parcelní čísla (tj. parcelní čísla, která byla použita za dobu elektronického vedení katastru nemovitostí) • DOHICI – parcelní čísla, která byla použita za dobu elektronického vedení katastru • REZBP – rezervovaná čísla pro PBPP, která přísluší k exportovanému katastrálním území

Definiční body • OBDEBO – obrazy definičních bodů

Adresní místa • BUDOBJ – vazební blok mezi budovami a adresami • ADROBJ – odkazy na adresy budov, které jsou obsaženy v bloku nemovitostí

Návrhy změn • NZML – vazební blok přiřazující mapové listy k návrhům změn • NZU – vazební blok přiřazující kódy typu účelu návrhu změny k návrhu změny

194


D.3 Přehled OGR-VFK vrstev typ prvku v topologickém modelu

typ prvku v modelu SFA

SOBR OBBP SPOL

uzel uzel uzel

Point Point Point

body polohopisu body polohových polí souřadnice polohy, body polohopisu

OP OB OBPEJ

centroid centroid centroid

Point Point Point

obrazy parcel obrazy budov označení BPEJ

SBP

linie

LineString

SBM

linie

LineString

DPM

linie

LineString

spojení bodů polohopisu (polohopisné liniové prvky) spojení bodů mapy (nepolohopisné liniové prvky) polohopisné prvky katastrální mapy, které nezobrazují popisné údaje katastru

hraniční linie

LinearRing

hranice parcel

plocha plocha

Polygon Polygon

parcely budovy

datový blok VFK

HP PAR BUD

popisek


D.4 UML diagram C++ tříd ovladače VFK

Obrázek D.1: UML diagram C++ tříd ovladače VFK knihovny OGR (autor: Martin Landa, 2012).

195

196


D.5 Ukázková aplikace Programovací jazyk C++ Níže uvedená ukázková aplikace má za cíl určit počet prvků z datové vrstvy parcel (datový blok PAR) odpovídající zadané atributové podmínce: výměra parcely větší než 5ha. Zdrojový kód C++ je omezen pouze na názornou ukázku. Není ošetřen uživatelský vstup či chybové stavy, které mohou nastat při otevření OGR datového zdroje či datové vrstvy. Příklad výstupu ukázkové aplikace: Pocet parcel s vymerou vetsi nez 5ha: 12

1 # include < iostream > 2 # include < sstream > 3 # include " ogrsf_frmts . h " 4 5 int main () 6 { 7 8

double max_area ; std :: ostringstream attrb_filter ;

// limitn í v ý m ě ra parcel

9 10 11

OGRDataSource OGRLayer

* poDS ; * poLayer ;

12 13 14

// nastavit limit na 5 ha max_area = 5.;

15 16 17

// registrovat v š echny dostupn é ovlada č e knihovny OGR OGRRegisterAll () ;

18 19 20 21

/* otev ř í t OGR data source druh ý argument ur č uje re ž im č ten í */ poDS = O G R S F D r i v e r R e g i s t r a r :: Open ( " data . vfk " , FALSE ) ;

22 23 24

// na č í st OGR vrstvu s n á zvem ’ PAR ’ poLayer = poDS - > GetLayerByName ( " PAR " ) ;

25 26 27 28

// nastavit atributov ý filter - maxim á ln í v ý m ě ru parcely attrb_filter << " VYMERA_PARCELY > " << max_area * 1 e4 ; poLayer - > Se tA tt ri bu te Fi lt er ( attrb_filter . str () . c_str () ) ;

29 30 31

/* vypsat po č et prvk ů ( tj . parcel ) odpov í daj í c í ch atributov é podm í nce */

PŘÍLOHA D: PODPORA VF ISKN V KNIHOVNĚ OGR 32

197

std :: cout << " Pocet parcel s vymerou vetsi nez " << max_area << " ha : " << poLayer - > GetFeatureCount () << std :: endl ;

33 34 }

Programovací jazyk Python Níže uvedená jednoduchá aplikace je implementována v programovacím jazyce Python s cílem demonstrace přístupu k datům výměnného formátu ISKN pomocí Python rozhraní knihovny OGR. Uvedená aplikace porovná výměru parcely uvedené v atributové složce dat a vypočtené výměry jako obsahu polygonu parcely. Příklad výstupu ukázkové aplikace: 1319119210 1319120210 1319121210 ...

725 207 207

725.4 206.6 206.6

-0.4 0.4 0.4

1 # !/ usr / bin / env python 2 # -* - coding : utf -8 -* 3 4 """ 5 Tento skript porovn á zn á m é a vypo č ten é v ý m ě ry parcel a v ý sledek 6 vytiskne v podob ě p ř ehledn é tabulky . 7 8 parceln í č í slo | znam á vym ě ra | vypo č ten á v ý m ě ra | rozd í l v ý m ě r ( m ^2) 9 """ 10 11 import sys 12 13 import ogr 14 15 def usage () : 16

print >> sys . stderr , __doc__

17 18 def open_ds ( filename ) : 19 20

""" Otev ř í t OGR datov ý zdroj ( soubor ve form á tu VFK ) """ ds = ogr . Open ( filename )

21 22 23 24 25

if ds is None : print >> sys . stderr , ’ Nelze otev ř í t OGR datasource "% s " ’ % \ filename

198 26

PŘÍLOHA D: PODPORA VF ISKN V KNIHOVNĚ OGR return ds

27 28 def get_layer_par ( ds ) : 29 30

""" Z í skat OGR vrstvu ’ PAR ’ """ layer = ds . GetLayer ( ’ PAR ’)

31 32 33

if layer is None : print >> sys . stderr , ’ Nelze na č í st OGR vrstvu " PAR " ’

34 35

return layer

36 37 def read_feat_par ( layer ) : 38 39

""" Na č í st prvky z OGR vrstvy ’ PAR ’ """ tab = list ()

40 41 42 43 44

defn = layer . GetLayerDefn () if defn is None : print >> sys . stderr , ’ Nelze z í skat informace o vrstv ě ’ return -1

45 46 47

idx_id = defn . GetFieldIndex ( " ID " ) idx_area = defn . GetFieldIndex ( " VYMERA_PARCELY " )

48 49 50 51 52 53

layer . ResetReading () while True : feat = layer . GetNextFeature () if feat is None : break

54 55 56

pc = feat . Ge tField AsInte ger ( idx_id ) area = feat . Ge tField AsInt eger ( idx_area )

57 58 59 60 61 62

geom = feat . GetGeometryRef () if geom is None : area_comp = -1 else : area_comp = geom . GetArea ()

63 64

tab . append (( pc , area , area_comp ) )

65 66

return tab

67 68 def print_tab ( tab ) : 69 70

""" Vytisknout tabulku s v ý sledkem """ for pc , area_attrb , area_comp in tab :

PŘÍLOHA D: PODPORA VF ISKN V KNIHOVNĚ OGR 71 72

print ’% d %10 d %10.1 f %5.1 f ’ % ( pc , area_attrb , area_comp , area_attrb - area_comp )

73 74 def main () : 75 76 77

if len ( sys . argv ) != 2: usage () return 0

78 79 80 81

ds = open_ds ( sys . argv [1]) if ds is None : return 1

82 83 84 85

layer_par = get_layer_par ( ds ) if layer_par is None : return 1

86 87 88 89

tab = read_feat_par ( layer_par ) if tab == -1: return 1

90 91

print_tab ( tab )

92 93

ds . Destroy ()

199

200


Příloha E: Obsah přiloženého CD Struktura adresářů přiloženého CD: / models/ ........................ Modely GXM pro wxGUI grafický modeler poster/ ........................ Poster src/ ........................... Zdrojové kódy grass/ ...................... GRASS GIS verze 7 gui/wxpython/ ........... wxGUI lib/vector/Vlib/........ Vektorová knihovna lib/vector/VEdit/....... Knihovna VEdit vector/.................. Vektorové nástroje systému GRASS gdal-ogr/................... Knihovna GDAL/OGR ogr/ogrsf_frmts/vfk/ ... Ovladač VFK knihovny OGR text/ .......................... Text disertační práce v LATEXu code-samples/ .............. Ukázky zdrojového kódu v textu figures/.................... Obrázky použité v textu práce teze/ .......................... Teze disertační práce v LATEXu figures/.................... Obrázky použité v tezích disertační práce workspaces/.................... Soubory projektů GXW pro wxGUI

201

202

PŘÍLOHA E: OBSAH PŘILOŽENÉHO CD

Vektorová architektura systému GRASS GIS

Recommend Documents