Navigation:  Základní postupy > Práce s VFK > Obecně o VFK > Dopad VFK na zpracování GP

Obtížnost vytváření GP pro export do VFK je v tom, že tento formát je prakticky pouhým textovým výpisem databázových tabulek systému ISKN.

To je ideální pro kompletní přenosy dat z jednoho systému do druhého, například když je třeba zapotřebí kompletní data ISKN přenést do informačního systému místního úřadu.

Data se do takového systému jednou načtou za zvolené území a dále se pak využívají už jen k interpretaci a získávání informací, ale vlastní data se tam nemění ani neudržují. V takovém systému jsou tedy data vlastně uložena jako „read only“ nebo-li „jen ke čtení“. Je tedy úplně jedno jak programátoři takového systému, přebírajícího data z ISKN, převedená data uloží. Je jedno zda použijí všechny informace a vazby, které ISKN obsahuje nebo načtou jen informace, která koncový informační systém potřebuje, záleží jen účelu takového systému.

To však není případ vyhotovitele geometrického plánu. Ten sice taky potřebuje zobrazit data ISKN, ale na rozdíl od běžných uživatelů dat z ISKN v nich bude, díky základní logice výměnného formátu, přímo provádět změny. Tady už takto pojatý výměnný formát není až tak ideální. Vyhotovitel GP se díky němu vlastně stává přímo tím, kdo přímo provádí údržbu tohoto systému. O co jde?

Až dosud vyhotovitel GP pouze poskytoval podklady KÚ pro zavedení změn v operátech KN, buď v „papírové“ formě, případně nějaké soubory na disketě (například seznam souřadnic). Nyní místo poskytování podkladů se z hlediska logiky VFK stává vyhotovitel GP vlastně přímo tím, kdo změny v ISKN provádí. Tyto změny sice pak zkontroluje na vstupu do ISKN importní program, ale pak se jich dle logiky VFK už nemá „dotknout lidská ruka“. Při zápisu GP by jej pak pracovník KÚ měl zapsat prakticky automaticky, zatímco dříve prováděl změny osobně pouze podle papírové předlohy a poskytnutých dat v digitální formě (například seznam souřadnic).

Podrobněji o problému pro „zvídavější“

Až dosud byla pro zpracovatele GP vlastnická hranice čárou, která spojovala dva zaměřené body. Každý tento bod měl jako svůj identifikátor číslo bodu. Tvorba čísla bodu byla přesně popsána v příslušných předpisech: 4 místa jsou číslo k.ú., další 4 místa číslo náčrtu a poslední 4 místa vlastní číslo bodu. Například hranice parcely pak byla definována jako spojnice dvou bodů, které se zapsaly pomocí těchto identifikátorů – čísel bodů. Pokud se hranice rušila, dostala příznak „rušená“, tedy se na ní nakreslily tzv. škrty.

Takové údaje šly bez problému zapsat textovým editorem. Mnoho z nás asi ještě dokonce pamatuje vytváření předpisů kresby pro systém MAPA (resp. MAPA2) na pětistopých děrných páskách v dálnopisu.

V ISKN je však každá čára podstatně složitější objekt. Například každá čára má také svůj identifikátor, tedy jakési jméno, cosi podobného číslu bodu. Tento identifikátor je vlastně náhodné číslo. Jedinou podmínkou pro jeho vytvoření je, že se nesmí v databázi vyskytnout dvakrát (alespoň dle popisu struktury výměnného formátu). Pokud je taková čára rušena, je ve výměnném formátu identifikována právě tímto číselným identifikátorem, tedy vlastně jakýmsi jménem.

Podobně je tomu s bodem. Každý bod má v ISKN nejenom klasické číslo bodu, ale stejně jako čára systémem náhodně vygenerovaný číselný identifikátor. Vlastnická hranice je pak v ISKN definována jako spojnice dvou bodů pomocí těchto číselných identifikátorů (ne čísel bodů).

Tedy každý systém, který chce zpracovávat tyto údaje, musí kompletně respektovat a „pamatovat si“ všechny tyto údaje a jejich vazby, protože je není možné dodatečně vygenerovat z údajů, které až dosud tvořily součást tvorby geometrického plánu.

Z hlediska programátorského je toto řešení naprosto pochopitelné, je zbytečné zabíhat do technických podrobností, ale jde o rychlost práce s takovými velmi rozsáhlými databázemi.

Praktickým důsledkem však je, že každý systém, který chce vygenerovat změny pro takto pojatý výměnný formát, musí udržovat a pracovat s údaji, které vlastně vůbec nesouvisí s vlastním obsahem KN, ale jsou to ve skutečnosti pouze pomocné vnitřní údaje informačního systému, které si vymysleli jeho programátoři, aby jimi použité technické řešení bylo použitelné z hlediska rychlosti práce.

Ponechejme toto řešení bez dalších komentářů. Přestože v tuto chvíli vypadá nepříliš vhodně, třeba se jeho výhody ukážou teprve v budoucí praxí.