Recenze audioknihy Letecké katastrofy a jejich vyšetřování

Jako příznivce dokumentárního televizního seriálu Letecké katastrofy, který má již 180 epizod (neviděl jsem všechny), jsem uvítal stejnojmennou knihu od Lukáše Musila, která vyšla v audio verzi. Kniha průřezově popisuje 40 leteckých havárií, které se staly od roku 1946.

Jednotlivé kapitoly jsou samostatné události a jsou jasně strukturované do částí:

úvod – průběh události – příčina – přijatá opatření

Pokud znáte zmíněný TV seriál, budete jako doma, kniha je mu velmi podobná. Proti seriálu má kniha z mého pohledu dvě výhody a jednu nevýhodu.

Jako první výhodu považuji fakt, že je kniha u každého příběhu oproštěna od úvodní omáčky. V TV seriálu je vždy na začátku každé epizody poměrně dlouhá pasáž ve stylu:

„Pan Novák se ten den vracel z Londýna, kde byl na služební cestě. Letadlo stihl na poslední chvíli, protože cestou na letiště byla velká dopravní zácpa“. 

Tato část tvoří odhadem ¼ celkového času a nikdy mě nebavila. Naopak kniha čtenáře/posluchače na začátku kapitoly rychle seznámí se základními fakty (číslo letu, datum, stručný popis,…) a pak již přejde k vlastnímu popisu události.

Druhá výhoda knihy proti TV verzi je fakt, že se neopakují popisy/vysvětlování termínů a pojmů, např. „rychlost V1“, „střih větru“, „ILS“ atd. Každý pojem je vysvětlen pouze při prvém výskytu. Klade to sice vyšší nároky na posluchače, který si je musí pamatovat, ale není jich mnoho.

Pozn.: Protože jsem poslouchal audio verzi tak nevím, zda není součástí tištěné knihy rejstřík.

Dostávám se k nevýhodě, kterou je pro mě absence podrobnějšího popisu vyšetřování. Kniha jde většinou přímo k příčině události. TV seriál byl v této oblasti popisnější, protože součástí byly i zajímavé slepé uličky, do kterých se vyšetřovatelé často dostali. Toto ořezání je zřejmě daň za to, že kniha obsahuje 40 příběhů, které nemohly být moc dlouhé. Raději bych uvítal při zachování celkové délky třeba jen 20 příběhů, ale s podrobnější vyšetřovací fází.

Součástí obdobných dokumentárních děl bývají často nepřesnosti, které pozná ten, kdo se v dané problematice lépe orientuje. Jsou většinou způsobeny nutným zjednodušováním, aby text nebyl příliš odborný a problematiku pochopil i laik. Já, v této oblasti velký laik, jsem nic nezaznamenal.

Audio zpracování je na dobré úrovni, Valérie Zawadská se dobře poslouchá. Audioverze je pojata částečně jako dramatizace, takže se například při přehrávání rozhovorů mezi letadlem a řídící věží pokouší navodit dojem vysílačky, někdy až moc na úkor srozumitelnosti. Jednotlivé kapitoly jsou odděleny krátkými hudebními předěly, které neruší. Rozlišeny jsou i části s vysvětlováním pojmů. Celkově k režii nemám větší výhrady.

Knihu hodnotím 80 % a nebojím se ji doporučit příznivcům literatury faktu. Je přehledná, informativní a nezahlcuje čtenáře zbytečnostmi, byť bych uvítal podrobnější popis cest, kterými se vyšetřování ubíralo. Určitě si rád poslechnu i druhý díl Letecké katastrofy 2, který ale zatím nevyšel v audio verzi.

Poznámka na závěr: Jako nejděsivější bych vybral kapitolu Daň za pokrok, která popisuje příběh poválečného vývoje dálkového letounu Comet. Počet havárií je odstrašující. Byla to opravdu „Daň za pokrok“, které byla způsobena pohybem v tehdy neprobádaných oblastech.

Letecké katastrofy a jejich vyšetřování

Žánr: Literatura faktu

Tištěná verze

Autor: Lukáš Musil

Vydáno: 2018, Nakladatelství Regia

Počet stran: 288

ISBN: 978-80-87866-39-9

Audiokniha

Délka: 10 hodin 33 minut

Interpret: Valérie Zawadská

Hry, které se vejdou do boot sektoru

David Murray (The 8-Bit Guy) na svém Youtube kanále zveřejnil krátké a pěkně zpracované video o hrách, které se vejdou do boot sektoru. To znamená, výsledná velikost po zkompilování nepřesáhne jak 512 byte.

Je samozřejmostí, že takové hry se píší v nízkoúrovňovém Assembleru nebo strojovém kódu, což byla běžná praxe programování her na 8bitech. Já si spíše z dob 286 pamatuji temnější stránky - boot viry (u nás mezi nejznámější patří asi slovenský OneHalf).

Ale zpět ke hrám. Pokud se chcete inspirovat nebo si vyzkoušet nějakou takovou hru naprogramovat, tak se podívejte na stránky mexického vývojáře jména Óscar Toledo Gutiérrez, který se právě takovýmto programováním zabývá. Mezi jeho díla mimo jiné patří:

• Tinyasm (8086/8088 assembler)
• bootOS operating system
• bootBASIC interpreter (opravdu funkční základní interpretr BASIC)
• bootRogue game
• Invaders game
• Pillman game

Až na Tinyasm se vše vejde do 512 byte. Všechny zdrojové kódy jsou k dispozici na jeho Githubu.

Oskar o programování her napsal i pěknou knihu Programming Boot Sector Games.

Knihu lze koupit v tištěné verzi jako paperback nebo hardcover nebo a jako e-book (úplně dole na stránce, která vypadá sice podezřele, ale nákup přes PayPal proběhl bez problémů a dostanete PDF). V knize jsou vysvětleny i základy assembleru.

Doporučit mohu také výukové materiály Nicka Blundella, zejména Writing a Simple Operating System.

Vyzkoušení

Připravil jsem krátký postup, jak si vyzkoušet takovou hru zprovoznit:

• stáhněte si a nainstalujte emulátor DosBox
• stáhněte si The Netwide Assembler (verze 2.14 pro Windows x64), archiv si rozbalte např. do složky "C:\NASM"
• stáhněte si zdrojový kód (pillman.asm) hry Pillman a uložte ho např. do složky "C:\Pillman"
• spusťte příkazový řádek Windows a zkompilujte hru pomocí příkazu
  "C:\NSAM\nasm.exe -f bin C:\Pillman\pillman.asm -o C:\Pillman\pillman.bin"
• spusťte DosBox a zadejte v něm příkaz "boot C:\Pillman\pillman.bin"

Pokud chcete něco jednoduššího, tak můžete zkusit obyčejné "Hello" z výše uvedeného materiálu Writing a Simple Operating System (PDF):

; A simple boot sector that prints a message to the screen using a BIOS routine.
;
mov ah, 0x0e ; int 10/ ah = 0eh -> scrolling teletype BIOS routine
mov al, 'H'
int 0x10
mov al , 'e'
int 0x10
mov al , 'l'
int 0x10
mov al , 'l'
int 0x10
mov al , 'o'
int 0x10
jmp $ ; Jump to the current address ( i.e. forever )
;
times 510 -($-$$) db 0 ; Pad the boot sector out with zeros
;
dw 0xaa55 ; Last two bytes form the magic number so BIOS knows we are a boot sector.



Jestli vás tato oblast zaujala, přidávám pár užitečných odkazů:

• www verze v dobách DOSu známého a skvělého TechHelp manuálu
• DOS verze TechHelp 6, přímý odkaz na soubor
• pěkná učebnice Assembleru 

Ještě jsi pamatuji, že existovala česká verze TechHelpu, která se jmenovala SYSMAN. Bohužel ji už ale nemohu nikde najít. Pokud o ní víte, dejte prosím odkaz do diskuze.

Odstranění dynamicky přidaného rozložení klávesnice ve Windows bez rebootu

Poznámky na úvod:
1) Nenaleznete zde postup, jak nechtěnému přidávání zabránit. Je zde jen návod, jak ho jednoduše a bez rebootu odstranit.
2) Pro popis řešení bez úvodní omáčky skočte přímo na řešení.

Popis problému

Ve Windows 10 se občas stane, že se do nastavení rozložení klávesnice bez přičinění uživatele přidá nové rozložení. V mém případě se mi přidává do jazyka "Čeština" rozložení QWERTZ. Myslel jsem, že se mi tento problém podařilo vyřešit tak, že jsem pomocí CTRL+SHIFT nepřepínal klávesnice, ale jazyky:

Bohužel se ukázalo, že to byla mylná teorie, protože se mi to dnes opět po delší době stalo. Zajímavé je, při jaké příležitosti - spuštění hry pomocí Steam klienta s nastavením na Češtinu. Je to pěkně vidět na videu: 

Před spuštěním hry mám pouze dvě rozložení - anglické a české QWERTY. Následně spustím hru nastavenou na angličtinu, rozložení se nezmění. Pak přepnu hru do češtiny, spustím ji a hned se automaticky přidá QWERTZ rozložení, viz čas 00:30, kdy se změní indikátor rozložení na hlavním panelu. 

Není to jediná situace, kdy to nastane. S tímto problém se potýká hodně uživatelů Windows. Tomášovi Vítovi se to např. stává s Outlookem. 

Protože se mi to konečně podařilo v jednom případu odchytit a bez problémů opakovaně reprodukovat, tak jsem zkoušel jsem googlovat a aplikovat několik postupů ( např. https://twitter.com/RadekHulan/status/1076125557128155137 nebo https://superuser.com/questions/1092246/how-to-prevent-windows-10-from-automatically-adding-keyboard-layouts-i-e-us-ke ), které tomu měly zabránit. Bohužel žádný mi nefungoval.

Začal jsem tedy řešit, jak se tohoto rozložení jednoduše zbavit. Problém je v tom, že to rozložení se do Windows přidá a zároveň nepřidá. Zní to zvláštně. Představte si to tak, že se sice ukazuje na hlavním panelu (taskbaru), ale v nastavení Windows není:

Vlevo je vidět, že v nastavení Windows je pro češtinu pouze jedno rozložení ("Česká QWERTY"), přesto jsou ale v panelu jazyků pro češtinu rozložení dvě - "Česká QWERTY" a "Česká" (to je ona dynamicky přidaná QWERTZ). 

Pozn: Pokud byste měli rozložení QWERTZ záměrně přidané, vypadlo by to v nastavení Windows takto:

Důsledky toho, že rozložení je přidané pouze "za běhu" a není v nastavení jsou dva:

• po rebootu rozložení zase zmizí,
• bez rebootu nelze odstranit (není "co" odstranit).

Řešení

Jak už ale titulek článku říká, nějak to lze. Jednoduchý trik spočívá v tom, že rozložení do Windows nejprve přidáte a následně ho odstraníte:

Pokud se vám nechce klikat, tak jsem připravil jednoduchý script v Powershellu, který udělá totéž: https://github.com/KamilZm/RemoveUnwantedKBLayout

Jak na sebe narazilo nařízení EU a německé a české právo

aneb když se nedaří dohody na mezinárodní úrovni a občasné jsou v pasti…

Níže uvedený text je v rámci snahy o snadnější čitelnost upravena část důvodové zprávy návrhu na změnu vyhlášky č. 357/2013 Sb., o katastru nemovitostí. Pro zájemce je plný text dostupný ve veřejném eKLEPu pod ID KORNBF7JRXNU.

Dne 17. 8. 2015 vstoupilo v účinnost nařízení Evropského parlamentu a Rady (EU) č. 650/2012 o příslušnosti, rozhodném právu, uznávání a výkonu rozhodnutí a přijímání a výkonu veřejných listin v dědických věcech a o vytvoření evropského dědického osvědčení (dále jen „Nařízení“).

V souvislosti s aplikací Nařízení však vyvstal zásadní praktický problém, pokud jde o zápis nabytých práv do katastru nemovitostí na základě evropských dědických osvědčení. Konkrétně jde o odlišné pojímání označení majetku, který tvoří pozůstalost podle německého a českého práva. Ačkoli v obou státech se uplatní v dědickém právu zásada univerzální sukcese, německé soudy na jejím základě považují za nepřípustné uvádět jednotlivé předměty pozůstalosti v evropském dědickém osvědčení.

Na druhé straně podle českého práva nelze provést vklad vlastnického práva do katastru nemovitostí na základě listiny, ve které není dotčená nemovitost náležitě označena.

Katastrální úřady proto návrhy vklad doložené evropským dědickým osvědčením vydaným Spolkovou republikou Německo zamítají.

Ministerstvo spravedlnosti se opakovaně pokusilo věc řešit na expertní i politické úrovni, avšak doposud se nepodařilo německou stranu o změně jejich postupu přesvědčit. Reakce německé strany byla vždy nekompromisní – německé orgány jsou přesvědčeny, že Nařízení nenutí členské státy přizpůsobit svou vnitrostátní praxi či právní úpravu.

Interpretace Nařízení ze strany německých soudů má v praxi negativní dopad na dědice (české, německé i ze třetích států), kteří se tak dostávají do patové situace. Česká republika není jediným státem EU, kde je třeba tento problém řešit, s obdobnými obtížemi se setkávají občané a úřady též např. v Rakousku, Chorvatsku, Polsku nebo na Slovensku. Ani tyto státy nebyly schopny dosáhnout jakékoli dohody s německou stranou a rozhodly se řešit tuto problematiku v rámci svých vnitrostátních právních řádů. Vzhledem ke společným hranicím České republiky se Spolkovou republikou Německo a velkému množství smíšených rodin žijících v obou státech se problémy s uplatňováním evropských dědických osvědčení stávají stále palčivějšími a je zapotřebí najít reálné a účinné řešení pro občany, kteří jsou momentálně v neřešitelné situaci.

Navrhovanou změnou jsou tak nově stanoveny listiny pro zápis práv do katastru nemovitostí v případě univerzální sukcese s mezinárodním prvkem. Aplikace tohoto ustanovení je možná pouze za podmínek, že se jedná o univerzální sukcesi, v listině nejsou uvedena práva nebo nemovitosti, na něž se univerzální sukcese vztahuje, a zároveň jejich uvedení v listině brání právní řád členského státu EU, ve kterém byla tato listina vydána.

Problém s nefunkčním záhlavím okna ve Windows a jeho chybějící horní části

Již několik let mě ve Windows 10 trápí chyba, která se projevuje tak, že u některých aplikacích občas chybí horní část okna. Nedělají to všechny aplikace, problém se projevuje hlavně v Acrobat Reader nebo prohlížečích postavených na Chromiu (Google Chrome, Vivaldi, ...).

Správné zobrazení:

Špatné zobrazení (bílý pruh nahoře je ona chybějící část okna. Chybí záložky, adresní řádek, ovládací prvky okna - minimalizace, maximalizace, zavřít):

Pro lepší názornost porovnání vedle sebe:

Když tento problém nastane, tak se postižené okno chová tak, jako by tam daná část okna vůbec nebyla. Takže když se např. klikne do oblasti, kde je křížek na zavření, tak se zavře okno, co je pod ním. Aplikace ale nicméně funguje. V Chrome sice není vidět adresní řádek, ale po stisknutí ALT+D lze zadat URL. Když se aplikace (pomocí klávesové zkratky) přesune na druhý monitor, tak se zobrazí správně, ale po vrácení zpět je opět zobrazení rozbité.

Dlouho jsem marně pátral, co je příčinou. Problém se někdy vyskytl několikrát denně, jindy byl zase týden pokoj a už jsem si říkal, že třeba zabraly nové ovladače. Problém se u mě vyskytoval na 3 různých PC různých výrobců PC (Lenovo, "skládačka") s různou konfigurací, včetně rozdílných grafických karet (integrovaná v CPU Intel i vyhrazená NVIDIA).

Hledal jsem na internetu a vypadá to, že je to celkem rozšířený problém, se který nemá mnoho let řešení. Dlouho nebyla ani jasná příčina. Až jsem narazil na vlákno Windows 10 pro missing title bar and part of the top of window. Tam se nějak postupně dopátrali k tomu, že tento problém nastane, pokud se před tím otevře dokument Office v chráněném zobrazení:

Několik lidí v uvedeném vlákně psalo, že problém přestal, pokud režim chráněného zobrazení vypnuli. Zkoušel jsem uvedenou situaci nasimulovat a mohu potvrdit, že je to u mě stejné. Pro vznik problému stačí otevřít Word dokument stažený z internetu (standardně se takový dokument otevírá ve chráněném zobrazení) a pak spustit např. Chrome nebo otevřít v Acrobat Readeru nějaké PDF. Na verzi Office nezáleží, resp. se mi to děje jak v Office 2016, tak Office 2019.

Takže alespoň je už (snad) jasné, kdy problém vznikne a proč se objevuje tak "náhodně". Zjištění komplikoval i fakt, že to nedělají všechny aplikace, takže se po otevření Office v chráněném režimu dalo třeba 2 hodiny pracovat s jinými aplikacemi a až pak např. spustit Acrobat Reader a nebyla tak jasná souvislost....
Druhou podmínkou pro vznik problému je zřejmě používání dvou monitorové konfigurace. Když jeden monitor odpojím, problém nenastává.
Je pravděpodobné, že tam bude ještě nějaká další podmínka. Nepředpokládám, že se to projevuje všem těm, kdo mají dva monitory a otevírají dokumenty Office v chráněném zobrazení.

Pokud se nebojíte, můžete v Office vypnout chráněné zobrazení. Já se ale bojím a nechávám ho raději zapnuté. Bohužel nemám definitivní řešení, jen to umím obejít dvěma způsoby, pokud se daný problém objeví:
1) vypnout a pak zase zapnout jeden monitor
2) stisknutím CTRL+SHIFT+Win+B provést restart grafického driveru

Dlouho jsem používal řešení č. 1, protože o č. 2 jsem nevěděl a dočetl jsem se o něm až v již zmíněném vlákně.

Bohužel to zatím nevypadá, že by tento nepříjemný bug Microsoft nějak řešil 😢.

Pokud máte stejný problém a máte k němu další poznatky, napište je prosím do komentáře nebo např. do vlákna Windows 10 pro missing title bar and part of the top of window.

Proč byla v Nahlížení do KN neaktuální data

Na Twitteru jsem slíbil, že napíši něco k problému, díky kterému byla na Nahlížení do KN  (dále jen Nahlížení) neaktuální data. Ostřílené Oraclisty prosím o shovívavost, protože jsem v rámci čtivosti občas něco zjednodušil.

Pokud čirou náhodou Nahlížení neznáte, tak se ve zkratce jedná o www aplikaci, ve které můžete získat vybrané údaje týkající se vlastnictví parcel, staveb, jednotek evidovaných v katastru nemovitostí, informace o stavu řízení a další užitečné informace.  

Architektura replikací

Nahlížení má svoji samostatnou databázi, do které se replikují data z interní databáze ISKN:

Replikuje se cca 200 databázových tabulek, replikace probíhají každé 2 hodiny a jsou založeny na Oracle Materialized View. Pro zachování logické konzistence dat a cizích klíčů (Foreign Key) jsou všechny tabulky umístěny v jedné  replikační skupině (Materialized View Group), což znamená, že se v rámci jednoho průběhu replikací musí úspěšně zreplikovat všechny tabulky v dané skupině, jinak replikace zhavarují. Takže systém vše nebo nic. 

Pozn.: ve skutečnosti je replikační model košatější. Replikačních skupin tam mámě několik, včetně opačného směru, a ještě se do Nahlížení replikují data z databáze ISÚI.

Kódové stránky

Další věc, která je v tomto případě podstatná, je tzv. character set databáze, což je zjednodušeně řečeno kódová stránka. Protože v době vzniku ISKN nebyla v Oracle rozumná podpora pro Unicode, tak databáze ISKN využívá EE8ISO8859P2 se single-byte  kódováním (každý znak je uložen právě v jednom byte). 

Nahlížení je novější a využívá character set AL32UTF8, což odpovídá Unicode ve verzi 6.2 a je doporučován samotným Oracle. Tento character set je vícebytový (Multibyte) a využívá proměnnou délku kódování (Variable-width encoding), kdy je každý znak podle potřeby uložen v 1-4 byte.  

Pozn 1.: české znaky se tuším vejdou do 2 byte, ale ruku do ohně za to teď nedám.
Pozn 2.: jsou i Multibyte kódování s pevnou délkou, např. UTF-32.

V Oracle se velikost sloupců pro ukládání textu (typicky VARCHAR2) dá definovat dvěma způsoby - v bytech nebo znacích (Char). Velikost v bytech je maximální počet byte, které do sloupečku půjdou uložit, velikost ve znacích udává maximální počet znaků.

V Singlebyte databázi (EE8ISO8859P2) je to jedno, ale v Multibyte (AL32UTF8) je to podstatné, protože do sloupečku s definicí "VARCHAR2 9 Byte" nejde vložit řetězec "nahlížení", neboť má sice jen 9 znaků, ale jeho skutečná reprezentace má délku 12 byte (3 byte navíc jsou díky 3 českým znakům, každý je reprezentován 2 byte). Proto je v obou databázích  ISKN a Nahlížení použita definice pomocí znaků (Char), což eliminuje problém s rozdílnou délkou skutečného uložení řetězců.

Vznik chyby a její příčina

V pátek 8.2.2019 nám dopoledne začal systém indikovat, že se nedaří provést replikace z ISKN do Nahlížení. Replikace končily na chybu:

ORA-12008: error in materialized view or zonemap refresh path

ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 2952

ORA-06512: at "SYS.DBMS_SNAPSHOT_KKXRCA", line 2370

ORA-12899: value too large for column "ISKN"."AK_JINE_PRAV_VZTAHY"."POPIS_PRAVNIHO_VZTAHU" (actual: 4379, maximum:

4000)

Jednalo se o sloupec tabulky AK_JINE_PRAV_VZTAHY, do kterého se ukládá popis jiného právního vztahu a který je v obou databázích definován shodně, jak délka 4000, tak jednotky Char: 

SQL> desc AK_JINE_PRAV_VZTAHY

Name                    Type

---------------------------------------

ID                      NUMBER(30)

VERZE                   NUMBER(30)

OPSUB_ID_K              NUMBER(30)

TYPRAV_KOD              VARCHAR2(4 CHAR)

POPIS_PRAVNIHO_VZTAHU   VARCHAR2(4000 CHAR)

TEL_ID                  NUMBER(30)

(zkráceno...)

V ten okamžik jsme začali jsme tušit větší problém. Po detailním trasování jsme zjistili, že problém dělá řádek, který má v ISKN délku 3963 znaků a měl by se tedy do 4000 znaků v Nahlížení, kde jeho velikost díky českým znakům v AL32UTF8 naskočila na 4379 byte, s rezervou vejít. 

Zapojili jsme do pátrání i pracovníky podpory české pobočky Oracle a ti po dalším zkoumání přišli s tím, že Oracle sice povolí pro datový typ VARCHAR2 použít maximální velikost 4000 Char, ale ve skutečnosti je strop na 4000 byte, bez ohledu na použití jednotky char. Je to interní limit, což je v případě vícebytového AL32UTF8 docela průšvih. 

Zrádné je to navíc v tom, že se na limit narazí, až pokud se blíží oné maximální velikosti 4000. Pokud je sloupec definován jako "VARCHAR2 500 CHAR", tak se do něj v AL32UTF8 bez problémů 500 českých znaků uloží, přestože zabírají například 560 byte. V našem případě byla velikost problémového záznamu v ISKN (Singlebyte EE8ISO8859P2) 3963 znaků, ale po přenosu do Nahlížení se díky Multibyte AL32UTF8 zvětšila na 4379 byte a narazilo se na strop 4000 byte.

Hledání řešení

Možných řešení bylo několik.

1) Změna character set databáze

Character set se v Oracle definuje při vytváření databáze a následně jíž nejde jednoduše změnit. Je potřeba vytvořit databázi novou, přeexportovat data atd. Je šílená práce, která by v případě Nahlížení trvala několik dnů (export dat, nová databáze, import dat, vše znovu nastavit atd) a musela by se ještě předem důkladně vyzkoušet. 

Existují sice nějaké neoficiální postupy jak to změnit, ale to si nemůžeme u takového systému jen tak dovolit. V Oracle 12c se také objevil oficiální nástroj Database Migration Assistant for Unicode, pomocí kterého by měl jít character set změnit, ale od jeho použití nás v produkčním prostředí odrazovali samotní pracovníci Oracle, protože je (zatím) velmi problémový a plný chyb. Vše by se muselo nejprve vyzkoušet na kopii databáze a ani tak by jistota funkčnost nebyla a navíc jsme nechtěli přecházet z Unicode zpět.

2) Změna parametru max_string_size

Další možností bylo změnit parametr max_string_size na hodnotu "extended", což zvýší limit ze 4000 byte na 32767 byte, což by bohatě stačilo:
STARTUP UPGRADE;
ALTER SYSTEM SET max_string_size=extended;
@?/rdbms/admin/utl32k.sql
SHUTDOWN IMMEDIATE;
STARTUP;

Jenže je zde obdobný problém jako u předchozího řešení. Po dlouhém zkoumání opět samotný Oracle tento postup nedoporučil, protože součástí změny je nutnost spustit script utl32k.sql pro úpravu Oracle Dictionary (katalog - interní tabulky popisující strukturu samotné databáze), na který v Oracle Supportu zrovna chvála není:

Důsledkem by také byla byla fragmentace řetězců v databázi. Zároveň bychom museli změnit inicializačního parametr "compatible", který mám vliv i na chování CBO optimalizátoru dotazů. takže to není bez důkladného testování možné. Opět tedy několik dnů testování a zkoušení, navíc s nejistým výsledkem.

Pozn.: Pokud by databáze byla vytvořena přímo s parametrem max_string_size nastaveným na extended, tak by odpadl problém s fragmentací řetězců a nemusel by se spouštět script utl32k.sql. To je ale jen teoretická možnost, protože to znamená vytvořené nové databáze, viz předchozí řešení 1). Navíc jsme od pracovníků podpory Oracle dostali následující informaci:

"ani po delším pátrání se mi nepodařilo najít reference na použití max_string_size = extended. To znamená, že nemůžeme vyloučit komplikace, bugy apod.".

3) Redefinice MVIEW AK_JINE_PRAV_VZTAHY

Jako jednoduché řešení se nabízelo vytvořit v Nahlížení znovu Materialized View pro dotčenou tabulku AK_JINE_PRAV_VZTAHY  tak, že by se problémový sloupec rozdělil na dvě části, každá o velikosti 4000 CHAR. Reálně by se tedy, díky limitu, do každé části vešlo až 2000 českých znaků, celkem 4000 znaků, což je maximum, které lze v ISKN zapsat:

create mview as 

select id,

substr(popis_pravniho_vztahu,1,2000) as popis_pravniho_vztahu, substr(popis_pravniho_vztahu,2001) as popis_pravniho_vztahu_1,

…. from ak_jine_prav_vztahy@iskni 

To však narazilo z více důvodů. Prvním důvodem byla nutnost upravit aplikaci, která by musela interně oba sloupce zase zpět spojovat. To by nějakou dobu zabralo, ale asi by to šlo za víkend provést a otestovat (+ předělat  MVIEW, i to nějakou dobu trvá, protože by se musela znovu přenést všechna data). 

Druhý důvod byl závažnější. V Nahlížení je na replikované tabulky navázáno přes databázové triggery hlídání přicházejících změn, na jejichž základě se následně provádějí další změny v grafické části (mapě). Novou definicí MVIEW bychom tedy přišli o možnost zpracovat o změny, které v tu dobu již byly nachystané v replikační frontě v ISKN a příslušná část grafiky by se musela kompletně od začátku znovu spočítat, což je časově velmi náročná akce (dny) a navíc jsme neměli vyzkoušen postup, kdy se přepočte jen jedna část. 

4) Aplikační úprava problémového textu v ISKN

Toto řešení by spočívalo v tom, že by se v ISKN upravil problematický text tak, aby se i s českými znaky v Nahlížení vešel do 4000 byte. Použil by se standardní postup přes aplikaci ISKN, jako každá jiná změna v ISKN. Takže založit řízení a provést aktualizaci dat se vším, co k tomu formálně patří. To by ale znamenalo čekat až do pondělí, protože o víkendu nikoho z daného katastrálního pracoviště, které daný jiný právní vztah zapsalo, neseženeme, a do práce nenaženeme.

Následně jsme si ale uvědomili, že bychom tím problém vlastně nevyřešili. Datový model ISKN je navržen takovým způsobem, aby bylo možné zjistit stav data k jakémukoli času. Proto je možné dělat např. výpisy KN k zpětně. Funguje to tak, že pro každou entitu (jiný právní vztah, parcela, stavba, ...) existují 3 tabulky:

• AK_JINE_PRAV_VZTAHY
• AK_JINE_PRAV_VZTAHY_B
• AK_JINE_PRAV_VZTAHY_M

Tabulka AK_JINE_PRAV_VZTAHY (bez suffixu) slouží k uložení aktuálně platných dat, tzv. přítomnost.
Tabulka AK_JINE_PRAV_VZTAHY_B (budoucnost) slouží k vytváření budoucího stavu dat, který bude platit po tzv. zplatnění řízení (navrhují se v ní změny dat).
Tabulka AK_JINE_PRAV_VZTAHY_M (minulost) slouží k uložení již neplatných dat a využívá se právě pro zpětné výpisy, zjištění vývoje změn atd.

Zaměstnanec při zápisu změny navrhne v _B tabulce stav, jak by data měla vypadat. Poté proběhne kontrola jiným pracovníkem a pokud je úspěšná, tak se provede zplatnění řízení, což znamená, že se z přítomnostní tabulky (bez suffixu) data přesunou do minulostní (suffix _M) a z budoucnosti (suffix _B se přesunou do přítomnosti).
Z toho plyne, že bychom aplikační aktualizací problém s délkou textu jen přesunuli z tabulky pro přítomnost (AK_JINE_PRAV_VZTAHY) do tabulky pro minulost (AK_JINE_PRAV_VZTAHY_M).

Pozn.: Rozdělení na 3 tabulky a ne např. použitím atributu v jedné tabulce je dáno historicky. Bylo na zvoleno začátku tvorby ISKN (1997) pro optimalizaci výkonu, protože většina dotazů je na přítomnost, která oddělením od minulosti není velká. 
V ISKN se následně pro přístup využívají tzv. Partitioned views, což v současné době není doporučované technika a působí problémy při migraci na vyšší verze (zhavaroval na ní pokus o přechod na Oracle 11, protože se k takovýmto view přistupuje přes opět hodně zabugovaný JPPD).  Aktuálně se v rámci migrace na Oracle 12c připravuje změna založena na sloučení těchto 3 tabulek do jedné s využitím Oracle Partitioningu, což udělá docela vítr v datovém modelu a celé aplikaci, ale je to koncepční řešení.

5) Úprava problémového textu v ISKN na úrovni databáze

Protože jsme administrátoři, tak můžeme provést update záznamu na úrovni databáze. pomocí SQL příkazu. Jenže to si nemůžeme jen tak dovolit. Někdo ten záznam vytvořil, je za jeho obsah odpovědný a my bychom mu to změnili. Záznam vznikl na základě nějaké listiny, která byla doručena spolu s  návrhem na vklad. Zasáhnout do zapsaného textu není tak jednoduché a mohlo by to znamenat problém, přestože bychom to provedli v dobré víře zprovoznění replikací.

Problém je v tom, že změna by se projevila nejen v Nahlížení, ale i v ISKN, ze kterého pracovníci vydávají veřejné listiny, a také ve výstupech Dálkového přístupu, které mají také charakter veřejné listiny a jsou opatřeny kvalifikovanou pečetí.

Další komplikací by mohlo být, pokud by někdo v rozmezí od okamžiku zápisu daného textu v ISKN do provedení této "tvrdé" opravy na úrovni databáze získal Výpis z KN,  ať už z Dálkového přístupu nebo na přepážce, případně by odebral data ve výměnném formátu nebo jako geodet přes WS GP. Pokud bychom do textu sáhli takto natvrdo, mimo aplikační logiku, tak by se při vyhotovení výpisu ke zpětnému časovému okamžiku toulaly po světě dva výpisy z KN s platností ke stejnému časovému okamžiku, ale s jinými texty. U výměnného formátu bychom zase porušili logiku změnových vět.

Ačkoli by tedy technicky tato změna byla jednoduchá (jeden SQL příkaz), tak z formálního hlediska zase tak jednoduchá není.  

Řešení 

Nějak jsme situaci ale vyřešit museli. Replikace stály už více jak 24 hodin, což není dobré ani pro uživatele, ani pro systém, protože se hromadí data v replikačních frontách a následné spuštění replikací je o to delší.

Varianty 1) a 2) byly hodně rizikové. Komplikuje je také fakt, že v databázi  s replikacemi se nemůžete jen tak v případě problémů vrátit v čase zpět. Kdyby se nějaký problém objevil po tom, co by úspěšně do Nahlížení proběhly replikace z ISKN nebo ISÚI, tak už by se nešlo vrátit zpět a následně zkusit jiné řešení, protože by se replikace rozsynchronizovaly (v ISKN nebo ISÚI  by byla data, která by se tvářila, že už jsou zreplikovaná i v Nahlížení, ale tam by díky vrácení v čase se zpět nebyla). Data by se musela  přenést všechna znovu (provést tzv. complete refresh, který přenese vše, ne pouze fast refresh, který přenáší jen změny). Complete refresh je na dlouho a ještě komplikovaný tím, že ve zdrojové databázi (ISKN, ISÚI) nesmí v tu dobu pro aktuálně přenášení MVIEW probíhat žádné změny. Následně by se v Nahlížení musela kompletně znovu spočítat grafika, viz konec bodu 3). V neposlední řadě bychom vrácením se zpět také přišli o všechna data pořízení přímo v Nahlížení.

Varianta 3) by sice byla funkční a bez problémů, ale časově velmi náročná (dny) a řešila by jen jednu tabulku. Varianta 4) by nepomohla a tak nám po dlouhém zvažování (pořád jsme přemýšleli nad 1) a 2) ) zbyla varianta 5).

Varianta 5) také nebyla ideální, nicméně jsme se pro ni rozhodli s tím, že nám umožní vyřešit co nejrychleji aktuální problém a získáme čas na provedení koncepčního řešení.

Přemýšleli jsme, co s tím, jak změnit text, aby z toho nebyl problém. Nakonec jsme se rozhodli, že zkusíme jen odstranit diakritiku. Nejprve jsme zkontrolovali, že se odstraněním diakritiky nijak nezmění význam textu. Pak jsme prověřili vydané výpisy, výstupy výměnného formátu atd., viz popis ve variantě 5). Naštěstí proběhl jen relativně krátký časový okamžik a ještě to bylo v pátek. Odešlo sice vyrozumění o zápisu daného řízení a s ním výpis, ale to je kontrolovaný a podchycený proces. Do karet nám také hrál fakt, že se by se "jen" odstranila diakritika, takže i kdyby byl výpis vydaný, nebyl by to takový průšvih, nicméně příjemné by to nebylo.

Museli jsme také ověřit, že daným zásahem nezpůsobíme nějakou aplikační nekonzistenci. Některé akce v ISKN jsou hlídány přes databázové triggery a jejich nové spuštění by mohlo vyvolat např. duplicity v navázaných datech atd.

Po prověření jsme požádali vedení o schválení provedené této "tvrdé" úpravy přímo v databázi a po vysvětlení situace, našich zjištění a možných řešení jsme obdrželi souhlas. Zazálohovali jsme tedy měněný záznam a provedli jeho aktualizaci jednoduchým příkazem:

update ak_jine_prav_vztahy set

popis_pravniho_vztahu=convert(popis_pravniho_vztahu,'US7ASCII')

where id=1234

Za dalších 30 minut už všechny replikace na Nahlížení úspěšně proběhly. 

Závěr

Řešení tedy bylo triviální a otázka 5 sekund. Než jsme k němu ale dospěli, tak to trvalo 1.5 dne (1/2 pátku a sobotu) perné práce, protože jsme museli zkoumat možné varianty, ověřovat je atd.

Není to ale řešení trvalé a teď zvažujeme co dál. Naštěstí pravděpodobnost, že by se situace mohla opakovat velká není (délka textu byla opravdu extrémní). Do definitivního vyřešení jsme přijali i organizační opatření. Zatím váháme, zda se v rámci připravovaného cross-platform upgrade (v rámci konsolidace prostředí přechod databáze Nahlížení z Linuxu na AIX) pustit do řešení podle poznámky v bodu 2), které by bylo sice systémovější, ale s možnými problémy, nebo zda půjdeme řešením 3) a sloupec (vlastně sloupce, celkem takových s VARCHAR2(4000) máme v různých tabulkách 4) v Nahlížení rozdělíme na 2. Pokud bychom to dělali řízeně, s prázdnou replikační frontou, tak bychom nepřišli o žádné změny a nebylo by nutné přepočítávat grafickou část.

---

Pár zajímavostí a poznámek pod čarou

1) Kdybychom nebyli "pokrokoví" a databází Nahlížení udělali také v Singlebyte kódování a nikoli Unicode s proměnnou délkou, tak jsme si tyto problémy ušetřili, obzvláště v kombinaci s replikacemi databází databází s různým character set.

2) Pokud vás zajímá, na čem ztroskotal náš předchozí pokus o upgrade ISKN na Oracle 11g nebo  problematika Partiton Views zmíněná v řešení 3) s bugy JPPD, tak si přečtete naši podrobnou analýzu. Výživné a velmi poučné čtení.

3) Chyba "ORA-12899: value too large for column"  se při replikacích začala objevovat až po nedávné migraci (prosinec 2018) databáze Nahlížení na Oracle 12.2. Ten samý problém ale byl i v předchozích verzích, jenže Oracle při replikacích chybu nehlásil, ale data prostě bez jakéhokoli upozornění ořezal, což je ještě horší.

4) Tvrdým limitem 4000 byte pro VARCHAR2 byli překvapení i samotní pracovníci podpory Oracle. Nemohli ve svých interních systémech dohledat hlášený obdobný problém, což zase překvapilo nás. Zřejmě se kombinace tak dlouhých VARCHAR2 položek v kombinaci s proměnnou délkou kódování a znaky, které se nevejdou do 1 byte, tak často neobjevuje a používá se spíše CLOB.

5) Chování Oracle při použití Multibyte s proměnnou délkou (Nahlížení, AL32UTF8) je opravdu zákeřné, příklad:
(funkce length(rpad('X',4000,'X')) doplní řetězec "X" až do délky 4000 znaků dalšími "X")

SQL> select length(rpad('X',4000,'X')) as delka from dual;

DELKA

--------------------------

                      4000 (očekávaný výsledek)

Když místo US znaku X použijete znak český, tak najednou dostanete pouze 2000 znaků (reprezentovaných 4000 byte): 

SQL> select length(rpad('Ň',4000,'Ň')) as delka from dual;

DELKA

--------------------------

                      2000 

Pro mě neočekávaný výsledek, který je daný tím, že interní reprezentace v rámci implicitního kurzoru pro 2000 českých znaků je v Multibyte 4000 byte a Oracle to prostě na 2000 znacích bez uzardění ořízne. Když ten samý dotaz spustíte v Singlebyte databázi (ISKN, EE8ISO8859P2), tak je vše OK:

SQL> select length(rpad('Ň',4000,'Ň')) as delka from dual;

DELKA

--------------------------

                      4000 

Dotaz vypadá nevinně a různý výsledek v různých databázích docela zaskočí. Na takových věcí pak narazíte spousty, pokud už víte, co hledat. 

6) V dokumentaci Oracle se píše: 

The VARCHAR2 datatype stores variable-length character strings. When you create a table with a VARCHAR2 column, you specify a maximum string length (in bytes or characters) between 1 and 4000 bytes for the VARCHAR2 column. 

Je to zavádějící a jak jsem psal, překvapilo to i samotné pracovníky Oracle. Tohle vám prostě nedocvakne, když o tom nevíte. O nutnosti používat v Multibyte jednotky Char jsme věděli (narazili jsme na to v replikacích již dříve u kratších polí), ale o tvrdém limitu 4000 byte při použití Char ne. Chtělo by to velké červené varování.

7) Z mého textu mohlo zdát, že Oracle je ten nejvíce zabugovaný SW na světě a je prakticky nepoužitelný. Přesto si myslím, že Oracle je v oblastí SQL databází špička, daleko před ostatními (např. technologie RAC), a jinou databází bychom si nijak nepolepšili. Bugy jsou všude a u nás většinou bohužel narazíme na nějaké speciality, které se jinde neřeší. Navíc český support se opravdu snaží. Ale je pravda, že si Oracle jak za licence, tak služby supportu, nechá řádně zaplatit.

8) K druhé větě v odstavci Řešení - někteří uživatelé jsou tak nedočkaví, že se občas stane situace, že náš zaměstnanec zplatní řízení a než připraví a odešle účastníkům řízení vyrozumění o zápisu (to jde i Datovou schránkou), tak se data stihnou zreplikovat na Nahlížení (replikace mohou proběhnout třeba za 5 minut), kde si uživatelé hlídají jejich řízení/LV a volají našemu zaměstnanci, kdy si mohou přijít pro výsledek atd. :-)

Pozor na KeePass

KeePass je jeden z často používaných správců hesel, který je uvolněný pod General Public Licencí veze 2.

Na rozdíl od různých cloudových správců funguje tak, že máte hesla uložené v jeho "databázi" (soubor), ke které získáte přístup po zadání hlavního klíče ("master password") nebo např. použitím souboru klíče v souboru ("Key File"). Způsobů existuje více.

Tento nástroj má implementovanou jednu vlastnost, na kterou mě dnes upozornil kolega Jirka V. Publikoval jsem ji na Twitteru, ale pak jsem usoudil, že si zaslouží samostatný článek.

V jeho konfiguraci lze nastavit tzv. triggery, což jsou události, které se spustí při určité akci. Na tuto událost lze pak provést další akce.  Jednou z událostí je i otevření/odemčení databáze s hesly a jednou z akcí je export této databáze. Stačí do KeePass.config.xml dopsat níže uvedenou část a při každém odemčení se současně databáze vyexportuje do souboru c:\temp\hesla.txt:

<TriggerSystem>
  <Enabled>true</Enabled>
  <Triggers>
    <Trigger>
      <Guid>esN+2TpQpUSxHM2rzGhXmw==</Guid>
      <Name>test</Name>
      <Events>
        <Event>
          <TypeGuid>5f8TBoW4QYm5BvaeKztApw==</TypeGuid>
          <Parameters>
            <Parameter>0</Parameter>
            <Parameter/>
          </Parameters>
        </Event>
      </Events>
      <Conditions/>
      <Actions>
        <Action>
          <TypeGuid>D5prW87VRr65NO2xP5RIIg==</TypeGuid>
          <Parameters>
            <Parameter>c:\temp\hesla.txt</Parameter>
            <Parameter>KeePass CSV (1.x)</Parameter>
            <Parameter/>
            <Parameter/>
          </Parameters>
        </Action>
      </Actions>
    </Trigger>
  </Triggers>
</TriggerSystem>

V domácím použití to není úplně kritické, protože pokud se vám někdo dostane do počítače, aby vám bez vašeho vědomí změnil konfigurační soubor KeePass.config.xml, tak máte velký problém tak jak tak. Horší je ale, pokud je KeePass používán ve firemním prostředí jako úložiště hesel pro více uživatelů, což je scénář, který KeePass přímo podporuje a uvádí.  

Představme si tedy scénář, kdy je databáze s hesly uložena na sdílení a přístup k ní mají jen oprávnění uživatelé, mezi které ale nepatří administrátor systému, na kterém je databáze a konfigurace uložena. Když takový administrátor do konfigurace doplní výše uvedenou část, tak stačí, aby někdo jiný (oprávněný), otevřel databázi s hesly, na což zareaguje trigger a spustí export hesel do textového souboru. V podstatě ji dostane naservírovanou na talíři. 

Pozor tedy na tuto (dokumentovanou) vlastnost, není to chyba. Jen mám pochybnosti, zda je tato vlastnost ve všeobecné známosti uživatelů, kteří KeePass používají. Já KeePass nepoužívám a nevěděl jsem o tom, ale i kdybych ho používal, tak upřímně, zase tak detailně nápovědu a možnosti konfigurace nestuduji a určitě bych o tom nevěděl.

Možná je čas se poohlédnout po nějakém jiném řešení, obzvláště v podnikovém prostředí. Inspirovat se můžete třeba na následujících stránkách:

https://www.cloudwards.net/best-password-manager-for-small-business/

https://smallbiztrends.com/2018/01/best-password-manager-apps-small-business.html

Na závěr přidávám doplnění od Michala Špačka, uznávaného odborníka na bezpečnost:

Asi je dobré poznamenat, že dávat do firemního správce hesel "nefiremní" přístupy, kde by vadilo, že se k nim dostane např. správce, který nakonfiguruje triggery, není dobrý nápad a ani dokumentace KeePassu takovou věc nezmiňuje. Zákeřný admin systému se k heslům v databázi vždy dostane, triggery, netriggery. 

Mají být všechna data státu zdarma?

Velmi často se někde objeví názor, že by měl stát dávat všechna data, která má, a které nepodléhají utajení, zdarma. Prakticky to samé platí i pro poskytované služby. Na jednu stranu je to představa poměrně líbivá, i pro mě. Jsem informatik a v datech se rád hrabu, takže bych s tím souhlasil. Na první poslech logicky zní i argument typu "zaplatili jsme si to z daní", který je občas v těchto souvislostech slyšet. Proti faktu, že by to mohlo rozjet další podnikání a služby občanům, také nelze nic namítat. Bohužel to má ale i druhou stránku, kterou si lidé hned neuvědomí.

Stanovené příjmy

O tomhle faktu se moc veřejně neví, nebo jsem na něj alespoň zatím nikde, u podobných diskuzí,  nenarazil. Státní úřady, přinejmenším některé, mají ze zákona, který reprezentuje Zákon o státním rozpočtu, stanoveny příjmy, které musí splnit (lidově řečeno "vybrat peníze"). Jsou dvoje typy příjmů - daňové (typicky správní poplatky) a nedaňové, mezi které patří příjmy za úplatu (neplést s úplatkem :-), pojem je opakem k bezúplatně poskytovaným věcem).

ČÚZK měl pro rok 2017 rozpočtem stanoveny následující podmínky (zdroj Výroční zpráva ČÚZK za rok 2017):
"Schválený státní rozpočet pro kapitolu 346 Český úřad zeměměřický a katastrální na rok 2017 byl stanoven ve výši 700 mil. Kč pro příjmy a v objemu 3 048,8 mil. Kč pro výdaje. Rozpočet daňových příjmů zahrnující správní poplatky byl stanoven ve výši 550 mil. Kč, jeho plnění dosáhlo objemu 651,8 mil. Kč, tj. 118,5 %. Nedaňové příjmy v roce 2017 byly kapitole stanoveny ve výši 150 mil. Kč a byly naplněny objemem 237,7 mil. Kč, tj. plnění na 158,5 %. "

Pokud tyto stanovené příjmy nejsou splněny, tak dochází směrem k nám ke krácení výdajů ze státního rozpočtu, což má přímý dopad do investičních činností atd. a není to příjemná situace. Takže i státní úřady jsou nuceny vybrat peníze za svoji činnost a pokud se tak nestane, jsou penalizovány. Není to tak, že je jedno, kolik příjmů mají. Pokud bychom měli všechna data poskytovat zdarma, tak o část těchto příjmů přijdeme. To by bylo třeba zohlednit ve státním rozpočtu, aby s tím počítal. To se ale dnes neděje a i proto se musíme snažit data prodávat.

Je to komplikované i tím, že zdaleka nemůžeme být tak pružní, jako soukromé firmy. Nemůžeme si udělat "Black friday". Nemůžeme jednoduše upravit výši správních poplatků a úplat. To, co soukromá firma je schopna udělat lusknutím prstu, musí státní instituce prohnat přes zákony a vyhlášky, což je věc minimálně na 1/2 roku, když to jde velmi dobře. Naše ceny jsou stanoveny vyhláškou 358/2013 Sb., o poskytování údajů z katastru nemovitostí.

Problém z příjmů byla také jeden ze zásadních připomínek, které jsme v roce 2017 zasílali při připomínkování návrhu usnesení vlády ČR  "o zveřejňování dat, která jsou vedena v informačních systémech veřejné správy spravovaných ústředními správními úřady, jako otevřených dat".

Obecný přístup

I kdyby se problém příjmů vyřešil, tak zde je podle mě ještě závažnější otázka. Opravdu chceme, aby byla všechna státní data zdarma? Z jakého důvodu? Pořízení dat něco stojí, zadarmo nic není. Státní úřady mohou všechna data dávat zdarma, ale tím se se sníží příjmy rozpočtu a pravděpodobně se tak budou muset zvýšit daně, aby tento výpadek pokryly. 

Co je ale správná cesta? Mají všichni plošně platit za něco, co je nezajímá? Proč by si to nemohli zaplatit pouze Ti, kterých se to týká? Já nechci z daní platit data pro Pepíka z Horní dolní. Jsem zastáncem toho, že by daně měly být stanoveny tak, aby pokrývaly pouze široké plošné výdaje státu, u kterých by bylo ve výsledku dražší platit položkově. Za věci, které plošné nejsou, by měly platit jen zájmové osoby, ne všichni. Jaké procento lidí je využije? Bude to většina obyvatel? To mi připomíná spíše socialismus. 

Závěr 

Poskytovat plošně státní data mi z výše uvedeného důvodu nedává smysl. Je ale určitě obtížné najít tu správnou hranici, aby byly spokojeny obě strany, jak stát, tak jeho obyvatelé. Tato problematika není jednoduchá a celá věc není tak černobílá, jak by se na první pohled mohlo zdát.

PS: Pokud chceme data zdarma, musíme ulevit státnímu rozpočtu. Můžete to udělat i vy, třeba tím, že si zřídíte jako fyzické osoby datovou schránku. V našem případě to v našem rozpočtu (nikoli v rozpočtu státu, ale i tak je to celkově levnější) ušetří náklady na poštovné (zdroj Výroční zpráva ČÚZK za rok 2017) a budeme je moci použít na jiné věci:

Služby pošt byly čerpány ve výši 138,1 mil. Kč a vykázaly po loňském snížení opět nárůst o 2 mil. Kč oproti roku 2016

Otevřenost katastru v EU

Občas se vyskytnou diskuze, zda je správně, že je katastr nemovitostí v České republice veřejný a otevřený. Kolegové prošli lokální katastry (land register, LR) některých států a vyrobili přehled, jak je to v EU (+ i někde jinde). Výsledek jejich zkoumání naleznete v tabulce s přehledem otevřenosti katastru v EU.

Raději upozorňuji, že je to pojato zjednodušeně a získáním informací se myslí výpis na jednotlivou nemovitost. Mnohde totiž vůbec nelze nijak získat žádný přehled vlastnictví ani kopii listiny. Někde to získat lze, ale po prokázání právního zájmu (pro listiny to platí s tímto omezením dokonce i na Slovensku, pro přehled vlastnictví zase v Rakousku). 

Primárním zdrojem dat byla stránka http://www.doingbusiness.org/.