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

Transkript

1 České vysoké učení technické v Praze Fakulta stavební Katedra mapování a kartografie Doktorská disertační práce Geodata a metadata ISKN v prostředí INSPIRE 29. listopadu 2010 Ing. Jiří Bartoš

2 České vysoké učení technické v Praze Fakulta stavební Katedra mapování a kartografie Ing. Jiří Bartoš Geodata a metadata ISKN v prostředí INSPIRE Geodata and metadata of ISCRE in INSPIRE environment Disertační práce k získání akademického titulu Ph.D. Doktorský studijní program: Geodézie a kartografie Studijní obor: Geodézie a kartografie Školitel: Prof. Ing. Aleš Čepek, CSc. Praha, 29. listopadu 2010

3 PROHLÁŠENÍ Prohlášení Prohlašuji tímto, že tuto práci jsem vypracoval samostatně, s použitím odborné literatury a dostupných pramenú uvedených v seznamu, jenž je součástí této práce. V Praze dne 29. listopadu 2010 Ing. Jiří Bartoš Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE i

4 PODĚKOVÁNÍ Poděkování V první řadě bych chtěl poděkovat svému vynikajícímu školiteli prof. Ing. Alešovi Čepkovi, CSc. především za důvěru a s ní spojenou volnost, které se mi při vypracování této disertační práce dostalo. Dále bych chtěl poděkovat své rodině za veškerou podporu v průběhu celého studia. V neposlední řadě bych chtěl poděkovat všem současným i minulým zaměstnancům sekce centrální databáze ČÚZK, kteří mi vždy ochotně poradili a pomohli. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE ii

5 Summary The doctoral thesis deals with testing of INSPIRE data specification on Czech Real Estate data. Within the scope of this thesis a complete system publication database was designed and developed. This system is being used for both: national web mapping services and INSPIRE services (Discovering, Viewing, Downloading). The subsystem that keeps data in accord with ISCRE (Informational System of Czech Real Estate) is also part of this thesis. Others extensions created by the author of this thesis are: An Subsystem for searching different errors in source database (ISCRE) and other subsystem that brings support for incoming data (future state of Real Estate). Extensions of others authors are also mentioned at the end of this thesis. Resumé Disertační práce se zabývá testováním INSPIRE datových specifikací na datech katastru nemovitostí. V rámci této práce byl navržen a realizován systém publikační databáze, který slouží jako zdroj dat pro poskytování národních webových mapových služeb, tak i služeb INSPIRE (vyhledávací, prohlížecí, stahovací). Součástí tohoto nového systému je subsystém, který udržuje tento systém v souladu s aktualizacemi centrální databáze ISKN. Dále je systém autorem rozšířen o funkcionalitu hledání různých typů chyb ve zdrojové databázi a subsystém umožňující práci s budoucím stavem. Součástí práce je též ukázka systémů jiných autorů, které pracují s daty tohoto nového systému. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE iii

6 OBSAH Obsah 1 Úvod 1 2 INSPIRE INSPIRE směrnice Prováděcí pravidla Metadata Specifikace dat Vyhledávací služba Prohlížecí služba Služba stahování dat Transformační služba Další služby Sdílení dat Monitoring a reporting Infrastruktura Datová specifikace Generický konceptuální model Práce s proměnnými no data Správa identifikátorů Životní cyklus prvků Podpora mnohojazyčnosti Základní typ SpatialDataSet Téma Geografické názvy (GN) Typ prvku Pojmenované místo (Named Place) Datový prvek Geografické jméno (Geographical Name) Téma Katastrální Parcely (CP) Typ prvek Katastrální parcela (CadastralParcel) Typ prvku Katastrální členění (Cadastral Zoning) Typ prvek Katastrální hranice (Cadastral Boundary) Typ prvek Základní jednotka vlastnictví (BasicPropertyUnit) Téma Adresy (AD) Typ prvku Adresa (Address) Typ prvku Komponenta adresy (AddressComponent) Typ prvku Lokalita adres (AddressAreaName) Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE iv

7 OBSAH Typ prvku Jméno administrativní jednotky (AdminUnitName) Typ prvku Odkaz na Poštu (Postal Descriptor) Typ prvku Jméno komunikace (Throughfare name) Datový prvek Položka adresy (AddressLocator) Datový typ Položka označení (LocatorDesignator) Datový typ Položka jméno (LocatorName) Téma Administrativní jednotky (AU) Prvek Administrativní jednotka (Administrative Unit) Prvek Administrativní hranice (Administrative Boundary) Typ prvku Kondominium (Condominium) Metadata datových sad Metadata společná všem tématům Povinná a podmíněná metadata pro témata CP, AU, AD a GN Volitelná metadata přidaná k jednotlivým tématům Geography Markup Language Stereotyp «voidable» Jednotlivé příklady INSPIRE versus GML identifikátory Reprezentace geometrie Prostorová topologie Časová topologie GML versus INSPIRE zásobníky Datové sady a systémy ČÚZK v prostředí INSPIRE ISKN RÚIAN ZABAGED a jiná data ZÚ Testování datové specifikace Testování prvního a druhého návrhu Ukázka aplikačního testování Testovací architektura Testování třetího návrhu Téma Katastrální parcely Téma Adresy Téma Administrativní jednotky Testování v jiných státech Postupné budování INSPIRE prostorové databáze (SK) Export z prostorové databáze (ES) Návrh publikační databáze Publikační databáze na SCD ČÚZK PUB-DB v infrastruktuře ČÚZK Návrh PUB-DB Schéma PUB-DB Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE v

8 OBSAH 7.5 Procesy v PUB-DB Konverze dat ISKN do PUB-DB Další prvky mapy Konverze textů a značek DPM Konverze přímých grafických prvků DPM Konverze DPM vzniklých spojením bodů polohopisu Konverze parcely KN s geometrií Konverze drobných geometrických prvků Konverze definičního bodu Konverze parcelních šipek a parcelních čísel Konverze značek Konverze geometrie hranic parcely Poznámky k použitým algoritmům Tvorba geometrie parcely KN Reprezentace kružnic pomocí liniových řetězců Transformace do ETRS Systém obarvování hranic parcel Definice přesnosti hranic v PUB-DB Přesnost bodu hranice Zlepšení přesnosti bodu Pravidla tvorby hranic parcel v publikační databázi Implementace Změna přesnosti bodu daná kódem kvality výměry Změna přesnosti bodu na přímce Ověření Kontrola výlučné přesnosti Kontrola existence přesnosti Další kontroly Migrace schématu ISKN do struktury Publikační databáze Předpoklady migrace Kroky migrace Krok Krok 2a Krok 2b Krok Krok Krok Výpočet ZMĚN nad PUB-DB Procedura zmeny_job_rastery Procedura zmeny_spocti_iskn2pub Výpočet oprav Oprava dat na základě časového intervalu Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE vi

9 OBSAH Oprava dat na základě výčtu k.ú. nebo KP Statistiky Chyby ISKN a jejich přenos do PUB-DB Chyby geometrie Duplicitní body Lichá křížení Volné konce (Stopky) Pevná lichá křížení (Stopky/Linie navíc) Prázdné polygony Duplicitní linie (Třísky) Prázdné polygony (Třísky) Prázdné spojené polygony (Dvojtřísky) Nevalidní geometrie Křížení linií parcel (Smyčky) Chyby přesnosti parcel (Výběžky) Další chyby parcel Pouze zmenšené parcelní číslo Samostatný volný konec šipky parcely Chybějící/Duplicitní definiční bod Chyby geometrie budov Negeometrické chyby Neexistující PAR_ID Špatný KATUZE_KOD Další chyby Opravy chyb Obnova operátu (Námitkové řízení) Import dat do databáze Databázové schéma PUB-DB Operace nad PUB-DB Systémy a práce pracující s daty PUB-DB Nahlížení do KN Metadata Geoportálu ČÚZK Generování INSPIRE GML Export dat PUB-DB do SHP: Diplomová práce Ing. Kateřina Šmídová Export katastrálních hranic z PUB-DB do DGN: Bc. Jiří Novák Kontroly dalších prvků map: Bakalářská práce Bc. Adéla Volfová Vektorizace masek rastrů KN: Diplomová práce Bc. David Legner Závěr Vlastní řešení Další vývoj Reference 169 Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE vii

10 SEZNAM OBRÁZKŮ Seznam obrázků 2.1 Metadata ISO, INSPIRE a metadatový profil Inspire služby Služba stahování celých datasetů Služba stahování s přímým přístupem Národní infrastruktura Vývojový rámec pro tvoru INSPIRE témat (Zdroj [7]) GCM jako základ INSPIRE aplikačních schémat (Zdroj [7]) Postupný vznik prvků Hromadný vznik prvků INSPIRE SpatialDataSet Schéma Geografické Názvy (Zdroj [6]) Pojmenované místo (Zdroj [6]) Geografické jméno (Zdroj [13]) Schéma tématu Katastrální parcely (Zdroj [12]) Prvek Katastrální parcela (Zdroj [12]) Prvek Katastrální členění (Zdroj [12]) Prvek Katastrální hranice (Zdroj [12]) Prvek Základní jednotka vlastnictví (Zdroj [12]) Prvek Adresa (Zdroj [10]) Prvek Komponenta adresy (Zdroj [10]) Prvek Lokalita Adres (Zdroj [10]) Prvek Jméno admin. jednotky (Zdroj [10]) Prvek Odkaz na Poštu (Zdroj [10]) Prvek Jméno komunikace (Zdroj [10]) Prvek Položka adresy (Zdroj [10]) Datový typ Položka označení (Zdroj [10]) Prvek Položka jméno (Zdroj [10]) Schéma Administrativní jednotky (Zdroj [11]) Prvek Administrativní jednotka (Zdroj [11]) Prvek Administrativní hranice (Zdroj [11]) Prvek Kondominium (Zdroj [11]) Topologické chyby Možné reprezentace topologické plochy se dvěma hranami Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE viii

11 SEZNAM OBRÁZKŮ 4.2 GML FeatureColection INSPIRE SpatialDataSet Systém ISKN Základní systémy státní správy Základní systémy státní správy Testování jako součást vývoje datové specifikace Průběh DKM na Česko-Slovenské hranici Testování druhého návrhu: k.ú. Sudoměřice Testování druhého návrhu: detail Průběh Česko-slovenské hranice Nesoulad na Česko-Slovenské hranici Architektura testování prvního návrhu Architektura: Testování třetího návrhu Testování třetího návrhu: k.ú. Bylany Publikování pomocí Snowflake GoPublisher CE ISÚI - Adresy ISÚI Administrativní jednotky - datová architektura (Zdroj: [2]) Slovensko - testování Španělsko 1: Mapování generického GML do INSPIRE DS (Zdroj: [28]) Španělsko 2: Mapování generického GML do INSPIRE DS (Zdroj: [28]) Publikační databáze - služby Publikační databáze - infrastruktura Publikační databáze - schéma Další prvky mapy Tabulky ISKN tvořící další prvky mapy Grafická reprezentace uživatelské geometrie Parcely v ISKN Atributy parcely KN ISKN drobné geometrické prvky parcel Parcelní šipky a parcelní čísla ISKN geometrie hranic parcel KN Výpočet geometrie parcely KN V současnosti neřešitelná topologická uspořádání Počet kroků potřebných k vyřešení topologie parcely Různé způsoby převodu kruhového oblouku Chyba na styku dvou kruhových oblouků Orientace kruhových oblouků při převodu na linie Prostorový rámec všech dat ČÚZK pro metadata Změna přesnosti na přímce Změna přesnosti způsobená kódem kvality výměry Kontroly přesností linií v PUB-DB Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE ix

12 SEZNAM OBRÁZKŮ 10.1 Schéma migrace Konverze v PUB-DB Update prvků orientační mapy Schéma výpočtu ZMĚN Hranice schématu ISKN a PUBL vstupující do výpočtu nové geometrie parcel Ukázka změny geometrie parcel v rámci jednoho výpočtu ZMĚN Nepřímá změna hranice v ISKN způsobená změnou spojení bodů polohopisu Výpočet ZMĚN na hranici katastrálního pracoviště Volné konce Pevná lichá křížení Duplicitní linie Prázdné polygony Prázdné spojené polygony Hranice parcel v PUB-DB a dle ISO Křížení linií parcel Chyby přesnosti parcel Šipky parcel a jejich chyby Validní budovy Schéma importu budoucnosti Schéma tabulek PUB-DB reprezentující budoucnost Ukázka obnovy operátu Původní a nové (svrchní) Nahlížení do KN Ukázka vyhledávání na novém Geoportálu ČÚZK Zdroje metadat ČÚZK Volby implementace služby stahování celých datových sad Ukázka exportu dat PUB-DB do formátu ESRI Shapefile Export z PUB-DB do formátu Microstation DGN v Umístění dalších prvků mapy mimo hranici k.ú. (Zdroj: [30, strana 60]) Vektorizace masek rastrů Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE x

13 Kapitola 1. Úvod Kapitola 1 Úvod V září roku 2008 jsem se stal, díky svému částečnému úvazku v sekci centrální databáze Českého úřadu zeměměřického a katastrálního v Praze (ČÚZK-SCD), jedním z členů testovacího týmu datové specifikace INSPIRE v rámci tohoto úřadu. Přestože se ČÚZK v té době již projektem INSPIRE (INfrastructure for SPatial InfoRmation in Europe) zabýval déle než tři roky, byl na jakékoliv testování i na příchod samotné datové specifikace velmi špatně připraven, jak po stránce potřebného vybavení, tak i po stránce personálního zajištění. Tyto problémy se pak plně projevily cca jeden měsíc po začátku testování. Proto byla vzhledem k rozsahu a časovému harmonogramu testování dohodnuta spolupráce mezi SCD a ČVUT-FSv, kdy mi bylo po konzultaci s vedoucím disertační práce změněno téma disertační práce z problematiky řídkých matic na problematiku INSPIRE. Cíle této spolupráce je možné shrnout do bodů: Testování INSPIRE datové specifikace tématu Katastrální parcely z dat ISKN (Informační systém katastru nemovitostí). Závěry tohoto testování neslouží pouze k předání do JRC (Join Research Center), ale i jako podklady pro tvorbu nového systému viz druhý bod. Podílení se na návrhu a implementaci tzv. publikační databáze. Vzhledem k rozsahu projektu se mám samostatně zabývat problematikou spojenou s INSPIRE a ve spolupráci s dalšími kolegy i problematikou nového Nahlížení do KN. Implementací se rozumí vytvoření a naplnění nově vzniklého databázového schématu příslušným daty ISKN a průběžná aktualizace těchto dat. Součástí této implementace je i ověření snadného získávání dat INSPIRE z této databáze. Spolupráce při vytěžování dat publikační databáze a jejího rozšiřování. Pod tento bod lze začlenit poměrně různorodou činnost. Příkladem rozšíření publikační databáze (PUB-DB) může být doplnění PUB-PB pro potřeby nové funkcionality Obnova operátu nového Nahlížení do KN. Příkladem vytěžování pak spolupráce při odstraňování chyb v ISKN. Tyto body se promítly do mé disertační práce. Druhá kapitola této práce pojednává o samotném projektu (iniciativě) INSPIRE. Třetí kapitola se zabývá datovou specifikací IN- SPIRE témat, která byla pro potřeby SCD testována. Nejdůležitějším tématem je zde téma Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 1

14 Kapitola 1. Úvod Katastrální parcely, ostatní témata jsou pak do značné míry podpůrná. Témata Adresy a Administrativní jednotky je možné teoreticky zahrnout do třetího bodu spolupráce (rozšiřování publikační databáze), kdy se zvažuje použití stejného mechanismu publikace jako pro téma Katastrální parcely. Proto jsou právě tato témata zařazena do této práce. Čtvrtá kapitola pojednává o jazyku GML (Geography Markup Language), který je použit pro fyzický zápis dat dle INSPIRE datových specifikací. Pátá kapitola je o zdrojích dat na ČÚZK. Na ni navazuje šestá kapitola, kde jsou data těchto systémů testována pro potřeby poskytování dat dle příslušných INSPIRE datových specifikací. Sedmá kapitola představuje nový systém nazvaný publikační databáze. Další kapitoly se zabývají vybranými aspekty tohoto nového systému. Osmá kapitola pojednává o způsobu, jakým lze mapovat/převádět data z ISKN do schématu PUBL publikační databáze, devátá kapitola se zabývá přesností hranic parcel v publikační databázi. Desátá kapitola popisuje konverzi všech stávajících dat ISKN do schématu PUBL v publikační databázi, kapitola jedenáctá pak pouze konverzi inkrementálních přírůstků ISKN. Dvanáctá kapitola pojednává o chybách ISKN a jejich přenosu do publikační databáze. Třináctá kapitola představuje rozšíření publikační databáze o novou funkcionalitu Obnova operátu pro potřeby nového Nahlížení do KN. Poslední čtrnáctá kapitola obsahuje ukázky dalších systémů a prací jiných autorů, kteří pracují s daty publikační databáze. Tato skutečnost je do značné míry ojedinělá, kdy je část ještě nedokončené disertační práce použita jako platforma pro bakalářské a diplomové práce studentů. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 2

15 Kapitola 2. INSPIRE Kapitola 2 INSPIRE 2.1 INSPIRE směrnice INSPIRE (INfrastructure for SPatial InfoRmation in Europe) je iniciativou Evropské komise na vytvoření společné infrastruktury prostorových dat v Evropě. Z pohledu Evropské komise je INSPIRE reprezentován směrnicí a množinou jejích prováděcích pravidel. Cílem směrnice INSPIRE je zlepšit dostupnost prostorových dat v rámci EU tím, že bude navržen společný výměnný formát (protokol) dat a sada služeb, která bude příslušná data v tomto formátu poskytovat. Směrnice INSPIRE vešla v platnost 15. května 2007 a byla postupně transponována do právního řádu jednotlivých států (V ČR zákon č. 380/2009 Sb.). INSPIRE je založen na následujících principech: Data jsou shromažďována pouze jednou a to na místě, kde je to nejvíce efektivní. Možnost kombinovat jednotlivé prostorové informace z různých zdrojů v rámci celé Evropy a sdílet je s mnoha uživateli a aplikacemi. Možnost sdílet prostorová data, která jsou vytvořená na jedné úrovni státní správy, na jejích dalších úrovních. Geografická data, která jsou potřeba pro rozhodování státní správy na všech úrovních, by měla být snadno dostupná a za jasných podmínek. Snadná vyhledatelnost dostupných dat, vyhledání vhodnosti pro daný účel a podmínek jejich poskytnutí. Spolu se směrnicí vznikl plán její postupné implementace, přičemž úplná implementace se očekává v roce Plán implementace je rozdělen na jednotlivá prováděcí pravidla. Vytvořením jednotlivých prováděcích pravidel se zabývají tzv. Návrhové týmy Drafting Teams, které jsou složeny z odborníků z různých zemí. Tito odborníci jsou na své pozice navrženi SDIC (Spatial Data Interest Communities, tedy organizace/sdružení zabývající se prostorovými daty) a LMO (Legally Mandated Organisation, tedy právně pověřené organizace; většinou se jedná o budoucí povinné poskytovatele) z jednotlivých států a vybráni Evropskou komisí. Tyto týmy navrhují podobu datových či jiných prováděcích Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 3

16 Kapitola 2. INSPIRE pravidel. Týmy při své práci vycházejí ze společného konceptuálního modelu. Následně jsou návrhy testovány nebo pouze připomínkovány v členských státech držiteli dat nebo jinými organizacemi (je nutné poznamenat, že testování je dobrovolné). Na konci testování dojde ke zhodnocení návrhu testovanými subjekty v podobě výsledků testování. Výsledky testování obsahují dosažené úspěchy, popřípadě překážky, které vedly k tomu, že testování nebylo úspěšné. Následně je Návrh pravidel opět přepracován a jeho nová verze opět poskytnuta k otestování a připomínkování. Očekává se, že po dvou až třech revizích je návrh konkrétního pravidla akceptovatelný pro většinu států. Je nutné zmínit, že samotné připomínkování nemá pouze zajistit soulad poskytovatelů, ale i odstranění problémů mezi jednotlivými prováděcími pravidly navzájem. Nebo lépe řečeno jednotlivé návrhové týmy spolu mnohé věci nekonzultují a mnohé nesoulady jsou odstraňovány až na základě stížností budoucích poskytovatelů dat. Po vytvoření prováděcích pravidel se očekává jejich naplnění jednotlivými poskytovateli dat ve stanovených termínech. 2.2 Prováděcí pravidla Metadata Prováděcí pravidla pro Metadata vešla v platnost 24. prosince Prováděcí pravidla vycházejí z metadatového modelu stanoveného v ISO 19115, ke kterému dodávájí sadu vlastních metadatových elementů. Přesněji řečeno ISO 19115:2005 (a ISO 19115:2003/- Cor.1:2006) stanovuje sadu 22 základních, z toho ale jen 7 povinných a dalších cca 400 metadatových elementů. Na tuto normu navazuje ISO/TS 19139:2007, která definuje způsob reprezentace těchto metadatových elementů v XML pomocí stanovení XML schématu. INSPIRE prováděcí pravidla pak rozšiřují zmíněný ISO metadatový model o další elementy. Celkem se jedná o dalších 21 položek, přičemž 19 z nich je použito pro metadata datových sad a 17 pro metadata služeb. Tento rozšířený metadatový model lze dále rozšiřovat kupříkladu vhodným profilem poskytovatele dat. Ten zajistí, že bude možné různá data (datové sady) jednoho poskytovatele popsat společnou množinou dalších metadat. Metadatový profil se zdá být velmi výhodný nástroj, který ale mnohdy vede i ke slepé víře, zejména u státních poskytovatelů dat, že jejich dokonalý metadatový profil se může stát jakýmsi standardem pro ostatní. Tito poskytovatelé často zapomínají na jednoduchost a eleganci, kdy by tento profil měl být co možná nejlépe definován v rámci metadatových elementů již zmíněných ISO norem. Tedy aby soubor reprezentující metadata jako celek bylo možné validovat i pomocí ISO metadat. Mimo metadatový profil jsou metadata jednotlivých typů dat ještě rozšířena o specifické metadatové elementy, které mají mnohdy význam jen pro určitý typ INSPIRE dat. Tato metadata mnohdy patří do oblasti kvality dat (Data Quality). Pro snadnější schvalovací proces jsou tyto metadatové elementy definovány u jednotlivých datových specifikací INSPIRE dat. Na obrázku 2.1 je zobrazeno schéma metadat. Kde základní ISO metadatové elementy spolu s dalšími vybranými ISO elementy, ale i jinými vnějšími (v našem případě OGC elementy), definují INSPIRE metadatový profil. Tento metadatový profil lze dále rozšířit o metadatový profil poskytovatele, který se skládá z ISO metadat a metadat dle dalších specifikací (OGC, ale může být i vlastní schéma). Každé téma je navíc obohaceno o tématicky specifická metadata. Tato metadata jsou většinou ISO metada- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 4

17 Kapitola 2. INSPIRE tovými elementy, ale v budoucnu může dojít i k tomu, že přibudou metadata z OGC či jiných specifikací. Obrázek 2.1: Metadata ISO, INSPIRE a metadatový profil Specifikace dat Nejprve je nutné si zavést dva nové termíny: INSPIRE téma a Datová sada (Dataset). INSPIRE tématem budeme rozumět množinu všech instancí prvků, které jsou jako jedno téma definovány v rámci INSPIRE datové specifikace. Datovou sadou pak budeme rozumět vhodně prostorově omezenou část INSPIRE tématu do publikační jednotky. Vzhledem k velkému množství INSPIRE témat je jejich datová specifikace rozdělena do třech příloh (Annex I.-III.). Specifikace datových sad by měla představovat ucelený, vzájemně provázaný datový model jednotlivých mapových vrstev, který odpovídá příslušným tématům. Protože se při definici jednotlivých témat vychází ze společného konceptuálního modelu, který definuje společný rámec pro všechna INSPIRE témata. Na druhou stranu je datový model INSPIRE nesourodou směsicí ISO norem a OGC (Open Geospatial Consortium) specifikací, kde se i verze jednotlivých norem liší v jednotlivých tématech. A protože metadata k těmto tématům mají svůj vlastní společný datový model, dochází nutně i k rozdílům v datech a metadatech jednoho tématu. Datová struktura jednotlivých témat je reprezentována UML (Unified Modeling Language) modelem. Fyzická reprezentace jednotlivých elementů datového modelu se provádí v datovém formátu INSPIRE za využití prvků (features) jazyka GML (Geography Markup Language). Pro každé INSPIRE téma jsou definována XML schémata (XSD), která pak usnadňují validaci. K metadatovému modelu INSPIRE nejsou dodávána žádná validační schémata. Dále je reprezentace modelu doplněna dalšími specifikacemi (pravidla a omezení), které nelze v jazyce UML reprezentovat anebo pomocí gramatiky GML zapsat. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 5

18 Kapitola 2. INSPIRE Po schválení jednotlivých příloh je stanoveno 18 měsíců na implementaci témat jednotlivými poskytovateli. Dále je stanoveno, že metadata datových sad Annexu I a II budou v souladu s pravidly do dvou let a u Annexu III v souladu do pěti let od vstupu v platnost Vyhledávací služba Vyhledávací služba (Discovery service - na obrázku 2.2) je webová služba, která umožňuje vyhledávání v metadatových záznamech. Obdobou této služby v OGC (Open Geospital Consorcium) infrastruktuře je Katalogová služba, resp. CSW INSPIRE vyhledávací služba ze svého OGC protějšku do značné míry vychází. Navíc však definuje práci s vícejazyčnými metadaty (ta nejsou dosud zahrnuta v žádné ISO normě ani OGC specifikaci) a mechanismus dotazování. Na druhou stranu čistá INSPIRE implementace vyhledávací služby neumožňuje oproti své OGC obdobě fulltextové vyhledávání, protože původní OGC pseudoentita AnyText zde není mezi doporučenými položkami pro vyhledávání. Základní operace vyhledávací služby: Get Discovery Service: V infrastruktuře INSPIRE se jedná o povinnou operaci. Její obdobou v OGC-CSW je také povinná operace OGC_Service.GetCapabilities. Touto operací získáme informace o prohlížecí službě. Tedy soubor 15 OGC metadatových záznamů a 20 metadatových záznamů INSPIRE (z toho jen 14 povinných). Discovery Metadata: V infrastruktuře INSPIRE se jedná o povinnou operaci. Její obdobou v OGC-CSW je také povinná operace CSW Discovery.GetRecords. Tato operace slouží k vyhledávání metadatových záznamů na základě dvou parametrů: požadovaného jazyka (Language) a dotazu (Query). Publish Metadata: V infrastruktuře INSPIRE se jedná o podmíněnou operaci. Podmíněností zde budeme rozumět to, že máme na výběr ze dvou způsobů implementace: Transaction (push mechanismus), Harvest (pull mechanismus). Její obdobou v OGC-CSW je také podmíněná operace CSWT Manager.Transaction nebo CSWT Manager.Harvest. Tato funkce slouží k publikování metadat do katalogů. Link Discovery Service: V infrastruktuře INSPIRE se jedná o povinnou operaci. Její obdobou v OGC-CSW mohou být (existuje více možností implementace) též povinné operace OGC_Service.GetCapabilities a CSW Discovery.GetRecords. Tato operace umožňuje prohlášení o dostupnosti vyhledávání metadat této služby přes jinou vyhledávací službu, přičemž zdroj metadat je stále udržován na úrovni vlastníka. Doporučený mechanismus pro implementaci takového vyhledávání je pak Publish Metadata operace. Operace připojení vyhledávací služby je v INSPIRE infrastruktuře, protože se počítá s různými úrovněmi vyhledávacích služeb: Vyhledávací služba poskytovatele dat, Vyhledávací služba členského státu (tato služba umožňuje vyhledávání v metadatech všech poskytovatelů v daném státě) a hlavní vyhledávací služba/portál INSPIRE na evropské úrovni. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 6

19 Kapitola 2. INSPIRE Pro provoz vyhledávací služby platí následující kritéria: Odezva pro 250 záznamů vyhledávací služby je stanovena na 3 sekundy. Dostupnost 99% času, tedy výpadek služby je možný na cca 3 dny v roce. Služba musí být schopna zpracovávat současně 30 dotazů. Obrázek 2.2: Inspire služby Prohlížecí služba Prohlížecí službou (View Service na obrázku 2.2) je služba vycházející z webové mapové služby OGC verze 1.3 (odpovídá ISO 19128:2005). Propojení vyhledávací a prohlížecí služby je následující: Metadatové záznamy vyhledané v rámci INSPIRE vyhledávací služby obsahují též element odkazující na INSPIRE prohlížecí a stahovací službu. Tedy po vyhledání vhodných dat je možné si data rovnou prohlédnout nebo stáhnout. Samozřejmě je nutné brát na zřetel licenční omezení, poplatky ale i jiná omezení přístupu (kupříkladu lokality rozšíření vzácných druhů by zde neměly být přístupné komukoliv). Obecně se předpokládá, že pro většinu dat bude prohlížecí služba zdarma. Zdarma by měla být i služba stahování celých datových sad. Naopak služba stahování dat pomocí přímého přístupu by měla být placená. Pro jednotlivá témata dat datové specifikace INSPIRE jsou definovány soubory mapových vrstev, styly a symbologie. Tímto lze, spolu s definováním ETRS a jeho vybraných projekcí jako povinného souřadnicového systému, dosáhnout souvislé mapy celého území Evropské Unie. Prováděcí pravidla Vyhledávací a Prohlížecí služby byla společně schválena Evropskou komisí a vešla v platnost Základní operace prohlížecí služby: Get View Service Metadata: Poskytuje metadata prohlížecí služby, seznam možných operací, Metadata jednotlivých vrstev a jazyků. Get Map: Operace slouží pro získání obrazových dat (PNG/JPEG/GIF) na základě následujících INSPIRE a OGC parametrů: Verze (VERSION): Povinný OGC parametr označující verzi služby, se kterou chceme pracovat. Parametr by měl být používán pro ISO 19128:2005(E). Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 7

20 Kapitola 2. INSPIRE Požadavek (REQUEST): Hodnota GetMap v tomto povinném OGC parametru zajistí volání funkce GetMap. Jazyk (LANGUAGE): Parametr značí preferovaný jazyk výstupní mapy. Hodnota tohoto parametru se stanovuje dle ISO 639-2/B. Hodnota by měla být z množiny nabízených hodnot jazyků operace Get View Service Metadata. Pokud je hodnota jiná nebo prohlížecí služba nepodporuje práci s více jazyky, je tento parametr ignorován. Vrstvy (LAYERS): Seznam zobrazených vrstev. Styly (STYLES): Seznam použitých stylů. Souřadnicový referenční systém (CRS): Souřadnicový systém a zobrazení, ve kterém má být výsledná mapa vrácena. Opsaný obdélník (BBOX): Minimální a maximální souřadnice zobrazované mapy. Šířka obrázku (WIDTH): Počet pixelů reprezentující šířku vrácené mapy. Výška obrázku (HEIGHT): Počet pixelů reprezentující výšku vrácené mapy. Formát obrázku (FORMAT): Formát obrazových dat, ve kterém má být výsledná mapa vrácena. Transparence (TRANSPARENT): Povinný OGC parametr specifikující zda má být pozadí mapy průhledné. Barva pozadí (BGCOLOR): Volitelný OGC parametr udávající barvu pozadí (oblast bez dat) mapy. Výjimky (EXCEPTIONS): Povinný OGC parametr udávající způsob, jakým mají být reprezentovány/sděleny uživateli chyby/výjimky. Standardní hodnota je XML, dalšími možnostmi jsou INIMAGE a BLANK. Rozměrový pár (TIME, ELEVATION): Volitelný parametr umožňující práci s časovým a výškovým systémem. Link View Service: Operace umožňuje třetí straně připojení prohlížecí služby do své vlastní prohlížecí služby. Předpokládané použití je spojení prohlížecích služeb všech poskytovatelů v daném státě do prohlížecí služby členského státu (Member State View Service). Pro provoz prohlížecí služby platí následující kritéria: Odezva pro mapu v rozlišení 800x600/8bit a formátech PNG/GIF je stanovena na 5 sekund. Dostupnost 99% času, tedy výpadek služby je možný na cca 3 dny v roce. Služba musí být schopna zpracovávat současně 20 dotazů. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 8

21 Kapitola 2. INSPIRE Služba stahování dat Službu stahování dat (Download service na obrázku 2.2) můžeme rozdělit na dva typy: Službu stahování celých datových sad nebo jejich částí (Download service of pre-defined datasets or pre-defined parts of datasets) a Službu stahování dat s přímým přístupem (Direct access download service). Službu stahování celých datových sad lze charakterizovat dvěma vlastnostmi: První vlastnost je, že tyto služby mají metadatový záznam dostupný přes INSPIRE vyhledávací službu (Discovery service) a druhou vlastností je skutečnost, že tato metadata obsahují element odkazující na URL, kde lze jednoduše pomocí funkce GET protokolu HTTP tato data stáhnout. Velkou výhodou pro poskytovatele je, že publikuje data nejlépe v souřadnicovém systému ETRS(B,L) a kódování provede nejlépe v UTF-8. Uživatel si tato data stáhne v tomto tvaru a dané publikační jednotce. Tedy tato služba neklade speciální nároky na server, ze kterého jsou takto předpřipravené datové sady poskytovány. Sekvenční diagram práce této služby je zobrazen na obrázku 2.3. Obrázek 2.3: Služba stahování celých datasetů Oproti tomu služba stahování dat s přímým přístupem umožňuje stahování pouze požadovaných dat. Množina požadovaných dat je zde specifikována pomocí dotazu. Implementace služby se provádí použitím Web Feature Service dle ISO/DIS s použitím Filter Encoding ISO/DIS Jako minimální požadavky INSPIRE stahovací služby s přímým přístupem jsou požadovány následující třídy operací WFS: Simple WFS, Basic WFS a SOAP. Ostatní operace jako jsou: transakce, zamykání, stránkování, spojování filtrovacích, časových a prostorových operátů a vytváření vlastních dotazů je pouze volitelné. Sekvenční diagram práce této služby je zobrazen na obrázku 2.4. Základní operace stahovací služby: Get Download Service Metadata: Jedná se o povinnou operaci pro oba typy stahovací služby. Tato operace vrací metadata služby stahování dat. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 9

22 Kapitola 2. INSPIRE Obrázek 2.4: Služba stahování s přímým přístupem Get Spatial Objects: Opět se jedná o povinnou funkci, která v případě služby stahování s přímým přístupem vrací vybrané prvky, které byly vybrány pomocí operace Define Query. Při nespecifikování výběrového kritéria a služby stahování celých datasetů vrací celou datovou sadu. Describe Spatial Object: Tato operace je povinná jen pro stahovací služby s přímým přístupem. Pro službu stahování celých datasetů vrací operace seznam popisů všech prvků. Při použití služby s přímým přístupem je možné požadovat jen popis specifického prvku zadaného vstupním parametrem. Define Query: Tato operace je povinná pro službu stahování s přímým přístupem. Pro službu stahování celých datasetů se tato operace použít nedá. Operace slouží k vytvoření dotazu na množinu prostorových dat, které dále budou vráceny operací Get Spatial Objects. Link Download Service: Tato funkce umožňuje připojení stahovací služby třetí stranou. Tedy jedná se o analogii operací u vyhledávací a prohlížecí služby. Pro provoz stahovací služby platí následující kritéria: Odezva 3 sekundy pro operaci Get Download Service Metadata. Odezva 30 sekund pro první odezvu operace Get Spatial Objects pro data 0.5MB nebo 500 objektů. Odezva 10 sekund pro první odezvu operace Describe Spatial Object Type pro data 0.5MB nebo 500 objektů. Dostupnost 99 % času s výpadkem menším než 15 minut během pracovní doby. Služba musí být schopna zpracovávat současně 10 dotazů. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 10

23 Kapitola 2. INSPIRE Transformační služba Transformační služba ( INSPIRE Coordinate Transformation service neboli Transformation service na obrázku 2.2) je služba založená na profilu Web Coordinate Transformation Service (WCTS) definovaném ve specifikaci OGC Web Processing Service (WPS). Jak již z názvu vyplývá, úkolem této služby je provádět souřadnicové transformace. Povinným souřadnicovým systémem, z (do) kterého musí transformační služba být schopna převádět, je Evropský Terestrický Referenční Systém (ETRS) v projekci Transversální Merkátorově (ETRS89-TMzn), Lambertově Azimutální se zachováním ploch podél poledníku (ETRS89- LAEA) a Lambertově konformním kuželovém zobrazení (ETRS89-LCC) a samozřejmě bez zobrazení v podobě pracující přímo s elipsoidickými souřadnicemi. Zařazení ostatních souřadnicových systémů do transformační služby je pak na zvážení každého poskytovatele. Výhodou transformační služby pro koncového uživatele je skutečnost, že transformaci můžeme díky přesměrování požadovat pro data služby stahování dat nebo již pro data stažená. Základní operace stahovací služby: Get Service Metadata: Jedná se o povinnou operaci vracející metadata transformační služby. Transform: Povinná operace, která provede požadovanou souřadnicovou transformaci. Parametry této operace jsou vstupní data (Input Spatial Dataset), vstupní souřadnicový systém (Source Model), výstupní souřadnicový systém (Target Model) a zvolená transformace (Model Mapping). Parametr vstupních dat zde lze zadat přímo jako inline XML nebo pomocí odkazu (URL), ostatní tři parametry se zadávají jako URN (urn:ogc:def:crs:[authority]:[db-version]:[code]). Navíc je možné zadat ještě volitelný parametr TestTransformation s hodnotou true. Operace pak vrací pouze informaci, zda je transformace s danými parametry proveditelná. Link Transformation Service: Tato operace umožňuje připojení metadat této služby do vyhledávací služby pomocí operace Publish Metadata Pro provoz transformační služby platí následující kritéria: Dostupnost 99% času s výpadkem menším než 15 minut během pracovní doby. Služba musí být schopna zpracovávat současně 10 dotazů. Výkon služby pro GML obsahující pouze geometrická primitiva musí být 1MB/s (0.5MB/s při iniciaci) Další služby Na obrázku 2.2 jsou zmíněny další služby, s nimiž se v rámci INSPIRE počítá. Pro tyto služby dosud neexistují návrhy implementačních pravidel a ani tyto služby nebyly Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 11

24 Kapitola 2. INSPIRE dosud z INSPIRE infrastruktury vyřazeny. Jedná se o Registrační službu (Registery Service) a Spouštěcí službu (Invoke Service). Registrační služba představuje jednotnou a centralizovanou registrační autoritu pro přístup ke službám INSPIRE. Naproti tomu služba Spuštění představuje službu, která umožňuje pracovat s daty INSPIRE bez specifického software. Konkrétní naplnění této služby může být různorodé. Ať již si představíme pouhou prohlížečku WMS dat, systém kombinující data INSPIRE s jinými datovými sadami INSPIRE nebo daty mimo zájem direktivy. Příkladem takového systému může být kupříkladu systém Nahlížení do KN nebo systémy, které provádějí složité a časově náročné výpočty nad daty INSPIRE Sdílení dat První návrh tohoto pravidla vyšel 12. prosince Pravidla sdílení dat budou určovat pravidla přístupu Evropských orgánů k prostorovým datům a službám jednotlivých členských států a pravidla využívání těchto dat. Jsou zde stanoveny tři typy licencí (základní, specifická, rámcová dohoda). Zřízení přístupu musí být do 20 dní (v případě, že zřízení přístupu vyžaduje více než pět dní, by měly organizace o tom žadatele informovat). Je zde dále zajištěn přístup k datům v případě ohrožení Monitoring a reporting Prováděcí pravidla pro monitoring a reporting vešla v platnost 5. června Monitoring a reporting spočívá v pravidelném zasílání ukazatelů o využívání prostorových dat a služeb. Report budou členské státy pravidelně zasílat prostřednictvím svého zástupce v INPSIRE Committee (Pro Českou republiku byla tímto zástupcem stanovena Česká informační agentura životního prostředí CENIA). První report byl zaslán 15. května Reálná podoba prvního reportingu nabývá podoby sešitu s tabulkami, kam držitel dat do jednotlivých řádek vyplní vlastní datové sady a služby, které odpovídají nebo budou zdrojem INSPIRE dat/služeb a v jednotlivých sloupcích následně vyznačí příslušnost k jednotlivým INSPIRE Annexům a doplní další údaje jako je existence metadat, pokrytí území, shoda s prováděcími pravidly. Právní status všech prováděcích pravidel je nařízení Evropské komise s výjimkou prováděcích pravidel pro monitoring a reporting, které bude mít status rozhodnutí EK, tedy pouze forma doporučení. 2.3 Infrastruktura Směrnice INSPIRE a rovněž pak zákon č. 380/2009 Sb. definuje pojem povinný subjekt, tedy povinného poskytovatele dat INSPIRE. Povinnými poskytovateli jsou správní úřady a jiné organizační složky státu, orgány samosprávných celků, právnické nebo fyzické osoby, které na základě zvláštních předpisů vykonávají v oblasti veřejné správy působnost vztahující se přímo nebo nepřímo k životnímu prostředí. Nebo odpovídající pověřené osoby těchto subjektů. Tedy povinnými poskytovateli dat se stávají i obce, městské obvody statutárních měst a městské části hlavního města Prahy, pokud jim tvorbu těchto dat ukládá zvláštní právní předpis. Povinný poskytovatel má na výběr, zda svá harmonizovaná data zpřístupní Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 12

25 Kapitola 2. INSPIRE pomocí sady vlastních služeb (vyhledávací, prohlížecí, stahovací) nebo využije řešení svého členského státu a tedy tomuto poskytovateli INSPIRE služeb předá pouze harmonizovaná data s příslušnými metadaty. Tento státní poskytovatel INSPIRE služeb, v ČR je to Česká informační agentura životního prostředí (CENIA), pak data začlení do dat svého systému a poskytuje nad nimi příslušné INSPIRE služby. Zde je vhodné zdůraznit, že jelikož státní poskytovatel obdrží již harmonizovaná data, je vybudování příslušného informačního systému ve srovnání s informačním systémem publikační databáze (PUB-DB) popisovaném v této disertační práci poměrně jednoduché. Státní poskytovatel služeb není jen agregátem datových sad poskytovatelů, kteří nemají vlastní data, ale agreguje i metadata a odkazy na služby všech poskytovatelů INSPIRE dat a služeb v daném státě. Obrázek 2.5: Národní infrastruktura Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 13

26 Kapitola 3. Datová specifikace Kapitola 3 Datová specifikace 3.1 Generický konceptuální model Generický konceptuální model (GCM) je jedním ze čtyř základních dokumentů reprezentující INSPIRE vývojový rámec (INSPIRE development framework), který definuje pravidla a způsob práce při vytváření INSPIRE infrastruktury. Infrastrukturou zde rozumíme soubor pravidel/schémat a jiných dokumentů nikoliv fyzickou infrastrukturu na straně poskytovatelů dat. Na obrázku 3.1 jsou tyto čtyři základní dokumenty zobrazeny. V první řadě se jedná o dokument definující jednotlivá témata (Definition of Annex Themes and Scope, zdroj: [4]), dokument generického konceptuálního modelu (INSPIRE Generic Conceptual Model, zdroj [7]), dokument popisující metodiku tvorby jednotlivých prováděcích pravidel (Methodology for the development of data specifications, zdroj [8]) a dokument popisující vybrané způsoby zápisu prostorových dat a práci s XML (Guidelines for the encoding of spatial data, zdroj [5]). Obrázek 3.1: Vývojový rámec pro tvoru INSPIRE témat (Zdroj [7]). Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 14

27 Kapitola 3. Datová specifikace Tyto čtyři dokumenty tedy dohromady stanovují způsob práce jednotlivých návrhových týmů (metodik), náplň témat a společný soubor pravidel a postupů, které je nutné při návrhu dodržovat. Přestože všechny zmíněné dokumenty bezesporu ovlivní podobu výsledných aplikačních schémat jednotlivých témat, my si v následujícím textu uvedeme pouze Generický konceptuální model, protože jeho pochopení nám následně umožní pochopení datové architektury, kterou v této disertační práci chápeme do značné míry jako základní a nejdůležitější. Generický konceptuální model (GCM) v sobě spojuje výhody generického a konceptuálního modelu. Generický model představuje generalizaci konvenčních modelů, v našem případě se jedná o generalizaci všech případných modelů jednotlivých INSPIRE témat. Konceptuální model pak představuje model, který slouží k formálnímu popisu modelované reality. Hlavním úkolem tohoto modelu je nalezení entit, vztahů a atributů. Tedy dohromady Generický konceptuální model se zabývá nalezením entit, jejich atributů a případných vztahů v generalizovaném modelu INSPIRE témat. Nebo méně přesně řečeno: GCM definuje společné objekty a vztahy a jiná pravidla pro všechny z něj odvozené datové specifikace INSPIRE témat. Obrázek 3.2 znázorňuje GCM, který pro své potřeby využívá základní kostru (Foundation Schemas) v podobě XML schémat, z nichž GCM vytváří své základní typy, pravidla a sub-modely, které v podobě rozhraní zpřístupňuje odvozeným aplikačním schématům. Pojem rozhraní zde používáme pro zjednodušení. Máme na mysli, že objekty konkrétních aplikačních schémat nepřistupují k prvkům základních schémat (Foundation Schemas) přímo, ale přes Generický konceptuální model. Obrázek 3.2: GCM jako základ INSPIRE aplikačních schémat (Zdroj [7]). Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 15

28 Kapitola 3. Datová specifikace Generický konceptuální model se zabývá: Tvorbou INSPIRE aplikačních schémat. Prostorovou a časovou reprezentací prostorových objektů v závislosti na úrovni detailu. Prostorovými a časovými vazbami mezi objekty. Unikátními identifikátory. Omezeními. Společným prostorovým a časovým systémem. Slovníky a mnohojazyčnou podporou. Jelikož je dokument popisující Generický konceptuální model poměrně rozsáhlý (cca 138 stran), není zde možné uvést celý jeho obsah v náležitém zpracování. Proto se zaměříme na vybrané oblasti: tvorbu identifikátorů, časový rozsah prvků, zápis atributů bez dat, podporu více jazyků a definování nového zásobníku SpatialDataSet Práce s proměnnými no data Některé atributy jednotlivých prvků aplikačních schémat nemusí být možné naplnit hodnotou. Je potřeba rozeznávat dva důvody. První důvod nastane, pokud není zajištěno, že samotný atribut existuje pro každý prvek reálného světa. Příkladem je vyžadování atributu jméno u každého objektu silnice/cesta, kdy je minimálně zřejmé, že mnohé přístupové a polní cesty tento atribut nemohou naplnit. Vzniku problému, kdy není zaručeno, že každý objekt reálného světa daný atribut má, je možné předejít použitím při návrhu aplikačního schématu pro tento atribut násobnosti s dolní mezí nula. Druhou možností je případ, kdy daný atribut v reálném světě existuje, ale není zaručeno, že každý poskytovatel tento atribut ve své databázi (zde je nutné brát v potaz, že jakékoliv databáze, tedy i prostorové, vždy vznikají za určitým účelem) má nebo dokonce není zaručeno, že všechna data jednoho poskytovatele tento atribut obsahují. V tomto případě je vhodné při návrhu aplikačního schématu v UML použít pro tento atribut stereotyp «voidable». Ten zajistí, že daný UML atribut bude v GML schématu reprezentován elementem s atributem umožňujícím nevyplnění dat a uvedení důvodu, proč data nebyla uvedena. Je poměrně složité dopředu určit v UML schématu všechny atributy, které budou tento způsob vyžadovat. Proto bylo raději stanoveno, že všechny atributy prvku, bez kterých prvek stále dává smysl, mají být opatřeny stereotypem «voidable». V UML modelu je typ tohoto atributu modelován jako VoidReasonType a v GML schématu je reprezentován atributem nilreason a výčtovým souborem hodnot (inapplicable, missing, template, unknown a withheld). Zde si dovolím jednu poznámku: Při testování první a druhé datové specifikace tématu Katastrální parcely mnohé severské státy došly k závěru, že nejsou schopny pro nepovinný prvek hranice parcel uvést přesnost této hranice, proto požadovaly, aby tento GML element byl nepovinný. Pokud se podíváme do UML schématu druhého a třetího návrhu tohoto tématu, Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 16

29 Kapitola 3. Datová specifikace bude se nám na první pohled jevit, že severské státy s tímto svým návrhem zdánlivě uspěly. Ve skutečnosti však požadavek na smysluplnost hranic parcel stále trvá. Tedy prvek hranice parcel byl zaveden právě pro možnost, aby státy byly schopné poskytovat přesnost linií, pokud tuto přesnost mají. Důvod použití stereotypu «voidable» je ten, že ve třetím návrhu byla odstraněna prostorová topologie a byla nahrazena tzv. implicitní topologií přímo z hranic parcel. Tedy pokud státy chtějí poskytnout celý topologický model, musejí poskytnout i hranice parcel, u kterých přesnost uvedena není Správa identifikátorů Pro potřeby práce s jednotlivými objekty INSPIRE infrastruktury (zejména vytvářením vazeb mezi nimi) je potřeba zavést jednotný externí identifikátor (platí i pro samotné datové sady a obrazová data). O externím identifikátoru mluvíme, protože je nutné zajistit správnou identifikaci objektu nejenom v rámci jedné datové sady (interní identifikátor) ale v rámci celé infrastruktury INSPIRE. V infrastruktuře EU se běžně setkáme s externími identifikátory, jako jsou NUTS (kódy statistických jednotek), ICAO (mezinárodní zkratka letišť). Tyto identifikátory nemohou být pro identifikaci v INSPIRE použity implicitně, ale musejí být explicitně jako identifikátory určeny INSPIRE objektem. Na počátku jsou všechny prvky aplikačního schématu opatřeny jedinečným identifikátorem (InspireId) s násobností 0..1 nebo přímo 1 a to až do té doby, než je zjištěno, že pro objekty tohoto typu nebude unikátní externí identifikátor potřeba. Pro prvky aplikačního schématu, kde se očekává, že na tyto prvky se bude navazovat jiný prvek, se stává atribut InspireId povinným. Naproti tomu u prvků, kde se nepočítá s jakoukoliv návazností (kupříkladu Geologie), je možné InspireId vynechat. InspireId se vyznačuje čtyřmi základními vlastnostmi: Unikátností, Persistencí, Vysledovatelností a Vhodností. Unikátnost spočívá v tom, že dva různé objekty by neměly mít stejný externí identifikátor. Stejný objekt (i změněný) nebo jeho kopie má stále stejný InspireId. Je zakázáno znovupoužití již nepoužívaných InspireId. Persistencí se rozumí neměnnost externího identifikátoru v rámci životního cyklu objektu. Vyhledatelností se rozumí schopnost na základě InspireId dohledat postupně daný prvek v rámci celé infrastruktury. Tedy InspireId obsahuje dostatečné informace o poskytovateli dat. Vhodností pak rozumíme snahu využít pro identifikaci již existující národní identifikátory. Externí identifikátor (InspireId) se skládá ze jmenného prostoru (namespace), lokálního identifikátoru (localid) a volitelně pak z verze (versionid). Jmenný prostor je identifikátor poskytovatele dat a tématu, který je jedinečný v rámci příslušného registru INSPIRE External Object Namespaces Register. Lokální identifikátor je též jedinečný identifikátor v rámci daného tématu poskytovatele a poskytovatel též za jeho jedinečnost zodpovídá. Verze je pak volitelný maximálně 25 znaků dlouhý řetězec. Tento element není uveden, pokud poskytovatel dat nepracuje s elementy stereotypu «lifecycleinfo». Pokud je element prázdný, poskytovatel není schopen rozeznat od sebe jednotlivé stavy daného objektu. GCM definuje InspireId jako jeden ze svých základních typů (Base Types) a považuje všechny hodnoty jeho elementů za řetězce a povoluje u nich následující znaky: velká a malá písmena latinské abecedy (pouze 26 základních písmen), arabské číslice, znak podtržítko, tečka a pomlčky. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 17

30 Kapitola 3. Datová specifikace Životní cyklus prvků Pokud má být architektura INSPIRE reálně použitelná, musí se nutně vypořádat se skutečností, že jednotlivé prvky v rámci témat vznikají, zanikají a mění své atributy. Z tohoto důvodu byly do konceptuálního modelu přidány atributy, které mají umožnit určení rozsahu platnosti jednotlivých prvků aplikačních schémat. Samotný životní cyklus objektu je označován stereotypem «lifecycleinfo» a je v příslušném prvku reprezentován dvěma proměnnými: začátek (beginlifespanversion) a konec (endlifespanverison) existence verze daného objektu v datové sadě. Jedná se tedy o datum vložení a vyjmutí z datové sady. Dále podle potřeb jednotlivých schémat může být prvek obohacen o další dva atributy: Začátek (validfrom) a konec (validto) platnosti objektu v reálném světě. Tyto dva atributy však nejsou součástí informace o životním cyklu, jak je mnohde uváděno. Atributy konec platnosti objektu v datové sadě a konec platnosti objektu v reálném světě jsou vždy volitelné atributy. Jejich užití je silně závislé na podpoře této funkcionality v použitém systému. Naproti tomu vložení do datové sady a začátek platnosti v reálném světě jsou většinou povinné atributy a lze obecně prohlásit, že jejich hodnoty mohou být různé a libovolně mohou zasahovat i do budoucnosti. Pro atributy pracující s životním cyklem prvku a InspireId platí INSPIRE požadavky z konceptuálního modelu Tyto požadavky jsou: Pokud může nastat změna prostorového objektu, musí prvek příslušného aplikačního schématu podporovat životní cyklus objektu. Pokud existuje v rámci prvku/schématu podpora životního cyklu, nesmí tato podpora omezovat poskytovatele dat, jejichž data tuto funkcionalitu nepodporují. Různé verze téhož prvku musejí být stejného typu. Všechny verze prvku mají mít společné InspireId. Pokud je atribut součástí funkcionality Podpora životního cyklu, náleží mu stereotyp «lifecycleinfo». Stereotyp «version» naopak náleží vazbě, která odkazuje na verzi stavu prostorového objektu. Deváté a desáté INSPIRE doporučení z konceptuálního modelu dále zmiňuje rozdílný přístup k životnímu cyklu objektů, kdy rozlišujeme dva základní přístupy. První přístup (Obrázek 3.3) pracuje s datovou sadou, kde se jednotlivé objekty mění, přibývají a ruší nezávisle. Zde je výhodné použít přístup popsaný výše. Druhý přístup (Obrázek 3.4) je hromadný vznik prvků exportem ze stávajícího systému. Zde je vhodné pouze zaznamenat společný začátek platnosti prvků v metadatech. Je dobré zdůraznit, že všechna INSPIRE témata a systémy, vyjma testování tématu Geografických názvů ze systému ZABAGED, popsané v této disertační práci, pracují s prvním způsobem Podpora mnohojazyčnosti Podpora vícejazyčnosti představuje poměrně jednoduchý mechanismus a příslušnou sadu pravidel. Je třeba říci, že se jedná co do rozsahu zasažených koncových dat o ojedinělý Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 18

31 Kapitola 3. Datová specifikace Obrázek 3.3: Postupný vznik prvků. Obrázek 3.4: Hromadný vznik prvků. projekt. Všechny elementy, které reprezentují geografické jméno, by měly být v aplikačních schématech modelovány jako instance typu GeographicalName z tématu Geografické Názvy z Annexu I. Počet překladů by neměl být nijak omezený. Měla by se uvádět pouze exonyma a ne doslovné překlady. Každý překlad by měl být opatřen jazykem původu, názvy skládající se z více jazyků by proto měly být používány výjimečně a to u oficiálních mnohojazyčných názvů. Je však potřeba v INSPIRE aplikačních schématech umožnit práci s FreeTextem (řetězce znaků bez přiděleného jazyka) a to nejméně u tématu Adresy (v ČR kupříkladu písmeno čísla domovního). Výčtové seznamy hodnot (CodeList), které jsou součástí INSPIRE aplikačního schématu, by měly být vícejazyčné a měly by používat na jazyku nezávislý zápis. Tedy fyzický zápis výčtových typů bude v podobě kódu, ale reprezentace významů bude umožněna přes vícejazyčný seznam. Pro implementaci těchto slovníků ale i slovníků jednotek měření se vychází z ISO/TS Základní typ SpatialDataSet Typ SpatialDataSet 3.5 je speciální zásobník navržený pro uchovávání libovolných prvků aplikačních témat INSPIRE. Tento zásobník se odlišuje od standardního zásobníku GML tím, že má vlastní vnější identifikátor (InspireId) a element metadata, které jsou uvedeny před položkami zásobníku. Tento zásobník bude sloužit/slouží k publikaci pomocí služby stahování dat celých datových sad nebo též k prostému zápisu INSPIRE dat do GML. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 19

32 Kapitola 3. Datová specifikace Obrázek 3.5: INSPIRE SpatialDataSet 3.2 Téma Geografické názvy (GN) Téma Geografické názvy obsahuje jediný typ prvku Pojmenované místo (Named Place), dále pak datové typy Geografické jméno (Geographical Name), Zápis jména (Spelling of Name) a Výslovnost jména (Pronunciation of Name) a několik výčtových typů. Vazba tématu na Generický konceptuální model je na obrázku 3.6. Obrázek 3.6: Schéma Geografické Názvy (Zdroj [6]) Typ prvku Pojmenované místo (Named Place) Jedná se o jediný typ prvku v tomto tématu. Prvek (Obrázek 3.7) reprezentuje objekt reálného světa, pro který existuje Geografické jméno a je u něho známa poloha. Termínem Geografické jméno budeme rozumět složený datový typ, který je definován v tomto schématu viz dále. Tento datový prvek je držitelem veškerých lingvistických informací a je proto hojně využíván v rámci jiných témat. S jistým zjednodušením můžeme konstatovat, že prvek Pojmenované místo tvoří jakousi minimální INSPIRE obálku pro datový typ Geografické jméno tak, aby bylo možné tento datový typ publikovat nezávisle na ostatních tématech. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 20

33 Kapitola 3. Datová specifikace Obrázek 3.7: Pojmenované místo (Zdroj [6]). Atributy: Geometrie (geometry): Specifikace přímo nenařizuje, který typ geometrického prvku se má použít. Použitý typ geometrie mnohdy závisí na lokálních zvyklostech státu a typu objektu reálného světa. Nejpoužívanějšími typy geometrií jsou bod, linie, opsaný obdélník nebo přímo polygon. Vždy ale musí být dodržena lineární interpolace mezi body. Vnější identifikátor (inspireid): Vnější identifikátor, který slouží pro jedinečnou identifikaci prvku v rámci celé INSPIRE infrastruktury. Jméno (name): Instance datového typu Geografické jméno. Datum vzniku (beginlifespanversion): Datum vzniku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum zániku (endlifespanversion): Datum zániku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Nejmenší povolené měřítko pro zobrazení (leastdetailedviewingresolution): Nejmenší povolené měřítko pro zobrazení prvku Geografické jméno.tj. pro menší měřítka (menší úroveň detailu) nesmějí být tyto geografické názvy zobrazeny. Místní typ (localtype): Typ prvku reálného světa, ke kterému se vztahuje Geografické jméno. Tento název je stanoven publikační autoritou v nejméně jednom oficiálním jazyce Evropské Unie. Největší povolené měřítko pro zobrazení (mostdetailedviewingresolution): Největší povolené měřítko pro zobrazení Geografického jména.tj. pro větší měřítka (větší úroveň detailu) nesmějí být tyto geografické názvy zobrazeny. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 21

34 Kapitola 3. Datová specifikace Navazující prostorový objekt (relatedspatialobject): Odkaz na prvek jiného INSPIRE tématu, který identifikuje stejný objekt reálného světa. Typ (NamedPlaceTypeValue): Typ objektu reálného světa, ke kterému se vztahuje geografický název dle UNGEGN Manuálu z roku Typy jsou: Administrativní jednotka, budova, vodstvo, pokrytí území, geomorfologický prvek, osídlené a chráněné území, ostatní Datový prvek Geografické jméno (Geographical Name) Tento datový typ reprezentuje Geografické jméno tak, aby ho bylo možné efektivně použít i v jiných tématech. Na obrázku 3.8 je zobrazen UML diagram tohoto datového typu. Obrázek 3.8: Geografické jméno (Zdroj [13]). Atributy: Pravopis jména (spelling): Jedná se o složený datový typ, který reprezentuje text (samotný název), skript (pojmenování množiny glyphů použitých pro záznam, nejčastěji abeceda: latinka, řecká abeceda, cyrilice) a transakční schéma (identifikace převodní funkce/metody použité pro transformaci z jednoho skriptu do druhého, příkladem mohou být různé způsoby romanizace). Gramatický rod (grammaticalgender): Gramatický rod geografického názvu (masculine, femine, neuter, common). Gramatické číslo (grammaticalnumber): Gramatické číslo geografického názvu (singular, dual, plural). Jazyk (language): Kód jazyka dle ISO nebo ISO Stav (namestatus): Status dat vypovídající míru standardizace geografického jména (historický název, oficiální, standardizovaný a ostatní). Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 22

35 Kapitola 3. Datová specifikace Původ názvu (nativeness): Exonimum nebo endonimum. Výslovnost (pronunciation): Výslovnost geografického jména v zápisu IPA (International Phonetic Alphabet) nebo odkazu na zvukový záznam. Zdroj geografického jména (sourceofname): Označení zdroje dat geografických jmen. 3.3 Téma Katastrální Parcely (CP) Datový model tématu Katastrální parcely se skládá z jednoho typu povinného prvku (Katastrální parcela) a třech volitelných prvků (Katastrální hranice, Katastrální členění, Základní jednotka užití ). Jednotlivé typy prvků jsou odvozeny z Generického konceptuálního modelu, ze kterého přebírají některé atributy (Obrázek 3.9). Dále je prvek Katastrální členění závislý na tématu Geografických jmen. Obrázek 3.9: Schéma tématu Katastrální parcely (Zdroj [12]) Typ prvek Katastrální parcela (CadastralParcel) Katastrální parcely (Obrázek 3.10) jsou definovány v INSPIRE jako území definované katastrálním registrem nebo jeho ekvivalentem. Katastrální parcelou se dle INSPIRE rozumí polygon na povrchu země či vody, který je pod jednotným vlastnictvím. Atributy: Geometrie (geometry): Polygon nebo region reprezentující geometrii parcely. Kdy je mezi body této geometrie povolena pouze lineární interpolace. Vnější identifikátor (inspireid): Vnější identifikátor, který slouží pro jedinečnou identifikaci prvku v rámci celé INSPIRE infrastruktury. Popisek (label): Text, který se obvykle používá k označení parcely. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 23

36 Kapitola 3. Datová specifikace Obrázek 3.10: Prvek Katastrální parcela (Zdroj [12]). Odkaz do národního registru (nationalcadastralreference): Jednoznačný odkaz do národního katastru, kterým je možné získat údaje o parcele. Výměra (areavalue): Jedná se o registrovanou výměru parcely vedenou v národním registru. Referenční bod (referencepoint): Bod uvnitř parcely, k němuž je možné vztáhnout popis parcely. Začátek platnosti (validfrom): Začátek platnosti tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Konec platnosti (validto): Konec platnosti tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum vzniku (beginlifespanversion): Datum vzniku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum zániku (endlifespanversion): Datum zániku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Asociace: Odkaz na administrativní jednotku (Prvek Administrativní jednotka tématu Administrativní jednotky, Annex I.) nejnižší úrovně, jejíž součástí je parcela. Odkaz na jednu a více Základních jednotek vlastnictví. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 24

37 Kapitola 3. Datová specifikace Odkaz na nejnižší jednotku Katastrálního členění jejíž součástí je parcela. Omezení: Plocha výměry musí být zadána v metrech čtverečních. Geometrie parcely musí být typu GM_Surface nebo GM_Multisurface 1. Datum konce životního cyklu musí být větší nebo rovno datu jeho začátku. Datum konce platnosti objektu musí být větší nebo rovno datu jeho začátku. Historie: V průběhu vývoje návrhu implementace se mění povolený typ geometrie u prvku Geometrie. Poslední třetí verze návrhu povoluje tuto geometrii naplnit regionem. Dříve bylo nutné region reprezentovat jako sadu polygonů. Každý prvek obsahující polygon měl svůj vlastní vnější identifikátor (inspireid), ale odkaz do národního registru byl stejný. První a druhý návrh též obsahoval volitelnou topologii. Ve třetím návrhu však byla topologie odstraněna. Ve třetím návrhu byla též odstraněna předpokládaná přesnost parcely. Implementace: Některé státy (zejména severské) mají problém s naplněním tohoto prvku, protože ve svých katastrálních systémech se soustředí na užívací nikoliv vlastnické vztahy. Pro tyto státy je proto vhodnější využít prvku Základní jednotka vlastnictví (BasicPropertyUnit). V České republice stejně jako ve Španělsku je problém, že hranice parcel může být reprezentována kružnicí nebo kruhovým obloukem. Proto je nutné tyto geometrie před konverzí do datového modelu INSPIRE převést na požadovaný typ. Dále je v ČR, stejně jako v Nizozemí, problém se samotným sestavením geometrie parcel, protože národní registry udržují geometrii pouze jako shluk linií s odkazem na parcelu vlevo a vpravo pro každou hranici. V případě nizozemského katastru můžeme mluvit o tom, že hranice parcel jsou uloženy v topologickém systému Okřídlené hrany (Winged Edge). ČÚZK to o svých hranicích prohlašuje, ale prakticky není schopen u svých dat tento topologický model dodržet. Aby zde někomu nepřipadalo, že ČÚZK oproti jejímu nizozemskému kolegovi křivdím, je zde potřeba zmínit, že nizozemský katastr svá data ve spolupráci s univerzitou v Delftu dlouhodobě testuje (přinejmenším od roku 2003, kdy je možné dohledat první závěry testování topologie). Naproti tomu první obdobný test byl proveden na ČÚZK v listopadu roku 2009 jako nutná příprava na migraci dat z ISKN do publikační databáze (PUB-DB). Vnější identifikátor (inspireid) bude mít v ČR tvar: cz.cuzk.cp:parcela.a:v). Kde A je identifikátor parcely z Informačního Systému Katastru Nemovitostí (ISKN) a V pak značí datum vytvoření verze této parcely. 1 GM_Surface a GM_Multisurface jsou geometrická primitiva definovaná v UML modelu ISO 19107, tato primitiva mohou být namapována do GML jako gml:polygon (pouze GM_Surface do GML v.2) a gml:surface, gml:multisurface pro GML v.3. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 25

38 Kapitola 3. Datová specifikace Typ prvku Katastrální členění (Cadastral Zoning) Prvek Katastrálního členění je pomocný prvek tématu katastrální parcely. Umožňuje rozeznávat úroveň katastrálního členění, přičemž se předpokládá skladnost nižších jednotek do nadřazené jednotky. Obrázek 3.11: Prvek Katastrální členění (Zdroj [12]). Atributy: Geometrie (geometry): Jedná se o geometrii polygonu nebo regionu za použití výhradně lineární interpolace mezi body. Vnější identifikátor (inspireid): Vnější identifikátor, který slouží pro jedinečnou identifikaci prvku v rámci celé INSPIRE infrastruktury. Popisek (label): Text, který se obvykle používá k označení katastrální jednotky. Odkaz do národního registru (nationalcadastralreference). Jednoznačný odkaz do národního katastru, kterým je možné získat údaje o této katastrální jednotce. Datum vzniku (beginlifespanversion): Datum vzniku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum zániku (endlifespanversion): Datum zániku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Předpokládaná přesnost (estimate Accuracy): Předpokládanou přesností se rozumí polohová přesnost ve výchozím souřadnicovém systému a přesnost transformace do ETRS. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 26

39 Kapitola 3. Datová specifikace Úroveň jednotky Katastrálního členění (level): Úroveň Katastrálního členění, do kterého daná katastrální jednotka patří. Úroveň se zadává ve formě hodnoty z číselníku CadastralZoningLevelValue s hodnotami 1stOrder až 3thOrder. První úroveň zde značí nejvyšší úroveň Katastrálního členění a třetí nejnižší. Jméno úrovně (levelname): Jméno používané pro typ jednotky Katastrálního členění. Jméno (name): Jméno jednotky v národním registru katastrálních jednotek. Původní měřítko (originalmapscaledenominator): Původní měřítko katastrální mapy. Referenční bod (referencepoint): Bod uvnitř parcely, k němuž je možné vztáhnout popis parcely. Začátek platnosti (validfrom): Začátek platnosti tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Konec platnosti (validto): Konec platnosti tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Asociace: Odkaz na katastrální jednotku vyšší úrovně jejíž součástí tato jednotka je. Omezení: Plocha výměry musí být zadána v metrech čtverečních. Každá katastrální jednotka, která není první úrovně katastrálního členění, musí mít nadřazenou katastrální jednotku. Datum konce životního cyklu musí být větší nebo rovno datu jeho začátku. Datum konce platnosti objektu musí být větší nebo rovno datu jeho začátku. Historie: První a druhý návrh též obsahoval volitelnou topologii. Ve třetím návrhu však byla topologie odstraněna. Rozlišná implementace: Dánsko nepoužívá katastrální členění. Naproti tomu Francie používá tři úrovně členění a navíc pracuje s kontrolovanými topologickými mezerami, tedy jednotlivé katastrální jednotky na sebe nemusejí navazovat. Mnoho států bude pracovat se dvěma úrovněmi katastrálního členění, první bude obdobou české jednotky katastrální území (Cadastral District) a druhou úrovní bude rozlišení intravilánu a extravilánu. V České republice se bude až do příchodu hybridní mapy, způsobené Účelovou Katastrální mapou (ÚKM), používat pouze jedna úroveň katastrálního dělení (katastrální území). Po přijetí ÚKM bude rozhodnuto, zda přibude další úroveň nebo bude hybridní mapa poskytována jako celek. Vnější identifikátor (inspireid) bude v ČR tvar: cz.cuzk.cp:ku.a:v). Kde A je kód (šestimístné číslo) katastrálního území v Informačním Systému Katastru Nemovitostí (ISKN) a V pak značí datum vytvoření verze této jednotky. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 27

40 Kapitola 3. Datová specifikace Typ prvek Katastrální hranice (Cadastral Boundary) Prvek Katastrální hranice je pomocný prvek tématu katastrální parcely. Tento prvek by měl být poskytován pouze v případě, kdy je možné instance tohoto prvku charakterizovat absolutní přesností. Obrázek 3.12: Prvek Katastrální hranice (Zdroj [12]). Atributy: Geometrie (geometry): Jedná se o liniovou geometrii (interpolace mezi body musí být liniová) reprezentující tuto hranici. Vnější identifikátor (inspireid): Vnější identifikátor, který slouží pro jedinečnou identifikaci prvku v rámci celé INSPIRE infrastruktury. Datum vzniku (beginlifespanversion): Datum vzniku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum zániku (endlifespanversion): Datum zániku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Předpokládaná přesnost (estimateaccuracy): Předpokládanou přesností se rozumí přesnost linie ve výchozím souřadnicovém systému a přesností transformace do ETRS. Začátek platnosti (validfrom): Začátek platnosti tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Konec platnosti (validto): Konec platnosti tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 28

41 Kapitola 3. Datová specifikace Asociace: Odkaz na parcelu/parcely jejíž součástí katastrální hranice je. Omezení: Plocha výměry musí být zadána v metrech čtverečních. Datum konce životního cyklu musí být větší nebo rovno datu jeho začátku. Datum konce platnosti objektu musí být větší nebo rovno datu jeho začátku. Historie: První a druhý návrh též obsahoval volitelnou topologii. Ve třetím návrhu však topologie byla odstraněna. V prvním a druhém návrhu bylo též stanoveno pravidlo, že pokud je přesnost uvedena u jednotlivých Katastrálních hranic, není potřeba ji uvádět u prvků vyšších řádů. Po odstranění předpokládané přesnosti u prvku parcela, je možné předpokládanou přesnost přiřadit jen konkrétním hranicím nebo katastrální jednotce. Proto je pro mnohé státy výhodné jako nejnižší jednotku Katastrálního členění uvádět extravilán/intravilán. Implementace: Finsko nemá katastrální hranici s absolutní přesností. Navíc zde hranice představuje hranici mezi Základními jednotkami vlastnictví/užití. Většina států se spokojí s publikováním přesností celých datových sad (Španělsko, Slovenská republika). Česká republika má přesnost katastrální hranice charakterizovanou přesností jednotlivých lomových bodů na území digitální vektorové katastrální mapy. Při publikování hranic parcel je výhodné vytvořit nové uspořádání hranic, kde budou v maximální míře spojeny body o podobné přesnosti, protože v současném systému (ISKN) při vytváření hranic na to není brán ohled. Přesnost těchto nových hranic by pak lépe odpovídala přesnosti jednotlivých bodů. Součástí této úpravy by mělo být i pravidlo, že v průběhu hranice se nemůže měnit způsob interpolace mezi body. Nově je nutné též v ČR počítat s vektorovou účelovou mapou, kterou bude velmi těžce možné charakterizovat exaktní přesností, vzhledem ke způsobu jejího vzniku. Proto se nejspíše v ČR přistoupí k hledání dostatečně velkého čísla pro tuto přesnost, které nám bude ještě tolerováno. Touto přesností pak bude charakterizována celá datová sada. V případě, že bude ÚKM jen na části datové sady, bude možné tuto datovou sadu rozdělit na dva díly nebo publikovat dohromady s oběma přesnostmi. Zde je nutné zmínit, že se tento problém netýká pouze ČR. Podobný problém mají kupříkladu v Irsku, kde je přesnost katastrální mapy v měřítku 1:10560 (šest palců na míli) přibližně 20 metrů. Vnější identifikátor (inspireid) bude v ČR tvar: cz.cuzk.cp:hranice.a). Kde A je identifikátor hranice z publikační databáze (PUB-DB). Tedy u tohoto prvku nebude docházet k verzování. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 29

42 Kapitola 3. Datová specifikace Typ prvek Základní jednotka vlastnictví (BasicProperty- Unit) Volitelný prvek Základní jednotky vlastnictví představuje záznam v územním nebo ekvivalentním registru, který se vyznačuje unikátním vlastnictvím a homogenním vlastnickým právem nad jednou samostatnou nebo sadou sousedních nebo prostorově oddělených parcel. Jednotky vlastnictví budou v INSPIRE poskytovány pouze v případě, kdy není možné poskytovat přímo Katastrální parcely. Obrázek 3.13: Prvek Základní jednotka vlastnictví (Zdroj [12]). Atributy: Vnější identifikátor (inspireid): Vnější identifikátor, který slouží pro jedinečnou identifikaci prvku v rámci celé INSPIRE infrastruktury. Odkaz do národního registru (nationalcadastralreference). Jednoznačný odkaz do národního katastru, kterým je možné získat údaje o Základní jednotce vlastnictví. Výměra (areavalue). Jedná se o registrovanou výměru vedenou v národním katastru. Začátek platnosti (validfrom): Začátek platnosti tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Konec platnosti (validto): Konec platnosti tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum vzniku (beginlifespanversion): Datum vzniku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum zániku (endlifespanversion): Datum zániku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 30

43 Kapitola 3. Datová specifikace Asociace: Odkaz na administrativní jednotku (Prvek Administrativní jednotka tématu Administrativní jednotky, Annex I.) nejnižší úrovně, jejíž součástí je Základní jednotka vlastnictví). Omezení: Plocha výměry musí být zadána v metrech čtverečních. Datum konce životního cyklu musí být větší nebo rovno datu jeho začátku. Datum konce platnosti objektu musí být větší nebo rovno datu jeho začátku. Historie: Tento prvek je zaveden až ve třetím návrhu implementačních pravidel. Prakticky ho tedy nikdo netestoval. Implementace: Ve většině států (včetně ČR) je prvek jednotky užití totožný s parcelou. Pro ČR tedy není potřeba tento prvek implementovat! Finsko má též jednotky vlastnictví bez informace o výměře, tyto jednotky vlastnictví nebudou předmětem INSPIRE. Norsko má parcely náležící více jednotkám vlastnictví. 3.4 Téma Adresy (AD) Téma Adresy (Address) patří k jednomu z nejlépe zpracovaných témat. Samotný návrh schématu byl vypracován na základě několika dotazníků, ve kterých jednotlivé členské státy popsaly formu a pravidla tvorby adres na svém území. Zástupci téměř všech členských států, za ČR byl zástupcem Český statistický úřad, se též staly členy TWG-AD (Thematic Working Group Addresses), která nejenom tyto dotazníky proměnila ve výsledné aplikační schéma, ale též v podstatě zajistila to, že zvolená úroveň abstrakce bude dostatečná pro reprezentaci adres ve všech členských státech. Základním prvkem tohoto tématu je prvek Adresa (Address). Adresou se v tomto datovém schématu rozumí identifikace prostorového objektu na základě adresních identifikátorů jako jsou ulice, čísla domů a poštovní čísla. Ve většině členských států EU je adresa vázána na parcelu, budovu nebo její část. V některých státech jsou však adresy dostupné i pro jiné typy prostorových objektů: parkoviště, kotviště, stodoly a jiné. Mimo prvek Adresa jsou ve schématu i další významné prvky, které mají za úkol z prvku Adresa vyčlenit často opakující se lokalizační části adresy. V případě českých adres můžeme hovořit kupříkladu o názvu ulice, PSČ, obci. Samotným vyčleněním těchto prvků nejen ušetříme nějaké to místo ve výstupním souboru nebo zmenšíme objem WFS odpovědi, ale zavádíme tím i vazby, které mohou dále sloužit pro urychlení řazení, vyhledávání. Lokalizace spolu s řazením, vyhledáváním pro potřeby krizového řízení spolu s určováním soudní pravomoci patří mezi základní účely využití tohoto tématu. Mezi další prvky patří datový typ Reprezentace adresy. Tento datový typ je určen pro začlenění do jiného GML-aplikačního Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 31

44 Kapitola 3. Datová specifikace schématu. Jelikož tento datový typ nemá praktický význam pro samotné poskytování dat ve formě služby stahování, nebudeme si pro zjednodušení tento datový typ uvádět Typ prvku Adresa (Address) Prvek, který představuje Adresu jako adresovaný objekt spolu s geografickou polohou. Nebo lépe řečeno, jedná se o reprezentaci objektu reálného světa, kterému je přiřazena geografická poloha a množina položek adresy. Objekt reálného světa se zde liší v závislosti na místních zvyklostech jednotlivých členských států EU: Zatímco v ČR je adresa vztažena k budově a vstupním dveřím, ve Spojeném Království je jednotkou adresy doručovací místo a v Nizozemí je běžné též adresu vztahovat pro kotviště nebo místa určená pro dlouhodobý pobyt mobilních domů. Obrázek 3.14: Prvek Adresa (Zdroj [10]). Atributy: InspireId (inspireid): Vnější jedinečný identifikátor prostorového objektu, na který je připojena adresa. Pro lepší představu je dobré považovat tento identifikátor jako ukazatel na vchod do budovy či byt a nikoliv samostatnou budovu, protože ta je součástí jiného tématu. Pozice (position): Množina bodů na zemském povrchu, ke kterým je adresa vztažena. Položky (locator): Seřazená množina adresních klíčů a hodnot specifikující adresu. Alternativní identifikátor (alternativeidentifier): Vnější identifikátor, který umožňuje napojení na stávající (legacy) systémy. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 32

45 Kapitola 3. Datová specifikace Stav (Status): Informace o odpovídajícím stavu adresy jako celku. Povolené hodnoty jsou: Platná (current): V současnosti platná a oficiální adresa. Nepoužívaná (retired): Adresa, která již není platná nebo se nepoužívá. Navrhovaná (proposed): Adresa čekající na schválení správcem adres nebo adresa navržená správcem datové sady. Rezervovaná (reserved): Adresa rezervovaná správcem adres pro budoucí využití. Náhradní (alternative): Adresa oficiálně neschválená ale široce používaná. Začátek platnosti (validfrom): Začátek platnosti tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Konec platnosti (validto): Konec platnosti tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum vzniku (beginlifespanversion): Datum vzniku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum zániku (endlifespanversion): Datum zániku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Asociace: Odkaz na nadřazenou adresu (parentaddress). Užívá se pro modelování hlavních a podřízených adres, kdy nadřazenou adresou je adresa budovy a podřízenou adresou je adresa bytu včetně podlaží a vstupních dveří. Násobnost vazby [0-1]. Odkaz na katastrální parcelu (Prvek Katastrální parcela tématu Katastrální parcely, Annex I.), na které se adresa nachází. Násobnost vazby [0-2 ]. Odkaz na objekt Budova z Annexu III., ke ktermu se adresa vztahuje. Násobnost vazby [0- ]. Odkaz na komponenty, ze kterých se adresa skládá. Tento odkaz je do značné míry zbytečný, protože prvek Adresa agreguje komponenty v podobě atributů položek. Pro minimální nutné využití této vazby je vhodné využít odkaz na administrativní jednotku první úrovně. Násobnost vazby [1- ]. Omezení: Adresa musí nést informaci o členské zemi v rámci svých odkazů na komponenty. Adresa musí mít jednu implicitní polohu. Datum konce životního cyklu musí být větší nebo rovno datu jeho začátku. 2 Násobnost vazby značí, že lze použít libovolný počet opakování této vazby. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 33

46 Kapitola 3. Datová specifikace Implementace: Tento prvek v sobě obsahuje jiné prvky tohoto tématu přímo nebo na ně odkazuje, proto je výhodnější přímo popsat implementaci těchto prvků. Dále je nutné zmínit, že při implementaci v ČR není využita možnost hierarchického uspořádání adres a plně jsou zde využity volitelné vazby na jiná témata (Budovy a Katastrální parcely) Typ prvku Komponenta adresy (AddressComponent) Jedná se o abstraktní prvek, který je společným předkem pro všechny adresní položky. Jeho úkolem je zjednodušení a zpřehlednění návrhu schématu. Obrázek 3.15: Prvek Komponenta adresy (Zdroj [10]). Atributy: InspireId (inspireid): Vnější jedinečný identifikátor prostorového objektu. Alternativní identifikátor (alternativeidentifier): Vnější externí identifikátor komponenty adresy, který umožňuje napojení na stávající (legacy) systémy. U tohoto identifikátoru nejsou žádné další požadavky. Stav (Status): Informace o platnosti položky adresy. Je tedy možné v rámci jedné adresy publikovat různé verze komponent. Jednotlivé stavy komponent jsou stejného výčtového typu jako stavy prvku Adresa. Začátek platnosti (validfrom): Začátek platnosti tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Konec platnosti (validto): Konec platnosti tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum vzniku (beginlifespanversion): Datum vzniku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 34

47 Kapitola 3. Datová specifikace Datum zániku (endlifespanversion): Datum zániku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Asociace: Umístění v rámci (situatedwithin): Tento odkaz umožňuje lepší provázanost jednotlivých položek adresy mezi sebou. Kupříkladu je možné modelovat byt čísla 20 ležící v pátém patře budovy s číslem popisným 1526 v ulici X v rámci části obce Y v obci Z. Dědičnost (potomci): Jméno administrativní jednotky (AdminUnitName) Jméno lokality seskupující skupinu adres (AddressAreaName), toto jméno nesmí být administrativní jednotkou. Jméno komunikace (ThoroughfareName) Odkaz na Poštu (PostalDescriptor) Omezení: Datum konce životního cyklu musí být větší nebo rovno datu jeho začátku. Implementace: Tento prvek je abstraktní a proto není určen k implementaci Typ prvku Lokalita adres (AddressAreaName) Jedná se o geografické jméno charakterizující lokalitu, na které se nachází skupina adres. Toto jméno nesmí být administrativní jednotkou. Obrázek 3.16: Prvek Lokalita Adres (Zdroj [10]). Atributy: Jméno (name): Geografické jméno (Geografické jméno z tématu Geografické názvy) lokality. Asociace: Odkaz na prvek Pojmenované místo z datové sady Geografické názvy. Násobnost prvku [0..1] Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 35

48 Kapitola 3. Datová specifikace Implementace: Pro adresy České republiky je vhodné tento prvek použít pro část obce, protože ta není dle INSPIRE součástí administrativního členění Typ prvku Jméno administrativní jednotky (AdminUnit- Name) Jedná se o geografické jméno charakterizující administrativní jednotku, která je komponentou adresy. Obrázek 3.17: Prvek Jméno admin. jednotky (Zdroj [10]). Atributy: Jméno (name): Geografické jméno (Geografické jméno z tématu Geografické názvy) administrativní jednotky. Úroveň (level): Úroveň administrativní jednotky. Asociace: Odkaz na Administrativní jednotku (Prvek Administrativní jednotka tématu Administrativní jednotky, Annex I.). Násobnost prvku [1] Implementace: Pro adresy České republiky budou používány odkazy na administrativní jednotky obce, kraje a státu Typ prvku Odkaz na Poštu (Postal Descriptor) Jedná se o geografické jméno charakterizující rozdělení adres v rámci členských států pro potřeby poštovní doručovací služby. Obrázek 3.18: Prvek Odkaz na Poštu (Zdroj [10]). Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 36

49 Kapitola 3. Datová specifikace Atributy: Jméno pošty (postname): Geografické jméno (Geografické jméno z tématu Geografické názvy) administrativní jednotky. Kód pošty (postcode): Alfa-numerický řetězec reprezentující poštu dle národních zvyklostí. Omezení: Jméno pošty, pokud existuje, nesmí být prázdné. Kód pošty, pokud existuje, nesmí být prázdný. Implementace: Pro adresy České republiky bude tento prvek použit a bude pomocí něj publikováno poštovní směrovací číslo (PSČ) Typ prvku Jméno komunikace (Throughfare name) Jedná se o geografické jméno charakterizující komunikaci (silnici, říční cestu), která je komponentou adresy. Obrázek 3.19: Prvek Jméno komunikace (Zdroj [10]). Atributy: Jméno (name): Geografické jméno (Geografické jméno z tématu Geografické názvy) cesty. Asociace: Odkaz na transportní objekt ze schématu Transportní Sítě. Implementace: Pro adresy České republiky bude tento prvek použit pro označení ulice adresy. Odkaz na schéma INSPIRE Transportních Sítí je možný pouze při zachování identifikátorů mezi systémy ISÚI a ZABAGED. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 37

50 Kapitola 3. Datová specifikace Datový prvek Položka adresy (AddressLocator) Jedná se o účelově vytvořený datový typ, který má za úkol zjednodušit návrh pomocí kompozice, kdy tento datový typ může nabývat hodnoty Položka jméno (LocatorName) nebo Položka označení (LocatorDesignator). Tento datový typ je využit pouze v rámci prvku Adresa, kde slouží k uspořádanému seskupení všech položek adresy. Samotné řazení však není jediným důvodem, který vedl ke zvolení tohoto způsobu implementace. Další možností, jak daný problém řešit, by bylo použití dědičnosti. Ta by však nutně vedla ke správě jednotlivých položek mimo adresu, což je krajně nevhodné, protože by to vedlo k vytváření velkého množství naprosto zbytečných vnějších identifikátorů (inspireid). Obrázek 3.20: Prvek Položka adresy (Zdroj [10]). Atributy: Označení (designator): Číslo nebo sekvence znaků, která slouží jako položka adresy. Jméno (name): Geografické jméno nebo popisný text, který slouží jako položka adresy. Úroveň (level): Úroveň lokátoru slouží k hierarchickému uspořádání jednotlivých položek. Kupříkladu položka reprezentující domovní číslo je v hierarchii výše než položka reprezentující číslo bytu. Asociace: Odkaz na komponentu adresy v rámci které je tato položka jedinečná. Omezení: Pokud neexistuje atribut jmenovka, pak musí existovat a musí být vyplněn atribut jméno. Pokud neexistuje atribut jméno, pak musí existovat a musí být vyplněn atribut jmenovka. Implementace: Použití tohoto datového prvku je nezbytné pro zápis prvku Adresa. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 38

51 Kapitola 3. Datová specifikace Datový typ Položka označení (LocatorDesignator) Jedná se o položku adresy, která je reprezentována číslem nebo řetězcem znaků. Příkladem takových položek je číslo domovní, číslo popisné, písmeno popisné, číslo bytu a jiné. Obrázek 3.21: Datový typ Položka označení (Zdroj [10]). Atributy: Označení (designator): Číslo nebo sekvence znaků, která slouží jako položka adresy. Typ (type): Kategorie pod kterou toto označení patří. Povolené typy jsou: addressidentifiergeneral: Identifikátor adresy skládající se z písmen a číslic. addressnumber: Identifikátor adresy skládající se pouze z číslic. addressnumberextension: Druhá přípona identifikátoru adresy. addressnumber2ndextension: Přípona identifikátoru adresy. buildingidentifier: Identifikátor budovy skládající se z písmen a číslic. buildingidentifierprefix: Předčíslí identifikátoru budovy. entrancedooridentifier: Identifikátor vstupních dveří, vrat nebo jiného vstupu. staircaseidentifier: Identifikátor schodiště. flooridentifier: Identifikátor podlaží nebo úrovně uvnitř budovy. unitidentifier: Identifikátor dveří, apartmá, pokoje nebo jiného příbytku nalézajícího se uvnitř budovy. postaldeliveryidentifier: Identifikátor poštovního doručovacího místa. kilometrepoint: Číselná hodnota podélného odsazení měřená po komunikaci od bodu s nultým odsazením silnice. corneraddress1stidentifier: Identifikátor vztažený k primární komunikaci pro rohové adresy. corneraddress2ndidentifier: Identifikátor vztažený k sekundární komunikaci pro rohové adresy. Implementace: Pro adresy České republiky bude tento prvek použit na reprezentaci domovního čísla (buildingidentifier), typu čísla domovního (buildingidentifierprefix), čísla (addressnumber) a písmene orientačního (addressnumberextension). Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 39

52 Kapitola 3. Datová specifikace Datový typ Položka jméno (LocatorName) Jedná se o položku adresy, která je reprezentována geografickým jménem. Obrázek 3.22: Prvek Položka jméno (Zdroj [10]). Atributy: jméno (name): Geografické jméno, které slouží jako položka adresy. typ (type): Kategorie pod kterou toto označení patří. Povolené typy jsou: sitename: Lokátor (specifikátor polohy) identifikující pozemek, budovu nebo jiný objekt užitím čísla adresy, čísla budovy nebo jména budovy či objektu. accesslevel: Lokátor (specifikátor polohy) identifikující speciální přístup k pozemku, budově a jiným užitím vstupních dveří nebo podobného identifikátoru. unitlevel: Lokátor (specifikátor polohy) identifikující speciální část budovy. postaldeliverypoint: Lokátor (specifikátor polohy) identifikující poštovní doručovací místo. Implementace: Pro Adresy ČR tento datový typ nebude použit. 3.5 Téma Administrativní jednotky (AU) Téma Administrativních jednotek je součástí prvního Annexu, protože toto téma je chápáno jako referenční téma, které definuje prostorový rámec, do kterého se napojují a v jehož rámci existují ostatní témata. Hlavní užití tohoto tématu jsou: Hledání a filtrování ostatních témat na základě příslušnosti k administrativní jednotce. Publikování a spojování ostatních témat. Vyhledání odpovědných orgánů pro potřeby ochrany prostředí, živelných pohrom,... Jako další se počítá pro využití různých kontrol využívající geometrickou část administrativních hranic, jako jsou geometrické kontroly a správnost klasifikace (tj. náležitost tematického prvku do administrativní jednotky). INSPIRE rozeznává hierarchické uspořádání administrativních jednotek, přičemž předpokládá, že nadřazená administrativní jednotka se skládá z jedné či více úplných administrativních jednotek nižšího stupně (tj. úplná skladnost administrativních jednotek). Pro potřeby Annexu I. téma Administrativní jednotky rozeznává čtyři datové prvky: Administrativní území, Administrativní hranice, Kondominium a NUTSRegion. NUTSRegion je prvek aplikačního schématu statistické jednotky, který je připravován do třetího Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 40

53 Kapitola 3. Datová specifikace Obrázek 3.23: Schéma Administrativní jednotky (Zdroj [11]). Annexu. Téma Administrativní jednotky však potřebuje pracovat s odkazem na tento typ prvku. Proto je tento prvek potřeba deklarovat dopředu bez toho, aniž by zde byla jeho implementace. Téma Administrativní jednotky dále pracuje s prvkem Geografické jméno z tématu Geografické názvy z Annexu I. Nutnou závislost na Generickém konceptuálním schématu (Obrázek 3.23) není potřeba zmiňovat Prvek Administrativní jednotka (Administrative Unit) Jedná se o základní prvek schématu Administrativní jednotky. Tento prvek (Obrázek 3.24) představuje prostorově vymezenou část zemského povrchu, na kterém má nebo vykonává členský stát (nebo jeho část) soudní moc. Atributy: Geometrie (geometry): Geometrická reprezentace obvodu administrativní jednotky v podobě polygonu/regionu tvořených pouze liniovou interpolací mezi body. Národní kód (nationalcode): Národní identifikátor definovaný členským státem, pro tento kód nejsou definována žádná pravidla. Toto lze využít při neplatnosti skladnost jednotek. Tedy jednotku nižší úrovně lze rozdělit a publikovat v INSPIRE po částech tak, aby bylo dodrženo INSPIRE pravidlo skladnosti. Vnější identifikátor (inspireid): Vnější identifikátor, který slouží pro jedinečnou identifikaci prvku v rámci celé INSPIRE infrastruktury a snadné napojení ostatních témat. Národní úroveň (nationallevel): Úroveň administrativního členění, do kterého daná administrativní jednotka patří. Úroveň se zadává ve formě hodnoty z číselníku Admini- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 41

54 Kapitola 3. Datová specifikace Obrázek 3.24: Prvek Administrativní jednotka (Zdroj [11]). strativehierarchylevel s hodnotami 1stOrder až 6thOrder. První úroveň zde značí nejvyšší úroveň administrativního dělení a šestá nejnižší. Kód státu (country): Dvojpísmenná zkratka dle Publikační kanceláře Evropské Unie. Jméno (name): Oficiální jméno administrativní jednotky, publikované v požadovaném počtu úředních jazyků. Jméno administrativní úrovně (nationallevelname): Jméno administrativní úrovně dle členského státu. Tento atribut představuje určité zjednodušení objektového modelu. Správně by tento údaj měl být v číselníku administrativních úrovní. Dále je dobré si všimnout, že je zde použit datový typ LocalisedCharacterString a ne geografické jméno, protože název úrovně není většinou spjat s konkrétním objektem (výjimkou je administrativní úroveň jedna). Sídlo správního úřadu (residenceofautority): Jedná se o datový typ charakterizující geografické jméno (Téma GN Annexu I.) a polohu (bod na zemském povrchu). Opět zde platí, že zde nejsou žádné kontroly: Poloha sídla správního úřadu může být mimo administrativní jednotku, více administrativních jednotek může mít stejný správní úřad. Datum vzniku (beginlifespanversion): Datum vzniku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum zániku (endlifespanversion): Datum zániku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 42

55 Kapitola 3. Datová specifikace Asociace: Odkaz na Kondominium administrované touto Administrativní jednotkou. Odkaz na Administrativní jednotku/y o jednu nižší administrativní úrovně, ze které/ých se tato jednotka skládá. Odkaz na Administrativní jednotku o jednu vyšší administrativní úrovně, která tuto jednotku obsahuje. NUTS: Odkaz na nejnižší statistickou jednotku NUTS1-3, která obsahuje tuto administrativní jednotku. V případě ČR je to odkaz na NUTS3 (Kraj) nebo na NUTS1 (Stát). Odkaz na prvek Administrativní jednotka stejné administrativní úrovně, která administruje tuto jednotku. Tento odkaz pouze umožňuje snadné vyhledávání a filtrování již zmíněných duplicit sídla správního úřadu. Odkaz na Administrativní jednotku stejné administrativní úrovně, která je administrována touto jednotkou. Odkaz na jednotlivé Administrativní hranice vymezující tuto administrativní jednotku. Omezení: Jednotka první úrovně má nulový počet nadřazených jednotek a nenulový počet jednotek nižší úrovně. Jednotka šesté úrovně má nulový počet jednotek nižší úrovně. Odkaz na Kondominium může existovat jen pro jednotky první úrovně. Implementace: Pouze tři státy (FR, DE, UK) využijí dělení do všech šesti úrovní administrativního dělení. Většina států využije tři až čtyři úrovně, ale kupříkladu Malta si vystačí pouze se dvěma úrovněmi. Česká republika bude publikovat administrativní jednotky ve čtyřech úrovních: První (nejvyšší) úrovní bude úroveň státu (NUTS1), druhá úroveň bude představovat kraje (NUTS3), třetí úroveň pak dělení do okresů (LAU1)a poslední čtvrtá bude odpovídat obcím (LAU2). V rámci publikace administrativních jednotek ČR nebude možné publikovat atribut sídla správního úřadu, protože tento údaj, včetně své polohy, není v systémech ČÚZK obsažen. U prvku Administrativní jednotky je nezbytně nutné volit vnější identifikátory (inspireid) tak, aby bylo možné odkazovat se z jiných témat na tyto administrativní jednotky. Vnější identifikátor (inspireid) u Administivních jednotek bude proto na ČÚZK publikován v tomto tvaru: cz.cuzk.au:a.b:c (výjimku bude tvořit administrativní jednotka státu, která bude mít tvar: cz.cuzk.au.cr:v). Kde A je označení příslušné úrovně administrativní jednotky (NUTS1, NUTS3, LAU1, LAU2), B je číslo z číselníku ČÚZK pro jednotlivé administrativní jednotky. Tyto číselníky ČÚZK dodává spolu s daty i svým partnerům a nově budou ke stažení z Geoportálu ČÚZK. Poslední V značí datum vytvoření verze této administrativní jednotky. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 43

56 Kapitola 3. Datová specifikace Prvek Administrativní hranice (Administrative Boundary) Obrázek 3.25: Prvek Administrativní hranice (Zdroj [11]). Jedná se prvek reprezentující takovou část hranice administrativních úrovní, kde nedochází ke změně nejnižší administrativní jednotky napravo/nalevo. Vzhledem k tomu, že INSPIRE předpokládá úplnou skladnost administrativních jednotek, platí, že v průběhu administrativní hranice se nesmí měnit ani jediná množina administrativních jednotek všech úrovní napravo/nalevo od této hranice. Výše uvedené platí pouze v rámci jednotlivých států pro jednotky úrovně dva a nižší. Dále je definováno, že libovolné trojmezí jednotek první úrovně nesmí být kříženo průběhem administrativní hranice. Tedy administrativní hranice nikdy neprocházejí trojmezím států, ale na tomto místě vznikají a zanikají. Atributy: Geometrie (geometry): Geometrická reprezentace administrativní hranice v podobě lomené čáry (oblouky ani jiný typ nelineární interpolace mezi body) není povolen. Vnější identifikátor (inspireid): Vnější identifikátor, který slouží pro jedinečnou identifikaci prvku v rámci celé INSPIRE infrastruktury. Na rozdíl od prvku Administrativní jednotky, se zde nepředpokládá, že se na typ objektu Administrativní hranice bude potřeba odkazovat z jiného tématu. Vnější identifikátor (InspireId) je zde tedy uveden jen pro umožnění obousměrné vazby Administrativní jednotkou a jejích hranic. Kód státu (country): Dvojpísmenná zkratka dle Publikační kanceláře Evropské Unie. Národní úroveň (nationallevel): Všechny úrovně administrativního členění, pro které administrativní hranice vytváří geometrii. Právní stav (legalstatus): Technický stav byl odsouhlasen (agreed) oběma dotyčnými administrativními jednotkami nejnižší úrovně nebo není odsouhlasen (notagreed). Technický stav (technicalstatus): Průběh hranice je (edgematched) nebo není (noedge- Matched) sladěn pro administrativní jednotky vpravo a vlevo od administrativní hranice. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 44

57 Kapitola 3. Datová specifikace Datum vzniku (beginlifespanversion): Datum vzniku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum zániku (endlifespanversion): Datum zániku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Asociace: Odkaz na administrativní jednotku, pro kterou tato Administrativní hranice vytváří geometrii. Implementace: Z datové specifikace tématu Administrativní jednotky vychází tento prvek jako povinný. Na druhou stranu, a po konzultaci s tvůrci této datové specifikace v JRC (Join Research Center), byla shledána možnost tento prvek v počátečním provozu neposkytovat, pokud bude zajištěna topologicky kvalitní geometrie u samotných administrativních jednotek. Pro implementaci v ČR bude nejjednodušší tento prvek odvodit od polygonů jednotlivých administrativních jednotek a doplnit tento algoritmus o další dělení administrativních hranic na bodě trojmezí států. První část algoritmu jsem již v minulosti úspěšně vytvořil a tato implementace je též více než čtyři roky na ČÚZK používána pro generování administrativních hranic systému ArchivWeb. Vnější identifikátor (InspireId) u administrativních hranic není potřeba volit se stejnou obezřetností jako u Administrativních území. Pro data ČÚZK bude tedy vnější identifikátor (inspireid) mít jednoduchý tvar cz.cuzk.au:hranice.x, kde X bude reprezentováno číslem určujícím chronologické pořadí vytvoření linie v rámci všech linií hranic. Pro tento prvek tedy nebude udržována informace o verzi, ale v případě změny (například doplnění bodu na hranici) bude původní hranice zrušena a místo ní přibude úplně nová hranice. Je to z toho důvodu, že samotná Administrativní hranice je jen odvozený údaj z prvku Administrativní jednotka, nad kterým dochází k verzování a z něhož je možné vždy tuto hranici odvodit a je možné mu přidělit i jiný vnější identifikátor (inspireid), protože je zde použita vnitřní vazba mezi objekty Typ prvku Kondominium (Condominium) Prvek Kondominium představuje administrativní oblast, která je nezávislá na jakémkoliv národním administrativním dělení území v daném státu a je administrována dvěma a více státy. Kondominium je zajímavé tím, že by mělo být publikováno více státy: Pokud se státy nedohodnou, tak i různými vnějšími identifikátory (inspireid). Atributy: Vnější identifikátor (inspireid): Vnější identifikátor, který slouží pro jedinečnou identifikaci prvku v rámci celé INSPIRE infrastruktury. Geometrie (geometry): Geometrická reprezentace v podobě polygonu/regionu tvořených liniemi. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 45

58 Kapitola 3. Datová specifikace Obrázek 3.26: Prvek Kondominium (Zdroj [11]). Jméno (name): Oficiální jméno Kondominia, publikované v požadovaném počtu úředních jazyků. Datum vzniku (beginlifespanversion): Datum vzniku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Datum zániku (endlifespanversion): Datum zániku tohoto prvku nebo jeho verze v rámci infrastruktury INSPIRE. Asociace: Minimálně jedno administrativní území spravující toto kondominium. Přestože je kondominium spravované dvěma a více státy, je zde ponechána možnost opublikovat jen jeden odkaz na administrativní jednotku, kterou je toto kondominium spravováno. Implementace: Pro data České republiky tento prvek nebude publikován. V ostatních státech bude tento prvek využit podle potřeby jak pro kondominium na pevnině tak i kondominium moří a hraničních jezer. 3.6 Metadata datových sad Jak již bylo řečeno v kapitole o INSPIRE (kapitola 2) datové sady a služby mají v infrastruktuře INSPIRE svá metadata. My se zde soustředíme na metadata datových sad. Tato metadata můžeme rozdělit do tří skupin. V první skupině jsou metadata společná pro všechna témata, těchto metadat je celkem 19. Druhým typem je metadatový profil poskytovatele, který by měl vhodně rozšiřovat společná metadata. ČÚZK má svůj vlastní metadatový profil, avšak v této práci se jím nebudeme zabývat, kvůli jeho rozsahu a především kvůli tomu, že autor této práce nebyl a není součástí týmu, který daný profil sestavil. Obecně lze říci, že projekt INSPIRE je na ČÚZK rozdělen do práce několika týmů, které vykonávají činnost odděleně (tým metadatového profilu, tým pro testování datové specifikace, tým definující smlouvy), všechny výbory jsou pak zastřešeny Řídícím výborem. Tento model je samozřejmě výhodný, ale principiálně má svá úskalí, protože nezajišťuje, že jednotliví řadoví členové jednoho týmu budou znát výsledky nebo budou vůbec mít ponětí o existenci jiného týmu. Třetím typem metadat jsou metadata specifická pro jednotlivá Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 46

59 Kapitola 3. Datová specifikace témata, tato metadata jsou popsána vždy v datové specifikaci daného INSPIRE tématu. Tato speciální metadata dále můžeme dělit na metadata povinná (podmíněná) a volitelná Metadata společná všem tématům Název zdroje (Resource title)[1] 3 : Název zdroje dat pro metadata. Popis zdroje (Resource abstrakt)[1]: Popis datové sady. Typ zdroje (Resource type)[1]: Typ zdroje dat pro metadata (datová sada, datová série, služba). Odkaz na zdroj (Resource locator)[0..*]: Přímý odkaz na zdroj dat pro metadata. Pokud není možné uvést přímý odkaz na zdroj, poskytuje se zde kontakt, kde je možné získat více informací o zdroji. Unikátní identifikátor zdroje (Unique resource identifier)[1..*] : Unikátní identifikátor zdroje metadat včetně svého jmenného prostoru. Jazyk zdroje (Resource language)[0..*]: Jazyk používaný v rámci datové sady. Prvek je povinný pro všechny datové sady, které obsahují textové informace. Zkratky jazyků jsou zapsány v ISO Kategorie tématu (Topic category)[1..*]: Téma datové sady. Je možné použít jména datových sad INSPIRE. Klíčová slova (Keyword)[1..*]: Klíčová slova používaná pro popis prvků nebo celé datové sady. Opsaný obdélník (Geographic bounding box)[1..*]. Opsaný obdélník datové sady v zeměpisných souřadnicích. Časový rozsah (Temporal Reference)[1..*]: Časový interval platnosti dat. Původ (Lineage )[1]. Obecný popis původu dat. Prostorové rozlišení (Spatial resolution )[0..*]: Informace o měřítku, ve kterém byly tato data získávána. Shoda s prováděcími pravidly (Conformita )[1]: Prohlášení o míře shody s prováděcími pravidly INSPIRE. Podmínky přístupu a užití (Conditions for access and use)[1..*]: Omezení, která se vztahují k přístupu k datům i samotným metadatům. Omezení přístupu (Limitations on public access)[1]: Omezení, která je nutná respektovat při přístupu k datům a nakládání s nimi. 3 Značí násobnost metadatového záznamu Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 47

60 Kapitola 3. Datová specifikace Zodpovědná organizace (Responsible organisation )[1..*]: Organizace zodpovědná za data. Může zde být uvedeno i více organizací, pak je ale velmi výhodné tyto organizace oddělit rolemi. Kontakt v metadatech (Metadata point of contact )[1..*]: Kontakt na organizaci zodpovědnou za metadata. Datum metadat (Metadata date)[1]: Datum vytvoření metadat. Datový typ je gmd:datestamp jehož podelementem je gco:date nebo gco:datatime. Datum vytvoření metadat je tedy možné uvést. Jazyk metadat (Metadata language )[1]: Jazyk použitý pro popis metadat. Zkratka jazyka je dle ISO Povinná a podmíněná metadata pro témata Katastrální parcely, Administrativní jednotky, Adresy a Geografické názvy Souřadnicový systém (Coordinate Reference System): Souřadnicový systém použitý pro data datové sady. Časový systém (Temporal Reference System): Prvek označující časový referenční rámec. Používá se pouze v případě, že se v datech datové sady vyskytují i časové informace v jiném než Gregoriánském kalendáři nebo UTC. Kódování (Encoding): Popis formálního jazyka použitého pro zápis datové sady. Popis obsahuje téma a verzi INSPIRE aplikačního schématu a verzi GML gramatiky použité pro zápis. Kódování znaků (Character Encoding): Plný název způsobu kódování znakové sady použité pro zápis datové sady. Tento prvek je povinný, pokud není zápis prováděn v jazyce XML a bez použití kódování UTF-8. Tento prvek není možné použít pro téma Katastrální parcely Volitelná metadata přidaná k jednotlivým tématům K jednotlivým tématům se podle potřeby přidávají další metadatové elementy. Tato přidaná metadata většinou patří do oblasti datové kvality (Data Quality), výjimku tvoří informace o obnově dat. Informace o obnově dat (Maintenance information)[0..1]: Informace o rozsahu a intervalu obnovy dat v příslušné datové sadě. Implementace v ČR (ČÚZK): Všechna témata: Data jsou aktualizována inkrementálně v intervalu cca 2 hodiny - 1 den. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 48

61 Kapitola 3. Datová specifikace Počet nadbytečných položek (Rate of excess items): Počet položek, které se nalézají v datové sadě, ale nepatří sem ve vztahu ke všem položkám, které by v datové sadě měly být přítomny. Může se jednat jak o položky, které měly být již zrušeny, tak i o položky, které patří do jiné datové sady. Implementace v ČR (ČÚZK): Adresy a Administrativní jednotky: U systémů (ISÚI) poskytující informace do INSPIRE se předpokládá aktuálnost dat, proto zde neexistuje jakýkoliv mechanismus jak s takovými položkami pracovat. Jediná možnost, jak takovou informaci do metadat zapsat, je zvolit dostatečně reprezentativní hodnotu, na základě znalosti chyb vstupních systémů, ze kterých byl ISÚI naplněn. Počet chybějících položek (Rate of missing items): Počet chybějících položek v datové sadě ve vztahu k celkovému počtu všech položek, které by měly být v datové sadě přítomny. Implementace v ČR (ČÚZK): Katastrální parcely: Počet parcel, které se nepodařilo kvůli chybám v geometrii a topologii převést do publikační databáze. Adresy: Počet chybějících Adres. Pro praktické řešení lze stanovit dostatečně reprezentativní hodnotu na základě znalosti kvality dat zdrojů adres pro ISÚI. Nebo využít statistik Návrhů Změn v systému RÚIAN. Administrativní jednotky: Není stanoveno, protože systém RÚIAN by měl obsahovat všechna potřebná data. Střední polohová nejistota (Mean value of positional uncertainies): Střední hodnota polohové nejistoty pro množinu prvků. Míra polohové nejistoty představuje vzdálenost mezi měřenou a skutečnou pozicí. Implementace v ČR (ČÚZK): Katastrální parcely: Přesnost stanovena přímo pro jednotlivé hranice parcel, do budoucna je potřeba pouze vyřešit tento metadatový údaj pro Účelovou Katastrální Mapu (ÚKM). Adresy a Administrativní jednotky: Není stanoveno. Počet špatných napojení bodů na linie (Number of fault point-curve connections): Tento typ chyby se týká pouze tématu Administrativních Jednotek. Příklady takové chyby jsou na obrázku 3.27/b-c. Kdy na obrázku 3.27/b máme zobrazeny hranice čtyř obcí (e 1, e 2, e 3, e 4 ) oranžovou barvou, zelená hranice pak představuje hranici okresů. A právě tato hranice obsahuje špatné napojení mezi bodem a linií. Dalším příkladem takové chyby je obrázek 3.27/c, kde se jedna linie nenapojuje na druhou linii na jejím konci (tak jak je to definované v požadavcích datové specifikace tématu Administrativních Jednotek). V datech ČÚZK k takovýmto chybám může dojít v případě konverze dat ISÚI do datové specifikace INSPIRE pouze tehdy, pokud geometrie administrativních jednotek v ISÚI není skutečně skladebná. Počet chybějících napojení (number of missing connection due to undershoots): Nedotah (chybějící napojení) je chyba zobrazená na obrázku 3.27/a. Tento metadatový element je možné zapsat jen u metadat tématu Administrativních Jednotek. V datech Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 49

62 Kapitola 3. Datová specifikace ČÚZK k takovému typu chyb dle současného schváleného datového modelu nemůže dojít. Konceptuální konzistence (Conceptual schema compliance): Počet položek datové sady (pouze pro téma Adresy), které nejsou ve shodě s konceptuálním modelem INSPIRE. Poměr položek se špatným typem hodnoty (Domain consistency): Počet položek v tématu Adresy, které mají hodnotu atributu jiného typu, než je povolený typ INSPIRE. Počet položek s chybou v zápise životního cyklu (Percentage of items that are correctly events ordered): Tato chyba se týká pouze tématu Adresy. Chyba se týká stavu, kdy jedna z komponent adresy může zaniknout (endlifespanversion) dříve, než vzniká prvek Adresa. Poměr špatných atributů (Rate of incorrect attributes names values): Počet atributů, které obsahují špatně přiřazenou hodnotu ku všem atributům v datové sadě. Tento metadatový element může být použit jen u tématu Adresy. Obrázek 3.27: Topologické chyby Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 50

63 Kapitola 4. Geography Markup Language Kapitola 4 Geography Markup Language GML je Open Geospital Consorcium (OGC) norma, která definuje modelový jazyk (XML gramatiku) pro vyjádření formátů prostorových dat (nebo obecněji formátů pracujících s prostorovou informací). Ve svých počátcích bylo GML definováno pomocí Resource Description Framework (RDF) konsorcia W3C. Od verze dva je pak nově založeno na XML schématech, což přináší výhodu při konverzi dat z/do stávajících databází prostorových dat. Pomocí GML je možné definovat konkrétní aplikační schémata, která představují formáty/protokoly pro uchování dat s prostorovou informací. Základním objektem aplikačního schématu je prvek GML (GML Feature), který představuje fyzickou entitu jako je budova, řeka atd., přičemž je stanoveno, že každý GML prvek může, ale nemusí mít geometrická nebo jiné základní GML primitiva. Mezi základní GML primitiva patří: vektorová i bitmapová geometrie, topologie, definice souřadnicového systému, měřené veličiny, orientace, fyzikální jednotky, čas, dynamické prvky a zobrazovací styly. Jelikož je samotné aplikační schéma jen konkrétním XML schématem, máme zde k dispozici X Linking Language (xlink), který výrazně zjednodušuje vazby mezi prvky GML. Tedy obdobu asociace v UML nebo sekundárního klíče v ER schématech. S ohledem na blízkost GML a databázových schémat je vhodné též zmínit jeden speciální GML atribut a tím je gml:id; tedy unikátní klíč, který musí být jedinečný v rámci celého GML souboru a to pro všechny typy GML prvků. Úkolem této kapitoly není přiblížit úvod do jazyka GML, protože pak by bylo nezbytně nutné čtenáři důkladně objasnit samotnou technologii XML a XML schémata (XSD), pomocí nichž je GML definované. V této kapitole si představíme některé základní a stavební prvky jazyka GML, které jsou nebo by mohly být využity v rámci INSPIRE. 4.1 Stereotyp «voidable» Jak již bylo zmíněno v Generickém konceptuálním modelu, některé atributy objektů v jednotlivých UML modelech mohou být označeny stereotypem «voidable». Ten značí, že daný atribut může být prázdný za předpokladu, že je uveden důvod nevyplnění tohoto atributu. Předpokládejme jednoduchý objekt reprezentující stánek se zmrzlinou. Pro zjednodušení zde budeme uvažovat dva atributy: název stánku a typ nabízené zmrzliny. Nejprve tedy vytvoříme příslušné XML schéma v příkladu 4.1 a následně pak pro něj uvedeme jednotlivé příklady Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 51

64 Kapitola 4. Geography Markup Language Příklad 4.1: GML schéma stánku se zmrzlinou: <? xml version =" 1.0 " encoding ="UTF -8"?> <schema xmlns =" http :// / 2001 / XMLSchema " xmlns : gml =" http :// www. opengis. net / gml / 3.2 " xmlns : base =" urn :x- inspire : specification : gmlas : BaseTypes : 3.2 " xmlns : shops =" Shops : 1.0 " elementformdefault =" qualified " targetnamespace =" Shops : 1.0 " version =" 1.0 "> <import namespace =" http :// www. opengis. net / gml / 3.2 " schemalocation ="./ gml / / gml. xsd "/> <import namespace =" urn :x- inspire : specification : gmlas : BaseTypes : 3.2 " schemalocation =" BaseTypes. xsd "/> < element name =" IceCreamStall " substitutiongroup =" gml : AbstractFeature " > < annotation > < documentation > Stánek se zmrzlinou </ documentation > </ annotation > < complextype > < complexcontent > < extension base =" gml : AbstractFeatureType " > < sequence > < element minoccurs ="0" name =" ownername " type =" string "></ element > < element minoccurs ="0" name =" icecreamtype " nillable =" true "> < complextype > < simplecontent > < extension base =" string "> < attribute name =" nilreason " type =" gml : NilReasonType "/> </ extension > </ simplecontent > </ complextype > </ element > </ sequence > </ extension > </ complexcontent > </ complextype > </ element > </ schema > Jednotlivé příklady Příklad 4.2: Stánek s nabídkou třech druhů zmrzlin: <Shops : IceCreamStall gml :id=" bohatá_nabídka "> < ownername > Šmejkal < ownername > < icecreamtype > Mrkvová < icecreamtype / > < icecreamtype > Jahodová < icecreamtype / > < icecreamtype > Vanilková < icecreamtype / > <Shops : IceCreamStall /> Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 52

65 Kapitola 4. Geography Markup Language Příklad 4.3: Stánek bez zmrzliny (minimální počet atributů zmrzlina je nulový): <Shops : IceCreamStall gml :id=" škrt "> < ownername > Volfová < ownername > <Shops : IceCreamStall /> Příklad 4.4: Stánek, u kterého neevidujeme, zda se zde prodává zmrzlina (kupříkladu ortodoxně nanukový stánek): <Shops : IceCreamStall gml :id=" nikdo_neví ">> < ownername >Novák < ownername > < icecreamtype xsi : nil =" true " nilreason =" missing "/> <Shops : IceCreamStall /> Příklad 4.5: Nebo pomocí zkráceného zápisu <Shops : IceCreamStall gml :id=" nikdo_neví ">> < ownername >Novák < ownername > < icecreamtype nilreason =" missing "/> <Shops : IceCreamStall /> 4.2 INSPIRE versus GML identifikátory InspireId je jedinečný identifikátor objektu v rámci celé INSPIRE infrastruktury. Pokud mají dva objekty stejného typu stejný InspireId, jedná se o stejné objekty reálného světa v různých verzích. Pro jejich rozlišení je vhodné použít atributy označené stereotypem lifecycleinfo. Zápis INSPIRE identifikátoru (Příklad 4.6) je dán přímo v generickém konceptuálním modelu, kde se INSPIRE identifikátor skládá ze dvou povinných částí: LocalID - jedná se o jedinečný identifikátor v rámci tohoto tématu a poskytovatele dat a Namespace, který představuje složený identifikátor poskytovatele a tématu. Dále je ještě možné specifikovat volitelný element verze. Způsob zápisu (Příklad 4.7), jakým je možné odkazovat na tento identifikátor, je stanoven v doprovodném dokumentu Guidelines for the encoding of spatial data (zdroj [5]). Zde je nutné zmínit, že zápis odkazu musí být explicitně stanoven, protože pro tento složený identifikátor není možné použít standardní chování technologie xlink. Příklad 4.6: Zápis INSPIRE identifikátoru pro jedno katastrální území: <CP: inspireid > <base : Identifier > <base : localid >Zone </ base : localid > <base : namespace >CZ. CUZK.KN </ base : namespace > </ base : Identifier > </CP: inspireid > Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 53

66 Kapitola 4. Geography Markup Language Příklad 4.7: Odkaz na INSPIRE identifikátor: <zone xlink : href =" urn :x- inspire : object :id:cz. CUZK.KN: Zone "/> Naproti tomu gml:id představuje jedinečný identifikátor pouze v rámci jednoho GML dokumentu. Tento atribut musí být uveden v rámci každého GML prvku aplikačního schématu a u geometrických elementů a jiných GML primitiv. Příklad 4.8 představuje zápis takového identifikátoru pro prvek Katastrální parcely a její geometrie. Příklad 4.9 pak znázorňuje zápis odkazu na tuto parcelu. Příklad 4.8: Ukázka zápisu gml:id u prvku a jeho atributu: <CP: CadastralParcel gml :id=" CP1 ">... <CP: beginlifespanversion > T08 :59:43 </CP: beginlifespanversion > <CP: geometry > <gml : Polygon srsname =" urn : ogc : def : crs : EPSG : 2065 " gml :id=" Polygon_1 ">... </ gml : Polygon > </CP: geometry >... </ CP: CadastralParcel > Příklad 4.9: Ukázka zápisu odkazu na gml:id parcely: <CP: CadastralBoundary gml :id=" CB "> <CP: beginlifespanversion > T09 :29:49 </CP: beginlifespanversion > <CP: estimatedaccuracy uom ="m">.5 </CP: estimatedaccuracy > <CP: geometry >... <CP: geometry /> <CP: inspireid > <base : Identifier > <base : localid > </ base : localid > <base : namespace >CZ. CUZK.CP </ base : namespace > </ base : Identifier > </CP: inspireid > <CP: parcel xlink : href ="# CP "/> <CP: parcel xlink : href ="# CP "/> </ CP: CadastralBoundary > Volitelný element gml:name reprezentuje popisek prostorového objektu. Element se může opakovat. V rámci elementu je definován atribut gml:codetype, který slouží k odlišení popisků jednotlivých autorit. Ukázka užití různých gml:name (Příklad 4.10) zobrazuje dva odkazy na stávající systémy v podobě ISKN reprezentovaném BUDID (Budova ID) a systémem ČSÚ reprezentovaném IDOB (Identifikátor obydlí), kdy BUDID a IDOB reprezentují určité zjednodušení, protože správně by se mělo poskytovat celé URI. Naproti tomu gml:identifier (Příklad 4.11) umožňuje zadat jediný identifikátor prvku stávajícího systému poskytovatele. Obdobu gml:identifieru můžeme najít v různých INSPIRE tématech. Například u tématu Katastrální parcely v příkladu 4.12 a tématu Adresy v příkladu 4.13, tyto INSPIRE elementy však na rozdíl od gml:identifieru nemají atribut gml:codetype, protože ten je možné převzít z InspireId. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 54

67 Kapitola 4. Geography Markup Language Příklad 4.10: Ukázka užití různých gml:name: <B: Building gml :id="b1"> <gml : name codespace ="# idob ">1</ gml : name > <!-- Vazba na CSU --> <gml : name codespace ="# budid ">2</ gml : name ><!-- Vazba na ISKN --> </B: Building > Příklad 4.11: Ukázka užití různých gml:identifier: <gml : identifier codespace =" iskn "> </ gml : identifier > Příklad 4.12: parcely: Ukázka INSPIRE odkazu do stávajícího systému pro téma Katastrální <CP: nationalcadastralreference > Parcel </CP: nationalcadastralreference > Příklad 4.13: Ukázka INSPIRE odkazu do stávajícího systému pro téma Adresy: <AD: alternativeidentifier > RUIAN_ID </AD: alternativeidentifier > 4.3 Reprezentace geometrie Nejjednodušším prvkem geometrie je bod (Příklad 4.14 ). Vhodný minimální zápis bodu představuje povinné gml:id, atribut srsname reprezentace souřadnicového systému a element <pos>, který obsahuje geometrii bodu. Před příchodem GML byl možný zápis souřadnic bodu do elementu <coordinates>. Tento element je však ve verzi označen jako deprecated. Rozdíl mezi těmito dvěma elementy je ten, že dřívější zápis pomocí elementu <coordinates> umožňoval zapisovat reálná čísla s využitím vlastního desetinného oddělovače a oddělovače tisíců. Zápis bodu lze rozšířit ještě o ostatní identifikátory, jako je gml:name a gml:identifier a informace zjednodušující práci se souřadnicovým systémem srsdimension, axislabels a uomlabels. Atribut srsdimension udává počet souřadnic jednoho bodu, atributy axislabels a uomlabels jsou pak popisky os a jednotek dělení, které zjednodušují práci se složitými souřadnicovými systémy. Navíc element <pos> oproti elementu <coordinates> též umožňuje zápis většiny zmíněných atributů. Příklad 4.14: Geometrie bodu: <gml : Point srsname =" urn : ogc : def : crs : EPSG : 2065 " gml :id=" Point_ "> <gml : pos > </ gml : pos > </ gml : Point > Zápis geometrie linie je možný pomocí gml:linestring nebo gml:curve. Pro následující výklad je vhodnější použít prvek gml:curve (Příklad 4.15 ), protože, jak se dozvíme dále, je tento prvek nesmírně vhodný pro skládání geometrie jednotlivých křivek do ploch. Geometrie prvku křivky představuje seznam dílčích geometrií (linií, kruh. oblouků, spline), ze kterých se křivka skládá. Element <gml:postlist> pak slouží pro zápis samotných Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 55

68 Kapitola 4. Geography Markup Language souřadnic geometrie. Tento element stejně jako element <gml:pos> umožňuje přímý zápis seznamu geometrií, proto je vhodné vždy u tohoto element uvádět atribut srsdimension, který v GML nahrazuje atribut gml:dimension z GML 3.0. Navíc je tento element dále možno rozšířit o atribut count reprezentující počet geometrií. Za předpokladu, že atribut count použijeme, stává se atribut srsdimension též povinným. Pokud se souřadnice geometrie nacházejí ve stejném dokumentu nebo jsou dostupné přes technologii xlink, je možné místo elementu <gml:postlist> užít element <gml:pointrep>, který umožňuje navázat se na tuto původní geometrii. Příklad 4.15: Geometrie linie: <gml : Curve srsname =" urn : ogc : def : crs : EPSG : 2065 " gml :id=" Edge_ "> <gml : segments > < gml : LineStringSegment > <gml : poslist srsdimension ="2"> </ gml : poslist > </ gml : LineStringSegment > </ gml : segments > </ gml : Curve > Orientovaná křivka (Příklad 4.16 ) není jen prostým přidáním orientace, ale navíc představuje velmi efektivní způsob, který umožňuje geometrii prvku poskládat z jednotlivých úseků tak, aby na sebe jednotlivé úseky postupně navazovaly bez nutnosti dodržení orientací původních linií. Příklad 4.16: Geometrie orientované linie: <gml : curvemember > <gml : OrientableCurve gml :id=" EDGE_ m " orientation ="-"> <gml : basecurve xlink : href ="# EDGE_ " /> </ gml : OrientableCurve > </ gml : curvemember > Zápis geometrie polygonu je principiálně možný dvěma způsoby. Buď klasickým zápisem (Příklad 4.17 ), kdy je celá geometrie agregována uvnitř jednotlivých vnějších (<exterior>) a vnitřních (<interior>) obálek geometrií polygonu nebo je možné výslednou geometrii poskládat ať již pomocí elementu <gml:pointrep> nebo prostým skládáním hranic pomocí technologie xlink. Skládání geometrie (Příklad 4.18 ) bylo využito při prvním a druhém testování datové specifikace tématu Katastrální parcely, protože v té době nebylo možné získat topologicky spolehlivou geometrii parcel reprezentovanou pouze body s lineární interpolací. S rozvojem algoritmů PUB-DB je již možné takovou geometrii získat, proto je dnes vhodnější (zejména pro koncové uživatele) geometrii parcel poskytovat přímo. Příklad 4.17: Prostá geometrie polygonu: <gml : Polygon srsname =" urn : ogc : def : crs : EPSG : 2065 " gml :id=" Polygon_ " > <gml : exterior > <gml : LinearRing > Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 56

69 Kapitola 4. Geography Markup Language <gml : poslist srsdimension ="2"> </ gml : poslist > </ gml : LinearRig > </ gml : exterior > </ gml : Polygon > Příklad 4.18: Složená geometrie polygonu: <gml : Polygon gml :id=" PP " > <gml : exterior > <gml : Ring > <gml : curvemember xlink : href ="# EDGE_ " /> <gml : curvemember xlink : href ="# EDGE_ " /> <gml : curvemember xlink : href ="# EDGE_ " /> <gml : curvemember > <gml : OrientableCurve gml :id=" EDGE_ m " orientation ="-"> <gml : basecurve xlink : href ="# EDGE_ " /> </ gml : OrientableCurve > </ gml : curvemember > <gml : curvemember xlink : href ="# EDGE_ " /> <gml : curvemember xlink : href ="# EDGE_ " /> </ gml : Ring > </ gml : exterior > </ gml : Polygon >. 4.4 Prostorová topologie Tak jako GML geometrický model poskytuje zápis absolutní polohy objektu v souřadnicovém systému, tak GML topologický model umožňuje zápis strukturovaných vztahů mezi objekty. Topologický model GML vychází z normy ISO 19107, která mimo jiné definuje konceptuální schéma pro prostorové a topologické vlastnosti geografický dat. Prvky topologického modelu jsou čtyři základní topologická primitiva: Vrchol (Node), Hrana (Edge), Plocha (Face) a Objem (TopoSolid) a jeden pokročilý typ Model (TopoModel). Pro potřeby této disertační práce vynecháme popis prvku Objem, protože ten pracuje s trojrozměrnými objekty, které nebudeme potřebovat. Vrchol (Příklad 4.19) představuje nejjednodušší topologický útvar, který ve svém minimálním vyjádření obsahuje pouze gml:id identifikátor. Volitelně pak lze zápis vrcholu rozšířit o informaci souřadnicové reprezentace v podobě bodu a informaci náležitost vrcholu hranám. V případě odkazu na hranu se jedná o prostou snahu mít vazbu z obou stran a urychlit tak vybrané topologické výpočty. V případu doplnění vrcholu o údaje o souřadnicové poloze je pak též možné řešit smíšené úlohy nebo chcete-li topologické úlohy doplněné o dodatečné podmínky z oblasti analytické geometrie. Přidání geometrie pouze z důvodu snadného zobrazení topologického modelu je též časté. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 57

70 Kapitola 4. Geography Markup Language Příklad 4.19: Topologický vrchol (Node): <Node gml :id=" Start "> < pointproperty ><Point gml :id=" Bod_na_startu "><pos > 1 2</ pos ></ Point >< / pointproperty > < directededge orientation ="-" xlink : href ="# Hrana_1 "></ directededge > </ Node > Hrana (Příklad 4.20) představuje orientované spojení právě dvou vrcholů doplněné o volitelné informace, jako je souřadnicové vyjádření v podobě křivky a informaci o plochách, které hrana pomáhá vytvářet. Stejně jako u vrcholu neexistuje omezení počtu odkazů na orientované hrany, neexistuje u hrany omezení v počtu odkazů na plochy, tedy je zde možné i jednotlivé plochy nepřímo skládat. Dále stojí za povšimnutí možnost hrany se na vrchol pouze odkazovat nebo ho přímo agregovat. Využití této vlastnosti si ozřejmíme dále. Příklad 4.20: Topologická hrana (Edge): <Edge gml :id=" Hrana_1 "> < directednode orientation ="-" xlink : href ="# Start "></ directednode > < directednode orientation ="+"><Node ns1 :id=" Cil "/></ directednode > < curveproperty > <Curve ns1 :id=" krivka_1 "> < segments ><Arc ><pos > </ pos ></ Arc ></ segments > </ Curve > </ curveproperty > < directedface gml : href ="# Plocha_1 "/> </ Edge > Plocha (Příklad 4.21) představuje pro naši potřebu nejvyšší primitivní topologický útvar, který se skládá z jednotlivých orientovaných hran a volitelného geometrického vyjádření. A platí pro ni přibližně obdobná pravidla jako pro hranu, včetně toho, že plocha může obsahovat hranu přímo a tato hrana může přímo obsahovat své vrcholy. Navíc však zde platí rozšířená pravidla pro zápis hran v rámci plochy. Hrany jsou uváděny v pořadí proti směru hodinových ručiček, pokud chceme vyjádřit vnější obálku plochy. V pořadí po směru hodinových ručiček, pokud popisujeme vnitřní obálku (díru) plochy. Dalším specifikem topologie plochy je možnost přidání izolovaného bodu, pro naše potřeby bychom takto mohli přidat kupříkladu definiční bod do geometrie parcely. Všechny orientované hrany spolu s izolovanými body jsou zapsány ve stejné úrovni, z GML zápisu tedy nemusí být hned zřejmé, zda je hrana vnitřní nebo vnější částí plochy. Různá zobrazení plochy z příkladu 4.21 je zobrazeno na obrázku 4.1. Příklad 4.21: Topologická plocha (Face): <Face gml :id=" Plocha_1 "> < directededge orientation ="-" xlink : href ="# Hrana_1 "></ directededge > < directededge orientation ="-" xlink : href ="# Hrana_2 "></ directededge > < surfaceproperty >< Polygon gml :id=" Polygon_1 ">... </ Polygon ></ surfaceproperty > </ Face > Topologii bylo možné volitelně použít v prvním a druhém návrhu datové specifikace, kde bylo možné zadat topologii pro prvek Katastrální hranice, Katastrální parcely a dělení Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 58

71 Kapitola 4. Geography Markup Language Obrázek 4.1: Možné reprezentace topologické plochy se dvěma hranami do katastrálních celků (prvek Katastální členění ). Ve třetím návrhu byla možnost poskytování topologie odstraněna. Ať již z nezájmu uživatelů o tento typ dat, tak i z důvodu špatné motivace jejích poskytovatelů. Tj. topologie byla pouze volitelným prvkem a její poskytnutí přinášelo jen implementační problémy poskytovatelům dat. Navíc její využití pro analýzy bylo přinejmenším pochybné. Přestože plnohodnotná implementace topologie na úrovni Oracle Spatial do struktur PUB-DB byla již od počátku zamítnuta vedením ČÚZK, PUB-DB si uchovala omezenou schopnost poskytovat topologii zapsanou v GML a to díky tomu, že si PUB-DB uchovává pro parcely a katastrální území uspořádaný seznam hran, ze kterých byla geometrie složena a topologický model PUB-DB je dle standardu ISO Pokud bychom se rozhodli topologický model poskytnout, zbývá vyřešit jediný problém a tím je způsob kódování vrcholů v hranách. Pokud by byl dostupný úplný topologický model, bylo by možné jako gml:id vrcholů použít čísla bodů z ISKN. Vrcholy by pak buďto mohly být uvedeny mimo hrany nebo by byly uvedeny přímo v hraně vždy jen při prvním výskytu. Zde tedy využijeme možnost vrchol v hraně uvádět přímo nebo na něj jen odkazovat. Jelikož ale úplný topologický model není v PUB-DB obsažen, je nutné využít umělého dodání těchto bodů (dummy points), kdy funkce, která tyto body poskytuje, pracuje se souřadnicemi vrcholů. Spolehlivá implementace takové funkce může pak představovat výkonnostní problém, a v případě intenzivního využití je vhodnější databázovou tabulku obsahující hranice parcel rozšířit o dva sloupce (z a do BP_ID). Topologický model (TopoComplex) pak představuje prvek, který agreguje jednotlivá topologická primitiva a obsahuje odkaz na jiné topologické modely, které jsou tomuto modelu nadřazené. Pro katastrální mapu je tedy možné vytvořit nejnižší model v podobě podrobných bodů, vyšší model v podobě hranic a nakonec model parcel. Naproti tomu má topologický model mnohé nevýhody, jako je nemožnost protínání hran v jednotlivých modelech a jiné, které znemožňují vytvořit základní topologický model a z něho následně odvozovat jednotlivé časové řezy stavu katastrální mapy. 4.5 Časová topologie Časová topologie představuje způsob, jakým lze efektivně zapsat vývoj velkého množství GML prvků v čase. Pro potřeby této disertační práce je nejlepší ukázat možnosti časové topologie na vývoji změn parcel v katastru nemovitostí, kdy vytvoříme patřičné schéma v příkladu Toto schéma bude mít dva typy prvků Řízení a Položka (ve smyslu položky katastru nemovitostí nikoliv jenom položka řízení), kdy řízení bude představovat vrchol a položka (parcela, hranice parcely,...) pak hranu grafu. Příklad 4.23 pak představuje ukázku Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 59

72 Kapitola 4. Geography Markup Language takové časové topologie. Při modelování časových topologických změn nad databází ISKN je však nutné brát v úvahu některá specifika ISKN. Kupříkladu pokud bychom použili časovou topologii pro určování přírůstků a úbytků jednotlivých druhů půdy, dojdeme ke zjištění, že zde dochází v jednom řízení ke zrušení části parcel ISKN a plocha těchto parcel je do ISKN opět vrácena až v jiném řízení. Tato vlastnost ISKN má pak za následek, že jednotlivé řezy stromu časové topologie představují značně nedůvěryhodné údaje. Dalším problémem, který práci s časovou topologií ještě ztíží, je skutečnost, že ISKN je systém, ve kterém se nalezené chyby opravují pouze v přítomnosti. Oprava většinou vypadá tak, že se topologická nebo jiná chyba smaže a znovu se vloží opravená data. Na závěr je dobré zmínit, že časová topologie je v rámci INSPIRE zakázána již v rámci Generického konceptuálního modelu. Namísto toho je poskytována informace o životním cyklu objektu, která však nemůže časovou topologii zcela zastoupit. Důvod zákazu časové topologie je jednoduchý. Většina států a většina datových sad není v takové kvalitě, aby umožnily publikovat časovou topologii. Přesto, že by osud prostorové topologie v rámci INSPIRE mohl některým čtenářům připomínat osud časové topologie, je potřeba zmínit podstatný rozdíl. Zatímco časová topologie není publikována vůbec, při publikování témat, kde by mohla prostorová topologie hrát roli (Dopravní síť, Vodstvo), je explicitní zápis topologie zrušen a namísto toho se předpokládá implicitní schopnost jednotlivých geometrických primitiv vytvářet topologický čistý model. Příklad 4.22: Schéma pro časovou Topologii: < complextype name =" PoložkaType " > < complexcontent > < extension base =" gml : AbstractFeatureType " > <choice minoccurs ="1" maxoccurs ="1"> < element name =" Parcela " type ="cp: CadastralParcel "/> < element name =" Hranice " type ="cp: CadastralBoundary "/> < element name =" KatastralníUzemí " type ="cp: CadastralZoning "/> </ choose > </ extension > </ complexcontent > <group name =" PoložkaType Platnost_Group "> < sequence > < element name =" Platnost " type =" gml : TimeEdgePropertyType "/> </ sequence > </ group > </ complextype > < complextype name =" ŘízeníType "> < complexcontent > < extension base =" gml : AbstractFeatureType " > < element minoccurs ="0" name =" Zaniká " type =" PoložkaType "/> < element minoccurs ="1" name =" Vzniká " type =" PoložkaType "/> </ extension > </ complexcontent > </ complextype > < element name =" Řízení " type =" ŘízeníType " substitutiongroup =" gml : _Feature "/> Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 60

73 Kapitola 4. Geography Markup Language < element name =" Položka " type =" PoložkaType " substitutiongroup =" gml : _Feature "/> Příklad 4.23: Ukázka časové topologie. <Řízení gml :id=" Spojeni_parcel "> <Zaniká > < Položka xlink : href ="# Parcela_1 "> < Položka xlink : href ="# Parcela_2 "> </ Zaniká > <Vzniká > < Položka xlink : href ="# Parcela_3 "> </ Vzniká > </ Řízení > < Položka gml :id=" Parcela_3 "> < Parcela > < cp: CadastralParcel >... </ cp: CadastralParcel > < Parcela > < Platnost > <gml : TimeEdge gml :id=" Hrana_2 "> <gml : start > <gml : TimeNode gml :id=" Vrchol_2 "> <gml : previousedge xlink : href ="# Hrana_1 "/> <gml : nextedge xlink : href ="# Hrana_2 "/> <gml : position > <gml : TimeInstant > <gml : timeposition > T03 :04:05Z</ gml : timeposition > </ gml : TimeInstant > </ gml : position > </ gml : TimeNode > </ gml : start > <gml : end > <gml : TimeNode gml :id=" Vrchol_3 "> <gml : previousedge xlink : href ="# Hrana_2 "/> <gml : nextedge xlink : href ="# Hrana_3 "/> <gml : nextedge xlink : href ="# Hrana_4 "/> <gml : position > <gml : TimeInstant > <gml : timeposition > T04 :05:00Z</ gml : timeposition > </ gml : TimeInstant > </ gml : position > </ gml : TimeNode > </ gml : end > <gml : extent > <gml : TimePeriod > <gml : beginposition > T03 :04:05Z</ gml : beginposition > <gml : endposition > T04 :05:00Z</ gml : endposition > </ gml : TimePeriod > </ gml : extent > Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 61

74 Kapitola 4. Geography Markup Language </ gml : TimeEdge > </ Platnost > </ Položka > 4.6 GML versus INSPIRE zásobníky Do příchodu GML byl nejpoužívanějším zásobníkem GML prvků gml:feature- Collection (Příklad 4.2), který představoval velmi efektivní nástroj, jakým šlo publikovat velké množství dat. Jeho oblíbenost můžeme ukázat na příkladu, kdy mnohé INSPIRE testovací týmy použily tento zásobník, přestože tento zásobník nevyhovoval potřebám kladeným INSPIRE konceptuálním modelem (požadavek na externí unikátní identifikátor datové sady a metadata dle ISO 19139). S příchodem GML je tento zásobník, stejně jako ostatní zásobníky, označen za deprecated a GML přechází na jiný model modelování, kdy přímo každý gml:abstractfeature umožňuje rozšiřování. INSPIRE pro své potřeby definuje v Generickém konceptuálním modelu nový typ zásobníku SpatialDataSet (Příklad 4.3). Vznik tohoto zásobníku není nijak spojen s GML 3.2.1, pouze tento zásobník je pro potřeby INSPIRE po příchodu GML konečně vnímán většinou testovacích autorit jako ten pravý. Uvažujeme testování služby stahování celých datových sad, protože pro potřeby testování WFS 2.0 je vhodné stále využívat zásobník wfs:featurecollection používaný ve starších verzích WFS Příklady obou zásobníků jsou uvedeny na příkladech 4.24 a Obrázek 4.2: GML FeatureColection Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 62

75 Kapitola 4. Geography Markup Language Příklad 4.24: Zásobník GML: <? xml version =" 1.0 " encoding ="UTF -8"?> < gml : FeatureCollection xmlns : gml =" http :// www. opengis. net / gml "> <gml : boundedby > <gml : Envelope srsname =" EPSG : " srsdimension ="2"> <gml : lowercorner > </ gml : lowercorner > <gml : uppercorner > </ gml : uppercorner > </ gml : Envelope > </ gml : boundedby > <gml : featuremember >... </ gml : featuremember > </ gml : FeatureCollection > Obrázek 4.3: INSPIRE SpatialDataSet Příklad 4.25: Zásobník INSPIRE datové sady: <? xml version =" 1.0 " encoding ="UTF -8"?> <base : SpatialDataSet gml :id="cz. cuzk.kn " xmlns : gml =" http :// www. opengis. net / gml / 3.2 " xmlns : base =" urn :x- inspire : specification : gmlas : BaseTypes : 3.2 "> <base : identifier > <base : Identifier > <base : localid > </ base : localid > <base : namespace >CZ. CUZK.KN </ base : namespace > </ base : Identifier > </ base : identifier > <base : metadata /> <base : member >... <base : member /> < base : SpatialDataSet / > Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 63

76 Kapitola 5. Datové sady a systémy ČÚZK v prostředí INSPIRE Kapitola 5 Datové sady a systémy ČÚZK v prostředí INSPIRE 5.1 ISKN ISKN (Informační systém katastru nemovitostí) je systém pro podporu výkonu státní správy v oblasti katastru nemovitostí. V době svého vzniku systém představoval jeden z nejrozsáhlejších a datově nejobjemnějších systémů státní správy. Systém se skládá ze 107 lokálních databází, které jsou spravovány jednotlivými katastrálními pracovišti (KP) a které jsou spojeny pomocí sítě WAN do jediné centrální databáze. Lokální databáze obsahují pouze data vybraného KP a číselníky společné pro celou infrastrukturu ISKN. Lokální databáze v intervalu patnácti minut poskytují repliku cca 90% svých dat do centrální databáze. Centrální databáze tedy obsahuje kopie všech dat lokálních ISKN. Navíc však zajišťuje distribuci centrálních číselníků do jednotlivých lokálních databází. Pro potřeby této disertační práce je vhodné na ISKN pohlížet jen jako na strukturované databázové schéma. Ve skutečnosti ISKN představuje procedurální informační systém, který pracuje nad tímto databázovým schématem. Struktura databáze pak v mnohém napoví o jednotlivých částech (dílčích aplikacích) ISKN. Pro potřeby práce s grafickými daty si vystačíme se dvěma schématy. Prvním je schéma AK, kterému odpovídá aplikace Aktualizace. Druhým potřebným schématem je pak schéma SC, kterému odpovídá aplikace správy číselníků. Z dat ISKN bude poskytováno pouze INSPIRE téma Katastrální parcely. Dalším INSPIRE tématem, o kterém se ve spojitosti s ISKN přemýšlelo, je téma Budovy z třetího Annexu, pro jeho poskytování je však v současnosti preferován datový zdroj ISÚI. Na tomto místě je vhodné zmínit aplikaci Nahlížení do KN a způsob, kterým tato aplikace v současnosti získává grafická data z ISKN, protože později se na stav aplikace Nahlížení do KN budeme vhodně odkazovat. Aplikace Nahlížení do KN slouží široké veřejnosti k bezplatnému prohlížení dat katastru nemovitostí v prostředí systému internet. Aplikace umožňuje zobrazovat jak vybrané popisné informace katastru nemovitostí tak i ty grafické prostřednictvím WMS služeb. Zatímco způsob uložení popisných informací v databázi ISKN je vhodný pro publikaci webovým serverem, u grafických informací publikovaných přes WMS toto neplatí. Prvním problémem je skutečnost, že webový server očekává vstupní data v určitém předem stanoveném formátu. Z tohoto formátu pak rastrový server vytváří bitmapové dlaždice určené k publikování. Je nutné data ISKN nej- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 64

77 Kapitola 5. Datové sady a systémy ČÚZK v prostředí INSPIRE prve převést do formátu vhodného pro publikování. Po vyjmenování problémů je zřejmé, že při řešení WMS služeb muselo dojít ke kompromisům. Ty spočívají ve spuštění skriptu, který vytvoří z dat ISKN vstupní data pro rastrový server jednou za čtrnáct dní. Obrázek 5.1: Systém ISKN 5.2 RÚIAN Základní registr územní identifikace adres a nemovitostí (RÚIAN) je jedním ze čtyř připravovaných základních registrů (Obrázek 5.2) státní správy České republiky dle zákona č. 119/2009 Sb. Ostatní tři základní registry jsou Registr obyvatel (ROB), Registr osob (ROS), Registr práv a povinností (RPP). Správci jednotlivých registrů jsou Ministerstvo vnitra (ROB, RPP), Český úřad zeměměřický a katastrální (RÚIAN), Český statistický úřad (ROS). Všechny tyto registry jsou spojeny do společného informačního systému základních registrů (ISZR), který je též pod správou Ministerstva vnitra. RÚIAN, stejně jako ostatní Základní registry, obsahuje pouze aktuální údaje a jeho aktualizace probíhá přes agendové informační systémy (ISKN, ISÚI). Základní registry mohou spolu komunikovat navzájem, ale i se svými agendovými informačními systémy, výhradně přes rozhraní ISZR. Přičemž RÚIAN a ROS jsou jedinými ze Základních registrů, které jsou v současnosti budovány. Dále je nutné zmínit, že Základní registry fungují do značné míry jako celek, tedy v případě včasného dokončení tohoto systému hrozí, že systém nebude prakticky využitelný a nebude možné ani zkontrolovat jeho plnou funkčnost a to až do vybudování ostatních registrů. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 65

78 Kapitola 5. Datové sady a systémy ČÚZK v prostředí INSPIRE Obrázek 5.2: Základní systémy státní správy 1 Systém RÚIAN je naplněn daty ze svých agendových informačních systémů. Těmito systémy je Informační Systém Katastru Nemovitostí (ISKN) a Informační Systém Územní Identifikace (ISÚI). Kdy na jedné straně dochází k rozšíření ISKN (jedním z rozšíření ISKN vedení obvodů k.ú. ve vektorové digitální podobě na celém území), tedy ISKN do systému RÚIAN poskytuje parcely, stavební objekty a obvody katastrálních území, a na druhé straně dochází budování nového informačního systému ISÚI, který bude obsahovat data, která nejsou předmětem katastru nemovitostí. Těmito daty jsou: Údaje o základních územních prvcích: Území státu, regionů soudržnosti, vyšších samosprávných celků, krajů, okresů, obcí s rozšířenou působností (ORP), obcí s pověřeným obecním úřadem (POU), obcí, vojenských újezdů, správních obvodů Prahy, městských obvodů a městských částí ve statutárních městech a Praze, základních sídelních jednotek, stavebních objektů, adresních míst. Údaje o základních územně evidenčních jednotkách: části obcí, ulice nebo veřejná prostranství. Adresy. Údaje o účelových územních prvcích (pokud tak stanoví zákon a tyto prvky jsou skladebné). Editace prvku RÚIAN (Obrázek 5.3) je provedena přes oba agendové systémy. Editory těchto systémů jsou ČÚZK (interní editor edituje většinu prvků), ČSÚ (externí editor základních sídelních jednotek), obce (externí editor ulic, veřejných prostranství), stavební úřady (externí editor adres č.p nových stavebních objektů a jejich technickoekonomické atributů). Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 66

79 Kapitola 5. Datové sady a systémy ČÚZK v prostředí INSPIRE Obrázek 5.3: Základní systémy státní správy 2 Prvotní naplnění ISÚI proběhlo z Registru sčítacích obvodů (RSO), jehož provozovatelem je ČSÚ, systému ÚIR-ADR (Adresy), jehož provozovatelem je MPSV a několika dalších kontrolních zdrojů (databáze doručovacích míst České pošty, Evidence obyvatel MV). Rozšíření ISKN lze rozdělit na dvě pomyslné fáze. První fází je pouze začlenění nutných změn do stávající (decentralizované) verze ISKN, které jsou potřeba pro start externího pilotního provozu. Druhá fáze představuje začlenění zbývající funkcionality do centralizované ISKN včetně napojení na ISZR. Stejně jako na ISKN budeme i na ISÚI pohlížet pouze jako na určité databázové schéma. Z pohledu INSPIRE je z ISÚI možné publikovat témata Adresy, Administrativní jednotky, Budovy a Transportní sítě (uliční čáry). INSPIRE tématem, které bude nejspíše publikováno z dat Stavebního objektu dat ISÚI, se zde nebudeme zabývat, protože toto téma je součástí třetího Annexu a tedy jeho datová specifikace není známa. Tématem Transportních sítí nad daty ZABAGED i daty ISÚI se zabývá tým ZÚ. A to z toho důvodu, že prvotní data do ISÚI jsou poskytována právě ze ZABAGED a ZABAGED by rád těžil zpětně z těchto dat v podobě oprav a doplnění, ke kterým nad daty ISÚI bude docházet. Do budoucna je však potřeba v ZABAGED ošetřit případy, kdy data ISÚI v rámci reklamací mohou změnit svou polohu jen proto, aby odpovídala podkladové mapě a tyto úpravy Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 67

80 Kapitola 5. Datové sady a systémy ČÚZK v prostředí INSPIRE nezahrnovat do ZABAGED. Zde se očekávají problémy především u dat (KMD, KM-D a ÚKM). Přes tyto komplikace však editoři v rámci jednotlivých obcí představují pro ZÚ a jeho ZABAGED zajímavý zdroj informací. V této disertační práci se naopak zmíníme o datech ISÚI, která budou v budoucnu publikována v rámci INSPIRE témat Adresy a Administrativní jednotky. 5.3 ZABAGED a jiná data ZÚ Data Zeměměřického úřadu jsou co do obsahu INSPIRE témat mnohem bohatší než data sekce centrální databáze (SCD), navíc jsou tato data mnohdy udržována i ve více měřítcích. Proto je vhodné jednotlivé zdroje Zeměměřického úřadu přímo rozdělit do příslušných INSPIRE témat. INSPIRE téma Zeměpisné názvy bude poskytováno z primárního zdroje databáze Geonames, doplňkovými sadami dat bude Základní báze geografických dat (ZABAGED) a dále pak data již zmíněného ISÚI pod správou SCD. INSPIRE téma Administrativní jednotky bude poskytováno z dat: ZABAGED, Základní mapy ČR v měřítcích 1:50tis (tzv. DATA50) a 1:200tis (tzv. DATA200), Mapy ČR v měřítcích 1:500tis (tzv. DATA500) a 1:1mil (tzv. DATA1M). Všechny zmíněné zdroje však představují vícenásobné poskytování a nepředstavují hlavní datový zdroj tohoto tématu pro INSPIRE. Hlavní datovým zdrojem bude systém ISÚI spravovaným SCD ČUZK. INSPIRE téma Transportní sítě bude primárně poskytováno z dat ZABAGED doplněného o data ISÚI. Dalšími zdroji dat v jiných měřítcích budou DATA50, DATA200, DATA500 a DATA1M. INSPIRE téma Vodstvo bude primárně poskytováno z dat ZABAGED, další zdroje budou stejné jako pro téma Transportních sítí tedy DATA50, DATA200, DATA500, DATA1M. INSPIRE téma Chráněná území by mělo být poskytováno primárně z dat DATA50, ale zvažují se i data ZABAGED. Mimo datové sady Annexu I je situace značně nejasná, protože pro druhý a třetí Annex ještě nejsou stanovena přesná pravidla, tedy není mnohdy možné určit, zda daný datový zdroj může být zdrojem datových sad tohoto tématu. Za současných podmínek se však ZÚ hlásí k těmto dalším INSPIRE tématům: Nadmořské výšky, Krajinný pokryv, Ortofotosnímky. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 68

81 Kapitola 6. Testování datové specifikace Kapitola 6 Testování datové specifikace Testování datové specifikace představuje jeden z pomyslných kroků při vytváření konkrétní datové specifikace INSPIRE tématu. Prvním krokem tohoto procesu (celý proces je zobrazen na obrázku 6.1) se zabývá tým CT-1 (Consolidation Team 1), který má za úkol vytvořit případy užití (Use Cases) a aplikační scénáře koncového uživatelského chování při vytváření analýz z oblasti životního prostředí, EUROSTATu, Evropských Strukturálních Fondů a jiných projektů nad abstraktním GIS systémem. Na práci tohoto týmu navazuje TWG-2 tým (Thematic working group 2), který má za úkol identifikovat typy prostorových a jiných dat v těchto případech užití. Výsledkem práce tohoto týmu je tedy seznam typů prostorových objektů, které čekají na své zařazení do registru INSPIRE typů prvků (INSPIRE Feature Concept Dictionary Register). Tento tým také vytváří první nástin datových specifikací. Dalším týmem je tým TWG-3, který má za úkol popsat stávající stav datových sad prvků navržených předešlým týmem v jednotlivých členských státech. Tomuto procesu se říká Analýza současného stavu (As-is analysis) a spočívá v sestavení a zaslání strukturovaného dotazníku jednotlivým budoucím poskytovatelům dat ve všech členských státech. Z této analýzy následně vychází TWG-4, která se snaží definovat společné a chybějící atributy jednotlivých prvků napříč všemi zúčastněnými státy s ohledem na vstupní požadavky uživatelů. Tato analýza se nazývá Analýza mezer (Gap analysis), její závěry mohou vést k požadavku na novou analýzu stavu dat a to za předpokladu, že se zjistí, že předchozí analýza nebyla v určitých aspektech dostatečně podrobná nebo byla neúplná. V případě, že výsledkem analýzy mezer, mnohdy až několikáté v pořadí, je konstatování, že uživatelské scénáře je možné realizovat nad daty všech států, dochází k tvorbě prvního skutečného návrhu příslušné datové specifikace. Tuto specifikaci vytváří tým TWG-5. Tento návrh specifikace je následně předán zpět organizacím, které poskytly prvotní analýzy (As-is analysis), ale i jiným zájmovým organizacím, které mají zájem na testování. Tyto subjekty provedou testování schopnosti vlastní data konvertovat do dodaného datového modelu INSPIRE (mluvíme o transformačním testování) nebo provedou tzv. aplikační testování, které spočívá v aplikačním testování dvou a více již konvertovaných datových sad. Pod pojmem aplikační testování si můžeme představit libovolnou sadu operací provedenou na testovaných datových sadách od pouhého načtení do GIS nástroje a kontroly mezer/přesahů až po složité topologické dotazy. Po dokončení testování jsou výsledky předány týmu CT-6. Tento tým pak porovná dosažené výsledky v jednotlivých státech a rozhodne o případném doplnění nebo předělání datové specifikace. Předpokládá Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 69

82 Kapitola 6. Testování datové specifikace se, že k dosažení souladu datových sad s navrhovanou datovou specifikací dojde během dvou až tří návrhů datové specifikace. Jednotlivé návrhy datových specifikací se co do požadavků na testovací subjekty liší. Zatímco první návrh očekává pouze porovnání s datovou specifikací, druhý návrh již počítá s pilotní implementací a hmatatelným testem schopnosti konverze. Po úspěšném dokončení testování datové specifikace je pověřen tým CT-7 vytvořením analýzy nákladů a přínosů (Cost-benefit consideration). Tedy opět dotazníku pro jednotlivé implementátory, kde tito budoucí poskytovatelé zhodnotí náklady a přínosy, pokud nějaké existují, z nově vytvářené infrastruktury. Tým CT-7 pak tyto dotazníky vyhodnotí a doporučí testovanou datovou specifikaci ke schválení nebo k dalšímu přepracování. Obrázek 6.1: Testování jako součást vývoje datové specifikace 6.1 Testování prvního a druhého návrhu Na přelomu roku 2008/2009 se Český úřad zeměměřický a katastrální (ČÚZK) v roli LMO (Legally Mandated Organization) připojil k rozsáhlému testování prvního a později druhého návrhu datové specifikace témat INSPIRE Annexu I. V rámci sekce centální databáze (SCD) jsem prováděl testování návrhu datové specifikace tématu Katastrální parcely z dat ISKN. Protože v té době neexistoval systém RÚIAN, bylo téma Adresy Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 70

83 Kapitola 6. Testování datové specifikace přisouzeno Českému statistickému úřadu (ČSÚ) a téma Administrativní jednotky Zeměměřickému úřadu (ZÚ). Předpokládalo se otestování daty ZABAGED společně pro témata Transportní sítě, Administrativní jednotky a Vodstvo. Dále jsem pak za SCD společně se slovenskými kolegy vypracoval aplikační testování na ČR-SR hranici pro oba katastry. Nakonec jsem provedl transformační testování tématu Geografických Názvů z dat ZABAGED. Aplikační testování bylo umožněno díky spolupráci stážistky z úřadu Geodézie, Kartografie a Katastru SR Ing. Martiny Behuliákové, která domluvila výměnu INSPIRE- GML dat na společné hranici z obou stran pokryté DKM. Z české strany do testování vstoupilo k.ú. Sudoměřice s DKM, ze slovenské strany pak k.ú. Skalica s DKM. Na obrázku 6.2 jsou zobrazena tato katastrální území spolu s českým katastrálním územím Bohatec, kde je DKM na části (DKM-C). Transformační testování Geografických jmen pak byla výpomoc ZÚ od SCD, o jehož zužitkování se uvažovalo při případné implementaci INSPIRE Geografických názvů z dat ISKN (další prvky mapy). Transformační testování spočívá v identifikování INSPIRE struktur ve vlastních datových sadách, následné otestování schopnosti transformovat vlastní datové sady do struktury INSPIRE včetně transformace/projekce do jednotného zobrazení. Závěr transformačního testování pak shrnuje dosažené úspěchy a problémy při transformaci datové specifikace. Po dokončení testování byla vytvořená INSPIRE-GML data i metadata předána RNDr. Tomáši Řezníkovi Ph.D. z Masarykovy Univerzity v Brně, aby před samotným odevzdáním provedl nezávislou kontrolu. Ten shledal jak vygenerovaný dataset tématu Katastrálních parcel, geografických názvů (test SCD) tak i metadata pro Katastrální parcely odpovídající datové specifikaci INSPIRE i profilu ČÚZK. Ze závěru testování vyplývá, že data DKM a KMD ČÚZK je možné konvertovat do datového modelu INSPIRE. Transformační test Katastrálních parcel představoval aplikaci v jazyce Java schopnou pracovat s daty centrální databáze. Při samotném testování tohoto tématu byly zjištěny překážky, které vedly až ke vzniku publikační databáze (PUB- DB), které se budeme věnovat v další kapitole. Ukázky výsledků transformačního testování jsou na obrázcích 6.3 a 6.4. Obrázek 6.2: Průběh DKM na Česko-Slovenské hranici Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 71

84 Kapitola 6. Testování datové specifikace Zjištěné problémy při testování Model uložení INSPIRE geometrie/topologie je odlišný od modelu ISKN. V ISKN je přesnost uváděna u každého bodu hranice parcely. Zatímco u INSPIRE je to souhrnná přesnost za linii/parcelu (odpovídá prvnímu návrhu datové specifikace). INSPIRE vyžaduje u parcely geometrii. Ta může být zapsána v GML jako polygon nebo jako zřetězení hranic. ISKN však ukládá jen hranice parcely a nezná k nim topologické pořadí. Topologická informace tedy musí být znovu zjištěna. INSPIRE neumožňuje kružnice, kruhové oblouky tak jako ISKN. Data ISKN obsahují malé množství velmi různorodých chyb, které je možné odhalit pouze při změně topologického modelu: volné konce, nekontrolované topologické mezery ve formě štíhlých trojúhelníků, parcely, jež samy sebe nekříží jen při sub-milimetrovém porovnání. Geometrii je potřeba převést do souřadnicového systému ETRS. Při testování bylo použito řešení mimo databázi (řešení prof. Kosteleckého), pro reálný provoz je vhodné transformaci přenést na úroveň databáze. Výpočet je velmi náročný. Je téměř vyloučeno ho provádět přímo z ISKN. Není možné automaticky ověřit validitu metadat v profilu ČÚZK. Obrázek 6.3: Testování druhého návrhu: k.ú. Sudoměřice Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 72

85 Kapitola 6. Testování datové specifikace Příklad 6.1: Obrázek 6.4: Testování druhého návrhu: detail Ukázka kódování Geografických jmen. <GN: NamedPlace > <GN: name > < GN: GeographicalName > <GN: language >cze / ces </GN: language > <GN: nativevalue > Endonym </GN: nativevalue > <GN: status > Official </GN: status > <GN: spelling > <GN: SpellingOfName > <GN: text > Povýšení sv. kříže </GN: text > <GN: script >Latn </GN: script > </GN: SpellingOfName > </GN: spelling > </ GN: GeographicalName > </GN: name > <GN: geometry > <gml : Point srsname =" urn : ogc : def : crs : EPSG :25833 " > <gml : pos > </ gml : pos > </ gml : Point > </GN: geometry > <GN: type > Church </GN: type > <GN: referencepointmeaning > Inside </GN: referencepointmeaning > <GN: beginlifespanversion > T12 :08:00 </GN: beginlifespanversion > </ GN: NamedPlace > Ukázka aplikačního testování V rámci aplikačního testování byl porovnán soulad průběhu (Obrázek 6.5) katastrálních území na společné ČR-SR hranici. Z výsledků vyplývá, že minimálně jeden ze států Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 73

86 Kapitola 6. Testování datové specifikace nezařadil výsledky společného měření státní hranice do svého katastru. Na obrázku 6.6 bílá barva zobrazuje jednu z topologických mezer na společné hranici. Modrá barva představuje území pokryté českými parcelami k.ú. Sudoměřice, tmavě oranžové jsou slovenské parcely a světle oranžové je území Slovenska k.ú. Skalice, kde v GML chybí parcely. Dále bylo na Česko-slovenské hranici provedeno porovnání průběhu katastrální hranice v ETRS, přičemž česká strana použila software prof. Kosteleckého (v.7) a slovenská strana použila GTK (Globální transformační klíč) a výsledek poskytla v dekadické úhlové míře. Očekávaná přesnost, vyjma třech topologických chyb (Obrázek 6.2), porovnání cca 10cm byla splněna. Obrázek 6.5: Průběh Česko-slovenské hranice Obrázek 6.6: Nesoulad na Česko-Slovenské hranici Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 74

87 Kapitola 6. Testování datové specifikace Testovací architektura Pro samotné testování prvního a druhého návrhu byl vytvořen program v jazyce Java, který měl za úkol vytvořit INSPIRE GML přímo z databáze ISKN (popřípadě ZABAGED). Postup konverze dat ISKN na data INSPIRE v tomto programu je naznačen na obrázku 6.7. Tento proces začínal výběrem zájmových dat z centrální databáze ISKN. Následně byla znovu vytvořena posloupnost jednotlivých linií v rámci geometrie parcely. Tedy geometrie parcely zde nebyla reprezentována přímo polygonem, ale jako posloupnost linií (Příklad 6.2). Důvodem byla skutečnost, že v té době chyběly jakékoliv informace o testech topologie a geometrie nad daty ISKN, protože ČÚZK svá data v tomto ohledu velmi zanedbával 1. Dalším krokem byl převod souřadnic ze systému S-JTSK do systému ETRS. Tento převod byl proveden externím programem prof. Kosteleckého (v.7). Jednou ze zvláštností tohoto převodu oproti převodům implementovaným jinými státy byla skutečnost, že každý podrobný bod byl transformován pouze jednou, protože testovací software si udržoval seznam souřadnic a v modelu geometrií pak pracoval jen s referencemi. Po transformaci do ETRS bylo provedeno zobrazení do Transverzálního Merkátora a teprve až v tomto zobrazení došlo k nahrazení kružnic a kruhových oblouků liniovými řetězci. Zvolená maximální odchylka pro odklon linie od průběhu kružnice byla stanovena na deset centimetrů. Nově vzniklý model byl zapsán do INSPIRE GML, včetně INSPIRE metadat a byla přidána metadata z metadatového profilu ČÚZK z externího zdroje. Na konci byl ještě vytvořený GML soubor zvalidován oproti INSPIRE schématu Katastrální parcely. Obrázek 6.7: Architektura testování prvního návrhu Příklad 6.2: Ukázka kódování české parcely při prvním a druhém testování. <CP: CadastralParcel gml :id=" CP1317 ">... <CP: geometry > <gml : Polygon gml :id=" PP1317 " > <gml : exterior > <gml : Ring > <gml : curvemember xlink : href ="# h7983 " /> <gml : curvemember > 1 Prvním, kdo se systematicky zabýval topologickými chybami v ISKN byl Ing. Karel Janečka, Ph.D. v rámci spolupráce s SCD na své disertační práci v letech Tyto testy však nebyly v mnoha ohledech úplné a navíc nedokázaly identifikovat všechny instance hledaných typů chyb. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 75

88 Kapitola 6. Testování datové specifikace <gml : OrientableCurve gml :id=" h1317_25421 " orientation ="-"> <gml : basecurve xlink : href ="# h25421 "/> </ gml : OrientableCurve > </ gml : curvemember > <gml : curvemember xlink : href ="# h8071 " /> <gml : curvemember > <gml : OrientableCurve gml :id=" h1317_25430 " orientation ="-"> <gml : basecurve xlink : href ="# h25430 "/> </ gml : OrientableCurve > </ gml : curvemember > </ gml : Ring > </ gml : exterior > </ gml : Polygon > </CP: geometry >... </ CP: CadastralParcel > 6.2 Testování třetího návrhu Téma Katastrální parcely Plnohodnotné testování třetího návrhu bylo zpočátku odloženo, protože v době publikování třetího návrhu byly prováděny dokončovací práce na publikační databázi (PUB- DB). Testování třetího návrhu bylo čistě analytické, kdy byly identifikovány rozdíly oproti druhému návrhu a bylo shledáno, že rozdíly v třetím návrhu jsou sice výrazné, ale nijak výrazně neovlivní publikační databázi ani způsob, jakým z ní následně budou získávána INSPIRE data. Po dokončení prací na publikační databázi bylo předešlé tvrzení ověřeno tím, že byly z publikační databáze získány INSPIRE GML data k.ú. Bylany celkem třemi způsoby (Příklad 6.8). První a druhý způsob spočíval v získání GML souboru pomocí PL/SQL procedury implementované přímo v databázi a to ve formátech, kdy v prvním případě byly geometrie parcel reprezentovány jako posloupnosti hranic (stejně jako u prvního a druhého testování) a u druhého způsobu pak nově i jako plnohodnotné geometrie zapsané přímo (Obrázek 6.9). Třetí způsob spočíval v získání GML z publikační databáze pomocí software Snowflake Community Edition (Obrázek 6.10). U tohoto způsobu byla též použita plnohodnotná geometrie parcel. Obrázek 6.8: Architektura: Testování třetího návrhu Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 76

89 Kapitola 6. Testování datové specifikace Obrázek 6.9: Testování třetího návrhu: k.ú. Bylany Obrázek 6.10: Publikování pomocí Snowflake GoPublisher CE Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 77

90 Kapitola 6. Testování datové specifikace Téma Adresy Jak již bylo řečeno v úvodu testování s návrhem a vývojem RÚIAN/ISÚI stává se ČÚZK poskytovatelem INSPIRE tématu Adresy. Samotný harmonogram spuštění systému RÚIAN odpovídá termínu povinného poskytování všech dat Annexu I. Z tohoto důvodu je potřeba prakticky zaručit, aby systém RÚIAN (resp. ISÚI) byl plně v souladu s požadavky INSPIRE od svého spuštění. Již před začátkem testování třetí verze datových specifikací bylo vedením ČÚZK rozhodnuto, že data RÚIAN, která odpovídají INSPIRE tématům Adresy a Administrativní jednotky, nebudou poskytována do projektu přímo z těchto systémů, ale přes nově navrženou publikační databázi (PUB-DB). Úkolem testování INSPIRE tématu Adres je porovnání datového schématu nově vznikajícího systému ISÚI, který bude systémem, ze kterého se budou adresy poskytovat do systému RÚIAN s datovým modelem v INSPIRE datové specifikaci tématu Adres. Závěr tohoto testování je, že všechny položky potřebné pro publikování dat ve formátu INSPIRE jsou v ISÚI obsaženy (schéma databázového schématu ISÚI je na obrázku 6.11). Další krok testování spočívá v pokusu o vytvoření INSPIRE GML souboru přímo z dat ISUÍ, který by závěr testování potvrdil. Ukázku zápisu adresy rozdělíme pro přehlednost do několika částí, hlavním bude prvek Adresa (Příklad 6.3), následovat pak budou jednotlivé komponenty adresy (Příklady 6.4, 6.5, 6.6, 6.7). Obrázek 6.11: ISÚI - Adresy Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 78

91 Kapitola 6. Testování datové specifikace Příklad 6.3: Ukázka prvku Adresa <AD: Address gml :id="ad. Adresa "> <AD: inspireid > <base : Identifier > <base : localid >Adresa </ base : localid > <base : namespace >CZ. CUZK.AD </ base : namespace > </ base : Identifier > </AD: inspireid > <AD: alternativeidentifier > </AD: alternativeidentifier ><!-- UIADR --> <AD: position > < AD: GeographicPosition > <AD: geometry > <gml : Point gml :id=" Adresa. Bod " srsname =" urn : ogc : def : crs : EPSG :2065 "> <gml : pos > </ gml : pos > </ gml : Point > </AD: geometry > <AD: specification > entrance </AD: specification ><!-- co to znaci --> <AD: method > byotherparty </AD: method ><!-- kdo to meril --> <AD: default >true </AD: default > </ AD: GeographicPosition > </AD: position > <AD: status > current </AD: status ><!-- Je aktivni? --> <AD: locator > <AD: AddressLocator > <AD: designator > < AD: LocatorDesignator > <AD: designator >č.p.</ad: designator ><!-- typ cisla domovniho --> <AD: type > buildingidentifierprefix </AD: type > </ AD: LocatorDesignator > </AD: designator > <AD: designator > < AD: LocatorDesignator > <AD: designator >11 </AD: designator ><!-- cislo domovni --> <AD: type > buildingidentifier </AD: type > </ AD: LocatorDesignator > </AD: designator > <AD: designator > <AD: LocatorDesignator ><!-- cislo orientacni --> <AD: designator >71 </AD: designator > <AD: type > addressnumber </AD: type > </ AD: LocatorDesignator > </AD: designator > <AD: designator > < AD: LocatorDesignator > <AD: designator >A</AD: designator ><!-- pismeno orientacni --> <AD: type > addressnumberextension </AD: type > </ AD: LocatorDesignator > </AD: designator > <AD: level ></AD: level > Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 79

92 Kapitola 6. Testování datové specifikace </AD: AddressLocator > </AD: locator > <AD: validfrom > T09 :47:48 </AD: validfrom > <AD: beginlifespanversion > T09 :47:48 </AD: beginlifespanversion > <AD: parcel xlink : href =" Parcela "/> <AD: building xlink : href =" StavebniObjekt "/> <AD: component xlink : href ="# Posta "/> <AD: component xlink : href ="# Ulice "/> <AD: component xlink : href ="# Obec "/> <AD: component xlink : href ="# CastObce "/> </AD: Address > Příklad 6.4: Ukázka prvku Administrativní jednotka <AD: AdminUnitName gml :id=" Obec "> <AD: beginlifespanversion > T09 :22:24 </AD: beginlifespanversion > <AD: validfrom > T09 :22:24 </AD: validfrom > <AD: name > < GeographicalName xmlns =" urn :x- inspire : specification : gmlas : GeographicalNames :3.0 "> < language >ces </ language > < nativeness > endonym </ nativeness > < namestatus > current </ namestatus > < sourceofname > RÚIAN </ sourceofname > < pronunciation >... </ pronunciation > < spelling > < SpellingOfName > <text > Nymburk </ text > <script >Latn </ script > </ SpellingOfName > </ spelling > </ GeographicalName > </AD: name > <AD: level >4 thorder </AD: level > <AD: adminunit xlink : href ="# LAU "/> </AD: AdminUnitName > Příklad 6.5: Ukázka Části obce <AD: AdresAreaName gml :id=" CastObce "> <AD: beginlifespanversion > T09 :22:24 </AD: beginlifespanversion > <AD: validfrom > T09 :22:24 </AD: validfrom > <AD: name > < GeographicalName xmlns =" urn :x- inspire : specification : gmlas : GeographicalNames :3.0 "> < language >ces </ language > < nativeness > endonym </ nativeness > < namestatus > current </ namestatus > < sourceofname > RÚIAN </ sourceofname > < pronunciation >... </ pronunciation > < spelling > Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 80

93 Kapitola 6. Testování datové specifikace < SpellingOfName > <text > Drahelice </ text > <script >Latn </ script > </ SpellingOfName > </ spelling > </ GeographicalName > </AD: name > </AD: AdresAreaName > Příklad 6.6: Ukázka prvku Pošta <AD: PostalDescriptor gml :id="pd. Posta "> <AD: inspireid > <base : Identifier > <base : localid >Posta </ base : localid > <base : namespace >CZ. CUZK.AD </ base : namespace > </ base : Identifier > </AD: inspireid > <AD: beginlifespanversion > T08 :44:05 </AD: beginlifespanversion > <AD: status > current </AD: status > <AD: validfrom > T08 :44:05 </AD: validfrom > <AD: postname > < GeographicalName xmlns =" urn :x- inspire : specification : gmlas : GeographicalNames :3.0 "> < language >ces </ language ><!-- ISO > < nativeness > endonym </ nativeness > < namestatus > official </ namestatus > < sourceofname > RÚIAN </ sourceofname > < pronunciation >... </ pronunciation > < spelling > < SpellingOfName > <text > Nymburk 2</ text > <script >Latn </ script > </ SpellingOfName > </ spelling > </ GeographicalName > </AD: postname > <AD: postcode >28802 </AD: postcode > </ AD: PostalDescriptor > Příklad 6.7: Ukázka prvku Komunikace <AD: ThoroughfareName gml :id="tn. Ulice "> <AD: inspireid > <base : Identifier > <base : localid >Ulice </ base : localid > <base : namespace >CZ. CUZK.AD </ base : namespace > </ base : Identifier > </AD: inspireid > <AD: beginlifespanversion > T09 :23:25 </AD: beginlifespanversion > <AD: validfrom > T09 :23:25 </AD: validfrom > Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 81

94 Kapitola 6. Testování datové specifikace <AD: name > < GeographicalName xmlns =" urn :x- inspire : specification : gmlas : GeographicalNames :3.0 "> < language >ces </ language > < nativeness > endonym </ nativeness > < namestatus > current </ namestatus > < sourceofname > RÚIAN </ sourceofname > < pronunciation >... </ pronunciation > < spelling > < SpellingOfName > <text > Drahelická </ text > <script >Latn </ script > </ SpellingOfName > </ spelling > </ GeographicalName > </AD: name > </ AD: ThoroughfareName > Téma Administrativní jednotky Plnohodnotné testování tématu Administrativních jednotek v současné době není možné, protože systém ISÚI tato data v současnosti ještě neobsahuje. Jediné, co je možné provést, je porovnání části datového modelu ISÚI z popsané datové architektury, protože vývoj ISÚI není dokončen. Z čistého porovnání datové specifikace INSPIRE a navrhovaného datového modelu můžeme konstatovat, že model INSPIRE je možné z datového modelu ISÚI odvodit. Je nutné zmínit, že současný model uložení dat administrativních jednotek v ISÚI je odlišný od modelu popsaném v jeho konceptuálním modelu (Příklad 6.12). Rozdíl spočívá v tom, že v současném stavu v ISÚI chybí veškeré tabulky HRAN_P_* a navíc je zde prázdná tabulka HRAN_OBEC (tabulka by měla obsahovat přímo hranice), o které v datové specifikaci není zmínka. Další testování by mělo probíhat až v případě, kdy bude DB schéma ISÚI shodné se svým datovým modelem a bude naplněno daty. Obrázek 6.12: ISÚI Administrativní jednotky - datová architektura (Zdroj: [2]) Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 82

95 Kapitola 6. Testování datové specifikace 6.3 Testování v jiných státech Postupné budování INSPIRE prostorové databáze (SK) Slovenská republika (Obrázek 6.13) měla pro testování velmi podobné výchozí podmínky jako Česká republika, zvolená architektura pro testování je však zcela jiná. To je dáno tím, že Slovenská strana pro testování využila svého partnera firmu ArcGEO. Tato firma je autorizovaným partnerem firmy ESRI pro Slovenskou republiku, tedy je pochopitelné, že pro testování použila prostředky ESRI. Testování bylo provedeno na k.ú. Skalica, které vhodně sousedí s ČR. Testování prováděl partner, který nemá přímý přístup do databáze slovenského katastru. Jako vstup konverze zde slouží výměnný formát VGI. Tedy na začátku je proveden import VGI do databáze nástrojem ImportVGI (Součást Desktop ArcGIS). Při načtení se tak vytvoří plnohodnotná prostorová databáze, tedy dojde zde i k zaplochování parcel a katastrálního území. Následně se provede souřadnicová transformace do ETRS. Třetím krokem je pak vytvoření INSPIRE databáze, tedy databáze uzpůsobené pro GML výstup. Tato databáze se vyznačuje tím, že jednotlivé typy INSPIRE prvků představují samostatné tabulky a všechny potřebné INSPIRE atributy představují sloupce těchto tabulek. Poté je proveden výstup z této databáze do formátu generického GML. Generické GML představuje obecný a do značné míry i zjednodušený GML zápis, tedy zápis bez použití technologie Aplikačních schémat. Tento obecný zápis je však možné poměrně jednoduše přetransformovat (nebo chcete-li zkonvertovat) do příslušného aplikačního schématu pomocí uživatelsky napsané transformace XSL-T. Zde je potřeba zdůraznit, že o úspěchu této konverze rozhoduje struktura INSPIRE databáze, ze které je proveden výstup generického GML. Výsledné GML je pak vhodné validovat proti příslušnému XML schématu (XSD) a následně zobrazit. Příklady 6.8 a 6.9 představují GML reprezentaci katastrální parcely a katastrální hranice vytvořené slovenským testovacím týmem. Při pohledu na tyto ukázky zjistíme, že automatizovaný zápis GML nejspíše zapříčinil některé formální neduhy ve formě neekonomického zápisu: Každý prvek INSPIRE GML obsahuje definice všech jmenných prostorů (namespaces), s jehož datovými typy/prvky tento GML prvek pracuje. Navíc jsou zde uvedeny i reziduální jmenné prostory MS XSL-T, ESRI a X-Path. Toto je zapříčiněno nízkou nebo žádnou optimalizací XSL-T transformace vytvořenou ve firmě ArcGEO. Jelikož samotná firma ArcGEO tuto transformaci označuje za své know-how, lze jen doufat, že se tato firma nepokusí též proniknout na český trh:-) Další odlišností je způsob zápisu geometrie, kdy všechny geometrie parcel jsou zapsány pomocí elementů GML v.3. Naproti tomu zápis geometrie hranice parcel odpovídá zápisu v ČR. Na druhou stranu je nutné zmínit, že slovenská strana na rozdíl od té české byla schopna poskytnout v rámci prvního a druhého testování přímý zápis geometrie, ne tedy skládáním linií, i když k tomu využila již připravený produkt importvgi. Tedy geometrie slovenských parcel byla lépe připravena pro práci se současnými GML čtečkami. Příklad 6.8: Ukázka kódování slovenské parcely. < CP: CadastralParcel xmlns :xs=" http :// / 2001 / XMLSchema " xmlns : esri =" http :// www. esri. com / schemas / ArcGIS / 9.0 " xmlns :fn=" http :// / 2005 / xpath - functions " Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 83

96 Kapitola 6. Testování datové specifikace xmlns :ms=" urn : schemas - microsoft - com : xslt " xmlns : base =" urn :x- inspire : specification : gmlas - v31 : BaseTypes :3.1 " xmlns :GN=" urn :x- inspire : specification : gmlas - v31 : GeographicalNames :2.0 " xmlns : gmd =" http :// www. isotc211. org / 2005 / gmd " gml :id=" ID_SK. UGKK.KN ">... <CP: geometry > <gml : Surface srsname =" EPSG :25833 " srsdimension ="2"> <gml : patches > <gml : PolygonPatch > <gml : exterior > <gml : LinearRing > <gml : poslist > </ gml : poslist > </ gml : LinearRing > </ gml : exterior > </ gml : PolygonPatch > </ gml : patches > </ gml : Surface > </CP: geometry >... </ CP: CadastralParcel > Obrázek 6.13: Slovensko - testování Příklad 6.9: Ukázka kódování slovenské hranice parcel. < CP: CadastralBoundary xmlns :xs=" http :// / 2001 / XMLSchema " xmlns : esri =" http :// www. esri. com / schemas / ArcGIS / 9.0 " xmlns :fn=" http :// / 2005 / xpath - functions " xmlns :ms=" urn : schemas - microsoft - com : xslt " xmlns : base =" urn :x- inspire : specification : gmlas - v31 : BaseTypes :3.1 " xmlns :GN=" urn :x- inspire : specification : gmlas - v31 : GeographicalNames :2.0 " Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 84

97 Kapitola 6. Testování datové specifikace xmlns : gmd =" http :// www. isotc211. org / 2005 / gmd " gml :id=" ID_SK. UGKK.KN _ ">... <CP: geometry > <gml : Curve srsname =" EPSG :25833 " srsdimension ="2"> <gml : segments > < gml : LineStringSegment > <gml : poslist > </ gml : poslist > </ gml : LineStringSegment > </ gml : segments > </ gml : Curve > </CP: geometry >... </ CP: CadastralBoundary > Export z prostorové databáze (ES) Na chvíli se ještě vrátíme ke Španělsku. Španělský katastr, neuvažujeme zde oblast Baskitska, kde je správa katastrálních dat prováděna odděleně, je možné rozdělit do dvou typů, které přibližně odpovídají našemu pojetí intravilánu (Cadastro Urbano) a extravilánu (Cadastro Rural). Cadastro Rural, jak již bylo zmíněno, umožňuje na cca 1% území geometrii parcely v podobě multipolygonu. Na obrázku 6.14 je zobrazeno mapování generického GML pro Cadasto Urbano v programu Altova Map Force, který používá španělský testovací tým. Přičemž způsob získání generického GML je poměrně odlišný od způsobu, které zvolilo Slovensko. Španělsko totiž jako vstup použilo svou prostorovou databázi katastrálních dat (Sistema de Información Geográfica Catastral, zkráceně SIGCA). Z této prostorové databáze následně vytvořilo odvozením testovací databázi, která se lišila pouze v souřadnicovém systému ETRS. Pro převod z UTM Španělsko použilo k tomu navržený španělský národní grid. Z této databáze následně bylo získáno generické GML pro výsledné mapování. Zbývá jen dodat, že Cadastro Rural extravilan se získá podobným mapováním, pouze zde je odkaz do národního registru sestaven jiným způsobem (Obrázek 6.15). Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 85

98 Kapitola 6. Testování datové specifikace Obrázek 6.14: Španělsko 1: Mapování generického GML do INSPIRE DS (Zdroj: [28]) Obrázek 6.15: Španělsko 2: Mapování generického GML do INSPIRE DS (Zdroj: [28]) Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 86

99 Kapitola 7. Návrh publikační databáze Kapitola 7 Návrh publikační databáze 7.1 Publikační databáze na SCD ČÚZK Publikační databází budeme rozumět takové databázové schéma, které si jako základní požadavek klade snadnost a rychlost publikace svých dat do jiných systémů. Požadavku na snadnost a rychlost publikace dat je pak do značné míry podřízeno vše ostatní, tedy schéma publikační databáze mnohdy odporuje už i první normální formě. Asi nejznámější databází, kterou by šlo v rámci ČÚZK považovat za publikační je databáze dat ZABAGED. Na této databázi se silně projevuje další rys mnoha (starších) publikačních databází a to jsou chybějící vazby mezi jednotlivými záznamy. Vazby zde chybějí, protože pro samotnou publikaci nejsou potřeba a v grafickém výstupu se koncový uživatel mnohdy spokojí pouze se systémem vrstev. Na druhou stranu je potřeba zmínit, že termín publikační databáze není nijak pevně svázán s prostorovými daty. Je tedy možné pracovat i s jiným typem dat (kupříkladu XML), i když se v praxi s těmito databázemi oproti jejich prostorovým kolegům jen zřídka setkáte. Pro potřeby této disertační práce pak pod pojmem publikační databáze (PUB-DB) budeme myslet nově vzniklou databázi prostorových dat v rámci sekce centrální databáze ČÚZK. Tato publikační databáze je reprezentována samostatným databázovým schématem PUBL, které vzniklo z části replikované centrální ISKN (ISKN-R). Data ISKN-R jsou zde brána jako vstupní a jsou konvertována do tvaru vhodného pro další snadnou publikaci dat. V budoucnu se též počítá, že dalším databázovým schématem, které do této databáze přibude, a z něhož budou též prostorová data konvertována do vhodnějšího modelu, bude replikovaná část ISÚI (ISÚI-R). Z takto vytvořené PUB-DB (Obrázek 7.1) budou dále poskytovány různorodé služby. 7.2 PUB-DB v infrastruktuře ČÚZK Stav infrastruktury serverů a datových skladů pro publikaci dat KN byl popsán v kapitole 5. Tento způsob byl též v této kapitole shledán pro budoucnost nevyhovující. Naštěstí po příchodu PUB-DB se situace výrazně mění (Obrázek 7.2). Z datového skladu souborových dat KÚ se dále do datového skladu souborových dat přebírají pouze rastry. K tomu mimo jiné bude docházet až do doby, než bude v ISKN digitální vektorová mapa na celém území Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 87

100 Kapitola 7. Návrh publikační databáze Obrázek 7.1: Publikační databáze - služby (ať již ve formě DKM, KMD nebo nově příchozí ÚKM). Již existující vektorová data jsou však nově s cca dvouhodinovým zpožděním oproti aktuálnímu stavu z centrální ISKN (ISKN-C) z PUB-DB kopírována do datového skladu WKB geometrií, kdy se do datového skladu kopírují vždy jen celá k.ú., na kterých v uplynulé době došlo ke změně grafických dat. Tato data jsou pak součástí datového skladu souborových dat. Z tohoto datového skladu jsou pak všechna data poskytována v podobě rastrů dalším službám (tedy data WKB geometrie se na tomto místě při dotazu uživatele převádějí na odpověď v podobě rastru, popřípadě v budoucnu na GML pro WFS odpověď). Mimo tento datový sklad jsou dále přímo z PUB-DB poskytována data INSPIRE služby stahování celých datových sad. To, co na obrázku kvůli přehlednosti zcela chybí, je rozdělení ISKN-R do dvou pomyslných částí. První část jsou data SGI (Soubor Geodetických Informací) a číselníky ISKN potřebné pro vytvoření nového tvaru geometrie v publikační databázi. Druhou částí je pak SPI (Soubor Popisných informací) potřebný pro aplikaci Nahlížení do KN. 7.3 Návrh PUB-DB Návrh publikační databáze je úzce spjat se závěry datové specifikace INSPIRE pro téma Katastrální parcely a se snahou vytvoření nového Nahlížení do KN, které by mělo výrazně snížit rozdíly v aktuálnosti dat SGI a SPI v tomto systému. Je tedy nutné si uvědomit, že publikační databáze nevznikla pouze z důvodů potřeby řešit požadavky direktivy IN- SPIRE, ale jako komplexní řešení pro většinu grafických dat katastru nemovitostí. Z tohoto důvodu byl sestaven na ČÚZK tým odborníků, kteří se podíleli na návrhu zřízení publikační databáze a s ním spojeném vzniku nového systému Nahlížení do KN. V rámci tohoto návrhu bylo potřeba mimo jiné připravit investiční záměr na zakoupení potřebného HW v podobě samostatného serveru pro tuto databázi a publikačního SW Marushka od firmy GEO- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 88

101 Kapitola 7. Návrh publikační databáze Obrázek 7.2: Publikační databáze - infrastruktura VAP včetně jeho úpravy pro specifické požadavky ČÚZK. Jednou ze součástí podkladů tohoto investičního záměru byl popis schématu nově navrhované publikační databáze. Na návrhu tohoto schématu pracoval tým tří lidí, kteří měli za úkol tento návrh uzpůsobit různým požadavkům pro systémy, které s těmito nově vzniklými daty budou pracovat. Zde je potřeba zdůraznit, že hned z několika důvodů nebylo možné, aby daný návrh zpracoval jeden člověk. Prvním důvodem je rozsah dat ISKN, kdy každý z odborníků uplatnil v návrhu poměrně jedinečné zkušenosti s částí grafických dat ISKN. Tedy každý člen týmu navrhoval tu část schématu, u níž měl velmi dobrý přehled o datech a jejich chybách. Druhým důvodem byl poměrně šibeniční termín na odevzdání tohoto návrhu, z důvodu již zmíněného investičního záměru, který byl řešen ke konci kalendářního roku. Prvotní rozdělení práce se osvědčilo a každý z pracovníků následně pak dále pracoval s těmito daty. Následující položka označená jako Společné nebyla nikdy naplněna a její samotný návrh pouze pracoval s možností implementace až v momentě, kdy tato data budou potřebná. Rozdělení práce: Ing. Jiří Bartoš: katastrální území, katarální parcely a jejich hranice, další prvky dat, metadata. Zde je třeba poznamenat, že tato část je nejobtížnější, protože je zde nutné vytvořit nové souvislé topologické uspořádání hranic parcel, přičemž je potřeba brát v úvahu přesnost jednotlivých podrobných bodů. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 89

102 Kapitola 7. Návrh publikační databáze Mgr. Luboš Matásek: budovy, orientační prvky parcel. Ing. Petr Souček, Ph.D.: rastry a dokončení práce za Mgr. Luboše Matáska po jeho odchodu. Společné: bodové pole, BPEJ, věcná břemena. Investiční záměr byl vedením ČÚZK schválen. Osobně jsem přesvědčen, že za úspěchem schválení bylo právě spojení záměru s novým systémem Nahlížení do KN, protože tento systém tvoří svým způsobem výkladní skříň celého resortu a je veřejností velmi kladně hodnocen. Tedy lze si těžko představit, že by vedení ČÚZK bylo ochotné uvolnit nemalé ale potřebné finance na tento systém, pokud by se týkal pouze INSPIRE. Navíc v době kdy INSPIRE pomalu mizí z prezentací vrcholného managementu (Nahrazen tématem RÚIAN a DMVS:-). Pokud přijmeme tento názor, můžeme konstatovat, že Nahlížení do KN představuje prakticky investora pro implementaci INSPIRE na ČÚZK. Pokud porovnáme způsob testování INSPIRE v ČR a ostatních státech, všimneme si, že přestože mnohé státy (asi nejlepším příkladem je Nizozemí) se problematikou publikace katastrálních dat v GML a různých topologických modelech zabývají poměrně dlouhou dobu, tak dosud nebyly schopny realizovat plnohodnotnou a aktuální databázi katastru nemovitostí, která by odpovídala těmto moderním požadavkům. Naproti tomu ČÚZK, který svým přístupem k vědě a výzkumu v KN se sám v lepším případě staví do role pouhého poskytovatele dat, je schopen díky tomuto investičnímu záměru, který je postaven na reálných základech, tuto databázi ve spolupráci s ČVUT realizovat. 7.4 Schéma PUB-DB Databázové schéma PUBL (Obrázek 7.3) je jedním ze základních schémat publikační databáze. V tomto schématu se uchovávají veškerá geometrická i jiná data pro publikaci. Tabulky schématu PUBL lze pomyslně rozdělit do tří skupin: aktuální stav, minulost a budoucí stav. Budoucímu stavu se budeme věnovat v kapitole 13. K minulosti si uvedeme jen to, že minulost v PUB-DB je uchovávána z důvodu ošetření nekonzistentních stavů. V případě, že k takové nekonzistenci dojde, je možné se vrátit do požadovaného stavu v minulosti, kdy data byla konzistentní. A jelikož je součástí minulosti i soubor údajů popisující změny dat v čase, je možné zpětně dopočítat všechny změny až do současnosti včetně závěrečné kontroly konzistence dat. Přestože jsou minulostní tabulky velmi výhodné, poměrně nenáročné (oproti datům současnosti) a velmi efektivní při ošetřování nekonzistencí, budou nejspíše v budoucnosti odstraněny, protože dle názoru vedení ČÚZK publikační databáze nemá udržovat minulost 1. V následujícím popisu PUB-DB se budeme proto téměř výlučně zabývat částí schématu popisující přítomnost. Základní tabulkou části PUBL schématu popisující přítomnost je databázová tabulka PUB_KATASTRALNI_UZEMI, která slouží jako přehled publikačních jednotek pro následující služby: Import INSPIRE metadat do Geoportálu ČÚZK, publikace WKB geometrií do datového skladu (služba aktualizace WKB) a služba generování INSPIRE GML 1 Toto rozhodnutí nelze vnímat čistě jako negativní, protože jde pouze o pevné stanovení rámce dat a služeb, které budou z publikační databáze poskytovány. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 90

103 Kapitola 7. Návrh publikační databáze Obrázek 7.3: Publikační databáze - schéma souborů pro službu stahování dat celých datových sad. V momentě, kdy bude na PUB-DB napojen i systém ISÚI, přibudou její ekvivalenty pro data adres (PUB_OBCE) a administrativních jednotek (PUB_ADM_JEDNOTKY). Tato tabulka má primární klíč KOD značící šestimístné číslo katastrálního území. Ostatní tabulky, jejichž data mají být publikována, mají vždy sloupec KATUZE_KOD, který představuje sekundární klíč. Tedy záznamy těchto tabulek jsou publikovány v rámci příslušného katastrálního území. Tabulka PUB_HRANICE_PARCEL však představuje výjimku, protože jednotlivé záznamy této tabulky mohou patřit do dvou katastrálních území (KATUZE_KOD a KATUZE_KOD_2). Služba generování INSPIRE GML tak bere v úvahu obě katastrální území, zatímco služba aktualizace WKB pracuje pouze se sloupcem KATUZE_KOD. Chování obou služeb je v současnosti správné, protože data publikovaná službou aktualizace WKB slouží v současnosti jen k vytváření mapových služeb (WMS). V budoucnosti, kdy budou z této služby poskytovány i INSPIRE služby s přímým přístupem, bude muset být tato služba rozhodně upravena. Předjímat jakým způsobem tomu bude, dnes nemá smysl, protože software firmy GEOVAP je nutné upravit pro publikování každého aplikačního schématu zvlášť. Další vlastností publikační databáze je duplikace hlavních grafických dat, kdy je geometrie parcel KN (tabulka PUB_PARCELY_KN) prakticky znovu zopakována v podobě úseků hranic parcel (tabulka PUB_HRANICE_PARCEL). Mapové služby primárně pracují s geometrií hranic parcel, geometrii parcel pak používají jen při práci s novým Nahlížením do KN, kdy dochází ke zvýraznění celého polygonu hledané parcely. Služby vycházející z INSPIRE pak potřebují obě geometrie. Dalším rysem publikační databáze je agregace vedlejších grafických dat do jedné geometrie, kdy jsou značky a šipky parcel KN uloženy do jedné společné geometrie (v případě šipek se může jednat až o kolekci prvků). Dalším poněkud zvlášt- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 91

104 Kapitola 7. Návrh publikační databáze ním rysem je duplicita geometrií v systému ETRS (původní data jsou vždy v S-JTSK). Důvod této duplicity je poskytnutí vysokého výkonu službě stahování dat celých datových sad, kdy je geometrie tímto způsobem vhodně přepočítána. Služby pracující s datovým skladem WKB tuto ETRS geometrii nepotřebují. Pro své operace transformace souřadnic budou využívat přesnou transformaci pouze pro rohy WMS dotazu (nebo ekvivalentu), ostatní body pak budou spočteny interpolací. Zde je nutné zmínit, že i přes velký objem grafických dat, v současnosti cca 20GB pro data v S-JTSK, je velmi výhodné data v ČR udržovat v obou systémech. V ostatních státech poskytovatelé INSPIRE dat Katastrálních parcel, stejně jako ČÚZK, používají nebo hodlají použít transformaci do ETRS se zvýšenou přesností (tedy včetně odstranění lokálních nepřesností vstupního systému). Výkon takové transformace však nejsou většinou poskytovatelé schopni odhadnout, proto raději mnohdy volí publikování dat pro INSPIRE rovnou v ETRS. Poslední vlastností publikační databáze je duplicita geometrie parcel a hranic parcel. A to v původním tvaru s oblouky a kružnicemi a ve zjednodušeném tvaru v podobě liniové interpolace mezi body, kdy sloupec GEOMETRIE je naplněn geometrií s liniovou interpolací a sloupec GEOME- TRIE_ORIGINALNI obsahuje geometrii kružnic a oblouků, pokud existuje. Geometrie budov a katastrálních území je poskytována rovnou ve tvaru liniových úseků. Z geometrie v ETRS je pak primárně poskytována též přímo v liniových řetězcích, výjimku tvoří hranice parcel, které si udržují i originální tvar. Zdánlivá chaotičnost má následující důvody: Data publikovaná podle INSPIRE musejí mít lineární interpolaci mezi body. Pro budoucí možné potřeby KN, je ale výhodné v systému S-JTSK uchovat i originální geometrii parcel a jejich hranic. ETRS originální (nezjednodušená) geometrie u hranic parcel je dána snahou ČÚZK najít rozumný způsob jak dodat uživatelům INSPIRE služeb i originální data. Tato iniciativa však nenašla prozatímní uplatnění (výsledky), ale do budoucna se počítá s možností doplnění velmi topologicky kvalitních výstupů INSPIRE GML o jakýsi doplněk generického GML, ve kterém budou zapsány i zbývající prvky katastrální mapy, které nejsou součástí INSPIRE. 7.5 Procesy v PUB-DB V následujících kapitolách budou postupně popsány procesy uvnitř publikační databáze. Nejprve bude v kapitole 8 popsán způsob, jakým jsou data ISKN konvertována na data ve schématu PUBL. V další kapitole (kapitola 9) pak rozebereme způsob, jakým se do struktur PUB-DB přenášejí informace o přesnosti bodu. V kapitole 10 rozebereme proces migrace dat ISKN do struktur PUB-DB. V následující kapitole (kapitola 11) se budeme věnovat problematice konverze přírůstků ISKN, tento výpočet budeme nazývat výpočtem ZMĚN. V kapitole 12 se následně zmíníme o významných chybách ISKN a jejich přenosu do PUB-DB. Kapitola 13 (Obnova operátu) představuje ukázku praktického využití PUB- DB pro zdroje dat mimo ISKN. Kapitola 14 pak představuje souhrn dosavadního užití PUB-DB. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 92

105 Kapitola 8. Konverze dat ISKN do PUB-DB Kapitola 8 Konverze dat ISKN do PUB-DB Konverzí dat ISKN do PUB-DB budeme rozumět změny struktury prvků, tedy změny jejich reprezentace v záznamech příslušných schémat, z replikovaného schématu ISKN-R do nově navrženého schématu PUBL v publikační databázi PUB-DB. V současné době prvky podléhající konverzi jsou: budovy, parcely a jejich hranice, další prvky mapy (vnitřní kresba parcel), prvky orientační mapy parcel (jedná se o geometrii nových geometrických plánů, které se zobrazují nad digitální rastrovou mapou katastru nemovitostí) a katastrální území. Na návrhu konverze SGI (Souboru Geodetických Informací) se podíleli dva autoři. Konverzi budov a prvků orientační mapy (POM) navrhl Mgr. Luboš Matásek. Ostatní používané konverze jsou dílem autora této práce. Pro naše potřeby si popíšeme konverzi dvou prvků a to dalších prvků mapy a parcel KN a jejich hranic. Na tomto místě je též dobré zmínit, že návrh konverze je do značné míry nezávislý na dalších krocích: návrhu procesu migrující data z ISKN do struktur publikační databáze a výpočtu změn v ISKN. Tyto procesy však kladou na samotnou konverzi některé nároky (zejména nárok na výkon, konverzi pouze části prvku) a tedy mohou výslednou podobu konverze výrazně měnit. 8.1 Další prvky mapy Další prvky mapy (DPM) představují doplnění katastrální mapy o tzv. vnitřní kresbu parcel a texty místního a pomístního názvosloví. Další prvky mapy dělíme na tři typy (Obrázek 8.1). Prvním typem DPM jsou již zmíněné texty, druhým typem jsou značky 1. Tyto dva typy DPM se v mnohém vzájemně podobají, kupříkladu mají shodné atributy; úhel natočení a zvětšení. Prvek text má pak navíc atribut příchytný bod. Proto mechanismus práce s těmito prvky bude až na drobné výjimky shodný. Třetím typem je typ liniového prvku, kdy navíc rozeznáváme dva podtypy. Prvním podtypem je liniový prvek definovaný spojením bodů polohopisu. Druhým podtypem jsou liniové prvky uložené přímo v geometrii Oracle Spatial (u bodů těchto linií tedy v ISKN nepracujeme s přesností). Při konverzi DPM ze schématu ISKN do schématu PUBL budeme pracovat s tabulkou AK_DALSI_PRV- KY_MAPY, která obsahuje jednotlivé DPM, dále s tabulkami AK_SPOJENI_B_POLOH a AK_SOURADNICE_PB. Kde tabulka AK_SPOJENI_B_POLOH představuje vazební 1 Oficiální název v ISKN je typ bodového prvku, jeho jediným významovým typem v DPM je pak značka. My upřednostníme významový typ, protože nám to usnadní další výklad. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 93

106 Kapitola 8. Konverze dat ISKN do PUB-DB tabulku mezi AK_DALSI_PRVKY_MAPY a tabulkou obsahující souřadnice bodů AK_- SOURADNICE_PB 2. Pro rozlišení jednotlivých typů DPM využijeme číselník SC_T_PRV- KU_DAT, který obsahuje velmi podrobný číselník typů prostorových dat (hranice k.ú., parcelní číslo, obvod budovy), kdy je stanoveno, že každý tento prvek prostorových dat může nabývat jen jediného typu prvků (značka, text, linie). Jednotlivé záznamy v tabulce AK_DALSI_PRVKY_MAPY obsahují informaci (sloupec TYPPPD_KOD) odkazující na tabulku SC_T_PRVKU_DAT. Na obrázku 8.2 jsou zobrazeny všechny tabulky ISKN, které budeme pro konverzi DPM do schématu potřebovat. Obrázek 8.1: Další prvky mapy Konverze textů a značek DPM Jak již bylo řečeno dříve, je výhodné pracovat s textovými DPM a značkami DPM zároveň, protože oba typy mají jak ve výchozím schématu ISKN tak i v cílovém schématu PUBL mnoho společného. Pro získání obou typů prvků z ISKN zároveň můžeme kupříkladu využít postup z příkladu 8.1. Pokud budeme potřebovat během konverze vědět, zda se jedná o textový typ nebo značku, můžeme se jednoduše zeptat na počet souřadnic v geometrii. Pokud jsou souřadnice právě dvě, jedná se o souřadnice značky (Příklad 8.2). Pokud je souřadnic více, jedná se o zápis Textového prvku (Příklad 8.3). U textového prvku jsou pro nás zajímavé pouze první tři souřadnice (X a Y bodu textu a výška textu) a pak souřadnice pátá (příchytný bod). Atributem, který mají Textový prvek i Značka stejný, je úhel stočení, který lze získat z kovarianční matice zapsané ve sloupci ROT_MATRIX. Matice rotace dále slouží pro Značky k zápisu měřítka. Příklad 8.1: ISKN výběr Textů a Značek z DPM select * from iskn. AK_ DALSI_ PRVKY_ MAPY where typppd_ kod not in ( select kod from iskn. SC_ T_ PRVKU_ P_ DAT where TYP_ PRVKU =1) 2 Tabulka AK_SPOJENI_B_POLOH zde neprovádí spojení na tabulku AK_SOURADNICE_PB přímo, ale přes tabulku obsahující body polohopisu AK_BODY_POLOHOPISU, tuto tabulku však pro naše potřeby můžeme vynechat, protože tato tabulka obsahuje v obou předchozích tabulkách svůj sekundární klíč v podobě BP_ID, který můžeme využít pro samotnou vazbu. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 94

107 Kapitola 8. Konverze dat ISKN do PUB-DB Příklad 8.2: Obrázek 8.2: Tabulky ISKN tvořící další prvky mapy ISKN geometrie značky DPM MDSYS. SDO_GEOMETRY (2001, null,null, MDSYS. SDO_ELEM_INFO_ARRAY (1,1,1),MDSYS. SDO_ ORDINATE_ ARRAY ( , ) ) Příklad 8.3: ISKN geometrie textu DPM MDSYS. SDO_GEOMETRY (2001, null,null, MDSYS. SDO_ELEM_INFO_ARRAY (1,1,1,3,0,0), MDSYS. SDO_ORDINATE_ARRAY ( , ,6700,4690,1, -1) ) Do schématu PUBL publikační databáze (PUB-DB) jsou všechny tyto grafické elementy zapsány do společné geometrie: Bod je zde zapsán standardním způsobem obvyklým v rozšíření Oracle Spatial, ostatní elementy jsou zapsány jako uživatelská geometrie. Uživatelská geometrie představuje způsob, kterým lze rozšířit standardní zápis geometrie v Oracle Spatial o další uživatelské typy geometrií. V našem případě potřebujeme provést rozšíření o informaci o úhlu stočení, velikosti písma/změně měřítka značky a příchytném bodu pro textové prvky. Změna měřítka a úhel stočení by bylo možné zapsat pomocí Orientovaného bodu, což je vestavěný typ Oracle typ geometrie. Tento typ však není přenosný do jiných databází a navíc zde stále zůstává nevyřešený problém s příchytným bodem. Proto bylo upřednostněno použít uživatelsky definovanou geometrii pro všechny tři typy. Uživatelsky definovanou geometrii poznáme tak, že její druhý prvek v trojici prvků ve struktuře ELEMENT_INFO je roven nula. První prvek trojice ve struktuře ELE- MENT_INFO představuje stejně jako u běžné Oracle geometrie odsazení, tedy index první Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 95

108 Kapitola 8. Konverze dat ISKN do PUB-DB souřadnice. Třetí prvek (prvek interpretace) pak představuje typ uživatelské geometrie. Pro potřeby PUB-DB jsou tedy stanoveny tři typy uživatelské geometrie. Prvním typem je poměr zmenšení (zvětšení) objektu, který je uložen jako neznámý element s interpretací 10 (v poli SDO_ELEM_INFO trojice [offset, 0, 10] ] a v poli SDO_ORDINATES bude uloženo zmenšení). Druhým typem je orientace objektu, která je uložena jako neznámý element s interpretací 11 (v poli SDO_ELEM_INFO bude trojice [offset, 0, 11] a v poli SDO_ORDINATES bude uložena orientace bodu ve stupních [360 ] od osy -x proti směru hodinových ručiček). Posledním (třetím) typem je vztažný bod připojení textu, který je uložen jako neznámý element s interpretací 12 (v poli SDO_ELEM_INFO bude uloženo [offset, 0, 12]) a v poli SDO_ORDINATES bude uložena hodnota z intervalu < 1, 9 > tak, aby odpovídala standardu firmy Gepro pro kódování příchytných bodů. Ukázka geometrie a jejího zápisu je uvedena na obrázku 8.3 respektive příkladu 8.4. Obrázek 8.3: Grafická reprezentace uživatelské geometrie Příklad 8.4: Zápis uživatelská geometrie SDO_ GEOMETRY ( 2001, null,null, SDO_ELEM_INFO (1,1,1, 3,0,10, 4,0,11, 5,0,12), SDO_ORDINATES (2,1, 1.7, 70, 2) ) Konverze přímých grafických prvků DPM Přímé grafické prvky představují liniové prvky, které jsou též přímo zapsány ve sloupci geometrie pomocí geometrie Oracle Spatial. V současné době existují čtyři typy prvků, které mohou být takto zapsány. Jedná se o: Čáru vyplňující schodiště, Hranici chráněného území, Hranici ochranného pásma a tzv. Volnou čáru pro umístění šipky parcely. Poslední zmíněný typ by již dnes neměl vznikat, v současné době však existuje cca 61 tisíc instancí tohoto typu prvku. Pro zajímavost jen uvedu, že tento prvek vznikal v době těsně po migraci do struktur ISKN, kdy do značné míry chyběla zkušenost se správou tak ohromné databáze a nebyla ještě potřeba vazby mezi samotnou parcelou a její šipkou. Převod do struktur PUB-DB je zde velmi jednoduchý. Prakticky stačí pouze prohodit souřadnice X,Y a převést Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 96

109 Kapitola 8. Konverze dat ISKN do PUB-DB je na metry (zdrojová data jsou v milimetrech). Navíc je zde potřeba odstranit duplicitní body, protože DPM jsou často nevalidní. Další častou chybou ve vstupních datech ISKN jsou polygony zapsané pouze svou vnitřní částí dírou. Ošetření této chyby je v příkladu 8.5. Příklad 8.5: Uživatelská geometrie select SDO_GEOM. VALIDATE_GEOMETRY_WITH_CONTEXT ( geometrie,0.001) into zprava from dual ; zmena_ polygon : =0; IF zprava <> TRUE THEN for kk in 1.. info. count () /3 loop IF info (3* kk -1) =2003 THEN info (3* kk -1) :=1003; zmena_ polygon : =1; END IF;... select SDO_GEOM. VALIDATE_GEOMETRY_WITH_CONTEXT ( geometrie,0.001) into zprava from dual ; end loop ; END IF; IF zprava = TRUE THEN... IF zmena_ polygon =1 THEN -- pokud jsem menil polygon, musim to nahlasit! insert into zmeny_log ( zprava, prvek,typ, stav ) values ( Menim vnitrni polygony na vnejsi,vstup,4106,1) ; END IF; ELSE insert into zmeny_log ( zprava, prvek,typ, stav ) values ( SDO Geometrie neni validni ani po vynechani duplicitnich bodu, vstup,4102,1) ; END IF; Konverze DPM vzniklých spojením bodů polohopisu Tento typ DPM je zdánlivě nejsložitější, protože geometrie těchto prvků není přímo uložena ve sloupci geometrie tabulky AK_DALSI_PRVKY_MAPY, ale je zde uložena pomocí již dříve zmíněné vazební tabulky AK_SPOJENI_B_POLOH. Pro získání geometrie (souřadnic) DPM zapsané tímto způsobem využijeme dotaz z příkladu 8.6. Sloupec PARAMETRY_SPOJENI zde slouží k odlišení jednotlivých typů interpolace mezi body geometrie, kterých si čtenář mohl všimnout již na obrázku 8.1. Rozeznáváme zde tedy různé typy spojení bodů: spojení linií (PARAMETRY_SPOJENI=3 nebo PARAMETRY_SPO- JENI=4), spojení bodů kruhovým obloukem (PARAMETRY_SPOJENI=14), spojení do kružnice (PARAMETRY_SPOJENI=15) a posledním typem spojení je spojení obecnou křivkou (PARAMETRY_SPOJENI=13). Parametry spojení 3 a 4 u spojení do linie jsou Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 97

110 Kapitola 8. Konverze dat ISKN do PUB-DB dnes ekvivalentní. Na počátcích ISKN byl parametr spojení 3 definován pro spojení pouze dvou bodů a parametr 4 pro spojení více bodů. Vlivem neexistujících kontrol v software APV (Aplikační programové vybavení), který je používán na jednotlivých KÚ a především pak díky rozdílé implementaci VFK (výměnného formátu katastru) v geodetickém software jsou však rozdíly významu smazány. Spojení do kružnice umožňuje zadání pomocí třech párů souřadnic a pomocí bodu reprezentující střed kružnice a stanovení jeho poloměru. Údaj o poloměru se připojuje do informace o typu interpolace do sloupce PARAME- TRY_SPOJENI. Při konverzi do schématu PUBL se zachovává u kruhových oblouků jejich původní geometrie (nedochází zde k nahrazování oblouků liniovým řetězcem o stanoveném maximálním odklonu od původní geometrie). Jelikož ale není možné zapsat geometrický typ kružnice 3 v geometrii Oracle Spatial, je nutné uložit do schématu PUBL geometrii náhradní. Tato náhradní geometrie je pak reprezentována dvěma kruhovými oblouky, jehož liché resp. sudé body vyznačují poloměr. Z této geometrie je tedy snadné zpětně dopočítat střed a poloměr původní kružnice. Geometrie v Oracle Spatial též neumožňuje pracovat s obecnými křivkami, proto je nutné tuto geometrii též upravit před uložením do schématu PUBL. Úprava geometrie spočívá v nalezení podrobných bodů B-spline křivky, které budou výchozí křivku reprezentovat s dostatečnou přesností. Samotná implementace byla provedena dle zdrojového kódu Ing. Karla Janečky, Ph.D., který tuto funkci použil ve své disertační práci (Zdroj: [22]). Autorem této funkce je pak firma Gepro. Důvodem, proč je implementace křivek přebírána, je snaha sjednocení jejich zobrazení alespoň v rámci software ČÚZK. Tedy stejná implementace je (bude) i v jiných systémech ČÚZK. Příklad 8.6: DPM z bodů polohopisu select X, Y, PORADOVE_ CISLO_ BODU, PARAMETRY_ SPOJENI from iskn. AK_ SPOJENI_ B_ POLOH spoj join iskn. AK_ SOURADNICE_ PB sour on spoj. BP_ID = sour. BP_ID where spoj. dpm_id =% DPM_ID order by PORADOVE_ CISLO_ BODU 8.2 Konverze parcely KN s geometrií Všechny parcely v ISKN jsou uloženy v jediné tabulce AK_PARCELY. Pro potřeby publikační databáze tyto parcely rozdělíme (Obrázek 8.4) na parcely zjednodušené evidence (parcely ZE jsou uloženy v tabulce PUB_PARCELY_ZE) a parcely katastru nemovitostí (parcely KN jsou uloženy v tabulce PUB_PARCELY_KN, jejich případná geometrie je pak uložena v tabulce PUB_HRANICE_PARCEL). Z parcel ZE jsou do PUB-DB přeneseny pouze ty parcely, které mají svůj definiční bod (cca 10% parcel ZE). Parcely KN dělíme na dva typy. Prvním typem je parcela, které chybí geometrie hranic parcely (parcela KN s definičním bodem) a druhým je pak plnohodnotná parcela KN, která má geometrii svých hranic v ISKN. Oba dva typy jsou konvertovány do PUB-DB do společné tabulky PUB_PARCELY_KN. Pro rozeznání, zda má parcela KN geometrii nebo jen definiční bod, 3 V Oracle Spatial existuje typ geometrie kruh (kruhový polygon), ten však nelze pro tyto účely využít, protože se jedná o prostorový nikoliv liniový prvek. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 98

111 Kapitola 8. Konverze dat ISKN do PUB-DB lze jednoduše využít atributů geometrie, hranice (topologie), vypočtená výměra (výměra z SGI), které má vyplněné pouze parcela s geometrií hranic. Tedy není zde nutný dotaz do tabulky PUB_HRANICE_PARCEL, jak je tomu v případě ISKN. Obrázek 8.4: Parcely v ISKN Parcela KN s geometrií svých hranic je ze všech typů nejzajímavější, protože její konverze do schématu PUBL obsahuje všechny dílčí konverze atributů ostatních typů parcel a navíc přidávává konverzi geometrie hranic parcely, která je z hlediska implementace vůbec nejsložitější konverzí. Proto se v dalším povídání budeme zabývat výhradně parcelou KN s geometrií. Na obrázku 8.5 jsou zobrazeny atributy takovéto parcely (duplicitní geometrie v ETRS jsou pro přehlednost vynechány) ve schématu PUBL. Značka (ikona) vykřičníku značí, že daný atribut se musí nalézat ve schématu ISKN, pokud chceme tuto parcelu uložit do schématu PUBL. Otazník značí, že atribut je volitelný a značka zámku značí, že atribut je vázaný (spočitatelný z povinného atributu v ISKN). Specifickým atributem je geometrie parcelního čísla, která je principiálně povinná, ale vzhledem k chybám v ISKN tento atribut může chybět. Obrázek 8.5: Atributy parcely KN Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 99

112 Kapitola 8. Konverze dat ISKN do PUB-DB Konverze drobných geometrických prvků Drobnými geometrickými prvky máme na mysli geometrii definičního bodu, značek druhů pozemku, parcelních šipek a čísel parcel. Pro tyto konverze využijeme ISKN tabulky z obrázku 8.6. Obrázek 8.6: ISKN drobné geometrické prvky parcel Konverze definičního bodu Definiční bod parcely lze jednoduše získat z tabulky AK_OBRAZY_DEF_BODU, kde je přímo uložen v Oracle prostorové geometrii. Ve vlastním řešení je nezbytně nutné provádět testování na existenci definičního bodu parcely, protože může nastat situace, kdy parcela KN nemá definiční bod. Tento stav nemůže být vždy vyhodnocen jako chyba, protože kupříkladu cca dva až tři dny před samotným zplatnění přepracované obnovy operátu obnovou operátů se na jednotlivých katastrálních pracovištích ruší všechny definiční body parcel KN. Pro potřeby konverze však budeme požadovat existenci definičního bodu parcely v ISKN za nutnou podmínku pro vytvoření této parcely v PUB-DB Konverze parcelních šipek a parcelních čísel Parcelní šipky a značky jsou uloženy v ISKN v tabulce AK_OBRAZY_PARCEL. Na obrázku 8.7 jsou zobrazeny tři základní konfigurace. Na obrázku 8.7/a je nejjednodušší případ, kdy je možné parcelní číslo umístit uvnitř parcely (šipka parcelního čísla tedy není Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 100

113 Kapitola 8. Konverze dat ISKN do PUB-DB potřeba). Záznam parcelního číslo má v tomto případě v tabulce AK_OBRAZY_PARCEL buď typ kódu prostorových dat (sloupec TYPPD_KOD) nastaven na 18 v případě, že se jedná o pozemkovou parcelu nebo 28 v případě stavební parcely. Záznam parcelního čísla v ISKN má též své zvětšení a otočení zapsané ve sloupci ROTMATRIX, a příchytný bod zapsaný jako pátou souřadnici v geometrii (tedy stejně jako u DPM). Zápis v PUB- DB je pak proveden přes uživatelskou geometrii, popsanou dříve. Druhý příklad (obrázek 8.7/b) pak zobrazuje situaci, kdy parcelní číslo nelze, kvůli svým rozměrům, umístit přímo do parcely. Proto je toto parcelní číslo vyvedeno mimo parcelu pomocí parcelní šipky. V tomto případě stačí k vyvedení parcelního čísla pouze standardní šipka o délce 2m. Tato šipka je zapsána v ISKN svým bodem, úhlem rotace a zvětšením ve sloupci ROTMATRIX. Od jiných záznamů tuto šipku poznáme podle typu kódu prostorových dat, který je zde nastaven na V PUB-DB je pak tato šipka též zapsána jako uživatelská geometrie. Zejména z důvodu vyhledávání je v parcele dále ponecháno zmenšená parcelní číslo s velikostí textu 0.1m (minimální velikost, která zaručí, že se tento prvek nezobrazí). Toto zmenšené parcelní číslo má v ISKN typ prvku prostorových dat nastaven na Do PUB-DB se zmenšené parcelní čísla nepřenášejí. Výjimkou jsou parcely, které vlivem chyb v ISKN postrádají parcelní číslo plné velikosti. Poslední případ (obrázek 8.7/c) zde doplňuje předchozí o tzv. složenou šipku parcelního čísla, kde je tato šipka v ISKN rozdělena na svou pevnou část (popsanou v předchozím příkladu) a jednu nebo více volných částí. Volné části šipky jsou linie/lomené čáry o dvou a více bodech vzájemně na sebe navazující. Tyto volné části šipky mají v ISKN typ kódu prostorových dat nastaven na 1033 a jsou zde zaznamenány jako linie v Oracle Spatial. V PUB-DB je složená šipka zaznamenána jako kolekce, kdy jsou nejprve uvedeny volné části šipky a pak jejich zakončení v podobě pevné části. Obrázek 8.7: Parcelní šipky a parcelní čísla Konverze značek Zápis značek parcel je podobný zápisu značek dalších prvků mapy jak v ISKN (otočení a zvětšení je zadáno v parametru ROTMATRIX), tak i ve schématu PUBL, kde se pro zápis těchto atributů používá uživatelská geometrie popsaná v této kapitole. Značky parcel Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 101

114 Kapitola 8. Konverze dat ISKN do PUB-DB jsou v ISKN zapsány v tabulce AK_OBRAZY_PARCEL. Pro získání všech značek jedné parcely využijeme dotaz z příkladu 8.7. Příklad 8.7: Získání značek příslušné parcely select geometrie. sdo_geom.x, geometrie. sdo_geom.y, TYPPPD_KOD, ROTMATRIX from AK_ OBRAZY_ PARCEL where typppd_kod not in (18,1018,28,1032,1033) and par_id =% PAR_ID Konverze geometrie hranic parcely Při práci s geometrií hranic parcel budeme potřebovat ISKN tabulky z obrázku 8.8. Pro získání všech hranic parcel (až do úrovně samostatných bodů) můžeme využít dotaz z příkladu 8.8. My však navíc potřebujeme pracovat s přesností (třídami přesností) jednotlivých bodů. Před samotným příchodem systému dvojích (polohy a obrazu) souřadnic do ISKN by bylo možné použít téměř stejný dotaz pouze rozšířený o atribut KODCH_KOD (třída přesnosti). S příchodem systému dvojích souřadnic se vše však ztíží, protože jediný bod z tabulky AK_BODY_POLOHOPISU (tato tabulka na obrázku 8.8 není, protože již v povídání o DPM jsme konstatovali, že pro konverze není přímo potřeba) může mít v tabulce AK_SOURADNICE_PB dva záznamy. Prvním záznamem je bod polohy (PLATNA= a ), druhým pak bod obrazu (PLATNA= n ). V ISKN je dále dáno, že bod polohy musí vždy existovat a přesnost bodu (třída přesnosti) je stanovena u jednoho z bodů (jsou zde přímo stanovena pravidla, ale vzhledem k chybám v ISKN není vhodné se na ně spoléhat). Proto je vhodné výsledný dotaz upravit dle příkladu 8.9. Dalším ztížením je zavedení pravidel na změnu přesnosti bodu (tyto změny jsou popsány v samostatné kapitole 9). Z tohoto důvodu zavádíme novou tabulku PUBL.PUB_SPOJENI_PRESNOST (Obrázek 9.1), která má za úkol agregovat body, na nichž se mění přesnost. Výsledný dotaz je pak uveden v příkladu Příklad 8.8: Hranice parcel bez přesností bodů select hp.id HP_ID,sp. poradove_cislo_bodu PORADI, sp. parametry_ spojeni SPOJENO, s. geometrie. sdo_point.x X,s. geometrie. sdo_point.y Y from iskn. ak_ hranice_ parcel hp join iskn. ak_spojeni_b_poloh sp on sp. HP_ID =hp. ISKN_ID join iskn. ak_souradnice_pb s on sp. BP_ID =s. BP_ID order by hp.id,sp. poradove_cislo_bodu ; Příklad 8.9: Hranice parcel s přesností bodů, ale bez jejich změn select hp.id HP_ID,sp. poradove_cislo_bodu PORADI, sp. parametry_ spojeni SPOJENO, s1. geometrie. sdo_point.x X,s1. geometrie. sdo_point.y Y, s2. kodchb_ kod PRESNOST Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 102

115 Kapitola 8. Konverze dat ISKN do PUB-DB from iskn. ak_ hranice_ parcel hp join iskn. ak_spojeni_b_poloh sp on sp. HP_ID =hp. ISKN_ID join iskn. ak_souradnice_pb s1 on sp1. BP_ID =s. BP_ID join iskn. ak_souradnice_pb s2 on sp1. BP_ID =s. BP_ID where s1. PLATNA = a and s2. kodchb_ kod is not null order by hp.id,sp. poradove_cislo_bodu ; Příklad 8.10: Hranice parcel se změněnou přesností bodů select hp.id HP_ID,sp. poradove_cislo_bodu PORADI, sp. parametry_ spojeni SPOJENO, s1. geometrie. sdo_point.x X,s1. geometrie. sdo_point.y Y, nvl ( spp. nova_presnost,s2. kodchb_kod ) PRESNOST from iskn. ak_ hranice_ parcel hp join iskn. ak_spojeni_b_poloh sp on sp. HP_ID =hp. ISKN_ID join iskn. ak_souradnice_pb s1 on sp1. BP_ID =s. BP_ID join iskn. ak_souradnice_pb s2 on sp1. BP_ID =s. BP_ID left outer join pub_ spojeni_ presnost spp on ( spp. hp_id = sp1. hp_id and spp. poradove_cislo_bodu = sp1. poradove_ cislo_ bodu ) where s1. PLATNA = a and s2. kodchb_ kod is not null order by hp.id,sp. poradove_cislo_bodu ; Všechny výše uvedené dotazy však mají jednu nepříjemnost. Zatímco jednotlivé body jsou zde hezky uspořádány v rámci hranice parcely, v ISKN neexistuje způsob, jakým lze získat vzájemné uspořádání hranic parcel v parcele. O tom, že by toto uspořádání obsahovalo i vzájemnou orientaci, ani nemluvě. O samotném algoritmu, který vede k získání takového uspořádání se zmíníme v této kapitole dále a v kapitole pojednávající o chybách ISKN (kapitola 12). Nyní se soustředíme na jiný méně zřejmý problém, který spočívá v tom, že i když nalezneme velmi výkonný algoritmus tvorby geometrie parcely KN, tak výkon tohoto algoritmu bude výrazně degradován nutností pracovat s předem definovanými dotazy pro výběr hranic parcel. Proto je vhodné dotaz z příkladu 8.10 uzpůsobit pro výkon. Nejlepší je tuto optimalizaci provést ve dvou krocích. V prvním kroku se velmi podobným dotazem jako je v příkladu 8.10 dotážeme do schématu ISKN pro velké množství parcel (cca ). Výsledek tohoto dotazu pak uložíme do pomocné tabulky, nad kterou následně vytvoříme indexy a spočteme příslušné statistiky. Ve druhém kroku pak vytvoříme částečnou kopii (pro cca parcel) této pomocné tabulky a opět zde dodatečně vytvoříme potřebné indexy a statistiky. Nad touto tabulkou je možné vytvářet velmi efektivní dotazy. Při výpočtu geometrie parcel se též počítají hranice parcel ve schématu PUBL, které mají jiné identifikátory i uspořádání (hranice parcely v ISKN je jiná než hranice parcely ve schématu PUBL, viz kapitola 9). Tyto hranice se vždy po výpočtu vracejí do tabulky malé kopie dočasné tabulky a původní hranice ISKN se z této tabulky vymažou. Po dokončení výpočtu parcel je nutné všechny tyto změny přenést do originální (velké) dočasné tabulky. V této (velké) tabulce pak dojde k opětovnému vytvoření indexů a spočtení statistik. Výpočet pokračuje výběrem dalších parcel. Přestože mluvíme o dočasných tabulkách, pro jejich implementaci nepoužijeme Oracle dočasné ta- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 103

116 Kapitola 8. Konverze dat ISKN do PUB-DB Obrázek 8.8: ISKN geometrie hranic parcel KN bulky (GLOBAL TEMPORARY TABLE). Protože budeme výsledný proces provozovat v paralelním prostředí (kapitola 10) a tyto tabulky neumožňují vytváření a rušení indexů v konkurenčním prostředí (výpočet v různých sessions) a proto jejich použití nepřináší žádné výhody. 8.3 Poznámky k použitým algoritmům Tvorba geometrie parcely KN Algoritmus tvorby geometrie parcel a k.ú. představuje nejsložitější část výpočtu, ať již procesu migrace nebo výpočtu ZMĚN. Výsledný algoritmus se výrazně liší od tzv. ideálního až snového algoritmu, který by byl nejlépe reprezentován svým objektovým rozhraním a pracoval nad topologicky čistými daty KN s dostatečným, ba přímo oslnivým, výkonem. Reálná implementace je naproti tomu výrazně uzpůsobena jak pro hledání možných chyb v datech, tak i vysokým požadavkům na výkon. Kdy především druhý požadavek naprosto mění strukturu výpočtu geometrie. A to jednak tak, že výpočet jednotlivých geometrií seskupuje do výpočetních jednotek a také tím, že výrazně pozměňuje výpočet geometrie samotné parcely. O výpočetních jednotkách parcel jsem se již zmínil v této kapitole (chybami v datech se budeme zabývat v kapitole 12), proto se nyní zaměříme na výpočet ge- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 104

117 Kapitola 8. Konverze dat ISKN do PUB-DB ometrie jedné parcely/k.ú. Schéma výpočtu je znázorněno na diagramu aktivit na obrázku 8.9. Zde je potřeba zdůraznit, že nalezený model výpočtu představuje jen jeden z možných způsobů. Tento model je výhodný kvůli svému vysokému výkonu a modularitě. Na druhou stranu je tento model velmi složitý a to zejména ve své implementaci, při které opět dochází k poměrně radikální optimalizaci. Pro srovnání asi nejjednodušší model, který by bylo možné k výpočtu použít, je jednoduchý algoritmus pracující s backtrackingem. Backtracking zde představuje dostatečně robustní mechanismus pro ošetření významných topologických chyb i vyřešení průchodu uzlovými body (viz. dále). Problémem tohoto řešení je malý výkon, který je způsoben nutností použít validační funkci Oracle jako jedinou autoritu rozhodující o správnosti celé geometrie. Pokud bychom chtěli myšlenku backtrackingu dále rozvíjet, je možné tento algoritmus postupně rozšiřovat o další podmínky, které budou výrazně redukovat nutnost validace geometrie, ale budou se čím dál přibližovat řešení popsanému níže. Při pohledu na schéma je též dobré si uvědomit, že backtracking může vyřešit pouze spojení linií do objektů. Samotné rozhodnutí, zda je objekt součástí vnitřní nebo vnější obálky geometrie, musí být určeno jinými algoritmy. V prvním kroku je výhodné určit linie ISKN, které jsou uzavřené a tedy reprezentují samostatný objekt obálky 4 geometrie. Tyto linie dočasně vyřadíme z dalších výpočtů a znovu je zařadíme až do kroku šest jako samostatné objekty. V druhém kroku následně odstraníme všechny volné konce, ve třetím pak zkontrolujeme, zda se na všech bodech střetává sudý počet hranic, přičemž z výpočtu jsou samozřejmě vyřazeny uzavřené linie a střetávání je povoleno jen na koncových bodech linií. Všechny tři výše zmíněné kroky jsou prováděny pomocí SQL dotazů nad dočasným (upraveným) modelem repliky ISKN a jsou doplněny o další nutnou logiku v PL/SQL, protože kupříkladu využití rekurzivního SQL se výkonově neosvědčilo. Základní popis těchto algoritmů naleznete v kapitole o topologických chybách. Jedním z artefaktů, Obrázek 8.9: Výpočet geometrie parcely KN 4 Obálkou (vnitřní/vnější) budeme rozumět soubor všech objektů geometrie, které definují vnitřní/vnější hranici polygonu. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 105

118 Kapitola 8. Konverze dat ISKN do PUB-DB které získáme v těchto krocích, jsou i tzv. uzlové body. Uzlové body představují body, ve kterých se střetávají více než dvě linie. Tyto body pro nás znamenají problém. Máme sice zaručena topologicky čistá data pro výpočet jedné geometrie, nemůžeme ale přistoupit rovnou k sestavení geometrie jednotlivých objektů geometrie, protože si nemůžeme být při skládání jednotlivých linií do objektů dopředu jisti, zda tam skutečně patří a zda nejsou ve skutečnosti součástí jiného objektu. Proto provedeme nejprve spojení linií ISKN do tzv. uzlových linií, tedy linií mezi uzlovými body. Poté provedeme spojení těchto uzlových linií do objektů. Nejjednodušším typem spojení je pouhé uzavření linie. Složitějším spojením je spojení dvou linií, pokud mají oba koncové body stejné. V praktickém řešení však musíme počítat i s mnoha složitějšími způsoby spojování, kdy je možné se opět vrátit k použití jednou zavrhnutého backtrackingu nebo se pokusit najít jiný (náhradní) algoritmus, který bude výkonnější. Takový algoritmus se už podařilo najít. Algoritmus spočívá v iteračním výpočtu skládajícím se ze tří kroků. V prvním kroku vždy spojíme uzlové linie, pokud je jejich počáteční a koncový bod totožný. V druhém kroku následně odstraníme z uzlových bodů ty body, na nichž se nestřetávají více než dvě uzlové linie. Ve třetím kroku pak spojíme jednoznačně spojené uzlové linie (bodem spojení zde je bod právě vyřazený z uzlových bodů) a následuje výpočtem další iterace. Podmínka přechodu na další iteraci může být volena různě (rušení jednoho uzlového bodu, pokles počtu neuzavřených uzlových linií,...) je však krajně nevhodné volit jako podmínku existenci nevyřazeného uzlového bodu, protože je možné najít takové grafy reprezentující geometrii, které nepůjde tímto algoritmem vyřešit (Obrázek 8.10). Tento algoritmus Obrázek 8.10: V současnosti neřešitelná topologická uspořádání však vždy nalezne správné řešení pro geometrii s jedním vnějším objektem, což odpovídá parcelám KN a většině geometrií celých k.ú. Pro regiony s dvěma resp. třemi vnějšími obálkami dané řešení neexistuje pouze v případě, že vstupní geometrie obsahuje velmi specifickou chybu v podobě duplicitních linií jako vnitřních prázdných polygonů (Obrázek 8.10/a). V tomto případě je však vhodné se zabývat odstraněním topologické chyby a ne se snažit geometrii s touto chybou zapsat. Pro regiony se čtyřmi a více vnějšími objekty je možné najít takové případy, kdy je možné najít topologicky validní reprezentace, ale daný algoritmus při jejím hledání selže. Skutečnost, že každý objekt takové geometrie musí mít minimálně tři uzlové body, vytváří minimální pravděpodobnost, že taková geometrie aktivního obvodu k. ú. pokrytého digitální mapou vznikne. V případě, že by však nad daty KN k něčemu takovému došlo (od roku 2008 do současnosti máme zaručeno, že taková Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 106

119 Kapitola 8. Konverze dat ISKN do PUB-DB geometrie nevznikla, dřívější testy nejsou dostupné), výpočet nové geometrie selže a toto selhání se zaloguje. Další ošetření v současnosti není potřeba, protože data s digitální mapou na části nejsou v současnosti předmětem INSPIRE a další využití není. Na obrázku 8.11 je zobrazen počet kroků potřebných k vyřešení ukázkových geometrií, kdy je zřejmé, že daný algoritmus umožňuje řešit i velmi složité geometrie s velmi malým počtem iterací. V praxi pak k vyřešení stačí použít maximálně dvě iterace, přestože obsahuje cca 6-12 uzlových bodů. Obrázek 8.11: Počet kroků potřebných k vyřešení topologie parcely Poté, co máme geometrii jednotlivých objektů geometrie, je potřeba určit, zde jsou tyto objekty součástí vnitřní nebo vnější obálky geometrie. Pro geometrii parcely toto lze jednoduše určit pomocí přibližného určení plochy opsaného obdélníku jednotlivých objektů. Kdy objekt s největší plochou je vnější obálkou a ostatní jsou pak součástí vnitřní obálky. Pro hledání geometrie regionu je potřeba daný algoritmus upravit. Nejprve vybereme objekt s největší plochou a následně určujeme, zdali ostatní objekty nejsou uvnitř tohoto objektu. Pro implementaci je vhodné použít algoritmus založený na počtu průchodů paprsků objektem (Ray casting/crossing number algorithm). Předposledním krokem je určení správné orientace každé hranice ISKN příslušné jednotlivým objektům geometrie v závislosti na své původní orientaci a na tom, zda patří k vnější/vnitřní části obálky. Poté je možné přikročit k poslední fázi v podobě zápisu geometrie do struktur Oracle Spatial Reprezentace kružnic pomocí liniových řetězců Pro potřeby poskytování dat dle směrnice INSPIRE je nutné převést všechny kruhové oblouky a kružnice na liniové řetězce. V Oracle Spatial je přímo dostupná funkce (SDO_- ARC_DENSIFY z balíku SDO_GEOM), která by měla být schopna zajistit pro zadanou geometrii její zjednodušený tvar při požadované přesnosti. Při použití této funkce však může být uživatel nepříjemně překvapen. Prvním problémem je skutečnost, že tato funkce obsahuje ve verzi Oracle Spatial 11.1 chybu. V případě, že se rozhodnete tuto funkci použít, může to vést až k pádu celého databázového stroje. Tato chyba je následně odstraněna ve verzi Oracle 11.2, publikační databáze (PUB-DB) však i pro svůj ostrý provoz bude používat stále dřívější verzi (11.1). Druhým problémem je pak skutečnost, že použitý al- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 107

120 Kapitola 8. Konverze dat ISKN do PUB-DB goritmus nezaručí stoprocentně topologicky čistý model 5. Oba dva problémy pak vedou k tomu, že je nutné pro PUB-DB vyvinout vlastní způsob konverze kruhových oblouků do liniových řetězců. Stejně jako v Oracle Spatial tato funkce má dva vstupní parametry: vstupní geometrii a maximální požadovaný odklon (toleranci) výsledné linie od té vstupní. Z pohledu implementace do PUB-DB je vhodné tuto funkci rozdělit na dvě. První funkce bude pracovat pouze s liniemi. Tato funkce nebude brát jakýkoliv ohled na orientaci vstupní linie. Tedy pokud tuto funkci použijeme pro linii a její převrácenou kopii (začínající od konce), mohou být obě výstupní linie odlišné. K tomu může dojít jen u hranic parcel na okraji katastrálních pracovišť. Toto si můžeme z pohledu INSPIRE dovolit, protože tyto hranice mají PAR_ID_2 prázdné, tedy explicitně prohlašujeme, že tyto hranice jsou součástí jen jedné parcely. Výsledné chyby vznikají tedy pouze spojením tzv. ostrovních map, které o sobě navzájem nevědí (z pohledu INSPIRE se tedy jedná o tzv. kontrolované topologické mezery). Při samotné implementaci této funkce pak máme na výběr z mnoha způsobů. Prvním způsobem (Obrázek: 8.12/a) je rozdělení kruhového oblouku na stejné úseky, které budou mít lepší nebo stanovenou přesnost. Tento způsob je obecně velmi výhodný, ale není možné zpětně získat přesnost těchto oblouků. Druhým způsobem (Obrázek: 8.12/b) je rozdělení kruhového oblouku na úseky o stanovené přesnosti a to co zbyde pak ponechat na konci původního kruhového oblouku. Třetím způsobem (Obrázek: 8.12/c) je obdobný postup, ale zbývající úsek je ponechán uprostřed nové linie. Takový způsob má výhodu, že v případě, že na sebe navazují dvě hranice parcel v podobě kruhových oblouků, je zaručeno, že jejich liniové reprezentace se nebudou protínat (Obrázek: 8.13). Pro implementaci v PUB-DB byl vybrán poslední zmíněný způsob. Je nutné zmínit, že výměna algoritmu je jen otázkou několika málo desítek minut (včetně přepočtení všech kruhových oblouků). Obrázek 8.12: Různé způsoby převodu kruhového oblouku Druhá funkce bude pracovat s polygony, úkolem této funkce je pak zaručit, aby jedna linie (byť převrácená) byla vždy převedena na linii stejným způsobem. Přitom je nutné brát ohled na skutečnost, že polygon (v současnosti parcela KN) může obsahovat kruhové oblouky, které sousedí s různými polygony. Tedy pro jeden polygon nemusí existovat jediná orientace pro všechny jeho kruhové oblouky (Obrázek 8.14/a). Namísto toho je vhodné orientaci kruhového oblouku při vstupu do funkce převádějící pouze linie určovat pro každý 5 Tedy pokud provádíme konverzi dvou geometrií, které mají společnou hranici v podobě kruhového oblouku, není nikterak zaručeno, že výsledný liniový řetězec reprezentující danou část hranice bude v obou geometriích stejný. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 108

121 Kapitola 8. Konverze dat ISKN do PUB-DB Obrázek 8.13: Chyba na styku dvou kruhových oblouků kruhový oblouk zvlášť. Pro samotné rozhodování, zda kruhový oblouk převést v tomto nebo převráceném pořadí, je nejlepší použít souřadnice počátečního a koncového bodu. Na obrázku 8.14/b je ukázka takového porovnání, kdy jsou nejprve porovnány souřadnice Y a pokud jsou shodné, tak porovnáváme i souřadnice X. Obrázek 8.14: Orientace kruhových oblouků při převodu na linie Transformace do ETRS Databázový systém Oracle obsahuje též podporu převodu mezi jednotlivými souřadnicovými systémy. Tyto transformace jsou však určeny výhradně pro práce, kde se vysloveně vyžaduje nízká přesnost (v řádech metrů). Někdy se dokonce můžeme setkat se zděšením u GIS uživatelů nad samotnou přesností transformací v Oracle, kteří jsou zvyklí na přesnost ze systému Projection 6. Proto je nutné pro potřeby publikační databáze, kde budeme pracovat s daty katastru nemovitostí a kde požadujeme vyšší kvalitu transformace, dodat vlastní transformaci z S-JTSK do ETRS. Pro tuto transformaci byly využity závěry projektu Realizace S-JTSK/05 (Zdroj: [23]), který byl realizován skupinou odborníků z Výzkumného ústavu geodetického, topografického a kartografického a Stavební fakultou ČVUT v Praze. V této práci se prof. Jan Kostelecký spolu s dalšími spoluautory zabývá definováním a realizací nového (homogenního) souřadnicového systému a jeho vztahu k ETRF2000. Součástí závěrů projektu je i zdrojový kód programu v jazyce FORTRAN, 6 Projekt Proj.4, URL: Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 109

122 Kapitola 8. Konverze dat ISKN do PUB-DB který má zabezpečit transformaci ze systému S-JTSK do systému ETRS. Pro implementaci transformace z S-JTSK (katastrální mapa je definována v nulové nadmořské výšce) do ETRS je pak vycházeno právě z tohoto software, kdy je též na konci proveden test shody transformace. Na tomto místě se nebudeme zabývat popisem jednotlivých kroků transformace, ale na místo toho si zde uvedeme některé implementační závislosti. Implementace v PUB-DB je v současnosti provedena v PL/SQL, které bylo upřednostněno před jazyky Java a C++ (externí procedura) čistě z důvodů provozně organizačních. I když původní návrh počítal s implementací v C++ jako externí procedury. Z důvodu výběru PL/SQL je nutné upravit mechanismus práce s bikubickou dotransformací a s daty kvazigeoidu, kde jsou data během výpočtu dostupná v PL/SQL asociativním poli. Tato data jsou pak, vzhledem ke svému objemu, uložena v samostatných SQL tabulkách. Celou transformaci je vhodné implementovat jako samostatný balíček (package) a samotné načítání dat z SQL tabulky do asociativního pole je vhodné provádět mimo jeho konstruktor. Na obrázku 8.15 je zobrazen prostorový rámec všech dat ČÚZK vypočtený z velmi podrobného obvodu České republiky (data systému ArchiWeb) v S-JTSK (červeně) a ETRS(modře). Prostorový rámec ETRS je zde, pro společné zobrazení, zpětně transformován do S-JTSK. Obrázek 8.15: Prostorový rámec všech dat ČÚZK pro metadata v S-JTSK(červeně) a ETRS(modře) Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 110

123 Kapitola 9. Systém obarvování hranic parcel Kapitola 9 Systém obarvování hranic parcel Přesnost parcel DKM/KMD v databázi ISKN je reprezentována přesností jednotlivých podrobných bodů a pomocí jejich zařazení do třídy přesnosti (1-8) bodů. S tímto modelem je možné vystačit nejenom pro potřeby ISKN, ale je ho možné použít i pro zobrazení. Ať již tak, že ke každému podrobnému bodu parcely přidáme čistě textový atribut nebo využijeme barevného odlišení. Tento model však naštěstí není podporován datovým formátem tématu Katastrální parcely směrnice INSPIRE, protože se jedná o příliš podrobný údaj, který je jen těžce využitelný pro potřeby GIS. Datová specifikace naproti tomu pracuje buďto s přesností všech parcel v datové sadě nebo jejích jednotlivých hranic. Způsobů, jakým lze provést konverzi přesnosti podrobných bodů na přesnost liniovou nebo celé parcely, je bezpočet. Různé způsoby transformace využívají různorodé dodatečné informace (náležitost bodu přímce, kódy kvality výměry, existence mezníku na bodě,...) a následně aplikují různé transformační funkce. A ve výsledku mohou dosahovat pro stejnou parcelu různých hodnot. Jeden z poměrně jednoduchých způsobů transformace přesnosti podrobných bodů parcel ISKN pro potřeby INSPIRE může spočívat v získání přesnosti reprezentující celou parcelu dle následujících pravidel: Parcely s kódem kvality 1 výměry 2 budou mít třídu přesnosti linie 1 za předpokladu, že jejich hranice je tvořena pouze liniemi. Třídu přesnosti linie 2 pak v případě, že jejich hranice obsahuje kruhový oblouk nebo kružnici. Ostatní parcely budou mít přesnost 3 (pouze liniové) popřípadě 4 (kruhové oblouky). Mezi výhody tohoto algoritmu patří zejména jeho jednoduchost a relativně snadná ověřitelnost. Relativní snadností máme na mysli skutečnost, do jaké míry uvažujeme data PUB-DB za důvěryhodná. Tedy zda ověření požadujeme čistě z dat ISKN nebo důvěřujeme PUB-DB alespoň v otázce existence oblouku na hranici parcely. Mezi nevýhody patří skutečnost, že tento způsob neřeší nejlépe přesnost jednotlivých linií. Pokud bychom je chtěli v rámci INSPIRE poskytovat a využili bychom podobná pravidla pro přesnosti linií, mnohdy bychom deklarovali nižší přesnost než skutečně hranice má. Je potřeba též uvážit relativní jednoduchost celého algoritmu. Při výpočtu geometrie parcely 1 Kód kvality výměry je číselný kód, který v SPI (Soubor Popisných Informací) označuje způsob určení výměry parcely. Kód 2 reprezentuje výměru parcely určenou ze souřadnic S-JTSK. Kód 1 reprezentuje výměru parcely určenou jinným číselým systémem a kód 0 reprezentuje výměru parcely určenou graficky. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 111

124 Kapitola 9. Systém obarvování hranic parcel by použití složitějšího algoritmu, který by reprezentoval skutečnost lépe, znamenalo jen velmi drobný rozdíl v rychlosti výpočtu. Tedy za předpokladu, že algoritmus využije daný způsob výpočtu geometrie a topologie a pouze se na něj napojí. Jak již bylo řečeno, existuje bezpočet způsobů, jakým transformaci přesnosti provést. Některé způsoby se nám mohou zdát lepší, jiné horší. V následujícím textu je popsán mnohem složitější způsob, kterým je pro PUB-DB v současnosti získána přesnost jednotlivých částí hranic parcely. Výpočet vychází z jednotlivých přesností bodů, které jsou doplněny dalšími pravidly vedení ČÚZK. Nejdůležitějším doplňujícím pravidlem je počet konečných skupin přesností pro linie. Dalšími doplňkovými pravidly jsou pravidla na zlepšování přesnosti bodu. Tato pravidla představují porušení čistě matematického výpočtu na základě znalosti chyb nebo chcete-li vlastností dat katastru nemovitostí. Tato práce si neklade za cíl hodnocení těchto pravidel, protože autorovi této práce přinejmenším chybí mnohaletá zkušenost, kterou naopak mají jednotliví zaměstnanci katastrálních úřadů, kteří tu a tam jsou nejhlasitějšími odpůrci některých doplňkových manažerských pravidel. Na druhou stranu je potřeba zmínit, že tak jako se mění politická rozhodnutí, mění se i názor vedení ČÚZK na definici způsobu výpočtu přesností linií v čase, kdy jsou přidávána a ubírána pravidla a poněkud absurdně se mění i počet skupin přesností. Což je z pohledu programátora velmi nepříjemné, protože je následně nutné nejenom tuto novou definici převést do programového kódu, kdy drobná změna v definici může znamenat naprosto odlišný zvolený způsob implementace, ale je též nutné následně znovu přepočítat všechny hranice v PUB-DB. Před tím, než se pustíme do samotné definice přesnosti, je dobré zdůraznit, že v současné době PUB-DB nerozlišuje přesnost hranice přirozeně liniové nebo hranice původně kruhové, která byla převedena na lomenou čáru. Toto odlišení v přesnosti se provádí až při vytváření INSPIRE GML souborů. Služba generování GML souborů je též jediným místem, kde existuje konkrétní číselné vyjádření přesnosti. Jinak jsou v celé struktuře PUB-DB používány pouze třídy přesností bodů a linií. 9.1 Definice přesnosti hranic v PUB-DB Přesnost bodu hranice Pro potřeby PUB-DB zavádíme zjednodušené přesnosti podrobných bodů hranic parcel. Tyto třídy přesnosti představují mezikrok při výpočtu přesnosti hranic parcel. A jako takové se nikterak v databázi neukládají. Třídy přesnosti jsou: Přesnost 1 v PUB-DB reprezentuje body ISKN s kódem charakteristiky kvality bodu 1, 2 a 3 (body určené s max. střední souřadnicovou chybou 0.14 m). Přesnost 2 v PUB-DB reprezentuje body ISKN s kódem charakteristiky kvality bodu 4, 5, 6, 7 a 8 (bod určený se střední souřadnicovou chybou 0.26 m, bod určený se střední souřadnicovou chybou 0.50 m, bod digitalizovaný z mapy měřítka 1:1000 se střední souřadnicovou chybou 0.21 m, bod digitalizovaný z mapy měřítka 1:2000 se střední souřadnicovou chybou 0.42 m a bod digitalizovaný z mapy měřítka 1:2880 a jiné (kromě 1000 a 2000) Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 112

125 Kapitola 9. Systém obarvování hranic parcel Zlepšení přesnosti bodu Zlepšením přesnosti bodu DB-PUB rozumíme změnu přesnosti bodu v DB-PUB z hodnoty 2 na hodnotu 1 pouze v rámci specifické hranice nebo skupiny hranic. Oprava přesnosti bodu na přímce: Přesnost bodu X (na obrázku 9.1 je X reprezentován bodem D) na hranici parcel se v PUB-DB zlepší v případě, že bod X leží na libovolné téměř rovné polylinii tvořené body hranic parcel, pokud bod nalevo a bod napravo od X má přesnost 1. Bodu X je pak též přiřazena přesnost 1. Numerické řešení bere v úvahu přesnost <2cm pro posouzení rovnosti polylinie při třech bodech. Tedy výška trojúhelníku, který je tvořen bodem X a bodem vpravo/vlevo od něho, spuštěná z bodu X je menší než 2 cm. Obrázek 9.1: Změna přesnosti na přímce. Na bodě D(2) dojde na spojnici E-F ke změně přesnosti bodu na hodnotu 1, ve směru linie D-C však zůstává přesnost bodu na hodnotě 2. Oprava přesnosti bodu z kvality výměry parcely Přesnost bodu (obrázek 9.2) na hranici se zlepší, pokud je tato hranice součástí parcely s kvalitou výměry 2 a bod v PUB-DB vznikl z bodu ISKN o třídě přesnosti Pravidla tvorby hranic parcel v publikační databázi 1. Hranice parcel je posloupnost bodů mezi dvěma parcelami. (a) V průběhu jedné hranice parcel v publikační databázi nemůže docházet ke změně ani jedné z parcel. Každé hranici parcely tedy náleží jednoznačný identifikátor pro parcelu vpravo a vlevo označen jako PAR_ID_1 a PAR_ID_2. Čistě z důvodu optimalizace je pro potřeby PUB-DB zaručeno, že PAR_ID_1 je větší než PAR_ID_2 nebo PAR_ID_2 je prázdné. (b) V průběhu jedné hranice parcel nemůže dojít ke změně reprezentace interpolace (lineární/kruhová) bodů hranice parcely. (c) Každá hranice parcel je reprezentována svou přesností, která vychází z přesností (přesnost bodů PUB-DB) bodů této hranice. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 113

126 Kapitola 9. Systém obarvování hranic parcel Obrázek 9.2: Změna přesnosti způsobená kódem kvality výměry. (d) V PUB-DB může existovat více hranic parcel se stejným složeným klíčem, (klíč je tvořen ze složek PAR_ID_1, PAR_ID_2, přesnost hranice v PUB-DB a reprezentace interpolace bodů) ale tyto hranice parcel se nesmějí dotýkat. (e) Výpočet průběhu hranice je závislý na pořadí parcel vstupujících do algoritmu. Proto je nutné parcely s kódem výměry 2 počítat přednostně. 2. Přesnost hranice parcel vychází z přesnosti jejích bodů (přesnost bodů v PUB-DB) a pro potřeby PUB-DB definujeme následující přesnosti hranic: (a) Přesnost 1 hranice parcel, je dána spojením bodů s přesností 1 v PUB-DB Příklad: Pouze body o přesnosti 1. (b) Přesnost 2 hranice parcel, je dána spojením bodů s přesností 1 a 2 v PUB-DB za předpokladu, že dva body o přesnosti 1 nejsou přímo spojeny. Příklady: Pouze body o přesnosti Body o přesnosti 2 uvnitř linie a na libovolném konci může být bod o přesnosti Body o přesnosti 1,2, ale dva body o přesnosti 1 nesmějí být vedle sebe. 3. Obarvování hranic parcel v PUB-DB vychází z jejich přesnosti: Hranice přesnosti 1 má barvu zelenou. Hranice přesnosti 2 má barvu černou. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 114

127 Kapitola 9. Systém obarvování hranic parcel Implementace Změna přesnosti bodu daná kódem kvality výměry Z pohledu implementace tato část definice zavádí do výpočtu pořadí výpočtu jednotlivých parcel, kdy je nutné dodržet postup. Nejprve se v rámci jednotlivých katastrálních pracovišť spočtou všechny parcely s kódem kvality výměry 2 a následně pak všechny zbylé. Tento postup, tedy jmenovitě řazení parcel, tak představuje výraznou zátěž zejména při procesech migrace a opravy části území Změna přesnosti bodu na přímce Tato část definice patří k nejvíce měněným částem výpočtu. Původní definice počítala se změnou přesnosti bodu, pokud leží na přímce. Tedy přesnost bodu se měnila pro všechny jeho linie. Výhodou tohoto původního způsobu byla skutečnost, že danou změnu lze provést na různých částech programového kódu, protože jedinou vstupní hodnotou je identifikátor bodu (BP_ID). Tedy bylo možné použít různě výkonově profilované funkce pro výpočet změn (cca 5tis. parcel) a migraci celého katastrálního pracoviště (cca tis. parcel). Nově se přesnost bodu mění jen ve směru vylepšující přímky, na které tento bod leží. Pro tyto účely byla zavedena v PUB-DB nová tabulka (PUB_SPOJENI_PRESNOST, příklad 9.1), protože vzhledem ke složitosti výpočtu je vhodné všechny spočtené změny přesnosti agregovat. Dále je výpočet změny přesnosti prováděn pouze pro tři po sobě následující body. Protože exaktní způsob, který by pracoval s liniemi o větším počtu bodů, je velmi problematické úspěšně implementovat pro výpočet ZMĚN. Úspěšnou implementací zde rozumíme zejména dobu trvání výsledného výpočtu. Výpočet změny přesnosti si je nejlépe možné představit jako hledání neorientované cesty mezi každými dvěma body (každý z bodů má přesnost v PUB-DB 1) katastrálního pracoviště. Kdy tato neorientovaná cesta musí být zároveň přímkou. V případě výpočtů ZMĚN jde vlastně o výpočet, i když značně optimalizovaný, pro každý příchozí bod/spojení přicházející replikací z centrální ISKN. Čistě neexaktní způsoby, zejména ty pracující s tzv. levými a pravými přírůstky linií, narážejí na problém stanovení maximální odchylky výsledné linie spojené s problémem různých délek hranic parcel. Jednotlivá řešení mohou vést až k topologickým kružnicím nebo netriviálním větvením. Řešením topologických kružnic a větvení pak výsledný algoritmus pro část parcel ztrácí potřebný výkon. Příklad 9.1: Tabulka PUB_SPOJENI_PRESNOST: desc publ. pub_ spojeni_ presnost Name Null Type HP_ID NUMBER (30) PORADI NUMBER ( 38) PUVODNI_ PRESNOST NUMBER (1) NOVA_ PRESNOST NUMBER (1) KATUZE_ KOD NUMBER (6) DATUM_ VZNIKU DATE BP_ID NUMBER (30) Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 115

128 Kapitola 9. Systém obarvování hranic parcel Ověření Při sestavování definice přesnosti hranic v PUB-DB nebyl brán zřetel na snadnou ověřitelnost stavu PUB-DB. Přesto však je možné některé základní věci zkontrolovat. Kontroluje se nejenom formální správnost algoritmu provádějící výpočet výsledné přesnosti, ale též se testuje fungování služby výpočtu ZMĚN, protože je běžné, že celá katastrální území obsahují špatně kódy kvality u svých parcel. Tyto chyby jsou pak následně opraveny v rámci ZMĚN. Jelikož se při konverzi mezi ISKN a PUB-DB nezachovávají identifikátory samostatných hranic, je v systému kontrol (Obrázek 9.3) nutné pracovat s náhradním identifikátorem složeným z obou PAR_ID (větší PAR_ID je uvedeno jako první). Dále je nutné si uvědomit, že hranice parcely nemusí nutně v celém svém průběhu zachovávat svou přesnost. Tedy pro jeden identifikátor (složený z obou PAR_ID) může v PUB-DB existovat klidně více hranic parcel. Proto je kontroly vhodné rozdělit na kontroly dvojího typu. Prvním typem je kontrola výlučnosti, kdy je zaručeno, že hranice mezi dvěma parcelami bude mít ve výsledku jedinou třídu přesnosti linie. Zde můžeme kontrolovat, že daná katastrální hranice nebude mít v průběhu styků obou parcel jinou přesnost. Druhým typem je kontrola existence, kdy víme, že na dané hranici musí být úsek o dané přesnosti. Obrázek 9.3: Kontroly přesností linií v PUB-DB Při ověřování naplnění PUB-DB se nejprve soustředíme na hranice parcel s kódem kvality výměry 2 a na hranice s přesností 1. Tyto hranice parcel představují přes 60% všech hranic parcel PUB-DB a přes 90% hranic s přesností 1. Pro čtenářovu představu uvádím statistiky parcel (Příklad 9.2) a hranic (Příklad 9.3) v PUB-DB. Příklad 9.2: Počty parcel v PUB-DB: Počet parcel ISKN s geometrií : Počet parcel s kódy výměry 2: Počet parcel s kódy výměry 1: Počet parcel s kódy výměry 0: Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 116

129 Kapitola 9. Systém obarvování hranic parcel Příklad 9.3: Počty hranic parcel v PUB-DB: Počet hranic parcel PUB - DB: Počet hranic parcel PUB - DB s přesností 1: Počet hranic parcel náležící parcele s kódem 2: Kontrola výlučné přesnosti (Chybějící hranice parcel s přesností 1) V této kontrole hledáme hranice parcel (ani jedna z parcel této hranice nemá KKV=2), na kterých je v PUB-DB vytvořen úsek o přesnosti linie 2, přestože tato hranice parcel má v ISKN pouze body s přesností 1, 2, 3. V této kontrole si nejprve vybereme příslušné hranice z ISKN (Příklad 9.4) 2 a následně vyhledáme v PUB-DB takové hranice, na nichž je úsek o přesnosti 2 (Příklad 9.5). Obdobně pak tento dotaz můžeme upravit i pro hranice parcel, které mají minimálně jednu parcelu s KKV=2. Příklad 9.4: Uspořádaná dvojice PAR_ID_1 a PAR_ID_2 hranic parcel, jejichž obraz lze nalézt v PUB-DB: create table test_ linie_ iskn as( select CASE WHEN par_ id_ 2 is null or par_ id_ 2 > par_ id_ 1 THEN par_ id_ 1 ELSE par_id_2 END par_id_1, CASE WHEN par_ id_ 2 is null or par_ id_ 2 > par_ id_ 1 THEN par_ id_ 2 ELSE par_ id_ 1 END par_ id_ 2 from iskn. ak_ hranice_ parcel where id in ( select id from ( select hp.id id,max ( so1. KODCHB_KOD ) maxp from iskn. ak_ hranice_ parcel hp join ISKN. ak_spojeni_b_poloh sp1 on sp1. hp_id =hp.id join ISKN. ak_souradnice_pb so1 on so1. bp_id = sp1. bp_id group by hp. id ) where maxp <4 ) and id in ( select id from pub_ hranice_ parcel where ( par_ id_ 1 in ( select id from iskn. ak_ parcely p where ZPURVY_ KOD < >2) or par_ id_ 2 in ( select id from iskn. ak_ parcely p where ZPURVY_ KOD < >2) ) ) Příklad 9.5: Hranice parcel v PUB-DB, které by měly mít též přesnost 1. 2 Tento dotaz není nijak optimalizovaný a slouží pouze k vysvětlení Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 117

130 Kapitola 9. Systém obarvování hranic parcel select id from pub_ hranice_ parcel where ( par_id_1, par_id_2 ) in ( select par_id_1, par_id_2 from test_ linie_ iskn ) and presnost < > Kontrola existence přesnosti (Nezlepšené hranice parcel s přesností 1) V této kontrole hledáme hranice parcel, na kterých nebyl v PUB-DB vytvořen úsek s přesností linie 1, ale na této hranici jsou v ISKN dva body o přesnosti 1, 2, 3 pro parcely s kódem kvality výměry jiným než 2 za sebou. Obdobně lze toto pravidlo vytvořit pro parcely s kódem kvality výměry 2. Nejprve si vybereme příslušné hranice z ISKN (Příklad 9.6) a následně vyhledáme v PUB-DB takové hranice, na nichž není úsek o přesnosti 1 (Příklad 9.7). Obdobným mechanizmem lze pracovat i s hranicemi, na nichž došlo ke změně přesnosti vlivem změny přesnosti na přímce. Pokud důvěřujeme mechanismu vyhledávání těchto bodů v ISKN, můžeme použít dotaz z příkladu 9.8. Příklad 9.6: Uspořádaná dvojice PAR_ID_1 a PAR_ID_2 hranic parcel, jejichž obraz lze nalézt v PUB-DB: create table test_ linie_ iskn as( select CASE WHEN par_ id_ 2 is null or par_ id_ 2 > par_ id_ 1 THEN par_ id_ 1 ELSE par_id_2 END par_id_1, CASE WHEN par_ id_ 2 is null or par_ id_ 2 > par_ id_ 1 THEN par_ id_ 2 ELSE par_ id_ 1 END par_ id_ 2 from iskn. ak_ hranice_ parcel where id in ( select distinct hp. id from iskn. ak_ hranice_ parcel hp join ISKN. ak_spojeni_b_poloh sp1 on sp1. hp_id =hp.id join ISKN. ak_ spojeni_ b_ poloh sp2 on ( sp2. hp_id =hp.id and sp1. PORADOVE_CISLO_BODU +1= sp2. PORADOVE_ CISLO_ BODU ) join ISKN. ak_souradnice_pb so1 on so1. bp_id = sp1. bp_id join ISKN. ak_souradnice_pb so2 on so2. bp_id = sp2. bp_id where so1. KODCHB_ KOD <4 and so2. KODCHB_ KOD <4 and hp. id in ( select id from pub_ hranice_ parcel where ( par_ id_ 1 in ( select id from iskn. ak_ parcely p where ZPURVY_ KOD < >2) or par_ id_ 2 in ( select id from iskn. ak_ parcely p where ZPURVY_ KOD < >2) ) ) ) Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 118

131 Kapitola 9. Systém obarvování hranic parcel Příklad 9.7: Hranice parcel v PUB-DB, které by měly mít přesnost 1, ale nemají: select id from pub_ hranice_ parcel where ( par_id_1, par_id_2 ) in ( select par_id_1, par_id_2 from test_ linie_ iskn where ( par_id_1, par_id_2 ) not in ( select par_id_1, par_id_2 from pub_ hranice_ parcel where presnost =1 ) ) Příklad 9.8: Hranice parcel v PUB-DB, které by měly mít též přesnost 1. select CASE WHEN par_ id_ 2 is null or par_ id_ 2 > par_ id_ 1 THEN par_ id_ 1 ELSE par_ id_ 2 END, CASE WHEN par_ id_ 2 is null or par_ id_ 2 > par_ id_ 1 THEN par_ id_ 2 ELSE par_ id_ 1 END from iskn. ak_ hranice_ parcel where id in ( select hp_ id from pub_ spojeni_ presnost where nova_ presnost <4) Další kontroly Systém kontrol není a ani by neměl být omezený schématem na obrázku 9.3. V samotných kontrolách lze pokračovat dle zvolených potřeb, kupříkladu kontrolou hranic na kterých jsou dva úseky s přesností linií 1. Nebo lze celý mechanismus kontrol obrátit a vycházet z hranic s přesností 2, které nebyly zlepšené. Většinu kontrol však není možné provádět v běžném provozu, protože jednotlivé kontroly mnohdy vyžadují řádově hodiny na zpracování v podmínkách běžného provozu PUB-DB. Kontroly tedy spíše slouží k hledání chyb po migraci nebo na speciální vyžádání. Navíc kontroly nejsou v současné době 100% účinné, protože implementace dalších kontrol by si vyžádala ještě větší nároky na provoz těchto kontrol. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 119

132 Kapitola 10. Migrace schématu ISKN do struktury Publikační databáze Kapitola 10 Migrace schématu ISKN do struktury Publikační databáze Migrace je proces, při kterém dojde ke konverzi všech dat ze schématu ISKN (replika dat centrální ISKN) do struktur publikační databáze (schéma PUBL). Vzhledem k tomu, že čas potřebný pro migraci se počítá v řádech dnů, je vhodné na cílovém databázovém stroji vypnout replikační proces (tzv. synchronizaci s centrální ISKN) a veškeré nedůležité požadavky (kupříkladu Nahlížení do KN) přesměrovat na jiný zdroj tak, aby proces migrace nebyl ničím zdržován. Ke spuštění procesu migrace mohou vést různé důvody. Asi nejznámějším důvodem je provedení migrace na nové databázi. Jedná se tedy o prvotní naplnění schématu PUBL. Dalším případem je nové (opakované) naplnění schématu PUBL, které je způsobeno vnějšími vlivy. Za vnější vliv můžeme považovat cokoliv, co zapříčiní selhání synchronizace centrální ISKN a schématu ISKN v její replice, včetně naplňování logovacích tabulek ISKN.TR_*. Důvodů vnějšího selhání je několik. Asi nejdiskutovanější je úmyslné přerušení logování do tabulek ISKN.TR_* při enormním množství replikovaných dat. K takovému enormnímu množství dochází jednou za několik let (poslední byla v roce 2008), kdy jsou provedeny mohutné opravy dat na jednotlivých lokálních (107 lokálních) databázích. Při takových mohutných opravách pak představuje problém samostatný přenos měněných dat z lokálních databází do centrální ISKN, který trvá několik následujících dní (3-8 dní). Proto je naprosto nemyslitelné předpokládat, že by si samotná PUB-DB, která neprovádí pouze kopírování dat, ale provádí nad změněnými daty i výpočty, byla schopna poradit s podobnými replikacemi. Navíc i při menším objemu replikace (cca data za jeden měsíc) administrátoři minimálně v minulosti rušili logování do tabulek ISKN.TR_*, přestože by PUB-DB takový nápor dat zvládla. Posledním důvodem k nové migraci je odhalení závažných a jinak neopravitelných chyb v datech PUB-DB nebo závažná změna některého z algoritmů výpočtu ZMĚN/migrace. Příkladem takové změny v algoritmu může být změna výpočtu přesností linií v PUB-DB. Najít příklad neopravitelné chyby, která by vedla k nové migraci dat, je poměrně složité, protože PUB-DB umožňuje pracovat s mechanismem oprav a tedy většina chyb je opravitelná tímto mechanismem. Na druhou stranu se vždy vyplatí určitá skromnost, protože v budoucnu může nastat případ, kdy bude objevena tak závažná chyba v PUB-DB, že bude výhodnější provést migraci dat. Samotný proces migrace si je nejlépe možné představit jako sadu procedur (Obrázek Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 120

133 Kapitola 10. Migrace schématu ISKN do struktury Publikační databáze 10.1), přičemž běh některých z nich je na sobě nezávislý a jiné mají definované pořadí spuštění. My si tyto elementární procesy popíšeme. Čtenáři se možná bude proces migrace zdát zdlouhavý a raději by upřednostnil popsání migračního procesu jako volání jediné funkce. To však není naším úkolem, protože by neměl být problém napsat obalové funkce, které zajistí paralelní zpracování a zpětnou synchronizaci. Obrázek 10.1: Schéma migrace Předpoklady migrace Předpoklady migrace: Jsou zastaveny replikace z ISKN a systém Nahlížení do KN je přesměrován na jiný zdroj dat, tedy systém není zbytečně zatěžován jinými úlohami Kroky migrace Postup migrace: Předpokládejme výpočet na šesti databázových vláknech, výpočet každého vlákna budeme reprezentovat samostatnou session v podobě SQL-Plus terminálu T1- T6. Přičemž v T1-T5 budeme provádět výpočet parcel KN a ve zbylém T6 provedeme výpočet zbylých prvků Krok 1. Nejprve provedeme vyčištění tabulky MIGRACE_LOG (Příklad 10.1), tato tabulka je obdobou tabulky PUB_LOG a budou v ní uchovávány všechny chyby ISKN, které byly Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 121

134 Kapitola 10. Migrace schématu ISKN do struktury Publikační databáze objeveny při migraci. Po skončení vymazaní tabulky MIGRACE_LOG tohoto kroku mohu pokračovat krokem 2, který se skládá z kroků 2a a 2b. Příklad 10.1: TRUNCATE TABLE MIGRACE_ LOG ; Migrace krok 1 - vymazaní logu migrace Krok 2a. V libovolném terminálu T1-T5 provedeme rozdělení výpočtu PARCEL_KN na požadovaný počet jader. Tento výpočet (Příklad 10.2) trvá přibližně 12 minut. Můžeme dokončit krok 2 tím, že budeme pokračovat krokem 2b, nebo pokud již máme krok 2b zadán, můžeme postoupit na krok 3. Příklad 10.2: Migrace krok 2a - rozdělení parcel KN na jednotlivá výpočetní jádra exec MIGRUJ_PRIP_JADRA_PARCELY_KN (5) ; --5 VYPOCETNICH JADER Krok 2b. V terminálu T6 provedeme výpočet parcel zjednodušené evidence, dalších prvků mapy, prvků orientační mapy, budov a katastrálních území (Příklad 10.3). Výpočet tohoto kroku trvá cca 4-6 dní, po jeho zadání pokračujeme buď krokem 2a (pokud ještě nebyl zadán) nebo krokem 3. Příklad 10.3: BEGIN MIGRUJ_ BUDOVY ; MIGRUJ_ DPM ; MIGRUJ_ POM ; MIGRUJ_ PARCELY_ ZE ; MIGRUJ_KU ; END ; Migrace krok 2b - výpočet na posledním jádře Krok 3. V terminálu T1-T5, po dokončení výpočtu kroku 2a provedeme výpočet změny přesnosti na bodě parcel KN a výpočet geometrie parcel KN daných bodem i množinou hranic. Proměnná CISLO_JADRA v příkladu 10.4 značí hodnoty <1,5> odpovídající číslu jádra výpočtu (terminálu, ve kterém výpočet spouštíme). Tento krok trvá 7-9 dní. Příklad 10.4: Migrace krok 3 - výpočet parcel KN BEGIN MIGRUJ_JADRO_PRESNOST_BODU (% CISLO_JADRA ) MIGRUJ_JADRO_PARCELY_KN (% CISLO_JADRA ); MIGRUJ_JADRO_PARCELY_KN_DB (% CISLO_JADRA ); END ; Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 122

135 Kapitola 10. Migrace schématu ISKN do struktury Publikační databáze Krok 4. Krok 4 představuje kopírování dat ze schématu PUB_MIGRACE do schématu PUBL. Krok lze bezpečně provést po skončení kroků 2b a 3. Před samotným kopírováním dat je vhodné zkontrolovat výsledek procesu migrace, zejména pak počet nespočtených parcel a počet tzv. volných konců (Příklad 10.5). Po zkontrolování je nutné se přehlásit do schématu PUBL a následné kopírování prvků ze schématu PUBL_MIGRACE (Příklad 10.6) provádět z něho. Kopírování je vhodné provádět ve více vláknech. My si ho opět ukážeme pro terminál T1-T6. Příklad 10.5: Migrace krok 4 - kontrola dat před kopírováním SELECT PRVEK FROM MIGRACE_ LOG WHERE KOD = NESPOCTENE PARCELY SELECT PRVEK FROM MIGRACE_ LOG WHERE KOD = VOLNE KONCE Příklad 10.6: Migrace krok 4 - kopírování výtvořených dat EXEC KOPIRUJ_HRANICE_PARCEL ; -- SCHEMA PUBL, TERMINAL T1, DOBA TRVANI 4 HODINY EXEC KOPIRUJ_ PARCELY ; -- SCHEMA PUBL, TERMINAL T2, DOBA TRVANI 6-7 HODIN EXEC KOPIRUJ_ DPM ; -- SCHEMA PUBL, TERMINAL T3, DOBA TRVANI 2 HODIN EXEC KOPIRUJ_ OMP ; -- SCHEMA PUBL, TERMINAL T4, DOBA TRVANI 2 HODIN EXEC KOPIRUJ_ BUDOVY ; -- SCHEMA PUBL, TERMINAL T5, DOBA TRVANI 3 HODIN BEGIN -- SCHEMA PUBL, TERMINAL T6, DOBA TRVANI 30 MINUT KOPIRUJ_ KU ; KOPIRUJ_ PRESNOST ; KOPIRUJ_ LOG ; END ; Krok 5. Výpočet první ZMĚNY. Provedeme synchronizaci repliky ISKN, replikační mechanismus by měl provést naplnění tabulek ISKN.TR_*. Poté zapneme automatický výpočet ZMĚN (Příklad 10.7). Příklad 10.7: Migrace krok 5 - spuštění výpočtu ZMĚN -- VE SCHEMATU PUBL_ ZMENY exec dbms_scheduler. enable ( ZMENY_JOB_ISKN_PRIRUSTKY_10M ); Poté, co se provede automatický výpočet první ZMĚNY, je vhodné ověřit celý stav publikační databáze v tabulce PUB_PREHLED_STAVY. (Příklad 10.8). Příklad 10.8: Migrace krok 5 - závěrečná kontrola SELECT * FROM PUBL. PUB_ PREHLED_ STAVY Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 123

136 Kapitola 11. Výpočet ZMĚN nad PUB-DB Kapitola 11 Výpočet ZMĚN nad PUB-DB Výpočtem změn budeme rozumět proces konverze přírůstků nebo jiných změn v databázi ISKN do struktur PUB-DB. Na obrázku 11.1 je zobrazeno schéma takové konverze, kdy změny ve zdrojových datech centrální ISKN jsou každých patnáct minut kopírovány do databáze PUB-DB. Tyto změny se však v samotné databázi promítnou jednou za dvě hodiny. Součástí těchto změn je i zápis do logovacích tabulek ISKN.TR, které obsahují identifikátory změněných záznamů v příslušných tabulkách, identifikátor operace nad záznamem (INSERT, UPDATE, DELETE), datum změny a popřípadě některé doplňující informace (například tabulka ISKN.TR_AK_HRANICE_PARCEL obsahuje záznamy o původních a nových odkazech na parcely této hranice). Důležité je zmínit, že tok číselníků ze schématu SC (schéma v centrální databázi) se těmito pravidly neřídí, číselníky jsou tedy do ISKN-R přenášeny vždy, když se změní. Patnáctiminutový interval replikací z centrální ISKN do PUB-DB je dán samotným replikačním mechanizmem přenosu dat mezi jednotlivými lokálními ISKN na katastrálních úřadech (celkem 107 DB) a jednou centrální databází. V tomto procesu může dojít k výpadku nebo jiným nepříjemnostem, pak jsou data lokální ISKN replikována do centrální databáze se zpožděním. Toto zpoždění pak ve strukturách publikační databáze vede k některým obtížím, protože může nastat a nastává situace, kdy jsou po dvou hodinách do struktur ISKN-R přenesena data z PUB-DB cache, ve kterých ale v poslední replikaci chybí data jednoho katastrálního pracoviště. Datum změn těchto dat v tabulkách ISKN.TR odpovídá času T1. V momentě, kdy do PUB-DB cache dorazí i replikace posledního katastrálního pracoviště, tato data nečekají na své přenesení na další interval 2 hodiny, ale jsou okamžitě přenesena do ISKN-R a jejích logovacích tabulek (ISKN.TR), přičemž datum uvedený v těchto logovacích tabulkách je nezávislý na skutečném času příchodu replikovaných dat do PUB-DB a je velmi blízký času T1. Tedy čas a datum uvedený v tabulkách ISKN.TR není spolehlivým indikátorem skutečného času vzniku těchto dat v PUB-DB. Této vlastnosti budeme muset následně přizpůsobit práci s těmito tabulkami, kdy využijeme serializovaných transakcí. Samotná konverze dat ze struktur ISKN do schématu PUBL je provedena pomocí dvou samostatných a nezávislých procedur, které se spouštějí každých deset minut. První procedurou je zmeny_job_rastery, která v případě přeskenování některého z rastrů analogové katastrální mapy vypne zobrazení prvků orientační mapy, které jsou tímto rastrem zasaženy a jsou starší než tento rastr. Tedy dojde k vypnutí geometrických plánů, které jsou již součástí nového rastru. Druhou procedurou je zmeny_spocti_iskn2pub, která má za Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 124

137 Kapitola 11. Výpočet ZMĚN nad PUB-DB Obrázek 11.1: Konverze v PUB-DB úkol provést update zbytku geometrie schématu PUBL (tento proces nazýváme výpočtem ZMĚN). Obě funkce na závěr provedou update zasažených katastrálních pracovišť, čímž spustí mechanizmus přenosu geometrie do datového skladu WKB geometrií, ze kterého jsou data poskytována dále pro WMS a aplikaci Nahlížení do KN Procedura zmeny_job_rastery Tato procedura představuje vyčlenění části algoritmů z procedury zmeny_spocti_iskn- 2pub. K tomuto vyčlenění došlo vzhledem k vysokým nárokům na čas pro běh této procedury. K přeskenování části rastrů dochází vždy na začátku měsíce, tedy pokud by byla tato procedura součástí výpočtu běžných ZMĚN, došlo by vždy na začátku měsíce k půldennímu až dennímu výpadku v aktuálnosti katastrálních dat. Tato procedura řeší problém, kdy prvky orientační mapy (POM) nemají přiřazený rastr, kterému náleží jejich data. Tento problém však v současnosti nelze, pouze z dat ISKN, exaktně řešit, protože mnoho prvků (POM) leží na překrytu dvou a více rastrů a v současnosti nejsou součástí ISKN informace o jejich vzájemném vymaskování. Tedy v případě, že dojde k přeskenování libovolného rastru, musí být určeny POM, které tomuto rastru patří pomocí prostorového dotazu. Prvky (POM), které jsou tímto rastrem zasaženy a jsou starší než datum vzniku tohoto rastru (zde si musíme uvědomit, že tato procedura může běžet delší dobu, tedy v replice ISKN mohou být obsaženy nové POM, které jsou již vytvářeny nad novým rastrem) jsou pak označeny za neaktivní (set zobrazovat= n ) v tom případě, že neexistuje jiný rastr, který je starší než datum vytvoření těchto POM. Neaktivní prvky se pak nezobrazují v Nahlížení do KN ani WMS. Zde je nutné chápat, že tyto prvky ale dále existují jak v PUB-DB tak i v ISKN a dalšími procesy nad ISKN pak mohou být klidně i znova označeny za aktivní nebo naopak mohou být smazány. Tyto operace však neřeší tato procedura, ale procedura zajištující výpočet ZMĚN. Na obrázku 11.2 je zobrazen průběh výpočtu, kdy v prvním kroku dojde k znovunačtení tabulky PUB_RASTROVE_SOUBORY (Příklad 11.1), která je ve schématu PUBL pouze z tohoto důvodu. Výhodou této tabulky je sloupec geometrie, který obsahuje opsaný Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 125

138 Kapitola 11. Výpočet ZMĚN nad PUB-DB obdélník rastrového souboru a umožňuje tak prostorový dotaz hledání POM, které leží na dotčeném rastrovém souboru. Následně v druhém kroku dojde k vyhledání všech POM, které leží na rastrech, které byly přeskenovány. Tyto POM jsou zkopírovány do pomocné tabulky. V kroku tři a čtyři jsou pak v této pomocné tabulce označeny jako POM, které se nezobrazují, takové prvky, které leží na měněném rastru, ale zároveň neleží na libovolném mladším rastru. V dalších krocích pak dojde k samotnému update POM v tabulce PUBL.PUB_PRVKY_ORIENT_MAPY a přípravě na další výpočet. Příklad 11.1: Tabulka PUB_RASTROVE_SOUBORY CREATE TABLE PUBL. PUB_ RASTROVE_ SOUBORY AS ( ID NOT NULL NUMBER ; NAZEV_ SOUBORU NOT NULL VARCHAR2 ( 254) ; TYP_ RASTRU NOT NULL VARCHAR2 ( 20) ; PLATNOST_ OD NOT NULL DATE ; PRARES_ KOD NUMBER (3) ; DATUM_ AKTUALNOSTI DATE ; POCET_ ZMEN NUMBER ; GEOMETRIE SDO_ GEOMETRY (); GEOMETRIE_ TEXT SDO_ GEOMETRY () ) Obrázek 11.2: Update prvků orientační mapy Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 126

139 Kapitola 11. Výpočet ZMĚN nad PUB-DB 11.2 Procedura zmeny_spocti_iskn2pub Tato procedura slouží k výpočtu změn, ke kterým dojde v průběhu dvouhodinového intervalu v datech ISKN. Schéma výpočtu je zobrazeno na obrázku V prvním kroku jsou kopírovány záznamy z tabulek ISKN.TR_AK_* do pomocných tabulek ZMENY_TR_*. Důvody kopírování jsou dva. Prvním důvodem je skutečnost, že nad tabulkami ISKN.TR_* nemáme plnohodnotnou kontrolu nad vznikem záznamů a jejich konzistencí, proto je vhodné pracovat pouze s kopií těchto dat vytvořených v rámci transakce (SET TRANSACTION ISOLATION LEVEL SERIALIZABLE). Druhým důvodem je skutečnost, že proceduru výpočtu ZMĚN je pak možné jen drobně upravit a získat tak procedury provádějící opravy konzistence dat nad PUB-DB. V druhém kroku výpočtu ZMĚN dojde ke spočtení změn přesností bodů dle pravidel zmíněných v kapitole 9. Následně jsou v kroku tři spočteny změněné další prvky mapy, prvky orientační mapy, budovy, k.ú. a parcely. Samotný výpočet parcel se výrazně liší od všech ostatních typů prvků, protože zatímco k přepočtení celého libovolného prvku (mimo prvku parcela) stačí změna jeho libovolné části, u prvku parcela rozeznáváme různé skupiny změn a podle zařazení změn na dotčené parcele přepočítáváme parcelu celou nebo pouze její část. Důvodem rozdílného chování je pouze požadavek na výkon celého procesu. Tedy pokud se kupříkladu změní definiční bod budovy, dojde k přepočtení všech záznamů v kopii ISKN, patřící dané budově a budova je v PUB-DB nově vytvořená. Zatímco při změně definičního bodu parcely nedojde k přepočtení celé parcely, ale pouze jejích pomocných grafických prvků (definiční bod, šipky, značky). Obrázek 11.3: Schéma výpočtu ZMĚN Asi nejzajímavější částí výpočtu parcel je samotný počáteční výběr hranic parcel z PUB- DB, které do výpočtu budou vstupovat. Pro popis, jakým samotný výběr hranic ze schématu ISKN a schématu PUBL z PUB-DB funguje, použijeme obrázek Budeme použí- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 127

140 Kapitola 11. Výpočet ZMĚN nad PUB-DB vat červenou plnou čáru pro hranice parcel, které v rámci jedné replikace vznikají, červenou přerušovanou pro hranice, které se během replikace sice nemění, ale přesto tyto hranice budou do výpočtu vstupovat ze schématu ISKN a nikoliv PUBL. Oranžovou plnou linii používáme pro hranice parcel, které jsou v průběhu jedné replikace rušeny. Zelenou plnou čarou označíme všechny linie, které budou vstupovat do výpočtu ze schématu PUBL. Na obrázku 11.4/a dochází během replikace k zániku hranice A 1 a vzniku hranice A 2. Dále zde dochází ke změně PAR_ID na hranici A 3, proto tuto hranici můžeme považovat též za měněnou. Všechny tyto tři hranice jsou zmíněny v tabulce ISKN.TR_AK_HRA- NICE_PARCEL. Pro provedení výpočtu změny geometrie těchto parcel však potřebujeme do výpočtu ještě dodat hranici A 4 a množinu hranic označovaných pro zjednodušení jako A 5. Hranice A 4 do výpočtu vstupuje ze schématu ISKN, protože její PAR_ID jsou shodná ať již s A 1 nebo s A 2. Tedy z důvodu rozdílných identifikátorů hranic parcel ve schématech ISKN a PUBL do výpočtu ZMĚN vstupují ze schématu ISKN vždy všechny hranice, které mají stejná (obě) PAR_ID jako libovolná rušená, měněná nebo nově vznikající hranice. Skupina hranic označených jako A 5 představuje skupinu hranic ze schématu PUBL, které je nutné do výpočtu dodat, aby byl výpočet nové geometrie možný. Na obrázku 11.4/b je vyobrazen obdobný případ, navíc zde do výpočtu vstupuje hranice A 6, která představuje hranici s prázdným atributem PAR_ID_2. V případě, že dochází ke změně parcely, vstupují do výpočtu ZMĚN všechny její hranice s prázdným PAR_ID_2 ze schématu ISKN. Je tomu tak z několika důvodů. Na obrázku 11.4/c je vyobrazena velmi speciální změna v geometrii parcely, kdy dojde pouze ke zrušení hranice. Jedná se o sloučení parcely a vnitřní parcely. Zvláštností této změny je skutečnost, že k výpočtu jsou potřeba jen hranice ze schématu PUBL, ale ke spuštění výpočtu dochází na základě rušených (již neexistujících hranic). Pro informaci uvedu, že v průběhu cca 4 měsíců dochází k přibližně 10 takovým změnám. Ukázka skutečného výpočtu ZMĚN pro skupinu parcel v jedné replikaci je zobrazena na obrázku Při praktickém řešení však navíc musíme brát v úvahu, že ke změně hranic parcely dochází i vlivem změn spojení bodů polohopisu (modré linie na obrázku 11.6) nebo dokonce pouhou změnou jediného bodu polohopisu, který leží na dané hranici. Na konec na obrázku 11.7 uvedeme ukázku výpočtu změn na hranici katastrálního pracovistě. Po výpočtu parcel dochází ke krokům čtyři a pět, při kterých se označí ke smazání ze schématu PUBL parcely, které měly být změněny, ale u nichž výpočet nové geometrie selhal. Dále se zde provede dopočet chybějících hranic k.ú. do tabulky publ.pub_opravy_hranice_ku tak, aby tabulka odpovídala současnému stavu. Tato tabulka neobsahuje všechny hranice k.ú., ale pouze ty hranice, na kterých jsou obě PAR_ID vyplněna, přestože jedna z parcel v PUB-DB neexistuje. Tedy tato tabulka slouží k ošetření velmi speciální chyby v topologii ISKN, blíže se s chybou seznámíme v následující kapitole (konkrétně v podsekci ). Dalším (šestým) krokem je určení změněných publikačních jednotek (v našem případě k.ú.). Tedy pro všechny změněné budovy, parcely,... se určí jejich k.ú., pro službu aktualizace WKB geometrií do datového skladu vektorových dat, který slouží jako jeden ze zdrojů aplikace Nahlížení do KN. Též se určí její podmnožina v podobě změněných parcel a jejich hranic pro službu INSPIRE stahování celých datových sad. V sedmém kroku dojde ke kopírování a mazání dat ve schématu PUBL daty spočtenými v předchozích krocích. Při tomto kopírování dat dochází též ke kopírování vstupních dat z tabulek ZMENY.TR_* Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 128

141 Kapitola 11. Výpočet ZMĚN nad PUB-DB Obrázek 11.4: Hranice schématu ISKN a PUBL vstupující do výpočtu nové geometrie parcel (nebo přesněji ISKN.TR_*) do tabulek PUBL.PUB_LOG_TR_* tak, aby byly všechny změny nad schématem dobře zdokumentovány a aby při nalezení případně chyby bylo možné určit důvod, proč k chybě došlo. Osmým krokem je dopočet geometrie změněných k.ú. K tomuto výpočtu dochází poněkud nešťastně až po skončení kopírování vypočtených ZMĚN do schématu PUBL. Důvodem tohoto chování je složitost výběru dat zejména pro k.ú, kde je DKM/KMD pouze na části území. Předposledním krokem je update sloupce DA- TUM_POSLEDNI_AKTUALIZACE v tabulce PUBL.PUB_KATASTRALNI_UZEMI. Tímto krokem se zároveň automaticky spouští dříve zmíněná služba aktualizace WKB geometrií. Posledním krokem je výpočet statistik. Nejprve se určí statistiky pro změněná data, tedy počty změněných/smazaných budov, parcel a poté se spočtou statistiky stavu. Tedy porovnání dat ve schématu ISKN a schématu PUBL. Výpočty statistik jsou velmi časově náročné, protože jejich výpočet vyžaduje cca 15 minut. Výpočet ZMĚN v běžném provozu trvá cca 2-8 minut, v době (víkendy) mohutného zplatňování výjimečně 2-3 hodiny. Přesto je však velmi výhodné tyto statistiky po každém výpočtu ZMĚN pořizovat, protože nám mohou říci mnohé o dynamice (chování) dat v ISKN a také nám mohou pomoci při odhalení chyb ve výpočtu ZMĚN nebo selhání logování replikací Výpočet oprav Jak již bylo řečeno, procedura zmeny_spocti_iskn2pub může být velmi jednoduše modifikována tak, aby fungovala pro opravu nekonzistentního stavu v PUB-DB. Při modifikaci funkcionality máme na výběr dva způsoby. Prvním způsobem je využítí dat v tabulkách PUBL.PUB_LOG_TR_*, které obsahují vstupní data již proběhlých výpočtů ZMĚN. Tedy je možné napsat proceduru, která provede opravu dat ve schématu PUBL od stanoveného data. Toto je výhodné, pokud známe časovou značku, kdy data ve schématu PUBL začala být nekonzistentní oproti schématu ISKN. Tento časový údaj je nejlépe možné vyčíst z pořizovaných statistik. Druhý způsob modifikace funkce je možné využít v případě, že k nekonzistenci nedošlo vinou výpočtu ZMĚN v PUB-DB, ale kupříkladu vyp- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 129

142 Kapitola 11. Výpočet ZMĚN nad PUB-DB Obrázek 11.5: Ukázka změny geometrie parcel v rámci jednoho výpočtu ZMĚN Obrázek 11.6: Nepřímá změna hranice v ISKN způsobená změnou spojení bodů polohopisu nutím logování do tabulek ISKN.TR_*. K tomuto vypnutí bohužel může dojít ze strany administrátorů, kteří si tak ulehčí proces replikací dat, ale prakticky znehodnotí konzistenci dat PUB-DB. V tomto případě je nutné buď přepočítat celou PUB-DB nebo jen její část, danou nejlépe výčtem k.ú. nebo KP, pokud je tato množina známá. Když dojde k jednodennímu výpadku logování změn, je nutné přepočítat cca 150 k.ú., v praktickém řešení je však vhodné přepočítat celé KP, protože mapa jednoho KP tvoří ostrovní mapu a vzhledem k topologii ISKN, které je rozděleno na malé lokální DB podle KP je pravděpodobnost selhání dat na úrovni jednoho KP více pravděpodobná. Na druhou stranu je nutné zmínit, že od dubna 2010, kdy byla publikační databáze spuštěna do provozu, nikdy nenastala Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 130

143 Kapitola 11. Výpočet ZMĚN nad PUB-DB Obrázek 11.7: Výpočet ZMĚN na hranici katastrálního pracoviště chyba, kdy by bylo nutné takovou funkci použít Oprava dat na základě časového intervalu Oprava dat na základě časového intervalu spočívá v opakovaném přepočítání všech ZMĚN. Oprava dat tímto způsobem je možná, pokud dochází ke správnému logování dat do tabulek ISKN.TR_* resp. k jejich přenosu do tabulek PUBL.PUB_LOG_TR při výpočtu ZMĚN. Implementace spočívá v pouhém prohození zdrojů v PL/SQL proceduře zmeny_spocti_iskn2pub z tabulek ISKN._TR do tabulek PUBL.PUB_LOG_TR a samozřejmě v následném odstranění kopírování těchto záznamů zpět (jak bylo popsáno v kroku 7. výpočtu ZMĚN). Výhodné je zde využít i výpočtu statistik jako kontroly výpočtu oprav. Pro představu změn, které musí být do výpočtu začleněny, uvádím funkci pro získání dat pro výpočet ZMĚN (Příklad 11.2) a opravu na základě limitního času (Příklad 11.3). Pro zjednodušení pracují příklady jen s dalšími prvky dat. Příklad 11.2: Výběr dat pro výpočet ZMĚN dalších prvků mapy create or replace PROCEDURE ZMENY_ ISKN2PUB_ TR AS BEGIN EXECUTE IMMEDIATE truncate table zmeny_tr_ak_spojeni_b_poloh ; EXECUTE IMMEDIATE truncate table zmeny_tr_ak_souradnice_pb ; EXECUTE IMMEDIATE truncate table zmeny_tr_ak_dalsi_prvky_mapy ; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE ; insert into zmeny_tr_ak_spojeni_b_poloh ( select id,operace, datum from iskn. tr_ak_spojeni_b_poloh ); Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 131

144 Kapitola 11. Výpočet ZMĚN nad PUB-DB insert into zmeny_tr_ak_souradnice_pb ( select id,operace, datum from iskn. tr_ak_souradnice_pb ); insert into zmeny_tr_ak_dalsi_prvky_mapy ( select id,operace, datum from iskn. tr_ak_dalsi_prvky_mapy ); delete from iskn. tr_ak_spojeni_b_poloh ; delete from iskn. tr_ ak_ souradnice_ pb ; delete from ISKN. tr_ak_dalsi_prvky_mapy ; COMMIT ; END ZMENY_ ISKN2PUB_ TR ; Příklad 11.3: data Výběr dat opravy všech dalších prvků mapy, jenž se změnily od stanoveného create or replace PROCEDURE OPRAVA_ISKN2PUB_TR_DATE ( date mez ) AS BEGIN EXECUTE IMMEDIATE truncate table zmeny_tr_ak_spojeni_b_poloh ; EXECUTE IMMEDIATE truncate table zmeny_tr_ak_souradnice_pb ; EXECUTE IMMEDIATE truncate table zmeny_tr_ak_dalsi_prvky_mapy ; insert into zmeny_tr_ak_spojeni_b_poloh ( select id, operace, datum from publ. pub_log_tr_ak_spojeni_b_poloh where datum_zmeny >= mez ); insert into zmeny_tr_ak_souradnice_pb ( select id, operace, datum from publ. pub_log_tr_ak_souradnice_pb where datum_zmeny >= mez ); insert into zmeny_tr_ak_dalsi_prvky_mapy ( select id, operace, datum from publ. pub_log_tr_ak_dalsi_prvky_mapy where datum_zmeny >= mez ); END OPRAVA_ISKN2PUB_TR_DATE ; Oprava dat na základě výčtu k.ú. nebo KP Oprava dat na základě výčtu k.ú. nebo KP též představuje relativně jednoduchou úpravu procedury zmeny_spocti_iskn2pub (tedy za předpokladu, že udržíme rozumný počet opravovaných dat, tedy kupříkladu cca parcel). Úprava spočívá opět ve změně vstupních dat v tabulkách ZMENY.ZMENY_TR, v tomto případě na základě dotazu do schématu ISKN. Následuje opět ukázka procedury výběru prvků pro opravu pro prvky další mapy (Příklad 11.4). Příklad 11.4: Výběr dat pro opravu všech dalších prvků mapy v zadaném k.ú. create or replace PROCEDURE OPRAVA_ISKN2PUB_TR_KOD ( number kod ) AS BEGIN EXECUTE IMMEDIATE truncate table zmeny_tr_ak_spojeni_b_poloh ; EXECUTE IMMEDIATE truncate table zmeny_tr_ak_souradnice_pb ; Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 132

145 Kapitola 11. Výpočet ZMĚN nad PUB-DB EXECUTE IMMEDIATE truncate table zmeny_tr_ak_dalsi_prvky_mapy ; insert into zmeny_tr_ak_dalsi_prvky_mapy ( select id, operace, datum from iskn. ak_ dalsi_ prvky_ mapy where katuze_ kod = kod ); END OPRAVA_ISKN2PUB_TR_KOD ; 11.4 Statistiky Pro potřeby monitoringu publikační databáze (PUB-DB) se při každém výpočtu ZMĚN nebo OPRAVĚ pořizují statistiky změněných dat (statistiky ZMĚN) a aktuálního stavu (statistiky STAVU) PUB-DB. Z těchto statistik pak lze snadno odvodit aktuální potřeby PUB-DB. Statistiky též obsahují informace o délce trvání výpočtu ZMĚN. Z dlouhodobého pohledu lze tedy tento výkon sledovat a jeho programové zabezpečení upravovat aktuálním potřebám. Statistiky ZMĚN obsahují počty nových (měněných) a rušených prvků ve schématu PUBL. Tyto statistiky vypovídají o dynamice změn ve zdrojové ISKN. Dalším údajem, který lze z těchto statistik získat, je výkon (počet prvků konvertovaných ze struktury ISKN do struktury PUB-DB za jednotku času). Statistiky ZMĚN se vedou pro následující prvky: Katastrální území: Počet katastrálních území, ve kterých se změnila hranice parcely (ZMENENO_KU_HRANICE) nebo jakýkoliv prvek (ZMENENO_KU). Parcely: Počet přidaných nebo změněných parcel KN s geometrií hranic (PRIDAT_- PARCELY_KN_GEO), počet přidaných nebo změněných parcel KN s definičním bodem (PRIDAT_PARCELY_KN_DB), počet přidaných nebo změněných parcel ZE (PRIDAT_PARCELY_ZE), počet zrušených parcel (ODEBRAT_PARCELY). Hranice parcel: Počet přidaných hranic parcel (PRIDAT_HRANY_PARCEL), počet smazaných hranic parcel. (ODEBRAT_HRANY_PARCEL). Další prvky mapy (DPM): Počet přidaných DPM (PRIDAT_DPM), počet smazaných DPM (ODEBRAT_DPM). Prvky orientační mapy: Počet přidaných POM (PRIDAT_POM), počet smazaných POM (ODEBRAT_POM). Budovy: Počet přidaných budov (PRIDAT_BUDOVY), počet smazaných budov (ODEBRAT_BUDOVY). Statistiky STAVU pak představují nezávislé porovnání aktuálního naplnění schématu ISKN a schématu PUBL. Toto porovnání je velmi náročné na čas výpočtu (cca 15 minut) Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 133

146 Kapitola 11. Výpočet ZMĚN nad PUB-DB a nemá cenu ho provádět v jinou dobu než přímo po dokončení výpočtu ZMĚN nebo rozsáhlejších oprav v PUB-DB. Protože jinak mohou být tyto statistiky znehodnoceny daty, která jsou ve schématu ISKN, ale ještě pro ně neproběhl výpočet ZMĚN. Statistiky stavu se vedou pro následující prvky: Parcely KN: Počet parcel KN v ISKN (ISKN_PARCELY_KN). Počet parcel KN ve schématu PUBL (PUB_PARCEL_KN). U tohoto výpočtu se ani nepředpokládá soulad s počtem parcel v ISKN, protože ne všechny parcely KN z ISKN se konvertují na parcely v PUB-DB. Počet parcel ve schématu PUBL, které jsou zde navíc oproti schématu ISKN (PUB_NAVIC_PARCEL_KN). Parcelu KN bez geometrie hranic ve schématu PUBL je možné pokládat za parcelu navíc, pokud neexistuje v ISKN parcela se stejným ID nebo tato parcela nemá v ISKN definiční bod. Parcelu KN s geometrií hranic lze považovat za parcelu navíc pouze tehdy, pokud neexistuje parcela v ISKN se stejným ID a parcela ve schématu PUBL ztrácí během výpočtu ZMĚN všechny své hranice. Počet parcel KN v ISKN, které ve schématu PUBL chybí (PUB_CHYBI_PAR- CELY_KN). Parcela KN v ISKN je považovaná za parcelu, která ve schématu PUBL chybí, pokud tato parcela se stejným ID neexistuje ve schématu PUBL a tato parcela v ISKN má definiční bod a její popisek (sloupec TEXT) není nulový. Parcely ZE: Počet parcel ZE v ISKN (ISKN_PARCELY_ZE). Počet parcel ZE ve schématu PUBL (PUB_PARCELY_ZE). Předpokládá se, že ISKN_ZE není rovno PUB_ZE. Počet parcel ZE ve schématu PUBL, které jsou zde navíc oproti ISKN (PUB_NA- VIC_PARCELY_ZE). Parcela ZE ve schématu PUBL je pokládána za parcelu navíc, pokud neexistuje parcela ZE se stejným identifikátorem (ID) v ISKN nebo tato parcela nemá v ISKN definiční bod. Počet parcel ZE v ISKN, které ve schématu PUBL chybí (PUB_CHYBI_PAR- CELY_ZE). Parcela ZE v ISKN je považovaná za parcelu ZE, která ve schématu PUBL chybí, pokud tato parcela ZE se stejným ID neexistuje ve schématu PUBL a tato parcela v ISKN má definiční bod. Další prvky mapy (DPM): Počet DPM v ISKN (ISKN_DPM). Počet DPM ve schématu PUBL (PUB_DPM). Předpokládá se, že ISKN_DPM není rovno PUB_DPM. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 134

147 Kapitola 11. Výpočet ZMĚN nad PUB-DB Počet DPM ve schématu PUBL, které jsou zde navíc oproti ISKN (PUB_NA- VIC_DPM). DPM ve schématu PUBL je pokládána za prvek navíc, pokud neexistuje DPM se stejným ID v ISKN. Počet DPM ISKN, které ve schématu PUBL chybí (PUB_CHYBI_DPM). DPM je považován za prvek, který ve schématu PUBL chybí, pokud ve schématu PUBL není prvek se stejným ID. Dále tento prvek v ISKN musí mít určené k.ú. a pokud je tento prvek v ISKN liniový, pak nesmí pouze obsahovat opakující se body. Speciálním případem jsou DPM tzv. chyby po migraci (mající TYPPPD_KOD=1050), které do struktur PUBL nesmějí být konvertovány a tedy nemohou být ani považovány za prvky, které ve schématu PUBL chybí. Orientační prvky mapy (POM): Počet POM v ISKN (ISKN_POM). Počet POM ve schématu PUBL (PUB_POM). Předpokládá se, že ISKN_POM není rovno PUB_POM. Počet POM ve schématu PUBL, které jsou zde navíc oproti ISKN (PUB_NA- VIC_POM). POM je ve schématu PUBL navíc, pokud POM se stejným ID neexistuje ve schématu ISKN. Počet POM ISKN, které ve schématu PUBL chybí (PUB_CHYBI_POM). POM je považován za prvek, který ve schématu PUBL chybí, pokud ve schématu PUBL není prvek se stejným ID a POM v ISKN neobsahuje tzv. malý text (text o velikost 200 a menší). Budovy: Počet budov v ISKN (ISKN_BUDOVY). Počet budov ve schématu PUBL (PUB_BUDOVY). Předpokládá se, že ISKN_- BUDOVY není rovno PUB_BUDOVY. Počet budov ve schématu PUBL, které jsou zde navíc oproti ISKN (PUB_NA- VIC_BUDOVY). Budova ve schématu PUBL je pokládána za budovu navíc, pokud neexistuje budova se stejným identifikátorem (ID) v ISKN nebo tato budova nemá v ISKN definiční bod. Počet budov ISKN, které ve schématu PUBL chybí (PUB_CHYBI_BUDOVY). Budova je považována za budovu, která ve schématu PUBL chybí, pokud ve schématu PUBL není budova se stejným ID. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 135

148 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB Kapitola 12 Chyby ISKN a jejich přenos do PUB-DB 12.1 Chyby geometrie Duplicitní body Duplicitní body představují na první pohled poměrně jednoduše odstranitelnou chybu, která se nalézá v geometrii parcel a dalších prvků mapy. Při hlubším pohledu je však nutné brát v potaz nejenom úplnou/prostou duplicitu, která spočívá v posloupnosti dvou či více identických souřadnic, ale je nutné brát v potaz i body blízké, tedy tzv. duplicitu ze zaokrouhlení. V současné době pro ISKN neexistuje sada business pravidel pro identické body a jejich relativní přesnost. Proto jsou při hledání duplicitních bodů nad daty ISKN uvažovány pouze prosté duplicity. Praxe však ukazuje, že toto není příliš vhodné pro některé typy geometrických prvků. Kupříkladu šipka parcelního čísla se může skládat z mnoha linií. Jednotlivé navázání linií na sebe je dáno identitou koncového bodu. Nad ISKN lze najít více než 2000 takových linií, které nejsou navzájem navázány identickým bodem, ale bodem, který se v jedné ze souřadnic liší o 1 cm (tzv. chyba ze zaokrouhlování), tedy tyto linie jsou označeny jako samostatné volné konce šipek viz Mimo data ISKN, například data získaná linearizací křivek a oblouků, je odstraňování duplicitních bodů zajištěno programově přímo ve funkcích, které vytvářejí tyto geometrie Lichá křížení Z pohledu teorie grafu lze parcelu katastru nemovitostí reprezentovanou množinou hranic považovat za množinu uzavřených neorientovaných cest. Pokud ještě navíc stanovíme vhodný topologický model (pro naše potřeby nejlépe topologický model popsaný v ISO 19107), můžeme tuto množinu hranic považovat za jednoznačnou množinu uzavřených orientovaných cest 1. Topologický model zde tedy představuje sadu dalších pravidel řešících orientaci cest a způsob, jakým se dotýkají jednotlivé cesty navzájem ve společných vrch- 1 Pokud bychom potřebovali pracovat s jiným topologickým modelem, kupříkladu oblíbeným modelem Okřídlené Hrany (Winged Edge), je nutné předešlou definici náležitě upravit. V případě modelu Okřídlené Hrany bychom byli nuceni pracovat s orientovanými tahy. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 136

149 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB olech. Navíc, pokud do geometrie parcel budeme uvažovat i definiční body parcel, pak předchozí tvrzení platí beze zbytku pro všechny parcely KN. Obdobné tvrzení platí pro geometrii katastrálního území a katastrálního pracoviště. Pro ostatní typy prvků v ISKN (budovy, orientační prvky mapy, další prvky mapy, věcná břemena) to není zaručeno (vyjma bodového pole). Pro nás je nejdůležitější geometrie parcel, protože ostatní geometrie (katastrální území, katastrální pracoviště) z této geometrie vycházejí. Z teorie grafu dále víme, že graf lze reprezentovat množinou uzavřených tahů/cest, pokud je každý z vrcholů grafu sudého stupně. Proto jsou při konverzi geometrie parcel z ISKN do struktur PUB-DB vrcholy s lichým stupněm (lichá křížení) vyhledávány. Pro vysvětlení způsobu, jaký je pro toto vyhledávání použit, definujeme tabulku TEMP_HRANY 12.1, která představuje výrazné zjednodušení a odstínění od struktury ISKN. Příklad 12.1: Tabulka hranic parcel: CREATE TABLE TEMP_ HRANY ( PAR_ID_1 NUMBER (30), PAR_ID_2 NUMBER (30), HRANICE_ ID NUMBER (9) NOT NULL ENABLE, PORADOVE_ CISLO_ BODU NUMBER ( 38) NOT NULL ENABLE, MAX_PORADOVE_CISLO_BODU NUMBER (38) NOT NULL ENABLE, X NUMBER, Y NUMBER, ); Tabulka TEMP_HRANY bude pro naše potřeby obsahovat všechny hranice velkého množství parcel (pro nás zde není důležité přímo vědět, kolik parcel má zde hranice, jen je potřeba zdůraznit, že ne všechny hranice obsažené v této tabulce patří jedné parcele). Hranice jsou v této tabulce zapsány pomocí svých bodů, kdy každý záznam reprezentuje jeden bod hranice. Kdy bodu je přiděleno pořadí (PORADOVE_CISLO_BODU) na této hranici parcely (HRANICE_ID) a souřadnice (X,Y). Sloupec MAX_PORADOVE_CISLO_BO- DU značí maximální pořadí v dané hranici parcely (HRANICE_ID). Sloupce PAR_ID_1 a PAR_ID_2 pak reprezentují parcelní číslo vpravo a vlevo hrany. Je zaručeno, že PAR_- ID_1 je vždy vyplněno, PAR_ID_2 může být nevyplněno (hrana katastrálního pracoviště). Dále je konverzí z ISKN zaručeno, že se jednotlivá PAR_ID v průběhu jedné hranice nemění 2. Před tím, než se pustíme do vyhledávání jednotlivých typů lichých křížení, si na procvičení ukážeme na příkladu 12.2 způsob, jakým lze vyhledat uzavřené linie (linie jejichž první bod je totožný s posledním) parcely zadané parcelním číslem gl_parcela. Příklad 12.2: Zjišťování uzavřených linií: for i in ( select distinct h1. hranice_ id from temp_ hrany h1 join temp_ hrany h2 2 Ve skutečnosti však změna PAR_ID není zaručena na bodě dotyku vnitřní a vnější obálky jedné parcely, což nám při práci s topologickým modelem dle ISO nijak nevadí, na druhou stranu se jedná o defekt v datech ISKN, pro které je definován topologický model Okřídlené hrany. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 137

150 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB on h1.x=h2.x and h1.y=h2.y and h1. hranice_id =h2. hranice_id where h1. poradove_ cislo_ bodu = 1 and h2. poradove_cislo_bodu = h2. max_poradove_cislo_bodu and (h1. par_id_1 = gl_parcela or h1. par_id_2 = gl_parcela ) and (h2. par_id_1 = gl_parcela or h2. par_id_2 = gl_parcela ) union select null from dual ) loop IF i. HRANICE_ID >0 THEN Uzavrene_Linie (i. HRANICE_ID ) :=1; END IF; end loop ; Jak je z ukázky zřejmé, v podstatě zjišťujeme ID hranic, u kterých je první bod souřadnicově navázán na poslední bod té samé hranice. Jako filtr je pak použito číslo parcely. Z pohledu implementace je však vhodné podmínku where zvolit poněkud jinak. Pořadové číslo první parcely vybereme z počátku/konce hranice a pořadové číslo bodu na druhé hranici vybereme jako jakékoliv, které není rovno pořadovému číslu první linie. Příklad 12.3: Úprava podmínky při zjišťování uzavřených linií: select distinct h1. hranice_ id from temp_ hrany h1 join temp_ hrany h2 on h1.x=h2.x and h1.y=h2.y and h1. hranice_id =h2. hranice_id where h1. poradove_cislo_bodu in (1, h1. max_poradove_cislo_bodu ) and h1. poradove_cislo_bodu <>h2. poradove_cislo_bodu and (h1. par_id_1 = gl_parcela or h1. par_id_2 = gl_parcela ) and (h2. par_id_1 = gl_parcela or h2. par_id_2 = gl_parcela ) Volné konce (Stopky) Volná lichá křížení označovaná též jako volné konce nebo stopky 3 patří k nejjednodušším typům chyb v geometrii parcely. Na obrázku 12.1 jsou zobrazeny rozličné podoby tohoto typu chyby v geometrii parcely. Před samotným spuštěním publikační databáze (PUB-DB) byl tento typ chyby poměrně častým jevem nad daty ISKN. Hledání volných konců se provádí v cyklu, přičemž určování je ukončeno, když již není žádný další volný konec nalezen. Proto, aby určování volných konců v cyklu fungovalo, je nutné u nalezeného volného konce nastavit příslušné PAR_ID na prázdné (null). Tedy od tohoto momentu může nastat, že má hranice PAR_ID_1 rovno null, nebo rovnou obě PAR_ID jsou null (nejčastěji po spočtení geometrií obou parcel). Což je kupodivu častější případ a jsme za něj rádi, protože je málo pravděpodobné, že by hranice byla topologickou chybou v rámci jedné parcely a naprosto validní součástí parcely druhé. Na závěr je vhodné zmínit, že hledáním volných konců se svého času na ČÚZK zabýval Ing. Karel Janečka, Ph.D., přestože jeho řešení v praxi bylo schopné odhalit maximálně 30% instancí této chyby, což je pro potřeby PUB-DB nepoužitelné, je dobré zde zmínit tohoto pionýra odhalování chyb v geometrii ISKN. 3 Název používaný zaměstanci ČÚZK Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 138

151 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB Příklad 12.4: Obrázek 12.1: Volné konce Zjišťování volných konců parcel: for i in ( with temp AS ( select * from temp_ hrany where par_ id_ 1 = gl_ parcela or par_id_2 = gl_parcela ) select distinct h1. hranice_ id from temp h1 left join temp h2 on h1.x=h2.x and h1.y=h2.y and h1. hranice_id!= h2. hranice_ id where h1. poradove_cislo_bodu in (1, h1. max_poradove_cislo_bodu ) and h2. hranice_ id is null union select null from dual ) loop IF i. HRANICE_ID >0 and Uzavrene_Linie. exists (i. HRANICE_ID )= FALSE THEN -- Zde mam volny konec update temp_ hrany set par_ id_ 1 = null where hranice_ id = i. HRANICE_ ID and par_id_1 = gl_parcela ; update temp_ hrany set par_ id_ 2 = null where hranice_ id = i. HRANICE_ ID and par_id_2 = gl_parcela ; END IF; end loop ; end loop ; Pevná lichá křížení (Stopky/Linie navíc) Pevná lichá křížení vznikají na parcelách, kde jsou dva a více vrcholů lichého stupně a přitom zde není žádný volný konec. Ukázky tohoto typu chyb jsou vyobrazeny na obrázku K těmto topologickým chybám dochází náhodně při slučování a rozdělování parcel Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 139

152 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB v průběhu let, proto je velmi těžké tyto chyby odhalit. Plně automatická oprava těchto chyb je možná jen pro podmnožinu, kupříkladu konfigurace c na obrázku 12.2 není možné řešit, konfigurace a, b, které se zdají lehce řešitelné, ve skutečnosti (po přiložení Katastrální mapy na ortofotomapu) mohou odhalit daleko závažnější chyby. Z tohoto důvodu se tento typ chyb odstraňuje jen při migraci ISKN do PUB-DB a to jen několik málo typizovanými postupy. Hranu je zde možné odstranit pouze tehdy, pokud přímo spojuje vrcholy lichého stupně. Po procesu migrace je navíc nutné všechny tyto chyby projít a ověřit správné řešení. Pro výpočet inkrementálních přírůstků v čase nad ISKN (výpočet ZMĚN) se žádné opravy neprovádějí a parcela, která obsahuje tuto chybu, není přenesena do PUB-DB, ale je pouze logována pro ruční opravu. Pro představu jen uvedu, že při migraci bylo odstraňováno cca 50 takových chyb. V současnosti jsou všechny tyto chyby opraveny ISKN, předpokládaný přírůstek těchto chyb je cca 1-2 chybné parcely za 4-5 měsíců (porovnání provedeno za posledních 13 měsíců). Obrázek 12.2: Pevná lichá křížení Příklad 12.5: Křížení vyšších řádů: select X, Y, count (*) c from temp_ hrany_ b_ loc where ( PAR_ID_1 = gl_parcela or PAR_ID_2 = gl_parcela ) and poradove_cislo_bodu in (1, max_poradove_cislo_bodu ) and hranice_ id not in ( -- musim vyradit sebeuzavrene polygony select j. HRANICE_ ID as HA from temp_ hrany_ b_ loc j join temp_ hrany_ b_ loc k on j. HRANICE_ID =k. HRANICE_ID and j. poradove_cislo_bodu < k. poradove_ cislo_ bodu and j.x=k.x and j.y=k.y and (j. par_id_1 = gl_parcela or j. par_id_2 = gl_ parcela ) and (k. par_id_1 = gl_parcela or k. par_id_2 = gl_parcela ) ) group by X, Y having count (*) >2 Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 140

153 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB Prázdné polygony Všechny typy prázdných polygonů představují chyby zápisu geometrie v ISKN, které se neprojeví při samotném výpočtu geometrie parcely pro PUB-DB, ale až při výpočtu geometrií prvků vyšších řádů (katastrální území, katastrální pracoviště). Tedy ve smyslu PUB-DB nejsou tyto chyby destruktivní, protože k samostatnému vytvoření validní geometrie parcely dojde, ale s tím, že tato geometrie není správně navázána na ostatní geometrie parcel. Žádná z těchto chyb se automaticky v PUB-DB neodstraňuje. V současné době lze velmi jednoduše najít všechny tyto chyby v rámci jednoho katastrálního území. Daný algoritmus by bylo možné jednoduše upravit i pro nalezení všech těchto chyb v rámci katastrálních pracovišť. Algoritmus spočívá ve vytvoření geometrie katastrálního území z jednotlivých hranic parcel. Do výpočtu zde nevstupují všechny hranice parcel v tomto k.ú., ale jen ty na jeho okraji. Tedy hranice parcel v PUB-DB, které mají rozdílné kódy katastrálních území nebo i hranice parcel daného k.ú., kde jedna z parcel není přítomna v PUB-DB nebo má hranice v PUB-DB vyplněné jen PAR_ID_1. Tímto způsobem lze získat aktivní obvody (území s parcelami ve vektorové formě) katastrálních území. Z podstaty věci takto získané geometrie obsahují i všechny prázdné polygony. Poměrně jednoduchým způsobem lze pak výslednou geometrii sekvenčně projít a odstranit z ní všechny prázdné polygony podle stanovených kritérií (nejlepší kombinací kritérií se zdají podmínky výměry do půl metru a rozměr prázdného polygonu menší než 10 cm ve směru kolmém na libovolnou jeho hranu). Nakonec je ještě potřeba zjistit duplicitní linie pomocí standardních funkcí Oracle a následně je odstranit. Výhoda tohoto řešení je ta, že ke zjišťování prázdných polygonů může docházet plně automaticky, vždy když se změní některá linie obvodu k.ú. Navíc, pokud bychom tomuto automatickému výpočtu nevěřili, je možné během cca jedné hodiny získat pro všechna k.ú. tyto chyby novým výpočtem přímo z dat PUB-DB Duplicitní linie (Třísky) Duplicitní linie (Obrázek 12.3) jsou reprezentovány zdvojením hranice mezi dvěma parcelami. Oba záznamy se liší pouze ve vyplněném PAR_ID_1, PAR_ID_2 jsou prázdná. Tento typ prázdného polygonu představuje jediný typ, který by bylo možné automatizovaně odstraňovat, kdy v případě procesu migrace celé ISKN do struktur PUB-DB je možné poměrně efektivně tyto chyby odstranit. Problémy však nastanou, pokud chceme podobný způsob zacházení aplikovat i na přírůstky ISKN v čase, tzv. výpočet ZMĚN. Zde mohou nastat dvě možnosti. První případ nastane, když jsou obě duplicitní hranice vloženy do PUB-DB v rámci jednoho výpočtu ZMĚN, kdy je možné tento typ chyby efektivně zachytit a odstranit. Druhý případ nastane, když v ISKN resp. PUB-DB již jedna instance této hranice existuje, v rámci replikací (výpočtu ZMĚN) je pak přidána druhá instance. Nalezení takové duplicitní linie představuje nepříliš efektivní prostorový dotaz. Tedy při každém výpočtu změn by bylo potřeba zjišťovat, zda některá z parcel s prázdným PAR_ID_2 není již v databázi v příslušném katastrálním pracovišti. Podmínka příslušnosti ke katastrálnímu pracovišti je nutná, protože vektorová mapa KN vlastně tvoří množinu ostrovních map, kde data jednotlivých katastrálních pracovišť o sobě neví, tedy existuje zde určitá přirozená množina duplicitních linií mezi jednotlivými katastrálními pracovišti. Ani jeden zmíněný typ není v současné době automaticky odstraňován, protože nároky na běh programového zabezpečení přesahují užitek (hlavně počet vznikajících chyb). Vzhle- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 141

154 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB dem k existenci dalších typů prázdných polygonů je daleko efektivnější tyto chyby zjišťovat při výpočtu geometrie katastrálních území. Obrázek 12.3: Duplicitní linie Prázdné polygony (Třísky) Duplicitní polygony (Obrázek 12.4 ) představují nejčastěji velmi štíhlý (prázdný) trojúhelník mezi dvěma parcelami. Tento typ chyby není možné automatizovaně odstranit, protože zde je mnohdy vyžadováno nejenom sloučení dvou linií, ale též s tím spojené rozhodnutí, která geometrie z obou hranic je ta správná. Nezřídka se pak stává, že obě hranice jsou špatné a je nutné do systému dodat hranici zcela novou. Obrázek 12.4: Prázdné polygony Prázdné spojené polygony (Dvojtřísky) Prázdné spojené polygony (Obrázek 12.5 ) představují speciální chybu, která vzniká v PUB-DB (existence této chyby nás v ISKN do značné míry nezajímá). Vznik této chyby je dán z podstaty algoritmu tvorby hranic parcel v PUB-DB, kdy je definováno, že hranice představuje nejdelší možný úsek polygonu parcely, na kterém se zachovává stejná PAR_ID a nedochází zde ke změně interpretace hranice (typu prvku prostorových dat), změně způsobu interpolace, dále je zde brán zřetel na přesnost jednotlivých bodů. V praxi tedy může Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 142

155 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB nastat situace, že dvě parcely mají mezi sebou prázdné polygony, které jsou spojené jedním společným bodem nebo jeden prázdný polygon na samotné aktivní hranici (hranice katastrálního pracoviště nebo okrajová hranice vektorové kresby). Dle topologického modelu, který je popsaný v ISO 19107, by pak tento bod měl rozdělovat polygon parcely na dvě hranice, aby bylo možné následně správně zapsat vnější a vnitřní část polygonu katastrálního území. (Obrázek 12.6 představuje případy prázdných dvoj-polygonů v PUB-DB a jejich následnou správnou reprezentaci v ISO modelu). V PUB-DB však při tvorbě geometrie parcely na tento bod není a ani nemůže být brán zřetel, protože pak by bylo možné, že hranice parcely v PUB-DB se bude měnit, přestože v ISKN je tato hranice neměnná, jen proto, aby odpovídala nově příchozím hranicím zcela nové parcely. Dalším možným řešením, jak se s tímto problémem vypořádat, je definovat hranice s prázdným PAR_ID_2 čistě jako linie o dvou bodech. Toto řešení však postrádá jistou eleganci. Vzhledem k tomu, že tyto chyby jsou do značné míry spojeny s fenoménem chyb prázdných polygonů (v ISKN existuje jen jedna instance této chyby, která není spojena s prázdným polygonem ve formě chyby, a to na DKM na části) je výhodné naopak opravy těchto chyb neprovádět. Daný typ chyby pak může být jen reprezentován v metadatech i když i zde převládá názor, že tuto chybu vzhledem k její povaze není potřeba uvádět v INSPIRE metadatech. Do metadat tedy pouze zapisujeme samostatné volné polygony. Skutečnost, že tuto chybu na hranicích parcely neodstraňujeme, neznamená, že tuto chybu budeme tolerovat i v samotné geometrii reprezentující polygon/region daného k.ú. Právě naopak, zde tuto chybu musíme odstranit, aby tato geometrie byla validní! Obrázek 12.5: Prázdné spojené polygony Nevalidní geometrie Chybami vedoucími k nevalidní geometrii budeme rozumět různorodé typy chyb, které po sestavení geometrie brání její validitě. Geometrii určíme jako validní, pokud test validity v Oracle Spatial, reprezentovaný funkcí sdo_geom.validate_geomery_with_context, bude vyhodnocen jako true. Nad takovou geometrií umí programové zabezpečení Oracle vystavět prostorový index a provádět správně prostorové dotazy (ať již pro svou funkci potřebují prostorový index nebo ne). Zde je nutné zmínit, že samotný test má hodnotu pouze v prostředí Oracle, protože mnohé prováděné dílčí testy jsou velmi vágní a mnohé potřebné kontroly zde nejsou prováděny. Toto v minulosti způsobovalo nemalé potíže při Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 143

156 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB Obrázek 12.6: Hranice parcel v PUB-DB a dle ISO napojení systému Oracle na jiné systémy (kupříkladu produkty firmy ArcGIS) 4. V současné době se však tyto systémy, díky tržnímu podílu firmy Oracle, přizpůsobily definici použité v Oracle Spatial a plně umožňují s těmito daty pracovat Křížení linií parcel (Smyčky) Jedná se o málo častou chybu, kterou lze najít v zápise geometrie polygonu, kdy dochází ke křížení jednotlivých hranic parcely. Tato chyba by se teoreticky (dle dokumentace ISKN) neměla v datech vyskytovat. Po jejím odhalení však tvůrce ISKN konstatoval, že v určitých případech nedokáže vzniku této chyby zabránit. Tato chyba byla v současnosti odhalena jen v případě zápisu geometrie parcel. U jiných objektů (především budov) nebyl dosud prokázán vznik této chyby. Navíc se tato chyba vyskytuje pouze u geometrie parcel, které jsou uvnitř jiné parcely. Při konverzi geometrie parcely s touto chybou z ISKN do PUB- DB nedojde k vytvoření této parcely v PUB-DB (protože geometrie této parcely obsahuje chybu), ale do PUB-DB jsou přeneseny hranice této parcely. Tedy vektorová mapa v aplikaci Nahlížení do KN obsahuje kresbu hranic parcel, ale dané parcely nelze vyhledávat. Tím, že není zasažená parcela vytvořena v PUB-DB, dojde k zalogování této chybějící parcely do statistik chyb. Oprava této chyby se pak provede automaticky s opravou chyby v ISKN nebo ručně ve schématu PUBL v PUB-DB. Ruční oprava v PUB-DB spočívá v pouhé opravě dotyčné hranice parcely a opětovného spočtení této parcely z geometrie ve schématu PUBL v PUB-DB Chyby přesnosti parcel (Výběžky) Tato chyba je oproti té předchozí nedestruktivního typu. Tedy geometrii této parcely i s příslušnými chybami lze zapsat do PUB-DB. Tato chyba se projeví při pokusu validovat geometrii polygonu parcely (u jiných prvků tato chyba nebyla nalezena) při toleranci jeden milimetr. Tolerance v Oracle Spatial představuje informaci o úrovni přesnosti, kterou si 4 Na obranu řešení Oracle je potřeba zmínit, že kontroly, které se provádějí, jsou pouze a právě ty potřebné pro vestavěnou funkcionalitu Oracle Spatial a plně odpovídají interpretaci modelu geometrie a topologie ISO v době svého vzniku. V průběhu času se pak oficiální interpretace některých pravidel v příslušné normě upravila a vzniklé odlišnosti v Oracle představují udržování zpětné kompatibility v rámci vlastní produktové řady. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 144

157 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB Obrázek 12.7: Křížení linií parcel lze nejlépe představit jako mez vzdálenosti mezi dvěma body, pod kterou jsou dva body vnímány jako totožné. Tedy tolerance 1 mm by měla být dostatečnou mezí pro zápis geometrie polygonu parcely, kde jednotlivé body jsou zapsány s přesností 1 cm. Naneštěstí však existují i takové konfigurace, pro které je tolerance 1mm nevyhovující. Prakticky je tedy nutné výslednou geometrii parcely validovat s přesností 1/10 mm. Existence takové konfigurace téměř vždy (dosud se nepodařilo najít opak) je způsobena špatným zápisem lomového bodu parcely. K této chybě nejčastěji dochází při rozdělování parcely. Tato chyba je pro potřeby PUB-DB logována, a přes velké množství svých instancí je postupně odstraňována v rámci 5. etapy oprav dat v ISKN. Obrázek 12.8: Chyby přesnosti parcel Další chyby parcel Pouze zmenšené parcelní číslo Pokud je parcela příliš malá, je její parcelní číslo zmenšeno na minimální velikost, která zaručí, že se toto parcelní číslo nezobrazí, ale budou pro něj fungovat všechny vyhledávací funkce jako u parcelního čísla o standardní velikosti. Navíc je toto zmenšené parcelní číslo doplněno o parcelní číslo standardní velikosti umístěné vhodně mimo parcelu. Spojení parcely(především visuální) a nového standardního parcelního čísla je provedeno pomocí šipky parcelního čísla. V ISKN však dochází k jevu, kdy k parcele existuje pouze zmenšené parcelní číslo. Tento stav je pro potřeby oprav zaznamenán do logu PUBL.PUB_LOG. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 145

158 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB Samostatný volný konec šipky parcely Jak již bylo zmíněno v kapitole 8, šipka parcely se povinně skládá z tzv. pevné části a volitelně pak jedé nebo více volných částmí. Pevná část je reprezentována samotnou šipkou o velikosti 2 metry (Obrázek 12.9/a). Volné části pak představují linie o dvou nebo více bodech vzájemně spojené, přičemž každá skupina spojených volných částí musí být napojena na právě jednu pevnou část šipky (Obrázek 12.9/bc). V ISKN však dochází k tzv. chybě ze zaokrouhlení pro identické body volných částí šipky. Tyto chyby pak brání samotnému spojení dvou volných částí (linií) šipky nebo častěji spojení volné a pevné části šipky navzájem. Nejčastěji se chyba projeví pouze v jedné rozdílné souřadnici (rozdíl je zde 1 cm). Do PUB-DB se vkládají všechny pevné části a pouze ty volné části, které jsou přímo nebo nepřímo navázány na pevnou část. Tedy šipky z obrázku 12.9/a-c uložené v PUB-DB mohou mít skutečnou podobu v ISKN z obrázku 12.9/d-f. Ostatní, tzv. samostatné volné části šipky, jsou zaznamenány v logu a spolu s ostatními chybami v ISKN jsou odstraňovány na příslušných katastrálních pracovištích. Obrázek 12.9: Šipky parcel a jejich chyby Chybějící/Duplicitní definiční bod V ISKN není programově zabezpečeno, že každá parcela (budova) nutně musí mít definiční bod. Této vlastnosti se následně využívá při obnově operátu, kdy je nejprve smazána geometrie parcely včetně definičního bodu, záznam v tabulce AK_PARCELY však zůstává. Pro potřeby PUB-DB je však nutné ošetřit nejenom tento proces obnovy, ale i samotné stavy, kdy parcela (budova) má žádný nebo více definičních bodů. PUB- DB proto zavádí pro parcely následující pravidla: Pokud parcela zjednodušené evidence nemá definiční bod, tak není pro potřeby PUB-DB brána v potaz (takových parcel ZE je cca 2 miliony). Obdobné pravidlo platí pro parcely Katastru Nemovitostí (parcela KN), které nemají hranice parcel. Pokud parcela KN má geometrii hranic a nemá definiční bod, tak její instance nevzniká ani procesem MIGRACE ani postupným výpočtem inkrementálních přírůstků (výpočet ZMĚN) a tato chyba parcely je zalogována do tabulky PUBL.PUB_LOG. Pokud parcela KN během výpočtu ZMĚN ztratí jak svou geometrii hranic, tak i definiční bod, tak tato parcela KN v PUB-DB zaniká. Pokud ale parcela KN během výpočtu ZMĚN ztratí pouze svůj definiční bod, tak tato parcela dále v PUB-DB existuje se svým původním def. bodem. A na závěr pokud existuje pro libovolnou parcelu větší počet definičních bodů, tak je pro PUB-DB použit jen první z nich a tato skutečnost (chyba) je opět zaznamenána. Chyby vícenásobných definičních bodů se však v ISKN již poměrně dlouhou dobu nevyskytují. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 146

159 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB Chyby geometrie budov Pro geometrii budov je celkem těžké stanovit jakákoliv pravidla povolených geometrických typů. Na obrázku jsou zobrazeny možné validní reprezentace geometrie. V současné době je prakticky jediným omezením v KN to, že budova nemůže být zadána pouze neuzavřenou linií. Problémem, který zůstává dosud nevyřešený, je nalezení dostatečně efektivního algoritmu, který bude schopen (nejlépe pomocí polygonů) uložit všechny validní parcely do prostorové geometrie Oracle. Objektem typu budova se v prostředí PUB-DB zabýval Mgr. Luboš Matásek. Po jeho odchodu z ČÚZK se však rozvoji daných algoritmů prakticky nikdo dále nevěnoval, protože význam budov v PUB-DB klesl z rozhodnutí vedení ČÚZK. Toto rozhodnutí upřednostnilo poskytování INSPIRE tématu Budovy z prvku stavební objekt systému ISÚI, před prvkem budova v ISKN. Ke cti Mgr. Matáska je potřeba zmínit, že nedokončení algoritmu v žádném případě není jeho chybou, protože v době jeho odchodu ještě v rámci ČÚZK nebylo zřejmé, co je a co není validní reprezentace geometrie a též v té době nebyla k dispozici plnohodnotná PUB-DB. Veškeré testování se tedy provádělo nad velmi omezenou testovací databází PUB-DB-T, která obsahovala cca 1% dat ISKN a jinými pomocnými systémy. Obrázek 12.10: Validní budovy 12.2 Negeometrické chyby Neexistující PAR_ID Neexistující parcelní číslo většinou představuje speciální případ volného konce, kdy dotčená hranice je plnohodnotnou součástí jedné jinak bezproblémové parcely. Geometrii druhé parcely (PAR_ID_1 nebo PAR_ID_2) však nelze sestrojit. Protože tato hranice je jedinou hranicí této parcely a přitom nepředstavuje uzavřený polygon. Tuto chybu vyčleňujeme, protože zde není pevně stanoveno, zda daná parcela musí v ISKN vůbec existovat. Může se tedy jednat o hranici neexistující parcely nebo častěji hranici parcely, která nebyla smazána z ISKN před nadcházející obnovou operátu. Samotná obnova může, ale nemusí danou chybu opravit. Pro potřeby PUB-DB je tato chyba zanesena do statistik jako ne- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 147

160 Kapitola 12. Chyby ISKN a jejich přenos do PUB-DB spočtená parcela. Navíc je tato hranice zanesena do tabulky PUBL.PUB_OPRAVY_HRA- NICE_KU, kdy tato tabulka obsahuje všechny hranice, které by měly být na okraji k.ú. Jelikož ale data v PUB_HRANICE_PARCEL obsahují obě PAR_ID (tedy i to špatné), není možné tyto hranice z této tabulky určit implicitně jako hranice katastrálního území Špatný KATUZE_KOD Špatný KATUZE_KOD (identifikátor příslušnosti ke katastrálnímu území) je zapsán nejčastěji u dalších prvků mapy. Tato chyba nad daty ISKN je velmi dobře popsána v bakalářské práci Adély Volfové ([30]), která se na ČÚZK zabývá chybami v geometrii dalších prvků mapy. V této práci však není zmíněn praktický dopad této chyby pro infrastrukturu PUB-DB a aplikaci Nahlížení do KN. Při libovolné změně v k.ú. se do datového skladu WKB geometrií načte celé toto změněné k.ú., ale nedochází zde automaticky k výpočtu opsaného obdélníku jednotlivých typů prvků daného k.ú. Tato funkce vzhledem ke své náročnosti je volána pouze explicitně na vyžádání administrátora dané služby (předpokládá se, že tato funkce bude v budoucnu volána automatizovaně 1 denně). V případě, že do daného k.ú. je zařazen i prvek mimo daný opsaný obdélník, se tento prvek nezobrazuje v aplikaci Nahlížení do KN až do doby přepočítání tohoto opsaného obdélníku (ve skutečnosti se jedná o prostorový index). Speciálním případem jsou další prvky mapy s prázdným KATUZE_KODEM (bez příslušnosti ke katastrálnímu území). Takovéto prvky (v současnosti celkem 5418 prvků) se do PUB-DB nepřenášejí Další chyby V rámci této kapitoly nebylo možné vyjmenovat všechny chyby Souboru Geodetických Informací (SGI). Některé chyby, jako definování kruhového oblouku dvěma body místo třech zde byly záměrně vynechány. Protože se mnohdy jedná o osamělé chyby, které by údajně neměly vznikat. Chyby dalších prvků mapy (DPM) zde kvůli své odlišnosti nebyly zmíněny téměř vůbec. Pro případné zájemce o tuto problematiku doporučuji k přečtení již zmíněnou bakalářskou práci Adély Volfové (Analýza místního a pomístního názvosloví v katastrální mapě). Tato práce se přes svůj rozsah 90 stran zabývá pouze textovými prvky DPM, což na druhou stranu samo o sobě může dokreslit představu o množství různorodých typů chyb nad prvky DPM Opravy chyb Všechny výše zmíněné chyby jsou buďto přímo logovány v publikační databázi (schéma PUBL, tabulka PUB_CHYBY) nebo jsou snadno z PUB-DB získatelné. V současnosti jsou tyto chyby v intervalu cca 3 měsíců zasílány jednotlivým katastrálním pracovištím k opravě. Výsledky těchto oprav jsou však různorodé. Zatímco na jedné straně se povedlo odstranit některé typy chyb úplně (kružnice DPM bez poloměru zadaná středem, geometrie DPM pouze s vnitřním polygonem), některé chyby jsou při opravách téměř ignorovány. Tedy mnohé chyby, přestože jsou známy, mohou v systému ISKN přežívat téměř libovolně dlouhou dobu (není výjimkou, že chyby existují i 6 měsíců po svém objevení). Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 148

161 Kapitola 13. Obnova operátu (Námitkové řízení) Kapitola 13 Obnova operátu (Námitkové řízení) Obnova operátu představuje doplnění budoucího zplatnění do Publikační databáze (PUB-DB). Rozšíření PUB-DB o budoucí stav je čistě z důvodu poskytování této funkcionality v aplikaci Nahlížení do KN. Navíc data budoucího stavu se nikdy nestanou daty současnosti, ale namísto toho zaniknou. Tedy data budoucího stavu existují nezávisle na přítomnosti a minulosti v PUB-DB. Tato speciální vlastnost v podobě nezávislosti velmi zjednoduší návrh části databázového schématu budoucnosti pro PUB-DB, protože geometrie prvků nebude muset splňovat podmínky směrnice INSPIRE, ale bude nutné ji uzpůsobit pouze k zobrazování ve webovém mapovém serveru pro aplikaci Nahlížení do KN Import dat do databáze Celý proces obnovy řídí speciální služba (windows-service), která má za úkol hlídat přírůstky a úbytky databázových exportů (dumpů) v souborovém systému příslušného serveru. Každý z exportovaných souborů představuje jeden export obnovy operátu vytvořený programem MicroGeos Nautil. Tato windows služba v pravidelných intervalech načte seznam všech exportovaných projektů (souborů). Pokud zjistí, že nějaký projekt nově vznikl nebo se změnil, provede jeho import do databázového schématu MGEO_IMPORT. Toto schéma existuje jen z importních důvodů a existuje v něm jen právě načítaný projekt. Nejzajímavější částí tohoto schématu je tabulka NX_MG_PROJEKTY, která obsahuje jediný záznam (řádek). Tento záznam se skládá z identifikátoru projektu (GUID), katastrálního území (KATUZE_KOD) a doby platnosti zobrazení obnovy (DATUM_PLATNOSTI_OD a DATUM_PLATNOSTI_DO). Takto importované schéma se následně zkopíruje do schématu MGEO_XXXXXX_KOD (XXXXXX představuje kód katastrálního území) a dvojice GUID, KATUZE_KOD se zapíší do schématu NAHLIZENI tabulky MGEO_PRO- JEKTY. Následně se spustí funkce publ.mgeo_pridej_guid a nebo v případě, že je projekt smazán, se spustí funkce publ.mgeo_smaz_guid. Obě funkce mají jediný parametr GUID, z pomocí tohoto parametru se zjistí v tabulce NAHLIZENI.MGEO_PRO- JEKTY identifikátor katastrálního území a následně se provede import nebo smazání geometrie tohoto projektu z PUB-DB. Nebo jinak řečeno obě funkce provedou nejprve smazání geometrie projektu z PUB-DB a funkce publ.mgeo_pridej_guid navíc provede následované znovunačtení těchto dat do PUB-DB a to z důvodu možnosti v jed- Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 149

162 Kapitola 13. Obnova operátu (Námitkové řízení) notlivých projektech provádět opravy. Na obrázku 13.1 představuje PROJECT_2.dump nový projekt z katastrálního území , pro tento projekt se tedy vytvoří nové databázové schéma MGEO_ PRO- JECT_3a.dump pak představuje nový projekt v katastrálním území V tomto katastrálním území ale již jeden projekt (PROJECT_3.dump) existuje, proto se tento projekt pouze přidá do databázového schématu MGEO_ Dále windows služba zjistila, že ze vstupního adresáře zmizel projekt PROJECT_1.dump, proto se data tohoto projektu smažou ze schématu MGEO_ a samozřejmě i z PUB-DB. Navíc byl tento projekt jediný v katastrálním území , proto dojde ke zrušení schématu MGEO_ Obrázek 13.1: Schéma importu budoucnosti 13.2 Databázové schéma PUB-DB Tabulky reprezentující budoucnost (tabulky obrázku 13.2 s koncovkou _B ) jsou zcela nezávislé na ostatních tabulkách PUB-DB a jsou též do značné míry nezávislé i na datech reprezentujících repliku ISKN. Tyto tabulky jsou umístěny ve schématu PUBL pro zjednodušení správy při kopírováním WKB geometrie do datového skladu webového serveru pro aplikaci Nahlížení do KN a WMS, kdy je zcela zbytečné těmto tabulkám vytvářet vlastní databázové schéma, protože jediný přístup k nim vyžaduje právě služba publikace WKB souborů. Tedy ta samá služba, která publikuje data současnosti PUB-DB. Základní tabulkou je zde PUB_KATASTR_UZEMI_B, která představuje zjednodušenou obdobu tabulky PUB_KATASTR_UZEMI. Tato tabulka, stejně jako tabulka současnosti, určuje publikaci dat jednotlivých katastrálních území pro webový server. Publikace budoucího stavu je zcela nezávislá na současnosti a navíc je možné publikovat případně nově vzniklá katastrální území, která ještě v ISKN neexistují. Všechny ostatní tabulky budoucnosti jsou navázány na tuto tabulku sekundárním klíčem (KATUZE_KOD). Navíc všechny tyto tabulky ještě mají sloupec GUID, který umožňuje identifikovat zdrojový projekt pro operace znovunačtení projektu nebo jeho smazání. Na tabulky budoucnosti Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 150

163 Kapitola 13. Obnova operátu (Námitkové řízení) nejsou kladeny žádné požadavky na topologii. Geometrie je vždy reprezentována v tom nejjednodušším možném tvaru a nejsou prováděny, žádné kontroly konzistence dat. Kupříkladu tabulka PUB_BUDOVY_B zcela postrádá geometrii, protože ta ve vstupních datech též zcela chybí. Naproti tomu v tabulce PUB_PARCELY_B geometrie chybí, přestože by šla vytvořit z geometrie hranic parcel. Tabulka PUB_HRANICE_PARCEL_B obsahuje hranice parcel bez rozlišení jejich kvality (přesnosti) a tyto hranice jsou v původním tvaru (žádné nahrazování kružnic a kruhových oblouků). Dokonce zde nevadí, pokud hranice nemají vyplněné PAR_ID_1 a PAR_ID_2. Je však velmi výhodné, pokud jsou obě PAR_ID obsaženy ve vstupním dumpu, protože tyto hodnoty umožňují v aplikaci Nahlížení do KN pro přehlednost zvýraznit hranice hledané parcely. U tabulky PUB_PARCELY_B neexistují žádné požadavky na pořadí pevné a volné části šipky, tato tabulka navíc, oproti tabulce současnosti, může obsahovat i samostatné volné části šipky. Další specialitou je tabulka PUB_ZNACKY_PARCEL_B. Vznik této tabulky je dán skutečností, že jednotlivé značky parcel v tabulce MGEO_XXXXXX.AK_OBRAZY_PARCEL (XXXXXX značí číslo katastrálního území) nemusejí mít příslušné PAR_ID. Poslední tabulkou je tabulka PUB_DALSI_PRVKY_MAPY_B. Tato tabulka se velmi podobá tabulce současnosti. Je to dáno především tím, že na data této tabulky nebyly vynaloženy žádné přísné požadavky. Tedy data jsou jak v přítomnostní tak i v budoucnostní tabulce zatížena mnoha topologickými chybami. Jak již bylo řečeno budoucnostní tabulky obecně představují velmi zjednodušený pohled na geometrická data. To je dáno tím, že tato data nebudou publikována jako data INSPIRE a samozřejmé také tím, že v jednotlivých exportech projektů prostě některá data chybějí. S jistou mírou nadsázky lze říci, že pokud by neexistovala směrnice INSPIRE, neexistoval by důvod proč by data současnosti neměla být publikována v podobném (podobně ošklivém) tvaru. V budoucnosti se též počítá s modernizací aplikace Dálkový přístup do KN, který představuje placenou obdobu aplikace Nahlížení do KN. Navíc však tato aplikace umožňuje placený výstup opatřený elektronickou značkou. Součástí této modernizace bude i úprava publikace grafických dat. Pro naplnění nových požadavků by zcela dostačovalo, pokud by byla data publikována v tomto zjednodušeném formátu Operace nad PUB-DB Jak již bylo zmíněno výše pro práci s PUB-DB jsou určeny dvě PL/SQL procedury MGEO_PRIDEJ_GUID (Příklad 13.1) a MGEO_SMAZ_GUID (Příklad 13.2), které se pro zjednodušení nalézají v databázovém schématu PUBL. Spouštění těchto funkcí se děje automaticky na základě přírůstku nebo úbytku souborů s obnovou. Úkolem těchto funkcí je konverze geometrie do struktury PUB-DB a následný update tabulky PUB_KATASTR_U- ZEMI_B, tak, aby došlo k update WKB geometrie v příslušném datovém skladu. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 151

164 Kapitola 13. Obnova operátu (Námitkové řízení) Obrázek 13.2: Schéma tabulek PUB-DB reprezentující budoucnost Příklad 13.1: Funkce MGEO_PRIDEJ_GUID create or replace procedure MGEO_ GENERUJ_ GUID ( i_ guid in varchar2 ) as datum date default sysdate ; k_ kod number (6) default 0; prefix varchar2 ( 100) ; pocet number ; begin select TO_ NUMBER ( katuze_ kod ) into k_ kod from NAHLIZENI. MGEO_ PROJEKTY where guid = i_ guid ; prefix := MGEO_ TO_CHAR ( k_kod ).AK ; MGEO_GENERUJ_PARCELY ( k_kod, i_guid, prefix, sysdate ); MGEO_GENERUJ_BUDOVY ( k_kod, i_guid, prefix, sysdate ); MGEO_GENERUJ_HRANICE ( k_kod, i_guid, prefix, sysdate ); MGEO_GENERUJ_DPM ( k_kod, i_guid, prefix, sysdate ); select count (*) into pocet from pub_katastralni_uzemi_b where kod = k_kod ; IF pocet =0 THEN insert into pub_katastralni_uzemi_b (kod, datum_posledni_aktualizace, datum_posledni_publikace ) values ( k_kod, sysdate, null ); ELSE update pub_katastralni_uzemi_b set datum_posledni_aktualizace = sysdate where kod = k_kod ; END IF; commit ; exception when others then null ; end ; Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 152

165 Kapitola 13. Obnova operátu (Námitkové řízení) Příklad 13.2: Funkce MGEO_SMAZ_GUID: create or replace procedure MGEO_ SMAZ_ GUID ( i_ guid in varchar2 ) as k_ kod number (6) default 0; pocet number ; begin select TO_ NUMBER ( katuze_ kod ) into k_ kod from NAHLIZENI. MGEO_ PROJEKTY where guid = i_guid ; delete pub_ budovy_ b where guid = i_ guid and katuze_ kod = k_ kod ; delete pub_ parcely_ b where guid = i_ guid and katuze_ kod = k_ kod ; delete pub_ hranice_ parcel_ b where guid = i_ guid and katuze_ kod = k_ kod ; delete pub_dalsi_prvky_mapy_b where guid = i_guid and katuze_kod = k_kod ; delete pub_ znacky_ parcel_ b where guid = i_ guid and katuze_ kod = k_ kod ; select count (*) into pocet from pub_ hranice_ parcel_ b where katuze_ kod = k_kod ; IF pocet =0 THEN -- GEOVAP udajne jiz umi mazat WKB pro jednotliva k. u. delete pub_katastralni_uzemi_b where kod = k_kod ; ELSE update pub_katastralni_uzemi_b set datum_posledni_aktualizace = sysdate where kod = k_kod ; END IF; commit ; exception when others then null ; end ; Příklad 13.3 znázorňuje část funkce vytvářející geometrii hranic parcel obnovy. Nejzajímavější je povšimnout si rozdílů oproti generování hranic parcel z ISKN pro současný stav. Pro hranice budoucnosti dochází k užití dynamického SQL pro získání dat z různých schémat. Dále je z dotazu zřejmá skutečnost, že budoucnost PUB-DB nepracuje s přesností bodů. A na závěr zde můžeme spatřit náznak přímého vytváření geometrie, tedy včetně kružnic a kruhových oblouků. Příklad 13.3: Generování hranic: dotaz := select * from ( select pol. PORADOVE_CISLO_BODU,pb. SOURADNICE_Y,pb. SOURADNICE_X, pol. PARAMETRY_ SPOJENI from i_prefix _spojeni_b_poloh pol join i_prefix _souradnice_pb pb on pol. bp_id =pb. bp_id where pol. HP_id =:1 ) order by poradove_ cislo_ bodu ; OPEN cii FOR dotaz USING v_ hranice_ id ; loop FETCH cii INTO v_poradi, v_souradnice_y, v_souradnice_x, v_spojeni ; EXIT WHEN cii % NOTFOUND ; IF v_ poradi =1 THEN linie_par_spojeni := SUBSTR ( v_spojeni, 1, 11) ; END IF; Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 153

166 Kapitola 13. Obnova operátu (Námitkové řízení) IF v_spojeni = 11 THEN linie_par_spojeni :=11; ELSIF v_spojeni = 16 THEN info (3) :=2; ELSIF v_ spojeni = 15 or length ( v_ spojeni ) >3 THEN linie_ typ_ objektu :=2003; END IF; souradnice. extend (); souradnice ( souradnice. last ):= v_souradnice_y ; souradnice. extend (); souradnice ( souradnice. last ):= v_souradnice_x ; end loop ; close cii ; Obrázek 13.3 reprezentuje náhled na jeden projekt obnovy operátu v programu Oracle SQLDeveloper s rozšířením Georaptor pro zobrazení geometrických dat. Z obrázku je zřejmé, že budovy a parcely jsou zde reprezentovány jako pouhé body a jedinými neliniovými prvky jsou zde hranice parcel a vnitřní kresba parcel v podobě dalších prvků mapy. Obrázek je ochuzen o zobrazení značek parcel, protože ty v daném měřítku splývají s bodovou reprezentací parcely v podobě definičního bodu. Obrázek 13.3: Ukázka obnovy operátu. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 154

167 Kapitola 14. Systémy a práce pracující s daty PUB-DB Kapitola 14 Systémy a práce pracující s daty PUB-DB 14.1 Nahlížení do KN Systém nového Nahlížení do KN je bezesporu nejdůležitější aplikace pracující s daty PUB-DB. Použitím PUB-DB jako zdroje vektorových geometrických dat (Souboru Geodetických Informací - SGI) došlo k výraznému snížení rozdílů v aktuálnosti SPI (Souboru Popisných Informací) a SGI na cca dvě hodiny. Což je oproti původním až čtrnácti dním velký pokrok. Dále zde došlo k výraznému zvýšení kvality při zobrazování vektorových dat. Je to dáno mechanismy a algoritmy, kterými aktualizovaný software firmy GEOVAP pracuje s různými zdroji vektorových dat. Další výhodou PUB-DB je možnost zvýrazňovat hledané budovy a parcely a nově pak možnost zobrazení průběhu obnovy operátu. To, co bohužel současný grafický klient Nahlížení do KN neumožňuje, je vyhledávání parcel a budov přímo v grafickém klientu. Není to ale dáno ani omezením PUB-DB ani možnostmi software firmy GEOVAP. Důvodem je rozhodnutí managementu ČÚZK tuto funkcionalitu neposkytovat. Osobně si myslím, že je to škoda, protože tímto rozhodnutím grafického klienta plně podřizuje vyhledávání přes formuláře Nahlížení do KN, které jsou pro někoho nepřehledné. A při hlubším pohledu, tak výrazně dochází k omezení možného další vývoj dané aplikace. Porovnání obou verzí (původní/letité a nové, ještě s neodstraněnou funkcí vyhledávání) Nahlížení do KN je na obrázku Metadata Geoportálu ČÚZK V rámci direktivy INSPIRE se publikují metadata k jednotlivým tématům (k jejich datovým sadám) a INSPIRE službám, která tato data poskytují. Výsledná metadata mají být přístupná nejenom přes INSPIRE vyhledávací službu (INSPIRE Discovery service), ale i přes tzv. geoportál 1, ať již samotného poskytovatele dat, tak i Národní geoportál. Pub- 1 Slovo geoportál je tvořeno slovy geo (lat. země) a portál (z lat. slova porta = brána), název má v uživateli vyvolat představu, že zde je to správné místo pro přístup k mapovým produktům. Z historického hlediska nelze nevzpomenout staršího brášku v podobě slovního spojení web portál, který zažil největší rozkvět v druhé polovině devadesátých letech v období tzv. Dot-com bubliny (dot-com bubble). Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 155

168 Kapitola 14. Systémy a práce pracující s daty PUB-DB Obrázek 14.1: Původní a nové (svrchní) Nahlížení do KN likační databáze je jedním ze zdrojů metadatových elementů (nikoliv hotových metadatových souborů) pro INSPIRE vyhledávací službu a zprostředkovaně i Geoportál ČÚZK (Obrázek 14.2), který s danou službou pracuje. Tvorbou a aktualizací všech metadat na ČÚZK se zabývá ETL (extract-transform-load) software firmy ESRI (Obrázek 14.3). Tento ETL software funguje jinak pro INSPIRE data SCD (Katastrální parcely, v budoucnosti pak i Adresy a Administrativní jednotky) a data Zeměměřického úřadu (ZABAGED, Geonames,...). Pro data INSPIRE tématu Katastrálních parcel je v úložišti ETL uložena šablona metadat (včetně metadatového profilu ČÚZK). ETL software pak kontroluje stav tabulky PUB_METADATA ve schématu PUBL v publikační databázi. Pokud dojde ke změně, ETL řešení vezme metadatové elementy měněných k.ú. z PUB-DB a spolu s metadaty ze systému Metadata o k.ú. je vyplní do již zmíněné šablony metadat Katastrálních parcel. Výsledná metadata pak dále distribuuje. Tedy PUB-DB slouží jako generátor událostí, které vedou k novému vytvoření metadat o příslušném k.ú. (datové sadě). Nutné je poznamenat, že systém Metadata o k.ú. je pouze stavový systém, který na požádání poskytne aktuální XML metadata ČÚZK k zadanému katastrálnímu území. Tento systém tedy nelze použít pro generování událostí o změně metadat. Jak již jsem zde zmínil, PUB-DB též slouží jako zdroj některých elementů. Těmito elementy jsou pouze volitelná metadata specifická pro jednotlivá témata (metadata z oblasti kvality dat). Způsob, jakým ETL software pracuje s metadaty Zeměměřického úřadu (ZÚ), se liší od dat SCD právě v nemožnosti automatické aktualizace. Pro data je v tzv. Metadatovém editoru vytvořen profil dané datové sady a specifikován zdroj datových sad. ETL software na vyžádání vygeneruje všechna metadata příslušných datových sad. Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 156

169 Kapitola 14. Systémy a práce pracující s daty PUB-DB Obrázek 14.2: Ukázka vyhledávání na novém Geoportálu ČÚZK Obrázek 14.3: Zdroje metadat ČÚZK 14.3 Generování INSPIRE GML Zatímco o implementaci INSPIRE služby stahování dat s přímým přístupem již bylo principiálně rozhodnuto, u implementace INSPIRE služby stahování celých datových sad zůstává mnoho nevyjasněného. V současné době je tato služba navrhována tak, že bude uživateli poskytovat data přímo z databáze (Varianta 1 na Obrázku 14.4). Toto řešení je krajně nevýhodné z hlediska požadavků na zatížení publikační databáze (PUB-DB). Daleko lepší variantou (Varianta 2) je ukládat výsledná GML v datovém skladu mimo databázi a uživatelům data poskytovat odsud. Tato varianta se dá řešit několika způsoby. Ať již pomocí služby dotazující se do PUB-DB na GML změněných k.ú. nebo procedurou uvnitř PUB-DB, která bude GML data zapisovat do souborového systému. Třetí Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 157

170 Kapitola 14. Systémy a práce pracující s daty PUB-DB variantou je generování GML souborů mimo PUB-DB přímo ze souborů WKB geometrie při jejich vytváření. Výhodou tohoto řešení by byla skutečnost, že by celé řešení bylo na jednom místě a do značné míry nezávislé na PUB-DB. Z pohledu administrace by stačilo provádět pravidelné zálohy WKB souborů (Varianta 2 by vyžadovala navíc zálohu INSPIRE GML souborů), protože v případě, že by se s PUB-DB cokoliv stalo, by bylo možné provést jen rychlou obnovu WKB souborů a veškeré služby poskytovat z nich. Na druhou stranu je velkou nevýhodou této varianty právě řešení firmy GEOVAP, kdy implementace druhé varianty je do značné míry snadná a může být i levná. Naproti tomu třetí varianta vyžaduje implementaci aplikačních schémat ze strany GEOVAPu. Je dobré zmínit, že GEOVAP v současnosti neumí a ani v současné generaci produktů nebude umět pracovat s aplikačními schématy GML na úrovni konfigurace systému (tzv. parametrická podpora aplikačních schémat, která se většinou řeší vhodnou XSL-T transformací na úrovni aplikační logiky). Namísto toho je nutné na zakázku podporu konkrétního GML aplikačního schématu programově do systému dopsat. Tato disertační práce si neklade za cíl vytvořit řešení na úrovni první nebo druhé varianty, protože pokud by takové řešení mělo být plnohodnotné, muselo by především spolehlivě pracovat s předpokládaným objemem dat a požadovanou dostupností služeb. Kdy pro zajištění výše uvedeného, v rozměrech ČÚZK, bude zapotřebí především manažerské podpory (a z ní plynoucí podpory na straně systémů a jejich administrace), kterou v současnosti a nejspíše i v příštím roce INSPIRE služba stahování celých datových sad mít nebude. Obrázek 14.4: Volby implementace služby stahování celých datových sad 14.4 Export dat PUB-DB do SHP: Diplomová práce Ing. Kateřina Šmídová Diplomová práce (Zdroj: [29]) Ing. Kateřiny Šmídové je minimálně z historického pohledu výjimečná tím, že tato práce vznikala v samotném průběhu vytváření publikační databáze (PUB-DB). Autorka se tak musela do značné míry vyrovnat a pracovat s databází, která Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 158

171 Kapitola 14. Systémy a práce pracující s daty PUB-DB jí rostla takříkajíc pod rukama. Protože mnohé vlastnosti PUB-DB byly měněny podle aktuálních zkušeností s daty obsaženými v ISKN. Stejným bouřlivým vývojem v té době procházela i dokumentace k PUB-DB. Ke cti autorky se tento vývojový zmatek nijak negativně nepodepsal na její práci. První částí této diplomové práce bylo napsat program, který dokáže exportovat data jednoho katastrálního území z PUB-DB do výkresu ve formátu ESRI Shapefile (SHP). Druhou částí pak bylo napsat opačný program pro export dat z formátu Shapefile do prostorové databáze, která podporuje standard geometrie Wellknown text (WKT). Jako ukázková databáze byla v této diplomové práci použita databáze SpatialLite, což je klon databáze SQLLite rozšířený o práci s prostorovými daty. Výsledné databázové schéma v nově vytvořené databázi nemělo kopírovat strukturu PUB-DB, ale mělo umožnit přirozené 2 uložení prostorových prvků a informací. Ukázka GUI aplikace a vytvořeného k.ú je na obrázku Jako další ukázka použití PUB-DB bude popisován export do formátu Microstation DGN, který má oproti Shapefile velkou tradici a podporu v resortu. Je nutné zmínit, že tento software vytvořený v rámci diplomové práce představuje do značné míry vyšší ligu, protože přenáší veškeré informace PUB-DB tedy včetně podpory přenositelné databáze (dle standardu xbase) pro atributy. Obrázek 14.5: Ukázka exportu dat PUB-DB do formátu ESRI Shapefile 14.5 Export katastrálních hranic z PUB-DB do DGN: Bc. Jiří Novák Jak již bylo řešeno v průběhu této disertační práce, v minulosti obsahovala celá katastrální území body se špatnou třídou přesnosti. S příchodem INSPIRE a nového Nahlížení do KN na ČÚZK převládla myšlenka, že bude vhodné umožnit široké veřejnosti pracovat i s tzv. dvoubarevnou mapou. Tedy s mapou, kde budou stejně jako v INSPIRE hranice parcel rozděleny do tříd přesnosti, navíc však příslušnost linie k této třídě se projeví 2 Databáze PUB-DB naproti tomu pracuje i s tzv. uživatelsky definovanou geometrií, kdy je význam této geometrie potřeba začlenit do software, který s daty PUB-DB pracuje Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 159

172 Kapitola 14. Systémy a práce pracující s daty PUB-DB v barvě této linie. Z tohoto důvodu je potřeba, aby všechna katastrální pracoviště, která ještě neopravila chyby v kódech kvality svých bodů, tak učinila. Pro vizuální kontrolu pak mělo sloužit těmto Katastrálním pracovištím právě nově testované Nahlížení do KN. Mnohá pracoviště si však stěžovala na ergonomii práce (zejména malý rozměr grafického prohlížeče Nahlížení do KN) a především skutečnost, že by mnozí zaměstnanci katastrálních pracovišť upřednostnili práci s off-line souborem (nejlépe DGN) doplněným o některé další atributy, jako jsou kódy kvality výměry bodů a výměr. Pro danou úlohu by bylo možné použít program vytvořený v diplomové práci Ing. Kateřiny Šmídové. Bylo by ale nutné řešit konverzi mezi formáty Shapefile a DGN v.7. Proto byl vytvořen nový program v prostředí Bentley Microstation 8i (přesněji v produktu Bentley Map spojeném s Microstation 8i). Autorem tohoto programu (skriptu) je Bc. Jiří Novák, který pro řešení tohoto problému využil programovacího jazyka Visual Basic. Řešení pomocí programovacího jazyka Visual Basic je jen jedním z možných prostředí, kdy toto prostředí je vhodné pro vývoj malých skriptů, u nichž se nepožaduje vysoký výkon. Přestože výsledný skript není v žádném případě nenáročný, protože vyžaduje pro svůj běh řády dnů (export DKM/KMD na celém digitalizovaném území údajně trvá 14 dní), je dle mého názoru vybrané řešení správné, protože většina zabraného času zde představuje práce s databází a souborovou cache. Tedy implementace v nativním prostředí (v současnosti firma Bentley prosazuje řešení postavené na prostředí.net) by nepřinesla výrazné zrychlení. Navíc tomuto zvolenému řešení nelze bezesporu upřít jistou eleganci, která spočívá ve snadnosti změn a vede k zamyšlení, zda by v rámci ČÚZK nemohly být i méně známé produkty firmy Bentley používány, když už ČÚZK v rámci svého partnerství s Bentley smí využívat od této firmy takřka cokoliv. Ukázka výsledného exportu je na obrázku 14.6, ukázka hlavní programové logiky je pak v příkladu Jméno Bc. Jiřího Nováka je s PUB-DB spojeno mnohem více. Kupříkladu tento programátor vytváří a aplikuje sadu kontrol na nově vznikajících hranicích katastrálních území a výsledné topologicky čisté obálky pak ukládá do PUB-DB. O jisté genialitě nebo chcete-li minimálně odvaze tohoto autora svědčí i skutečnost, že přestože systém těchto kontrol by byl bezesporu naprosto výjimečným tématem diplomové práce (s mírným přeháněním, lze říci, že o dostatečně přesných a topologicky čistých hranicí katastrálních území, které jsou dnes vytvářeny, sní již několikátá generace geodetů), tak autor se raději ve své nadcházející diplomové práci bude věnovat svému vlastnímu projektu 3. Příklad 14.1: Kód programu Start Benley Mapu na pozadi =========================== WScript. Echo (" Startuji Bentley Map na pozadi.") Set mymsappcon = CreateObject (" MicroStationDGN. ApplicationObjectConnector " ) Set mymsapp = mymsappcon. Application mymsapp. Visible = True Kopie seedfile a otevreni vykresu WScript. Echo (" Export : " & outputfile ) mymsapp. CopyDesignFile seedfile, outputfile, True 3 Projekt QGama, URL: < Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 160

173 Kapitola 14. Systémy a práce pracující s daty PUB-DB Set DesignFile = mymsapp. OpenDesignFile ( outputfile, False ) WScript. sleep 2000 WScript. Echo (" Pripojuji se k databazi Oracle.") mymsapp. CadInputQueue. SendKeyin " gdi open name = oracle " Zkraceno mymsapp. CadInputQueue. SendKeyin " gdi import storage = oracle feature = jino_mapa_ku_hranice level ="" Level 51"" color =2 weight =0 style =0 where ="" presnost =1""" mymsapp. CadInputQueue. SendKeyin " gdi import storage = oracle feature = jino_mapa_ku_hranice level ="" Level 52"" color =3 weight =0 style =0 where ="" presnost =2""" Zkraceno nastaveni stylu mymsapp. CadInputQueue. SendKeyin " VBA LOAD " & currentdir & "\ mapy_ ku. mvba " mymsapp. CadInputQueue. SendKeyin " VBA RUN [ mapy_ ku ] NastavStyl " mymsapp. CadInputQueue. SendKeyin " vba unload mapy_ ku " mymsapp. CadInputQueue. SendKeyin " gdi import storage = oracle feature = jino_mapa_ku_kodkvbod pba =""[ ZPMZ_CISLO_ZPMZ ]"" level ="" Level 56"" color =0 weight =0 style =0 textstyle ="" popisky """ mymsapp. CadInputQueue. SendKeyin " gdi close name = oracle " zvetseni popisku mymsapp. CadInputQueue. SendKeyin " VBA LOAD " & currentdir & "\ mapy_ ku. mvba " mymsapp. CadInputQueue. SendKeyin " VBA RUN [ mapy_ ku ] ZvetsiPopisky " mymsapp. CadInputQueue. SendKeyin " vba unload mapy_ ku " Obrázek 14.6: Export z PUB-DB do formátu Microstation DGN v.7 Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 161

174 Kapitola 14. Systémy a práce pracující s daty PUB-DB 14.6 Kontroly dalších prvků map: Bakalářská práce Bc. Adéla Volfová Jak již bylo zmíněno v kapitole 12, jedním z výjimečných počinů v oblasti katastru nemovitostí a kvality dat (Data Quality), který byl v posledních letech publikován, je bakalářská práce Bc. Adély Volfové, která se zaměřila na hledání chyb v oblasti místního a pomístního názvosloví v katastrální mapě. Autorka během své práce též využívala publikační databázi, o níž se též zmiňuje [30, strana 27]: Většinu kontrol jsem prováděla v databázi ISKN. Některé však vyžadovaly práci s topologií a v tomto případě jsem využila publikační databázi, kde je geometrie uložena efektivnějším způsobem, jak je popsáno v předešlé, teoretické, části této práce. V případech, kdy bylo vhodné použít publikační databázi, ale obor jejích dat nestačil pro danou kontrolu, bylo nutné tyto dvě databáze propojit. Z výše uvedeného by se mohlo zdát, že publikační databáze nedokáže vyřešit všechny kontroly. Je nutné si uvědomit, že autorka pod pojmem databáze ISKN myslí schéma ISKN v publikační databázi a publikační databází pak schéma PUBL v PUB-DB. Následně pak s tvrzením nelze nesouhlasit. Publikační databáze (schéma PUBL) nevznikla jako plnohodnotná kopie (pouze v jiném formátu) všech dat v ISKN, ale jako její vhodné doplnění. Autorka se ve své práci zabývá různými chybami v názvosloví, ať již se jedná o topologické, typografické nebo pouhý nesoulad s předpisy. Pro nás je však zajímavá chyba špatného kódu katastrálního území u jednotlivých prvků, která může mít dopad na publikaci dat novým Nahlížením do KN. Proto na tomto místě si s laskavým svolením autorky dovolím uvést, jí objevený příklad (Obrázek 14.7), do jakého rozměru může daná chyba narůst. Obrázek 14.7: Umístění dalších prvků mapy mimo hranici k.ú. (Zdroj: [30, strana 60]) Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 162

175 Kapitola 14. Systémy a práce pracující s daty PUB-DB 14.7 Vektorizace masek rastrů KN: Diplomová práce Bc. David Legner Bc. David Legner se ve své připravované diplomové práci zabývá problematikou vektorizace masek digitálních rastrových map katastru nemovitostí a jejich následného ukládání do struktur publikační databáze. Z publikační databáze (PUB-DB) tato data budou distribuována do Geoportálu ČÚZK, stejně jako jsou dnes distribuována INSPIRE metadata. V geoportálu budou tato data sloužit především k přehledu území s analogovou a digitální mapou a s tím spojeného přehledu kladu platných (aktivních) rastrů. Tedy bude se jednat o plně zautomatizovanou obdobu části funkčnosti aplikace ArchivWeb, kde jsou ale platné rastry udržovány ručně, tedy dochází zde k chybám. O využití masek rastrů v PUB- DB dosud nebylo rozhodnuto, ale jejich využití je možné k určení prvků orientační mapy (POM), u nichž se má vypnout zobrazení při přeskenování příslušné analogové mapy. Tedy díky maskám v PUB-DB by mohl mít každý POM přidělen jednoznačně rastr (analogovou mapu), nad kterou se zobrazuje. Z pohledu samotného zpracování souborů masek je nejprve nutné převést soubory masek na formát Tagged Image File Format (TIFF) nebo do jiného formátu, se kterým je schopen pracovat software Grass GIS (Geographic Resources Analysis Support System). V software Grass GIS je následně tento rastr zpracován pomocí neinteraktivního skriptu. Při tomto zpracování je nejprve rastr načten, dále pak vektorizován (pouze jeho bílá část, která reprezentuje masku) a následně generalizován. Dále je pak soubor polygonů transformován do systému S-JTSK. Poté následuje odstranění malých polygonů a případné složení všech zbylých polygonů do jednoho regionu. Tomuto regionu/polygonu jsou následně přiřazeny atributy (opsaný obdélník v obrazových a geodetických souřadnicích). Takto vytvořená geometrie masky je pak načtena do publikační databáze. V současné době se též testuje postup, kdy je generalizace prováděna přímo v prostředí Oracle Spatial. Při tomto postupu je ale krok odstranění malých polygonů stále přenechán na software Grass GIS, pouze je tento krok přesunut před generalizaci. Na příkladu 14.2 je ukázka části programového kódu (skriptu) pro Grass GIS a na obrázku 14.8 jsou pak zobrazeny výsledné masky v publikační databázi. Na tomto obrázku jsou tyto masky (aktivní část) zobrazeny oranžovou barvou. Zelené území představuje zamaskovanou část rastru (část kde se rastr/analogová mapa nezobrazuje). Dále je na obrázku patrné území, kde již není ani na části mapového listu analogová mapa. Ukázka je provedena v software MaruskaDesigner firmy GEOVAP, který slouží pro návrh mapových a publikačních vrstev a je přímo napojen na publikační databázi. Příklad 14.2: Kód programu - příprava transformace # vytvoreni transformacni tabulky echo " Ziskavam rozsah rastru " echo " Ziskavam rozsah rastru " >> $LOG_ FILE echo " ====================== " >> $LOG_FILE r. info -g map = $NAME >$RANGE cat $RANGE >> $LOG_ FILE 2 >&1 NN=$( cat $RANGE awk -F= { print $2} head -n1 tail -n1) SS=$( cat $RANGE awk -F= { print $2} head -n2 tail -n1) Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 163

176 Kapitola 14. Systémy a práce pracující s daty PUB-DB EE=$( cat $RANGE awk -F= { print $2} head -n3 tail -n1) WW=$( cat $RANGE awk -F= { print $2} head -n4 tail -n1) X1=$( cat $ROH head -n1 awk { print $1 } ) Y1=$( cat $ROH head -n1 awk { print $2 } ) X2=$( cat $ROH head -n1 awk { print $3 } ) Y2=$( cat $ROH head -n1 awk { print $4 } ) RESX = $( cat $ROH head - n2 tail - n1 awk { print $3 } ) RESY = $( cat $ROH head - n2 tail - n1 awk { print $4 } ) PIXAREA = $( echo " $RESX * $RESY " bc ) TOL = $( echo " $TOL_ PIXCOUNT * $PIXAREA " bc ) echo $WW $NN - $Y2 - $X1 > $TRAN echo $EE $NN - $Y1 - $X1 >> $TRAN echo $EE $SS - $Y1 - $X2 >> $TRAN echo $WW $SS - $Y2 - $X2 >> $TRAN Obrázek 14.8: Vektorizace masek rastrů Jiří Bartoš: Geodata a metadata ISKN v prostředí INSPIRE 164