Ing. Stanislav Tomeš
GEPRO s.r.o.
Štefánikova 52
150 00 Praha 5 - Smíchov
E - mail: stanislav.tomes@gepro.cz
This paper deals with the initial practical experience in the implementation of the "Standard for the Digital Technical Town Map Structure and Exchange Format" (DDTM) in the capital city of Prague. This document was developed by CAGI expert group on the basis of request from the Public Information System Office (ÚVIS - Úřad pro veřejné informační systémy) and professional public.
At the present time, the implementation of the DTMM exchange format is under way, intended for the purposes of data exchange between the Prague(s Institute of Urban Informatics (IMIP - Institut Městské Informatiky hl. m. Prahy) and technical facilities managers.
Příspěvek popisuje první praktické zkušenosti s nasazováním "Standardu pro strukturu a výměnný formát digitální technické mapy města" v hlavním městě Praze. Tento standard vznikl na základě požadavku Úřadu pro veřejné informační systémy (ÚVIS) a odborné veřejnosti a zpracovala jej odborná skupina CAGI.
V současné době se začíná nasazovat výměnný formát DTMM v Praze pro výměnu dat mezi Institutem městské informatiky hlavního města Prahy (IMIP) a správci technického vybavení.
V současné době si již nedovedeme jakékoliv pracoviště představit bez počítače. Nelze dnes snad najít obor lidské činnosti, kde by počítač nebylo možné využít. Počítač sám je však jen nástrojem, který nelze využívat bez programového vybavení. Vzhledem k rozmanitosti jednotlivých oborů lidské činnosti vznikalo a vzniká mnoho různých programových systémů, které jsou optimalizovány pro využívání v určitém oboru. Nedílnou součástí systémů jsou data, která jsou zpracovávána dle potřeb uživatele. Jednotlivé obory lidské činnosti však nejsou uzavřeny samy do sebe, ale naopak si výsledky své činnosti poskytují navzájem. V počítačovém světě toto znamená výměnu dat, a protože programové (a někdy i hardwarové) vybavení se u uživatelů liší, je většinou také struktura a obsah dat velice rozmanitý. Aby bylo možno tato data využívat i v ostatních oborech, je zapotřebí stanovit pravidla pro jejich výměnu. Nejlepším způsobem se jeví stanovení pravidel nezávislých ani na typu počítače ani na programovém vybavení.
V tomto referátu se budeme zabývat pouze technickými mapami měst v digitální vektorové podobě a možností jejich výměny mezi rozličnými programovými systémy. Pod výrazem programový systém je zde myšlen program pro práci s vektorovou grafikou a pojem data bude nahrazovat technickou mapu města v digitální podobě (vektorové). Slovo systém bude používané pro kombinaci programového vybavení a předpisu pro tvorbu mapy.
Citace WWW.UVIS.CZ
"Hlavním úkolem Úřadu pro veřejné informační systémy je v souladu se zákonem 365/2000 Sb., o informačních systémech veřejné správy a změně dalších zákonů, koordinovat výstavbu informačních systémů veřejné správy. Základními nástroji technické koordinace jsou standardy ISVS, systém atestací a systém kontrol. Standardy vymezují technické a organizační předpisy, systém atestací prokazuje v jednoznačně vymezených případech shodu s povinnými ustanoveními standardů a systém kontrol ověřuje dodržování povinností správců ISVS vyplývající z tohoto zákona."
Úřad pro veřejné informační systémy si je vědom nejednotnosti vznikající v prudkém (a ničím neřízeném) rozvoji počítačů a programového vybavení. Aby (alespoň ve veřejných) informačních systémech bylo ve výměně dat jasno, začal ÚVIS vydávat standardy. Standardy nevypracovává ÚVIS sám, ale spolupracuje s externími odborníky v zájmových oblastech. Takto také vznikl Standard ISVS pro strukturu a výměnný formát digitální technické mapy města.
Tento standard začal vznikat na konci roku 1998. Návrh standardu zpracovávala skupina ČAGI až do konce roku 1999. V této skupině pracovalo několik odborníků z firem s různým odborným zaměřením a s odlišným programovým vybavením. Tak měla být podchycena co nejširší oblast oborů, způsobů práce s mapami a jejich obsah. Schválení standardu proběhlo 1.11.2000 a vyhlášen byl 22.12.2000.
Cílem tohoto standardu bylo navrhnout obecný výměnný (přenosový, předávací) formát pro přenos dat digitální technické mapy města (dále jen DTMM) mezi různými programovými produkty.
Výdej a příjem dat mezi programovými produkty lze dělit na dva typy:
1. mezi stejnými programovými produkty
2. mezi různými programovými produkty
V bodě 1. se ještě vyskytuje problém s různými verzemi programového produktu, ale ten není pro tuto úvahu důležitý (je to potom vlastně určitá obdoba bodu 2.). Zdá se, že pokud nastane případ 1. a jak vydavatel tak i odběratel mají totožné programové produkty, nemůže nastat problém. Toto je však jen zdání a praxe je zcela jiná. V takovém případě jsme sice schopni bez problémů předávaná data načíst a zobrazit, ale horší situace pak nastává, pokud máme tato data správně interpretovat. Žádný programový produkt a priori nestanoví, co a jak má být vykresleno, ale bývá to stanoveno buď normami, směrnicemi nebo jenom uživatelovou volbou. Takto stanovené předpisy kresby jsou ovlivněny možnostmi používaného programového vybavení a nelze je vždy jednoduše aplikovat na jiné programové vybavení.
V případě 2. se k problémům případu 1. ještě přidají problémy s načítáním dat z jiných (neznámých) struktur. Obecně lze takový problém řešit vždy pouze za předpokladu, že onu "cizí" strukturu dat nakonec nějakým způsobem dekódujeme. Pokud jsme schopni data přečíst, máme opět dvě možnosti:
a) data z cizí struktury přečteme a zobrazíme
b) data z cizí struktury zkonvertujeme do struktury "známé" a tu následně zobrazíme
Pokud jsme schopni provést bod a), pak opět ještě není zaručeno, že jsme schopni zobrazená data správně interpretovat. Většinou také ztrácíme možnost jejich úpravy, neboť jsou pouze zobrazena, ale nadále uchovávána v původní struktuře.
Chceme-li cizí data upravovat, musíme je konvertovat z původní struktury do struktury, kterou je náš programový produkt schopen zpracovat. Pro konverzi dat je nutno stanovit, jak se která data mají převádět. Většinou se toto řeší tzv. konverzními tabulkami. Při tvorbě konverzních tabulek si uživatel nejvíce uvědomuje, že vlastně není schopen za každých okolností data převést. Bránit mu v tom může jak již dříve vzpomínaná nejasnost v interpretaci cizích dat (nezná-li předpis kresby), tak i fakt, že v jedné mohou existovat prvky, které při převodu do struktury druhé nelze nahradit.
Z tohoto popisu je jasně patrné, že k úspěšné výměně dat je jednoznačně nutné mít k dispozici přesný popis dodaných dat a to jak popis struktury datového souboru, tak i popis logického významu jednotlivých prvků ve výkresu obsažených (norma, směrnice, nařízení ...). Teoreticky tedy není tedy nutné vytvářet nějaký obecný převodní formát. Pokud si ale uvědomíme, kolik druhů programového vybavení společně s různými normami, směrnicemi a předpisy je dnes používáno, dostaneme se k poměrně velkému počtu jejich kombinací, nepočítaje v to jejich neustálý vývoj (nové verze programových produktů, nově vydané normy, předpisy, nařízení ...)
Pokud za takového stavu probíhá výměna dat více systémy, stává se udržování bezchybného výměny dat složitou a tím i nákladnou záležitostí. Okamžitě se tedy naskýtá otázka, zda by tento problém nešel řešit nějak efektivněji - stanovením jednotného a srozumitelného postupu.
Pokud prostudujeme hlouběji prvky ve strukturách jednotlivých programových produktů a jejich používání v různých směrnicích, nařízeních a vyhláškách, lze dospět k zajímavým poznatkům.
1. každý prvek je definován minimálně jedním bodem (=polohou)
2. každý prvek je v předpisech pro tvorbu mapy pojmenován
Poloha bodu je vždy dána kartézskými souřadnicemi a pro pojmenování zakreslovaných prvků v předpisech pro kresbu jsou používány všeobecně vžité výrazy. K těmto výrazům je pak doplněny grafické parametry, které později slouží zpětně ke správné interpretaci logického významu prvku mapy. Setkal jsem i se systémy, kde na první pohled není patrno, co zakreslený prvek znamená a prvek bylo nutno identifikovat a teprve podle dalších jeho vlastností určit, co znamená. U takto navržených systémů se vypovídací schopnost mapy ztrácí po jejím vytištění. Takto navržené systémy nepovažuji za zdařené a je z nich zcela zřejmé, že byly navrhovány bez znalostí základů mapování.
Ve většině systémů se také objevuje nedostatek dostupných dat potřebných pro provoz celého systému, jejichž tvorba a údržba však nespadá do oboru příslušné firmy. Jasným příkladem jsou polohopis a mapa vlastnických vztahů (katastrální mapa). Nedostupnost takových dat může mít několik důvodů:
1. neexistence organizace, která příslušná data udržuje (polohopis)
2. právní problémy v poskytování dat (katastrální mapa, neveřejné údaje map)
3. neexistence potřebných dat
4. přemrštěné finanční požadavky
Organizace, které potřebují pro svoji práci tato (pro ně doplňková) data a nemohou je získat, definují je přímo do svých systémů. Dodavatel mapy (geodet) potom musí pro každého odběratele měřit polohopis různě (odlišnosti jsou však minimální), ale obvykle zcela rozdílně zakreslovat. Takové postupy nevedou k "dokonalé" mapě, ale pouze k mrháním finančními prostředky a pracovními silami.
Tento standard vznikl s cílem sjednotit výměnný (přenosový, předávací) formát pro přenos dat digitální technické mapy města (dále jen DTMM) mezi různými programovými produkty
Účelem Standardu pro strukturu a výměnný formát digitální technické mapy města je zajištění bezproblémového přenosu datového obsahu DTMM mezi informačními systémy a sjednocení interpretace údajů technické mapy města.
Pro výměnný formát digitální technické mapy byl stanoven textový formát. Důvodem byla jeho čitelnost v libovolném textovém editoru. Formát se skládá z částí povinných a nepovinných. Mezi povinné údaje samozřejmě patří určení polohy všech bodů popisujících polohu a tvar prvku a kód stanovující logický význam prvku. Kódy prvků jsou definovány v tabulce Standardu. Je počítáno s budoucím rozšiřováním jak tabulky, tak i kódu.
Základními prvky jsou BOD, LINIE, PLOCHA a TEXT.
BOD je používán pro vyjádření reálného prvku do mapy symbolem (prvky nezakreslitelné v měřítku mapy)
LINIE vyjadřuje průběh reálného prvku v mapě svým průběhem (obrysem)
PLOCHA je používána pro plošné prvky
TEXT je používán pro popis reálných prvků v mapě, ve skutečnosti neexistuje
Jakékoliv grafické vyjádření (barva, symbol, vrstva, ...) není v tomto formátu definováno a je zcela ponecháno na uživateli, který si jej stanoví pro každý prvek podle svých zvyklostí.
Z dříve uvedených faktů je zcela zřejmé, že pro úspěšné používání VF DTMM je zapotřebí každé programového vybavení doplnit funkcí (modulem) pro výdej a příjem tohoto formátu.
Jednotnou digitální mapu Prahy (JDMP) tvoří a udržuje Institut městské informatiky hlavního města Prahy (IMIP). JDMP v sobě integruje obraz katastrální mapy a technickou mapu města. Slouží jako jednotný a závazný podklad pro potřebu orgánů a organizací, které zajišťují správu řízení rozvoje města a provoz jeho veřejných zařízení, a pro fyzické a právnické osoby, které provádějí investiční a stavební činnost. Je určena zejména pro územně plánovací činnost, pro přípravnou a projektovou dokumentaci staveb, údržbu a evidenci podzemních a nadzemních objektů a vedení technického vybavení. IMIP je také pověřen výdejem dat z JDMP výše citovaným uživatelům.
Celá JDMP je provozována v databázovém prostředí s podporou dalších programů (editory vektorové grafiky, editory textu, editory rastrů ...) a zahrnuje v sobě velké množství dat z velice rozdílných zdrojů. Jednou velkou skupinou dat jsou vektorová data popisující technickou mapu města (TMM - definice lit. 1 - kap. 3.1 a 3.2). Tato množina dat se interně dále dělí na data získaná od správců sítí (tzv. autorizovaná) a data z ostatních zdrojů. Autorizovaná data od správců sítí jsou do JDMP pouze začleněna a je-li požadavek, tak v nezměněné podobě vydávána.
VF DTMM se nyní začíná používat pro výměnu dat mezi IMIP a správci inženýrských sítí. Nebudu se zde zabývat legislativou při poskytování dat ani finančními otázkami. Mým úkolem je zabývat se výměnou dat pouze z technického hlediska.
Podle dosavadního jednání s dodavateli a odběrateli prý nebude problém jejich programové vybavení doplnit o potřebné funkce (moduly). Po počátečních úvahách se totiž jeví do budoucna jako ekonomicky výhodnější investice rozšíření programového vybavení, než výdej a příjem dat dosavadním způsobem (konverze).
Při praktickém aplikování VF DTMM se projevil problém při vyhledávání odpovídajících si prvků v obou systémech. Problém vyplývá z toho, že při tvorbě obou systémů nebylo přistoupeno k důslednému systematickému dělení. Při definici VF DTMM bylo použito dělení prvků podle jejich typu (bod, linie, text, plocha). Dále byly prvky rozděleny na skupiny dle ČSN 01 3411, a tyto dále děleny opět podle dříve jmenované normy. Tato norma však svým rozsahem a strukturou nevyhovuje počítačovému zpracování map.
Nesystematický přístup k prvkům mapy lze vysledovat např. v dělení TVY (technického vybavení). Jednotlivé prvky se vyskytují u několika typu IS, ale nelze je najít vždy u obou technologií. Například by bylo vhodné doplnit zákres IS o "doplňkové" informace (bez rozlišení, nadzemní, ověřené, neověřené, ...). K těmto doplňkovým informacím by mohly náležet i další doplňkové informace o typu IS (plyn, voda, kanalizace, silové, sdělovací, teplovod, ...) atd.
Pokud nebude k dispozici systematické dělení prvků zakreslovaných do mapy, bude obtížné využít možnosti VF DTMM pro snadnou výměnu dat mezi jednotlivými uživateli.
Podle ČSN 01 3411 bylo také použito kódování popisu jednotlivých prvků. Kódy těchto popisů jsou ve skupině deset dle jmenované normy. Zřejmě by bylo vhodnější pro celý kód použít stejnou "číselnou" část kódu popisovaného prvku s tím, že mu bude předřazen typ "T" (=popis). Tímto způsobem by byla stanovena jednoznačná vazba textu k odpovídajícímu prvku mapy.
Např. existuje kód prvku. Je-li předsazen typ "B" (bod), je takový prvek zobrazitelný v měřítku mapy pouze jako symbol. Je-li to typ "P", pak je zřejmé, že tento prvek je v mapě zobrazen svým obvodem (který ale nemusí být stejného typu). U typu "T" by pak bylo zřejmé, že náleží prvku se stejným kódem. Nepovažuji proto za nutné zavádět samostatné kódy pro popis prvků, které se jako takové vyskytují v mapě.
Dalším problém se jeví v používání nejednoznačné terminologie. Při hledání odpovídajících si prvků obou systémů je obtížné určit, zda vyhledaný pár prvků v obou systémech vyjadřuje opravdu totéž.
Např. v JDMP se používá termín "budova nespalná" a v definici VF DTMM je používán termín "budova zděná, betonová, kovová". Lze usoudit, že oba termíny mají stejný význam, ale nemusí tomu tak být vždy. Například pojmy "sdělovací vedení" a "slaboproud" již tak jasné nejsou.
Pokud se prochází slovní popis jednotlivých prvků, pak se setkáváme s podrobnějším popisem vlastností, které jsou stejné i pro různé prvky např.: nadzemní, podzemní, vyřazené, autorizované, se slučkou, ověřený, neověřený, měřeno po zásypu, vektorizace, .... Tyto doplňující popisy upřesňují logický význam prvku a velice často se mohou kumulovat (podzemní+vyřazené+vektorizace). Bylo by tedy vhodné definici VF DTMM rozšířit o číselník těchto doplňkových popisů.
Tyto doplňkové informace by napomohly vyřešení dříve popsaných nedostatků t.j. důsledné systematické dělení zakreslovaných prvků a používání jasných a jednoznačných termínů.
Při přiřazování prvků JDMP k prvkům definovaným ve VF DTMM nebylo možno v definici VF DTMM nalézt všechny prvky, které jsou v JDMP používány. Chybějící definice ve VF DTMM byly doplněny a jejich seznam byl uveden v tabulce návrhu na doplnění VF DTMM. Bude tedy zapotřebí kontaktovat Úřad pro veřejné informační systém a požádat o doplnění Standardu ISVS pro strukturu a výměnný formát digitální technické mapy města a o vydání nové verze.
Z prvních zkušeností s používáním VF DTMM zcela jasně vyplývá, že navržený způsob výměny dat je reálný a ekonomický. Standard výměnného formátu digitální technické mapy není osamocen (výměnné formáty pro katastrální mapu, územně plánovací dokumentaci, terminologické slovníky) a pevně věřím, že počet obdobných standardů bude stoupat.
Dále lze z praxe vypozorovat, že základem v digitální komunikaci není (často draze zakoupené) programové vybavení, ale možnosti komunikace takového vybavení s ostatními systémy. Jsem si zcela jist, že programové vybavení, které si organizace vybrala a zakoupila, je pro její potřebu optimální, ale zajisté potřebuje k plnému využití i data ze systémů jiných.
S postupem doby je také patrná změna pohledu uživatelů na počítačové vybavení. Mnozí si začínají uvědomovat, že získat dobrý počítač není žádný problém, vhodný program pro svoji problematiku lze dnes zajisté vybrat ze široké nabídky, ale "svoje" vhodná data pro takový program se mnohdy získávají obtížně. A zde si budují svoji pevnou pozici standardy výměnných formátů.