Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze
Martin Vícha
Návrh aplikace pro tvorbu cenové mapy nemovitostí Bakalářská práce
2010 1
Zadávací list
2
Čestné prohlášení Prohlašuji, že bakalářskou práci na téma „Návrh aplikace pro tvorbu cenové mapy nemovitostí“ jsem vypracoval samostatně a veškerou použitou literaturu a další prameny jsem řádně označil a uvedl v přiloženém seznamu.
V Praze dne ...............................
........................................ podpis
3
Poděkování Touto cestou chci poděkovat Ing. Lucii Vaníčkové, Ph.D. za odborné konzultace a pomoc při zpracování mé bakalářské práce.
4
Anotace Bakalářská práce popisuje návrh a implementaci aplikace sloužící k vytváření cenových map nemovitostí. Ve zjednodušeném modelu ukazuje implementaci, která modeluje, jak vnější faktory prostřednictvím své váhy a vzájemné interference ovlivňují ceny nemovitostí. V závislosti od polohy a lokace je tak nemovitost na základě matematického modelu oceněna a následně srovnána se svou tržní hodnotou. V závěru práce je nastíněn návrh informačního systému založeném na této aplikaci a možnosti jeho využití.
Abstract The thesis describes the design and implementation of an application capable of creating residential heat maps. It uses a simplified modeling to demonstrate the influence of the external factors on the property prices, based on their weight, distance and mutual interference. The property is automatically valuated depending on its location and compared to its market value using the simplified mathematical model. A simple information system along with the possible applications is sketched at the end of the thesis, with the software serving as a core of it.
5
Obsah Úvod ........................................................................................................................................... 7 1
2
3
Úvod do problematiky ......................................................................................................... 9 1.1
Proces oceňování nemovitostí ...................................................................................... 9
1.2
Vysvětlení pojmů a zkratek ........................................................................................ 10
1.3
Současný stav ............................................................................................................. 13
Návrh aplikace ................................................................................................................... 15 2.1
Účel a požadavky aplikace ......................................................................................... 15
2.2
Technologie vhodné pro vytváření aplikace............................................................... 15
2.3
Typ cílové aplikace a zvolené technologie ................................................................. 15
2.4
Datové toky v aplikaci ................................................................................................ 17
2.5
Vstupy, výstupy a podporované formáty.................................................................... 20
2.6
Testování aplikace ...................................................................................................... 21
2.7
Objektový návrh aplikace ........................................................................................... 22
2.8
Návrh uživatelského rozhraní ..................................................................................... 27
Implementace ..................................................................................................................... 30 3.1
Proces implementace .................................................................................................. 30
3.1.1
Hlavní myšlenka aplikace ................................................................................... 31
3.1.2
Kostra aplikace .................................................................................................... 34
3.1.3
Cenová mapa ....................................................................................................... 35
3.1.4
Tvorba diferenční mapy a srovnávání cen .......................................................... 40
Licenční omezení a zmenšení funkcionality ........................................................................ 40
4
5
3.2
Uživatelské rozhraní ................................................................................................... 41
3.3
Problémy při implementaci ........................................................................................ 45
3.4
Finální verze implementace ........................................................................................ 46
Používání a využití aplikace .............................................................................................. 49 4.1
Nastavování vah ......................................................................................................... 49
4.2
Další využití aplikace ................................................................................................. 49
Stručný návrh informačního systému ................................................................................ 51
Závěr ........................................................................................................................................ 53 Seznam použité literatury a pramenů ....................................................................................... 54
6
Úvod Bakalářská práce s názvem Návrh aplikace pro tvorbu cenové mapy nemovitostí se zabývá návrhem, implementací, používáním a využitím aplikace pro tvorbu cenových map nemovitostí. Zabývá se taky návrhem na vytvoření informačního systému využívajícího jako jádro principy a části této navržené aplikace. Na základě analýzy různých faktorů působících na nemovitosti v rámci určité lokality je možné vytvořit cenovou mapu, která není produktem pouhé deskripce již existujícího stavu cen, ale vytvořit mapu novou, která umožňuje tyto ceny stanovit. Tato mapa taky určuje, nakolik se reální, tedy tržní ceny liší od úrovně cen vypočtených způsobem navrhovaným v této bakalářské práci. Cílem mé bakalářské práce je navrhnout a posléze implementovat aplikaci umožňující vytvořit takovou cenovou mapu rezidenčních nemovitostí, která bude zobrazovat jejich ceny na základě posouzení externích vlivů nacházejících se v dané lokalitě. Tato aplikace založená na využití geografických informačních systémů bude využívat analytické a procesní nástroje systému ArcGis a ty posléze kombinovat s vlastním modelem posuzování váhy a rozsahu vzájemného vlivu a působení jednotlivých faktorů. Práce se dělí na čtyři části: v první jsou vysvětleny pojmy související s oblastí geografických informačních systémů a důvody k napsání navrhované aplikace. Čtenáře seznamuje s procesem jak klasického, tak počítačového oceňování nemovitostí a prezentuje současný stav na trhu produktů s počítačovými systémy určenými k práci s touto problematikou. Ve druhé části je pak stručně popsán návrh takové aplikace a prezentaci navrhované architektury. Důraz je kladen na vysvětlení souvislostí, možnostech následné implementace a obrazovou dokumentaci. V závěru kapitoly je navrhováno uživatelské rozhraní. Třetí část se věnuje implementaci aplikace. Tady tkví těžiště práce, které slovně i graficky popisuje tvorbu cenové mapy v jednotlivých krocích. Logicky a chronologicky popisuje a názorně ukazuje, jaký postup byl použit a jak aplikace funguje. Slovně, číselně i graficky demonstruje způsoby počítání cen v závislosti od faktorů. Ukazuje implementaci architektury aplikace (kostru aplikace) a její uživatelské rozhraní. V poslední, čtvrté části práce, je pak popsána možnost dalšího využití aplikace a stručný návrh informačního systému, který je na této aplikaci postaven. Nastiňuje tedy možnost, jak ji 7
použít v prostředí internetu. Umožní tím, aby její služby využívaly různé soukromé a vládní instituce. Aby bylo vůbec možné splnit zamýšlený cíl a takovou aplikaci navrhnout a implementovat, bylo nutné použít poznatků zejména ze tří oborů: z ekonomie, programování a geografických informačních systémů. Na čtenáře jsou tak kladeny znalostní požadavky, které předpokládají znalosti alespoň ze základního kurzu ekonomie, základní znalosti objektového programování a obecné povědomí o geografických informačních systémech. Pro lepší orientaci a pochopení významu slov je za úvodem zařazená část vysvětlující klíčové pojmy. V případě, že je v práci použit pojem, který tyto základní znalosti v některé oblasti překračuje, je při něm uveden odkaz na zdroj a tím i další literaturu, která čtenáře do problematiky uvede. Aby si čtenář dovedl některé souvislosti lépe představit, je práce doprovázena četnými příklady z každodenního světa.
8
1 Úvod do problematiky 1.1 Proces oceňování nemovitostí U stanovování cen se obecně postupuje vždycky od konkrétní položky, s přihlédnutím na ceny na trhu v konkrétní lokalitě – městské části, městě nebo státě. Jestli jde o spotřební zboží nebo potraviny či nemovitosti, model je v tomto základě srovnatelný. Proces oceňování vždycky obsahuje několik proměnných, které jsou součástí oceňovacího modelu a které podstatným způsobem předurčují cenu statku. Tak například u automobilů předurčuje cenu na trhu jeho užitná hodnota, zdanění a spotřeba, ale taky v neposlední řadě úroveň cen automobilů na daném trhu (které jsou pak určovány dalšími faktory). Nejde pouze o ceny automobilů obecně, ale taky o segment trhu automobilů a danou třídu. Do hry vstupují pak další skutečnosti, jakými jsou například cílový zákazník (jestli je relativně bohatší nebo chudší, jestli auto bude používat na firemní nebo osobní účely, což bychom taky mohli rozčlenit) a taky cílový účel, na který se dá auto používat (například nákladní auta nebo autobusy se odlišují nastavením cen a její tvorbou od osobních automobilů). Oceňování nemovitostí podléhá dvěma takovým základním myšlenkám, neboli atributům, které ovlivňují veškerý proces tvorby jejich cen. Základní myšlenkou oceňování nemovitostí je skutečnost, že každá nemovitost je jedinečná a odlišná1. Druhým pravidlem, dokonce ještě důležitějším, je, že jednou ze základních činitelů určujících hodnotu nemovitosti je její poloha2. V praxi to znamená, že nemovitost v neobydlené oblasti má mnohem nižší hodnotu, než kvalitativně srovnatelná nemovitost ve městě. Podobně dva domy ve stejné oblasti se liší cenou, pokud se liší taky vybavením. Z toho taky vyplývá například situace, že domy v řadové zástavbě (postavené stejnou společností a stejně vybaveny) budou mít s největší pravděpodobností velmi podobnou cenu, avšak ve skutečnosti ne o každý dům bude stejný zájem. Dům, který je na začátku ulice má jinou dostupnost a mírně odlišné prostředí než ten, který stojí na jejím konci. Určování cen nemovitostí provádějí tzv. odhadcové majetku, kterých profese je regulována státními orgány. Zatímco v USA provádějí regulaci jednotlivé členské státy Unie, v České republice výkon tohoto povolání podléhá regulaci ze strany Živnostenského zákona, konkrétně novely č. 130/2008 Sb. ze dne 20.3.2008, platnou od 1.7.2008 na základě živnostenského 1
Real estate appraisal In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2005-11-22, 2010-05-05 [cit. 2010-05-09]. Dostupné z WWW:
. 2 Tamtéž.
9
oprávnění3. Ta rovněž stanovuje podmínky pro získání a výkon tohoto povolání, stejně tak kategorie věcí, pro které je možné provádět odhad. Odhadci majetku mají možnost být posléze zastřešeni Českou komorou odhadců majetku, která je členem celoevropské organizace TEGoVA (The European Group of Valuers Association, Evropská organizace sdružující jednotlivé národní asociace odhadců) již od roku 1993. TEGoVA z titulu své pozice vydává EVS neboli European Valuation Standards (evropské oceňovací standardy) obsahující závazné postupy při oceňování nemovitostí pro různé účely z více hledisek4. Již šestou verzi standardů si je možné stáhnout ze stránek organizace5. Obecně se k odhadu hodnoty rezidenční nemovitostí používají dvě metody: metoda oceňování na základě prodejů ze stejné lokality a nákladová metoda6. V prvním případě odhadce zjišťuje ceny prodaných nemovitostí ve stejné lokalitě a pak udělá soupis rozdílů co do kvality nemovitostí. Výsledkem je pak seznam, ve kterém je uvedeno, za kolik by byla která nemovitost prodána, pokud by byla stejné kvality jako oceňovaná nemovitost. Druhý případ oceňování se používá spíš pro novější stavby, kde není těžké dopátrat se nákladů vynaložených při stavbě nemovitosti. V obou případech vstupují do hry dva uvedené faktory, kterými jsou lokalita a jedinečnost. V této bakalářské práci se zaměřuji právě na první uvedený faktor, který ovlivňuje cenu nemovitosti podstatným způsobem. Například několika tisíců akrů velký ranč v Texasu může mít stejnou tržní hodnotu jako byt v Kensingtonu. Faktor jedinečnosti je v této práci a navrhované aplikaci pro zjednodušení zanedbaný, jakékoliv postupy a výpočty je však možné po mírném upravení použít i na výpočet na základě vnitřní hodnoty, nebo dokonce na výpočet zahrnující kombinaci obou nebo více faktorů.
1.2 Vysvětlení pojmů a zkratek API – Application Programming Interface neboli aplikační programové rozhraní. Podle publikace Podniková informatika7 si lze toto rozhraní představit jako „množinu pravidel, která
3
Česká komora odhadců majetku. Česká komora odhadců majetku [online]. 2008 [cit. 2010-05-09]. Profese odhadce. Dostupné z WWW: . 4 TEGoVA. TEGoVA Homepage [online]. 2009 [cit. 2010-05-09]. EVS (Blue Book). Dostupné z WWW: . 5 TEGoVA. European Valuation Standards 2009 : The Blue Book [online]. Sixth Edition. Belgium : Gillis nv/sa, 2009 [cit. 2010-05-09]. Dostupné z WWW: . ISBN 978-90-9024138-8. 6 WICKELL, Janet. Home Buying - Facts About Residential Real Estate Appraisals [online]. 2010 [cit. 2010-0509]. About.com. Dostupné z WWW: . 7 GÁLA, Ing., Libor; POUR, Doc. Ing. CSc., Jan; TOMAN, Doc. Ing. CSc., Prokop. Podniková informatika. Havlíčkův Brod : Grada Publishing, a.s., 2006. 485 s. ISBN 80-247-1278-4.
10
upravuje komunikaci mezi programy či jednotlivými částmi programů – jaké metody/funkce lze volat, jaké lze předávat parametry, jaké budou návratové hodnoty“8. ArcGis (Desktop, Server) – představuje balík programového vybavení a API z oblasti geografických informačních systémů od společnosti ESRI. Zatímco verze Desktop 9 je určena pro stolní počítače a obsahuje nástroje k přímé editaci a prohlížení map (nástroje ArcReader, ArcView, ArcEditor a ArcInfo), verze Server10 je určena pro internetové GIS služby, které mohou být používány (anglicky consumed) kromě serverů, internetových prohlížečů a různých platforem taky z desktopové nebo mobilní verze systému ArcGis. ArcObjects – komponenty, které tvoří jádro systému ArcGis, jsou používány k vytváření a rozšiřování funkcionality systému11. Aplikační rámec (software framework) – soubor znovu použitelných návrhů a kódů, který může být použit při vývoji počítačových aplikací12, který pomáhá při zvládání opakujících se úkolů ale sám o sobě netvoří aplikaci ani žádné komplexní a uzavřené úkoly13. Příkladem může být kód pomáhající s připojením k databázi nebo konverzí datových typů. AVM – Automatic Valuation Model neboli automatický model oceňování, je název pro službu, která dokáže ocenit nemovitosti na základě matematického modelování a použití dat z databáze14. C# – programovací jazyk pro prostředí .NET. Podle specifikace jazyka C#15 od společnosti Microsoft jde o „jednoduchý, moderný, objektově orientovaný a typově bezpečný programovací
8
Tamtéž, strana 223. ESRI. ESRI Products Overview [online]. 2010 [cit. 2010-05-28]. Desktop GIS. Dostupné z WWW: . 10 ESRI. ESRI Products Overview [online]. 2010 [cit. 2010-05-28]. ArcGis Server. Dostupné z WWW: . 11 ESRI. ESRI Resource Centers [online]. 2010 [cit. 2010-05-28]. Dostupné z WWW: . 12 CHEN, Xin. Developing Application Frameworks in .NET. United States of America : Apress, 2004. 370 s. ISBN 1-59059-288-3. 13 PANCHAL, Chetan. Chetan's web scribblings! [online]. 2008-12-06 [cit. 2010-05-28]. What is Framework?. Dostupné z WWW: . 14 DOWNIE, Mary Lou; ROBSON, Gill. Automated Valuation Models : An International Perspective [online]. London : The Council of Mortgage Lenders, 2007 [cit. 2010-05-28]. Dostupné z WWW: . 15 Microsoft Corporation. C# Language Specification 3.0. :, 2007. 519 s. Dostupné z WWW: . 9
11
jazyk“16, který „má své kořeny v rodině jazyků C a je bez dalších znalostí zřejmý programátorům znalým jazyk C, C++ a Javu“17. CAMA – Computer Assisted Mass Appraisal neboli hromadné ocenění pomocí počítačů, označuje aplikaci, která hromadně ocení nemovitosti ve stanovené lokalitě a tím umožní stanovit výši daní a další poplatky vládními institucemi18. CLR, virtuální stroj – Common Language Runtime (technický pojem) je běhové prostředí, které s pomocí CLI (Common Language Infrastructure, technický pojem) vytváří virtualizované prostředí, tzv. virtuální stroj, umožňující běh programů na tzv. virtuální platformě, podobně, jak je tomu například v prostředí virtuálního stroje platformy Java. Více informací o této problematice se nachází na stránkách společnosti Microsoft19. COM – v této práci zkratka používaná výhradně pro pojem Component Object Model (technický pojem). Představuje standard společnosti Microsoft pro rozhraní používané pod operačním systémem MS Windows k různým typům komunikace mezi komponenty, jako je například komunikace mezi procesy (interprocess communication), k dynamickému vytváření objektů apod20. Feature – může představovat entity dvou typů: Buď je to „skupina prostorových prvků, která jako celek představuje entitu skutečného světa“21 nebo v užším smyslu „zobrazení objektů reálného světa na mapě“22. Feature Class – je jednoduše řečeno sada skupin prostorových prvků (features). Obsáhlejší definice tohoto pojmu je k nalezení v knize Editing in ArcMap od společnosti ESRI23. Geoprocessing – operace používaná k manipulaci s daty, která obvykle „zahrnuje načtení vstupní sady dat, jejich proměnu nebo zpracování a následný výstup této zpracované sady dat“24. .NET – neboli .NET Framework, sada API umožňujících tvorbu a běh aplikací ve virtualizovaném prostředí CLR. 16
Tamtéž, strana 1. Tamtéž, strana 1. 18 CAMA Resources & Technologies, LLC. CAMA Resources & Technologies, LLC [online]. 2010 [cit. 201005-28]. CRT's FAQ. Dostupné z WWW: . 19 Microsoft Corporation. Common Language Runtime Overview : Microsoft MSDN [online]. 2010 [cit. 201005-28]. Dostupné z WWW: . 20 Microsoft Corporation. COM: Component Object Model Technologies : Microsoft COM [online]. 2010 [cit. 2010-05-28]. Dostupné z WWW: . 21 ESRI. ArcGis 9: Editing in ArcMap. USA : ESRI, 2004. 495 s. 22 Tamtéž, strana 462. 23 Tamtéž, strana 462. 24 ESRI. ArcGis 9: Geoprocessing in ArcGis. USA : ESRI, 2004. 364 s. 17
12
RCW – tzv. proxy objekt (objekt, který je prostředníkem mezi objekty) vytvořený za účelem komunikace a zpřístupnění COM objektů v prostředí .NET. Více informací je na stránkách MSDN věnovaných tomuto typu objektů25. Shapefile – vektorový datový formát společnosti ESRI uchovávající polohu, tvar a atributy geografických prvků26.
1.3 Současný stav V současné době existuje několik aplikací umožňujících vytváření cenových map. Všechny spadají do kategorie webových aplikací založených na systému klient – server. Zejména jde o cenové mapy vytvořené za účelem dokumentace nebo přehlednějšího zobrazení výsledků. Příkladem takových cenových map jsou například služby generování cenových map letenek podle místa odletu od společnosti SkyScanner.com27 nebo mapa cen benzinu v USA od společnosti GasBuddy.Com Organization, Inc.28 Pro mapy nemovitostí uvedu např. cenovou mapu nemovitostí v USA od společnosti Trulia, Inc29 umožňující prohlížet ceny nemovitostí podle států nebo okresů (tzv. counties) USA. Další významnou mapou je např. cenová mapa nemovitostí v okolí Chicaga zobrazující medián cen poskytovaná službou deníka Chicago Tribune30 nebo cenová mapa nemovitostí a vývoje jejich cen v Anglii a Walesu od společnosti Calnea Analytics31. Vždycky ovšem u těchto cenových map jde o vytvoření cenových map na základě již známých cen. Nejprve tedy existuje sada zdrojových dat, která obsahuje lokalitu a cenu nemovitosti a další potřebné atributy. Následně je vytvořena cenová mapa, která
pouze
zobrazuje, neboli popisuje již existující stav a je proto vhodná pouze pro jakési schematické zobrazení skutečnosti, tedy něčeho, co již existuje a co potřebujeme názorněji popsat. Na druhou stranu existují taky dvě metody, neboli systémy pro automatický výpočet ceny nemovitostí, jednoduše pro automatické oceňování. Jde o metody CAMA a AVM. 25
Microsoft Corporation. Microsoft MSDN [online]. 2010 [cit. 2010-05-28]. Runtime Callable Wrapper. Dostupné z WWW: . 26 ESRI. ArcGis 9: Editing in ArcMap. USA : ESRI, 2004. 495 s. 27 Skyscanner Ltd. Skyscanner [online]. 2010 [cit. 2010-05-09]. Dostupné z WWW: . 28 GasBuddy Organization Inc. USA National Gas Price Heat Map [online]. 2010 [cit. 2010-05-09]. Dostupné z WWW: . 29 Trulia, Inc. US Home Prices And USA Heat Map [online]. 2010 [cit. 2010-05-09]. Dostupné z WWW: . 30 Chicago Tribune. Median Price Heat Map [online]. 2010 [cit. 2010-05-09]. Dostupné z WWW: . 31 Calnea Analytics Ltd. Heatmaps [online]. 2010 [cit. 2010-05-09]. Dostupné z WWW: .
13
CAMA, tedy Computer-Assisted Mass Appraisal (hromadné oceňování pomocí počítače) je metodou systematického hromadného oceňování nemovitostí k danému datu pro potřeby zdanění nemovitostí32. Je používané zejména státními orgány, soukromý sektor jej vesměs nepoužívá. Příkladem takového systému je systém Instant jihoafrické společnosti SouWest Software33. AVM, tedy Automatic Valuation Model (automatický oceňovací model nebo model automatického oceňování) je způsobem navrhování (odhadování) tržní hodnoty nemovitosti prostřednictvím matematických modelů a podpůrných dat v databázi34. Automatické ocenění je založeno na analýze polohy, časového hlediska a vlastností nemovitosti na základě dat získaných z předešlých zjištění. Nejvíc zpochybňovanou částí je skutečnost, že spolehlivost a tím i věrohodnost výstupů z aplikace AVM je silně závislá na použitých datech a modelech programu. Aplikaci navrhovanou v této bakalářské práci je možné zařadit mezi aplikace AVM, s použitím nástrojů pro geoprocessing a vlastních matematických modelů. Jak již bylo řečeno, navrhovaná aplikace z důvodu rozsahu práce předpokládá některá zjednodušení a zajímá poněkud odlišný pohled na tvorbu cen rezidenčních nemovitostí. Příkladem systémů AVM je například systém od již uvedené společnosti Calnea Analytics edice Instantvalue35. Pro zajímavost, cena odhadu CAMA se v USA pohybuje obecně někde mezi 25 – 75 USD, u AVM je to 100 – 125 USD a v případě osobního odhadu je poplatek obecně vyšší než 225 USD36.
32
CAMA Resources And Technologies LLC. CAMA Resources And Technologies LLC [online]. 2010 [cit. 2010-05-09]. Frequently Asked Questions. Dostupné z WWW: . 33 SouWest Software. Souwest Software [online]. 2010 [cit. 2010-05-09]. Instant. Dostupné z WWW: . 34 Automated Valuation Model In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2008-11-18, 2010-04-28 [cit. 2010-05-09]. Dostupné z WWW: . 35 Calnea Analytics. Calnea Analytics [online]. 2010 [cit. 2010-05-09]. Automated Valuations. Dostupné z WWW: . 36 South Central Kansas Regional Chapter of IAAO. CAMA - AVM : Are they the same? [online]. 2006-07-05 [cit. 2010-05-09]. CAMA - AVM. Dostupné z WWW: .
14
2 Návrh aplikace 2.1 Účel a požadavky aplikace Účelem navrhované aplikace je vytvořit program, který na základě uživatelského výběru vhodných externích faktorů (vstupů) s přiřazením hodnot jejich atributům (nastavení) vygeneruje cenovou mapu, která bude barevně zobrazovat jednotlivé úrovně vypočtěných cenových koefcientů. Tyto koeficienty budou získány postupným výpočtem z hodnot atributů. Má umožnit prohlížení výsledků jak v grafické podobě ve formě mapy, tak v interaktivní tabulkové formě. Dále má umožnit vytvořit diferenční cenovou mapu, která bude zobrazovat rozdíl mezi navrhovanými cenami a skutečnými, tržnými cenami nemovitostí. Aplikace bude používána pouze ke stanovení cen rezidenčních, tedy dlouhodobě obývatelných nemovitostí a prostor.
2.2
Technologie vhodné pro vytváření aplikace
Aplikace bude využívat prostředí geografického informačního systému ArcGis od společnosti ESRI, který poskytuje dostatečné možnosti pro analýzu geografických dat, geoprocessing a vizualizaci map. Poskytuje široký záběr pro práci s geodatabázema a modifikaci dat a podporuje standardizované a otevřené formáty, jako je např. shapefile37. Součástí systému ArcGis je zároveň aplikační rámec (neboli software framework) ArcObjects, umožňující vývoj aplikací nad tímto systémem. Umožňuje psaní aplikací v různých jazycích a na různých platformách. Z jazyků pro nativní vývoj jsou to například Visual Basic 6, C++ nebo Visual C++, z interpretovaných jazyků například Python nebo Visual Basic for Applications. Podporuje taky použití v prostředí (virtuálním stroji) Javy a v neposlední řadě je možné taky rámec ArcObjects použít i v prostředí .NET. Jak je vysvětleno v následující podkapitole, právě toto prostředí jsem si zvolil pro vytvoření této aplikace.
2.3 Typ cílové aplikace a zvolené technologie Do úvahy přicházely dva typy aplikace: jednak rozšíření aplikace ArcMap prostřednictvím modulu (rozšíření neboli extension) nebo vytvoření samostatné aplikace (standalone application) využívající pro svůj běh pouze některé komponenty rámce ArcObjects. Oba přístupy mají své pro a proti.
37
Environmental Systems Research Institute, Inc. ESRI Shapefile Technical Description [online]. USA : ESRI, 1998 [cit. 2010-05-10]. Dostupné z WWW: .
15
Za vytvoření modulu nebo rozšíření aplikace ArcMap hovoří několik faktorů. Jednak je to možnost přímé editace vrstev, unifikované uživatelské rozhraní a přistup ke všem licencovaným nástrojům a možnostem aplikace ArcMap. Z implementačního hlediska se jeví jako nesporná výhoda několikanásobně rychlejší vývoj aplikace, protože není potřeba řešit některé elementární otázky, jako je například ověřování licence k aplikaci nebo nástrojům, uživatelské ovládací prvky nebo stabilita aplikace. Jako nevýhody se tady jeví zejména celková těžkopádnost aplikace a vysoké paměťové nároky (aplikace ArcMap 9.3.1 spotřebuje po zapnutí s výchozí sadou rozšíření přibližně 32 MB operační paměti, nárazově se číslo může zvýšit až na 140 MB). Samostatná aplikace má naproti modulu několik výhod. Za prvé, je možné ji vytvořit zcela libovolně podle potřeb a není nutné přizpůsobovat kód, funkčnost a uživatelské rozhraní standardům aplikace ArcMap. Za druhé, rychlost samostatné aplikace sice je do jisté míry vázána na rychlost nástrojů v rámci rámce ArcObjects (například pokud jde o geoprocessing nebo využívání možností geodatabáze), v ostatních případech je zcela na tvůrci aplikace, jak ji naškáluje a s jakými nároky na hardware počítače poběží. Za třetí, při pádu samostatné aplikace sice uživatel ztratí neuložená data z aplikace, nebudou však ztracena data z aplikace ArcMap: její činnost nebude nijak ohrozena. Dalším argumentem pro tvorbu samostatného programu je možnost využít velkých částí kódu a objektů při zachování rozšiřitelnosti a přenosu pod jiné rámce nebo implementace do informačního systému: není až tak velkým problémem už existující kód, pokud je dobře navržený, přenést do jiného prostředí (druhou věcí je, že se tady často vyskytují problémy a zdržení). Nepříjemnou stránkou tvorby samostatné aplikace je její implementace od nejnižších částí až po uživatelské rozhraní. Zde se nachází několik nepříjemných omezení a zdlouhavých fází, jako je například návrh uživatelských ovládacích prvků a licenční omezení oproti verzi ArcMap. Protože je systém ArcGis vytvořen, jak již bylo spomenuto, jako nativní aplikace pod operačním systémem Windows, rámec ArcObjects je spřístupněn do prostředí .NET framework prostřednictvím COM objektů a tím skýtající mnoho omezení a nepříjemností. Jedním z nich je například problematická implementace běhu programu ve více vláknách, nutnost zbavovat se odkazů na tzv. RCW (Runtime Callable Wrapper) nebo pomalý běh a komunikace mezi objekty v rámci a mimo prostředí .NET (.NET a COM). Tyto problémy, nicméně, nejsou nijak závažnou překážkou k tomu, aby bylo nutné uvažovat o vytvoření modulu aplikace, proto je cílem navrhnout samostatnou aplikaci na platformě .NET nad rámcem ArcObjects využívající WinForms pro uživatelské prostředí. Za programovací jazyk byl zvolen jazyk C#. Pro správu zdrojového kódu bude použitý systém správy obsahu Microsoft 16
Team Foundation Server 2010, který umožňuje pohodlnou práci a zapojení do integrovaného vývojového prostředí Microsoft Visual Studio 2010. Posledně jmenované jsem používal ve verzi Professional. Pro tvorbu jednotkových testů (tzv. unit testing) je použit rámec NUnit ve verzi 2.5.5. Aplikace je navrhována pro běh pod Microsoft .NET Framework verze 3.5 z důvodu podpory technologie LINQ (zejména využívaného Linq To Objects) a překládána jako aplikace pro 32 bitovou architekturu procesoru (x86), což je omezení vyplývající z použití objektů typu COM systému ArcGis, respektive ArcObjects. Částečně bude aplikace umožňovat běh ve více vláknech, zejména z důvodu potřeby komunikace aplikace s uživatelem počas zpracování požadavků (známé pod pojmem UI Responsivness). Částečně z toho důvodu, že bere do úvahy omezení vyplývající z použití objektů typu COM a tedy bude schopna svoji hlavní činnost vykonávat pouze na jednom procesoru (nebo pouze na jednom jádře procesoru). Za jazyk dokumentace i kódu byla zvolena angličtina, z důvodu bohaté slovné zásoby, ustálených pojmů a slovních spojení pro jednotlivé entity a procesy a zejména jejich jednoznačnost a nezaměnitelnost v kontextu. Za jazyk programu byla zvolena taky angličtina a to ze stejných důvodů. Aplikace je jednoduše přeložitelná formou externích souborů čtených za běhu programu. Dalším argumentem pro zvolení tohoto jazyka byla snaha dodržet konzistenci se systémem ArcGis, z hlediska kódu s rámcem ArcObjects a taky s rámcem .NET Framework, z hlediska uživatele pak kvůli nutnosti stejného označení a jednoznačnosti zdrojových a výstupních formátů souborů, pojmenování jednotlivých vrstev a probíhaných operací.
2.4 Datové toky v aplikaci V navrhované aplikaci je přítomných několik datových toků. Pokud bychom se chtěli na aplikaci podívat jako na jeden systém pod drobnohledem, našli bychom mezi uživatelem jako externí entitou a aplikací jako systémem dva základní datové toky. Viditelnějším je první tok dat od uživatele k aplikaci (obrázek 1), který znamená, že uživatel vybere vhodné vrstvy ke zpracování a zpátky dostane cenovou mapu nebo posléze taky diferenční mapu nemovitostí. Tento datový tok je podporován druhým tokem dat mezi aplikací a rámcem ArcObjects, který provádí činnosti geoprocessingu.
17
Výběr zdrojových dat
Geoprocessing a geodatabáze
Uživatel
Rámec ArcObjects Aplikace Zpracovaná data Cenová a diferenční mapa
Obrázek 1: Kontextuální schéma toků dat v aplikaci. Zdroj: vlastní zpracování.
Jakkoliv se může zdát obrázek triviální a jednoduchý, je potřebný zejména pro ujasnění, co patří a co nepatří do systému, jinými slovy, kde aplikace začíná a kde končí 38. Aplikace pak využívá ještě rámce ArcObjects, kterému zasílá požadavky na zpracování a transformaci dat. Od ní pak obdrží výstupy ze zpracovaných dat. Nacházíme zde tedy další dva datové toky mezi aplikací na jedné straně a externím rámcem na straně druhé. Tady by se bylo vhodné pozastavit nad tím, co patří a co nepatří do systému. Pokud bychom chtěli považovat knihovny rámce ArcObjects za součást aplikace, nebylo by na tom nic špatného. Ostatně taky .NET jako rámec je vytvořen mnoha knihovnami, velmi konzistentně spojenými do spolupracujícího celku. Na druhé straně je pak možné argumentovat tvrzením, že rámec by netvořil součást systému pouze tehdy, pokud by byl na něm nezávislý, jako je to například u webových služeb umožňujících přístup k databázovým serverům. Rámec ArcObjects je však, navzdory snahám o integraci, natolik odlišný od zbytku rámce .NET, že ho můžeme logicky považovat za oddělený a samostatně pracující systém. Přidává tomu i skutečnost, že systém nepracuje ve virtualizovaném prostředí CLR, ale v nativním prostředí operačního systému a pro vrstvu .NET je zpřístupněna formou COM a po své inicializaci vytváří v operačním systému vlastní procesy. Proto by sice z čistě technického hlediska byla uvedená webová služba samostatným systémem, logicky je však součástí většího celku, protože má stejnou architekturu, využívá stejného, homogenního prostředí (například virtuálního stroje nebo CLR) a je ostatně tvořena současně s aplikací službu využívající. Pokud by služba byla samostatná a tvořila samostatný a nezávislý systém, jako je tomu například u webových služeb firmy Amazon39, webových služeb Google AppEngine společnosti Google40 nebo dokonce tzv. 38
Interactive Training Technologies Limited. GetAhead interactive multimedia business and career skills training courses [online]. 2010 [cit. 2010-05-10]. Data Flow Diagrams. Dostupné z WWW: . 39 Amazon Web Services, LLC. Amazon Web Services [online]. 2010 [cit. 2010-05-10]. Dostupné z WWW: . 40 Google Inc. Google AppEngine [online]. 2010 [cit. 2010-05-10]. Dostupné z WWW: .
18
webový operační systém jako je tomu u systému Windows Azure společnosti Microsoft41, nebylo by pochyb o tom, že se entita nachází již mimo vlastní systém aplikace. Pokud bychom chtěli datové toky více konkretizovat, její datové toky se ještě více rozšíří (obrázek 2). Požadavky na geoprocessing a geodatabázi
Výběr zdrojových dat Nastavení hodnot atributů
Uživatel
Zdrojová geografická data
Výběr vrstvy pro propočet
Generování cenové mapy
Cenová mapa nemovitostí
Generování diferenční mapy
Diferenční mapa cen nemovitostí
Rámec ArcObjects
Zpracovaná data Zpráva o činnosti aplikace (report) Zobrazení cenové mapy
Aplikační data atributů
Uživatel
Zobrazení diferenční mapy Požadavky na geoprocessing Zpracovaná data
Rámec ArcObjects
Obrázek 2: schéma toku dat v aplikaci, DFD první úrovně. Zdroj: vlastní zpracování.
Zde je patrné, jak proudí data od uživatele do systému a naopak, kde jsou data ukládána a co se s nima děje. Uživatel nejprve vybere zdrojová geografická data (vrstvy neboli layery nebo tzv. shapefile), která jsou načtena do aplikace. V nich si uživatel nastaví požadované hodnoty atributů, tedy vlastností jednotlivých vrstev (tím se rozumí například nastavení váhy faktorů nebo délka jejich působnosti, jak je vysvětleno později). Následně je na vyžádání uživatelem vytvořena, po několika krocích zpracování zdrojových geografických dat pomocí nástrojů ArcGis i vlastního modelu, cenová mapa nemovitostí. V případě, že si uživatel načte taky konkrétní vrstvu s cenami nemovitostí pro danou lokalitu, výsledky si pak již nebude muset prohlížet jen ve formě koeficientu k celku. Bude mít možnost zobrazit i konkrétní vypočtenou hodnotu pro danou nemovitost a nechat si dodatečně propočítat 41
Microsoft Coproration. Windows Azure [online]. 2010 [cit. 2010-05-10]. Dostupné z WWW: .
19
a vygenerovat tzv. diferenční mapu cen nemovitostí. Mapa jako taková (tedy mapa jako rastr) bude vygenerována taky geoprocesními nástroji informačního systému ArcGis, ceny, na základě kterých bude mapa vytvořena, budou vypočteny interním modelem aplikace. Ukládány budou všechny mezivýsledky a stejně tak finální výsledky. Uživateli se po vytvoření cenové mapy zobrazí finální zpráva o činnosti aplikace, tedy report.
2.5 Vstupy, výstupy a podporované formáty Vstupem do aplikace, jak je částečně patrno i z obrázku 2, je otevřený vektorový formát shapefile společnosti ESRI42. Vstup musí být co do absolutního počtu alespoň jeden. Výstupním formátem je taky formát shapefile. Aplikace vytváří vlastní popisní soubory ve formátu xml s koncovým označením .map.xml, do kterých si ukládá informace potřebné k vytýčeným úkolům. Obsahuje následující údaje:
Relativní cestu k mapovému souboru MXD obsahující projektový soubor aplikace ArcMap. Obsahuje informace o souřadnicích, prostorové informace, umístění a pořadí vrstev apod.
Údaje o jednotlivých vrstvách přítomných na mapě, zejména o Název vrstvy nezávislý na velikosti písma (case-insensitive) a sloužící jako interní identifikátor vrstvy. Srovnávání textových řetězců v celé aplikaci je prováděno přes transformaci na velká písmena neutrální lokalizace (invariant culture). o Interní typ vrstvy, tedy typ působení faktoru (jestli je pozitivní, negativní nebo je pozitivní a časem se změní na negativní nebo opačně) o Vzdálenost, při které dochází ke změne faktoru z pozitivního na negativní a opačně o Vzdálenost, při které působí faktor největší silou o Vzdálenost, při které faktor ztrácí svůj vliv o Největší sílu při daném typu faktoru o Značku (přepínač, flag), jestli vrstva představuje výslední vygenerovanou cenovou mapu
V aplikaci existují dva typy formátu shapefile, které musí mít předepsaný formát a nedoporučuje se je použít jako zdrojový soubor pro generování map nebo výpočet cen. Jednak je 42
Environmental Systems Research Institute, Inc. ESRI Shapefile Technical Description [online]. USA : ESRI, 1998 [cit. 2010-05-10]. Dostupné z WWW: .
20
to shapefile již vytvořené cenové mapy a jednak shapefile obsahující informace o cenách nemovitostí v dané lokalitě, která se musí jmenovat „Homes“ a kromě vlastních dat a libovolné užiavatelské struktury musí obsahovat následující sloupce: Název sloupce
Datový typ
Popis
sqm
Long Integer
Plocha bytu ve čtverečních metrech nebo stopách
price
Double
Celková tržní cena bytu
Tabulka 1: Povinné sloupce přítomné v souboru shapefile použitého pro výpočet absolutních cen nemovitostí. Zdroj: vlastní zpracování.
K těmto již uvedeným sloupcům aplikace po vypočtení absolutních cen a zároveň pro potřeby vytvoření diferenční cenové mapy vloží do již existující tabulky další dva sloupce: Název sloupce
Datový typ
Popis
c_price
Double
Celková vypočtená cena bytu jako rozdíl
c_diff
Double
Podíl mezi tržní a vypočtenou cenou bytu
Tabulka 2: Sloupce přidané do již existujícího souboru shapefile potřebné pro výpočet diferenční cenové mapy nemovitostí. Zdroj: vlastní zpracování.
Výstupním souborem diferenční cenové mapy je rastr ve formátech ADF, resp. AUX43 (tzv. coverage file společnosti ESRI). Dalším výstupním formátem je textový soubor ve formátu HTML obsahující zprávu o činnosti aplikace během vytváření cenové mapy (tzv. report).
2.6 Testování aplikace Testování aplikace je možné rozdělit na dva samostatné celky podle způsobu testování. Jednak jsou to automatické jednotkové testy (unit tests) a jednak jsou to testy uživatelského rozhraní, pro které vytvoření úplného automatického testovacího mechanismu není možné. Jsou nazývány testy uživatelského prostředí, interaktivní testy nebo lidově řečeno „klikače“. Pro testování této aplikace budou vytvořeny jednotkové testy pro systém testování NUnit verze 2.5.5. Testy musí ověřit správnost výstupů funkcí, tedy testují shodu výstupu funkce s předdefinovaným očekávaným výstupem. Test projde, pokud se hodnota výstupu funkce shoduje s očekávanou přednastavenou hodnotou, tedy nastane úplná shoda. Pokud se liší, test 43
ESRI. ArcGis Resource Center [online]. 2010 [cit. 2010-05-10]. When is an .AUX file created for rastert datasets?. Dostupné z WWW: .
21
selže. Jednotkové testování je vhodné zejména pokud je systém hierarchicky uspořádaný, ve kterém jednotlivé části závisí na druhých. Taky pokud je systém relativně složitý a v neposlední řadě taky pokud je systém, ať už jednou nebo často, modifikován. V takovém případě je možné, že nastane narušení části, která způsobí v lepším případě pád aplikace a v horším chybové výsledky (někdy taky nazývané tzv. fantomovy chyby neboli phantom errors). Testují se pouze veřejné metody (funkce) veřejných tříd, které jsou vytvářeny tak, aby vzaly nějaký vstup nebo stav a provedly nějaký proces, akci nebo vstup nebo stav změnily. Privátní neboli soukromé metody (funkce) jsou vytvářeny za předpokladu, že systém jako celek používá stejné pravidla a není nutné informace o stavu (například instance třídy vlastní nebo cizí) nebo vstup (například přes formální parametry) nějak dále ověřovat. Pro testy jsou vytvořena zdrojová, manuálně ověřena data (tedy data ověřena člověkem), u kterých je zaručena správnost. Testy uživatelského rozhraní byly vzhledem k jeho malému rozsahu prováděny zcela ručně. Pro zamezení chybovosti uživatelského rozhraní byly použity obsluhující rozhraní (interface), lépe řečeno implementace rozhraní obsluhující uživatelské prostředí.
2.7 Objektový návrh aplikace Aplikace je navržena tak, aby umožnila efektivní a rychlý vývoj s ohlednem na předpokládanou velikost projektu. Především je brán ohled na to, aby nebyla zbytečně vytvořena příliš složitá hierarchická struktura objektů a jmenných prostorů (namespaces), která by časem stěžovala psaní nového kódu a zvyšovala by počet závislostí jednotlivých sestavení (assemblies). Aplikace by měla být součástí jednoho sestavení (assembly) s objekty seskupenými do několika jmenných prostorů (namespaces). Tyto jmenné prostory odrážejí zaměření tříd, jejich funkci a v neposlední řadě taky naznačují, jakou mají objekty v jejich rámci dostupnost neboli viditelnost (scope, visibility) a jestli jsou statické nebo instanční. Hierarchie vzájemných závislostí jmenných prostorů (namespaces) je na obrázku 3.
22
Obrázek 3: Hierarchie závislostí jmenných prostorů (namespaces) aplikace. Zdroj: vlastní zpracování.
Jak je z obrázku 3 patrné, výchozí jmenný prostor (namespace) využívá pouze tříd z prostoru PriceMap.UI, který obsahuje rozhraní umožňující zpracování událostí hlavního okna. Jde především o události uživatelské interakce s hlavním oknem aplikace, ale taky události systémové nebo aplikační. Konkrétní návrh je možné vidět na obrázku 4, ve kterém se obecné události, jako je například kliknutí na tlačítko, spojí s konkrétní událostí jako je například generování mapy.
23
Obrázek 4: Diagram tříd zobrazující výchozí jmenný prostor (namespace). Zdroj: vlastní zpracování.
Jádrem aplikace je prostor PriceMap.Core, který obsahuje vesměs statické třídy určené ke správě aplikace jako takové, ke správě aplikačních proměnných, uchovávání odkazů na vnější zdroje a zdroje, které jsou hardwarové náročné (neboli „drahé“). Příkladem je instanční třída PriceMap.Core.MapProcessor, která je využívána ke geoprocessingu nebo statická chráněná (internal neboli Shared v jazyku VB.NET) třída PriceMap.Core.CoreManager, která spravuje mapový dokument, pamatuje si cesty k důležitým adresářům a spravuje konfigurační soubory projektů. Na obrázku 5 je vidět jmenný prostor (namespace) PriceMap.Mapping. Obsahuje instanční třídy, které slouží zejména k ulehčení operací na jednotlivých vrstvách mapy a ke zjednocení hierarchie objektů, která je jinak roztroušená podle jiných kritérií do rámce ArcObjects. Jednotlivé objekty tak umožňují provádět akce, které by jinak vyžadovaly rutinní opakování kódu a při změnách nebo optimalizaci by pak bylo nutné přepisovat velké části opakujícího se zdrojového kódu. Klíčovou třídou je třída Map, jejíž instance je vytvořena s formálním parametrem aktuální reálné mapy z třídy PriceMap.Core.CoreManager nebo získané přímo z rámce tříd ArcObjects. Ta obsahuje odkazy na své nižší podčásti, které jsou vytvářeny až v okamžiku vyžádání. Každý objekt má odkaz taky na svůj zdrojový objekt, nazvaný „SourceObject“, kde znaky Object jsou nahrazeny názvem nebo zkráceným názvem třídy, nad kterou je třída této aplikace postavena. Tyto vlastnosti třídy (properties) jsou chráněné (internal), aby k nim objekt mimo sestavení (assembly) nemohl proniknout a způsobit nežádoucí nebo nepovolenou změnu stavu.
24
Obrázek 5: Hierarchie jmenného prostoru (namespace) PriceMap.Mapping. Zdroj: vlastní zpracování.
Poslední navrhovanou částí aplikace je jmenný prostor (namespace) PriceMap.Core, zobrazený na obrázku 6. Jak již bylo zmíněno v úvodu podkapitoly, tento jmenný prostor obsahuje vesměs statické třídy uchovávající stav celé aplikace. V přístupu k nim v různých vláknech je pak nutné, kvůli absenci možnosti vytvořit instanci v kontextu běžícího vlákna, objekty
zamknout
(jednosměrně
nebo
úplně),
což
právě
dělá
například
třída
PriceMap.Core.MapProcessor, obsahující třídu System.Threading.ReaderWriterLock starající se právě o jednosměrné zamykání objektů. Třída PriceMap.MapFile je určena k práci s projektovým souborem, stará se o načítání, spravování (mazání, přidávání a úpravu) vrstev přítomných v mapě a obsahuje seznam (List) odkazů na závislou třídu (přepravku, kontejner) PriceMap.Core.LayerFileEntry. Instance této třídy uchovávají hodnoty atributů zadaných uživatelem při editaci jednotlivé vrstvy a jsou pak uloženy do souboru map.xml. 25
Obrázek 6: Jmenný prostor (namespace) PriceMap.Core. Zdroj: vlastní zpracování.
Co se týče ostatních tříd, navrhovaných pro vytváření zpráv činnosti (reportů) nebo okna pro sběr a zadávání hodnot pro jednotlivé atributy vrstev, je kód vesměs přímočárý a nepotřebuje složitější návrh. Třída pro generování reportů sesbírá údaje a funkce pak vytvoří HTML kód, který je zobrazen nebo uložen (a nebo obojí). Okno pro sběr údajů načte hodnoty atributů a v rámci jistých omezení dovolených hodnot údaje sesbírá a vrátí. Pro vrácení údajů se použije vnořená struktura (neboli taky česky záznam, anglicky struct nebo structure) obsahující údaje ze zadaných políček (obrázek 7).
26
Obrázek 7: Jmenný prostor (namespace) PriceMap.Forms. Zdroj: vlastní zpracování.
2.8 Návrh uživatelského rozhraní Uživatelské rozhraní by mělo v zásadě splňovat následující obecné podmínky:
být v souladu se zaužívanými principy vzhledu aplikací v operačních systémech Windows
údaje musí být viditelné a čitelné při standardním rozlišení 96 pixelů na čtvereční palec (DPI)
prostředí musí být snadno přeložitelné do jiných jazyků
musí zobrazovat informace i počas zaneprázdněnosti
umožní navigaci pomocí počítačové myši
umožní vytvářet, otevírat a ukládat dokumenty
umožní pracovat s mapou: přibližovat, oddalovat, zobrazovat mírku a souřadnice a umožnit interaktivní prohlížení výsledků
zobrazovat interaktivní výsledky v okně hlavní aplikace
zobrazovat přítomné vrstvy, umožňovat je přidávat, odstraňovat, vypínat a zapínat zobrazení a měnit pořadí jejich vykreslování
umožnit nastavení vlastností jednotlivých vrstev, není nutno v okně hlavní aplikace
a nakonec samozřejmě umožní vytvořit cenovou mapu a diferenční mapu cen
Z důvodu omezeného účelu a rozsahu práce, stejně jako omezený počet a druh cílového uživatele není nutné stanovit potřebu dodržovat zásady pro správný vzhled, chování a nastavení uživatelského rozhraní jako je stanoveno v doporučení s názvem Windows User Experience Interaction Guidelines for Windows 7 and Windows Vista44. Pro okno hlavní aplikace bylo navrženo následující schematické rozložení (obrázek 8):
44
Microsoft Corporation. Windows User Experience Interaction Guidelines : for Windows 7 and Windows Vista [online]. : Microsoft, 2010 [cit. 2010-05-10]. Dostupné z WWW: .
27
Cenová mapa Nová mapa
Otevřít mapu
Vrstva 1 Vrstva 2 Vrstva 3 Vrstva 4 Vrstva 5 Cenová mapa Homes
Uložit mapu Zvětšit/zmenšit
Vytvořit cenovou mapu
Vytvořit diferenční mapu
1:10,000
Mapová oblast
Oblast pro zobrazování interaktivních výsledků
Souřadnice mapy
Obrázek 8: Schematické znázornění návrhu hlavního okna aplikace. Zdroj: vlastní zpracování.
Hlavní okno se tak rozdělilo do tří částí: v první je seznam vrstev, které bude obsahovat kontextovou nabídku (context menu) obsahující další akce, zejména akce „Přidat vrstvu“ a „Odebrat vrstvu“, které přidávají a odebírají vrstvy z aplikace (mapy), položky „Posunout nahoru“, „Posunout dolů“ měnící prioritu neboli pořadí vykreslování a položka „Vlastnosti“, která zobrazí další okno aplikace s výběrem nastavení hodnot pro jednotlivé atributy vrstvy (obrázek 4). Vstupní data pro předepsanou vrstvu „Homes“ obsahující údaje o tržních cenách nemovitostí a obytné ploše musí aplikace při vkládání vrstvy rozpoznat a podle toho se zařídit. Stejně tak v případě přidání vrstvy, která již obsahuje vygenerovanou cenovou mapu. Střední část hlavního okna zabírá samotná mapa schopna posunování v obou směrech (vertical and horizontal scrolling), přibližování a oddalování (zooming) neboli změna měřítka mapy. Mapa musí být schopna zachytávat požadavky od uživatele, nejlépe kliknutím levého tlačítka myši na prvek mapy. Po kliknutí musí aplikace zabezpečit zobrazení interaktivních výsledků ve třetí části okna. Pro tuto oblast je nejlepší zvolit ovládací prvek schopný zpracovat a vykreslit obsah z textového řetězce obsahujícího kód HTML, aby bylo možné zobrazit tabulky a později taky, podle možností a požadavků, přidat více interaktivních součástí (jako je třeba hypertextový odkaz, a nebo v případě přítomnosti JavaScriptu taky dynamický obsah). Horní lišta musí umožňovat již spomínaný požadavek na práci s projektovými soubory aplikace, tedy musí být možné projekt vytvořit, uložit a otevřít. Po kliknutí na tlačítka 28
„Generovat cenovou mapu“ a „Generovat diferenční mapu“ musí být aplikace schopna vytvořit příslušné mapy, což tvoří jádro aplikace. Okno pro nastavování hodnot atributů jednotlivých vrstev je navrženo jako na obrázku 9: Nastavení Směr vlivu
Váha vlivu
Pozitivní
Nejvyšší váha
1.25
Negativní
Směr vlivu
Hodnoty směru vlivu (obrat, nejvyšší, dosah) Další hodnoty
Další nastavení (barva, průhlednost) OK
Obrázek 9: Navrhované okno pro nastavení hodnot atributů jednotlivých vrstev. Zdroj: vlastní zpracování.
Pro nastavování okna je důležité, aby bylo možné nastavit směr vlivu (pozitivní, negativní, pozitivní měnící se k negativnímu nebo opačně) a taky váhu vlivu fakoru představovaného vrstvou. Pak musí být možné nastavit hodnoty směru vlivu, jako je obrat vlivu (z negativního na pozitivní a opačně), vzdálenost, u které má nejvyšší sílu a dosah faktoru. Musí umožnit nastavování dalších atributů, jakými jsou barva vrstvy a průhlednost (transparency). Mezi další užitečné vlastnosti tohoto okna je navrhováno přidání barevného přechodu (gradient), který zobrazí, v jakém směru a jakým typem vlivu daný faktor působí. Vhodnou nápovědou taky může být automatické propočítavání váhy v konkrétní vzdálenosti od hranic faktoru. Pro uživatelské rozhraní musí ještě existovat jedno okno, které bude zobrazovat aktuální průběh práce programu. Musí zobrazovat hlavní činnost, stadium, ve kterém se nachází (buď v procentech nebo jako poměr dvou celých čísel) a vedlejší činnost spolu se stadiem vedlejší činnosti. Může obsahovat taky ke každé činnosti ukazatel, který zobrazuje poměrnou část prošlé aktivity (progress bar).
29
3 Implementace 3.1 Proces implementace Implementace aplikace neprobíhala zcela jednolitě. Byla rozdělena do tří částí (obrázek 10), které na sebe navazují a postupně přidávají na funkčnosti aplikace. Jak je patrné z obrázku 10, průběžně byly testy psány jednak na ověření funkčnosti již existujícího kódu a jednak byly psány přednostně za účelem napsání metody naplňující zamýšlený cíl. Co se týče třech fází vývoje, nejprve byla vytvořena kostra aplikace, podpůrné třídy z jmenných prostorů (namespace) PriceMap, PriceMap.Mapping a PriceMap.Core. Ve druhém kroku byla implementována funkcionalita generování cenových map na základě lineárního modelu stoupání a klesání váhy vlivů s rostoucí vzdáleností. Ve třetím, posledním kroku, byla implementována funkcionalita generování absolutní ceny nemovitosti na základě vstupních tržních cen a možnost vytvoření diferenční cenové mapy nemovitostí. Poslední, jakousi „tichou“ fázi představuje generování dokumentace vytažené z komentářů funkcí a tříd (tzv. XmlDoc).
Návrh
Implementace
Jednotkové testy
Kostra aplikace
Cenová mapa
Diferenční mapa
Použití aplikace
Obrázek 10: Proces implementace a testování v procesu tvorby aplikace. Zdroj: vlastní zpracování.
Z důvodu licenčních omezení používané verze jsem byl nucen, jak je vysvětleno v dalších kapitolách, upustit od implementace dvou částí aplikace. Jednak z výslední cenové mapy 30
nemohly být odečteny vrstvy cenové mapy překrývající se, tedy tvořící průnik, se zdrojovými vrstvami. Tou druhou a to už více nepříjemnou, bylo omezení funkcionality z důvodu vypuštění generování diferenční mapy cen nemovitostí. Zdrojová data jsou nicméně generována aplikací, proto je možné diferenční mapu nahradit ručním nebo skriptovaným generováním přímo z aplikace ArcMap. 3.1.1 Hlavní myšlenka aplikace Ještě předtím, než začnu popisovat proces implementace a jeho detaily, je na místě vysvětlit, na jaké myšlence je aplikace založena. Klíčovým pojmem jsou faktory. Ty jsou představovány jednotlivými vrstvami, které uživatel importuje (vloží nebo načte) do aplikace ve formě již tolik spomínaných souborů shapefile. Ty si uživatel nadefinuje, vytvoří a upraví například v aplikaci ArcMap, která je součástí systému ArcGis. Jsou to třeba stromy, budovy, novostavby nebo řeky, jezera, silnice, tramvajové pásy nebo zastávky městské hromadné dopravy. Klíčovou myšlenkou těchto faktorů, tedy lépe řečeno externích faktorů, protože působí na rezidenční nemovitost zvenčí, je ta skutečnost, že působí nějakou váhou do jisté vzdálenosti a spolu s ní se mění (neboli váha je funkcí vzdálenosti). Například spomínané tramvajové pásy: se zvyšující se vzdálenosti směrem od nich se jejich hluk snižuje až úplně zanikne. Nebo třeba upravené obytné novostavby s rozvinutými službami přitahují pozornost lidí, kteří v blízkosti těchto budov rádi tráví čas a pohybují se, nenudí se, cítí se bezpečně a ve vhodném sociálním prostředí. Dá se tedy říct, že čím jsou blíž k budově, tím ji vnímají silněji a tedy se váha jejího vlivu zvyšuje. Na základě těchto příkladů bychom mohli rozdělit tyto faktory na pozitivní (ona budova) a negativní (tramvajové pásy). Skutečnost není však tak jednoduchá, jak by se na první pohled mohlo zdát. V reálném prostředí totiž nikdo skutečně nechce bydlet těsně u tramvajové zastávky, většina lidí ji však chce mít v rámci nějakého dosahu. Dejme tomu, že do vzdálenosti 120 metrů je příliš hlučná a pohybuje se kolem ní hodně lidí. Pak bychom mohli teoreticky říct, že nám tramvajová zastávka ve vzdálenosti 120 metrů ani nevadí ani nějak nepřináší pozitiva, protože se vyrovnávají. Řekli bychom, že třeba 200 metrů je ideální vzdálenost bydlení od tramvajové zastávky, protože na tramvaj není daleko a hluk je už dobře rozptýlen, takže jej v podstatě nevnímáme. A pak si taky například řekneme, že víc než 500 metrů na tramvaj stejně chodit nebudeme, protože to už raději půjdeme autem. Proto je vzálenost 500 metrů pro nás přesně tak nezajímavá, jako ona vzdálenost 120 metrů, kde se pozitivní a negativní vlivy vyrovnávají.
31
Pro potřeby aplikace si to tedy shrneme tak, že známe dva typy faktorů: ty, které začínají přímo u sebe působit jako negativní a pak se v nějaké vzdálenosti vyrovnají negativa a pozitiva a jejich působení se otočí a nastane přesně opačný efekt – efekt pozitivní. Příkladem jsou již spomínané tramvajové zastávky. Jejich působení pak někde vrcholí a pak zase klesá, až úplně zanikne. Druhým typem takového efektu je pak opačně působící faktor: nejprve je pozitivní a pak se nám otočí až se z něj stane negativní. Takových příkladů je ovšem poskromnu, dají se ale najít. Může ním být například veřejné osvětlení, které přináši velmi vysoké množství užitku, pokud stojíme těsně u lampy (pokud zanedbáme její vlastní stín pochopitelně) ale s rostoucí vzdáleností její užitek klesne, tedy v místě kde už z lampy nedopadá žádné volným okem viditelné a využitelné světlo až se její působení obrátí a začne působit negativně: v jisté vzdálenosti nás totiž lampa může osvítit a oko se nestíhá tak rychle adaptovat na tmu, jak by to bylo za přirozeného nočního světla (nebo tmy). Dá se taky předpokládat, že pokud odbočíme z osvětlené uličky, koncentrace kriminality na těchto místech je mnohem vyšší, než kdyby osvětlení nebylo k dispozici. Je třeba si samozřejmě uvědomit, že tyto příklady jsou čistě subjektivní – někdo by si mohl nastavit zcela jiné hodnoty vzdáleností nebo dokonce kvalifikaci toho kterého vlivu jako pozitivního nebo negativního. Pokud bychom se pokusili ony vzdálenosti nějak pojmenovat, nulovou vzdálenost od bodu působení je pro naše potřeby nazývána stejně – tedy nulová neboli počáteční vzdálenost (anglicky initial distance). Vzdálenost oněch 120 metrů od tramvajové zastávky bychom mohli nazvat vzdálenosti obratu efektu (change distance). Další vzdálenost, tedy tu, kde působí faktor nejvíc, ale opačnou silou, nazýváme vrcholní vzdáleností (peak distance) a tu, kde se rozplývá, vzdáleností ztráty efektu (fade out distance). Pomocí nastavení vhodných hodnot těchto vzdáleností jsme pak schopni docílit toho, že některou vzdálenost kvalifikujeme jako pouze negativní nebo pouze pozitivní a jsme schopni položit její vrcholní působení na libovolné místo. Uživatelské rozhraní aplikace se tuto skutečnost snaží zjednodušit tím, že zobrazuje barevný přechod a hodnoty, které v daném bodě nabývá. Pokud uživatel hodnoty přepíše, barevný přechod se automaticky přizpůsobí novému stavu, přepočte hodnoty ve vyznačených bodech a tím uživateli našeptá, jak bude efekt a jakou sílou na kterém místě působit. Reálné ukázky jsou v části věnované implementaci uživatelského rozhraní. Teď, pokud jsme si již definovali, jaké entity působí, osvětlíme ještě jednu dimenzi aplikace a to skutečnost, jak se takové efekty chovají. Hodnoty váhy, tedy maximálního působení jsou zadávány v logaritmickém měřítku. Hodnota rovna 1.0 tedy znamená, že je efekt neutrální – nepůsobí ani negativně ani pozitivně. Čím jdeme po stupnici blíž k nule, tím má efekt vyšší 32
pozitivní váhu. Hodnota limitně se blížící nule má tedy nekonečně pozitivní vliv. Opačně to platí stejně: čím je hodnota vyšší od 1.0, tím má horší vliv. V nulové vzdálenosti má tedy faktor vždycky hodnotu zadanou jako maximální váhu faktoru, třeba pro pozitivní směrující k negativnímu to může být 0.75. Teď je na místě ještě jedna poznámka: pro potřeby názorné ukázky tohoto modelu v této práci byl zvolen lineárný model nárůstu a poklesu váhy se stoupající vzdáleností. Je však jen otázkou jednodušší implementace zadat na příslušná místa v programu libovolnou funkci, kterou chceme použít – je to však otázka již reálného světa a projekt sám o sobě, jak se vlivy s rostoucí vzdáleností chovají v heterogenním prostředí. Tady je uvažováno vždycky o homogenním prostředí, znova pro příklady ilustrace modelu v práci. Ve vzdálenosti obratu (change distance) má faktor váhu vždycky 1.0, což odpovídá neutrálnímu stavu působení. Pak se začne jeho síla obracet opačným směrem (nad nebo pod hodnotu 1.0), zase lineárně, až dosáhne v bodě vrcholního působení (peak distance) výše obrácené hodnoty svého maximálního vlivu. V případě uvedeného pozitivního efektu by to tady byla obrácená hodnota 0.75, tedy obrácená hodnota čísla 3/4, tedy 4/3. Pak by se začala znova lineárně přibližovat hodnotě 1.0, kterou by nabyla v bodě ztráty efektu (fade out distance). Celou uvedenou vlastnost demonstruje tabulka 3 a navazující obrázek 11, který používá již uvedené inicializační hodnoty 0.75 pozitivního vlivu a vzdáleností 30 metrů pro vzdálenost obratu, 50 pro bod vrcholního působení a 90 pro bod ztráty efektu. Vzdálenost Váha Vliv 10 0.83333 Pozitivní 20 0.91666 Pozitivní 30 1.00000 Neutrální 40 1.16666 Negativní 50 1.33333 Negativní 60 1.25000 Negativní 70 1.16666 Negativní 80 1.08333 Negativní 90 1.00000 Neutrální Tabulka 3: Hodnoty demonstrující uvedené skutečnosti působení. Zdroj: vlastní zpracování.
33
Obrázek 11: Graf zobrazující uvedené skutečnosti působení. Zelená barva představuje pozitivní vliv, hnědooranžová neutrální a růžověčervená negativní vliv. Zdroj: vlastní zpracování.
Co se týče provádění výpočtů vah pro jednotlivé vzdálenosti, jsou pro potřeby demonstrace tohoto modelu vypočteny jako pouhý součin hodnot v dané vrstevnici. Tabulka 4 ukazuje příklad spočítání vah pro vzdálenosti 10, 20 a 30 metrů dvou faktorů stejného směru s různými hodnotami. Vzdálenost 10 20 30
Váha 1 0.75 0.93 1.06
Váha 2 1.24 1.14 1.04
Součin 0.93 1.0602 1.1024
Tabulka 4: Příklad spočítání vah pro vzdálenosti uvedené v textu. Zdroj: vlastní zpracování.
3.1.2 Kostra aplikace Jako úplně první byla zavedena schopnost přihlášení do systému ArcObjects pod dostupnou licencí a její ověření. Pak následovalo vytvoření základního uživatelského rozhraní podle návrhů a vytvoření rozhraní PriceMap.UI.IMainFormUI, které je zodpovědné za zpracovávání uživatelských a aplikačních událostí. Následovalo vytvoření statické třídy obsahující tzv. extension metody určené k překladu textů a popisků v aplikaci do jiných jazyků. Statická třída PriceMap.Core.TranslatorExtensions obsahuje tzv. extension metodu Translate, která má za úkol přeložit zdrojový textový řetězec do cílového jazyka. Cílový jazyk je brán z nastavení jazykového prostředí operačního systému a tím i aplikace. Pokud není daný jazyk při startu aplikace k dispozici, je načten výchozí jazyk a to angličtina (důvody ke zvolení angličtiny jako výchozího jazyka jsou uvedeny v části návrhu aplikace). 34
Pak následovalo vytvoření základní sady tříd umožňující vytváření projektů a práci se soubory. Byla navrhnuta struktura konfiguračního projektového souboru obsahujícího návrhem vyžadované atributy pro uchování hodnot zadaných uživatelem. Kvůli jednoduchosti a rychlosti implementace byl zvolen formátem projektového souboru formát xml. Je tvořen instancí třídy PriceMap.Core.MapFile,
zaserializovanou
do
formátu
XML
pomocí
třídy
System.Xml.Serialization.XmlSerializer. Při otevírání projektového souboru je deserializací vytvořena instance třídy ze zdrojových dat přítomných v projektovém souboru. Za koncovku projektového souboru byla zvolena přípona .map.xml navrhovaná v návrhové části práce. 3.1.3 Cenová mapa Vytvoření této části aplikace bylo z hlediska implementace nejdůležitější. Generování cenové mapy ze zdrojových dat a na základě uživatelsky zvolených hodnot atributů je právě tou částí aplikace, kvůli které byla navrhována. Celý proces vytváření mapy prochází několika fázemi geoprocessingu a výpočtami. Jejich schéma je zobrazena na obrázku 12. Nejprve, ve fázi 1, je zavolána funkce pro vytvoření cenové mapy, která má na starosti vytvořit nové vlákno, ve kterém spustí okno zobrazující stav aplikace a právě prováděnou akci. Zobrazuje jednak celkový proces vytváření mapy a jednak prováděnou podčást, jejich pozici v rámci celého generování a taky vizuální ukazatel stavu generování (tzv. progress bar). Příklad okna zobrazujícího stav aplikace je na obrázku 11.
Obrázek 11: Zobrazení informačního okna během vytváření cenové mapy. Zdroj: vlastní zpracování.
Zde nastává otázka, proč je v novém, tedy pracovním vlákně, spuštěné informační okno zobrazující aktuální stav aplikace a ve hlavním vlákně aplikace se provádí dlouhotrvající 35
výpočty. Problém tkví v nativních knihovnách typu COM systému ArcObjects, které jsou v systému .NET zpřístupněny pomocí systému tzv. COM Interop (a taky například pomocí RCW apod). Ten sice umožňuje používat takové objekty ve více vláknech, ale s několika závažnými omezeními. Jedním z nich je například vlastnost, že takový objekt může přijímat zprávy pouze od objektů ve stejném vlákně a nebo jeho spouštěné prostředí (tzv. thread execution context) musí být konzistentní. Pokud však v aplikaci existuje centrální správa aplikace ve jmenném prostoru (namespace) PriceMap.Core, která obsahuje odkazy na již instancované třídy z dalších COM objektů, využívaných například při vykreslování map, načítání vrstev a jejich úpravu a podobně, není možné je pak jednoduše přesunout do jiného vlákna. Jedním z řešení by bylo vytvořit pracovní vlákno, které by existovalo po celou dobu běhu aplikace a bylo by probouzeno pouze při spouštění činností geoprocessingu nebo úpravy geodatabáze. V tomto vlákně by se pak tyto procesy odehrávaly a hlavní vlákno, ve kterém jsou vytvořeny objekty uživatelského rozhraní by s ním definovaným způsobem (nepřímo samozřejmě) komunikovalo. Tak by bylo hlavní uživatelské prostředí vždy schopné zpracovávat události od uživatele, avšak za cenu zkomplikování modelu aplikace. Pro řešení této práce je však tahle (nebo jiná vhodná cesta) zbytečně složitá a nijakým způsobem neovlivňuje cíl, který má tato aplikace naplnit. Proto je zvolen stávající způsob zpracování požadavků s vytvořením informačního okna v pracovním vlákně. Co se týče samotného procesu vytváření cenové mapy, který je, jak již bylo spomenuto, na obrázku 12, ten je spouštěn postupně, tedy synchronně. Postup vytváření mapy je lineární, je tedy nutností mít k dispozici výstup z předešlé procedury, aby se mohlo začít s další fází zpracování. Ve fázi 3 je tedy zavolána samotná funkce spravující všechny nutné kroky směrující k vytvoření cenové mapy. Nejprve jsou zdrojové vzdálenosti rozdělené podle toho, jak velkou část z faktorů tvoří pozitivní a jak velkou část tvoří negativní vliv. Faktory totiž existují dvojího typu: Pozitivní se sklonem k negativnímu vlivu a negativní se sklonem k pozitivnímu typu. Díky hodnotám, které se dají nastavit pro tyto faktory, je možné nastavit tyto faktory tak, aby se chovali buď jako postoupně slábnoucí faktory (například z maximální váhy až po vyprchání efektu) nebo postoupně silnící faktory (například z výchozí neutrální váhy až k nejvyšší či nejnižší váze a pak se dostávající do neutrální váhy vyprchání). Je možné je taky nastavit tak, aby byly pouze jednoho typu bez proměny: tedy pouze pozitivní nebo negativní. Ony čtyři hodnoty, jak je uvedeno v části používání aplikace, jsou tyto: 36
hodnota nulové vzdálenosti, která je fixní a není možno ji měnit
hodnota vzdálenosti, kde se daný faktor mění na opačný
hodnota vzdálenosti, kde má faktor největší negativní vliv a to s váhou rovnou obrácené hodnotě maximální váhy
hodnota vzdálenosti, ve které má faktor již neutrální, tedy nulový vliv a proto je označována jako vzdálenost vyprchání efektu (fade-out distance)
Pro výpočet cenové mapy je však nutné tyto faktory rozdělit podle vzdáleností a vah tak, aby bylo možné počítat váhu i vzdálenost samostatně pro negativní a samostatně pro pozitivní části vrstev neboli faktorů. Proto se v procesu 3a nejprve rozdělí vrstvy na negativní a pozitivní v každé vzdálenostní vrstvě, se kterou se pracuje. Pak se geoprocessingem vytvoří tzv. Multiple Ring Buffer, tedy jakýchsi vícenásobných vrstev prstenců v definovaných vzdálenostech. V procesu
3b
jsou
pak
jednotlivé
vzdálenosti
od
sebe
odděleny
(nástrojem
ESRI.ArcGis.AnalysisTools.Select) a posléze je pro každou vzdálenost vypočtena lineárním modelem příslušná váha, kterou na danou vzdálenost vrstva neboli efekt působí.
37
1. Vytvoření cenové mapy
2. Vytvoření nového vlákna
2a. Zobrazení okna se stavem aplikace
3. Jádro pro vytvoření cenové mapy
2b. Aktualizace zobrazení stavu aplikace
4. Monitorování stavu aplikace
3a. Vytvoření vícenásobných vrstev vzdálenostních prstenců
3b. Selekce stejných vzdáleností
3c. Sloučení vrstev stejných vzdálenosti stejných typů vlivů
3d. Spojení všech vzdáleností stejných typů vlivů
3e. Přepočet váhy u jednotlivých vzdáleností
3f. Vypuštění překrývajících se ploch
3g. Spojení všech typů vlivů
3h. Přepočet vah všech vzdáleností
3i. Vypuštění překrývajících se ploch
3j. Uložení cenové mapy do nového adresáře
3k. Přidání cenové mapy do aplikace
3l. Obarvení cenové mapy podle váhy vlivů
Obrázek 12: Schéma vytváření cenové mapy. Zdroj: vlastní zpracování.
38
V metodě 3c dochází ke sloučení (pomocí nástroje ESRI.ArcGis.DataManagementTools. .Merge) jednotlivých vrstev na základě jejich vzdálenosti a typu. Jednoduše řečeno to znamená, že se najdou všechny pozitivní a pak negativní vrstvy (neboli prstence) se vzdáleností 10, 20, 30 atd. a pak se sloučí do jedné. Sloupce tabulek s vypočtenou váhou se zkopírují do výsledné tabulky se sufixem _X, kde X představuje číslo slučované tabulky v pořadí. S výstupy metody 3c pracuje metoda 3d, která slučí všechny její vytvořené vrstvy, ale pouze v rámci svého typu, tedy pozitivní zvlášť a negativní taky. Tady je nutné říct, že z důvodu licenčních omezení je nutné slučovat vrstvy po dvou, čímž exponenciálně narůstá čas nutný ke spojení všech vrstev. Tím, že jsou slučovány po dvou, jsou metodou 3e vzaty posledně vygenerované vrstvy (pozitivní a negativní) a je vypočtena hodnota váhy pro danou vrstevnici jako součin hodnot všech vah přítomných v poslední tabulce (kromě nuly samozřejmě). Hodnota je pak uložena do sloupce s názvem „weight“ a ostatní sloupce jsou smazány. Aby se zaručilo, že výstupní soubor neobsahuje překrývající se plochy (a v neposlední řadě taky z důvodu optimalizace), jsou v metodě 3f vypuštěny překrývající se plochy nástrojem ESRI.ArcGis. .DataManagementTools.Dissolve. V tomto bodě jsou již obě typy vrstev připraveny k závěrečnému slučování. Metoda 3g pomocí geoprocessingového nástroje ESRI.ArcGis.AnalysisTools.Union slučí pozitivní a negativní vrstvy, čímž vznikne „surová“ mapa vlivů. S výstupem této funkce pak pracuje metoda 3h, která znova přepočte vahy všech vzdáleností, jako součin obou hodnot, pokud jsou různé od nuly nebo opíše hodnotu, která je různá od nuly, pokud je pouze jedna. Na základě těchto přepočtených dat je pak možné znova, teď už ale společnou „surovou“ mapu „vyčistit“, tedy znova vypustit překrývající se části, což je náplní metody 3i. Tady je zajímavé zdůraznit, že v důsledku nezaokrouhlování je vypuštěno úplné minimum řádků z tabulky (tedy překrývajících se ploch), protože sloupec „weight“ v tabulce uchovávající váhu faktoru na dané ploše je definován jako datový typ Double, který je schopen uchovat číslo s plovoucí desetinnou tečkou (floating point number) a obecně má rozlišovací schopnost 15 čísel, což je obecně dostatek na to, aby se vyskytlo úplné minimum stejných čísel. Po této fázi následují pouze metody „kosmetické“ a sice metoda 3j, která výslednou cenovou mapu zkopíruje do nově vytvořeného adresáře, metoda 3k, která ji přidá do projektu a poslední metoda 3l, která relativně složitým způsobem obarví výslednou cenovou mapu tak, aby byly odlíšené negativní, pozitivní a neutrální vrstvy (plochy). Tím je celý proces generování cenové mapy dokončen a na závěr je uložen a zobrazen report skládající se z časového otisku ve formátu 39
RFC 112345 a zprávy o činnosti převzaté ze zpráv přebírajících informačním oknem (obrázek 11). Je na místě podotknout, že použité metody generování cenové mapy, stejně jako matematický model použitý ke srovnání vah, je ilustrační pro potřeby prezentace modelu tvorby cenové mapy. Je proto možné je nahradit zcela libovolným (v rámci jistých pravidel samozřejmě) algoritmem. 3.1.4 Tvorba diferenční mapy a srovnávání cen Jak již bylo naznačeno v části návrhu aplikace, srovnávání cen je aktivováno po přidání vrstvy s názvem „Homes“ a obsahující některé předdefinované sloupce. Po vykonání příkazu „Vytvořit diferenční mapu cen“ je spuštěn přepočet, který vypočte následovné hodnoty:
Průměrná cena za m2: Představuje průměrnou cenu za metr čtvereční na celé mapě (tedy v celé městské části například nebo mapované lokalitě). Příkladem může být hodnota 30,000 Kč za m2.
Vypočtená cena za m2: Představuje cenu, která je vypočtena podle vzorce průměrné ceny za m2 ÷ hodnota koeficientu kombinované váhy na místě, na kterém se nemovitost nachází. Příkladem může být například koeficient 0.9 při 30,000 Kč, takže vypočtená cena bude 27,000 Kč za m2 plochy.
Vypočtená hodnota nemovitosti: Je to vypočtená cena za metr čtvereční vynásobená počtem čtverečních metrů.
Absolutní cenový rozdíl je tvořen rozdílem vypočtené ceny nemovitosti a tržní ceny nemovitosti.
Relativní cenový rozdíl je tvořen podílem vypočtené a tržní ceny nemovitosti.
Diferenční cenová mapa, jejíž implementace není z důvodu licenčních omezení (rozebráno v následující kapitole) v aplikaci přítomna, ale může být vytvořena na základě vytvořeného sloupce „c_diff“ vrstvy „Homes“ v jakékoli aplikaci, například ArcMap, zobrazuje, ve kterých lokalitách se cena odlišuje od stavu vypočteného aplikací a kde je cena vesměs stejná.
Licenční omezení a zmenšení funkcionality Pro vývoj aplikace byla použita testovací (demonstrační, šedesátidenní) verze aplikace ArcGis Desktop 9.3.1 s licencí pro rozšíření, mezi které patřilo například ArcGis Spatial Analyst (prostorová analýza). Licenční podmínky ArcGis obecně jsou zejména pro vývojáře nezvykle 45
Microsoft Corporation. MSDN [online]. 2010 [cit. 2010-05-11]. DateTimeFormatInfo.RFC1123Pattern Property. Dostupné z WWW: .
40
tvrdé: u velké části produktů jsou právě vývojářské sady do jisté míry buď zcela zdarma nebo zdarma za určitých podmínek (například pro studentské nebo výzkumné účely) nebo výkonových anebo alespoň časově omezených, jako je tomu například u nástrojů společnosti Microsoft v případě Visual Studia Express nebo SQL Serveru Express46, v případě společnosti Apple a jejího produktu pro tvorbu aplikací Xcode47 nebo různých produktů a platforem (od Windows Azure, Google AppEngine nebo různé vývojové nástroje a emulátory pro vývoj aplikací na mobilních zařízeních jako je iPhone SDK nebo Palm Emulator). V případě nástrojů pro vývoj nad systémem ArcGis jsou tyto nástroje ulehčující práci jen velmi těžko dostupné a to i v omezené míře (například nedostupnost offline dokumentace, volně nedostupné sady SDK nebo šablony k prostředí Visual Studio). Ovládací prvky distribuované spolu s aplikací pak jsou volně dostupné pouze dva: prvek MapControl zobrazující samotnou mapu a prvek PageLayout zobrazující mapu na tiskovém formátu. Všechny ostatní ovládací prvky je nutné navrhnout a implementovat od nuly (neboli taky „from scratch“). Na druhou stranu je nutné dodat, že právě dva uvedené prvky tvoří nejsložitější část ovládacích prvků, bez prvního by nebyl možný vývoj této aplikace. Co se týče omezení, od kterých jsem musel z důvodu licence upustit, bylo odečtení zdrojových vrstev (ploch) z výsledků cenové mapy a na druhé straně, poněkud vážnější, nemožnost vytvořit z předpočtených hodnot diferenční cenovou mapu. Tu jsem však měl možnost vytvořit v samotné aplikaci ArcMap, která licenci pro dané nástroje obsahovala (SpatialAnalysis, Spline).
3.2 Uživatelské rozhraní Uživatelské rozhraní aplikace je vytvořeno podle požadavků stanovených v části návrhu aplikace. Hlavní okno programu, po načtení ukazuje pouze na možné způsoby prvotního použití aplikace (obrázek 13), tedy vytvoření projektu nebo otevření nového projektu.
46
Microsoft Corporation. Microsoft Express Home [online]. 2010 [cit. 2010-05-11]. Dostupné z WWW: . 47 Apple Inc. Xcode [online]. 2010 [cit. 2010-05-11]. Dostupné z WWW: .
41
Obrázek 13: Úvodní obrazovka programu. Zdroj: vlastní zpracování.
Po otevření projektu máme možnost akcí popisovaných v části návrhu aplikace, tedy:
Uložit mapu
Vytvořit novou mapu
Otevřít existující mapu
Generovat cenovou mapu
Vytvořit diferenční mapu (resp. připravit data pro generování diferenční mapy)
Přidat a odebírat vrstvy, měnit jejich pořadí vykreslování, zobrazovat a skrývat vrstvy
Měnit hodnoty atributů jednotlivých vrstev
Pracovat s mapou, interaktivně se dotazovat na výpočet hodnoty dané nemovitosti, zvětšovat a zmenšovat a posouvat mapu, zobrazení souřadnic ve stavovém řádku, zobrazení měřítka
Vypínání a zapínání obrysů vrstevnic cenové mapy pro větší plastičnost zobrazení
Některé z popsaných akcí jsou zobrazeny na obrázku 14:
42
Obrázek 14: Hlavní okno aplikace po načtení dat a dotázaní se na cenu nemovitosti. Zdroj: vlastní zpracování.
Jak bylo uvedeno v úvodu této kapitoly, okno pro nastavování hodnot atributů je navrhnuto jednak podle požadavků návrhu, jednak je navíc přítomna ještě funkce automatického zbarvování našeptávajícího proužku a přepočet hodnot vah. Okno pro nastavování hodnot je na obrázku 15 a různé hodnoty při našeptávání jsou v obrázcích 16 – 20. Byla taky přidána možnost nastavit barvu vrstvy (platná u bodů, čar a ploch) a její průhlednost (platná téměř všude). Obarvení cenové mapy je spravováno automaticky pomocí přednastavených barev pro pozitivní vliv, pro negativní a pro neutrální vliv.
43
Obrázek 15: Okno pro nastavování hodnot atributů vrstev. Zdroj: vlastní zpracování.
Pro definování vlivu faktoru postupujícího od negativního k pozitivnímu, jako je tomu na obrázku 16:
Obrázek 16: Negativní vliv směrem k pozitivnímu s váhou 1.10. Zdroj: vlastní zpracování.
nebo pro definování čistě negativního vlivu, jako je tomu na obrázku 17, postačí, pokud nestanovíme hodnotu obratu (nastavíme ji stejnou, jako ostatní hodnoty).
44
Obrázek 17: Nastavení pouze negativního vlivu. Zdroj: vlastní zpracování.
Pro vytvoření vlivu, který působí od pozitivního směrem k negativnímu, nastavíme hodnoty podle obrázku 18:
Obrázek 18: Nastavení hodnot pro výchozí působení vlivu směrem od pozitivního k negativnímu. Zdroj: vlastní zpracování.
Stejně jako v případě negativních vlivů můžeme definovat pouze pozitivní vliv jako na obrázku 19:
Obrázek 19: Definování pouze pozitivního vlivu faktoru. Zdroj: vlastní zpracování.
3.3 Problémy při implementaci Při implementaci jsem se potýkal s problémy zejména ze strany rámce ArcObjects, které působí poněkud nekonzistentním a heterogenním dojmem. Jednak je patrné historické hledisko vývoje rámce (viditelné zejména na příkladech skládání realizace rozhraní (implementation 45
realization), jako je tomu třeba u rozhraní ILayer, který přestal postačovat, proto se zavedl ILayer2, pak ILayer3 a pak další rozhraní. Nekonzistentní model rámce se projevuje taky v různé logice používání objektů: někdy připomínají procedurální model (nutnost používat posílání odkazů na hodnotové typy ve formálních parametrech přes klíčová slova ref nebo out), někdy objektový (například volání funkce pro změnu stavu třídy), někdy vracejí funkce se stejnou logikou návratovou hodnotu a někdy pouze změní interní vlastnosti (properties) třídy a ty je pak nutné přečíst. Taky někdy se používají tzv. indexery48 (např. Item[0]) a někdy jsou k tomu rozepsané tzv. getery a setery (např. get_Row(int)). Taky dokumentace je někdy nejasná, uvádí buď málo příkladů nebo spíš vůbec a občas chybuje; například v tom, jestli je formální parametr předáván pomocí odkazu jako „ref“ nebo jako „out“49. Další nekonzistentnost je možné vidět například v tom, že některé data se dají upravovat přímo přiřazením hodnoty, některé prostřednictvím zvláštní funkce, některé prostřednictvím tzv. seterů a nebo někdy je nutné objekt přetypovat na jiný typ (například u zapisování IFieldEdit) a pro čtení hodnot se pak používají vlastnosti (properties) s přímým názvem (například Name) a pro zapisování se použijí vlastnosti (properties) se sufixem „2“ (například Name2 = „ABCD“). Taky někdy je hodnota uložena automaticky po přiřazení hodnoty a někdy je nutné ji uložit manuálně (například u řádku IRow.Store()).
3.4 Finální verze implementace Z původního návrhu aplikace byla implementována celá část architektury, funkcionality a uživatelského rozhraní. Z důvodu licenčních omezení šedesátidenní studentské verze aplikace ArcGis desktop nebylo možné zahrnout do finální implementace tvorbu diferenčních map. Jsou tvořeny prostřednictvím modulu Spline v licenční skupině Spatial Analyst, které nebyly součástí zkušební verze. Dalším, mnohem více nepříjemným omezením byla časová náročnost výpočtů objektů ArcObjects. Původní plán používat na všechny operace geodatabáze soubory shapefile a jim příslušné tabulky ve formátu Visual FoxPro (DBF) byl sice implementován, ale pro neúměrnou časovou zátěž byly operace se zápisem a čtením tabulek zcela vypuštěny a implementovány pomocí knihoven FastDBF50. Generování jednoduchých map ale i přesto trvá několik desítek minut a v případě složitější mapy sídliště Petřin na Praze 6 trvá několik desítek hodin. Další 48
Microsoft Corporation. C# Language Specification [online]. 2010 [cit. 2010-05-26]. 10.8 Indexers (C#). Dostupné z WWW: . 49 Microsoft Corporation. C# Programmer's Reference [online]. 2010 [cit. 2010-05-26]. Passing parameters (C#). Dostupné z WWW: . 50 Codeplex [online]. 2010 [cit. 2010-05-28]. Fast DBF. Dostupné z WWW: .
46
problém pak nastává se zobrazovaním finálních map, které komponenty ArcObjects nejsou schopny zobrazit v celosti v rozumném čase. Finální cenovou mapu sídliště není komponenta schopna zobrazit v celosti ani v časovém úseku do třiceti minut (za použití procesoru taktu 2,26 GHz a disku s 5400 otáčkami za minutu). Zdrojové kódy aplikace se nacházejí na přiloženém CD, spolu s dokumentací a vzorovými soubory, ze kterých je možné cenové mapy vytvořit. Přiloženy jsou jak jednoduché vrstvy, tak složité vrstvy sídliště Petřin a lokace nemovitostí, které byly k dispozici k prodeji ke květnu 2010. Na obrázku 20 je aplikace s načtenou mapou sídliště Petřiny, na obrázku 21 pak vidíme vygenerovanou cenovou mapu vesnice u dvou jezer s automatickým a tržním oceněním nemovitostí.
Obrázek 20: Finální vzhled aplikace s načteným sídlištěm Petřiny. Vzor: vlastní zpracování.
47
Obrázek 21: Finální vzhled aplikace s vygenerovanou cenovou mapou. Vzor: vlastní zpracování.
48
4 Používání a využití aplikace 4.1 Nastavování vah Původně byla aplikace zamýšlena jako model reality, ve kterém by byly váhy stanoveny jednou osobou. Po úvaze však bylo patrné, že není možné stanovit váhy jednotlivých faktorů a její vzdálenosti pouze ze subjektivního pohledu jednotlivce. Po rozeslání ankety se stručným vysvětlením problematiky, příkladů a předepsané tabulky 41 lidem bydlejícím na vysokoškolských kolejích bylo obdrženo kvůli složitosti problému pouze 19 odpovědí, které zaznamenaly dvě zvláštnosti: lidé se vesměs shodli na tom, co tvoří pozitivní faktory, co negativní a taky by se dalo říct, že se shodli na vzdálenostech, po které určité faktory působí. Co se týče stanovených hodnot vah, zde byly už rozdíly markantní: navzdory upozornění, že váhy jsou velice citlivé, si účastnící neuvědomovali reálnou sílu faktorů a v téměř třetině případů byly váhy nastaveny příliš silně. V ostatních případech byly váhy nastaveny přijatelně. V anketě se odrazila zejména subjektivnost pohledu na věc lukrativity pozemků, respektive lokality a osobní preference subjektů. Jde o to, že každý máme jiné zkušenosti z reálného světa, jiné zájmy, zvyky a preference a v neposlední řadě i povahu. Zatímco jedni preferují cestování autem a přisuzují velký význam parkovištím a silnicím, někteří přisuzují význam právě veřejné dopravě. Pokud někdo rád tráví volný čas v přírodě, přál by si bydlet v její blízkosti a to se právě odrazilo na váhach jednotlivých faktorů. Ve všech případech byla na dotaznících přítomna položka vysoké školy, což souvisí s cílovou skupinou dotazovaných. Plyne z toho vysvětlení, že váhy u takových aplikací by měly být nastavovány nestrannými expertmi na základě zvyklostí trhu, nebo matematických modelů, jak bylo ostatně řečeno již v na začátku práce v souvislosti s otázkami systémů pro automatické oceňování nemovitostí formou AVM. Tyto systémy však potřebují enormní množství informací a potřebují být často aktualizovány.
4.2 Další využití aplikace Aplikace jako taková je vytvořena za účelem ověření teoretického modelu se zanedbáním mnoha faktorů. Nicméně je možné ji použít pro potřeby menšího rozsahu, zejména pro plochy do 1 km2, ve kterých je možné po nastavení vah přizpůsobit aplikaci konkrétnímu cíli (například najít si vhodné místo na rekreaci nebo koupě bytu s nestandardními požadavky na okolité 49
prostředí) nebo si ověřit předpokládané hypotézy a odpovědět na některé otázky. Příkladem mohou být například otázky typu „Do jaké míry ovlivňují prázdné byty lukrativitu ostatních bytů?“ nebo pružně reagovat na změny podmínek („pokud zahřadili cestu přes park, klesla lukrativita okolitých oblastí?“). Po úpravách ve zdrojovém kódu je navíc možné implementovat i rozlišování vnitřních faktorů, jako je například prašnost cest nebo provoz na silnici, preference patra nebo vybavení a stáří bytů a domů a tím ji rozšířit na úplně novou úroveň.
50
5 Stručný návrh informačního systému Metody a postupy použité v aplikaci je možné s použitím systému ArcGis Server využít na vybudování informačního systému. Po implementaci dodatečných částí jako je složitější matematický model výpočtů vah, zohlednění interních faktorů navrhovaných v předešlé podkapitole by mohl být takový systém nasazený na server, kde by měl k v databázích dispozici relativně velké množství dat a záznamů o existujících nemovitostech, byl by propojen se servery, na kterých by běžely aplikace GIS s možnosti výkonných a rychlých nástrojů pro geoprocessing a aplikační server, na kterém by běžela samotná aplikace. Schéma takového systému je uvedena na obrázku 20.
Samospráva
Stát
Zjišťování daní
Finanční kontrola
Poskytování úvěrů, hypoték, solventnost klientů
Banky Pojištění nemovitostí
Webové rozhraní Vytváření modelů
Pojišťovny
Hodnota prodávané nemovitosti, Možný zisk nebo solventnost klienta
Aplikační servery Realitní kanceláře
Výzkum Servery GIS
Databázové servery
Vývoj aplikací
Obrázek 22: Názorné schéma využití informačního systému pro oceňování nemovitostí. Zdroj: vlastní zpracování.
Takový systém by byl na jedné straně plněn daty z reálního prostředí, jakými jsou stav budov, zařízení, použitý materiál při stavbě, stavební úpravy, ale taky informace o okolí staveb a pozemků, zamýšlené nebo již existující stavby v kompetenci samosprávy nebo státu, informace o 51
infrastruktuře a o ekonomických poměrech v zemi (propojení se statistickým úřadem). Dále by byl aktualizován a optimalizován programový kód vývojem aplikací na jedné straně a spolupracující s výzkumem (ekonomickým, stavebním apod.) vytvářejícím ekonomické modely tvorby cen. V neposlední řadě by tady byly ještě přítomné vylepšující se matematické modely tvorby cen a vzájemných vlivů. Server by běžel na principu jedného propočtu za několik týdnů nebo měsíců s aktualizovanými daty pro specifickou lokalitu. Výsledky by byly uloženy a použity pro výstupy a dotazy. Uživatelmi takového systému by bylo celé spektrum uživatelů. Po přihlášení do systému by mohl být dotazován státními orgány pro ohodnocení nemovitostí zejména kvůli finanční kontrole nebo výběru daní (na tento účel dnes slouží systémy CAMA, jsou rozebrány v předešlých kapitolách) a místní samosprávy (ze stejných důvodů). Pak by je mohly používat banky, zejména z důvodu ověření si hodnoty zástavy, návratnosti investice nebo poskytnutí hypotéky, čímž by snížily riziko nevýhodně poskytnuté hypotéky51. Z podobných důvodů by systém mohly používat taky pojišťovny. Realitní kanceláře by zase mohly ověřit tvrzení klientů nebo vyhledat nemovitosti vhodné ke koupě a pak se snažit danou nemovitost prodat nebo koupit. Možnosti použití takových systémů jsou velmi široké, mohou je používat taky developerské společnosti k zjištění návratnosti investice, mohou být využity ke zlepšení územního plánování nebo taky mohou být vytvářeny fiktivní modely a simulace úpravy městských částí a jejich vliv na konečnou lukrativitu upravené lokality (například v souvislosti s veřejnými zakázkami přestavby náměstí nebo výstavby budov).
51
The Truth About Realty [online]. 2007-06-25 [cit. 2010-05-11]. Real Estate AVMs And Automated Value Model. Dostupné z WWW: .
52
Závěr Aplikace, kterou jsem v práci navrhoval a posléze implementoval dokázala, že existuje přímá souvislost mezi cenou nemovitosti a její polohou, respektive vlivem externalit. Různá váha externalit v závislosti na vzdálenosti od nemovitosti a jejich interakce dokázala značně ovlivnit hodnotu bytu a to i po zanedbání uvedených faktorů v důsledku zjednodušení. Nejdůležitějším poznatkem však je, že aplikace po nastavení vah dokázala na základě implementovaného modelu určit koeficient pro výpočet ceny s takovou hodnotou, že po dosazení průměrné ceny bytů v dané lokalitě se automaticky vypočtena cena vždycky pohybovala v pouze malém rozmězí. Lze ji tím použít pro odhad hodnoty nemovitostí v téměř libovolné lokalitě, samozřejmě po jejím rozšíření a zohlednění více faktorů působících na ceny. Je nutné taky v produkčním nasazení upřesnit relativně jednoduché lineární modely nebo je zcela nahradit modely složitějšími, reálně odrážejícími povahu prostředí, ve kterém má být výpočet proveden. Na základě sesbíraných informací a faktů, průzkumu dosavadních techologií a dostupných aplikací a v neposlední řadě taky na základě výsledků a výstupů navrhnuté a implementované aplikace si myslím, že existuje reálná možnost implementace takového produktu (systému) pro tvorbu cen nemovitostí, který by reálně odrážel skutečnou tržní hodnotu nemovitostí a dokázal ji popsat a odhadnout vývoj jejich cen. Je však nutné do této oblasti investovat velké finanční prostředky na sledování trhu, vývoj aplikací a zejména matematických modelů, které dokáží skutečnost reálně popsat a tím i odhadnout cenu tak, aby odrážela co nejvěrněji skutečnost. Jsem přesvědčený o tom, že při investování dostatečních prostředků (finančních, časových i osobních) do problematiky vytváření modelů automatického oceňování nemovitostí a působení vnějších a vnitřních faktorů bude možné vyvinout systém schopný reálně odhadnout ceny nemovitostí pro potřeby různých subjektů, i když spočátku pod dohledem expertů. Naději dávají taky metody používané v oblastech umělé inteligence, logiky a ekonomie a expertních systémů.
53
Seznam použité literatury a pramenů 1. Amazon Web Services, LLC. Amazon Web Services [online]. 2010 [cit. 2010-05-10]. Dostupné z WWW: . 2. Apple Inc. Xcode [online]. 2010 [cit. 2010-05-11]. Dostupné z WWW: . 3. Automated Valuation Model In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2008-11-18, 2010-04-28 [cit. 2010-05-09]. Dostupné z WWW: . 4. Calnea Analytics Ltd. Heatmaps [online]. 2010 [cit. 2010-05-09]. Dostupné z WWW: . 5. Calnea Analytics. Calnea Analytics [online]. 2010 [cit. 2010-05-09]. Automated Valuations. Dostupné z WWW: . 6. CAMA Resources & Technologies, LLC. CAMA Resources & Technologies, LLC [online]. 2010 [cit. 2010-05-28]. CRT's FAQ. Dostupné z WWW: . 7. CAMA Resources And Technologies LLC. CAMA Resources And Technologies LLC [online]. 2010 [cit. 2010-05-09]. Frequently Asked Questions. Dostupné z WWW: . 8. Česká komora odhadců majetku. Česká komora odhadců majetku [online]. 2008 [cit. 201005-09]. Profese odhadce. Dostupné z WWW: . 9. CHEN, Xin. Developing Application Frameworks in .NET. United States of America : Apress, 2004. 370 s. ISBN 1-59059-288-3. 10. Chicago Tribune. Median Price Heat Map [online]. 2010 [cit. 2010-05-09]. Dostupné z WWW: . 11. Codeplex [online]. 2010 [cit. 2010-05-28]. Fast DBF. Dostupné z WWW: . 12. DOWNIE, Mary Lou; ROBSON, Gill. Automated Valuation Models : An International 54
Perspective [online]. London : The Council of Mortgage Lenders, 2007 [cit. 2010-05-28]. Dostupné z WWW: . 13. Environmental Systems Research Institute, Inc. ESRI Shapefile Technical Description [online]. USA : ESRI, 1998 [cit. 2010-05-10]. Dostupné z WWW: . 14. Environmental Systems Research Institute, Inc. ESRI Shapefile Technical Description [online]. USA : ESRI, 1998 [cit. 2010-05-10]. Dostupné z WWW: . 15. ESRI. ArcGis Resource Center [online]. 2010 [cit. 2010-05-10]. When is an .AUX file created for rastert datasets?. Dostupné z WWW: . 16. ESRI. ArcGis 9: Editing in ArcMap. USA : ESRI, 2004. 495 s. 17. ESRI. ArcGis 9: Editing in ArcMap. USA : ESRI, 2004. 495 s. 18. ESRI. ArcGis 9: Geoprocessing in ArcGis. USA : ESRI, 2004. 364 s. 19. ESRI. ESRI Products Overview [online]. 2010 [cit. 2010-05-28]. ArcGis Server. Dostupné z WWW: . 20. ESRI. ESRI Products Overview [online]. 2010 [cit. 2010-05-28]. Desktop GIS. Dostupné z WWW: . 21. ESRI. ESRI Resource Centers [online]. 2010 [cit. 2010-05-28]. Dostupné z WWW: . 22. GÁLA, Ing., Libor; POUR, Doc. Ing. CSc., Jan; TOMAN, Doc. Ing. CSc., Prokop. Podniková informatika. Havlíčkův Brod : Grada Publishing, a.s., 2006. 485 s. ISBN 80247-1278-4. 23. GasBuddy Organization Inc. USA National Gas Price Heat Map [online]. 2010 [cit. 201005-09]. Dostupné z WWW: . 24. Google Inc. Google AppEngine [online]. 2010 [cit. 2010-05-10]. Dostupné z WWW: . 25. Interactive Training Technologies Limited. GetAhead interactive multimedia business and 55
career skills training courses [online]. 2010 [cit. 2010-05-10]. Data Flow Diagrams. Dostupné z WWW: . 26. Microsoft Coproration. Windows Azure [online]. 2010 [cit. 2010-05-10]. Dostupné z WWW: . 27. Microsoft Corporation. C# Language Specification [online]. 2010 [cit. 2010-05-26]. 10.8 Indexers (C#). Dostupné z WWW: . 28. Microsoft Corporation. C# Programmer's Reference [online]. 2010 [cit. 2010-05-26]. Passing parameters (C#). Dostupné z WWW: . 29. Microsoft Corporation. Microsoft Express Home [online]. 2010 [cit. 2010-05-11]. Dostupné z WWW: . 30. Microsoft Corporation. MSDN [online]. 2010 [cit. 2010-05-11]. DateTimeFormatInfo.RFC1123Pattern Property. Dostupné z WWW: . 31. Microsoft Corporation. Windows User Experience Interaction Guidelines : for Windows 7 and Windows Vista [online]. : Microsoft, 2010 [cit. 2010-05-10]. Dostupné z WWW: . 32. Microsoft Corporation. C# Language Specification 3.0. :, 2007. 519 s. Dostupné z WWW: . 33. Microsoft Corporation. COM: Component Object Model Technologies : Microsoft COM [online]. 2010 [cit. 2010-05-28]. Dostupné z WWW: . 34. Microsoft Corporation. Common Language Runtime Overview : Microsoft MSDN [online]. 2010 [cit. 2010-05-28]. Dostupné z WWW: . 35. Microsoft Corporation. Microsoft MSDN [online]. 2010 [cit. 2010-05-28]. Runtime 56
Callable Wrapper. Dostupné z WWW: . 36. PANCHAL, Chetan. Chetan's web scribblings! [online]. 2008-12-06 [cit. 2010-05-28]. What is Framework?. Dostupné z WWW: . 37. Real estate appraisal In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 2005-11-22, 2010-05-05 [cit. 2010-05-09]. Dostupné z WWW: . 38. Skyscanner Ltd. Skyscanner [online]. 2010 [cit. 2010-05-09]. Dostupné z WWW: . 39. South Central Kansas Regional Chapter of IAAO. CAMA - AVM : Are they the same? [online]. 2006-07-05 [cit. 2010-05-09]. CAMA - AVM. Dostupné z WWW: . 40. SouWest Software. Souwest Software [online]. 2010 [cit. 2010-05-09]. Instant. Dostupné z WWW: . 41. TEGoVA. European Valuation Standards 2009 : The Blue Book [online]. Sixth Edition. Belgium : Gillis nv/sa, 2009 [cit. 2010-05-09]. Dostupné z WWW: . ISBN 978-909024138-8. 42. TEGoVA. TEGoVA Homepage [online]. 2009 [cit. 2010-05-09]. EVS (Blue Book). Dostupné z WWW: . 43. The Truth About Realty [online]. 2007-06-25 [cit. 2010-05-11]. Real Estate AVMs And Automated Value Model. Dostupné z WWW: . 44. Trulia, Inc. US Home Prices And USA Heat Map [online]. 2010 [cit. 2010-05-09]. Dostupné z WWW: . 45. WICKELL, Janet. Home Buying - Facts About Residential Real Estate Appraisals [online]. 2010 [cit. 2010-05-09]. About.com. Dostupné z WWW: .
57
