Globální architektura RÚIAN

Veřejná zakázka “Registr územní identifikace, adres a nemovitostí – implementace řešení“ je zadávána v rámci řešení projektu „Vybudování Registru územní identifikace, adres a nemovitostí a modernizace Informačního systému katastru nemovitostí ČÚZK„, který je spolufinancován Evropskou unií v rámci Evropského fondu pro regionální rozvoj a Integrovaného operačního programu.

Zadávací dokumentace – Příloha č. 1b

Globální architektura RÚIAN Verze: 1.0

Strana 1/111

Projekt „Vybudování Registru územní identifikace, adres a nemovitostí a modernizace Informačního systému katastru nemovitostí ČÚZK„ je spolufinancován Evropskou unií v rámci Evropského fondu pro regionální rozvoj a Integrovaného operačního programu.

Obsah: 1.

Vymezení cílů dokumentu .............................................................................................. 4

2.

Pojmy a zkratky............................................................................................................... 5

3.

Procesní architektura ....................................................................................................13 3.1.

Upřesnění struktury dokumentu: ...........................................................................13

3.2.

Postup tvorby a použité metodiky .........................................................................13

3.3.

Základní východiska a cíle .....................................................................................14

3.4.

Přehled procesů ......................................................................................................17

3.5.

Procesy iniciované správcem ISUI.........................................................................19

3.6.

Procesy iniciované Obcí .........................................................................................24

3.7.

Procesy iniciované Stavebním úřadem .................................................................28

3.8.

Procesy iniciované ČUZK .......................................................................................30

3.9.

Procesy iniciované externím uživatelem ...............................................................32

3.10.

Procesy iniciované ČSÚ .........................................................................................38

3.11.

Speciální případy procesů ......................................................................................39

4.

Funkční dekompozice ...................................................................................................42 4.1.

Návrh struktury dokumentu ...................................................................................42

4.2.


4.3.


4.4.

První úroveň funkční hierarchie - Kontextové schéma ........................................44

4.5.

Druhá úroveň funkční hierarchie – Funkční bloky ................................................50

5.

Datová architektura .......................................................................................................65 5.1.

Struktura dokumentu ..............................................................................................65

5.2.


5.3.


5.4.

Globální datová architektura ..................................................................................67

Strana 2/111


5.5. 6.

Konceptuální datový model jádra RUIAN ..............................................................78 Základní rámec technologické architektury.................................................................82

6.1.


6.2.


6.3.

Globální technologická architektura ......................................................................82

7.

Katalog služeb ...............................................................................................................89 7.1.


7.2.


7.3.

Obecné vlastnosti služeb .......................................................................................92

7.4.

Přehled služeb .........................................................................................................92

8.

Postup naplnění systému daty .....................................................................................95 8.1.

Návrh struktury dokumentu: ..................................................................................95

8.2.


8.3.

Popis současného stavu ........................................................................................97

8.4.

Stanovení pravidel a metrik ..................................................................................102

8.5.

Datová analýza migrace ........................................................................................106

8.6.

Využití systému reklamací pro čištění dat ...........................................................107

8.7.

Návrh postupu naplnění a zprovoznění systému................................................107

Strana 3/111


1. Vymezení cílů dokumentu Cílem dokumentu je vytvořit koncepci architektury systému a pro jednotlivé dokumenty, které budou výstupem detailní analýzy, stanovit výchozí předpoklady a základ řešení.

Strana 4/111


2. Pojmy a zkratky Vzhledem k tomu, že v dokumentu se vyskytuje řada zkratek a odborných pojmů (např. technologických), uvádíme v následující tabulce výčet a vysvětlení používaných zkratek a některých pojmů. Zkratka nebo pojem

Vysvětlení

Actor

Aktér, aktivní účastník událostí

Agenda

Souhrn činností spočívajících ve výkonu vymezeného okruhu vzájemně souvisejících aktivit v rámci působnosti Orgánu veřejné moci definované zákonem o základních registrech.

AIS

Agendový informační systém. Informační systém veřejné správy, který slouží k výkonu Agendy. V dokumentu se AIS často doplňuje o svoji roli v dané situaci viz Editační AIS a Přistupující AIS.

Autentizační údaje

Údaje umožňující provést ověření identity fyzické osoby; tyto údaje jsou vedeny v rozsahu stanoveném zákonem o základních registrech upravujícím vedení příslušného Základního registru.

Business Case

Obchodní případ

Cluster

Seskupení volně vázaných počítačů obvykle propojených počítačovou sítí, které spolu úzce spolupracují, takže navenek mohou pracovat jako jeden počítač. Jsou nasazovány pro zvýšení výpočetní rychlosti nebo spolehlivosti.

ČP

Česká pošta

ČR

Česká republika

ČSÚ

Český statistický úřad

Strana 5/111


Zkratka nebo pojem

Vysvětlení

ČÚZK

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

DA

Detailní architektura – sada dokumentů, které budou vycházet z dokumentu GA a zpodrobňovat jeho obsah.

DB

Databáze

DKM

Digitální katastrální mapa

DMVS

Digitální mapa veřejné správy

DNS

Domain Name Server - překlad doménových jmen na IP adresy.

DWDM

Dense wavelength division multiplexing. Technologie přenosu dat po optickém vlákně

Editační AIS

Agendový informační systém, který je zdrojem dat pro základní registry.

Editor

Orgán veřejné moci, který je podle zákona o základních registrech upravujícího vedení příslušného Základního registru oprávněn zapisovat Referenční údaje do Základního registru a provádět změny zapsaných Referenčních údajů. Odpovídá za to, že zapsané Referenční údaje jsou v souladu s údaji uvedenými v dokumentech, na jejichž základě jsou údaje do příslušného Základního registru zapsány.

eGON

eGovernment. Elektronizace Veřejné správy sledující zefektivnění fungování státní správy a místní samosprávy a zjednodušení výkonu Služeb Veřejné správy.

GA

Globální architektura – tento dokument

GP

Geometrický plán

GUI

Graphic user interface. Grafické rozhraní pro komunikaci uživatele se systémem.

Strana 6/111


Zkratka nebo pojem HW

Vysvětlení Hardware - fyzicky existující technické vybavení počítačů (na rozdíl od dat a programů, které se označují jako software).

IOP

Integrovaný operační program.

IS

Informační systém.

ISEO-ADR

Informační systém evidence obyvatel.

ISKN

Informační systém katastru nemovitostí.

ISUI

Informační systém územní identifikace.

ISVS

Informační systémy veřejné správy.

ISZR

Informační systém základních registrů.

IT

Informační technologie.

KIVS

Komunikační infrastruktura veřejné správy. Jednotná komunikační infrastruktura pro elektronické úřadování. Je to bezpečné místo propojení mezi veřejností a Veřejnou správou. Zabezpečuje propojení sítí a systémů do společného prostředí.

Kód agendy

Veřejný identifikátor, který je jednoznačně přiřazen záznamu o Agendě v Číselníku agend v Základním registru práv a povinností.

LAN

Local area network. Místní počítačová síť.

LAU

Local Administrative Units neboli místní správní jednotka. Označuje úroveň územní státní správy, která je níže než provincie, kraje a podobné velké správní jednotky. Doplňuje statistickou soustavu NUTS.

Load Balancing

Vyvažování zátěže - technika pro rozložení zatížení mezi dva nebo více počítačů, síťových linek, procesorů, pevných disků

Strana 7/111


Zkratka nebo pojem

Vysvětlení nebo jiných zařízení, aby bylo dosaženo optimálního využití, prostupnosti nebo času odezvy.

MPSV

Ministerstvo práce a sociálních věcí.

MV

Ministerstvo vnitra.

NZ,

Editorem zadaný požadavek na vytvoření, změnu, nebo zrušení

Návrh změny

jednoho, nebo více Prvků, který tvoří společně editovanou, kontrolovanou, schvalovanou a zplatňovanou transakci.

NTP

Protokol pro synchronizaci vnitřních hodin počítačů po paketové síti s proměnným zpožděním. Zajišťuje, aby všechny počítače v síti měly stejný a přesný čas.

NUTS

Nomenclature des Unites Territoriales Statistique neboli Nomenklatura územních statistických jednotek. Zkratka pro normalizovanou klasifikaci územních celků v České republice pro potřeby statistického úřadu a Eurostatu.

Odvozený lokalizační

takový lokalizační údaj územního prvku, který je odvozen z

údaj

podřízených územních prvků.

Orgán veřejné moci

Státní orgán, územní samosprávný celek a fyzická nebo

(správy)

právnická osoba, byla-li svěřena působnost v oblasti Veřejné správy.

PKI

Public Key Infrastructure – prostředí, které umožňuje ochranu informačních systémů, elektronických transakcí a komunikace. Zahrnuje veškerý software, technologie a služby, které umožňují využití šifrování s veřejným a privátním klíčem.

Portál veřejné správy

Informační systém vytvořený a provozovaný se záměrem usnadnit veřejnosti vzdálený přístup k potřebným informacím z Veřejné správy a komunikaci s ní.

Strana 8/111


Zkratka nebo pojem Prvek

Vysvětlení Instance Územního prvku nebo Územně evidenční jednotky ve smyslu jejich definice v zákonu o základních registrech. Prvky lze též rozlišit na ty, jejichž vznik, nebo změna jejich údajů má evidenční význam (v dokumentu se o nich hovoří jako o prvcích evidenčního charakteru) a dále prvky, jejichž vznik nebo změna jejich údajů má konstitutivní význam (v dokumentu se o nich hovoří jako o prvcích konstitutivního charakteru)

Přistupující AIS

AIS - Agendový informační systém v roli systému žádajícího data ze základních registrů

Referenční údaj

Údaj vedený v Základním registru, který zákon o základních registrech jako Referenční údaj označuje.

Referenční vazby

Kódy nebo identifikátory, kterými je odkazováno na Referenční údaje v Základních registrech.

ROB

Základní registr obyvatel. Vede údaje vztahující se ke státním občanům České republiky, k cizincům s povolením k pobytu na území České republiky a k cizincům, kterým byla na území České republiky udělena mezinárodní ochrana formou azylu nebo doplňkové ochrany, nebo k jiným fyzickým osobám.

ROS

Základní registr osob. Vede údaje vztahující se k právnickým osobám, podnikajícím fyzickým osobám a k Orgánům veřejné moci.

RPP

Základní registr práv a povinností. Vede údaje o působnosti Orgánů veřejné moci, a to včetně údajů o oprávněních přístupu k datům vedených v Základních registrech a seznamu názvů Agend a jejich číselných kódů; údaje o právech a povinnostech fyzických a právnických osob a právech a povinnostech k věcem, pokud jsou údaje o těchto osobách a věcech vedeny v Základních

Strana 9/111


Zkratka nebo pojem

Vysvětlení registrech, a to včetně údajů o pravomocných rozhodnutích Orgánů veřejné moci.

RSO

Registr sčítacích obvodů

RUIAN

Registr územní identifikace, adres a nemovitostí

Schvalovatel

Role uživatele ISUI, který schvaluje návrh změny. Tuto roli mohou zastávat uživatelé všech agend s pravomocí schvalovat návrhy změny své agendy v rámci své lokální působnosti.

SAN

Storage Area Network – samostatná síť, používaná pouze pro přenos dat mezi paměťovými úložnými prostory a servery, které tato data používají. Moderní technologie plně umožňující oddělení datových částí IS od serverových a vzájemně nezávislou možnost změn.

SOA

Service Oriented Architecture – vícevrstvá architektura zaměřená na služby.

SP

Studie proveditelnosti.

TI

Technologická infrastruktura.

UDDI

Universal Description Discovery and Integration – univerzální adresář obsahující seznam a popis dostupných webových služeb. Systém, jehož prostřednictvím lze definovat a posléze vyhledávat nabízené služby a jejich vlastnosti.

UIR-ADR

Územně identifikační registr adres.

UML

Grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů nabízející standardní způsob zápisu modelů užívaných pro návrhů informačních systémů.

Strana 10/111


Zkratka nebo pojem

Vysvětlení

Use Case

Případ užití

Veřejná správa

Souhrn činností resp. služeb poskytovaných organizacemi státní správy, územní samosprávy a dalšími veřejnoprávními institucemi.

VLAN

Virtual Local Area Networks – virtuální lokální síť

VPN

Virtuální privátní síť (Virtual Private Network) realizovaná na KIVS.

VS

Veřejná správa.

VÚSC

Vyšší územní samosprávný celek ustanovený zákonem 347/1997 Sb., o vytvoření vyšších územních samosprávných celků.

WAN

Wide Area Network – rozsáhlá (vzdálená) síť

WEB

Služba sítě Internet – systém serverů podporujících dokumenty ve speciálním formátu (HTML), propojení mezi těmito dokumenty a další služby (např. grafické, audio a video soubory).

WSDL

Web Services Description Language – XML popis webové služby (jaké funkce nabízí a jakým způsobem s ní komunikovat).

XML

eXtensible Markup Language – značkovací jazyk určený pro přenos strukturovaných dat standardizovaný konsorciem W3C.

XSD

XML Schema Definition. Schéma, které popisuje strukturu XML dokumentu.

XSLT

Extensible Style Language Transformation – jazyk použitý ve stylech XSL pro transformaci XML dokumentů na jiné XML dokumenty (např. HTML).

Zadavatel

Role uživatele ISUI, který vytváří návrh změny. Tuto roli mohou zastávat uživatelé všech agend avšak s rozdílnou pravomocí

Strana 11/111


Zkratka nebo pojem

Vysvětlení k jednotlivým prvkům a v rámci své lokální působnosti.

Základní registr, ZR

Informační systém veřejné správy, který obsahuje Referenční údaje.

Zákon o základních

Zákon č. 111/2009 Sb., o základních registrech.

registrech

Strana 12/111


3. Procesní architektura Kapitola obsahuje popis základních procesů, které jsou vykonávány v souvislosti s provozem registru RUIAN a jeho zdrojových agendových systémů ISUI a ISKN. Nejsou zde popsány procesy prvotního naplnění ISUI a RUIAN, protože této problematice je věnována samostatná kapitola.

3.1.

Struktura dokumentu:

Dokument obsahuje tyto body •

Přehled procesů

•

Pro každý proces kapitolu s následující strukturou

•

Diagram procesu

•

Popis procesu

3.2.

Postup tvorby a použité metodiky

Ke grafickému znázornění procesů bude použita syntaxi Value Added Chain. V této notaci je každý proces popsán jednou či více událostmi, které ho iniciují, řetězcem aktivit, které vykonává osoba či systém, a koncovým stavem, kterého je po proběhnutí procesu dosaženo. Metodika Value Added Chain je jednoduchá a dostatečně názorná pro popis procesů na „business“ úrovni. U procesů na této úrovni většinou není zvykem popisovat chybové větve procesu a ošetření chybových stavů. Bude-li však v průběhu analýzy potřeba detailně popsat některou složitější část zpracování, navrhujeme použít tzv. activity diagramů podle metodiky UML veze 2.0. Příklad diagram procesu (syntaxe Value Added Chain):

Spouštěcí událost

Krok1

Nepoviný krok2

Krok3

Konec

Strana 13/111


Popis procesu Cíl procesu:

Stručný popis cíle procesu jednou, dvěma větami.

Aktéři:

Role uživatelů (tj. editoři, schvalovatelé, administrátoři...).

Dotčené IS:

Systémy, které proces podpoří.

Spouštěcí událost:

Událost, která je podnětem ke spuštění procesu. Může být externí – mimo systém, nebo interní - na základě nějaké změny v systému.

Popis kroků

Popis činností, které se při provádění procesu

procesu:

odehrávají. Činnosti mohou probíhat mimo organizaci či uvnitř, mimo systém či uvnitř systému, mohou být manuální nebo automaticky prováděné. Je-li to účelné, jsou popsány i alternativní sledy činností, které mohou nastat.

Poznámky:

Ostatní důležité informace vztažené k procesu. Například předpoklady pro jeho spuštění nebo nutné podmínky, které musí být splněny, aby mohl být proces spuštěn.

3.3.

Základní východiska a cíle

3.3.1. Východiska Činnosti vykonávané při zápisu údajů do RUIAN a jeho správě jsou distribuované mezi mnoho orgánů veřejné moci. To je důvodem, proč je účelné popsat procesy spojené s provozem registru RUIAN a jeho zdrojových agendových systémů a výsledný procesní model využít jako východisko pro návrh funkcí. Dále jsou popsaná základní východiska vycházející ze zákona o základních registrech.

Strana 14/111


•

Orgány veřejné moci získávají údaje vedené v základním registru nebo je do něj zapisují výhradně prostřednictvím agendového informačního systému; jeho přístup k údajům je zajišťován službou informačního systému základních registrů.

•

•

Návrh zákona o základních registrech definuje tyto editory: •

Správce RUIAN prostřednictvím ISKN

•

Správce RUIAN prostřednictvím ISUI

•

Stavební úřady

•

Obce

•

Český statistický úřad

Působnosti výše definovaných editorů detailně definují § 40 - 45 zákona o základních registrech.

•

Editoři mohou zapisovat referenční údaje do základního registru prostřednictvím agendového informačního systému.

•

Editor je zodpovědný za to, že údaje jím zapsané do základních registrů jsou v souladu s dokumenty, které jsou podkladem pro zápis do základního registru.

•

V případě pochybností označí editor údaj v základním registru za „nesprávný“.

•

Orgán veřejné moci, který není editorem údaje zapisovaného do základního registru a zjistí nesoulad s údajem evidovaným v základním registru, informuje o tom editora.

•

Český statistický úřad, obce a stavební úřady mohou údaje stanovené tímto zákonem zapisovat do informačního systému územní identifikace prostřednictvím informačních systémů sloužících k plnění jejich úkolů §39 odstavec 5 zákona o základních registrech.

3.3.2. Cíle Cílem procesní architektury je poskytnout zadavateli zpětnou vazbu formou strukturovaného popisu problematiky, která bude v cílové podobě podpořena dodanými systémy. Procesní architektura se tak stává východiskem k návrhu Funkční hierarchie systému ISUI, RUIAN a úprav systému ISKN.

Strana 15/111


Součástí Procesní architektury jsou i stavové diagramy dvou základních entit: Návrhu změny a Prvku (viz definice v následující kapitole).

Strana 16/111


3.4.

Přehled procesů

V následující tabulce je uveden přehled základních procesů spojených s provozem registru RUIAN a souvisejících AIS. V dalších kapitolách je pro každý proces uveden diagram a jeho popis. Pozn.: Nejsou popisovány procesy pomocné (související například s administrací systémů). Kód procesu

Název procesu

Procesy iniciované správcem ISUI P01

Editace identifikačních, vazebních, a doplňkových údajů Prvků správcem ISUI

P02

Zplatnění údajů Prvku (přenos do RUIAN)

P03

Převzetí a zpracování zvláštních údajů pro doručování prostřednictvím poštovních služeb

Procesy iniciované Obcí P10

Editace Ulice Obcí v ISUI

P11

Editace Adresního místa Obcí v ISUI

P12

Změna příslušnosti Stavebního objektu

Procesy iniciované Stavebním úřadem P20

Editace Stavebního objektu Stavebním úřadem v ISUI

Procesy iniciované Katastrálním úřadem P30

Editace údajů/prvku katastru nemovitostí Katastrálním úřadem v ISKN

Procesy iniciované externím uživatelem (uživatelé přistupujících AIS) P40

Reklamace údajů uvedených v RUIAN

Strana 17/111


Kód procesu

Název procesu

P41

Požadavek AIS na zaslání změnových záznamů k zadanému datu

P42

Požadavek AIS na poskytnutí údaje konkrétního Prvku

P43

Požadavek AIS na vyhledání Prvku podle zadaných údajů

Procesy iniciované ČSÚ P50

Editace údajů Základní sídelní jednotky ČSU

Speciální případy procesů V této části jsou popsány speciální případy procesů, které v sobě obsahují více výše uvedených „generických“ procesů. Důvodem jejich popisu je shoda na postupech složitějších případů, které mohou vyžadovat koordinaci činnosti mezi více subjekty. S01

Editace Stavebního objektu v ISKN i ISUI (budov, které jsou zapisovány do katastru a které podléhají stavebnímu oznámení nebo stavebnímu povolení)

S02

Editace Stavebního objektu v ISKN i ISUI (budov, které nejsou zapisovány do katastru ale podléhají stavebnímu oznámení nebo stavebnímu povolení (Bude doplněn v DA)

S03

Editace Stavebního objektu v ISKN i ISUI (budov, které jsou zapisovány do katastru ale nepodléhají stavebnímu oznámení nebo stavebnímu povolení. (Bude doplněn v DA)

Pozn.: V průběhu DA může dojít k doplnění nově identifikovaného procesu.

Strana 18/111


Procesy iniciované správcem ISUI

3.4.1. P01 - Editace identifikačních, vazebních, lokalizačních a doplňkových údajů Prvků správcem ISUI 3.4.1.1.

Diagram procesu:

Sdělení Ministerstv a vnitra

Sdělení Kanceláře posl. sněmovny

P01.1 Editace Prvků

Sdělení obce

Sdělení hlavního města Prahy

P01.2 Kontrola konzistence údajů

P01.3 Změna odvoz. lokalizačních údajů

P01.4 Schválení Návrhu změny

Schválená změna objektů

P01.5 Editace lokalizačních údajů

Sdělení statutárníh o města

3.4.1.2. Cíl procesu

Popis procesu.:

Zadání, změna nebo zrušení Identifikačních, vazebních či doplňkových údajů nebo primárních lokalizačních údajů Prvků ve správě Správce registru územní identifikace do ISUI. Výstupem procesu je Editorem zadaná a systémem i Schvalovatelem schválená změna údajů, připravená pro předání do RUIAN. Tento proces se týká Prvků: ČR, Region soudržnosti, VÚSC, Kraj, Okres, ORP, POU, Obec, Správní obvod, Městský obvod, Městská část, Část obce

Aktéři:

Správce registru územní identifikace v roli editora (dále jen Editor) Správce registru územní identifikace v roli schvalovatele (dále jen Schvalovatel)

Dotčené IS:

ISUI

Strana 19/111


Spouštěcí

Sdělení Ministerstva vnitra, Kanceláře poslanecké sněmovny, obce,

událost:

hlavního města Prahy, statutárního města o novém Prvku nebo změně jeho údajů.

Popis kroků

P01.1 Editor vytvoří nový Návrh změny, ve kterém zadá:

procesu:

Údaje o rozhodnutí, na základě kterého se Návrh změny připravuje, identifikační či doplňkové údaje nových nebo změněných prvků a vazeb na ostatní Prvky. V případě, že editor zjistí, že podklady pro tvorbu NZ jsou neúplné, nebo chybné, poznamená tuto informaci do NZ a jeho zpracování NZ přeruší do doby jejich doplnění. Pozn.: všechny změny provedené při Editaci jsou dále kontrolovány, schvalovány a zplatňovány společně v rámci Návrhu změny. P01.2 Editor spustí pro Návrh změny kontrolu konzistence Prvků. Systém provede kontrolu správnosti vyplnění a konzistence s ostatními Prvky podle pravidel konzistence definovaných pro editované Prvky. V případě, že kontrola skončí úspěšně, předá editor změnu ke schválení. P01.3 Systém analyzuje nadřízené Prvky, určí ty, kterých se případně dotýká změna hranic, a aktualizuje lokalizační údaje nadřízených Prvků. Tyto Prvky jsou zahrnuty do Návrhu změny. P01.4 Schvalovatel Návrh změny zkontroluje a následně schválí nebo odmítne. Pozn.: Tento krok je odkazován i v jiných procesech. Vždy však platí, že krok schválení vykonávají aktéři uvedení v daném procesu podle pravidla agendy, která změnu navrhuje, ji též schvaluje. V případě odmítnutí změny se proces vrací do kroku P 01.1 Editace Prvků jako rozpracovaný. P01.5 Je-li potřeba editovat primární lokalizační údaje Prvků, pak Editor v grafickém prostředí editace map u daného Prvku zadá/změní lokalizační údaje. Pozn.: tento krok se týká pouze: zadání/změny lokalizačních údajů Městské části, čáry Ulice, nebo bodu Části obce.

Strana 20/111


Poznámky:

Procesní krok P01.4 Schválení Návrhu změny je použit v několika následujících procesech. Protože je z hlediska vykonávaných činností všude stejný, je v následujících procesech pouze odkazován.

3.4.2. P02 - Zplatnění údajů Prvků a jejich publikace do RUIAN 3.4.2.1. Schválení Návrhu změny Schvalovatelem

P02.1 Kontrola konzistence

Začátek platnosti změny u Prvků evidenčního charakteru

P02.2 Zplatněn změn

P02.3 Předání změn do RUIAN

P02.5 Vrácení návrhu k editaci


Diagram procesu:

P02.4 Předání údajů o Stavebním objektu do ISKN

Zplatněný Návrh změny v RUIAN

Návrh je vrácen k editaci

Popis procesu

Předání změn Prvků obsažených v Návrhu změny do RUIAN v okamžiku jejich zplatnění.

Aktéři:

Správce registru územní identifikace v roli schvalovatele (dále jen Schvalovatel). Systém ISUI. Systém ISKN.

Dotčené IS:

ISUI, ISKN, ISZR, RUIAN, RPP

Spouštěcí

Schválení návrhu změny Schvalovatelem.

událost:

Začátek platnosti změny u Prvků, jejichž vznik nebo změna má evidenční význam.

Popis kroků

P02.1 Systém ISUI provede kontrolu konzistence všech Prvků ve

Strana 21/111


procesu:

schváleném Návrhu změny. V případě, že kontrola konzistence dopadla dobře, pokračuje se P02.2 jinak P02.5. P02.2 Návrh změny je zplatněn, to znamená, že navržené změny Prvků v Návrhu změny jsou systémem znovu zkontrolovány a v případě úspěšné kontroly převedeny do platného stavu Zplatněný a Návrh změny se zařadí do fronty výstupního rozhraní ISUI na RUIAN. V případě neúspěchu při kontrole jde proces na krok 2.05. P02.3 Návrh změny je prostřednictvím služeb systému ISZR odeslán do RUIAN. V RUIAN jsou opraveny existující záznamy Prvků, zapsány nové či označeny jako zrušené. Současně s daty pro RUIAN jsou v případě změny referenčního údaje do registru práv a povinností (RPP) odeslány údaje o rozhodnutí, na základě kterého byly v RUIAN učiněny změny. P02.4 V případě, že v Návrhu změny je založen, opraven nebo zrušen Stavební objekt, který je v ISKN zaveden jako budova, je zaslána zpráva do ISKN. P02.5 Návrh změny je vrácen do editace a Editor Návrhu změny je upozorněn o potřebě Návrh upravit.

Poznámky:

Celý proces zápisu Návrhu změny do RUIAN je realizován jako transakce, tj. buď je celý realizován pro všechny obsažené změny Prvků, nebo je celý odvolán. Detaily řízení této transakce včetně průchodu systémem ISZR a řešení případných chybových stavů nejsou na úrovni tohoto modelu řešeny.

Strana 22/111


3.4.3. P03 – Převzetí a zpracování zvláštních údajů pro doručování prostřednictvím poštovních služeb 3.4.3.1.

Diagram procesu:

P03.1 Kontrola podkladů

Převzení podkladů

P60.2 Vytvoření Návrhu změny v ISUI

P03.3 Kontrola konzistence údajů v ISUI

Vrácení chybných podkladů



Schválený návrh změny

Vrácení chybové zprávy

Popis procesu:

Změna údajů zvláštních údajů pro doručování prostřednictvím poštovních služeb na základě podkladů dodaných držitelem poštovní licence. Jde o údaje o: Adresní poště Vazbě Adresního místa na Adresní poštu

Aktéři:

Správce registru územní identifikace v roli editora (dále jen Editor) Správce registru územní identifikace v roli schvalovatele (dále jen Schvalovatel)

Dotčené IS:

ISUI

Spouštěcí

Dodání podkladů pro změnu zvláštních údajů pro doručování

událost:

prostřednictvím poštovních služeb od držitele poštovní licence.

Popis kroků

P03.1 Editor převezme podklady a zkontroluje, zda jsou v

procesu:

dohodnuté formě a struktuře. Jestliže nejsou v pořádku, vrátí je držiteli poštovní licence. P03.2 Editor prostřednictvím funkce ISUI nahraje podklady do systému ISUI, kde je na jejich základě vytvořen Návrh změny. Ten

Strana 23/111


obsahuje založení změnu, nebo zrušení adresní pošty, nebo založení, nebo změnu vazby adresních míst na adresní poštu. P03.3 Systém ISUI provede kontrolu konzistence Návrhu změny a sestaví soubor s odpovědí s uvedením chyb a varování. P03.4 V případě, že zpráva obsahuje chyby, editor je vyexportuje a v dohodnuté formě odešle zpět držiteli poštovní licence a Návrh změny ukončí, jinak pokračuje krokem schválení. Alternativa: Editor zpracování vrátí do editace a po dohodě s držitelem poštovní licence Návrh změny opraví a znovu spustí kontrolu konzistence. P01.4 viz popis v procesu P01

Poznámky:

Podmínkou je aby pošta používala identifikátory Adresních pošt a Adresních míst užívané v RUIAN.

3.5.

Procesy iniciované Obcí

3.5.1. P10 - Editace Ulice Obcí v ISUI 3.5.1.1.

Diagram procesu:

P10.1 Editace Ulice a vazby na obec

Rozhodnu tí obce

3.5.1.2. Cíl procesu:

P10.2 Kontrola konzistence ulice


Navržená změna ulice

Popis procesu:

Změna údajů Ulice a vazeb ulice na Obec Obecním úřadem, úřadem

Strana 24/111


městyse, úřadem města nebo magistrátem. Aktéři:

Obec v roli editora (dále jen Editor) Obec v roli schvalovatele (dále jen Schvalovatel)

Dotčené IS:

ISUI, RPP, ISZR.

Spouštěcí

Rozhodnutí obce.

událost: Popis kroků

P10.1 Editor zadá v rámci Návrhu změny údaje o rozhodnutí, na

procesu:

základě kterého se Návrh změny připravuje, novou Ulici nebo vyhledá existující ulici a vyplní/změní příslušné údaje. Může editovat údaje pouze ulice, která je součástí jeho vlastní obce. P10.2 Editor spustí kontrolu konzistence Prvků. Systém analyzuje nadřízené a podřízené Prvky a vrátí případné nekonzistence a varování. Příklady kontrol: při zániku ulice nesmí ulice obsahovat existující adresy. Při změně nesmí vzniknout ulice se stejným názvem v rámci obce apod.

Poznámky:

Předpoklad: Obec bude moci předat Ulici do působnosti jiné obce, nebude moci ulici sama převzít z jiné obce. Tím se vyřeší změny vazeb v případě sloučení či rozdělení obcí.

Strana 25/111


3.5.2. P11 - Editace adresního místa Obcí v ISUI 3.5.2.1.

Diagram procesu:

P11.1 Editace Adresního místa

Dodatečné přidělení/změna čísla orientačního.


P11.2 Editace definičního bodu



Schválená změna Adresního místa

Popis procesu:

Změna údajů Adresního místa Obecním úřadem, úřadem městyse, úřadem města nebo magistrátem.

Aktéři:

Obec v roli editora (dále jen Editor) Obec v roli schvalovatele (dále jen Schvalovatel)

Dotčené IS:

ISUI, RPP, ISZR

Spouštěcí

Dodatečné přidělení či změna adresního místa tj.:

událost:

-

vznik adresního místa (bez souvislosti s kolaudačním souhlasem, či ohlášením Stavebního objektu stavebnímu úřadu)

-

dodatečné přidělení/změna/ zrušení čísla orientačního,

-

přiřazení adresního místa do ulice,

-

vynětí adresního místa z ulice,

-

přesun adresního místa do jiné ulice,

-

zánik adresního místa,

-

přesun adresního místa do jiného objektu (např. při sloučení či rozdělení objektů).

Strana 26/111


Popis kroků


procesu:

základě kterého se Návrh změny připravuje, nové adresní místo nebo vyhledá existující adresní místo a vyplní/změní příslušné údaje. Může editovat údaje pouze adresního místa, které je součástí jeho vlastní obce. P11.2 Je-li potřeba editovat definiční bod Adresního místa, pak Editor v prostředí editace map u Adresního místa změní definiční bod. P11.3 Editor spustí kontrolu konzistence prvků. Systém analyzuje nadřízené prvky a vrátí případné nekonzistence a varování. P01.4 viz popis v procesu P01

Poznámky:

Obec před zápisem údajů zjistí údaje určující polohu definičního bodu stavebního objektu a adresního místa.

3.5.3. P12 – Změna příslušnosti Stavebního objektu k Části obce nebo Městské části Obcí v ISUI 3.5.3.1.

P12.1 Editace vazby stavebního objektu

změna příslušnosti k části obce, městské části


Diagram procesu:


P01.4 Schválení změn objektu

Schválená změna příslušnosti St. Objektu

Popis procesu

Změna vazby Stavebního objektu na Část obce nebo Městskou část Obecním úřadem, úřadem městyse, úřadem města nebo magistrátem

Aktéři:

Obec v roli editora (dále jen Editor). Obec v roli schvalovatele (dále jen Schvalovatel).

Strana 27/111


Dotčené IS:

ISUI, ISZR, RPP

Spouštěcí

Změna stavebního objektu: změna příslušnosti k části obce,

událost:

městské části.

Popis kroků


procesu:

základě kterého se Návrh změny připravuje, vyhledá jeden nebo více Stavebních objektů (v mapě, zadáním části nebo celé adresy) a změní vazbu na Část obce. P12.2 Editor spustí kontrolu konzistence Prvků. Systém analyzuje nadřízené Prvky a vrátí případné nekonzistence a varování. V případě, že kontrola projde bez chyb, předá Editor záznamy ke kontrole Schvalovateli. P01.4 viz popis v procesu P01.

Poznámky:

Předpoklad: Obec bude moci předat Stavební objekt do působnosti jiné obce, nebude moci objekt sama převzít z jiné obce. Tím se vyřeší změny vazeb v případě slučování či rozdělení obcí.

3.6.

Procesy iniciované Stavebním úřadem

3.6.1. P20 - Editace Stavebního objektu Stavebním úřadem v ISUI 3.6.1.1.

Udělení kolaudačníh o souhlasu

Oznámení o dokončení stavby

Diagram procesu:

P20.1 Editace Stavebního objektu včetně vazeb

P20.2 Zadání adresních míst

P20.3 Zadání definičních bodů


P01.4 Schválení změn objektu

Schválená změna Stavebníh o objektu

Strana 28/111



Popis procesu

Zadání nebo změna identifikačních, vazebních, doplňkových údajů a definičního bodu Stavebního objektu Stavebním úřadem v ISUI včetně případného zápisu Adresního místa.

Aktéři:

Stavební úřad v roli editora (dále jen Editor). Stavební úřad v roli schvalovatele (dále jen Schvalovatel).

Dotčené IS:

ISUI, ISZR, RPP

Spouštěcí

Udělení kolaudačního souhlasu.

událost:

Zpracování oznámení o užívání stavby.

Popis kroků


procesu:

základě kterého se Návrh změny připravuje. Vyhledá parcelu, na které je stavební objekt umístěn, a ověří údaje o parcele a případně o budově evidované v ISKN. Naváže na ně zakládaný Stavební objekt a vyplní identifikační údaje a vazby na Prvky Část obce, případně Městská část, a zadá technickoekonomické atributy. Varianta kroku: V případě změny údajů Editor vyhledá Stavební objekt a provede změnu jeho údajů. P20.2 V případě, že současně vzniká jedno nebo více adresních míst, pak editor založí adresní místa, vyplní jejich identifikační údaje a případně vazbu na Prvek Ulice. P20.3 Editor si zobrazí výřez mapy v okolí Stavebního objektu a zadá do ní pozici definičního bodu Stavebního objektu a Adresních míst, nebo zplatní pozice bodů již uvedených v potvrzeném geometrickém plánu. P20.4 Editor spustí kontrolu konzistence Prvků. Systém provede kontrolu správnosti vyplnění a konzistence s ostatními Prvky podle pravidel konzistence definovaných pro Stavební objekt a Adresní bod. V případě, že kontrola skončí úspěšně, předá editor změnu ke

Strana 29/111


schválení. P01.4 viz popis v procesu P01

Poznámky:

Procesy iniciované ČUZK

3.7.

3.7.1. P30 - Editace prvku katastru nemovitostí Katastrálním úřadem v ISKN 3.7.1.1.

Příchod listiny na KP

Diagram procesu:

P30.1 Editace návrhu změny

P30.2 Kontrola návrhu změny

P30.3 Zplatnění návrhu změny

P30.4 Kontrola dopadů

P30.5 Předání změn do RUIAN P30.7 Předání údajů do ISUI


Popis procesu

Vytvoření, zrušení nebo změna údajů o prvcích, které jsou předmětem evidence v katastru nemovitostí. Zde je popsán případ, kdy je součástí návrhu změny některý z prvků, které jsou evidovány v RUIAN. Jedná se o tyto prvky:

Aktéři:

-

Parcela.

-

Katastrální území.

-

Budova (v RUIAN evidovaná jako Stavební objekt).

Katastrální pracoviště v roli editora (dále jen Editor).

Strana 30/111

Zplatněný návrh změny ISKN


Katastrální pracoviště v roli schvalovatele (dále jen Schvalovatel). Dotčené IS:

ISKN, ISZR, RUIAN, (ISUI), RPP.

Spouštěcí

Příchod listiny, která může být podkladem k zápisu do katastru

událost:

nemovitostí. V případech, kdy to vyžaduje příslušný právní předpis, je k listině přiložen geometrický plán (GP).

Popis kroků

P30.1 Editor v rámci Editace návrhu změny zapíše všechny změny,

procesu:

které vyplývají z listiny. Varianta kroku: Pokud je k listině přiložen GP, Editor převezme návrh změny připravený v GP a dále ho upraví podle listiny. P30.2 V rámci kontroly Návrhu změny budou kromě dosavadních kontrol ISKN provedeny kontroly souladu s RUIAN. Případné nesoulady budou oznámeny ve formě varování (např. existence Stavebního objektu evidovaného na parcele, na které není v KN evidována budova). P30.3 Vlastní krok zplatnění proběhne stejně jako v současném ISKN, pouze na něj bude v rámci existující transakce navazovat další krok. P30.4 Bude provedena kontrola, zda mají provedené změny přímý či nepřímý dopad do RUIAN. Budou identifikovány změny, které mají přímý dopad (změna prvku, který je editován prostřednictvím ISKN) a změny, které mají nepřímý dopad (změna prvku, která by mohla prostřednictvím ISUI vyvolat změnu v RUIAN). P30.5 Nalezené změny údajů, které jsou editovány prostřednictvím ISKN, se odešlou do RUIAN, který do ISKN vrátí potvrzení o úspěšném zápisu a číslo transakce, pod kterou byly změny do RUIAN zapsány. Současně s daty pro RUIAN jsou v případě změny referenčních údajů do registru práv a povinností (RPP) odeslány údaje o rozhodnutí, na základě kterého byly v RUIAN učiněny změny

Strana 31/111


(tj. o příslušné listině uvedené v řízení). P30.7 V případě, že v návrhu byly identifikovány změny, které by mohly vyvolat změny v ISUI, jsou tyto změny odeslány do ISUI (např. změna hranice katastrálního území, která je zároveň hranicí obce).

Poznámky:

3.8.

Procesy iniciované externím uživatelem

3.8.1. P40 - Reklamace údajů v RUIAN 3.8.1.1.

Diagram procesu:

P40.1 Zapsání do systému reklamací

Zjištění chyby

P40.2 Zaslání upozornění editorovi

P40.3 Posouzení reklamace editorem

P40.5 Schválení reklamace, oprava dat

Kladně vyřízená reklamace

P40.6 Zamítnutí reklamace

3.8.1.2.

Zamítnutá reklamace

Popis procesu

Cíl procesu

Zadávání a vyřizování reklamací údajů v RUIAN.

Aktéři:

Zadavatel reklamace (uživatel AIS) – dále jen Zadavatel. Editor reklamovaného údaje - dále jen Editor.

Dotčené IS:

AIS zadavatele reklamace, ISUI, ISKN, RUIAN, RPP, ISZR.

Spouštěcí

Zjištění chyby v RUIAN.


P40.1 Zadavatel zapíše zjištěnou chybu prostřednictvím služby

procesu:

registrované v ISZR volané z jeho AIS. Systém ISZR odešle reklamaci do ISUI nebo ISKN podle typu prvku.

Strana 32/111


Pozn.: Další zpracování je popsáno shodně pro systém ISKN i ISUI (dále v tomto procesu jen Systém). P40.2 Systém vyhodnotí, kterého Editora (Editorů) se reklamace týká, a pošle jim upozornění. (volitelný krok) P40.3 Editor vyhodnotí oprávněnost reklamace a označí ji jako oprávněnou nebo neoprávněnou. P40.4 Pokud Editor vyhodnotí reklamaci jako oprávněnou a je reklamován referenční údaj, Systém odešle do RUIAN označení reklamovaného údaje jako nesprávný. P40.5 Pokud Editor vyhodnotil reklamaci jako oprávněnou, Editor standardními prostředky (viz jiné procesy) provede opravu reklamovaného údaje. Přitom se v Návrhu změny odkáže na příslušnou reklamaci. Po zápisu správného údaje do RUIAN Systém označí reklamaci za vyřízenou a volitelně zašle zadavateli vyrozumění. P40.6 Pokud Editor vyhodnotí reklamaci jako neoprávněnou, zamítne ji s příslušným vysvětlením. Systém volitelně zašle zadavateli vyrozumění. Poznámky:

Při zadání reklamace je třeba vždy uvést, jaké jsou správné údaje, není možná reklamace ve tvaru „název ulice je chybný“ bez udání správného tvaru. Předpokládáme, že záznam o reklamaci bude obsahovat: -

identifikaci AIS,

-

identifikaci autora záznamu,

-

identifikace Prvku,

-

ID (při reklamaci chybných údajů),

-

identifikační údaje (při reklamaci chybějícího prvku),

Strana 33/111


-

správné hodnoty údajů

-

odůvodnění reklamace,

Tento proces bude potřeba koordinovat s navrhovateli systémů ISZR a ostatních registrů, tak aby byl pro všechny registry shodný.

3.8.2. P41 - Požadavek přistupujícího AIS na zaslání změnových záznamů k zadanému datu 3.8.2.1. Požadavek na zaslání změn

Diagram procesu:

P41.1 Sestavení požadavku v AIS

P41.2 Odeslání požadavku

P41.3a Vytvoření souboru s identifikátory změněných záznamů

P41.4 Odeslání dat žadateli

P41.5 Přijetí dat žadatelem

P41.3b Vytvoření souboru s kompletními změnovými daty

3.8.2.2.

Popis procesu

Cíl procesu

Poskytnutí změn v RUIAN za dané období.

Aktéři:

Žadatel. Systém RUIAN.

Dotčené IS:

AIS žadatele, ISZR, RUIAN, RPP.

Spouštěcí

Požadavek na zaslání změnových záznamů.


P41.1 AIS sestaví požadavek na zaslání dat.

procesu:

P41.2 Požadavek je odeslán do RUIAN prostřednictvím služby ISZR. P41.3a Pokud uživatel požadoval zaslání pouze identifikátorů prvků změněných od určitého data, vytvoří se v RUIAN soubor pouze z identifikátorů.

Strana 34/111

Vyřízený požadavek


Pozn.: Pokud bude uživatel požadovat zaslání kompletních dat pro některé prvky, může to učinit následně pro každý prvek samostatně (viz proces P42). P41.3b Pokud uživatel požadoval zaslání kompletních dat, vytvoří se soubor obsahující kompletní údaje o změněných prvcích. P41.4 Soubor vytvořený v předcházejícím kroku je odeslán žadateli. P41.5 Žadatel přijme soubor s požadovanými změnovými údaji. Poznámky:

Bude umožněno poskytovat změny pouze pro omezenou množinu atributů Prvku.

3.8.3. P42 - Požadavek přistupujícího AIS na poskytnutí údajů konkrétního Prvku 3.8.3.1. Požadavek na údaj RUIAN

P42.1 Kontrola nutnosti dotazu do RUIAN

Diagram procesu: P42.2 Dotaz do lokálních dat AIS

P42.3 Sestavení požadavku AIS

3.8.3.2.

P42.4 Odeslání požadavku do RUIAN

P42.5 Zpracování požadavku


P42.7 Přijetí dat žadatelem


Popis procesu

Cíl procesu

Poskytnutí údajů o Prvku zadaném svým identifikátorem.

Aktéři:

Uživatel přistupujícího AIS v roli žadatele (dále jen Žadatel).

Dotčené IS:

Přistupující AIS, ISZR, RUIAN,RPP

Spouštěcí

Požadavek na zaslání údajů o prvku.

událost:

Strana 35/111


Popis kroků

P42.1 Přistupující AIS zkontroluje, zda je nutné dotazovat se na

procesu:

údaj do RUIAN. P42.2

Není-li nutný dotaz do RUIAN, provede

se dotaz do lokální kopie dat RUIAN nebo dat přistupujícího AIS. P42.3 Je-li nutný dotaz do RUIAN, AIS sestaví požadavek na poskytnutí údajů konkrétního Prvku. P42.4 Požadavek je odeslán do RUIAN prostřednictvím ISZR. P42.5 Je vytvořen soubor s údaji o daném prvku. P42.6 Soubor vytvořený v předcházejícím kroku je odeslán žadateli. P42.7 Žadatel přijme soubor s údaji o daném prvku. Poznámky:

Předpokládáme, že bude možné požadovat poskytnutí pouze daného prvku nebo i příslušných nadřízených prvků.

3.8.4. P43 - Požadavek přistupujícího AIS na vyhledání Prvků podle zadaných údajů 3.8.4.1. Požadavek na zaslání údajů

Diagram procesu:

P43.1 Sestavení požadavku v AIS


P43.2 Odeslání požadavku do RUIAN

P43.3 Zpracování požadavku


P43.5 Přijetí dat v AIS žadatelem


Popis procesu

Poskytnutí údajů o všech prvcích daného typu podle zadaných parametrů. Používá se v okamžiku, kdy přistupující AIS není schopen získat odpověď z lokálně uložených údajů, nebo si nevede lokálně uložená data RUIAN.

Aktéři:

Žadatel. Systém RUIAN

Strana 36/111


Dotčené IS:

Přistupující AIS , ISZR, RUIAN, RPP

Spouštěcí

Požadavek na zaslání údajů o prvcích.


P43.1 Přistupující AIS sestaví požadavek na poskytnutí údajů o

procesu:

Prvcích podle zadaných parametrů. P43.2 Požadavek je odeslán do RUIAN prostřednictvím ISZR. P43.3 Požadavek je v RUIAN zkontrolován. Pokud je správný, jsou vyhledány všechny prvky daného typu, které vyhovují zadaným parametrům. P43.4 Pokud jsou nalezeny nějaké prvky podle zadaných parametrů a jejich počet nepřekročí daný maximální počet, jsou data odeslána žadateli. Varianta kroku: v případě, že dojde k chybě, je informace o ní zaslána žadateli. Příklady možných chyb: chybná syntaxe požadavku, neexistuje žádný prvek podle zadaných parametrů, počet vyhovujících prvků je vyšší než daný maximální počet, neexistuje zadaný nadřízený prvek atd. P13.5 Žadatel ve svém AIS přijme soubor s požadovanými údaji. Varianta kroku: Žadatel ve svém AIS přijme soubor s informací o chybě.

Poznámky:

Mezi vstupními parametry požadavku může být i seznam údajů, které uživatel požaduje vrátit, včetně identifikačních údajů nadřízených prvků.

Strana 37/111


Procesy iniciované ČSÚ

3.9.

3.9.1. P50 - Editace údajů Základní sídelní jednotky ČSU 3.9.1.1.

Diagram procesu:

P50.1 Editace údajů ZSJ v AIS

Rozhodnutí ČSU

P50.3 Předání Návrhu změny do ISUI

P50.4 Kontrola konzistence údajů v ISUI

P50.5 Předání výsledku kontroly do AIS

P50.6 Schválení Návrhu změny v AIS

Schválená změna ZSJ

P50.2 Editace lokalizačních ůdajů ZSJ


Popis procesu:

Změna nebo vznik identifikačních, vazebních nebo lokalizačních údajů Základní sídelní jednotky zapisovaných Českým statistickým úřadem.

Aktéři:

Český statistický úřad v roli editora (dále jen Editor). Český statistický úřad v roli schvalovatele (dále jen Schvalovatel).

Dotčené IS:

AIS ČSU, ISUI, ISZR, RPP

Spouštěcí

Rozhodnutí Českého statistického úřadu.


P50.1 Editor prostřednictvím svého AIS navrhne vznik nebo změnu

procesu:

identifikačních dat ZSJ. P50.2 Mění–li se hranice ZSJ, pak Editor prostřednictvím svého AIS navrhne změnu lokalizačních dat ZSJ. P50.3 AIS ČSU sestaví Návrh změny ve struktuře vyžadované ISUI a odešle ho do ISUI. P50.4 Systém ISUI provede kontrolu konzistence Návrhu změny a sestaví soubor s odpovědí s uvedením chyb a varování.

Strana 38/111


Příklad kontrol: souhlas hranic ZSJ s hranicí parcel. P50.5 Systém zprávu o kontrole odešle zpět do AIS ČSU. V případě, že zpráva obsahuje chyby, vrací se zpracování do editace, jinak pokračuje krokem schvalování. P50.6 Schvalovatel zkontroluje Návrh změny a případná varování ve zprávě o kontrole v ISUI. V případě odmítnutí i přijetí odešle AIS ČSU zprávu do ISUI. V případě odmítnutí změny se proces v AIS ČSU vrací do editace a v ISUI Návrh změny do stavu Rozpracovaný. V případě schválení se v AIS ČSU proces ukončí a v ISUI se Návrh změny uvede do stavu Schválený. Podmínkou je, aby ČSU užíval identifikátory ZSJ a Katastrálního

Poznámky:

území užívaného v RUIAN.

3.10.

Speciální případy procesů

3.10.1. 3.10.1.1.

S01 - Editace Stavebního objektu v ISKN i ISUI Diagram procesu:

ISKN – Katastrální úřad - Evidence potvrzených geometrických plánů Žádost vlastníka o zápis GP

S01.1 Záznam GP skutečného provedení stavby

V ISKN zaznamená n potvrzený GP

ISUI - Stavební úřad Přijetí ohlášení/ žádosti stav. úřadem

S01.2 Editace St. objektu včetně vazeb

S01.3 Zplatnění údajů St. objektu a jejich publikace do RUIAN

Stavební objekt zapsán do RUIAN z ISUI

ISKN - ČUZK Předloženy doklady o kolaud. souhlasu / ohlášení

S01.4 Zadání budovy do katastru nemovitostí

Doplněny údaje st. objektu do RUIAN z ISKN

Strana 39/111



Popis procesu

Zápis údajů nově dokončené budovy do RUIAN prostřednictvím systémů ISKN a ISUI u budov, které jsou zapisovány do katastru a které podléhají stavebnímu oznámení nebo stavebnímu povolení.

Aktéři:

Katastrální úřad v roli zadavatele GP (dále jen aktualizátor). Stavební úřad v roli zadavatele (dále jen Editor SÚ). Správce registru územní identifikace v roli zadavatele (dále jen Editor ČUZK).

Dotčené IS:

ISKN, ISUI, RUIAN

Spouštěcí

Přijetí oznámení o užívání stavby stavebním úřadem

událost:

Přijetí žádosti o vydání kolaudačního souhlasu stavebním úřadem

Popis kroků

S01.1 Zadavatel GP převezme GP dokončené stavby a zaznamená

procesu:

ho do ISKN do potvrzených GP. Při tom zaznamená: -

hranice budovy,

-

definiční bod budovy,

definiční bod adresních míst (bude ještě předmětem diskuse v DA) Pozn.: uvedené informace jsou od tohoto okamžiku přístupné z ISUI S01.2 Editor SÚ v průběhu kolaudačního řízení vytvoří v ISUI NZ ve kterém založí nový stavební objekt a zadá -

číslo popisné nebo evidenční,

-

vazbu na část obce,

-

vazbu na městskou část (má-li obec městské části),

-

vazbu na číslo stavební parcely (výběrem z údajů z ISKN), v případě, že stavební parcela dosud není v ISKN evidovaná pak výběrem z GP potvrzených GP (pozn.: v tomto případě

Strana 40/111


nebude číslo parcely odesíláno do RUIAN, ale uchováno v ISUI do doby, než bude parcela zaevidována v ISKN).vazbu na budovu (výběrem budovy v potvrzeném GP k dané parcele) - tím získá i definiční bod stavebního objektu, nebo definiční bod zadá, -

typu stavebního objektu,

-

způsobu jeho využití

-

technickoekonomických atributech

-

zadá údaje adresních míst(přitom jejich definiční body vybere z potvrzených GP,nebo je zadá)včetně definičních bodů

NZ je následně schválen a označen ke zplatnění. Pozn.: Tento krok je genericky popsán v procesem P20 S01.3 Na základě podkladů o kolaudačním souhlasu či oznámení o užívání stavby dodaných stavebníkem Katastrální úřad vytvoří v ISKN NZ, ve kterém zadá novou budovu a její údaje. Po schválení a zplatnění NZ se do RUIAN přenesou údaje budovy dané zákonem o základních registrech, které se váží se stavebním objektem. Pozn.: Tento krok je genericky popsán v procesem P30. Poznámky:

Strana 41/111


4. Funkční dekompozice Kapitola popisuje dekompozici funkčnosti analyzovaného řešení až na úroveň elementárních funkcí.

4.1.

Struktura dokumentu

Dokument obsahuje tyto body: •


•

První úroveň funkční hierarchie – Kontextové schéma

•

Druhá úroveň funkční hierarchie – Funkční bloky (bude doplněno v DA)

•

Detailní úroveň funkční hierarchie – Use Case (bude vytvořeno v DA)

4.2.


Na prvních dvou úrovních bude použit hierarchický rozklad navrhovaného řešení a popis jeho systémů a základních funkčních bloků. Na detailní úrovni popisu bude použita metoda Případů užití – Use Case diagramů a popisů jejich scénářů.

4.3.


4.3.1. Východiska Základní požadavky ovlivňující funkční návrh vyplývající ze zadávací dokumentace: •

Orgány veřejné moci získávají údaje z registru území identifikace, adres a nemovitostí (dále RUIAN), nebo do něj zapisují pouze prostřednictvím agendových informačních systémů.

•

Agendové systémy budou k RUIAN přistupovat výhradně prostředním služeb systému základních registrů (ISZR).

•

Údaje evidované v RUIAN budou vedené v aktuální podobě.

Strana 42/111


•

Obsah RUIAN je spravován prostřednictvím editorů agendového informačního systému územní identifikace (dále ISUI) a agendovým informačním systém ISKN. Oba tyto systémy jsou spravovány ČÚZK.

•

Referenční údaje obsažené v RUIAN mohou být označeny za nesprávné editorem nebo jeho prostřednictvím. Tyto údaje pak mají pouze informativní povahu. Otázka způsobu interpretace plomby z ISKN do RUIAN a z toho vyplývající legislativní úprava bude podrobněji diskutována v DA.

•

RUIAN je veřejný seznam. Každý má právo do registru územní identifikace nahlížet a pořizovat výpisy, a to i dálkovým přístupem.

•

Jeho údaje lze též poskytovat za úplatu na nosičích dat.

•

Správce RUIAN zveřejňuje způsobem umožňujícím dálkový přístup •

změny v územně správním členění České republiky,

•

vzájemné vztahy a vazebnost územních prvků a územně evidenčních jednotek a to i v grafické podobě,

•

adresy adresních míst ČR.

Data poskytovaná prostřednictvím dálkového přístupu mají pouze informativní a nikoli referenční charakter. •

Některé údaje budou do systému ISUI zapisovat i jiní editoři než správce RUIAN. Jsou to: Obec, Stavební úřad a Český statistický úřad.

•

V případě, že orgán veřejné moci, který není editorem daného údaje v základním registru, při své činnosti zjistí nesoulad referenčních údajů vedených v základním registru se skutečným stavem, uvědomí o tom neprodleně editora daného referenčního údaje prostřednictvím agendových IS (ISÚI, ISKN) viz P40.

•

V RPP jsou vedeny údaje o rozhodnutích nebo jiných úkonech orgánů veřejné moci včetně veřejnoprávních smluv a opatření obecné povahy (dále jen „rozhodnutí“), na základě nichž dochází ke změně referenčních údajů v některém ze základních registrů.

•

Systém ISUI dosud neexistuje a je nutno jej vytvořit.

•

Systém ISKN je nutno upravit tak, aby byla zajištěna provázanost systémů.

Strana 43/111


•

Systém ISUI musí zachycovat stav údajů k jakémukoli datu od jeho vytvoření.

•

Obce, ČSÚ, a stavební úřady mohou údaje do ISKN a ISUI zapisovat prostřednictvím svých informačních systémů.

•

K ISUI bude možné přistupovat i prostřednictvím webových formulářů.

•

Princip územní příslušnosti vyžaduje rozdělení Editora dle jeho územní působnosti a při editaci údajů RUIAN umožnit editovat uživateli jen ty prvky náležející svým typem a geografickým umístěním do územní působnosti příslušného Editora.

•

Z požadavku na možnost zapisovat do systému ISUI prostřednictvím svých informačních systémů, vyplývá nutnost, vytvořit aplikační rozhraní ISUI, které budou moci tyto systémy využívat.

4.3.2. Cíle dokumentu Cílem dokumentu je: •

na první úrovni popsat navrhované řešení jako celek v kontextu okolních systémů a uživatelů,

•

na druhé úrovni rozdělit řešení na menší komponenty, popsat jejich funkci a případně komunikaci mezi nimi,

•

na detailní úrovni popsat případy užití jednotlivých komponent tak, aby vznikl úplný popis navrhovaného řešení, na jehož základě bude dodavatel systému schopen provést technický návrh a implementaci.

4.4.

První úroveň funkční hierarchie - Kontextové schéma

Funkce první úrovně jsou systémy nebo jejich celky. Pro klasické kontextové schéma platí, že budovaný systém je zobrazen jako jedna komponenta a diagram se zaměřuje na jeho okolí. V tomto případě je cílem vytvořit několik vzájemně spolupracujících systémů, které budou komunikovat prostřednictvím integračního prostředí tvořeného samostatným externím systémem. Z toho důvodu je navrhované řešení rozděleno do několika samostatných celků již v tomto diagramu.

Strana 44/111


4.4.1. Globální architektura základních registrů Systém RUIAN tvoří jednu z komponent architektury základních registrů. Detailní návrh RUIAN a zejména návrh komunikace mezi systémy je třeba vytvářet v kontextu návrhu globální architektury ZR a ISZR. Ta vznikne v definitivní verzi až na základě spolupráce architektů jednotlivých systémů. Protože ale bez představy o globální architektuře nelze navrhovat funkčnost jednotlivých systémů, popisujeme v této kapitole globální architekturu tak, jak si ji v současné chvíli představujeme na základě dosavadních informací. Všechny dále uvedené návrhy ohledně komunikace mezi systémy, vycházejí z této globální architektury.

4.4.2. Diagram schématu RUIAN

ROB

ROS

RPP

ISZR

AIS - ISKN

AIS - ISUI

AIS 1

AIS N

Nová a měněná funkcionalita ISKN

Uživatel ISKN

Interní uživatel Externí uživatel ISUI ISUI

Uživatel AIS

Uživatel AIS

Aplikace pro publikaci dat veřejnosti

Veřejnost

Strana 45/111


4.4.3. Popis funkcí (systémů) první úrovně 4.4.3.1.

ISUI

ISUI je agendový informační systém, ve kterém jsou připravována a spravována data prezentovaná v systému RUIAN, včetně jejich historických i v budoucnu platných verzí. Systém obsahuje funkcionalitu pro podporu práce editorů - interních uživatelů ČÚZK i externích uživatelů (přistupujících prostřednictvím uživatelského rozhraní ISUI nebo svých agendových systémů). Systém podporuje životní cyklus změnové operace, prostřednictvím které uživatelé mění, kontrolují, schvalují a zplatňují změny prvků, jež jsou následně promítány do RUIAN. Systém podporuje životní cyklus reklamace, prostřednictvím které lze opravit nesprávné údaje v RUIAN a informovat původce reklamace. Systém komunikuje s agendovým systémem ISKN tak, aby při tvorbě změn zůstala zachována konzistence s údaji připravovanými a předávanými do RUIAN z ISKN, nebo aby se tyto systémy vzájemně informovaly o nutnosti vyřešení vzniklých nekonzistencí. Systém komunikuje se systémem RUIAN výhradně prostřednictvím služeb systému ISZR. 4.4.3.2.

Nová a měněná funkcionalita ISKN

Agendový systém ISKN bude upraven a doplněn o funkcionalitu potřebnou pro editaci prvků zapisovaných jeho prostřednictvím do RUIAN. Bude vytvořena funkčnost potřebná pro napojení na registr RUIAN prostřednictvím ISZR a pro komunikaci se systémem ISUI pro zajištění konzistence s údaji připravovanými a předávanými do RUIAN z ISUI. 4.4.3.3.

RUIAN

Základní registr územní identifikace, adres a nemovitostí je základním registrem podle zákona o základních registrech a obsahuje aktuální platné údaje o územních prvcích, územně evidenčních jednotkách a doplňkových údajích. Údaje do RUIAN jsou zapisovány prostřednictvím systémů ISUI a ISKN. RUIAN poskytuje informace ostatním agendovým systémům státní správy prostřednictvím systému ISZR.

Strana 46/111


RUIAN poskytuje informace též veřejnosti a to v plném rozsahu v něm uložených informací. 4.4.3.4.


Aplikace pro publikaci dat veřejnosti (dálkový přístup) je samostatná aplikace pracující s daty RUIAN, ISUI a některými daty ISKN. Aplikace veřejnosti neposkytuje referenční data, pouze zprostředkovává k nahlédnutí. Data RUIAN jsou poskytována z lokální kopie databáze RUIAN, kterou si pro tyto účely udržuje. Data poskytovaná z lokální kopie databáze RUIAN nemají referenční charakter. Okolní komponenty Systém

Popis komponenty

AIS - ISKN

Informační systém katastru nemovitostí je agendový systém, který slouží pro podporu výkonu státní správy katastru nemovitostí.

ISZR

Informační systém základních registrů zajišťuje komunikaci mezi jednotlivými základními registry a komunikaci mezi základními registry a agendovými informačními systémy.

ROB

V registru obyvatel jsou vedeny referenční a další údaje o fyzických osobách - občanech České republiky i cizincích v rozsahu dle Zákona o základních registrech.

ROS

Registr osob je centrálním úložištěm referenčních údajů evidovaných o osobách a souvisejících provozních údajích dle Zákona o základních registrech.

RPP

V registru práv a povinností jsou vedeny referenční údaje o působnosti orgánů veřejné moci a referenční údaje o právech a povinnostech osob v rozsahu dle Zákona o základních registrech.

AIS 1 - N

Ostatní agendové systémy státní správy.

Strana 47/111


4.4.3.5.

Okolní aktéři – Uživatelé

Uživatel

Popis uživatele

Interní editor

Uživatel agendového systému ISUI, který k němu přistupuje

ISUI

z prostředí správce systému ISUI – ČÚZK.

Externí editor

Uživatel agendového systému ISUI, který k němu přistupuje

ISUI

z jiného orgánu státní správy či samosprávy buď prostřednictvím svého agendového systému připojeného na ISUI, nebo přímo prostřednictvím webového rozhraní ISUI. Existují následující externí editoři: Obce, Stavební úřady a Český statistický úřad.

Uživatel ISKN

Uživatel agendového systému ISKN, který může editovat informace publikované v systému RUIAN.

Uživatel AIS

Uživatel agendového systému v roli uživatele dat poskytovaných registrem RUIAN prostřednictvím systému ISZR.

Veřejnost

Anonymní uživatel přistupující k RUIAN prostřednictvím Aplikace pro publikaci dat veřejnosti.

4.4.4. Předpoklad funkce systému ISZR ISZR zajišťuje komunikaci AIS se základními registry i vzájemnou komunikaci mezi základními registry. Komunikace s AIS bude probíhat přes vnější komunikační rozhraní, komunikace se základními registry bude probíhat přes vnitřní komunikační rozhraní. Z hlediska RUIAN a souvisejících AIS předpokládáme následující způsob komunikace: 1

AIS zavolá službu ISZR přístupnou na vnějším komunikačním rozhraní, prostřednictvím kterého budou AIS zasílat požadavky na zápis údajů do RUIAN nebo získání údajů z RUIAN.

2

ISZR provede kontrolu oprávnění použití příslušné služby danou Agendou a Agendovou rolí na základě informací v Registru práv a povinností.

Strana 48/111


3

ISZR prostřednictvím vnitřního komunikačního rozhraní zašle požadavky na provedení funkcí do RUIAN.

4

RUIAN provede příslušnou funkci (zápis údajů, výdej údajů) a vrátí zpět ISZR výsledek operace v RUIAN a případně požadované referenční údaje.

5

Výsledkem volání služby pomocí ISZR je vrácení výstupu služby prostřednictvím vnějšího komunikačního rozhraní zpět do AIS.

Pozn.: RUIAN obsahuje některé údaje, na které existují v ROB a ROS referenční vazby. V případě dotazů do ROB a ROS, kdy součástí odpovědi mají být i údaje z RUIAN, zajistí ISZR získání příslušných referenčních údajů dotazem do RUIAN automaticky.

Strana 49/111


4.5.

Druhá úroveň funkční hierarchie – Funkční bloky Ve druhé úrovni jsou tři základní systémy ISUI, ISKN a RUIAN rozloženy na jednotlivé funkční bloky. Funkční bloky jsou tvořeny funkcemi, které mají společné vlastnosti z hlediska jejich účelu.

Strana 50/111

Projekt „Vybudování Registru územní identifikace, adres a nemovitostí a modernizace Informačního systému katastru nemovitostí ČÚZK„ je spolufinancován Evropskou unií v rámci Evropského fondu pro regionální rozvoj a Integrovaného operačního systému. RUIAN Změny dat

GUI pro administrátory RUIAN

Odpovědi z RUIAN Administrativní služby RUIAN

Aplikační logika RUIAN

Interní komunikace mezi ISKN a ISUI

Administrátor RUIAN

Komunikace s aplikací pro publikaci veřejnosti Synchronizace lokální kopie RUIAN

Služby rozhraní RUIAN

ISZR Rozhraní ISZR na základní registry

Aplikační logika ISZR a ORG

Rozhraní ISZR na AIS

AIS - ISKN

AIS - ISUI

Výstupní rozhraní ISKN

Vstupní rozhraní ISKN

Rozšíření a uprava aplikační logiky ISKN

Existující agendy ISKN

Rozhraní na ISUI


Výstupní rozhraní ISUI

Rozhraní na ISKN

Vstupní rozhraní ISUI

Řízení životního cyklu návrhu změny

Rozhraní pro publikaci dat veřejnosti

WMS standard

Systémy poskytující mapové podklady

Služby rozhraní

Řízení životního cyklu reklamace

Administrati vní služby

GUI pro editory a schvalovatele

Webové služby pro editory

GUI pro administrát ory

GUI pro textové i grafické informace

Interní editor/ Externí editor/ schvalovatel schvalovatel

Externí editor/ Schvalovatel V AIS

Administrátor ISUI

Veřejnost

Aplikační logika

Administrati vní služby

Strana 51/111

Dálkový přístup do ISKN


4.5.1. Funkční bloky ISUI Funkční bloky ISUI jsou rozděleny na: -

Bloky aplikační logiky, kvůli které byl systém požadován, tj. hlavně správu dat pro systém RUIAN a reklamační proces.

-

Bloky rozhraní, které zajišťují komunikaci s RUIAN, ISKN, zodpovídání dotazů na historická data z ostatních AIS a z Aplikace pro publikace dat veřejnosti.

-

Bloky grafického rozhraní a webových služeb, které zajišťují komunikaci s interními i externími uživateli ISUI. 4.5.1.1.

Řízení životního cyklu návrhu změny

Obsahuje funkce pro editaci, kontrolu a zplatňování návrhů změn, pomocí kterých bude možné měnit údaje ISUI (a následně i v RUIAN). Tyto funkce budou využívány pro změnu údajů jak uživateli správce registru, tak i externích uživatelů ISUI (ostatních editorů). Řešení je postaveno na základě těchto předpokladů: -

Jeden návrh změny bude připravován vždy jednou agendou a nebude sdílen, či předáván mezi agendami.

-

Návrh změny je po svém schválení zplatněn (jako celek) automaticky ke dni platnosti navržených změn. V případě, že obsahuje údaje evidenčního charakteru, čeká na den platnosti evidenčních údajů. V případě že obsahuje údaje konstitutivního charakteru – je zplatněn ihned po schválení.

-

V návrhu změny nemůže být řešeno více údajů evidenčního charakteru s rozdílnými datumy platnosti.

-

Změny navrhované do budoucnosti v souvislosti se změnou evidenčních údajů může zadávat pouze editor ČÚZK.

-

Případy rozsáhlých změn připravovaných k datumu začátku platnosti prvků evidenčního charakteru a na nich závislých změnách v prvcích konstitutivního charakteru zadává editor ČÚZK na základě podkladů od obcí. (Příkladem takového scénáře je dělení a slučování obcí.)

-

Po dobu, kdy schválený návrh změny (s evidenčními údaji) čeká na zplatnění jsou zamčené všechny v něm měněné prvky. V případě požadavku na změnu některého v něm uvedeného registračního prvku je nutno jej zaslat editorovi tohoto NZ (ČÚZK), který jej předsune před připravovaný NZ a připravovaný NZ s ním uvede do souladu.

Strana 52/111


-

Aby nedocházelo k blokování záznamů a nemožnosti schvalovat a zplatňovat jiné návrhy změn měly by návrhy změn být schvalovány maximálně dny před začátkem právní planosti změny.

Funkční blok obsahuje tyto funkce: •

Založení nového návrhu změny – Funkce založí nový návrh změny, který bude sdružovat všechny provedené změny, které spolu souvisí a které je třeba zplatnit společně. Bude vyžadováno uvedení příslušného rozhodnutí či jiného dokumentu, na základě kterého se změna provádí (pro RPP).

•

Řízení životního cyklu návrhu změny – Funkce umožní potřebné operace s návrhem změny, které mění jeho stav, nebo předávají návrh změny mezi jeho řešiteli.

•

Vyhledání prvků podle zadaných parametrů – Funkce pro vyhledání prvků podle nejrůznějších kriterií pro účely prohlížení údajů, kontroly dat, schvalování změn ap.

•

Editace popisných údajů – Funkce do ISUI vloží novou verzi prvku, tj. založí nový prvek, opraví existující prvek nebo jej zruší.

•

Editace lokalizačních údajů – hranice prvku – Funkce umožňující editovat lokalizační údaje tvořící hranici prvku. Protože tato funkce bude prováděna na speciálním grafickém software, je vyčleněna z editace jako samostatná funkce.

•

Editace lokalizačních údajů - definiční bod prvku – Funkce umožní zadat souřadnice definičního bodu prvku buď zadáním souřadnic, vyznačením bodu na mapě, nebo výběrem existujícího definičního bodu katastrální mapy.

•

Přidělení jednoznačného identifikátoru – Pro prvky, pro které se identifikátory přiřazují v ISUI (ulice, objekt, adresní místo). zajistí funkce při vložení nového prvku vytvoření a přiřazení jednoznačného bezvýznamového identifikátoru.

•

Kontroly – Kontrolní funkce ověřující úplnost a správnost údajů a konzistenci s ostatními údaji ISUI a ISKN. Kontrolují se jednak údaje editovaného prvku, jednak konzistence vazeb na ostatní prvky (nadřízené, podřízené prvky). Kontrolních funkcí bude značné množství, podrobný přehled bude obsahovat detailní analýza.

•

Schválení návrhu změn – Pokud daná změna vyžaduje schválení jinou osobou, než je příslušný editor, tato funkce umožní této osobě zobrazení návrhu změny a schválení, či odmítnutí návrhu změny.

Strana 53/111


•

Zplatnění návrhu změn – Funkce zplatní změny obsažené v návrhu změny tzn. stávající verze dotčených prvků označí jako historické a nové verze označí jako aktuální. Tím jsou změny připravené pro publikování do RUIAN.

•

Publikování návrhu změn – Funkce předá požadavek na odeslání návrhu změny do RUIAN výstupnímu rozhraní a po přijetí potvrzení o úspěšném zápisu do RUIAN, označí provedené změny s konečnou platností v ISUI jako publikované. Současně s návrhem změny odešle informace o rozhodnutí, na základě kterého byla změna připravena (a která se zapíše do RPP).

•

Výpočet odvozených lokalizačních údajů – Při změně lokalizačních údajů (např. hranice obce) funkce zkontroluje, případně navrhne, opravené verze lokalizačních údajů nadřazených prvků (např. hranice okresů...), a v případně ZSJ i podřízených.

•

Odvození historie reality – Při zplatnění návrhu změny, který obsahuje prvky s evidenčním principem bude v případě, že je opravována historie vzniku prvku, nebo realizována změna prvku na základě legislativního podkladu (tj., že nejde o opravu chybně zadaného údaje), vytvořen záznam historie reality. Pozn.:Tyto záznamy jsou potřeba k zodpovídání dotazů na historii zákonem, nebo vyhláškou vyhlášených změn evidenčního prvku, na rozdíl od historie oprav chybně zadaných údajů. 4.5.1.2.

Řízení životního cyklu reklamace

Reklamace je důležitou součástí aplikační logiky ISUI. Slouží: -

pro evidenci a řešení nesouladů zjištěných orgány státní moci (viz kapitola Východiska),

-

pro evidenci a řešení nesouladů vzniklých při naplnění systému daty,

-

pro řešení nesouladů mezi ISKN a ISUI, které vzniknou při zadávání údajů svázaných s oběma AIS.

Funkční blok obsahuje tyto funkce: •

Přijetí reklamace – Funkce bude sloužit pro přijetí a prvotní zpracování přijaté reklamace. Pokud jsou data v ISUI již v souladu s přijatou reklamací, funkce tuto reklamaci označí jako vyřízenou kladně. Pokud v ISUI již existuje stejná reklamace, která nebyla dosud vyřízena, funkce pouze přidá identifikaci tazatele k této reklamaci.

•

Interaktivní zpracování reklamací – Funkce bude sloužit pro vyřizování reklamací údajů RUIAN aktualizovaných prostřednictvím ISUI. Reklamaci bude možné buď Strana 54/111


zamítnout jako neoprávněnou, přijmout ji a vyřídit kladně, případně ji zařadit k dalšímu prověření. Editor bude moci reklamované údaje do doby vyřízení reklamace označit jako nesprávné. •

Automatické zpracování reklamací – Funkce bude sloužit pro automatické vyřizování reklamací údajů RUIAN aktualizovaných prostřednictvím ISUI. Po každém úspěšném publikování změn do RUIAN funkce prověří, zda na změněné údaje nebyla podána reklamace, která byla touto změnou vyřízena kladně. Pokud ano, příslušná reklamace je automaticky označena jako kladně vyřízená.

4.5.1.3.

Administrativní služby

Funkce ISUI, které využívá uživatel v roli administrátora a správce ISUI a systémové služby zajišťující přístup k datům a funkcím systému. •

Autentizace a autorizace – Funkce provádějící ověření přístupu interních uživatelů do systému a omezení uživatelů v přístupu k datům a funkcím systému na základě jejich rolí U externích uživatelů bude akceptována externí autentifikace a autorizace s využitím služeb ISZR a RPP´.

•

Správa uživatelů – Funkce pro správu interních uživatelů ISUI (pracovníků ČÚZK). Dále funkce pro rozšířenou definici rolí pro jednotlivé agendy. Funkce pro rozšířenou definici rolí budou využívat jak externí, tak interní uživatelé.

•

Monitoring – Funkce pro monitorování stavu zpracování návrhů změn a zpracování reklamací. Dále funkce pro zachycení všech důležitých událostí v systému, součástí monitoringu je i technické logování přístupů k ISUI z aplikace pro vzdálený přístup.

•

Statistiky – Funkce pro výpočet a analýzu nejrůznějších informací o stavu dat v ISUI, řešení reklamací, běhu systému atd. a přípravu příslušných reportů.

4.5.1.4.


Funkce ISUI, které volají služby zaregistrované v systému ISZR (viz kapitola Katalog služeb). •

Odeslání změn do RUIAN – Funkce zajistí sestavení požadavku na základě zplatněného návrhu změny a jeho odeslání do RUIAN prostřednictvím rozhraní

Strana 55/111


ISZR. Odeslaný požadavek zůstává v rozhraní až do potvrzení RUIAN o úspěšném promítnutí zaslaných změn do platného stavu. •

Příprava odpovědí na dotaz na informace o údajích ISUI k určenému datu – Funkce zajistí sestavení odpovědi u dotazu na informace k určenému datu o prvcích, které jsou vedeny v ISUI. Odpověď zařadí do výstupní fronty.

•

Odeslání asynchronních odpovědí na požadavky ISZR – Funkce odešle připravené odpovědi na dotazy z ISZR, které ještě nebyly odeslány.

•

Odeslání odpovědi při vyřízení reklamace – Funkce při kladném či záporném vyřízení reklamace odešle informaci zadavateli reklamace. 4.5.1.5.


Funkce ISUI které jsou volány ze systému ISZR. •

Přijetí požadavků ISZR – Funkce přijme požadavek z ISZR na informace k datu a zařadí jej do fronty ke zpracování. Pokud je požadována odpověď v synchronním módu, čeká vyhrazený čas, zda již ve výstupní frontě existuje připravená odpověď. Pokud ano, odešle ji zpět ISZR. Pokud odpověď není v určeném čase připravena nebo pokud byla požadována odpověď v asynchronním módu, funkce ISZR pouze potvrdí přijetí požadavku k asynchronnímu zpracování.

•

Přijetí reklamace – Funkce umožní přijetí reklamace údajů RUIAN, které jsou zapisovány prostřednictvím ISUI, a její zápis do systému reklamací. 4.5.1.6.

Rozhraní pro publikaci dat veřejnosti

Funkce ISUI zajištující komunikaci s aplikací pro publikaci dat veřejnosti. 4.5.1.7.

Rozhraní na ISKN

Funkce, které zajistí komunikaci se systémem ISKN, nutné pro udržení vazeb mezi prvky spravovanými v ISUI a ISKN. •

Odeslání informací o změně do ISKN – Funkce průběžně zpracovává informace o změnách v ISUI, které mohou mít vliv na prvky editované prostřednictvím ISKN připravených k odeslání, a předává je ISKN.

•

Přijetí informace o změně z ISKN – Funkce přebírá informace zaslané z ISKN o změnách, které mohou mít vliv na údaje ISUI, a zařazuje je do systému reklamací, kde se dále zpracovávají.

Strana 56/111


4.5.1.8. •

Webové služby pro editory

Neinteraktivní zapsání změn do ISUI – Funkce přijme a zkontroluje dávku změn zaslaných od editora prostřednictvím jeho AIS . Pokud kontrola odhalí chybu, je celá dávka změn odmítnuta, pokud kontrola proběhne v pořádku, je celý soubor změn odeslán do RUIAN a zplatněn. Nebude podporována možnost uložení návrhu změn v rozpracovaném stavu a pozdější pokračování zpracování. Funkce je interně realizována voláním potřebných funkcí z aplikační logiky. 4.5.1.9.

Uživatelské rozhraní pro administrátory ISUI

Funkce pro prohlížení a editaci údajů v souvislosti se správou systému. •

GUI pro administrátory – Rozhraní pro zadávání a údržbu interních uživatelů ISUI a detailní správu rolí.

•

GUI pro zobrazení statistik – Rozhraní pro zobrazování statistik a reportů o stavu dat v ISUI, o řešení reklamací, o běhu systému atd.

•

Správa logů – Funkce pro nastavení vytváření logů potřebných pro vytváření statistik o provozu, jejich zálohování a mazání. 4.5.1.10.

Uživatelské rozhraní pro Editory

Funkce tvořící uživatelské rozhraní pro prohlížení a editaci dat ISUI. •

GUI pro Editory – Obsahuje funkce pro interaktivní práci interních i externích uživatelů tj.: •

vyhledávání, zobrazení a editaci údajů návrhů změn.

•

prohlížení a schvalování návrhů změn

•

zadávání a vyřizování reklamací

4.5.2. Funkční bloky ISKN Aby mohl ISKN sloužit kromě své současné funkce i jako editační AIS pro zápis údajů do RUIAN, bude nutné provést jeho rozšíření a úpravy, které lze rozdělit do několika funkčních bloků. Nejrozsáhlejší část bude rozšíření a úprava stávající aplikační logiky systému, která umožní sladit procesy používané při správě katastru nemovitostí s procesy podporujícími editaci určených údajů RUIAN. Kromě toho bude nutné vytvořit funkce zajišťující komunikaci s novými systémy. Jedná se o rozhraní na ISZR (vstupní i výstupní část) a rozhraní pro komunikaci s ISUI.

Strana 57/111


4.5.2.1.

Rozšíření a úprava aplikační logiky ISKN

Rozšíření aplikační logiky ISKN o funkce, které tvoří dodatečnou business logiku potřebnou pro podporu registru RUIAN, tj. hlavně odesílání dat o aktuálních hodnotách prvků Parcela a Katastrální území, reklamační proces a zodpovídání dotazů na historická data. •

Rozšíření standardních kontrol o kontroly proti datům ISUI – Kontrolní funkce zajišťující, že návrh změny v ISKN splňuje požadavky na úplnost a konzistenci s ostatními údaji ISKN, se rozšíří o relevantní kontroly konzistence proti údajům ISUI (jde např. o kontroly údajů o budovách v ISKN proti údajům o stavebních objektech v ISUI) .

•

Převzetí údajů z ISUI do návrhu změn – Nová funkce editace umožňující v relevantních případech převzít do návrhu změny údaje již zapsané v RUIAN. Jedná se zejména o údaje stavebních objektů, které by měly být v okamžiku vydání kolaudačního souhlasu, nebo závěrečné kontrolní prohlídky po oznámení o započetí užívání stavby do ISKN již v RUIAN obsaženy.

•

Údržba přehledové mapy údaji z RUIAN – Lokalizační údaje vybraných územních jednotek nadřazených katastrálním územím (např. VÚSC) budou využity pro automatickou aktualizaci příslušných vrstev přehledové mapy.

•

Vedení účelové katastrální mapy – Funkce bude zajišťovat potřebnou podporu pro import a další údržbu lokalizačních údajů parcel z území nepokrytých v ISKN digitální katastrální mapou.

•

Vedení lokalizačních údajů katastrálních území, tam kde není DKM – Funkce zajistí import a možnost údržby hranic katastrálních území a parcel i v územích, kde není DKM.

•

Kontrola zplatňovaných návrhů změny z pohledu dopadů na RUIAN – Funkce spouštěná vzápětí po zplatnění změn v ISKN vyhodnotí, zda některé změny mají vliv na prvky evidované v RUIAN. Pokud došlo ke změně v údajích RUIAN měněných prostřednictvím ISKN, funkce připraví tyto změny do výstupního rozhraní k odeslání do RUIAN. Pokud došlo v ISKN ke změně v údajích, které mohou mít dopad na prvky vedené v ISUI, funkce připraví tyto změny do rozhraní k odeslání do ISUI.

•

Zpracování ostatních změn z pohledu dopadů na RUIAN – Způsob vedení změn o katastrálních územích bude upraven tak, aby ISKN splňoval požadavek na evidování historie změn u prvků publikovaných v RUIAN. Funkce zajistí u

Strana 58/111


měněných údajů katastrálních území zaznamenání změn takovým způsobem, aby pro všechny atributy vedené v RUIAN bylo možné určit údaje platné k určitému datu. Zároveň zajistí přípravu změn do výstupního rozhraní k odeslání do RUIAN. •

Promítání změn relevantních číselníků do RUIAN – Funkce při změně číselníků ISKN, které jsou používány i v RUIAN, zajistí promítnutí změn těchto číselníků do RUIAN.

•

Údržba číselníků územní identifikace na základě jejich změn v RUIAN – Funkce nahradí stávající funkce pro údržbu číselníků územní identifikace přebíráním změn přímo z RUIAN.

•

Zpracování reklamace – Funkce bude sloužit pro přijetí reklamací z rozhraní a její navázání na odpovídající řízení typu ZDŘ (Záznam dalšího řízení), OR (Ostatní rozhodnutí) či Z (Záznam). Podrobný postup zpracování reklamací v ISKN se bude řešit v detailní analýze.

•

Napojení ISKN na ostatní ZR - Funkce pro zajištění napojení ISKN na ostatní ZR budou zajišťovat funkčnost ISKN ve třech oblastech, kde ISKN bude fungovat jako běžný AIS. Půjde zejména o nahrazení systému ověřování fyzických osob proti ISEO ověřováním proti ROB a souvisejícím zavedením AIFO pro tuto komunikaci. Obdobně bude nutné zajistit ověřování právnických osob vůči ROS. Třetí oblastí bude předávání informací o rozhodnutích do RPP v požadovaném rozsahu . 4.5.2.2.


Funkce ISKN, které volají služby zaregistrované v systému ISZR (viz kapitola Katalog služeb) •

Odeslání změn do RUIAN – Funkce zajistí sestavení požadavku na základě návrhu změny a jeho odeslání do RUIAN a do RPP prostřednictvím rozhraní ISZR. Odeslaný požadavek zůstává v rozhraní až do potvrzení RUIAN o úspěšném promítnutí zaslaných změn do platného stavu. Následně je také do RPP odeslána informace o rozhodnutí, na základě kterého byla změna zapsána..

•

Odeslání dotazů do ZR – Funkce zajistí sestavení požadavku na data ZR, odeslání dotazů do ZR prostřednictvím rozhraní ISZR a pokud budou dotazy zodpovězeny v synchronním módu, zajistí předání výsledků volající funkci.

•

Příprava odpovědí na požadavek informace o vlastníkovi – Funkce zajistí sestavení odpovědi k dotazu na informace o vlastníkovi parcely nebo stavebního objektu zaslaný z ISZR a odpověď zařadí do výstupní fronty.

Strana 59/111


•

Příprava odpovědí na požadavek informace o údajích RUIAN k určenému datu – Funkce zajistí sestavení odpovědi k dotazu na informace k určenému datu (o parcele, katastrálním území nebo o údajích stavebního objektu vedených v ISKN) a odpověď zařadí do výstupní fronty.

•

Odeslání asynchronních odpovědí na požadavky ISZR – Funkce odešle připravené odpovědi na dotazy z ISZR, které ještě nebyly odeslány. 4.5.2.3.


Funkce ISKN které jsou volány ze systému ISZR. •

Přijetí požadavků ISZR – Funkce přijme požadavek z ISZR a zařadí jej do fronty ke zpracování. Pokud je požadována odpověď v synchronním módu, čeká vyhrazený čas, zda již ve výstupní frontě existuje připravená odpověď. Pokud ano, odešle ji zpět ISZR. Pokud odpověď není v určeném čase připravena nebo pokud byla požadována odpověď v asynchronním módu, funkce ISZR pouze potvrdí přijetí požadavku k asynchronnímu zpracování.

•

Přijetí reklamace – Funkce umožní přijetí reklamace údajů RUIAN, které jsou zapisovány prostřednictvím ISKN. Obsah reklamace bude předán k dalšímu zpracování funkci Zpracování reklamací. 4.5.2.4.

Rozhraní na ISUI

Funkce, které zajistí komunikaci se systémem ISUI, nutné pro udržení vazeb mezi prvky spravovanými v ISUI a ISKN. •

Odeslání informací o změně do ISUI – Funkce průběžně zpracovává informace o změnách v ISKN, které mohou mít vliv na prvky editované prostřednictvím ISUI, připravených k odeslání a předává je ISUI.

•

Přijetí informace o změně z ISUI – Funkce přebírá informace zaslané z ISUI o změnách, které mohou mít vliv na údaje ISKN, a zařazuje je do systému reklamací, kde se dále zpracovávají.

Strana 60/111


4.5.3. Funkční bloky RUIAN 4.5.3.1.

Aplikační logika RUIAN

Funkce, které vybírají požadavky na zápis nebo poskytnutí dat z fronty vstupního rozhraní, vykonávají je a zapisují do logů. Není zde obsažena žádná složitější logika. Jde o tyto funkce: •

Zpracování požadavku na zápis dat z ISUI.

•

Zpracování požadavku na zápis dat z ISKN.

•

Zpracování dotazu na konkrétní prvek.

•

Zpracování dotazu na vyhledání prvků.

•

Zpracování dotazu na seznam změn v RUIAN za určité období.

•

Zpracování dotazu na obsah změn konkrétních typů prvku RUIAN za určité období.

4.5.3.2.

Administrativní služby RUIAN

Jde o služby, které budou užívat administrátoři RUIAN prostřednictvím GUI RUIAN. •

Správa logů – Funkce pro nastavení vytváření logů potřebných pro vytváření statistik o provozu, jejich zálohování a mazání.

•

Vytváření statistik o provozu a kvalitě dat – Funkce pro záznam a ukládání informací o provozu registru a o kvalitě dat. Předpokládáme vytváření statistik např. o: •

množství dotazů v čase,

•

odezvách na dotazy v čase (překročení požadovaných SLA),

•

množství nesprávných záznamů a nekonzistencí vazeb pro jednotlivé Prvky (jde hlavně o možné nekonzistence vzniklé mezi Prvky udržovanými editory dvou AIS - ISKN a ISUI).

•

Reporty – Vytváření sestav dokumentujících nesprávné údaje Prvků, nekonzistence Prvků mezi sebou apod. 4.5.3.3.

•

GUI pro administrátory

GUI pro administrátory – Zprostředkuje interaktivní rozhraní pro administrátory RUIAN. Zpřístupňuje správu logů a spouštění a zobrazení statistik provozu a kvality dat.

Strana 61/111


4.5.3.4.

Služby rozhraní RUIAN

Funkce, které zabezpečují komunikaci se systémem ISZR. •

Synchronní služby pro přijímání zodpovídání požadavků z ISZR (viz definice v kapitole Katalog služeb).

•

Služby pro odeslání dat vyžádaných z RUIAN - požadavku na informace logů (dat o využití údajů) a poskytování částečné nebo úplné kopie dat RUIAN. 4.5.3.5.


Aplikace pro publikaci dat veřejnosti bude koncipována tak, aby mohla používat stejné funkce, jaké budou používány k implementaci služeb rozhraní RUIAN.

4.5.4. Funkční bloky Aplikace pro publikaci dat veřejnosti Aplikace pro publikaci dat veřejnosti slouží ke zpřístupnění dat RUIAN, ISUI a informace o vlastnictví z ISKN veřejnosti v datové, mapové i souborové formě. Aplikace neposkytuje referenční data, pouze zprostředkovává data RUIAN ze své lokální kopie databáze, kterou si pro tyto účely udržuje. Pro přístup k aplikaci není potřeba registrace. Aplikace nebude sloužit pro objednávání dat RUIAN na datových nosičích. Poskytovaná data nemají referenční charakter. 4.5.4.1.

Aplikační logika

Aplikační logika obsahuje základní funkce aplikace, tj. hlavně služby pro vyhledávání dat obsažených v RUIAN. •

Vyhledávání prvků - Vyhledávání aktuálních prvků evidovaných v RUIAN a zobrazování údajů o nich.

•

Vyhledávání prvků platných ke dni - Vyhledávání prvků evidovaných v ISUI platných k určitému dni (kromě aktuálního dne).

•

Zprostředkování údaje o vlastníkovi pozemku nebo v katastru nemovitostí evidovaného stavebního objektu voláním příslušné služby DP.

•

Poskytování obsahu RUIAN a ISUI v souborové formě – aplikace bude umožňovat stažení obsahu RUIAN a ISUI ve výměnném formátu. Výměnným formátem bude XML, definice bude provedena pomocí XSD. Obsah bude rozdělen na data platná ke konci měsíce a denní přírůstky. Dále bude členěn do souborů – dle typu prvků a dle platnosti dat (platné/neplatné záznamy).

Strana 62/111


4.5.4.2.

GUI pro textové a grafické informace

Funkce pro prohlížení údajů RUIAN. •

Prohlížení aktuálních údajů - Funkce pro prohlížení údajů o aktuálních prvcích a vazbách mezi nimi. Funkce bude číst data RUIAN. Funkce bude umožňovat navigaci mezi nadřízenými a podřízenými prvky, přechod na prohlížení mapy se zvýrazněním vybraných prvků.

•

Prohlížení údajů platných k zadanému dni - Funkce pro prohlížení údajů o prvcích a vazbách mezi nimi platných k určitému dni. Funkce bude číst data k ISUI. Funkce bude umožňovat navigaci mezi nadřízenými a podřízenými prvky. Nebudou zobrazována data uchovávaná v ISKN. Nebude umožněn přechod na prohlížení mapy.

•

Prohlížení mapy - Aplikace, která umožní prohlížet vybrané typy aktuálních prvků na mapě nad mapami poskytovanými Zeměměřickým úřadem prostřednictvím WMS. Pro každý prvek, který bude obsahovat lokalizační atributy (alespoň definiční bod), bude existovat funkce, která zobrazí lokalizaci prvku na mapě. Z mapového zobrazení bude možné přejít do prohlížení aktuálních popisných údajů RUIAN výběrem definičního bodu zvoleného prvku. Pozn.: lokalizační data budou zobrazována výhradně prostřednictvím mapy. Nebudou zobrazována v popisné formě.

•

Prohlížení údajů - Funkce pro prohlížení údajů o prvcích a vazbách mezi nimi v tabulkové formě. 4.5.4.3.

Administrativní služby

Aplikace pro publikaci dat veřejnosti bude využívat anonymní přístup, proto nebude obsahovat správu uživatelů. Informace o přístupech bude logována na technické úrovni. Rozsah logovaných údajů bude specifikován v rámci detailní analýzy. . 4.5.4.4.

Služby rozhraní na RUIAN

Funkce pro komunikaci se systémem poskytujícím data RUIAN. •

Synchronizace lokální databáze s RUIAN – Funkce pro synchronizaci interní kopie databáze RUIAN s databází RUIAN.

Strana 63/111


•

Zpřístupnění dat ISUI – Funkce, které volají rozhraní ISUI a zajišťují zodpovězení dotazů na data o prvcích k určitému datu v minulosti.

•

Komunikace s aplikací dálkový přístup do ISKN - Funkce, které zajistí informace o vlastnících stavebních objektů (tj. v ISNK budov) a parcel.

Strana 64/111


5. Datová architektura 5.1.

Struktura dokumentu

Dokument obsahuje tyto body: •

Shrnutí relevantních požadavků vyplývajících ze zákonů nebo jiných závazných dokumentů.

•

Shrnutí relevantních vstupů z funkční a procesní analýzy.

•

Globální datová architektura.

•

Konceptuální datový model RUIAN, ISUI a rozšíření/úpravy datového modelu ISKN. (V GA je uveden pouze pro jádro RUIAN, doplněn v DA)

•

5.2.

Detailní datový model pro prvky jádra RUIAN (bude doplněn v DA)


Návrh globální datové architektury bude koordinován s hlavním architektem ZR a architekty ostatní registrů a na základě toho případně upraven. Cílem je dosáhnout konzistentní globální datové architektury v celém systému základních registrů. V tomto dokumentu je uvedena základní představa o datovém obsahu všech částí systému a popis datového obsahu RUIAN definovaného zákonem o základních registrech (jádro RUIAN) na konceptuální úrovni. V návaznosti na globální architekturu bude vytvořena detailní datová analýza – ta bude obsahovat popis dalších struktur RUIAN, ISUI a ISKN na konceptuální úrovni a návrh struktury dat jádra RUIAN na logické úrovni. Pro popis konceptuálního datového modelu bude použit obecný diagram tříd a pro jednotlivé třídy bude uveden popis, jejich hlavní atributy a integritní omezení. Pro popis jádra RUAIN na logické úrovni bude použit diagram tříd se stereotypem „table“ a pro jednotlivé tabulky budou definovány jejich sloupce (název, typ a popis) a integritní omezení (primární klíče, cizí klíče, další omezení).

Strana 65/111


5.3.


5.3.1. Požadavky vyplývající ze závazných dokumentů •

V RUIAN jsou evidovány referenční údaje o základních územních prvcích, účelových územních prvcích, územně evidenčních jednotkách a doplňkové údaje.

•

V základních registrech jsou evidovány pouze aktuální údaje, nikoliv jejich historie. Za vedení historických údajů jsou zodpovědné Agendy prostřednictvím editačních AIS.

•

Referenční údaje mohou být v základním registru označeny jako „nesprávné“, pokud vznikne oprávněná pochybnost o správnosti údaje.

•

Oprávnění k přístupu a zápisu do základních registrů nejsou evidována v jednotlivých základních registrech, ale v RPP.

•

Kód agendy je jednoznačným identifikátorem agendového informačního systému. Kódy agend jsou evidované v RPP.

•

V ROB se vede adresa místa pobytu ve formě referenční vazby (kódu adresního místa) na referenční údaj o adrese v základním registru územní identifikace, adres a nemovitostí.

•

V ROB se vede údaj o místě a okrese narození a úmrtí na území České republiky ve formě referenční vazby (kódu adresního místa) na referenční údaj o adrese v základním registru územní identifikace, adres a nemovitostí.

•

V ROS se vede adresa sídla osoby nebo adresa místa podnikání fyzické osoby vyjádřená kódem adresního místa, který tvoří referenční vazbu na základní registr územní identifikace, adres a nemovitostíi,

•

V ROS se vede adresa sídla provozovny vyjádřená kódem adresního místa, který tvoří referenční vazbu na referenční údaje o adrese v základním registru územní identifikace, adres a nemovitostí.

•

V RPP jsou vedeny údaje o rozhodnutích nebo jiných úkonech orgánů veřejné moci, včetně veřejnoprávních smluv a opatření obecné povahy (dále jen „rozhodnutí“), na základě nichž dochází ke změně referenčního údaje v některém ze základních registrů.

5.3.2. Požadavky vyplývající z funkční a procesní analýzy •

Vzhledem k požadavkům referenční integrity není možné zrušené prvky z RUIAN fyzicky smazat.

Strana 66/111


•

Kromě datových struktur pro ukládání údajů vedených v RUIAN, ISUI i ISKN ze zákona o základních registrech, je třeba v systémech ukládat i další data nezbytná pro řízení aplikace.

5.4.

Globální datová architektura

5.4.1. Cíl globální datové architektury Cílem globální datové architektury bude popsat základní představu o datovém obsahu a tu pak konzultovat se zadavatelem a v relevantních částech i s architekty ostatních registrů. Na základě dořešení případných sporných bodů bude možné přistoupit k detailní datové analýze.

Strana 67/111


5.4.2. Globální datové schéma. RUIAN Změny dat

Číselníky

Provozmí údaje

Odpovědi z RUIAN Interní komunikace mezi ISKN a ISUI

Referenční údaje Doplňkové údaje

Identifikační

Vazby

Lokalizační

Adresy

ROB

ROS

RPP

Další údaje

Ostatní referenční údaje

ISZR Rozhraní ISZR na základní registry

Aplikační logika ISZR a ORG Rozhraní ISZR na AIS

AIS - ISKN

AIS - ISUI


Lokalizační údaje mimo DKM


Nová aplikační data a číselníky

Rozhraní na ISUI



Rozhraní na ISKN

Návrhy změn Údaje RUIAN (včetně historie Rozhodnutí

Reklamace Existující data ISKN Číselníky Uživatelé, role

Provozní údaje

5.4.3. Datový obsah RUIAN 5.4.3.1.

Použité pojmy

Pro zjednodušení popisu jsou v této kapitole zavedeny následující zkratky pro názvy Prvků: Názvy Prvků: Název dle zákona o základních registrech

Název užitý v popisech procesu

Strana 68/111


Území státu

ČR

Území regionu soudržnosti podle jiného právního

Region soudržnosti

předpisu Území vyššího územně samosprávného celku

VÚSC

Území kraje

Kraj

Území okresu

Okres

Správní obvod obce s rozšířenou působností

ORP

Správní obvod obce s pověřeným obecním úřadem

POU

Území obce

Obec

Území vojenského újezdu

Obec (zde jde o vědomé zjednodušení vycházející z toho, že obce a újezdy tvoří souvislé území a oba Prvky budou spravovány stejným typem editora)

Správní obvod v hlavním městě Praze

Správní obvod

Území městského obvodu v hlavním městě Praze

Městský obvod

Území městského části v hlavním městě Praze

Městská část

Území městského obvodu územně členěného

Městská část

statutárního města

(z datového hlediska se bude s městským obvodem statutárních měst zacházet stejně jako s městskou částí, budou evidovány ve společné entitě)

Území městské části územně členěného

Městská část

statutárního města Katastrální území

Katastrální území

Strana 69/111


Území základní sídelní jednotky

ZSJ

Stavební objekt

Stavební objekt

Adresní místo

Adresní místo

Pozemek v podobě parcely

Parcela

Část obce

Část obce

Ulice nebo jiné veřejné prostranství

Ulice

Pozn.: V diagramu konceptuálního datového modelu jsou názvy uvedeny bez diakritiky a s podtržítky místo mezer. 5.4.3.2.

Referenční údaje

Jádrem datového modelu jsou referenční údaje. Jedná se o: •

identifikační údaje,

•

údaje o vazbách na ostatní územní prvky, případně na územně evidenční jednotky,

•

údaje o druhu a způsobu využití pozemku a jeho technickoekonomické atributy,

•

údaje o typu a způsobu ochrany nemovitosti,

•

adresy.

Nejsou zde zahrnuty lokalizační údaje, které jsou v územích, ve kterých je katastrální mapa vedena v digitální formě, také referenčními údaji – jejich problematika je popsána dále. 5.4.3.3.

Lokalizační údaje

Lokalizační údaje jsou referenční pouze v území, kde je vedena digitální katastrální mapa, v ostatních územích nikoliv. Přesný způsob ukládání lokalizačních údajů bude navržen až během detailní analýzy na základě koncepčních rozhodnutí z tohoto dokumentu (práce s lokalizačními údaji mimo území s DKM, generalizace apod.). Vzhledem k zavedení lokalizačních údajů katastrálních území a parcel z území mimo DKM do ISKN, budou v RUIAN vedeny lokalizační údaje ze všech katastrálních území, včetně těch, ve kterých není katastrální mapa vedena v digitální formě (tyto údaje sice nemají váhu referenčních údajů, ale vzhledem k úrovni pokrytí území digitální katastrální mapou značně zvýší využitelnost RUIAN). Na úrovni katastrálních území se předpokládá, že do zahájení plnění RUIAN budou v ISKN uloženy a aktualizovány jejich kompletní hranice včetně území, ve kterých dosud není

Strana 70/111


mapa vedena v digitální podobě. Pokud by tomu tak nebylo, bylo by nutné zvážit varianty dalšího postupu v této oblasti, protože zákon o základních registrech jednoznačně předpokládá údržbu lokalizačních údajů katastrálních území z ISKN. Naplnění hranic katastrálních území bez ohledu na to, jakým způsobem je v nich vedena mapa, je nezbytné pro odvození hranic obcí a vyšších celků. U prvků, jejichž hranice jsou odvozeny z hranic podřazených prvků, bude použita generalizace. Jako základní lokalizační údaj bude použita negeneralizovaná hranice odvozená od podřazených prvků - toto odvození lze realizovat automaticky v rámci procesu aktualizace a zplatnění. Tato hranice pak bude podle potřeby doplněna automatizovaně generalizovanými hranicemi pro různá měřítka používaná pro zobrazování. 5.4.3.4.

Doplňkové údaje

V zákoně o základních registrech jsou definovány další údaje, které mají být vedeny v RUIAN, a přitom nejde o referenční údaje. Tyto údaje budou vedeny jako další atributy entit uvedených na diagramu, resp. v případě doplňkových údajů pro účely doplňkových služeb k nim ještě přibude entita Adresní pošta. V některých případech není ze zákona jednoznačně určena forma těchto údajů, bude proto nutné tuto formu stanovit po dohodě se zadavatelem v rámci detailní analýzy. Např. u mluvnických charakteristik názvu obce, městské části/obvodu, katastrálního území, ZSJ a části obce je pouze v důvodové zprávě uvedeno, že by mohlo jít o mluvnický rod, mluvnické číslo a o tvary názvu ve všech sedmi pádech daného čísla. Také je potřeba stanovit, kde tyto charakteristiky vzít při migraci a odkud je bude získávat editor těchto údajů, kterým je ze zákona ČÚZK. 5.4.3.5.

Problematika stavebních objektů

V zákoně zavedený pojem Stavební objekt v sobě zahrnuje jak budovy katastru nemovitostí definované na základě katastrálního zákona, tak objekty v pojetí UIR-ADR a tzv. statistické budovy vedené v registru sčítacích obvodů. Ze známých rozdílů v definici těchto objektů (možnost vedení více č.p. u jedné budovy v katastru nemovitostí apod.) vyplývají problémy, které je v této oblasti datového modelu nutné vyřešit. Podle našeho názoru bude nejvhodnější vyjít z definice statistické budovy (resp. objektu UIRADR) a zároveň udržet vazbu stavebních objektů na budovu vedenou v ISKN. V případech, kdy se v ISKN nachází budova, která se skládá z více částí, bude tedy vedena jako více stavebních objektů (s č.p. odpovídajících jednotlivým částem budovy), které budou mít odkaz na stejnou budovu v ISKN (BUD_ID). Z toho zároveň vyplývá, že pokud se nezmění způsob evidence Strana 71/111


budov v ISKN, budou hranice všech takto vzniklých objektů shodné a budou odpovídat hranicím původní budovy v ISKN. Bude také nutné potvrdit předběžnou dohodu s ČSÚ, že stavební objekt v RUIAN nebude obsahovat přímou vazbu na ZSJ, protože není jasné, jak by editor této vazby, kterým je stavební úřad, údaje o příslušnosti stavebního objektu k ZSJ získával. 5.4.3.6.

Platnost prvků

Přestože jsou v základních registrech vedeny pouze aktuální údaje a nikoliv jejich historie, považujeme za vhodné zrušené prvky neodstraňovat, ale vést u každého prvku údaje o datu zahájení a ukončení jeho platnosti. Zrušené prvky pak musí v registru zůstat pro případy, kdy registry nebo AIS obsahují odkaz na již zrušený prvek U údajů: •

vznik, zánik a změna názvu části obce,

•

pojmenování, zrušení pojmenování a změna názvu ulice,

•

očíslování, přečíslování a zrušení očíslování stavebního objektu číslem domovním,

•

očíslování, přečíslování a zrušení očíslování stavebního objektu číslem orientačním

vyjmenovaných v návrhu zákona o změně jiných zákonů je uvedeno, že jejich zápis do registru má konstitutivní význam, tj. že jsou „platné od okamžiku jejich zápisu do tohoto registru editorem“. U ostatních údajů zapisovaných do registru má zápis pouze evidenční význam, tj. datum zahájení platnosti určuje editor na základě příslušných podkladů.

5.4.3.7.

Stav údajů

Podle zákona o základních registrech musí existovat možnost označit za určených okolností referenční údaj jako nesprávný. Možnost označení jako údaj dotčený změnou bude podrobněji diskutována v DA. Z toho vyplývá nutnost mít pro každý atribut, který je dle zákona referenčním údajem, jiný atribut, který označuje správnost/nesprávnost tohoto referenčního údaje. Domníváme se, že vzhledem k předpokládanému malému procentu případů, kdy bude některý referenční údaj označený jako nesprávný, bude vhodnější vytvořit pro tyto indikace samostatné datové struktury a neukládat je přímo k originálním atributům. Detailní datová struktura pro ukládání indikace správný/nesprávný bude navržena v rámci detailní analýzy.

Strana 72/111


5.4.3.8.

Číselníky

Některé údaje vedené v RUIAN mohou nabývat hodnot, které jsou definovány příslušnými číselníky (např. typ ochrany nemovitosti). Tyto číselníky budou udržovány v zdrojových editačních AIS a do RUIAN budou pouze kopírovány. 5.4.3.9.

Účelové územní prvky

Podle zákona o základních registrech lze v RUIAN vést i další údaje o účelových územních prvcích pokud tak stanoví jiný právní předpis. Zatím byly jako jediné účelové prvky, které by bylo vhodné vést v RUIAN od samotného počátku identifikovány statistické jednotky (kódy NUTS, LAU) a obvody působnosti stavebních úřadů. 5.4.3.10.

Provozní údaje

Během provozu RUIAN budou vznikat údaje, které budou následně sloužit k vyhodnocování běhu systému, vytváření statistik apod. Budou obsahovat data o aktualizaci referenčních údajů, o poskytování informací z RUIAN, podklady pro reporty využití systému, podklady pro vyhodnocování datové kvality apod. V rámci detailní analýzy bude třeba po dohodě se zadavatelem stanovit rozsah sledovaných údajů jako podklad pro návrh datových struktur.

5.4.4. Datový obsah ISUI 5.4.4.1.

Historie údajů ISUI

Na rozdíl od RUIAN bude ISUI obsahovat kompletní historii vedených údajů (od uvedení systému do provozu). Již neplatné údaje budou uloženy ve stejné struktuře jako údaje aktuální, jednotlivé verze stejného prvku budou označeny číslem verze a rozsahem platnosti (datum vzniku a datum zániku verze). Kromě údajů, které již neplatí, zde budou vedeny i údaje, které ještě neplatí - tj. budoucnost. Tyto údaje budou opět uloženy ve stejné struktuře a budou navázány na návrh změny, ke kterému se vztahují – jinak než přes návrh změny nebude možné žádné změny údajů RUIAN provést. V okamžiku zplatnění konkrétního návrhu změny se pak příslušné navržené změny z budoucnosti přesunou do platného stavu a měněné prvky platného stavu se přesunou do minulosti.

Strana 73/111


5.4.4.2.

Datový model pro správu návrhů změn a rozhodnutí

Změny v údajích RUIAN budou připravovány, kontrolovány a zplatňovány výhradně prostřednictvím návrhů změny, což je seskupení změn údajů, které se mění na základě jednoho rozhodnutí nebo jiného podkladu a které dohromady tvoří konzistentní změnu (ve smyslu logické i databázové konzistence). Pro tyto účely budou navrženy entity, které umožní evidovat jak jednotlivé návrhy změn, tak vazby jednotlivých verzí prvků a operace, které jsou k nim navrženy. Aby bylo vyhověno požadavku na ukládání údajů o rozhodnutích nebo jiných úkonech orgánů veřejné moci, na základě nichž dochází ke změně referenčního údaje v některém ze základních registrů, bude každý návrh změny vázán na datové struktury evidující důvod změn. Předpokládáme, že půjde o struktury obdobné jako je evidence řízení v ISKN, ale podstatně jednodušší – bude existovat hlavička rozhodnutí a k tomu detailní údaje. V rámci tvorby společné globální analýzy by měla proběhnout koordinace s tvůrci registru práv a povinností a po zjištění přesné struktury požadovaných údajů budou navrženy v rámci detailní analýzy příslušné datové struktury. 5.4.4.3.

Identifikátory stávajících evidencí

Pro agendové systémy, které se budou postupně napojovat na RUIAN, bude výhodné, aby ISUI obsahoval relevantní identifikační údaje stávajících evidencí, i když zákon nic takového nevyžaduje. V ISÚI budou tyto údaje fungovat jako převodník údajů stávajících evidencí na RÚIAN pro všechny agendové informační systémy i informační systémy mimo subjekty veřejné správy. Naplnění těchto odkazů proběhne v rámci migrace v ISUI. 5.4.4.4.

Datový model reklamací

Datové struktury pro reklamace budou obsahovat hlavičku reklamace, kde budou soustředěny základní informace o reklamaci (identifikace, stav, datum přijetí, datum vyřízení, předmět reklamace, způsob vyřízení, vazba na návrh změny, která reklamaci kladně vyřídila apod.) a detailní informace o obsahu reklamace a postupu vyřizování (v podstatě návrh změn jednotlivých prvků). 5.4.4.5.

Číselníky

Pro všechny údaje, které mohou nabývat pouze vybraných hodnot, budou zavedeny číselníky. Ty mohou být buď interní (pokud se nepředpokládá změna těchto hodnot) nebo udržované uživatelem (pokud by bylo potřeba hodnoty měnit).

Strana 74/111


Pro všechny číselníky, které nejsou interní, budou existovat pracovní datové struktury. Ty budou shodné s datovými strukturami příslušných číselníků a budou sloužit k editaci. Uživatel bude mít možnost v rámci pravidel číselník v pracovní oblasti upravit a po odsouhlasení cílového stavu bude mít možnost změny jednorázově přesunout do „ostrých“ datových struktur číselníků. U číselníků, které jsou obsaženy v RUIAN, následně dojde k aktualizaci jejich obsahu i v RUIAN. 5.4.4.6.

Správa uživatelů a rolí

V ISUI budou vedeny údaje o interních uživatelích ISUI a jim přidělených rolích. U externích uživatelů se vzhledem k použití externí identifikace a autorizace žádné údaje nepovedou, budou zde pouze definovány role pro jednotlivé agendy, v rámci kterých bude externí autorizace přípustná. 5.4.4.7.

Provozní údaje

Pro audit provozu a žurnálování budou navrženy datové struktury, které budou obsahovat informace o všech důležitých událostech v systému. Dále budou navrženy datové struktury pro ukládání provozních statistik systému – zejména statistik kvality dat, statistiky mapující počty změn jednotlivých údajů a statistiky vyřizování reklamací.

5.4.5. Rozšíření/změny v datovém obsahu ISKN 5.4.5.1.

Lokalizační údaje katastrálních území v území bez DKM

Do ISKN bude zavedena nová datová vrstva obsahující kompletní hranice k.ú., které budou v ISKN udržovány ve formě tzv. okřídlených hran (spojnice trojmezí obsahující informaci o kódu k.ú. na jedné i druhé straně hranice). V k.ú. s DKM budou udržovány konzistentní s DKM a v oblastech mimo DKM na základě zplatňovaných GP. 5.4.5.2.

Lokalizační údaje parcel v území mimo DKM

Pro předpokládané vedení DKM Není v seznamu zkratek.Pokud budou vedeny v ISKN budeme je i udržovat, což bude znamenat citelné navýšení práce. v ISKN bude vytvořena nová datová vrstva obsahující hranice parcel dodané z krajů. Tyto hranice budou udržovány ve formě tzv. okřídlených hran, stejně jako parcely DKM. V oblastech mimo DKM budou tyto hranice udržovány na základě zplatňovaných GP.

Strana 75/111


5.4.5.3.

Nová aplikační data a číselníky

Pro potřeby nové doplněné funkčnosti (např. správa reklamací) budou navrženy nové datové struktury a podle potřeby i nové interní číselníky. 5.4.5.4.

Datové struktury pro komunikaci s RUIAN a ISUI

Při komunikaci s ISUI i s RUIAN budou používány datové struktury pro ukládání odchozích i příchozích správ do front, což umožní v případě potřeby asynchronní komunikace a zajistí nezávislost běhu ISKN na dostupnosti obou systémů.

5.4.6. Vazby mezi registry RUIAN neobsahuje žádné údaje odkazující do ostatních ZR. V ROS se budou používat odkazy na adresy RUIAN realizované pomocí ID adresního místa. V ROB se budou používat odkazy na adresy RUIAN realizované pomocí ID adresního místa. V průběhu společné globální analýzy bude třeba ve spolupráci s řešiteli architektury ROB vyjasnit, zda budou existovat i jiné typy vazeb do RUIAN. Podle dikce zákona o základních registrech by se sice informace o místu a okresu narození a úmrtí měla evidovat formou odkazu na adresní místo, zřejmě ale bude třeba použít odkaz na obec a okres (v Praze na městský obvod) – bude nutné dořešit v rámci koordinace s ostatními registry.

5.4.7. Pravidla pro využívání referenčních vazeb Pro vazby popsané v předchozím odstavci platí tato pravidla: •

Datové základny ZR nejsou navzájem propojeny, není tedy možno realizovat constraint typu Foreign Key na úrovni databází mezi ZR.

•

Vrstva služeb eGON před zavoláním služby zápisu do registru kontroluje existenci identifikátoru v příslušném registru (tuto kontrolu neprovádí registr, do kterého se zápis provádí).

•

Jednotlivé základní registry poskytují pouze služby, které vracejí jejich vlastní data. Pokud přistupující AIS žádá o referenční údaje, které jsou obsahem více základních registrů, provede se to tak, že základní registr vydá pouze hodnotu referenční vazby a ISZR provede doplnění těchto údajů z jiného ZR.

•

V okamžiku rušení záznamu v registru se nekontroluje, zda záznam není předmětem referenční vazby. Záznam by ale neměl být rušen fyzicky ale jen logicky (označen jako zrušený).

Strana 76/111


•

V případě, že nějaký přistupující AIS nebo ISZR požaduje vydání zrušeného záznamu, je upozorněn, že záznam byl zrušen.

Tato navržená pravidla bude nutno v rámci návrhu architektury registru doplnit a přizpůsobit ostatním základním registrům a vrstvě ISZR.

5.4.8. Vazby mezi RUIAN a editačními AIS (ISUI, ISKN) Všechny údaje, které jsou obsahem RUIAN, jsou zároveň uloženy v jednom z editačních AIS. Platí tedy, že pro každý údaj uložený v RUIAN existuje jeho zdrojový údaj uložený v ISUI nebo v ISKN, který je s ním datově totožný. Tato vazba se ovšem nevztahuje na provozní údaje.

5.4.9. Vazby mezi ISKN a ZR Mezi ISKN a ZR se vyskytuje ještě druhý typ vazby. Zde ISKN vystupuje v roli přistupujícího AIS a má tedy právo přistupovat v rozsahu svého oprávnění k jejich datům. V této roli bude ISKN odkazovat na údaje o osobách do ROB (viz. aktuální znění katastrálního zákona § 6a, odstavec 3), ROS (viz zákon o základních registrech §65, odstavec 3), případně o jejich adresách do RUIAN (viz zákon o základních registrech §67.

5.4.10.

Vazby mezi ISKN a ISUI

Vzhledem k tomu, že se část údajů v RUIAN udržuje z ISKN a část z ISUI a přitom je nutné zajistit jejich konzistenci, je třeba, aby systém, který mění údaje, měl přístup k souvisejícím údajům z druhého systému. Navrhujeme ověřovat potřebné údaje přímo vůči datům z druhého systému. Protože oba systémy budou ve správě ČÚZK a budou provozovány na společné infrastruktuře, je několik variant, jak získat přístup k potřebným datům – použití virtuálních pohledů na úrovni databáze, využití služeb na aplikační úrovni nebo třeba transparentní replikace potřebných dat do druhého systému. Konkrétní způsob komunikace bude navržen v DA.

Strana 77/111


5.5.

Konceptuální datový model jádra RUIAN

5.5.1. Diagram tříd jádra RUAIN class CM_Vazby mezi prv ky

Stat 1

1 1..*

Region_soudrznosti 1 1..*

1..*

Kraj

VUSC

1

1

1 1..* ORP

1..*

0..1

1..*

1

Okres

1..*

1 POU

+spravni_obec_ORP

0..1 1 1..*

+spravni_obec_POU

1..*

1

Obec 1

1

1

0..*

1

0..*

Ulice

1

1

0..*

Sprav ni_obv od

0..1

1

1..* Mestsky_obv od

0..1

0..1

Katastralni_uzemi

0..1

1

1

+spravni_MC_SO 1..* Cast_obce

1

1..*

0..*

1..*

Mestska_cast

0..1

0..1

1..* Parcela +definicni_parcela

1

1..* ZSJ

0..*

0..*

0..*

Stav ebni_obj ekt 1 0..*

0..*

Adresni_misto

Strana 78/111


5.5.2. Popis jednotlivých tříd Třída

Popis

Stat

Území státu

Region_soudrznosti Členění ČR dané zákonem č.248/2000 Sb , o podpoře regionálního rozvoje ve znění pozdějších předpisů. VUSC

VÚSC představují členění ČR na vyšší územní samosprávné celky podle ústavního zákona č. 347/1997 Sb., o vytvoření vyšších územních samosprávných celků a o změně ústavního zákona České národní rady č. 1/1993 Sb., Ústava České republiky .V registru je v evidenci VÚSC i hlavní město Praha.

Kraj

Členění území ČR podle zákona č. 36/1960 Sb., o územním členění státu.

Okres

Okresy představují členění kraje na menší celky. V rámci okresů musí být jednoznačný název obcí. Okresy jsou definovány zákonem č. 36/1960 Sb., o územním členění státu. V registru je z formálních důvodů návaznosti hierarchie prvků zavedeno jako okres i hlavní město Praha

ORP

Obce s rozšířenou působností (ORP) dle zákona č. 128/2000 Sb., o obcích (obecní zřízení), ve znění pozdějších předpisů. Správní obvod ORP je definován výčtem obcí a nemusí respektovat území okresů. Správní obvod ORP je prostorově lokalizován hranicemi obcí, které má ve správě – nemusí tvořit souvislé území.

POU

Pověřený obecní úřad (POU) vykonává přenesenou působnost veřejné správy pro určené obce dle zákona č. 314/2002 Sb., o stanovení obcí s pověřeným obecním úřadem a stanovení obcí s rozšířenou působností, ve znění zákona 387/2004 Sb. Správní obvod POU je prostorově lokalizován jednou nebo několika hranicemi – nemusí tvořit souvislé území.

Strana 79/111


Třída

Popis

Obec

Seznam obcí a vojenských újezdů dle zákona č. 128/2000 Sb., o obcích (obecní zřízení), ve znění pozdějších předpisů. a zákona č. 222/1999 Sb., o zajišťování obrany České republiky, ve znění pozdějších předpisů. V registru je v evidenci obcí i hlavní město Praha.

Cast_obce

Část obce definovaná podle zákona č. 128/2000 Sb., o obcích (obecní zřízení), ve znění pozdějších předpisů.

Spravni_obvod

Správní obvody představují členění hlavního města Praha dle zákona č. 131/2000 Sb., o hlavním městě Praze, ve znění pozdějších předpisů.

Mestsky_obvod

Městské obvody představují členění hl. města Praha podle zákona č 36/1960 Sb., o územním členění státu, (obvody 110)

Mestska_cast

Městské části a městské obvody představují členění území statutárních měst dle zákona č. 128/2000 Sb., o obcích (obecní zřízení), ve znění pozdějších předpisů. členění Prahy na městské části dle zákona č.131/2000 Sb. ve znění pozdějších předpisů.

Katastralni_uzemi

Katastrální území ve smyslu zákona č. 344/1992 Sb., o katastru nemovitostí České republiky (katastrální zákon), ve znění pozdějších předpisů.

ZSJ

Základní sídelní jednotky dle zákona č. 89/1995 Sb., o státní statistické službě, ve znění pozdějších předpisů.

Parcela

Parcely podle katastrálního zákona č. 344/1992 Sb., o katastru nemovitostí České republiky (katastrální zákon), ve znění pozdějších předpisů. V RUIAN se evidují pouze parcely KN.

Ulice

Ulice a veřejná prostranství obcí se zavedeným uličním systémem dle zákona č. 128/2000 Sb ., o obcích (obecní zřízení), ve znění pozdějších předpisů. a v Praze dle zákona č.

Strana 80/111


Třída

Popis 131/2000 Sb., o hlavním městě Praze, ve znění pozdějších předpisů

Stavebni_objekt

Stavebním objektem se pro účely registru RUIAN rozumí budovy (i bez čísla domovního pokud jsou evidované v KN) nebo jejich části označené číslem popisným nebo evidenčním.

Adresni_misto

Adresní místa – obvykle odpovídají vchodu do stavebního objektu.

Strana 81/111


6. Základní rámec technologické architektury 6.1.

Struktura dokumentu

Výsledný dokument DA bude obsahovat tyto body: •

shrnutí relevantních požadavků vyplývajících ze zákonů nebo jiných závazných dokumentů

•

shrnutí relevantních vstupů z datové, funkční a procesní analýzy

•

cíle návrhu technologické architektury

•

návrh globální technologické architektury

•

podklady pro sizing

•

detailní návrh technologické architektury

•

stanovení technologických standardů a parametrů

V GA je technická architektura popsána na globální úrovni.

6.2.

Základní východiska a cíle •

Technologická infrastruktura ISKN a ISUI je zajištěna (bude využita stávající infrastruktura), předmětem návrhu je pouze RUIAN a infrastruktura pro dálkový přístup do RUIAN,

•

Návrh technologické infrastruktury RUIAN musí být koordinován s technologickou infrastrukturou ostatních registrů a zejména ISZR

6.2.1. Cíle návrhu rámce technologické architektury Cílem návrhu rámce technologické architektury je připravit podklady pro obstarání technologické infrastruktury. Cílem stanovení technologických standardů a parametrů je určit omezení jak z pohledu potřeb aplikací, tak i z pohledu správy, která bude muset implementátor respektovat při obstarání potřebné infrastruktury.

6.3.

Globální technologická architektura

6.3.1. Základní principy návrhu globální architektury Z definice RUIAN jako jednoho ze základních registrů vyplývá, že aby mohl sloužit svému účelu, je nezbytná jeho vysoká dostupnost a dostatečná výkonnost. K zajištění dostupnosti a Strana 82/111


škálovatelnosti navrhujeme zdvojení komponent a v maximální míře využít technologie clusteru ve všech vrstvách, kde je to účelné. Další zvýšení dostupnosti bude realizováno využitím záložního pracoviště s obdobným vybavením jako pracoviště primární (předpokládá se realizace rozšířením stávajících pracovišť). Na následujícím obrázku je zobrazena technologická architektura na fyzické úrovni - je zde schematicky znázorněno zdvojení jednotlivých vrstev a zároveň vztah mezi primárním a záložním pracovištěm.

Strana 83/111


ISZR - záložní lokalita

ISZR - primární lokalita

Primární lokalita

Záložní lokalita n krát GigabitEthernet

LoadBalancing Content switche

LoadBalancing Content switche

Aplikační farma 1

Aplikační farma 2

Aplikační servery

Aplikační servery NAS servery

Řízené prostředí migrací a replikací databází geoclusterem

DB cluster

DB server

SAN DB server

SAN switch

SAN

NAS servery

DB cluster

DB server

SAN

SAN switch

FibreChannel

Backup server

SAN

Backup server

Zálohovací knihovna

Zálohovací knihovna

Diskové pole

DB server

Replikace dat prostředky diskových polí nebo OS

Diskové pole

Fyzické schéma technologické architektury RUIAN Vzhledem k nutné spolupráci několika systémů (jednotlivé základní registry, ISZR, existující a budoucí agendové systémy) je nutné zajistit spolupráci mezi různými platformami a zajistit transparentnost poskytovaných služeb. Proto by měla architektura základních registrů vycházet

Strana 84/111


z přístupu Service-Oriented Architecture (SOA). Tento přístup bude využit jak pro architekturu vnějšího referenčního rozhranní, tak pro architekturu vnitřního komunikačního rozhranní. Komunikace mezi jednotlivými registry a ISZR i mezi ISZR a AIS pak bude probíhat přes standardizované rozhraní. Při tomto přístupu je možné uvažovat i o rozdílných technologických řešeních pro jednotlivé registry.

6.3.2. Technologická infrastruktura pro RUIAN Vzhledem k rozhodnutí, že hardwarové prostředky jednotlivých základních registrů (diskové pole, zálohování a obnovu, síťové prvky atd.) nebudou sdíleny a jejich pořízení bude v režii jednotlivých správců, předpokládáme, že infrastruktura bude umístěna ve shodných lokalitách jako infrastruktura ISKN+ ISUI a měla by s ní být kompatibilní.

Strana 85/111

Projekt „Vybudování Registru územní identifikace, adres a nemovitostí a modernizace Informačního systému katastru nemovitostí ČÚZK„ je spolufinancován Evropskou unií v rámci Evropského fondu pro regionální rozvoj a Integrovaného operačního programu. AIS 1

AIS 2

AIS 3

AIS 4

ISZR

AIS N

eGON služby

Vnější rozhraní

Logika zpracování

služby vnitřního rozhraní

RPP ROB ROS

RUIAN

Infrastruktura Infrastruktura Infrastruktura

Infrastruktura

DNS DNS

Aplikační servery

Identity and Access

DNS DNS

Identity and Access Identity DNS servery Aplikační and Access Identity Aplikační servery Monitoring and Access DNS servery Aplikační

Monitoring Monitoring

Monitoring

Servisní rozhraní Servisní rozhraní Servisní PKI rozhraní

Databáze

Databázové servery

Servisní rozhraní

Databáze Databázové servery

Data Data

PKI

Data

Data Síť

PKI

PKI

PKI PKI

PKI

Síť Síť

Síť

Logické schéma oddělených ZR a ISZR Schéma zobrazuje umístění jednotlivých základních registrů v oddělených fyzických prostorech. V případě RUIAN to znamená, že pro provoz RUIAN bude využito rozšíření infrastruktury pořízené pro provoz ISKN a ISUI. Bude nutné pořízení dalších databázových a aplikačních

Strana 86/111


serverů a rozšíření diskových polí. Potřeba rozšíření u ostatních komponent bude předmětem detailního návrhu TI. Na nově doplněné infrastruktuře bude provozována DB RUIAN, aplikační služby RUIAN a aplikace pro veřejný dálkový přístup. Nově doplňovaná architektura musí být dimenzována a konfigurována takovým způsobem, aby záložní pracoviště mohlo sloužit pro testování nových verzí systému včetně přístupu externích systému. Pro úspěšné integrační testování ZR by bylo vhodné, aby tímto způsobem byly konstruovány i ostatní spolupracující systémy, zejména ISZR. Z pohledu co nejefektivnějšího využití finančních prostředků jak při pořízení, tak při provozu je žádoucí dosáhnout maximální míry kompatibility mezi nově pořizovanou technologickou infrastrukturou a již existující infrastrukturou pro ISKN a ISUI. Dopady pořízení odlišné technologie se na jednotlivých vrstvách liší. Datová vrstva U diskových polí pořízených v rámci infrastruktury pro ISKN a ISUI se již při výběru počítalo s možným dalším rozšířením pro účely RUIAN. Na této vrstvě by pořízení infrastruktury jiným způsobem než rozšířením stávajících diskových polí znamenalo podstatně vyšší pořizovací náklady, neboť by bylo nutné pořídit další dvě nové pole minimálně střední třídy včetně licencí a příslušenství. Pokud se použije varianta rozšíření existujících polí, budou náklady řádově nižší, protože potřebné datové objemy jsou poměrně malé a u některých prvků nebude zřejmě rozšíření třeba. Konkrétné návrh rozšíření pole bude zpracován v detailním návrhu.

Databázové servery Nově pořizované servery pro databázovou vrstvu RUIAN by mohly být z hlediska pořizovacích nákladů založeny na jiné technologii než existující servery pro ISKN a ISUI. V případě jiného HW a operačního systému by ovšem tato situaci přinášela zvýšené náklady na další údržbu a zejména na administraci systému. Zvýšené náklady by se také mohly objevit při integraci takové architektury do stávajícího řešení – např. při zapojení do existujících geografických clusterů. Jednotná technologie dále umožní v případě potřeby lépe přesouvat výkonové zdroje mezi aplikacemi ISKN, ISUI, DP a RUIAN a optimálnější využití licencí.

Aplikační servery Zde je situace prakticky shodná jako u databázových serverů

Strana 87/111


Síťová infrastruktura Předpokládáme, že u většiny síťových komponent bude výkon stávajících komponent dostatečný. V rámci detailního návrhu budou zmapovány případné potřeby na rozšíření. Pořízení nové, odlišné technologie by na této vrstvě bylo značně neekonomické.

Databázový software Pořízení odlišného databázového systému než Oracle by v zásadě bylo možné. Kromě zvýšených nákladů na administraci systému by to ale přineslo zvýšené náklady na vývoj aplikací, protože některé moduly, které by případně mohly fungovat jak v DB ISUI, tak i v DB RUIAN, by bylo nutné kvůli odlišné technologii vyvíjet a testovat dvakrát. Dále by bylo omezeno použití Oracle technologií pro přenos dat, které by v případě shodného databázového systému přinesly vyšší výkon. Vzhledem k tomu, že vzdálený přístup do RUIAN bude současně používat i ISUI, je vznik uvedených problému velice pravděpodobný. I u částí aplikací, které nebudou mít společné moduly, přinese použití dvojího vývojového prostředí zvýšení režijních nákladů na vývoj i testování.

Aplikační software U aplikačního SW je situace obdobná. Je sice možné použít jiný software pro veřejný přístup k ISKN a k ISUI a jiný pro přístup externích uživatelů (editorů) k ISUI, povede to ale ke zvýšeným nákladům na administraci, vývoj i testování.

Strana 88/111


7. Katalog služeb 7.1.

Struktura dokumentu

Výsledný dokument DA bude obsahovat tyto body: •

Shrnutí relevantních požadavků vyplývajících ze zákonů nebo jiných závazných dokumentů.

•

Shrnutí relevantních vstupů z funkční, datové a procesní analýzy.

•

Stanovení obecných požadavků na katalog služeb v prostředí ZR (tato část by měla vzniknout koordinovaně s hlavním architektem a s ostatními architekty ZR a ISZR).

•

Identifikace a kategorizace služeb.

•

Detailní popis jednotlivých služeb, včetně vstupních a výstupních parametrů.

•

Detailní popis struktury rozhraní.

V GA jsou popsány obecné vlastnosti služeb a jejich přehled.

7.2.


7.2.1. Požadavky vyplývající ze závazných dokumentů •

RUIAN musí obsahovat služby pro zápis údajů z obou agendových IS,prostřednictvím kterých jsou údaje zapisovány (ISUI, ISKN).

•

RUIAN musí obsahovat služby pro poskytování údajů jiným přistupujícím AIS.

•

RUIAN musí obsahovat služby pro řešení referenčních vazeb z ostatních ZR.

•

ISKN musí obsahovat službu pro poskytování údajů o vlastnících nemovitostí.

•

ISKN i ISUI musí obsahovat službu pro poskytování údajů o historických údajích prvků, které jsou jejich prostřednictvím zapisovány do RUIAN.

7.2.2. Požadavky vyplývající z funkční, datové a procesní analýzy •

RUIAN musí obsahovat službu umožňující poskytování údajů o změnách údajů. Tento požadavek vyplynul z procesní analýzy, kde je blíže okomentován způsob, jakým přistupující AIS budou pracovat s údaji RUIAN, současně je ale i obsažen v důvodové zprávě návrhu zákona o registrech.

•

Funkce pro zápis údaje musí umožnit konzistentní zápis souvisejících změn více prvků najednou v jedné transakci.

Strana 89/111


7.2.3. Obecné požadavky na katalog služeb v prostředí ZR Návrh katalogu služeb je část návrhu, která musí být ještě důrazněji koordinována napříč jednotlivými registry a ISZR než ostatní části, protože směrem k ostatním AIS bude existovat pouze jeden katalog služeb, který bude spravovat ISZR, a ten bude obsahovat jak služby jednotlivých registrů, tak služby editačních AIS rozšířené o údaje potřebné pro zpracování v ISZR. Služby eGON, vytvářené na vnějším rozhraní ISZR, bude možno funkčně rozdělit do těchto tří skupin: 1

Editační (pouze pro agendy-editory údajů) •

2

Provedení změny v údajích registru.

Informační (pro všechny oprávněné agendy). •

Služby základní - výstup obsahuje pouze údaje z jednoho ZR.

•

Služby složené - výstup vznikne složením odpovědi z dílčích odpovědí jednotlivých ZR, budou tedy složeny ze základních služeb jednotlivých základních registrů.

•

Služby asistenční - zprostředkování komunikace přesměrováním zpráv mezi dvěma AIS na základě registrovaného workflow.

3

Servisní (pro všechny oprávněné agendy). •

Služby notifikační poskytující upozornění na nepřesný referenční údaj jeho editorovi.

•

Služby poskytující informace o změnách v údajích RUIAN (pro účely replikace dat do AIS registrovaných k této službě).

4

Hromadné (výdej dat pro speciální účely). •

Služby poskytující informace o logu přístupu k datům registru pověřeným orgánům veřejné moci.

•

Služby umožňující zaslání hromadného dotazu.

•

Služba umožňující předání kompletní nebo částečné množiny údajů ZR pro vytvoření lokální kopie registru. To bude možné využít (u RUIAN a případně veřejných údajů z ROS) pro snížení zátěže generované agendami s nadstandardními požadavky na data registrů (pravděpodobně MPSV, MF, ČSÚ, případně krajská centra).

Strana 90/111


Předpokládáme, že v rámci návrhu služeb pro jednotlivé registry bude připraven věcný obsah komunikačních funkcí v úrovni vnitřního rozhraní (zde RUIAN-ISZR, ISUI-ISZR a ISKN-ISZR) a na základě těchto funkcí v koordinaci s ostatními architekty bude specifikována jejich podoba na vnějším rozhraní ISZR. Aby byl tento společný katalog služeb konzistentní, bude třeba definovat společná pravidla, kterým se jednotlivé návrhy budou muset následně přizpůsobit. Podle našeho názoru se dá očekávat shoda na následujících principech: 1

Komunikace AIS-ISZR a ISZR-RUIAN (ROB, ROS, RPP) bude založena na výměně XML dokumentů. Využití XML umožní používat obecnější funkce, které mohou lépe splňovat očekávané množství různorodých požadavků jednotlivých AIS než větší množství jednoúčelových funkcí. Použití XML dokumentů je kromě toho zmiňováno v důvodové zprávě návrhu zákonu o registrech.

2

Každý ZR poskytuje (na vnitřním rozhraní) jen svá data. Předpokládáme, že přímá komunikace mezi RUIAN, ROS a ROB nebude povolena, každý ZR pracuje samostatně. Řešení odkazů z referenčních vazeb mezi registry provádí výkonná vrstva ISZR nad základními registry.

3

Při aktualizaci RUIAN posílá agendový systém pouze měněné referenční údaje. Tento princip by měl zabránit zatěžování rozhraní zbytečnými údaji zejména v těch případech, kdy některé údaje mohou být poměrně rozsáhlé (v RUIAN např. lokalizační údaje nebo obrazové údaje – znak, vlajka). ZR nezkoumá, který ze zaslaných údajů se liší od původní hodnoty a mění všechny zaslané, to zajistí editační AIS.

4

Každá funkce vrací v odpovědi status, který jednoznačně určuje, zda a jak byl požadavek zpracován.

5

Každé volání služby na vnějším rozhraní bude obsahovat hlavičku s parametry, které budou sloužit primárně pro zpracování služby ISZR (ověření přístupu, přesměrování apod.). Tato hlavička se ale bude dále předávat i na vnitřní rozhraní ZR zejména pro účely logování. Hlavička by měla obsahovat: •

kód agendy,

•

role, pod kterou je služba požadována,

•

identifikátor volání (generovaný dotazující se agendou),

Strana 91/111


7.3.

•

důvod a konkrétní účel přístupu,

•

uživatelské jméno úředníka vykonávajícího agendu,

•

datum a čas volání služby (s časovým údajem z dotazující se agendy),

•

pro editační služby dále •

příznak, zda dochází ke změně referenčních údajů,

•

údaje o rozhodnutí, na základě kterého se mění referenční údaje.

Obecné vlastnosti služeb

Autorizaci agend a jejich uživatelských rolí vůči jednotlivým službám RUIAN bude řešit kontrolní mechanizmus v ISZR/RPP. Ten bude rovněž řešit formální kontrolu požadavku včetně vyplnění povinných údajů. Předpokládáme, že by tato kontrola byla řešena validací proti příslušnému XSD dokumentu. RUIAN bude ve svých funkcích předpokládat, že tato kontrola proběhla a že v případě nevalidního požadavku nebo nesouladu s pravidly uloženými v RPP bude volání služby zamítnuto na vyšší úrovni. Kontrola pomocí XSD dokumentu bude probíhat i při vstupu do RUIAN. Veškerá volání služeb v RUIAN (ISUI a ISKN) budou logována. Pokud bude služba umožňovat pro nějaký typ dotazu vracet více záznamů, bude vždy specifikován: •

maximální počet záznamů, které funkce může vrátit,

•

maximální počet záznamů, které budou vráceny v rámci jedné odpovědi

Dále může být specifikován: •

maximální počet záznamů, které funkce může vrátit pro danou agendu/roli (pro RUIAN zřejmě nebude uplatněno).

7.4.

Přehled služeb

Předpokládáme, že na základě výsledků procesní, funkční a datové analýzy koordinované s architekty ostatních základních registrů budou definovány vnitřní služby RUIAN, ISUI a ISKN. Tyto služby budou v případě RUIAN dostupné na vnitřním rozhraní ISZR, v případě ISUI a ISKN na rozhraní AIS/ISZR. Těmto vnitřním službám budou odpovídat (v podstatě 1:1) eGON služby

Strana 92/111


publikované na vnějším rozhraní. Kromě toho mohou být vnitřní služby RUIAN použity ISZR k zpracování odpovědí na složené informační služby směřující do jiného registru (např. doplnění údajů o adrese při dotazu na fyzickou osobu do ROB). Přestože zpracování služeb je v ISZR založeno na principu front a je tedy z podstaty asynchronní, pro dotazy na údaje registru je vhodnější použít synchronní komunikaci, aby bylo možné dosáhnout dostatečně krátkých dob odezvy. V následující tabulce je uveden předpokládaný rozsah poskytovaných služeb a náš návrh na rozdělení služeb z pohledu synchronnosti odpovědi, přičemž předpokládáme, že definitivní rozhodnutí bude uděláno až po vzájemných konzultacích architektů jednotlivých registrů a architekta ISZR.

Název služby

Kategorie

Poskytuje

Typ služby

Účel služby

zmena_ISKN

editační

RUIAN

určí ISZR

Zapíše do RUIAN změnovou transakci zaslanou z ISKN

zmena_ISUI

editační

RUIAN

určí ISZR

Zapíše do RUIAN změnovou transakci zaslanou z ISUI

cti_RUIAN

informační

RUIAN

synchronní

Dotaz na konkrétní prvek RUIAN

hledej_RUIAN

informační

RUIAN

synchronní

Požadavek na vyhledání prvku/prvků RUIAN

cti_historii_RUIAN

informační

ISKN, ISUI

určí ISZR

Dotaz na historické údaje konkrétního prvku RUIAN

cti_vlastniky

informační

ISKN

určí ISZR

Dotaz na vlastníky konkrétní parcely nebo stavebního objektu

cti_seznam_zmen_R

servisní

RUIAN

asynchronní

UIAN cti_zmeny_RUIAN

Dotaz na seznam změn v RUIAN za určité období

servisní

RUIAN

asynchronní

Dotaz na obsah změn

Strana 93/111


konkrétních typů prvku RUIAN za určité období reklamace_RUIAN

servisní

ISKN, ISUI

asynchronní

Zaslání informace o nepřesném údaji

cti_log_RUIAN, ISUI

hromadné

RUIAN

asynchronní

Výdej dat o využití údajů

kopie_RUIAN

hromadné

RUIAN

asynchronní

Žádost o poskytnutí kopie dat RUIAN do souboru

castecna_kopie_RUI AN

hromadné

RUIAN

asynchronní

Žádost o poskytnutí částečné kopie dat RUIAN do souboru

Strana 94/111


8. Postup naplnění systému daty Kapitola popisuje postup naplnění systému daty včetně určení zdrojů dat (agendových informačních systémů a případných dalších zdrojů), způsob jejich ověření a způsob jejich průběžné aktualizace.

8.1. Návrh struktury dokumentu: Výsledný dokument DA bude obsahovat tyto body: •


•

Popis současného stavu

•

Stanovení pravidel a metrik

•

Analýza struktury dat jednotlivých AIS

•

Využití systému reklamací pro čištění dat

•

Návrh postupu naplnění a zprovoznění systému

V GA jsou popsána východiska, popis současného stavu, stanovení pravidel a metrik a návrh postupu naplnění. V DA budou zpodrobněny kapitoly Analýza struktury dat a využití systému reklamací pro čištění dat.

8.2. Základní východiska a cíle Situace ohledně základního registru RUIAN je odlišná od situace v základních registrech ROS a ROB. Společně s registrem RUIAN vznikne nový agendový informační systém ISUI, který bude jediným IS pro údržbu agend územní identifikace a adres (agenda nemovitostí zůstane na ISKN), stávající agendové IS budou muset od vlastního pořizování dat přejít na používání dat z RUIAN.

8.2.1. Požadavky vyplývající ze zákona o RUIAN Zákon o RUIAN poměrně přesně stanoví (§66), ze kterých AIS bude ISUI naplněn a které údaje se z jednotlivých AIS budou přebírat: (1)

Správce registru územní identifikace při vytváření registru územní

identifikace zapíše a)

údaje o katastrálních územích a pozemcích z katastru nemovitostí,

Strana 95/111


b)

údaje o stavebních objektech z katastru nemovitostí,

c)

údaje o stavebních objektech nezapisovaných do katastru nemovitostí z registru sčítacích obvodů a budov vedeného Českým statistickým úřadem,

d)

vybrané údaje o stavebních objektech z katastru nemovitostí a z registru sčítacích obvodů a budov;

e)

údaje o druhu a způsobu využití pozemku a jeho technickoekonomické atributy z katastru nemovitostí,

f)

údaje o typu a způsobu ochrany nemovitosti z katastru nemovitostí,

g)

údaje o území obcí z katastru nemovitostí,

h)

údaje o územích městských částí hlavního města Prahy a správních obvodech v hlavním městě Praze z registru sčítacích obvodů a budov,

i)

údaje o územích městských částí a městských obvodů statutárních měst z registru sčítacích obvodů a budov,

j)

údaje o základních sídelních jednotkách z registru sčítacích obvodů a budov,

k)

údaje o částech obce a ulicích z informačního systému vedeného Ministerstvem práce a sociálních věcí,

l)

údaje o adresním místě z informačního systému vedeného Ministerstvem práce a sociálních věcí. (2)

Správci informačních systémů veřejné správy, uvedených v odstavci 1

poskytnou potřebné údaje správci registru územní identifikace, a to nejpozději do 3 měsíců ode dne nabytí účinnosti tohoto zákona. (3)

Správce registru územní identifikace zpracuje údaje poskytnuté podle

odstavců 1 a 2 a nejpozději do 12 měsíců ode dne nabytí účinnosti tohoto zákona je zapíše do registru územní identifikace.

8.2.2. Požadavky vyplývající z funkční, datové a procesní analýzy Ačkoli zákon celkem jasně definuje zdrojové AIS pro různé prvky a jejich atributy, v praxi bude nutné tento požadavek rozšířit vzhledem k následujícím vazbám mezi prvky: •

Adresní místo nemůže existovat bez nadřazeného stavebního objektu. Pokud tedy v UIR-ADR bude existovat adresní místo, pro které nebude existovat příslušný stavební objekt převzatý z ISKN nebo RSO, bude nutné stavební objekt převzít z UIR-ADR. Takové objekty by měly být označené a při čištění dat prověřené.

Strana 96/111


•

Stavební objekty z RSO, které mají v RSO adresní místo, ale ne v UIR-ADR. Považujeme za rozumné, aby spolu s objekty byla do RUIAN přebírána i příslušná adresní místa z RSO. Spolu s těmito adresními místy je pak nezbytné převzít i příslušné ulice, pokud v UIR-ADR neexistují.

•

Budovy z ISKN s číslem domovním, ke kterým není adresní místo. Považujeme za rozumné k těmto objektům automaticky vygenerovat adresní místo bez ulice a čísla orientačního, které bude ale označeno jako nesprávné a bude muset být zkontrolováno v procesu čištění dat.

•

Definiční bod adresního místa není v UIR-ADR vyplněn ve všech adresních místech. V těchto případech navrhujeme převzít definiční bod z adresního místa z RSO, pokud se podaří obě adresní místa z obou registrů přesně ztotožnit.

8.2.3. Cíle Cílem dokumentu bude popsat koncepci naplnění ISUI a RUIAN daty ze stávajících AIS, která bude sloužit k projednání navrženého postupu se zainteresovanými stranami (zadavatel, ostatní řešitelé registrů, provozovatelé současných registrů), a podrobně popsat metodiku, která bude sloužit realizátorovi pro vytvoření systému migrace a její provedení.

8.3. Popis současného stavu 8.3.1. Stávající agendové informační systémy V současné době je ve státní správě vedeno a používáno pět hlavních registrů (agendových informačních systémů), které slouží k evidenci agend územní identifikace, adres a nemovitostí (vždy však pouze některých prvků a údajů) a které je možno použít jako zdroj dat pro prvotní naplnění ISUI. Tyto systémy se liší primární oblastí použití (účel, pro který systém vznikl), dalšími oblastmi využití (další agendy, které používají data z tohoto systému), rozsahem a strukturou evidovaných prvků, rozsahem údajů, které evidují pro jednotlivé prvky, primárními zdroji dat (zdroje nezávislé na ostatních agendových systémech), sekundárními zdroji dat (data přebíraná od jiných agendových systémů), poskytovanými službami, funkcemi atd. •

Územně identifikační registr adres (UIR-ADR). Správcem je Ministerstvo práce a sociálních věcí (MPSV)

•

Informační systém katastru nemovitostí (ISKN). Správcem je Český úřad zeměměřický a katastrální (ČÚZK)

Strana 97/111


•

Registr sčítacích obvodů (RSO). Správcem je Český statistický úřad (ČSÚ)

•

Informační systém evidence obyvatel – subsystém adresy (ISEO-ADR). Správcem je Ministerstvo vnitra (MV)

•

Databáze dodacích míst ČP (DDM). Správcem je Česká pošta (ČP)

8.3.1.1. Územně identifikační registr adres (UIR-ADR) Primární oblast

UIR-ADR vznikl pro potřeby IS státní sociální podpory a úřadů práce,

použití

kdy bylo třeba vytvořit spolehlivý zdroj adres zejména z důvodu některých dávek SSP vázaných na adresu.

Další oblasti použití

Státní správa (např. Registr živnostenského podnikání, Státní fond rozvoje bydlení, ePUSA), soukromý sektor (např. Telefónica O2, energetické, plynárenské a vodárenské podniky, pojišťovny, krajské záchranné systémy).

Primární zdroje dat

Údaje o ulicích, objektech a adresách zadávané správci regionů (okresy, ORP, obce,…).

Sekundární zdroje

Měsíční aktualizace údaji o poštách a PSČ z DDM od České pošty,

dat

týdenní aktualizace adresními daty z ISEO-ADR.

Poskytované služby

Data v různých formátech (Oracle, MS SQL Server,…) s příslušným programovým vybavením, aktualizační soubory (1x týdně), webové aplikace pro prohlížení dat a ověřování adres, systém reklamací, mapový server.

Zvláštní funkce

Systém reklamací, kam registrovaní uživatelé mohou vkládat reklamace na chybné údaje v ulicích, objektech, adresách a PSČ.

Údaje pro RUIAN

Údaje o částech obcí, ulicích a adresách.

dle zákona Poznámky

-

Strana 98/111


8.3.1.2. Informační systém katastru nemovitostí (ISKN) Primární oblast

Evidence popisných a geodetických informací o nemovitostech

použití

v České republice.


Státní správa (např. Pozemkový fond ČR, MZe, MF, samospráva,…), soukromý sektor (např. realitní kanceláře).


Data katastrálních úřadů.

Sekundární zdroje

Data získaná externě, např. definiční body.

dat Poskytované služby

Informace o nemovitostech, jejich vlastnictví a jiných právech, zobrazení katastrálních map.

Zvláštní funkce

Informace o vlastnících nemovitostí.

Údaje pro RUIAN

Údaje o katastrálních územích, parcelách a některé údaje o

dle zákona

stavebních objektech.

Poznámky

Neeviduje adresní místa.

8.3.1.3. Registr sčítacích obvodů (RSO) Primární oblast

Evidence většiny standardních prvků prostorové identifikace v České

použití

republice včetně základních sídelních jednotek, objektů a adres pro statistické služby.


Státní správa (např. Portál veřejné správy, ministerstva), soukromý sektor (např. pojišťovny, správci sítí, záchranné systémy).


Stavební úřady, sčítání lidu a bytů.

Sekundární zdroje

Data z ISKN.


Data s příslušným programovým vybavením, aktualizační soubory (4x ročně), webové aplikace pro prohlížení dat, geografické informace.

Zvláštní funkce

Informace o vlastnících nemovitostí.

Strana 99/111


Údaje pro RUIAN

Údaje o územích městských částí hlavního města Prahy a správních

dle zákona

obvodech v hlavním městě Praze, údaje o územích městských částí a městských obvodů statutárních měst, údaje o základních sídelních jednotkách a některé údaje o objektech.

Poznámky

-

8.3.1.4. Informační systém evidence obyvatel – subsystém adresy (ISEO-ADR) Primární oblast

Evidence adres pro potřeby evidence obyvatel České republiky

použití

(vydávání občanských průkazů, cestovních dokladů, řidičských průkazů,…).


Sekundární zdroj dat pro UIR-ADR.


Údaje o ulicích a adresách z obcí.

Sekundární zdroje

-


Aktualizační soubory (libovolně podle data), webová aplikace pro prohlížení a vyhledávání adres.

Zvláštní funkce

-

Údaje pro RUIAN

-

dle zákona Poznámky

Vlastní struktura lokality odlišná od standardní územní identifikace. Nedostatečná kontrola zadávaných dat: duplicitní názvy ulic (např. Němcové, B. Němcové, Boženy Němcové), nedůsledná kontrola datumů (např. datum vzniku adresy může být dřívější než datum vzniku nadřízené ulice) ap.

Zákon o RUIAN neuvádí registr ISEO-ADR jako zdroj dat. Adresy jsou ale velmi důležitou složkou budoucího ROB, který bude vznikat v největší míře právě z ISEO. Problematiku zahrnutí ISEO-ADR do přípravy RUIAN bude nutné konzultovat se zadavateli obou registrů (RUIAN a ROB) a bude řešena až v detailní analýze. Navrhujeme, aby registr ISEO-ADR byl použit jako jeden z registrů pro ověření správnosti RUIAN.

Strana 100/111


8.3.1.5. Databáze dodacích míst ČP (DDM) Primární oblast

Evidence adres pro potřeby doručování zásilek Českou poštou

použití Další oblasti použití

Sekundární zdroj dat (PSČ) pro UIR-ADR a další registry adres i jiné informační systémy.


Vlastní evidence adres pro účely doručování zásilek, správa databáze rozdělena do osmi regionů.

Sekundární zdroje

-


Poskytnutí celé databáze, webová aplikace na zjištění PSČ k dané adrese.

Zvláštní funkce

-

Údaje pro RUIAN

-

dle zákona poznámky

-

Zákon o RUIAN neuvádí registr DDM jako zdroj dat adres, pouze konstatuje, že RUIAN obsahuje doplňkové údaje potřebné pro účely poštovních služeb, které je oprávněn zapisovat do RUIAN správce RUIAN na základě dohody s držitelem poštovní licence. Protože registr DDM představuje průběžně prověřovanou (při doručování zásilek) databázi adres, navrhujeme, aby DDM byl použit jako jeden z registrů pro ověření správnosti RUIAN.

8.3.2. Porovnání a konsolidace dat Na základě usnesení vlády České republiky ze dne 12. října 2005 č. 1306 k registru územní identifikace, adres a nemovitostí bylo v roce 2007 ve spolupráci MPSV, ČÚZK, MV a ČSÚ provedeno porovnání čtyř registrů – UIR-ADR, ISKN, RSO, ISEO-ADR. Zjištěné neshody jsou průběžně řešeny pomocí nástrojů registru UIR-ADR (systém reklamací) a výsledky vkládány do tohoto registru. Údaje o řešení neshod jsou k dispozici i pro zbylé tři registry. Tímto postupem se alespoň částečně sjednocuje datová základna pro vybudování ISUI/RUIAN.

Strana 101/111


8.4. Stanovení pravidel a metrik 8.4.1. Pravidla pro posouzení chyb v prvcích Pro každý prvek a každý atribut budou v detailní analýze stanovena pravidla, podle kterých se bude posuzovat správnost údajů v ISUI (ISKN). Tato pravidla budou mít různou závažnost, která se uplatní zejména ve dvou krocích při plnění systému - při převzetí dat z AIS do ISUI pro odmítnutí prvků s nejzávažnějšími chybami a pak při rozhodování, jakým způsobem a za jakých podmínek se bude prvek publikovat do RUIAN. Problematika přesného postupu naplnění RUIAN z ISUI bude řešena až v detailní analýze, protože je možných několik přístupů, které bude třeba analyzovat. Následující tabulka ukazuje předběžný návrh klasifikace závažnosti pravidel:

Klasifikace závažnosti pravidel Kód Závažnost

Z1

Závažná

Prvek

Prvek lze

lze

označit

přijmout

jako

do ISUI

správný

ne

ne

chyba

Popis

Prvek nelze použít, do ISUI nebude zahrnut. Příklady: Číslo domovní větší než 9999; chybějící nebo neexistující ID části obce ve stavebním objektu s přiděleným číslem domovním.

Z2

Závažný

pouze

ano, pouze

Dva nebo více prvků z jednoho AIS, které

konflikt mezi

jeden

ten jeden

samy o sobě nejsou chybné, ale nemohou být

prvky

prvek

prvek

oba zahrnuty do ISUI. Před naplněním bude

(v závislosti třeba rozhodnout, který z prvků bude do ISUI na dalších

zahrnut a který odmítnut. Předpokládáme, že

chybách)

takových konfliktů bude minimum. Příklad: Dva stavební objekty mající shodnou část obce a číslo domovní, ale různé ID v jednom AIS.

Strana 102/111


Kód Závažnost

Z3

Chybějící či

Prvek

Prvek lze

lze

označit

přijmout

jako

do ISUI

správný

ano

po

Méně závažné chyby, kdy lze prvek přijmout

prověření

s výhradou a chybnou hodnotu lze vynechat

chybný

Popis

referenční

nebo upravit. Příslušný údaj je do rozhodnutí

údaj, lze

editorem označen jako nesprávný.

vynechat

Příklady: Vyplněné číslo orientační v adrese bez ulice; číslo orientační větší než 999.

Z4

po

Dva nebo více prvků, které samy o sobě

prvky

prověření,

nejsou chybné, ale nemohou všechny ve

stejného typu

pouze

skutečnosti existovat zároveň. Při čištění dat

jeden

je třeba rozhodnout, který z nich je správný.

prvek

Příklad: Dvě adresní místa patřící ke stejnému

Konflikt mezi

ano

stavebnímu objektu ležící ve stejné ulici, přičemž jedno z nich má vyplněné číslo orientační a druhé ne. Z5

Chybějící či

ano

ano

Méně závažné chyby, kdy lze prvek přijmout,

chybný

příslušný údaj bude doplněn či opraven

nereferenční

později.

údaj

Příklad: Nevyplněný údaj o typu ochrany nemovitosti.

Z6

Podezřelý

ano

ano

Prvek nebo údaj, který splňuje všechny

prvek nebo

podmínky platnosti, ale jsou důvody ho

údaj

označit jako podezřelý pro prověření při čištění dat. Příklady: Stavební objekt, který se vyskytl pouze v jednom ze tří zdrojových AIS; adresní místo, jehož definiční bod leží „příliš daleko“ od definičního bodu příslušného stavebního

Strana 103/111


Kód Závažnost

Prvek

Prvek lze

lze

označit

přijmout

jako

do ISUI

správný

Popis

objektu.

Pravidla spolu s odpovídajícími metrikami budou dále sloužit pro průběžné vyhodnocování kvality dat. Podrobný přehled pravidel pro každý prvek a údaj bude uveden v detailní analýze, zde uvádíme příklady některých pravidel pro adresní místo:

Příklady pravidel pro adresní místo: Kód Metrika

Popis

Závažnost

A1

Povinnost odkazu

Odkaz na stavební objekt v adresním místě je

Z1

na stavební

povinný.

objekt. A2

A3

Cizí klíč na

Stavební objekt s ID uvedeným v adresním místě

Z1

stavební objekt.

musí existovat v seznamu stavebních objektů.

Jednoznačnost

V rámci jednoho stavebního objektu nesmí existovat

adresního místa

více adresních míst se shodnými identifikačními údaji

Z2

(ulice, číslo orientační). A4

Cizí klíč na ulici.

Pokud je ID ulice uveden, pak ulice s tímto ID musí

Z3

existovat v seznamu ulic. A5

Hodnota čísla

Hodnota čísla orientačního je v rozmezí 1 – 999.

Z3

Písmeno čísla

Písmeno čísla orientačního je písmeno anglické

Z3

orientačního

abecedy (na velikosti nezáleží, ale v rámci obce by

orientačního A6

měla být použita jedna velikost). A7

Vztah čísla

Číslo orientační smí být zadáno pouze tehdy, je-li

Z3

Strana 104/111


Kód Metrika orientačního a

Popis

Závažnost

zadána ulice.

ulice A8

Vztah hodnoty a

Písmeno čísla orientačního smí být zadáno pouze

písmena čísla

tehdy, je-li zadána hodnota čísla orientačního.

Z3

orientačního A9

Nevyplněný

Definiční bod adresního místa není vyplněn.

Z3

A10 Konflikt adresních

V rámci jednoho stavebního objektu nesmí existovat

Z4

míst v rámci

dvě adresní místa, kdy jedno má zadánu ulici a jedno

jednoho

ne.

stavebního

Příklad: Cheb 456 X Lidická 465, Cheb, kde 465 je

objektu

číslo popisné.

definiční bod

Stejně tak nesmí v rámci jednoho stavebního objektu existovat dvě adresní místa, ležící v jedné ulici, přičemž jedno má zadáno číslo orientační a druhé ne. Příklad: Lidická 465, Cheb X Lidická 465/13, Cheb, kde 465 je číslo popisné a 13 číslo orientační. A11 Chybné nebo nevyplněné PSČ A11 Adresní místo je pouze v RSO

U adresního místa je vyplněno chybné PSČ nebo

Z5

není vyplněno vůbec. Toto adresní místo bylo do ISUI převzato pouze

Z6

z RSO, v UIR-ADR nebylo. Je nutno prověřit, jestli ve skutečnosti existuje.

A12 Shodné číslo

Číslo orientační uvedené u adresního místa je

Z6

domovní a číslo

shodné s číslem domovním uvedeným u příslušného

orientační

objektu. Toto může ve skutečnosti nastat, ale často to může být chyba pramenící z neznalosti pravidel přidělování čísel popisných a orientačních, proto navrhujeme takováto adresní místa označit jako

Strana 105/111


Kód Metrika

Popis

Závažnost

podezřelá a nechat prověřit. A13 Podezřelý definiční bod

Definiční bod adresního místa leží „příliš daleko“

Z6

(vzdálenost je nutno definovat v detailní analýze) od definičního bodu příslušného stavebního objektu.

8.4.2. Metriky Pro sledování kvality dat budou stanoveny elementární a sumární metriky. Elementární metrikou zde rozumíme procento prvků, které splňují dané pravidlo. Pro celkový přehled o stavu dat budou vytvořeny sumární metriky (pro celý ISUI, jednotlivé prvky, agendy popř. podle územního členění), které budou vhodným způsobem sumarizovat elementární metriky pro získání celkového přehledu o procesu čištění dat a pro sledování provozu celého systému. Kromě metrik sledující kvalitu dat a její změny přímo, budou navrženy i metriky sledující kvalitu dat prostřednictvím vyhodnocování reklamací. Bude sledován stav reklamací na jednotlivé typy prvků k danému časovému okamžiku nebo za určité období. Budou odlišeny interní reklamace (viz dále) vzniklé při plnění ISUI od reklamací zadaných vnějšími uživateli. Podrobněji budou metriky popsány v detailní analýze.

8.5. Analýza struktury dat jednotlivých AIS V DA bude provedena analýza tabulek a atributů prvků z jednotlivých AIS, ze kterých se bude plnit ISUI, a jejich vlastností (datové typy, rozsahy hodnot, omezení ap.). Pro účely detailní analýzy je třeba zajistit popis datových struktur jednotlivých AIS. Pro UIRADR, RSO a DDM lze struktury získat z veřejných zdrojů, Pro ISKN od zadavatele. Pokud pro ověření dat bude použita databáze ISEO-ADR, je třeba zajistit získání její struktury z MV. Dále je třeba zajistit zdroj pro znaky a vlajky a mluvnické charakteristiky názvů.

8.5.1. Datová základna ISUI Datová základna ISUI bude sloužit pro prvotní shromáždění veškerých údajů pro ISUI ze všech zdrojů. Datová struktura datové základny ISUI bude rozšířením datové struktury ISUI: •

o identifikátory entit z jednotlivých evidencí Strana 106/111


•

o pomocné údaje potřebné k řízení migrace

8.6. Využití systému reklamací pro čištění dat Důležitým úkolem po naplnění ISUI daty z jednotlivých AIS bude jejich čištění, tzn. odstranění chyb, vyřešení nesrovnalostí, doplnění chybějících údajů ap. K zajištění této činnosti je potřebné vytvořit pro Editory dobrou podporu, aby bylo možné potřebné údaje snadno vyhledávat a opravovat. Protože k podobnému úkolu (vyhledávání a odstraňování chyb, které byly v RUIAN nalezeny externími uživateli) bude sloužit systém reklamací, navrhujeme pro čištění dat využít funkce tohoto systému, které budou vytvořeny v ISUI a ISKN. Upozornění na chyby a nesrovnalosti zjištěné při kontrole dat po naplnění ISUI budou vhodným způsobem do systému vloženy jako reklamace, které pak budou řešeny standardními prostředky systému reklamací. Podrobnější popis způsobu generování reklamací na základě zjištěných chyb a nesrovnalostí bude uveden v detailní analýze.

8.7. Návrh postupu naplnění a zprovoznění systému V této kapitole na základě analýzy struktury dat zdrojových AIS podle předešlé kapitoly podrobně navrhneme a popíšeme etapy a jednotlivé kroky naplnění ISUI daty z AIS a zprovoznění RUIAN. Zde uvádíme stručnou představu:

8.7.1. Vlastní naplnění ISUI ,vytvoření datové základny ISUI V této etapě bude provedeno vlastní vytvoření datového základu ISUI podle požadavků uvedených v kapitole Základní východiska a cíle. Tato etapa by měla být co nejkratší, protože je nutné co nejdříve po začátku plnění ISUI zahájit editaci údajů v ISUI a umožnit ostatním AIS a základním registrům postupné napojení se na RUIAN. 8.7.1.1. Příprava dat z jednotlivých zdrojů •

Převzetí ostrých dat od jednotlivých AIS

•

Vytvoření datových struktur pro jednotlivé AIS

•

Migrace dat do připravených datových struktur

•

Kontrola dat pro ISUI

Strana 107/111


8.7.1.2. Vytvoření datových struktur datové základny pro ISUI 8.7.1.3. Vytvoření Naplnění datové základny pro ISUI V postupných krocích bude základna naplněna z databázových schémat jednotlivých AIS. Pro každý prvek se převezmou i ID z jednotlivých AIS, aby bylo zřejmé, ve kterých AIS byl prvek evidován. •

Naplnění bezesporných vyšších prvků

•

Naplnění ZSJ z RSO

•

Naplnění ulic z UIR-ADR

•

Naplnění stavebních objektů z ISKN

•

Naplnění stavebních objektů z RSO

•

Naplnění adresních míst z UIR-ADR

•

Doplnění potřebných adresních míst a ulic z RSO

•

Doplnění, oprava PSČ podle DDM

8.7.2. Naplnění ISUI a reklamací z datové základny ISUI Bude provedena analýza dat vložených do datové základny a rozhodne se, která data budou vložena přímo do ISUI a která pouze do reklamací. •

Naplnění bezesporných vyšších prvků včetně ZSJ

•

Naplnění ulic, stavebních objektů a adresních míst

Přenos ulic, stavebních objektů a adresních míst do ISUI nebo reklamací podle pravidel, která budou podrobně popsána v detailní analýze. •

Analýza chybějících údajů

•

Zaslání seznamu chybných prvků na příslušné AIS

Seznam prvků označených jako podezřelé či nesprávné, a těch, které byly převzaty pouze do reklamací, bude odeslán na jednotlivé AIS, protože tyto prvky budou pravděpodobně později působit problémy při napojení AIS na RUIAN. Tímto budou jednotlivé AIS na tyto možné problémy včas upozorněny. 8.7.2.1. Synchronizace ISUI a ISKN •

Logická konsolidace dat mezi ISUI a ISKN

Je pravděpodobné, že při postupném plnění ISUI daty ze tří AIS dojde k nekonzistenci dat mezi ISUI a ISKN (např. hranice ZSJ nebudou odpovídat hranicím Katastrálních Strana 108/111


území, ID parcel z ČSÚ nebudou existovat v ISKN ap.). Zjištěné nekonzistence budou označeny jako nesprávné údaje pro pozdější čištění dat. •

Časová synchronizace dat mezi ISUI a ISKN

ISKN na rozdíl od ISUI je systém, který již existuje a ve kterém jsou data průběžně aktualizována. Z toho plyne, že po naplnění dat do ISUI bude třeba nějakým způsobem zajistit průběžnou synchronizaci dat mezi ISKN a ISUI tak, aby v okamžiku naplnění RUIAN daty z ISKN a ISUI nedošlo v RUIAN k nekonzistencím. 8.7.2.2. Vyhodnocení elementárních a sumárních metrik Budou vyhodnoceny elementární a sumární metriky. Budou sestaveny podrobné statistiky s ohledem na existenci jednotlivých prvků v různých AIS a podrobné statistiky o chybách. 8.7.2.3. Ověření správnosti dat porovnáním proti dalším AIS Data v ISUI budou porovnána s daty dalších AIS, která budou k dispozici. Navrhujeme použít ISEO-ADR (pouze adresy, na kterých mají bydliště žijící osoby), popř. také DDM. 8.7.2.4. Zahájení editace dat v ISUI. V této chvíli bude možné zahájit editaci všech prvků v ISUI editory jednotlivých agend.

8.7.3. Pilotní povoz RUIAN V rámci pilotního provozu systému budou data již editována v ISUI a ISKN a předávána do RUIAN, údaje v RUIAN však zatím nebudou používány jako referenční, tzn., nebudou závazné pro ostatní AIS státní správy. Nebude ještě zprovozněn systém reklamací pro externí uživatele, funkce systému reklamací budou využity pro čištění dat. Podle zadávacích podmínek musí být pilotní provoz zahájen nejpozději 1. 7. 2010. Přesný začátek pilotního provozu určí zadavatel podle stavu převzatých dat a připravenosti systému. 8.7.3.1. Zprovoznění ISUI pro externí editory •

Zahájení editace dat v ISUI.

•

Prvotní naplnění RUIAN daty z ISKN a ISUI

•

Čištění dat editory jednotlivých agend

Strana 109/111


8.7.3.2. Zprovoznění RUIAN Bude nutné editory vhodným způsobem motivovat popř. vynaložit určitý tlak, aby většina chyb a nejasností vzniklých při plnění ISUI byla vyřešena do data ukončení pilotního a začátku ostrého provozu systému. •

Prvotní naplnění RUIAN daty z ISKN a ISUI

Bude provedeno v závislosti na stupni čištění dat (procentu vyřízených reklamací vzniklých při vytváření ISUI a procentu údajů označených za nesprávné). Údaje v RUIAN však zatím nebudou používány jako referenční. •

Aktualizace RUIAN změnami z ISUI

•

Zpřístupnění systému reklamací externím uživatelům

•

Příprava jiných IS na přebírání dat z RUIAN

Bude vhodné, aby na přebírání dat z RUIAN co nejdříve přešly AIS, které předaly editaci dat do ISUI. Čím dříve ukončí vlastní editaci dat, tím menší problémy s napojením na RUIAN budou mít. Paralelně bude třeba také řešit připojení nových základních registrů RPP, ROS a ROB k RUIAN.

8.7.4. Ukončení pilotního provozu RUIAN, ISUI, ISKN Podle zadávacích podmínek musí být pilotní provoz ukončen nejpozději 1. 7. 2011. Ukončení pilotního provozu znamená prohlášení příslušných údajů v RUIAN za referenční a zahájení ostrého provozu celého systému včetně zadávání reklamací. Přesné datum ukončení pilotního provozu určí zadavatel podle stavu čištění dat.

Strana 110/111


AIS

data UIR-ADR

UIR-ADR data nevyhovující struktuře podle dokumentace

ISKN

ISKN

RSO

Kontrola struktury podle dokumentace převzaté od správců AIS.

převzatá data vlastní formáty

RSO UIR-ADR

ISKN

RSO

Pomocné struktury

data nevyhovující podmínkám ISUI Kontrola pro přípustnost převzetí do ISUI.

Datová základna ISUI Analýza dat. Data do ISUI a do reklamací.

ISUI Reklamace zamítnuté reklamace

ISUI Řešení reklamací

RUIAN RUIAN

Migrace dat

Strana 111/111

Globální architektura RÚIAN

Recommend Documents